UDP — 因为什么都不承诺才拿到的东西

一句话总结

UDP 只是加上端口号和校验和的薄封装，让应用在希望自行设计可靠性时拥有自由。

为什么需要它

TCP 的可靠性并非免费：建立连接需要往返，丢包后还会等重传完成才向应用交付后续数据。实时通话中，半秒前的声音即使重传也没有价值，但 TCP 为保证顺序仍会等待。

这叫队头阻塞。有些应用中延迟比可靠性重要，此时不作承诺的传输层反而更合适。

工作原理

UDP 首部只有 8 字节，包含源端口、目的端口、长度和校验和。没有连接状态、序列号或重传；数据报可能到达、丢失或乱序。

这种简单性带来三点：无需建立连接的往返；服务器无需维护连接状态，可服务更多客户端；应用可自行决定重传策略。

DNS 使用 UDP 正是因为前两点：一次查询、一次响应，无需用三次往返建立和关闭连接。但响应超过 512 字节时，服务器会设置截断(TC)标志，客户端再以 TCP 重试同一查询。所以阻断 DNS 服务器的 TCP 53 端口时，平时看似正常，只有记录较多的特定域名无法解析。 这种事故很难诊断。

QUIC 把第三点发挥到极致，在 UDP 上重新实现重传、顺序、加密和多路复用。之所以不直接修改 TCP，是因为 TCP 固化在操作系统内核和全球中间设备中，更新需多年；UDP 上的实现只需更新应用即可部署。HTTP/3 还通过各流独立交付，消除了 TCP 的队头阻塞。

实际工作中的表现

使用 UDP 时必须自行处理大小问题。MSS 钳制只适用于 TCP，UDP 协议须自行应对路径 MTU。QUIC 把默认数据报大小保守地设为 1200 字节，原因就在这里。

UDP 也没有流量控制。发送方快于接收方时，接收缓冲区溢出并静默丢包。可通过 /proc/net/udp 的 drops 列或 ss -u -a 的队列状态确认。指标采集器或日志转发器“偶尔缺数据”时，这很常见。

后续测验将确认什么

确认你能说明何时选择 UDP 合理，以及 TCP 的顺序保证为什么有时反而有害。