TCP、UDP 是什么，哪些业务吃 UDP？
- 阅读
- 1,145次浏览
- 字数
- 897全文
- 时长
- 约 3 分钟估计阅读
上网的数据不是裸奔的，TCP 和 UDP 就是 IP 之上两种最常用的传输协议，相当于快递的两种发货模式。先记住一句话：怕丢包选 TCP，怕延迟选 UDP。
TCP：可靠快递，有回执、有重传、有顺序
发包裹前先握手建立连接；送到了对方要确认；丢件自动重发；保证顺序不乱。
**代价：**多了大量确认包，有额外延迟，开销更大。
**适合：**不能丢数据的场景。网页浏览、微信文字消息、文件下载、SSH、数据库访问。
UDP：广播扔快递，不确认、不重传、不保序
不用提前建立连接，发出去就不管了，对方收没收到、丢没丢，发送方并不知道。
**优点：**逻辑简单、延迟极低、开销小。
TCP 和 UDP 一表对比
| 维度 | TCP | UDP |
|---|---|---|
| 连接 | 先三次握手建立连接 | 无连接，直接发 |
| 可靠性 | 确认 + 重传，尽量不丢 | 不确认、不重传，丢了就丢了 |
| 顺序 | 保证按序到达 | 不保证顺序 |
| 延迟与开销 | 协议开销大，延迟较高 | 极轻量，延迟低 |
| 典型业务 | 网页、文件传输、登录与数据库 | 音视频通话、直播、游戏、DNS |
哪些业务真的在用 UDP
视频通话与直播：画面是连续流，晚到的帧补回来也没用了。
实时对战游戏：王者、吃鸡这类，只关心“现在这一帧”，不为旧数据等待重传。
DNS 域名解析：一问一答，报文短，追求快。
语音通话、实时对讲：同上，宁可轻微断续也不接受卡顿。
低延迟推流、组播：一份数据发给多个人，不必逐个建连接。
部分 IoT 设备上报：数据小、频率高，丢一条可以下次再报。
实际产品常混合使用：直播的信令走 TCP，音视频流走 UDP；低延迟线路用 UDP，高清回看走 TCP。
FAQ
Q1：UDP 不可靠，为什么游戏和视频通话还要用？
A：音视频和游戏画面是连续流。晚到的数据重传回来已经过时，不如直接丢掉，优先保证实时流畅。用 TCP 反而会因为等重传卡住。
Q2：DNS 为什么默认用 UDP？
A：请求报文很短，不需要复杂握手，一次请求一次应答，核心诉求就是快。返回内容太长时会切到 TCP。
Q3：UDP 丢包就没法补救吗？
A：UDP 本身不提供可靠保障，但应用层可以自己补逻辑。QUIC（HTTP/3 的底层）就跑在 UDP 上，由应用层实现握手、重传和拥塞控制。
Q4：TCP 的三次握手是什么？
A：双方先互相确认“我发的你能收到、你发的我能收到”，再开始传数据，是建立可靠通道的准备动作。
Q5：UDP 需要端口吗？
A：需要。TCP 和 UDP 都靠端口区分同一台机器上的不同程序，只是两者的端口空间互相独立。
Q6：有没有业务两个都能用？
A：有。很多音视频方案会做双通道兜底，低延迟走 UDP，稳定优先走 TCP。
