关于http:HTTP-HTTP2-知识点

在《图解 HTTP》的读书笔记《图解 HTTP》- HTTP 协定历史倒退（重点）当中介绍了一部分对于 HTTP/ 2 的内容，然而内容比拟简短没有过多深刻，本文对于 HTTP/2 协定做一个更深刻的介绍。

HTTP1.X 有两个次要的毛病：平安有余 和性能不高。

所谓平安有余，是指 HTTP1.X 大部分时候应用了 明文传输，所以很多时候黑客能够通过抓包报文的形式对于网络数据进行监控和尝试破解，为了平安传输数据，HTTP 通常和 TLS 组合实现网络安全连贯。

性能不高则指的是 HTTP 在申请传输中会传输大量的反复字段，Body 的数据能够通过 GZIP 进行压缩。这达到了能够勉强承受传输效率，然而 Header 头部字段仍旧十分臃肿和低效，并且 HTTP1.X 后续也没无效的头部压缩伎俩，HTTP/2 借用了 哈夫曼编码 对于 Header 进行高效压缩，进步传输效率。

除了下面的问题，HTTP1.X 中最大的问题是 队头阻塞，HTTP1.X 中浏览器对于同一域名的并发连贯拜访此时是无限的，所以经常会导致只有个位数的连贯能够失常工作，后续的连贯都会被阻塞。

HTTP/2 解决队头阻塞是以 HTTP1.X 管道化的为根底拓展，它应用了二进制流和帧概念解决应用层队头阻塞。应用层的阻塞被解决便是实现流 并发传输。

为了管制资源的资源的获取程序，HTTP 在并发传输的根底上实现 申请优先级 以及 流量管制，流的流量管制是思考接管方是否具备承受能力。

在发送方存在 WINDOWS 流量窗口，而接管方能够通过一个叫做 WINDOW_UPDATE 帧限度发送方的传输长度。

要了解 HTTP/ 2 的细节须要有一个宏观的概念：为了提高效率，HTTP/ 2 整体都在向着 TCP 协定贴近。

以上就是对于 HTTP/ 2 降级的含糊了解，HTTP/2 的改良从整体上分为上面几个局部：

兼容 HTTP1.X
应用层队头阻塞解决
并发传输
多路复用
二进制帧
服务器推送
HPACK/ 头部压缩
申请优先级
补充
- 连贯前言
- 流和管道化关系
- 申请头字段束缚

HTTP 和 TLS 协定一样背着微小的历史包袱，所以不能在结构上做出过多的改变，HTTP/ 2 为了进行推广也必须要进行前后兼容，而兼容 HTTP1.X 则疏导出上面三个点：

HTTP 协定头平滑过渡
应用层协定扭转
根本传输格局的保障

HTTP 协定头平滑过渡

所谓的平滑过渡指的是协定头的辨认仍然是 HTTP 结尾，不论是 HTTP1 还是 HTTP/2，甚至是 HTTP3，都将会沿用 http 结尾的协定名进行向后兼容。

应用层协定扭转

HTTP/ 2 只扭转了应用层并没有扭转 TCP 层和 IP 层，所以数据仍然是通过 TCP 报文的形式进行传输，通样通过 TCP 握手和 HTTP 握手实现。

根本传输格局的保障

HTTP1.X 中的申请报文格式如下，联合来说申请报文能够总结为上面的格局：

申请行
申请首部字段和其余字段
空行
申请负载

HTTP 尽管把外部的格局大变样，然而申请报文的构造总体是没有变的。

HTTP/ 2 是“事实上的平安协定”，HTTP/ 2 尽管并没有强制应用 SSL 平安传输，然而许多浏支流浏览器曾经不反对非 HTTPS 进行 HTTP2 申请，同时能够发现很多实现了 HTTP/ 2 的网站根本都是都是具备 HTTPS 平安传输条件的。

因为 HTTP/ 2 要比 TLS1.3 早出几年，HTTP/ 2 推广加密版本的 HTTP/2 在平安方面做了强化，要求上层的通信协议必须是 TLS1.2 以上，并且此时 TLS1.2 很多加密算法曾经被证实存在安全隐患（比方 DES、RC4、CBC、SHA- 1 不可用），所以应用 HTTP/ 2 被要求保障前向平安，更像是TLS1.25。

因为 TLS1.3 要比 HTTP/ 2 要晚几年才出台，而 HTTP/ 2 呈现的时候 TLS 很多加密套件早曾经没法应用了，所以 HTTP/ 2 应用的 TLS1.2 加密套件是带椭圆曲线函数的TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。

HTTP/ 2 协定还对加密和不加密的报文进行划分，HTTP/2 定义了字符串标识标识明文和非明文传输，“h2”示意加密的 HTTP/2，“h2c”示意明文的 HTTP/2，这个 c 示意 ”clear text”。

从 HTTP1.X 到 HTTPS 以及 HTTP/ 2 的协定栈变动图能够看到整个应用层协定尽管构造上没有过多调整，然而内容呈现了翻天覆地的变动，实现细节也更加简单。

尽管 HTTP/ 2 的“语法”简单了很多，然而“语义”自身是没有变动的，用 HTTP1.X 的一些思路形象了解 HTTP/ 2 的构造定义是实用的。

二进制帧是 HTTP/ 2 的“语法”变动，HTTP/ 2 的传输格局由明文转为了二进制格局，属于向 TCP/IP 协定“聚拢”，能够通过位运算提高效率。

二进制的格局尽管对于人浏览了解不是很敌对，然而对于机器来说却刚好相同，实际上二进制传输反倒要比明文传输省事多了，因为二进制只有 0 和 1 相对不会造成解析上的歧义，也不会因为编码问题须要额定转译。

二进制帧保留 Header+Body 传输构造，然而打散了外部的传输格局，把内容拆分为二进制帧的格局，HTTP/ 2 把报文的根本传输单位叫做帧，而帧分为两个大类 HEADERS（首部） 和 DATA（音讯负载），一个音讯划分为两类帧传输同时采纳二进制编码。

这种做法相似 Chunked 化整数据的形式，把 Header+body 等同的帧数据，同时外部通过类型判断进行标记。

这里能够举个简略例子，比方常见的状态码 200，用文本数据传输须要 3 个字节（二进制：00110010 00110000 00110000），而用 HTTP/ 2 的二进制只须要 1 个字节（10001000）

HTTP/ 2 的数据传输根本单位（最小单位）是帧，帧构造如下：

留神这里的单位是 bit 不是 byte，头部实际上占用的字节数非常少，一共加起来也就 9 个字节大小。其中 3 个字节的长度示意长度，帧长度前面示意 帧类型 ，HTTP/ 2 定义了多大 10 种类型帧，次要分为 数据帧 和管制帧：

帧类型前面接着标记位，标记位用于携带一些管制信息，比方上面：

END_HEADERS：示意头数据完结标记，相当于 HTTP1.X 外头后的空行“\r\n”。
END_Stream：示意单方向数据发送完结，后续不会再有数据帧。
PRIORITY：示意流的优先级。

最初是 31 位的流标识符以及 1 个最高位保留不必的数据，流标识符的最大值是 2^31，大概是 21 亿大小，此标记位的次要作用是标识该 Frame 属于哪个 Stream，乱序传输中依据这部分乱序的帧流标识符号找到雷同的 Stream Id 进行传输。

RFC 文档定义：
Streams are identified with an unsigned 31-bit integer. Streams initiated by a client MUST use odd-numbered stream identifiers; those initiated by the server MUST use even-numbered stream identifiers.

最初是帧数据，这部分为了进步利用效率应用了 HPACK 算法 压缩的头部和理论数据。

实际上 SPDY 晚期的计划也是应用 GZIP 压缩，只不过CRIME 压缩破绽 攻打之后才专门钻研出 HPACK 算法它避免压缩破绽攻打。

外围概念：

流是二进制帧的双向传输序列。
一个 HTTP/2 的流就等同于一个 HTTP/1 里的“申请 – 应答”。
HTTPP2 的流特点
- 一个 TCP 复用多个“申请响应”，反对并发传输
- 流和流之间独立，然而外部通过 StreamId 保障程序。
- 流能够进行申请优先级设置
- 流 ID 不容许反复
- 0 号流是用于流量管制的管制帧
  ….

了解多路复用咱们须要先理解二进制帧，因为流的概念在 HTTP/ 2 中其实是 不存在 的，HTTP/ 2 探讨的流是基于二进制帧的数据传输模式的考量。流是二进制帧的双向传输序列。

咱们这里再温习一遍二进制帧的构造，外面的 流标识符 就是流 ID。

通过抓包能够看到 HTTPS2 很多时候会呈现流被拆分的状况，比方上面的 Headers 就传输了 3 个流，把这些帧进行编号并且排队之后进行传输就转化为流传输：

一个 HTTP/2 的流就等同于一个 HTTP/1 里的“申请 – 应答”，而在 HTTP1 外面，它示意一次报文的“申请响应”，所以 HTTP1 和 HTTP/ 2 在这一点上概念是一样的。

不过依照 TCP/IP 的五层传输模型来看，其实 TCP 的连贯概念也是虚构的，它须要依赖 IP 运输和 MAC 地址寻址，然而从性能上来说它们都是实实在在的实现传输动作，所以不须要纠结流虚构还是不虚构的概念，咱们间接把他当成理论存在的更容易好了解。

HTTP/2 的流的次要有上面的特点：

HTTP/ 2 遵循一个 TCP 上复用多个“申请 – 应答”，意味着一个 HTTP/2 连贯上能够同时收回多个流传输数据，并且流能够并发传输实现“多路复用”；
客户端和服务器都能够创立流，并且互不烦扰；
HTTP/ 2 反对服务端推送，流能够从客户端或者服务端登程；
流外部的帧是有严格程序的，然而流之间相互独立；
流能够设置优先级，让服务器优先解决特定资源，比方先传 HTML/CSS，后传图片，优化用户体验；
流 ID 不能重用 ，只能程序递增，客户端发动的 Stream ID 是奇数，服务器端发动的 Stream ID 是偶数；
在流上发送“RST_STREAM”帧能够随时终止流，勾销流的接管或发送；
第 0 号流比拟非凡，它 不能敞开，也不能发送数据帧 ，只能发送 管制帧，用于流量管制。

从下面特点那中咱们还能够发现一些细节。

默认长连贯

比方第一条能够推理出 HTTP/ 2 遵循的申请跑在一个 TCP 连贯上，而多个申请的并发传输跑在一个 TCP 连贯的前提是 连贯有绝对长时间占用 ，也就是说 HTTP/2 在一个连贯上应用多个流收发数据自身默认就会是 长连贯，所以永远不须要“Connection”头字段（keepalive 或 close）。

RST_STREAM 帧 的常见利用是大文件中断重传，在 HTTP/1 里只能断开 TCP 连贯从新“三次握手”在进行申请重连，这样解决的老本很高，而在 HTTP/2 里就能够简略地发送一个“RST_STREAM”中断流即可进行暂停，此时长连贯会 持续放弃。

流标识符不是有限的，如果 ID 递增到耗尽，此时能够发送管制帧“GOAWAY”，真正敞开 TCP 连贯。

因为流的双向传输的，HTTP/ 2 应用了奇数和偶数划分申请起源方向，奇数为客户端发送的帧，而偶数为服务端发送的帧，客户端在一个连贯最多收回 2^30 申请，大概为 10 亿个。

既然 RST_STREAM 帧 能够扭转整个流的传输状态，那么意味着 HTTP/ 2 的流是存在状态帧的概念的，翻阅 RFC 文档果然发现了状态机的图，从上面的能够看到比较复杂。咱们重点关注四个状态：

idle
open
half closed

closed

是不是感觉有点相熟？没错这和 TCP 层的连贯握手状态其实是有不少相似性的，从这里也能够看出 HTTP/ 2 的整个指定理念是贴近 TCP 协定层。

       +--------+
                  send PP |        | recv PP
                 ,--------|  idle  |--------.
                /         |        |         \
               v          +--------+          v
        +----------+          |           +----------+
        |          |          | send H /  |          |
 ,------| reserved |          | recv H    | reserved |------.
 |      | (local)  |          |           | (remote) |      |
 |      +----------+          v           +----------+      |
 |          |             +--------+             |          |
 |          |     recv ES |        | send ES     |          |
 |   send H |     ,-------|  open  |-------.     | recv H   |
 |          |    /        |        |        \    |          |
 |          v   v         +--------+         v   v          |
 |      +----------+          |           +----------+      |
 |      |   half   |          |           |   half   |      |
 |      |  closed  |          | send R /  |  closed  |      |
 |      | (remote) |          | recv R    | (local)  |      |
 |      +----------+          |           +----------+      |
 |           |                |                 |           |
 |           | send ES /      |       recv ES / |           |
 |           | send R /       v        send R / |           |
 |           | recv R     +--------+   recv R   |           |
 | send R /  `----------->|        |<-----------'  send R / |
 | recv R                 | closed |               recv R   |
 `----------------------->|        |<----------------------'
                          +--------+

    send:   endpoint sends this frame
    recv:   endpoint receives this frame

    H:  HEADERS frame (with implied CONTINUATIONs)
    PP: PUSH_PROMISE frame (with implied CONTINUATIONs)
    ES: END_STREAM flag
    R:  RST_STREAM frame

Note that this diagram shows stream state transitions and the frames
and flags that affect those transitions only. In this regard,
CONTINUATION frames do not result in state transitions; they are
effectively part of the HEADERS or PUSH_PROMISE that they follow.

无关流状态转化的细节都在 RFC 的文档中，链接如下：
：https://datatracker.ietf.org/doc/html/rfc7540#section-5.1，下面的图了解起来比拟吃力，咱们先看一个极简格调的图：

当连贯没有开始的时候，所有流都是闲暇状态，此时的状态能够了解为“不存在待调配”。客户端发送 HEADERS帧之后，流就会进入 ”open” 状态，此时双端都能够收发数据，发送数据之后客户端发送一个带“END_STREAM”标记位的帧，流就进入了“半敞开”状态。响应数据也须要发送 END_STREAM 帧，示意本人曾经承受完所有数据，此时也进入到“半敞开”状态。如果申请流 ID 耗尽，此时就能够发送一个 GOAWAY 齐全断开 TCP 连贯，从新建设 TCP 握手。

以上就是一个简略的流交互过程。

idel：Sending or receiving a HEADERS frame causes the stream to become “open”.
END_STREAM flag causes the stream state to become “half-closed

  (local)"; an endpoint receiving an END_STREAM flag causes the
  stream state to become "half-closed (remote)".

并发传输是依附流的多路复用实现的，依据下面的内容咱们晓得 Stream 能够并行在一个 TCP 连贯上，每一个 Stream 就是一次申请响应，HTTP/ 2 在并发传输中设置了上面几个概念：

Stream
Message
Frame

这三者的关系如下

HTTP1.X 的头部压缩能够总结出上面几个毛病：

ASCII 编码明文传输尽管容易浏览，然而传输效率低。
大量反复的申请和响应头部字段耗费无用网络传输带宽。
申请负载能够应用 GZIP 压缩然而申请头部字段不足无效的压缩伎俩。

综上所述 HTTP/ 2 为什么要引入头部压缩？次要的起因是 HTTP1.X 中所有的内容都是明文传输的，而很多状况下对于轮询申请和频繁调用的接口，常常须要传输反复申请头部，而随着网络传输报文越来越简单，累赘的申请头部优化亟待优化。

头部压缩能够带来多少效率晋升，官网的答案是至多 50%，反复字段越多优化越发显著，具体能够看 Patrick McManus 对于头部压缩的性能晋升的提倡探讨：# In Defense of Header Compresson

HTTP/2 头部压缩是基于 HPACK 算法实现的，次要通过三个技术点实现：

动态表：外部预约义了 61 个 Header 的 K /V 数值
动静表：利用动静表存储不在动态表的字段，从 62 开始进行索引，次要存储一些动态变化的申请头部。
哈夫曼（霍夫曼、赫夫曼）编码：一种高效数据压缩的数据结构，被广泛应用在计算机的各个领域。

了解这几个概念作为初学能够简略了解设计思路是借用了 DNS 查表的形式，在 HTTP 连贯的双端构建缓存表，对于传输反复字段采纳缓存到表外面的形式进行代替。

动态表蕴含了一下根本不会呈现变动的字段，动态表设计固定 61 个字段，这些字段都是申请中高频呈现的字段，比方申请办法，资源门路，申请状态等等。

那么这个 Index 是什么意思？这个相似于数组定位，index 标识索引，在传输的过程中固定的字段用固定的索引标识和传输，header name 标识申请头的名称，而 Header Value 则示意内容。

上面的内容来摘自小林的博客，咱们来看一下动态表是如何存储申请头部字段的。

留神 Value 字段是动态变化的，Value 设置之前都须要进行哈夫曼编码，编码之后通常具备 50% 左右的字节占用缩小，比方高亮局部是 server 头部字段，只用了 8 个字节来示意 server 头部数据。

RFC 中规定，如果头部字段属于动态表范畴并且 如果 Value 是变动的，那么它的 HTTP/2 头部前 2 位固定为 01。

通过抓包理解 server 在 HTTP 的格局：

server: nghttpx\r\n
哈夫曼编码之后：server: 01110110

算上冒号空格和开端的 \r\n，共占用了 17 字节，而应用了动态表和 Huffman 编码，能够将它压缩成 8 字节，压缩率大略 47 %。

下面的 server的值是如何定义的，首先通过 index 找到 server字段的序列号为 54，二进制为110110，同时它的 Value 是变动的，所以是01 结尾，最初组成01110110。

接着是 Value 局部，依据上文 RFC 哈夫曼编码的规定，首个比特位是用来标记是否哈夫曼编码的，所以跳过字节首位，前面的 7 位才是真正用于标识 Value 的长度，10000110，它的首位比特位为 1 就代表 Value 字符串是通过 Huffman 编码的，通过 Huffman 编码的 Value 长度为 6。

整个进化后果就是，字符串 nghttpx 转为二进制之后，而后通过 Huffman 编码后压缩成了 6 个字节。 哈夫曼的核心思想就是把高频呈现的“单词”用尽可能最短的编码进行存储，比方 nghttpx 对应的哈夫曼编码表如下：

一共是六个字节的数据，从二进制通过查表的后果如下：

server 头部的二进制数据对应的动态头部格局如下：

留神 \r\n 是不须要二进制编码的。01 示意变动的动态表字段。

动态表蕴含了固定字段然而值不肯定固定的表，而动静表则用存储动态表中不存在的字段，动静表从索引号 62 开始，编码的时候会随时进行更新。

比方第一次发送 user-agent 字段，值通过哈夫曼编码之后传输给接管方，单方独特存储值到各自的动静表上，下一次如果须要同样的 user-agent 字段只须要发送序列号 index 即可，因为单方都把值存储在各自对应的 index 索引当中。

所以哪怕字段越来越多，只有通过了哈夫曼编码存储以及通过索引号能找到对应的参数，就能够无效缩小反复数据的传输。

哈夫曼编码是一种用于无损数据压缩的熵编码（权编码）算法。由美国计算机科学家大卫·霍夫曼（David Albert Huffman）在 1952 年创造。霍夫曼在 1952 年提出了最优二叉树的构造方法，也就是结构最优二元前缀编码的办法，所以最优二叉树也别叫做霍夫曼树，对应最优二元前缀码也叫做霍夫曼编码。

哈夫曼编码对于初学者来说不是特地好了解，这部分内容放到了 [[哈夫曼编码]] 中进行探讨。

概念不好了解，初学倡议多去找找视频教程比照学习

这部分实际上指的是 HTTP3 对于 HTTPS 的 Header 压缩优化，既然是优化，咱们反向思考就能够晓得问题了，次要是上面三点：

申请接收端的解决能力无限，Header 压缩不能设置过于极限，缓存表如果占用超过肯定的占比就会开释掉整个连贯从新申请。（空间换工夫不可避问题）
动态表容量不够，HTTP3 降级到 91 个。
HTTP/ 2 的动静表存在时序性问题，编码重传会造成网络拥挤。

缓存表限度：浏览器的内存以及客户端以及服务端的内存都是无限的，尤其是动静表的不确定因素很大，HTTP 规范设计要求避免动静表适度收缩占用内存导致客户端解体，并且在超过肯定长度过后会主动开释 HTTP/ 2 申请。

激进设置：压缩表的设置有点过于激进了，所以 HTTP3 对于这个表进行进一步扩大。

时序性问题：时序性问题是在传输的时候如果呈现丢包，此时一端的动静表做了改变然而另一端是没扭转的，同样须要把编码重传，这也意味着整个申请都会阻塞掉。

在结尾介绍过，因为 HTTP/ 2 实现了应用层的多路复用，然而因为双向承受能力不对等问题，在应用多个 Stream 的时候容易单向申请阻塞问题。

这个问题是因为 管道连贯 的设计思维带来的，在起草协定之前，SPDY 中通过设置优先级的形式让重要申请优先解决解决这个问题，比方页面的内容应该先进行展现，之后再加载 CSS 文件丑化以及加载脚本互动等等，理论缩小用户在期待过程中敞开页面的几率，也有更好的上网体验。

HTTP/ 2 的流量管制是依附帧构造实现的，通过关键字段 WINDOW_UPDATE 帧来提供流量管制，依据构造体定义，这个帧固定为 4 个字节的长度：

WINDOW_UPDATE Frame {Length (24) = 0x04,
  Type (8) = 0x08,

  Unused Flags (8),

  Reserved (1),
  Stream Identifier (31),

  Reserved (1),
  Window Size Increment (31),
}

对于流量管制，存在上面几个显著特色：

流控制仅实用于被辨认为受流量管制的帧（DATA 帧），同时流量的管制存在方向概念，由数据的双端负责流量管制，能够设置每一个流窗口的大小。
流量管制须要受到各种 代理服务器 限度，并不齐全靠谱，比方如果 IP 的一跳中存在代理，则代理和双端都有流控，所以特地留神这并非端到端的管制；
基于 信用根底 颁布每个流在每个连贯上接管了多少字节，WINDOW_UPDATE 框架没有定义任何标记；换句话说只定义了几个根本的帧字段格局定义，怎么发送承受和管制齐全由实现方决定，保障流控的自由度。
WINDOW_UPDATE 能够对已设置了 END_STREAM 标记的帧进行发送，示意接管方这时候有可能进入了 半敞开 或者曾经敞开的状态接管到 WINDOW_UPDATE 帧，然而接收者不能视作谬误看待；
接收者必须将接管到流控制窗口增量为 0 的 WINDOW_UPDATE 帧视为 PROTOCOL_ERROR 类型的流谬误；
对于连贯与所有新开启的流而言，流控窗口大小默认都是 65535，且最大值为 2^32;
流控无奈禁用；
流控既能够作用于 stream 也能够作用于 connection。

理解流量管制的注意事项，咱们看看它是如何实现的？

每个发送端会存在一个叫做流量窗口的货色，外面简略保留了整数值，标识发送端容许传输的，当流量窗口没有可用空间时，能够发送带有END_STREAM 的帧标记。

然而发送端的流量窗口没有多大意义，这有点相似把井水装到一个桶外面，次要的限度不是井里有多少水，而是看桶能够装多少水，所以为了确保网络失常传输，发送端传输长度不能超过超出接收端播送的流量管制窗口大小的可用空间长度。

后面屡次提到的 WINDOW_UPDATE帧有什么用？次要作用是给接收端告知本人的承受能力，如果提供这个帧，那么发送方不论有多强能力，都须要依照提供的长度限度进行数据发送。

WINDOW_UPDATE帧要么独自作用于 stream，要么独自作用于 connection（streamid 为 0 时，示意作用于 connection，无承受能力）

咱们依据流量窗口和 WINDOW_UPDATE 帧理解 根本算法流程 如下：

发送方提供流量窗口初始值，初始值是 SETTING 帧，这个帧的参数设置非常要害，比方 SETTINGS_INITIAL_WINDOW_SIZE示意窗口初始大小，默认初始值和最大值均为 65535。

SETTINGS_INITIAL_WINDOW_SIZE (0x4): Indicates the sender’s initial

  window size (in octets) for stream-level flow control.  The
  initial value is 2^16-1 (65,535) octets.

发送端每发送一个 DATA 帧，就把 window 流量窗口的值递加，递加量为这个帧的大小，如果流量窗口大小小于DATA 帧，则必须对于流进行拆分，直到小于 windows 流量窗口为止，而流量窗口 递加到 0 的时候，不能发送任何帧。
接收端通过 WINDOW_UPDATE 帧，告知发送方本人的负载能力。

本节最初咱们再补充一下 SETTING 帧的选项含意：

SETTINGS_HEADER_TABLE_SIZE：HPACK（header 压缩算法）header 表的最大长度，默认值 4096
SETTINGS_ENABLE_PUSH：客户端发向服务端的配置，若设置为 true，客户端将容许服务端推送响应，默认值 true
SETTINGS_MAX_CONCURRENT_STREAMS：同时关上的 stream 最大数量，通常意味着同一时刻可能同时响应的申请数量，默认有限
SETTINGS_INITIAL_WINDOW_SIZE：流控的初始窗口大小，默认值 65535
SETTINGS_MAX_FRAME_SIZE：对端可能承受帧的最大长度，默认值 16384
SETTINGS_MAX_HEADER_LIST_SIZE：对端可能承受的 header 列表最大长度，默认不限度

httpcore5 过来的版本存在流控的 BUG，然而这个问题很快被发现并且被修复。

因为波及流控触发 BUG 的概率还是挺大的，也是比较严重的 BUG，BUG 修复能够看这个 COMMIT，想看具体分析能够看参考文章的第一篇。上面为集体阅读文章之后剖析思路。

咱们以 URL https://www.sysgeek.cn/ 为例，通过在本地做代码 debug 发现，最终抛异样的起因在于接管到 WINDOW_UPDATE 帧后，更新后窗口大小值大于 2^32 – 1导致抛异样：

首先依据 commit log，修复者本人也进行了阐明。

The connection flow-control window can only be changed using
> WINDOW_UPDATE frames.

咱们接着对照 RFC 的文档定义：

意思是说 connection 窗口大小仅在接管到 WINDOW_UPDATE 后才可能批改 这个规定被违反的。

把代码扒进去看一下改了什么：

private void applyRemoteSettings(final H2Config config) throws H2ConnectionException {
    
    remoteConfig = config;
    
    hPackEncoder.setMaxTableSize(remoteConfig.getHeaderTableSize());
    
    final int delta = remoteConfig.getInitialWindowSize() - initOutputWinSize;
    
    initOutputWinSize = remoteConfig.getInitialWindowSize();
    
      
    
    if (delta != 0) {
        // 要害 BUG 修复
        updateOutputWindow(0, connOutputWindow, delta);
    
    if (!streamMap.isEmpty()) {for (final Iterator<Map.Entry<Integer, H2Stream>> it = streamMap.entrySet().iterator(); it.hasNext(); ) {final Map.Entry<Integer, H2Stream> entry = it.next();
            
            final H2Stream stream = entry.getValue();
            
            try {updateOutputWindow(stream.getId(), stream.getOutputWindow(), delta);
            
            } catch (final ArithmeticException ex) {throw new H2ConnectionException(H2Error.FLOW_CONTROL_ERROR, ex.getMessage());
        
        }
    
    }
    
    }
    
    }

}

delta 是对方告知的 WINDOW_UPDATE 大小，问题出在 接管 SETTINGS 指令之后，初始化的窗口大小被批改了 ，本来的 6555 被改成更大的值，这个值超过了流量窗口的默认值和最大值的下限，然而流量窗口的大小必须是WINDOW_UPDATE 帧传输之后才容许更改，发送方擅自批改并且发送了超过接受方能力的流量，被查看出异样流量而在代码中抛出异样。

这个很好了解，就如同井水不论桶有多大，就一个劲的往里面灌水，这必定是有问题的。

概括：

管道化改进
偶数帧数为起始
依附 PUSH_PROMISE 帧传输头部信息
通过帧中的 Promised Stream ID 字段告知偶数号

服务器推送的 RFC 定义：RFC 7540: Hypertext Transfer Protocol Version 2 (HTTP/2) (rfc-editor.org)

服务器推送是为了补救 HTTP 这个半双工协定的短板，尽管 HTTP1.X 尝试应用管道流实现服务端推送，然而管道流存在各种缺点所以 HTTP1.X 并没有实现服务端推送的性能。

留神在下面提到的二进制帧数据传输中中，客户端发动的申请必须应用的是奇数号 Stream，服务器被动的推送申请应用的是偶数号 Stream，所以如果是服务端推送通常是从偶数开始。

服务端推送资源须要 依附 PUSH_PROMISE 帧传输头部信息 ，并且须要 通过帧中的 Promised Stream ID 字段 告知客户端本人要发送的偶数号。

须要服务端推送存在诸多限度，从整体上看服务端推送的话语权根本是在客户端这边，上面简略列举几点：

客户端能够设置 SETTINGS_MAX_CONCURRENT_STREAMS=0 或者重置 PUSH_PROMISE 回绝服务端推送。
客户端能够通过 SETTINGS_MAX_CONCURRENT_STREAMS 设置服务端推送的响应。
PUSH_PROMISE帧只能通过服务端发动，应用客户端推送是“不非法“的，服务端有权回绝。

这个连贯前言算是比拟偏门的点，也经常容易被疏忽。如果能看懂上面的内容，那么根本就晓得怎么会回事了。

   In HTTP/2, each endpoint is required to send a connection preface as
   a final confirmation of the protocol in use and to establish the
   initial settings for the HTTP/2 connection.  The client and server
   each send a different connection preface.

   The client connection preface starts with a sequence of 24 octets,
   which in hex notation is:

     0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a

   **That is, the connection preface starts with the string "PRI *
   HTTP/2.0\r\n\r\nSM\r\n\r\n").**  This sequence MUST be followed by a
   SETTINGS frame ([Section 6.5](https://datatracker.ietf.org/doc/html/rfc7540#section-6.5)), which MAY be empty.  The client sends
   the client connection preface immediately upon receipt of a 101
   (Switching Protocols) response (indicating a successful upgrade) or
   as the first application data octets of a TLS connection.  If
   starting an HTTP/2 connection with prior knowledge of server support
   for the protocol, the client connection preface is sent upon
   connection establishment.

连贯前言的关键点如下：

“连贯前言”是规范的 HTTP/1 申请报文，应用 纯文本 的 ASCII 码格局，申请办法是特地注册的一个 关键字“PRI”，全文只有 24 个字节。
如果客户端在建设连贯的时候应用 PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n，并且通过 SETTINGS 帧 告知服务端本人冀望 HTTPS2 连贯，服务端就晓得客户端须要的是 TLS 的 HTTP/ 2 连贯。

为什么是这样的规定，以及为什么是传输这样一串奇怪的字符无需纠结，这是 HTTP/ 2 规范制定者指定的规矩，所以就不要问“为什么会是这样”了。

其实把这一串咒语拼起来还是有含意的，PRISM，2013 年斯诺登的“棱角打算”，这算是在致敬？

HTTP/ 2 的流是对于 HTTP1.X 的管道化的欠缺以及改良，所以在流中能够看到不少管道化的概念。而 HTTP/2 要比管道化更加欠缺正当，所以管道化的概念在 HTTP/ 2 之后就被流取代而隐没了。

因为 HTTP1.X 对于头字段写法很随便，所以 HTTP/ 2 设置所有的头字段必须首字母小写。

 Just as in HTTP/1.x, header field names are strings of ASCII
   characters that are compared in a case-insensitive fashion.  However,
   header field names MUST be converted to lowercase prior to their
   encoding in HTTP/2

就像在 HTTP/1.x 中一样，标头字段名称是 ASCII 字符串
    以不辨别大小写的形式比拟的字符。然而，标头字段名称必须在其之前转换为小写
    HTTP/2 中的编码

咱们依照重点排序，来从整体上看一下 HTTP2 的知识点，为此我总结了几个关键字：

重塑：不是指齐全重造，而是借用 HTTP 协定的根本架构，从外部进行从新调整。

兼容：HTTP 协定背负这微小的历史包袱，所有的改变如果无奈向后兼容，那么就是失败的降级，也不会受到宽泛认可。所以 HTTP2 整体构造沿用 HTTP1.X，退出连贯前言这种和 TLS 握手相似的“咒语”实现新协定的启用。

状态：Header 压缩的 HACK 技术退出之后，HTTP 仿佛不再像是以前那样的无状态协定，它的动静表和动态表都是理论存在的，每个 HTTP2 的连贯都会呈现状态保护，所以尽管自身内部实现不须要关注这些细节，实际上 HTTP2 外部的确加了状态这个概念。

贴合 TCP：HTTP2 的很多细节不难看出是为了更好的和 TCP 协调，比方二进制数据。

管道化延长：管道化在 HTTP1.X 中十分鸡肋，而 HTTP2 则把管道化的理念改良为流的概念进行数据传输，并且依附流实现并发传输。

来来回回改了很屡次，自认为把 HTTP2 次要的知识点遍及了，更多细节须要深刻 RFC 文档，不过不是专供网络编程方向的集体也就点到为止了。

# HTTP/2 的流控实现
# HTTP/ 2 协定解析
3.6 HTTP/2 牛逼在哪？| 小林 coding (xiaolincoding.com)
# 霍夫曼编码 – 维基百科

引言

概览

兼容 HTTP1.X

推广平安

协定栈变动

二进制帧（Stream）

二进制分帧构造

流与多路复用

流状态转化

并发传输

Header 压缩（Header Compression）

动态表

动静表

哈夫曼编码

Header 压缩问题

申请优先级

流量管制

流量管制窗口 (Flow Control Window)

WINDOW_UPDATE 帧

SETTING 帧

题外话：httpcore5 的 BUG

服务器推送

补充

连贯前言

流和管道化关系

申请头字段束缚

总结

写到最初

参考文章

站内搜索