前阵子写了篇 TCP 三次握手四次挥手（/post/136.html），捋完之后脑子里突然蹦出个问题：跟 TCP 同一层的还有个 UDP，这俩到底差在哪？

很多人只记得“TCP 可靠、UDP 不可靠”，然后就没了。可靠不可靠具体指啥？为啥不可靠还有人用？

这篇我们把 TCP 和 UDP 摆一块儿，一条条对比清楚。

先给俩快递公司画个像

直接讲协议容易干，我们拿寄快递打个比方。

TCP 像一家较真的快递公司：

• 寄之前先给你打电话确认地址（建立连接）
• 每送到一件都要你签收（确认回执）
• 没签收的会一直重寄（丢包重传）
• 保证按你寄的顺序一件件送到

UDP 像一个图省事的传单派发员：

• 不打招呼，抓起来就往你门口塞
• 塞完就走，不管你收没收到
• 丢了？丢了就丢了，不补
• 谁先到谁后到，随缘

这俩画像立住了，下面的区别就都是从这里长出来的。

区别一 要不要先建连接

TCP 是面向连接的。

传数据之前，必须先通过三次握手把连接建起来，传完还要四次挥手把连接关掉。就像打电话，得先拨通、确认对方在，才能开聊。

UDP 是无连接的。

它不握手、不挥手，抓起数据就发，根本不管对面在不在、准备好没有。像是往对方信箱里塞张纸条，塞完就走。

这一条是所有差异的根，TCP 的“可靠”都是靠这条连接换来的，UDP 的“快”也是省掉这条连接省出来的。

区别二 保不保证送到

这就是大家常说的“可靠”到底指啥。

TCP 保证数据一定送达。

每发一段数据，接收方都要回个确认。发送方没收到确认，就认为丢了，会重发，直到确认为止。所以正常情况下，TCP 传的东西不会缺胳膊少腿。

UDP 不保证送达。

发出去就完事了，丢没丢它不管，也不重发。网络一抖，包丢了就是丢了。

所以“可靠”这个词，说白了就是丢了会不会帮你补。TCP 补，UDP 不补。

区别三 顺序乱不乱

数据在网络里是拆成一个个小包走的，走的路可能不一样，到达顺序未必跟发出顺序一致。

TCP 会帮你排好序。

每个包都带编号，接收方按编号重新拼回原来的顺序再交给你。你收到的，永远是发送方发出时的那个顺序。

UDP 不管顺序。

先到的先给你，后到的后给你，顺序乱了它也不负责整理。

区别四 快慢差多少

聊到这儿就好理解为啥 UDP 还有人用了。

TCP 又是握手、又是确认、又是重传、又是排序，这一堆机制都是开销。可靠是可靠，但慢，也占资源。

UDP 把这些全省了，头部信息也少得多，所以它又快又轻。

打个比方：TCP 是全程有回执、有跟踪的挂号信，稳当但慢；UDP 是随手一扔的普通传单，快是快，丢了活该。

速度和可靠，这里有个天然的取舍，鱼和熊掌。

一张表对齐区别

零散讲完了，拉个表对齐着看一眼更清楚：

对比项        TCP                 UDP
--------      ----------------    ----------------
连接          面向连接(要握手)     无连接(直接发)
可靠性        保证送达,丢了重传    不保证,丢了不管
顺序          保证按序到达         不保证顺序
速度          较慢,开销大          快,开销小
头部          较大                 很小
场景          要求完整准确的传输    要求快、能容忍丢一点
​

那什么时候用哪个

光记区别没用，落到场景才算真会。

要求数据完整、准确、不能出错的，用 TCP。

• 网页浏览、接口请求（HTTP 就是基于 TCP 的）
• 文件传输、下载（少一个字节文件就废了）
• 发消息、发邮件（丢一句话可不行）

这些场景，宁可慢一点，也不能错、不能丢。

要求快、又能容忍偶尔丢一点的，用 UDP。

• 视频直播、语音通话（丢一两帧画面顶多花屏一下，但绝不能卡着等重传）
• 在线游戏（要的是实时，晚到的旧数据等于没用，重传反而添乱）
• DNS 查询（一问一答，快最重要，丢了再问一次就是）

看出规律了吗？

• 数据比时间重要 → TCP：错了不行，慢点没关系
• 时间比数据重要 → UDP：快最关键，丢一点能忍

直播里丢一帧画面你没感觉，但要是为了这一帧卡住等重传，那才是灾难。这时候 UDP 那个“丢了就丢了”反而是优点。

小结

绕回最开始那句“TCP 可靠、UDP 不可靠”，现在应该能说清背后是啥了。

• 连接：TCP 要握手建连，UDP 抓起来就发
• 可靠：TCP 丢了会重传，UDP 丢了不管
• 顺序：TCP 保证按序，UDP 不管
• 速度：TCP 慢但稳，UDP 快但糙

选择就一句话：数据比时间重要选 TCP，时间比数据重要选 UDP。

UDP 不是“差”，它是把可靠性换成了速度，专门服务那些等不起的场景。

搞清楚这个取舍，就不会再无脑一律上 TCP 了。那就按场景挑着用吧。