udp 发送调用成功（send() 返回无异常）并不保证数据包真正抵达对端——丢包可发生在发送队列溢出、网卡驱动缓冲区满、中间设备拥塞等任意环节，且完全静默，无异常抛出。
在基于 UDP 实现可靠文件传输时，一个常见误区是认为“只要 send() 调用成功，数据就已发出并大概率可达”。事实并非如此：UDP 的 send() 是非阻塞的“尽力而为”接口，其成功仅表示数据已拷贝至内核发送缓冲区，不承诺任何链路层或网络层的投递保障。
丢包可能发生在多个环节，且均不会触发应用层异常：
- 本地发送队列溢出：当应用层持续高速调用 send()，超出内核 socket 发送缓冲区（SO_SNDBUF）容量时，后续 send() 可能被阻塞（若 socket 为阻塞模式）或直接返回 EAGAIN/EWOULDBLOCK（非阻塞模式）；但若缓冲区尚有空间，数据入队即返回成功，而实际在后续协议栈处理（如 IP 分片、ARP 解析、网卡驱动入队）中仍可能因资源不足被静默丢弃；
- 网卡驱动或硬件缓冲区饱和：即使内核缓冲区未满，网卡驱动环形缓冲区（TX ring buffer）满载时，底层驱动可能直接丢弃待发送帧，且不向上层反馈；
- 中间网络设备拥塞：路由器、交换机等在队列满时采用尾部丢弃（Tail Drop）或主动队列管理（如 RED），此类丢包对通信双方完全透明；
- 目标主机接收端丢包：如 UDP 接收缓冲区溢出（SO_RCVBUF 不足）、中断处理延迟、协议栈过载等，同样无通知机制。
✅ 正确应对方式（尤其在实现类 TCP 可靠性机制时）：
- 必须依赖超时重传 + 确认应答（ACK）：不能信任 send() 成功即等于对方收到；
- 为每个数据包分配唯一序列号，并要求 ACK 携带该序号；
- 客户端需维护未确认报文的重传定时器（RTO），超时即重发（建议使用指数退避）；
- 服务端需去重（根据序列号缓存已收包），避免重复写入文件；
- 显式处理 ACK 丢失：由于 ACK 本身也是 UDP 包，它也可能丢失 → 客户端需重传原数据包，服务端需容忍重复 ACK 和重复数据包。
? 示例关键逻辑（伪代码）：
# 客户端发送与重传逻辑节选
def send_with_retry(seq, data):
packet = build_udp_packet(seq, data)
sock.sendto(packet, server_addr)
start_timer(seq, timeout=1.0) # 启动重传定时器
def on_ack_received(ack_seq):
cancel_timer(ack_seq) # 收到 ACK 则取消对应重传
if ack_seq == expected_next_ack:
expected_next_ack += 1 # 推进滑动窗口⚠️ 注意事项：
- 不要试图通过 getsockopt(SO_SNDBUF) 或 ioctl(SIOCOUTQ) 监控发送队列来规避丢包——它们仅反映内核缓冲区状态，无法覆盖驱动层及网络路径上的不确定性；
- 即使在 localhost 测试（如使用教授提供的模拟 Channel 类），也应完整实现超时/重传/去重，因为模拟丢包正是为了验证协议鲁棒性；
- 实际部署时，建议结合 setsockopt(IPPROTO_IP, IP_TTL, ...) 控制跳数，并启用 SO_KEEPALIVE（虽对 UDP 无效，但提醒你：UDP 本身无连接保活，需自行设计心跳）。
归根结底：UDP 的“不可靠”本质，不仅在于接收端可能收不到，更在于发送端永远无法得知——它是否真的出发了。 因此，所有可靠性保障必须构建在应用层确认机制之上，而非依赖底层传输语义。
