Appearance
UDP：无连接、轻量传输与实时场景
UDP 是 User Datagram Protocol，中文常叫“用户数据报协议”。
如果把它压缩成一句话，可以直接这样看：
UDP 负责提供一种更轻量、无连接、尽力而为的数据报传输方式。
1. UDP 到底解决什么问题
不是所有场景都需要像 TCP 那样维护连接、确认应答、重传、排序。
有些场景更关心：
- 开销更低
- 时延更低
- 尽快发出去
- 某个包偶尔丢了也能接受
UDP 就是更偏这类需求的协议。
它主要负责：
- 提供端到端数据报传输
- 通过端口区分不同应用
- 保持协议本身足够轻量
2. 为什么说 UDP 是“无连接”
这表示：
- 双方不需要像
TCP那样先建立连接状态 - 每个数据报更像独立发送
- 协议层不会为这段通信维护复杂连接上下文
所以 UDP 的“无连接”不等于“完全没有双方概念”，而是：
协议层不强制维护一段长期连接状态。
3. UDP 不保证什么
这部分非常关键。
UDP 不保证：
- 一定送达
- 一定按序
- 一定不重复
- 一定有拥塞与流量控制机制帮你兜底
也就是说，它把很多事情留给了上层应用自己决定。
🌟 所以 UDP 的核心不是“更高级”，而是 少做很多事，把控制权和代价留给上层。
4. UDP 的能力边界
4.1 UDP 负责什么
- 提供端口级别的数据报收发
- 给应用一个更轻量的传输层通道
4.2 UDP 不负责什么
- 不维护连接状态
- 不提供可靠重传
- 不提供按序交付
- 不理解应用数据语义
所以它更像：
- 我负责把这个数据报发出去
- 但能不能到、什么时候到、顺序对不对，上层要自己考虑
5. 为什么很多实时场景会用 UDP
因为在音视频、语音、直播、在线游戏等场景里，经常有一个现实判断：
过晚到达的数据，价值可能还不如直接丢掉。
例如：
- 一帧视频晚来 2 秒，补回来意义不大
- 一次语音片段延迟太久，用户体验会明显变差
这时比起“绝对可靠”，业务更关心：
- 更低时延
- 更可控的上层策略
6. UDP 真的就“很简单”吗
协议层更简单，不代表业务层一定简单。
如果你在 UDP 之上还需要：
- 重传
- 顺序控制
- 拥塞控制
- 会话维护
那这些能力就可能要由应用层或更高层协议自己补。
所以 UDP 常见的工程现实是：
- 协议层简单
- 上层设计不一定简单
7. 一个最小的使用场景
下面这类场景通常都可能考虑 UDP：
DNS查询- 音视频实时传输
- 局域网广播或发现协议
- 对时延更敏感、对少量丢包可接受的业务
这不是说这些系统只靠 UDP 就能完成全部能力，而是说它们更适合从轻量传输起步，再补自己的上层机制。
8. 和 TCP 的核心区别
| 维度 | TCP | UDP |
|---|---|---|
| 连接 | 面向连接 | 无连接 |
| 可靠性 | 提供可靠机制 | 尽力而为 |
| 顺序 | 保证按序交付 | 不保证 |
| 开销 | 更高 | 更低 |
| 典型场景 | Web、数据库、RPC | DNS、音视频、游戏 |
所以选型时真正的问题不是“谁更先进”，而是：
当前业务更需要可靠性，还是更需要低延迟与更小协议负担。
9. 常见误区
9.1 以为 UDP 一定更快
不绝对。
实际写项目时，更多是这样，它协议开销更小，但最终体验还取决于业务、网络环境和上层机制。
9.2 以为 UDP 完全不适合重要业务
不准确。
很多重要业务会在 UDP 之上自定义可靠性和控制策略。
9.3 以为不用握手就没有任何状态
协议层无连接，不等于应用层完全不维护会话语义。
10. 一句话总结
UDP 这条主线，本质上是在解决 如何用更轻量的方式，把数据报尽快发到目标端口，并把可靠性、顺序和控制策略更多留给上层应用自己决定。