深入理解 RFC 768：用户数据报协议（UDP）

如果说TCP是互联网上可靠的信使，那么UDP就是那匹自由驰骋的野马。

1980年8月，J. Postel在RFC 768中正式定义了UDP。40多年过去了，这个只有8字节头部的协议，依然是支撑互联网半边天的核心基石。今天，我们通过这篇RFC，来彻底读懂它。

文档速览：一张身份证

• RFC编号：768
• 完整标题：User Datagram Protocol
• 标准状态：互联网标准 (Internet Standard)
• 发布日期：1980-08-28
• 核心目标：在IP网络上定义一种极简的、无连接的、尽力而为的数据报传输服务。让应用能以最低的协议开销发送消息。

一句话总结：UDP就是互联网上的“微信语音”，又快又省事，但不保证对方听清了。

核心机制：飞鞋传信的艺术

想象一下大学宿舍的生活。A栋的张三想给B栋的李四传个纸条。TCP会怎么做？张三先跑到李四房间门口敲门，确认李四在，然后递上纸条，李四看完了再回个“收到了”的凭证。UDP呢？张三把纸条卷起来，直接甩开膀子，把鞋扔进了李四敞开窗户的房间。

整个流程就两步：

1. 封装：应用层的数据，UDP在上面贴个“标签”（源端口、目的端口、长度、校验和），连招呼都不打，就交给IP协议。
2. 发送：IP协议负责在整个互联网中找到收件主机，然后把UDP报文塞给主机上对应端口号的应用程序。

没有握手、没有确认、没有重传、没有状态。这就是UDP的极致简单。

报文结构：极简主义的8字节

UDP头部只有8字节，结构清晰得如同一张整齐的表格：

0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | Source | Destination | | Port | Port | +--------+--------+--------+--------+ | | | | Length | Checksum | +--------+--------+--------+--------+ | | | data octets ... | +---------------- ...

• Source Port：可选。你自己房间的号码，方便对方回信（设为0表示不回信）。
• Destination Port：必填。收件人的房间号。这是UDP提供的唯一多路复用机制。
• Length：整封信的长度。最小值是8（只有信封，没有内容）。
• Checksum：一个基于IP伪头和UDP数据的校验值。全0表示发信人不计算校验，全1表示正常校验。一个容易忽视的陷阱！

与其他协议的依赖关系：

• UDP ↔ IP：UDP是“租客”，IP是“大楼”。UDP依靠IP进行寻址和路由。IP心里的“协议号”17，指的就是UDP。
• UDP ↔ TCP：一对孪生兄弟。TCP可靠但慢，适合文件、网页；UDP不可靠但快，适合语音、视频、DNS。它们是互补的，不是竞争的。
• UDP ↔ DNS：DNS查询是UDP最典型的应用场景。一个快速的小查询，一下就搞定。

开发者必知：5个关键知识点

1. 无边界？错！有边界！：一次sendto()发送的完整数据（包括应用层数据），接收方必须通过一次recvfrom()完整接收。不能像TCP那样分多次读取。否则丢数据。

2. 丢包是常态，不是异常：UDP说得很清楚了，“交付和重复保护不保证”。你的应用如果没有重传和序列号机制，就当它在玩丢包游戏。

3. Checksum陷阱：别忘了，UDP发送方可以选择不计算校验和（填0）。这会导致数据静默损坏而应用层不知情。不要依赖它保护关键数据。

4. MTU分片地狱：如果UDP报文（头部+数据）大于路径MTU（比如1500），IP层会分片。但任何一个分片丢了，整个UDP报文就废了。设计应用时，让UDP数据尽量小于1468-1472字节。

5. 协议号：17：防火墙、抓包工具、或自己造协议时，识别UDP的协议号是17。这是你的技术名片。

一句话记住这个协议

UDP，就是最快的、不保证送达的、无连接的“快递信封”，它用最精简的8字节头部，让你在IP网络上快速传递消息，但真的丢了，它绝不会帮你捡回来。用完就忘，简单粗暴，却让VoIP、视频流和在线游戏有了灵魂。

珍视UDP，但永远不要指望它。它是最好的“朋友”，也是最坏的“队友”。