网络协议选型：TCP vs UDP vs QUIC
做网络编程，绕不开协议选型。很多人上来就 TCP，觉得稳定可靠。但我踩过不少坑，选错协议的场景最后都付出了代价。你想想看，一个实时通话用 TCP，丢包重传直接卡成 PPT。所以今天咱们把 TCP、UDP、QUIC 掰开揉碎，看看它们到底适合什么。
3.1 TCP —— 稳字当头的“老大哥”
TCP 干了四件事：保证数据到达、保证顺序、做流量控制、做拥塞控制。说白了，它就是个“强迫症”，丢包就重传，乱序就排队。但代价呢？头部 20 字节起步，三次握手加四次挥手，端到端延迟比 UDP 高一个数量级。
核心特性
- 面向连接（三次握手）
- 可靠传输（确认与重传）
- 有序交付（序列号排序）
- 流量控制（滑动窗口）
- 拥塞控制（慢启动、拥塞避免、快速重传）
我在项目里遇到过一个问题：一个视频监控平台，IPC 上传采用 TCP，结果 Wi-Fi 丢包时画面卡死十几秒。为什么？TCP 的队头阻塞——一个包丢了，后面所有包都得等。所以你问我 TCP 什么时候用？Web、邮件、文件传输、数据库事务，这些要求“死也要到”的场景。实时互动？赶紧绕道。
3.2 UDP —— 轻装上阵的“快枪手”
UDP 就是个“懒人”，不握手、不确认、不排队。应用层给它什么，它直接扔给对端。延迟低，开销小。但责任也全在应用层——丢了你得自己补。
什么时候选 UDP？
- 实时音视频通话（WebRTC）
- 在线游戏（FPS 类，丢帧比卡顿好）
- DNS 查询
- 物联网传感器数据上报（可容忍少量丢包）
- 广播/多播场景
我曾经在做一个流媒体推送项目时，开始用的 TCP，用户反馈在弱网下直播延迟飙到 10 秒。换成 UDP + 自定义 FEC 后，延迟降到 500ms，丢包率仅 1% 以内。记住了：UDP 不是“不可靠”，而是把可靠性交给应用自己控制。
3.3 QUIC —— 新一代“全能选手”
QUIC 是 Google 搞出来的，现在已经是 HTTP/3 的传输层基础。它基于 UDP，却内建了 TLS 1.3 加密、多路复用、0-RTT 握手、前向纠错。最狠的是：它解决了 TCP 的队头阻塞——一条流丢了包，只会阻塞那条流，其他流照发不误。
注意陷阱
QUIC 目前并不是银弹。它的实现（比如 Chromium 的 IETF QUIC 或 quiche）有内存开销，且一些中间件（防火墙、NAT）可能会丢弃 UDP 长连接。我在某电商 App 中试用 QUIC 时，发现部分老旧路由器会拦截 UDP 443，导致回退到 TCP 慢路径。所以 QUIC 必须做好“fallback 方案”。
我建议你按这个节奏评估：如果网络环境可控（比如自建 CDN、移动端全包），大胆上 QUIC。如果还是用公共网络，混用模式——QUIC 做主，TCP 做保底。
3.4 三协议对比表
| 特性 | TCP | UDP | QUIC |
|---|---|---|---|
| 传输层基础 | 协议栈自带 | 协议栈自带 | 基于 UDP，应用层实现 |
| 可靠性 | 内置（确认 + 重传） | 无，应用自建 | 内置（类似 TCP 但更灵活） |
| 有序性 | 严格有序 | 不保证有序 | 按流有序，多流可乱序 |
| 队头阻塞 | 整个连接 HOB | 无 | 仅单流 HOB |
| 握手延迟 | 3 RTT（含 TLS） | 0 RTT | 0~1 RTT |
| 多路复用 | 需多个连接 | 需应用层管理 | 原生多流 |
| 加密 | 可选（TLS 附加） | 需上层加密 | 内置 TLS 1.3 |
| 适用场景 | 文件传输、Web、DB | 实时互动、广播 | HTTP/3、移动弱网 |
3.5 选型决策流程
我习惯用这张图来帮团队做判断。你只需要回答三个问题：丢包完全不能容忍吗？延迟是否敏感？需要同时发送很多请求吗？然后就能知道该用哪个。
我的个人习惯
每当新项目架构评审，我会问三个问题：1. 数据必须按顺序到达吗？2. 用户能忍受 200ms 以上的延迟吗？3. 是否有多条独立的逻辑通道？三个“是” -> TCP；前两个“是” -> 考虑 QUIC；第一个“否”且第二个“是” -> UDP。这样做决策几乎没出过错。
最后说一点：协议选型不是非此即彼。我在视频会议系统里用过“混合模式”——信令走 TCP（保证可靠性），媒体流走 UDP（保证低延迟），上传日志走 QUIC（弱网优化）。你完全可以根据业务不同部分，选最适合的那个。千万别一把梭。好了，这一章就聊到这儿，去实战中试试吧。