分类目录归档:博文推荐

移动游戏战斗系统实现方式探讨

腾讯一下出了两款MOBA游戏,全民超神,王者荣耀,玩了一下,效果不错,就分析了一下它底层的一些技术,发现一个是采用的状态同步,TCP协议,另一个是采用的帧同步,UDP协议。自从去年了解到即时游戏帧同步这门技术,我就一直关注使用这个技术的游戏,一直没有发现,虽然我们自己的游戏也是采用的帧同步,毕竟还没有上线,现在线上有帧同步的游戏,效果还挺好,有点小激动。所以就写了这篇文章,分享出来大家一块研究。

      先说一些题外话,感慨一下,没兴趣的直接略过。
做了这么多年游戏了,深深知道一个游戏的成功需要多方面的因素,不仅需要人和,有的时候也需要天时地利,但作为一个游戏开发者而言能决定就是人和,而这也是游戏能成功的基础,有一帮人能够全身心的投入去开发一款游戏,不断的打磨甚至调整方向,面对问题能够及时反馈,不断迭代,就像做一个互联网产品一样,在这个过程中团队里的所有人都能够互相信任,不厌其烦的对产品进行改动,每一次的信任来源不是为大家打鸡血画饼,而是实实在在的数据分析以及努力总结原因后的理性决策。如果以上能够坚持的话,先不说创新,最起码游戏可以做到某一品类的极致,我想在任何的市场环境下,只要这个品类还没死,总有你的一席之地,在我看来很多游戏死了,很多原因是做的还不到位,向当年抄COC的游戏很多,最后缺没有一款成功的,而截至到目前COC的利润还在不断上升,如果国内抄袭者真能做到COC的一样的体验,我想一定会有成功的。
那又有人要说了,怎样才能做的比别人还好呢,这个问题确实比较复杂,我感觉首先一定要有合适的人,什么是合适的人呢,从3个方面考察 责任心积极性 学习能力 能力,我把能力放在最后是因为如果前面两个条件满足的情况下,这个人一定会变得有能力,然后就是需要有个高的要求,目标就是精品,这个不是光说说就行了,从策划设计,程序实现,美术都要向着最高的标准要求,要比市面上的都要优秀,绝对不会为了各种其他因素(时间点,实现复杂)有任何妥协。最后是需要有点耐心,合理安排计划时间,高效率完成,其实这点事最难的,团队里的人很多,游戏制作有的时候经常需要反复,经常就是初期很有激情,中期不断磨灭,到了后期(尤其是项目遇到困难时候)就比较松懈了,如果是没有耐心的人估计在一起继续工作都是问题了,还怎么谈之前的事情。团队是需要打磨的,如果你有一支这样的团队,那真的要好好的珍惜。
        好了,这是我对于游戏开发的一些感慨,还是回归正题吧,对于一个游戏来讲,战斗就是灵魂,如果战斗做不到极致,其他方面做的再好也是徒劳,这几年,也参与了很多游戏的开发,其中有很多游戏是从决策到死掉全程参与,深有感慨。从端游到页游 从页游再到手游 每一个新市场机会出现的时候,都是从闭着眼睛就能赚钱到大部分赚不到钱过度,对游戏的开发技术都要求也是越来越高,只不过每个市场到成熟的时间都被大大缩短了。对于战斗来讲很多都是策划脑补的跟实际做出来的完全不是一回事,很多原因都是战斗方案选型就是错误的。
从程序角度来讲,我把战斗从两个维度分类
       1、从操作方式上分为 回合操作 即时操作
       2、从交互方式上分为 离线战斗 联网战斗,这个地方需要说明一下,有些游戏虽然也能进攻别人,例如COC 但是因为战斗的时候,另外一个人是不可以操作的,类似于这样的战斗也可以称为离线战斗
基本上所有的战斗都是以上两种方式在某种程度的组合而已,例如梦幻西游可以认为是 联网战斗 回合操作类型
最近比较火的全民超神,王者荣耀,属于 (联网战斗|离线战斗)即时操作类型
最新网易出的功夫熊猫 属于 (联网战斗|离线战斗)即时操作类型,相对于dota类的全民超神、王者荣耀,他对延迟要求的更高了。
     如果在立项初期,项目计划时候不确定游戏的操作类型,以及网络要求,做得后期要想调整的话,改动是致命的,假设按照之前时空猎人的方式实现的纯离线战斗及时游戏,最多也只能做做离线PVP,如果想增加联网PVP的功能的话,对于程序来讲几乎需要重写战斗。
     随着移动游戏市场越来越成熟,对于战斗的要求也在提高,原来做一款ARPG,只有单机玩法就足够了,不需要开发实时PVP,但是现在市面上的ARPG不仅可以联网PVP,甚至可以联网组队PVE了,所以我感觉如果现在再去做游戏的话,只是一个单机玩法,或者是离线PVP玩法已经远远不能满足现代玩家的口味了。
我认为现在战斗系统需要满足一下几点。
     1、一定要有离线PVE玩法,或者离线PVP玩法,可以在让玩家在网络不好的时候消遣,节省流量。(全民超神、王者荣耀在5V5匹配时候都有一定几率匹配到离线战斗,这个时候是不耗流量的,其他人全是AI控制的)
     2、一定要有在线PVP,在线PVE,能够让玩家在网络比较好的时候,实时竞技。增加可玩性。
     3、战斗中,尽最大程度节省玩家的流量,例如全民超神这款游戏,一场30分钟的战斗基本上要消耗掉20M的流量,而且此类游戏大部分是玩的联网战斗,基本上在非wifi情况下没法玩。
     4、需要有战斗回放机制,可以让策划设计离线玩法的时候更自由,例如COC,战斗回放基本变成了它游戏的一部分。
     5、防作弊,如果有离线玩法的话,一定有机制对离线玩法的结果进行验证,要不然等你游戏真火了,你就知道错了。
6、实现难度相对较低。
对于联网游戏来讲,同步的方式主要分为两种,状态同步、帧同步。
    1、状态同步:顾名思义,是指的将其他玩家的状态行为同步的方式,一帮情况下AI逻辑,技能逻辑,战斗计算都由服务器运算,只是将运算的结果同步给客户端,客户端只需要接受服务器传过来的状态变化,然后更新自己本地的动作状态、Buff状态,位置等就可以了,但是为了给玩家好的体验,减少同步的数据量,客户端也会做很多的本地运算,减少服务器同步的频率以及数据量。
    2、 帧同步:RTS游戏常采用的一种同步技术 ,上一种状态同步方式数据量会随着需要同步的单位数量增长,对于RTS游戏来讲动不动就是几百个的单位可以被操作,如果这些都需要同步的话,数据量是不能被接受的,所以帧同步不同步状态,只同步操作,每个客户端接受到操作以后,通过运算可以达到一致的状态(通过随机种子保证所有客户端随机序列一致),这样的情况下就算单位再多,他的同步量也不会随之增加。
下面我们从以上的5个方面对各自实现方式进行描述:
状态同步 帧同步
离线战斗、联网战斗并存 大部分的逻辑在服务器,所以需要服务器开发人员将服务器战斗逻辑写成能够在客户端运行的模块,客户端开发人员不需要特别要求就可以实现。 大部分逻辑在客户端,要求战斗逻辑部分与显示部分分离,甚至可以让逻辑部分代码客户端与服务端公用,这部分代码服务器用它来实现实时战斗和战斗验证
PVP,PVE在线战斗 可以实现 可以实现
节省流量 流量大,全民超神采用状态同步,流量30分钟20M 流量小 王者荣耀采用帧同步,流量30分钟8M
战斗回放 通过记录所有的状态同步数据实现,记录两较大 记录文件比较小
离线战斗防作弊 只能通过协议加密,内存混淆,大概数据验证实现,没办法彻底解决 可以用记下来的输入,服务器将战斗重新打一遍,通过这样的方式准确验证战斗结果
网络卡的时候表现 如果网络卡的时候,会频繁出现玩家瞬移,回位,莫名其妙掉血,对于MOBA游戏体验可以参考全民超神 网络卡的时候整个战斗会停止,网络恢复以后逻辑快速执行赶上进度,对于MOBA游戏体验可以参考王者荣耀
实现难度 需要客户端跟服务器开发人员都比较有经验,而且还会有沟通成本,为了达到比较好的战斗效果,需要不断调优状态同步的方式。客户端需要做差值处理之类的。 客户端按照单机战斗方式实现,保证显示层和逻辑层是分离的,保证逻辑层不要用到浮点数,不要用到不确定顺序的逻辑结构,如果是用unity做的游戏,要注意unity自身的physics navmesh 都是不可以在战斗中使用的,因为他们都用到了浮点计算,会出问题,好在对于他们我们都有比较好的替代方式。
总结一下:
    1、对于回合制战斗来讲,其实选用哪种方式实现不是特别重要了,因为本身实现难度不是很高,采用状态同步也能实现离线战斗验证。所以采用帧同步的必要性不是很大。
    2、对于单位比较多的RTS游戏一定是帧同步,对于COC来讲,他虽然是离线游戏,但是他在一样输入的情况下是能得到一样结果的,所以也可以认为他是用帧同步方式实现的战斗系统。
    3、对于对操作要求比较高的,例如MOBA类游戏有碰撞(玩家、怪物可以互相卡位)、物理逻辑,纯物理类即时可玩休闲游戏,帧同步实现起来比较顺畅,(有开源的Dphysics 2D物理系统可用 它是Determisti的)
    4、对于战斗时大地图MMORPG的,一个地图内会有成千上百的玩家,不是小房间性质的游戏,只能使用状态同步,只同步自己视野的状态。
    5、帧同步有个缺点,不能避免玩家采用作弊工具开图。

帧锁定同步算法

帧锁定算法解决游戏同步

早期 RTS,XBOX360 LIVE游戏常用同步策略是什么?格斗游戏多人联机如何保证流畅性和一致性?如何才能像单机游戏一样编写网游?敬请观看《帧锁定同步算法》

《帧锁定同步算法》转载请注明出处:http://www.skywind.me/blog/archives/131

 

算法概念

该算法普遍要求网速RTT要在100ms以内,一般人数不超过8人,在这样的情况下,可以像单机游戏一样编写网络游戏。所有客户端任意时刻逻辑都是统一的,缺点是一个人卡机,所有人等待。

1.客户端定时(比如每五帧)上传控制信息。
2.服务器收到所有控制信息后广播给所有客户。
3.客户端用服务器发来的更新消息中的控制信息进行游戏。
4.如果客户端进行到下一个关键帧(5帧后)时没有收到服务器的更新消息则等待。
5.如果客户端进行到下一个关键帧时已经接收到了服务器的更新消息,则将上面的数据用于游戏,并采集当前鼠标键盘输入发送给服务器,同时继续进行下去。
6.服务端采集到所有数据后再次发送下一个关键帧更新消息。

这个等待关键帧更新数据的过程称为“帧锁定”
应用案例:大部分RTS游戏,街霸II(xbox360),Callus模拟器。

 

算法流程

客户端逻辑:
1.        判断当前帧F是否关键帧K1:如果不是跳转(7)。
2.        如果是关键帧,则察看有没有K1的UPDATE数据,如果没有的话重复2等待。
3.        采集当前K1的输入作为CTRL数据与K1编号一起发送给服务器
4.        从UPDATE K1中得到下一个关键帧的号码K2以及到下一个关键帧之间的输入数据I。
5.        从这个关键帧到下 一个关键帧K2之间的虚拟输入都用I。
6.        令K1 = K2。
7.        执行该帧逻辑
8.        跳转(1)

服务端逻辑:
1.        收集所有客户端本关键帧K1的CTRL数据(Ctrl-K)等待知道收集完成所有的CTRL-K。
2.        根据所有CTRL-K,计算下一个关键帧K2的Update,计算再下一个关键帧的编号K3。
3.        将Update发送给所有客户端
4.        令K1=K2
5.        跳转(1)

1

服务器根据所有客户端的最大RTT,平滑计算下一个关键帧的编号,让延迟根据网络情况自动调整。

 

算法演示

我根据该算法将街机模拟器修改出了一个可用于多人对战的版本,早期有一个叫做kaillera的东西,可以帮助模拟器实现多人联机,但是并没有作帧锁定,只是简单将键盘消息进行收集广播而已,后来Capcom在PSP和360上都出过街霸的联网版本,但是联网效果不理想。这个算法其实局域网有细就经常使用了,只是近年来公网速度提高,很容易找到RTT<50ms的服务器,因此根据上述算法,在平均RTT=100ms(操作灵敏度1/10秒),情况下,保证自动计算关键帧适应各种网络条件后,就能够像编写单机游戏一样开发网游,而不需状态上作复杂的位置/状态同步。

2

从上图的演示中可以看到,两个模拟器进程都在运行1941这个游戏,两边客户端使用了该算法,将逻辑统一在一个整体中。

3

最后这张图是运行KOF99的效果图,两边完美同步。

 

乐观帧锁定

针对传统严格帧锁定算法中网速慢会卡到网速快的问题,实践中线上动作游戏通常用“定时不等待”的乐观方式再每次Interval时钟发生时固定将操作广播给所有用户,不依赖具体每个玩家是否有操作更新:

1. 单个用户当前键盘上下左右攻击跳跃是否按下用一个32位整数描述,服务端描述一局游戏中最多8玩家的键盘操作为:int player_keyboards[8];

2. 服务端每秒钟20-50次向所有客户端发送更新消息(包含所有客户端的操作和递增的帧号):

update=(FrameID,player_keyboards)

3. 客户端就像播放游戏录像一样不停的播放这些包含每帧所有玩家操作的 update消息。

4. 客户端如果没有update数据了,就必须等待,直到有新的数据到来。

5. 客户端如果一下子收到很多连续的update,则快进播放。

6. 客户端只有按键按下或者放开,就会发送消息给服务端(而不是到每帧开始才采集键盘),消息只包含一个整数。服务端收到以后,改写player_keyboards

————-

虽然网速慢的玩家网络一卡,可能就被网速快的玩家给秒了(其他游戏也差不多)。但是网速慢的玩家不会卡到快的玩家,只会感觉自己操作延迟而已。另一个侧面来说,土豪的网宿一般比较快,我们要照顾。

随机数需要服务端提前将种子发给各个客户端,各个客户端算逻辑时用该种子生成随机数,另外该例子以键盘操作为例,实际可以以更高级的操作为例,比如“正走向A点”,“正在攻击”等。该方法目前也成功的被应用到了若干实时动作游戏中。

 

指令缓存

针对高级别的抽象指令(非前后可以覆盖的键盘操作),比如即时战略游戏中,各种高级操作指令,在“乐观帧锁定”中,客户端任何操作都是可靠消息发送到服务端,服务端缓存在对应玩家的指令队列里面,然后定时向所有人广播所有队列里面的历史操作,广播完成后清空队列,等待新的指令上传。客户端收到后按顺序执行这些指令,为了保证公平性,客户端可以先执轮询行每个用户的第一条指令,执行完以后弹出队列,再进入下一轮,直到没有任何指令。这样在即时战略游戏中,选择 250ms一个同步帧,每秒四次,已经足够了。如果做的好还可以象 AOE一样根据网速调整,比如网速快的时候,进化为每秒10帧,网速慢时退化成每秒4帧,2帧之类的。

————–

PS:可以把整段战斗过程的操作和随机数种子记录下来,不但可以当录像播放,还可以交给另外一台服务端延迟验算,还可以交给其他空闲的客户端验算,将验算结果的 hash值进行比较,如果相同则认可,如果不通则记录或者处理,服务端如果根据游戏当前进程加入一些临时事件(比如天上掉下一个宝箱),可以在广播的时候附带。

(完)

解密:腾讯如何打造一款实时对战手游

2015年以来,手机游戏的市场偏好,逐渐从早期的休闲类、跑酷类、卡牌类游戏,转向重度、操作性更强的ARPG 、FPS、MOBA类游戏。

因此实时对战这一游戏玩法,也逐渐成为了手机游戏的一个核心玩法。

纵观AppStore畅销榜前十的游戏,过半都支持玩家实时的PK或者合作攻关。由于实时对战有玩家之间自发进行强互动的特点,活跃度和社交强度都是比较高,为游戏的用户活跃和流水的提高奠定了坚实的基础。

腾讯的游戏开发团队,很早就观察到实时对战这一核心玩法对游戏生命周期影响的重要性,因此在自研产品方面,加大力度开发围绕实时对战这一核心玩法的游戏,从而诞生了《王者荣耀》、《穿越火线·枪战王者》、《全民超神》、《全民突击》、《天天炫斗》等一大批优秀的作品,其中不乏日活跃过千万的大作。

而早期的休闲类游戏如《全民飞机大战》等,也加入了实时双打等游戏特性,所以现在依然可以经常在AppStore畅销榜前十看到《全民飞机大战》这款游戏的身影。

既然实时对战是一个非常重要的游戏玩法,为什么我们现在看到的许多游戏,都不具备这一的玩法,或者并不是游戏的主要玩法?其中一个重要的原因,就是开发实时对战的功能,在技术上需要有一定的门槛。本文希望能向大家分享腾讯是如何跨过这些门槛,解决实时对战游戏开发的一系列核心技术难题。

游戏数据同步方案

首先我们介绍实时对战手游中最难解决的技术问题——弱网络下的同步问题。

通过对玩家的游戏数据进行观察,发现玩家的游戏环境存在很大差异,不同玩家会使用不同的2G/3G/4G/Wifi网络,不同网络之间的延迟相差很大。另外移动网络质量不稳定,且都是按流量收费,这些都是需要考虑的问题。手机在网络间的切换,又会造成底层网络断线、地址变化等问题,都是常见的情况。这些问题的统一解决手段,最重要的是通盘考虑各种需求,选择一个合理的游戏状态同步模型。

腾讯在大量游戏开发的实践中,总结出三种游戏的同步模型:

 

第一种叫MMOG模式。这种同步模型,在端游时代就使用的非常广泛,特别是MMORPG里面。

它的主要实现要点是:服务器负责计算全部的游戏逻辑,并且广播这些计算的结果,客户端仅仅负责发送玩家的操作,以及表现收到的游戏结果。一般来说,玩家发送一个操作到服务器上,服务器根据玩家操作去修改内存中的游戏世界模型,同时运算游戏世界对这个操作的反应,然后把这些反应都广播给相关的多个客户端,每个客户端负责把这些数据表现出来给玩家看。

这种做法的优点是非常安全,由于整个游戏逻辑都在服务器上,服务器只接受合法的玩家操作,一切都经过既定逻辑的运算。另外一个优点是游戏的逻辑更新很方便,因为主要逻辑都在服务器端。一般的游戏玩法需要更新,游戏开发团队自己更新重启服务器就可以了,无需让千万个手机去下载更新包。

但是这种做法的缺点也很明显,首先就是用户的体验非常依赖网络质量,如果一个用户的网速慢,其他玩家都会发现他在游戏中明显的变卡。

另外一个缺点就是服务器负责了太多的游戏逻辑运算。在动作游戏里,服务器往往需要针对二维或者三维空间进行运算。

最后,使用这种同步方案,由于每个游戏表现都要以数据包发往客户端,所以当一起玩的用户数量较多,这种广播的数据包量就会非常大。

因此根据以上的特点,腾讯一般会在那些同局游戏人数不太多,但讲求玩法变化快和安全性高的游戏中采用这种同步方案。腾讯自研手游中比较著名的《穿越火线·枪战王者》、《全民超神》、《炫斗之王》都是使用这种方案。

关注点 表现
网络延迟 <  100ms
流量 占用较大,同时游戏角色越多占用越大
服务器负载 非常高
安全性 很好,能很方便的做反外挂。

第二种方案叫主机模式。这种同步方案的做法是:以参与对战的一个客户端为“主机”,其他的客户端为“副机”。

游戏逻辑的主要运算由“主机”完成,所有的“副机”把操作指令,通过服务器中转,集中发送给“主机”;“主机”完成游戏运算后,把结果指令再通过服务器中转,广播给所有的“副机”。

这个方案看起来有点奇怪,但是却有很明显的优点:首先是大量的实时动作游戏,其游戏过程的逻辑代码,都是在客户端上开发和运行的。客户端的游戏引擎对于二维、三维空间中的位置运算、碰撞检测等功能,都有很好的支持。

因此把整个游戏逻辑由客户端负责,就能让服务器端无需再开发这部分功能。服务器只负责做转发、广播的操作,所以能承载的人数和第一种方案有数量级上的差别。由于“主机”客户端运行游戏逻辑,所以其体验是最好的,就算“副机”由于网络不佳造成体验下降,对于“主机”来说,只是发现“副机”动作有点迟缓而已。

在以PVE玩法为主的游戏中,用户关注的是自己的体验,不会太在意同伴的准确动作,这种情况下,主机模式就是一种不错的同步方案。腾讯的《全民飞机大战》的双打模式就是采用这种方式,效果相当不错。

关注点 表现
网络延迟 <  400ms
流量 一般,大概为MMOG模式一半
服务器负载
安全性 较差,比较容易通过修改客户端作假

第三种方案叫帧同步模式,又叫“锁步模式”。这种模式用形象的比喻来说,就是把所有参与对战的客户端,看成是排成一列的囚犯。这些囚犯们的左脚都被链子所在一起,因此他们如果要往前走,就只能同时迈步,如果其中某个人走快了,或者走慢了,都会让整队人停下来。

在实现上,一般是以服务器按固定的帧率,来搜集每个客户端的输入,然后把这些输入广播给所有的客户端;由于每个操作指令到达所有客户端的时间(帧)都是一样的,所以每个客户端运算的结果也是一样的,同样的输入就会得到同样的结果。

这就好像:其他玩家通过网络,把操作手柄接到你的手机。这种同步方案,是传统单机-局域网游戏中最常用的。

这种同步模型的最大优点是:强一致性。每个客户端的表现是完全一样的,非常适合高度要求操作技巧的游戏。由于广播的仅是玩家的操作,所以数据量很少。不管游戏中的角色数、状态量有多大、多复杂,都不会影响广播的数据量。

但是这个方案也有缺点:对所有玩家的延迟都有要求,一般来说要求在50毫秒以内。如果有一个客户端网络卡了,所有的客户端都要停下来等,大家在玩《星际争霸》就见识过:一个玩家断线,全部玩家的游戏都暂停。腾讯游戏中的《王者荣耀》、《全民突击》由于竞技性非常强,所以采用了这种方案。

另外在帧同步模式中,数据同步的频率较高,网络延迟越小越好。由于TCP的滑动窗口机制和重传机制,导致延时无法控制,因此帧同步一般采用udp进行网络传输,但udp又会衍生出可靠性问题,对于客户端,如果某些udp包没有收到,就会出现丢帧的情况,所以这里我们自己研发了一套《可靠UDP传输》的协议,应用在《王者荣耀》项目。关于《可靠UDP传输》的相关技术介绍,后续会作为专题继续分享给大家。

关注点 表现
网络延迟 <  50ms
流量 很小
服务器负载
安全性 差,游戏逻辑主要依赖客户端

安全问题

游戏外挂,一直是国内游戏市场的痼疾。在实时对战的游戏中,常见的有修改客户端代码运行时逻辑、协议破解,以及脚本代替玩家行为等外挂。对此,我们花了很大力气,从游戏的内部结构上,对抗这些破坏游戏性的行为。现在比较常用的手段有四种:

第一种是服务器驱动。在同步模型中的”MMOG模型”中,游戏逻辑都由服务器控制,所以外挂能攻击的空间比较小,这是最好的对抗外挂的方法。由于逻辑全部在服务器上运算,所以外挂几乎无法从游戏逻辑中得到任何好处,只能在降低玩家操作难度上想办法。

但是这种方案的代价也是高昂的:服务器需要保存整个游戏世界的模型,并演算所有的AI逻辑,这让服务器消耗大量内存和CPU,增加了服务器端代码的复杂性。

第二种是MonoSvr抽查回放。这种方法是在第一种服务器驱动方案上的一种简化:客户端还是会上传所有的游戏操作,但服务器并不完全的演算整个战斗逻辑,仅对容易被外挂攻击的部分,进行验证。

服务器上仅保留部分世界模型即可,从而降低了服务器的运算量。客户端并不需要等待服务器的命令回复,就可以先按自己的逻辑去运行,所以体验上有更好的表现。如果服务器发现了作弊,会事后惩罚相关的帐号。这种做法也有漏洞:因为那些没有被抽查到的客户端,或没有被验证的逻辑,都可能是外挂攻击的漏洞。

第三种是柔性反外挂。这种方法的校验更加简单,仅仅在服务器上保留了一批预设的校验规则。这些规则可能是核算玩家的收益和付出是否合理、一些重点操作是否符合规则……。

这种方案服务器的压力非常的轻。由于验算的过程大大的加快了,玩家的体验也会很好。不过这种方法的漏洞更加多,一旦外挂熟悉了这些预设的校验规则,就很容易进行针对性的攻击。

第四种是举报系统。这种方法简单来说就是人民战争,让玩家发起举报请求,然后服务器再搜集模拟被举报者的行为证据,进行针对性的验证和惩罚。但这种民不举官不究的做法,很容易被有意识的互刷所利用。这种方案有一定的漏报几率,因此往往是作为其他几种验证机制的后备机制,一起使用。

以上四种,在腾讯的游戏中,往往都是结合起来使用。在实时对战游戏中,我们除了要关注验证的准确性外,同时还需要平衡游戏体验。因此往往需要在很多地方做妥协,但是只要我们有足够多的手段复合使用,真正的漏网之鱼还是很少的。

版本更新问题

手机游戏的版本更新问题由来已久,让用户升级手机上的程序是非常不容易的。经常会出现以下问题:

  • 手机内存小,更新的过程较容易崩溃;

  • 移动设备的网络环境很不稳定。经常下载到一半,用户走出了wifi范围或者进了电梯,网络中断了。

  • 应用商店的版本审核。什么时候能审核通过往往不能预测,对于紧急的BUG来说更是远水救不了近火。

然而,实时对战游戏由于强调竞技性,所以玩法逻辑常常需要进行小的调整优化。并且实时对战的玩法内容需要持续更新,所以经常都需要更新很多程序,在现有的条件下,如果只是简单的按部就班发版本,估计玩家早就跑光了。

从一些自研游戏发版本时的运营数据来看,如果在游戏内进行资源更新,可以做到99.5%以上的成功率的。但是,如果要发布一个程序包版本的更新,成功率往往就会跌至90%以下。

所以每次发布版本,一些游戏的在线人数会下降10%,这对于游戏运营来说,是一个巨大而持久的损失。因此,热更新技术是现在的主流版本更新方式。把程序代码,以脚本来编写,然后使用一个优秀的脚本解析器来运行,就能让程序代码以文本资源的形式,和图片、声音等其他游戏资源一样更新下载了。

我们自己开发了一个xLua执行库,这个库能在Unity3D引擎中运行lua脚本,并且其执行的效率非常高,还能无缝的在脚本中调用游戏引擎的API。这样,我们就可以尽量少的发布新的程序版本,大部分的游戏内容玩法调整,都使用lua脚本更新来实现。

由于使用了资源更新的方式来更新游戏,现在游戏的更新成功率普遍可以达到99.8%左右,并且避免了应用商店的审核,使iOS和Android用户同时玩上游戏的最新版本。

玩家实时沟通

在传统的端游中,玩家在游戏过程中往往会通过键盘打字沟通。后来有一些第三方语音聊天软件,充当了游戏过程中实时沟通的工具。在实时对战的游戏中,和队友的配合往往是游戏的重要乐趣来源,因此实时的沟通非常重要。

所谓的“开黑”,就是表示一个沟通良好的游戏伙伴小组,一起和其他玩家对战,顺畅的沟通能带给玩家巨大的竞技优势。然而,在手机游戏中,屏幕一般都比较小,不可能有空间来让玩家打字输入,况且如此激烈的实时战斗,也没有时间去慢慢的打字。因此自然很多人想到像PC上一样,运行一些实时聊天的语音软件,来辅助游戏沟通。

但是手机操作系统和Windows不一样,在手机上运行的后台软件,除了会严重降低手机运行性能外,还可能被操作系统暂停和关闭。所以游戏+语音工具的路子是走不通的。这时,就需要游戏开发团队,为玩家在游戏中,直接提供实时语音的服务。

 

腾讯自研的两款大作《王者荣耀》、《穿越火线手游》为了改善玩家在PVP对战时的沟通体验,率先使用了腾讯内部的实时游戏语音服务。从上线后玩家反馈的效果来看,这一功能对维持用户活跃非常有价值。

从运营统计数据来分析,有30%的玩家会主动说话,每人单局的语音会超过30秒,累计用过语音的玩家超过85%——这些数据都说明了语音服务是实时对战游戏玩家需要的功能。所以腾讯后续在所有32款对战游戏中,都加入了游戏实时语音服务。后面腾讯也会开放出这一技术为所有游戏开发者服务。

结束语

实时对战游戏的核心技术难点,主要是解决数据同步问题及弱网络下玩家的游戏体验优化。没有一款通用模型可以用于所有游戏,根据自己游戏的模型,设计出合理的游戏架构,才能让游戏的PVP体验趋于完美。

 

转载自: http://mp.weixin.qq.com/s?__biz=MjM5MDI5MjAyMA==&mid=402528028&idx=1&sn=50b90cadc10d545865ebd6897fc6a6c0&scene=23&srcid=03191karOzdEnKKkG78DqeSR#rd

架构师的职责(写的挺好的)

0、前言

架构师是一个没有被严格定义的角色。

在写这篇文章之前,我特意把这几年看过的关于架构和架构师的 书重新翻了一遍,结果发现它们的定义或多或少有一些不一样,而经过了这几年,一些之前同意的观点,现在的我也不敢苟同了。另一方面,业界对于架构师这个岗 位,其实也没有统一的角色定位。在阿里巴巴,前几年是有专职的“架构师”职位的,现在已经回归到“工程师”、“专家”、“研究员”这样的纯技术职位。而我 面试过的人中,也有各种各样的“架构师”,很多小团队里,项目经理就经常自认为架构师。大概架构师目前还不至于称为一个职业,更多的是在项目中的一个角 色,而其角色定位也是模糊的,因此,这个文章里,我主要还是从自己的理解出发,阐述一下这个角色的定位和个人发展的建议。
1、架构师的定义

架构师:任何复杂结构的设计人员。

架构师的名字来自于建筑业,Software Architect直译应该叫“软件建筑师”。从很多方面讲,软件架构师的工作跟建筑师很像,为了寻根问祖,曾经我也看了不少建筑设计的书(推荐一本《建筑的永恒之道》),最后我发现,两者一脉相承,现阶段分道扬镳,未来也许殊途同归。

一脉相承——不管是建筑师还是软件架构师,都是为了“大图”而存在,做好顶层设计,充当需求方和实施者的桥梁,是其最重要的两个职责。

分道扬镳——两者的发展 阶段不同所致。建筑业实践绵延数千年,理论根基有数百年,真正成为一门学科也有一百多年,而软件架构真正出现不过二十年。建筑业已经在足够高的层面上模式 化,建筑师能够真正去“设计”,也就是决定“做什么”。而软件行业还在高速发展中,各个层面的技术还在百花齐放。技术的选择意味着权衡,因此软件架构师更 多还在关注“怎么做”——这也是建筑师可以称设计师,而软件架构师只能算高阶工程师的原因,设计师更关注美感,而美感在软件架构师的考虑优先级里,排不上 第一。

殊途同归——计算机发展 的几十年,也是技术不断往上抽象和模式化的几十年。SOA、IoT、IFTTT等技术理念已经接近于建筑行业的模块化级别,各种“智慧城市”、“生态城 市”已经在架构层面上考虑“做什么”。假以时日,架构师也许能成为一个真正的纯“设计”的职业,到时候大学里也可以开设“软件架构”的专业了,那一句“建 筑设计师在成为建筑设计师之前,是不会成为建筑工人或工程师的“也能在软件行业成为现实。

当然,这只是可能的未来,这需要我们这些前辈技术人员,能够和建筑行业的前辈一样,把技术规范化,设计模式化,还要有一套关于架构美学和功能设计的完整统一的约束,任重而道远。
2、架构的职责

在软件技术发展的前几十年,是没有架构师这个称谓的。所有的 人都是程序员,可能有个带头的人,叫主程序员。随着计算机技术的发展,软件覆盖的领域越来越大,软件本身也越来越复杂,现在,动辄几百万行、几千万行代码 的软件系统已经非常普遍。软件的复杂化,对于开发人员的脑力负担也不断增大,而人脑所能处理的信息量是有限的,于是,软件开发工具、开发方法也在不断发 展,从汇编语言到高级语言,从函数到框架,从面向过程到面向对象,从设计模式到架构模式……

总体而言,人类在软件开发工具的各个维度上都在做着“封装” 和“抽象”,架构设计是这种抽象和封装的最高层次。从架构的维度上,已经不需要考虑语言、函数、设计模式这一类的抽象,而是站在整体软件系统的高度上,考 虑系统设计的技术合理性,需求实现的完整性,商业诉求的匹配度(主要是成本和效率)——这是架构的技术职责。

另一方面,随着行业的发展,软件项目的参与角色和人员也越来 越多,从起初只有程序员和需求方,发展到技术、产品、设计、商务、项目管理多团队,技术团队内部的分工也越来越细化,前端、后端、测试、运维、售前售后技 术、集成技术等应运而生。架构师是技术团队面向产品设计等团队的接口人,承担着弥合技术与非技术团队之间知识和语言体系差异的职责,同时作为技术团队的带 头人,要负责勾勒蓝图,明确边界,让不同技能的团队通力协作,最终完成软件系统的整体建设和发布——这是架构的组织职责。
2.1、架构的技术职责

首先,架构师经常被类比于建筑师,但是有两个建筑领域的基础理念,在软件架构领域是不成立的(至少现阶段不成立):

建筑设计师在成为建筑设计师之前,是不会成为建筑工人或工程师的。——现阶段的软件架构师,一定是从软件工程师成长起来的。

建筑学和工程学之间的区别表现在“做什么”和“怎么做”:建筑师决定做什么,工程师想出怎么做。——现阶段的软件架构师,除了决定做什么,也要决定关键部分怎么做。

架构的技术职责分为三大块:

抽象设计;
非功能设计;
关键技术设计。

首先是抽象设计。架构师需要能自由地在不同的抽象层次和视角上分析需求,不同的架构层次/视角提供了不同的视图,这些视图互相验证,又能构成整体的设计大图。架构的抽象层次分成两个维度:

垂直维度

从上到下,分成企业架构、解决方案架构、应用架构、系统架构 等,这个分层的逻辑,是提供不同颗粒度的业务建模。CTO关注企业架构,它提现了一个企业整体的IT技术建设的战略选择,典

型的就是集中式和SOA、大型 机和云计算的选择等;产品经理和运维关注应用架构,这里映射了产品的业务流程和应用的整体部署依赖;外部客户关注解决方案架构,它定义了如何通过产品的整 合和协同,解决特定客户的特定的技术方案需求;研发工程师关注系统架构,这里定义了单个系统的领域建模和系统框架。

水平维度

具体到对某一个业务的架构设计,又可以区分出业务架构、数据 架构、技术架构、应用架构几个不同的视角。业务架构是对业务领域和业务流程的分析抽象,需要提炼出业务的核心领域模型,业务的可变和不变部分,这是架构师 和产品经理协同完成的;数据架构基于业务架构提炼的核心领域模型做数据模型和存储模型的设计;技术架构基于业务的性能,可用性,安全等非功能性指标,确定 语言、框架、中间件、部署等技术选型;应用架构基于业务抽象设计应用系统的层次结构、系统边界等。

在这些架构划分中,企业架构匹配商业模式,业务架构匹配业务模式,其他几个架构的划分,更多的是从技术的不同视角来看,他们提供了从不同的抽象层次,不同的切面对于功能需求的分析和建模。

同时需要说明的是,架构的抽象是匹配于业务的,就像桥梁设计师不能直接转做摩天大楼设计,架构抽象也是区分领域的,每一个业务领域都有自己的独特性,因此在架构上也是千人千面的,好的架构设计也是对于业务抽象得最好的设计。

架构师的另一个技术职责,是对非功能需求的分析。这 也是“架构服务于功能,高于功能”的含义。这里的非功能性需求包括了软件系统的可靠性、扩展性、可测性、数据一致性、安全和性能等。考虑到成本和运行环境 等限制,这些非功能性需求很多时候是不能同时满足的。这个时候就需要“权衡”

转自: http://my.oschina.net/u/1589651/blog/676078

验证码识别思路

0x00 简介


验证码作为一种辅助安全手段在Web安全中有着特殊的地位,验证码安全和web应用中的众多漏洞相比似乎微不足道,但是千里之堤毁于蚁穴,有些时候如果能绕过验证码,则可以把手动变为自动,对于Web安全检测有很大的帮助。

全自动区分计算机和人类的图灵测试(英语:Completely Automated Public Turing test to tell Computers and Humans Apart,简称CAPTCHA),俗称验证码,是一种区分用户是计算机和人的公共全自动程序。在CAPTCHA测试中,作为服务器的计算机会自动生成一个问题由用户来解答。这个问题可以由计算机生成并评判,但是必须只有人类才能解答。由于计算机无法解答CAPTCHA的问题,所以回答出问题的用户就可以被认为是人类。(from wikipedia)

大部分验证码的设计者都不知道为什么要用到验证码,或者对于如何检验验证码的强度没有任何概念。大多数验证码在实现的时候只是把文字印到背景稍微复杂点的图片上就完事了,程序员没有从根本上了解验证码的设计理念。

验证码的形式多种多样,先介绍最简单的纯文本验证码。

纯文本验证码

纯文本,输出具有固定格式,数量有限,例如:

•1+1=?

•本论坛的域名是?

•今天是星期几?

•复杂点的数学运算

这种验证码并不符合验证码的定义,因为只有自动生成的问题才能用做验证码,这种文字验证码都是从题库里选择出来的,数量有限。破解方式也很简单,多刷新几次,建立题库和对应的答案,用正则从网页里抓取问题,寻找匹配的答案后破解。也有些用随机生成的数学公式,比如 随机数 [+-*/]随机运算符 随机数=?,小学生水平的程序员也可以搞定……

这种验证码也不是一无是处,对于很多见到表单就来一发的spam bot来说,实在没必要单独为了一个网站下那么大功夫。对于铁了心要在你的网站大量灌水的人,这种验证码和没有一样。

下面讲的是验证码中的重点,图形验证码。

图形验证码

先来说一下基础:

识别图形验证码可以说是计算机科学里的一项重要课题,涉及到计算机图形学,机器学习,机器视觉,人工智能等等高深领域……

简单地说,计算机图形学的主要研究内容就是研究如何在计算机中表示图形、以及利用计算机进行图形的计算、处理和显示的相关原理与算法。图形通常由点、线、面、体等几何元素和灰度、色彩、线型、线宽等非几何属性组成。计算机涉及到的几何图形处理一般有 2维到n维图形处理,边界区分,面积计算,体积计算,扭曲变形校正。对于颜色则有色彩空间的计算与转换,图形上色,阴影,色差处理等等。

在破解验证码中需要用到的知识一般是 像素,线,面等基本2维图形元素的处理和色差分析。常见工具为:

•支持向量机(SVM)

•OpenCV

•图像处理软件(Photoshop,Gimp…)

•Python Image Library

支持向量机SVM是一个机器学习领域里常用到的分类器,可以对图形进行边界区分,不过需要的背景知识太高深。

OpenCV是一个很常用的计算机图像处理和机器视觉库,一般用于人脸识别,跟踪移动物体等等,对这方面有兴趣的可以研究一下

PS,GIMP就不说了,说多了都是泪啊……

Python Image Library是pyhon里面带的一个图形处理库,功能比较强大,是我们的首选。

1

SVM图像边界区分

2

SVM原理,把数据映射到高维空间,然后寻找能够分割的超平面

识别验证码需要充分利用图片中的信息,才能把验证码的文字和背景部分分离,一张典型的jpeg图片,每个像素都可以放在一个5维的空间里,这5个维度分别是,X,Y,R,G,B,也就是像素的坐标和颜色,在计算机图形学中,有很多种色彩空间,最常用的比如RGB,印刷用的CYMK,还有比较少见的HSL或者HSV,每种色彩空间的维度都不一样,但是可以通过公式互相转换。

3

RGB色彩空间构成的立方体,每个维度代表一种颜色

4

HSL(色相饱和度)色彩空间构成的锥体,可以参考:

https://zh.wikipedia.org/wiki/HSL%E5%92%8CHSV%E8%89%B2%E5%BD%A9%E7%A9%BA%E9%97%B4

了解到色彩空间的原理,就可以用在该空间适用的公式来进行像素的色差判断,比如RGB空间里判断两个点的色差可以用3维空间中两坐标求距离的公式:

distance=sqrt[(r1-r2)^2+(g1-g2)^2+(b1-b2)^2]

更加直观的图片,大家感受一下:

5

随便把一张图片的每个像素都映射到RGB色彩空间里就能获得一个这样的立方体。

通过对像素颜色进行统计和区分,可以获得图片的颜色分布,在验证码中,一般来说使用近似颜色最多的像素都是背景,最少的一般为干扰点,干扰线和需要识别文字本身。

对于在RGB空间中不好区分颜色,可以把色彩空间转换为HSV或HSL:

6

0x01 验证码识别的原理和过程


第一步:    二值化

所谓二值化就是把不需要的信息通通去除,比如背景,干扰线,干扰像素等等,只剩下需要识别的文字,让图片变成2进制点阵。

7

第二步: 文字分割

为了能识别出字符,需要对要识别的文字图图片进行分割,把每个字符作为单独的一个图片看待。

8

第三步:标准化

对于部分特殊的验证码,需要对分割后的图片进行标准化处理,也就是说尽量把每个相同的字符都变成一样的格式,减少随机的程度

最简单的比如旋转还原,复杂点的比如扭曲还原等等

第四步:识别

这一步可以用很多种方法,最简单的就是模板对比,对每个出现过的字符进行处理后把点阵变成字符串,标明是什么字符后,通过字符串对比来判断相似度。

在文章的后半部分会详细解释每步的各种算法

9

二值化算法

对于大部分彩色验证码,通过判断色差和像素分布都能准确的把文字和背景分离出来,通过PS等工具把图片打开,用RGB探针对文字和背景图的颜色分别测试,在测试多张图片后,很容易可以发现文字和背景图的RGB差距总是大于一个固定的阈值,即使每次图片的文字和背景颜色都会变化,比如:

新浪和discuz的验证码

10

11

通过对文字部分和干扰部分取样可以发现,文字部分的R、G值一般在100左右,B值接近255,但是背景干扰的R、G值则大大高于文字部分,接近200,比较接近文字轮廓部分的像素的RG值也在150以上。通过程序遍历一遍像素就可以完全去掉背景。

12

Discuz的验证码同理

对于一些和文字颜色相同但是较为分散和单一的干扰像素点,我们可以用判断相邻像素的方法,对于每个点判断该点和相邻8个点的色差,若色差大于某个值,则+1,如果周围有超过6个点的色差都比较大,说明这个点是噪点。对于图像边界的一圈像素,周围没有8个像素,则统统清除,反正文字都在图片的中间位置。

如下图:假如当前像素的坐标是x,y  图形坐标系的原点是图像的左上角

13

干扰线对于识别验证码增加了一些难度,不过干扰线只有很小的几率会以大角度曲线的方式出现,大部分时间还是小角度直线,去除算法可以参考http://wenku.baidu.com/view/63bac64f2b160b4e767fcfed.html

对于1个像素粗细的干扰线,在字符为2个像素以上的时候,可以用去噪点算法作为滤镜,多执行几次,就可以完美的把细干扰线去掉。

对于像素数比干扰点稍大的干扰色块,可以采用的算法有:

油漆桶算法(又叫种子填充算法,Floodfill)

种子填充算法可以方便的计算出任意色块的面积,对于没有粘连字符或者粘连但是字符每个颜色不一样的验证码来说,去除干扰色块的效果很好,你只需要大概计算一下最小的和最大的字符平均占多少像素,然后把这段区间之外像素数的色块排除掉即可。

14        15

上下左右4个方向填充还有8个方向填充的不同

判断颜色分布:

对于大多数彩色验证码来说,文字基本在图片中心的位置,每个字符本身的颜色是一样的,也就是说对于文字来说,同一种颜色基本都集中在一个固定的区域范围内,通过统计图片中的像素,按近似颜色分组,同时分析每个颜色组在图片中的分布范围,假如说有一种颜色大部分像素都在图片边缘,那么这个颜色肯定不属于要识别的字符,可以去掉。

对于干扰线,并没有一种十分有效的方式能完全去除并且不影响到文字,不过如果能够成功分割字符的话,少量干扰线对于识别率影响不大。

字符分割算法

破解验证码的重点和难点就在于能否成功分割字符,这一点也是机器视觉里的一道难题,对物件的识别能力。对于颜色相同又完全粘连的字符,比如google的验证码,目前是没法做到5%以上的识别率的。不过google的验证码基本上人类也只有30%的识别率

对于字符之间完全没有粘连的验证码

分割起来是非常的容易,用最基本的扫描线法就可以分割,比如从最左侧开始从上到下(y=0—|||||y=n)扫描,如果没有遇到任何文字的像素,就则往右一个像素然后再扫描,如果遇到有文字像素存在,就记录当前横坐标,继续向右扫,突然没有文字像素的时候,就说明到了两个字符直接的空白部分,重复这个步骤再横向扫描就能找到每个字符最边缘4个像素的位置,然后可以用PIL内建的crop功能把单独的字符抠出来。

对于有少许粘连但是只是在字符边角的地方重叠几个像素的验证码,可以用垂直像素直方图的统计方法分割。如下图:

17

图上半部分是垂直像素直方图的一种直观展示,假如图片宽度为100像素,则把图片切割为100个1像素的竖线,下面的红色部分为当前x坐标上所有黑色像素的总和。这么一来可以很容易的通过直方图的波峰波谷把4个字母分割开。图片的下半部分是扫描线分隔法,因为干扰线和字符旋转的存在,只有M和5直接才出现了连续的空白部分。

除了垂直像素直方图,还可以从不同的角度进行斜线方向的像素数投影,这种方式对于每次全体字符都随机向一个角度旋转的验证码效果很好。对于每次字符大小和数量都一样的验证码还可以用平均分割法,也就是直接先把中间的文字部分整体切出来,然后按宽度平均分成几份,这种方式对字符粘连比较多用其他方式不好分割的验证码很有用,之前的megaupload的3位字母验证码就是通过这种方式成功分割的。

另外对于彩色的验证码,还可以用颜色分割,比如12306的:

18

12306的验证码,每个字符颜色都不一样,真是省事啊。

作为验证码识别里的难点,分割字符还有很多种算法,包括笔画分析曲线角度分析等等,不过即便如此,对粘连的比较厉害的字符还是很难成功的。

标准化

标准化的意思是指对于同一个字符,尽可能让每次识别前的样本都一致,以提高识别率。而验证码设计者则会用随机旋转,随机扭曲还有随机字体大小的方式防止字符被简单方法识别。

还原随机旋转的字符一般采用的是旋转卡壳算法:

19

此算法非常简单,对一张图片左右各旋转30度的范围,每次1度,旋转后用扫描线法判断字符的宽度,对于标准的长方形字体,在完全垂直的时候肯定是宽度最窄的。嗯?纳尼?上面的图是中间的最窄?好像的确是这样,不过只要每次旋转后的结果都一样,对于识别率不会有影响。

扭曲还原的算法比较蛋疼,效果也不怎么样(其实我不会),不过如果识别算法好的话,对扭曲的字符只要人能认出来,识别率也可以达到接近人类的水准。

还有一些常用到的算法,对于提高识别率和减少样本数量有一定帮助:

骨架细化:腐蚀算法

20

腐蚀算法的原理有点像剥洋葱,从最外层沿着最外面的一层像素一圈一圈的去掉,直到里面只剩下一层像素为止。腐蚀算法里面需要用到另一个算法,叫做凸包算法,用来找一堆像素点里面最外围的一层。

最后就是把字符变成统一大小,一般而言是把全部字符都缩到和验证码里出现过的最小的字符一个大小。

详情请自行google……

21

分割算法差不多就到这里了,都是一些比较基础的内容。下面是最终的识别。

0x02 识别

其实到了这一步,单独的字符已经分离出来了,可以训练tesseract ocr来识别了,样本数量多的话,识别率也是很高的。不过在这里还是要讲一下,如何自己来实现识别过程。

第一步,样本现在应该已经是一个矩阵的形式了,有像素的地方是1,背景是0,先肉眼识别一下,然后把这个矩阵转换为字符串,建立一个键值对,标明这串字符串是什么字符。之后就只需要多搜集几个同样字符的不同字符串变形,这就是制作模板的过程,。

搜集了足够多的模板后,就可以开始识别了,最简单的方法:汉明距离,但是如果字符有少许扭曲的话,识别率会低的离谱。对比近似字符串用的最多一般是 编辑距离算法(Levenshtein Distance),具体请自己google。

两种算法的差别在于,对同样两个字符串对比10010101和10101010,汉明距离是6,但是编辑距离是2。

最后一种最NB的识别算法,就是神经网络,神经网络是一种模拟动物神经元工作模式的算法,神经网络有多种不同的结构,但是基本架构分为输入层,隐含层和输出层,输入和输出均为二进制。

22

对于验证码识别来说,输入和输出节点不宜过多,因为多了很慢……所以如果样本矩阵为20×20 400个像素的话,需要对应的也要有400个输入节点,因此我们需要对整个矩阵提取特征值,比如先横向每两个数字XOR一下,然后再竖向每两个数字XOR。

Python有很多封装好的神经网络库,你所需要的只是把特征值输入神经网络,再告诉他你给他的是什么(字符),这样多喂几次之后,也就是训练的过程,随着训练的进行,神经网络的内部结构会改变,逐渐向正确的答案靠拢。神经网络的优势是,对于扭曲的字符识别成功率非常高。另外神经网络在信息安全中还可以起到很多其他作用,比如识别恶意代码等等。

动画验证码

有些不甘寂寞的程序员又玩出了些新花样,比如各种GIF甚至flv格式的动画验证码,下面我来分析一下腾讯安全中心的GIF验证码。

23

晃来晃去的看似很难,放慢100倍一帧一帧再看看?

24

基本上每帧都有一个字符和其他的分开,用最简单的扫描法就能分割出来。

剩下的就很轻松了,旋转还原之后,先填充内部空白,缩小细化之后做成模板对比,识别率怎么也得有90%了。

原本一张图就能搞定的事情,偏偏给了我们8张图,而且每张图还有一点区别,平白无故增大了很多信息量。

另外就是一些所谓的高用户体验的验证码,比如freebuf的:

25

拖动解锁按钮会触发执行一段js,生成一串随机字符串,ajax给后端程序判断。

破解方式就当留给大家的思考题了,假如我想刷评论的话,怎么办。

还有就是声音验证码的识别,现在很多验证码为了提高用户体验和照顾视觉障碍的用户,都有声音验证码,一般来说是机器生成一段读数字的语音。但是在这方面上很多程序员都偷懒了,预先找了10个数字的声音录音,然后生成的时候把他们随机拼到一起,结果就是这样:

26

前3秒为语音提示,后面的是数字,有没有发现什么?

声音也是可以做成模板的哦

最后就是应该怎么样去设计验证码

•整体效果


•字符数量一定范围内随机


•字体大小一定范围内随机


•波浪扭曲(角度方向一定范围内随机)


•防识别


•不要过度依赖防识别技术


•不要使用过多字符集-用户体验差


•防分割 


•重叠粘连比干扰线效果好


•备用计划


•同样强度完全不同的一套验证码

附件添加一个破解验证码的实例包括程序大家自行研究吧:验证码识别

转载自: http://drops.wooyun.org/tips/141

 

中文女和程序员的爱情奇遇

摘要:“我所认为最深沉的爱,莫过于分开以后,我将自己,活成了你的样子”。——写给所有热爱互联网和相信爱情的人。

菜菜是个开朗乐观的90后小文艺少女,随和开放。饭饭是个睿智严谨的80后程序员,温和传统。她还是个大学生,他已是工作族。故事的发生始于青天白日被一大捆Money砸中的相爱几率,两个人的生活也从此发生了翻天覆地的变化。 继续阅读中文女和程序员的爱情奇遇