HTTP2中英对照版

超文本传输协议版本 2

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

摘要

本规范描述了一种优化的超文本传输协议(HTTP)。HTTP/2通过引进报头字段压缩以及多路复用来更有效利用网络资源、减少感知延迟。另外还介绍了服务器推送规范。

本文档保持对HTTP/1.1的后向兼容,HTTP的现有的语义保持不变。

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.

特别是,HTTP/1.0只允许在一个连接上建立一个当前未完成的请求。HTTP/1.1管道只部分处理了请求并发和报头阻塞的问题。因此客户端需要发起多次请求通过数次连接服务器来减少延迟。

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.

此外,HTTP/1.1的报头字段经常重复和冗长。在产生更多或更大的网络数据包时,可能导致小的初始TCP堵塞窗口被快速填充。这可能在多个请求建立在一个新的TCP连接时导致过度的延迟。

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.

请求多路复用是通过在一个流上分配多个HTTP请求响应交换来实现的(章节5)。流在很大程度上是相互独立的,因此一个请求上的阻塞或终止并不会影响其他请求的处理。

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.

流量控制和优先级能确保正确使用复用流。流量控制(章节5.2)有助于确保只传播接受者需要使用的数据数据。优先级(章节5.3)能确保有限的资源能优先被重要的请求使用。

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.

HTTP/2添加了一种新的交互模式,即服务器能推送消息给客户端。服务器推送允许服务端预测客户端需要来发送数据给客户端,交换网络的使用来阻止潜在的延迟增长。服务器通过复用一个以PUSH_PROMISE帧发送的请求来实现推送,然后服务端可以在一个单独的流里面发送响应给这个合成的请求。

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.

帧包含的HTTP报头字段是压缩的。HTTP请求有可能是高度冗余的,因此压缩能显著减少请求和响应的大小。

文档结构

The HTTP/2 specification is split into four parts:

HTTP/2协议被分为以下四个部分:

  • 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.

一些帧和流层的概念是与HTTP隔离的,因为意图并不是定义一个完全通用的帧层。这些帧和流层是为了HTTP协议和服务端推送的需求定制的。

约定和术语

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.

所有的数值都是按网络字节顺序。除非有另外说明,数值是无符号的。按情况提供十进制或十六进制的文本值。十六进制用前缀0x来区分。

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连接是运行在TCP连接上的应用层协议。客户端是TCP连接的发起者。

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 http://example.org/foo or https://example.com/bar 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端口。因此,实现对例如http://example.org/foohttps://example.com/bar目标资源的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.

只有依据最终发表的RFC的实现能使用”h2″或”h2c”进行标明。在此之前,任何实现绝对不能使用这两个字符进行识别。

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.

本文档内的例子或者文本只作为编辑方便使用”h2″。针对草案版本的实现绝对不能使用这个字符进行识别。

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 ietf-http-wg@w3.org mailing list.

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

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
Host: server.example.com
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.

包含主体内容的请求必须在客户端能发送HTTP/2帧前全部发送。这意味着一个大的请求实体能阻塞连接的使用直到其全部被发送。

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.

如果一个请求的并发后续请求是重要的,那么可以使用一个小的请求来执行升级到HTTP/2的操作,这样仅消耗一个额外的往返成本。

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

不支持HTTP/2的服务端对请求返回一个不包含升级的报头字段的响应:

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/2的服务端可以返回一个101(转换协议)响应来接受升级请求。在101空内容响应终止后,服务端可以开始发送HTTP/2帧。这些帧必须包含一个发起升级的请求的响应。

“`
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.

第一个被服务端发送的HTTP/2帧是一个设置(SETTINGS)帧。在收到101响应后,客户端发送一个包含设置(SETTINGS)帧的连接序言。

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.

作为一个逐跳的报文报头字段,当升级到HTTP/2时,此连接报头字段必须包含一个HTTP2设置(HTTP2-Settings)的值来完成升级操作。

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.

服务端就像对任何其他设置(SETTINGS)帧一样对这些值进行解码和解释。因为101响应的隐式声明,对这些设置参数的确认不是必须的。这些升级请求中的值使得协议不需要上述设置参数的默认值,同时使客户端有机会在从服务端接受任何帧之前提供其他参数。

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).

TSL协议一旦完成,客户端和服务端都可以发送连接序言(章节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.

客户端可以通过其他方式判断服务端是否支持HTTP/2。例如,AltSvc定义一种机制让HTTP头字段进行广播。

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].

客户端可以对支持HTTP/2的服务端在连接序言(章节3.5)之后立即发送HTTP/2帧。服务端可以通过连接序言中的“PRI”方法来区分这种连接。这只对基于明文TCP的HTTP/2连接建立有影响;支持HTTP/2的服务端对“https”URI需要支持TLS中的协商扩展。

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.

对HTTP/2之前的支持并不表明一个给定的服务器会在以后的连接中一定支持HTTP/2。服务器配置有可能改变或者集群中不同服务器配置有差异。拦截代理(又叫“透明”代理)是另一个可能得原因。

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.

在建立TCP连接并且检测到HTTP/2会被各个对等端使用后,每个端点必须发送一个连接序言最终确认并作为建立HTTP/2连接的初始设置参数。

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

客户端连接序言以24个字节的序列开始,以十六进制表示是:

0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a

(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].

客户端连接序言是用来让大部分的HTTP/1.1或者HTTP/1.0服务端以及中介端不试图进一步处理帧。注意这并不能处理【讨论】中提到的问题。

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.

服务端连接序言包含一个有可能是空的设置(SETTING)帧(章节6.5),它必须在HTTP/2连接中首个发送。

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.

为了避免不必要的延迟,允许客户端在发送客户端连接序言之后立即发送其他额外的帧,不需要等待收到服务端连接序言。不过需要注意的是,服务端连接序言设置(SETTINGS)帧可能包含一些关于期望客户端如何与服务端通信的所必须修改的参数。在收到这些设置(SETTINGS)帧之后,客户端应当遵守所有设置的参数。

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.

如果任何一个端点没有以一个有效的连接序言开头,客户端和服务端必须终止TCP连接。如果端点并没有使用HTTP/2此时可以省略超时(GOAWAY)帧(章节6.8)。

4 HTTP Frames HTTP帧

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

HTTP/2连接一旦建立,端点之间可以马上交换数据帧。

4.1 Frame Format 帧格式

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

所有的帧以8字节的报头开始并且跟着0-16,383字节长度的主体。

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字节字段有具体的布尔标识。
    标识针对确定的帧类型赋予特定的语义。确定帧类型定义语义以外的标示必须被忽略,并且必须在发送的时候保留未设置(0)。
  • 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.

某些帧类型,例如PING(章节6.7),对主体数据大小有额外的限制。同样的,一些特定的应用也可能使用额外的大小限制(见HttpExtra)。

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.

如果一个帧大小超过设定的限制,或者太小无法包含必须的基础帧数据,这个端点必须发送一个帧大小错误(FRAME_SIZE_ERROR)。如果帧大小错误可能修改整个连接状态,必须作为一个连接错误(章节5.4.1)处理;这包括与0流一起的携带报头区块(即报文头(HEADERS),推送承诺(PUSH_PROMISE)和延续(CONTINUATION)帧)、设置(SETTINGS)以及任何窗口更新(WINDOW_UPDATE)帧。

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).

HTTP/2报文报头字段是包含一个或多个相关的键值对。他们在HTTP请求响应消息及服务器推送操作(见章节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.

报头集合是0个或多个报头字段的集合。当他通过连接传输的时候,报头集合将使用HTTP报头压缩序列化到报文报头块中。序列化的报头块被分割成一个或多个的字节序列,称为报头分区,并在报头、推送承诺及延续帧的载体中传送。

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 8.1.2.3), 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 8.1.2.4).

报文头Cookie字段被通过HTTP映射特殊处理;见章节8.1.2.4。

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.

报头压缩是有状态的并且在整个连接过程中使用同个压缩环境。每个报头区块作为离散的单元处理。报头区块必须作为一个连续的帧序列传输,没有任何类型或任何其他流的交错帧。一个报头HEADERS或者延续CONTINUATION帧序列的最后一帧必须有报头终止标记设置。推送承诺PUSH_PROMISE或者延续CONTINUATION帧序列的最后一帧必须具有报头终止标记设置。

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.

报头区块必须被报头HEADERS、推送承诺PUSH_PROMISE或延续CONTINUATION的有效载体发送,因为这些帧中携带了能被接收端修改的压缩上下文数据。端点在接收报头HEADERS、推送承诺PUSH_PROMISE或延续CONTINUATION帧时必须重新组装报头区块并且执行解压缩,即便这些帧将被废弃。如何不能重建报头区间,接收端必须终止连接并报类型为解压缩错误的连接错误(章节5.4.1)。

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连接下交换帧的双向序列。流有一下几个重要特点:

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

5.1 Stream States 流状态

The lifecycle of a stream is shown in Figure 1.

流的生存周期如StreamStatesFigure所示:

“`
+——–+
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)
ES: END_STREAM flag
R: RST_STREAM frame

“`

$$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.

当流在传输的时候,各个端点对在传送中的流状态的主观认识可能不同。终端并不协调流的创建;它们是被任意终端单方面创建的。不匹配的状态导致的消极结果是在发送RST_STREAM流之后它们的“关闭”是受限制的,因为可能在关闭之后帧才被接收。

流有以下状态:

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).

在“报留(本地)”状态的是已经被承诺发送推送承诺PUSH_PROMISE帧的流。一个推送承诺PUSH_PROMISE帧通过使一个流与一个由远端对等端初始化的打开的流相关联来保留一个空闲流。

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.

在这种状态下一个端绝对不能发送报头HEADERS帧和RST_STREAM以外的帧。

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.

在这种状态下一个优先级PRIORITY帧可能被接收。接收到任何报头HEADERS帧、RST_STREAM帧或者优先级PRIORITY帧以外的帧都将被认为是类型为协议错误PROTOCOL_ERROR的连接错误(章节5.4.1)。

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).

处于“打开”状态的流可以被两个对等端来发送任何类型的帧。在这种状态下,发送数据的对等端检查被广播端FlowControl流量控制限制(章节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)”.

在这种状态下每个终端可以发送一个带有END_STREAM结束流标记的帧来使流转换到其中一种“半关闭”状态:一个终端发送一个结束流END_STREAM标记使流变成“半封闭”状态;一个终端接收一个结束流END_STREAM标记使流变成“半封闭(远程)”状态。带有结束流END_STREAM标记的报头HEADERS帧后面可以跟着延续CONTINUATION帧。

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

这种状态下各个终端可以发送一个RST_STREAM帧来使流转换到”关闭”状态。

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.

“半封闭(本地)”状态下的流不能发送帧。只有窗口更新(WINDOW_UPDATE)、优先级(PRIORITY)和终止流(RST_STREAM)帧能在这种状态下发送。

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.

这种状态下,当流接收到包含END_STREAM标记的帧或者某个终端发送了RST_STREAM帧,流转换到“关闭”状态。带有结束流END_STREAM标记的报头HEADERS帧后面可以跟着延续CONTINUATION帧。

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.

这种状态下接收端可以忽略窗口更新WINDOW_UPDATE(或优先级PRIORITY???)帧。这种类型的帧有可能在结束流END_STREAM标记到达一小段时间后才收到。

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

优先级(PRIORITY)帧可以在这种状态下接收并用来对依赖当前流的流进行优先级重排序。

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.

如果终端接收到处于这种状态下的流发送的额外的帧,除非是延续CONTINUATION帧,否则必须返回类型为流关闭STREAM_CLOSED的流错误(章节5.4.2)。

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.

这种状态下,当流发送一个带有终止流END_STREAM标记的帧或者某个终端发送了一个RST_STREAM帧,流将转换到“关闭”状态。

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).

关闭的流上可以发送优先级帧用来对依赖当前关闭流的流进行优先级重排序。终端应该处理优先级帧,但当该流已经从依赖树(章节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.

如果流在发送RST_STREAM帧后转换到这种状态,接收到RST_STREAM的对等端可能已经发送或者队列中准备发送无法取消的帧。终端必须忽略从已经发送RST_STREAM帧的流接收到的帧。终端可以选择设置忽略帧的超时时间并在超过限制后作为错误处理。

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.

在发送RST_STREAM之后收到的流量受限帧(如数据DATA帧)转向流量控制窗口连接处理。尽管这些帧可以被忽略,因为他们是在发送端接收到RST_STREAM之前发送的,但发送端会认为这些帧与流量控制窗口不符。

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.

终端可能在发送RST_STREAM之后接收PUSH_PROMISE帧。即便相关的流已经被重置,推送承诺帧也能使流变成“保留”状态。因此,需要RST_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.

本文档中没有明确说明的地方,具体实现时接收描述状态中没有明确许可的信息都应作为类型为协议错误(PROTOCOL_ERROR)的连接错误(章节5.4.1)来处理。

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.

流由31位字节的无符号整数标识。客户端发起的流必须以奇数标示;服务器发起的流必须使用偶数来标示。0(0x0)用来标识连接控制信息流,且绝对不能用来建立一个新流。

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.

HTTP/1.1升级到HTTP/2的请求将收到一个1(0x1)标识的流的响应。升级完成后,0x1流将对客户端处于“半封闭(本地)”状态。因此,0x1流不能被从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.

一个新建立的流标识符必须数值大于任何终端已经打开或者保留的流标识符。规则适用于使用报头帧打开的流以及使用推送承诺帧保留的流。终端收到不规范的流标识符必须响应一个类型为协议错误(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.

新的流标识符第一次被使用时将隐式关闭所有处于“空闲”状态下可能已经被对等端初始化而且流标识符数字小于新标识符的流。例如,一个客户端发送一个流7的报头帧,那么在流7发送或者接收帧后从没有发送帧的流5将转换为“关闭”状态。

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.

流标识符不能被重复使用。生存期长的连接可能导致流标识符可用范围耗尽。客户端不能新建流标识符时可以针对新流建立一个新的连接。服务端不能新建流标识符时可以发送一个超时帧(GOAWAY)强制客户端对新的流使用新的连接。

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.

对等端可以使用设置帧里面的SETTINGS_MAX_CONCURRENT_STREAMS参数来限制流的并发量。最大并发流设置(章节6.5.2)仅适用于终端并且只对接收到此设置的对等端有效。也就是说:客户端可以指定服务端能启动的流最大并发量,而且服务端能指定客户端能启动的流最大并发量。终端绝对不能超过对等端设置的限制。

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.

处于“打开”或者任意一种“半封闭”状态的流均计入终端被允许启动的流次数中。处于任意这三种状态下的流都将计入SETTINGS_MAX_CONCURRENT_STREAMS设置次数中。处于任意一种“保留”状态下的流不计入打开次数中。

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.4.2)处理。终端希望将SETTINGS_MAX_CONCURRENT_STREAMS的值减少到比当前打开的流更小时可以关闭超过新的设置值的流或者允许流结束。

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.

使用复用流介绍了针对TCP连接的资源争夺导致的流阻塞。流量控制方案等确保同一连接上的流相互之间不会造成破坏性的干扰。流量控制在单个流及整个连接过程中使用。

HTTP