什么是游戏协议?

 协议是网络游戏前后端交互的实现方式。

游戏中协议的收发过程是怎样的?

 当我们在进行游戏的时候,我们点击了某个按钮进行某一种游戏行为,这个时候,客户端会按照跟服务器约定好的一些规则,将我们的游戏行为对应的请求和参数通过网络封包发送给服务器,服务端在收到这个请求后会对请求内容进行解析,以确定客户端进行的是什么游戏行为,并获取到对应的请求参数,之后服务端会根据代码逻辑来对这些数据进行相应的处理,并将处理结果同样以封包的形式返回给客户端,客户端在接收到封包之后,也会按照约定好的规则进行解析,并将解析后的结果展示给玩家。

 不同的游戏有不同的协议类型和实现方式,有可能客户端发送的请求服务器并不会响应(无效请求),也有可能服务器会主动推送协议给客户端(如整点活动的开启)

常见协议

1.TCP 协议(传输控制协议)
 市面上大部分的游戏都是使用的 TCP 协议,当游戏不需要非常强的实时性,能够容忍一定程度延迟的时候,推荐使用 TCP 协议,但如果是强实时性的游戏(如 moba 和 fps 类型的游戏),就需要使用 UDP 协议来尽量减少延迟
 优点:面向连接(一对一,类似于打电话),传输可靠(能够保证数据的正确性),有序(能保证数据的顺序),可以传输大量数据(流模式),简单直接,无需再次开发
 缺点:对系统资源的要求多,程序结构较复杂,丢包重传时延迟较大

2.UDP 协议(用户数据报协议)
 上面讲到了,一些实时性强的竞技类游戏,一般是使用 UDP 协议
 优点:速度快,对系统资源的要求少,程序结构简单,支持一对一,一对多和多对多的交互通信
 缺点:传输不可靠(可能丢包)、无序(不能保证数据的顺序),传输数据量小,可能需要二次开发来保证实时性

3.websocket 协议
 websocket 是基于 HTML5 语言而诞生的一种协议,websocket 跟 socket 不同,websocket 是一个完整的应用层协议,包含一套标准的 API,多应用于 H5 和微信小游戏
 而 socket 是对 TCP/IP 协议的封装和应用,它并不是一种协议,而是为了方便大家直接使用更底层协议而存在的一个抽象层,将应用层之间的网络通信简单化,当 socket 连接创建时,通过参数指定使用的传输层协议类型,当使用 TCP 协议进行连接时,该 socket 就是一个 TCP 连接
 在 websocket 中,需要服务器和客户端(或浏览器)通过 http 协议进行一次握手动作,然后单独创建一条 TCP 通信通道进行数据传输

PS:如果不需要写机器人的话,其实不太需要关心协议的实现方式,不管是 TCP 协议,还是 websocket 等等,我们需要关注的其实是服务器对协议参数的验证。

常见的游戏协议封包构成

 一般来说,一个通过 socket 传输的完整的游戏协议封包,通常由包长、协议号、验证码、协议参数构成(具体项目可能实现方式略有不同,具体可跟开发人员求证)

 包长:当前封包的字节流长度,用来判断收到的字节流是否是一个完整的封包
 协议号:客户端与服务端之间定义的具体的事件编号,通过协议号,我们可以知道客户端是进行了哪种操作
 验证码:客户端跟服务端之间定义的一套封包有效性验证机制
 协议参数:客户端与服务端进行协议传输的时候附带的实际协议内容,是某种游戏行为的具体实现,协议参数又分为多种类型,有 int 型,str 型,list 型,甚至是某种自定义的对象,这个一般需要参照具体的游戏协议文档。

 ps:由于 TCP 特殊的流模式,某些情况下,我们收到的封包可能是由多个封包黏连在一起的,那么在进行封包处理的时候如何判断是否是一个完整的封包呢?就需要通过包长来判断,如果当前封包的长度等于包长的值,那么就是一个完整的封包,否则就需要对封包进行截取拆分

为什么要测协议?

 游戏中很多行为限制,是在客户端层面的,在我们进行某些非正常游戏行为的时候,客户端已经在逻辑层面阻止了我们的这种行为(比如,在金钱不足的时候我去买一件物品,客户端会判断你的钱是否足够买这件物品,如果不足则会提示金钱不足,并阻止你这次行为),但之前我们讲了,客户端与服务端之间是通过协议封包来进行交互的,客户端阻止你的行为,只是阻止客户端自己来发送这个行为封包,那么服务端对于这种非正常情况是否有做判断呢?如果我伪造一个这样的封包,或者在网络不顺畅的时候,多次点击购买来重复发送封包,是否可以在金钱不足的时候购买成功呢?是否存在刷钱刷道具的漏洞呢?
 这个就是我们进行协议测试的目的:验证服务器逻辑的正确性!

抓包和发包

1.抓包
 既然要分析协议,那么首先就需要看到协议,看到协议那么就需要监听服务端与客户端之间的通信,并抓取游戏封包
 市面上目前有很多抓包工具,常用的游戏抓包神器 WPE、其他的还有 fiddler、wireshark 等,使用方法这里不做过多介绍,网上很多使用教程。

2.发包
 以 WPE 为例,在我们抓到包之后,右键其中的一条封包选择发送,就可以在新弹出来的界面修改封包内容,在修改好对应的参数之后,点击发送按钮,这条修改后的封包就会发送给服务端了。

 开发人员一般也会留一个 GM 指令的接口或者其他的发包方式,通过预留接口也可以实现对服务器进行发包测试。
 但一般来讲,WPE 的可读性太差,GM 指令的操作便利性也比较差,建议有能力的测试人员或开发人员,能自己写一套发包工具(类似下图),方便进行协议测试。
 (我们公司的这个抓包工具思路可参考另一篇帖子:https://testerhome.com/topics/33501

如何分析协议?

 我们在协议测试的时候,主要是针对客户端对服务端发送的协议进行测试,因为游戏数据的处理大部分都是在服务器上进行的,我们需要验证的是服务器的逻辑处理环节,而服务器返回的封包,是已经在服务器逻辑处理完成之后的,我们就算对这些封包进行了修改,也只是修改了客户端的显示而已,并不会对服务器的数据造成任何影响。
 那么怎么样去分析呢?请看下面这张图:

 我们玩游戏时进行的游戏行为,都是具有行为前置条件的,比如我们买东西,那么就需要有足够的钱,想要挑战某个副本,就需要有足够的等级和挑战次数,我们要做的,就是推翻前置条件,在条件不满足的情况下,来发送一个正常的游戏封包。前置条件大概整理了以下几种类型:
1.等级无效
 对于某些具有等级限制的玩法,在等级不足的时候进行发包验证
2.时间无效
 对于某些具有时效性的玩法,在时间范围之外进行发包验证
3.货币无效
 对于需要消耗货币的玩法,在货币数量不足的时候发包验证(这里的货币指的是广义的货币,不单指金钱,还包括副本次数等等)
4.次数无效
 这里指的是一些有次数限制的玩法,在次数不足的时候发包验证,如某个活动奖励,每个角色只能领取 1 次,那么在领取完奖励之后,再发送一次领取奖励的封包,看服务器的处理逻辑
5.前置条件无效
 这个比较特殊,举个例子:帮派每日礼包,帮派成员每日可以领取 1 次,前置条件就是角色必须已经加入帮派成为帮派成员,在角色未加入帮派的时候,这个奖励通过发包是否可以领取?
6.参数范围无效
 这个也有点特殊,还是通过一个例子来说明:游戏内的 7 天登录协议,协议参数为对应奖励的天数,如玩家要领取第一天的奖励,在发送协议的时候参数为 1,第二天为 2……第七天为 7,那么 0 和 8 就是范围外的无效参数
7.特殊限制
 未在上述条件中的可能存在的一些其他的限制,如在跟 NPC 提交任务和领取奖励的时候,需要在一个有效交互范围之内,在这里特殊限制就是交互距离

协议测试用例设计

 测试用例并没有一个固定的格式,看个人喜好,但建议包含协议信息以及有效无效条件等,下图是个示例,供参考

写在最后

 协议的分析与测试,到这里就讲的差不多了,不过还有一点需要关注的,就是协议的有效性冗余性,这个不属于单条协议测试的范畴,但却是游戏体验和性能方面很重要的一个方向。
 我们游戏的协议是通过网络形式发送的,网络是有流量成本和传输压力的,减少无效协议和重复协议、减少非必要的协议参数,在一定程度上能够提高协议的传输效率,给游戏带来更好的体验。
 有些公司还需要负值校验(将参数修改为负数),以及不完整封包校验(删除部分字段),因为我们公司后端在这块验证做的比较完善,所以我没有写,感兴趣的同学可以跟后端开发人员确认一下。


↙↙↙阅读原文可查看相关链接,并与作者交流