[要約] RFC 7540はHTTP/2プロトコルの仕様を定めており、高速で効率的なウェブ通信を実現することを目的としています。HTTP/2は従来のHTTP/1.1よりも多くのリクエストを同時に処理し、ヘッダーの圧縮やストリームの優先順位付けなどの機能を提供します。
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バージョン2（HTTP / 2）と呼ばれるハイパーテキスト転送プロトコル（HTTP）のセマンティクスの最適化された表現について説明しています。 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.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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
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接続で一度に未処理のままにできる要求は1つだけでした。 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）。各フレームタイプは異なる目的を果たします。たとえば、HEADERSフレームとDATAフレームは、HTTP要求と応答の基礎を形成します（セクション8.1）。 SETTINGS、WINDOW_UPDATE、PUSH_PROMISEなどの他のフレームタイプは、他の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）。サーバープッシュを使用すると、サーバーは、クライアントが必要と予想するデータをクライアントに投機的に送信し、潜在的な遅延の増加とネットワーク使用量をトレードオフできます。サーバーは、PUSH_PROMISEフレームとして送信する要求を合成することによってこれを行います。その後、サーバーは別のストリームで合成要求への応答を送信できます。
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）。これは、一般的な場合のリクエストサイズに特に有利な影響を与え、多くのリクエストを1つのパケットに圧縮することができます。
The HTTP/2 specification is split into four parts:
HTTP / 2仕様は4つの部分に分かれています。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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.
すべての数値はネットワークバイト順です。特に明記されていない限り、値は符号なしです。リテラル値は、10進数または16進数で適宜提供されます。 16進数リテラルには、10進数リテラルと区別するために「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.
接続：2つのエンドポイント間のトランスポート層接続。
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です。その結果、 "http://example.org/foo"や "https://example.com/bar"のようなターゲットリソースURIのリクエストを処理する実装は、最初に上流のサーバー（クライアントが接続を確立したい場合）HTTP / 2をサポートします。
The means by which support for HTTP/2 is determined is different for "http" and "https" URIs. Discovery for "http" URIs is described in Section 3.2. Discovery for "https" URIs is described in Section 3.3.
HTTP / 2のサポートが決定される方法は、「http」と「https」のURIでは異なります。 「http」URIの検出については、セクション3.2で説明しています。 「https」URIの検出については、セクション3.3で説明します。
The protocol defined in this document has two identifiers.
このドキュメントで定義されているプロトコルには、2つの識別子があります。
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]フィールド、およびHTTP / 2 over TLSが識別される場所で使用されます。
The "h2" string is serialized into an ALPN protocol identifier as the two-octet sequence: 0x68, 0x32.
「h2」文字列は、2オクテットシーケンス0x68、0x32としてALPNプロトコル識別子にシリアル化されます。
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 Upgradeヘッダーフィールド、およびHTTP / 2 over TCPが識別される場所で使用されます。
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 / 2のサポートに関する事前の知識なしに「http」URIを要求するクライアントは、HTTPアップグレードメカニズムを使用します（[RFC7230]のセクション6.7）。クライアントは、 "h2c"トークンを含むUpgradeヘッダーフィールドを含むHTTP / 1.1リクエストを作成することによってこれを行います。このようなHTTP / 1.1要求には、HTTP2-Settings（セクション3.2.1）ヘッダーフィールドを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>
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」を含むトークンの存在は、HTTP / 2 over TLSを意味し、セクション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フレームは、SETTINGSフレーム（セクション6.5）で構成されるサーバー接続序文（セクション3.5）である必要があります。 101応答を受信すると、クライアントは、SETTINGSフレームを含む接続序文（セクション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リクエストには、デフォルトの優先度値（セクション5.3.5）とともにストリーム識別子1（セクション5.1.1を参照）が割り当てられます。リクエストはHTTP / 1.1リクエストとして完了するため、ストリーム1はクライアントからサーバーに向かって暗黙的に「ハーフクローズ」されます（セクション5.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-Settings」ヘッダーフィールドを1つだけ含める必要があります。 HTTP2-Settingsヘッダーフィールドは接続固有のヘッダーフィールドであり、アップグレードのリクエストを受け入れるサーバーを見越して提供される、HTTP / 2接続を制御するパラメーターが含まれています。
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にアップグレードしてはなりません（MUST NOT）。サーバーはこのヘッダーフィールドを送信してはなりません（MUST NOT）。
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-Settingsヘッダーフィールドを送信するクライアントは、接続ヘッダーフィールドの接続オプションとして「HTTP2-Settings」も送信して、転送されないようにする必要があります（セクション6.1を参照）。 [RFC7230]）。
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.
サーバーは、他のSETTINGSフレームと同様に、これらの値をデコードして解釈します。 101応答は暗黙の確認応答として機能するため、これらの設定の明示的な確認応答（6.5.3節）は必要ありません。アップグレード要求でこれらの値を提供すると、クライアントはサーバーからフレームを受信する前にパラメーターを提供する機会が与えられます。
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へのリクエストを行うクライアントは、アプリケーションレイヤープロトコルネゴシエーション（ALPN）拡張[TLS-ALPN]を備えたTLS [TLS12]を使用します。
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.
HTTP / 2 over TLSは、「h2」プロトコル識別子を使用します。 「h2c」プロトコル識別子は、クライアントによって送信されたり、サーバーによって選択されたりしてはなりません（MUST NOT）。 「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 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].
クライアントは接続の前書き（セクション3.5）を送信しなければならず（MUST）、そのようなサーバーにHTTP / 2フレームをすぐに送信できます（MAY）。サーバーは、接続序文の存在によってこれらの接続を識別できます。これは、クリアテキストTCPを介したHTTP / 2接続の確立にのみ影響します。 HTTP / 2 over TLSをサポートする実装は、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オクテットのシーケンスで始まり、16進表記では次のようになります。
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」で始まります。このシーケンスの後には、空の可能性があるSETTINGSフレーム（セクション6.5）が続く必要があります。クライアントは、101（Switching Protocols）応答（アップグレードの成功を示す）を受信するとすぐに、または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サーバーと仲介者がそれ以上のフレームを処理しようとしないように選択されています。これは[TALKING]で提起された懸念に対処しないことに注意してください。
The server connection preface consists of a potentially empty SETTINGS frame (Section 6.5) that MUST be the first frame the server sends in the HTTP/2 connection.
サーバー接続の前書きは、サーバーがHTTP / 2接続で送信する最初のフレームである必要がある、潜在的に空のSETTINGSフレーム（セクション6.5）で構成されています。
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.
接続序文の一部としてピアから受信したSETTINGSフレームは、接続序文を送信した後で確認する必要があります（セクション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.
不要な待ち時間を回避するために、クライアントは、サーバー接続序文の受信を待たずに、クライアント接続序文を送信した直後にサーバーに追加のフレームを送信できます。ただし、サーバー接続の序文SETTINGSフレームには、クライアントがサーバーと通信する方法を必ず変更するパラメーターが含まれている場合があることに注意してください。 SETTINGSフレームを受信すると、クライアントは確立されたすべてのパラメータを受け入れることが期待されます。一部の構成では、クライアントが追加のフレームを送信する前にサーバーが設定を送信することが可能であり、この問題を回避する機会を提供します。
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.
クライアントとサーバーは、無効な接続序文をタイプPROTOCOL_ERRORの接続エラー（セクション5.4.1）として扱わなければなりません（MUST）。この場合、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オクテットヘッダーで始まり、その後に可変長ペイロードが続きます。
+-----------------------------------------------+
| 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ビット整数として表されるフレームペイロードの長さ。 2 ^ 14（16,384）より大きい値は、受信者がSETTINGS_MAX_FRAME_SIZEに大きな値を設定していない限り送信してはなりません（MUST NOT）。
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.
フレームペイロードのサイズは、受信者がSETTINGS_MAX_FRAME_SIZE設定でアドバタイズする最大サイズによって制限されます。この設定には、2 ^ 14（16,384）〜2 ^ 24-1（16,777,215）オクテットまでの任意の値を指定できます。
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）を受信し、最小限の処理が可能でなければなりません（MUST）。フレームヘッダーのサイズは、フレームサイズを説明するときに含まれていません。
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.
フレームがSETTINGS_MAX_FRAME_SIZEで定義されたサイズを超えている場合、フレームタイプに定義された制限を超えている場合、または小さすぎて必須のフレームデータを含めることができない場合、エンドポイントはFRAME_SIZE_ERRORのエラーコードを送信する必要があります。接続全体の状態を変更する可能性のあるフレームのフレームサイズエラーは、接続エラーとして処理する必要があります（セクション5.4.1）。これには、ヘッダーブロック（セクション4.3）（つまり、HEADERS、PUSH_PROMISE、CONTINUATION）、SETTINGS、およびストリーム識別子が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_STREAM、WINDOW_UPDATE、PRIORITYなど）の送信に遅延が生じる可能性があり、大きなフレームの送信によってブロックされると、パフォーマンスに影響を与える可能性があります。
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のヘッダーフィールドは、1つ以上の関連付けられた値を持つ名前です。ヘッダーフィールドは、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.
ヘッダーリストは、0個以上のヘッダーフィールドのコレクションです。接続を介して送信される場合、ヘッダーリストはHTTPヘッダー圧縮[圧縮]を使用してヘッダーブロックにシリアル化されます。シリアル化されたヘッダーブロックは、ヘッダーブロックフラグメントと呼ばれる1つ以上のオクテットシーケンスに分割され、HEADERS（セクション6.2）、PUSH_PROMISE（セクション6.6）、またはCONTINUATION（セクション6.10）フレームのペイロード内で送信されます。
The Cookie header field [COOKIE] is treated specially by the HTTP mapping (see Section 8.1.2.5).
Cookieヘッダーフィールド[COOKIE]は、HTTPマッピングによって特別に扱われます（セクション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フラグが設定された単一の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フラグがクリアされたHEADERSまたはPUSH_PROMISEフレームと1つ以上のCONTINUATIONフレーム。最後のCONTINUATIONフレームには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.
ヘッダー圧縮はステートフルです。接続全体で1つの圧縮コンテキストと1つの解凍コンテキストが使用されます。ヘッダーブロックのデコードエラーは、タイプ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.
各ヘッダーブロックは個別のユニットとして処理されます。ヘッダーブロックは、他のタイプのインターリーブされたフレームや他のストリームからのフレームの連続したシーケンスとして送信されなければなりません（MUST）。一連のHEADERSまたはCONTINUATIONフレームの最後のフレームには、END_HEADERSフラグが設定されています。 PUSH_PROMISEまたはCONTINUATIONフレームのシーケンスの最後のフレームには、END_HEADERSフラグが設定されています。これにより、ヘッダーブロックを論理的に1つのフレームと同等にすることができます。
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.
ヘッダーブロックフラグメントは、HEADERS、PUSH_PROMISE、またはCONTINUATIONフレームのペイロードとしてのみ送信できます。これらのフレームは、レシーバーによって維持される圧縮コンテキストを変更できるデータを運ぶためです。 HEADERS、PUSH_PROMISE、またはCONTINUATIONフレームを受信するエンドポイントは、ヘッダーブロックを再構成し、フレームを破棄する場合でも解凍を実行する必要があります。ヘッダーブロックを解凍しない場合、受信者はCOMPRESSION_ERRORタイプの接続エラー（セクション5.4.1）で接続を終了する必要があります。
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 フレームがストリームで送信される順序は重要です。受信者は、受信した順にフレームを処理します。特に、HEADERSおよびDATAフレームの順序は、意味的に重要です。
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: endpoint sends this frame recv: endpoint receives this frame
send：エンドポイントがこのフレームを送信するrecv：エンドポイントがこのフレームを受信する
H: HEADERS frame (with implied CONTINUATIONs) PP: PUSH_PROMISE frame (with implied CONTINUATIONs) ES: END_STREAM flag R: RST_STREAM frame
H：HEADERSフレーム（暗黙のCONTINUATIONを含む）PP：PUSH_PROMISEフレーム（暗黙のCONTINUATIONを含む）ES：END_STREAMフラグR：RST_STREAMフレーム
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.
この図は、ストリームの状態遷移と、それらの遷移にのみ影響するフレームとフラグを示していることに注意してください。この点で、CONTINUATIONフレームは状態遷移を引き起こしません。それらは事実上、従うHEADERSまたはPUSH_PROMISEの一部です。
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_STREAMフラグは、それを保持するフレームへの個別のイベントとして処理されます。 END_STREAMフラグが設定されたHEADERSフレームは、2つの状態遷移を引き起こす可能性があります。
Both endpoints have a subjective view of the state of a stream that could be different when frames are in transit. Endpoints do not coordinate the creation of streams; they are created unilaterally by either endpoint. The negative consequences of a mismatch in states are limited to the "closed" state after sending RST_STREAM, where frames might be received for some time after closing.
両方のエンドポイントには、フレームの転送中に異なる可能性があるストリームの状態の主観的なビューがあります。エンドポイントはストリームの作成を調整しません。どちらかのエンドポイントによって一方的に作成されます。状態の不一致による悪影響は、RST_STREAMを送信した後の「クローズ」状態に限定され、クローズ後しばらくの間フレームが受信される可能性があります。
Streams have the following states:
ストリームには次の状態があります。
idle: All streams start in the "idle" state.
アイドル：すべてのストリームは「アイドル」状態で開始します。
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".
* HEADERSフレームを送信または受信すると、ストリームが「オープン」になります。ストリーム識別子は、セクション5.1.1の説明に従って選択されます。同じHEADERSフレームが原因で、ストリームがすぐに「ハーフクローズ」になる場合もあります。
* 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.
* PUSH_PROMISEフレームはアイドルストリームでは送信されませんが、Promised Stream 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.
この状態のストリームでHEADERSまたはPRIORITY以外のフレームを受信した場合は、タイプ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).
予約済み（ローカル）：「予約済み（ローカル）」状態のストリームは、PUSH_PROMISEフレームを送信することによって約束されたストリームです。 PUSH_PROMISEフレームは、リモートピアによって開始されたオープンストリームにストリームを関連付けることにより、アイドルストリームを予約します（セクション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.
* エンドポイントはHEADERSフレームを送信できます。これにより、ストリームは「ハーフクローズ（リモート）」状態で開きます。
* Either endpoint can send a RST_STREAM frame to cause the stream to become "closed". This releases the stream reservation.
* どちらのエンドポイントもRST_STREAMフレームを送信して、ストリームを「クローズ」することができます。これにより、ストリームの予約が解除されます。
An endpoint MUST NOT send any type of frame other than HEADERS, RST_STREAM, or PRIORITY in this state.
エンドポイントは、この状態のHEADERS、RST_STREAM、またはPRIORITY以外のタイプのフレームを送信してはなりません（MUST NOT）。
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.
PRIORITYまたはWINDOW_UPDATEフレームは、この状態で受信される場合があります。この状態のストリームでRST_STREAM、PRIORITY、またはWINDOW_UPDATE以外のタイプのフレームを受信した場合は、PROTOCOL_ERRORタイプの接続エラー（セクション5.4.1）として処理する必要があります。
reserved (remote): A stream in the "reserved (remote)" state has been reserved by a remote peer.
reserved（remote）：「reserved（remote）」状態のストリームは、リモートピアによって予約されています。
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_STREAMフレームを送信して、ストリームを「クローズ」することができます。これにより、ストリームの予約が解除されます。
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.
エンドポイントは、この状態でPRIORITYフレームを送信して、予約されたストリームの優先順位を変更できます。エンドポイントは、この状態でRST_STREAM、WINDOW_UPDATE、またはPRIORITY以外のタイプのフレームを送信してはなりません（MUST NOT）。
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.
この状態のストリームでHEADERS、RST_STREAM、またはPRIORITY以外のタイプのフレームを受信した場合は、タイプPROTOCOL_ERRORの接続エラー（セクション5.4.1）として処理する必要があります。
open: A stream in the "open" state may be used by both peers to send frames of any type. In this state, sending peers observe advertised stream-level flow-control limits (Section 5.2).
open：「open」状態のストリームは、両方のピアが任意のタイプのフレームを送信するために使用できます。この状態では、送信ピアは、アドバタイズされたストリームレベルのフロー制御制限を監視します（セクション5.2）。
From this state, either endpoint can send a frame with an END_STREAM flag set, which causes the stream to transition into one of the "half-closed" states. An endpoint sending an END_STREAM flag causes the stream state to become "half-closed (local)"; an endpoint receiving an END_STREAM flag causes the stream state to become "half-closed (remote)".
この状態から、どちらのエンドポイントもEND_STREAMフラグが設定されたフレームを送信できるため、ストリームが「ハーフクローズ」状態のいずれかに遷移します。 END_STREAMフラグを送信するエンドポイントは、ストリームの状態を「ハーフクローズ（ローカル）」にします。 END_STREAMフラグを受信するエンドポイントは、ストリームの状態を「ハーフクローズ（リモート）」にします。
Either endpoint can send a RST_STREAM frame from this state, causing it to transition immediately to "closed".
どちらのエンドポイントもこの状態からRST_STREAMフレームを送信できるため、すぐに「クローズ」に遷移します。
half-closed (local): A stream that is in the "half-closed (local)" state cannot be used for sending frames other than WINDOW_UPDATE, PRIORITY, and RST_STREAM.
ハーフクローズ（ローカル）：「ハーフクローズ（ローカル）」状態のストリームは、WINDOW_UPDATE、PRIORITY、およびRST_STREAM以外のフレームの送信には使用できません。
A stream transitions from this state to "closed" when a frame that contains an END_STREAM flag is received or when either peer sends a RST_STREAM frame.
END_STREAMフラグを含むフレームを受信したとき、またはいずれかのピアがRST_STREAMフレームを送信したときに、ストリームはこの状態から「クローズ」に移行します。
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.
エンドポイントは、この状態で任意のタイプのフレームを受信できます。 WINDOW_UPDATEフレームを使用してフロー制御クレジットを提供することは、フロー制御フレームの受信を継続するために必要です。この状態では、受信者はWINDOW_UPDATEフレームを無視できます。これは、END_STREAMフラグが付いたフレームが送信された後、短期間到着する可能性があります。
PRIORITY frames received in this state are used to reprioritize streams that depend on the identified stream.
この状態で受信されたPRIORITYフレームは、識別されたストリームに依存するストリームの優先順位を変更するために使用されます。
half-closed (remote): A stream that is "half-closed (remote)" is no longer being used by the peer to send frames. In this state, an endpoint is no longer obligated to maintain a receiver flow-control window.
ハーフクローズ（リモート）：「ハーフクローズ（リモート）」であるストリームは、フレームを送信するためにピアによって使用されていません。この状態では、エンドポイントは、受信側のフロー制御ウィンドウを維持する義務を負いません。
If 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.
エンドポイントがこの状態にあるストリームについて、WINDOW_UPDATE、PRIORITY、またはRST_STREAM以外の追加のフレームを受信した場合、エンドポイントは、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_STREAMフラグを含むフレームを送信するか、いずれかのピアがRST_STREAMフレームを送信すると、この状態から「クローズ」に移行できます。
closed: The "closed" state is the terminal state.
closed：「クローズ」状態は最終状態です。
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.
エンドポイントは、閉じたストリームでPRIORITY以外のフレームを送信してはなりません（MUST NOT）。 RST_STREAMの受信後にPRIORITY以外のフレームを受信したエンドポイントは、それをタイプSTREAM_CLOSEDのストリームエラー（5.4.2節）として扱わなければなりません（MUST）。同様に、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.
WINDOW_UPDATEまたはRST_STREAMフレームは、END_STREAMフラグを含むDATAまたはHEADERSフレームが送信された後、短期間この状態で受信できます。リモートピアは、RST_STREAMまたはEND_STREAMフラグが付いたフレームを受信して処理するまで、これらのタイプのフレームを送信する可能性があります。エンドポイントは、この状態で受信したWINDOW_UPDATEまたはRST_STREAMフレームを無視する必要があります。ただし、エンドポイントは、END_STREAMを送信した後、かなりの時間到着したフレームをタイプPROTOCOL_ERRORの接続エラー（セクション5.4.1）として扱うことを選択できます（MAY）。
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).
PRIORITYフレームをクローズドストリームに送信して、クローズドストリームに依存するストリームに優先順位を付けることができます。エンドポイントはPRIORITYフレームを処理する必要があります（SHOULD）。ただし、ストリームが依存関係ツリーから削除されている場合は無視できます（セクション5.3.4を参照）。
If this state is reached as a result of sending a RST_STREAM frame, the peer that receives the RST_STREAM might have already sent -- or enqueued for sending -- frames on the stream that cannot be withdrawn. An endpoint MUST ignore frames that it receives on closed streams after it has sent a RST_STREAM frame. An endpoint MAY choose to limit the period over which it ignores frames and treat frames that arrive after this time as being in error.
RST_STREAMフレームを送信した結果としてこの状態に達した場合、RST_STREAMを受信したピアが、取り消せないストリーム上でフレームをすでに送信している（または送信のためにキューに入れられている）可能性があります。エンドポイントは、RST_STREAMフレームを送信した後、閉じたストリームで受信するフレームを無視する必要があります。エンドポイントは、フレームを無視する期間を制限し、この時間より後に到着するフレームをエラーとして処理することを選択できます。
Flow-controlled frames (i.e., DATA) received after sending RST_STREAM are counted toward the connection flow-control window. Even though these frames might be ignored, because they are sent before the sender receives the RST_STREAM, the sender will consider the frames to count against the flow-control window.
RST_STREAMの送信後に受信したフロー制御フレーム（つまり、DATA）は、接続フロー制御ウィンドウに対してカウントされます。これらのフレームは無視される可能性がありますが、送信者がRST_STREAMを受信する前に送信されるため、送信者はフレームをフロー制御ウィンドウに対してカウントすることを検討します。
An endpoint might receive a PUSH_PROMISE frame after it sends RST_STREAM. PUSH_PROMISE causes a stream to become "reserved" even if the associated stream has been reset. Therefore, a RST_STREAM is needed to close an unwanted promised stream.
エンドポイントは、RST_STREAMを送信した後にPUSH_PROMISEフレームを受信する場合があります。 PUSH_PROMISEは、関連付けられたストリームがリセットされていても、ストリームを「予約」します。したがって、不要な約束されたストリームを閉じるには、RST_STREAMが必要です。
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）として扱う必要があります。 PRIORITYは、どのストリーム状態でも送受信できることに注意してください。不明なタイプのフレームは無視されます。
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.
新しく確立されたストリームの識別子は、開始エンドポイントが開いたか予約したすべてのストリームよりも数値的に大きくなければなりません（MUST）。これは、HEADERSフレームを使用して開かれたストリームと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.
新しいストリーム識別子の最初の使用は、より低い値のストリーム識別子を持つそのピアによって開始された可能性がある「アイドル」状態のすべてのストリームを暗黙的に閉じます。たとえば、クライアントがストリーム5にフレームを送信せずにストリーム7にHEADERSフレームを送信した場合、ストリーム7の最初のフレームが送信または受信されると、ストリーム5は「クローズ」状態に移行します。
Stream identifiers cannot be reused. Long-lived connections can result in an endpoint exhausting the available range of stream identifiers. A client that is unable to establish a new stream identifier can establish a new connection for new streams. A server that is unable to establish a new stream identifier can send a GOAWAY frame so that the client is forced to open a new connection for new streams.
ストリーム識別子は再利用できません。存続時間が長いと、エンドポイントがストリーム識別子の使用可能な範囲を使い果たす可能性があります。新しいストリーム識別子を確立できないクライアントは、新しいストリームの新しい接続を確立できます。新しいストリーム識別子を確立できないサーバーはGOAWAYフレームを送信できるため、クライアントは新しいストリーム用に新しい接続を開く必要があります。
A peer can limit the number of concurrently active streams using the SETTINGS_MAX_CONCURRENT_STREAMS parameter (see Section 6.5.2) within a SETTINGS frame. The maximum concurrent streams setting is specific to each endpoint and applies only to the peer that receives the setting. That is, clients specify the maximum number of concurrent streams the server can initiate, and servers specify the maximum number of concurrent streams the client can initiate.
ピアは、SETTINGSフレーム内のSETTINGS_MAX_CONCURRENT_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.
「オープン」状態または「ハーフクローズ」状態のいずれかにあるストリームは、エンドポイントが開くことを許可されているストリームの最大数にカウントされます。これら3つの状態のいずれかのストリームは、SETTINGS_MAX_CONCURRENT_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).
エンドポイントは、ピアによって設定された制限を超えてはなりません（MUST NOT）。アドバタイズされた同時ストリーム制限を超える原因となるHEADERSフレームを受信するエンドポイントは、これをタイプPROTOCOL_ERRORまたはREFUSED_STREAMのストリームエラー（5.4.2節）として扱わなければなりません（MUST）。エラーコードの選択により、エンドポイントが自動再試行を有効にするかどうかが決まります（詳細については、セクション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.
SETTINGS_MAX_CONCURRENT_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は、WINDOW_UPDATEフレームを使用してフロー制御を提供します（セクション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. フロー制御は、WINDOW_UPDATEフレームに基づいています。レシーバーは、ストリーム上および接続全体で受信する準備ができているオクテットの数をアドバタイズします。これはクレジットベースのスキームです。
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. フロー制御は方向性があり、全体的な制御はレシーバーによって提供されます。レシーバーは、各ストリームおよび接続全体に必要なウィンドウサイズを設定することを選択できます（MAY）。送信者は、受信者によって課されたフロー制御制限を尊重しなければなりません（MUST）。クライアント、サーバー、および仲介者はすべて、独立してフロー制御ウィンドウをレシーバーとしてアドバタイズし、送信時にピアによって設定されたフロー制御制限に従います。
4. The initial value for the flow-control window is 65,535 octets for both new streams and the overall connection.
4. フロー制御ウィンドウの初期値は、新しいストリームと接続全体の両方で65,535オクテットです。
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. フレームタイプは、フロー制御をフレームに適用するかどうかを決定します。このドキュメントで指定されているフレームのうち、フロー制御の対象となるのはDATAフレームのみです。他のすべてのフレームタイプは、アドバタイズされたフロー制御ウィンドウのスペースを消費しません。これにより、重要な制御フレームがフロー制御によってブロックされないことが保証されます。
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は、WINDOW_UPDATEフレーム（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.
フロー制御は、リソースの制約下で動作しているエンドポイントを保護するために定義されています。たとえば、プロキシは多くの接続間でメモリを共有する必要があり、低速のアップストリーム接続と高速のダウンストリーム接続もある場合があります。フロー制御は、レシーバーが1つのストリームのデータを処理できないが、同じ接続で他のストリームの処理を続行したい場合に対処します。
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）のフロー制御ウィンドウをアドバタイズし、データを受信したときにWINDOW_UPDATEフレームを送信することでこのウィンドウを維持できます。これにより、そのレシーバーのフロー制御が事実上無効になります。逆に、送信側は常に、受信側によってアドバタイズされたフロー制御ウィンドウの影響を受けます。
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）に優先順位情報を含めることにより、新しいストリームに優先順位を割り当てることができます。それ以外の場合は、PRIORITYフレーム（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
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
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までの親ストリームのチェーン）が閉じているか、進行できない場合にのみ、リソースを割り当てる必要があります（SHOULD）。
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の整数の重みが割り当てられます。
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.
同じ親を持つストリームには、その重みに基づいて比例的にリソースを割り当てる必要があります（SHOULD）。したがって、ストリームBが重み4のストリームAに依存し、ストリームCが重み12のストリームAに依存し、ストリームAで進行できない場合、ストリームBは理想的にはストリームCに割り当てられたリソースの3分の1を受け取ります。
Stream priorities are changed using the PRIORITY frame. Setting a dependency causes a stream to become dependent on the identified parent stream.
ストリームの優先順位は、PRIORITYフレームを使用して変更されます。依存関係を設定すると、ストリームは識別された親ストリームに依存するようになります。
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.
ストリームが自身の依存関係の1つに依存するようにされる場合、以前に依存していたストリームは、最初に移動されて、優先順位を変更したストリームの以前の親に依存します。移動された依存関係はその重みを保持します。
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の代わりになります。優先順位付けが排他的である場合にAに依存するようになるFを除いて、同じです。
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は利用可能なリソースの半分ではなく、3分の1を受け取ります。
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.
これらの問題を回避するために、エンドポイントは、ストリームが閉じられた後の一定期間、ストリームの優先順位付け状態を保持する必要があります（SHOULD）。保持される時間が長いほど、ストリームに誤ったまたはデフォルトの優先度値が割り当てられる可能性が低くなります。
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.
SETTINGS_MAX_CONCURRENT_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.
エンドポイントが優先順位付けのために維持する追加の状態の量は、負荷に依存する可能性があります。高負荷の場合、優先順位付け状態を破棄して、リソースのコミットメントを制限できます。極端な場合、エンドポイントは、アクティブなストリームまたは予約されたストリームの優先順位付け状態を破棄することさえできます。制限が適用されている場合、エンドポイントは、SETTINGS_MAX_CONCURRENT_STREAMSの設定で許可されている数以上のストリームの状態を維持する必要があります（SHOULD）。実装はまた、優先ツリーでアクティブに使用されているストリームの状態を保持しようとします。
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.
それを行うのに十分な状態を保持している場合、閉じたストリームの優先度を変更するPRIORITYフレームを受信するエンドポイントは、それに依存するストリームの依存関係を変更する必要があります（SHOULD）。
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フレーミングは、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）を最初に送信する必要があります（SHOULD）。 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.
エンドポイントはいつでも接続を終了できます。特に、エンドポイントは、ストリームエラーを接続エラーとして処理することを選択できます（MAY）。エンドポイントは、接続を終了するときにGOAWAYフレームを送信する必要があります（SHOULD）。
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.
ストリームエラーを検出するエンドポイントは、エラーが発生したストリームのストリームIDを含むRST_STREAMフレーム（セクション6.4）を送信します。 RST_STREAMフレームには、エラーのタイプを示すエラーコードが含まれています。
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_STREAMは、エンドポイントがストリームで送信できる最後のフレームです。 RST_STREAMフレームを送信するピアは、リモートピアが送信するために送信またはエンキューしたフレームを受信できるように準備する必要があります。これらのフレームは、接続状態（ヘッダー圧縮（セクション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_STREAMフレームを送信してはなりません（SHOULD NOT）。ただし、エンドポイントは、ラウンドトリップ時間を超えて閉じられたストリームでフレームを受信した場合、追加のRST_STREAMフレームを送信できます（MAY）。この動作は、誤動作の実装を処理するために許可されています。
To avoid looping, an endpoint MUST NOT send a RST_STREAM in response to a RST_STREAM frame.
ループを回避するために、エンドポイントはRST_STREAMフレームに応答してRST_STREAMを送信してはなりません（MUST NOT）。
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）の中央にある拡張フレームは許可されません。これらは、PROTOCOL_ERRORタイプの接続エラー（セクション5.4.1）として扱われなければなりません（MUST）。
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.
既存のプロトコルコンポーネントのセマンティクスを変更する可能性がある拡張機能は、使用する前にネゴシエートする必要があります。たとえば、HEADERSフレームのレイアウトを変更する拡張機能は、ピアがこれを受け入れられるという肯定的なシグナルを提供するまで使用できません。この場合、変更されたレイアウトが有効になるタイミングを調整する必要がある場合もあります。 DATAフレーム以外のフレームをフロー制御として処理することは、セマンティクスの変更であり、ネゴシエーションを介してのみ実行できることに注意してください。
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 a setting is used for extension negotiation, the initial value MUST be defined in such a fashion that the extension is initially disabled.
このドキュメントでは、拡張機能の使用を交渉するための特定の方法を義務付けていませんが、その目的のために設定（6.5.2項）を使用できることに注意しています。両方のピアが拡張機能を使用する意思を示す値を設定した場合、拡張機能を使用できます。設定が拡張ネゴシエーションに使用される場合、初期値は拡張が最初に無効になるような方法で定義されなければなりません。
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.
DATAフレーム（type = 0x0）は、ストリームに関連付けられたオクテットの任意の可変長シーケンスを伝達します。たとえば、HTTP要求または応答のペイロードを運ぶために、1つ以上のDATAフレームが使用されます。
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.
DATAフレームにはパディングが含まれる場合があります。 DATAフレームにパディングを追加して、メッセージのサイズを隠すことができます。パディングはセキュリティ機能です。セクション10.7を参照してください。
+---------------+
|Pad Length? (8)|
+---------------+-----------------------------------------------+
| Data (*) ...
+---------------------------------------------------------------+
| Padding (*) ...
+---------------------------------------------------------------+
Figure 6: DATA Frame Payload
図6：DATAフレームのペイロード
The DATA frame contains the following fields:
DATAフレームには次のフィールドが含まれます。
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.
パッド長：オクテット単位のフレームパディングの長さを含む8ビットフィールド。このフィールドは条件付きで（図では「？」で示されています）、PADDEDフラグが設定されている場合にのみ存在します。
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.
パディング：アプリケーションのセマンティック値を含まないオクテットをパディングします。送信時には、パディングオクテットをゼロに設定する必要があります。レシーバーはパディングを検証する義務はありませんが、ゼロ以外のパディングをタイプPROTOCOL_ERRORの接続エラー（セクション5.4.1）として扱うことができます（MAY）。
The DATA frame defines the following flags:
DATAフレームは、次のフラグを定義します。
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は、パッド長フィールドとそれが説明するパディングが存在することを示します。
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.
DATAフレームはストリームに関連付けられている必要があります。ストリーム識別子フィールドが0x0のDATAフレームを受信した場合、受信者はタイプPROTOCOL_ERRORの接続エラー（セクション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.
DATAフレームはフロー制御の対象であり、ストリームが「オープン」または「ハーフクローズ（リモート）」状態にある場合にのみ送信できます。 DATAフレームペイロード全体がフロー制御に含まれ、存在する場合は、Pad LengthおよびPaddingフィールドが含まれます。ストリームが「オープン」または「ハーフクローズ（ローカル）」状態ではないDATAフレームを受信した場合、受信者は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.
パディングオクテットの総数は、Pad Lengthフィールドの値によって決まります。パディングの長さがフレームペイロードの長さ以上である場合、受信者はこれをタイプ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.
注：値がゼロのパッド長フィールドを含めることにより、フレームのサイズを1オクテット増やすことができます。
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）、さらにヘッダーブロックフラグメントを伝送します。 HEADERSフレームは、「アイドル」、「予約済み（ローカル）」、「オープン」、または「ハーフクローズ（リモート）」の状態のストリームで送信できます。
+---------------+
|Pad Length? (8)|
+-+-------------+-----------------------------------------------+
|E| Stream Dependency? (31) |
+-+-------------+-----------------------------------------------+
| Weight? (8) |
+-+-------------+-----------------------------------------------+
| Header Block Fragment (*) ...
+---------------------------------------------------------------+
| Padding (*) ...
+---------------------------------------------------------------+
Figure 7: HEADERS Frame Payload
図7：HEADERSフレームのペイロード
The HEADERS frame payload has the following fields:
HEADERSフレームのペイロードには次のフィールドがあります。
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.
パッド長：オクテット単位のフレームパディングの長さを含む8ビットフィールド。このフィールドは、PADDEDフラグが設定されている場合にのみ存在します。
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を参照）。このフィールドは、PRIORITYフラグが設定されている場合にのみ存在します。
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を参照）。このフィールドは、PRIORITYフラグが設定されている場合にのみ存在します。
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を加算して、1〜256の重みを取得します。このフィールドは、PRIORITYフラグが設定されている場合にのみ存在します。
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_STREAMフラグが含まれています。ただし、END_STREAMフラグが設定されたHEADERSフレームの後に、同じストリームのCONTINUATIONフレームを続けることができます。論理的には、CONTINUATIONフレームはHEADERSフレームの一部です。
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_HEADERS（0x4）：セットされている場合、ビット2は、このフレームにヘッダーブロック全体（セクション4.3）が含まれ、その後にCONTINUATIONフレームがないことを示します。
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フレームの後には、同じストリームのCONTINUATIONフレームが続く必要があります。受信者は、他のタイプのフレームまたは別のストリームのフレームの受信を、タイプPROTOCOL_ERRORの接続エラー（セクション5.4.1）として扱わなければなりません（MUST）。
PADDED (0x8): When set, bit 3 indicates that the Pad Length field and any padding that it describes are present.
PADDED（0x8）：設定されている場合、ビット3は、パッド長フィールドとそれが説明するパディングが存在することを示します。
PRIORITY (0x20): When set, bit 5 indicates that the Exclusive Flag (E), Stream Dependency, and Weight fields are present; see Section 5.3.
PRIORITY（0x20）：セットされている場合、ビット5は、Exclusive Flag（E）、Stream Dependency、およびWeightフィールドが存在することを示します。セクション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).
HEADERSフレームのペイロードには、ヘッダーブロックフラグメントが含まれます（セクション4.3）。 HEADERSフレームに収まらないヘッダーブロックは、CONTINUATIONフレームに続きます（セクション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.
HEADERSフレームはストリームに関連付けられている必要があります。ストリーム識別子フィールドが0x0であるHEADERSフレームを受信した場合、受信者はタイプPROTOCOL_ERRORの接続エラー（セクション5.4.1）で応答する必要があります。
The HEADERS frame changes the connection state as described in Section 4.3.
セクション4.3で説明するように、HEADERSフレームは接続状態を変更します。
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.
HEADERSフレームにはパディングを含めることができます。パディングフィールドとフラグは、DATAフレームに対して定義されたものと同じです（セクション6.1）。ヘッダーブロックフラグメントの残りのサイズを超えるパディングは、PROTOCOL_ERRORとして処理する必要があります。
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).
HEADERSフレームの優先順位付け情報は、別のPRIORITYフレームと論理的に同等ですが、HEADERSに含めることで、新しいストリームが作成されたときにストリームの優先順位付けでチャーンが発生する可能性を回避できます。ストリームの最初のフレームに続くHEADERSフレームの優先順位フィールドは、ストリームの優先順位を再設定します（セクション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.
PRIORITYフレーム（type = 0x2）は、ストリームの送信者が推奨する優先度を指定します（セクション5.3）。アイドルストリームや閉じたストリームを含む、任意のストリーム状態で送信できます。
+-+-------------------------------------------------------------+
|E| Stream Dependency (31) |
+-+-------------+-----------------------------------------------+
| Weight (8) |
+-+-------------+
Figure 8: PRIORITY Frame Payload
図8：PRIORITYフレームのペイロード
The payload of a PRIORITY frame contains the following fields:
PRIORITYフレームのペイロードには、次のフィールドが含まれます。
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を加算して、1〜256の重みを取得します。
The PRIORITY frame does not define any flags.
PRIORITYフレームはフラグを定義しません。
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.
PRIORITYフレームは常にストリームを識別します。 PRIORITYフレームが0x0のストリーム識別子で受信された場合、受信者は、PROTOCOL_ERRORタイプの接続エラー（セクション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.
PRIORITYフレームは、任意の状態のストリームで送信できますが、単一のヘッダーブロックを構成する連続するフレーム間では送信できません（セクション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.
PRIORITYフレームは、「アイドル」または「クローズ」状態のストリームに対して送信できます。これにより、未使用または閉じた親ストリームの優先順位を変更することにより、依存するストリームのグループの優先順位を変更できます。
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オクテット以外の長さのPRIORITYフレームは、タイプFRAME_SIZE_ERRORのストリームエラー（セクション5.4.2）として扱われなければなりません（MUST）。
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_STREAMフレーム（type = 0x3）は、ストリームの即時終了を可能にします。 RST_STREAMは、ストリームのキャンセルを要求するため、またはエラー状態が発生したことを示すために送信されます。
+---------------------------------------------------------------+
| Error Code (32) |
+---------------------------------------------------------------+
Figure 9: RST_STREAM Frame Payload
図9：RST_STREAMフレームのペイロード
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_STREAMフレームには、エラーコードを識別する1つの符号なし32ビット整数が含まれています（セクション7）。エラーコードは、ストリームが終了している理由を示します。
The RST_STREAM frame does not define any flags.
RST_STREAMフレームはフラグを定義しません。
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_STREAMフレームは、参照されたストリームを完全に終了させ、「クローズ」状態に入ります。ストリームでRST_STREAMを受信した後、受信者は、PRIORITYを除いて、そのストリームに追加のフレームを送信してはなりません（MUST NOT）。ただし、RST_STREAMを送信した後、送信側エンドポイントは、RST_STREAMの到着前にピアによって送信された可能性があるストリームで送信された追加のフレームを受信して処理する準備をしなければなりません（MUST）。
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_STREAMフレームは、ストリームに関連付けられている必要があります。 RST_STREAMフレームが0x0のストリーム識別子で受信された場合、受信者はこれをタイプPROTOCOL_ERRORの接続エラー（セクション5.4.1）として扱わなければなりません（MUST）。
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_STREAMフレームを送信してはなりません（MUST NOT）。アイドルストリームを識別するRST_STREAMフレームを受信した場合、受信者はこれをタイプPROTOCOL_ERRORの接続エラー（セクション5.4.1）として扱わなければなりません（MUST）。
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_STREAMフレームは、タイプFRAME_SIZE_ERRORの接続エラー（セクション5.4.1）として扱われなければなりません（MUST）。
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".
SETTINGSフレーム（type = 0x4）は、ピアの動作に関する設定や制約など、エンドポイントの通信方法に影響を与える構成パラメーターを伝達します。 SETTINGSフレームは、これらのパラメーターの受信を確認するためにも使用されます。個別に、SETTINGSパラメータは「設定」とも呼ばれます。
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.
SETTINGSパラメータはネゴシエートされません。受信ピアが使用する送信ピアの特性を記述します。同じパラメータの異なる値は、各ピアによってアドバタイズできます。たとえば、クライアントは高い初期フロー制御ウィンドウを設定し、サーバーはリソースを節約するために低い値を設定する場合があります。
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.
SETTINGSフレームは、接続の開始時に両方のエンドポイントによって送信されなければならず（MUST）、接続の存続期間中、いずれかのエンドポイントによっていつでも送信される場合があります。実装は、この仕様で定義されているすべてのパラメーターをサポートする必要があります。
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フレームの各パラメーターは、そのパラメーターの既存の値を置き換えます。パラメータは出現順に処理され、SETTINGSフレームの受信者は、そのパラメータの現在の値以外の状態を維持する必要はありません。したがって、SETTINGSパラメーターの値は、レシーバーによって認識される最後の値です。
SETTINGS parameters are acknowledged by the receiving peer. To enable this, the SETTINGS frame defines the following flag:
SETTINGSパラメータは、受信ピアによって確認されます。これを有効にするには、SETTINGSフレームで次のフラグを定義します。
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は、このフレームがピアのSETTINGSフレームの受信と適用を確認することを示します。このビットが設定されている場合、SETTINGSフレームのペイロードは空である必要があります。 ACKフラグが設定され、長さフィールド値が0以外のSETTINGSフレームを受信した場合は、タイプ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.
SETTINGSフレームは常に接続に適用され、単一のストリームには適用されません。 SETTINGSフレームのストリーム識別子はゼロ（0x0）でなければなりません。エンドポイントがストリーム識別子フィールドが0x0以外のSETTINGSフレームを受信した場合、エンドポイントは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.
SETTINGSフレームは、接続状態に影響します。不正な形式または不完全なSETTINGSフレームは、タイプPROTOCOL_ERRORの接続エラー（セクション5.4.1）として扱われなければなりません（MUST）。
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オクテットの倍数以外の長さのSETTINGSフレームは、タイプFRAME_SIZE_ERRORの接続エラー（セクション5.4.1）として扱われなければなりません（MUST）。
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.
SETTINGSフレームのペイロードは、0個以上のパラメータで構成され、それぞれが符号なし16ビット設定識別子と符号なし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.
SETTINGS_HEADER_TABLE_SIZE（0x1）：送信者がリモートエンドポイントに、ヘッダーブロックのデコードに使用されるヘッダー圧縮テーブルの最大サイズをオクテットで通知できるようにします。エンコーダーは、ヘッダーブロック内のヘッダー圧縮形式に固有のシグナリングを使用して、この値以下の任意のサイズを選択できます（[COMPRESSION]を参照）。初期値は4,096オクテットです。
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.
SETTINGS_ENABLE_PUSH（0x2）：この設定を使用して、サーバープッシュを無効にできます（セクション8.2）。エンドポイントは、値0に設定されたこのパラメーターを受信した場合、PUSH_PROMISEフレームを送信してはなりません（MUST NOT）。 1）タイプPROTOCOL_ERROR。
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以外の値は、タイプPROTOCOL_ERRORの接続エラー（セクション5.4.1）として扱わなければなりません（MUST）。
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.
SETTINGS_MAX_CONCURRENT_STREAMS（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 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_MAX_CONCURRENT_STREAMSの値0は、エンドポイントによって特別なものとして扱われるべきではありません（SHOULD NOT）。ゼロの値は、新しいストリームの作成を防ぎます。ただし、これは、アクティブなストリームで使い果たされた制限でも発生する可能性があります。サーバーは、短い期間にのみゼロ値を設定する必要があります（SHOULD）。サーバーが要求を受け入れたくない場合は、接続を閉じる方が適切です。
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.
SETTINGS_INITIAL_WINDOW_SIZE（0x4）：ストリームレベルのフロー制御の送信者の初期ウィンドウサイズ（オクテット単位）を示します。初期値は2 ^ 16-1（65,535）オクテットです。
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の最大フロー制御ウィンドウサイズを超える値は、FLOW_CONTROL_ERRORタイプの接続エラー（セクション5.4.1）として扱われなければなりません（MUST）。
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（16,384）オクテットです。エンドポイントによってアドバタイズされる値は、この初期値と最大許容フレームサイズ（2 ^ 24-1または16,777,215オクテット）の間でなければなりません（MUST）。この範囲外の値は、PROTOCOL_ERRORタイプの接続エラー（セクション5.4.1）として扱わなければなりません（MUST）。
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.
SETTINGS_MAX_HEADER_LIST_SIZE（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.
不明またはサポートされていない識別子を持つSETTINGSフレームを受信するエンドポイントは、その設定を無視する必要があります。
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.
SETTINGSのほとんどの値は、ピアが変更されたパラメータ値をいつ受信して適用したかを理解する必要があります。そのような同期タイムポイントを提供するために、ACKフラグが設定されていないSETTINGSフレームの受信者は、受信後できるだけ早く更新されたパラメータを適用する必要があります。
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.
SETTINGSフレーム内の値は、値の間に他のフレーム処理を行わずに、出現順に処理する必要があります。サポートされていないパラメーターは無視する必要があります。すべての値が処理されたら、受信者はACKフラグが設定されたSETTINGSフレームをすぐに送信する必要があります。 ACKフラグが設定されたSETTINGSフレームを受信すると、変更されたパラメータの送信者は、適用された設定に依存できます。
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.
SETTINGSフレームの送信者が妥当な時間内に確認応答を受信しない場合、タイプ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.
PUSH_PROMISEフレーム（type = 0x5）は、送信者が開始しようとしているストリームを事前にピアエンドポイントに通知するために使用されます。 PUSH_PROMISEフレームには、エンドポイントが作成する予定のストリームの符号なし31ビット識別子と、ストリームに追加のコンテキストを提供する一連のヘッダーが含まれています。セクション8.2には、PUSH_PROMISEフレームの使用に関する詳細な説明が含まれています。
+---------------+
|Pad Length? (8)|
+-+-------------+-----------------------------------------------+
|R| Promised Stream ID (31) |
+-+-----------------------------+-------------------------------+
| Header Block Fragment (*) ...
+---------------------------------------------------------------+
| Padding (*) ...
+---------------------------------------------------------------+
Figure 11: PUSH_PROMISE Payload Format
図11：PUSH_PROMISEペイロード形式
The PUSH_PROMISE frame payload has the following fields:
PUSH_PROMISEフレームのペイロードには、次のフィールドがあります。
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.
パッド長：オクテット単位のフレームパディングの長さを含む8ビットフィールド。このフィールドは、PADDEDフラグが設定されている場合にのみ存在します。
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：PUSH_PROMISEによって予約されているストリームを識別する符号なし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_HEADERS（0x4）：セットされている場合、ビット2は、このフレームにヘッダーブロック全体（セクション4.3）が含まれ、その後にCONTINUATIONフレームがないことを示します。
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フレームの後には、同じストリームのCONTINUATIONフレームが続く必要があります。受信者は、他のタイプのフレームまたは別のストリームのフレームの受信を、タイプPROTOCOL_ERRORの接続エラー（セクション5.4.1）として扱わなければなりません（MUST）。
PADDED (0x8): When set, bit 3 indicates that the Pad Length field and any padding that it describes are present.
PADDED（0x8）：設定されている場合、ビット3は、パッド長フィールドとそれが説明するパディングが存在することを示します。
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.
PUSH_PROMISEフレームは、「オープン」または「ハーフクローズ（リモート）」のいずれかの状態にあるピアによって開始されたストリームでのみ送信する必要があります。 PUSH_PROMISEフレームのストリーム識別子は、関連付けられているストリームを示します。ストリーム識別子フィールドに値0x0が指定されている場合、受信者はタイプPROTOCOL_ERRORの接続エラー（セクション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.
ピアエンドポイントのSETTINGS_ENABLE_PUSH設定が0に設定されている場合は、PUSH_PROMISEを送信してはなりません。この設定を設定し、確認応答を受け取ったエンドポイントは、PUSH_PROMISEフレームの受信をタイプ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.
PUSH_PROMISEフレームの受信者は、約束されたストリーム識別子を参照するRST_STREAMをPUSH_PROMISEの送信者に返すことにより、約束されたストリームを拒否することを選択できます。
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).
PUSH_PROMISEフレームは、2つの方法で接続状態を変更します。第1に、ヘッダーブロックを含めると（4.3節）、ヘッダー圧縮のために維持されている状態が変更される可能性があります。次に、PUSH_PROMISEは後で使用するためにストリームも予約し、約束されたストリームを「予約済み」状態にします。送信側は、そのストリームが「オープン」または「ハーフクローズ（リモート）」でない限り、PUSH_PROMISEをストリームに送信してはなりません（MUST NOT）。送信者は、約束されたストリームが新しいストリーム識別子（セクション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_PROMISEはストリームを予約するため、PUSH_PROMISEフレームを無視すると、ストリームの状態が不確定になります。受信者は、「オープン」でも「ハーフクローズ（ローカル）」でもないストリームでのPUSH_PROMISEの受信を、タイプPROTOCOL_ERRORの接続エラー（セクション5.4.1）として扱わなければなりません（MUST）。ただし、関連するストリームでRST_STREAMを送信したエンドポイントは、RST_STREAMフレームが受信および処理される前に作成された可能性のあるPUSH_PROMISEフレームを処理する必要があります。
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_PROMISEの受信を、タイプPROTOCOL_ERRORの接続エラー（セクション5.4.1）として扱わなければなりません（MUST）。不正なストリーム識別子は、現在「アイドル」状態にないストリームの識別子であることに注意してください。
The PUSH_PROMISE frame can include padding. Padding fields and flags are identical to those defined for DATA frames (Section 6.1).
PUSH_PROMISEフレームにはパディングを含めることができます。パディングフィールドとフラグは、DATAフレームに対して定義されたものと同じです（セクション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) |
| |
+---------------------------------------------------------------+
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フレームの受信者は、応答としてACKフラグが設定されたPINGフレームを、同じペイロードで送信する必要があります。 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フレームに応答してはなりません（MUST NOT）。
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）として扱われなければなりません（MUST）。
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フレーム（type = 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.
送信された後、ストリームに含まれている最後のストリーム識別子より高い識別子がある場合、送信者は受信者によって開始されたストリームで送信されたフレームを無視します。 GOAWAYフレームの受信者は、新しいストリーム用に新しい接続を確立できますが、接続で追加のストリームを開かないでください。
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フレームを送信する必要があります（SHOULD）。たとえば、サーバーが接続を閉じると同時に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.
GOAWAYフレームは、接続のクローズの直前にない場合があります。接続に使用されなくなったGOAWAYの受信者は、接続を終了する前にGOAWAYフレームを送信する必要があります（SHOULD）。
+-+-------------------------------------------------------------+
|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）として扱わなければなりません（MUST）。
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フレームを送信できます（MAY）。たとえば、正常なシャットダウン中にNO_ERRORを指定してGOAWAYを送信するエンドポイントは、その後、接続の即時終了を必要とする状態に遭遇する可能性があります。受信した最後のGOAWAYフレームからの最後のストリーム識別子は、どのストリームが影響を受けたかを示します。ピアはすでに別の接続で未処理の要求を再試行している可能性があるため、エンドポイントは最後のストリーム識別子で送信する値を増加してはなりません（MUST NOT）。
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を使用するクライアントにサービスを提供していない可能性がある仲介者に特に当てはまります。接続を正常にシャットダウンしようとしているサーバーは、最後のストリーム識別子が2 ^ 31-1に設定され、NO_ERRORコードが設定された初期GOAWAYフレームを送信する必要があります（SHOULD）。これは、シャットダウンが差し迫っており、それ以上の要求の開始が禁止されていることをクライアントに知らせます。処理中のストリームを作成するための時間（少なくとも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フレームを送信した後、送信者は、識別された最後のストリームよりも高い識別子を持つ受信者によって開始されたストリームのフレームを破棄できます。ただし、接続状態を変更するフレームを完全に無視することはできません。たとえば、HEADERS、PUSH_PROMISE、およびCONTINUATIONフレームは、ヘッダー圧縮のために維持される状態が一貫していることを保証するために最小限に処理する必要があります（セクション4.3を参照）。同様に、DATAフレームは、接続フロー制御ウィンドウに向けてカウントする必要があります。これらのフレームの処理に失敗すると、フロー制御またはヘッダー圧縮状態が非同期になる可能性があります。
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.
WINDOW_UPDATEフレーム（type = 0x8）は、フロー制御を実装するために使用されます。概要については、セクション5.2を参照してください。
Flow control operates at two levels: on each individual stream and on the entire connection.
フロー制御は2つのレベルで動作します。個々のストリームごとと接続全体です。
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.
どちらのタイプのフロー制御もホップバイホップです。つまり、2つのエンドポイント間のみです。仲介者は、依存する接続間でWINDOW_UPDATEフレームを転送しません。ただし、受信者によるデータ転送のスロットルにより、元の送信者へのフロー制御情報の伝播が間接的に発生する可能性があります。
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.
フロー制御は、フロー制御の対象として識別されたフレームにのみ適用されます。このドキュメントで定義されているフレームタイプのうち、これにはDATAフレームのみが含まれます。受信者がフレームを処理するためにリソースを割り当てることができない場合を除き、フロー制御から除外されたフレームは受け入れられ、処理されなければなりません（MUST）。受信側は、フレームを受け入れることができない場合、FLOW_CONTROL_ERRORタイプのストリームエラー（セクション5.4.2）または接続エラー（セクション5.4.1）で応答してもよい（MAY）。
+-+-------------------------------------------------------------+
|R| Window Size Increment (31) |
+-+-------------------------------------------------------------+
Figure 14: WINDOW_UPDATE Payload Format
図14：WINDOW_UPDATEペイロードの形式
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.
WINDOW_UPDATEフレームのペイロードは、予約済みの1ビットと、既存のフロー制御ウィンドウに加えて送信者が送信できるオクテットの数を示す符号なし31ビット整数です。フロー制御ウィンドウへの増分の有効な範囲は、1〜2 ^ 31-1（2,147,483,647）オクテットです。
The WINDOW_UPDATE frame does not define any flags.
WINDOW_UPDATEフレームはフラグを定義しません。
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.
WINDOW_UPDATEフレームは、ストリームまたは接続全体に固有にすることができます。前者の場合、フレームのストリーム識別子は影響を受けるストリームを示します。後者の場合、値「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のWINDOW_UPDATEフレームの受信を、PROTOCOL_ERRORタイプのストリームエラー（5.4.2節）として扱わなければなりません（MUST）。接続フロー制御ウィンドウのエラーは、接続エラーとして処理する必要があります（セクション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).
WINDOW_UPDATEは、END_STREAMフラグが付いたフレームを送信したピアから送信できます。これは、受信者が「ハーフクローズ（リモート）」または「クローズ」ストリームでWINDOW_UPDATEフレームを受信できることを意味します。受信者はこれをエラーとして扱わないでください（セクション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）、接続フロー制御ウィンドウに対するその寄与を常に考慮しなければなりません（MUST）。これは、フレームにエラーがある場合でも必要です。送信側はフレームをフロー制御ウィンドウに向かってカウントしますが、受信側がカウントしない場合、送信側と受信側のフロー制御ウィンドウが異なる可能性があります。
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オクテット以外の長さのWINDOW_UPDATEフレームは、タイプFRAME_SIZE_ERRORの接続エラー（セクション5.4.1）として扱われなければなりません（MUST）。
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.
ストリームフロー制御ウィンドウと接続フロー制御ウィンドウの2つのフロー制御ウィンドウを適用できます。送信者は、受信者によって通知されたいずれかのフロー制御ウィンドウで利用可能なスペースを超える長さのフロー制御フレームを送信してはいけません（MUST NOT）。 END_STREAMフラグが設定された長さがゼロのフレーム（つまり、空のDATAフレーム）は、どちらのフロー制御ウィンドウにも使用可能なスペースがない場合に送信される場合があります。
For flow-control calculations, the 9-octet frame header is not counted.
フロー制御計算では、9オクテットのフレームヘッダーはカウントされません。
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.
フレームの受信側は、データを消費し、フロー制御ウィンドウのスペースを解放するときに、WINDOW_UPDATEフレームを送信します。個別のWINDOW_UPDATEフレームが、ストリームレベルおよび接続レベルのフロー制御ウィンドウに送信されます。
A sender that receives a WINDOW_UPDATE frame updates the corresponding window by the amount specified in the frame.
WINDOW_UPDATEフレームを受信した送信側は、フレームで指定された量だけ対応するウィンドウを更新します。
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オクテットを超えることを許可してはなりません。送信者がWINDOW_UPDATEを受信したためにフロー制御ウィンドウがこの最大値を超えた場合、ストリームまたは接続を適切に終了する必要があります。ストリームの場合、送信者はFLOW_CONTROL_ERRORのエラーコードを含むRST_STREAMを送信します。接続の場合、エラーコードFLOW_CONTROL_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.
送信側からのフロー制御フレームと受信側からのWINDOW_UPDATEフレームは、互いに完全に非同期です。このプロパティにより、受信者は送信者が保持するウィンドウサイズを積極的に更新して、ストリームの停止を防ぐことができます。
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接続が最初に確立されると、65,535オクテットの初期フロー制御ウィンドウサイズで新しいストリームが作成されます。接続フロー制御ウィンドウも65,535オクテットです。両方のエンドポイントは、接続の序文の一部を形成するSETTINGSフレームにSETTINGS_INITIAL_WINDOW_SIZEの値を含めることにより、新しいストリームの初期ウィンドウサイズを調整できます。接続フロー制御ウィンドウは、WINDOW_UPDATEフレームを使用してのみ変更できます。
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.
SETTINGS_INITIAL_WINDOW_SIZEの値を設定するSETTINGSフレームを受信する前は、エンドポイントはフロー制御フレームを送信するときにデフォルトの初期ウィンドウサイズしか使用できません。同様に、WINDOW_UPDATEフレームが受信されるまで、接続フロー制御ウィンドウはデフォルトの初期ウィンドウサイズに設定されます。
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.
SETTINGSフレームは、まだアクティブになっていないストリームのフロー制御ウィンドウを変更するだけでなく、アクティブなフロー制御ウィンドウを持つストリーム（つまり、「オープン」または「ハーフ」のストリーム）の初期フロー制御ウィンドウサイズを変更できます。 -closed（remote） "状態）。 SETTINGS_INITIAL_WINDOW_SIZEの値が変更された場合、レシーバーは、新しい値と古い値の差によって維持するすべてのストリームフロー制御ウィンドウのサイズを調整する必要があります。
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.
SETTINGS_INITIAL_WINDOW_SIZEを変更すると、フロー制御ウィンドウの使用可能なスペースがマイナスになる可能性があります。送信者は、負のフロー制御ウィンドウを追跡しなければならず、フロー制御ウィンドウを正にするWINDOW_UPDATEフレームを受信するまで、新しいフロー制御フレームを送信してはなりません（MUST NOT）。
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 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.
たとえば、クライアントが接続の確立時にすぐに60 KBを送信し、サーバーが初期ウィンドウサイズを16 KBに設定した場合、クライアントは、SETTINGSフレームの受信時に使用可能なフロー制御ウィンドウを-44 KBに再計算します。 WINDOW_UPDATEフレームがウィンドウを正に戻すまで、クライアントは負のフロー制御ウィンドウを保持します。その後、クライアントは送信を再開できます。
A SETTINGS frame cannot alter the connection flow-control window.
SETTINGSフレームは、接続フロー制御ウィンドウを変更できません。
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.
エンドポイントは、フロー制御ウィンドウが最大サイズを超えるSETTINGS_INITIAL_WINDOW_SIZEへの変更を、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.
現在のサイズよりも小さいフロー制御ウィンドウを使用したい受信者は、新しいSETTINGSフレームを送信できます。ただし、送信者はSETTINGSフレームを処理する前に下限を超えるデータを送信する可能性があるため、受信者はこのウィンドウサイズを超えるデータを受信できるように準備する必要があります。
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.
初期のフロー制御ウィンドウサイズを縮小するSETTINGSフレームを送信した後、受信者はフロー制御制限を超えるストリームを処理し続けることができます（MAY）。ストリームの継続を許可しても、受信者がフロー制御ウィンドウ用に予約するスペースをすぐに減らすことはできません。送信者が送信を再開できるようにするにはWINDOW_UPDATEフレームが必要なため、これらのストリームの進行も停止する可能性があります。代わりに、受信者は影響を受けるストリームに対してFLOW_CONTROL_ERRORのエラーコードを含むRST_STREAMを送信する場合があります。
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.
CONTINUATIONフレーム（type = 0x9）は、ヘッダーブロックフラグメントのシーケンスを継続するために使用されます（セクション4.3）。前のフレームが同じストリーム上にあり、END_HEADERSフラグが設定されていないHEADERS、PUSH_PROMISE、またはCONTINUATIONフレームである限り、任意の数のCONTINUATIONフレームを送信できます。
+---------------------------------------------------------------+
| Header Block Fragment (*) ...
+---------------------------------------------------------------+
Figure 15: CONTINUATION Frame Payload
図15：継続フレームペイロード
The CONTINUATION frame payload contains a header block fragment (Section 4.3).
CONTINUATIONフレームペイロードには、ヘッダーブロックフラグメントが含まれています（セクション4.3）。
The CONTINUATION frame defines the following flag:
CONTINUATIONフレームは、次のフラグを定義します。
END_HEADERS (0x4): When set, bit 2 indicates that this frame ends a header block (Section 4.3).
END_HEADERS（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ビットが設定されていない場合、このフレームの後に別のCONTINUATIONフレームが続く必要があります。受信者は、他のタイプのフレームまたは別のストリームのフレームの受信を、タイプPROTOCOL_ERRORの接続エラー（セクション5.4.1）として扱わなければなりません（MUST）。
The CONTINUATION frame changes the connection state as defined in Section 4.3.
CONTINUATIONフレームは、セクション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.
CONTINUATIONフレームはストリームに関連付けられている必要があります。ストリーム識別子フィールドが0x0であるCONTINUATIONフレームを受信した場合、受信者はタイプPROTOCOL_ERRORの接続エラー（セクション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.
CONTINUATIONフレームの前には、END_HEADERSフラグが設定されていないHEADERS、PUSH_PROMISE、またはCONTINUATIONフレームを配置する必要があります。このルールの違反を監視する受信者は、PROTOCOL_ERRORタイプの接続エラー（セクション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_STREAMおよび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.
NO_ERROR（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.
PROTOCOL_ERROR（0x1）：エンドポイントが不特定のプロトコルエラーを検出しました。このエラーは、より具体的なエラーコードが利用できない場合に使用されます。
INTERNAL_ERROR (0x2): The endpoint encountered an unexpected internal error.
INTERNAL_ERROR（0x2）：エンドポイントで予期しない内部エラーが発生しました。
FLOW_CONTROL_ERROR (0x3): The endpoint detected that its peer violated the flow-control protocol.
FLOW_CONTROL_ERROR（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").
SETTINGS_TIMEOUT（0x4）：エンドポイントはSETTINGSフレームを送信しましたが、タイムリーに応答を受信しませんでした。セクション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.
FRAME_SIZE_ERROR（0x6）：エンドポイントが無効なサイズのフレームを受信しました。
REFUSED_STREAM (0x7): The endpoint refused the stream prior to performing any application processing (see Section 8.1.4 for details).
REFUSED_STREAM（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.
COMPRESSION_ERROR（0x9）：エンドポイントは、接続のヘッダー圧縮コンテキストを維持できません。
CONNECT_ERROR (0xa): The connection established in response to a CONNECT request (Section 8.3) was reset or abnormally closed.
CONNECT_ERROR（0xa）：CONNECTリクエスト（セクション8.3）への応答として確立された接続がリセットされたか、異常終了しました。
ENHANCE_YOUR_CALM (0xb): The endpoint detected that its peer is exhibiting a behavior that might be generating excessive load.
ENHANCE_YOUR_CALM（0xb）：エンドポイントは、ピアが過度の負荷を生成している可能性がある動作を示していることを検出しました。
INADEQUATE_SECURITY (0xc): The underlying transport has properties that do not meet minimum security requirements (see Section 9.2).
INADEQUATE_SECURITY（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 / 2ではなくHTTP / 1.1を使用する必要があります。
Unknown or unsupported error codes MUST NOT trigger any special behavior. These MAY be treated by an implementation as being equivalent to INTERNAL_ERROR.
不明またはサポートされていないエラーコードは、特別な動作を引き起こしてはなりません。これらは、実装によって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 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.
したがって、HTTP / 1.1セマンティクスとコンテンツ[RFC7231]、条件付き要求[RFC7232]、範囲要求[RFC7233]、キャッシング[RFC7234]、および認証[RFC7235]の仕様と要件は、HTTP / 2に適用できます。 HTTPおよびHTTPS URIスキームなどのHTTP / 1.1メッセージ構文およびルーティング[RFC7230]の選択された部分は、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応答のメッセージヘッダーを含む0個以上のHEADERSフレーム（その後に0個以上のCONTINUATIONフレームが続く）（[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. メッセージヘッダーを含む1つのHEADERSフレーム（その後に0個以上のCONTINUATIONフレーム）（[RFC7230]、セクション3.2を参照）、
3. zero or more DATA frames containing the payload body (see [RFC7230], Section 3.3), and
3. ペイロード本体を含む0個以上のDATAフレーム（[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. 必要に応じて、1つのHEADERSフレームと、それに続くトレーラパーツを含む0個以上のCONTINUATIONフレーム（存在する場合）（[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_STREAMフラグが付いています。END_STREAMフラグが付いたHEADERSフレームの後には、ヘッダーブロックの残りの部分を運ぶCONTINUATIONフレームが続く場合があることに注意してください。
Other frames (from any stream) MUST NOT occur between the HEADERS frame and any CONTINUATION frames that might follow.
（任意のストリームからの）他のフレームは、HEADERSフレームとその後に続くCONTINUATIONフレームの間で発生してはなりません（MUST NOT）。
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はDATAフレームを使用してメッセージペイロードを伝送します。 [RFC7230]のセクション4.1で定義された「チャンク」転送エンコーディングは、HTTP / 2では使用してはなりません（MUST NOT）。
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.
後続のヘッダーフィールドは、ストリームを終了するヘッダーブロックで運ばれます。このようなヘッダーブロックは、HEADERSフレームで始まり、その後に0個以上のCONTINUATIONフレームが続くシーケンスで、HEADERSフレームにはEND_STREAMフラグが付いています。ストリームを終了しない最初のヘッダーブロックは、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).
HEADERSフレーム（および関連するCONTINUATIONフレーム）は、ストリームの最初または最後にのみ表示できます。最終的な（非情報）ステータスコードを受信した後、END_STREAMフラグが設定されていないHEADERSフレームを受信するエンドポイントは、対応する要求または応答を不正な形式として処理しなければなりません（セクション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_STREAMが付いたフレームで終了します。これにより、ストリームがクライアントでは「ハーフクローズ（ローカル）」になり、サーバーでは「ハーフクローズ（リモート）」になります。応答はHEADERSフレームで始まり、END_STREAMが付いたフレームで終わります。これにより、ストリームが「クローズ」状態になります。
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.
サーバーがEND_STREAMフラグが設定されたフレーム（ヘッダーブロックを完了するために必要なCONTINUATIONフレームを含む）を送信（またはクライアントが受信）すると、HTTP応答が完了します。応答が送受信されていない要求のどの部分にも依存しない場合、サーバーはクライアントが要求全体を送信する前に完全な応答を送信できます。これがtrueの場合、サーバーは、完全な応答（つまり、END_STREAMフラグが付いたフレーム）を送信した後、エラーコードNO_ERRORのRST_STREAMを送信することにより、クライアントがエラーなしで要求の送信を中止するように要求できます（MAY）。クライアントは、そのようなRST_STREAMを受け取った結果として応答を破棄してはなりません（MUST）が、クライアントは他の理由でいつでも自分の判断で応答を破棄できます。
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/message-headers>で管理されている「メッセージヘッダーフィールド」レジストリを参照してください。
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ヘッダーフィールドではありません。エンドポイントは、このドキュメントで定義されているもの以外の疑似ヘッダーフィールドを生成してはなりません（MUST NOT）。
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メッセージを生成してはなりません（MUST NOT）。接続固有のヘッダーフィールドを含むメッセージは、不正な形式として扱われる必要があります（セクション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に変換する中間者は、Connectionヘッダーフィールドによって指定されたヘッダーフィールドを、Connectionヘッダーフィールド自体とともに削除する必要があります。このような仲介者は、接続ヘッダーフィールドで指定されていない場合でも、Keep-Alive、Proxy-Connection、Transfer-Encoding、Upgradeなどの他の接続固有のヘッダーフィールドも削除する必要があります（SHOULD）。
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のスキーム部分が含まれます（[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」サブコンポーネントを含めてはなりません（MUST NOT）。
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リクエストを直接生成するクライアントは、Hostヘッダーフィールドの代わりに "：authority"疑似ヘッダーフィールドを使用する必要があります（SHOULD）。 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のパス部分とクエリ部分（ "path-absolute"プロダクション、オプションで「？」文字の後に "query"プロダクションが続く）が含まれます（[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のOPTIONSリクエストです。これらには、値が「*」の「：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).
CONNECTリクエストでない限り、すべてのHTTP / 2リクエストには、「：method」、「：scheme」、および「：path」疑似ヘッダーフィールドの有効な値を1つだけ含める必要があります（セクション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応答の場合、HTTPステータスコードフィールドを持つ[：status]疑似ヘッダーフィールドが1つ定義されます（[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ペア（または "クラム"）を区切ります。このヘッダーフィールドは、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ヘッダーフィールドは、それぞれが1つ以上のCookieペアを持つ個別のヘッダーフィールドに分割される場合があります。解凍後に複数のCookieヘッダーフィールドがある場合、これらを非HTTP / 2コンテキストなどに渡す前に、0x3B、0x20（ASCII文字列 ";"）の2オクテット区切り文字を使用して1つのオクテット文字列に連結する必要があります。 HTTP / 1.1接続、または一般的なHTTPサーバーアプリケーションとして。
Therefore, the following two lists of Cookie header fields are semantically equivalent.
したがって、次の2つのCookieヘッダーフィールドのリストは、意味的に同等です。
cookie: a=b; c=d; 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.
ペイロード本体を含む要求または応答には、content-lengthヘッダーフィールドを含めることができます。 content-lengthヘッダーフィールドの値が、本文を形成するDATAフレームのペイロード長の合計と等しくない場合も、要求または応答の形式が正しくありません。 [RFC7230]のセクション3.3.2で説明されているように、ペイロードがないと定義されている応答は、DATAフレームにコンテンツが含まれていなくても、ゼロ以外のcontent-lengthヘッダーフィールドを持つ可能性があります。
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リクエストまたはレスポンスを処理する仲介者（つまり、トンネルとして機能していない仲介者）は、不正なリクエストまたはレスポンスを転送してはなりません（MUST NOT）。検出された不正な要求または応答は、PROTOCOL_ERRORタイプのストリームエラー（5.4.2節）として扱われなければなりません（MUST）。
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フレームとして送信され、その後にリクエストヘッダーフィールドのシリアル化されたブロックを含む0個以上のCONTINUATIONフレームが送信されます。次のHEADERSフレームには、END_HEADERSフラグとEND_STREAMフラグの両方が設定されています。 CONTINUATIONフレームは送信されません。
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.
同様に、応答ヘッダーフィールドのみを含む応答は、応答ヘッダーフィールドのシリアル化されたブロックを含むHEADERSフレームとして送信されます（これにも0個以上のCONTINUATIONフレームが続きます）。
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 Not Modified HEADERS ETag： "xyzzy" ==> + END_STREAM Expires：Thu、23 Jan ... + END_HEADERS：status = 304 etag = "xyzzy" expires = Thu、23 Jan ...
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リクエストは、1つのHEADERSフレームとして送信され、その後にリクエストヘッダーフィールドを含む0個以上のCONTINUATIONフレームが続き、最後に1つ以上のDATAフレームが続き、最後のCONTINUATION（またはHEADERS）フレームにはEND_HEADERSフラグが設定され、END_STREAMフラグが設定された最後のDATAフレーム：
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}
DATA + END_STREAM {バイナリデータ}
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:
ヘッダーフィールドとペイロードデータを含む応答は、HEADERSフレームとして送信され、その後に0個以上のCONTINUATIONフレーム、1つ以上のDATAフレームが続き、END_STREAMフラグが設定されたシーケンスの最後のDATAフレームが続きます。
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}
DATA + END_STREAM {バイナリデータ}
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ステータスコードを使用した情報応答は、HEADERSフレームとして送信され、その後に0個以上のCONTINUATIONフレームが続きます。
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.
後続のヘッダーフィールドは、要求または応答ヘッダーブロックとすべてのDATAフレームの両方が送信された後にヘッダーブロックとして送信されます。トレーラーヘッダーブロックを開始するHEADERSフレームには、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:
次の例には、Expectヘッダーフィールドに「100-continue」トークンを含むリクエストに応答して送信される100（Continue）ステータスコードと、後続のヘッダーフィールドの両方が含まれています。
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}
HEADERS + END_STREAM + END_HEADERS foo = bar
ヘッダー+ END_STREAM + END_HEADERS 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は、リクエストが処理されていないことをクライアントに保証するための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 REFUSED_STREAMエラーコードをRST_STREAMフレームに含めて、処理が行われる前にストリームが閉じられていることを示すことができます。リセットストリームで送信された要求はすべて安全に再試行できます。
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.
サーバーは、その事実を保証できない限り、ストリームが処理されなかったことを示してはなりません（MUST NOT）。ストリーム上のフレームが任意のストリームのアプリケーション層に渡される場合、そのストリームにはREFUSED_STREAMを使用してはならず、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.
クライアントはサーバープッシュを無効にするよう要求できますが、これはホップごとに個別にネゴシエートされます。 SETTINGS_ENABLE_PUSH設定を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を参照）、リクエストボディを含めてはなりません（MUST NOT）。キャッシュ可能ではない、安全であることがわかっていない、またはリクエスト本文の存在を示す約束されたリクエストを受け取るクライアントは、タイプ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.
キャッシュ可能なプッシュされた応答（[RFC7234]、セクション3を参照）は、HTTPキャッシュを実装している場合、クライアントによって保存できます。プッシュされた応答は、オリジンサーバーで正常に検証されたと見なされます（たとえば、「no-cache」キャッシュ応答ディレクティブが存在する場合（[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を参照）。クライアントは、サーバーが信頼できないPUSH_PROMISEをPROTOCOL_ERRORタイプのストリームエラー（5.4.2節）として扱わなければなりません（MUST）。
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_PROMISEフレームの受信をPROTOCOL_ERRORタイプの接続エラー（セクション5.4.1）として処理する必要があります。クライアントは、メッセージをタイプPROTOCOL_ERRORの接続エラー（セクション5.4.1）として扱うことにより、SETTINGS_ENABLE_PUSH設定を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.
サーバープッシュは、意味的には、サーバーが要求に応答することと同じです。ただし、この場合、その要求はPUSH_PROMISEフレームとしてサーバーからも送信されます。
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).
プッシュされた応答は、常にクライアントからの明示的な要求に関連付けられています。サーバーによって送信されたPUSH_PROMISEフレームは、その明示的な要求のストリームで送信されます。 PUSH_PROMISEフレームには、サーバーで利用可能なストリーム識別子から選択された、約束されたストリーム識別子も含まれます（セクション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および後続のCONTINUATIONフレームのヘッダーフィールドは、リクエストヘッダーフィールドの有効かつ完全なセットでなければなりません（セクション8.1.2.3）。サーバーは、安全でキャッシュ可能な「：method」疑似ヘッダーフィールドにメソッドを含める必要があります。クライアントがヘッダーフィールドの完全かつ有効なセットを含まないPUSH_PROMISEを受信した場合、または "：method"疑似ヘッダーフィールドが安全でないメソッドを識別した場合、クライアントは次のストリームエラー（セクション5.4.2）で応答する必要があります。タイプPROTOCOL_ERROR。
The server SHOULD send PUSH_PROMISE (Section 6.6) frames prior to sending any frames that reference the promised responses. This avoids a race where clients issue requests prior to receiving any PUSH_PROMISE frames.
サーバーは、約束された応答を参照するフレームを送信する前にPUSH_PROMISE（セクション6.6）フレームを送信する必要があります（SHOULD）。これにより、クライアントがPUSH_PROMISEフレームを受信する前にリクエストを発行する競合を回避できます。
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.
たとえば、サーバーが複数の画像ファイルへの埋め込みリンクを含むドキュメントのリクエストを受信し、サーバーがそれらの追加画像をクライアントにプッシュすることを選択した場合、画像リンクを含むDATAフレームの前にPUSH_PROMISEフレームを送信すると、クライアントは確実に埋め込まれたリンクを発見する前にリソースがプッシュされることを確認します。同様に、サーバーがヘッダーブロックによって参照される応答をプッシュする場合（リンクヘッダーフィールドなど）、ヘッダーブロックを送信する前にPUSH_PROMISEを送信すると、クライアントがこれらのリソースを要求しないようになります。
PUSH_PROMISE frames MUST NOT be sent by the client.
PUSH_PROMISEフレームはクライアントによって送信されてはいけません（MUST NOT）。
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フレームは、クライアントが開始したストリームに応答してサーバーから送信できますが、ストリームはサーバーに対して「オープン」または「ハーフクローズ（リモート）」の状態でなければなりません。 PUSH_PROMISEフレームには、応答を構成するフレームが散在していますが、単一のヘッダーブロックを構成するHEADERSおよびCONTINUATIONフレームを散在させることはできません。
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_PROMISEフレームを送信した後、サーバーは、プッシュされた応答を、約束されたストリーム識別子を使用するサーバー起動ストリームの応答（8.1.2.4項）として配信し始めることができます。サーバーは、このストリームを使用して、セクション8.1で定義されているのと同じフレームのシーケンスを使用して、HTTP応答を送信します。このストリームは、最初のHEADERSフレームが送信された後、クライアントに対して「ハーフクローズ」されます（セクション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.
クライアントがPUSH_PROMISEフレームを受信し、プッシュされた応答を受け入れることを選択すると、クライアントは、約束されたストリームが閉じるまで、約束された応答の要求を発行してはなりません（SHOULD NOT）。
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.
クライアントが何らかの理由でサーバーからプッシュされた応答を受信したくないと判断した場合、またはサーバーが約束された応答の送信を開始するのに時間がかかりすぎる場合、クライアントはCANCELまたはREFUSED_STREAMを使用してRST_STREAMフレームを送信できます。コードとプッシュされたストリームの識別子の参照。
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.
クライアントは、SETTINGS_MAX_CONCURRENT_STREAMS設定を使用して、サーバーが同時にプッシュできる応答の数を制限できます。 SETTINGS_MAX_CONCURRENT_STREAMSの値を0にアドバタイズすると、サーバーが必要なストリームを作成できないようになり、サーバープッシュが無効になります。これは、サーバーがPUSH_PROMISEフレームを送信することを禁止しません。クライアントは、不要な約束されたストリームをリセットする必要があります。
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ストリームの応答は、HEADERSフレームで始まります。このフレームは、ストリームをサーバーの場合は「ハーフクローズ（リモート）」状態に、クライアントの場合は「ハーフクローズ（ローカル）」状態にして、フレームで終了します。ストリームを「クローズ」状態にするEND_STREAMを保持します。
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プロキシで使用され、「https」リソースと対話する目的で、オリジンサーバーとのTLSセッションを確立します。
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"疑似ヘッダーフィールドには、接続するホストとポートが含まれます（CONNECTリクエストのリクエストターゲットの権限フォームと同じです（[RFC7230]、セクション5.3を参照））。
A CONNECT request that does not conform to these restrictions is malformed (Section 8.1.2.6).
これらの制限に準拠していないCONNECTリクエストは、形式が正しくありません（セクション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]を確立します。この接続が正常に確立されると、[RFC7231]のセクション4.3.6で定義されているように、プロキシは2xxシリーズのステータスコードを含むHEADERSフレームをクライアントに送信します。
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.
各ピアによって送信された最初のHEADERSフレームの後、後続のすべてのDATAフレームは、TCP接続で送信されたデータに対応します。クライアントによって送信されたDATAフレームのペイロードは、プロキシによってTCPサーバーに送信されます。 TCPサーバーから受信したデータは、プロキシーによってDATAフレームに組み立てられます。 DATAまたはストリーム管理フレーム（RST_STREAM、WINDOW_UPDATE、およびPRIORITY）以外のフレームタイプは、接続されたストリームで送信してはならず（MUST）、受信した場合はストリームエラー（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接続はどちらのピアでも閉じることができます。 DATAフレームのEND_STREAMフラグは、TCP FINビットと同等として扱われます。クライアントは、END_STREAMフラグが付いたフレームを受信した後、END_STREAMフラグが設定されたDATAフレームを送信することが期待されています。 END_STREAMフラグが設定されたDATAフレームを受信するプロキシは、最後のTCPセグメントでFINビットが設定された添付データを送信します。 FINビットが設定されたTCPセグメントを受信するプロキシは、END_STREAMフラグが設定されたDATAフレームを送信します。最後のTCPセグメントまたはDATAフレームが空である可能性があることに注意してください。
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_STREAMで通知されます。プロキシは、RSTビットが設定されたTCPセグメントの受信を含む、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接続は永続的です。最高のパフォーマンスを得るには、サーバーとの通信が不要であると判断されるまで（たとえば、ユーザーが特定のWebページから移動したときなど）、またはサーバーが接続を閉じるまで、クライアントは接続を閉じないことが予想されます。
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.
クライアントは、ホストがURI、選択された代替サービス[ALT-SVC]、または構成されたプロキシから派生している、特定のホストとポートのペアへの複数のHTTP / 2接続を開かないでください。
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]値を使用するか、異なるTLSクライアント証明書を提供するために、同じIPアドレスとTCPポートへの複数の接続を開くことができますが、同じ構成で複数の接続を作成しないでください。
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）フレームを送信して（SHOULD）、両方のエンドポイントが以前に送信されたフレームが処理されているかどうかを確実に判断し、必要な残りのタスクを正常に完了するか終了することができるようにします。
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」属性またはワイルドカード付きの名前を持つ証明書を提供する場合があります。そのうちの1つは、URI内の機関に有効です。たとえば、「subjectAltName」が「* .example.com」である証明書では、「https://a.example.com/」と「https：//」で始まるURIへのリクエストに同じ接続を使用できる場合があります。 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（Misdirected Request）ステータスコードを送信することにより、リクエストに対して権限がないことを示すことができます（セクション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（Misdirected Request）ステータスコードは、要求が応答を生成できないサーバーに送信されたことを示します。これは、要求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（Misdirected Request）応答を受信するクライアントは、異なる接続を介して、要求を再試行してもよい（要求メソッドがべき等であるかどうかにかかわらず）。これは、接続が再利用されている場合（セクション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.
HTTP / 2の実装では、HTTP / 2 over TLSに対してTLSバージョン1.2 [TLS12]以降を使用する必要があります。 [TLSBCP]の一般的なTLS使用ガイダンスに従う必要があります（SHOULD）。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接続を、タイプINADEQUATE_SECURITYの接続エラー（セクション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.
HTTP / 2 over TLS 1.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
HTTP / 2 over TLS 1.2の展開では、再ネゴシエーションを無効にする必要があります。エンドポイントは、TLS再ネゴシエーションをタイプPROTOCOL_ERRORの接続エラー（セクション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.
エンドポイントは再ネゴシエーションを使用して、ハンドシェイクで提供されるクライアント資格情報の機密保護を提供できますが、再ネゴシエーションはすべて、接続序文を送信する前に発生する必要があります。サーバーは、接続を確立した直後に再ネゴシエーション要求を確認した場合、クライアント証明書を要求する必要があります（SHOULD）。
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_REQUIREDタイプのエラー（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サイズを受け入れる必要があります。エンドポイントは、下限より小さい鍵サイズのネゴシエーションをタイプINADEQUATE_SECURITYの接続エラー（セクション5.4.1）として扱うことができます（MAY）。
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).
HTTP / 2 over TLS 1.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.
エンドポイントは、ブラックリストの暗号スイートの1つがネゴシエートされた場合、タイプINADEQUATE_SECURITYの接続エラー（セクション5.4.1）を生成することを選択できます（MAY）。潜在的なピアのセットがその暗号スイートを受け入れることがわかっている場合を除き、ブラックリストの暗号スイートの使用を選択したデプロイメントは、接続エラーをトリガーするリスクがあります。
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.
実装は、ブラックリストにない暗号スイートのネゴシエーションに反応してこのエラーを生成してはなりません（MUST NOT）。その結果、クライアントがブラックリストにない暗号スイートを提供する場合、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のデプロイメントは、P-256楕円曲線[FIPS186]でTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE]をサポートする必要があります。
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」スキームの認証済みサーバーIDに依存しています（[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.
クロスプロトコル攻撃では、攻撃者はクライアントに、あるプロトコルで、別のプロトコルを理解するサーバーへのトランザクションを開始させます。攻撃者は、トランザクションを2番目のプロトコルで有効なトランザクションとして表示させる可能性があります。これは、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サーバーを混乱させるように設計された文字列が含まれていますが、他のプロトコルに対する特別な保護は提供されていません。クライアント接続の序文に加えて、Upgradeヘッダーフィールドを含む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で使用されるインターネットメッセージ構文の有効なフィールド名ではない名前を表現できます。無効なヘッダーフィールド名を含む要求または応答は、不正な形式として扱われなければなりません（セクション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の「field-content」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.
プッシュされた応答のキャッシュは、オリジンサーバーによって提供されたCache-Controlヘッダーフィールドのガイダンスに基づいて可能です。ただし、単一のサーバーが複数のテナントをホストしている場合、これにより問題が発生する可能性があります。たとえば、サーバーは複数のユーザーにそれぞれの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を参照）は、使用またはキャッシュしてはなりません（MUST NOT）。
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.
PUSH_PROMISEフレームの数は、同じ方法で制約されません。サーバープッシュを受け入れるクライアントは、「予約済み（リモート）」状態になることを許可するストリームの数を制限する必要があります（SHOULD）。過剰な数のサーバープッシュストリームは、ENHANCE_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.
SETTINGSフレームを悪用して、ピアに追加の処理時間を費やす可能性があります。これは、SETTINGSパラメータを無意味に変更したり、複数の未定義パラメータを設定したり、同じフレームで同じ設定を複数回変更したりすることによって行われる場合があります。 WINDOW_UPDATEまたはPRIORITYフレームは、リソースの不要な浪費を引き起こすために悪用される可能性があります。
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.
多数の小さなフレームまたは空のフレームが悪用されて、ピアがフレームヘッダーの処理に時間を費やす可能性があります。ただし、ストリームの最後に空のDATAまたはCONTINUATIONフレームを送信するなど、一部の用途は完全に正当であることに注意してください。
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.
SETTINGSパラメータの制限を瞬時に減らすことはできません。これにより、新しい制限を超える可能性のあるピアからの動作にエンドポイントがさらされることになります。特に、接続を確立した直後は、サーバーによって設定された制限はクライアントには知られていないため、明らかなプロトコル違反になることなく超えることができます。
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.
この動作を監視しないエンドポイントは、サービス拒否攻撃のリスクにさらされます。実装は、これらの機能の使用を追跡し、それらの使用に制限を設定する必要があります。エンドポイントは、疑わしいアクティビティをタイプENHANCE_YOUR_CALMの接続エラー（セクション5.4.1）として扱うことができます（MAY）。
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 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.
大きなヘッダーブロック（セクション4.3）では、実装が大量の状態をコミットする可能性があります。ルーティングに重要なヘッダーフィールドは、ヘッダーブロックの終わり近くに表示される可能性があり、最終的な宛先へのヘッダーフィールドのストリーミングを妨げます。この順序付けと、キャッシュの正確さを保証するなどの他の理由により、エンドポイントはヘッダーブロック全体をバッファリングする必要がある場合があります。ヘッダーブロックのサイズにはハードリミットがないため、一部のエンドポイントは、ヘッダーフィールドに使用可能な大量のメモリを強制的にコミットする可能性があります。
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.
エンドポイントは、SETTINGS_MAX_HEADER_LIST_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接続はTIME_WAIT状態のままであるため、プロキシーは、CONNECT要求を運ぶストリームのクローズを超えて、TCP接続の一部のリソースを維持することもあります。したがって、プロキシーは、SETTINGS_MAX_CONCURRENT_STREAMSだけに依存して、CONNECT要求によって消費されるリソースを制限することはできません。
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の特性を悪用する圧縮に対する実証可能な攻撃があります（[BREACH]など）。攻撃者は、さまざまな平文を含む複数のリクエストを誘導し、それぞれの結果の暗号文の長さを観察します。これにより、シークレットについての推測が正しい場合、長さが短くなります。
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).
安全なチャネルで通信する実装は、データの各ソースに個別の圧縮辞書が使用されない限り、機密データと攻撃者制御データの両方を含むコンテンツを圧縮してはなりません。データのソースを確実に決定できない場合は、圧縮を使用してはなりません（MUST NOT）。 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内の特定の攻撃（たとえば、圧縮されたコンテンツに攻撃者が制御するプレーンテキストと秘密データ（[BREACH]など）の両方が含まれる攻撃）を軽減するために提供されます。
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.
中間体はDATAフレームのパディングを保持する必要がありますが、HEADERSおよびPUSH_PROMISEフレームのパディングを削除する必要があります（SHOULD）。仲介者がフレームのパディングの量を変更する正当な理由は、パディングが提供する保護を改善することです。
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.
単一のTCP接続を使用するためのHTTP / 2の設定により、サイトでのユーザーのアクティビティを相関させることができます。異なる発信元の接続を再利用すると、それらの発信元全体を追跡できます。
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].
[TLS-ALPN]で確立された「アプリケーション層プロトコルネゴシエーション（ALPN）プロトコルID」レジストリにHTTP / 2を識別するための文字列が入力されます。
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-Settingsヘッダーフィールドを登録します。また、421（Misdirected Request）ステータスコードも登録します。
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を参照）の識別用に2つの登録を作成します。
The "h2" string identifies HTTP/2 when used over TLS:
「h2」文字列は、TLSを介して使用される場合、HTTP / 2を識別します。
Protocol: HTTP/2 over TLS
プロトコル：HTTP / 2 over TLS
Identification Sequence: 0x68 0x32 ("h2")
識別シーケンス：0x68 0x32（ "h2"）
Specification: This document
仕様：このドキュメント
The "h2c" string identifies HTTP/2 when used over cleartext TCP:
「h2c」文字列は、クリアテキストTCPで使用される場合、HTTP / 2を識別します。
Protocol: HTTP/2 over TCP Identification Sequence: 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ビットのスペースを管理します。 "HTTP / 2 Frame Type"レジストリは、 "IETF Review"または "IESG Approval"ポリシー[RFC5226]のいずれかで動作し、0x00から0xefまでの値があり、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 |
+---------------+------+--------------+
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 |
+------------------------+------+---------------+---------------+
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 | |
+---------------------+------+----------------------+---------------+
This section registers the HTTP2-Settings header field in the "Permanent Message Header Field Names" registry [BCP90].
このセクションでは、HTTP2-Settingsヘッダーフィールドを「Permanent Message Header Field Names」レジストリ[BCP90]に登録します。
Header field name: HTTP2-Settings
ヘッダーフィールド名：HTTP2-Settings
Applicable protocol: http
該当するプロトコル：http
Status: standard
ステータス：標準
Author/Change controller: IETF Specification document(s): Section 3.2.1 of this document
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).
このドキュメントでは、421（Misdirected Request）HTTPステータスコードを「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).
このドキュメントでは、「h2c」アップグレードトークンを「HTTPアップグレードトークン」レジストリに登録しています（[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>.
[圧縮] Peon、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>.
[クッキー] 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-4、2013年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。、「HTTP Over TLS」、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、「Uniform Resource Identifier（URI）：Generic Syntax」、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。、「The 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、「RFCで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]クロッカー、D。、エド。および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]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、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]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年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]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Conditional Requests」、RFC 7232、DOI 10.17487 / RFC7232、2014年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。、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>。
[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。、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>。
[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]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Authentication」、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。、「Transmission Control Protocol」、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、「Transport Layer Security（TLS）Application-Layer Protocol Negotiation Extension」、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 Galois Counter Mode（GCM）を使用したTLS楕円曲線暗号スイート」、RFC 5289、DOI 10.17487 / RFC5289、2008年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。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、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、「The Transport Layer Security（TLS）Protocol Version 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 Alternative Services」、Work in Progress、draft-ietf-httpbis-alt-svc-06、2015年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>.
[違反] Gluck、Y.、Harris、N.、A。Prado、「BREACH：Reviving the CRIME Attack」、2013年7月、<http://breachattack.com/resources/ BREACH％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.、Width、T.、Doyle Navara、E.、O'Connor、E.、and S. Pfeiffer、 "HTML5"、W3C Recommendation 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。、「Transport Layer Security Protocol Compression Methods」、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、「Elliptic Curve Cryptography（ECC）Cipher Suites for Transport Layer Security（TLS）」、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 / RFC7323、2014年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>.
[TALKING] Huang、L.、Chen、E.、Barth、A.、Rescorla、E.、and C. Jackson、 "Talking Yourself to Yourself for Fun and Profit"、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、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（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を使用した次の暗号スイートのネゴシエーションを、タイプINADEQUATE_SECURITYの接続エラー（セクション5.4.1）として扱うことができます（MAY）。
o TLS_NULL_WITH_NULL_NULL
o TLS_NULL_WITH_NULL_NULL
o TLS_RSA_WITH_NULL_MD5
o TLS_RSA_WITH_NULL_MD5
o TLS_RSA_WITH_NULL_SHA
o TLS_RSA_WITH_NULL_SHA
o TLS_RSA_EXPORT_WITH_RC4_40_MD5
o TLS_RSA_EXPORT_WITH_RC4_40_MD5
o TLS_RSA_WITH_RC4_128_MD5
o TLS_RSA_WITH_RC4_128_MD5
o TLS_RSA_WITH_RC4_128_SHA
o TLS_RSA_WITH_RC4_128_SHA
o TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
o TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
o TLS_RSA_WITH_IDEA_CBC_SHA
o TLS_RSA_WITH_IDEA_CBC_SHA
o TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
o TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
o TLS_RSA_WITH_DES_CBC_SHA
o TLS_RSA_WITH_DES_CBC_SHA
o TLS_RSA_WITH_3DES_EDE_CBC_SHA
o TLS_RSA_WITH_3DES_EDE_CBC_SHA
o TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
o TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
o TLS_DH_DSS_WITH_DES_CBC_SHA
o TLS_DH_DSS_WITH_DES_CBC_SHA
o TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
o TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
o TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
o TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
o TLS_DH_RSA_WITH_DES_CBC_SHA
o TLS_DH_RSA_WITH_DES_CBC_SHA
o TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
o TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
o TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
o TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
o TLS_DHE_DSS_WITH_DES_CBC_SHA
o TLS_DHE_DSS_WITH_DES_CBC_SHA
o TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
o TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
o TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA o TLS_DHE_RSA_WITH_DES_CBC_SHA
o TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA o TLS_DHE_RSA_WITH_DES_CBC_SHA
o TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
o TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
o TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
o TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
o TLS_DH_anon_WITH_RC4_128_MD5
o TLS_DH_anon_WITH_RC4_128_MD5
o TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
o TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
o TLS_DH_anon_WITH_DES_CBC_SHA
o TLS_DH_anon_WITH_DES_CBC_SHA
o TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
o TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
o TLS_KRB5_WITH_DES_CBC_SHA
o TLS_KRB5_WITH_DES_CBC_SHA
o TLS_KRB5_WITH_3DES_EDE_CBC_SHA
o TLS_KRB5_WITH_3DES_EDE_CBC_SHA
o TLS_KRB5_WITH_RC4_128_SHA
o TLS_KRB5_WITH_RC4_128_SHA
o TLS_KRB5_WITH_IDEA_CBC_SHA
o TLS_KRB5_WITH_IDEA_CBC_SHA
o TLS_KRB5_WITH_DES_CBC_MD5
o TLS_KRB5_WITH_DES_CBC_MD5
o TLS_KRB5_WITH_3DES_EDE_CBC_MD5
o TLS_KRB5_WITH_3DES_EDE_CBC_MD5
o TLS_KRB5_WITH_RC4_128_MD5
o TLS_KRB5_WITH_RC4_128_MD5
o TLS_KRB5_WITH_IDEA_CBC_MD5
o TLS_KRB5_WITH_IDEA_CBC_MD5
o TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
o TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
o TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA
o TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA
o TLS_KRB5_EXPORT_WITH_RC4_40_SHA
o TLS_KRB5_EXPORT_WITH_RC4_40_SHA
o TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
o TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
o TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5
o TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5
o TLS_KRB5_EXPORT_WITH_RC4_40_MD5
o TLS_KRB5_EXPORT_WITH_RC4_40_MD5
o TLS_PSK_WITH_NULL_SHA
o TLS_PSK_WITH_NULL_SHA
o TLS_DHE_PSK_WITH_NULL_SHA
o TLS_DHE_PSK_WITH_NULL_SHA
o TLS_RSA_PSK_WITH_NULL_SHA o TLS_RSA_WITH_AES_128_CBC_SHA
o TLS_RSA_PSK_WITH_NULL_SHA o TLS_RSA_WITH_AES_128_CBC_SHA
o TLS_DH_DSS_WITH_AES_128_CBC_SHA
o TLS_DH_DSS_WITH_AES_128_CBC_SHA
o TLS_DH_RSA_WITH_AES_128_CBC_SHA
o TLS_DH_RSA_WITH_AES_128_CBC_SHA
o TLS_DHE_DSS_WITH_AES_128_CBC_SHA
o TLS_DHE_DSS_WITH_AES_128_CBC_SHA
o TLS_DHE_RSA_WITH_AES_128_CBC_SHA
o TLS_DHE_RSA_WITH_AES_128_CBC_SHA
o TLS_DH_anon_WITH_AES_128_CBC_SHA
o TLS_DH_anon_WITH_AES_128_CBC_SHA
o TLS_RSA_WITH_AES_256_CBC_SHA
o TLS_RSA_WITH_AES_256_CBC_SHA
o TLS_DH_DSS_WITH_AES_256_CBC_SHA
o TLS_DH_DSS_WITH_AES_256_CBC_SHA
o TLS_DH_RSA_WITH_AES_256_CBC_SHA
o TLS_DH_RSA_WITH_AES_256_CBC_SHA
o TLS_DHE_DSS_WITH_AES_256_CBC_SHA
o TLS_DHE_DSS_WITH_AES_256_CBC_SHA
o TLS_DHE_RSA_WITH_AES_256_CBC_SHA
o TLS_DHE_RSA_WITH_AES_256_CBC_SHA
o TLS_DH_anon_WITH_AES_256_CBC_SHA
o TLS_DH_anon_WITH_AES_256_CBC_SHA
o TLS_RSA_WITH_NULL_SHA256
o TLS_RSA_WITH_NULL_SHA256
o TLS_RSA_WITH_AES_128_CBC_SHA256
o TLS_RSA_WITH_AES_128_CBC_SHA256
o TLS_RSA_WITH_AES_256_CBC_SHA256
o TLS_RSA_WITH_AES_256_CBC_SHA256
o TLS_DH_DSS_WITH_AES_128_CBC_SHA256
o TLS_DH_DSS_WITH_AES_128_CBC_SHA256
o TLS_DH_RSA_WITH_AES_128_CBC_SHA256
o TLS_DH_RSA_WITH_AES_128_CBC_SHA256
o TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
o TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
o TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
o TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
o TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA
o TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA
o TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA
o TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA
o TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
o TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
o TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
o TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
o TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA o TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
o TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA o TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
o TLS_DH_DSS_WITH_AES_256_CBC_SHA256
o TLS_DH_DSS_WITH_AES_256_CBC_SHA256
o TLS_DH_RSA_WITH_AES_256_CBC_SHA256
o TLS_DH_RSA_WITH_AES_256_CBC_SHA256
o TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
o TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
o TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
o TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
o TLS_DH_anon_WITH_AES_128_CBC_SHA256
o TLS_DH_anon_WITH_AES_128_CBC_SHA256
o TLS_DH_anon_WITH_AES_256_CBC_SHA256
o TLS_DH_anon_WITH_AES_256_CBC_SHA256
o TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
o TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
o TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA
o TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA
o TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA
o TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA
o TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
o TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
o TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
o TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
o TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA
o TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA
o TLS_PSK_WITH_RC4_128_SHA
o TLS_PSK_WITH_RC4_128_SHA
o TLS_PSK_WITH_3DES_EDE_CBC_SHA
o TLS_PSK_WITH_3DES_EDE_CBC_SHA
o TLS_PSK_WITH_AES_128_CBC_SHA
o TLS_PSK_WITH_AES_128_CBC_SHA
o TLS_PSK_WITH_AES_256_CBC_SHA
o TLS_PSK_WITH_AES_256_CBC_SHA
o TLS_DHE_PSK_WITH_RC4_128_SHA
o TLS_DHE_PSK_WITH_RC4_128_SHA
o TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA
o TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA
o TLS_DHE_PSK_WITH_AES_128_CBC_SHA
o TLS_DHE_PSK_WITH_AES_128_CBC_SHA
o TLS_DHE_PSK_WITH_AES_256_CBC_SHA
o TLS_DHE_PSK_WITH_AES_256_CBC_SHA
o TLS_RSA_PSK_WITH_RC4_128_SHA
o TLS_RSA_PSK_WITH_RC4_128_SHA
o TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA
o TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA
o TLS_RSA_PSK_WITH_AES_128_CBC_SHA o TLS_RSA_PSK_WITH_AES_256_CBC_SHA
o TLS_RSA_PSK_WITH_AES_128_CBC_SHA o TLS_RSA_PSK_WITH_AES_256_CBC_SHA
o TLS_RSA_WITH_SEED_CBC_SHA
o TLS_RSA_WITH_SEED_CBC_SHA
o TLS_DH_DSS_WITH_SEED_CBC_SHA
o TLS_DH_DSS_WITH_SEED_CBC_SHA
o TLS_DH_RSA_WITH_SEED_CBC_SHA
o TLS_DH_RSA_WITH_SEED_CBC_SHA
o TLS_DHE_DSS_WITH_SEED_CBC_SHA
o TLS_DHE_DSS_WITH_SEED_CBC_SHA
o TLS_DHE_RSA_WITH_SEED_CBC_SHA
o TLS_DHE_RSA_WITH_SEED_CBC_SHA
o TLS_DH_anon_WITH_SEED_CBC_SHA
o TLS_DH_anon_WITH_SEED_CBC_SHA
o TLS_RSA_WITH_AES_128_GCM_SHA256
o TLS_RSA_WITH_AES_128_GCM_SHA256
o TLS_RSA_WITH_AES_256_GCM_SHA384
o TLS_RSA_WITH_AES_256_GCM_SHA384
o TLS_DH_RSA_WITH_AES_128_GCM_SHA256
o TLS_DH_RSA_WITH_AES_128_GCM_SHA256
o TLS_DH_RSA_WITH_AES_256_GCM_SHA384
o TLS_DH_RSA_WITH_AES_256_GCM_SHA384
o TLS_DH_DSS_WITH_AES_128_GCM_SHA256
o TLS_DH_DSS_WITH_AES_128_GCM_SHA256
o TLS_DH_DSS_WITH_AES_256_GCM_SHA384
o TLS_DH_DSS_WITH_AES_256_GCM_SHA384
o TLS_DH_anon_WITH_AES_128_GCM_SHA256
o TLS_DH_anon_WITH_AES_128_GCM_SHA256
o TLS_DH_anon_WITH_AES_256_GCM_SHA384
o TLS_DH_anon_WITH_AES_256_GCM_SHA384
o TLS_PSK_WITH_AES_128_GCM_SHA256
o TLS_PSK_WITH_AES_128_GCM_SHA256
o TLS_PSK_WITH_AES_256_GCM_SHA384
o TLS_PSK_WITH_AES_256_GCM_SHA384
o TLS_RSA_PSK_WITH_AES_128_GCM_SHA256
o TLS_RSA_PSK_WITH_AES_128_GCM_SHA256
o TLS_RSA_PSK_WITH_AES_256_GCM_SHA384
o TLS_RSA_PSK_WITH_AES_256_GCM_SHA384
o TLS_PSK_WITH_AES_128_CBC_SHA256
o TLS_PSK_WITH_AES_128_CBC_SHA256
o TLS_PSK_WITH_AES_256_CBC_SHA384
o TLS_PSK_WITH_AES_256_CBC_SHA384
o TLS_PSK_WITH_NULL_SHA256
o TLS_PSK_WITH_NULL_SHA256
o TLS_PSK_WITH_NULL_SHA384
o TLS_PSK_WITH_NULL_SHA384
o TLS_DHE_PSK_WITH_AES_128_CBC_SHA256 o TLS_DHE_PSK_WITH_AES_256_CBC_SHA384
o TLS_DHE_PSK_WITH_AES_128_CBC_SHA256 o TLS_DHE_PSK_WITH_AES_256_CBC_SHA384
o TLS_DHE_PSK_WITH_NULL_SHA256
o TLS_DHE_PSK_WITH_NULL_SHA256
o TLS_DHE_PSK_WITH_NULL_SHA384
o TLS_DHE_PSK_WITH_NULL_SHA384
o TLS_RSA_PSK_WITH_AES_128_CBC_SHA256
o TLS_RSA_PSK_WITH_AES_128_CBC_SHA256
o TLS_RSA_PSK_WITH_AES_256_CBC_SHA384
o TLS_RSA_PSK_WITH_AES_256_CBC_SHA384
o TLS_RSA_PSK_WITH_NULL_SHA256
o TLS_RSA_PSK_WITH_NULL_SHA256
o TLS_RSA_PSK_WITH_NULL_SHA384
o TLS_RSA_PSK_WITH_NULL_SHA384
o TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256
o TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256
o TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256
o TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256
o TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256
o TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256
o TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256
o TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256
o TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
o TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
o TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256
o TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256
o TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256
o TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256
o TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256
o TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256
o TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256
o TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256
o TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256
o TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256
o TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256
o TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256
o TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256
o TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256
o TLS_EMPTY_RENEGOTIATION_INFO_SCSV
o TLS_EMPTY_RENEGOTIATION_INFO_SCSV
o TLS_ECDH_ECDSA_WITH_NULL_SHA
o TLS_ECDH_ECDSA_WITH_NULL_SHA
o TLS_ECDH_ECDSA_WITH_RC4_128_SHA
o TLS_ECDH_ECDSA_WITH_RC4_128_SHA
o TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
o TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA o TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA o TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
o TLS_ECDHE_ECDSA_WITH_NULL_SHA
o TLS_ECDHE_ECDSA_WITH_NULL_SHA
o TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
o TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
o TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
o TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
o TLS_ECDH_RSA_WITH_NULL_SHA
o TLS_ECDH_RSA_WITH_NULL_SHA
o TLS_ECDH_RSA_WITH_RC4_128_SHA
o TLS_ECDH_RSA_WITH_RC4_128_SHA
o TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
o TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
o TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
o TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
o TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
o TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
o TLS_ECDHE_RSA_WITH_NULL_SHA
o TLS_ECDHE_RSA_WITH_NULL_SHA
o TLS_ECDHE_RSA_WITH_RC4_128_SHA
o TLS_ECDHE_RSA_WITH_RC4_128_SHA
o TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
o TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
o TLS_ECDH_anon_WITH_NULL_SHA
o TLS_ECDH_anon_WITH_NULL_SHA
o TLS_ECDH_anon_WITH_RC4_128_SHA
o TLS_ECDH_anon_WITH_RC4_128_SHA
o TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
o TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
o TLS_ECDH_anon_WITH_AES_128_CBC_SHA
o TLS_ECDH_anon_WITH_AES_128_CBC_SHA
o TLS_ECDH_anon_WITH_AES_256_CBC_SHA
o TLS_ECDH_anon_WITH_AES_256_CBC_SHA
o TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA
o TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA
o TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA
o TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA
o TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA o TLS_SRP_SHA_WITH_AES_128_CBC_SHA
o TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA o TLS_SRP_SHA_WITH_AES_128_CBC_SHA
o TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA
o TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA
o TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA
o TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA
o TLS_SRP_SHA_WITH_AES_256_CBC_SHA
o TLS_SRP_SHA_WITH_AES_256_CBC_SHA
o TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA
o TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA
o TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA
o TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA
o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
o TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
o TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
o TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
o TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
o TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
o TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
o TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
o TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
o TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
o TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
o TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
o TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
o TLS_ECDHE_PSK_WITH_RC4_128_SHA
o TLS_ECDHE_PSK_WITH_RC4_128_SHA
o TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA
o TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA
o TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA
o TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA
o TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA
o TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA
o TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256
o TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256
o TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384 o TLS_ECDHE_PSK_WITH_NULL_SHA
o TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384 o TLS_ECDHE_PSK_WITH_NULL_SHA
o TLS_ECDHE_PSK_WITH_NULL_SHA256
o TLS_ECDHE_PSK_WITH_NULL_SHA256
o TLS_ECDHE_PSK_WITH_NULL_SHA384
o TLS_ECDHE_PSK_WITH_NULL_SHA384
o TLS_RSA_WITH_ARIA_128_CBC_SHA256
o TLS_RSA_WITH_ARIA_128_CBC_SHA256
o TLS_RSA_WITH_ARIA_256_CBC_SHA384
o TLS_RSA_WITH_ARIA_256_CBC_SHA384
o TLS_DH_DSS_WITH_ARIA_128_CBC_SHA256
o TLS_DH_DSS_WITH_ARIA_128_CBC_SHA256
o TLS_DH_DSS_WITH_ARIA_256_CBC_SHA384
o TLS_DH_DSS_WITH_ARIA_256_CBC_SHA384
o TLS_DH_RSA_WITH_ARIA_128_CBC_SHA256
o TLS_DH_RSA_WITH_ARIA_128_CBC_SHA256
o TLS_DH_RSA_WITH_ARIA_256_CBC_SHA384
o TLS_DH_RSA_WITH_ARIA_256_CBC_SHA384
o TLS_DHE_DSS_WITH_ARIA_128_CBC_SHA256
o TLS_DHE_DSS_WITH_ARIA_128_CBC_SHA256
o TLS_DHE_DSS_WITH_ARIA_256_CBC_SHA384
o TLS_DHE_DSS_WITH_ARIA_256_CBC_SHA384
o TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256
o TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256
o TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384
o TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384
o TLS_DH_anon_WITH_ARIA_128_CBC_SHA256
o TLS_DH_anon_WITH_ARIA_128_CBC_SHA256
o TLS_DH_anon_WITH_ARIA_256_CBC_SHA384
o TLS_DH_anon_WITH_ARIA_256_CBC_SHA384
o TLS_ECDHE_ECDSA_WITH_ARIA_128_CBC_SHA256
o TLS_ECDHE_ECDSA_WITH_ARIA_128_CBC_SHA256
o TLS_ECDHE_ECDSA_WITH_ARIA_256_CBC_SHA384
o TLS_ECDHE_ECDSA_WITH_ARIA_256_CBC_SHA384
o TLS_ECDH_ECDSA_WITH_ARIA_128_CBC_SHA256
o TLS_ECDH_ECDSA_WITH_ARIA_128_CBC_SHA256
o TLS_ECDH_ECDSA_WITH_ARIA_256_CBC_SHA384
o TLS_ECDH_ECDSA_WITH_ARIA_256_CBC_SHA384
o TLS_ECDHE_RSA_WITH_ARIA_128_CBC_SHA256
o TLS_ECDHE_RSA_WITH_ARIA_128_CBC_SHA256
o TLS_ECDHE_RSA_WITH_ARIA_256_CBC_SHA384
o TLS_ECDHE_RSA_WITH_ARIA_256_CBC_SHA384
o TLS_ECDH_RSA_WITH_ARIA_128_CBC_SHA256
o TLS_ECDH_RSA_WITH_ARIA_128_CBC_SHA256
o TLS_ECDH_RSA_WITH_ARIA_256_CBC_SHA384
o TLS_ECDH_RSA_WITH_ARIA_256_CBC_SHA384
o TLS_RSA_WITH_ARIA_128_GCM_SHA256 o TLS_RSA_WITH_ARIA_256_GCM_SHA384
o TLS_RSA_WITH_ARIA_128_GCM_SHA256 o TLS_RSA_WITH_ARIA_256_GCM_SHA384
o TLS_DH_RSA_WITH_ARIA_128_GCM_SHA256
o TLS_DH_RSA_WITH_ARIA_128_GCM_SHA256
o TLS_DH_RSA_WITH_ARIA_256_GCM_SHA384
o TLS_DH_RSA_WITH_ARIA_256_GCM_SHA384
o TLS_DH_DSS_WITH_ARIA_128_GCM_SHA256
o TLS_DH_DSS_WITH_ARIA_128_GCM_SHA256
o TLS_DH_DSS_WITH_ARIA_256_GCM_SHA384
o TLS_DH_DSS_WITH_ARIA_256_GCM_SHA384
o TLS_DH_anon_WITH_ARIA_128_GCM_SHA256
o TLS_DH_anon_WITH_ARIA_128_GCM_SHA256
o TLS_DH_anon_WITH_ARIA_256_GCM_SHA384
o TLS_DH_anon_WITH_ARIA_256_GCM_SHA384
o TLS_ECDH_ECDSA_WITH_ARIA_128_GCM_SHA256
o TLS_ECDH_ECDSA_WITH_ARIA_128_GCM_SHA256
o TLS_ECDH_ECDSA_WITH_ARIA_256_GCM_SHA384
o TLS_ECDH_ECDSA_WITH_ARIA_256_GCM_SHA384
o TLS_ECDH_RSA_WITH_ARIA_128_GCM_SHA256
o TLS_ECDH_RSA_WITH_ARIA_128_GCM_SHA256
o TLS_ECDH_RSA_WITH_ARIA_256_GCM_SHA384
o TLS_ECDH_RSA_WITH_ARIA_256_GCM_SHA384
o TLS_PSK_WITH_ARIA_128_CBC_SHA256
o TLS_PSK_WITH_ARIA_128_CBC_SHA256
o TLS_PSK_WITH_ARIA_256_CBC_SHA384
o TLS_PSK_WITH_ARIA_256_CBC_SHA384
o TLS_DHE_PSK_WITH_ARIA_128_CBC_SHA256
o TLS_DHE_PSK_WITH_ARIA_128_CBC_SHA256
o TLS_DHE_PSK_WITH_ARIA_256_CBC_SHA384
o TLS_DHE_PSK_WITH_ARIA_256_CBC_SHA384
o TLS_RSA_PSK_WITH_ARIA_128_CBC_SHA256
o TLS_RSA_PSK_WITH_ARIA_128_CBC_SHA256
o TLS_RSA_PSK_WITH_ARIA_256_CBC_SHA384
o TLS_RSA_PSK_WITH_ARIA_256_CBC_SHA384
o TLS_PSK_WITH_ARIA_128_GCM_SHA256
o TLS_PSK_WITH_ARIA_128_GCM_SHA256
o TLS_PSK_WITH_ARIA_256_GCM_SHA384
o TLS_PSK_WITH_ARIA_256_GCM_SHA384
o TLS_RSA_PSK_WITH_ARIA_128_GCM_SHA256
o TLS_RSA_PSK_WITH_ARIA_128_GCM_SHA256
o TLS_RSA_PSK_WITH_ARIA_256_GCM_SHA384
o TLS_RSA_PSK_WITH_ARIA_256_GCM_SHA384
o TLS_ECDHE_PSK_WITH_ARIA_128_CBC_SHA256
o TLS_ECDHE_PSK_WITH_ARIA_128_CBC_SHA256
o TLS_ECDHE_PSK_WITH_ARIA_256_CBC_SHA384
o TLS_ECDHE_PSK_WITH_ARIA_256_CBC_SHA384
o TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 o TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384
o TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 o TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384
o TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256
o TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256
o TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384
o TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384
o TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
o TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
o TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384
o TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384
o TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256
o TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256
o TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384
o TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384
o TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256
o TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256
o TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384
o TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384
o TLS_DH_RSA_WITH_CAMELLIA_128_GCM_SHA256
o TLS_DH_RSA_WITH_CAMELLIA_128_GCM_SHA256
o TLS_DH_RSA_WITH_CAMELLIA_256_GCM_SHA384
o TLS_DH_RSA_WITH_CAMELLIA_256_GCM_SHA384
o TLS_DH_DSS_WITH_CAMELLIA_128_GCM_SHA256
o TLS_DH_DSS_WITH_CAMELLIA_128_GCM_SHA256
o TLS_DH_DSS_WITH_CAMELLIA_256_GCM_SHA384
o TLS_DH_DSS_WITH_CAMELLIA_256_GCM_SHA384
o TLS_DH_anon_WITH_CAMELLIA_128_GCM_SHA256
o TLS_DH_anon_WITH_CAMELLIA_128_GCM_SHA256
o TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384
o TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384
o TLS_ECDH_ECDSA_WITH_CAMELLIA_128_GCM_SHA256
o TLS_ECDH_ECDSA_WITH_CAMELLIA_128_GCM_SHA256
o TLS_ECDH_ECDSA_WITH_CAMELLIA_256_GCM_SHA384
o TLS_ECDH_ECDSA_WITH_CAMELLIA_256_GCM_SHA384
o TLS_ECDH_RSA_WITH_CAMELLIA_128_GCM_SHA256
o TLS_ECDH_RSA_WITH_CAMELLIA_128_GCM_SHA256
o TLS_ECDH_RSA_WITH_CAMELLIA_256_GCM_SHA384
o TLS_ECDH_RSA_WITH_CAMELLIA_256_GCM_SHA384
o TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256
o TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256
o TLS_PSK_WITH_CAMELLIA_256_GCM_SHA384
o TLS_PSK_WITH_CAMELLIA_256_GCM_SHA384
o TLS_RSA_PSK_WITH_CAMELLIA_128_GCM_SHA256
o TLS_RSA_PSK_WITH_CAMELLIA_128_GCM_SHA256
o TLS_RSA_PSK_WITH_CAMELLIA_256_GCM_SHA384
o TLS_RSA_PSK_WITH_CAMELLIA_256_GCM_SHA384
o TLS_PSK_WITH_CAMELLIA_128_CBC_SHA256 o TLS_PSK_WITH_CAMELLIA_256_CBC_SHA384
o TLS_PSK_WITH_CAMELLIA_128_CBC_SHA256 o TLS_PSK_WITH_CAMELLIA_256_CBC_SHA384
o TLS_DHE_PSK_WITH_CAMELLIA_128_CBC_SHA256
o TLS_DHE_PSK_WITH_CAMELLIA_128_CBC_SHA256
o TLS_DHE_PSK_WITH_CAMELLIA_256_CBC_SHA384
o TLS_DHE_PSK_WITH_CAMELLIA_256_CBC_SHA384
o TLS_RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256
o TLS_RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256
o TLS_RSA_PSK_WITH_CAMELLIA_256_CBC_SHA384
o TLS_RSA_PSK_WITH_CAMELLIA_256_CBC_SHA384
o TLS_ECDHE_PSK_WITH_CAMELLIA_128_CBC_SHA256
o TLS_ECDHE_PSK_WITH_CAMELLIA_128_CBC_SHA256
o TLS_ECDHE_PSK_WITH_CAMELLIA_256_CBC_SHA384
o TLS_ECDHE_PSK_WITH_CAMELLIA_256_CBC_SHA384
o TLS_RSA_WITH_AES_128_CCM
o TLS_RSA_WITH_AES_128_CCM
o TLS_RSA_WITH_AES_256_CCM
o TLS_RSA_WITH_AES_256_CCM
o TLS_RSA_WITH_AES_128_CCM_8
o TLS_RSA_WITH_AES_128_CCM_8
o TLS_RSA_WITH_AES_256_CCM_8
o TLS_RSA_WITH_AES_256_CCM_8
o TLS_PSK_WITH_AES_128_CCM
o TLS_PSK_WITH_AES_128_CCM
o TLS_PSK_WITH_AES_256_CCM
o TLS_PSK_WITH_AES_256_CCM
o TLS_PSK_WITH_AES_128_CCM_8
o TLS_PSK_WITH_AES_128_CCM_8
o TLS_PSK_WITH_AES_256_CCM_8
o TLS_PSK_WITH_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 ウィリアムチャン、サルヴァトーレロレート、オサママザヒル、ガブリエルモンテネグロ、ジトゥパディ、ロベルトペオン、ロブトレース（フロー制御）。
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 Mark Nottingham、Julian Reschke、James Snell、Jeff Pinner、Mike Bishop、Herve Ruellan（相当な編集寄稿）。
o Kari Hurtta, Tatsuhiro Tsujikawa, Greg Wilkins, Poul-Henning Kamp, and Jonathan Thackray.
o カリ・ハッタ、辻川達弘、グレッグ・ウィルキンス、ポール・ヘニング・カンプ、ジョナサン・サックレイ。
o Alexey Melnikov, who was an editor of this document in 2013.
o 2013年にこのドキュメントの編集者を務めたAlexey Melnikov。
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
マイク・ベルシェ・ビットゴー
EMail: mike@belshe.com
Roberto Peon Google, Inc
Roberto Peon Google、Inc
EMail: fenix@google.com
Martin Thomson (editor) Mozilla 331 E Evelyn Street Mountain View, CA 94041 United States
マーティン・トムソン（編集者）Mozilla 331 E Evelyn Street Mountain View、CA 94041 United States
EMail: martin.thomson@gmail.com