什么是游戏协议?
协议是网络游戏前后端交互的实现方式。
游戏中协议的收发过程是怎样的?
当我们在进行游戏的时候,我们点击了某个按钮进行某一种游戏行为,这个时候,客户端会按照跟服务器约定好的一些规则,将我们的游戏行为对应的请求和参数通过网络封包发送给服务器,服务端在收到这个请求后会对请求内容进行解析,以确定客户端进行的是什么游戏行为,并获取到对应的请求参数,之后服务端会根据代码逻辑来对这些数据进行相应的处理,并将处理结果同样以封包的形式返回给客户端,客户端在接收到封包之后,也会按照约定好的规则进行解析,并将解析后的结果展示给玩家。
不同的游戏有不同的协议类型和实现方式,有可能客户端发送的请求服务器并不会响应(无效请求),也有可能服务器会主动推送协议给客户端(如整点活动的开启)
![](https://pic4.zhimg.com/80/v2-a89d11bf3bc3c8ac1ea1a0afa94bbfc3_720w.webp)
常见协议
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传输的完整的游戏协议封包,通常由包长、协议号、验证码、协议参数构成(具体项目可能实现方式略有不同,具体可跟开发人员求证)
![](https://pic2.zhimg.com/80/v2-bfb11ab0b5ba6ef06302e00bcc616481_720w.webp)
包长:当前封包的字节流长度,用来判断收到的字节流是否是一个完整的封包
协议号:客户端与服务端之间定义的具体的事件编号,通过协议号,我们可以知道客户端是进行了哪种操作
验证码:客户端跟服务端之间定义的一套封包有效性验证机制
协议参数:客户端与服务端进行协议传输的时候附带的实际协议内容,是某种游戏行为的具体实现,协议参数又分为多种类型,有int型,str型,list型,甚至是某种自定义的对象,这个一般需要参照具体的游戏协议文档。
![](https://pic1.zhimg.com/80/v2-f42cb50b1a2887daa0de9c9e7039ecf8_720w.webp)
ps:由于TCP特殊的流模式,某些情况下,我们收到的封包可能是由多个封包黏连在一起的,那么在进行封包处理的时候如何判断是否是一个完整的封包呢?就需要通过包长来判断,如果当前封包的长度等于包长的值,那么就是一个完整的封包,否则就需要对封包进行截取拆分
为什么要测协议?
游戏中很多行为限制,是在客户端层面的,在我们进行某些非正常游戏行为的时候,客户端已经在逻辑层面阻止了我们的这种行为(比如,在金钱不足的时候我去买一件物品,客户端会判断你的钱是否足够买这件物品,如果不足则会提示金钱不足,并阻止你这次行为),但之前我们讲了,客户端与服务端之间是通过协议封包来进行交互的,客户端阻止你的行为,只是阻止客户端自己来发送这个行为封包,那么服务端对于这种非正常情况是否有做判断呢?如果我伪造一个这样的封包,或者在网络不顺畅的时候,多次点击购买来重复发送封包,是否可以在金钱不足的时候购买成功呢?是否存在刷钱刷道具的漏洞呢?
这个就是我们进行协议测试的目的:验证服务器逻辑的正确性!
抓包和发包
1.抓包
既然要分析协议,那么首先就需要看到协议,看到协议那么就需要监听服务端与客户端之间的通信,并抓取游戏封包
市面上目前有很多抓包工具,常用的游戏抓包神器WPE、其他的还有fiddler、wireshark等,使用方法这里不做过多介绍,网上很多使用教程。
![](https://pic2.zhimg.com/80/v2-ab1b4e6c90cec66ad3fade43223c9f61_720w.webp)
![](https://pic3.zhimg.com/80/v2-3181f50886540f8dc85c91e1b9df733a_720w.webp)
2.发包
以WPE为例,在我们抓到包之后,右键其中的一条封包选择发送,就可以在新弹出来的界面修改封包内容,在修改好对应的参数之后,点击发送按钮,这条修改后的封包就会发送给服务端了。
![](https://pic1.zhimg.com/80/v2-9939ba8c8995af7397463f8600878304_720w.webp)
![](https://pic1.zhimg.com/80/v2-1a77c085e792dcdf07f10db854764858_720w.webp)
开发人员一般也会留一个GM指令的接口或者其他的发包方式,通过预留接口也可以实现对服务器进行发包测试。
但一般来讲,WPE的可读性太差,GM指令的操作便利性也比较差,建议有能力的测试人员或开发人员,能自己写一套发包工具(类似下图),方便进行协议测试。
![](https://pic1.zhimg.com/80/v2-ba29e7e436d86f184e8a6649303d7ef4_720w.webp)
如何分析协议?
我们在协议测试的时候,主要是针对客户端对服务端发送的协议进行测试,因为游戏数据的处理大部分都是在服务器上进行的,我们需要验证的是服务器的逻辑处理环节,而服务器返回的封包,是已经在服务器逻辑处理完成之后的,我们就算对这些封包进行了修改,也只是修改了客户端的显示而已,并不会对服务器的数据造成任何影响。
那么怎么样去分析呢?请看下面这张图:
![](https://pic4.zhimg.com/80/v2-1f2621ef10437bb7a06c5c3b58104103_720w.webp)
我们玩游戏时进行的游戏行为,都是具有行为前置条件的,比如我们买东西,那么就需要有足够的钱,想要挑战某个副本,就需要有足够的等级和挑战次数,我们要做的,就是推翻前置条件,在条件不满足的情况下,来发送一个正常的游戏封包。前置条件大概整理了以下几种类型:
1.等级无效
对于某些具有等级限制的玩法,在等级不足的时候进行发包验证
2.时间无效
对于某些具有时效性的玩法,在时间范围之外进行发包验证
3.货币无效
对于需要消耗货币的玩法,在货币数量不足的时候发包验证(这里的货币指的是广义的货币,不单指金钱,还包括副本次数等等)
4.次数无效
这里指的是一些有次数限制的玩法,在次数不足的时候发包验证,如某个活动奖励,每个角色只能领取1次,那么在领取完奖励之后,再发送一次领取奖励的封包,看服务器的处理逻辑
5.前置条件无效
这个比较特殊,举个例子:帮派每日礼包,帮派成员每日可以领取1次,前置条件就是角色必须已经加入帮派成为帮派成员,在角色未加入帮派的时候,这个奖励通过发包是否可以领取?
6.参数范围无效
这个也有点特殊,还是通过一个例子来说明:游戏内的7天登录协议,协议参数为对应奖励的天数,如玩家要领取第一天的奖励,在发送协议的时候参数为1,第二天为2……第七天为7,那么0和8就是范围外的无效参数
7.特殊限制
未在上述条件中的可能存在的一些其他的限制,如在跟NPC提交任务和领取奖励的时候,需要在一个有效交互范围之内,在这里特殊限制就是交互距离
协议测试用例设计
测试用例并没有一个固定的格式,看个人喜好,但建议包含协议信息以及有效无效条件等,下图是个示例,供参考:
![](https://pic1.zhimg.com/80/v2-70c3a0aa6d3c1198eb0edf9ad4fa3d10_720w.webp)
![](https://pic3.zhimg.com/80/v2-6861f6ab0c80f497f3bba40e75ebd3e2_720w.webp)