协议是网络游戏前后端交互的实现方式。
当我们在进行游戏的时候，我们点击了某个按钮进行某一种游戏行为，这个时候，客户端会按照跟服务器约定好的一些规则，将我们的游戏行为对应的请求和参数通过网络封包发送给服务器，服务端在收到这个请求后会对请求内容进行解析，以确定客户端进行的是什么游戏行为，并获取到对应的请求参数，之后服务端会根据代码逻辑来对这些数据进行相应的处理，并将处理结果同样以封包的形式返回给客户端，客户端在接收到封包之后，也会按照约定好的规则进行解析，并将解析后的结果展示给玩家。
不同的游戏有不同的协议类型和实现方式，有可能客户端发送的请求服务器并不会响应（无效请求），也有可能服务器会主动推送协议给客户端（如整点活动的开启）
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 提交任务和领取奖励的时候，需要在一个有效交互范围之内，在这里特殊限制就是交互距离
测试用例并没有一个固定的格式，看个人喜好，但建议包含协议信息以及有效无效条件等，下图是个示例，供参考
协议的分析与测试，到这里就讲的差不多了，不过还有一点需要关注的，就是协议的有效性和冗余性，这个不属于单条协议测试的范畴，但却是游戏体验和性能方面很重要的一个方向。
我们游戏的协议是通过网络形式发送的，网络是有流量成本和传输压力的，减少无效协议和重复协议、减少非必要的协议参数，在一定程度上能够提高协议的传输效率，给游戏带来更好的体验。
有些公司还需要负值校验（将参数修改为负数），以及不完整封包校验（删除部分字段），因为我们公司后端在这块验证做的比较完善，所以我没有写，感兴趣的同学可以跟后端开发人员确认一下。
