标签:blog http 使用 strong 文件 数据 ar 2014
12306采用验证码, 无疑是一种很不错的措施,可以在一定程度上阻止了黄牛们的疯狂行为,不过也给正常使用验证码的童鞋带了个很头痛的问题,在选座提交订单的关键时候,竟然验证码图片拉取不下来又或者验证过程非常耗时。鉴于自己也是无数码农中的有这职业病的一员,为此也来谈谈关于验证码的优化方案。
验证码通常一张静态的图片,但是12306使用的却是一张动态的图片(GIF格式),动态图片的验证码大大的提高了破解的难度,但无疑也具备比较高的生成成本。我们首先来看一下通常情况下的验证码校验流程:
1)浏览器向验证码服务器发起获取验证码图片的请求;
2)验证码服务器返回验证码图片文件和图片文件对应的ID编号(ID编号一般下发到浏览器的Cookie中);
3)浏览器提交用户输入的验证码和图片文件ID编号;
4)Web服务器校验用户输入的验证码与图片中展示的验证码是否一致,根据校验结果来向用户展示不同的页面;
下面我们来看一下系统的整体架构图:
主要处理流程为:
1、获取验证码
1)从配置中心中获取当前可用的频率控制、验证码库、待验证库可用的服务地址列表
2)频率控制,主要控制当前请求是否属于恶意攻击;
3)验证码库,获取可用的验证码信息,即获取一个可用的验证码图片文件地址;
4)将获取到的验证码信息写入到待验证库中,方便后续进行校验验证码;
2、校验验证码
1)根据从前端获取到的图片编号(获取验证码时,下发的对应编号),来从待验证库中获取验证信息;
2)将验证结果发送到校验统计模块;
在设计过程中需要考虑的点:
1)恶意刷新
来自某个IP频繁的请求验证码,大体上就可以判定验证码正在被刷中,需要采取措施进行一定的频率限制,降低继续被刷的请求量,这里我们可以采用比较简单限制来个某个IP请求次数,当然也可以根据业务特性,添加业务对应的频率控制逻辑;
2)验证码有效期
验证码可以生成一条Key—Value的数据存放到Memcache中(即待验证库),Value为:验证码图片文件ID、验证码Code、生成时间,每个请求验证码图片的请求,均在缓存中插入一条记录,每发送一个验证请求,即将缓存中的这条记录删除失效。
3)图片文件与图片编号
两者之间不可以建立一一对应的关系,否则,坏人只需要保存图片编号,下次就可以重复提交对应的验证码;但是可以建立一对多的关系,也就是一张图片对应多个图片编号,但是一图片编号只能唯一对应图片;
4)验证码生成
验证码图片文件的生成相比而言是比较慢的操作,所以需要采用离线计算成功的方案,避免浏览器获取图片验证码文件耗时比较久,影响用户的体验;这里存放一个问题,什么时机启动验证码生成的流程,有以下几种策略:
a)每天定时生成更新,策略简单实现;
b)定时检测验证码可用量,来生成一批新的验证码文件;
总之,验证码图片文件的生成必须是离线进行的,同时在此时需要为图片文件生成一个或者多个编号;服务部署的个数,完全取决于验证码的消耗量;
5)验证码库
验证码库,应该采用那种数据结构?Mysql还是其他的数据结构。在这里,可以尝试采用Redis的list结构来当作消息队列来使用或者其他的可用的消息队列。需要获取验证码时,从消息队列中Pop出一个值即可。每个记录中至少需要存储的字段为:图片编号、图片地址、验证码等信息。消息队列中的记录 < 50%时,可以出发验证码生成逻辑来定时插入新的验证码。面对更并发的验证码请求量,可以在集群中多部署几套Redis消息队列以及验证码生成系统来应对;
6)图片编号的生成
验证码图片文件需要支持在多台机器上面部署多个服务,同时也要支持在单机上面部署多个服务,这里就需要解决如何来生成唯一验证码图片编号的问题。可以通过根据机器IP和服务编号来解决这个问题,每台机器上面的服务均存在一个服务编号(保证服务编号在单机上是唯一的),计算公式可以为:ID = MD5(IP+服务编号+时间戳+自动序列号)
验证码设计(转),布布扣,bubuko.com
验证码设计(转)
标签:blog http 使用 strong 文件 数据 ar 2014
原文地址:http://www.cnblogs.com/llios/p/3921925.html