illegalCreed

中文

English

中文

English

Appearance

UDP 协议与适用场景 ​

基于 HTTP 现代标准 · 核于 2026-06

速查 ​

  • UDP（User Datagram Protocol，用户数据报协议）= 无连接的轻量传输层协议，RFC 768 定义，在 IP 之上仅做「加端口 + 加校验和」的最薄封装，IP 协议号为 17。
  • 核心定位：当「速度与效率」比「可靠与有序」更重要时用 UDP——发包前不握手、不建连，数据可以立即开始传输。
  • 四不保证：不保证送达（丢了不重传）、不保证顺序（可能乱序到达）、不保证不重复（可能收到重复包）、无拥塞控制（不会因网络拥塞自动降速）。
  • 报文叫「数据报（datagram）」：首部固定 8 字节，仅 4 个字段——源端口 / 目的端口 / 长度 / 校验和，各 16 bit（2 字节）。
  • Length 字段 = 首部 + 数据的总字节数，最小值为 8（只有首部、无数据时）。
  • 校验和（Checksum）：对「伪首部 + UDP 首部 + 数据」做 16 位反码和，伪首部含源/目的 IP、协议号、UDP 长度，可防误投；IPv4 下校验和可选（填 0 表示不校验），IPv6 下必填。
  • 源端口可选：不需要对端回包时可填 0。
  • 为什么快：省掉三次握手往返（少一个 RTT）、无连接状态（服务端不为每条「连接」维护 TCB，内存开销小）、首部仅 8 字节（TCP 至少 20 字节）。
  • 典型场景：DNS 查询、实时音视频 / 直播、在线游戏、VoIP、DHCP、以及 QUIC / HTTP/3 的传输基础。
  • 不适合：要求可靠、有序、完整的大文件传输（如网页 HTML、API 数据、文件下载）——这类交给 TCP。
  • 应用层兜底：UDP 把可靠性「下放」给应用——需要时由应用自己实现确认、重传、排序（QUIC 正是这么做的）。
  • 上游端口与复用分用见传输层与端口·复用分用；与 TCP 的逐项对比与队头阻塞见TCP vs UDP 选型与队头阻塞。

一、UDP 是什么：IP 之上最薄的一层 ​

传输层有两大协议：TCP 与 UDP。如果说 TCP 是「打电话」——先拨号、对方接听、确认听清后才说话，那么 UDP 就是「寄明信片」：写上地址直接投进邮筒，不确认对方在不在家、不保证一定送到、也不保证多张明信片按寄出顺序抵达。

Cloudflare 对 UDP 的定性很精炼：

The User Datagram Protocol speeds up communications by not formally establishing a connection before data is transferred. This allows data to be transferred very quickly, but it can also cause packets to become lost in transit. —— Cloudflare, What is UDP?

UDP 在 IP 之上只做两件事：

  • 加端口：用源端口 / 目的端口区分同一台主机上的不同进程（复用与分用，详见上一页）。
  • 加校验和：对数据做一次完整性检查，发现损坏的包直接丢弃（但不负责重传）。

除此之外，IP 不保证的（送达、顺序、去重），UDP 一概不补。MDN 把这点说得很直白：UDP 提供 checksums 与端口，但 no guarantee of delivery, ordering, or duplicate protection；需要纠错就该改用 TCP 或 SCTP。

丢包不全是 UDP 的「锅」

Cloudflare 特别指出：互联网的路由器本就默认不做排序与到达确认（否则要消耗不可行的巨量内存）。UDP 只是「如实暴露」了底层 IP 网络的不可靠；TCP 则是在应用需要时，在传输层「填补」这道缺口。理解这一点，就明白可靠性本质是一种「按需付费」的开销。

二、UDP 报文结构：固定 8 字节首部 ​

UDP 数据报由**首部（Header）+ 数据（Data）**组成，首部固定为 8 字节，结构极其简单：

 0      7 8     15 16    23 24    31   ← bit 位
+--------+--------+--------+--------+
|     源端口       |    目的端口      |   ← 各 16 bit
+--------+--------+--------+--------+
|      长度        |     校验和       |   ← 各 16 bit
+--------+--------+--------+--------+
|              数据 (payload)        |
+-----------------------------------+

四个字段（依据 RFC 768）：

字段长度含义
源端口 Source Port16 bit发送方进程端口；可选，无需回包时填 0
目的端口 Dest Port16 bit接收方进程端口，用于分用到正确的应用
长度 Length16 bit首部 + 数据的总字节数，最小值 8（仅首部、无数据时）
校验和 Checksum16 bit对「伪首部 + 首部 + 数据」的 16 位反码和；IPv4 可选（填 0 不校验），IPv6 必填

校验和为什么要带「伪首部」

RFC 768 规定校验和覆盖一个伪首部（pseudo header）——它取自 IP 层的源地址、目的地址、协议号与 UDP 长度。这是为了「防止误投（protection against misrouted datagrams）」：万一包被投递到错误的 IP，校验和会对不上而被丢弃。注意伪首部只参与计算、不真正随包发送。

对比 TCP 至少 20 字节、且含序号 / 确认号 / 窗口 / 各种标志位的复杂首部，UDP 的 8 字节首部几乎没有「协议开销」——这正是它轻量、快速的根源。

三、为什么要用 UDP：用「不可靠」换「快」 ​

UDP 的优势全部来自它的「少做事」：

3.1 无握手，低延迟 ​

TCP 通信前必须完成三次握手（一次往返 RTT）才能开始发数据；UDP 没有这个过程，第一个包就是数据。在跨洲网络里一个 RTT 动辄上百毫秒，省掉它对 DNS 查询、游戏指令这类「一来一回」的小交互意义巨大。

3.2 无连接状态，开销小 ​

TCP 服务端要为每条连接维护一份控制块（TCB：序号、窗口、定时器、缓冲区……），海量连接会吃掉大量内存与 CPU。UDP 无连接，服务端不为「连接」保存状态，天然适合 DNS 这种「一台服务器应对海量短查询」的场景，也更容易水平扩展。

3.3 可靠性「下放」给应用层 ​

不要把「UDP 不可靠」理解为「用 UDP 就一定不可靠」。UDP 只是把要不要可靠、要多可靠的决定权交给应用：

  • 实时音视频：主动选择容忍丢包——丢一帧画面远好过为了重传而卡顿（一句「有杂音但实时」的通话，胜过「清晰但延迟两秒」）。
  • QUIC：在 UDP 之上自行实现确认、重传、排序、拥塞控制，做到既可靠又能绕开内核 TCP 的种种限制。

这种「按需定制可靠性」的灵活度，是 UDP 在现代协议设计中复兴的关键。

四、UDP 的典型适用场景 ​

场景为什么选 UDP
DNS 查询单个请求/响应、报文小，无需建连；快与省资源压倒一切（默认 UDP 53）
实时音视频 / 直播时效性 >完整性，丢几帧可容忍，绝不能为重传而卡顿
在线游戏 / VoIP位置/语音持续更新，最新一帧才有意义，旧包重传无价值
DHCP主机还没 IP 时就要广播获取配置，无法先建立 TCP 连接
QUIC / HTTP/3以 UDP 为底座，把可靠传输与多路复用做到应用层，规避 TCP 队头阻塞

UDP 不适合什么

凡是要求可靠、有序、完整送达的传输，都不该裸用 UDP：网页 HTML、API 的 JSON 数据、文件 / 镜像下载、数据库同步……这些场景「错一个字节都不行」，正是 TCP 的主场。简言之：能容忍丢包、且追求低延迟 → UDP；要求零差错、完整有序 → TCP。

安全副作用：UDP 反射放大攻击

正因为 UDP 无需握手就能发包，攻击者可伪造源 IP向 DNS/NTP 等服务发请求，让服务器把巨大的响应「反射」到受害者（放大攻击 / UDP Flood）。这是 UDP「无连接」带来的代价。防御思路：限制 ICMP 响应速率、用分布式数据中心吸收流量等——这属于 DDoS 防护范畴，本页不展开。

小结 ​

  • UDP 是 RFC 768 定义的无连接、轻量传输协议（IP 协议号 17），首部固定 8 字节：源端口 / 目的端口 / 长度 / 校验和。
  • 它四不保证（送达 / 顺序 / 去重 / 拥塞控制），用「不可靠」换来了无握手低延迟、无连接状态开销小的速度优势。
  • 适合 DNS、实时音视频、在线游戏、DHCP、QUIC/HTTP/3 等「时效优先、容忍丢包」的场景；不适合要求可靠有序的大文件与关键数据传输。
  • 可靠性可由应用层按需自建（QUIC 即范例），这正是 UDP 在现代协议中复兴的原因。

上一页 传输层与端口·复用分用 打好了「端口如何区分进程」的地基；下一页起进入 TCP 世界，先看它如何建连与断连——TCP 三次握手与四次挥手。