文：徐江威
协议选择
即时消息有两个主要特性：时效性和可靠性。
一般的，为了客户端能及时的接收到消息，并且控制功耗，长连接是首选的连接方式。同样的，为了保证消息的可靠接收，TCP 协议是优先的选择。
报文格式设计
确定了采用 TCP 长连接协议之后，我们需要为我们的协议设计封包格式。
我们明确三点封包设计原则：
- 短报文头
- 报文负载可被分段
- 报文数据可被描述
首先，即时通信数据报文类型大概7到8种即可描述所有主要的通信业务，因此可以使用短报文头来携带报文分类和索引信息，而业务层需要的数据由负载携带而不由报文头携带，这样既能为业务层提供足够的灵活性的同时保证较小的报文结构。
其次，报文负载应该能携带多个数据段，每个数据段可以独立的描述一组数据，从而实现多数据端被封包在一个报文里。
最后，为了兼容不同的操作系统和平台，在进行数据序列化时，需要对不同的数据类型进行对应的序列化方式，而不同的数据类型在每个平台上支持程度不一，例如，浮点数的处理，在 JVM 里的处理和在浏览器里使用 JavaScript 处理就有明显差异。因此，对数据进行必要的描述以便在不同平台之间平滑的描述数据。
|--|-00-|-01-|-02-|-03-|-04-|-05-|-06-|-07-|
|--|---------------------------------------|
|01| VER| SN | RES | PN |
|--|---------------------------------------|
|02| DATA BEGIN |
|--|---------------------------------------|
|03| ... ... |
|--|---------------------------------------|
|04| DATA END |
|--|---------------------------------------|
封包仅8字节包头，分别是版本描述、序号、保留位（用于区别不同认证方式）、封包名。抖动、包序等状态都有由控制器控制，封包不携带任何状态描述。
协议报文
为了实现通信和应答，我们需要如下协议报文进行数据交互：
- 握手与验证
- 传输报文数据
- 传输流数据
- 心跳
握手协议
握手协议负责验证接入的客户机是否能被识别，并让客户机提供必要的识别数据。对于无法完成握手流程的客户机强制关闭连接。
数据包传输协议
数据按照打包方式进行发送和接收，我们可以将需要传输的数据封装为一个数据包，为了便于解包之后还原源数据值和数据属性，同时考虑到不同平台的适配，建议将一个属性值或者一个变量值作为数据包的一个字段。
通过在包里封入多个数据值来达到同时发送若干数据的目的，这样数据包就需要进行分段规划，使用分段符来区隔数据字段。
数据流传输协议
数据按照流形式进行发送和接收，流数据除了在链路上传输流负载外，还需要对收发两端进行流控，来保证流的传输品质（例如，出现 TCP 拥塞时的流量控制）。这里需要说明的是为了达到链路复用的目的，同时不导致拥塞非流数据包，在同一条传输链路上，流将被拆解为一个个数据块，我们将允许各个流的数据块和数据包在通一条链路上进行受控的竞争传输。
如上所述，因为流控的引入，我们在 TCP 协议上的流控主要目的是协调两端的拥塞，我们推荐的流控算法是基于对端响应时间变化的拥塞控制。通过持续记录每个数块到达对端之后，对端给予的应答时间，计算出每个数据块的潜伏期，跟踪潜伏期的变化来判断当前数据传输的拥塞，简单的说就是潜伏期的长短表示了当前的拥塞状况。
心跳协议
为了保证可靠性和及时性，我们不完全依赖 Socket 的状态来管理链路的连通性。因此，我们需要增加一个心跳协议来主动侦测链路的连通性。心跳协议被设计为一个单向协议，对端只进行应答，发送端根据应答来进行连通性判断，也就是说，谁需要连通性校验谁发送心跳包。客户端需要判断连通性，客户端向服务器发送心跳包，发送间隔和时机由客户端自行决定，例如，桌面客户端连接外部电源时可以缩小发送间隔，每3分钟一次心跳，桌面客户端使用电池时可以放大发送间隔，每10分钟一次心跳。同理，服务器的心跳发送也由服务器控制。
数据封包和解包
数据封包就是将数据序列化为二进制字节数组的过程，将数据按照约定的二进制形式进行序列化。解包的过程就是反序列化的过程，解包时我们需要对接收到的数据的每一个字节逐一进行读取，为了提高效率，我们仅进行一次读取就还原发送的数据格式，充分复用内存可以帮助我们提高读取效率。
