Internet Engineering Task Force (IETF) M. Belshe
Request for Comments: 7540 BitGo
Category: Standards Track R. Peon
ISSN: 2070-1721 Google, Inc
M. Thomson, Ed.
Mozilla
May 2015
Internet Engineering Task Force (IETF) M. Belshe
Request for Comments: 7540 BitGo
Category: Standards Track R. Peon
ISSN: 2070-1721 Google, Inc
M. Thomson, Ed.
Mozilla
May 2015
Hypertext Transfer Protocol Version 2 (HTTP/2)
超文本传输协议版本2（HTTP/2）
Abstract
摘要
This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.
本规范描述了超文本传输协议（HTTP）语义的优化表达，称为HTTP版本2（HTTP/2）。HTTP/2通过引入报头字段压缩并允许在同一连接上进行多个并发交换，从而能够更有效地使用网络资源并降低延迟感知。它还引入了从服务器到客户端的主动推送表示。
This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
本规范是HTTP/1.1消息语法的替代品，但并不过时。HTTP的现有语义保持不变。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7540.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7540.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. HTTP/2 Protocol Overview ........................................5
2.1. Document Organization ......................................6
2.2. Conventions and Terminology ................................6
3. Starting HTTP/2 .................................................7
3.1. HTTP/2 Version Identification ..............................8
3.2. Starting HTTP/2 for "http" URIs ............................8
3.2.1. HTTP2-Settings Header Field .........................9
3.3. Starting HTTP/2 for "https" URIs ..........................10
3.4. Starting HTTP/2 with Prior Knowledge ......................10
3.5. HTTP/2 Connection Preface .................................11
4. HTTP Frames ....................................................12
4.1. Frame Format ..............................................12
4.2. Frame Size ................................................13
4.3. Header Compression and Decompression ......................14
5. Streams and Multiplexing .......................................15
5.1. Stream States .............................................16
5.1.1. Stream Identifiers .................................21
5.1.2. Stream Concurrency .................................22
5.2. Flow Control ..............................................22
5.2.1. Flow-Control Principles ............................23
5.2.2. Appropriate Use of Flow Control ....................24
5.3. Stream Priority ...........................................24
5.3.1. Stream Dependencies ................................25
5.3.2. Dependency Weighting ...............................26
5.3.3. Reprioritization ...................................26
5.3.4. Prioritization State Management ....................27
5.3.5. Default Priorities .................................28
5.4. Error Handling ............................................28
5.4.1. Connection Error Handling ..........................29
5.4.2. Stream Error Handling ..............................29
1. Introduction ....................................................4
2. HTTP/2 Protocol Overview ........................................5
2.1. Document Organization ......................................6
2.2. Conventions and Terminology ................................6
3. Starting HTTP/2 .................................................7
3.1. HTTP/2 Version Identification ..............................8
3.2. Starting HTTP/2 for "http" URIs ............................8
3.2.1. HTTP2-Settings Header Field .........................9
3.3. Starting HTTP/2 for "https" URIs ..........................10
3.4. Starting HTTP/2 with Prior Knowledge ......................10
3.5. HTTP/2 Connection Preface .................................11
4. HTTP Frames ....................................................12
4.1. Frame Format ..............................................12
4.2. Frame Size ................................................13
4.3. Header Compression and Decompression ......................14
5. Streams and Multiplexing .......................................15
5.1. Stream States .............................................16
5.1.1. Stream Identifiers .................................21
5.1.2. Stream Concurrency .................................22
5.2. Flow Control ..............................................22
5.2.1. Flow-Control Principles ............................23
5.2.2. Appropriate Use of Flow Control ....................24
5.3. Stream Priority ...........................................24
5.3.1. Stream Dependencies ................................25
5.3.2. Dependency Weighting ...............................26
5.3.3. Reprioritization ...................................26
5.3.4. Prioritization State Management ....................27
5.3.5. Default Priorities .................................28
5.4. Error Handling ............................................28
5.4.1. Connection Error Handling ..........................29
5.4.2. Stream Error Handling ..............................29
5.4.3. Connection Termination .............................30
5.5. Extending HTTP/2 ..........................................30
6. Frame Definitions ..............................................31
6.1. DATA ......................................................31
6.2. HEADERS ...................................................32
6.3. PRIORITY ..................................................34
6.4. RST_STREAM ................................................36
6.5. SETTINGS ..................................................36
6.5.1. SETTINGS Format ....................................38
6.5.2. Defined SETTINGS Parameters ........................38
6.5.3. Settings Synchronization ...........................39
6.6. PUSH_PROMISE ..............................................40
6.7. PING ......................................................42
6.8. GOAWAY ....................................................43
6.9. WINDOW_UPDATE .............................................46
6.9.1. The Flow-Control Window ............................47
6.9.2. Initial Flow-Control Window Size ...................48
6.9.3. Reducing the Stream Window Size ....................49
6.10. CONTINUATION .............................................49
7. Error Codes ....................................................50
8. HTTP Message Exchanges .........................................51
8.1. HTTP Request/Response Exchange ............................52
8.1.1. Upgrading from HTTP/2 ..............................53
8.1.2. HTTP Header Fields .................................53
8.1.3. Examples ...........................................57
8.1.4. Request Reliability Mechanisms in HTTP/2 ...........60
8.2. Server Push ...............................................60
8.2.1. Push Requests ......................................61
8.2.2. Push Responses .....................................63
8.3. The CONNECT Method ........................................64
9. Additional HTTP Requirements/Considerations ....................65
9.1. Connection Management .....................................65
9.1.1. Connection Reuse ...................................66
9.1.2. The 421 (Misdirected Request) Status Code ..........66
9.2. Use of TLS Features .......................................67
9.2.1. TLS 1.2 Features ...................................67
9.2.2. TLS 1.2 Cipher Suites ..............................68
10. Security Considerations .......................................69
10.1. Server Authority .........................................69
10.2. Cross-Protocol Attacks ...................................69
10.3. Intermediary Encapsulation Attacks .......................70
10.4. Cacheability of Pushed Responses .........................70
10.5. Denial-of-Service Considerations .........................70
10.5.1. Limits on Header Block Size .......................71
10.5.2. CONNECT Issues ....................................72
10.6. Use of Compression .......................................72
10.7. Use of Padding ...........................................73
10.8. Privacy Considerations ...................................73
5.4.3. Connection Termination .............................30
5.5. Extending HTTP/2 ..........................................30
6. Frame Definitions ..............................................31
6.1. DATA ......................................................31
6.2. HEADERS ...................................................32
6.3. PRIORITY ..................................................34
6.4. RST_STREAM ................................................36
6.5. SETTINGS ..................................................36
6.5.1. SETTINGS Format ....................................38
6.5.2. Defined SETTINGS Parameters ........................38
6.5.3. Settings Synchronization ...........................39
6.6. PUSH_PROMISE ..............................................40
6.7. PING ......................................................42
6.8. GOAWAY ....................................................43
6.9. WINDOW_UPDATE .............................................46
6.9.1. The Flow-Control Window ............................47
6.9.2. Initial Flow-Control Window Size ...................48
6.9.3. Reducing the Stream Window Size ....................49
6.10. CONTINUATION .............................................49
7. Error Codes ....................................................50
8. HTTP Message Exchanges .........................................51
8.1. HTTP Request/Response Exchange ............................52
8.1.1. Upgrading from HTTP/2 ..............................53
8.1.2. HTTP Header Fields .................................53
8.1.3. Examples ...........................................57
8.1.4. Request Reliability Mechanisms in HTTP/2 ...........60
8.2. Server Push ...............................................60
8.2.1. Push Requests ......................................61
8.2.2. Push Responses .....................................63
8.3. The CONNECT Method ........................................64
9. Additional HTTP Requirements/Considerations ....................65
9.1. Connection Management .....................................65
9.1.1. Connection Reuse ...................................66
9.1.2. The 421 (Misdirected Request) Status Code ..........66
9.2. Use of TLS Features .......................................67
9.2.1. TLS 1.2 Features ...................................67
9.2.2. TLS 1.2 Cipher Suites ..............................68
10. Security Considerations .......................................69
10.1. Server Authority .........................................69
10.2. Cross-Protocol Attacks ...................................69
10.3. Intermediary Encapsulation Attacks .......................70
10.4. Cacheability of Pushed Responses .........................70
10.5. Denial-of-Service Considerations .........................70
10.5.1. Limits on Header Block Size .......................71
10.5.2. CONNECT Issues ....................................72
10.6. Use of Compression .......................................72
10.7. Use of Padding ...........................................73
10.8. Privacy Considerations ...................................73
11. IANA Considerations ...........................................74
11.1. Registration of HTTP/2 Identification Strings ............74
11.2. Frame Type Registry ......................................75
11.3. Settings Registry ........................................75
11.4. Error Code Registry ......................................76
11.5. HTTP2-Settings Header Field Registration .................77
11.6. PRI Method Registration ..................................78
11.7. The 421 (Misdirected Request) HTTP Status Code ...........78
11.8. The h2c Upgrade Token ....................................78
12. References ....................................................79
12.1. Normative References .....................................79
12.2. Informative References ...................................81
Appendix A. TLS 1.2 Cipher Suite Black List .......................83
Acknowledgements ..................................................95
Authors' Addresses ................................................96
11. IANA Considerations ...........................................74
11.1. Registration of HTTP/2 Identification Strings ............74
11.2. Frame Type Registry ......................................75
11.3. Settings Registry ........................................75
11.4. Error Code Registry ......................................76
11.5. HTTP2-Settings Header Field Registration .................77
11.6. PRI Method Registration ..................................78
11.7. The 421 (Misdirected Request) HTTP Status Code ...........78
11.8. The h2c Upgrade Token ....................................78
12. References ....................................................79
12.1. Normative References .....................................79
12.2. Informative References ...................................81
Appendix A. TLS 1.2 Cipher Suite Black List .......................83
Acknowledgements ..................................................95
Authors' Addresses ................................................96
The Hypertext Transfer Protocol (HTTP) is a wildly successful protocol. However, the way HTTP/1.1 uses the underlying transport ([RFC7230], Section 6) has several characteristics that have a negative overall effect on application performance today.
超文本传输协议（HTTP）是一种非常成功的协议。但是，HTTP/1.1使用底层传输的方式（[RFC7230]，第6节）有几个特点，这些特点对当今的应用程序性能有负面的总体影响。
In particular, HTTP/1.0 allowed only one request to be outstanding at a time on a given TCP connection. HTTP/1.1 added request pipelining, but this only partially addressed request concurrency and still suffers from head-of-line blocking. Therefore, HTTP/1.0 and HTTP/1.1 clients that need to make many requests use multiple connections to a server in order to achieve concurrency and thereby reduce latency.
特别是，HTTP/1.0只允许在给定TCP连接上一次有一个未完成的请求。HTTP/1.1增加了请求管道，但这只是部分解决了请求并发性问题，并且仍然受到行首阻塞的影响。因此，需要发出许多请求的HTTP/1.0和HTTP/1.1客户端使用到服务器的多个连接来实现并发性，从而减少延迟。
Furthermore, HTTP header fields are often repetitive and verbose, causing unnecessary network traffic as well as causing the initial TCP [TCP] congestion window to quickly fill. This can result in excessive latency when multiple requests are made on a new TCP connection.
此外，HTTP头字段通常重复且冗长，导致不必要的网络流量，并导致初始TCP[TCP]拥塞窗口快速填满。当在新TCP连接上发出多个请求时，这可能会导致延迟过长。
HTTP/2 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/2通过定义HTTP语义到底层连接的优化映射来解决这些问题。具体来说，它允许在同一连接上交错请求和响应消息，并对HTTP头字段使用有效的编码。它还允许对请求进行优先级排序，让更重要的请求更快地完成，从而进一步提高性能。
The resulting protocol is 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 lead to better utilization of available network capacity.
由此产生的协议对网络更友好，因为与HTTP/1.x相比，可以使用更少的TCP连接。这意味着与其他流的竞争更少，连接寿命更长，从而更好地利用可用网络容量。
Finally, HTTP/2 also enables more efficient processing of messages through use of binary message framing.
最后，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中的基本协议单元是一个帧（第4.1节）。每种框架类型都有不同的用途。例如，标头和数据帧构成HTTP请求和响应的基础（第8.1节）；其他帧类型（如设置、窗口更新和推送承诺）用于支持其他HTTP/2功能。
Multiplexing of requests is achieved by having each HTTP request/ response exchange associated with its own stream (Section 5). Streams are largely independent of each other, so a blocked or stalled request or response does not prevent progress on other streams.
通过使每个HTTP请求/响应交换与其自己的流相关联来实现请求的多路复用（第5节）。流在很大程度上彼此独立，因此阻塞或暂停的请求或响应不会阻止其他流的进展。
Flow control and prioritization ensure that it is possible to efficiently 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 streams 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 data to a client 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增加了一种新的交互模式，通过这种模式，服务器可以将响应推送到客户端（第8.2节）。服务器推送允许服务器推测性地向客户机发送服务器预期客户机将需要的数据，从而权衡一些网络使用情况和潜在的延迟增益。服务器通过合成一个请求来实现这一点，该请求作为推送承诺帧发送。然后，服务器能够在单独的流上发送对合成请求的响应。
Because HTTP header fields used in a connection can contain large amounts of redundant data, frames that contain them are compressed (Section 4.3). This has especially advantageous impact upon request sizes in the common case, allowing many requests to be compressed into one packet.
由于连接中使用的HTTP头字段可能包含大量冗余数据，因此会压缩包含这些数据的帧（第4.3节）。在常见情况下，这对请求大小具有特别有利的影响，允许将多个请求压缩到一个数据包中。
The HTTP/2 specification is split into four parts:
HTTP/2规范分为四个部分：
o Starting HTTP/2 (Section 3) covers how an HTTP/2 connection is initiated.
o 启动HTTP/2（第3节）介绍了如何启动HTTP/2连接。
o The frame (Section 4) and stream (Section 5) layers describe the way HTTP/2 frames are structured and formed into multiplexed streams.
o 帧（第4部分）和流（第5部分）层描述了HTTP/2帧的结构和形成多路复用流的方式。
o Frame (Section 6) and error (Section 7) definitions include details of the frame and error types used in HTTP/2.
o 帧（第6节）和错误（第7节）定义包括HTTP/2中使用的帧和错误类型的详细信息。
o HTTP mappings (Section 8) and additional requirements (Section 9) describe how HTTP semantics are expressed using frames and streams.
o HTTP映射（第8节）和附加要求（第9节）描述了如何使用帧和流来表示HTTP语义。
While some of the frame and stream layer concepts are isolated from HTTP, this specification does not define a completely generic frame layer. The frame and stream 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 that initiates an HTTP/2 connection. Clients send HTTP requests and receive HTTP responses.
客户端：启动HTTP/2连接的端点。客户端发送HTTP请求并接收HTTP响应。
connection: A transport-layer connection between two endpoints.
连接：两个端点之间的传输层连接。
connection error: An error that affects the entire HTTP/2 connection.
连接错误：影响整个HTTP/2连接的错误。
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 octets structured according to the frame type.
帧：HTTP/2连接中最小的通信单元，由一个报头和一个根据帧类型构造的可变长度的八位字节序列组成。
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 that accepts an HTTP/2 connection. Servers receive HTTP requests and send HTTP responses.
服务器：接受HTTP/2连接的端点。服务器接收HTTP请求并发送HTTP响应。
stream: A bidirectional flow of frames within the HTTP/2 connection.
流：HTTP/2连接中的双向帧流。
stream error: An error on the individual HTTP/2 stream.
流错误：单个HTTP/2流上的错误。
Finally, the terms "gateway", "intermediary", "proxy", and "tunnel" are defined in Section 2.3 of [RFC7230]. Intermediaries act as both client and server at different times.
最后，[RFC7230]第2.3节定义了术语“网关”、“中介”、“代理”和“隧道”。中介体在不同的时间充当客户机和服务器。
The term "payload body" is defined in Section 3.3 of [RFC7230].
[RFC7230]第3.3节定义了术语“有效载荷体”。
An HTTP/2 connection is an application-layer protocol running on top of a TCP connection ([TCP]). The client is the TCP connection initiator.
HTTP/2连接是在TCP连接（[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/2共享相同的默认端口号：“HTTP”URI为80，“https”URI为443。因此，处理目标资源URI请求的实现类似于“http://example.org/foo“或”https://example.com/bar“需要首先发现上游服务器（客户端希望建立连接的直接对等方）是否支持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/2的支持的方法对于“HTTP”和“https”URI是不同的。第3.2节描述了“http”URI的发现。第3.3节描述了“https”URI的发现。
The protocol defined in this document has two identifiers.
本文件中定义的协议有两个标识符。
o The string "h2" identifies the protocol where HTTP/2 uses Transport Layer Security (TLS) [TLS12]. This identifier is used in the TLS application-layer protocol negotiation (ALPN) extension [TLS-ALPN] field and in any place where HTTP/2 over TLS is identified.
o 字符串“h2”标识HTTP/2使用传输层安全性（TLS）[TLS12]的协议。此标识符用于TLS应用层协议协商（ALPN）扩展[TLS-ALPN]字段中，以及在识别TLS上的HTTP/2的任何位置。
The "h2" string is serialized into an ALPN protocol identifier as the two-octet sequence: 0x68, 0x32.
“h2”字符串被序列化为ALPN协议标识符，作为两个八位字节序列：0x68、0x32。
o 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 in any place where HTTP/2 over TCP is identified.
o 字符串“h2c”标识HTTP/2在明文TCP上运行的协议。此标识符用于HTTP/1.1升级标头字段和识别TCP上的HTTP/2的任何位置。
The "h2c" string is reserved from the ALPN identifier space but describes a protocol that does not use TLS.
“h2c”字符串是从ALPN标识符空间保留的，但描述了不使用TLS的协议。
Negotiating "h2" or "h2c" implies the use of the transport, security, framing, and message semantics described in this document.
协商“h2”或“h2c”意味着使用本文档中描述的传输、安全、帧和消息语义。
A client that makes a request for an "http" URI without prior knowledge about support for HTTP/2 on the next hop uses the HTTP Upgrade mechanism (Section 6.7 of [RFC7230]). The client does so by making an HTTP/1.1 request that includes an Upgrade header field with the "h2c" token. Such an HTTP/1.1 request MUST include exactly one HTTP2-Settings (Section 3.2.1) header field.
如果客户机请求“http”URI，而事先不知道下一跳对http/2的支持，则使用http升级机制（RFC7230的第6.7节）。客户端通过发出一个HTTP/1.1请求来实现这一点，该请求包含一个带有“h2c”令牌的升级头字段。这样的HTTP/1.1请求必须只包含一个HTTP2设置（第3.2.1节）头字段。
For example:
例如：
GET / HTTP/1.1
Host: server.example.com
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
GET / 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 a payload body MUST be sent in their entirety before the client can send HTTP/2 frames. This means that a large request 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, an OPTIONS request can be used to perform the upgrade to HTTP/2, at the cost of an additional round trip.
如果初始请求与后续请求的并发性很重要，则可以使用OPTIONS请求执行到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
HTTP/1.1 200 OK
Content-Length: 243
Content-Type: text/html
...
...
A server MUST ignore an "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”标记。带有“h2”的令牌的存在意味着TLS上的HTTP/2，而是如第3.3节所述进行协商。
A server that supports HTTP/2 accepts 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帧。这些帧必须包括对启动升级的请求的响应。
For example:
例如：
HTTP/1.1 101 Switching Protocols Connection: Upgrade Upgrade: h2c
HTTP/1.1 101交换协议连接：升级：h2c
[ HTTP/2 connection ...
[HTTP/2连接。。。
The first HTTP/2 frame sent by the server MUST be a server connection preface (Section 3.5) consisting of a SETTINGS frame (Section 6.5). Upon receiving the 101 response, the client MUST send a connection preface (Section 3.5), which includes a SETTINGS frame.
服务器发送的第一个HTTP/2帧必须是由设置帧（第6.5节）组成的服务器连接序言（第3.5节）。收到101响应后，客户端必须发送一个连接前言（第3.5节），其中包括一个设置框架。
The HTTP/1.1 request that is sent prior to upgrade is assigned a stream identifier of 1 (see Section 5.1.1) with default priority values (Section 5.3.5). Stream 1 is implicitly "half-closed" from the client toward the server (see Section 5.1), 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（见第5.1.1节）和默认优先级值（第5.3.5节）。流1从客户端隐式地“半封闭”到服务器（参见第5.1节），因为请求是作为HTTP/1.1请求完成的。在开始HTTP/2连接之后，流1用于响应。
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 connection-specific 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设置”头字段。HTTP2设置标头字段是一个特定于连接的标头字段，其中包括控制HTTP/2连接的参数，这些参数是在服务器接受升级请求之前提供的。
HTTP2-Settings = token68
HTTP2-Settings = token68
A server MUST NOT upgrade the connection to HTTP/2 if this header field is not present or if more than one is present. A server MUST NOT send this header field.
如果此标头字段不存在或存在多个标头字段，则服务器不得将连接升级到HTTP/2。服务器不得发送此标头字段。
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].
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].
Since the upgrade is only intended to apply to the immediate connection, a client sending the HTTP2-Settings header field MUST also send "HTTP2-Settings" as a connection option in the Connection header field to prevent it from being forwarded (see Section 6.1 of [RFC7230]).
由于升级仅适用于即时连接，因此发送HTTP2设置标头字段的客户端还必须在连接标头字段中发送“HTTP2设置”作为连接选项，以防止其被转发（请参阅[RFC7230]第6.1节）。
A server decodes and interprets these values as it would any other SETTINGS frame. Explicit acknowledgement of these settings (Section 6.5.3) is not necessary, since a 101 response serves as implicit acknowledgement. Providing these values in the upgrade request gives a client an opportunity to provide parameters prior to receiving any frames from the server.
服务器对这些值进行解码和解释，就像对任何其他设置帧进行解码和解释一样。无需明确确认这些设置（第6.5.3节），因为101响应作为隐含确认。在升级请求中提供这些值使客户端有机会在从服务器接收任何帧之前提供参数。
A client that makes a request to an "https" URI uses TLS [TLS12] with the application-layer protocol negotiation (ALPN) extension [TLS-ALPN].
向“https”URI发出请求的客户端使用TLS[TLS12]和应用层协议协商（ALPN）扩展[TLS-ALPN]。
HTTP/2 over TLS uses the "h2" protocol identifier. The "h2c" protocol identifier MUST NOT be sent by a client or selected by a server; the "h2c" protocol identifier describes a protocol that does not use TLS.
TLS上的HTTP/2使用“h2”协议标识符。“h2c”协议标识符不得由客户端发送或由服务器选择；“h2c”协议标识符描述了不使用TLS的协议。
Once TLS negotiation is complete, both the client and the server MUST send a connection preface (Section 3.5).
一旦TLS协商完成，客户端和服务器都必须发送连接前言（第3.5节）。
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。例如，[ALT-SVC]描述了一种宣传此功能的机制。
A client MUST send the connection preface (Section 3.5) and then MAY immediately send HTTP/2 frames to such a server; servers can identify these connections by the presence of the connection preface. This
客户端必须发送连接前言（第3.5节），然后可以立即向这样的服务器发送HTTP/2帧；服务器可以通过连接的存在来识别这些连接。这
only affects the establishment of HTTP/2 connections over cleartext TCP; implementations that support HTTP/2 over TLS MUST use protocol negotiation in TLS [TLS-ALPN].
仅影响通过明文TCP建立HTTP/2连接；支持通过TLS的HTTP/2的实现必须在TLS[TLS-ALPN]中使用协议协商。
Likewise, the server MUST send a connection preface (Section 3.5).
同样，服务器必须发送连接前言（第3.5节）。
Without additional information, prior support for HTTP/2 is not a strong signal that a given server will support HTTP/2 for future connections. For example, it is possible for server configurations to change, for configurations to differ between instances in clustered servers, or for network conditions to change.
如果没有其他信息，先前对HTTP/2的支持并不是一个很强的信号，表明给定的服务器将支持HTTP/2用于将来的连接。例如，服务器配置可能会更改，群集服务器中的实例之间的配置可能会有所不同，或者网络条件可能会更改。
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.
在HTTP/2中，每个端点都需要发送连接前言，作为对正在使用的协议的最终确认，并为HTTP/2连接建立初始设置。客户端和服务器分别发送不同的连接顺序。
The client connection preface starts with a sequence of 24 octets, which in hex notation is:
客户端连接前言以24个八位字节的序列开始，十六进制表示法为：
0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
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), 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.
也就是说，连接前言以字符串“PRI*HTTP/2.0\r\n\r\nSM\r\n\r\n”开头。此序列后面必须有一个设置框（第6.5节），该框可能为空。客户机在收到101（交换协议）响应（表示升级成功）或作为TLS连接的第一个应用程序数据八位组时，立即发送客户机连接前言。如果在事先知道服务器支持协议的情况下启动HTTP/2连接，则在连接建立时发送客户端连接前言。
Note: 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.
服务器连接前言包含一个可能为空的设置帧（第6.5节），该帧必须是服务器在HTTP/2连接中发送的第一个帧。
The SETTINGS frames received from a peer as part of the connection preface MUST be acknowledged (see Section 6.5.3) after sending the connection preface.
发送连接前言后，必须确认作为连接前言一部分从对等方接收的设置帧（见第6.5.3节）。
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. In some configurations, it is possible for the server to transmit SETTINGS before the client sends additional frames, providing an opportunity to avoid this issue.
为了避免不必要的延迟，允许客户端在发送客户端连接前言后立即向服务器发送附加帧，而不必等待接收服务器连接前言。但是，需要注意的是，服务器连接顺序设置框架可能包含一些参数，这些参数必然会改变客户机与服务器通信的方式。在收到设置框架后，客户机应遵守已建立的任何参数。在某些配置中，服务器可以在客户端发送其他帧之前传输设置，从而提供了避免此问题的机会。
Clients and servers MUST treat an invalid connection preface as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. A GOAWAY frame (Section 6.8) MAY be omitted in this case, since an invalid preface indicates that the peer is not using HTTP/2.
客户机和服务器必须将无效的连接顺序视为协议错误类型的连接错误（第5.4.1节）。在这种情况下，GOAWAY帧（第6.8节）可以省略，因为无效的前言表示对等方未使用HTTP/2。
Once the HTTP/2 connection is established, endpoints can begin exchanging frames.
一旦建立了HTTP/2连接，端点就可以开始交换帧。
All frames begin with a fixed 9-octet header followed by a variable-length payload.
所有帧都以固定的9-octet报头开始，后跟可变长度的有效负载。
+-----------------------------------------------+
| Length (24) |
+---------------+---------------+---------------+
| Type (8) | Flags (8) |
+-+-------------+---------------+-------------------------------+
|R| Stream Identifier (31) |
+=+=============================================================+
| Frame Payload (0...) ...
+---------------------------------------------------------------+
+-----------------------------------------------+
| Length (24) |
+---------------+---------------+---------------+
| Type (8) | Flags (8) |
+-+-------------+---------------+-------------------------------+
|R| Stream Identifier (31) |
+=+=============================================================+
| Frame Payload (0...) ...
+---------------------------------------------------------------+
Figure 1: Frame Layout
图1：框架布局
The fields of the frame header are defined as:
帧标头的字段定义为：
Length: The length of the frame payload expressed as an unsigned 24-bit integer. Values greater than 2^14 (16,384) MUST NOT be sent unless the receiver has set a larger value for SETTINGS_MAX_FRAME_SIZE.
长度：帧有效负载的长度，表示为无符号24位整数。除非接收器已为“设置”\u MAX\u FRAME\u SIZE设置了更大的值，否则不得发送大于2^14（16384）的值。
The 9 octets of the frame header are not included in this value.
帧头的9个八位字节不包括在此值中。
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.
类型：帧的8位类型。帧类型决定帧的格式和语义。实现必须忽略并放弃任何具有未知类型的帧。
Flags: An 8-bit field reserved for boolean flags specific to the frame type.
标志：为特定于帧类型的布尔标志保留的8位字段。
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 (0x0) when sending.
标志被指定为特定于指定帧类型的语义。必须忽略没有为特定帧类型定义语义的标志，并且在发送时必须保持未设置（0x0）。
R: A reserved 1-bit field. The semantics of this bit are undefined, and the bit MUST remain unset (0x0) when sending and MUST be ignored when receiving.
R：保留的1位字段。该位的语义未定义，发送时该位必须保持未设置（0x0），接收时必须忽略该位。
Stream Identifier: A stream identifier (see Section 5.1.1) expressed as an unsigned 31-bit integer. The value 0x0 is reserved for frames that are associated with the connection as a whole as opposed to an individual stream.
流标识符：表示为无符号31位整数的流标识符（见第5.1.1节）。值0x0保留给作为整体与连接关联的帧，而不是单个流。
The structure and content of the frame payload is dependent entirely on the frame type.
帧有效载荷的结构和内容完全取决于帧类型。
The size of a frame payload is limited by the maximum size that a receiver advertises in the SETTINGS_MAX_FRAME_SIZE setting. This setting can have any value between 2^14 (16,384) and 2^24-1 (16,777,215) octets, inclusive.
帧有效负载的大小受接收器在设置\u MAX\u frame\u size设置中播发的最大大小的限制。此设置可以具有2^14（16384）和2^24-1（16777215）个八位字节（含）之间的任意值。
All implementations MUST be capable of receiving and minimally processing frames up to 2^14 octets in length, plus the 9-octet frame header (Section 4.1). The size of the frame header is not included when describing frame sizes.
所有实现必须能够接收和最少处理长度为2^14个八位字节的帧，加上9个八位字节的帧头（第4.1节）。描述帧大小时不包括帧标题的大小。
Note: Certain frame types, such as PING (Section 6.7), impose additional limits on the amount of payload data allowed.
注：某些帧类型，如PING（第6.7节），对允许的有效负载数据量施加额外限制。
An endpoint MUST send an error code of FRAME_SIZE_ERROR if a frame exceeds the size defined in SETTINGS_MAX_FRAME_SIZE, exceeds any limit defined for the frame type, or is too small to contain mandatory frame data. 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 frame with a stream identifier of 0.
如果某个帧超出了“设置”\u MAX\u FRAME\u SIZE中定义的大小、超出了为该帧类型定义的任何限制，或者太小而无法包含必需的帧数据，则终结点必须发送错误代码FRAME\u SIZE\u error。帧中可能改变整个连接状态的帧大小错误必须视为连接错误（第5.4.1节）；这包括任何带有头块的帧（第4.3节）（即头、推送承诺和延续）、设置和流标识符为0的任何帧。
Endpoints are not obligated to use all available space in a frame. Responsiveness can be improved by using frames that are smaller than the permitted maximum size. Sending large frames can result in delays in sending time-sensitive frames (such as RST_STREAM, WINDOW_UPDATE, or PRIORITY), which, if blocked by the transmission of a large frame, could affect performance.
端点没有义务使用帧中的所有可用空间。通过使用小于允许的最大大小的帧，可以提高响应能力。发送大帧可能会导致发送时间敏感帧（如RST_流、窗口更新或优先级）的延迟，如果被大帧的传输阻止，可能会影响性能。
Just as in HTTP/1, a header field in HTTP/2 is a name with one or more associated values. Header fields are used within HTTP request and response messages as well as in server push operations (see Section 8.2).
正如在HTTP/1中一样，HTTP/2中的头字段是具有一个或多个关联值的名称。头字段用于HTTP请求和响应消息以及服务器推送操作（参见第8.2节）。
Header lists are collections of zero or more header fields. When transmitted over a connection, a header list 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标头压缩[压缩]将标头列表序列化为标头块。然后将序列化的报头块划分为一个或多个八位组序列，称为报头块片段，并在报头（第6.2节）、推送承诺（第6.6节）或连续（第6.10节）帧的有效载荷内传输。
The Cookie header field [COOKIE] is treated specially by the HTTP mapping (see Section 8.1.2.5).
HTTP映射专门处理Cookie头字段[Cookie]（参见第8.1.2.5节）。
A receiving endpoint reassembles the header block by concatenating its fragments and then decompresses the block to reconstruct the header list.
接收端点通过连接其片段重新组装头块，然后解压缩该块以重建头列表。
A complete header block consists of either:
一个完整的标题块由以下任一部分组成：
o a single HEADERS or PUSH_PROMISE frame, with the END_HEADERS flag set, or
o 设置了END_HEADERS标志的单个标头或PUSH_PROMISE帧，或
o 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.
o 清除END_HEADERS标志的标头或PUSH_PROMITE帧，以及一个或多个连续帧，其中最后一个连续帧设置了END_HEADERS标志。
Header compression is stateful. One compression context and one decompression context are used for the entire connection. A decoding error in a header block MUST be treated as a connection error (Section 5.4.1) of type COMPRESSION_ERROR.
头压缩是有状态的。一个压缩上下文和一个解压缩上下文用于整个连接。头块中的解码错误必须视为压缩错误类型的连接错误（第5.4.1节）。
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 has the
每个标题块作为一个离散单元进行处理。头块必须作为连续的帧序列传输，没有任何其他类型的交织帧或来自任何其他流的交织帧。标题或连续帧序列中的最后一帧具有
END_HEADERS flag set. The last frame in a sequence of PUSH_PROMISE or CONTINUATION frames has the END_HEADERS flag set. This allows a header block to be logically equivalent to a single frame.
结束标题标志集。推送承诺或连续帧序列中的最后一帧设置了END_头标志。这允许头块在逻辑上等同于单个帧。
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 needs to 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.4.1节）类型为COMPRESSION_error的情况下终止连接。
A "stream" is an independent, bidirectional sequence of frames exchanged between the client and server within an HTTP/2 connection. Streams have several important characteristics:
“流”是HTTP/2连接中客户端和服务器之间交换的独立、双向的帧序列。流有几个重要特征：
o A single HTTP/2 connection can contain multiple concurrently open streams, with either endpoint interleaving frames from multiple streams.
o 一个HTTP/2连接可以包含多个并发打开的流，其中任意一个端点交错来自多个流的帧。
o Streams can be established and used unilaterally or shared by either the client or server.
o 流可以单方面建立和使用，也可以由客户端或服务器共享。
o Streams can be closed by either endpoint.
o 流可以由任一端点关闭。
o 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.
o 在流上发送帧的顺序很重要。收件人按接收帧的顺序处理帧。特别是，头和数据帧的顺序在语义上是重要的。
o Streams are identified by an integer. Stream identifiers are assigned to streams by the endpoint initiating the stream.
o 流由整数标识。流标识符由发起流的端点分配给流。
The lifecycle of a stream is shown in Figure 2.
流的生命周期如图2所示。
+--------+
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 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
send:endpoint发送此帧recv:endpoint接收此帧
H: HEADERS frame (with implied CONTINUATIONs) PP: PUSH_PROMISE frame (with implied CONTINUATIONs) ES: END_STREAM flag R: RST_STREAM frame
H:HEADERS帧（带隐含延续）PP:PUSH_承诺帧（带隐含延续）ES:END_流标志R:RST_流帧
Figure 2: Stream States
图2：流状态
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.
请注意，此图显示了流状态转换以及仅影响这些转换的帧和标志。在这方面，连续帧不会导致状态转换；它们实际上是标题的一部分，或者是它们所遵循的承诺。
For the purpose of state transitions, the END_STREAM flag is processed as a separate event to the frame that bears it; a HEADERS frame with the END_STREAM flag set can cause two state transitions.
出于状态转换的目的，END_流标志作为承载它的帧的单独事件处理；设置了END_STREAM标志的Header帧可能会导致两种状态转换。
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_流后的“关闭”状态，其中在关闭后的一段时间内可能会收到帧。
Streams have the following states:
流具有以下状态：
idle: All streams start in the "idle" state.
空闲：所有流都以“空闲”状态启动。
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".
* 发送或接收头帧会导致流“打开”。按照第5.1.1节所述选择流标识符。相同的头帧也会导致流立即变成“半关闭”。
* Sending a PUSH_PROMISE frame on another stream reserves the idle stream that is identified for later use. The stream state for the reserved stream transitions to "reserved (local)".
* 在另一个流上发送PUSH_PROMISE帧将保留标识供以后使用的空闲流。保留流的流状态转换为“保留（本地）”。
* Receiving a PUSH_PROMISE frame on another stream reserves an idle stream that is identified for later use. The stream state for the reserved stream transitions to "reserved (remote)".
* 在另一个流上接收PUSH_PROMISE帧将保留一个空闲流，该空闲流被标识以供以后使用。保留流的流状态转换为“保留（远程）”。
* Note that the PUSH_PROMISE frame is not sent on the idle stream but references the newly reserved stream in the Promised Stream ID field.
* 注意，推送承诺帧不是在空闲流上发送的，而是在承诺流ID字段中引用新保留的流。
Receiving any frame other than HEADERS or PRIORITY on a stream in this state MUST be treated as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
在此状态下，在流上接收除头或优先级以外的任何帧都必须视为协议_错误类型的连接错误（第5.4.1节）。
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).
reserved（local）：处于“reserved（local）”状态的流是通过发送PUSH_承诺帧而承诺的流。推送承诺帧通过将流与远程对等方发起的开放流相关联来保留空闲流（参见第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.
* 任一端点都可以发送RST_流帧，以使流变为“关闭”。这将释放流保留。
An endpoint MUST NOT send any type of frame other than HEADERS, RST_STREAM, or PRIORITY in this state.
在此状态下，端点不得发送除标头、RST_流或优先级以外的任何类型的帧。
A PRIORITY or WINDOW_UPDATE frame MAY be received in this state. Receiving any type of frame other than RST_STREAM, PRIORITY, or WINDOW_UPDATE on a stream in this state MUST be treated as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
在此状态下，可能会收到优先级或窗口更新帧。在此状态下，在流上接收除RST_流、优先级或窗口_更新以外的任何类型的帧必须视为协议_错误类型的连接错误（第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)".
* 接收HEADERS帧会导致流转换为“半封闭（本地）”。
* Either endpoint can send a RST_STREAM frame to cause the stream to become "closed". This releases the stream reservation.
* 任一端点都可以发送RST_流帧，以使流变为“关闭”。这将释放流保留。
An endpoint MAY send a PRIORITY frame in this state to reprioritize the reserved stream. An endpoint MUST NOT send any type of frame other than RST_STREAM, WINDOW_UPDATE, or PRIORITY in this state.
端点可以在这种状态下发送优先级帧，以重新设置保留流的优先级。在此状态下，端点不得发送除RST_流、窗口_更新或优先级以外的任何类型的帧。
Receiving any type of frame other than HEADERS, RST_STREAM, or PRIORITY on a stream in this state MUST be treated as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
在这种状态下，接收除头、RST_流或流优先级以外的任何类型的帧必须视为协议_错误类型的连接错误（第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).
打开：处于“打开”状态的流可被两个对等方用于发送任何类型的帧。在此状态下，发送对等方遵守公布的流级流量控制限制（第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标志的帧，这将导致流转换为“半关闭”状态之一。发送消息的端点
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标志的端点会导致流状态变为“半关闭（远程）”。
Either endpoint can send a RST_STREAM frame from this state, causing it to transition immediately to "closed".
任一端点都可以从此状态发送RST_流帧，使其立即转换为“关闭”。
half-closed (local): A stream that is in the "half-closed (local)" state cannot be used for sending frames other than WINDOW_UPDATE, PRIORITY, and RST_STREAM.
半关闭（本地）：处于“半关闭（本地）”状态的流不能用于发送除窗口更新、优先级和RST_流之外的帧。
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帧时，流从该状态转换为“closed”。
An endpoint can receive any type of frame in this state. Providing flow-control credit using WINDOW_UPDATE frames is necessary to continue receiving flow-controlled frames. In this state, a receiver can ignore WINDOW_UPDATE frames, 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 identified 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 an endpoint receives additional frames, other than WINDOW_UPDATE, PRIORITY, or RST_STREAM, for a stream that is in this state, it MUST respond with a stream error (Section 5.4.2) of type STREAM_CLOSED.
对于处于该状态的流，如果端点接收到除窗口更新、优先级或RST_流以外的其他帧，则其必须以STREAM_CLOSED类型的流错误（第5.4.2节）进行响应。
A stream that is "half-closed (remote)" can be used by the endpoint to send frames of any type. In this state, the endpoint continues to observe advertised stream-level flow-control limits (Section 5.2).
端点可以使用“半封闭（远程）”流发送任何类型的帧。在此状态下，端点继续遵守公布的流级流量控制限制（第5.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_流标志的帧或当任一对等方发送RST_流帧时，从该状态转换为“关闭”。
closed: The "closed" state is the terminal state.
关闭：“关闭”状态为终端状态。
An endpoint MUST NOT send frames other than PRIORITY 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_CLOSED类型的流错误（第5.4.2节）。类似地，在接收到设置了END_STREAM标志的帧后接收任何帧的端点必须将其视为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 RST_STREAM or 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.
在发送包含结束流标志的数据或报头帧后，可以在此状态下短时间内接收窗口更新或RST流帧。在远程对等方接收并处理RST_流或带有END_流标志的帧之前，它可能会发送这些类型的帧。端点必须忽略在此状态下接收的窗口\u更新或RST\u流帧，尽管端点可以选择将发送结束\u流后到达很长时间的帧视为协议\u错误类型的连接错误（第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 frames, 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_流帧而达到此状态，则接收RST_流的对等方可能已在流上发送（或排队等待发送）无法撤回的帧。端点在发送RST_流帧后，必须忽略在闭合流上接收的帧。端点可以选择限制忽略帧的时间段，并将在此时间之后到达的帧视为错误帧。
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_流后接收的流控制帧（即数据）朝连接流控制窗口计数。即使这些帧可能被忽略，因为它们是在发送方接收RSTHY流之前发送的，发送方将考虑这些帧对流量控制窗口的计数。
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_流后可能会收到一个PUSH_承诺帧。PUSH_PROMISE使流变为“保留”，即使相关流已重置。因此，需要RST_流来关闭不需要的承诺流。
In the absence of more specific guidance elsewhere in this document, implementations SHOULD treat the receipt of a frame that is not expressly permitted in the description of a state as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. Note that PRIORITY can be sent and received in any stream state. Frames of unknown types are ignored.
在本文件其他地方没有更具体的指导的情况下，实施应将接收到状态描述中未明确允许的帧视为类型为PROTOCOL_error的连接错误（第5.4.1节）。注意，优先级可以在任何流状态下发送和接收。忽略未知类型的帧。
An example of the state transitions for an HTTP request/response exchange can be found in Section 8.1. An example of the state transitions for server push can be found in Sections 8.2.1 and 8.2.2.
HTTP请求/响应交换的状态转换示例见第8.1节。服务器推送的状态转换示例见第8.2.1节和第8.2.2节。
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 of zero cannot be used to establish a new stream.
流由无符号31位整数标识。客户端启动的流必须使用奇数编号的流标识符；由服务器启动的流必须使用偶数编号的流标识符。零（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/2（参见第3.2节）的HTTP/1.1请求将以1（0x1）的流标识符响应。升级完成后，流0x1对客户端是“半关闭（本地）”的。因此，从HTTP/1.1升级的客户端无法选择流0x1作为新的流标识符。
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.
新建立的流的标识符在数字上必须大于发起端点已打开或保留的所有流。这控制使用Header帧打开的流和使用PUSH_PROMISE保留的流。接收到意外流标识符的端点必须以类型为PROTOCOL_error的连接错误（第5.4.1节）进行响应。
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上发送头帧而从未在流5上发送帧，则流5在发送或接收流7的第一帧时转换为“关闭”状态。
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帧，以便强制客户端为新流打开新连接。
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.
对等方可以在设置框架内使用设置\u MAX\u CONCURRENT\u streams参数（参见第6.5.2节）限制并发活动流的数量。最大并发流设置特定于每个端点，仅适用于接收该设置的对等方。也就是说，客户端指定服务器可以启动的最大并发流数，服务器指定客户端可以启动的最大并发流数。
Streams that are in the "open" state or in 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.
处于“打开”状态或任一“半关闭”状态的流计入端点允许打开的最大流数。这三种状态中的任何一种状态的流都会计入设置\u MAX\u CONCURRENT\u Streams设置中公布的限制。处于“保留”状态的流不计入流限制。
Endpoints MUST NOT exceed the limit set by their peer. An endpoint that receives a HEADERS frame that causes its advertised concurrent stream limit to be exceeded MUST treat this as a stream error (Section 5.4.2) of type PROTOCOL_ERROR or REFUSED_STREAM. The choice of error code determines whether the endpoint wishes to enable automatic retry (see Section 8.1.4) for details).
端点不得超过其对等方设置的限制。接收导致超出其播发并发流限制的报头帧的端点必须将其视为PROTOCOL_error或Rejected_stream类型的流错误（第5.4.2节）。错误代码的选择决定端点是否希望启用自动重试（有关详细信息，请参阅第8.1.4节）。
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.
希望将设置\u MAX\u CONCURRENT\u STREAMS的值降低到当前打开流数以下的端点可以关闭超过新值的流，也可以允许流完成。
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/2 provides for flow control through use of the WINDOW_UPDATE frame (Section 6.9).
HTTP/2通过使用窗口更新框架提供流控制（第6.9节）。
HTTP/2 stream flow control aims to allow a variety of flow-control algorithms to be used without requiring protocol changes. Flow control in HTTP/2 has the following characteristics:
HTTP/2流控制旨在允许在不需要更改协议的情况下使用各种流控制算法。HTTP/2中的流控制具有以下特征：
1. Flow control is specific to a connection. Both types of flow control are between the endpoints of a single hop and not over the entire end-to-end path.
1. 流量控制特定于连接。这两种类型的流控制都在单个跃点的端点之间，而不是在整个端到端路径上。
2. Flow control is based on WINDOW_UPDATE frames. Receivers advertise how many octets they are prepared to receive on a stream and for the entire connection. This is a credit-based scheme.
2. 流量控制基于窗口更新帧。接收器公布他们准备在一个流和整个连接上接收多少个八位字节。这是一个基于信用的计划。
3. Flow control is directional with overall control provided by the receiver. A receiver MAY choose to set any window size that it desires for each stream and for the entire connection. A sender MUST respect flow-control limits imposed by a receiver. Clients, servers, and intermediaries all independently advertise their flow-control window as a receiver and abide by the flow-control limits set by their peer when sending.
3. 流量控制是定向的，由接收器提供整体控制。接收器可以选择为每个流和整个连接设置其所需的任何窗口大小。发送方必须遵守接收方施加的流量控制限制。客户端、服务器和中介都独立地将其流控制窗口作为接收方进行宣传，并在发送时遵守其对等方设置的流控制限制。
4. The initial value for the flow-control window is 65,535 octets for both new streams and the overall connection.
4. 对于新流和整个连接，流量控制窗口的初始值为65535个八位字节。
5. The frame type determines whether flow control applies to a frame. Of the frames specified in this document, only DATA frames are subject to flow control; all other frame types do not consume space in the advertised flow-control window. This ensures that important control frames are not blocked by flow control.
5. 帧类型确定流控制是否应用于帧。在本文件规定的帧中，只有数据帧受流量控制；所有其他帧类型不会占用播发流控制窗口中的空间。这可确保重要的控制帧不会被流量控制阻塞。
6. Flow control cannot be disabled.
6. 无法禁用流控制。
7. HTTP/2 defines only the format and semantics of the WINDOW_UPDATE frame (Section 6.9). This document does not stipulate how a receiver decides when to send this frame or the value that it sends, nor does it specify how a sender chooses to send packets. Implementations are able to select any algorithm that suits their needs.
7. HTTP/2仅定义窗口更新框架的格式和语义（第6.9节）。本文档未规定接收者如何决定何时发送此帧或其发送的值，也未指定发送者如何选择发送数据包。实现可以选择任何适合其需要的算法。
Implementations are also responsible for managing how requests and responses are sent based on priority, choosing how to avoid head-of-line blocking for requests, and managing the creation of new streams. Algorithm choices for these could interact with any flow-control algorithm.
实现还负责管理如何基于优先级发送请求和响应，选择如何避免请求的行首阻塞，以及管理新流的创建。这些算法的选择可以与任何流控制算法交互。
Flow control is defined to protect endpoints that are operating under resource constraints. For example, a proxy needs to share memory between many connections and also might have a slow upstream connection and a fast downstream one. Flow-control addresses cases where the receiver is unable to process data on one stream yet wants to continue to process other streams in the same connection.
定义流控制是为了保护在资源约束下运行的端点。例如，代理需要在多个连接之间共享内存，并且可能有一个缓慢的上游连接和一个快速的下游连接。流控制解决了接收方无法处理一个流上的数据，但希望继续处理同一连接中的其他流的情况。
Deployments that do not require this capability can advertise a flow-control window of the maximum size (2^31-1) and can maintain this window by sending a WINDOW_UPDATE frame when any data is received. This effectively disables flow control for that receiver. Conversely, a sender is always subject to the flow-control window advertised by the receiver.
不需要此功能的部署可以公布最大大小（2^31-1）的流控制窗口，并且可以在接收到任何数据时通过发送窗口更新帧来维护此窗口。这将有效地禁用该接收器的流量控制。相反，发送方总是受制于接收方公布的流量控制窗口。
Deployments with constrained resources (for example, memory) can employ flow control to limit the amount of memory a peer can consume. Note, however, that this can lead to suboptimal use of available network resources if flow control is enabled without knowledge of the bandwidth-delay product (see [RFC7323]).
资源受限（例如内存）的部署可以使用流控制来限制对等方可以使用的内存量。但是，请注意，如果在不知道带宽延迟产品的情况下启用流量控制，则这可能导致可用网络资源的次优使用（请参阅[RFC7323]）。
Even with full awareness of the current bandwidth-delay product, implementation of flow control can be difficult. When using flow control, the receiver MUST read from the TCP receive buffer in a timely fashion. Failure to do so could lead to a deadlock when critical frames, such as WINDOW_UPDATE, are not read and acted upon.
即使完全了解当前的带宽延迟产品，实现流量控制也可能很困难。使用流控制时，接收器必须及时从TCP接收缓冲区读取数据。如果不这样做，则在未读取和操作关键帧（如WINDOW_UPDATE）时，可能会导致死锁。
A client can assign a priority for a new stream by including prioritization information in the HEADERS frame (Section 6.2) that opens the stream. At any other time, the PRIORITY frame (Section 6.3) can be used to change the priority of a stream.
客户端可以通过在打开流的HEADERS框架（第6.2节）中包含优先级信息来为新流分配优先级。在任何其他时间，优先级帧（第6.3节）可用于更改流的优先级。
The purpose of prioritization is to allow an endpoint to express how it would prefer its peer to allocate resources when managing concurrent streams. Most importantly, priority can be used to select streams for transmitting frames when there is limited capacity for sending.
优先级排序的目的是允许端点在管理并发流时表示希望其对等方如何分配资源。最重要的是，当发送容量有限时，可以使用优先级来选择用于发送帧的流。
Streams can be prioritized by marking them as dependent on the completion of other streams (Section 5.3.1). Each dependency is assigned a relative weight, a number that is used to determine the relative proportion of available resources that are assigned to streams dependent on the same stream.
通过将流标记为依赖于其他流的完成，可以对流进行优先级排序（第5.3.1节）。每个依赖项都分配了一个相对权重，这个数字用于确定分配给依赖于同一流的流的可用资源的相对比例。
Explicitly setting the priority for a stream is input to a prioritization process. It does not guarantee any particular processing or transmission order for the stream relative to any other stream. An endpoint cannot force a peer to process concurrent streams in a particular order using priority. Expressing priority is therefore only a suggestion.
显式设置流的优先级是优先级排序过程的输入。它不保证流相对于任何其他流的任何特定处理或传输顺序。端点不能强制对等方使用优先级以特定顺序处理并发流。因此，表示优先权只是一种建议。
Prioritization information can be omitted from messages. Defaults are used prior to any explicit values being provided (Section 5.3.5).
可以从消息中省略优先级信息。在提供任何明确值之前使用默认值（第5.3.5节）。
Each stream can be given an explicit dependency on another stream. Including a dependency expresses a preference to allocate resources to the identified stream rather than to the dependent stream.
可以为每个流指定对另一个流的显式依赖关系。包括依赖项表示将资源分配给所识别的流而不是依赖流的偏好。
A stream that is not dependent on any other stream is given a stream dependency of 0x0. In other words, the non-existent stream 0 forms the root of the tree.
不依赖于任何其他流的流被赋予0x0的流依赖性。换句话说，不存在的流0形成树的根。
A stream that depends on another stream is a dependent stream. The stream upon which a stream is dependent is a parent stream. A dependency on a stream that is not currently in the tree -- such as a stream in the "idle" state -- results in that stream being given a default priority (Section 5.3.5).
依赖于另一个流的流是从属流。流所依赖的流是父流。对当前不在树中的流（例如处于“空闲”状态的流）的依赖会导致该流被赋予默认优先级（第5.3.5节）。
When assigning a dependency on another stream, the stream is added as a new dependency of the parent stream. Dependent streams that share the same parent are not ordered with respect to each other. For example, if streams B and C are dependent on stream A, and if stream D is created with a dependency on stream A, this results in a dependency order of A followed by B, C, and D in any order.
在为另一个流分配依赖项时，该流将作为父流的新依赖项添加。共享同一父级的从属流彼此之间没有顺序。例如，如果流B和C依赖于流A，并且如果流D是在依赖于流A的情况下创建的，则这将导致依赖顺序为A，后面跟着任意顺序的B、C和D。
A A
/ \ ==> /|\
B C B D C
A A
/ \ ==> /|\
B C B D C
Figure 3: Example of Default Dependency Creation
图3：默认依赖项创建的示例
An exclusive flag allows for the insertion of a new level of dependencies. The exclusive flag causes the stream to become the sole dependency of its parent stream, causing other dependencies to become dependent on the exclusive stream. In the previous example, if stream D is created with an exclusive dependency on stream A, this results in D becoming the dependency parent of B and C.
独占标志允许插入新级别的依赖项。独占标志使流成为其父流的唯一依赖项，从而使其他依赖项依赖于独占流。在前面的示例中，如果流D是以流A的独占依赖关系创建的，这将导致D成为B和C的依赖关系父级。
A
A |
/ \ ==> D
B C / \
B C
A
A |
/ \ ==> D
B C / \
B C
Figure 4: Example of Exclusive Dependency Creation
图4：独占依赖项创建的示例
Inside the dependency tree, a dependent stream SHOULD only be allocated resources if either all of the streams that it depends on (the chain of parent streams up to 0x0) are closed or it is not possible to make progress on them.
在依赖关系树中，仅当依赖关系流所依赖的所有流（直至0x0的父流链）都已关闭或无法在这些流上取得进展时，才应为依赖关系流分配资源。
A stream cannot depend on itself. An endpoint MUST treat this as a stream error (Section 5.4.2) of type PROTOCOL_ERROR.
流不能依靠自身。端点必须将其视为PROTOCOL_error类型的流错误（第5.4.2节）。
All dependent streams are allocated an integer weight between 1 and 256 (inclusive).
所有相关流都分配了一个介于1和256（包括256）之间的整数权重。
Streams with the same parent SHOULD be allocated resources proportionally based on their weight. Thus, if stream B depends on stream A with weight 4, stream C depends on stream A with weight 12, and no progress can be made on stream A, stream B ideally receives one-third of the resources allocated to stream C.
具有相同父级的流应根据其权重按比例分配资源。因此，如果流B依赖于权重为4的流A，流C依赖于权重为12的流A，并且在流A上不能取得任何进展，则流B理想地接收分配给流C的资源的三分之一。
Stream priorities are changed using the PRIORITY frame. Setting a dependency causes a stream to become dependent on the identified parent stream.
使用优先级帧更改流优先级。设置依赖项会导致流依赖于已标识的父流。
Dependent streams move with their parent stream if the parent is reprioritized. Setting a dependency with the exclusive flag for a reprioritized stream causes all the dependencies of the new parent stream to become dependent on the reprioritized stream.
如果父流被重新设置优先级，则从属流将与其父流一起移动。为重新设置优先级的流设置具有独占标志的依赖项会导致新父流的所有依赖项都依赖于重新设置优先级的流。
If a stream is made dependent on one of its own dependencies, the formerly dependent stream is first moved to be dependent on the reprioritized stream's previous parent. The moved dependency retains its weight.
如果一个流依赖于它自己的一个依赖项，那么先前依赖的流首先被移动到依赖于重新确定优先级的流的前一个父流。移动的依赖项保留其权重。
For example, consider an original dependency tree where B and C depend on A, D and E depend on C, and F depends on D. If A is made dependent on D, then D takes the place of A. All other dependency relationships stay the same, except for F, which becomes dependent on A if the reprioritization is exclusive.
例如，考虑原始依赖树，其中B和C依赖于A、D和E依赖于C，F依赖于D。如果A依赖于D，则D代替了A。除了F，所有其他依赖关系保持不变，如果重新排序是排他的，则依赖于A。
x x x x
| / \ | |
A D A D D
/ \ / / \ / \ |
B C ==> F B C ==> F A OR A
/ \ | / \ /|\
D E E B C B C F
| | |
F E E
(intermediate) (non-exclusive) (exclusive)
x x x x
| / \ | |
A D A D D
/ \ / / \ / \ |
B C ==> F B C ==> F A OR A
/ \ | / \ /|\
D E E B C B C F
| | |
F E E
(intermediate) (non-exclusive) (exclusive)
Figure 5: Example of Dependency Reordering
图5：依赖项重新排序的示例
When a stream is removed from the dependency tree, its dependencies can be moved to become dependent on the parent of the closed stream. The weights of new dependencies are recalculated by distributing the weight of the dependency of the closed stream proportionally based on the weights of its dependencies.
当从依赖关系树中删除流时，可以将其依赖关系移动到依赖于关闭流的父级。新依赖项的权重通过基于其依赖项的权重按比例分配封闭流的依赖项权重来重新计算。
Streams that are removed from the dependency tree cause some prioritization information to be lost. Resources are shared between streams with the same parent stream, which means that if a stream in that set closes or becomes blocked, any spare capacity allocated to a stream is distributed to the immediate neighbors of the stream. However, if the common dependency is removed from the tree, those streams share resources with streams at the next highest level.
从依赖关系树中删除的流会导致某些优先级信息丢失。资源在具有相同父流的流之间共享，这意味着如果该集合中的流关闭或阻塞，则分配给流的任何备用容量都将分配给该流的紧邻。但是，如果从树中删除公共依赖项，则这些流与下一个最高级别的流共享资源。
For example, assume streams A and B share a parent, and streams C and D both depend on stream A. Prior to the removal of stream A, if streams A and D are unable to proceed, then stream C receives all the resources dedicated to stream A. If stream A is removed from the tree, the weight of stream A is divided between streams C and D. If stream D is still unable to proceed, this results in stream C receiving a reduced proportion of resources. For equal starting weights, C receives one third, rather than one half, of available resources.
例如，假设流A和B共享一个父级，流C和D都依赖于流A。在删除流A之前，如果流A和D无法继续，则流C接收流A专用的所有资源。如果从树中删除流A，流A的权重在流C和D之间分配。如果流D仍然无法继续，这将导致流C接收的资源比例降低。对于相同的起始权重，C获得可用资源的三分之一，而不是一半。
It is possible for a stream to become closed while prioritization information that creates a dependency on that stream is in transit. If a stream identified in a dependency has no associated priority information, then the dependent stream is instead assigned a default priority (Section 5.3.5). This potentially creates suboptimal prioritization, since the stream could be given a priority that is different from what is intended.
在传输对流产生依赖关系的优先级信息时，流可能会关闭。如果依赖项中标识的流没有相关的优先级信息，则将为依赖项流分配默认优先级（第5.3.5节）。这可能会产生次优优先级，因为流可能被赋予与预期不同的优先级。
To avoid these problems, an endpoint SHOULD retain stream prioritization state for a period after streams become closed. The longer state is retained, the lower the chance that streams are assigned incorrect or default priority values.
为了避免这些问题，端点应该在流关闭后的一段时间内保持流优先级状态。保留的状态越长，流被分配错误或默认优先级值的可能性越低。
Similarly, streams that are in the "idle" state can be assigned priority or become a parent of other streams. This allows for the creation of a grouping node in the dependency tree, which enables more flexible expressions of priority. Idle streams begin with a default priority (Section 5.3.5).
类似地，处于“空闲”状态的流可以被分配优先级或成为其他流的父流。这允许在依赖关系树中创建分组节点，从而支持更灵活的优先级表达式。空闲流以默认优先级开始（第5.3.5节）。
The retention of priority information for streams that are not counted toward the limit set by SETTINGS_MAX_CONCURRENT_STREAMS could create a large state burden for an endpoint. Therefore, the amount of prioritization state that is retained MAY be limited.
保留未计入设置\u MAX\u CONCURRENT\u streams设置的限制的流的优先级信息可能会给端点造成很大的状态负担。因此，保留的优先级状态的数量可能是有限的。
The amount of additional state an endpoint maintains for prioritization could be dependent on load; under high load, prioritization state can be discarded to limit resource commitments. In extreme cases, an endpoint could even discard prioritization state for active or reserved streams. If a limit is applied, endpoints SHOULD maintain state for at least as many streams as allowed by their setting for SETTINGS_MAX_CONCURRENT_STREAMS. Implementations SHOULD also attempt to retain state for streams that are in active use in the priority tree.
端点为优先级排序而保持的附加状态量可能取决于负载；在高负载下，可以放弃优先级状态以限制资源承诺。在极端情况下，端点甚至可以放弃活动或保留流的优先级状态。如果应用了限制，端点应保持其设置\u MAX\u CONCURRENT\u streams所允许的至少多个流的状态。实现还应尝试保留优先级树中处于活动使用状态的流的状态。
If it has retained enough state to do so, an endpoint receiving a PRIORITY frame that changes the priority of a closed stream SHOULD alter the dependencies of the streams that depend on it.
如果它保留了足够的状态来执行此操作，那么接收到更改封闭流优先级的优先级帧的端点应该更改依赖于它的流的依赖关系。
All streams are initially assigned a non-exclusive dependency on stream 0x0. Pushed streams (Section 8.2) initially depend on their associated stream. In both cases, streams are assigned a default weight of 16.
所有流最初都在流0x0上分配了一个非独占依赖项。推送流（第8.2节）最初取决于其相关流。在这两种情况下，流的默认权重均为16。
HTTP/2 framing permits two classes of error:
HTTP/2帧允许两类错误：
o An error condition that renders the entire connection unusable is a connection error.
o 导致整个连接不可用的错误条件是连接错误。
o An error in an individual stream is a stream error.
o 单个流中的错误称为流错误。
A list of error codes is included in Section 7.
错误代码列表包含在第7节中。
A connection error is any error that prevents further processing of the frame layer or corrupts any connection state.
连接错误是阻止进一步处理帧层或破坏任何连接状态的任何错误。
An endpoint that encounters a connection error SHOULD first send a GOAWAY frame (Section 6.8) with the stream identifier of the last stream that it successfully received from its peer. The GOAWAY frame includes an error code that indicates why the connection is terminating. After sending the GOAWAY frame for an error condition, the endpoint MUST close the TCP connection.
遇到连接错误的端点应首先发送一个GOAWAY帧（第6.8节），其中包含其从对等端成功接收的最后一个流的流标识符。GOAWAY帧包含一个错误代码，指示连接终止的原因。在发送错误条件的GOAWAY帧后，端点必须关闭TCP连接。
It is possible that the GOAWAY will not be reliably received by the receiving endpoint ([RFC7230], Section 6.6 describes how an immediate connection close can result in data loss). In the event of a connection error, GOAWAY only provides a best-effort attempt to communicate with the peer about why the connection is being terminated.
接收端点可能无法可靠地接收GOAWAY（[RFC7230]，第6.6节描述了立即连接关闭如何导致数据丢失）。在发生连接错误的情况下，GOAWAY只会尽最大努力与对等方沟通连接终止的原因。
An endpoint can end a connection at any time. In particular, an endpoint MAY choose to treat a stream error as a connection error. Endpoints SHOULD send a GOAWAY frame when ending a connection, providing that circumstances permit it.
端点可以随时结束连接。特别地，端点可以选择将流错误视为连接错误。端点应该在结束连接时发送一个GOAWAY帧，前提是环境允许。
A stream error is an error related to a specific stream that does not affect processing of other streams.
流错误是与特定流相关的错误，不会影响其他流的处理。
An endpoint that detects a stream error sends a RST_STREAM frame (Section 6.4) that contains the stream identifier of the stream where the error occurred. The RST_STREAM frame includes an error code that indicates the type of error.
检测到流错误的端点发送RST_流帧（第6.4节），该帧包含发生错误的流的流标识符。RST_流帧包括指示错误类型的错误代码。
A RST_STREAM is the last frame that an endpoint can send on a stream. The peer that sends the RST_STREAM frame MUST be prepared to receive any frames that were sent or enqueued for sending by the remote peer. These frames can be ignored, except where they modify connection state (such as the state maintained for header compression (Section 4.3) or flow control).
RST_流是端点可以在流上发送的最后一帧。发送RST_流帧的对等方必须准备接收远程对等方发送或排队发送的任何帧。这些帧可以忽略，除非它们修改连接状态（例如为报头压缩（第4.3节）或流控制维护的状态）。
Normally, an endpoint SHOULD NOT send more than one RST_STREAM frame for any stream. However, an endpoint MAY send additional RST_STREAM frames if it receives frames on a closed stream after more than a round-trip time. This behavior is permitted to deal with misbehaving implementations.
通常，端点不应为任何流发送多个RST_流帧。然而，如果端点在超过往返时间之后接收到闭合流上的帧，则其可以发送额外的RST_流帧。允许此行为来处理行为不端的实现。
To avoid looping, an endpoint MUST NOT send a RST_STREAM in response to a RST_STREAM frame.
为避免循环，端点不得发送RST_流以响应RST_流帧。
If the TCP connection is closed or reset while streams remain in "open" or "half-closed" state, then the affected streams cannot be automatically retried (see Section 8.1.4 for details).
如果TCP连接在流保持“打开”或“半关闭”状态时关闭或重置，则受影响的流无法自动重试（有关详细信息，请参阅第8.1.4节）。
HTTP/2 permits extension of the protocol. Within the limitations described in this section, protocol extensions can be used to provide additional services or alter any aspect of the protocol. Extensions are effective only within the scope of a single HTTP/2 connection.
HTTP/2允许协议的扩展。在本节描述的限制范围内，协议扩展可用于提供附加服务或更改协议的任何方面。扩展仅在单个HTTP/2连接的范围内有效。
This applies to the protocol elements defined in this document. This does not affect the existing options for extending HTTP, such as defining new methods, status codes, or header fields.
这适用于本文件中定义的协议元素。这不会影响扩展HTTP的现有选项，例如定义新方法、状态代码或头字段。
Extensions are permitted to use new frame types (Section 4.1), new settings (Section 6.5.2), or new error codes (Section 7). Registries are established for managing these extension points: frame types (Section 11.2), settings (Section 11.3), and error codes (Section 11.4).
允许扩展使用新的帧类型（第4.1节）、新设置（第6.5.2节）或新错误代码（第7节）。为管理这些扩展点建立了注册表：帧类型（第11.2节）、设置（第11.3节）和错误代码（第11.4节）。
Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. Implementations MUST discard frames that have unknown or unsupported types. This means that any of these extension points can be safely used by extensions without prior arrangement or negotiation. However, extension frames that appear in the middle of a header block (Section 4.3) are not permitted; these MUST be treated as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
实现必须忽略所有可扩展协议元素中的未知或不支持的值。实现必须丢弃具有未知或不受支持类型的帧。这意味着这些扩展点中的任何一个都可以由扩展安全使用，无需事先安排或协商。然而，不允许出现在标题块（第4.3部分）中间的扩展帧；必须将其视为协议错误类型的连接错误（第5.4.1节）。
Extensions that could change the semantics of existing protocol components MUST be negotiated before being used. For example, an extension that changes the layout of the HEADERS frame cannot be used until the peer has given a positive signal that this is acceptable. In this case, it could also be necessary to coordinate when the revised layout comes into effect. Note that treating any frames other than DATA frames as flow controlled is such a change in semantics and can only be done through negotiation.
可能改变现有协议组件语义的扩展必须在使用前协商。例如，在对等方给出了可接受的肯定信号之前，不能使用更改标题帧布局的扩展。在这种情况下，当修改后的布局生效时，可能还需要进行协调。注意，将数据帧以外的任何帧视为流控制是语义上的一种变化，只能通过协商来完成。
This document doesn't mandate a specific method for negotiating the use of an extension but notes that a setting (Section 6.5.2) could be used for that purpose. If both peers set a value that indicates willingness to use the extension, then the extension can be used. If
本文件未规定谈判使用扩展的具体方法，但指出可为此目的使用设置（第6.5.2节）。如果两个对等方都设置了表示愿意使用扩展的值，则可以使用扩展。如果
a setting is used for extension negotiation, the initial value MUST be defined in such a fashion that the extension is initially disabled.
如果设置用于扩展协商，则初始值的定义方式必须使扩展最初处于禁用状态。
This specification defines a number of frame types, each identified by a unique 8-bit type code. Each frame type serves a distinct purpose in the establishment and management either of the connection as a whole or of individual streams.
本规范定义了许多帧类型，每个帧类型由唯一的8位类型代码标识。每种帧类型在建立和管理作为一个整体的连接或单个流中都有不同的用途。
The transmission of specific frame types can alter the state of a connection. If endpoints fail to maintain a synchronized view of the connection state, successful communication within the connection will no longer be possible. Therefore, it is important that endpoints have a shared comprehension of how the state is affected by the use any given frame.
特定帧类型的传输可以改变连接的状态。如果端点无法维护连接状态的同步视图，则连接内的成功通信将不再可能。因此，端点对任何给定帧的使用如何影响状态有一个共同的理解是很重要的。
DATA frames (type=0x0) convey arbitrary, variable-length sequences of octets associated with a stream. One or more DATA frames are used, for instance, to carry HTTP request or response payloads.
数据帧（类型=0x0）传送与流相关联的任意、可变长度的八位字节序列。例如，一个或多个数据帧用于承载HTTP请求或响应有效载荷。
DATA frames MAY also contain padding. Padding can be added to DATA frames to obscure the size of messages. Padding is a security feature; see Section 10.7.
数据帧也可能包含填充。可以在数据帧中添加填充，以隐藏消息的大小。填充是一种安全特性；见第10.7节。
+---------------+
|Pad Length? (8)|
+---------------+-----------------------------------------------+
| Data (*) ...
+---------------------------------------------------------------+
| Padding (*) ...
+---------------------------------------------------------------+
+---------------+
|Pad Length? (8)|
+---------------+-----------------------------------------------+
| Data (*) ...
+---------------------------------------------------------------+
| Padding (*) ...
+---------------------------------------------------------------+
Figure 6: DATA Frame Payload
图6：数据帧有效载荷
The DATA frame contains the following fields:
数据框包含以下字段：
Pad Length: An 8-bit field containing the length of the frame padding in units of octets. This field is conditional (as signified by a "?" in the diagram) and is only present if the PADDED flag is set.
Pad Length：一个8位字段，包含以八位字节为单位的帧填充长度。此字段是有条件的（如图中的“？”所示），仅当设置了填充标志时才存在。
Data: Application data. The amount of data is the remainder of the frame payload after subtracting the length of the other fields that are present.
数据：应用程序数据。数据量是帧有效载荷减去存在的其他字段的长度后的剩余部分。
Padding: Padding octets that contain no application semantic value. Padding octets MUST be set to zero when sending. A receiver is not obligated to verify padding but MAY treat non-zero padding as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
填充：填充不包含应用程序语义值的八位字节。发送时，填充八位字节必须设置为零。接收器没有义务验证填充，但可以将非零填充视为协议_错误类型的连接错误（第5.4.1节）。
The DATA frame defines the following flags:
数据框定义了以下标志：
END_STREAM (0x1): When set, bit 0 indicates that this frame is the last that the endpoint will send for the identified stream. Setting this flag causes the stream to enter one of the "half-closed" states or the "closed" state (Section 5.1).
END_STREAM（0x1）：设置时，位0表示此帧是端点将为已标识流发送的最后一个帧。设置此标志会导致流进入“半关闭”状态或“关闭”状态之一（第5.1节）。
PADDED (0x8): When set, bit 3 indicates that the Pad Length field and any padding that it describes are present.
PADDED（0x8）：设置时，位3表示存在Pad Length字段及其描述的任何填充。
DATA frames MUST be associated with a stream. If a DATA frame is received whose stream identifier field is 0x0, the recipient MUST respond with a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
数据帧必须与流相关联。如果接收到流标识符字段为0x0的数据帧，则接收方必须以协议_错误类型的连接错误（第5.4.1节）进行响应。
DATA frames are subject to flow control and can only be sent when a stream is in the "open" or "half-closed (remote)" state. The entire DATA frame payload is included in flow control, including the Pad Length and Padding fields if present. If a DATA frame is received whose stream is not in "open" or "half-closed (local)" state, the recipient MUST respond with a stream error (Section 5.4.2) of type STREAM_CLOSED.
数据帧受流控制，仅当流处于“打开”或“半关闭（远程）”状态时才能发送。整个数据帧有效负载包括在流控制中，包括Pad Length和Padding字段（如果存在）。如果接收到的数据帧的流未处于“打开”或“半关闭（本地）”状态，则接收方必须以stream_closed类型的流错误（第5.4.2节）进行响应。
The total number of padding octets is determined by the value of the Pad Length field. If the length of the padding is the length of the frame payload or greater, the recipient MUST treat this as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
填充八位字节的总数由“填充长度”字段的值确定。如果填充的长度等于或大于帧有效负载的长度，则接收方必须将其视为协议_错误类型的连接错误（第5.4.1节）。
Note: A frame can be increased in size by one octet by including a Pad Length field with a value of zero.
注意：通过包含一个值为零的Pad Length字段，一个帧的大小可以增加一个八位字节。
The HEADERS frame (type=0x1) is used to open a stream (Section 5.1), and additionally carries a header block fragment. HEADERS frames can be sent on a stream in the "idle", "reserved (local)", "open", or "half-closed (remote)" state.
HEADERS帧（type=0x1）用于打开一个流（第5.1节），并另外携带一个头块片段。头帧可以在“空闲”、“保留（本地）”、“打开”或“半关闭（远程）”状态的流上发送。
+---------------+
|Pad Length? (8)|
+-+-------------+-----------------------------------------------+
|E| Stream Dependency? (31) |
+-+-------------+-----------------------------------------------+
| Weight? (8) |
+-+-------------+-----------------------------------------------+
| Header Block Fragment (*) ...
+---------------------------------------------------------------+
| Padding (*) ...
+---------------------------------------------------------------+
+---------------+
|Pad Length? (8)|
+-+-------------+-----------------------------------------------+
|E| Stream Dependency? (31) |
+-+-------------+-----------------------------------------------+
| Weight? (8) |
+-+-------------+-----------------------------------------------+
| Header Block Fragment (*) ...
+---------------------------------------------------------------+
| Padding (*) ...
+---------------------------------------------------------------+
Figure 7: HEADERS Frame Payload
图7：标题帧有效负载
The HEADERS frame payload has the following fields:
标题帧有效负载具有以下字段：
Pad Length: An 8-bit field containing the length of the frame padding in units of octets. This field is only present if the PADDED flag is set.
Pad Length：一个8位字段，包含以八位字节为单位的帧填充长度。仅当设置了填充标志时，此字段才存在。
E: A single-bit flag indicating that the stream dependency is exclusive (see Section 5.3). This field is only present if the PRIORITY flag is set.
E：一个单位标志，指示流依赖是独占的（见第5.3节）。仅当设置了优先级标志时，此字段才存在。
Stream Dependency: A 31-bit stream identifier for the stream that this stream depends on (see Section 5.3). This field is only present if the PRIORITY flag is set.
流依赖性：此流所依赖的流的31位流标识符（参见第5.3节）。仅当设置了优先级标志时，此字段才存在。
Weight: An unsigned 8-bit integer representing a priority weight for the stream (see Section 5.3). Add one to the value to obtain a weight between 1 and 256. This field is only present if the PRIORITY flag is set.
权重：表示流优先级权重的无符号8位整数（见第5.3节）。将一个值添加到该值以获得介于1和256之间的权重。仅当设置了优先级标志时，此字段才存在。
Header Block Fragment: A header block fragment (Section 4.3).
标题块片段：标题块片段（第4.3节）。
Padding: Padding octets.
填充：填充八位字节。
The HEADERS frame defines the following flags:
HEADERS框架定义了以下标志：
END_STREAM (0x1): When set, bit 0 indicates that the header block (Section 4.3) is the last that the endpoint will send for the identified stream.
END_STREAM（0x1）：设置时，位0表示头块（第4.3节）是端点将为已识别流发送的最后一个头块。
A HEADERS frame carries the END_STREAM flag that signals the end of a stream. However, a HEADERS frame with the END_STREAM flag set can be followed by CONTINUATION frames on the same stream. Logically, the CONTINUATION frames are part of the HEADERS frame.
HEADERS帧携带表示流结束的END_流标志。但是，设置了END_STREAM标志的Header帧后面可以是同一流上的连续帧。从逻辑上讲，延续帧是标题帧的一部分。
END_HEADERS (0x4): When set, bit 2 indicates that this frame contains an entire header block (Section 4.3) and is not followed by any CONTINUATION frames.
END_头（0x4）：设置时，位2表示此帧包含整个头块（第4.3节），后面没有任何连续帧。
A HEADERS frame without the END_HEADERS flag set MUST be followed by a CONTINUATION frame for the same stream. A receiver MUST treat the receipt of any other type of frame or a frame on a different stream as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
没有END_HEADERS标志集的HEADERS帧后面必须跟有同一流的延续帧。接收器必须将接收到的任何其他类型的帧或不同流上的帧视为协议_错误类型的连接错误（第5.4.1节）。
PADDED (0x8): When set, bit 3 indicates that the Pad Length field and any padding that it describes are present.
PADDED（0x8）：设置时，位3表示存在Pad Length字段及其描述的任何填充。
PRIORITY (0x20): When set, bit 5 indicates that the Exclusive Flag (E), Stream Dependency, and Weight fields are present; see Section 5.3.
优先级（0x20）：设置时，位5表示存在排他标志（E）、流依赖项和权重字段；见第5.3节。
The payload of a HEADERS frame contains a header block fragment (Section 4.3). A header block that does not fit within a HEADERS frame is continued in a CONTINUATION frame (Section 6.10).
报头帧的有效载荷包含报头块片段（第4.3节）。不适合页眉框架的页眉块在延续框架中继续（第6.10节）。
HEADERS frames MUST be associated with a stream. If a HEADERS frame is received whose stream identifier field is 0x0, the recipient MUST respond with a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
标题帧必须与流相关联。如果接收到流标识符字段为0x0的HEADERS帧，则接收方必须以PROTOCOL_error类型的连接错误（第5.4.1节）进行响应。
The HEADERS frame changes the connection state as described in Section 4.3.
HEADERS框架更改连接状态，如第4.3节所述。
The HEADERS frame can include padding. Padding fields and flags are identical to those defined for DATA frames (Section 6.1). Padding that exceeds the size remaining for the header block fragment MUST be treated as a PROTOCOL_ERROR.
标题框可以包含填充。填充字段和标志与为数据帧定义的字段和标志相同（第6.1节）。超过头块片段剩余大小的填充必须视为协议错误。
Prioritization information in a HEADERS frame is logically equivalent to a separate PRIORITY frame, but inclusion in HEADERS avoids the potential for churn in stream prioritization when new streams are created. Prioritization fields in HEADERS frames subsequent to the first on a stream reprioritize the stream (Section 5.3.3).
标头框架中的优先级信息在逻辑上等同于单独的优先级框架，但在标头中包含优先级信息可以避免在创建新流时流优先级发生变化的可能性。在流上的第一个帧之后的标题帧中的优先级字段会重新确定流的优先级（第5.3.3节）。
The PRIORITY frame (type=0x2) specifies the sender-advised priority of a stream (Section 5.3). It can be sent in any stream state, including idle or closed streams.
优先级帧（类型=0x2）指定流的发送方建议优先级（第5.3节）。它可以在任何流状态下发送，包括空闲流或关闭流。
+-+-------------------------------------------------------------+
|E| Stream Dependency (31) |
+-+-------------+-----------------------------------------------+
| Weight (8) |
+-+-------------+
+-+-------------------------------------------------------------+
|E| Stream Dependency (31) |
+-+-------------+-----------------------------------------------+
| Weight (8) |
+-+-------------+
Figure 8: PRIORITY Frame Payload
图8：优先帧有效负载
The payload of a PRIORITY frame contains the following fields:
优先级帧的有效载荷包含以下字段：
E: A single-bit flag indicating that the stream dependency is exclusive (see Section 5.3).
E：一个单位标志，指示流依赖是独占的（见第5.3节）。
Stream Dependency: A 31-bit stream identifier for the stream that this stream depends on (see Section 5.3).
流依赖性：此流所依赖的流的31位流标识符（参见第5.3节）。
Weight: An unsigned 8-bit integer representing a priority weight for the stream (see Section 5.3). Add one to the value to obtain a weight between 1 and 256.
权重：表示流优先级权重的无符号8位整数（见第5.3节）。将一个值添加到该值以获得介于1和256之间的权重。
The PRIORITY frame does not define any flags.
优先级帧未定义任何标志。
The PRIORITY frame always identifies a stream. If a PRIORITY frame is received with a stream identifier of 0x0, the recipient MUST respond with a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
优先级帧始终标识流。如果接收到流标识符为0x0的优先级帧，则接收方必须以协议_错误类型的连接错误（第5.4.1节）进行响应。
The PRIORITY frame can be sent on a stream in any state, though it cannot be sent between consecutive frames that comprise a single header block (Section 4.3). Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect on the identified stream. For a stream that is in the "half-closed (remote)" or "closed" state, this frame can only affect processing of the identified stream and its dependent streams; it does not affect frame transmission on that stream.
优先级帧可以在任何状态的流上发送，但不能在构成单个头块的连续帧之间发送（第4.3节）。请注意，此帧可能在处理或帧发送完成后到达，这将导致它对已识别的流没有影响。对于处于“半关闭（远程）”或“关闭”状态的流，该帧只能影响已识别流及其从属流的处理；它不会影响该流上的帧传输。
The PRIORITY frame can be sent for a stream in the "idle" or "closed" state. This allows for the reprioritization of a group of dependent streams by altering the priority of an unused or closed parent stream.
可以针对处于“空闲”或“关闭”状态的流发送优先级帧。这允许通过改变未使用或关闭的父流的优先级来重新确定一组依赖流的优先级。
A PRIORITY frame with a length other than 5 octets MUST be treated as a stream error (Section 5.4.2) of type FRAME_SIZE_ERROR.
长度不是5个八位字节的优先帧必须被视为frame_SIZE_error类型的流错误（第5.4.2节）。
The RST_STREAM frame (type=0x3) allows for immediate termination of a stream. RST_STREAM is sent to request cancellation of a stream or to indicate that an error condition has occurred.
RST_流帧（类型=0x3）允许立即终止流。发送RST_流以请求取消流或指示出现错误情况。
+---------------------------------------------------------------+
| Error Code (32) |
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| Error Code (32) |
+---------------------------------------------------------------+
Figure 9: RST_STREAM Frame Payload
图9:RST_流帧有效负载
The RST_STREAM frame contains a single unsigned, 32-bit integer identifying the error code (Section 7). The error code indicates why the stream is being terminated.
RST_流帧包含标识错误代码的单个无符号32位整数（第7节）。错误代码指示终止流的原因。
The RST_STREAM frame does not define any flags.
RST_流帧未定义任何标志。
The RST_STREAM frame fully terminates the referenced stream and causes it to enter the "closed" state. After receiving a RST_STREAM on a stream, the receiver MUST NOT send additional frames for that stream, with the exception of PRIORITY. However, after sending the RST_STREAM, the sending endpoint MUST be prepared to receive and process additional frames sent on the stream that might have been sent by the peer prior to the arrival of the RST_STREAM.
RST_流帧完全终止引用流，并使其进入“关闭”状态。在接收到流上的RST_流后，接收器不得为该流发送附加帧，优先级除外。然而，在发送RST_流之后，发送端点必须准备好接收和处理在流上发送的附加帧，这些帧可能在RST_流到达之前由对等方发送。
RST_STREAM frames MUST be associated with a stream. If a RST_STREAM frame is received with a stream identifier of 0x0, the recipient MUST treat this as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
RST_流帧必须与流相关联。如果接收到流标识符为0x0的RST_流帧，则接收方必须将其视为协议_错误类型的连接错误（第5.4.1节）。
RST_STREAM frames MUST NOT be sent for a stream in the "idle" state. If a RST_STREAM frame identifying an idle stream is received, the recipient MUST treat this as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
不得为处于“空闲”状态的流发送RST_流帧。如果接收到标识空闲流的RST_流帧，则接收方必须将其视为协议_错误类型的连接错误（第5.4.1节）。
A RST_STREAM frame with a length other than 4 octets MUST be treated as a connection error (Section 5.4.1) of type FRAME_SIZE_ERROR.
长度不是4个八位字节的RST_流帧必须视为帧大小_错误类型的连接错误（第5.4.1节）。
The SETTINGS frame (type=0x4) conveys configuration parameters that affect how endpoints communicate, such as preferences and constraints on peer behavior. The SETTINGS frame is also used to acknowledge the receipt of those parameters. Individually, a SETTINGS parameter can also be referred to as a "setting".
设置帧（type=0x4）传递影响端点通信方式的配置参数，例如对对等行为的首选项和约束。设置框还用于确认收到这些参数。单独而言，设置参数也可称为“设置”。
SETTINGS parameters are not negotiated; they describe characteristics of the sending peer, which are used by the receiving peer. Different values for the same parameter can be advertised by each peer. For example, a client might set a high initial flow-control window, whereas a server might set a lower value to conserve resources.
未协商设置参数；它们描述发送端的特征，接收端使用这些特征。同一参数的不同值可以由每个对等方公布。例如，客户端可能会设置较高的初始流量控制窗口，而服务器可能会设置较低的值以节省资源。
A SETTINGS frame MUST be sent by both endpoints at the start of a connection and MAY be sent at any other time by either endpoint over the lifetime of the connection. Implementations MUST support all of the parameters defined by this specification.
设置帧必须在连接开始时由两个端点发送，并且可以在连接生命周期内的任何其他时间由任一端点发送。实现必须支持本规范定义的所有参数。
Each parameter in a SETTINGS frame replaces any existing value for that parameter. Parameters are processed in the order in which they appear, and a receiver of a SETTINGS frame does not need to maintain any state other than the current value of its parameters. Therefore, the value of a SETTINGS parameter is the last value that is seen by a receiver.
设置框中的每个参数都将替换该参数的任何现有值。参数按其出现的顺序进行处理，设置帧的接收器不需要保持其参数当前值以外的任何状态。因此，设置参数的值是接收器看到的最后一个值。
SETTINGS parameters are acknowledged by the receiving peer. To enable this, the SETTINGS frame defines the following flag:
设置参数由接收对等方确认。要启用此功能，设置框定义以下标志：
ACK (0x1): When set, bit 0 indicates that this frame acknowledges receipt and application of the peer's SETTINGS frame. When this bit is set, the payload of the SETTINGS frame MUST be empty. Receipt of a SETTINGS frame with the ACK flag set and a length field value other than 0 MUST be treated as a connection error (Section 5.4.1) of type FRAME_SIZE_ERROR. For more information, see Section 6.5.3 ("Settings Synchronization").
ACK（0x1）：设置时，位0表示此帧确认对等方设置帧的接收和应用。设置此位时，设置帧的有效负载必须为空。接收设置了ACK标志且长度字段值不是0的设置帧时，必须将其视为frame_SIZE_error类型的连接错误（第5.4.1节）。有关更多信息，请参阅第6.5.3节（“设置同步”）。
SETTINGS frames always apply to a connection, never a single stream. The stream identifier for a SETTINGS frame MUST be zero (0x0). If an endpoint receives a SETTINGS frame whose stream identifier field is anything other than 0x0, the endpoint MUST respond with a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
设置帧始终应用于连接，而不是单个流。设置帧的流标识符必须为零（0x0）。如果端点接收到一个设置帧，其流标识符字段不是0x0，则该端点必须以类型为PROTOCOL_error的连接错误（第5.4.1节）进行响应。
The SETTINGS frame affects connection state. A badly formed or incomplete SETTINGS frame MUST be treated as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
“设置”框会影响连接状态。格式错误或不完整的设置帧必须视为协议_错误类型的连接错误（第5.4.1节）。
A SETTINGS frame with a length other than a multiple of 6 octets MUST be treated as a connection error (Section 5.4.1) of type FRAME_SIZE_ERROR.
长度不是6个八位字节倍数的设置帧必须视为frame_SIZE_error类型的连接错误（第5.4.1节）。
The payload of a SETTINGS frame consists of zero or more parameters, each consisting of an unsigned 16-bit setting identifier and an unsigned 32-bit value.
设置帧的有效负载由零个或多个参数组成，每个参数由一个无符号16位设置标识符和一个无符号32位值组成。
+-------------------------------+
| Identifier (16) |
+-------------------------------+-------------------------------+
| Value (32) |
+---------------------------------------------------------------+
+-------------------------------+
| Identifier (16) |
+-------------------------------+-------------------------------+
| Value (32) |
+---------------------------------------------------------------+
Figure 10: Setting Format
图10：设置格式
The following parameters are defined:
定义了以下参数：
SETTINGS_HEADER_TABLE_SIZE (0x1): Allows the sender to inform the remote endpoint of the maximum size of the header compression table used to decode header blocks, in octets. The encoder can select any size equal to or less than this value by using signaling specific to the header compression format inside a header block (see [COMPRESSION]). The initial value is 4,096 octets.
设置\头\表\大小（0x1）：允许发送方通知远程端点用于解码头块的头压缩表的最大大小（以八位字节为单位）。编码器可以通过在报头块内使用特定于报头压缩格式的信令来选择等于或小于该值的任何大小（参见[压缩]）。初始值为4096个八位字节。
SETTINGS_ENABLE_PUSH (0x2): This setting can be used to disable server push (Section 8.2). An endpoint MUST NOT send a PUSH_PROMISE frame if it receives this parameter set to a value of 0. An endpoint that has both set this parameter to 0 and had it acknowledged MUST treat the receipt of a PUSH_PROMISE frame as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
设置\启用\推送（0x2）：此设置可用于禁用服务器推送（第8.2节）。如果端点接收到设置为0的此参数，则不得发送推送承诺帧。已将此参数设置为0并已确认的端点必须将接收到PUSH_承诺帧视为类型为PROTOCOL_error的连接错误（第5.4.1节）。
The initial value is 1, which indicates that server push is permitted. Any value other than 0 or 1 MUST be treated as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
初始值为1，表示允许服务器推送。必须将0或1以外的任何值视为协议_错误类型的连接错误（第5.4.1节）。
SETTINGS_MAX_CONCURRENT_STREAMS (0x3): Indicates the maximum number of concurrent streams that the sender will allow. This limit is directional: it applies to the number of streams that the sender permits the receiver to create. Initially, there is no limit to this value. It is recommended that this value be no smaller than 100, so as to not unnecessarily limit parallelism.
设置\u最大\u并发\u流（0x3）：表示发送方允许的最大并发流数。这个限制是定向的：它适用于发送方允许接收方创建的流的数量。最初，该值没有限制。建议该值不小于100，以避免不必要地限制并行性。
A value of 0 for SETTINGS_MAX_CONCURRENT_STREAMS SHOULD NOT be treated as special by endpoints. A zero value does prevent the creation of new streams; however, this can also happen for any
端点不应将设置\u MAX\u并发\u流的值0视为特殊值。零值不会阻止创建新流；然而，这也可能发生在任何情况下
limit that is exhausted with active streams. Servers SHOULD only set a zero value for short durations; if a server does not wish to accept requests, closing the connection is more appropriate.
活动流耗尽的限制。服务器只应在短时间内设置零值；如果服务器不希望接受请求，则关闭连接更合适。
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.
设置\u初始\u窗口\u大小（0x4）：指示流级流控制的发送方初始窗口大小（以八位字节为单位）。初始值为2^16-1（65535）个八位字节。
This setting affects the window size of all streams (see Section 6.9.2).
此设置影响所有流的窗口大小（见第6.9.2节）。
Values above the maximum flow-control window size of 2^31-1 MUST be treated as a connection error (Section 5.4.1) of type FLOW_CONTROL_ERROR.
超过最大流量控制窗口大小2^31-1的值必须视为流量控制错误类型的连接错误（第5.4.1节）。
SETTINGS_MAX_FRAME_SIZE (0x5): Indicates the size of the largest frame payload that the sender is willing to receive, in octets.
SETTINGS_MAX_FRAME_SIZE（0x5）：表示发送方愿意接收的最大帧有效负载的大小，以八位字节为单位。
The initial value is 2^14 (16,384) octets. The value advertised by an endpoint MUST be between this initial value and the maximum allowed frame size (2^24-1 or 16,777,215 octets), inclusive. Values outside this range MUST be treated as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
初始值为2^14（16384）个八位字节。端点公布的值必须介于该初始值和允许的最大帧大小（2^24-1或16777215个八位字节）之间（包括这两个值）。超出此范围的值必须视为协议_错误类型的连接错误（第5.4.1节）。
SETTINGS_MAX_HEADER_LIST_SIZE (0x6): This advisory setting informs a peer of the maximum size of header list that the sender is prepared to accept, in octets. The value is based on the uncompressed size of header fields, including the length of the name and value in octets plus an overhead of 32 octets for each header field.
设置\最大\头\列表\大小（0x6）：此建议设置通知对等方发送方准备接受的头列表的最大大小，以八位字节为单位。该值基于头字段的未压缩大小，包括名称和值的长度（以八位字节为单位）加上每个头字段32个八位字节的开销。
For any given request, a lower limit than what is advertised MAY be enforced. The initial value of this setting is unlimited.
对于任何给定的请求，可能会强制执行低于广告的限制。此设置的初始值是无限的。
An endpoint that receives a SETTINGS frame with any unknown or unsupported identifier MUST ignore that setting.
接收带有任何未知或不受支持标识符的设置帧的端点必须忽略该设置。
Most values in SETTINGS benefit from or require an understanding of when the peer has received and applied the changed parameter values. In order to provide such synchronization timepoints, the recipient of a SETTINGS frame in which the ACK flag is not set MUST apply the updated parameters as soon as possible upon receipt.
设置中的大多数值受益于或需要了解对等方何时接收并应用更改的参数值。为了提供此类同步时间点，未设置ACK标志的设置帧的接收者必须在收到后尽快应用更新的参数。
The values in the SETTINGS frame MUST be processed in the order they appear, with no other frame processing between values. Unsupported parameters MUST be ignored. Once all values have been processed, the
“设置”框中的值必须按其显示顺序进行处理，值之间没有其他框处理。必须忽略不支持的参数。处理完所有值后
recipient MUST immediately emit a SETTINGS frame with the ACK flag set. Upon receiving a SETTINGS frame with the ACK flag set, the sender of the altered parameters can rely on the setting having been applied.
收件人必须立即发出设置了ACK标志的设置帧。在接收到设置了ACK标志的设置帧时，更改参数的发送方可以依赖已应用的设置。
If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a connection error (Section 5.4.1) of type SETTINGS_TIMEOUT.
如果设置帧的发送方在合理的时间内未收到确认，则可能会发出设置超时类型的连接错误（第5.4.1节）。
The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint in advance of streams the sender intends to initiate. The PUSH_PROMISE frame includes the unsigned 31-bit identifier of the stream the endpoint plans to create along with a set of headers that provide additional context for the stream. Section 8.2 contains a thorough description of the use of PUSH_PROMISE frames.
推送承诺帧（type=0x5）用于在发送方打算发起的流之前通知对等端点。PUSH_PROMISE帧包括端点计划创建的流的无符号31位标识符，以及一组为流提供附加上下文的头。第8.2节详细说明了推送框架的使用。
+---------------+
|Pad Length? (8)|
+-+-------------+-----------------------------------------------+
|R| Promised Stream ID (31) |
+-+-----------------------------+-------------------------------+
| Header Block Fragment (*) ...
+---------------------------------------------------------------+
| Padding (*) ...
+---------------------------------------------------------------+
+---------------+
|Pad Length? (8)|
+-+-------------+-----------------------------------------------+
|R| Promised Stream ID (31) |
+-+-----------------------------+-------------------------------+
| Header Block Fragment (*) ...
+---------------------------------------------------------------+
| Padding (*) ...
+---------------------------------------------------------------+
Figure 11: PUSH_PROMISE Payload Format
图11：推送承诺有效负载格式
The PUSH_PROMISE frame payload has the following fields:
推送帧有效载荷具有以下字段：
Pad Length: An 8-bit field containing the length of the frame padding in units of octets. This field is only present if the PADDED flag is set.
Pad Length：一个8位字段，包含以八位字节为单位的帧填充长度。仅当设置了填充标志时，此字段才存在。
R: A single reserved bit.
R：一个保留位。
Promised Stream ID: An unsigned 31-bit integer that identifies the stream that is reserved by the PUSH_PROMISE. The promised stream identifier MUST be a valid choice for the next stream sent by the sender (see "new stream identifier" in Section 5.1.1).
承诺流ID：一个无符号的31位整数，用于标识推送承诺保留的流。承诺流标识符必须是发送方发送的下一个流的有效选择（见第5.1.1节中的“新流标识符”）。
Header Block Fragment: A header block fragment (Section 4.3) containing request header fields.
头块片段：包含请求头字段的头块片段（第4.3节）。
Padding: Padding octets.
填充：填充八位字节。
The PUSH_PROMISE frame defines the following flags:
PUSH_PROMISE框架定义了以下标志：
END_HEADERS (0x4): When set, bit 2 indicates that this frame contains an entire header block (Section 4.3) and is not followed by any CONTINUATION frames.
END_头（0x4）：设置时，位2表示此帧包含整个头块（第4.3节），后面没有任何连续帧。
A PUSH_PROMISE frame without the END_HEADERS flag set MUST be followed by a CONTINUATION frame for the same stream. A receiver MUST treat the receipt of any other type of frame or a frame on a different stream as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
未设置END_HEADERS标志的PUSH_PROMISE帧后面必须跟有同一流的延续帧。接收器必须将接收到的任何其他类型的帧或不同流上的帧视为协议_错误类型的连接错误（第5.4.1节）。
PADDED (0x8): When set, bit 3 indicates that the Pad Length field and any padding that it describes are present.
PADDED（0x8）：设置时，位3表示存在Pad Length字段及其描述的任何填充。
PUSH_PROMISE frames MUST only be sent on a peer-initiated stream that is in either the "open" or "half-closed (remote)" state. The stream identifier of a PUSH_PROMISE frame indicates the stream it is associated with. If the stream identifier field specifies the value 0x0, a recipient MUST respond with a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
推送承诺帧只能在处于“打开”或“半关闭（远程）”状态的对等启动流上发送。推送承诺帧的流标识符指示与其关联的流。如果流标识符字段指定值0x0，则收件人必须以协议_错误类型的连接错误（第5.4.1节）进行响应。
Promised streams are not required to be used in the order they are promised. The PUSH_PROMISE only reserves stream identifiers for later use.
承诺流不需要按照承诺的顺序使用。PUSH_PROMISE仅保留流标识符供以后使用。
PUSH_PROMISE MUST NOT be sent if the SETTINGS_ENABLE_PUSH setting of the peer endpoint is set to 0. An endpoint that has set this setting and has received acknowledgement MUST treat the receipt of a PUSH_PROMISE frame as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
如果对等端点的设置\u启用\u推送设置设置为0，则不得发送推送承诺。设置了此设置并接收到确认的端点必须将接收到PUSH_承诺帧视为类型为PROTOCOL_error的连接错误（第5.4.1节）。
Recipients of PUSH_PROMISE frames can choose to reject promised streams by returning a RST_STREAM referencing the promised stream identifier back to the sender of the PUSH_PROMISE.
推送承诺帧的接收者可以通过将引用承诺流标识符的RST\U流返回给推送承诺的发送者来选择拒绝承诺流。
A PUSH_PROMISE frame modifies the connection state in two ways. First, the inclusion of a header block (Section 4.3) potentially modifies the state maintained for header compression. Second, PUSH_PROMISE also reserves a stream for later use, causing the promised stream to enter the "reserved" state. A sender MUST NOT send a PUSH_PROMISE on a stream unless that stream is either "open" or "half-closed (remote)"; the sender MUST ensure that the promised stream is a valid choice for a new stream identifier (Section 5.1.1) (that is, the promised stream MUST be in the "idle" state).
推送承诺框架通过两种方式修改连接状态。首先，包含头块（第4.3节）可能会修改为头压缩维护的状态。其次，PUSH_PROMISE还保留一个流供以后使用，导致承诺的流进入“保留”状态。发送方不得在流上发送推送承诺，除非该流是“打开”或“半关闭（远程）”的；发送方必须确保承诺流是新流标识符的有效选择（第5.1.1节）（即承诺流必须处于“空闲”状态）。
Since PUSH_PROMISE reserves a stream, ignoring a PUSH_PROMISE frame causes the stream state to become indeterminate. A receiver MUST treat the receipt of a PUSH_PROMISE on a stream that is neither "open" nor "half-closed (local)" as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. However, an endpoint that has sent RST_STREAM on the associated stream MUST handle PUSH_PROMISE frames that might have been created before the RST_STREAM frame is received and processed.
由于PUSH_承诺保留一个流，因此忽略PUSH_承诺帧会导致流状态变得不确定。接收方必须将在既不是“开放”也不是“半封闭（本地）”的流上接收推送承诺视为协议错误类型的连接错误（第5.4.1节）。但是，在关联流上发送RST_流的端点必须处理可能在接收和处理RST_流帧之前创建的推送承诺帧。
A receiver MUST treat the receipt of a PUSH_PROMISE that promises an illegal stream identifier (Section 5.1.1) as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. Note that an illegal stream identifier is an identifier for a stream that is not currently in the "idle" state.
接收方必须将接收到承诺非法流标识符（第5.1.1节）的PUSH_承诺视为协议_错误类型的连接错误（第5.4.1节）。请注意，非法流标识符是当前未处于“空闲”状态的流的标识符。
The PUSH_PROMISE frame can include padding. Padding fields and flags are identical to those defined for DATA frames (Section 6.1).
推送框架可以包括填充。填充字段和标志与为数据帧定义的字段和标志相同（第6.1节）。
The PING frame (type=0x6) is a mechanism for measuring a minimal round-trip time from the sender, as well as determining whether an idle connection is still functional. PING frames can be sent from any endpoint.
PING帧（type=0x6）是一种机制，用于测量来自发送方的最小往返时间，以及确定空闲连接是否仍然有效。PING帧可以从任何端点发送。
+---------------------------------------------------------------+
| |
| Opaque Data (64) |
| |
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| |
| Opaque Data (64) |
| |
+---------------------------------------------------------------+
Figure 12: PING Payload Format
图12:PING有效负载格式
In addition to the frame header, PING frames MUST contain 8 octets of opaque data in the payload. A sender can include any value it chooses and use those octets in any fashion.
除了帧头，PING帧必须在有效负载中包含8个八位字节的不透明数据。发送方可以包含它选择的任何值，并以任何方式使用这些八位字节。
Receivers of a PING frame that does not include an ACK flag MUST send a PING frame with the ACK flag set in response, with an identical payload. PING responses SHOULD be given higher priority than any other frame.
不包括ACK标志的PING帧的接收器必须发送一个PING帧，并在应答中设置ACK标志，有效负载相同。PING响应的优先级应高于任何其他帧。
The PING frame defines the following flags:
PING框架定义了以下标志：
ACK (0x1): When set, bit 0 indicates that this PING frame is a PING response. An endpoint MUST set this flag in PING responses. An endpoint MUST NOT respond to PING frames containing this flag.
ACK（0x1）：设置时，位0表示此PING帧是PING响应。端点必须在PING响应中设置此标志。端点不得响应包含此标志的PING帧。
PING frames are not associated with any individual stream. If a PING frame is received with a stream identifier field value other than 0x0, the recipient MUST respond with a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
PING帧不与任何单个流相关联。如果接收到的PING帧的流标识符字段值不是0x0，则接收方必须以PROTOCOL_error类型的连接错误（第5.4.1节）进行响应。
Receipt of a PING frame with a length field value other than 8 MUST be treated as a connection error (Section 5.4.1) of type FRAME_SIZE_ERROR.
收到长度字段值不是8的PING帧时，必须将其视为frame_SIZE_error类型的连接错误（第5.4.1节）。
The GOAWAY frame (type=0x7) is used to initiate shutdown of a connection or to signal serious error conditions. GOAWAY allows an endpoint to gracefully stop accepting new streams while still finishing processing of previously established streams. This enables administrative actions, like server maintenance.
GOAWAY帧（类型=0x7）用于启动连接关闭或发出严重错误条件的信号。GOAWAY允许端点优雅地停止接受新流，同时仍然完成对先前建立的流的处理。这将启用管理操作，如服务器维护。
There is an inherent race condition between an endpoint starting new streams and the remote sending a GOAWAY frame. To deal with this case, the GOAWAY contains the stream identifier of the last peer-initiated stream that was or might be processed on the sending endpoint in this connection. For instance, if the server sends a GOAWAY frame, the identified stream is the highest-numbered stream initiated by the client.
在启动新流的端点和远程发送GOAWAY帧之间存在固有的竞争条件。为了处理这种情况，GOAWAY包含上次对等启动的流的流标识符，该流已经或可能在该连接的发送端点上处理。例如，如果服务器发送GOAWAY帧，则标识的流是由客户端启动的编号最高的流。
Once sent, the sender will ignore frames sent on streams initiated by the receiver if the stream has an identifier higher than the included last stream identifier. Receivers of a GOAWAY frame MUST NOT open additional streams on the connection, although a new connection can be established for new streams.
一旦发送，如果流的标识符高于包含的最后一个流标识符，则发送方将忽略在由接收方发起的流上发送的帧。尽管可以为新的流建立新的连接，但球门框架的接收器不得在连接上打开额外的流。
If the receiver of the GOAWAY has sent data on streams with a higher stream identifier than what is indicated in the GOAWAY frame, those streams are not or will not be processed. The receiver of the GOAWAY frame can treat the streams as though they had never been created at all, thereby allowing those streams to be retried later on a new connection.
如果GOAWAY接收器发送的数据流标识符高于GOAWAY帧中指示的数据流标识符，则不会或不会处理这些数据流。GOAWAY帧的接收器可以将流视为从未创建过的流，从而允许稍后在新连接上重试这些流。
Endpoints SHOULD always send a GOAWAY frame before closing a connection so that the remote peer can know whether a stream has been partially processed or not. For example, if an HTTP client sends a POST at the same time that a server closes a connection, the client cannot know if the server started to process that POST request if the server does not send a GOAWAY frame to indicate what streams it might have acted on.
端点应始终在关闭连接之前发送GOAWAY帧，以便远程对等方可以知道流是否已被部分处理。例如，如果HTTP客户端在服务器关闭连接的同时发送POST，则如果服务器未发送GOAWAY帧以指示其可能对哪些流采取了操作，则客户端无法知道服务器是否已开始处理该POST请求。
An endpoint might choose to close a connection without sending a GOAWAY for misbehaving peers.
端点可以选择关闭连接，而不向行为不端的对等方发送GOAWAY。
A GOAWAY frame might not immediately precede closing of the connection; a receiver of a GOAWAY that has no more use for the connection SHOULD still send a GOAWAY frame before terminating the connection.
在连接关闭之前，门洞框架可能不会立即关闭；不再用于连接的球门接收器在终止连接之前仍应发送球门帧。
+-+-------------------------------------------------------------+
|R| Last-Stream-ID (31) |
+-+-------------------------------------------------------------+
| Error Code (32) |
+---------------------------------------------------------------+
| Additional Debug Data (*) |
+---------------------------------------------------------------+
+-+-------------------------------------------------------------+
|R| Last-Stream-ID (31) |
+-+-------------------------------------------------------------+
| Error Code (32) |
+---------------------------------------------------------------+
| Additional Debug Data (*) |
+---------------------------------------------------------------+
Figure 13: GOAWAY Payload Format
图13：GOAWAY有效载荷格式
The GOAWAY frame does not define any flags.
GOAWAY框架不定义任何标志。
The GOAWAY frame applies to the connection, not a specific stream. An endpoint MUST treat a GOAWAY frame with a stream identifier other than 0x0 as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
GOAWAY框架适用于连接，而不是特定流。端点必须将具有除0x0以外的流标识符的GOAWAY帧视为类型为PROTOCOL_error的连接错误（第5.4.1节）。
The last stream identifier in the GOAWAY frame contains the highest-numbered stream identifier for which the sender of the GOAWAY frame might have taken some action on or might yet take action on. All streams up to and including the identified stream might have been processed in some way. The last stream identifier can be set to 0 if no streams were processed.
GOAWAY帧中的最后一个流标识符包含编号最高的流标识符，GOAWAY帧的发送方可能已对该流标识符采取了某些操作，或者可能尚未对其采取操作。可能已经以某种方式处理了标识流之前和包括标识流在内的所有流。如果未处理任何流，则可以将最后一个流标识符设置为0。
Note: In this context, "processed" means that some data from the stream was passed to some higher layer of software that might have taken some action as a result.
注意：在这个上下文中，“已处理”意味着流中的一些数据被传递到可能已采取某些操作的更高软件层。
If a connection terminates without a GOAWAY frame, the last stream identifier is effectively the highest possible stream identifier.
如果连接在没有GOAWAY帧的情况下终止，则最后一个流标识符实际上是可能的最高流标识符。
On streams with lower- or equal-numbered identifiers that were not closed completely prior to the connection being closed, reattempting requests, transactions, or any protocol activity is not possible, with the exception of idempotent actions like HTTP GET, PUT, or DELETE. Any protocol activity that uses higher-numbered streams can be safely retried using a new connection.
在具有编号较低或相等的标识符且在连接关闭之前未完全关闭的流上，除了HTTP GET、PUT或DELETE等幂等操作外，无法重新尝试请求、事务或任何协议活动。任何使用编号较高的流的协议活动都可以使用新连接安全地重试。
Activity on streams numbered lower or equal to the last stream identifier might still complete successfully. The sender of a GOAWAY frame might gracefully shut down a connection by sending a GOAWAY frame, maintaining the connection in an "open" state until all in-progress streams complete.
编号低于或等于最后一个流标识符的流上的活动仍可能成功完成。GOAWAY帧的发送方可以通过发送GOAWAY帧优雅地关闭连接，将连接保持在“打开”状态，直到所有正在进行的流完成。
An endpoint MAY send multiple GOAWAY frames if circumstances change. For instance, an endpoint that sends GOAWAY with NO_ERROR during graceful shutdown could subsequently encounter a condition that requires immediate termination of the connection. The last stream identifier from the last GOAWAY frame received indicates which streams could have been acted upon. Endpoints MUST NOT increase the value they send in the last stream identifier, since the peers might already have retried unprocessed requests on another connection.
如果环境发生变化，端点可能会发送多个GOAWAY帧。例如，在正常关机过程中发送GOAWAY而不出错的端点可能随后遇到需要立即终止连接的情况。接收到的最后一个GOAWAY帧的最后一个流标识符指示可能对哪些流进行了操作。端点不得增加其在最后一个流标识符中发送的值，因为对等方可能已经在另一个连接上重试了未处理的请求。
A client that is unable to retry requests loses all requests that are in flight when the server closes the connection. This is especially true for intermediaries that might not be serving clients using HTTP/2. A server that is attempting to gracefully shut down a connection SHOULD send an initial GOAWAY frame with the last stream identifier set to 2^31-1 and a NO_ERROR code. This signals to the client that a shutdown is imminent and that initiating further requests is prohibited. After allowing time for any in-flight stream creation (at least one round-trip time), the server can send another GOAWAY frame with an updated last stream identifier. This ensures that a connection can be cleanly shut down without losing requests.
当服务器关闭连接时，无法重试请求的客户端将丢失正在运行的所有请求。对于可能没有使用HTTP/2为客户机提供服务的中介体来说，这尤其如此。试图正常关闭连接的服务器应发送一个初始GOAWAY帧，最后一个流标识符设置为2^31-1，并且无错误代码。这会向客户端发出关闭即将发生的信号，并且禁止启动进一步的请求。在为任何飞行中的流创建留出时间（至少一个往返时间）后，服务器可以发送另一个带有更新的最后一个流标识符的GOAWAY帧。这确保了连接可以干净地关闭，而不会丢失请求。
After sending a GOAWAY frame, the sender can discard frames for streams initiated by the receiver with identifiers higher than the identified last stream. However, any frames that alter connection state cannot be completely ignored. For instance, HEADERS, PUSH_PROMISE, and CONTINUATION frames MUST be minimally processed to ensure the state maintained for header compression is consistent (see Section 4.3); similarly, DATA frames MUST be counted toward the connection flow-control window. Failure to process these frames can cause flow control or header compression state to become unsynchronized.
在发送GOAWAY帧之后，发送方可以丢弃由接收方发起的具有高于所识别的最后一个流的标识符的流的帧。但是，不能完全忽略任何改变连接状态的帧。例如，必须对报头、PUSH_PROMISE和延续帧进行最低限度的处理，以确保为报头压缩保持的状态是一致的（参见第4.3节）；类似地，数据帧必须向连接流控制窗口计数。未能处理这些帧可能会导致流控制或标头压缩状态变得不同步。
The GOAWAY frame also contains a 32-bit error code (Section 7) that contains the reason for closing the connection.
GOAWAY帧还包含一个32位错误代码（第7节），其中包含关闭连接的原因。
Endpoints MAY append opaque data to the payload of any GOAWAY frame. Additional debug data is intended for diagnostic purposes only and carries no semantic value. Debug information could contain security-or privacy-sensitive data. Logged or otherwise persistently stored debug data MUST have adequate safeguards to prevent unauthorized access.
端点可以将不透明数据附加到任何GOAWAY帧的有效负载。附加调试数据仅用于诊断目的，不带语义值。调试信息可能包含安全或隐私敏感数据。记录的或以其他方式持久存储的调试数据必须具有足够的保护措施，以防止未经授权的访问。
The WINDOW_UPDATE frame (type=0x8) is used to implement flow control; see Section 5.2 for an overview.
窗口更新帧（类型=0x8）用于实现流量控制；有关概述，请参见第5.2节。
Flow control operates at two levels: on each individual stream and on the entire connection.
流量控制在两个级别上运行：在每个单独的流上和在整个连接上。
Both types of flow control are hop by hop, that is, only between the two endpoints. Intermediaries do not forward WINDOW_UPDATE frames between dependent connections. However, throttling of data transfer by any receiver can indirectly cause the propagation of flow-control information toward the original sender.
这两种类型的流控制都是逐跳的，即仅在两个端点之间。中间层不转发依赖连接之间的窗口更新帧。但是，任何接收器对数据传输的限制都会间接导致流控制信息向原始发送方传播。
Flow control only applies to frames that are identified as being subject to flow control. Of the frame types defined in this document, this includes only DATA frames. Frames that are exempt from flow control MUST be accepted and processed, unless the receiver is unable to assign resources to handling the frame. A receiver MAY respond with a stream error (Section 5.4.2) or connection error (Section 5.4.1) of type FLOW_CONTROL_ERROR if it is unable to accept a frame.
流量控制仅适用于标识为受流量控制的帧。在本文档中定义的帧类型中，这仅包括数据帧。必须接受和处理免于流控制的帧，除非接收方无法分配资源来处理该帧。如果接收器无法接受帧，则可能会以流控制错误类型的流错误（第5.4.2节）或连接错误（第5.4.1节）作出响应。
+-+-------------------------------------------------------------+
|R| Window Size Increment (31) |
+-+-------------------------------------------------------------+
+-+-------------------------------------------------------------+
|R| Window Size Increment (31) |
+-+-------------------------------------------------------------+
Figure 14: WINDOW_UPDATE Payload Format
图14：窗口更新有效负载格式
The payload of a WINDOW_UPDATE frame is one reserved bit plus an unsigned 31-bit integer indicating the number of octets that the sender can transmit in addition to the existing flow-control window. The legal range for the increment to the flow-control window is 1 to 2^31-1 (2,147,483,647) octets.
窗口更新帧的有效负载是一个保留位加上一个无符号的31位整数，该整数指示除了现有的流控制窗口之外，发送方可以传输的八位字节数。流量控制窗口增量的法定范围为1到2^31-1（2147483647）个八位字节。
The WINDOW_UPDATE frame does not define any flags.
窗口更新框架未定义任何标志。
The WINDOW_UPDATE frame can be specific to a stream or to the entire connection. In the former case, the frame's stream identifier indicates the affected stream; in the latter, the value "0" indicates that the entire connection is the subject of the frame.
窗口更新帧可以特定于流或整个连接。在前一种情况下，帧的流标识符指示受影响的流；在后者中，值“0”表示整个连接是帧的主体。
A receiver MUST treat the receipt of a WINDOW_UPDATE frame with an flow-control window increment of 0 as a stream error (Section 5.4.2) of type PROTOCOL_ERROR; errors on the connection flow-control window MUST be treated as a connection error (Section 5.4.1).
接收器必须将接收到的流控制窗口增量为0的窗口更新帧视为协议错误类型的流错误（第5.4.2节）；连接流控制窗口上的错误必须视为连接错误（第5.4.1节）。
WINDOW_UPDATE can be sent by a peer that has sent a frame bearing the END_STREAM flag. This means that a receiver could receive a WINDOW_UPDATE frame on a "half-closed (remote)" or "closed" stream. A receiver MUST NOT treat this as an error (see Section 5.1).
窗口更新可以由发送带有结束流标志的帧的对等方发送。这意味着接收器可以在“半关闭（远程）”或“关闭”流上接收窗口更新帧。接收方不得将其视为错误（见第5.1节）。
A receiver that receives a flow-controlled frame MUST always account for its contribution against the connection flow-control window, unless the receiver treats this as a connection error (Section 5.4.1). This is necessary even if the frame is in error. The sender counts the frame toward the flow-control window, but if the receiver does not, the flow-control window at the sender and receiver can become different.
接收流量控制帧的接收器必须始终说明其对连接流量控制窗口的贡献，除非接收器将其视为连接错误（第5.4.1节）。即使帧出错，这也是必要的。发送方向流量控制窗口计数帧，但如果接收方不计数，发送方和接收方的流量控制窗口可能会不同。
A WINDOW_UPDATE frame with a length other than 4 octets MUST be treated as a connection error (Section 5.4.1) of type FRAME_SIZE_ERROR.
长度不是4个八位字节的窗口更新帧必须视为帧大小错误类型的连接错误（第5.4.1节）。
Flow control in HTTP/2 is implemented using a window kept by each sender on every stream. The flow-control window is a simple integer value that indicates how many octets of data the sender is permitted to transmit; as such, its size is a measure of the buffering capacity of the receiver.
HTTP/2中的流控制是使用每个发送方在每个流上保留的窗口来实现的。流量控制窗口是一个简单的整数值，表示允许发送方传输多少个八位字节的数据；因此，其大小是接收机缓冲容量的度量。
Two flow-control windows are applicable: the stream flow-control window and the connection flow-control window. The sender MUST NOT send a flow-controlled frame with a length that exceeds the space available in either of the flow-control windows advertised by the receiver. Frames with zero length with the END_STREAM flag set (that is, an empty DATA frame) MAY be sent if there is no available space in either flow-control window.
两个流量控制窗口适用：流流量控制窗口和连接流量控制窗口。发送方发送的流控制帧的长度不得超过接收方公布的任何一个流控制窗口中的可用空间。如果任一流控制窗口中没有可用空间，则可以发送长度为零且设置了END_STREAM标志的帧（即，空数据帧）。
For flow-control calculations, the 9-octet frame header is not counted.
对于流量控制计算，9-octet帧头不计算在内。
After sending a flow-controlled frame, the sender reduces the space available in both windows by the length of the transmitted frame.
在发送流控制帧之后，发送方将两个窗口中的可用空间减少传输帧的长度。
The receiver of a frame sends a WINDOW_UPDATE frame as it consumes data and frees up space in flow-control windows. Separate WINDOW_UPDATE frames are sent for the stream- and connection-level flow-control windows.
帧的接收器在消耗数据并释放流控制窗口中的空间时发送一个窗口更新帧。为流级和连接级流控制窗口发送单独的窗口更新帧。
A sender that receives a WINDOW_UPDATE frame updates the corresponding window by the amount specified in the frame.
接收窗口更新帧的发送方按照帧中指定的数量更新相应的窗口。
A sender MUST NOT allow a flow-control window to exceed 2^31-1 octets. If a sender receives a WINDOW_UPDATE that causes a flow-control window to exceed this maximum, it MUST terminate either the stream or the connection, as appropriate. For streams, the sender sends a RST_STREAM with an error code of FLOW_CONTROL_ERROR; for the connection, a GOAWAY frame with an error code of FLOW_CONTROL_ERROR is sent.
发送方不得允许流量控制窗口超过2^31-1个八位字节。如果发送方收到导致流控制窗口超过此最大值的窗口更新，则它必须终止流或连接（视情况而定）。对于流，发送方发送带有错误代码FLOW_CONTROL_error的RST_流；对于连接，发送带有错误代码FLOW\u CONTROL\u error的GOAWAY帧。
Flow-controlled frames from the sender and WINDOW_UPDATE frames from the receiver are completely asynchronous with respect to each other. This property allows a receiver to aggressively update the window size kept by the sender to prevent streams from stalling.
来自发送方的流控制帧和来自接收方的窗口更新帧彼此完全异步。此属性允许接收方主动更新发送方保持的窗口大小，以防止流暂停。
When an HTTP/2 connection is first established, new streams are created with an initial flow-control window size of 65,535 octets. The connection flow-control window is also 65,535 octets. Both endpoints can adjust the initial window size for new streams by including a value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame that forms part of the connection preface. The connection flow-control window can only be changed using WINDOW_UPDATE frames.
首次建立HTTP/2连接时，将创建初始流量控制窗口大小为65535个八位字节的新流。连接流控制窗口也是65535个八位字节。两个端点都可以调整新流的初始窗口大小，方法是在构成连接的一部分的“设置”框中包含“设置”\u“初始”\u“窗口”\u“大小”的值。连接流控制窗口只能使用窗口更新框架进行更改。
Prior to receiving a SETTINGS frame that sets a value for SETTINGS_INITIAL_WINDOW_SIZE, an endpoint can only use the default initial window size when sending flow-controlled frames. Similarly, the connection flow-control window is set to the default initial window size until a WINDOW_UPDATE frame is received.
在接收设置值为“设置”\u“初始”\u“窗口大小”的设置帧之前，端点在发送流控制帧时只能使用默认的初始窗口大小。类似地，连接流控制窗口设置为默认初始窗口大小，直到收到窗口更新帧。
In addition to changing the flow-control window for streams that are not yet active, a SETTINGS frame can alter the initial flow-control window size for streams with active flow-control windows (that is, streams in the "open" or "half-closed (remote)" state). When the value of SETTINGS_INITIAL_WINDOW_SIZE changes, a receiver MUST adjust the size of all stream flow-control windows that it maintains by the difference between the new value and the old value.
除了更改尚未活动的流的流量控制窗口外，设置框还可以更改具有活动流量控制窗口的流（即处于“打开”或“半关闭（远程）”状态的流）的初始流量控制窗口大小。当设置值\u初始值\u窗口大小\u改变时，接收器必须通过新值和旧值之间的差值调整其保持的所有流控制窗口的大小。
A change to SETTINGS_INITIAL_WINDOW_SIZE can cause the available space in a flow-control window to become negative. A sender MUST track the negative flow-control window and MUST NOT send new flow-controlled frames until it receives WINDOW_UPDATE frames that cause the flow-control window to become positive.
更改设置\初始\窗口\大小会导致流量控制窗口中的可用空间变为负值。发送方必须跟踪负流量控制窗口，并且在收到导致流量控制窗口变为正的窗口更新帧之前，不得发送新的流量控制帧。
For example, if the client sends 60 KB immediately on connection establishment and the server sets the initial window size to be 16 KB, the client will recalculate the available flow-control window to
例如，如果客户机在建立连接时立即发送60 KB，而服务器将初始窗口大小设置为16 KB，则客户机将重新计算可用的流控制窗口
be -44 KB on receipt of the SETTINGS frame. The client retains a negative flow-control window until WINDOW_UPDATE frames restore the window to being positive, after which the client can resume sending.
在收到设置帧时为-44 KB。客户端保留负流量控制窗口，直到窗口更新帧将窗口恢复为正，然后客户端可以恢复发送。
A SETTINGS frame cannot alter the connection flow-control window.
设置框架无法更改连接流控制窗口。
An endpoint MUST treat a change to SETTINGS_INITIAL_WINDOW_SIZE that causes any flow-control window to exceed the maximum size as a connection error (Section 5.4.1) of type FLOW_CONTROL_ERROR.
端点必须将导致任何流控制窗口超过最大大小的设置\初始\窗口\大小更改视为流\控制\错误类型的连接错误（第5.4.1节）。
A receiver that wishes to use a smaller flow-control window than the current size can send a new SETTINGS frame. However, the receiver MUST be prepared to receive data that exceeds this window size, since the sender might send data that exceeds the lower limit prior to processing the SETTINGS frame.
希望使用小于当前大小的流量控制窗口的接收器可以发送新的设置帧。但是，接收方必须准备接收超过此窗口大小的数据，因为发送方可能在处理设置帧之前发送超过下限的数据。
After sending a SETTINGS frame that reduces the initial flow-control window size, a receiver MAY continue to process streams that exceed flow-control limits. Allowing streams to continue does not allow the receiver to immediately reduce the space it reserves for flow-control windows. Progress on these streams can also stall, since WINDOW_UPDATE frames are needed to allow the sender to resume sending. The receiver MAY instead send a RST_STREAM with an error code of FLOW_CONTROL_ERROR for the affected streams.
在发送减小初始流量控制窗口大小的设置帧之后，接收器可以继续处理超过流量控制限制的流。允许流继续不允许接收器立即减少其为流控制窗口保留的空间。这些流上的进度也可能停滞，因为需要窗口更新帧来允许发送方恢复发送。接收机可以改为发送具有针对受影响流的流控制错误的错误代码的RST流。
The CONTINUATION frame (type=0x9) is used to continue a sequence of header block fragments (Section 4.3). Any number of CONTINUATION frames can be sent, as long as the preceding frame is on the same stream and is a HEADERS, PUSH_PROMISE, or CONTINUATION frame without the END_HEADERS flag set.
延续帧（类型=0x9）用于延续标题块片段序列（第4.3节）。可以发送任意数量的连续帧，只要前一帧在同一流上，并且是未设置END_HEADERS标志的Header、PUSH_PROMISE或连续帧。
+---------------------------------------------------------------+
| Header Block Fragment (*) ...
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| Header Block Fragment (*) ...
+---------------------------------------------------------------+
Figure 15: CONTINUATION Frame Payload
图15：连续帧有效载荷
The CONTINUATION frame payload contains a header block fragment (Section 4.3).
连续帧有效载荷包含一个头块片段（第4.3节）。
The CONTINUATION frame defines the following flag:
延续帧定义了以下标志：
END_HEADERS (0x4): When set, bit 2 indicates that this frame ends a header block (Section 4.3).
END_头（0x4）：设置时，位2表示此帧结束头块（第4.3节）。
If the END_HEADERS bit is not set, this frame MUST be followed by another CONTINUATION frame. A receiver MUST treat the receipt of any other type of frame or a frame on a different stream as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
如果未设置END_HEADERS位，则此帧后面必须紧跟另一个连续帧。接收器必须将接收到的任何其他类型的帧或不同流上的帧视为协议_错误类型的连接错误（第5.4.1节）。
The CONTINUATION frame changes the connection state as defined in Section 4.3.
延续框架改变了第4.3节中定义的连接状态。
CONTINUATION frames MUST be associated with a stream. If a CONTINUATION frame is received whose stream identifier field is 0x0, the recipient MUST respond with a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
连续帧必须与流相关联。如果接收到流标识符字段为0x0的连续帧，则接收方必须以协议_错误类型的连接错误（第5.4.1节）进行响应。
A CONTINUATION frame MUST be preceded by a HEADERS, PUSH_PROMISE or CONTINUATION frame without the END_HEADERS flag set. A recipient that observes violation of this rule MUST respond with a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
连续帧之前必须有标头、PUSH_PROMISE或未设置END_HEADERS标志的连续帧。观察到违反此规则的收件人必须以协议_错误类型的连接错误（第5.4.1节）进行响应。
Error codes are 32-bit fields that are used in RST_STREAM and GOAWAY frames to convey the reasons for the stream or connection error.
错误代码是在RST_流和GOAWAY帧中使用的32位字段，用于传达流或连接错误的原因。
Error codes share a common code space. Some error codes apply only to either streams or the entire connection and have no defined semantics in the other context.
错误代码共享一个公共代码空间。某些错误代码仅适用于流或整个连接，并且在其他上下文中没有定义的语义。
The following error codes are defined:
定义了以下错误代码：
NO_ERROR (0x0): The associated condition is not a result of an error. For example, a GOAWAY might include this code to indicate graceful shutdown of a connection.
无错误（0x0）：关联条件不是错误的结果。例如，GOAWAY可能包含此代码以指示连接正常关闭。
PROTOCOL_ERROR (0x1): The endpoint detected an unspecific protocol error. This error is for use when a more specific error code is not available.
协议错误（0x1）：终结点检测到非特定协议错误。此错误用于没有更具体的错误代码时。
INTERNAL_ERROR (0x2): The endpoint encountered an unexpected internal error.
内部错误（0x2）：终结点遇到意外的内部错误。
FLOW_CONTROL_ERROR (0x3): The endpoint detected that its peer violated the flow-control protocol.
流控制错误（0x3）：终结点检测到其对等方违反了流控制协议。
SETTINGS_TIMEOUT (0x4): The endpoint sent a SETTINGS frame but did not receive a response in a timely manner. See Section 6.5.3 ("Settings Synchronization").
设置\u超时（0x4）：端点发送了设置帧，但未及时收到响应。见第6.5.3节（“设置同步”）。
STREAM_CLOSED (0x5): The endpoint received a frame after a stream was half-closed.
STREAM_CLOSED（0x5）：端点在流半关闭后接收到帧。
FRAME_SIZE_ERROR (0x6): The endpoint received a frame with an invalid size.
帧大小错误（0x6）：终结点收到的帧大小无效。
REFUSED_STREAM (0x7): The endpoint refused the stream prior to performing any application processing (see Section 8.1.4 for details).
拒绝的_流（0x7）：端点在执行任何应用程序处理之前拒绝流（有关详细信息，请参阅第8.1.4节）。
CANCEL (0x8): Used by the endpoint to indicate that the stream is no longer needed.
CANCEL（0x8）：端点使用它来指示不再需要流。
COMPRESSION_ERROR (0x9): The endpoint is unable to maintain the header compression context for the connection.
压缩_错误（0x9）：终结点无法维护连接的标头压缩上下文。
CONNECT_ERROR (0xa): The connection established in response to a CONNECT request (Section 8.3) was reset or abnormally closed.
CONNECT_错误（0xa）：响应连接请求（第8.3节）建立的连接被重置或异常关闭。
ENHANCE_YOUR_CALM (0xb): The endpoint detected that its peer is exhibiting a behavior that might be generating excessive load.
增强您的冷静（0xb）：端点检测到其对等方表现出可能产生过多负载的行为。
INADEQUATE_SECURITY (0xc): The underlying transport has properties that do not meet minimum security requirements (see Section 9.2).
_安全性不足（0xc）：基础传输的属性不符合最低安全要求（请参见第9.2节）。
HTTP_1_1_REQUIRED (0xd): The endpoint requires that HTTP/1.1 be used instead of HTTP/2.
HTTP_1_1_REQUIRED（0xd）：端点要求使用HTTP/1.1而不是HTTP/2。
Unknown or unsupported error codes MUST NOT trigger any special behavior. These MAY be treated by an implementation as being equivalent to INTERNAL_ERROR.
未知或不受支持的错误代码不得触发任何特殊行为。这些可能被实现视为等同于内部错误。
HTTP/2 is intended to be as compatible as possible with current uses of HTTP. This means that, from the application perspective, the features of the protocol are largely unchanged. To achieve this, all request and response semantics are preserved, although the syntax of conveying those semantics has changed.
HTTP/2旨在与HTTP的当前使用尽可能兼容。这意味着，从应用程序的角度来看，协议的特性基本上没有变化。为了实现这一点，保留了所有请求和响应语义，尽管传递这些语义的语法已经改变。
Thus, the specification and requirements of HTTP/1.1 Semantics and Content [RFC7231], Conditional Requests [RFC7232], Range Requests [RFC7233], Caching [RFC7234], and Authentication [RFC7235] are applicable to HTTP/2. Selected portions of HTTP/1.1 Message Syntax
因此，HTTP/1.1语义和内容[RFC7231]、条件请求[RFC7232]、范围请求[RFC7233]、缓存[RFC7234]和身份验证[RFC7235]的规范和要求适用于HTTP/2。HTTP/1.1消息语法的选定部分
and Routing [RFC7230], such as the HTTP and HTTPS URI schemes, are also applicable in HTTP/2, but the expression of those semantics for this protocol are defined in the sections below.
和路由[RFC7230]，例如HTTP和HTTPS URI方案，也适用于HTTP/2，但是这些协议语义的表达在下面的部分中定义。
A client sends an HTTP request on a new stream, using a previously unused stream identifier (Section 5.1.1). A server sends an HTTP response on the same stream as the request.
客户端使用以前未使用的流标识符在新流上发送HTTP请求（第5.1.1节）。服务器在与请求相同的流上发送HTTP响应。
An HTTP message (request or response) consists of:
HTTP消息（请求或响应）包括：
1. for a response only, zero or more HEADERS frames (each followed by zero or more CONTINUATION frames) containing the message headers of informational (1xx) HTTP responses (see [RFC7230], Section 3.2 and [RFC7231], Section 6.2),
1. 仅对于响应而言，包含信息性（1xx）HTTP响应的消息头的零个或多个头帧（每个后接零个或多个继续帧）（参见[RFC7230]，第3.2节和[RFC7231]第6.2节），
2. one HEADERS frame (followed by zero or more CONTINUATION frames) containing the message headers (see [RFC7230], Section 3.2),
2. 一个包含消息头的头帧（后跟零个或多个连续帧）（参见[RFC7230]，第3.2节），
3. zero or more DATA frames containing the payload body (see [RFC7230], Section 3.3), and
3. 包含有效载荷主体的零个或多个数据帧（参见[RFC7230]，第3.3节），以及
4. optionally, one HEADERS frame, followed by zero or more CONTINUATION frames containing the trailer-part, if present (see [RFC7230], Section 4.1.2).
4. （可选）一个标题帧，后跟零个或多个包含拖车零件的连续帧（如果存在）（参见[RFC7230]，第4.1.2节）。
The last frame in the sequence bears an END_STREAM flag, noting that a HEADERS frame bearing the END_STREAM flag can be followed by CONTINUATION frames that carry any remaining portions of the header block.
序列中的最后一帧带有END_流标志，注意，带有END_流标志的报头帧后面可以是承载报头块的任何剩余部分的连续帧。
Other frames (from any stream) MUST NOT occur between the HEADERS frame and any CONTINUATION frames that might follow.
其他帧（来自任何流）不得出现在标题帧和随后的任何继续帧之间。
HTTP/2 uses DATA frames to carry message payloads. The "chunked" transfer encoding defined in Section 4.1 of [RFC7230] MUST NOT be used in HTTP/2.
HTTP/2使用数据帧来承载消息有效负载。[RFC7230]第4.1节中定义的“分块”传输编码不得用于HTTP/2。
Trailing header fields are carried in a header block that also terminates the stream. Such a header block is a sequence starting with a HEADERS frame, followed by zero or more CONTINUATION frames, where the HEADERS frame bears an END_STREAM flag. Header blocks after the first that do not terminate the stream are not part of an HTTP request or response.
尾部标头字段在也终止流的标头块中携带。这样的报头块是以报头帧开始的序列，后跟零个或多个连续帧，其中报头帧带有结束流标志。不终止流的第一个之后的头块不是HTTP请求或响应的一部分。
A HEADERS frame (and associated CONTINUATION frames) can only appear at the start or end of a stream. An endpoint that receives a HEADERS frame without the END_STREAM flag set after receiving a final (non-informational) status code MUST treat the corresponding request or response as malformed (Section 8.1.2.6).
标题帧（和关联的继续帧）只能出现在流的开始或结束处。接收到最终（非信息性）状态代码后，接收未设置END_STREAM标志的Header帧的端点必须将相应的请求或响应视为格式错误（第8.1.2.6节）。
An HTTP request/response exchange fully consumes a single stream. A request starts with the HEADERS frame that puts the stream into an "open" state. The request ends with a frame bearing END_STREAM, which causes the stream to become "half-closed (local)" for the client and "half-closed (remote)" for the server. A response starts with a HEADERS frame and ends with a frame bearing END_STREAM, which places the stream in the "closed" state.
HTTP请求/响应交换完全使用单个流。请求从HEADERS框架开始，该框架将流置于“打开”状态。请求以一个带有帧的END_流结束，这会导致该流对于客户端变为“半关闭（本地）”，对于服务器变为“半关闭（远程）”。响应以HEADERS帧开始，以带有END_流的帧结束，该帧将流置于“关闭”状态。
An HTTP response is complete after the server sends -- or the client receives -- a frame with the END_STREAM flag set (including any CONTINUATION frames needed to complete a header block). A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the request that has not been sent and received. When this is true, a server MAY request that the client abort transmission of a request without error by sending a RST_STREAM with an error code of NO_ERROR after sending a complete response (i.e., a frame with the END_STREAM flag). Clients MUST NOT discard responses as a result of receiving such a RST_STREAM, though clients can always discard responses at their discretion for other reasons.
HTTP响应在服务器发送（或客户端接收）设置了END_STREAM标志的帧（包括完成头块所需的任何延续帧）后完成。如果响应不依赖于尚未发送和接收的请求的任何部分，则服务器可以在客户端发送整个请求之前发送完整的响应。当这为真时，服务器可通过在发送完整响应（即，具有结束流标志的帧）之后发送错误代码为无错误的RST_流来请求客户端无错误地中止请求的传输。客户端不能因为接收到这样的RST_流而丢弃响应，尽管客户端可以出于其他原因自行丢弃响应。
HTTP/2 removes support for the 101 (Switching Protocols) informational status code ([RFC7231], Section 6.2.2).
HTTP/2取消了对101（交换协议）信息状态代码的支持（[RFC7231]，第6.2.2节）。
The semantics of 101 (Switching Protocols) aren't applicable to a multiplexed protocol. Alternative protocols are able to use the same mechanisms that HTTP/2 uses to negotiate their use (see Section 3).
101（交换协议）的语义不适用于多路复用协议。替代协议能够使用HTTP/2用于协商其使用的相同机制（参见第3节）。
HTTP header fields carry information as a series of key-value pairs. For a listing of registered HTTP headers, see the "Message Header Field" registry maintained at <https://www.iana.org/assignments/ message-headers>.
HTTP头字段以一系列键值对的形式携带信息。有关已注册HTTP头的列表，请参阅维护在中的“消息头字段”注册表<https://www.iana.org/assignments/ 消息头>。
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. A request or response containing uppercase header field names MUST be treated as malformed (Section 8.1.2.6).
正如在HTTP/1.x中一样，标头字段名是ASCII字符字符串，它们以不区分大小写的方式进行比较。但是，在HTTP/2中编码头字段名称之前，必须将其转换为小写。包含大写标题字段名的请求或响应必须视为格式错误（第8.1.2.6节）。
While HTTP/1.x used the message start-line (see [RFC7230], Section 3.1) to convey the target URI, the method of the request, and the status code for the response, HTTP/2 uses special pseudo-header fields beginning with ':' character (ASCII 0x3a) for this purpose.
虽然HTTP/1.x使用消息起始行（参见[RFC7230]，第3.1节）来传递目标URI、请求方法和响应状态代码，但HTTP/2为此使用以“：”字符（ASCII 0x3a）开头的特殊伪头字段。
Pseudo-header fields are not HTTP header fields. Endpoints MUST NOT generate pseudo-header fields other than those defined in this document.
伪头字段不是HTTP头字段。端点不得生成除本文档中定义的伪头字段以外的伪头字段。
Pseudo-header fields are only valid in the context in which they are defined. Pseudo-header fields defined for requests MUST NOT appear in responses; pseudo-header fields defined for responses MUST NOT appear in requests. Pseudo-header fields MUST NOT appear in trailers. Endpoints MUST treat a request or response that contains undefined or invalid pseudo-header fields as malformed (Section 8.1.2.6).
伪标头字段仅在定义它们的上下文中有效。为请求定义的伪头字段不得出现在响应中；为响应定义的伪标头字段不得出现在请求中。伪标题字段不得出现在拖车中。端点必须将包含未定义或无效伪头字段的请求或响应视为格式错误（第8.1.2.6节）。
All pseudo-header fields MUST appear in the header block before regular header fields. Any request or response that contains a pseudo-header field that appears in a header block after a regular header field MUST be treated as malformed (Section 8.1.2.6).
所有伪标题字段必须在常规标题字段之前出现在标题块中。任何包含伪标头字段的请求或响应，如果在常规标头字段之后出现在标头块中，则必须视为格式错误（第8.1.2.6节）。
HTTP/2 does not use the Connection header field to indicate connection-specific header fields; in this protocol, connection-specific metadata is conveyed by other means. An endpoint MUST NOT generate an HTTP/2 message containing connection-specific header fields; any message containing connection-specific header fields MUST be treated as malformed (Section 8.1.2.6).
HTTP/2不使用连接头字段来指示特定于连接的头字段；在该协议中，特定于连接的元数据通过其他方式传送。端点不得生成包含连接特定头字段的HTTP/2消息；任何包含连接特定头字段的消息都必须视为格式错误（第8.1.2.6节）。
The only exception to this is the TE header field, which MAY be present in an HTTP/2 request; when it is, it MUST NOT contain any value other than "trailers".
唯一的例外是TE头字段，它可能出现在HTTP/2请求中；如果是，则不得包含除“拖车”以外的任何值。
This means that an intermediary transforming an HTTP/1.x message to HTTP/2 will need to remove any header fields nominated by the Connection header field, along with the Connection header field itself. Such intermediaries SHOULD also remove other connection-specific header fields, such as Keep-Alive, Proxy-Connection, Transfer-Encoding, and Upgrade, even if they are not nominated by the Connection header field.
这意味着，将HTTP/1.x消息转换为HTTP/2的中介体需要删除连接头字段指定的任何头字段，以及连接头字段本身。这些中介体还应该删除其他特定于连接的头字段，例如保持活动、代理连接、传输编码和升级，即使它们不是由连接头字段指定的。
Note: HTTP/2 purposefully does not support upgrade to another protocol. The handshake methods described in Section 3 are believed sufficient to negotiate the use of alternative protocols.
注意：HTTP/2故意不支持升级到其他协议。第3节中描述的握手方法被认为足以协商替代协议的使用。
The following pseudo-header fields are defined for HTTP/2 requests:
为HTTP/2请求定义了以下伪头字段：
o The ":method" pseudo-header field includes the HTTP method ([RFC7231], Section 4).
o “：method”伪头字段包括HTTP方法（[RFC7231]，第4节）。
o The ":scheme" pseudo-header field includes the scheme portion of the target URI ([RFC3986], Section 3.1).
o “：scheme”伪头字段包括目标URI的scheme部分（[RFC3986]，第3.1节）。
":scheme" is not restricted to "http" and "https" schemed URIs. A proxy or gateway can translate requests for non-HTTP schemes, enabling the use of HTTP to interact with non-HTTP services.
“：scheme”不限于“http”和“https”模式URI。代理或网关可以转换非HTTP方案的请求，从而允许使用HTTP与非HTTP服务交互。
o The ":authority" pseudo-header field includes the authority portion of the target URI ([RFC3986], Section 3.2). The authority MUST NOT include the deprecated "userinfo" subcomponent for "http" or "https" schemed URIs.
o “：authority”伪头字段包括目标URI的授权部分（[RFC3986]，第3.2节）。对于“http”或“https”架构URI，授权不得包含不推荐使用的“userinfo”子组件。
To ensure that the HTTP/1.1 request line can be reproduced accurately, this pseudo-header field MUST be omitted when translating from an HTTP/1.1 request that has a request target in origin or asterisk form (see [RFC7230], Section 5.3). Clients that generate HTTP/2 requests directly SHOULD use the ":authority" pseudo-header field instead of the Host header field. An intermediary that converts an HTTP/2 request to HTTP/1.1 MUST create a Host header field if one is not present in a request by copying the value of the ":authority" pseudo-header field.
为确保HTTP/1.1请求行能够准确复制，当从具有原始或星号形式请求目标的HTTP/1.1请求进行翻译时，必须省略此伪头字段（请参见[RFC7230]，第5.3节）。直接生成HTTP/2请求的客户端应使用“：authority”伪头字段而不是主机头字段。如果请求中不存在主机头字段，则将HTTP/2请求转换为HTTP/1.1的中介体必须通过复制“：authority”伪头字段的值来创建主机头字段。
o The ":path" pseudo-header field includes the path and query parts of the target URI (the "path-absolute" production and optionally a '?' character followed by the "query" production (see Sections 3.3 and 3.4 of [RFC3986]). A request in asterisk form includes the value '*' for the ":path" pseudo-header field.
o “：path”伪头字段包括目标URI的路径和查询部分（“绝对路径”产生，可选地是一个“？”字符，后跟“查询”产生（参见[RFC3986]第3.3节和第3.4节）。星号形式的请求包括“*”值作为“：path”伪头字段。
This pseudo-header field MUST NOT be empty for "http" or "https" URIs; "http" or "https" URIs that do not contain a path component MUST include a value of '/'. The exception to this rule is an OPTIONS request for an "http" or "https" URI that does not include a path component; these MUST include a ":path" pseudo-header field with a value of '*' (see [RFC7230], Section 5.3.4).
对于“http”或“https”URI，此伪标头字段不得为空；不包含路径组件的“http”或“https”URI必须包含值“/”。此规则的例外是对不包含路径组件的“http”或“https”URI的选项请求；其中必须包括一个“*”值的“：path”伪头字段（见[RFC7230]，第5.3.4节）。
All HTTP/2 requests MUST include exactly one valid value for the ":method", ":scheme", and ":path" pseudo-header fields, unless it is a CONNECT request (Section 8.3). An HTTP request that omits mandatory pseudo-header fields is malformed (Section 8.1.2.6).
所有HTTP/2请求必须包含“：method”、“：scheme”和“：path”伪头字段的一个有效值，除非它是连接请求（第8.3节）。忽略必需伪头字段的HTTP请求格式不正确（第8.1.2.6节）。
HTTP/2 does not define a way to carry the version identifier that is included in the HTTP/1.1 request line.
HTTP/2没有定义携带HTTP/1.1请求行中包含的版本标识符的方法。
For HTTP/2 responses, a single ":status" pseudo-header field is defined that carries the HTTP status code field (see [RFC7231], Section 6). This pseudo-header field MUST be included in all responses; otherwise, the response is malformed (Section 8.1.2.6).
对于HTTP/2响应，定义了一个“：status”伪头字段，其中包含HTTP状态代码字段（请参阅[RFC7231]，第6节）。此伪标头字段必须包含在所有响应中；否则，响应格式不正确（第8.1.2.6节）。
HTTP/2 does not define a way to carry the version or reason phrase that is included in an HTTP/1.1 status line.
HTTP/2没有定义携带HTTP/1.1状态行中包含的版本或原因短语的方式。
The Cookie header field [COOKIE] uses a semi-colon (";") to delimit cookie-pairs (or "crumbs"). This header field doesn't follow the list construction rules in HTTP (see [RFC7230], Section 3.2.2), which prevents cookie-pairs from being separated into different name-value pairs. This can significantly reduce compression efficiency as individual cookie-pairs are updated.
Cookie头字段[Cookie]使用分号（；）分隔Cookie对（或“crumps”）。此标头字段不遵循HTTP中的列表构造规则（请参阅[RFC7230]，第3.2.2节），这会防止cookie对被分离为不同的名称-值对。随着单个cookie对的更新，这会显著降低压缩效率。
To allow for better compression efficiency, the Cookie header field MAY be split into separate header fields, each with one or more cookie-pairs. If there are multiple Cookie header fields after decompression, these MUST be concatenated into a single octet string using the two-octet delimiter of 0x3B, 0x20 (the ASCII string "; ") before being passed into a non-HTTP/2 context, such as an HTTP/1.1 connection, or a generic HTTP server application.
为了允许更好的压缩效率，Cookie头字段可以拆分为单独的头字段，每个头字段都有一个或多个Cookie对。如果解压后有多个Cookie头字段，则必须使用两个八位分隔符0x3B、0x20（ASCII字符串“；”）将这些字段连接成一个八位字符串，然后才能传递到非HTTP/2上下文中，例如HTTP/1.1连接或通用HTTP服务器应用程序。
Therefore, the following two lists of Cookie header fields are semantically equivalent.
因此，以下两个Cookie头字段列表在语义上是等效的。
cookie: a=b; c=d; e=f
cookie: a=b; c=d; e=f
cookie: a=b
cookie: c=d
cookie: e=f
cookie: a=b
cookie: c=d
cookie: e=f
A malformed request or response is one that is an otherwise valid sequence of HTTP/2 frames but is invalid due to the presence of extraneous frames, prohibited header fields, the absence of mandatory header fields, or the inclusion of uppercase header field names.
格式错误的请求或响应是HTTP/2帧的有效序列，但由于存在无关帧、禁止的标头字段、缺少强制标头字段或包含大写标头字段名称而无效。
A request or response that includes a payload body can include a content-length header field. A request or response is also malformed if the value of a content-length header field does not equal the sum of the DATA frame payload lengths that form the body. A response that is defined to have no payload, as described in [RFC7230], Section 3.3.2, can have a non-zero content-length header field, even though no content is included in DATA frames.
包括有效负载主体的请求或响应可以包括内容长度报头字段。如果内容长度标头字段的值不等于构成正文的数据帧有效负载长度之和，则请求或响应的格式也不正确。如[RFC7230]第3.3.2节所述，定义为无有效负载的响应可以具有非零内容长度头字段，即使数据帧中不包含任何内容。
Intermediaries that process HTTP requests or responses (i.e., any intermediary not acting as a tunnel) MUST NOT forward a malformed request or response. Malformed requests or responses that are detected MUST be treated as a stream error (Section 5.4.2) of type PROTOCOL_ERROR.
处理HTTP请求或响应的中介体（即任何不充当隧道的中介体）不得转发格式错误的请求或响应。检测到的格式错误的请求或响应必须被视为协议_错误类型的流错误（第5.4.2节）。
For malformed requests, a server MAY send an HTTP response prior to closing or resetting the stream. Clients MUST NOT accept a malformed response. Note that these requirements are intended to protect against several types of common attacks against HTTP; they are deliberately strict because being permissive can expose implementations to these vulnerabilities.
对于格式错误的请求，服务器可能会在关闭或重置流之前发送HTTP响应。客户端不能接受格式错误的响应。注意，这些要求旨在防止针对HTTP的几种常见攻击；它们是故意严格的，因为允许会使实现暴露在这些漏洞之下。
This section shows HTTP/1.1 requests and responses, with illustrations of equivalent HTTP/2 requests and responses.
本节显示HTTP/1.1请求和响应，并举例说明等效的HTTP/2请求和响应。
An HTTP GET request includes request header fields and no payload body and is therefore transmitted as a single HEADERS frame, followed by zero or more CONTINUATION frames containing the serialized block of request header fields. The HEADERS frame in the following has both the END_HEADERS and END_STREAM flags set; no CONTINUATION frames are sent.
HTTP GET请求包含请求头字段，没有有效负载正文，因此作为单个头帧传输，后跟零个或多个包含请求头字段序列化块的连续帧。下面的HEADERS帧同时设置了END_头和END_流标志；不发送连续帧。
GET /resource HTTP/1.1 HEADERS
Host: example.org ==> + END_STREAM
Accept: image/jpeg + END_HEADERS
:method = GET
:scheme = https
:path = /resource
host = example.org
accept = image/jpeg
GET /resource HTTP/1.1 HEADERS
Host: example.org ==> + END_STREAM
Accept: image/jpeg + END_HEADERS
:method = GET
:scheme = https
:path = /resource
host = example.org
accept = image/jpeg
Similarly, a response that includes only response header fields is transmitted as a HEADERS frame (again, followed by zero or more CONTINUATION frames) containing the serialized block of response header fields.
类似地，仅包含响应头字段的响应作为包含响应头字段的序列化块的头帧（同样，后面是零个或多个连续帧）传输。
HTTP/1.1 304 Not Modified HEADERS ETag: "xyzzy" ==> + END_STREAM Expires: Thu, 23 Jan ... + END_HEADERS :status = 304 etag = "xyzzy" expires = Thu, 23 Jan ...
HTTP/1.1 304未修改的标题ETag:“xyzzy”==>+结束\u流过期：1月23日星期四…+END_HEADERS:status=304 etag=“xyzy”expires=Thu，1月23日。。。
An HTTP POST request that includes request header fields and payload data is transmitted as one HEADERS frame, followed by zero or more CONTINUATION frames containing the request header fields, followed by one or more DATA frames, with the last CONTINUATION (or HEADERS) frame having the END_HEADERS flag set and the final DATA frame having the END_STREAM flag set:
包含请求标头字段和有效负载数据的HTTP POST请求作为一个标头帧传输，然后是包含请求标头字段的零个或多个连续帧，然后是一个或多个数据帧，最后是一个连续帧（或标头）设置了END_头标志的帧和设置了END_流标志的最终数据帧：
POST /resource HTTP/1.1 HEADERS
Host: example.org ==> - END_STREAM
Content-Type: image/jpeg - END_HEADERS
Content-Length: 123 :method = POST
:path = /resource
{binary data} :scheme = https
POST /resource HTTP/1.1 HEADERS
Host: example.org ==> - END_STREAM
Content-Type: image/jpeg - END_HEADERS
Content-Length: 123 :method = POST
:path = /resource
{binary data} :scheme = https
CONTINUATION + END_HEADERS content-type = image/jpeg host = example.org content-length = 123
CONTINUATION+END_HEADERS content type=image/jpeg host=example.org content length=123
DATA + END_STREAM {binary data}
数据+结束_流{二进制数据}
Note that data contributing to any given header field could be spread between header block fragments. The allocation of header fields to frames in this example is illustrative only.
注意，任何给定的头字段的数据都可能分布在头块片段之间。在本示例中，将报头字段分配给帧只是说明性的。
A response that includes header fields and payload data is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames, followed by one or more DATA frames, with the last DATA frame in the sequence having the END_STREAM flag set:
包括报头字段和有效负载数据的响应作为报头帧传输，随后是零个或多个连续帧，接着是一个或多个数据帧，序列中的最后一个数据帧设置了END_流标志：
HTTP/1.1 200 OK HEADERS
Content-Type: image/jpeg ==> - END_STREAM
Content-Length: 123 + END_HEADERS
:status = 200
{binary data} content-type = image/jpeg
content-length = 123
HTTP/1.1 200 OK HEADERS
Content-Type: image/jpeg ==> - END_STREAM
Content-Length: 123 + END_HEADERS
:status = 200
{binary data} content-type = image/jpeg
content-length = 123
DATA + END_STREAM {binary data}
数据+结束_流{二进制数据}
An informational response using a 1xx status code other than 101 is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames.
使用除101以外的1xx状态码的信息性响应作为报头帧传输，后跟零个或多个连续帧。
Trailing header fields are sent as a header block after both the request or response header block and all the DATA frames have been sent. The HEADERS frame starting the trailers header block has the END_STREAM flag set.
在请求或响应头块和所有数据帧都已发送之后，尾部头字段将作为头块发送。开始拖车标题块的标题帧设置了END_STREAM标志。
The following example includes both a 100 (Continue) status code, which is sent in response to a request containing a "100-continue" token in the Expect header field, and trailing header fields:
以下示例包括100（继续）状态代码（发送该代码是为了响应在Expect标头字段中包含“100 Continue”标记的请求）和尾部标头字段：
HTTP/1.1 100 Continue HEADERS
Extension-Field: bar ==> - END_STREAM
+ END_HEADERS
:status = 100
extension-field = bar
HTTP/1.1 100 Continue HEADERS
Extension-Field: bar ==> - END_STREAM
+ END_HEADERS
:status = 100
extension-field = bar
HTTP/1.1 200 OK HEADERS
Content-Type: image/jpeg ==> - END_STREAM
Transfer-Encoding: chunked + END_HEADERS
Trailer: Foo :status = 200
content-length = 123
123 content-type = image/jpeg
{binary data} trailer = Foo
0
Foo: bar DATA
- END_STREAM
{binary data}
HTTP/1.1 200 OK HEADERS
Content-Type: image/jpeg ==> - END_STREAM
Transfer-Encoding: chunked + END_HEADERS
Trailer: Foo :status = 200
content-length = 123
123 content-type = image/jpeg
{binary data} trailer = Foo
0
Foo: bar DATA
- END_STREAM
{binary data}
HEADERS + END_STREAM + END_HEADERS foo = bar
标题+结束\u流+结束\u标题foo=bar
In HTTP/1.1, an HTTP client is unable to retry a non-idempotent request when an error occurs because there is no means to determine the nature of the error. It is possible that some server processing occurred prior to the error, which could result in undesirable effects if the request were reattempted.
在HTTP/1.1中，HTTP客户机无法在发生错误时重试非幂等请求，因为无法确定错误的性质。可能在错误发生之前发生了某些服务器处理，如果重新尝试请求，可能会导致不良影响。
HTTP/2 provides two mechanisms for providing a guarantee to a client that a request has not been processed:
HTTP/2提供了两种机制，用于向客户端保证请求未被处理：
o The GOAWAY frame indicates the highest stream number that might have been processed. Requests on streams with higher numbers are therefore guaranteed to be safe to retry.
o GOAWAY帧表示可能已处理的最高流编号。因此，在具有更高编号的流上的请求保证可以安全地重试。
o The REFUSED_STREAM error code can be included in a RST_STREAM frame to indicate that the stream is being closed prior to any processing having occurred. Any request that was sent on the reset stream can be safely retried.
o 被拒绝的\u流错误代码可以包括在RST \u流帧中，以指示流在发生任何处理之前被关闭。可以安全地重试在重置流上发送的任何请求。
Requests that have not been processed have not failed; clients MAY automatically retry them, even those with non-idempotent methods.
未处理的请求未失败；客户端可能会自动重试它们，即使是使用非幂等方法的客户端。
A server MUST NOT indicate that a stream has not been processed unless it can guarantee that fact. If frames that are on a stream are passed to the application layer for any stream, then REFUSED_STREAM MUST NOT be used for that stream, and a GOAWAY frame MUST include a stream identifier that is greater than or equal to the given stream identifier.
服务器不得指示流未被处理，除非它能保证这一事实。如果流上的帧被传递到任何流的应用层，则拒绝的流不得用于该流，并且GOAWAY帧必须包括大于或等于给定流标识符的流标识符。
In addition to these mechanisms, the PING frame provides a way for a client to easily test a connection. Connections that remain idle can become broken as some middleboxes (for instance, network address translators or load balancers) silently discard connection bindings. The PING frame allows a client to safely test whether a connection is still active without sending a request.
除了这些机制之外，PING框架还为客户端提供了一种轻松测试连接的方法。保持空闲状态的连接可能会断开，因为某些中间盒（例如，网络地址转换器或负载平衡器）会自动放弃连接绑定。PING帧允许客户端在不发送请求的情况下安全地测试连接是否仍然处于活动状态。
HTTP/2 allows a server to pre-emptively send (or "push") responses (along with corresponding "promised" requests) to a client in association with a previous client-initiated request. This can be useful when the server knows the client will need to have those responses available in order to fully process the response to the original request.
HTTP/2允许服务器先发制人地将响应（以及相应的“承诺”请求）发送（或“推送”）到与先前客户机发起的请求相关联的客户机。当服务器知道客户端需要这些响应才能完全处理对原始请求的响应时，这会很有用。
A client can request that server push be disabled, though this is negotiated for each hop independently. The SETTINGS_ENABLE_PUSH setting can be set to 0 to indicate that server push is disabled.
客户端可以请求禁用服务器推送，尽管这是为每个跃点单独协商的。设置\u启用\u推送设置可以设置为0，以指示已禁用服务器推送。
Promised requests MUST be cacheable (see [RFC7231], Section 4.2.3), MUST be safe (see [RFC7231], Section 4.2.1), and MUST NOT include a request body. Clients that receive a promised request that is not cacheable, that is not known to be safe, or that indicates the presence of a request body MUST reset the promised stream with a stream error (Section 5.4.2) of type PROTOCOL_ERROR. Note this could result in the promised stream being reset if the client does not recognize a newly defined method as being safe.
承诺的请求必须是可缓存的（见[RFC7231]，第4.2.3节），必须是安全的（见[RFC7231]，第4.2.1节），并且不得包含请求正文。接收不可缓存、未知安全或指示存在请求主体的承诺请求的客户端必须使用PROTOCOL_error类型的流错误（第5.4.2节）重置承诺流。注意，如果客户机没有识别出新定义的方法是安全的，那么这可能会导致承诺流被重置。
Pushed responses that are cacheable (see [RFC7234], Section 3) can be stored by the client, if it implements an HTTP cache. Pushed responses are considered successfully validated on the origin server (e.g., if the "no-cache" cache response directive is present ([RFC7234], Section 5.2.2)) while the stream identified by the promised stream ID is still open.
如果客户端实现了HTTP缓存，则可以存储可缓存的推送响应（请参阅[RFC7234]，第3节）。推送响应被视为在源服务器上成功验证（例如，如果存在“无缓存”缓存响应指令（[RFC7234]，第5.2.2节）），而承诺流ID标识的流仍处于打开状态。
Pushed responses that are not cacheable MUST NOT be stored by any HTTP cache. They MAY be made available to the application separately.
任何HTTP缓存都不能存储不可缓存的推送响应。它们可以单独提供给应用程序。
The server MUST include a value in the ":authority" pseudo-header field for which the server is authoritative (see Section 10.1). A client MUST treat a PUSH_PROMISE for which the server is not authoritative as a stream error (Section 5.4.2) of type PROTOCOL_ERROR.
服务器必须在“：authority”伪头字段中包含一个值，服务器对此具有权威性（参见第10.1节）。客户机必须将服务器未授权的推送承诺视为协议错误类型的流错误（第5.4.2节）。
An intermediary can receive pushes from the server and choose not to forward them on to the client. In other words, how to make use of the pushed information is up to that intermediary. Equally, the intermediary might choose to make additional pushes to the client, without any action taken by the server.
中介可以从服务器接收推送，并选择不将推送转发到客户端。换句话说，如何利用推送的信息取决于该中介。同样，中介可能会选择向客户机进行额外推送，而无需服务器执行任何操作。
A client cannot push. Thus, servers MUST treat the receipt of a PUSH_PROMISE frame as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. Clients MUST reject any attempt to change the SETTINGS_ENABLE_PUSH setting to a value other than 0 by treating the message as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
客户端无法推送。因此，服务器必须将收到PUSH_承诺帧视为协议_错误类型的连接错误（第5.4.1节）。客户端必须通过将消息视为协议错误类型的连接错误（第5.4.1节），拒绝将设置\u启用\u推送设置更改为0以外的值的任何尝试。
Server push is semantically equivalent to a server responding to a request; however, in this case, that request is also sent by the server, as a PUSH_PROMISE frame.
服务器推送在语义上等同于响应请求的服务器；但是，在这种情况下，该请求也由服务器作为推送承诺帧发送。
The PUSH_PROMISE frame includes a header block that contains a complete set of request header fields that the server attributes to the request. It is not possible to push a response to a request that includes a request body.
PUSH_PROMISE框架包含一个标头块，其中包含一组完整的请求标头字段，服务器将这些字段赋予请求。无法对包含请求正文的请求推送响应。
Pushed responses are always associated with an explicit request from the client. The PUSH_PROMISE frames sent by the server are sent on that explicit request's stream. The PUSH_PROMISE frame also includes a promised stream identifier, chosen from the stream identifiers available to the server (see Section 5.1.1).
推送响应始终与来自客户端的显式请求相关联。服务器发送的推送承诺帧在该显式请求的流上发送。推送承诺帧还包括承诺流标识符，从服务器可用的流标识符中选择（见第5.1.1节）。
The header fields in PUSH_PROMISE and any subsequent CONTINUATION frames MUST be a valid and complete set of request header fields (Section 8.1.2.3). The server MUST include a method in the ":method" pseudo-header field that is safe and cacheable. If a client receives a PUSH_PROMISE that does not include a complete and valid set of header fields or the ":method" pseudo-header field identifies a method that is not safe, it MUST respond with a stream error (Section 5.4.2) of type PROTOCOL_ERROR.
PUSH_PROMISE和任何后续延续帧中的头字段必须是一组有效且完整的请求头字段（第8.1.2.3节）。服务器必须在“：method”伪头字段中包含一个安全且可缓存的方法。如果客户机收到的PUSH_承诺不包括完整有效的头字段集，或者“：method”伪头字段标识了不安全的方法，则它必须以PROTOCOL_error类型的流错误（第5.4.2节）进行响应。
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.
服务器应在发送引用承诺响应的任何帧之前发送推送承诺（第6.6节）帧。这避免了客户端在接收任何推送承诺帧之前发出请求的竞争。
For example, if the server receives a request for a document containing embedded links to multiple image files and the server chooses to push those additional images to the client, sending PUSH_PROMISE frames before the DATA frames that contain the image links ensures that the client is able to see that a resource will be pushed before discovering embedded links. Similarly, if the server pushes responses referenced by the header block (for instance, in Link header fields), sending a PUSH_PROMISE before sending the header block ensures that clients do not request those resources.
例如，如果服务器收到一个文档请求，其中包含指向多个图像文件的嵌入链接，并且服务器选择将这些附加图像推送到客户端，在包含图像链接的数据帧之前发送推送承诺帧可确保客户端能够在发现嵌入链接之前看到资源将被推送。类似地，如果服务器推送头块引用的响应（例如，在链接头字段中），则在发送头块之前发送推送承诺可确保客户端不请求这些资源。
PUSH_PROMISE frames MUST NOT be sent by the client.
推送承诺帧不能由客户端发送。
PUSH_PROMISE frames can be sent by the server in response to any client-initiated stream, but the stream MUST be in either the "open" or "half-closed (remote)" state with respect to the server. PUSH_PROMISE frames are interspersed with the frames that comprise a response, though they cannot be interspersed with HEADERS and CONTINUATION frames that comprise a single header block.
推送承诺帧可以由服务器发送，以响应任何客户端启动的流，但相对于服务器，流必须处于“打开”或“半关闭（远程）”状态。PUSH_PROMISE帧散布在包含响应的帧中，尽管它们不能散布在包含单个头块的头帧和延续帧中。
Sending a PUSH_PROMISE frame creates a new stream and puts the stream into the "reserved (local)" state for the server and the "reserved (remote)" state for the client.
发送PUSH_PROMISE帧将创建一个新流，并将该流置于服务器的“保留（本地）”状态和客户端的“保留（远程）”状态。
After sending the PUSH_PROMISE frame, the server can begin delivering the pushed response as a response (Section 8.1.2.4) on a server-initiated stream that uses the promised stream identifier. The server uses this stream to transmit an HTTP response, using the same sequence of frames as defined in Section 8.1. This stream becomes "half-closed" to the client (Section 5.1) after the initial HEADERS frame is sent.
发送PUSH_承诺帧后，服务器可以开始在使用承诺流标识符的服务器启动流上以响应（第8.1.2.4节）的形式交付推送响应。服务器使用此流传输HTTP响应，使用第8.1节中定义的相同帧序列。发送初始头帧后，该流对客户端（第5.1节）变成“半封闭”。
Once a client receives a PUSH_PROMISE frame and chooses to accept the pushed response, the client SHOULD NOT issue any requests for the promised response until after the promised stream has closed.
一旦客户机接收到推送承诺帧并选择接受推送响应，则在承诺流关闭之前，客户机不应发出任何关于承诺响应的请求。
If the client determines, for any reason, that it does not wish to receive the pushed response from the server or if the server takes too long to begin sending the promised response, the client can send a RST_STREAM frame, using either the CANCEL or REFUSED_STREAM code and referencing the pushed stream's identifier.
如果客户端出于任何原因确定它不希望从服务器接收推送响应，或者如果服务器开始发送承诺的响应花费太长时间，则客户端可以使用取消或拒绝流代码并引用推送流的标识符发送RST_流帧。
A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit the number of responses that can be concurrently pushed by a server. Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables server push by preventing the server from creating the necessary streams. This does not prohibit a server from sending PUSH_PROMISE frames; clients need to reset any promised streams that are not wanted.
客户端可以使用设置\u MAX\u CONCURRENT\u STREAMS设置来限制服务器可以并发推送的响应数量。公布设置\u MAX\u CONCURRENT\u STREAMS值为零会阻止服务器创建必要的流，从而禁用服务器推送。这并不禁止服务器发送推送承诺帧；客户端需要重置任何不需要的承诺流。
Clients receiving a pushed response MUST validate that either the server is authoritative (see Section 10.1) or the proxy that provided the pushed response is configured for the corresponding request. For example, a server that offers a certificate for only the "example.com" DNS-ID or Common Name is not permitted to push a response for "https://www.example.org/doc".
接收推送响应的客户端必须验证服务器是否具有权威性（请参见第10.1节），或者是否为相应的请求配置了提供推送响应的代理。例如，仅为“example.com”DNS-ID或公共名称提供证书的服务器不允许推送对“”的响应https://www.example.org/doc".
The response for a PUSH_PROMISE stream begins with a HEADERS frame, which immediately puts the stream into the "half-closed (remote)" state for the server and "half-closed (local)" state for the client, and ends with a frame bearing END_STREAM, which places the stream in the "closed" state.
PUSH_PROMISE流的响应以Header帧开始，该帧立即将流置于服务器的“半关闭（远程）”状态和客户端的“半关闭（本地）”状态，并以带有帧的END_流结束，该帧将流置于“关闭”状态。
Note: The client never sends a frame with the END_STREAM flag for a server push.
注意：对于服务器推送，客户端从不发送带有END_STREAM标志的帧。
In HTTP/1.x, the pseudo-method CONNECT ([RFC7231], Section 4.3.6) is used to convert an HTTP connection into a tunnel to a remote host. CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with "https" resources.
在HTTP/1.x中，伪方法CONNECT（[RFC7231]，第4.3.6节）用于将HTTP连接转换为到远程主机的隧道。CONNECT主要与HTTP代理一起使用，用于与源服务器建立TLS会话，以便与“https”资源交互。
In HTTP/2, the CONNECT method is used to establish a tunnel over a single HTTP/2 stream to a remote host for similar purposes. The HTTP header field mapping works as defined in Section 8.1.2.3 ("Request Pseudo-Header Fields"), with a few differences. Specifically:
在HTTP/2中，出于类似目的，CONNECT方法用于通过单个HTTP/2流建立到远程主机的隧道。HTTP头字段映射的工作原理与第8.1.2.3节（“请求伪头字段”）中的定义相同，但存在一些差异。明确地：
o The ":method" pseudo-header field is set to "CONNECT".
o “：method”伪头字段设置为“CONNECT”。
o The ":scheme" and ":path" pseudo-header fields MUST be omitted.
o “：scheme”和“：path”伪头字段必须省略。
o The ":authority" pseudo-header field contains the host and port to connect to (equivalent to the authority-form of the request-target of CONNECT requests (see [RFC7230], Section 5.3)).
o “：authority”伪标头字段包含要连接到的主机和端口（相当于连接请求的请求目标的权限形式（请参阅[RFC7230]，第5.3节））。
A CONNECT request that does not conform to these restrictions is malformed (Section 8.1.2.6).
不符合这些限制的连接请求格式不正确（第8.1.2.6节）。
A proxy that supports CONNECT establishes a TCP connection [TCP] to the server identified in the ":authority" pseudo-header field. Once this connection is successfully established, the proxy sends a HEADERS frame containing a 2xx series status code to the client, as defined in [RFC7231], Section 4.3.6.
支持CONNECT的代理与“：authority”伪头字段中标识的服务器建立TCP连接[TCP]。成功建立此连接后，代理将向客户端发送包含2xx系列状态代码的标题帧，如[RFC7231]第4.3.6节所定义。
After the initial HEADERS frame sent by each peer, all subsequent DATA frames correspond to data sent on the TCP connection. The payload of any DATA frames sent by the client is transmitted by the proxy to the TCP server; data received from the TCP server is assembled into DATA frames by the proxy. Frame types other than DATA or stream management frames (RST_STREAM, WINDOW_UPDATE, and PRIORITY) MUST NOT be sent on a connected stream and MUST be treated as a stream error (Section 5.4.2) if received.
在每个对等方发送的初始头帧之后，所有后续数据帧都对应于TCP连接上发送的数据。客户端发送的任何数据帧的有效载荷由代理发送到TCP服务器；从TCP服务器接收的数据由代理组装成数据帧。数据或流管理帧（RST_流、窗口_更新和优先级）以外的帧类型不得在连接的流上发送，如果收到，则必须视为流错误（第5.4.2节）。
The TCP connection can be closed by either peer. The END_STREAM flag on a DATA frame is treated as being equivalent to the TCP FIN bit. A client is expected to send a DATA frame with the END_STREAM flag set after receiving a frame bearing the END_STREAM flag. A proxy that receives a DATA frame with the END_STREAM flag set sends the attached data with the FIN bit set on the last TCP segment. A proxy that receives a TCP segment with the FIN bit set sends a DATA frame with the END_STREAM flag set. Note that the final TCP segment or DATA frame could be empty.
TCP连接可以由任一对等方关闭。数据帧上的END_流标志被视为等同于TCP FIN位。在接收到带有END_流标志的帧之后，客户机应发送设置了END_流标志的数据帧。接收带有END_STREAM标志集的数据帧的代理发送附加数据，并在最后一个TCP段上设置FIN位。接收带有FIN位集的TCP段的代理发送带有END_STREAM标志集的数据帧。请注意，最后的TCP段或数据帧可能为空。
A TCP connection error is signaled with RST_STREAM. A proxy treats any error in the TCP connection, which includes receiving a TCP segment with the RST bit set, as a stream error (Section 5.4.2) of type CONNECT_ERROR. Correspondingly, a proxy MUST send a TCP segment with the RST bit set if it detects an error with the stream or the HTTP/2 connection.
TCP连接错误通过RST_流发出信号。代理将TCP连接中的任何错误（包括接收设置了RST位的TCP段）视为CONNECT_error类型的流错误（第5.4.2节）。相应地，如果代理检测到流或HTTP/2连接错误，则必须发送设置了RST位的TCP段。
This section outlines attributes of the HTTP protocol that improve interoperability, reduce exposure to known security vulnerabilities, or reduce the potential for implementation variation.
本节概述了HTTP协议的属性，这些属性可提高互操作性，减少已知安全漏洞的暴露，或减少实现变化的可能性。
HTTP/2 connections are persistent. For best performance, it is expected that clients will not close connections until it is determined that no further communication with a server is necessary (for example, when a user navigates away from a particular web page) or until the server closes the connection.
HTTP/2连接是持久的。为了获得最佳性能，在确定不需要与服务器进行进一步通信（例如，当用户离开特定网页时）或在服务器关闭连接之前，客户端不会关闭连接。
Clients SHOULD NOT open more than one HTTP/2 connection to a given host and port pair, where the host is derived from a URI, a selected alternative service [ALT-SVC], or a configured proxy.
客户端不应打开到给定主机和端口对的多个HTTP/2连接，其中主机派生自URI、选定的替代服务[ALT-SVC]或配置的代理。
A client can create additional connections as replacements, either to replace connections that are near to exhausting the available stream identifier space (Section 5.1.1), to refresh the keying material for a TLS connection, or to replace connections that have encountered errors (Section 5.4.1).
客户端可以创建其他连接作为替换，以替换接近耗尽可用流标识符空间的连接（第5.1.1节），刷新TLS连接的键控材料，或替换遇到错误的连接（第5.4.1节）。
A client MAY open multiple connections to the same IP address and TCP port using different Server Name Indication [TLS-EXT] values or to provide different TLS client certificates but SHOULD avoid creating multiple connections with the same configuration.
客户机可以使用不同的服务器名称指示[TLS-EXT]值打开到同一IP地址和TCP端口的多个连接，或提供不同的TLS客户机证书，但应避免使用相同的配置创建多个连接。
Servers are encouraged to maintain open connections for as long as possible but are permitted to terminate idle connections if necessary. When either endpoint chooses to close the transport-layer TCP connection, the terminating endpoint SHOULD first send a GOAWAY (Section 6.8) frame so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks.
鼓励服务器尽可能长时间地保持开放连接，但允许在必要时终止空闲连接。当任一端点选择关闭传输层TCP连接时，终止端点应首先发送GOAWAY（第6.8节）帧，以便两个端点都能可靠地确定是否已处理先前发送的帧，并正常完成或终止任何必要的剩余任务。
Connections that are made to an origin server, either directly or through a tunnel created using the CONNECT method (Section 8.3), MAY be reused for requests with multiple different URI authority components. A connection can be reused as long as the origin server is authoritative (Section 10.1). For TCP connections without TLS, this depends on the host having resolved to the same IP address.
直接或通过使用CONNECT方法（第8.3节）创建的隧道与源服务器建立的连接可用于具有多个不同URI授权组件的请求。只要源服务器是权威的，就可以重用连接（第10.1节）。对于没有TLS的TCP连接，这取决于主机已解析为相同的IP地址。
For "https" resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI. The certificate presented by the server MUST satisfy any checks that the client would perform when forming a new TLS connection for the host in the URI.
对于“https”资源，连接重用还取决于在URI中拥有对主机有效的证书。服务器提供的证书必须满足客户端在URI中为主机形成新TLS连接时执行的任何检查。
An origin server might offer a certificate with multiple "subjectAltName" attributes or names with wildcards, one of which is valid for the authority in the URI. For example, a certificate with a "subjectAltName" of "*.example.com" might permit the use of the same connection for requests to URIs starting with "https://a.example.com/" and "https://b.example.com/".
源服务器可能会提供具有多个“subjectAltName”属性的证书或具有通配符的名称，其中一个通配符对URI中的权限有效。例如，“subjectAltName”为“*.example.com”的证书可能允许对以“*”开头的URI请求使用相同的连接https://a.example.com/“和”https://b.example.com/".
In some deployments, reusing a connection for multiple origins can result in requests being directed to the wrong origin server. For example, TLS termination might be performed by a middlebox that uses the TLS Server Name Indication (SNI) [TLS-EXT] extension to select an origin server. This means that it is possible for clients to send confidential information to servers that might not be the intended target for the request, even though the server is otherwise authoritative.
在某些部署中，对多个源服务器重复使用连接可能会导致请求被定向到错误的源服务器。例如，TLS终止可能由使用TLS服务器名称指示（SNI）[TLS-EXT]扩展选择源服务器的中间盒执行。这意味着客户端可以将机密信息发送到可能不是请求的预期目标的服务器，即使该服务器在其他方面是权威的。
A server that does not wish clients to reuse connections can indicate that it is not authoritative for a request by sending a 421 (Misdirected Request) status code in response to the request (see Section 9.1.2).
不希望客户端重复使用连接的服务器可以通过发送421（错误指示的请求）状态代码来响应请求，从而表明其对请求没有权威性（参见第9.1.2节）。
A client that is configured to use a proxy over HTTP/2 directs requests to that proxy through a single connection. That is, all requests sent via a proxy reuse the connection to the proxy.
配置为通过HTTP/2使用代理的客户端通过单个连接将请求定向到该代理。也就是说，通过代理发送的所有请求都会重用到代理的连接。
The 421 (Misdirected Request) status code indicates that the request was directed at a server that is not able to produce a response. This can be sent by a server that is not configured to produce responses for the combination of scheme and authority that are included in the request URI.
421（错误定向请求）状态代码表示请求被定向到无法生成响应的服务器。这可以由未配置为针对请求URI中包含的方案和权限组合生成响应的服务器发送。
Clients receiving a 421 (Misdirected Request) response from a server MAY retry the request -- whether the request method is idempotent or not -- over a different connection. This is possible if a connection is reused (Section 9.1.1) or if an alternative service is selected [ALT-SVC].
从服务器接收421（错误定向请求）响应的客户端可以通过不同的连接重试该请求（无论请求方法是否为幂等）。如果重新使用连接（第9.1.1节）或选择了替代服务[ALT-SVC]，则这是可能的。
This status code MUST NOT be generated by proxies.
此状态代码不能由代理生成。
A 421 response is cacheable by default, i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
默认情况下，421响应是可缓存的，即，除非方法定义或显式缓存控制另有指示（参见[RFC7234]第4.2.2节）。
Implementations of HTTP/2 MUST use TLS version 1.2 [TLS12] or higher for HTTP/2 over TLS. The general TLS usage guidance in [TLSBCP] SHOULD be followed, with some additional restrictions that are specific to HTTP/2.
对于通过TLS的HTTP/2，HTTP/2的实现必须使用TLS版本1.2[TLS12]或更高版本。应遵循[TLSBCP]中的一般TLS使用指南，以及特定于HTTP/2的一些附加限制。
The TLS implementation MUST support the Server Name Indication (SNI) [TLS-EXT] extension to TLS. HTTP/2 clients MUST indicate the target domain name when negotiating TLS.
TLS实现必须支持TLS的服务器名称指示（SNI）[TLS-EXT]扩展。HTTP/2客户端在协商TLS时必须指明目标域名。
Deployments of HTTP/2 that negotiate TLS 1.3 or higher need only support and use the SNI extension; deployments of TLS 1.2 are subject to the requirements in the following sections. Implementations are encouraged to provide defaults that comply, but it is recognized that deployments are ultimately responsible for compliance.
协商TLS 1.3或更高版本的HTTP/2部署只需要支持和使用SNI扩展；TLS 1.2的部署应符合以下章节的要求。我们鼓励实现提供符合要求的默认值，但我们认识到，部署最终要对法规遵从性负责。
This section describes restrictions on the TLS 1.2 feature set that can be used with HTTP/2. Due to deployment limitations, it might not be possible to fail TLS negotiation when these restrictions are not met. An endpoint MAY immediately terminate an HTTP/2 connection that does not meet these TLS requirements with a connection error (Section 5.4.1) of type INADEQUATE_SECURITY.
本节介绍对可与HTTP/2一起使用的TLS 1.2功能集的限制。由于部署限制，当不满足这些限制时，TLS协商可能不会失败。端点可能会立即终止不符合这些TLS要求的HTTP/2连接，并出现连接错误（第5.4.1节），该错误类型为“不充分的安全性”。
A deployment of HTTP/2 over TLS 1.2 MUST disable compression. TLS compression can lead to the exposure of information that would not otherwise be revealed [RFC3749]. Generic compression is unnecessary since HTTP/2 provides compression features that are more aware of context and therefore likely to be more appropriate for use for performance, security, or other reasons.
通过TLS 1.2部署HTTP/2必须禁用压缩。TLS压缩可能会导致信息的泄露，否则将不会被披露[RFC3749]。通用压缩是不必要的，因为HTTP/2提供了更了解上下文的压缩功能，因此出于性能、安全性或其他原因可能更适合使用。
A deployment of HTTP/2 over TLS 1.2 MUST disable renegotiation. An endpoint MUST treat a TLS renegotiation as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. Note that disabling
通过TLS 1.2部署HTTP/2必须禁用重新协商。端点必须将TLS重新协商视为协议_错误类型的连接错误（第5.4.1节）。请注意，禁用
renegotiation can result in long-lived connections becoming unusable due to limits on the number of messages the underlying cipher suite can encipher.
由于基础密码套件可以加密的消息数量有限，重新协商可能导致长期连接变得不可用。
An endpoint MAY use renegotiation to provide confidentiality protection for client credentials offered in the handshake, but any renegotiation MUST occur prior to sending the connection preface. A server SHOULD request a client certificate if it sees a renegotiation request immediately after establishing a connection.
端点可以使用重新协商为握手中提供的客户端凭据提供保密保护，但任何重新协商都必须在发送连接之前进行。如果服务器在建立连接后立即看到重新协商请求，则应请求客户端证书。
This effectively prevents the use of renegotiation in response to a request for a specific protected resource. A future specification might provide a way to support this use case. Alternatively, a server might use an error (Section 5.4) of type HTTP_1_1_REQUIRED to request the client use a protocol that supports renegotiation.
这有效地防止了在响应特定受保护资源的请求时使用重新协商。未来的规范可能会提供支持此用例的方法。或者，服务器可能会使用HTTP_1_1_类型的错误（第5.4节），请求客户端使用支持重新协商的协议。
Implementations MUST support ephemeral key exchange sizes of at least 2048 bits for cipher suites that use ephemeral finite field Diffie-Hellman (DHE) [TLS12] and 224 bits for cipher suites that use ephemeral elliptic curve Diffie-Hellman (ECDHE) [RFC4492]. Clients MUST accept DHE sizes of up to 4096 bits. Endpoints MAY treat negotiation of key sizes smaller than the lower limits as a connection error (Section 5.4.1) of type INADEQUATE_SECURITY.
对于使用临时有限域Diffie-Hellman（DHE）[TLS12]的密码套件，实现必须支持至少2048位的临时密钥交换大小，对于使用临时椭圆曲线Diffie-Hellman（ECDHE）[RFC4492]的密码套件，实现必须支持224位的临时密钥交换大小。客户端必须接受高达4096位的DHE大小。端点可能会将密钥大小小于下限的协商视为类型不充分的连接错误（第5.4.1节）。
A deployment of HTTP/2 over TLS 1.2 SHOULD NOT use any of the cipher suites that are listed in the cipher suite black list (Appendix A).
在TLS 1.2上部署HTTP/2不应使用密码套件黑名单（附录A）中列出的任何密码套件。
Endpoints MAY choose to generate a connection error (Section 5.4.1) of type INADEQUATE_SECURITY if one of the cipher suites from the black list is negotiated. A deployment that chooses to use a black-listed cipher suite risks triggering a connection error unless the set of potential peers is known to accept that cipher suite.
如果黑名单中的一个密码套件被协商，端点可能会选择生成一个类型为“不安全”的连接错误（第5.4.1节）。选择使用黑名单密码套件的部署有触发连接错误的风险，除非已知一组潜在对等方接受该密码套件。
Implementations MUST NOT generate this error in reaction to the negotiation of a cipher suite that is not on the black list. Consequently, when clients offer a cipher suite that is not on the black list, they have to be prepared to use that cipher suite with HTTP/2.
实现不得在协商不在黑名单上的密码套件时生成此错误。因此，当客户端提供不在黑名单上的密码套件时，他们必须准备将该密码套件与HTTP/2一起使用。
The black list includes the cipher suite that TLS 1.2 makes mandatory, which means that TLS 1.2 deployments could have non-intersecting sets of permitted cipher suites. To avoid this problem causing TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with the P-256 elliptic curve [FIPS186].
黑名单包括TLS 1.2强制规定的密码套件，这意味着TLS 1.2部署可能具有不相交的允许密码套件集。为避免此问题导致TLS握手失败，使用TLS 1.2的HTTP/2部署必须支持TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256[TLS-ECDHE]WITH P-256椭圆曲线[FIPS186]。
Note that clients might advertise support of cipher suites that are on the black list in order to allow for connection to servers that do not support HTTP/2. This allows servers to select HTTP/1.1 with a cipher suite that is on the HTTP/2 black list. However, this can result in HTTP/2 being negotiated with a black-listed cipher suite if the application protocol and cipher suite are independently selected.
请注意，客户端可能会公布黑名单上的密码套件支持，以便允许连接到不支持HTTP/2的服务器。这允许服务器使用HTTP/2黑名单上的密码套件选择HTTP/1.1。但是，如果独立选择应用程序协议和密码套件，则这可能导致HTTP/2与黑名单密码套件进行协商。
HTTP/2 relies on the HTTP/1.1 definition of authority for determining whether a server is authoritative in providing a given response (see [RFC7230], Section 9.1). This relies on local name resolution for the "http" URI scheme and the authenticated server identity for the "https" scheme (see [RFC2818], Section 3).
HTTP/2依赖HTTP/1.1权限定义来确定服务器在提供给定响应时是否具有权限（请参见[RFC7230]，第9.1节）。这依赖于“http”URI方案的本地名称解析和“https”方案的经过身份验证的服务器标识（请参见[RFC2818]，第3节）。
In a cross-protocol attack, an attacker causes a client to initiate a transaction in one protocol toward a server that understands a different protocol. An attacker might be able to cause the transaction to appear as a valid transaction in the second protocol. In combination with the capabilities of the web context, this can be used to interact with poorly protected servers in private networks.
在跨协议攻击中，攻击者会使客户端以一种协议向理解不同协议的服务器发起事务。攻击者可能会导致该事务在第二个协议中显示为有效事务。结合web上下文的功能，可以使用它与私有网络中保护较差的服务器进行交互。
Completing a TLS handshake with an ALPN identifier for HTTP/2 can be considered sufficient protection against cross-protocol attacks. ALPN provides a positive indication that a server is willing to proceed with HTTP/2, which prevents attacks on other TLS-based protocols.
使用HTTP/2的ALPN标识符完成TLS握手可以被认为是对跨协议攻击的充分保护。ALPN提供了一个积极的迹象，表明服务器愿意继续使用HTTP/2，这可以防止对其他基于TLS的协议的攻击。
The encryption in TLS makes it difficult for attackers to control the data that could be used in a cross-protocol attack on a cleartext protocol.
TLS中的加密使得攻击者难以控制明文协议的跨协议攻击中可能使用的数据。
The cleartext version of HTTP/2 has minimal protection against cross-protocol attacks. The connection preface (Section 3.5) contains a string that is designed to confuse HTTP/1.1 servers, but no special protection is offered for other protocols. A server that is willing to ignore parts of an HTTP/1.1 request containing an Upgrade header field in addition to the client connection preface could be exposed to a cross-protocol attack.
HTTP/2的明文版本对跨协议攻击的保护最小。连接前言（第3.5节）包含一个旨在混淆HTTP/1.1服务器的字符串，但没有为其他协议提供特殊保护。如果服务器愿意忽略HTTP/1.1请求中除客户端连接前言外还包含升级头字段的部分，则可能会受到跨协议攻击。
The HTTP/2 header field encoding allows the expression of names that are not valid field names in the Internet Message Syntax used by HTTP/1.1. Requests or responses containing invalid header field names MUST be treated as malformed (Section 8.1.2.6). An intermediary therefore cannot translate an HTTP/2 request or response containing an invalid field name into an HTTP/1.1 message.
HTTP/2头字段编码允许在HTTP/1.1使用的Internet消息语法中表示无效字段名的名称。包含无效标题字段名称的请求或响应必须视为格式错误（第8.1.2.6节）。因此，中介无法将包含无效字段名的HTTP/2请求或响应转换为HTTP/1.1消息。
Similarly, HTTP/2 allows header field values that are not valid. While most of the values that can be encoded will not alter header field parsing, carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and the zero character (NUL, ASCII 0x0) might be exploited by an attacker if they are translated verbatim. Any request or response that contains a character not permitted in a header field value MUST be treated as malformed (Section 8.1.2.6). Valid characters are defined by the "field-content" ABNF rule in Section 3.2 of [RFC7230].
类似地，HTTP/2允许头字段值无效。虽然可以编码的大多数值不会改变头字段解析，但如果逐字翻译，回车符（CR、ASCII 0xd）、换行符（LF、ASCII 0xa）和零字符（NUL、ASCII 0x0）可能会被攻击者利用。任何包含头字段值中不允许的字符的请求或响应必须视为格式错误（第8.1.2.6节）。有效字符由[RFC7230]第3.2节中的“字段内容”ABNF规则定义。
Pushed responses do not have an explicit request from the client; the request is provided by the server in the PUSH_PROMISE frame.
推送响应没有来自客户端的明确请求；请求由服务器在PUSH_PROMISE框架中提供。
Caching responses that are pushed is possible based on the guidance provided by the origin server in the Cache-Control header field. However, this can cause issues if a single server hosts more than one tenant. For example, a server might offer multiple users each a small portion of its URI space.
根据源服务器在缓存控制标头字段中提供的指导，可以缓存推送的响应。但是，如果一台服务器承载多个租户，这可能会导致问题。例如，服务器可能会向多个用户提供其URI空间的一小部分。
Where multiple tenants share space on the same server, that server MUST ensure that tenants are not able to push representations of resources that they do not have authority over. Failure to enforce this would allow a tenant to provide a representation that would be served out of cache, overriding the actual representation that the authoritative tenant provides.
如果多个租户在同一台服务器上共享空间，则该服务器必须确保租户不能推送他们没有权限的资源表示。如果不执行此操作，承租人将可以提供一个将从缓存中提供的表示，从而覆盖权威承租人提供的实际表示。
Pushed responses for which an origin server is not authoritative (see Section 10.1) MUST NOT be used or cached.
不得使用或缓存源服务器不具有权威性的推送响应（参见第10.1节）。
An HTTP/2 connection can demand a greater commitment of resources to operate than an HTTP/1.1 connection. The use of header compression and flow control depend on a commitment of resources for storing a greater amount of state. Settings for these features ensure that memory commitments for these features are strictly bounded.
HTTP/2连接比HTTP/1.1连接需要更多的资源投入才能运行。报头压缩和流控制的使用取决于用于存储更多状态的资源承诺。这些功能的设置确保这些功能的内存承诺严格受限。
The number of PUSH_PROMISE frames is not constrained in the same fashion. A client that accepts server push SHOULD limit the number of streams it allows to be in the "reserved (remote)" state. An excessive number of server push streams can be treated as a stream error (Section 5.4.2) of type ENHANCE_YOUR_CALM.
推送承诺帧的数量不是以相同的方式约束的。接受服务器推送的客户端应限制其允许处于“保留（远程）”状态的流的数量。过多的服务器推送流可被视为Enhanced_YOUR_CALM类型的流错误（第5.4.2节）。
Processing capacity cannot be guarded as effectively as state capacity.
处理能力无法像状态能力那样得到有效保护。
The SETTINGS frame can be abused to cause a peer to expend additional processing time. This might be done by pointlessly changing SETTINGS parameters, setting multiple undefined parameters, or changing the same setting multiple times in the same frame. WINDOW_UPDATE or PRIORITY frames can be abused to cause an unnecessary waste of resources.
设置框可能被滥用，导致对等方花费额外的处理时间。这可以通过无意义地更改设置参数、设置多个未定义的参数或在同一帧中多次更改同一设置来实现。窗口更新或优先级帧可能被滥用，造成不必要的资源浪费。
Large numbers of small or empty frames can be abused to cause a peer to expend time processing frame headers. Note, however, that some uses are entirely legitimate, such as the sending of an empty DATA or CONTINUATION frame at the end of a stream.
大量的小帧或空帧可能被滥用，导致对等方花费时间处理帧头。但是，请注意，某些使用是完全合法的，例如在流的末尾发送空数据或继续帧。
Header compression also offers some opportunities to waste processing resources; see Section 7 of [COMPRESSION] for more details on potential abuses.
标头压缩还提供了一些浪费处理资源的机会；有关潜在滥用的更多详细信息，请参见[压缩]第7节。
Limits in SETTINGS parameters cannot be reduced instantaneously, which leaves an endpoint exposed to behavior from a peer that could exceed the new limits. In particular, immediately after establishing a connection, limits set by a server are not known to clients and could be exceeded without being an obvious protocol violation.
设置参数中的限制不能立即减少，这会使端点暴露于可能超过新限制的对等方行为。特别是，在建立连接后，客户端不知道服务器设置的限制，可以在不明显违反协议的情况下超过这些限制。
All these features -- i.e., SETTINGS changes, small frames, header compression -- have legitimate uses. These features become a burden only when they are used unnecessarily or to excess.
所有这些特性——即设置更改、小帧、头压缩——都有合法的用途。这些特性只有在不必要或过度使用时才会成为负担。
An endpoint that doesn't monitor this behavior exposes itself to a risk of denial-of-service attack. Implementations SHOULD track the use of these features and set limits on their use. An endpoint MAY treat activity that is suspicious as a connection error (Section 5.4.1) of type ENHANCE_YOUR_CALM.
不监视此行为的端点会使自己面临拒绝服务攻击的风险。实现应跟踪这些功能的使用情况，并对其使用设置限制。端点可将可疑活动视为Enhanced_YOUR_CALM类型的连接错误（第5.4.1节）。
A large header block (Section 4.3) can cause an implementation to commit a large amount of state. Header fields that are critical for routing can appear toward the end of a header block, which prevents streaming of header fields to their ultimate destination. This ordering and other reasons, such as ensuring cache correctness, mean
较大的头块（第4.3节）会导致实现提交大量状态。对于路由至关重要的标头字段可能会出现在标头块的末尾，这会阻止标头字段流式传输到最终目的地。这种排序和其他原因（如确保缓存正确性）意味着
that an endpoint might need to buffer the entire header block. Since there is no hard limit to the size of a header block, some endpoints could be forced to commit a large amount of available memory for header fields.
端点可能需要缓冲整个头块。由于头块的大小没有硬限制，因此可能会强制某些端点为头字段提交大量可用内存。
An endpoint can use the SETTINGS_MAX_HEADER_LIST_SIZE to advise peers of limits that might apply on the size of header blocks. This setting is only advisory, so endpoints MAY choose to send header blocks that exceed this limit and risk having the request or response being treated as malformed. This setting is specific to a connection, so any request or response could encounter a hop with a lower, unknown limit. An intermediary can attempt to avoid this problem by passing on values presented by different peers, but they are not obligated to do so.
端点可以使用设置\u MAX\u HEADER\u LIST\u SIZE来通知对等方可能应用于头块大小的限制。此设置只是建议性的，因此端点可能选择发送超出此限制的头块，并可能导致请求或响应被视为格式错误。此设置特定于连接，因此任何请求或响应都可能遇到具有较低未知限制的跃点。中介可以尝试通过传递不同对等方提供的值来避免此问题，但他们没有义务这样做。
A server that receives a larger header block than it is willing to handle can send an HTTP 431 (Request Header Fields Too Large) status code [RFC6585]. A client can discard responses that it cannot process. The header block MUST be processed to ensure a consistent connection state, unless the connection is closed.
如果服务器接收到的头块比它愿意处理的头块大，则可以发送HTTP 431（请求头字段太大）状态代码[RFC6585]。客户端可以放弃它无法处理的响应。必须处理头块以确保连接状态一致，除非连接已关闭。
The CONNECT method can be used to create disproportionate load on an proxy, since stream creation is relatively inexpensive when compared to the creation and maintenance of a TCP connection. A proxy might also maintain some resources for a TCP connection beyond the closing of the stream that carries the CONNECT request, since the outgoing TCP connection remains in the TIME_WAIT state. Therefore, a proxy cannot rely on SETTINGS_MAX_CONCURRENT_STREAMS alone to limit the resources consumed by CONNECT requests.
CONNECT方法可用于在代理上创建不成比例的负载，因为与TCP连接的创建和维护相比，流创建相对便宜。代理还可以在承载连接请求的流关闭之后为TCP连接维护一些资源，因为传出TCP连接仍处于TIME_WAIT状态。因此，代理不能仅依靠设置\u MAX\u并发\u流来限制连接请求消耗的资源。
Compression can allow an attacker to recover secret data when it is compressed in the same context as data under attacker control. HTTP/2 enables compression of header fields (Section 4.3); the following concerns also apply to the use of HTTP compressed content-codings ([RFC7231], Section 3.1.2.1).
当机密数据在与攻击者控制下的数据相同的上下文中压缩时，压缩可使攻击者恢复机密数据。HTTP/2支持头字段的压缩（第4.3节）；以下问题也适用于HTTP压缩内容编码的使用（[RFC7231]，第3.1.2.1节）。
There are demonstrable attacks on compression that exploit the characteristics of the web (e.g., [BREACH]). The attacker induces multiple requests containing varying plaintext, observing the length of the resulting ciphertext in each, which reveals a shorter length when a guess about the secret is correct.
存在利用web特性（例如，[漏洞]）的明显的压缩攻击。攻击者诱导多个包含不同明文的请求，观察每个请求中产生的密文的长度，当对秘密的猜测是正确的时，这会显示较短的长度。
Implementations communicating on a secure channel MUST NOT compress content that includes both confidential and attacker-controlled data unless separate compression dictionaries are used for each source of data. Compression MUST NOT be used if the source of data cannot be reliably determined. Generic stream compression, such as that provided by TLS, MUST NOT be used with HTTP/2 (see Section 9.2).
在安全通道上通信的实现不得压缩包含机密数据和攻击者控制数据的内容，除非对每个数据源使用单独的压缩字典。如果无法可靠地确定数据源，则不得使用压缩。通用流压缩，如TLS提供的压缩，不得与HTTP/2一起使用（见第9.2节）。
Further considerations regarding the compression of header fields are described in [COMPRESSION].
[compression]中描述了有关头字段压缩的更多注意事项。
Padding within HTTP/2 is not intended as a replacement for general purpose padding, such as might be provided by TLS [TLS12]. Redundant padding could even be counterproductive. Correct application can depend on having specific knowledge of the data that is being padded.
HTTP/2中的填充并不打算替代TLS[TLS12]可能提供的通用填充。多余的填充甚至可能适得其反。正确的应用程序可以依赖于对正在填充的数据有特定的了解。
To mitigate attacks that rely on compression, disabling or limiting compression might be preferable to padding as a countermeasure.
为了减轻依赖压缩的攻击，禁用或限制压缩可能比填充更可取。
Padding can be used to obscure the exact size of frame content and is provided to mitigate specific attacks within HTTP, for example, attacks where compressed content includes both attacker-controlled plaintext and secret data (e.g., [BREACH]).
填充可用于隐藏帧内容的确切大小，并用于减轻HTTP中的特定攻击，例如，压缩内容同时包含攻击者控制的明文和机密数据（例如，[break]）的攻击。
Use of padding can result in less protection than might seem immediately obvious. At best, padding only makes it more difficult for an attacker to infer length information by increasing the number of frames an attacker has to observe. Incorrectly implemented padding schemes can be easily defeated. In particular, randomized padding with a predictable distribution provides very little protection; similarly, padding payloads to a fixed size exposes information as payload sizes cross the fixed-sized boundary, which could be possible if an attacker can control plaintext.
使用填充物可能会导致防护效果比看上去立即明显的要差。充其量，填充只会增加攻击者必须观察的帧数，从而使攻击者更难推断长度信息。错误实施的填充方案很容易被击败。特别是，具有可预测分布的随机填充提供的保护很少；类似地，将有效负载填充为固定大小会在有效负载大小跨越固定大小边界时暴露信息，如果攻击者可以控制明文，则可能会出现这种情况。
Intermediaries SHOULD retain padding for DATA frames but MAY drop padding for HEADERS and PUSH_PROMISE frames. A valid reason for an intermediary to change the amount of padding of frames is to improve the protections that padding provides.
中介体应该保留数据帧的填充，但可能会删除头和推送帧的填充。中间层更改帧填充量的一个有效原因是改进填充提供的保护。
Several characteristics of HTTP/2 provide an observer an opportunity to correlate actions of a single client or server over time. These include the value of settings, the manner in which flow-control windows are managed, the way priorities are allocated to streams, the timing of reactions to stimulus, and the handling of any features that are controlled by settings.
HTTP/2的几个特性为观察者提供了一个机会，可以将单个客户机或服务器的操作随时间关联起来。这些包括设置值、流量控制窗口的管理方式、为流分配优先级的方式、对刺激的反应时间以及由设置控制的任何功能的处理。
As far as these create observable differences in behavior, they could be used as a basis for fingerprinting a specific client, as defined in Section 1.8 of [HTML5].
只要这些在行为上产生了明显的差异，它们就可以作为对特定客户进行指纹识别的基础，如[HTML5]第1.8节所定义。
HTTP/2's preference for using a single TCP connection allows correlation of a user's activity on a site. Reusing connections for different origins allows tracking across those origins.
HTTP/2对使用单个TCP连接的偏好允许在站点上关联用户的活动。重用不同来源的连接可以跨这些来源进行跟踪。
Because the PING and SETTINGS frames solicit immediate responses, they can be used by an endpoint to measure latency to their peer. This might have privacy implications in certain scenarios.
由于PING和SETTINGS帧请求立即响应，因此端点可以使用它们来测量对其对等方的延迟。在某些情况下，这可能会影响隐私。
A string for identifying HTTP/2 is entered into the "Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry established in [TLS-ALPN].
用于标识HTTP/2的字符串被输入到[TLS-ALPN]中建立的“应用层协议协商（ALPN）协议ID”注册表中。
This document establishes a registry for frame types, settings, and error codes. These new registries appear in the new "Hypertext Transfer Protocol version 2 (HTTP/2) Parameters" section.
本文档为帧类型、设置和错误代码建立注册表。这些新的注册表出现在新的“超文本传输协议版本2（HTTP/2）参数”部分。
This document registers the HTTP2-Settings header field for use in HTTP; it also registers the 421 (Misdirected Request) status code.
本文档注册了用于HTTP的HTTP2设置头字段；它还注册421（错误定向请求）状态代码。
This document registers the "PRI" method for use in HTTP to avoid collisions with the connection preface (Section 3.5).
本文档注册了在HTTP中使用的“PRI”方法，以避免与连接前言发生冲突（第3.5节）。
This document creates two registrations for the identification of HTTP/2 (see Section 3.3) in the "Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry established in [TLS-ALPN].
本文件在[TLS-ALPN]中建立的“应用层协议协商（ALPN）协议ID”注册表中创建了两个HTTP/2标识注册（见第3.3节）。
The "h2" string identifies HTTP/2 when used over TLS:
通过TLS使用时，“h2”字符串标识HTTP/2：
Protocol: HTTP/2 over TLS
协议：基于TLS的HTTP/2
Identification Sequence: 0x68 0x32 ("h2")
标识顺序：0x68 0x32（“h2”）
Specification: This document
规格：本文件
The "h2c" string identifies HTTP/2 when used over cleartext TCP:
当通过明文TCP使用时，“h2c”字符串标识HTTP/2：
Protocol: HTTP/2 over TCP
协议：TCP上的HTTP/2
Identification Sequence: 0x68 0x32 0x63 ("h2c")
标识顺序：0x68 0x32 0x63（“h2c”）
Specification: This document
规格：本文件
This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame Type" registry manages an 8-bit space. The "HTTP/2 Frame Type" registry operates under either of the "IETF Review" or "IESG Approval" policies [RFC5226] for values between 0x00 and 0xef, with values between 0xf0 and 0xff being reserved for Experimental Use.
本文档为HTTP/2帧类型代码建立了一个注册表。“HTTP/2帧类型”注册表管理8位空间。对于0x00和0xef之间的值，“HTTP/2帧类型”注册表在“IETF审查”或“IESG批准”策略[RFC5226]下运行，0xf0和0xff之间的值保留供实验使用。
New entries in this registry require the following information:
此注册表中的新条目需要以下信息：
Frame Type: A name or label for the frame type.
框架类型：框架类型的名称或标签。
Code: The 8-bit code assigned to the frame type.
代码：指定给帧类型的8位代码。
Specification: A reference to a specification that includes a description of the frame layout, its semantics, and flags that the frame type uses, including any parts of the frame that are conditionally present based on the value of flags.
规范：对规范的引用，包括对框架布局、其语义和框架类型使用的标志的描述，包括基于标志值有条件显示的框架的任何部分。
The entries in the following table are registered by this document.
下表中的条目由本文档注册。
+---------------+------+--------------+
| Frame Type | Code | Section |
+---------------+------+--------------+
| DATA | 0x0 | Section 6.1 |
| HEADERS | 0x1 | Section 6.2 |
| PRIORITY | 0x2 | Section 6.3 |
| RST_STREAM | 0x3 | Section 6.4 |
| SETTINGS | 0x4 | Section 6.5 |
| PUSH_PROMISE | 0x5 | Section 6.6 |
| PING | 0x6 | Section 6.7 |
| GOAWAY | 0x7 | Section 6.8 |
| WINDOW_UPDATE | 0x8 | Section 6.9 |
| CONTINUATION | 0x9 | Section 6.10 |
+---------------+------+--------------+
+---------------+------+--------------+
| Frame Type | Code | Section |
+---------------+------+--------------+
| DATA | 0x0 | Section 6.1 |
| HEADERS | 0x1 | Section 6.2 |
| PRIORITY | 0x2 | Section 6.3 |
| RST_STREAM | 0x3 | Section 6.4 |
| SETTINGS | 0x4 | Section 6.5 |
| PUSH_PROMISE | 0x5 | Section 6.6 |
| PING | 0x6 | Section 6.7 |
| GOAWAY | 0x7 | Section 6.8 |
| WINDOW_UPDATE | 0x8 | Section 6.9 |
| CONTINUATION | 0x9 | Section 6.10 |
+---------------+------+--------------+
This document establishes a registry for HTTP/2 settings. The "HTTP/2 Settings" registry manages a 16-bit space. The "HTTP/2 Settings" registry operates under the "Expert Review" policy [RFC5226] for values in the range from 0x0000 to 0xefff, with values between and 0xf000 and 0xffff being reserved for Experimental Use.
本文档为HTTP/2设置建立了一个注册表。“HTTP/2设置”注册表管理16位空间。“HTTP/2设置”注册表根据“专家评审”策略[RFC5226]对0x0000到0xefff范围内的值进行操作，0xf000到0xffff之间的值保留供实验使用。
New registrations are advised to provide the following information:
建议新注册者提供以下信息：
Name: A symbolic name for the setting. Specifying a setting name is optional.
名称：设置的符号名称。指定设置名称是可选的。
Code: The 16-bit code assigned to the setting.
代码：分配给设置的16位代码。
Initial Value: An initial value for the setting.
初始值：设置的初始值。
Specification: An optional reference to a specification that describes the use of the setting.
规范：对描述设置使用的规范的可选引用。
The entries in the following table are registered by this document.
下表中的条目由本文档注册。
+------------------------+------+---------------+---------------+
| Name | Code | Initial Value | Specification |
+------------------------+------+---------------+---------------+
| HEADER_TABLE_SIZE | 0x1 | 4096 | Section 6.5.2 |
| ENABLE_PUSH | 0x2 | 1 | Section 6.5.2 |
| MAX_CONCURRENT_STREAMS | 0x3 | (infinite) | Section 6.5.2 |
| INITIAL_WINDOW_SIZE | 0x4 | 65535 | Section 6.5.2 |
| MAX_FRAME_SIZE | 0x5 | 16384 | Section 6.5.2 |
| MAX_HEADER_LIST_SIZE | 0x6 | (infinite) | Section 6.5.2 |
+------------------------+------+---------------+---------------+
+------------------------+------+---------------+---------------+
| Name | Code | Initial Value | Specification |
+------------------------+------+---------------+---------------+
| HEADER_TABLE_SIZE | 0x1 | 4096 | Section 6.5.2 |
| ENABLE_PUSH | 0x2 | 1 | Section 6.5.2 |
| MAX_CONCURRENT_STREAMS | 0x3 | (infinite) | Section 6.5.2 |
| INITIAL_WINDOW_SIZE | 0x4 | 65535 | Section 6.5.2 |
| MAX_FRAME_SIZE | 0x5 | 16384 | Section 6.5.2 |
| MAX_HEADER_LIST_SIZE | 0x6 | (infinite) | Section 6.5.2 |
+------------------------+------+---------------+---------------+
This document establishes a registry for HTTP/2 error codes. The "HTTP/2 Error Code" registry manages a 32-bit space. The "HTTP/2 Error Code" registry operates under the "Expert Review" policy [RFC5226].
本文档为HTTP/2错误代码建立了一个注册表。“HTTP/2错误代码”注册表管理32位空间。“HTTP/2错误代码”注册表在“专家评审”政策下运行[RFC5226]。
Registrations for error codes are required to include a description of the error code. An expert reviewer is advised to examine new registrations for possible duplication with existing error codes. Use of existing registrations is to be encouraged, but not mandated.
错误代码的注册需要包含错误代码的说明。建议专家审查员检查新注册是否可能与现有错误代码重复。鼓励使用现有注册，但不强制使用。
New registrations are advised to provide the following information:
建议新注册者提供以下信息：
Name: A name for the error code. Specifying an error code name is optional.
名称：错误代码的名称。指定错误代码名称是可选的。
Code: The 32-bit error code value.
代码：32位错误代码值。
Description: A brief description of the error code semantics, longer if no detailed specification is provided.
描述：错误代码语义的简要描述，如果未提供详细规范，则不再赘述。
Specification: An optional reference for a specification that defines the error code.
规范：定义错误代码的规范的可选参考。
The entries in the following table are registered by this document.
下表中的条目由本文档注册。
+---------------------+------+----------------------+---------------+
| Name | Code | Description | Specification |
+---------------------+------+----------------------+---------------+
| NO_ERROR | 0x0 | Graceful shutdown | Section 7 |
| PROTOCOL_ERROR | 0x1 | Protocol error | Section 7 |
| | | detected | |
| INTERNAL_ERROR | 0x2 | Implementation fault | Section 7 |
| FLOW_CONTROL_ERROR | 0x3 | Flow-control limits | Section 7 |
| | | exceeded | |
| SETTINGS_TIMEOUT | 0x4 | Settings not | Section 7 |
| | | acknowledged | |
| STREAM_CLOSED | 0x5 | Frame received for | Section 7 |
| | | closed stream | |
| FRAME_SIZE_ERROR | 0x6 | Frame size incorrect | Section 7 |
| REFUSED_STREAM | 0x7 | Stream not processed | Section 7 |
| CANCEL | 0x8 | Stream cancelled | Section 7 |
| COMPRESSION_ERROR | 0x9 | Compression state | Section 7 |
| | | not updated | |
| CONNECT_ERROR | 0xa | TCP connection error | Section 7 |
| | | for CONNECT method | |
| ENHANCE_YOUR_CALM | 0xb | Processing capacity | Section 7 |
| | | exceeded | |
| INADEQUATE_SECURITY | 0xc | Negotiated TLS | Section 7 |
| | | parameters not | |
| | | acceptable | |
| HTTP_1_1_REQUIRED | 0xd | Use HTTP/1.1 for the | Section 7 |
| | | request | |
+---------------------+------+----------------------+---------------+
+---------------------+------+----------------------+---------------+
| Name | Code | Description | Specification |
+---------------------+------+----------------------+---------------+
| NO_ERROR | 0x0 | Graceful shutdown | Section 7 |
| PROTOCOL_ERROR | 0x1 | Protocol error | Section 7 |
| | | detected | |
| INTERNAL_ERROR | 0x2 | Implementation fault | Section 7 |
| FLOW_CONTROL_ERROR | 0x3 | Flow-control limits | Section 7 |
| | | exceeded | |
| SETTINGS_TIMEOUT | 0x4 | Settings not | Section 7 |
| | | acknowledged | |
| STREAM_CLOSED | 0x5 | Frame received for | Section 7 |
| | | closed stream | |
| FRAME_SIZE_ERROR | 0x6 | Frame size incorrect | Section 7 |
| REFUSED_STREAM | 0x7 | Stream not processed | Section 7 |
| CANCEL | 0x8 | Stream cancelled | Section 7 |
| COMPRESSION_ERROR | 0x9 | Compression state | Section 7 |
| | | not updated | |
| CONNECT_ERROR | 0xa | TCP connection error | Section 7 |
| | | for CONNECT method | |
| ENHANCE_YOUR_CALM | 0xb | Processing capacity | Section 7 |
| | | exceeded | |
| INADEQUATE_SECURITY | 0xc | Negotiated TLS | Section 7 |
| | | parameters not | |
| | | acceptable | |
| HTTP_1_1_REQUIRED | 0xd | Use HTTP/1.1 for the | Section 7 |
| | | request | |
+---------------------+------+----------------------+---------------+
This section registers the HTTP2-Settings header field in the "Permanent Message Header Field Names" registry [BCP90].
本节在“永久消息头字段名称”注册表[BCP90]中注册HTTP2设置头字段。
Header field name: HTTP2-Settings
标题字段名称：HTTP2设置
Applicable protocol: http
适用协议：http
Status: standard
状态：标准
Author/Change controller: IETF
作者/变更控制员：IETF
Specification document(s): Section 3.2.1 of this document
规范文件：本文件第3.2.1节
Related information: This header field is only used by an HTTP/2 client for Upgrade-based negotiation.
相关信息：此标头字段仅由HTTP/2客户端用于基于升级的协商。
This section registers the "PRI" method in the "HTTP Method Registry" ([RFC7231], Section 8.1).
本节在“HTTP方法注册表”中注册“PRI”方法（[RFC7231]，第8.1节）。
Method Name: PRI
方法名称：PRI
Safe: Yes
保险柜：是的
Idempotent: Yes
幂等元：是的
Specification document(s): Section 3.5 of this document
规范文件：本文件第3.5节
Related information: This method is never used by an actual client. This method will appear to be used when an HTTP/1.1 server or intermediary attempts to parse an HTTP/2 connection preface.
相关信息：此方法从未被实际客户端使用。当HTTP/1.1服务器或中介试图解析HTTP/2连接时，似乎会使用此方法。
This document registers the 421 (Misdirected Request) HTTP status code in the "HTTP Status Codes" registry ([RFC7231], Section 8.2).
本文档在“HTTP状态代码”注册表中注册421（错误定向请求）HTTP状态代码（[RFC7231]，第8.2节）。
Status Code: 421
状态代码：421
Short Description: Misdirected Request
简短描述：错误的请求
Specification: Section 9.1.2 of this document
规范：本文件第9.1.2节
This document registers the "h2c" upgrade token in the "HTTP Upgrade Tokens" registry ([RFC7230], Section 8.6).
本文档在“HTTP升级令牌”注册表中注册“h2c”升级令牌（[RFC7230]，第8.6节）。
Value: h2c
数值：h2c
Description: Hypertext Transfer Protocol version 2 (HTTP/2)
描述：超文本传输协议版本2（HTTP/2）
Expected Version Tokens: None
预期版本标记：无
Reference: Section 3.2 of this document
参考：本文件第3.2节
[COMPRESSION] Peon, R. and H. Ruellan, "HPACK: Header Compression for HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, <http://www.rfc-editor.org/info/rfc7541>.
[COMPRESSION]Paun，R.和H.Ruellan，“HPACK：HTTP/2的头压缩”，RFC 7541，DOI 10.17487/RFC7541，2015年5月<http://www.rfc-editor.org/info/rfc7541>.
[COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>.
[COOKIE]Barth，A.，“HTTP状态管理机制”，RFC 6265，DOI 10.17487/RFC6265，2011年4月<http://www.rfc-editor.org/info/rfc6265>.
[FIPS186] NIST, "Digital Signature Standard (DSS)", FIPS PUB 186-4, July 2013, <http://dx.doi.org/10.6028/NIST.FIPS.186-4>.
[FIPS186]NIST，“数字签名标准（DSS）”，FIPS PUB 186-42013年7月<http://dx.doi.org/10.6028/NIST.FIPS.186-4>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<http://www.rfc-editor.org/info/rfc2818>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<http://www.rfc-editor.org/info/rfc4648>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的增广BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<http://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.
[RFC7232]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：有条件请求”，RFC 7232，DOI 10.17487/RFC72322014年6月<http://www.rfc-editor.org/info/rfc7232>.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014, <http://www.rfc-editor.org/info/rfc7233>.
[RFC7233]Fielding，R.，Ed.，Lafon，Y.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：范围请求”，RFC 7233，DOI 10.17487/RFC7233，2014年6月<http://www.rfc-editor.org/info/rfc7233>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.
[RFC7234]Fielding，R.，Ed.，Nottingham，M.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：缓存”，RFC 7234，DOI 10.17487/RFC72342014年6月<http://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：认证”，RFC 7235，DOI 10.17487/RFC7235，2014年6月<http://www.rfc-editor.org/info/rfc7235>.
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[TCP]Postel，J.，“传输控制协议”，STD 7，RFC 793，DOI 10.17487/RFC0793，1981年9月<http://www.rfc-editor.org/info/rfc793>.
[TLS-ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <http://www.rfc-editor.org/info/rfc7301>.
[TLS-ALPN]Friedl，S.，Popov，A.，Langley，A.，和E.Stephan，“传输层安全（TLS）应用层协议协商扩展”，RFC 7301，DOI 10.17487/RFC7301，2014年7月<http://www.rfc-editor.org/info/rfc7301>.
[TLS-ECDHE] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, DOI 10.17487/RFC5289, August 2008, <http://www.rfc-editor.org/info/rfc5289>.
[TLS-ECDHE]Rescorla，E.，“具有SHA-256/384和AES伽罗瓦计数器模式（GCM）的TLS椭圆曲线密码套件”，RFC 5289，DOI 10.17487/RFC52892008年8月<http://www.rfc-editor.org/info/rfc5289>.
[TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>.
[TLS-EXT]Eastlake 3rd，D.，“传输层安全（TLS）扩展：扩展定义”，RFC 6066，DOI 10.17487/RFC6066，2011年1月<http://www.rfc-editor.org/info/rfc6066>.
[TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[TLS12]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", Work in Progress, draft-ietf-httpbis-alt-svc-06, February 2015.
[ALT-SVC]诺丁汉，M.，麦克马纳斯，P.，和J.雷什克，“HTTP替代服务”，正在进行的工作，草案-ietf-httpbis-ALT-SVC-062015年2月。
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004, <http://www.rfc-editor.org/info/bcp90>.
[BCP90]Klyne，G.，Nottingham，M.，和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月<http://www.rfc-editor.org/info/bcp90>.
[BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the CRIME Attack", July 2013, <http://breachattack.com/resources/ BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>.
[Break]Gluck，Y.，Harris，N.，和A.Prado，“Break:恢复犯罪攻击”，2013年7月<http://breachattack.com/resources/ 违反%20-%20SSL，%20gone%20in%2030%20seconds.pdf>。
[HTML5] Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Doyle Navara, E., O'Connor, E., and S. Pfeiffer, "HTML5", W3C Recommendation REC-html5-20141028, October 2014, <http://www.w3.org/TR/2014/REC-html5-20141028/>.
[HTML5]Hickson，I.，Berjon，R.，Faulkner，S.，Leithead，T.，Doyle Navara，E.，O'Connor，E.，和S.Pfeiffer，“HTML5”，W3C建议REC-HTML5-20141028，2014年10月<http://www.w3.org/TR/2014/REC-html5-20141028/>.
[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May 2004, <http://www.rfc-editor.org/info/rfc3749>.
[RFC3749]Hollenbeck，S.，“传输层安全协议压缩方法”，RFC 3749，DOI 10.17487/RFC3749，2004年5月<http://www.rfc-editor.org/info/rfc3749>.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, <http://www.rfc-editor.org/info/rfc4492>.
[RFC4492]Blake Wilson，S.，Bolyard，N.，Gupta，V.，Hawk，C.，和B.Moeller，“用于传输层安全（TLS）的椭圆曲线密码（ECC）密码套件”，RFC 4492，DOI 10.17487/RFC4492，2006年5月<http://www.rfc-editor.org/info/rfc4492>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, <http://www.rfc-editor.org/info/rfc6585>.
[RFC6585]诺丁汉，M.和R.菲尔丁，“附加HTTP状态代码”，RFC 6585，DOI 10.17487/RFC6585，2012年4月<http://www.rfc-editor.org/info/rfc6585>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, <http://www.rfc-editor.org/info/rfc7323>.
[RFC7323]Borman，D.，Braden，B.，Jacobson，V.，和R.Scheffenegger，编辑，“高性能TCP扩展”，RFC 7323，DOI 10.17487/RFC73232014年9月<http://www.rfc-editor.org/info/rfc7323>.
[TALKING] Huang, L., Chen, E., Barth, A., Rescorla, E., and C. Jackson, "Talking to Yourself for Fun and Profit", 2011, <http://w2spconf.com/2011/papers/websocket.pdf>.
[谈话]黄，L.，陈，E.，巴特，A.，瑞斯科拉，E.，和C.杰克逊，“为了乐趣和利益而与自己交谈”，2011年<http://w2spconf.com/2011/papers/websocket.pdf>.
[TLSBCP] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[TLSBCP]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
An HTTP/2 implementation MAY treat the negotiation of any of the following cipher suites with TLS 1.2 as a connection error (Section 5.4.1) of type INADEQUATE_SECURITY:
HTTP/2实现可将以下任何密码套件与TLS 1.2的协商视为类型不充分的连接错误（第5.4.1节）：
o TLS_NULL_WITH_NULL_NULL
o TLS_NULL_与_NULL_NULL
o TLS_RSA_WITH_NULL_MD5
o TLS\u RSA\u带\u NULL\u MD5
o TLS_RSA_WITH_NULL_SHA
o TLS_RSA_与_NULL_SHA
o TLS_RSA_EXPORT_WITH_RC4_40_MD5
o TLS_RSA_导出_与_RC4_40_MD5
o TLS_RSA_WITH_RC4_128_MD5
o TLS_RSA_和RC4_128_MD5
o TLS_RSA_WITH_RC4_128_SHA
o TLS_RSA_与_RC4_128_SHA
o TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
o TLS_RSA_导出_带RC2_CBC_40_MD5
o TLS_RSA_WITH_IDEA_CBC_SHA
o TLS_RSA_与_IDEA_CBC_SHA
o TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
o TLS_RSA_导出_与_DES40_CBC_SHA
o TLS_RSA_WITH_DES_CBC_SHA
o TLS_RSA_和CBC_SHA_DES_
o TLS_RSA_WITH_3DES_EDE_CBC_SHA
o TLS_RSA_与_3DES_EDE_CBC_SHA
o TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
o TLS_DH_DSS_导出_与_DES40_CBC_SHA
o TLS_DH_DSS_WITH_DES_CBC_SHA
o TLS_DH_DSS_与CBC_SHA
o TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
o TLS_DH_DSS_与CBC_SHA_3DES_EDE_
o TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
o TLS_DH_RSA_导出_与_DES40_CBC_SHA
o TLS_DH_RSA_WITH_DES_CBC_SHA
o TLS_DH_RSA_与CBC_SHA
o TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
o TLS_DH_RSA_与CBC_SHA_3DES_EDE_
o TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
o TLS_DHE_DSS_导出_与_DES40_CBC_SHA
o TLS_DHE_DSS_WITH_DES_CBC_SHA
o 与CBC SHA合作的TLS_DHE_DSS_
o TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
o 与CBC SHA合作的DSS
o TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
o TLS_DHE_RSA_导出_与_DES40_CBC_SHA
o TLS_DHE_RSA_WITH_DES_CBC_SHA
o TLS_DHE_RSA_与_DES_CBC_SHA
o TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
o TLS_DHE_RSA_与CBC_SHA_3DES_EDE_
o TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
o TLS_DH_anon_导出_RC4_40_MD5
o TLS_DH_anon_WITH_RC4_128_MD5
o TLS_DH_anon_与RC4_128_MD5
o TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
o TLS_DH_anon_出口_与CBC_SHA
o TLS_DH_anon_WITH_DES_CBC_SHA
o 与CBC SHA合作的TLS_DH_anon_
o TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
o 与CBC SHA合作的TLS_DH_anon_
o TLS_KRB5_WITH_DES_CBC_SHA
o TLS_KRB5_与CBC_SHA
o TLS_KRB5_WITH_3DES_EDE_CBC_SHA
o 与CBC_SHA合作的TLS_KRB5_
o TLS_KRB5_WITH_RC4_128_SHA
o TLS_KRB5_与_RC4_128_SHA
o TLS_KRB5_WITH_IDEA_CBC_SHA
o TLS_KRB5_与_IDEA_CBC_SHA
o TLS_KRB5_WITH_DES_CBC_MD5
o TLS_KRB5_和CBC_MD5
o TLS_KRB5_WITH_3DES_EDE_CBC_MD5
o TLS_KRB5_与CBC_MD5
o TLS_KRB5_WITH_RC4_128_MD5
o TLS_KRB5_带RC4_128_MD5
o TLS_KRB5_WITH_IDEA_CBC_MD5
o TLS_KRB5_与_IDEA_CBC_MD5
o TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
o TLS_KRB5_出口_与_DES_CBC_40_SHA
o TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA
o TLS_KRB5_出口_RC2_CBC_40_SHA
o TLS_KRB5_EXPORT_WITH_RC4_40_SHA
o TLS_KRB5_出口_RC4_40_SHA
o TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
o TLS_KRB5_出口_与CBC_40_MD5
o TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5
o TLS_KRB5_导出_RC2_CBC_40_MD5
o TLS_KRB5_EXPORT_WITH_RC4_40_MD5
o TLS_KRB5_导出_RC4_40_MD5
o TLS_PSK_WITH_NULL_SHA
o TLS_PSK_与_NULL_SHA
o TLS_DHE_PSK_WITH_NULL_SHA
o TLS_DHE_PSK_与_NULL_SHA
o TLS_RSA_PSK_WITH_NULL_SHA
o TLS_RSA_PSK_与_NULL_SHA
o TLS_RSA_WITH_AES_128_CBC_SHA
o TLS_RSA_与_AES_128_CBC_SHA
o TLS_DH_DSS_WITH_AES_128_CBC_SHA
o TLS_DH_DSS_与_AES_128_CBC_SHA
o TLS_DH_RSA_WITH_AES_128_CBC_SHA
o TLS_DH_RSA_与_AES_128_CBC_SHA
o TLS_DHE_DSS_WITH_AES_128_CBC_SHA
o TLS_DHE_DSS_与_AES_128_CBC_SHA
o TLS_DHE_RSA_WITH_AES_128_CBC_SHA
o TLS_DHE_RSA_与_AES_128_CBC_SHA
o TLS_DH_anon_WITH_AES_128_CBC_SHA
o TLS_DH_anon_与_AES_128_CBC_SHA
o TLS_RSA_WITH_AES_256_CBC_SHA
o TLS_RSA_与_AES_256_CBC_SHA
o TLS_DH_DSS_WITH_AES_256_CBC_SHA
o TLS_DH_DSS_与AES_256_CBC_SHA
o TLS_DH_RSA_WITH_AES_256_CBC_SHA
o TLS_DH_RSA_与AES_256_CBC_SHA
o TLS_DHE_DSS_WITH_AES_256_CBC_SHA
o TLS_DHE_DSS_与_AES_256_CBC_SHA
o TLS_DHE_RSA_WITH_AES_256_CBC_SHA
o TLS_DHE_RSA_与_AES_256_CBC_SHA
o TLS_DH_anon_WITH_AES_256_CBC_SHA
o TLS_DH_anon_与_AES_256_CBC_SHA
o TLS_RSA_WITH_NULL_SHA256
o TLS_RSA_，带_NULL_SHA256
o TLS_RSA_WITH_AES_128_CBC_SHA256
o TLS_RSA_与_AES_128_CBC_SHA256
o TLS_RSA_WITH_AES_256_CBC_SHA256
o TLS_RSA_与_AES_256_CBC_SHA256
o TLS_DH_DSS_WITH_AES_128_CBC_SHA256
o TLS_DH_DSS_与AES_128_CBC_SHA256
o TLS_DH_RSA_WITH_AES_128_CBC_SHA256
o TLS_DH_RSA_与AES_128_CBC_SHA256
o TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
o TLS_DHE_DSS_与AES_128_CBC_SHA256
o TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
o TLS_RSA_配_茶花_128_CBC_沙
o TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA
o TLS_DH_DSS_和_茶花_128_CBC_SHA
o TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA
o TLS_DH_RSA_与茶花_128_CBC_SHA
o TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
o TLS_DHE_DSS_与_茶花_128_CBC_SHA
o TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
o TLS_DHE_RSA_和_CAMELLIA_128_CBC_SHA
o TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA
o TLS_DH_anon_和_Camelia_128_CBC_SHA
o TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
o TLS_DHE_RSA_与AES_128_CBC_SHA256
o TLS_DH_DSS_WITH_AES_256_CBC_SHA256
o TLS_DH_DSS_与AES_256_CBC_SHA256
o TLS_DH_RSA_WITH_AES_256_CBC_SHA256
o TLS_DH_RSA_与AES_256_CBC_SHA256
o TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
o TLS_DHE_DSS_与AES_256_CBC_SHA256
o TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
o TLS_DHE_RSA_与AES_256_CBC_SHA256
o TLS_DH_anon_WITH_AES_128_CBC_SHA256
o TLS_DH_anon_与_AES_128_CBC_SHA256
o TLS_DH_anon_WITH_AES_256_CBC_SHA256
o TLS_DH_anon_与AES_256_CBC_SHA256
o TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
o TLS_RSA_配_茶花_256_CBC_沙
o TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA
o TLS_DH_DSS_和_茶花_256_CBC_SHA
o TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA
o TLS_DH_RSA_和_茶花_256_CBC_SHA
o TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
o TLS_DHE_DSS_与_茶花_256_CBC_SHA
o TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
o TLS_DHE_RSA_和_茶花_256_CBC_SHA
o TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA
o TLS_DH_anon_和_Camelia_256_CBC_SHA
o TLS_PSK_WITH_RC4_128_SHA
o TLS_PSK_与_RC4_128_SHA
o TLS_PSK_WITH_3DES_EDE_CBC_SHA
o 与CBC_SHA合作的TLS_PSK_
o TLS_PSK_WITH_AES_128_CBC_SHA
o TLS_PSK_与_AES_128_CBC_SHA
o TLS_PSK_WITH_AES_256_CBC_SHA
o TLS_PSK_与_AES_256_CBC_SHA
o TLS_DHE_PSK_WITH_RC4_128_SHA
o TLS_DHE_PSK_与_RC4_128_SHA
o TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA
o 与CBC SHA合作的TLS_DHE_PSK_
o TLS_DHE_PSK_WITH_AES_128_CBC_SHA
o TLS_DHE_PSK_与_AES_128_CBC_SHA
o TLS_DHE_PSK_WITH_AES_256_CBC_SHA
o TLS_DHE_PSK_与_AES_256_CBC_SHA
o TLS_RSA_PSK_WITH_RC4_128_SHA
o TLS_RSA_PSK_与_RC4_128_SHA
o TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA
o TLS_RSA_PSK_与CBC_SHA_3DES_EDE_
o TLS_RSA_PSK_WITH_AES_128_CBC_SHA
o TLS_RSA_PSK_与_AES_128_CBC_SHA
o TLS_RSA_PSK_WITH_AES_256_CBC_SHA
o TLS_RSA_PSK_与AES_256_CBC_SHA
o TLS_RSA_WITH_SEED_CBC_SHA
o TLS_RSA_与_SEED_CBC_SHA
o TLS_DH_DSS_WITH_SEED_CBC_SHA
o TLS_DH_DSS_与_SEED_CBC_SHA
o TLS_DH_RSA_WITH_SEED_CBC_SHA
o TLS_DH_RSA_与_SEED_CBC_SHA
o TLS_DHE_DSS_WITH_SEED_CBC_SHA
o TLS_DHE_DSS_与_SEED_CBC_SHA
o TLS_DHE_RSA_WITH_SEED_CBC_SHA
o TLS_DHE_RSA_与_SEED_CBC_SHA
o TLS_DH_anon_WITH_SEED_CBC_SHA
o 带种子的TLS_DH_anon___CBC_SHA
o TLS_RSA_WITH_AES_128_GCM_SHA256
o TLS_RSA_和_AES_128_GCM_SHA256
o TLS_RSA_WITH_AES_256_GCM_SHA384
o TLS_RSA_与_AES_256_GCM_SHA384
o TLS_DH_RSA_WITH_AES_128_GCM_SHA256
o TLS_DH_RSA_与AES_128_GCM_SHA256
o TLS_DH_RSA_WITH_AES_256_GCM_SHA384
o TLS_DH_RSA_与AES_256_GCM_SHA384
o TLS_DH_DSS_WITH_AES_128_GCM_SHA256
o TLS_DH_DSS_与AES_128_GCM_SHA256
o TLS_DH_DSS_WITH_AES_256_GCM_SHA384
o TLS_DH_DSS_与AES_256_GCM_SHA384
o TLS_DH_anon_WITH_AES_128_GCM_SHA256
o TLS_DH_anon_与AES_128_GCM_SHA256
o TLS_DH_anon_WITH_AES_256_GCM_SHA384
o TLS_DH_anon_与AES_256_GCM_SHA384
o TLS_PSK_WITH_AES_128_GCM_SHA256
o TLS_PSK_带AES_128_GCM_SHA256
o TLS_PSK_WITH_AES_256_GCM_SHA384
o TLS_PSK_和_AES_256_GCM_SHA384
o TLS_RSA_PSK_WITH_AES_128_GCM_SHA256
o TLS_RSA_PSK_与AES_128_GCM_SHA256
o TLS_RSA_PSK_WITH_AES_256_GCM_SHA384
o TLS_RSA_PSK_与AES_256_GCM_SHA384
o TLS_PSK_WITH_AES_128_CBC_SHA256
o TLS_PSK_与AES_128_CBC_SHA256
o TLS_PSK_WITH_AES_256_CBC_SHA384
o TLS_PSK_与AES_256_CBC_SHA384
o TLS_PSK_WITH_NULL_SHA256
o TLS_PSK_带_NULL_SHA256
o TLS_PSK_WITH_NULL_SHA384
o TLS_PSK_与_NULL_SHA384
o TLS_DHE_PSK_WITH_AES_128_CBC_SHA256
o TLS_DHE_PSK_与AES_128_CBC_SHA256
o TLS_DHE_PSK_WITH_AES_256_CBC_SHA384
o TLS_DHE_PSK_与AES_256_CBC_SHA384
o TLS_DHE_PSK_WITH_NULL_SHA256
o TLS_DHE_PSK_与_NULL_SHA256
o TLS_DHE_PSK_WITH_NULL_SHA384
o TLS_DHE_PSK_与_NULL_SHA384
o TLS_RSA_PSK_WITH_AES_128_CBC_SHA256
o TLS_RSA_PSK_与AES_128_CBC_SHA256
o TLS_RSA_PSK_WITH_AES_256_CBC_SHA384
o TLS_RSA_PSK_与AES_256_CBC_SHA384
o TLS_RSA_PSK_WITH_NULL_SHA256
o TLS_RSA_PSK_与_NULL_SHA256
o TLS_RSA_PSK_WITH_NULL_SHA384
o TLS_RSA_PSK_与_NULL_SHA384
o TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256
o TLS_RSA_带山茶花_128_CBC_SHA256
o TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256
o TLS_DH_DSS_带茶花_128_CBC_SHA256
o TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256
o TLS_DH_RSA_与茶花_128_CBC_SHA256
o TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256
o TLS_DHE_DSS_与茶花_128_CBC_SHA256
o TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
o TLS_DHE_RSA_和_CAMELLIA_128_CBC_SHA256
o TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256
o TLS_DH_anon_和_Camelia_128_CBC_SHA256
o TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256
o TLS_RSA_与_CAMELLIA_256_CBC_SHA256
o TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256
o TLS_DH_DSS_与_茶花_256_CBC_SHA256
o TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256
o TLS_DH_RSA_与茶花_256_CBC_SHA256
o TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256
o TLS_DHE_DSS_与_茶花_256_CBC_SHA256
o TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256
o TLS_DHE_RSA_和_CAMELLIA_256_CBC_SHA256
o TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256
o TLS_DH_anon_和_Camelia_256_CBC_SHA256
o TLS_EMPTY_RENEGOTIATION_INFO_SCSV
o TLS\u空\u重新协商\u信息\u SCSV
o TLS_ECDH_ECDSA_WITH_NULL_SHA
o TLS_ECDH_ECDSA_与_NULL_SHA
o TLS_ECDH_ECDSA_WITH_RC4_128_SHA
o TLS_ECDH_ECDSA_与_RC4_128_SHA
o TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
o TLS_ECDH_ECDSA_与_3DES_EDE_CBC_SHA
o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
o TLS_ECDH_ECDSA_与_AES_128_CBC_SHA
o TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
o TLS_ECDH_ECDSA_与_AES_256_CBC_SHA
o TLS_ECDHE_ECDSA_WITH_NULL_SHA
o TLS_ECDHE_ECDSA_与_NULL_SHA
o TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
o 带RC4的TLS_ECDHE_ECDSA_
o TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
o 与CBC SHA合作的TLS_ECDHE_ECDSA_
o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
o TLS_ECDHE_ECDSA_与_AES_128_CBC_SHA
o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
o TLS_ECDHE_ECDSA_与_AES_256_CBC_SHA
o TLS_ECDH_RSA_WITH_NULL_SHA
o TLS_ECDH_RSA_与_NULL_SHA
o TLS_ECDH_RSA_WITH_RC4_128_SHA
o TLS_ECDH_RSA_与_RC4_128_SHA
o TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
o TLS_ECDH_RSA_与CBC_SHA_3DES_EDE_
o TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
o TLS_ECDH_RSA_与_AES_128_CBC_SHA
o TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
o TLS_ECDH_RSA_与_AES_256_CBC_SHA
o TLS_ECDHE_RSA_WITH_NULL_SHA
o TLS_ECDHE_RSA_与_NULL_SHA
o TLS_ECDHE_RSA_WITH_RC4_128_SHA
o TLS_ECDHE_RSA_与_RC4_128_SHA
o TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
o 与CBC SHA合作的TLS_ECDHE_RSA_
o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
o TLS_ECDHE_RSA_与_AES_128_CBC_SHA
o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
o TLS_ECDHE_RSA_与_AES_256_CBC_SHA
o TLS_ECDH_anon_WITH_NULL_SHA
o TLS_ECDH_anon_与_NULL_SHA
o TLS_ECDH_anon_WITH_RC4_128_SHA
o TLS_ECDH_anon_与_RC4_128_SHA
o TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
o ECDH与CBC的合作
o TLS_ECDH_anon_WITH_AES_128_CBC_SHA
o TLS_ECDH_anon_与_AES_128_CBC_SHA
o TLS_ECDH_anon_WITH_AES_256_CBC_SHA
o TLS_ECDH_anon_与_AES_256_CBC_SHA
o TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA
o TLS_SRP_SHA_与CBC_SHA_3DES_EDE_
o TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA
o TLS_SRP_SHA_RSA_与CBC_SHA_3DES_EDE_
o TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA
o TLS_SRP_SHA_DSS_与CBC_SHA_3DES_EDE_
o TLS_SRP_SHA_WITH_AES_128_CBC_SHA
o TLS_SRP_SHA_与AES_128_CBC_SHA_
o TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA
o TLS_SRP_SHA_RSA_与AES_128_CBC_SHA
o TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA
o TLS_SRP_SHA_DSS_与AES_128_CBC_SHA
o TLS_SRP_SHA_WITH_AES_256_CBC_SHA
o TLS_SRP_SHA_与AES_256_CBC_SHA_
o TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA
o TLS_SRP_SHA_RSA_与AES_256_CBC_SHA
o TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA
o TLS_SRP_SHA_DSS_与AES_256_CBC_SHA
o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
o TLS_ECDHE_ECDSA_与_AES_128_CBC_SHA256
o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
o TLS_ECDHE_ECDSA_与_AES_256_CBC_SHA384
o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
o TLS_ECDH_ECDSA_与_AES_128_CBC_SHA256
o TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
o TLS_ECDH_ECDSA_与_AES_256_CBC_SHA384
o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
o TLS_ECDHE_RSA_与_AES_128_CBC_SHA256
o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
o TLS_ECDHE_RSA_与_AES_256_CBC_SHA384
o TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
o TLS_ECDH_RSA_与_AES_128_CBC_SHA256
o TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
o TLS_ECDH_RSA_与_AES_256_CBC_SHA384
o TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
o TLS_ECDH_ECDSA_与_AES_128_GCM_SHA256
o TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
o TLS_ECDH_ECDSA_与_AES_256_GCM_SHA384
o TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDH_RSA_与_AES_128_GCM_SHA256
o TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
o TLS_ECDH_RSA_与_AES_256_GCM_SHA384
o TLS_ECDHE_PSK_WITH_RC4_128_SHA
o 带RC4和128个SHA的TLS_ECDHE_PSK_
o TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA
o 与CBC SHA合作的项目
o TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA
o 带AES的TLS_ECDHE_PSK_128_CBC_SHA
o TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA
o 带AES的TLS_ECDHE_PSK_256_CBC_SHA
o TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256
o TLS_ECDHE_PSK_与_AES_128_CBC_SHA256
o TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384
o TLS_ECDHE_PSK_与_AES_256_CBC_SHA384
o TLS_ECDHE_PSK_WITH_NULL_SHA
o TLS_ECDHE_PSK_与_NULL_SHA
o TLS_ECDHE_PSK_WITH_NULL_SHA256
o TLS_ECDHE_PSK_与_NULL_SHA256
o TLS_ECDHE_PSK_WITH_NULL_SHA384
o TLS_ECDHE_PSK_与_NULL_SHA384
o TLS_RSA_WITH_ARIA_128_CBC_SHA256
o TLS_RSA_与_ARIA_128_CBC_SHA256
o TLS_RSA_WITH_ARIA_256_CBC_SHA384
o TLS_RSA_与_ARIA_256_CBC_SHA384
o TLS_DH_DSS_WITH_ARIA_128_CBC_SHA256
o TLS_DH_DSS_与ARIA_128_CBC_SHA256
o TLS_DH_DSS_WITH_ARIA_256_CBC_SHA384
o TLS_DH_DSS_与_ARIA_256_CBC_SHA384
o TLS_DH_RSA_WITH_ARIA_128_CBC_SHA256
o TLS_DH_RSA_与ARIA_128_CBC_SHA256
o TLS_DH_RSA_WITH_ARIA_256_CBC_SHA384
o TLS_DH_RSA_与_ARIA_256_CBC_SHA384
o TLS_DHE_DSS_WITH_ARIA_128_CBC_SHA256
o TLS_DHE_DSS_与_ARIA_128_CBC_SHA256
o TLS_DHE_DSS_WITH_ARIA_256_CBC_SHA384
o TLS_DHE_DSS_与_ARIA_256_CBC_SHA384
o TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256
o TLS_DHE_RSA_与_ARIA_128_CBC_SHA256
o TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384
o TLS_DHE_RSA_与_ARIA_256_CBC_SHA384
o TLS_DH_anon_WITH_ARIA_128_CBC_SHA256
o TLS_DH_anon_与_ARIA_128_CBC_SHA256
o TLS_DH_anon_WITH_ARIA_256_CBC_SHA384
o TLS_DH_anon_与_ARIA_256_CBC_SHA384
o TLS_ECDHE_ECDSA_WITH_ARIA_128_CBC_SHA256
o TLS_ECDHE_ECDSA_与_ARIA_128_CBC_SHA256
o TLS_ECDHE_ECDSA_WITH_ARIA_256_CBC_SHA384
o TLS_ECDHE_ECDSA_与_ARIA_256_CBC_SHA384
o TLS_ECDH_ECDSA_WITH_ARIA_128_CBC_SHA256
o TLS_ECDH_ECDSA_带_ARIA_128_CBC_SHA256
o TLS_ECDH_ECDSA_WITH_ARIA_256_CBC_SHA384
o TLS_ECDH_ECDSA_与_ARIA_256_CBC_SHA384
o TLS_ECDHE_RSA_WITH_ARIA_128_CBC_SHA256
o TLS_ECDHE_RSA_与_ARIA_128_CBC_SHA256
o TLS_ECDHE_RSA_WITH_ARIA_256_CBC_SHA384
o TLS_ECDHE_RSA_与_ARIA_256_CBC_SHA384
o TLS_ECDH_RSA_WITH_ARIA_128_CBC_SHA256
o TLS_ECDH_RSA_与_ARIA_128_CBC_SHA256
o TLS_ECDH_RSA_WITH_ARIA_256_CBC_SHA384
o TLS_ECDH_RSA_与_ARIA_256_CBC_SHA384
o TLS_RSA_WITH_ARIA_128_GCM_SHA256
o TLS_RSA_，带ARIA_128_GCM_SHA256
o TLS_RSA_WITH_ARIA_256_GCM_SHA384
o TLS_RSA_和_ARIA_256_GCM_SHA384
o TLS_DH_RSA_WITH_ARIA_128_GCM_SHA256
o TLS_DH_RSA_，带ARIA_128_GCM_SHA256
o TLS_DH_RSA_WITH_ARIA_256_GCM_SHA384
o TLS_DH_RSA_和_ARIA_256_GCM_SHA384
o TLS_DH_DSS_WITH_ARIA_128_GCM_SHA256
o TLS_DH_DSS_，带ARIA_128_GCM_SHA256
o TLS_DH_DSS_WITH_ARIA_256_GCM_SHA384
o TLS_DH_DSS_与_ARIA_256_GCM_SHA384
o TLS_DH_anon_WITH_ARIA_128_GCM_SHA256
o TLS_DH_anon_与_ARIA_128_GCM_SHA256
o TLS_DH_anon_WITH_ARIA_256_GCM_SHA384
o TLS_DH_anon_与_ARIA_256_GCM_SHA384
o TLS_ECDH_ECDSA_WITH_ARIA_128_GCM_SHA256
o TLS_ECDH_ECDSA_与_ARIA_128_GCM_SHA256
o TLS_ECDH_ECDSA_WITH_ARIA_256_GCM_SHA384
o TLS_ECDH_ECDSA_与_ARIA_256_GCM_SHA384
o TLS_ECDH_RSA_WITH_ARIA_128_GCM_SHA256
o TLS_ECDH_RSA_与_ARIA_128_GCM_SHA256
o TLS_ECDH_RSA_WITH_ARIA_256_GCM_SHA384
o TLS_ECDH_RSA_与_ARIA_256_GCM_SHA384
o TLS_PSK_WITH_ARIA_128_CBC_SHA256
o TLS_PSK_与_ARIA_128_CBC_SHA256
o TLS_PSK_WITH_ARIA_256_CBC_SHA384
o TLS_PSK_与_ARIA_256_CBC_SHA384
o TLS_DHE_PSK_WITH_ARIA_128_CBC_SHA256
o TLS_DHE_PSK_与_ARIA_128_CBC_SHA256
o TLS_DHE_PSK_WITH_ARIA_256_CBC_SHA384
o TLS_DHE_PSK_与_ARIA_256_CBC_SHA384
o TLS_RSA_PSK_WITH_ARIA_128_CBC_SHA256
o TLS_RSA_PSK_与_ARIA_128_CBC_SHA256
o TLS_RSA_PSK_WITH_ARIA_256_CBC_SHA384
o TLS_RSA_PSK_与_ARIA_256_CBC_SHA384
o TLS_PSK_WITH_ARIA_128_GCM_SHA256
o TLS_PSK_与_ARIA_128_GCM_SHA256
o TLS_PSK_WITH_ARIA_256_GCM_SHA384
o TLS_PSK_与_ARIA_256_GCM_SHA384
o TLS_RSA_PSK_WITH_ARIA_128_GCM_SHA256
o TLS_RSA_PSK_与_ARIA_128_GCM_SHA256
o TLS_RSA_PSK_WITH_ARIA_256_GCM_SHA384
o TLS_RSA_PSK_与_ARIA_256_GCM_SHA384
o TLS_ECDHE_PSK_WITH_ARIA_128_CBC_SHA256
o TLS_ECDHE_PSK_与_ARIA_128_CBC_SHA256
o TLS_ECDHE_PSK_WITH_ARIA_256_CBC_SHA384
o 带咏叹调的TLS_ECDHE_PSK_256_CBC_SHA384
o TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256
o TLS_ECDHE_ECDSA_带茶花_128_CBC_SHA256
o TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384
o TLS_ECDHE_ECDSA_与茶花_256_CBC_SHA384
o TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256
o TLS_ECDH_ECDSA_和_茶花_128_CBC_SHA256
o TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384
o TLS_ECDH_ECDSA_和_茶花_256_CBC_SHA384
o TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
o TLS_ECDHE_RSA_和_CAMELLIA_128_CBC_SHA256
o TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384
o TLS_ECDHE_RSA_和_CAMELLIA_256_CBC_SHA384
o TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256
o TLS_ECDH_RSA_和_CAMELLIA_128_CBC_SHA256
o TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384
o TLS_ECDH_RSA_和_CAMELLIA_256_CBC_SHA384
o TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256
o TLS_RSA_带茶花_128_GCM_SHA256
o TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384
o TLS_RSA_带茶花_256_GCM_SHA384
o TLS_DH_RSA_WITH_CAMELLIA_128_GCM_SHA256
o TLS_DH_RSA_与茶花_128_GCM_SHA256
o TLS_DH_RSA_WITH_CAMELLIA_256_GCM_SHA384
o TLS_DH_RSA_与茶花_256_GCM_SHA384
o TLS_DH_DSS_WITH_CAMELLIA_128_GCM_SHA256
o TLS_DH_DSS_和_茶花_128_GCM_SHA256
o TLS_DH_DSS_WITH_CAMELLIA_256_GCM_SHA384
o TLS_DH_DSS_和_茶花_256_GCM_SHA384
o TLS_DH_anon_WITH_CAMELLIA_128_GCM_SHA256
o TLS_DH_anon_和_茶花_128_GCM_SHA256
o TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384
o TLS_DH_anon_和_茶花_256_GCM_SHA384
o TLS_ECDH_ECDSA_WITH_CAMELLIA_128_GCM_SHA256
o TLS_ECDH_ECDSA_和_茶花_128_GCM_SHA256
o TLS_ECDH_ECDSA_WITH_CAMELLIA_256_GCM_SHA384
o TLS_ECDH_ECDSA_和_茶花_256_GCM_SHA384
o TLS_ECDH_RSA_WITH_CAMELLIA_128_GCM_SHA256
o TLS_ECDH_RSA_和_CAMELLIA_128_GCM_SHA256
o TLS_ECDH_RSA_WITH_CAMELLIA_256_GCM_SHA384
o TLS_ECDH_RSA_和_CAMELLIA_256_GCM_SHA384
o TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256
o TLS_PSK_配茶花_128_GCM_SHA256
o TLS_PSK_WITH_CAMELLIA_256_GCM_SHA384
o TLS_PSK_带茶花_256_GCM_SHA384
o TLS_RSA_PSK_WITH_CAMELLIA_128_GCM_SHA256
o TLS_RSA_PSK_带茶花_128_GCM_SHA256
o TLS_RSA_PSK_WITH_CAMELLIA_256_GCM_SHA384
o TLS_RSA_PSK_和_CAMELLIA_256_GCM_SHA384
o TLS_PSK_WITH_CAMELLIA_128_CBC_SHA256
o TLS_PSK_配茶花_128_CBC_SHA256
o TLS_PSK_WITH_CAMELLIA_256_CBC_SHA384
o TLS_PSK_带茶花_256_CBC_SHA384
o TLS_DHE_PSK_WITH_CAMELLIA_128_CBC_SHA256
o TLS_DHE_PSK_与_茶花_128_CBC_SHA256
o TLS_DHE_PSK_WITH_CAMELLIA_256_CBC_SHA384
o TLS_DHE_PSK_和_茶花_256_CBC_SHA384
o TLS_RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256
o TLS_RSA_PSK_带茶花_128_CBC_SHA256
o TLS_RSA_PSK_WITH_CAMELLIA_256_CBC_SHA384
o TLS_RSA_PSK_和_CAMELLIA_256_CBC_SHA384
o TLS_ECDHE_PSK_WITH_CAMELLIA_128_CBC_SHA256
o 带茶花的TLS_ECDHE_PSK__128_CBC_SHA256
o TLS_ECDHE_PSK_WITH_CAMELLIA_256_CBC_SHA384
o TLS_ECDHE_PSK_和_CAMELLIA_256_CBC_SHA384
o TLS_RSA_WITH_AES_128_CCM
o TLS_RSA_与_AES_128_CCM
o TLS_RSA_WITH_AES_256_CCM
o TLS_RSA_与_AES_256_CCM
o TLS_RSA_WITH_AES_128_CCM_8
o TLS_RSA_与_AES_128_CCM_8
o TLS_RSA_WITH_AES_256_CCM_8
o TLS_RSA_与_AES_256_CCM_8
o TLS_PSK_WITH_AES_128_CCM
o TLS_PSK_与_AES_128_CCM
o TLS_PSK_WITH_AES_256_CCM
o TLS_PSK_，带AES_256_CCM
o TLS_PSK_WITH_AES_128_CCM_8
o TLS_PSK_，带AES_128_CCM_8
o TLS_PSK_WITH_AES_256_CCM_8
o TLS_PSK_，带AES_256_CCM_8
Note: This list was assembled from the set of registered TLS cipher suites at the time of writing. This list includes those cipher suites that do not offer an ephemeral key exchange and those that are based on the TLS null, stream, or block cipher type (as defined in Section 6.2.3 of [TLS12]). Additional cipher suites with these properties could be defined; these would not be explicitly prohibited.
注：此列表是在撰写本文时从已注册的TLS密码套件集合中汇编而成的。该列表包括不提供临时密钥交换的密码套件和基于TLS null、流或分组密码类型的密码套件（如[TLS12]第6.2.3节所定义）。可以定义具有这些属性的其他密码套件；这些措施不会被明确禁止。
Acknowledgements
致谢
This document includes substantial input from the following individuals:
本文件包括以下人员的大量投入：
o Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe Chan, Adam Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay, Paul Amer, Fan Yang, and Jonathan Leighton (SPDY contributors).
o 亚当·兰利、温德昌、吉姆·莫里森、马克·诺丁汉、艾丽莎·威尔克、科斯汀·马诺拉奇、威廉·陈、维塔利·利文、乔·陈、亚当·巴特、瑞安·汉密尔顿、加文·彼得斯、肯特·阿尔斯塔德、凯文·林赛、保罗·艾默尔、范扬和乔纳森·莱顿（SPDY撰稿人）。
o Gabriel Montenegro and Willy Tarreau (Upgrade mechanism).
o 加布里埃尔·黑山和威利·塔罗（升级机制）。
o William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro, Jitu Padhye, Roberto Peon, and Rob Trace (Flow control).
o William Chan、Salvatore Loreto、Osama Mazahir、Gabriel Montegon、Jitu Padhye、Roberto Paon和Rob Trace（流量控制）。
o Mike Bishop (Extensibility).
o Mike Bishop（可扩展性）。
o Mark Nottingham, Julian Reschke, James Snell, Jeff Pinner, Mike Bishop, and Herve Ruellan (Substantial editorial contributions).
o 马克·诺丁汉、朱利安·雷什克、詹姆斯·斯内尔、杰夫·平纳、迈克·毕晓普和埃尔夫·鲁兰（大量编辑贡献）。
o Kari Hurtta, Tatsuhiro Tsujikawa, Greg Wilkins, Poul-Henning Kamp, and Jonathan Thackray.
o Kari Hurtta、Tatsuhiro Tsujikawa、Greg Wilkins、Poul Henning Kamp和Jonathan Thackray。
o Alexey Melnikov, who was an editor of this document in 2013.
o Alexey Melnikov，2013年担任本文件编辑。
A substantial proportion of Martin's contribution was supported by Microsoft during his employment there.
马丁在微软任职期间，很大一部分贡献都得到了微软的支持。
The Japanese HTTP/2 community provided invaluable contributions, including a number of implementations as well as numerous technical and editorial contributions.
日本HTTP/2社区提供了宝贵的贡献，包括许多实现以及许多技术和编辑贡献。
Authors' Addresses
作者地址
Mike Belshe BitGo
Mike Belshe BitGo
EMail: mike@belshe.com
EMail: mike@belshe.com
Roberto Peon Google, Inc
罗伯托·佩恩谷歌公司
EMail: fenix@google.com
EMail: fenix@google.com
Martin Thomson (editor) Mozilla 331 E Evelyn Street Mountain View, CA 94041 United States
马丁·汤姆森（编辑）美国加利福尼亚州伊夫林街山景大道331 E号Mozilla，邮编94041
EMail: martin.thomson@gmail.com
EMail: martin.thomson@gmail.com