N 001 了解HTTP2

Posted 2021-07-23 CS阿吉

本文目录如下：

---

引子：HTTP/2 是什么？如何使用 HTTP2？HTTP/2 出现的原因是什么？或者说，解决了 HTTP/1 的什么不足？他相对于 HTTP/1 做了哪些改进？HTTP/2有哪些不足？如何去解决？

---

0. 历史

Google 推动 Chrome 浏览器使用自己发明的 SPDY 协议，迫使 IETF 组织以 SPDY 为基础，经过改善，2015 年推出 HTTP/2 标准。

1. 定义

HTTP/2 is a newish protocol for transporting data that will drastically speed up the web and can help your SEO.HTTP/2 offers a dramatic speed boost as the line can be kept open and a lot of stuff can be sent at once.

HTTP / 2 是一种用于传输数据的新颖协议，可以大大加快网络速度并为您的 SEO 提供帮助。HTTP / 2 极大地提高了速度，因为可以保持线路畅通并且可以一次发送很多内容。

HTTP/2 先使用 HTTP/1 请求报文发送一个 24 字节的“连接前言”字符串『PRI』，服务器收到该字符串后，后续传输会使用 HTTP/2 的数据格式。

PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n

h2: 加密的 HTTP2 h2c: 明文的 HTTP2

2. 出现原因

『改进性能』

2-1. 文本解析

HTTP/1 、 HTTP/1.1 解析采用文本格式(可见的 ASCI 码)，其缺陷是健壮性不好，容易出现多义性，占用空间大。好处是方便阅读。

HTTP/1.1 采用文本格式传输数据，文本格式转为 ASCII 码，且只能按照语义以行为单位进行切割, 依旧是"Header + Body"形式的报文。

例子：类比 从文件存储角度看，文本存储按照字节 3.1415926 一个字符占用一个字节，共 9 字节。二进制存储按照数据类型，浮点数，占用 4 字节。

2-2. 长连接

HTTP/1 性能不高, 依旧依赖『长连接』，会存在 HTTP 层面和 TCP 层面的队头阻塞(HLO, Head-of-line blocking)。

HTTP 层面的队头阻塞定义：HTTP/1 规定，若干个请求排队串行化单线程处理，后面的请求等待前面请求的响应返回才能执行，一旦有某请求超时等，后续请求只能被阻塞。即有序请求，按序响应。

HTTP 层面的队头阻塞原因：这是因为 HTTP/1.1 采用 "请求-应答"模型，其规定报文必须"一收一发"。即为了知道当前响应属于哪个请求，只能有序请求、按序响应。有点类似于 Promise.all()。其实 HTTP/1.1 也可以考虑给报文标序号和连接号，但标准未采用此方案。

2-3. 冗余 header 字段

在 HTTP/1.1 中，header 字段未被压缩。随着网页内的请求数增长到需要数十到数百个请求的时候，这些请求中的冗余 header 字段不必要地消耗了带宽，从而显着增加了延迟。

2-4. 请求-响应 模式

请求啥响应啥，不灵活。

HTTP/1.1 采用文本格式传输数据，文本格式转为 ASCII 码，且只能按照语义以行为单位进行切割，

A well-designed format is dictated by what makes the information the easiest for the intended audience to understand.

文本格式最常见的是 JSON 和 XML,Content-Type:application/json, application/xml。application/x-www-form-urlencoded 表单默认提交数据格式

“队头阻塞”与短连接和长连接无关，而是由 HTTP 基本的“请求 - 应答”模型所导致的。因为 HTTP 规定报文必须是“一发一收”，这就形成了一个先进先出的“串行”队列。队列里的请求没有轻重缓急的优先级，只有入队的先后顺序，排在最前面的请求被最优先处理。

解决：并发连接，域名分片 “Connection: keep-alive

HTTP/1 里可以用头字段“Content-Encoding”指定 Body 的编码方式，比如用 gzip 压缩来节约带宽

3. 改进点

在 HTTP/2 中，请求和响应标头字段的定义保持不变，仅有一些微小的差异：所有标头字段名称均为小写，请求行现在拆分成各个 :method、:scheme、:authority 和 :path 伪标头字段。

3-1. 二进制格式

HTTP/2 的协议解析采用二进制格式，方便计算机解析、健壮性好。

将 "Header + Body" 拆分为二进制“帧”, 报头只有 9 字节, 用“HEADERS”帧存放头数据、“DATA”帧存放实体数据。

帧大小通常不超过 16K, 最大是 16M。

拆分成『碎片化』的流，可以进行多路复用。

3-2. 多路复用

多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行。

使用二进制帧的双向传输序列 即流，同一个消息往返的帧会分配一个唯一的流 ID。这样子乱序收发的帧, 使得多个请求-响应之间没有了顺序关系，根据流 ID 分配到对应的请求，根据帧序号组装出完整响应。

多路复用改变了 "请求-应答" 的工作模式，服务器可以新建流主动向客户端发送消息。

3-3. 头部压缩：

使用HPACK 算法, 将 header 字段 在客户端和服务端各自维护一个字典, 又称 Header Fields 表 (即 索引-header 字段, )，发送中用索引号表示重复的字符串，避免了 Header 字段反复发送。且釆用哈夫曼编码来压缩整数和字符串。

Header Field：一个名称/值 name-value 对。名称和值都被视为八位字节的不透明序列。

HTTP/2 提倡使用尽可能少的连接数，头部压缩是其中一个重要的原因：在同一个连接上产生的请求和响应越多，动态字典累积的越全，头部压缩的效果就越好。

动态字典上下文有关，需要为每个 HTTP/2 连接维护不同的字典。

HPACK 详解

3-3-1. 设计思想

简单，不灵活

3-3-2. 优点

消除了多余的 header 字段，将漏洞限制到已知的安全攻击，并且在受限的环境中具有有限的内存需求。

3-3-3. 缺点

潜在安全问题:

(1)将压缩用作基于长度的预测，以验证有关被压缩到共享压缩上下文中的加密的猜想。

(2)由于耗尽解码器的处理或存储容量而导致的拒绝服务。

3-3-4. 原理

HPACK 算法会保留 header 列表内 header 字段的顺序, 釆用哈夫曼编码, 生成 索引号-header 字段 的表，其键值均为八位字节的不透明序列。

编码器执行插入操作，解码器执行更新操作。

3-3-5. 表分类

（1）静态表(Static Table)

静态表包含一个预定义且不可更改的 header 字段列表。

将经常出现的 header 字段与索引值静态关联的表。该表是有序的，只读的，始终可访问的，并且可以在所有编码或解码上下文之间共享。

静态表是根据流行网站使用的最频繁的 header 字段创建的，并添加了 HTTP/2 特定的伪 header 字段。对于具有一些频繁值的 header 字段，为每个这些频繁值添加了一个条目。对于其他标题字段，添加了带有空值的条目。

（2）动态表(Dynamic Table)

将存储的 header 字段与索引值相关联的表。

动态表包含以先进先出的顺序维护的 header 字段列表。动态表中的第一个条目和最新条目在最低索引处，而动态表的最旧条目在最高索引处。

3-3-5. 更新表

没有定义扩展机制, 只能通过定义完整的替换来更新。

3-4. 服务器推送：

例：在浏览器请求 html 文件时，服务器把其可能用到的 css、js 发送给客户端，减少等待延迟。

多路复用改变了 "请求-应答" 的工作模式，服务器可以新建流主动向客户端发送消息。

静态资源通过该方式可以提升速度，节省客户端请求开销。

4. 好处

(1). 提高连接的利用率

(2). 增强了安全性，要求至少使用 TLS1.2

(3). 有利于 SEO

网站速度是 SEO 的重要因素

5. 缺点

不能解决传输层的队头阻塞。

6. 解决方案

改变传输层协议，例如 QUIC。