5.1 UDP：轻装上路
5.1 UDP：轻装上路
本节摘要：UDP 是传输层的极简主义者——8 字节首部、无连接、不保证送达不保证顺序，换来的是零建连时延与最少的协议开销。本节讲清 UDP 首部构成、端口与套接字四元组、校验和的覆盖范围，以及"哪些场景偏爱 UDP、为什么"，最后看 QUIC 如何在 UDP 上重建可靠传输。
旅程至此，数据包已站在目标主机门口。传输层的第一件事是补上门牌号的最后一段：端口号。IP 地址定位到主机，端口号（16 位，0~65535）定位到进程。经典搭配记住几个就够：80/443 网页、53 域名、22 远程登录、25/110/143 邮件。一条连接由四元组唯一标识：源 IP、源端口、目的 IP、目的端口——两台机器之间同时开几百条连接互不干扰，靠的就是源端口不同。
一、8 字节的极致简约
UDP 首部（固定 8 字节，没有可变部分）： +--------+--------+--------+--------+ | 源端口 2B | 目的端口 2B | +--------+--------+--------+--------+ | 长度 2B | 校验和 2B | +--------+--------+--------+--------+ 紧跟着就是应用数据 对比 TCP 首部至少 20 字节、外加握手挥手一堆来回： UDP 发一份 100 字节的 DNS 查询： 8B UDP 头 + 100B 数据 = 一次单向投递，完事。 TCP 同样的事：3 次握手（3 个包）+ 请求 + 应答 + 4 次挥手， 一来一回多出至少 7 个包、1.5 个 RTT 的纯开销。 校验和覆盖首部加数据，还加一个"伪首部"（含源目的 IP）—— 连 IP 层装错地址都能被发现，这是 UDP 仅有的安全网。 校验失败的处理：静默丢弃，不通知任何人。
UDP 的哲学：把复杂性留给应用自己按需实现。网络层已经尽最大努力了，如果应用本来就不在乎偶尔丢一两帧（视频直播）、或者自己有应用层确认（DNS 一次一问一答、超时重发即可），那 TCP 的全套机制就是纯开销。
二、谁在用 UDP，为什么
| 应用 | 选择 UDP 的理由 | 丢包时的自愈方式 |
|---|---|---|
| DNS 查询 | 一问一答，应用层超时重发即可 | 等几秒重问，或换服务器 |
| 视频直播 | 旧帧重发到也没用了（实时性压倒完整性） | 前向纠错、降码率 |
| 语音通话 | 100ms 后到的重传包是噪音 | 纠错编码、静音填充 |
| 网络游戏 | 状态同步要"最新"不要"补全" | 客户端插值预测 |
| DHCP | 客户端还没有 IP，握手无从谈起 | 周期性重试 |
共同规律：实时性压倒完整性时选 UDP。TCP 的重传是"迟到的正确"，而实时应用要的是"准时的近似"——一个迟到的游戏位置包不仅无用，还会误导客户端渲染。
反向的坑也存在：用 UDP 传关键数据而不做任何确认。早期某物联网固件用 UDP 上报计量数据、无重试逻辑，运营商网络 1% 的丢包率直接变成 1% 的数据黑洞。UDP 省下的机制不是免死金牌，而是把责任转移给了应用。
三、QUIC：在 UDP 上重建可靠的现代样本
HTTP/3 的底层传输协议 QUIC 值得单独一提，它是"UDP 哲学"的最新成果。为什么放着 TCP 不用，要在 UDP 上重造一遍可靠传输？
TCP 的历史包袱（QUIC 的动机清单）： 1. 队头阻塞：TCP 层必须按序交付，前面一个包丢了， 后面已到达的数据也被扣住等重传——HTTP/2 多路复用 反而放大了这个问题（所有流共享一条 TCP 连接）。 2. 握手串行：TCP 握手与 TLS 握手（第 7 章）只能排队进行， 建立安全连接要 2~3 个 RTT。 3. 中间设备僵化：二十年里大量防火墙/路由器对 TCP 行为有了固化假设，协议想演进（加字段、改语义）举步维艰。 QUIC 的做法（全在应用层，跑在 UDP 上）： - 每个流独立确认与重传：一条流丢包不阻塞其他流 - 传输握手与加密握手合并：1 个 RTT 建立安全连接， 会话复用时 0 RTT - 连接标识与四元组解耦：手机从 Wi-Fi 切到 5G， IP 变了连接不断（TCP 做不到，四元组变了就是新连接）
QUIC 证明了分层模型的弹性：当传输层的某个实现不再适配需求，可以在 UDP 这个"逃生舱口"上重新造一个。这不是否定分层，而是分层给了你重造的自由。
四、动手：观察一次 UDP 对话
# 抓 DNS 查询（典型 UDP 场景） $ dig example.com +stats ;; Query time: 12 msec ;; SERVER: 192.168.1.1#53(53) ← UDP 端口 53 对应抓包（过滤 udp.port == 53）： No. Time Source Destination Protocol Length Info 7 0.000 192.168.1.23 192.168.1.1 DNS 78 Standard query 0x8f2a A example.com 8 0.012 192.168.1.1 192.168.1.23 DNS 94 Standard query response 0x8f2a 解读：78 字节 = 14 以太网 + 20 IP + 8 UDP + 36 DNS 报文。 两个包、零握手、12 毫秒结束。若这个查询走 TCP： 光握手挥手就 7 个包。对每秒上亿次的全球 DNS 查询来说， 这笔账决定了 DNS 的默认选择永远是 UDP。 注意响应超过 512 字节或区域传送时 DNS 也会转 TCP—— 工具箱里两把刀，按活选刀，不是站队。
💡 关键直觉：UDP 不是"低配 TCP"，而是"传输层的自由签约"。选它意味着你接管了可靠性的责任，也换来了 TCP 永远给不了的东西：零建连时延、可控的拥塞策略、连接迁移能力。
图：TCP 与 UDP 的一次对话成本对比
本节要点回顾
- 端口定位进程：四元组唯一标识连接，源端口支撑并发
- UDP 三无：无连接、无确认、无顺序，8 字节首部加伪首部校验和
- 选型铁律：实时性压倒完整性选 UDP，反之 TCP，关键数据走 UDP 必须自建确认
- QUIC 启示：队头阻塞、握手串行、中间设备僵化三大痛点，驱动在 UDP 上重建传输
- 观察方法：DNS 是最常见的 UDP 样本，两包一问一答即全部
轻装者上路了，下一节看全副武装的 TCP 如何握手、如何保证每个字节有序到达。