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 实现都共享这一表：
https://i-blog.csdnimg.cn/direct/23a3b8767ffd4c7db7c7a97b58a2bed1.png
[*]可以发现每一个字段都对应了一个 index，在压缩时，HPACK 会使用这个索引值来取代字段名，从而淘汰传输的字节数，效率是很客观的
[*]动态表（Dynamic Table）：
[*]动态表用来存储当前毗连中未出现在静态表的头部字段信息
[*]当该新的头部字段发送时会记载下来，当下一次使用到时就可以使用索引
3. 服务器推送（Server Push）
是的，服务器也能主动的给我们的客户端推送数据了。就好比下面的场景，当欣赏器哀求一个 HTML 页面时，大概这个页面还必要各种图片，css等数据。原来只能欣赏器主动的哀求，服务器才会被动的给我们。现在的话，服务器知道我们还缺什么，直接主动的推送给我们。
这样的话淘汰了客户端哀求的次数，提升了页面渲染的效率。
4. 并发传输数据（多路复用）
最紧张的特性来啦！但是在开始之前，我想先给大家接着列举餐馆的例子。让大家卑鄙的目的他的大致原理，这样大概就更能好好的明白。
HTTP / 2 开的餐馆，也可以同时接纳很多客人，但是为了照顾每一位客人的感受，克制等待太多的时间。他选择了交替的给每一桌上菜，这样后来的客人不要等着前面的吃完了才轮着他。
起首我们先明白 HTTP / 2 中新增的 stream 流 的概念，流使得同一个毗连可以同时并行处理多个哀求和响应，而不必等待某个哀求的处理完成才气开始下一个哀求。
一个流当中可以传输多个信息，一个信息由一个或多个帧组成，所以一个流中包含了多个帧。我们现在来看图说话：
https://i-blog.csdnimg.cn/direct/b3dcf7b1e1dc410ca0796d9f5cc5942e.png
这是 HTTP / 1.1，熟悉的队头壅闭。现在来看看 HTTP / 2，是如何解决的：
https://i-blog.csdnimg.cn/direct/221f7643f9a94c058bf7dbe812b9e5bb.png
差别的流可以交替的发送数据，因为每一个帧都会携带 stream 的 id，所以到客户端之后数据会组装成一个完整的 stream。
三、HTTP / 2 不足之处
1. TCP 队头壅闭问题
咦？HTTP / 2不是有用的解决了队头壅闭问题吗？是的，但是他解决的是响应队头壅闭问题，但是我这里说的是 TCP 队头壅闭，好比：
https://i-blog.csdnimg.cn/direct/488197e2ba104ce0babbf6530b072a49.png
TCP 协议，如果前面的数据丢了，后面的数据纵然到了也必要等待前面的数据停当。对于上层来说拿不到数据，不久壅闭了吗？所以说不管你上层怎么设计也离不开下层的坎儿。
HTTP / 3 会接纳 UDP 传输数据，就算是数据丢了也不会壅闭。但是回依靠其他技术实现可靠性。
2. 毗连创建时间斲丧
HTTP/2 依然基于 TCP 进行毗连创建，而 TCP 毗连的创建过程必要颠末三次握手。尽管 HTTP/2 允许在一个毗连中复用多个哀求，但每次新毗连的创建仍然必要一定的时间。
在客户端和服务器之间创建新毗连时，由于必要执行三次握手过程，毗连创建的耽误可能会影响 Web 页面的加载速度，尤其在必要频繁创建毗连的场景中。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]