HTTP / 2
序言
在之前的文章中我们介绍过了 HTTP/1.1 协议,现在再来认识一下迭代版本 2。了解比起 1.1 版本,后面的版本改进在哪里,特点在哪里?话不多说,开始吧⭐️!
一、 HTTP / 1.1 存在的问题
很多时候新的版本的产生都是需要解决老的版本存在的问题,HTTP / 1.1 存在的问题如下:
头部字段过大且重复
如果大家抓过包的话,就很能直观的感受这句话。HTTP / 1.1 的头部携带着数据量在有时候会很大,特别是 Cookies
和 User-Agent
的体量,让大家直观感受一下:
Cookie:
Hm_lvt_ab984c6961d35319708c19c75e093eee=1737127750; Hm_lpvt_ab984c6961d35319708c19c75e093eee=1737127750; HMACCOUNT=8DE7CD8295FF210E; UM_distinctid=19474e1e9808f-0fac1ea52408b5-4c657b58-190140-19474e1e9811325
User-Agent:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36 Edg/121.0.0.0
因为 HTTP 是无状态的,所以说每次传输数据的时候都需要带上,这就会造成报文体量的增加。
响应队头阻塞
HTTP / 1.1 为了提升速度,支持同时发送多个请求。但是不管你同时发多少请求,我都会优先处理先到达的,只有第一个请求响应处理完成之后才回去处理之后的请求。这样的话,如果第一个请求的数据特别大,那好,你后面的人全给我等着,这就是队头阻塞。
在这里列举一个餐馆的例子(来自于知乎,特别形象,理解这个就很好理解 HTTP 2 的并发是咋回事):一个餐厅同时可以容纳多个客人(请求),但是餐厅每次会将先来客人的菜上齐了才会取准备下一桌,如果前面一桌的才特别多,那后面的人只有干等着。
被动传输数据
在 HTTP / 1.1 中 只有客户端向服务器请求数据,服务器不能向客户端主动推送数据。如果一个页面需要渲染的内容很多,需要请求较多数据,只能客户端主动请求,服务器不能主动的推送。
二、 HTTP / 2 的新特性
1. 二进制格式传输数据
在 HTTP / 1.1 的协议是使用文本的格式传输数据,但在 HTTP / 2 采用了二进制的格式传输数据,这样提高了 数据处理效率 以及 数据传输效率。
数据处理效率,我们的机器本身只能识别并运算二进制的数据,使用文本传输的话还需要对数据进行解析机器才能够直接使用,但是使用二进制传输就省去了这一过程。
数据传输效率,就拿一个整数 123456
示例:
- 在文本中,需要使用
6
个字节表示 - 在二进制中,一个整数类型只需要
4
字节
这不就节约了传输成本,增加了传输效率吗。
在 HTTP / 1.1 中,我们的一个请求对应一个请求报文,一个响应对应一个响应报文,这是在应用层传输的基本单位。但是 HTTP / 2 的话就不一样了,传输的基本单位是一个 帧 (大小默认是 16 KB),当我们数据太大时会被分为多个帧。
2. 头部压缩(HPACK)
在 HTTP / 1.1 中,每个 HTTP 请求和响应都会携带头部数据,而这些头部数据大多数情况下是重复的。例如,许多请求和响应都会重复包含相同的字段,如 User-Agent、Host、Accept-Encoding 等。
HTTP / 2 使用了 HPACK (HEAD PACK 把头打包
)的方式来压缩头部信息:
- 静态表(Static Table):
- HPACK 使用一个静态表来存储常见的 HTTP 头部字段及其值(总共 61 条)。静态表的内容是固定的,所有 HTTP/2 实现都共享这一表:
- 可以发现每一个字段都对应了一个
index
,在压缩时,HPACK 会使用这个索引值来代替字段名,从而减少传输的字节数,效率是很客观的
- 动态表(Dynamic Table):
- 动态表用来存储当前连接中未出现在静态表的头部字段信息
- 当该新的头部字段发送时会记录下来,当下一次使用到时就可以使用索引
3. 服务器推送(Server Push)
是的,服务器也能主动的给我们的客户端推送数据了。就比如下面的场景,当浏览器请求一个 HTML 页面时,也许这个页面还需要各种图片,css等数据。原来只能浏览器主动的请求,服务器才会被动的给我们。现在的话,服务器知道我们还缺什么,直接主动的推送给我们。
这样的话减少了客户端请求的次数,提升了页面渲染的效率。
4. 并发传输数据(多路复用)
最重要的特性来啦!但是在开始之前,我想先给大家接着列举餐馆的例子。让大家粗俗的目标他的大致原理,这样也许就更能好好的理解。
HTTP / 2 开的餐馆,也可以同时接纳许多客人,但是为了照顾每一位客人的感受,避免等待太多的时间。他选择了交替的给每一桌上菜,这样后来的客人不要等着前面的吃完了才轮着他。
首先我们先理解 HTTP / 2 中新增的 stream 流 的概念,流使得同一个连接可以同时并行处理多个请求和响应,而不必等待某个请求的处理完成才能开始下一个请求。
一个流当中可以传输多个信息,一个信息由一个或多个帧组成,所以一个流中包含了多个帧。我们现在来看图说话:
这是 HTTP / 1.1,熟悉的队头阻塞。现在来看看 HTTP / 2,是如何解决的:
不同的流可以交替的发送数据,因为每一个帧都会携带 stream 的 id,所以到客户端之后数据会组装成一个完整的 stream。
三、HTTP / 2 不足之处
1. TCP 队头阻塞问题
咦?HTTP / 2不是有效的解决了队头阻塞问题吗?是的,但是他解决的是响应队头阻塞问题,但是我这里说的是 TCP 队头阻塞,比如:
TCP 协议,如果前面的数据丢了,后面的数据即使到了也需要等待前面的数据就绪。对于上层来说拿不到数据,不久阻塞了吗?所以说不管你上层怎么设计也离不开下层的坎儿。
HTTP / 3 会采用 UDP 传输数据,就算是数据丢了也不会阻塞。但是回依靠其他技术实现可靠性。
2. 连接建立时间消耗
HTTP/2 依然基于 TCP 进行连接建立,而 TCP 连接的建立过程需要经过三次握手。尽管 HTTP/2 允许在一个连接中复用多个请求,但每次新连接的建立仍然需要一定的时间。
在客户端和服务器之间建立新连接时,由于需要执行三次握手过程,连接建立的延迟可能会影响 Web 页面的加载速度,尤其在需要频繁建立连接的场景中。