用户数据报协议（UDP）

一、什么是UDP

定义：UDP（User Datagram Protocol，用户数据报协议）是TCP/IP协议族中的传输层协议 ，提供无连接、不可靠、面向报文的传输服务。

与TCP的关系：

对比维度	UDP	TCP
连接状态	无连接	面向连接
可靠性	不可靠（不确认、不重传）	可靠（确认+重传）
顺序保证	不保证	保证
流量控制	无	有
拥塞控制	无	有
开销（首部）	8字节	20-60字节
传输方式	面向报文（保留边界）	面向字节流（无边界）

核心定位 ：UDP牺牲可靠性，换取低延迟和高效率，适合对实时性要求高、对丢包容忍的应用。

（传输控制协议（TCP）更多知识点击跳转）

UDP在网络中的位置

复制代码

┌─────────────────────────────────────────┐
│           应用层                        │
│  DNS、DHCP、RTP、SNMP、TFTP...          │
├─────────────────────────────────────────┤
│          传输层                         │
│     UDP（协议号17）                      │
│     提供：端口 + 校验                    │
├─────────────────────────────────────────┤
│          网络层                         │
│     IP（协议号17的UDP数据报）            │
├─────────────────────────────────────────┤
│        数据链路层 + 物理层               │
└─────────────────────────────────────────┘

二、UDP的特点

特点	说明
无连接	发送数据前不需要建立连接，直接发，直接收
不可靠	不保证数据能到达，不确认，不重传
面向报文	应用层交给UDP多少数据，UDP就原样封装成一个个UDP数据报发送，不合并、不拆分
无流量控制	发送方可以以任意速度发送，不管接收方能处理多快
无拥塞控制	即使网络拥塞，UDP也照发不误
首部开销小	只有8字节，比TCP的20字节小得多
支持组播和广播	TCP只支持点对点，UDP支持一对多

UDP的"面向报文"特性

核心区别 ：UDP保留应用层数据的边界。

示例对比：

复制代码

应用层调用两次发送：
send("Hello")   →   send("World")

UDP（面向报文）：
┌──────────┐     ┌──────────┐
│ "Hello"  │     │ "World"  │   → 接收方两次recv分别收到"Hello"和"World"
└──────────┘     └──────────┘

TCP（面向字节流）：
┌─────────────────────────┐
│     "HelloWorld"        │   → 接收方一次recv可能收到"HelloWorld"
└─────────────────────────┘    （也可能一次收一半，取决于缓冲区）

UDP的后果：

每个UDP数据报必须**≤64KB**（IP最大65535字节，UDP首部8字节，IP首部20字节，数据最多65507字节）
如果应用层数据太大，IP层会分片，但只要一个分片丢失，整个UDP数据报就丢失

为什么一个分片丢失，整个UDP数据报就丢失？

核心原因：IP层不重传，UDP层也不重传。

三步理解

步骤发生的事情

1 大UDP数据报被IP层切成多个分片发送

2 其中一个分片丢失 → 接收方IP层等不到完整分片 → 超时后丢弃所有已收到的分片

3 UDP层根本看不到这个不完整的数据报 → 无法通知发送方重传

步骤	发生的事情
1	大UDP数据报被IP层切成多个分片发送
2	其中一个分片丢失 → 接收方IP层等不到完整分片 → 超时后丢弃所有已收到的分片
3	UDP层根本看不到这个不完整的数据报 → 无法通知发送方重传

三、UDP报文格式

格式图

复制代码

 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）         |       目的端口（Dest Port）     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            长度（Length）             |           校验和（Checksum）    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            数据（Data）                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

各字段详解

字段	长度	作用
源端口	2字节	发送方进程的端口号（不需要回复时可填0）
目的端口	2字节	接收方进程的端口号（用于分发给正确的应用程序）
长度	2字节	UDP首部+数据的总长度（单位：字节，最小8字节）
校验和	2字节	检测UDP数据报在传输中是否出错（可选，IPv4中可填0表示不校验）
数据	可变	应用层交给UDP传输的实际数据

端口号

作用：标识主机上的具体进程，让数据能准确送达正确的应用程序。

端口范围：

范围	类型	说明
0-1023	系统端口（Well-Known Ports）	分配给知名服务，如DNS(53)、DHCP(67/68)、TFTP(69)
1024-49151	注册端口（Registered Ports）	用户进程可用，如很多P2P软件
49152-65535	动态/私有端口（Dynamic/Private）	临时分配给客户端进程

常见UDP端口：

端口	服务
53	DNS（域名解析）
67/68	DHCP（动态主机配置）
69	TFTP（简单文件传输）
123	NTP（网络时间协议）
161	SNMP（简单网络管理协议）
514	Syslog（系统日志）
4000-8000	很多P2P软件、在线游戏、视频通话

UDP的校验和

1.计算范围

UDP校验和不仅计算UDP首部+数据，还计算一个伪首部（不真正传输，只是计算时临时构造）。

2.伪首部结构（IPv4）

复制代码

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        源IP地址（4字节）                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       目的IP地址（4字节）                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    0   |  协议（17）|          UDP长度（2字节）                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

各字段详解

字段	值	作用
源IP地址	发送方IP	防止源IP伪造
目的IP地址	接收方IP	防止路由错误
0	0	填充字节
协议	17	UDP的IP协议号
UDP长度	UDP首部+数据长度	与UDP报文中的长度字段相同

3.为什么需要伪首部

作用：校验数据是否正确送达目的地（IP地址和端口都正确）。

例子：如果IP首部的目的IP地址被篡改，但UDP报文本身没出错，UDP校验和会失败（因为伪首部中的目的IP和实际收到的IP不匹配）。

4.校验和可选性（IPv4 vs IPv6）

版本	校验和是否可选	说明
IPv4	可选（可填0表示不校验）	早期设计考虑性能，但实际很少关闭
IPv6	强制要求	IPv6不计算首部校验和，靠UDP校验和保护

四、UDP的典型应用场景

4.1 适合UDP的场景

场景	原因	例子
实时音视频	可以容忍少量丢包，不能容忍延迟重传	VoIP、视频会议、直播
在线游戏	需要低延迟，丢包一帧通常可接受	FPS游戏、MOBA游戏
DNS查询	一次请求一次响应，丢包就重问，开销小	域名解析
DHCP	客户端还没有IP地址，无法建立TCP连接	自动获取IP
SNMP	简单查询，丢包重试即可	网络设备监控
广播/组播	UDP天然支持一对多，TCP不支持	视频广播、局域网发现

4.2 不适合UDP的场景

场景	原因	应该用
文件传输	丢包会导致文件损坏	TCP
网页浏览	需要完整、按顺序的数据	TCP
电子邮件	不能接受数据丢失	TCP
远程登录	每个字符都不能丢	TCP

五、UDP的可靠性问题（为什么应用层常自己加可靠机制）

5.1 UDP本身不保证什么

问题	UDP的做法	后果
丢包	不确认、不重传	数据可能到不了
乱序	不排序	数据可能先发的后到
重复	不去重	可能收到同一份数据多次
流量控制	无	发送过快会淹没接收方
拥塞控制	无	网络拥塞时UDP也不减速，可能让情况更糟

5.2 应用层自行实现可靠性

很多基于UDP的协议，在应用层自己实现可靠性 ：（应用层知识点见 OSI七层模型）

协议	应用层加的功能
QUIC（HTTP/3）	确认、重传、拥塞控制、加密
RTP（实时传输协议）	序号、时间戳
TFTP（简单文件传输）	确认、重传、超时
KCP	可靠UDP库

好处：可以按需定制可靠机制，比如游戏可以只重传关键数据，不重传次要数据。