UDP 协议详解：轻量、快速、无连接

本文是《计算机网络学习笔记》系列的第十篇。前四篇花了大量篇幅讲 TCP，传输层还有另一个协议 UDP，却只有区区 8 个字节的头部，几乎没什么可"配置"的——正是这种极度克制的设计，让它在 DNS、视频直播、HTTP/3 等场景中不可替代。

一、UDP 是什么？

UDP（User Datagram Protocol，用户数据报协议），和 TCP 一样工作在传输层，负责在两个进程之间传递数据。

两者的核心区别只有一句话：

TCP 把"可靠送达"作为己任；UDP 只管发出去，送不送到不关它的事。

UDP 的特征：

• 无连接：不需要握手，想发就发；
• 不可靠：不保证送达，不保证顺序，不重传；
• 无拥塞控制：不管网络有多堵，该发多快就发多快；
• 轻量：头部仅 8 字节，TCP 头部最少 20 字节。

这些听起来像是缺点，但在很多场景下，它们反而是优点。

二、协议格式

UDP 头部只有 4 个字段，共 8 字节，是所有主流协议里最简洁的之一：

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Length            |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Data ...                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

对比 TCP 的 20 字节头部（还不算选项字段），UDP 头部的开销几乎可以忽略不计。

三、检验和：唯一的"质检员"

UDP 是不可靠传输，但并不意味着它对数据损坏完全无感——检验和（Checksum）是 UDP 唯一的数据完整性保障。

参与计算的三部分

检验和不只覆盖 UDP 头部和数据，还引入了一个伪首部（Pseudo Header）。伪首部是一段虚拟数据，只在计算检验和时临时构造，不会真正发送到网络上：

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|              源 IP 地址（32 位）                 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|              目的 IP 地址（32 位）               |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|    全零（8 位）   |  协议号（8 位，UDP=17）       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|              UDP 长度（16 位）                   |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

引入伪首部的目的是：让检验和同时覆盖 IP 层的源/目的地址，如果数据包被误路由到了错误的目的地，检验和验证会失败，接收方直接丢弃。

发送端计算步骤

1. 将 伪首部 + UDP 首部 + 数据 拼在一起；
2. 把检验和字段先暂时填为 0x0000；
3. 按 16 位（2 字节）为单位切分，全部相加；
4. 回卷：若相加结果超出 16 位，产生进位，将进位加回到结果的最低位；
5. 对结果取反，填入检验和字段。

接收端验证步骤

1. 构建相同的伪首部；
2. 将 伪首部 + UDP 首部 + 数据 全部按 16 位相加（包含检验和字段本身）；
3. 结果若全为 1，说明数据完整；若不全为 1，说明数据在传输中被损坏，直接丢弃。

注意一：检验和只能检测损坏，无法修复。一旦发现错误，UDP 直接丢包，不通知发送方，不重传。如果应用需要可靠性，必须在应用层自己实现。

注意二：在 IPv4 中，UDP 检验和是可选的——将检验和字段设为 0x0000 表示发送方未计算，接收方跳过验证。在 IPv6 中，由于 IP 头部本身取消了检验和字段，UDP 检验和改为强制计算。

四、能发多大的包？

理论上限

Length 字段是 16 位，最大值 65535，减去 UDP 头部 8 字节和 IP 头部 20 字节：

65535 - 8 - 20 = 65507

实际上限

以太网的 MTU（最大传输单元）是 1500 字节。如果 UDP 包超过 MTU，IP 层会把它切成多个分片分别发送。

对 TCP 来说，分片问题影响不大——就算某个分片丢了，TCP 会重传。但 UDP 不一样：

只要有一个分片丢失，整个 UDP 包就必须被丢弃，因为 UDP 没有重传机制，无法只补发缺失的那片。

因此，在实践中 UDP 包的大小应控制在：

1500 - 20 - 8 = 1472

超过 1472 字节就会触发 IP 分片，丢包风险显著上升。

五、UDP vs TCP：如何选择？

选 UDP 的核心理由通常是以下之一：

1. 一问一答的短交互：比如 DNS 查询，一个请求包 + 一个响应包，建立 TCP 连接的开销比数据本身还大，完全没必要；
2. 允许丢包的实时流：视频直播、语音通话，丢一帧画面或一段音频，比等待重传卡顿要体验好得多；
3. 应用层自己管可靠性：当应用需要比 TCP 更精细的控制（比如只重传关键帧，不重传已过期的数据），可以在 UDP 之上自己实现定制化的可靠传输逻辑。

六、哪些协议用了 UDP？

DNS（53 端口）

每次域名查询都是一个极小的请求/响应，用 TCP 的三次握手太浪费。UDP 一来一回只需 1 个 RTT，而 TCP 光握手就要先消耗 1 个 RTT，数据交换才是第 2 个 RTT，整整多出一倍。

DHCP（67/68 端口）

主机刚接入网络时还没有 IP 地址，更不知道 DHCP 服务器在哪，只能广播。广播天然不支持 TCP 连接，UDP 是唯一选择。

实时音视频通话

视频通话（Zoom、WebRTC）、语音通话这类场景，卡顿比花屏更影响体验。UDP 允许丢帧继续播放，而 TCP 遇到丢包会等待重传，导致整体延迟，反而更糟。

注：Netflix、YouTube 这类点播/直播平台通常走 TCP（HLS/DASH over HTTP），因为它们有缓冲区，对延迟不敏感，更在乎传输可靠性。UDP 的优势主要体现在对延迟极度敏感的实时双向通信场景。

QUIC / HTTP/3

HTTP/3 底层抛弃了 TCP，改用谷歌设计的 QUIC 协议——一个跑在 UDP 之上、在应用层实现了可靠传输、多路复用和加密的协议。

为什么不直接用 TCP，而要在 UDP 上重新造轮子？因为 TCP 深埋在操作系统内核里，无法快速迭代；而 UDP 只是一个壳，QUIC 的逻辑完全跑在用户空间，谷歌可以随时更新优化，不需要等操作系统升级。

HTTP/3 的详细内容，见第六篇《HTTP 协议进化史》。

七、动手实践：UDP 编程

理解了 UDP 的特性，最快的巩固方式是写一个简单的程序。

UDP 编程和 TCP 的核心区别在于：没有连接的概念。不需要 connect()、accept()，直接 sendto() / recvfrom()，指定目标地址即可。

一个经典的入门练习是 Echo 服务器：客户端发什么，服务端原样返回。

完整的 C 语言 UDP Echo 服务器实现，见我的另一篇文章：《UDP 编程之 Echo 服务器》

小结

本系列前九篇：
· 第1篇：《TCP 协议格式详解》
· 第2篇：《TCP 三次握手与四次挥手》
· 第3篇：《TCP 可靠数据传输》
· 第4篇：《TCP 流量控制与拥塞控制》
· 第5篇：《TLS：HTTPS 背后的加密握手》
· 第6篇：《HTTP 协议进化史》
· 第7篇：《DNS：互联网的电话簿》
· 第8篇：《IPv4 与 IPv6：网络层的寻址与路由》
· 第9篇：《NAT：家里的路由器如何帮你"上网"》

参考资料：《计算机网络：自顶向下方法》