一站式了解http1.1,http2.0和http3.0-编程阁

引言

无论在面试还是工作，我们都会遇到关于http的问题，这次我们通过http1.1和http2.0的对比，http2.0和http3.0的对比，从不同维度一站式讲清楚它们到底有什么区别，做了什么优化。坐稳扶好，让我一起来探讨吧！❤️

HTTP/1.1 (文本协议):
- 基于文本（Text-based），可读性好，但解析效率低且不够健壮。
- 报文由 Header 和 Body 组成，以换行符分隔。
HTTP/2.0 (二进制协议):
- 基于二进制（Binary-based）。
- 引入了二进制分帧层 (Binary Framing Layer)。所有的传输数据被分割为更小的帧 (Frame)（如 Headers Frame, Data Frame），并采用二进制编码。这让协议解析更高效，且不易出错。

这是 HTTP/2 最大的性能提升点。

ps：http1.1和2.0都支持持久连接

HTTP/1.1 (串行/管道化):
- 队头阻塞 (Head-of-Line Blocking):每个请求/响应必须按顺序在单独的 TCP 连接上完成（或通过持久连接串行处理），容易造成“队头阻塞”。在同一个 TCP 连接中，请求是串行的。如果前一个请求处理很慢，后面的请求必须等待，即使它们没有任何依赖关系。
- 为了解决这个问题，浏览器通常会为一个域名建立多个 TCP 连接（通常限制为 6 个），这带来了 TCP 握手和慢启动的开销。
HTTP/2.0 (多路复用):
- 单连接多请求:整个域名只使用一个TCP 连接。
- 流 (Stream):引入了 Stream 的概念。多个请求（Stream）可以并行地在一个 TCP 连接中交错发送不同 Frame。
- 乱序发送，重组还原:接收端根据 Frame ID 将它们重新组装成完整的 HTTP 消息。这彻底解决了应用层的队头阻塞问题。

HTTP/1.1:
- Header 是纯文本传输的。
- 每次请求都会携带大量重复的 Header（如User-Agent,Cookie,Referer），在请求频繁的现代应用中，这造成了巨大的带宽浪费。
HTTP/2.0 (HPACK 算法):
- 使用了HPACK算法进行压缩。
- 静态/动态字典:客户端和服务器同时维护一张 Header 表（静态表存通用字段，动态表存本次连接中出现的字段）。
- 后续传输只需要发送索引 (Index)而不是完整的字符串，极大减少了 Header 的体积

HTTP/1.1:
- 资源必须由客户端显式请求。浏览器解析 HTML -> 发现 CSS/JS -> 再发起请求。
HTTP/2.0:
- 服务器可以“预测”客户端需要的资源，在客户端请求 HTML 时，主动将相关的 CSS/JS 推送给客户端。
- 客户端可以在本地缓存中直接取用，无需再次发起请求。
- ps：虽然特性很好，但因实施复杂且缓存控制难以完美，部分大厂（如 Chrome）在某些场景下已开始废弃或不推荐重度依赖此功能。

好的，总结http1.1和http2.0的区别主要集中在四个点，协议格式，连接复用，头部压缩和服务器主动推送，主要的优化是集中在应用层的。我们可以先记住这四个点，随后就可以展开来讲，内容都非常好理解。

HTTP/3 是 HTTP 协议的一次底层重构。如果说 HTTP/2 是在应用层做了极致优化，那么 HTTP/3 则是为了解决 HTTP/2 无法解决的痛点，直接把手术刀伸向了传输层。

核心区别可以用一句话概括：HTTP/3 抛弃了 TCP，改用基于 UDP 的 QUIC 协议。

http2.0虽然在应用层解决了队头阻塞问题，但是如果在丢包率高的环境，那么传输效率可能还不如http1.1。而这正是 HTTP/3 诞生的最大动力。

HTTP/2 (基于 TCP):
- 虽然 H2 在应用层通过“流（Stream）”解决了 HTTP 请求的串行问题，但它底层依赖 TCP。
- TCP 是字节流协议，它不知道上面的 H2 流是什么。一旦发生丢包，TCP 为了保证数据完整性，会暂停后续所有数据的交付，等待重传。
- 结果：一个 Stream 的丢包，会阻塞该 TCP 连接上的所有Stream。在弱网环境下（丢包率高），H2 的性能甚至不如 H1.1。
HTTP/3 (基于 QUIC/UDP):
- QUIC 协议基于 UDP，且自己实现了可靠传输和流控制。
- QUIC 清楚地知道“流”的概念。
- 结果：Stream A 丢包，只会阻塞 Stream A，Stream B 和 C 照常传输。彻底消除了传输层的队头阻塞。

对于后端服务来说，握手耗时直接影响首字节时间（TTFB）。

HTTP/2 (TCP + TLS):
- 握手繁琐：先进行 TCP 三次握手 (1.5 RTT)，再进行 TLS 握手 (1-2 RTT)。
- 通常需要 3 个 RTT 才能开始发数据。
HTTP/3 (QUIC):
- 1 RTT:QUIC 将传输层握手和 TLS 1.3 加密握手合并了。
- 0 RTT (Zero RTT Resumption):如果客户端之前连接过服务器，它可以在发送第一个包（Hello 包）的同时直接发送加密后的应用数据。

这是一个针对移动互联网（手机端）的杀手级特性。

HTTP/2 (TCP):
- TCP 连接是由四元组标识的（源IP、源端口、目的IP、目的端口）。
- 当你从 Wi-Fi 切换到 4G 时，你的 IP 变了，TCP 连接必须断开重连。这也是你在电梯里视频通话卡顿的原因。
HTTP/3 (Connection ID):
- QUIC 不使用 IP:Port 标识连接，而是使用一个Connection ID (CID)。
- 当网络切换（IP 改变）时，只要 CID 不变，服务器和客户端依然能认出对方，连接保持不断，数据继续传输。

HTTP/2:依赖操作系统的 TCP 栈。拥塞控制算法（如 Cubic, BBR）升级需要更新操作系统内核，这在生产环境中非常缓慢且困难。
HTTP/3:QUIC 运行在用户态 (User Space)。拥塞控制算法集成在代码（Go/Java 库）中。
- 这意味着你可以针对不同的业务（如直播 vs 支付）配置不同的拥塞控制策略。
- Go 开发者优势:更新 Go 版本或依赖库版本，就能立刻享受到 Google 最新的拥塞算法优化，无需重启服务器机器。

http2.0和3.0的区别主要集中在四个点，彻底解决队头阻塞，连接迁移，握手速度和拥塞控制。