TCP vs UDP 怎么选（偏实战：别背概念，用场景做决策）

项目里真正让人纠结的不是"TCP 可靠/UDP 不可靠"这种结论，而是这些更具体的问题：

这个接口/链路到底能不能丢？丢了能不能重试补救？
延迟更重要还是正确更重要？
连接数很多、短连接很多时，系统扛不扛得住？
线上出问题了，我怎么证明"丢包/重传/乱序"到底发生没发生？

这篇就用"知识分享 + 可验证"的方式，把 TCP/UDP 的选择讲清楚。

目录（按做决策/排查的顺序）

1. 先定标准：你到底在权衡什么
1. 一张差异表（先有地图）
1. TCP 的可靠性成本：它到底多做了哪些事
1. UDP 的低延迟来源：它到底省掉了什么
1. 场景选择：给你业务，你怎么一句话选出来
1. 实战：如何抓包/用命令验证是 TCP 还是 UDP、有没有重传
1. 最后总结

1. 先定标准：你到底在权衡什么

在真实业务里，你选 TCP 还是 UDP，通常不是"选协议"，而是在权衡三件事：

可靠性（正确）
时延（快）
开销（轻）

TCP 偏可靠，UDP 偏低延迟。

TCP ：强调"可靠有序"，适合 文件/交易/登录/接口调用 这类不能丢、不能乱序的场景。
UDP ：强调"低延迟/轻量"，适合 音视频、实时游戏、DNS 这类更在意时延、能容忍少量丢包的场景。

2. 差异对照表（先看整体）

维度	TCP	UDP
连接	面向连接（三次握手/四次挥手）	无连接（发就完了）
可靠性	可靠（确认/重传/序号/滑动窗口/拥塞控制）	不保证可靠、可能丢包/乱序
有序性	有序（按序交付给应用）	不保证有序
流量控制	有（接收窗口 rwnd）	无内建机制
拥塞控制	有（慢启动/拥塞避免等）	无内建机制
头部开销	较大（最少 20 字节）	小（8 字节）
传输模式	面向字节流（没有消息边界）	面向报文（有消息边界）
典型场景	HTTP/HTTPS、SSH、FTP、数据库连接	DNS、语音、直播、游戏、QUIC(基于 UDP)

建议你先把这张表当成"地图"记住：后面所有细节都能在这张表上找到位置。

3. TCP 的"可靠"到底包括什么

面试里不要只说"可靠"。你要能说清楚它靠哪些机制实现可靠。

3.1 可靠交付：序号 + 确认 + 重传

序号（Sequence Number）：给每段数据编号，便于识别丢失/乱序。
确认（ACK）：接收方告诉发送方"我收到了哪些数据"。
重传（Retransmission）：发送方发现超时或收到重复 ACK，就重发丢失的数据。

3.2 有序交付：乱序缓存，按序给应用

网络中可能出现乱序到达。

TCP 会：

把乱序到达的片段先缓存
等缺口补齐后再按序交付给应用

所以应用层看到的是"顺序的数据流"。

3.3 流量控制：避免把接收方压垮

接收方会在 ACK 中告诉发送方：

我当前还能接收多少数据（接收窗口 rwnd）

发送方就根据窗口控制发送速率。

本质目的：

让接收方来得及处理

3.4 拥塞控制：避免把网络打爆

即使接收方很强，如果网络本身拥塞，你继续狂发也会造成更严重的丢包。

TCP 有拥塞控制（典型四大算法）：

慢启动
拥塞避免
快重传
快恢复

面试不用背公式，但要能讲人话：

先试探网络容量
出现拥塞就收敛
网络变好再逐步放开

4. UDP 的"不可靠"到底意味着什么

UDP 的"不可靠"不是说它一定不可靠，而是说：

协议层不保证

所以它可能：

丢包
乱序
重复

但优点也很直接：

不需要建立连接
头部开销小
发送路径短，延迟更低

而且 UDP 也不是完全不能"可靠"。

你可以把可靠性上移到应用层（比如 RTP/RTCP、游戏协议、或者 QUIC）。

5. 什么时候选 TCP？什么时候选 UDP？

5.1 选 TCP 的典型场景

特征：

数据不能丢
顺序不能乱
业务能接受额外握手与开销

例子：

登录/下单/支付/转账
文件上传下载
数据库连接
大多数传统 Web API（HTTP/1.1、HTTP/2 仍基于 TCP）

5.2 选 UDP 的典型场景

特征：

极度在意延迟
允许少量丢包（或者可通过应用层补偿）
更需要"快"而不是"绝对正确"

例子：

语音通话
视频直播
实时对战游戏
DNS（一次请求很小，丢了重试成本也低）

5.3 一个面试官喜欢的说法：权衡三角

你可以用一句话总结"为什么要选"：

可靠性（正确）
时延（快）
开销（轻）

TCP 偏可靠，UDP 偏低延迟。

6. 实战：如何验证"我到底在用 TCP 还是 UDP"，以及是否有重传

6.1 最直接：看端口协议（Windows）

bash 复制代码

netstat -ano

你关注两点：

连接是 TCP 还是 UDP
对应进程 PID 是谁（把"网络问题"定位到具体进程）

6.2 抓包看证据（Wireshark）

如果是 TCP，你会看到：三次握手、序号/ACK、可能的重传（[TCP Retransmission]）
如果是 UDP，你会看到：一发一收的 datagram，没有握手，也没有协议层 ACK/重传

6.3 常见排障思路：你觉得"丢包"时，先问 3 个问题

是 UDP 丢包 （应用层没补偿）还是 TCP 重传（网络抖动导致吞吐下降）？
是 服务端处理慢 （应用耗时）还是 网络传输慢（RTT/重传）？
能不能通过 重试/幂等 把"少量丢"变成"可接受的结果"？

7. 最后总结

7.1 UDP 真的不能保证可靠性吗？

协议层不保证。
但应用层可以自己做：序号、ACK、重传、窗口。

加分点：

QUIC 就是基于 UDP 在应用层实现可靠传输与拥塞控制，用于 HTTP/3。

7.2 TCP 为什么慢？慢在哪里？

连接建立（三次握手）
可靠性机制带来的确认/重传
拥塞控制导致的"先慢后快"

7.3 TCP 是"面向字节流"，UDP 是"面向报文"是什么意思？

TCP：你 write 的边界不保留，可能出现粘包/拆包，应用层要自己处理消息边界。
UDP：一次 sendto 对应一个报文边界，接收时仍是一个整体（超长会被截断）。

7.4 你可以这样总结（写在脑子里的版本）

TCP 用"握手 + 确认 + 重传 + 窗口/拥塞控制"换来了可靠有序，但代价是更高的开销与在弱网下更明显的性能波动；UDP 把这些保证交给应用层，换来更低延迟与更轻的协议负担，适合实时场景。