在写机器人压测脚本来测试游戏服务器负载能力的过程中，发现一个难点，就是要自己写一个协议包解析的客户端实现，需要能够解析服务端发过来的TCP流当中划分对应的业务实体，以便脚本判断服务端返回是否正常。在这个过程中也看了下其协议源码实现。。
自定义协议中数据的生命周期
客户端将实体数据序列化成二进制数据流（封包），利用已经建立的TCP连接，向服务器发送数据
服务端接受到数据后，放入到缓冲区中，读取自定义的固定长度的二进制数据作为包头，反序列化该二进制数据，得到包头元数据（其中一个字段描述整个数据包的长度，当然也包含如何解析这个数据包包体的标记，该标记可以找到对应的反序列化函数来解析该包体），根据包体长度再从缓冲区拿对应字节长度的数据作为包体，再解析包体，即可得到客户端发过来的实体数据。。
服务端得到客户端数据后经过业务处理后，可以选择做一个响应请求，即服务端给客户端发送数据，和步骤1，2类似。
注意：
TCP是面向流的协议，是没有边界的概念（即没有包的概念），而这个概念是应用层为了业务而人为划分的。有点像一个json的本地文件，我们要读取该文件（二进制数据->字符文本数据），利用json反序列化函数解析成业务实体（字符数据->实体对象）
服务端在接受TCP流数据时，有可能没接受到完整的包（分包），也有可能同时接受到N个包（粘包）
-
分包的原因：
缓冲区太小
包太大，客户端分多次传输
-
粘包原因：
包太小，因Nagle算法，将多个小包进行合并（TCP延迟高），当超时或包大小足够时再发送。
缓冲区太大，流数据到达后放入缓冲区，服务器没有及时取走，而下次流数据到达时继续置入缓冲区，而服务器取走缓冲区数据时就会将多个包数据一并拿到
如何解决分包和粘包：使用生命周期描述的步骤2即可解决（接受时只需要保证将包头数据读完整，循环接受流数据，知道数据大小等于包头定义的长度即可）
