计网必问，你知道HTTP1.1/1.0和2.0的区别吗？解决了什么问题？一文搞懂他们的不同！

👨‍💻程序员三明治：个人主页 🔥 个人专栏: 《设计模式精解》 《重学数据结构》

🤞先做到 再看见！

HTTP/1.1 比1.0好在哪？1.1的优点？

1. 长连接

早期 HTTP/1.0 性能上的一个很大的问题，那就是每发起一个请求，都要新建一次 TCP 连接（三次握手），而且是串行请求，做了无谓的 TCP 连接建立和断开，增加了通信开销。

为了解决上述 TCP 连接问题，HTTP/1.1 提出了长连接的通信方式，这种方式的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。

持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。

2. 管道传输

在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

举例来说，客户端需要请求两个资源。以前的做法是，在同一个 TCP 连接里面，先发送 A 请求，然后等待服务器做出回应，收到后再发出 B 请求。那么，管道机制则是允许浏览器同时发出 A 请求和 B 请求。

1.1的性能问题

3. 队头阻塞

服务器必须按照请求的顺序作出响应。 如果服务端在处理 A 请求时耗时比较长，那么后续的请求的处理都会被阻塞住，这称为「队头堵塞」。 所以，HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞。

HTTP/2 做了什么优化？

HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。

那 HTTP/2 相比 HTTP/1.1 性能上的改进：

• 头部压缩
• 二进制格式
• 并发传输

1. 头部压缩

HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。

这就是所谓的 <font style="color:rgb(71, 101, 130);background-color:rgba(27, 31, 35, 0.05);">HPACK</font> 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

比如状态码 200 ，在 HTTP/1.1 是用 ‘2’‘0’‘0’ 三个字符来表示（二进制：00110010 00110000 00110000），共用了 3 个字节，如下图

在 HTTP/2 对于状态码 200 的二进制编码是 10001000，只用了 1 字节就能表示，相比于 HTTP/1.1 节省了 2 个字节，如下图：

3. 并发传输

从上图可以看到，1 个 TCP 连接包含多个 Stream，Stream 里可以包含 1 个或多个 Message，Message 对应 HTTP/1 中的请求或响应，由 HTTP 头部和包体构成。Message 里包含一条或者多个 Frame，Frame 是 HTTP/2 最小单位，以二进制压缩格式存放 HTTP/1 中的内容（头部和包体）。

针对不同的 HTTP 请求用独一无二的 Stream ID 来区分，接收端可以通过 Stream ID 有序组装成 HTTP 消息，不同 Stream 的帧是可以乱序发送的，因此可以并发不同的 Stream ，也就是 HTTP/2 可以并行交错地发送请求和响应。

比如下图，服务端并行交错地发送了两个响应： Stream 1 和 Stream 3，这两个 Stream 都是跑在一个 TCP 连接上，客户端收到后，会根据相同的 Stream ID 有序组装成 HTTP 消息。

在这里插入图片描述

你可能会有疑问，1.1管道传输和2的并发传输有啥区别？

举例理解1.1管道传输和2的并发传输

1. HTTP/1.0（无管道化）

• 你点第一道菜（请求A）→ 服务员送到厨房 → 你坐着等 → 菜上桌（响应A）→ 你再点第二道菜（请求B）→ 等第二道菜（响应B）…
• 问题：必须等一道菜上完才能点下一道，效率极低。

2. HTTP/1.1 管道化（Pipelining）

• 你一次性说完：“我要菜A、菜B、菜C”（连续发送请求A、B、C）。
• 但厨房（服务器）必须按顺序做菜：先做完菜A → 上菜A → 再做菜B → 上菜B…
  • 如果菜A是一道慢炖牛肉（耗时很久），即使菜B是凉菜（立刻可上），也必须等牛肉炖好才能上凉菜。
• 本质：虽然你一口气点了所有菜，但上菜顺序必须固定，慢菜会阻塞后续所有菜。

3. HTTP/2 多路复用（Multiplexing）

• 你点菜时，厨房把每道菜拆成“步骤”（帧）：
  • 菜A：步骤1（切肉）→ 步骤2（炖煮）
  • 菜B：步骤1（拌沙拉）→ 步骤2（装盘）
• 厨房可以交叉处理：切肉（A1）→ 拌沙拉（B1）→ 装盘（B2）→ 炖煮（A2）。
  • 结果：凉菜（B）先上桌，不用等牛肉（A）炖完。
• 本质：请求和响应被拆成小块（帧），通过Stream ID标记归属，所有帧可以乱序处理，互不阻塞。

为什么管道化听起来像多路复用？

• 表面相似点：两者都允许客户端在等待响应时发送更多请求。
• 核心差异：
  • HTTP/1.1 管道化：响应必须排队（像单车道收费站，车可以连续进入，但出口必须按顺序）。
  • HTTP/2 多路复用：响应可超车（像多车道高速公路，每辆车有专属通道，互不干扰）。

如果我的内容对你有帮助，请辛苦动动您的手指为我点赞，评论，收藏。感谢大家!!