不能直接用TCP做物联网网关应用层协议，因其重传超时长、连接重建开销大，且终端常仅支持UDP或轻量TCP栈；需在应用层自控重传粒度、确认节奏与包生命周期，通过2字节seq/ack、滑动窗口、累计确认、crc32c校验及版本扩展机制保障高效可靠通信。
为什么不能直接用 TCP 做物联网网关的应用层协议
TCP 确实能保证可靠传输，但网关侧常面临连接频繁断开、NAT 超时、移动网络抖动等场景，TCP 的重传机制在链路中断后需等待超时（通常秒级），且连接重建开销大；更关键的是，很多物联网终端只支持 UDP 或受限 TCP 栈（如 LwIP 轻量模式），无法维持长连接。所以必须在应用层自己控制重传粒度、确认节奏和包生命周期。
ACK 和 SEQ 怎么设计才不浪费字节又抗乱序
二进制协议里每个字节都珍贵。推荐用 2 字节无符号整数做 seq（0–65535），配合滑动窗口大小为 32；ack 字段也用 2 字节，表示「已连续收到的最高 seq」，即累计确认（cumulative ACK）。不采用选择性确认（SACK），避免解析复杂度和字段膨胀。注意：必须要求发送方按 seq 严格单调递增发包，接收方丢弃 seq ≤ last_ack 的重复包，对 seq > last_ack + window_size 的包缓存但不确认——这能自然过滤乱序+防止窗口外数据干扰。
重传触发条件和退避策略怎么写才不压垮弱终端
不能一丢就重传。建议组合三种触发方式：
- 定时器超时（初始 200ms，每次翻倍，上限 2s）
- 收到重复
ACK≥ 2 次（说明中间包丢失） - 发送窗口内有包待确认且超过 1.5 倍 RTT 未响应（需维护每包独立 RTT 估算）
重传时只重传最早未确认包（非全部窗口），避免雪崩。特别注意：终端内存小，不要缓存所有待重传包，而应把原始 payload 存在外部 buffer 中，重传时重新序列化，靠 seq 和校验和确保一致性。
如何让协议在 OTA 升级和多厂商设备混用时不崩溃
必须预留协议版本字段（1 字节）和扩展头长度字段（1 字节），主版本变更时强制断连重协商；扩展头用于携带可选信息（如时间戳、加密 nonce），接收方不认识的扩展类型直接跳过。校验必须用 crc32c（非简单 xor），放在包尾，计算范围包含版本、seq、ack、载荷——否则篡改 seq 可能被误收。另外，所有字段用小端序，避免 ARM/MIPS/ESP32 等平台字节序混乱。
真正难的不是编码头，是状态机边界：比如重传定时器在收到 ACK 后是否立即清除、窗口滑动时如何批量标记已确认、断连后如何安全清空重传队列而不漏包。这些逻辑一旦错位，丢包率反而比裸 UDP 还高。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
