## 新生命网络库 ### 标准网络封包协议 经过十多年经验积累以及多方共同讨论，于昨晚凌晨通过了新生命团队的标准网络封包协议，作为网络库NewLife.Net中封包接口的标准实现。（强烈推荐使用标准网络封包协议，用户也可以根据业务需要去自己实现接口） **标准网络封包协议：<font size="6" color="#ff0000">1 Flag + 1 Sequence + 2 Length + N Payload</font>** **<font size="4"><font color="#0000ff"> 1个字节标识位，标识请求、响应、错误、加密、压缩等； 1个字节序列号，用于请求响应包配对； 2个字节数据长度N，指示后续负载数据长度（不包含头部4个字节），解决粘包问题； N个字节负载数据，数据内容完全由业务决定，最大长度65535=64k。 </font>** **<font size="5" color="#800080"> 该网络封包协议应用于服务端RPC通信、CS通信、Web端、移动端、硬件设备端，10年内不做改变！！！ </font>** 相关讨论点： 1. **数据长度字段定长**。不同语言实现不便于使用7位压缩编码整数，并且头部定长非常有利于各种过滤器实现。 2. **数据长度定为2个字节**。2个字节可表示64k的负载数据，可满足99%的业务需要，超过64k的数据，完全可以由业务层进行划分解决。 3. **粘包问题**。封包协议实现类，根据长度字段拆分负载数据交给业务层，内部带有数据缓冲区，也可以把众多小包重新组合成为一个标准包交给业务层。 4. **非标干扰数据**。在一个标准包接收之外，可能收到干扰数据，此时可根据长度字段解包，绝大部分干扰数据因为不符合封包格式而被抛弃。 5. **GPRS网络数据干扰**。在物联网2G领域，运行商可能在标准包之后额外发送一些数据，此数据有可能导致后续解包连锁错误。封包实现带有500ms超时丢弃功能，此时间内未完成解包则清空缓冲区。 6. **物联网硬件设备实现**。固定4字节的头部长度，非常便于嵌入式C/C++实现协议。 7. **网页前端实现**。js可操作二进制实现该头部。 8. **HTML5增强**。HTML5强烈推荐使用WebSocket，无需使用标准封包协议再次封装。本封包协议实现将会避开WebSocket数据包，同一个Tcp端口仅对非WebSocket数据包解包。 **特别说明**，讨论期间争议最大的莫过于干扰数据导致连续出错，结论如下： 1. 封包格式可以有效干掉干扰数据 2. 500ms超时后清空缓冲区，避免干扰数据残留在缓冲区里面影响后续标准包，除非干扰数据能够以小于500ms的速度不断进来 3. 间隔小于500ms的干扰数据将会摧毁整个封包协议，但是这种情况已经不是程序问题，而是用户网络问题！！！