HTTP1.1与HTTP2的区别_HTTP1.1与HTTP2有哪些区别-电脑知识-PHP中文网

http/2通过多路复用在单个tcp连接上并行传输多个独立的数据流，每个流的数据被分割为带流id的二进制帧并交错发送，接收方根据流id重新组装，从而避免了http/1.1中因单个请求阻塞导致后续请求等待的队头阻塞问题；2. hpack头部压缩通过静态字典、动态字典和哈夫曼编码减少重复头部信息的传输量，显著降低冗余数据，提升传输效率；3. 服务器推送允许服务器在客户端请求html后主动推送其依赖的css、js等资源，减少往返延迟，适用于首屏关键资源的预加载，但需结合缓存策略避免推送冗余内容。

HTTP1.1与HTTP2的区别_HTTP1.1与HTTP2有哪些区别

HTTP/2协议相较于HTTP/1.1，核心差异在于它通过多路复用、二进制分帧、头部压缩和服务器推送等机制，显著提升了数据传输效率和网页加载速度，解决了HTTP/1.1中存在的队头阻塞、冗余头部信息和请求响应串行化等痛点。它并非是对HTTP协议的彻底颠覆，更像是对现有HTTP语义和方法的底层传输优化。

解决方案

回想当年，我们还在为HTTP/1.1的性能瓶颈挠头，尤其是那些复杂的单页应用，一个页面动辄几十上百个请求，每个请求都得单独建立TCP连接或者复用连接但依然串行，那种等待感，简直是折磨。HTTP/2的出现，在我看来，就是一次对症下药的革命，它从底层传输机制上做了大刀阔斧的改进。

首先，最让我感到震撼的，是它的多路复用（Multiplexing）能力。在HTTP/1.1时代，你一个浏览器标签页打开一个网站，如果需要加载多个资源，通常会开好几个TCP连接，或者在一个连接上顺序地发送请求、接收响应。这就导致了所谓的“队头阻塞”——前面一个请求没完成，后面即便准备好了也得等着。HTTP/2则完全不同，它允许在单个TCP连接上同时发送多个请求和响应，并且这些数据流是完全独立的。这就像把一条单车道拓宽成了多车道高速公路，车辆（数据帧）可以并行通过，效率自然不可同日而语。

其次，二进制分帧（Binary Framing）是HTTP/2的基石。HTTP/1.1是基于文本的协议，解析起来相对简单直接，但效率不高。HTTP/2则将所有传输的信息分割成更小的、独立的二进制帧，包括头部帧和数据帧。这使得协议的解析和处理更为高效，机器理解起来也更方便，减少了出错的可能性。这种底层二进制的封装，也为后续的多路复用、优先级控制等高级特性打下了基础。

再来说说头部压缩（Header Compression，尤其是HPACK）。HTTP/1.1中，每个请求和响应都会携带大量重复的头部信息，比如User-Agent、Accept等，这些信息在多次请求中几乎不变，却每次都要完整传输，无形中增加了数据量。HTTP/2引入了HPACK算法，它维护了一个静态表和一个动态表，并结合哈夫曼编码，对头部信息进行压缩。简单来说，就是把重复的头部信息只传输一次，后续的请求只发送索引或差异部分。这在移动端网络环境下，尤其能感受到它的好处，带宽占用瞬间小了一截。

还有个非常酷的特性是服务器推送（Server Push）。在HTTP/1.1里，客户端请求一个HTML页面，服务器响应后，客户端解析HTML发现还需要CSS、JS、图片等资源，再一个个去请求。HTTP/2则允许服务器在客户端尚未请求某个资源时，就主动将它“推送”给客户端。比如，你请求了

index.html

登录后复制

，服务器知道这个HTML肯定需要

style.css

登录后复制

和

script.js

登录后复制

，它就可以在发送

index.html

登录后复制

的同时，把这两个文件也一并推过去。这样就省去了客户端再次请求的往返时间，大大加快了首屏加载速度。

最后，HTTP/2还支持请求优先级（Request Prioritization）和流量控制（Flow Control）。客户端可以告诉服务器，哪些请求更重要，哪些可以稍后处理，服务器就能据此调整资源分配和发送顺序。流量控制则确保了发送方不会压垮接收方，避免了不必要的丢包和重传。这些都是HTTP/1.1所不具备的精细化管理能力。

HTTP/2的多路复用是如何解决HTTP/1.1队头阻塞问题的？

队头阻塞（Head-of-Line Blocking，HOL Blocking）是HTTP/1.1长期以来的一个痛点，它指的是在单个TCP连接上，如果第一个请求（或者说第一个响应片段）因为网络或其他原因被阻塞，那么后续的所有请求即使已经准备就绪，也必须等待前一个请求完成才能发送或接收。这就像一条单行道，前面一辆车抛锚了，后面所有车都得停下来。

HTTP/2通过引入流（Stream）和帧（Frame）的概念，彻底解决了这个问题。在HTTP/2中，所有的通信都在一个TCP连接上进行，但这个连接被划分为多个独立的、双向的“流”。每个流都有一个唯一的ID，代表着一个独立的请求-响应交换。数据在这些流之间以二进制帧的形式交错传输。

具体来说，当客户端发起多个请求时，每个请求都被分配到一个新的流ID。这些请求的数据（以及它们的响应数据）被分解成小的二进制帧，并打上对应的流ID。这些帧可以在同一个TCP连接上乱序发送，因为它们各自携带了流ID，接收方可以根据ID将属于同一个流的帧重新组装起来。

稿定AI社区

在线AI创意灵感社区

查看详情

举个例子，假设你需要加载

a.js

登录后复制

、

b.css

登录后复制

和

c.png

登录后复制

。在HTTP/1.1中，你可能需要等待

a.js

登录后复制

完全传输完才能开始传输

b.css

登录后复制

。但在HTTP/2中，

a.js

登录后复制

、

b.css

登录后复制

、

c.png

登录后复制

的帧可以交错发送。即使

a.js

登录后复制

的某个帧因为网络原因延迟了，

b.css

登录后复制

和

c.png

登录后复制

的帧依然可以继续传输，不会被阻塞。服务器和客户端都能并行处理多个流上的数据，从而消除了队头阻塞，显著提升了页面加载速度和用户体验。这感觉就像是把单行道改造成了多车道立交桥，每个方向的车都能同时通行，效率自然就上去了。

HTTP/2的头部压缩（HPACK）为何能显著提升性能？

HTTP/2的头部压缩，也就是HPACK，在我看来，是对网络传输效率的一次精妙优化。它之所以能显著提升性能，是因为它直接瞄准了HTTP/1.1中一个非常普遍但又容易被忽视的效率杀手：重复的请求和响应头部。

在HTTP/1.1中，每次客户端发起请求，或者服务器返回响应，都会带上一大堆头部信息，比如

User-Agent

登录后复制

（浏览器类型）、

Accept

登录后复制

（接受的文件类型）、

Cookie

登录后复制

、

Referer

登录后复制

等等。这些头部信息，尤其是在一个页面需要加载几十上百个资源时，很多都是重复的。想象一下，每次下载一个图片，都要把浏览器型号、接受语言这些信息再发一遍，累积起来，这部分冗余的数据量其实相当可观，尤其是在移动网络这种带宽受限的环境下，简直是浪费。

HPACK算法的聪明之处在于它引入了几个核心机制：

静态字典（Static Table）：预定义了一些常用的HTTP头部字段和值，比如
```
GET
```
登录后复制
、
```
/
```
登录后复制
、
```
200 OK
```
登录后复制
等。这些字段和值都有一个对应的索引号。传输时，直接发送索引号就行，比发送完整字符串要小得多。
动态字典（Dynamic Table）：客户端和服务器在通信过程中，会动态地维护一个字典。如果传输了一个新的、不常见的头部字段或值，它会被添加到这个动态字典中，并分配一个索引号。后续再遇到相同的字段或值，就可以直接引用这个索引。
哈夫曼编码（Huffman Encoding）：对于那些既不在静态字典也不在动态字典中的字符串，HPACK还会使用哈夫曼编码进行进一步压缩，减少其二进制表示的长度。

这套组合拳下来，效果是立竿见影的。原来可能需要几十上百字节的头部，现在可能只需要几个字节的索引号就能表示。特别是在大量小请求的场景下，比如加载几十个小图标、字体文件，头部信息占总数据量的比例会非常高，HPACK的压缩效果就显得尤为突出。它直接减少了传输的数据量，从而降低了网络延迟，提升了整体的加载速度。这不仅仅是带宽上的节省，更是对往返时间（RTT）的有效优化，因为数据包变小了，传输更快了。