udp协议本身不保证可靠传输，即使send()调用成功返回，数据包仍可能在发送队列溢出、网卡驱动丢弃、中间设备拥塞等环节无声丢失，且不会触发异常或错误码。
在实现基于UDP的可靠文件传输（如模拟TCP的CRC校验、序号控制、ACK/NACK机制）时，一个常见但关键的认知误区是：“send()成功 = 数据已送达对端”。事实恰恰相反——UDP的send()仅表示数据已成功提交至操作系统内核的发送缓冲区，后续流程完全脱离应用层控制：
- ✅ 内核完成校验和计算、封装UDP/IP头、入队至网络接口发送队列；
- ⚠️ 若发送速率持续超过网卡实际带宽（如突发100MB/s写入千兆网卡），内核队列满后新包将被静默丢弃；
- ⚠️ 网卡驱动或硬件缓冲区不足时，也可能直接丢弃待发包；
- ⚠️ 中间路由器、交换机因队列溢出（如RED/WRED未启用）、ACL过滤、MTU不匹配导致分片失败等，均会造成不可见丢包；
- ❌ 这些丢包均不会向应用层返回EAGAIN、EMSGSIZE等错误，send()仍返回发送字节数，看似“成功”。
以下代码演示了高并发UDP发送下潜在的静默丢包风险：
// 示例：无节制发送易触发内核丢包
int sock = socket(AF_INET, SOCK_DGRAM, 0);
struct sockaddr_in dest;
// ... 初始化dest ...
for (int i = 0; i < 10000; i++) {
ssize_t sent = sendto(sock, buf, len, 0, (struct sockaddr*)&dest, sizeof(dest));
if (sent != len) {
fprintf(stderr, "sendto partial: %zd/%d\n", sent, len);
// 注意：此处通常不会进入！静默丢包时sent == len仍成立
}
}? 关键洞察：UDP的“不可靠”本质在于端到端语义缺失——它不承诺交付，也不提供交付确认。无论丢包发生在本机发送栈、物理链路、还是远端接收栈，对发送方而言都是不可区分的。
因此，在您实现的可靠UDP传输协议中，必须：
- 始终假设任何发出的包（含ACK/NACK）都可能丢失，故需超时重传（RTO）与滑动窗口机制；
- 对ACK本身不进行二次确认（即不为ACK发ACK），而是通过数据包序号+累积确认（如类似TCP SACK的简化版）提升鲁棒性；
- 在模拟环境（如教授提供的Socket/Channel类）中，主动注入发送侧丢包，正是为了真实复现这一特性。
总结：UDP丢包绝非仅限于“接收失败”，发送路径上的任意环节都可能成为黑洞。真正的可靠性必须由应用层协议兜底——这不是缺陷，而是UDP设计哲学的必然要求。
