TCP 与 QUIC 横向对比：四个维度上的实质差异

TCP 与 QUIC 的差异不在「哪个更快」——协议不能突破链路的物理带宽。差异在四个具体机制上，每一项都有确定的适用条件。

本文只对比协议规范层面的机制差异（依据 RFC 9000 / 9002 / 8446 / 5681）， 不含任何实测数据。具体到你的链路上差多少，只能自己测。

一、握手轮次

组合	建立连接所需往返
TCP + TLS 1.2	TCP 三次握手 + TLS 两轮
TCP + TLS 1.3	TCP 三次握手 + TLS 一轮（RFC 8446）
QUIC	传输层与加密握手合并，一轮（RFC 9000）
QUIC 会话恢复	0-RTT，首包即可携带数据

这个成本由 RTT 决定，与带宽无关。 同城链路上省一轮可能只有几毫秒；跨洲链路上可能是几百毫秒——延迟越高，差距越明显。

⚠️ 0-RTT 有代价：首包数据不具备完整的重放保护，协议规范建议只用于幂等请求。这不是缺陷，是明确的设计取舍。

二、队头阻塞

TCP 保证按序交付。前面的包丢了，后面已到达的包必须等它重传完才能交给应用——一个流的丢包会拖慢同一连接上的所有流。

QUIC 在传输层实现多路复用，各流独立处理丢包（RFC 9000），不受此影响。

什么时候这项有意义：单连接承载多路请求、且链路存在丢包时。链路干净的情况下两者没有可感差别。

三、连接迁移

TCP 连接由四元组（源 IP、源端口、目的 IP、目的端口）标识。IP 一变，连接就断——切 Wi-Fi、换蜂窝网络都要重新握手。

QUIC 用连接 ID 标识连接，IP 变化时连接可延续。

什么时候这项有意义：移动设备频繁切换网络。固定桌面环境下基本用不到。

四、拥塞控制

TCP 经典拥塞控制把丢包视为拥塞信号（RFC 5681），一旦丢包立刻大幅收缩发送窗口。

这个假设在有线网络成立，在跨境链路和无线网络里经常不成立——那里的丢包大量来自链路不稳定而非拥塞。结果是链路还有余量，发送方却主动降速。

QUIC 的丢包检测与拥塞控制在 RFC 9002 中单独定义，可在用户态实现不同算法，迭代比内核态的 TCP 快。

⚠️ 但这不等于 QUIC 一定更快：具体表现取决于实现选用的算法，以及中间网络对 UDP 的处理策略。

五、QUIC 的两个现实约束

① 部分网络限制或降速 UDP。 企业网、校园网、某些运营商会对 UDP 做限速甚至阻断。这种环境下 QUIC 可能反而更差，客户端通常会回退到 TCP。

② CPU 开销更高。 QUIC 在用户态处理加密与拥塞控制，相同吞吐下 CPU 占用一般高于内核态 TCP。低性能设备上这一项值得留意。

六、怎么选

你的情况	倾向
高延迟跨境链路	QUIC（握手轮次差距被放大）
明显丢包	QUIC（拥塞控制与队头阻塞两项都受益）
移动网络频繁切换	QUIC（连接迁移）
链路干净、延迟低	差别不明显，选客户端支持最好的
网络对 UDP 有限制	TCP
低性能设备	TCP（CPU 开销更低）

结论

协议影响的是「在给定链路上能利用多少」，不是「链路本身有多宽」。

如果瓶颈是对端容量被超售或晚高峰负载过高，换协议解决不了。判断方法：在不同时段测同一条链路——只在特定时段慢是容量问题，全天都慢才轮到协议与配置。