udp本身不保证可靠，必须在应用层实现ack、重传和序号机制：为每个数据包分配唯一序列号，发送后启动定时器等待ack，超时未收到则重发；接收端按序号缓存、去重、重排后交付；还需引入滑动窗口控制并发量，支持延迟ack、捎带ack、选择性ack及快速重传，并兼顾nat穿透与心跳保活。
UDP本身不保证可靠，必须自己实现ACK、重传和序号机制
UDP是无连接、不可靠的传输协议，没有内置的丢包检测、重传或排序能力。要“可靠”，就得在应用层补全这三件事：给每个数据包加唯一sequence_number，发送后启动定时器等待ACK，超时未收到就重发，同时接收端按序号缓存乱序包、去重、组装后交付上层。
这不是简单套个库就能解决的事——标准boost::asio或std::net（C++23）只提供UDP socket封装，不带可靠性逻辑。你得自己设计状态机、维护发送窗口、管理重传队列。
用滑动窗口控制并发发送量，避免网络拥塞崩溃
盲目重发或不限速发送会压垮链路，尤其在弱网下极易触发雪崩。必须引入窗口机制：send_window_size限制同时处于“已发未确认”状态的包数量，每收到一个ACK就右移窗口并发出新包。
- 窗口大小建议从
4起步（类似TCP初始cwnd），可随RTT和丢包率动态调整 - 每个待发包需绑定
timer_id，超时后只重传该包，不是整个窗口 - 避免使用
std::chrono::steady_clock::now()反复查时间——改用单个主循环+最小堆管理所有定时器，否则高并发下性能骤降
ACK机制必须区分“纯ACK”和“捎带ACK”，减少小包开销
每收一个包都单独回ACK，会产生大量小包（典型“ACK风暴”）。更合理的方式是：接收端延迟20–50ms再回ACK，期间若收到后续包，就用ACK + data捎带应答（即“累计ACK”），把多个序号压缩进一个ACK字段。
关键细节：
-
ACK字段不能只存最新收到的sequence_number，而应存highest_received + 1（即期望下一个） - 需支持选择性ACK（SACK）：用
std::vector<:pair uint32_t>></:pair>记录已收但不连续的区间，否则丢第一个包会导致后续全部阻塞 - 发送端收到重复ACK（比如连续3次相同
ack_number）应立即触发快速重传，而非死等定时器
实际部署时，NAT穿透和防火墙保活比协议逻辑更难搞定
很多团队卡在最后一步：本地测试通了，一上公网就收不到包。根本原因不是协议写错，而是UDP被中间设备静默丢弃。STUN/TURN虽能解NAT问题，但keepalive心跳必须满足两个条件：
- 间隔≤
15s（多数家用路由器NAT表项超时为30s，留余量） - 心跳包必须复用已有连接五元组，不能每次换端口；且内容不能全零（有些防火墙过滤空载UDP）
- 服务端需主动探测客户端是否存活——仅靠客户端心跳不够，对方掉线后服务端无法感知
这些细节没处理好，再严谨的重传逻辑也跑不通。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
