UDP 的工作原理
应用程序将一块数据交给 UDP。UDP 加上 8 字节首部，将数据报交给 IP，无需先建立连接即可发送。首部包含源端口、目标端口、长度和校验和。
应用 → UDP 源端口 53000 → 目标端口 53 → 192.0.2.53
应用 ← UDP 目标端口 53000 ← DNS 响应 ← 192.0.2.53接收系统根据目标端口，将数据报交给相应的应用程序。UDP 会保留数据报边界，但不确认数据是否送达，也不会重传丢失的数据。校验和用于检测数据损坏；在 IPv4 中可以不使用，但普通 IPv6 UDP 流量必须使用。
UDP 与 TCP
UDP 和 TCP 都通过 IP 传输应用数据，但两者的传输方式不同。
| 特性 | UDP | TCP |
|---|---|---|
| 连接建立 | 无 | 先握手 |
| 数据丢失 | 无内置恢复机制 | 确认并重传 |
| 顺序 | 不保证顺序 | 按顺序传送字节流 |
| 数据模型 | 独立的数据报 | 连续的字节流 |
UDP 的内置开销较低，但应用程序不一定因此运行得更快。应用程序可能需要自行实现可靠传输和拥塞控制。
常见用途
- **DNS 查询：**传统 DNS 通常使用 UDP 处理简短的查询和响应，并在需要时改用 TCP。
- **语音、视频和游戏：**在这些场景中，迟到的数据可能已经没有用，少量丢包反而更容易接受。
- **网络发现：**DHCP 等协议使用 UDP 传输广播流量。
- **QUIC 和 HTTP/3：**QUIC 基于 UDP 运行，但自行提供可靠性、加密和拥塞控制。
每个应用程序会自行决定如何处理丢失、重复或乱序的数据报。
UDP 与代理
常规 HTTP 代理会转发 HTTP 请求或建立 TCP 隧道，因此通常无法中继任意 UDP 流量。SOCKS5 通过 UDP ASSOCIATE 命令定义了 UDP 中继，但能否使用取决于代理服务和客户端是否支持。
应分别检查每条流量路径。工具可能通过代理发送 Web 请求，却通过本地网络直接发送基于 UDP 的 DNS 查询。浏览器还可能绕过已配置的 Web 代理发送 WebRTC 流量，造成 WebRTC 泄漏。
常见问题
UDP 会丢包吗？
会。UDP 不确认数据是否送达，不重试丢失的数据报，也不会对乱序的数据报重新排序。需要这些功能时，必须由应用程序自行处理。
UDP 比 TCP 快吗？
不一定。UDP 的内置开销较低，但应用程序的性能取决于所需的可靠性、拥塞控制和网络状况。
代理支持 UDP 吗？
取决于代理协议和具体实现。常规 HTTP 代理通常不能中继任意 UDP 流量，而 SOCKS5 可以通过 UDP 中继提供支持。