1. UDP基础回顾：协议特点、与TCP对比、适用场景分析
做网络编程这么多年，我见过太多人一上来就怼UDP，觉得它「不可靠」、「丢包」、「乱序」，恨不得所有场景都用TCP。说实话，我以前也这么想。直到有一次在实时音视频项目里被TCP的队头阻塞折磨得欲哭无泪，才真正开始认真研究UDP。
UDP不是TCP的「低配版」。它们是两种设计哲学完全不同的协议。你想想看，TCP追求的是「完美」，UDP追求的是「够用」。在正确的场景下，UDP反而比TCP更「可靠」——我说的不是数据完整性，而是业务目标的达成率。
1.1 UDP协议的核心特点
UDP全称是User Datagram Protocol，用户数据报协议。它位于传输层，直接构建在IP层之上。说白了，它就是给IP包加了个「端口号」和「校验和」，然后就撒手不管了。
UDP的核心特性就四个字：无连接、不可靠。
具体来说：
- 无连接：发送前不需要握手，直接扔数据。节省了建立连接的时间开销。
- 不可靠：不保证送达，不保证顺序，不保证不重复。发出去就完事了。
- 无拥塞控制：不管网络堵不堵，照发不误。这一点在实时场景下反而是优势。
- 面向报文：应用层给多少数据，UDP就发多少，不拆分也不合并。边界清晰。
- 头部开销小：固定8字节头部，比TCP的20字节小得多。
我记得刚入行时，有个老工程师跟我说：「UDP就像寄明信片，TCP就像寄挂号信。」这个比喻我一直记到现在。明信片便宜、快，但可能丢；挂号信慢，但一定能到。
1.2 UDP与TCP的全面对比
很多教科书喜欢列一个长长的对比表，但我觉得那些表格太死板了。咱们直接看几个关键维度：
| 对比维度 | UDP | TCP |
|---|---|---|
| 连接状态 | 无连接，零状态 | 有连接，维护状态机 |
| 头部大小 | 8字节 | 20~60字节 |
| 可靠性 | 尽力而为，不保证 | 确认重传，保证送达 |
| 顺序性 | 不保证顺序 | 保证有序交付 |
| 拥塞控制 | 无 | 有（慢启动、拥塞避免等） |
| 流量控制 | 无 | 有（滑动窗口） |
| 传输模式 | 面向报文 | 面向字节流 |
| 双工通信 | 全双工 | 全双工 |
| 广播/组播 | 原生支持 | 不支持 |
| 典型延迟 | 微秒级 | 毫秒级（受握手和重传影响） |
这里我想特别强调一点：UDP的「不可靠」不是缺陷，是特性。TCP为了保证可靠，引入了确认、重传、拥塞控制等一系列机制。这些机制在文件传输、网页浏览等场景下是福音，但在实时通信场景下反而是灾难。
我曾经踩过一个坑：在一个游戏项目中，我们用TCP传输玩家位置数据。结果网络一波动，TCP开始重传旧数据，新数据被堵在后面。玩家看到的画面就是「瞬移」——上一秒还在A点，下一秒跳到C点，B点的数据被丢掉了。后来换成UDP，虽然偶尔丢包，但画面流畅多了。玩家反馈反而更好。
1.3 UDP的适用场景分析
UDP适合什么样的场景？我总结了一个简单的判断标准：如果数据「过期了就没用」，那就用UDP；如果数据「必须到，晚点到也行」，那就用TCP。
具体来说，以下几类场景是UDP的主战场：
1.3.1 实时音视频通信
VoIP、视频会议、直播推流。这些场景对延迟极度敏感，对丢包有一定容忍度。丢一帧画面，用户可能感觉不到；但延迟200ms，用户立刻觉得卡顿。我参与过一个视频会议项目，初期用TCP，延迟飙到500ms以上，后来切到UDP+自建FEC（前向纠错），延迟降到50ms以内。
1.3.2 实时游戏
FPS、MOBA、赛车类游戏。玩家的操作指令、位置信息都是「过期作废」的数据。用TCP重传旧指令，反而会干扰当前状态。现在主流游戏引擎（如Unity、Unreal）的网络层底层都是UDP。
1.3.3 DNS查询
DNS默认使用UDP（端口53）。查询一个域名，发一个包，等一个包回来。如果丢包了，客户端重试就行。用TCP做DNS查询反而慢，因为要先三次握手。
1.3.4 广播/组播场景
局域网设备发现、流媒体组播、股票行情推送。UDP原生支持一对多通信，TCP做不到。我记得在物联网项目中，设备上线时通过UDP广播发送发现报文，效率极高。
1.3.5 物联网（IoT）传感器数据
温度、湿度、电量等周期性上报数据。丢一个包没关系，下一个周期马上就有新数据。用TCP反而浪费资源，尤其是低功耗设备，握手开销太大。
我的个人习惯：在选型时，我会先问三个问题：1）数据能容忍丢包吗？2）延迟要求有多高？3）数据量是突发还是平稳？如果丢包容忍度>5%，延迟要求<100ms，数据量平稳——UDP基本就是最优解。
1.4 UDP的局限性
当然，UDP不是万能的。它的短板也很明显：
- 没有拥塞控制：如果发送端不管不顾地狂发数据，很容易把网络打爆。我曾经见过一个UDP客户端，在弱网环境下以10Mbps的速度发数据，结果把整个局域网的交换机搞挂了。
- 没有流量控制：接收端处理不过来怎么办？UDP不管。数据直接丢在接收缓冲区，满了就丢弃。
- 数据完整性弱：UDP的校验和是可选字段（IPv4下），而且只有16位。虽然碰撞概率低，但理论上存在数据损坏的风险。
- 防火墙不友好：很多企业防火墙会拦截UDP流量，或者对UDP做限速。我在做跨国传输时，经常遇到UDP包被中间路由器丢弃的情况。
所以，用UDP不是「不管了」，而是「换一种方式管」。后面几章我会详细讲如何在UDP之上构建可靠性、拥塞控制、流量控制等机制。说白了，UDP给了你一把「裸金属」，怎么打磨成趁手的工具，就看你的本事了。
1.5 本章知识体系总览
下面这张图概括了UDP的核心定位和决策逻辑。我建议你把它存下来，以后做网络选型时对照着看：
这张图把UDP的核心特点、适用场景、与TCP的差异串在了一起。你可以把它当作一个快速决策工具：当你在纠结用TCP还是UDP时，看看左侧的特点，再对照右侧的场景，基本就能做出判断。