超文本传输协议版本 2

IETF HTTP2草案(draft-ietf-httpbis-http2-13)




1 介绍

The Hypertext Transfer Protocol (HTTP) is a wildly successful protocol. However, the HTTP/1.1 message format ([RFC7230], Section 3) was designed to be implemented with the tools at hand in the 1990s, not modern Web application performance. As such it has several characteristics that have a negative overall effect on application performance today.

超文本传输协议(HTTP)是一个非常成功的协议。 但是HTTP/1.1 是针对90年代的情况而不是现代web应用的性能而设计的,导致它的一些特点已经对现代应用程序的性能产生负面影响。

In particular, HTTP/1.0 only allows one request to be outstanding at a time on a given connection. HTTP/1.1 pipelining only partially addressed request concurrency and suffers from head-of-line blocking. Therefore, clients that need to make many requests typically use multiple connections to a server in order to reduce latency.


Furthermore, HTTP/1.1 header fields are often repetitive and verbose, which, in addition to generating more or larger network packets, can cause the small initial TCP [TCP] congestion window to quickly fill. This can result in excessive latency when multiple requests are made on a single new TCP connection.


This specification addresses these issues by defining an optimized mapping of HTTP’s semantics to an underlying connection. Specifically, it allows interleaving of request and response messages on the same connection and uses an efficient coding for HTTP header fields. It also allows prioritization of requests, letting more important requests complete more quickly, further improving performance.

本协议通过定义一个优化的基础连接的HTTP语义映射来解决这些问题。 具体地,它允许在同一连接上交错地建立请求和响应消息,并使用高效率编码的HTTP报头字段。 它还允许请求的优先级,让更多的重要的请求更快速的完成,进一步提升了性能。

The resulting protocol is designed to be more friendly to the network, because fewer TCP connections can be used in comparison to HTTP/1.x. This means less competition with other flows, and longer-lived connections, which in turn leads to better utilization of available network capacity.

最终协议设计为对网络更友好,因为它相对HTTP/1.x减少了TCP连接。 这意味着与其他流更少的竞争以及更长时间的连接,从而更有效地利用可用的网络容量。

Finally, this encapsulation also enables more efficient processing of messages through use of binary message framing.


2 HTTP / 2协议概述

HTTP/2 provides an optimized transport for HTTP semantics. HTTP/2 supports all of the core features of HTTP/1.1, but aims to be more efficient in several ways.

HTTP/2 提供了HTTP语义的传输优化。HTTP/2支持所有HTTP/1.1的核心特征,并且在不同的方面做的更高效。

The basic protocol unit in HTTP/2 is a frame (Section 4.1). Each frame type serves a different purpose. For example, HEADERS and DATA frames form the basis of HTTP requests and responses (Section 8.1); other frame types like SETTINGS, WINDOW_UPDATE, and PUSH_PROMISE are used in support of other HTTP/2 features.

HTTP/2中基本的协议单位是帧。每个帧都有不同的类型和用途。例如,报头(HEADERS)和数据(DATA)帧组成了基本的HTTP 请求和响应;其他帧例如 设置(SETTINGS),窗口更新(WINDOW_UPDATE), 和推送承诺(PUSH_PROMISE)是用来实现HTTP/2的其他功能。

Multiplexing of requests is achieved by having each HTTP request-response exchanged assigned to a single stream (Section 5). Streams are largely independent of each other, so a blocked or stalled request does not prevent progress on other requests.


Flow control and prioritization ensure that it is possible to properly use multiplexed streams. Flow control (Section 5.2) helps to ensure that only data that can be used by a receiver is transmitted. Prioritization (Section 5.3) ensures that limited resources can be directed to the most important requests first.


HTTP/2 adds a new interaction mode, whereby a server can push responses to a client (Section 8.2). Server push allows a server to speculatively send a client data that the server anticipates the client will need, trading off some network usage against a potential latency gain. The server does this by synthesizing a request, which it sends as a PUSH_PROMISE frame. The server is then able to send a response to the synthetic request on a separate stream.


Frames that contain HTTP header fields are compressed (Section 4.3). HTTP requests can be highly redundant, so compression can reduce the size of requests and responses significantly.



The HTTP/2 specification is split into four parts:


  • Starting HTTP/2 (Section 3) covers how an HTTP/2 connection is initiated.
  • The framing (Section 4) and streams (Section 5) layers describe the way HTTP/2 frames are structured and formed into multiplexed streams.
  • Frame (Section 6) and error (Section 7) definitions include details of the frame and error types used in HTTP/2.
  • HTTP mappings (Section 8) and additional requirements (Section 9) describe how HTTP semantics are expressed using frames and streams.

  • 启动HTTP/2(章节3)包含了一个HTTP/2连接是如何初始化的。

  • 帧(章节4)和流层(章节5)描述了 HTTP/2流的结构以及如何形成复用流的。
  • 帧(章节6)和错误码(章节7)定义了HTTP/2中使用的流和错误类型的详细内容。
  • HTTP寻址(章节8)和拓展需求(章节9)描述了HTTP语义化是如何由帧和流表达的。

While some of the frame and stream layer concepts are isolated from HTTP, the intent is not to define a completely generic framing layer. The framing and streams layers are tailored to the needs of the HTTP protocol and server push.



The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 [RFC2119].

文档中出现的关键字“必须”,“绝对不能”,“要求”,“”,“不应”,“应该”,“不应该”,“建议”,“可以”及“可选”可通过在 RFC 2119 的解释进行理解【RFC2119】

All numeric values are in network byte order. Values are unsigned unless otherwise indicated. Literal values are provided in decimal or hexadecimal as appropriate. Hexadecimal literals are prefixed with 0x to distinguish them from decimal literals.


The following terms are used:

  • client: The endpoint initiating the HTTP/2 connection.
    connection:A transport-level connection between two endpoints.
  • connection error: An error that affects the entire HTTP/2 connection.
  • endpoint: Either the client or server of the connection.
  • frame: The smallest unit of communication within an HTTP/2 connection, consisting of a header and a variable-length sequence of bytes structured according to the frame type.
  • peer: An endpoint. When discussing a particular endpoint, “peer” refers to the endpoint that is remote to the primary subject of discussion.
  • receiver: An endpoint that is receiving frames.
  • sender: An endpoint that is transmitting frames.
  • server: The endpoint which did not initiate the HTTP/2 connection.
  • stream: A bi-directional flow of frames across a virtual channel within the HTTP/2 connection.
  • stream error: An error on the individual HTTP/2 stream.


  • 客户端:发起HTTP/2请求的端点
  • 连接:在两个端点之间的传输层级别的连接
  • 连接错误:整个HTTP/2连接过程中发生的错误
  • 端点:连接的客户端或服务器
  • 帧:HTTP/2.0通信连接中的最小单元,包括根据帧类型结构的字节的报头和可变长度 的序列
  • 对等端:一个端点。当讨论特定的端点时,“对等端”指的是讨论的主题的远程端点
  • 接收端:正在接收帧的端点
  • 发送端:正在传输帧的端点
  • 服务端:不是启动HTTP/2连接的端点
  • 流:一个双向字节帧流穿过HTTP/2连接中的虚拟通道
  • 流错误:一个HTTP/2流中的错误

3 启动HTTP/2

An HTTP/2 connection is an application level protocol running on top of a TCP connection ([TCP]). The client is the TCP connection initiator.


HTTP/2 uses the same “http” and “https” URI schemes used by HTTP/1.1. HTTP/2 shares the same default port numbers: 80 for “http” URIs and 443 for “https” URIs. As a result, implementations processing requests for target resource URIs like or are required to first discover whether the upstream server (the immediate peer to which the client wishes to establish a connection) supports HTTP/2.

HTTP/2使用与HTTP/1.1相同的”http”和”https” 资源标识符(URI)。使用相同的默认端口:”http” 的80端口及“https”的443端口。因此,实现对例如目标资源的URI请求处理需要首先确定上游服务端(当前客户端希望建立连接的对等端)是否支持HTTP/2。

The means by which support for HTTP/2 is determined is different for “http” and “https” URIs. Discovery for “http” URIs is described in Section 3.2. Discovery for “https” URIs is described in Section 3.3.

这意味着检测“http” 及“https” 的URIs是否支持HTTP/2的方法是不一样的。检测”http”URIs在章节3.2中描述。检测”https”URIs 在章节3.3中描述。

3.1 HTTP/2版本定义

The protocol defined in this document has two identifiers.

  • The string “h2” identifies the protocol where HTTP/2 uses TLS [TLS12]. This identifier is used in the TLS application layer protocol negotiation extension (ALPN) [TLSALPN] field and any place that HTTP/2 over TLS is identified.

    The “h2” string is serialized into an ALPN protocol identifier as the two octet sequence: 0x68, 0x32.

  • The string “h2c” identifies the protocol where HTTP/2 is run over cleartext TCP. This identifier is used in the HTTP/1.1 Upgrade header field and any place that HTTP/2 over TCP is identified.


  • 字符”h2″表示HTTP/2协议使用TLS[TLS]。这种方式用在HTTP/1.1的升级字段、TLS 应用层协议协商扩展字段以及其他需要定义协议的地方。当在定义ALPN协议(序列化的字节)中序列化时。
    “h2″字符序列化到 ALPN 协议中变成两个字节序列:0x68,0x32。

  • 字符”h2c” 表示HTTP/2协议运行在明文TCP上。这个标识用在HTTP/1.1 升级报头字段以及任何TCP是确定的地方。

Negotiating “h2” or “h2c” implies the use of the transport, security, framing and message semantics described in this document.

用到”h2″ 或者 “h2c” 表明使用文档中定义的传输、安全、帧及语义化消息。

Only implementations of the final, published RFC can identify themselves as “h2” or “h2c”. Until such an RFC exists, implementations MUST NOT identify themselves using these strings.


Examples and text throughout the rest of this document use “h2” as a matter of editorial convenience only. Implementations of draft versions MUST NOT identify using this string.


Implementations of draft versions of the protocol MUST add the string “-” and the corresponding draft number to the identifier. For example, draft-ietf-httpbis-http2-11 over TLS is identified using the string “h2-11”.

依据草案版本实现的协议必须添加字符”-“及相对应的草案版本进行标识。例如,基于TLS 的草案draft-ietf-httpbis-http2-11 需要使用字符”h2-11″进行标识。

Non-compatible experiments that are based on these draft versions MUST append the string “-” and an experiment name to the identifier. For example, an experimental implementation of packet mood-based encoding based on draft-ietf-httpbis-http2-09 might identify itself as “h2-09-emo”. Note that any label MUST conform to the “token” syntax defined in Section 3.2.6 of [RFC7230]. Experimenters are encouraged to coordinate their experiments on the mailing list.

基于这些草案版本的不兼容的实验必须在标识符中添加字符”-“及实验名称。例如,基于draft-ietf-httpbis-http2-09草案的情绪编码实验实现必须使用类似”h2-09-emo”的标识符。需要注意的是任何标签必须符合[RFC7230]章节3.2.6 定义的”token”语法。鼓励实验者提交实验到 的邮件列表中。

3.2 Starting HTTP/2 for “http” URIs 针对”http”启动HTTP/2

A client that makes a request to an “http” URI without prior knowledge about support for HTTP/2 uses the HTTP Upgrade mechanism (Section 6.7 of [RFC7230]). The client makes an HTTP/1.1 request that includes an Upgrade header field identifying HTTP/2 with the “h2c” token. The HTTP/1.1 request MUST include exactly one HTTP2-Settings (Section 3.2.1) header field.

客户端无法预知服务端是否支持HTTP/2.0 的情况下使用HTTP升级机制发起“http” URI请求([RFC7230] 章节6.7)。客户端发起一个http1.1请求,其中包含识别HTTP/2的升级报头字段与h2c token。HTTP/1.1必须包含一个确切的HTTP2-Settings中的报头字段。


GET /default.htm HTTP/1.1
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>

Requests that contain an entity body MUST be sent in their entirety before the client can send HTTP/2 frames. This means that a large request entity can block the use of the connection until it is completely sent.


If concurrency of an initial request with subsequent requests is important, a small request can be used to perform the upgrade to HTTP/2, at the cost of an additional round-trip.


A server that does not support HTTP/2 can respond to the request as though the Upgrade header field were absent:


HTTP/1.1 200 OK
Content-Length: 243
Content-Type: text/html

A server MUST ignore a “h2” token in an Upgrade header field. Presence of a token with “h2” implies HTTP/2 over TLS, which is instead negotiated as described in Section 3.3.

服务端必须忽略升级报头字段中的“h2” token。“h2” token基于TLS实现的HTTP/2,协商方法在章节3.3中定义。

A server that supports HTTP/2 can accept the upgrade with a 101 (Switching Protocols) response. After the empty line that terminates the 101 response, the server can begin sending HTTP/2 frames. These frames MUST include a response to the request that initiated the Upgrade.


HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2c

[ HTTP/2 connection …

The first HTTP/2 frame sent by the server is a SETTINGS frame (Section 6.5). Upon receiving the 101 response, the client sends a connection preface (Section 3.5), which includes a SETTINGS frame.


The HTTP/1.1 request that is sent prior to upgrade is assigned stream identifier 1 and is assigned default priority values (Section 5.3.5). Stream 1 is implicitly half closed from the client toward the server, since the request is completed as an HTTP/1.1 request. After commencing the HTTP/2 connection, stream 1 is used for the response.

(*** 升级前所发送的HTTP/1.1请求被派送到标示流1并将赋予最高优先级。)
HTTP/1.1最开始用来升级到2.0的请求用1来标示流并将赋予最高优先级。1流对发送到服务端的客户端是隐式半封闭的,因为这个请求已经作为HTTP/1.1请求完成了。HTTP/2连接开始后, 1流在响应中使用。

3.2.1 HTTP2-Settings Header Field HTTP2-Setting报头字段

A request that upgrades from HTTP/1.1 to HTTP/2 MUST include exactly one HTTP2-Settings header field. The HTTP2-Settings header field is a hop-by-hop header field that includes parameters that govern the HTTP/2 connection, provided in anticipation of the server accepting the request to upgrade.

从HTTP/1.1升级到HTTP/2的请求必须包含一个确切的HTTP2-Settings报头字段。HTTP2-Settings 的报头字段是逐跳报头字段,它包含管理HTTP/2连接参数。这是从对于服务端接受升级请求的预测中所获取的。

HTTP2-Settings = token68

A server MUST reject an attempt to upgrade if this header field is not present. A server MUST NOT send this header field.


The content of the HTTP2-Settings header field is the payload of a SETTINGS frame (Section 6.5), encoded as a base64url string (that is, the URL- and filename-safe Base64 encoding described in Section 5 of [RFC4648], with any trailing ‘=’ characters omitted). The ABNF [RFC5234] production for token68 is defined in Section 2.1 of [RFC7235].

HTTP2-Settings报头字段的内容是设置(SETTINGS)帧的有效载体,使用base64url字符编码(URL及文件名安全的Base64编码,编码描述在[RFC4648] 章节5中,忽略任何“=”字符。) ABNF[RFC5234]产品中对token68的定义在[RFC7235] 章节2.1中。

As a hop-by-hop header field, the Connection header field MUST include a value of HTTP2-Settings in addition to Upgrade when upgrading to HTTP/2.


A server decodes and interprets these values as it would any other SETTINGS frame. Acknowledgement of the SETTINGS parameters (Section 6.5.3) is not necessary, since a 101 response serves as implicit acknowledgment. Providing these values in the Upgrade request ensures that the protocol does not require default values for the above SETTINGS parameters, and gives a client an opportunity to provide other parameters prior to receiving any frames from the server.


3.3 Starting HTTP/2 for “https” URIs 针对“https”启动HTTP/2

A client that makes a request to an “https” URI without prior knowledge about support for HTTP/2 uses TLS [TLS12] with the application layer protocol negotiation extension [TLSALPN].

客户端在不了解服务端是否支持HTTP/2的时候,会使用TSL [TLS12] 于其应用层协议协商扩展 [TLSALPN]。

HTTP/2 over TLS uses the “h2” application token. The “h2c” token MUST NOT be sent by a client or selected by a server.

使用TLS的HTTP/2 使用”h2″程序token。“h2c”token绝对不能由客户端或者选定的服务端发送。

Once TLS negotiation is complete, both the client and the server send a connection preface (Section 3.5).


3.4 Starting HTTP/2 with Prior Knowledge 先验下启动HTTP/2

A client can learn that a particular server supports HTTP/2 by other means. For example, [ALT-SVC] describes a mechanism for advertising this capability.


A client MAY immediately send HTTP/2 frames to a server that is known to support HTTP/2, after the connection preface (Section 3.5). A server can identify such a connection by the use of the “PRI” method in the connection preface. This only affects the establishment of HTTP/2 connections over cleartext TCP; implementations that support HTTP/2 over TLS MUST use protocol negotiation in TLS [TLSALPN].


Prior support for HTTP/2 is not a strong signal that a given server will support HTTP/2 for future connections. It is possible for server configurations to change; for configurations to differ between instances in clustered server; or network conditions to change.


3.5 HTTP/2 Connection Preface HTTP/2连接序言

Upon establishment of a TCP connection and determination that HTTP/2 will be used by both peers, each endpoint MUST send a connection preface as a final confirmation and to establish the initial SETTINGS parameters for the HTTP/2 connection.


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



(the string PRI * HTTP/2.0rnrnSMrnrn). This sequence is followed by a SETTINGS frame (Section 6.5). The SETTINGS frame 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.

(字符串PRI * HTTP/2.0rnrnSMrnrn)。这个序列后跟着一个设置帧,其可为空帧。客户端在收到101转换协议响应(升级成功指示)后马上发送客户端连接序言,或者作为TLS连接的第一个应用数据字节。如果在预先知道服务器支持HTTP/2的情况下启动HTTP/2连接,客户端连接序言在连接建立后发送。

The client connection preface is selected so that a large proportion of HTTP/1.1 or HTTP/1.0 servers and intermediaries do not attempt to process further frames. Note that this does not address the concerns raised in [TALKING].


The server connection preface consists of a potentially empty SETTINGS frame (Section 6.5) that MUST be the first frame the server sends in the HTTP/2 connection.


To avoid unnecessary latency, clients are permitted to send additional frames to the server immediately after sending the client connection preface, without waiting to receive the server connection preface. It is important to note, however, that the server connection preface SETTINGS frame might include parameters that necessarily alter how a client is expected to communicate with the server. Upon receiving the SETTINGS frame, the client is expected to honor any parameters established.


Clients and servers MUST terminate the TCP connection if either peer does not begin with a valid connection preface. A GOAWAY frame (Section 6.8) can be omitted if it is clear that the peer is not using HTTP/2.


4 HTTP Frames HTTP帧

Once the HTTP/2 connection is established, endpoints can begin exchanging frames.


4.1 Frame Format 帧格式

All frames begin with a fixed 8-octet header followed by a payload of between 0 and 16,383 octets.


0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| R | Length (14) | Type (8) | Flags (8) |
|R| Stream Identifier (31) |
| Frame Payload (0...) ...

The fields of the frame header are defined as:

  • R :A reserved 2-bit field. The semantics of these bits are undefined and the bits MUST remain unset (0) when sending and MUST be ignored when receiving.
  • Length : The length of the frame payload expressed as an unsigned 14-bit integer. The 8 octets of the frame header are not included in this value.
  • Type : The 8-bit type of the frame. The frame type determines the format and semantics of the frame. Implementations MUST ignore and discard any frame that has a type that is unknown.
  • Flags :An 8-bit field reserved for frame-type specific boolean flags.
    Flags are assigned semantics specific to the indicated frame type. Flags that have no defined semantics for a particular frame type MUST be ignored, and MUST be left unset (0) when sending.
  • R: A reserved 1-bit field. The semantics of this bit are undefined and the bit MUST remain unset (0) when sending and MUST be ignored when receiving.
  • Stream Identifier: A 31-bit stream identifier (see Section 5.1.1). The value 0 is reserved for frames that are associated with the connection as a whole as opposed to an individual stream.


  • R : 保留的2位字段。这些字节的语义是未定义的,并且在发送的时候必须保持未设置(0),接收的时候必须被忽略此字段。
  • Length : 14位无符号整数的帧主体长度。8字节长度的帧报头信息不计算在此内。
  • Type : 帧的8位类型。帧类型定义了剩余的帧报头和帧主体将如何被解释。具体实现必须在收到未知帧类型(任何未在文档中定义的帧)时作为连接错误中的类型协议错误(PROTOCOL_ERROR)处理。
  • Flags : 为帧类型保留的8字节字段有具体的布尔标识。
  • R : 1位的保留字段。这个字段的语义未设置并且必须在发送的时候保持未设置(0),在接受的时候必须被忽略。
  • Stream Identifier : 31字节的流标识符(见StreamIdentifiers)。0是保留的,标明帧是与连接相关作为一个整体而不是一个单独的流。

The structure and content of the frame payload is dependent entirely on the frame type.


4.2 Frame Size 帧大小

The maximum size of a frame payload varies by frame type. The absolute maximum size of a frame payload is 214-1 (16,383) octets, meaning that the maximum frame size is 16,391 octets. All implementations MUST be capable of receiving and minimally processing frames up to this maximum size.

帧主体的最大长度限制因不同的帧类型而不同。最大帧主体的绝对长度是 $2^{14}-1$ (16,383)字节,表示最大的帧长度是16,391字节。所有的实现必须具备接收和处理此最大长度帧的能力。

Certain frame types, such as PING (Section 6.7), impose additional limits on the amount of payload data allowed.


If a frame size exceeds any defined limit, or is too small to contain mandatory frame data, the endpoint MUST send a FRAME_SIZE_ERROR error. A frame size error in a frame that could alter the state of the entire connection MUST be treated as a connection error (Section 5.4.1); this includes any frame carrying a header block (Section 4.3) (that is, HEADERS, PUSH_PROMISE, and CONTINUATION), SETTINGS, and any WINDOW_UPDATE frame with a stream identifier of 0.


4.3 Header Compression and Decompression 报头压缩和解压缩

A header field in HTTP/2 is a name with one or more associated values. They are used within HTTP request and response messages as well as server push operations (see Section 8.2).


Header sets are collections of zero or more header fields. When transmitted over a connection, a header set is serialized into a header block using HTTP Header Compression [COMPRESSION]. The serialized header block is then divided into one or more octet sequences, called header block fragments, and transmitted within the payload of HEADERS (Section 6.2), PUSH_PROMISE (Section 6.6) or CONTINUATION (Section 6.10) frames.


HTTP Header Compression does not preserve the relative ordering of header fields. Header fields with multiple values are encoded into a single header field using a special delimiter (see Section, this preserves the relative order of values for that header field.

HTTP报文头压缩并不保留报头字段的相关顺序。具有多个值的报头字段使用特定的分割器被编码分割到一个单独的报头区域(见 章节8.1.2.3 HeaderOrdering),这保留了该报头字段中各种值的对应顺序。

The Cookie header field [COOKIE] is treated specially by the HTTP mapping (see Section


A receiving endpoint reassembles the header block by concatenating its fragments, then decompresses the block to reconstruct the header set.

A complete header block consists of either:

  • a single HEADERS or PUSH_PROMISE frame, with the END_HEADERS flag set, or
  • a HEADERS or PUSH_PROMISE frame with the END_HEADERS flag cleared and one or more CONTINUATION frames, where the last CONTINUATION frame has the END_HEADERS flag set.



  • 一个包含报头终止标记集合的单独的报头HEADERS 或 推送承诺PUSH_PROMISE帧,或者
  • 一个报头终止标记被清除的报头HEADERS 或 推送承诺PUSH_PROMISE帧以及一个或多个延续CONTINUATION帧,最后一个延续CONTINUATION帧拥有报头终止标记设置。

Header compression is stateful, using a single compression context for the entire connection. Each header block is processed as a discrete unit. Header blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream. The last frame in a sequence of HEADERS or CONTINUATION frames MUST have the END_HEADERS flag set. The last frame in a sequence of PUSH_PROMISE or CONTINUATION frames MUST have the END_HEADERS flag set. This allows a header block to be logically equivalent to a single frame.


Header block fragments can only be sent as the payload of HEADERS, PUSH_PROMISE or CONTINUATION frames, because these frames carry data that can modify the compression context maintained by a receiver. An endpoint receiving HEADERS, PUSH_PROMISE or CONTINUATION frames MUST reassemble header blocks and perform decompression even if the frames are to be discarded. A receiver MUST terminate the connection with a connection error (Section 5.4.1) of type COMPRESSION_ERROR if it does not decompress a header block.


5 Streams and Multiplexing 流和多路复用

A “stream” is an independent, bi-directional sequence of frames exchanged between the client and server within an HTTP/2 connection. Streams have several important characteristics:

  • A single HTTP/2 connection can contain multiple concurrently open streams, with either endpoint interleaving frames from multiple streams.
  • Streams can be established and used unilaterally or shared by either the client or server.
  • Streams can be closed by either endpoint.
  • The order in which frames are sent on a stream is significant. Recipients process frames in the order they are received. In particular, the order of HEADERS, and DATA frames is semantically significant.
  • Streams are identified by an integer. Stream identifiers are assigned to streams by the endpoint initiating the stream.


  • 一个单独的HTTP/2连接能够保持多个同时打开的流,各个端点间从多个流中交换帧。
  • 流可以被被客户端或者服务端单方面建立使用或分享。
  • 流可以被任何一个连接终端关闭。
  • 在流内发送帧的顺序很重要。它们将按被接收的顺序处理。特别是报头及数据帧的顺序语义上是有意义的。
  • 流以一个整数标识。标识符有启动流的终端分配。

5.1 Stream States 流状态

The lifecycle of a stream is shown in Figure 1.


PP | | PP
,——–| idle |——–.
/ | |
v +——–+ v
+———-+ | +———-+
| | | H | |
,—| reserved | | | reserved |—.
| | (local) | v | (remote) | |
| +———-+ +——–+ +———-+ |
| | ES | | ES | |
| | H ,——-| open |——-. | H |
| | / | | | |
| v v +——–+ v v |
| +———-+ | +———-+ |
| | half | | | half | |
| | closed | | R | closed | |
| | (remote) | | | (local) | |
| +———-+ | +———-+ |
| | v | |
| | ES / R +——–+ ES / R | |
| ----------->| |<-----------' |
| R | closed | R |
——————–>| |<——————–‘

H: HEADERS frame (with implied CONTINUATIONs)
PP: PUSH_PROMISE frame (with implied CONTINUATIONs)


$$Figure 2: Stream States$$

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


Both endpoints have a subjective view of the state of a stream that could be different when frames are in transit. Endpoints do not coordinate the creation of streams; they are created unilaterally by either endpoint. The negative consequences of a mismatch in states are limited to the “closed” state after sending RST_STREAM, where frames might be received for some time after closing.



Streams have the following states:

idle :

All streams start in the “idle” state. In this state, no frames have been exchanged.


The following transitions are valid from this state:

  • Sending or receiving a HEADERS frame causes the stream to become “open”. The stream identifier is selected as described in Section 5.1.1. The same HEADERS frame can also cause a stream to immediately become “half closed”.
  • Sending a PUSH_PROMISE frame marks the associated stream for later use. The stream state for the reserved stream transitions to “reserved (local)”.
  • Receiving a PUSH_PROMISE frame marks the associated stream as reserved by the remote peer. The state of the stream becomes “reserved (remote)”.


  • 发送或者接收一个报头HEADERS帧导致流变成“打开”。流标识符如StreamIdentifiers说明。这个报头HEADERS帧同样可能导致流立即变成“半关闭”状态。
  • 发送一个推送承诺PUSH_PROMISE帧标记相关的流后续再使用。保留流状态将转换为“保留(本地)”。
  • 接收一个推送承诺PUSH_PROMISE帧标记相关的流为远程端点预留的流。这些流的状态变成“保留(远程)”

reserved (local) :

A stream in the “reserved (local)” state is one that has been promised by sending a PUSH_PROMISE frame. A PUSH_PROMISE frame reserves an idle stream by associating the stream with an open stream that was initiated by the remote peer (see Section 8.2).


In this state, only the following transitions are possible:

  • The endpoint can send a HEADERS frame. This causes the stream to open in a “half closed (remote)” state.
  • Either endpoint can send a RST_STREAM frame to cause the stream to become “closed”. This releases the stream reservation.


  • 端点可以发送报头HEADERS帧,致使流打开到“半封闭(远程)”状态。
  • 任意端点能发送一个RST_STREAM帧来使流变成“关闭”。这将释放流的保留。

An endpoint MUST NOT send frames other than HEADERS or RST_STREAM in this state.


A PRIORITY frame MAY be received in this state. Receiving any frames other than RST_STREAM, or PRIORITY MUST be treated as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.


reserved (remote) :

A stream in the “reserved (remote)” state has been reserved by a remote peer.


In this state, only the following transitions are possible:

  • Receiving a HEADERS frame causes the stream to transition to “half closed (local)”.
  • Either endpoint can send a RST_STREAM frame to cause the stream to become “closed”. This releases the stream reservation.


  • 接收一个报头HEADERS帧并致使流转换到“半封闭(本地)”状态。
  • 任意一个端点能发送一个RST_STREAM 帧来使流变成“关闭”。这将释放流的保留。

An endpoint MAY send a PRIORITY frame in this state to reprioritize the reserved stream. An endpoint MUST NOT send any other type of frame other than RST_STREAM or PRIORITY.

这种状态下任意终端可以发送一个优先级PRIORITY帧来变更保留流的优先级顺序。终端绝对不能发送任何RST_STREAM 和优先级PRIORITY以外的帧。

Receiving any other type of frame other than HEADERS or RST_STREAM MUST be treated as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.

接收任何RST_STREAM 和优先级PRIORITY以外的帧必须作为类型为 协议错误PROTOCOL_ERROR的连接错误(章节5.4.1)来处理。

open :

A stream in the “open” state may be used by both peers to send frames of any type. In this state, sending peers observe advertised stream level flow control limits (Section 5.2).


From this state either endpoint can send a frame with an END_STREAM flag set, which causes the stream to transition into one of the “half closed” states: an endpoint sending an 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)”.


Either endpoint can send a RST_STREAM frame from this state, causing it to transition immediately to “closed”.


half closed (local) :

A stream that is in the “half closed (local)” state cannot be used for sending frames. Only WINDOW_UPDATE, PRIORITY and RST_STREAM frames can be sent in this state.


A stream transitions from this state to “closed” when a frame that contains an END_STREAM flag is received, or when either peer sends a RST_STREAM frame.


A receiver can ignore WINDOW_UPDATE frames in this state, which might arrive for a short period after a frame bearing the END_STREAM flag is sent.


PRIORITY frames received in this state are used to reprioritize streams that depend on the current stream.


half closed (remote) :

A stream that is “half closed (remote)” is no longer being used by the peer to send frames. In this state, an endpoint is no longer obligated to maintain a receiver flow control window if it performs flow control.


If an endpoint receives additional frames for a stream that is in this state, other than WINDOW_UPDATE, PRIORITY or RST_STREAM, it MUST respond with a stream error (Section 5.4.2) of type STREAM_CLOSED.


A stream can transition from this state to “closed” by sending a frame that contains an END_STREAM flag, or when either peer sends a RST_STREAM frame.


closed :

The “closed” state is the terminal state.


An endpoint MUST NOT send frames on a closed stream. An endpoint that receives any frame other than PRIORITY after receiving a RST_STREAM MUST treat that as a stream error (Section 5.4.2) of type STREAM_CLOSED. Similarly, an endpoint that receives any frames after receiving a frame with the END_STREAM flag set MUST treat that as a connection error (Section 5.4.1) of type STREAM_CLOSED, unless the frame is permitted as described below.

终端绝对不能通过关闭的流发送帧。终端在收到RST_STREAM后接收的任何帧必须作为类型为流关闭STREAM_CLOSED的StreamErrorHandler流错误stream error(章节5.4.2)处理。相似的,终端接收到带有END_STREAM标记设置的数据DATA帧之后的任何帧,或在带有END_STREAM终止流标记且后面没有延续CONTINUATION帧的报头HEADERS帧之后收到任何帧都必须作为类型为流关闭STREAM_CLOSED的连接错误(章节5.4.1)处理。

WINDOW_UPDATE or RST_STREAM frames can be received in this state for a short period after a DATA or HEADERS frame containing an END_STREAM flag is sent. Until the remote peer receives and processes the frame bearing the END_STREAM flag, it might send frames of these types. Endpoints MUST ignore WINDOW_UPDATE or RST_STREAM frames received in this state, though endpoints MAY choose to treat frames that arrive a significant time after sending END_STREAM as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.

在这种情况下,在带有END_STREAM标记的DATA或HEADERS帧发送之后一小段时间内可以接收WINDOW_UPDATE或者RST_STREAM帧。在远端对等端接收并处理带有END_STREAM标记的帧之前,可以发送任意这几种帧。在这种状态下终端必须忽略接收到的WINDOW_UPDATE,PRIORITY, 或 RST_STREAM帧,但终端也可以当作类型为PROTOCOL_ERROR的连接错误(章节5.4.1)处理。

PRIORITY frames can be sent on closed streams to prioritize streams that are dependent on the closed stream. Endpoints SHOULD process PRIORITY frame, though they can be ignored if the stream has been removed from the dependency tree (see Section 5.3.4).


If this state is reached as a result of sending a RST_STREAM frame, the peer that receives the RST_STREAM might have already sent – or enqueued for sending – frames on the stream that cannot be withdrawn. An endpoint MUST ignore frames that it receives on closed streams after it has sent a RST_STREAM frame. An endpoint MAY choose to limit the period over which it ignores frames and treat frames that arrive after this time as being in error.


Flow controlled frames (i.e., DATA) received after sending RST_STREAM are counted toward the connection flow control window. Even though these frames might be ignored, because they are sent before the sender receives the RST_STREAM, the sender will consider the frames to count against the flow control window.


An endpoint might receive a PUSH_PROMISE frame after it sends RST_STREAM. PUSH_PROMISE causes a stream to become “reserved” even if the associated stream has been reset. Therefore, a RST_STREAM is needed to close an unwanted promised stream.


In the absence of more specific guidance elsewhere in this document, implementations SHOULD treat the receipt of a message that is not expressly permitted in the description of a state as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.


5.1.1 Stream Identifiers 流标识

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. A stream identifier of zero (0x0) is used for connection control messages; the stream identifier zero cannot be used to establish a new stream.


HTTP/1.1 requests that are upgraded to HTTP/2 (see Section 3.2) are responded to with a stream identifier of one (0x1). After the upgrade completes, stream 0x1 is “half closed (local)” to the client. Therefore, stream 0x1 cannot be selected as a new stream identifier by a client that upgrades from HTTP/1.1.


The identifier of a newly established stream MUST be numerically greater than all streams that the initiating endpoint has opened or reserved. This governs streams that are opened using a HEADERS frame and streams that are reserved using PUSH_PROMISE. An endpoint that receives an unexpected stream identifier MUST respond with a connection error (Section 5.4.1) of type PROTOCOL_ERROR.


The first use of a new stream identifier implicitly closes all streams in the “idle” state that might have been initiated by that peer with a lower-valued stream identifier. For example, if a client sends a HEADERS frame on stream 7 without ever sending a frame on stream 5, then stream 5 transitions to the “closed” state when the first frame for stream 7 is sent or received.


Stream identifiers cannot be reused. Long-lived connections can result in an endpoint exhausting the available range of stream identifiers. A client that is unable to establish a new stream identifier can establish a new connection for new streams. A server that is unable to establish a new stream identifier can send a GOAWAY frame so that the client is forced to open a new connection for new streams.


5.1.2 Stream Concurrency 流并发

A peer can limit the number of concurrently active streams using the SETTINGS_MAX_CONCURRENT_STREAMS parameter (see Section 6.5.2) within a SETTINGS frame. The maximum concurrent streams setting is specific to each endpoint and applies only to the peer that receives the setting. That is, clients specify the maximum number of concurrent streams the server can initiate, and servers specify the maximum number of concurrent streams the client can initiate.


Streams that are in the “open” state, or either of the “half closed” states count toward the maximum number of streams that an endpoint is permitted to open. Streams in any of these three states count toward the limit advertised in the SETTINGS_MAX_CONCURRENT_STREAMS setting. Streams in either of the “reserved” states do not count toward the stream limit.


Endpoints MUST NOT exceed the limit set by their peer. An endpoint that receives a HEADERS frame that causes their advertised concurrent stream limit to be exceeded MUST treat this as a stream error (Section 5.4.2). An endpoint that wishes to reduce the value of SETTINGS_MAX_CONCURRENT_STREAMS to a value that is below the current number of open streams can either close streams that exceed the new value or allow streams to complete.


5.2 Flow Control 流量控制

Using streams for multiplexing introduces contention over use of the TCP connection, resulting in blocked streams. A flow control scheme ensures that streams on the same connection do not destructively interfere with each other. Flow control is used for both individual streams and for the connection as a whole.