传输层协议：UDP

目录

1、概念

2、报文结构

3、核心特性

3.1 无连接

3.2 不可靠交付

3.3 面向数据报

3.4 轻量级&高效

3.5 支持广播和组播

4、典型应用场景

5、优缺点分析

6、与TCP的区别

---

1、概念

UDP（User Datagram Protocol，用户数据报协议）

主要目的：供一种简单、高效、无连接的数据传输服务。

2、报文结构

UDP 头部： (8 字节)

• 源端口： (2 字节) 发送方应用程序的端口号。可选（可置为 0），用于接收方回复时知道发给谁。

• 目的端口： (2 字节) 接收方应用程序的端口号。必需。

• 长度： (2 字节) UDP 数据报的总长度（头部 + 数据），以字节为单位。最小值是 8（只有头部）。

• 校验和： (2 字节) 用于检测头部和数据在传输过程中是否出错（可选，但强烈推荐使用）。覆盖头部、数据和伪头部（包含源/目标IP地址、协议号等）。如果接收方计算校验和不匹配，数据报会被静默丢弃（不通知发送方）。

数据： (长度可变) 应用程序要发送的有效载荷。

3、核心特性

3.1 无连接

这是 UDP 最显著的特点。在发送数据之前，不需要像 TCP 那样先建立连接（三次握手）。

应用程序只需构造好数据报（Datagram），指定目标 IP 地址和端口号，就可以直接发送出去。

同样，接收方也不需要事先同意或准备好接收连接。它只是监听某个端口，等待数据报的到来。（虽然UDP可以有校验和检查错误，但不保证送达）

3.2 不可靠交付

UDP 不保证数据报一定能到达目的地。

它不提供以下 TCP 具有的可靠性机制：

• 数据包确认： 接收方不会发送 ACK 确认收到数据。

• 超时重传： 发送方在超时后不会自动重发丢失的数据包。

• 数据包排序： 接收到的数据包顺序可能与发送顺序不同，UDP 不会重新排序。

• 重复数据检测： 可能会收到重复的数据包（例如，网络路径变化导致），UDP 不会去重。

• 流量控制： 不会根据接收方的处理能力调整发送速率。

• 拥塞控制： 不会主动检测和避免网络拥塞。

结果： 数据包可能丢失、重复、乱序到达，或者被网络设备（如路由器）静默丢弃（例如在拥塞时）。应用程序需要自己处理这些问题（如果需要）。

3.3 面向数据报

数据是以离散的、独立的 “数据报” 为单位发送和接收的（完整的）。

• 发送方应用程序的每次写操作（例如一个 sendto() 调用）通常会产生一个独立的 UDP 数据报。

• 接收方应用程序的每次读操作（例如一个 recvfrom() 调用）通常接收一个完整的 UDP 数据报。

关键： UDP 不会像 TCP 那样将应用层的数据流拆分成多个段（Segments）或重新组装成流。它保留消息边界。

3.4 轻量级&高效

• 协议头非常小（只有 8 字节），开销远低于 TCP（通常 20 字节，带选项更多）。

• 没有连接建立/拆除的开销（三次握手、四次挥手）。

• 没有复杂的确认、重传、排序、流量控制、拥塞控制逻辑。这使得 UDP 的协议栈处理非常快，消耗的 CPU 和网络资源更少。

结果： 延迟更低，传输速度理论上可以更快（尤其是在低丢包率的网络上）。

3.5 支持广播和组播

UDP 可以将数据报发送到：

• 单播： 单个目标主机。

• 广播： 同一局域网内的所有主机（例如 255.255.255.255 或子网广播地址）。

• 组播： 加入特定组播组的所有主机。

TCP 是严格的一对一连接，只支持单播。

4、典型应用场景

1> 对延迟极其敏感，能容忍少量丢包：

• 实时音视频传输： VoIP (如 Skype, Zoom 的部分传输)、视频会议、在线直播。偶尔丢帧或短暂声音中断比延迟高导致卡顿更可接受。

• 在线游戏： 特别是快节奏的 FPS、MOBA 等。玩家位置、动作指令需要极快送达，丢失个别数据包（如非关键位置更新）影响相对较小，而延迟高（Lag）会严重影响体验。

• 实时流媒体： 部分直播协议（如某些 RTP 实现）。

2> 简单查询/响应模型，且请求/响应本身很小：

• DNS（域名系统）： 查询域名对应的 IP 地址。请求和响应通常很小，一次查询一个响应，重试成本低且快速（客户端负责超时重试）。

• DHCP（动态主机配置协议）： 获取 IP 地址、网关等信息。使用广播/组播，且过程本身包含重试机制。

• SNMP（简单网络管理协议）： 网络设备监控和管理。查询和陷阱（Trap）消息。

• TFTP（简单文件传输协议）： 轻量级文件传输（如路由器固件升级），协议简单，自带简单的确认机制（ACK）。

3> 广播/组播应用：

• 服务发现： 设备在局域网内广播宣告自身服务（如 Bonjour/mDNS）。

• 路由协议： 如 RIP。

• 多媒体分发： 组播视频流。

4> 在可靠传输之上构建自定义协议：

• 应用层可以在 UDP 基础上实现自己需要的、更贴合应用特性的可靠性、顺序、拥塞控制逻辑。这提供了极大的灵活性：

  • QUIC： HTTP/3 的底层传输协议，基于 UDP，整合了 TLS 加密，并实现了更快速、更灵活的连接建立、可靠传输和拥塞控制。

  • DTN（容断网）协议： 用于高延迟、易中断的网络环境（如太空通信）。

  • 特定游戏网络协议： 针对游戏状态同步特性优化的可靠性和顺序机制。

5、优缺点分析

优点：

• 低延迟： 无连接建立开销，无等待确认的延迟。

• 低开销： 头部小，协议逻辑简单，节省带宽和计算资源。

• 高效率： 在低丢包率网络中，吞吐量可以非常高。

• 简单： 协议本身简单，API 也相对简单。

• 支持广播/组播： 实现一对多通信的基础。

• 无连接状态： 服务器端无需为每个客户端维护连接状态，能支持更多并发“连接”（实际是无连接的会话）。

• 灵活性： 为应用层提供基础传输，允许在其上构建自定义的可靠性等机制。

缺点：

• 不可靠： 数据可能丢失、重复、乱序。应用程序必须自行处理（如果需要可靠性）。

• 无拥塞控制： 发送方可能以过高速度发送数据淹没网络，导致拥塞崩溃。应用层需要谨慎设计发送速率。

• 数据报大小限制： 单个 UDP 数据报的有效载荷通常不能超过 64KB（减去 IP 和 UDP 头部）。更大的数据需要应用层分片和重组（易丢失）。

• 易受 DDoS 攻击： 伪造源 IP 地址发送大量 UDP 数据报进行反射放大攻击（如 DNS/NTP反射攻击）非常容易。

6、与TCP的区别

特性	UDP	TCP
连接	无连接	面向连接 (需三次握手)
可靠性	不可靠 (不保证送达、顺序、不重复)	可靠 (保证送达、顺序、无重复)
传输单位	数据报 (保留消息边界)	字节流 (无消息边界)
速度	更快 (低延迟、低开销)	相对较慢 (连接管理、确认、控制机制)
开销	低 (头部小，8字节)	高 (头部大，通常20字节+)
流量控制	无	有 (滑动窗口)
拥塞控制	无	有 (多种算法)
广播/组播	支持	不支持 (仅单播)
复杂性	简单	复杂
典型应用	实时音视频、游戏、DNS、广播、QUIC/HTTP3	Web浏览(HTTP/HTTPS)、文件传输(FTP)、邮件(SMTP/POP/IMAP)、远程登录(SSH)