HTTP 协议不再基于 TCP？详解 HTTP3.0 与 QUIC 协议的演进

基本每个面试者都被这些概念敲打过：“HTTP 基于 TCP 协议连接”“TCP 三次握手”。但如果你的认知还停留在这一步，可能已经跟不上互联网的变化了。毕竟这都 2026 年了，情况真的还是这样吗？

2026 年的 HTTP 协议，早已更新到 HTTP/3.0。之所以如此孜孜不倦地迭代这么多版本，核心目的只有一个：为了快。HTTP 协议的终极目标，就是又快又稳地传递数据。

HTTP/0.9 与 HTTP/1.0：早期的不稳定版本

这两个版本目前已经没人用了。它们甚至没有所谓的“三次握手”，每次都要重新建立 TCP/IP 连接，属于短连接、一次性连接。由此会制造大量连接开销，很快就被淘汰了。

HTTP/1.1：经典的主流版本

HTTP/1.1 是目前互联网上的主流版本，也是我们最熟悉的经典版本。大家耳熟能详的 TCP 三次握手，正是从这个版本开始的。

它的底层基于 TCP 三次握手，采用无状态长连接。请求内容分为两部分：请求头（Header）和请求体（Body），响应同理。同时，它也支持通过 HTTPS 加密传输。

可以说，该有的功能它都具备了。正因如此，从 1997 年推出以来，HTTP/1.1 一直沿用了接近 20 年，才有了接下来的大版本更新。

HTTP/2.0：从文本到二进制的跨越

既然 HTTP/1.1 已经那么完善，HTTP/2.0 又改动了什么？

请求头缓存

首当其冲就是数据压缩。在 HTTP/1.1 里，每次请求都会附带完整的请求头和请求体。但众所周知，请求头里的很多字段一般是不会变动的。每次都要传一遍，虽然单次数据量不大，可架不住 HTTP 请求实在太频繁了。

1997 年编写 HTTP/1.1 的时候，前辈们肯定想不到现在一个网页可能要发起上百次请求。所以，HTTP/2.0 采用了一个思路：把请求头缓存到服务器和客户端上。对于重复的请求头，不再每次都传递完整内容，而是只传一个索引，这样可以节约带宽，也加快了交互速度。

请求内容二进制传输

在 HTTP/1.1 时代，传输是按文本顺序进行的。到了 HTTP/2.0，数据被转为二进制传输。它会把请求内容切成若干片段同时传输，大大提升了速度。

此外，HTTP/2.0 还有其他一些小特性，比如预测加载 CSS、优先加载、流量控制等。不过在协议底层上，它依然基于 TCP 三次握手不变。

HTTP/3.0：不再基于 TCP，而是拥抱 UDP

如果说 HTTP/2.0 是对 1.1 的优化修补，那 HTTP/3.0 的变化，相比 2.0 完全称得上是“天差地别”。

HTTPS 加密成为强制标准

首先就是 HTTPS 加密。在 HTTP/3.0 里，HTTPS 不再是可选项，而是必选项。以前 HTTPS 协议中的 TLS 加密和 TCP 握手是两个独立的连接，HTTP/3.0 则把两者合二为一，既加快了速度，也把加密作为了强制标准。

底层协议与握手行为：告别 TCP，改用 UDP

HTTP/3.0 最颠覆性的改变正在于此：它不再使用经典的 TCP 三次握手，而是改为了 UDP 协议。

首次连接时，它只需握手一次，之后便不再需要专门握手。更关键的是，首次连接就会把数据包一起带过去，相当于把“建立连接”和“获取数据”这两个动作合并到了一起。

改用 UDP 协议还有另一个巨大优势。原本的 TCP 是一种长的、连续的连接，数据包必须按顺序一个个传，如果某一个包丢了，后续的包即便到了也会被丢弃，直到重传成功。

而 UDP 协议本身是一种无状态的连接，一次性接收所有内容再一次性返回，两者的关联就此结束。

HTTP/3 在 UDP 的基础上，额外加了一层 QUIC 协议，专门用来处理丢包问题和可靠性。QUIC 协议会在数据包里增加 Connection ID、心跳机制等，用于重发和持久运行。在 HTTP/3 里，如果丢包了，它只会单独重发丢失的那个包，完全不影响其他包。

这种设计在手机等移动环境下优势格外明显。试想一个场景：你的手机网络从 Wi-Fi 切换到了移动数据。在以前的 TCP 协议下，所有 TCP 连接都会断开，你可能会感受到明显的断网。而基于 UDP 的 QUIC 协议，则可以自动重发中途丢失的包，实现无缝继续上网，用户几乎感知不到网络变化带来的卡顿。

总结：别再用老答案对待新问题了

回过头再看开头那道面试题，你还觉得“HTTP 协议基于什么协议”是一个能用一句“TCP”就轻松过关的问题吗？

新版的 HTTP/3.0，已经拥抱了 UDP，并构建出了全新的 QUIC 层。技术栈的迭代远比想象中要快，保持终身学习，也许才是应对变化最好的一种方式。