2022 年 10 月，IETF 正式发布了 RFC 9114——HTTP/3 的标准文档。表面上看，这只是 HTTP 协议从 1.1 到 2 再到 3 的又一个小版本迭代。但翻到协议栈的最底层会发现一件反常识的事：HTTP/3 不再跑在 TCP 之上，而是跑在 UDP 之上。整个互联网的传输层，正在经历一次悄悄的、不可逆的迁移。

把这件事说清楚，我们要先回到 1980 年代——TCP 协议被设计出来的那一年。当时的网络环境是局域网、拨号、电话线、几 KB 的带宽、几毫秒的延迟。在那个世界里，TCP 设计的“可靠性优先”哲学是完美的：宁可慢一点，也不能丢一个包。这种哲学支撑了整个互联网的前 30 年。但到了 2020 年代，这条路的代价已经远远大于它能换来的可靠性收益。

TCP 在今天遇到的三个具体问题

第一个问题是握手开销。TCP 建立连接需要三次握手，加上 TLS 1.3 的密钥协商，完成一个真正“准备好传输数据”的连接，需要 2 到 3 个 RTT.RTT 是什么？是数据包从你到服务器再回来的时间。跨太平洋的 RTT 大约 150 毫秒，跨大西洋大约 80 毫秒，5G 网络在弱信号下可能跳到 300 毫秒以上，Starlink 这种卫星互联网在切换卫星时 RTT 可能瞬时跳到 800 毫秒。这意味着，光是建链这一步，就要吃掉用户 0.5 秒到 2 秒的等待时间。

第二个问题是队头阻塞。HTTP/2 时代，一个连接里可以跑多个流（stream)，看上去像是“并行下载”。但所有流都跑在同一条 TCP 连接上，只要任何一个流丢了一个包，TCP 就会让整个连接等待重传。其他流明明已经收到了数据，也必须停在那里等这个丢包被补上。这就像一条高速公路上有一辆车抛锚了，后面所有的车都必须等它被拖走。HTTP/2 在大文件、多资源页面下的速度表现，经常比 HTTP/1.1 还差，原因就在这里。

第三个问题是连接迁移。TCP 连接是用“四元组”(源 IP、源端口、目标 IP、目标端口）来标识的。这意味着你从 WiFi 切到 4G，IP 一变，整条连接就废了，必须重连。在移动设备越来越普及的今天，这种“切一次网络就断一次下载”的体验越来越让人难以忍受。

TCP 的设计哲学是“先可靠，后性能”。这条原则在 1980 年代是对的，在 2020 年代的移动和卫星网络里，它的代价已经远远超过了它的收益。

UDP 不靠谱，但它“刚好够用”

UDP 是互联网协议族里最简陋的传输层协议。它不保证数据到达、不保证数据顺序、不做拥塞控制，只是把数据包尽力发出去。但正是这种“简陋”，让 Google 的工程师看到了机会——如果你愿意在 UDP 之上重新实现一遍“可靠传输”，你就可以按 2020 年代的网络环境，而不是 1980 年代的网络环境来设计。

这就是 QUIC 的核心思路：把 TCP 的可靠传输、TLS 的加密、HTTP/2 的多路复用，全部塞进 UDP 之上的用户态协议。UDP 在这里只是个壳，真正干活的代码全部跑在用户空间，不在操作系统内核里。这种设计带来两个巨大好处：迭代速度快（不需要等操作系统升级)，和定制能力强（可以针对具体场景优化)。

QUIC 解决了什么

QUIC 第一个杀手锏是 1-RTT 握手。在第一次连接时，客户端和服务器通过一次往返就完成密钥协商和建链，比 TCP + TLS 2.x 节省了一个 RTT。第二次连接时，QUIC 可以做到 0-RTT——客户端直接把请求和加密参数一起发出去，服务器立即响应。这对短连接场景（比如网页浏览、API 调用）的延迟优化是颠覆性的。

第二个杀手锏是真正的独立流。QUIC 在一条连接里跑多个流，但每个流有自己独立的丢包恢复机制。一个流丢了包，只影响它自己，其他流继续跑。这彻底解决了 HTTP/2 的队头阻塞问题。在视频点播场景里，音频流丢了包不会卡住视频流，反之亦然。

第三个杀手锏是连接迁移。QUIC 用一个 64 位的连接 ID 来标识连接，不依赖 IP 和端口。用户从 WiFi 切到 5G，IP 变了，但连接 ID 没变，下载继续无缝进行。这种设计在卫星互联网、车载网络、IoT 场景下尤其重要。

HTTP/3 的现状与争议

HTTP/3 在 2020 年左右开始大规模部署。根据 Cloudflare 的测量数据，2025 年全球已经有相当比例的顶级网站启用 HTTP/3.Cloudflare 的边缘节点直接支持 QUIC 终结，Akamai、Fastly 也都跟进了。但 HTTP/3 也不是没有争议——它对中间网络设备（防火墙、NAT、运营商 QoS）提出了新要求，因为 UDP 流量在这些设备上的优先级往往低于 TCP。

另一个争议是 UDP 本身的安全隐患。UDP 因为没有连接状态，可以被用来做放大攻击（DNS 放大、Memcached 放大都是经典案例)。QUIC 在协议层面做了大量防护，但它对整个互联网的 UDP 基础设施提出了更高的要求。

对下载场景意味着什么

回到下载这件事本身，QUIC 和 HTTP/3 带来的最直接好处是“短连接更快”。一个 5MB 的小文件下载，在 4G 网络下从点下链接到开始接收数据，HTTP/2 大约需要 300 到 500 毫秒，HTTP/3 大约需要 100 到 200 毫秒。这种延迟在用户体感上是“秒开”和“要转一圈”的差别。

更大的好处是大文件下载在移动网络下的稳定性。QUIC 的独立流机制和连接迁移能力，意味着一个正在下载的大文件，在用户切换 WiFi 到 5G 时不会断掉，也不需要从头开始。这种体验提升，在直播、在线视频、云盘下载这些场景下尤其明显。

下一篇我们会看到一个看似和 QUIC 对立、实则互补的技术——CDN 和边缘计算。它不解决协议层面的问题，而是从物理层面把内容推到离用户最近的机房，解决最后一公里的延迟和带宽问题。HTTP/3 是把路修好，CDN 是把仓库修到小区门口。

参考资料