1. UDP 解决的是什么问题#

一台电脑上往往同时运行浏览器、游戏、DNS 等许多程序。IP 地址只能把数据送到某台电脑，UDP 再加上端口号，让操作系统把数据交给这台电脑里的正确程序。

可以把 UDP 看成寄明信片：

1
应用写下一段完整消息
2
        ↓
3
UDP 写上“从哪个端口来、送到哪个端口”
4
        ↓
5
IP 尽力把它送到另一台电脑
6
        ↓
7
对方操作系统按目的端口交给对应程序

例如程序 A 发给 B 的 12345 端口，B 的操作系统就会查找正在使用 12345 端口的程序，并把这条消息交给它。这里的端口可以理解成一台电脑里的“收件窗口号”。

UDP 不会把两次 send 自动拼成一长串字节。应用发送一条消息，接收端收到的也是一条消息；这个“消息边界”会被保留。

2. UDP 首部里有什么#

UDP 的附加信息很短，只有 8 字节，包含四项：

前两个字段解决“谁发给谁”；长度帮助接收端正确切出这条消息；校验和解决“收到的内容看起来有没有被传坏”。

3. 校验和：发现损坏，不负责修好#

发送端会根据 UDP 的附加信息、消息内容，以及两端 IP 地址等信息，算出一个很短的“核对码”放进包里。接收端重新计算：

1
核对不上 → 认为消息可能坏了 → 丢弃
2
核对得上 → 继续交给应用

因此 UDP 并不是完全不管数据是否传坏；它会尽量避免把明显损坏的数据交给应用。不过它只负责发现问题：不会找回原内容，也不会自动重发。

而且这不是百分之百保证。极少数损坏后的数据可能恰好仍通过核对；在 IPv4 中，发送端还可以选择不启用 UDP 校验和。

更重要的是，校验和只能防“意外传坏”，不能证明答案来自可信的人。有人如果故意伪造一份 DNS 回复，可以同时伪造相应的核对码。要验证 DNS 答案确实可信，需要 DNSSEC 这样的签名机制；这已经是另一层的工作。

4. UDP 不保证什么#

把消息交给 UDP，并不等于对方一定会收到。网络中可能发生：

• 消息丢失；
• 同一条消息到达两次；
• 后发的消息先到；
• 消息到了，但对方程序还没来得及处理。

所以 send 调用成功，只能说明“本机操作系统已经接下这条消息”，不能说明远端程序已经收到，更不能说明远端已经处理成功。

UDP 也不会自己等待回复、重发、排序或去重。这些工作要么由应用自己决定，要么改由 TCP 等其他协议处理。

5. DNS 为什么常用 UDP#

传统 DNS 查询通常很短：

1
电脑：www.example.com 对应哪台电脑？
2
DNS：93.184.216.34

它像问一次地址、得到一次回答。UDP 不必先建立长期连接，直接提问、直接回答，服务器也不用为每个问题保存一份连接记录。因此面对大量短查询时，开销较小。

如果电脑等了一会儿还没收到 DNS 回复，它会再问一次，或改问另一台 DNS。查询“这个名字对应什么地址”通常可以安全地重复，因此这类简单重试适合放在 DNS 自己这一层，而不是要求 UDP 为每个包维护复杂的确认机制。

但 DNS 并非永远使用 UDP：当回复很长，或需要传输较多数据时，可以改用 TCP。核心不是“UDP 一定更快”，而是：短小、可重复提问的请求—回答，常常不需要先建立一条可靠的长连接。

6. 何时应该选择 UDP#

UDP 的优点不是替应用消除问题，而是把选择权留给应用。

• 实时音视频可能宁可丢掉过期画面，也不愿等待旧画面重发；
• DNS 这类查询可以超时后再问；
• 如果业务必须保证完整、按顺序、只处理一次，就需要应用自己补上这些规则，或使用 TCP。

因此可以把 UDP 记成一句话：

UDP 提供“带端口号的一条消息，尽力送达，并尽量发现意外损坏”；送达、顺序、去重和重试由更上面的协议决定。

课程材料依据#

• R069：AIGC 2-2 UDP service model。00:00:25--00:00:50 说明 UDP 在 IP 之上用端口把消息交给具体程序；00:00:50--00:01:53 介绍四个首部字段；00:01:53--00:02:43 说明校验和与错误丢弃；00:03:33--00:05:52 说明 UDP 不做确认、重传和流控，以及应用可自行恢复。
• R023：官方讲义说明 UDP 是程序到程序的尽力而为数据报，并指出 UDP/IP 的轻量校验用于发现传输中被改变的数据（第 8—15 行）。
• R026：官方讲义将 DNS、DHCP 列为短请求—回答型数据报服务，并说明收不到回答时由 DNS/DHCP 自行重传（第 1—3、20—23 行）。以上与 R069 一致。