UDP 协议简介

前言

前面我们了解了 TCP 协议，它可靠、有序，具备流量控制与拥塞控制，但复杂机制也带来额外开销。互联网中还有一类场景，不在乎少量丢包，优先追求低延迟，这时就会使用 UDP（用户数据报协议，User Datagram Protocol）。

直播、语音通话、游戏实时帧、DNS 查询、广播通信等大量场景底层都基于 UDP。很多开发者只知道 UDP"不可靠"，却不清楚它的设计优势、适用边界，以及 UDP 开发会遇到哪些典型问题。本文结合网络原理与 Socket 开发实践，带你完整理解 UDP。

UDP 同样工作在传输层，和 TCP 属于同级协议。

一、UDP 核心特性

一句话概括：无连接、面向报文、不可靠传输、无拥塞控制、开销极小。

1. 无连接

   通信前不需要像 TCP 一样执行三次握手建立连接。发送端直接打包数据，带上目标 IP 和端口直接发出。不存在"连接"这一概念，服务端不会保存客户端连接状态。

2. 面向报文

   应用层调用一次 sendto，操作系统就封装成一个独立 UDP 报文。报文之间边界清晰，不存在 TCP 那样的粘包问题。

注意：虽然没有粘包，但存在分包；报文超出链路 MTU 时会被 IP 层分片，分片丢失整个报文失效。

3. 不可靠交付

   UDP 没有确认应答、超时重传机制。数据包发出后，发送方无从知晓对方是否收到。数据包可能丢失、重复到达、乱序到达。

4. 没有流量控制与拥塞控制

   UDP 只管向外发包，不会根据接收方缓冲区、网络拥堵情况调整速率。高速发包极易造成网络拥塞、大量丢包。

5. 头部极简，传输延迟低

   UDP 头部仅 8 字节；TCP 头部最少 20 字节。更小的头部意味着更少带宽消耗、更低处理延迟。

6. 支持一对一、一对多通信

   天然支持广播与组播（多播），适合局域网设备发现、消息推送场景；TCP 只能一对一通信。

二、UDP 报文结构

UDP 头部一共 4 个字段，总共 8 字节：

1. 源端口（2字节）
2. 目标端口（2字节）
3. UDP报文总长度（2字节，头部+数据）
4. 校验和（2字节，可选校验数据是否损坏）

结构简单，操作系统内核处理开销极低，这是 UDP 延迟低的根本原因。

三、UDP 和 TCP 核心对比

特性	TCP	UDP
连接属性	面向连接，需要握手挥手	无连接，直接发包
传输方式	面向字节流	面向报文
可靠性	可靠，不丢包、有序	不可靠，可能丢包、乱序
控制机制	重传、ACK、流量控制、拥塞控制	无额外控制机制
头部开销	至少20字节	固定8字节
通信模型	仅单播（一对一）	单播、广播、组播（一对多）
典型问题	粘包问题	丢包、乱序、无法感知对方是否在线

四、常见认知误区澄清

误区1：UDP 一定会丢包

错误。网络环境良好时，绝大多数 UDP 报文都可以正常送达。

"不可靠"的定义是：协议层不保证送达，出现丢包不会自动重传，不等于数据包一定会丢失。

误区2：UDP 有粘包问题

错误。UDP 是面向报文。一次 recvfrom 最多读取一个完整报文。

如果缓冲区过小，报文会直接被截断丢弃，不会出现多个报文合并读取的粘包现象。

误区3：无法实现可靠通信

原生 UDP 不可靠，但可以在应用层实现可靠机制 ：自定义序号、ACK确认、超时重传。

诸如 QUIC（HTTP3底层协议）、游戏私有可靠传输协议，都是基于 UDP 自研可靠逻辑。

五、UDP 开发常见痛点（Socket 开发重点）

1. 无法感知对方是否在线

   TCP 连接断开能够通过 recv 返回空字节识别；UDP 没有连接，对方下线、端口关闭，发送方不会得到任何通知。想要检测存活，必须自己实现心跳包。

2. 报文大小限制

   UDP 理论最大报文 65507 字节；但局域网、公网链路存在 MTU 限制（常见1500）。超大报文会被 IP 分片，任意分片丢失 → 整个报文作废。业务尽量控制单包大小，避免分片。

3. NAT 穿透难题

   内网设备使用 UDP 访问公网服务器时会产生 NAT 映射，长时间无数据交互，网关会清除映射记录，后续报文无法送达，也就是常说的"UDP 洞穿"场景。内网穿透、语音通话程序经常遇到该问题。

4. 无拥塞控制容易打满带宽

   不加限制持续高频发送 UDP，极易造成网络拥塞，引发大面积丢包，公网环境需要业务层做限速。

六、UDP 典型应用场景

✅ 适合使用 UDP：

1. DNS 域名解析：单次短请求，追求快速响应，丢包可以重试
2. 实时语音、视频通话（微信语音、直播、视频会议）：允许少量丢包，延迟优先
3. 网络游戏实时同步：玩家位置、操作指令，宁可丢包不要卡顿
4. 局域网设备广播发现：打印机、智能家居设备自动探测
5. QUIC / HTTP3：基于UDP，解决TCP在弱网下握手、切换网络的痛点

❌ 不适合原生 UDP：

文件下载、数据库交互、网页传输、日志上报等，要求数据完整不丢失，优先 TCP；

如果使用 UDP，则必须在应用层手动实现可靠传输逻辑。

七、拓展：如何基于UDP实现简易可靠传输思路

很多场景想要兼顾低延迟和可靠性，可以在应用层补充逻辑：

1. 每个数据包携带唯一序列号
2. 接收方收到报文回复 ACK
3. 发送方设置计时器，超时未收到ACK则重传
4. 接收端利用序列号去重、排序

这一套机制本质就是在应用层复刻 TCP 的部分能力，也是各类私有游戏协议、QUIC 的核心思想。

总结

UDP 以极简的设计牺牲了内置可靠性，换取更低延迟、更小开销与灵活的多播能力。它不是 TCP 的替代品，而是互补方案。

在进行 Socket 网络开发时，选择协议的核心判断标准：

是否能容忍少量丢包，是否追求最低延迟。

不能容忍丢包 → TCP；可容忍丢包、追求实时性 → UDP。

理解 UDP 原理之后，再结合之前学习的 Python UDP Socket 代码，就能根据业务场景合理选择通信方案，避免选错协议带来后期难以优化的问题。