接着上回继续讲 stream 状态机。
5. Streams and Multiplexing
5.1 Stream States
上次讲了我们所熟知的 request-response 工作流在 HTTP/2 中的样子。这里再重复一次：在 HTTP/2 中一个 request-response 就对应一个 stream，换句话说一个 stream 的任务就是完成一组 request-response 的传输，然后就没用了。
这次讲 server push。为了完整，我把不属于本章的一些内容（6.6, 8.2）也挪到这里。首先用一个例子介绍一下 server push。比如你在 HTTP/1.1 下访问 example.com，服务器会首先把 html 返回给你，然后浏览器看到 html 的内容，再发请求去拿 html 包含的资源比如图片、css 等。Server push 做的事是，服务器在返回 html 之后，因为知道 html 内容，所以可以直接把里面包含的资源发给客户端，这样客户端就不需要再发请求了。Server push 的好处是显而易见的：1. 减少了请求；2. 因为服务器不再需要等待后续请求到来而是主动 push，减少了一个 RTT 的等待时间。
上面淡紫色线表示的就是一个 server push 的流程。实际上，server push 依然符合之前对 request-response 的描述，即一个 request-response 对应一个 stream。下面会看到为什么。
先从熟悉的部分开始。上篇文章中详细讲了 stream 的关闭过程，对于 server push stream，这个过程是一样的。reserved 状态和 open 状态差不多，DATA frame 是在 reserved 状态下传输的。在 reserved 状态下，要么发送 RST_STREAM 直接 close stream，要么 client 和 server 各自发送 END_STREAM 先 half-closed 再 closed。这是我们已经了解的过程，如果不了解可以去阅读前一篇文章。
所以现在问题有两个：
- 既然功能差不多，为什么要弄一个 reserved，而不使用 open？reserved 到底是什么意思？
- 从 idle 到 reserved 的过程是怎样的？
现在没法回答这两个问题，因为要理解 server push，必须得先跳出 server push stream，去看前一个 stream。
前一个 stream
前一个 stream 是这样的 stream，该 stream 的 response reference 了要 push 的资源。什么意思？下面的继续使用访问 example.com 的那个例子来解释。
example.com 的服务器之所以可以提前 push 一些资源，是因为知道将要返回给客户端的 html 中 reference 了这些资源。在此场景下，“前一个 stream”，指的就是这个 html 作为 response 的 stream，也就是你访问 example.com 时发出的第一个 request 和 response 对应的 stream。
我们已经知道，server push 的好处是减少了 client 的请求。但是，client 怎么知道什么时候该发请求去拿 css，什么时候不该发呢？显然只能由 server 告知。问题是告知的时机。等 client 收到 html 之后再告知来得及吗？来不及，因为可能在 client 接收到 html 的一瞬间看到有 css 马上就发出请求，之后再告知也没意义了。所以，server 必须在 html 到达 client 之前告知将要 push 的资源。这样便引出了 8.2.1 节中的一个原则，我直接引用如下：
The server SHOULD send PUSH_PROMISE(Section 6.6) frames prior to sending any frames that reference the promised responses. This avoids a race where clients issue requests prior to receiving any PUSH_PROMISE frames.
至此终于可以正式引入 PUSH_PROMISE 这个概念了。PUSH_PROMISE 正是之前所说的“server 对 client 不要为某个资源发请求的告知”。所谓“promised responses”指的则是 server 打算 push 的那些资源。所以这个原则其实就是我们之前说的“server 必须在 html 到达 client 之前告知将要 push 的资源”，只不过把 html generalize 成了“frames that reference the promised responses”。
PUSH_PROMISE
OK，现在来讲 PUSH_PROMISE，以下简称 PP。PP 存在的意义上面已经说过了，下面是另外几件你需要知道的事：
PP 必须在前一个 stream 上发送
即是说，PP frame 的 stream ID 得是前一个 stream 的 stream ID。
PP 实质上是一个 request
前面说到在 server push 中，一个 request-response 仍然对应一个 stream。然而 client 并不发送 request，难道不是应该只有 response 么？原因在于，PP 充当了 request 的角色。没错，这是一个由 server 发出的 request。
PP 的结构
+---------------+
|Pad Length? (8)|
+-+-------------+-----------------------------------------------+
|R| Promised Stream ID (31) |
+-+-----------------------------+-------------------------------+
| Header Block Fragment (*) ...
+---------------------------------------------------------------+
| Padding (*) ...
+---------------------------------------------------------------+
PP 的 payload 结构如图所示。Header Block Fragment 和 6.2 HEADERS 的 Header Block Fragment 是一个东西，也就是 HTTP/2 的 header fields。上篇文章说过，HTTP/2 中的 HEADERS 可以视作 HTTP/1.1 中的 request。所以现在就很清楚了，PUSH_PROMISE 中携带了 request 的所有信息，故它实质上就是一个 server 发出的 request。
注意，图中只画了 payload，并未包含 stream ID，不要和 Promised Stream ID 弄混。那么 Promised Stream ID 是什么？它是由 server 选的一个偶数，代表一个还没有被使用过的 stream。之所以必须是没使用过的 stream，因为这个 ID 代表的 stream 正是接下来 push 要用的 stream，即传输资源 DATA 的 stream，也即 server push 的 request-response 对应的 stream。
Reserved State
现在来回答一开始提出的两个问题
既然功能差不多，为什么要弄一个 reserved，而不使用 open？reserved 到底是什么意思？
PP 中的 Promised Stream ID 代表接下来发送 response 要用的 stream。不同于 open，之前并没有任何数据在这个 stream 上被发送，因为 PP 是在前一个 stream 上被发送的。这就好比，我打电话给餐馆订桌，虽然我现在不在餐馆，但是保证下午六点前会过去，这就是一个 promise。PUSH_PROMISE 也是一样的，虽然在 Promised Stream ID 代表的 stream 上还没有发送过任何数据，但是我 promise 马上会有一个 push response 在上面发送。
Promise 的含义清楚了，但是 reserved 还没解释。继续用餐馆举例子。餐馆接到电话后，会给我留一个桌，于是这个桌就被预定了，处于 reserved 状态。Stream 也是同样的道理，reserved 状态表示这个 stream 被预定了，其它 request-response 不能用。
这个万能的例子还可以展示另一种情况：client 拒绝 push。client 在接到 PP 之后，如果发送 RST_STREAM，代表它并不想接收 push。server 在接收到 RST_STREAM 时有可能已经发送了一些 DATA，若没发完，也就没必要接着发了。这就好比餐馆答应帮我留桌，但是几分钟后打电话过来说刚才搞错了，其实并没有空桌了。于是我只能取消在这个餐馆吃饭的计划。如果我已经在路上，则有必要更改目的地。
提醒一下，上文所举的例子只是为了给读者一个概念，请勿强行对应。
从 idle 到 reserved 的过程是怎样的？
已经解释过了，server 发送 PUSH_PROMISE 把一个 stream 由 idle 变为 reserved。再次强调，server 在选择 Promised Stream ID 的时候必须选那些还没被使用过，即处于 idle 状态的 stream 才行。
那么 server push 主要的内容就讲完了。虽然是一篇 2000 字的文章，但我并没有自信让读者看完就彻底理解 server push。想真正理解，还是要读 RFC，并且多想。
Stream 是 RFC7540 的重点，理解了 stream 的基本概念、flow-control、priority 再加上 server push，也就理解了 HTTP/2。
5. Streams and Multiplexing
stream 可以由 client 或 server 的任意一方创建。frame 在 stream 中的流动是双向的，且接收方会按照接收到 frame 的顺序处理它们。
5.1 Stream States
这个状态机示意图很重要，表示 stream 的状态变化。
+--------+
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
图比较难看懂，主要在于它包含了两个不同的过程。因此我把它们分开表示（server push 过程下次讲）：
绿线所覆盖的流程代表我们所熟知的 request-response 工作流。在 HTTP/2 中一个 request-response 就对应一个 stream，换句话说一个 stream 的任务就是完成一组 request-response 的传输，然后就没用了。先不考虑 half-closed，于是流程可以简化为 idle ——> open ——> closed ，下面先解释这个流程。
idle
idle 很好理解，就是 stream 的初始状态。你也可以认为凡是还没被使用过的 stream 都是 idle 状态。
open
stream 发出或接收到 HEADERS（HEADERS + CONTINUATION 就相当于 HTTP/1.1 中的 request）之后进入 open 状态，这时 server 开始发送 DATA 也就是 response（没有标在图上）。有人可能会不理解为什么图中要把 send HEADER 和 receive HEADER 分开写，这是因为 stream 的状态实际上是在 client 和 server 端同时被维护的，即保存了两份。它们表示同一个 stream 的状态，理论上应该实时同步，但实际上两边维护的 stream state 变化过程是不同的，且并非每时每刻都相同。说得更明白点，idle ——> open 的过程是：client 发出 HEADER + CONTINUATION 后把 client 端维护的 stream state 变为 open，server 接收到 HEADER + CONTINUATION 后把 server 端维护的 stream state 变为 open。明白了 stream state 有两份这点，才能理解之后的内容。
closed
DATA（response） 发完之后就要关闭 stream，最终 stream 进入 closed 状态，永远不再被使用。
可以看到，idle ——> open ——> closed 的流程其实是我们已经熟悉的 request-response 工作流。不过 stream 并不是说关就关，下面解释 stream 由 open ——> closed 的过程。
Stream 是怎么关闭的？
第一种，通过 RST_STREAM。发送、接收到 RST_STREAM，那么这个 stream 直接进入 closed 状态。
第二种，通过 END_STREAM。Reset 快啊，但一般只有 stream 或某个 endpoint 出了些状况的时候才会使用，属于非常规手段。正常情况下 stream 是通过 END_STREAM 结束的。某个 endpoint 发送 END_STREAM 的意思是说，对一个 request-response 而言，我这边该发的数据都发完了，所以我觉得可以 close 这个 stream 了。一边说了不算，如果 peer 还没发完，当然是不能 close 的。如果接到 peer 发的 END_STREAM，那么说明 peer 也同意 close stream，于是 stream 变为 closed 状态。这是 open ——> half closed ——> closed 的流程。
所以你们现在知道，half-closed 表示一边想 close，但另一边还没有同意的状态。只不过呢，图里把这个流程分成了两条路，描述某个 endpoint 存储的 stream 状态变化（记得之前说到 stream 状态会存两份么）。
第一条路 open — send ES —> half closed(local) — recv ES —> closed ，endpoint 先发送 END_STREAM，再接收到 END_STREAM，half closed(local) 代表该 endpoint 想 close；
第二条路 open — send ES —> half closed(remote) — recv ES —> closed ，endpoint 先接收到 END_STREAM，再发送 END_STREAM，half closed(remote) 代表 peer 想 close。
local/remote 的含义需要自行体会，希望现在有把它讲清楚。另外需要说明的是，RST_STREAM 是一种特殊的 frame 类型，而 END_STREAM 则是 HEADERS 或者 DATA 带的 flag。前面说的发送 END_STREAM，指的是发送 set 了 END_STREAM flag 的 HEADERS 或 DATA。
本来想把两个 workflow 一起讲的，不过篇幅所限，server push 的内容就放到下次好了。
想理解 HTTP/2，目前还没有什么比读 RFC 更好的方式。不过 RFC7540 有些地方写的不够清楚，我花了很长时间才搞明白，故在此记录一些想法，请随 RFC 一起阅读。几点说明：
- 本文及后续文章中的章节号、Page x 均指 RFC7540 中的章节号和页码；
- 从实用性角度考虑，h2c only 的内容不太会涉及；
- 因为是笔记，所以基本只会写个人认为值得讨论或注意的地方，也会有一些总结；
- 不涉及 RFC7541，即 HAPCK 头部压缩；
- 不想翻译或不好翻译的术语不翻译；
- 有时用 frame 类型名指代这种类型的 frame，比如“发送 HEADERS”指的是发送 HEADERS frame。
1. Introduction
2. HTTP/2 Protocol Overview
最基本的介绍性内容，也是网上大部分相关文章的深度。只想了解的话，读这两章也就够了。如果想继续阅读，2.2 节中的名词解释很重要，介绍了 "MUST", "SHOULD" 等词（参考 RFC2119），以及 client, connection, endpoint, peer 等术语的含义。
3. Starting HTTP/2
3.5 HTTP/2 Connection Preface
client preface = 0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a + SETTINGS frame
server preface = SETTINGS frame（默认是空的）
h2 client 的 preface 是 TLS connection 传输的 data 的第一段（server 也是），允许在接收到 server preface 之前发送其它数据，比如比如 HEADER，别的 setting，这样省去了等待 server preface 的时间。
两边的 preface 都需要对方发送 ACK frame 进行确认，ACK 是一种特殊的 SETTINGS frame，参见 6.5 节。
4. HTTP Frames
4.1 Frame Format
frame 基本结构是 9 字节的 header 加上不定长的 payload。header 的第一部分是 payload length，占 24 位，也就是说 payload 最多是 2^24 - 1 字节。这个 payload length 有初始值，是 2^14，如果想提升这个值得靠 SETTINGS_MAX_FRAME_SIZE，参考 Page 39。还有一点就是 header 的 9 个字节是不计入 payload length 的。
Flags 在不同的 frame type 下含义是不一样的，每一位并没有固定的含义。
Stream Identifier 即所谓 stream ID。在 RFC 及我后续的笔记当中都经常会用到“frame 在 stream A 上发送”这种说法，实际上指的就是某个 frame 的 stream ID 是 A。
