TCP 和 UDP 有什么区别？
- 标签：网络
🏛 业务架构师
核心差异一句话：TCP 要"对"，UDP 要"快"。
- TCP：面向连接、可靠有序（重传、确认）、流量/拥塞控制、字节流——保证数据完整到达，代价是延迟与开销；
- UDP：无连接、尽力而为、报文边界保留（不粘包）、开销极小——不保证到达与顺序，换来低延迟与简单。
业务选型按"丢一次的代价"排序：
- 必须用 TCP：交易支付、订单、API 调用、文件传输、数据库连接——丢一个字节都是资损或错误；
- UDP 更合适：
- 音视频通话、直播推流——晚到的数据等于丢数据，宁可丢帧不要卡顿，应用层（RTCP/FEC）自己做弱恢复；
- 游戏、心跳、设备状态上报——高频小包，单条无价值；
- DNS 查询——一问一答，超时重发比建连接便宜；
- 海量 IoT 传感数据——按价值密度选协议，省电省流量；
- 折中典范 QUIC：UDP 上重建可靠性 + 多路复用 + 0-RTT——HTTP/3 证明"在 UDP 上按需定制"比"忍受 TCP 的历史包袱"更优——这给架构设计的启示是：当通用方案的税太重时，在更原始的地基上按业务重建。
工程提醒：UDP 的报文边界保留看似方便，但大报文分片后丢一片整包全丢——UDP 消息要控制大小（MTU 内）或自己做分包；另外运营商对 UDP 的 QoS 限制（限速）在国内环境真实存在，UDP 业务要带 TCP 降级路径。
一句话：协议选择 = 对"完整性"与"实时性"的优先级表态——业务对"错"和"慢"哪个更敏感，答案就在那里。
🏗 系统架构师
一张表对比，再讲选型：
| 维度 | TCP | UDP |
|---|---|---|
| 连接 | 面向连接（握手建状态） | 无连接 |
| 可靠性 | 确认重传、不丢不重 | 尽力而为，可能丢/乱 |
| 有序 | 保证字节流顺序 | 不保证 |
| 速度/开销 | 头部 20B+，有握手/重传/拥塞开销 | 头部 8B，极轻 |
| 传输形态 | 字节流（无边界） | 数据报（有边界） |
| 拥塞/流控 | 有 | 无 |
| 通信模型 | 一对一 | 一对一/多播/广播 |
选型逻辑（场景驱动）：
- TCP：数据完整性优先——HTTP/WebSocket、RPC、数据库连接、消息队列、文件传输；
- UDP：实时性优先、可容忍丢包——音视频通话（WebRTC，应用层自己做 FEC/ARQ）、直播（QUIC 之前的方案）、游戏（帧同步）、DNS 查询、心跳/服务发现（小报文一问一答，握手纯属浪费）；
- 混合路线：现代演进是"UDP 上重建可靠性"——QUIC（HTTP/3）用 UDP 绾开内核 TCP 的队头阻塞与升级困难，自己实现流级可靠、0-RTT、连接迁移；这是"TCP 太重、UDP 太裸"的第三条路。
架构启示：可靠性不是免费午餐，TCP 把重传/排序成本内置给所有用户；当你的业务不需要全部保证（或需要定制保证），UDP + 应用层协议是更精准的成本模型。
💻 全栈开发专家
| 维度 | TCP | UDP |
|---|---|---|
| 连接 | 面向连接（握手/挥手） | 无连接，拿起来就发 |
| 可靠性 | 确认+重传+校验，不丢不重不乱 | 尽力而为，可能丢/乱/重 |
| 有序性 | 字节流严格有序 | 数据报，无序 |
| 速度/开销 | 慢（状态 + 头部 20B+） | 快（头部 8B，无拥塞控制） |
| 通信模式 | 一对一 | 一对一/一对多/广播/组播 |
| 边界 | 字节流（要自己处理粘包） | 报文有边界 |
场景选择（按业务矛盾定）：
- 要"对"：HTTP/文件传输/邮件/数据库连接 → TCP；
- 要"快"且容忍丢：DNS 查询（小报文，丢了重问）、音视频通话（丢了跳帧，等重传不如丢）、游戏同步、心跳广播 → UDP；
- 既要快又要部分可靠：QUIC/HTTP3 在 UDP 上自建选择性重传；WebRTC 数据通道。
容易忽略的点（加分）：
- UDP 不是"不可靠所以没人用"——DHCP、NTP、流媒体都靠它，组播直播能省大量带宽；
- TCP 的可靠 ≠ 应用可靠：连接断开、进程崩溃时消息照样丢，应用层确认/幂等永远不能省；
- UDP 无拥塞控制，滥用会打爆网络（视频码率自适应就是在补这个），自建可靠 UDP 的难点全在拥塞控制上。
我做过的心跳选型：设备心跳用 UDP（丢了无所谓，下个周期再来），指令下发走 TCP（必须到达）。