为什么这么设计（Why’s THE Design）是一系列关于计算机领域中程序设计决策的文章，我们在这个系列的每一篇文章中都会提出一个具体的问题并从不同的角度讨论这种设计的优缺点、对具体实现造成的影响。如果你有想要了解的问题，可以在文章下面留言。

UDP 与 TCP 两种传输协议是 IP 协议簇的核心成员，1980 年发布的 RFC 768 定义了 UDP 协议¹，我们可以通过它在多个计算机连接构成的网络中传递数据。常见的 DNS 协议就可以使用 UDP 协议获取域名解析的结果²，我们在这一系列前面的为什么 DNS 使用 UDP 协议中曾经讨论过 DNS 使用的传输协议。

UDP 是能够传输数据的最简单的协议，它的协议首部（也称作协议头）只有 8 个字节，很多人，尤其是应届毕业生都能通过死机硬背暂时记住 UDP 协议头包含的内容，但是知道协议头的内容不代表我们真正理解背后的原因。本文会分析为什么只有 8 个字节的 UDP 协议能够传输数据，相信这篇文章能帮助你更好地理解 UDP 协议头中字段的作用。

udp-header

图 1 - UDP 协议头

UDP 协议头中只包含 4 个字段，分别是源端口、目的端口、长度和校验码，其中每一个字段都占 16 比特，即 2 字节，这 4 个字段的作用如下：

源端口是一个可选字段，它表示发送方进程的端口号，接收方可以使用该字段（不一定准确）向发送方发送信息；
目的端口是数据报接收方的端口号，它只在目标的 IP 地址下才有意义；
长度是协议头和数据报中数据长度的总和，表示整个数据报的大小；
校验码使用 IP 首部、UDP 首部和数据报中的数据进行计算³，接收方可以通过校验码验证数据的准确性，发现传输过程中出现的问题；

通过 Wireshark 抓包来查看实际使用中 UDP 协议首部的值。当我们执行 dig baidu.com 命令时，本地就会向 DNS 服务器发送 DNS 查询，下面就是一个 DNS 查询中 UDP 首部的例子：

0000   ff 7c 00 35 00 23 c2 6e

上述 UDP 首部中四个字段对应的值如下：

字段	数据
源端口	`0xff7c = 65404`
目的端口	`0x0035 = 53`
长度	`0x0023 = 35`
校验码	`0xc26e`

由于 DNS 协议使用的端口是 53⁴，所以上述 UDP 首部中的目的端口就是 53。源端口就是本地发出 DNS 请求的端口，该端口也用来接收 DNS 响应。

定义 UDP 协议的 RFC 768 文档只有 3 页，由于 UDP 协议既不需要保证送达，也不需要保证顺序，所以它没有 TCP 协议那么复杂。TCP 协议中的三次握手⁵、拥塞控制算法和重传策略等机制都是为了提供可靠性所付出的必要代价，但是 UDP 协议不需要这些策略，它只尽力保证数据报的送达。

我们今天来分析一下为什么首部只有 8 个字节的 UDP 协议能够将数据传输到目的地并由特定的服务接收和处理。我们可以将应用到应用之间的传输过程分成两个部分：主机到主机的数据传输和主机到应用的数据转发。

UDP 协议底层的网际协议（Internet Protocol，IP）会负责数据包在主机之间的传输；
UDP 协议首部的端口号用于定位处理数据的具体进程并转发数据；

我们都说 UDP 协议是传输层协议，但是真正在主机间完成『数据传输』工作的是 IP 协议，UDP 协议只起到了定位具体进程的作用。

本文转载自Draveness技术博客。
原文链接：https://draveness.me/whys-the-design-udp-minimum-header

创作场景

为什么 UDP 头只有 8 个字节（一）