1.背景
在JT/T808协议中，消息体长度用10位无符号数表示，最大为1023个字节。当涉及到大数据传输时，采用分包传输方式。在网络状态不佳导致分包丢失时，服务端可通过补传分包请求通知客户端重新发送丢失数据，这要求服务端具备Nack机制。协议文档详见下图：
2. Nack机制详解
2.1 Nack概念
ACK（确认应答）表示到达通知技术，接收方在接收数据后向发送方发送“已接收数据”的消息（ACK），确保消息可靠传输。相反，NACK（否定应答）在未收到数据时通知发送方“未收到消息”。
2.2 与实时音视频的Nack区别
· 已知初始包序号为1
· 已知最后一个包序号为消息总包数大小
2.3 何时发送请求
2.3.1. 定时收集丢失数据并发送（按往返时间间隔）
2.3.2. 收到包后立即检查并发送（实时性高）
· 在收到数据前检查包序号，如有丢失包则发送重发请求，若重发未完成则列入重发请求列表。
· 发送丢失包请求后的1.x*rtt时间后重发，重发次数可配置，从第一次发送开始计算，保留时间可配置。
· 无法通过后续包来检查时，尾包丢失时机及发送请求，若重发队列为空且时间x*rtt后未接收数据包则认为尾包丢失。
2.4 发送数量控制
2.4.1. 一个Nack请求包含重传包数量
· 不得超过（1023-2（流水号）-2（重传包总数））/2 = 509
· 数量可配置，值越小实时性越高。
2.5. RTT修正
发送请求包以更新发送时间，收到后更新rtt时间
3. 实测结果
3.1. 模拟发送端丢包率约为33%（每个补包请求包含一个丢失包）
3.1.1. 随机生成丢失数据
根据打印预测，发送方需发送至少26+1+1+1+2+3+1+2+2=39个包，服务端需发送至少13个补包请求(一次nack一个丢包)。
3.1.2. 发送端共发送39个数据包
3.1.3. 服务端发送13个补包请求
总结
上述Nack机制可以更加高效和稳定地处理数据传输中的丢包问题，确保数据的完整性和传输的可靠性。
