4. UDP 典型应用场景：DNS、DHCP、流媒体、VoIP、游戏
聊完 UDP 的协议细节，咱们来看看它到底用在哪儿。说实话，UDP 在互联网里的地位一点也不比 TCP 低。很多对实时性要求高的场景，TCP 反而成了累赘。
我个人习惯把 UDP 的应用场景分成两类：「查一下就走」和「丢了就丢了」。前者是请求-响应模式，后者是持续流模式。下面这五个场景，基本覆盖了 UDP 最核心的战场。
核心观点：UDP 不保证可靠交付，但正是这种「不负责任」，让它能在 DNS、DHCP、流媒体、VoIP 和在线游戏里大放异彩。你想想看，如果视频通话每丢一帧都要重传，那画面早就卡成幻灯片了。
4.1 DNS 查询：一次请求，一个响应
DNS 是 UDP 最经典的应用。你访问一个网站，浏览器先得把域名解析成 IP。这个查询过程，绝大多数时候走的是 UDP 53 端口。
为什么不用 TCP？因为 DNS 查询太短了。一个请求包通常几十个字节，服务器返回的响应也差不多。用 TCP 的话，三次握手就要多花一个 RTT，太浪费了。
我记得有一次排查线上问题，用户反馈网页打开慢。抓包一看，DNS 查询竟然走了 TCP。原来是 DNS 响应超过了 512 字节，触发了 TCP 回退。这种情况很少见，但一旦发生，延迟就会明显增加。
小提示：DNS 标准规定，当响应超过 512 字节时，客户端会重新用 TCP 发起查询。现在 EDNS0 扩展把 UDP 上限提到了 4096 字节，所以 TCP 回退越来越少了。
4.2 DHCP：没有 IP 也能通信
DHCP 是个很有意思的场景。你的设备刚开机，连 IP 地址都没有，怎么跟服务器通信？
答案是用广播。DHCP 客户端往 255.255.255.255 发 UDP 广播包，源端口 68，目的端口 67。服务器收到后，再广播回复一个 Offer。
这个过程只能用 UDP。TCP 是面向连接的，需要先建立连接，但连 IP 都没有，怎么建立连接？说白了，UDP 的无连接特性在这里是刚需。
我曾经在调试一个嵌入式设备时遇到过坑：设备获取 IP 特别慢，抓包发现 DHCP 请求发了，但服务器没回。后来发现是交换机上开启了 DHCP Snooping，把广播包给过滤了。嗯，这种问题在复杂网络环境里很常见。
注意：DHCP 依赖广播，广播不能跨子网。如果需要跨子网分配 IP，必须在路由器上配置 DHCP Relay Agent，把广播转为单播转发。
4.3 视频流媒体：丢帧比卡顿好
看视频的时候，你更愿意接受画面偶尔花一下，还是等它缓冲半天？
绝大多数人选前者。这就是流媒体用 UDP 的原因。像 RTP（实时传输协议）通常跑在 UDP 上，视频数据一帧一帧地发。如果某帧丢了，解码器直接跳过，最多画面闪一下。但如果用 TCP，丢包后要重传，播放器就得停下来等，用户体验反而更差。
我参与过一个直播平台的项目，初期用的 TCP，结果用户反馈延迟高、卡顿多。后来切到 UDP + 自定义 FEC（前向纠错），延迟从 5 秒降到了 1 秒以内。当然，FEC 会多消耗一些带宽，但相比用户体验的提升，这点代价完全值得。
| 对比项 | TCP 传输 | UDP 传输 |
|---|---|---|
| 丢包处理 | 重传，导致卡顿 | 直接丢弃，画面花屏 |
| 延迟 | 高（重传 + 拥塞控制） | 低（无重传机制） |
| 带宽利用率 | 稳定但偏低 | 可自定义 FEC 补偿 |
| 典型协议 | HTTP-FLV、HLS | RTP、SRT、QUIC |
4.4 VoIP：实时通话的命脉
VoIP 和流媒体很像，但对实时性的要求更高。你打电话的时候，如果延迟超过 300 毫秒，对话就会变得很不自然。
VoIP 通常用 SIP 做信令（这个可以走 TCP 或 UDP），用 RTP 传语音数据（走 UDP）。语音包很小，通常 20 毫秒一包，每包只有几十到几百字节。如果丢包率在 5% 以内，人耳几乎感觉不到。但一旦用 TCP 重传，延迟飙升，通话质量直接崩掉。
我调试过一个 VoIP 网关的问题：用户反映通话有回声。抓包发现，RTP 流里混入了 TCP 重传包，导致语音包到达时间不均匀。后来把 SIP 信令和 RTP 流分开走不同的端口，问题就解决了。嗯，这种「信令和数据分离」的设计思路，在实时通信里很常见。
关键指标：VoIP 的 MOS 评分（Mean Opinion Score）与丢包率、延迟、抖动直接相关。UDP 天然低延迟、低抖动，但需要应用层自己处理丢包补偿（如 PLC 算法）。
4.5 在线游戏：快才是王道
玩 FPS 游戏的时候，你开枪的瞬间，服务器必须立刻收到。如果走 TCP，丢包重传会导致你的子弹比别人晚到 100 毫秒——这局基本就输了。
在线游戏是 UDP 的「铁杆用户」。游戏服务器通常用 UDP 传输玩家的位置、动作、状态等高频数据。这些数据的特点是：旧数据没用。如果某个位置包丢了，服务器直接等下一个包就行，没必要重传旧的。
我曾经优化过一个 MOBA 游戏的网络层。最初用的 TCP，玩家频繁反馈「瞬移」「技能放不出来」。后来改成 UDP + 状态同步，客户端每帧发送当前状态，服务器做插值和预测。效果立竿见影，玩家满意度提升了 30%。
当然，游戏里也不是所有数据都用 UDP。登录、匹配、排行榜这些对可靠性要求高的操作，还是走 TCP 更稳妥。
实践建议：游戏开发中，通常采用「混合传输」策略：关键操作（如购买装备）走 TCP 保证可靠，高频状态（如移动、攻击）走 UDP 保证实时。这样既能保证体验，又不会丢失重要数据。
4.6 本章小结：一张图看懂 UDP 应用场景
下面这张图总结了 UDP 的五大典型场景，以及它们各自的核心诉求。你可以看到，所有场景都指向同一个关键词——实时性。