[要約] RFC 7692はWebSocketの圧縮拡張機能に関する仕様であり、データの圧縮と伝送効率の向上を目的としています。
Internet Engineering Task Force (IETF) T. Yoshino
Request for Comments: 7692 Google, Inc.
Category: Standards Track December 2015
ISSN: 2070-1721
Compression Extensions for WebSocket
WebSocketの圧縮拡張機能
Abstract
概要
This document defines a framework for creating WebSocket extensions that add compression functionality to the WebSocket Protocol. An extension based on this framework compresses the payload data portion of WebSocket data messages on a per-message basis using parameters negotiated during the opening handshake. This framework provides a general method for applying a compression algorithm to the contents of WebSocket messages. Each compression algorithm has to be defined in a document defining the extension by specifying the parameter negotiation and the payload transformation algorithm in detail. This document also specifies one specific compression extension using the DEFLATE algorithm.
このドキュメントでは、WebSocketプロトコルに圧縮機能を追加するWebSocket拡張機能を作成するためのフレームワークを定義します。このフレームワークに基づく拡張機能は、オープニングハンドシェイク中にネゴシエートされたパラメーターを使用して、メッセージごとにWebSocketデータメッセージのペイロードデータ部分を圧縮します。このフレームワークは、WebSocketメッセージのコンテンツに圧縮アルゴリズムを適用するための一般的な方法を提供します。各圧縮アルゴリズムは、パラメータネゴシエーションとペイロード変換アルゴリズムを詳細に指定して、拡張を定義するドキュメントで定義する必要があります。このドキュメントでは、DEFLATEアルゴリズムを使用する1つの特定の圧縮拡張も指定しています。
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/rfc7692.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7692で入手できます。
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 ....................................................3
2. Conformance Requirements and Terminology ........................3
3. Complementary Terminology .......................................4
4. WebSocket Per-Message Compression Extension .....................5
5. Extension Negotiation ...........................................5
5.1. General Negotiation Flow ...................................9
5.2. Negotiation Examples .......................................9
6. Framing ........................................................10
6.1. Compression ...............................................10
6.2. Decompression .............................................12
7. The "permessage-deflate" Extension .............................12
7.1. Extension Parameters ......................................14
7.1.1. Context Takeover Control ...........................14
7.1.2. Limiting the LZ77 Sliding Window Size ..............16
7.1.3. Examples ...........................................18
7.2. Message Payload Transformation ............................19
7.2.1. Compression ........................................19
7.2.2. Decompression ......................................21
7.2.3. Examples ...........................................22
7.3. Implementation Notes ......................................25
8. Security Considerations ........................................25
9. IANA Considerations ............................................26
9.1. Registration of the "permessage-deflate" WebSocket
Extension Name ............................................26
9.2. Registration of the "Per-Message Compressed"
WebSocket Framing Header Bit ..............................26
10. References ....................................................27
10.1. Normative References .....................................27
10.2. Informative References ...................................27
Acknowledgements ..................................................28
Author's Address ..................................................28
This document specifies a framework for adding compression functionality to the WebSocket Protocol [RFC6455]. The framework specifies how to define WebSocket Per-Message Compression Extensions (PMCEs) for a compression algorithm based on the extension concept of the WebSocket Protocol specified in Section 9 of [RFC6455]. A WebSocket client and a peer WebSocket server negotiate the use of a PMCE and determine the parameters required to configure the compression algorithm during the WebSocket opening handshake. The client and server can then exchange data messages whose frames contain compressed data in the payload data portion.
このドキュメントは、WebSocketプロトコル[RFC6455]に圧縮機能を追加するためのフレームワークを指定します。フレームワークは、[RFC6455]のセクション9で指定されたWebSocketプロトコルの拡張概念に基づいて、圧縮アルゴリズムのWebSocket Per-Message Compression Extensions（PMCE）を定義する方法を指定します。 WebSocketクライアントとピアWebSocketサーバーはPMCEの使用をネゴシエートし、WebSocketオープニングハンドシェイク中に圧縮アルゴリズムを構成するために必要なパラメーターを決定します。クライアントとサーバーは、フレームのペイロードデータ部分に圧縮データが含まれるデータメッセージを交換できます。
This framework only specifies a general method for applying a compression algorithm to the contents of WebSocket messages. Each individual PMCE has to be specified in a document describing in detail how to negotiate the configuration parameters for the specific compression algorithm used by that PMCE and how to transform (compress and decompress) data in the payload data portion.
このフレームワークは、WebSocketメッセージのコンテンツに圧縮アルゴリズムを適用する一般的な方法のみを指定します。個々のPMCEは、そのPMCEが使用する特定の圧縮アルゴリズムの構成パラメーターをネゴシエートする方法と、ペイロードデータ部分のデータを変換（圧縮および解凍）する方法を詳細に説明するドキュメントで指定する必要があります。
A WebSocket client may offer multiple PMCEs during the WebSocket opening handshake. A peer WebSocket server receiving the offer may choose to accept the preferred PMCE or decline all of them. PMCEs use the RSV1 bit of the WebSocket frame header to indicate whether a message is compressed or not so that an endpoint can choose not to compress messages with incompressible contents.
WebSocketクライアントは、WebSocketオープニングハンドシェイク中に複数のPMCEを提供する場合があります。オファーを受信するピアWebSocketサーバーは、優先PMCEを受け入れるか、それらすべてを拒否するかを選択できます。 PMCEは、WebSocketフレームヘッダーのRSV1ビットを使用してメッセージが圧縮されているかどうかを示し、エンドポイントが圧縮できない内容のメッセージを圧縮しないように選択できるようにします。
This document also specifies one specific PMCE based on the DEFLATE [RFC1951] algorithm. The DEFLATE algorithm is widely available on various platforms, and its overhead is small. The extension name of this PMCE is "permessage-deflate". To align the end of compressed data to an octet boundary, this extension uses the algorithm described in Section 2.1 of [RFC1979]. Endpoints can take over the LZ77 sliding window [LZ77] used to build frames for previous messages to achieve a better compression ratio. For resource-limited devices, this extension provides parameters to limit memory usage for compression context.
このドキュメントでは、DEFLATE [RFC1951]アルゴリズムに基づく特定のPMCEも1つ指定しています。 DEFLATEアルゴリズムはさまざまなプラットフォームで広く利用可能で、そのオーバーヘッドはわずかです。このPMCEの拡張名は「permessage-deflate」です。圧縮データの終わりをオクテット境界に揃えるために、この拡張機能は[RFC1979]のセクション2.1で説明されているアルゴリズムを使用します。エンドポイントは、以前のメッセージのフレームを構築するために使用されたLZ77スライディングウィンドウ[LZ77]を引き継ぎ、より良い圧縮率を実現できます。リソースが制限されたデバイスの場合、この拡張機能は、圧縮コンテキストのメモリ使用量を制限するパラメーターを提供します。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("MUST", "SHOULD", "MAY", etc.) used in introducing the algorithm.
アルゴリズムの一部として命令で語られた要件（「先頭の空白文字を取り除く」または「falseを返してこれらのステップを中止する」など）は、キーワードの意味（「MUST」、「SHOULD」、「 MAY "など）を使用してアルゴリズムを紹介します。
Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant.
アルゴリズムまたは特定のステップとして表現される適合性要件は、最終結果が同等である限り、任意の方法で実装できます。特に、この仕様で定義されているアルゴリズムは、理解を容易にするためのものであり、パフォーマンスを発揮するためのものではありません。
This document references the procedure to _Fail the WebSocket Connection_. This procedure is defined in Section 7.1.7 of [RFC6455].
このドキュメントでは、_WebSocket接続に失敗する手順について説明します。この手順は、[RFC6455]のセクション7.1.7で定義されています。
This document references the event that _The WebSocket Connection is Established_ and the event that _A WebSocket Message Has Been Received_. These events are defined in Sections 4.1 and 6.2, respectively, of [RFC6455].
このドキュメントは、_The WebSocket Connection is Established_というイベントと、_A WebSocketメッセージが受信されたというイベント_を参照しています。これらのイベントは、[RFC6455]のセクション4.1および6.2でそれぞれ定義されています。
This document uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]. The DIGIT (decimal 0-9) rule is included by reference, as defined in the Appendix B.1 of [RFC5234].
このドキュメントでは、[RFC5234]の拡張バッカスナウアフォーム（ABNF）表記を使用しています。 [RFC5234]の付録B.1で定義されているように、DIGIT（10進数の0〜9）ルールは参照により含まれています。
This document defines some terms about WebSocket and WebSocket extension mechanisms that are underspecified or not defined at all in [RFC6455].
このドキュメントは、[RFC6455]で指定されていないかまったく定義されていないWebSocketおよびWebSocket拡張メカニズムに関するいくつかの用語を定義しています。
data message - a message consisting of data frames as defined in Section 5.6 of [RFC6455].
データメッセージ-[RFC6455]のセクション5.6で定義されているデータフレームで構成されるメッセージ。
message payload (or payload of a message) - the concatenation of the payload data portion of all data frames (see Section 6.2 of [RFC6455]) representing a single message.
メッセージペイロード（またはメッセージのペイロード）-単一のメッセージを表す、すべてのデータフレームのペイロードデータ部分の連結（[RFC6455]のセクション6.2を参照）。
next extension in use after extension X - the next extension listed after X in the "Sec-WebSocket-Extensions" header in the server's opening handshake as defined in Section 9.1 of [RFC6455]. Such an extension is applied to outgoing data from the application right after X on the sender side but is applied right before X to incoming data from the underlying transport.
拡張Xの後に使用中の次の拡張-[RFC6455]のセクション9.1で定義されている、サーバーのオープニングハンドシェイクの「Sec-WebSocket-Extensions」ヘッダーでXの後にリストされている次の拡張このような拡張は、送信側のXの直後のアプリケーションからの発信データに適用されますが、基になるトランスポートからの着信データのXの直前に適用されます。
extension in use preceding extension X - the extension listed right before X in the "Sec-WebSocket-Extensions" header in the server's opening handshake. Such an extension is applied to outgoing data from the application right before X on the sender side but is applied right after X to incoming data from the underlying transport.
エクステンションXの前に使用中のエクステンション-サーバーのオープニングハンドシェイクの「Sec-WebSocket-Extensions」ヘッダーでXの直前にリストされているエクステンション。このような拡張は、送信側のXの直前のアプリケーションからの送信データに適用されますが、基になるトランスポートからの受信データにはXの直後に適用されます。
extension negotiation offer - each element in the "Sec-WebSocket-Extensions" header in the client's opening handshake.
拡張交渉オファー-クライアントのオープニングハンドシェイクの「Sec-WebSocket-Extensions」ヘッダーの各要素。
extension negotiation response - each element in the "Sec-WebSocket-Extensions" header in the server's opening handshake.
拡張交渉応答-サーバーの開始ハンドシェイクの「Sec-WebSocket-Extensions」ヘッダーの各要素。
corresponding extension negotiation response for an extension negotiation offer - an extension negotiation response that a server sends back to the peer client containing the same extension name as the offer and meeting the requirements represented by the offer.
拡張ネゴシエーションオファーに対応する拡張ネゴシエーション応答-サーバーがオファーと同じ拡張名を含み、オファーによって表される要件を満たすピアクライアントに送り返す拡張ネゴシエーション応答。
Accepting an extension negotiation offer - including a corresponding extension negotiation response for the offer in the "Sec-WebSocket-Extensions" header in the server's opening handshake.
拡張ネゴシエーションオファーの受け入れ-サーバーのオープニングハンドシェイクの「Sec-WebSocket-Extensions」ヘッダーにオファーに対応する拡張ネゴシエーション応答を含めます。
Declining an extension negotiation offer - not including a corresponding extension negotiation response for the offer in the "Sec-WebSocket-Extensions" header in the server's opening handshake.
拡張ネゴシエーションオファーの拒否-サーバーのオープニングハンドシェイクの「Sec-WebSocket-Extensions」ヘッダーにオファーの対応する拡張ネゴシエーション応答を含めません。
WebSocket PMCEs are extensions to the WebSocket Protocol enabling compression functionality. PMCEs are built based on the extension concept of the WebSocket Protocol specified in Section 9 of [RFC6455]. PMCEs are individually defined for each compression algorithm to be implemented and are registered in the "WebSocket Extension Name Registry" created in Section 11.4 of [RFC6455]. Each PMCE referring to this framework MUST define the following:
WebSocket PMCEは、圧縮機能を有効にするWebSocketプロトコルの拡張機能です。 PMCEは、[RFC6455]のセクション9で指定されているWebSocketプロトコルの拡張概念に基づいて構築されています。 PMCEは、実装する圧縮アルゴリズムごとに個別に定義され、[RFC6455]のセクション11.4で作成された「WebSocket Extension Name Registry」に登録されます。このフレームワークを参照する各PMCEは、以下を定義する必要があります。
o The extension name of the PMCE and any applicable extension parameters that MUST be included in the "Sec-WebSocket-Extensions" header during the extension negotiation offer/response.
o PMCEの拡張名と、拡張ネゴシエーションの提供/応答時に「Sec-WebSocket-Extensions」ヘッダーに含める必要がある該当する拡張パラメーター。
o How to interpret the extension parameters exchanged during the opening handshake.
o オープニングハンドシェイク中に交換された拡張パラメータを解釈する方法。
o How to transform the payload of a message.
o メッセージのペイロードを変換する方法。
One PMCE is defined in Section 7 of this document and is registered in Section 9. Other PMCEs may be defined in the future in other documents.
1つのPMCEはこのドキュメントのセクション7で定義され、セクション9で登録されています。他のPMCEは将来、他のドキュメントで定義される可能性があります。
Section 5 describes the basic extension negotiation process. Section 6 describes how to apply the compression algorithm with negotiated parameters to the contents of WebSocket messages.
セクション5では、基本的な拡張交渉プロセスについて説明します。セクション6では、ネゴシエートされたパラメーターを使用して圧縮アルゴリズムをWebSocketメッセージのコンテンツに適用する方法について説明します。
To offer use of a PMCE, a client MUST include the extension name of the PMCE in the "Sec-WebSocket-Extensions" header field of its opening handshake of the WebSocket connection. Extension parameters are used to specify the PMCE offer in detail. For example, a client lists its preferred configuration parameter values for the compression algorithm of the PMCE. A client may also offer multiple PMCE choices to the server by including multiple elements in the "Sec-WebSocket-Extensions" header, one for each PMCE offered. This set of elements MAY include multiple PMCEs with the same extension name to offer the possibility to use the same algorithm with different configuration parameters. The order of elements is important as it specifies the client's preference. An element preceding another element has higher preference. It is recommended that a server accepts PMCEs with higher preference if the server supports them.
PMCEの使用を提供するには、クライアントはWebSocket接続の開始ハンドシェイクの「Sec-WebSocket-Extensions」ヘッダーフィールドにPMCEの拡張名を含める必要があります。拡張パラメーターは、PMCEオファーを詳細に指定するために使用されます。たとえば、クライアントはPMCEの圧縮アルゴリズムの優先構成パラメータ値を一覧表示します。クライアントは、「Sec-WebSocket-Extensions」ヘッダーに複数の要素を含めることで、サーバーに複数のPMCEの選択肢を提供することもできます（提供されるPMCEごとに1つ）。この要素のセットには、同じ構成名で同じアルゴリズムを使用する可能性を提供するために、同じ拡張子名を持つ複数のPMCEが含まれる場合があります。要素の順序はクライアントの設定を指定するため重要です。別の要素の前の要素が優先されます。サーバーがPMCEをサポートしている場合は、より優先度の高いPMCEを受け入れることをお勧めします。
A PMCE negotiation offer provides requests and/or hints to the server.
PMCEネゴシエーションオファーは、サーバーにリクエストやヒントを提供します。
A request in a PMCE negotiation offer indicates constraints on the server's behavior that must be satisfied if the server accepts the offer. For example, suppose that a server sends data compressed with the DEFLATE algorithm to a client. The server must keep the original bytes of data that it recently compressed and sent to the client. The client must keep the result of decompressing the bytes of data that it recently received from the server. The amount of bytes of data kept is called the LZ77 window size. The LZ77 window size of the client must not be less than the LZ77 window size of the server. In a PMCE negotiation offer, the client MUST inform the server of its LZ77 window size so that the server uses an LZ77 window size that is not greater than the LZ77 window size of the client. This restriction on the LZ77 window size is an example of a request in a PMCE negotiation offer.
PMCEネゴシエーションオファーのリクエストは、サーバーがオファーを受け入れる場合に満たす必要があるサーバーの動作に対する制約を示します。たとえば、サーバーがDEFLATEアルゴリズムで圧縮されたデータをクライアントに送信するとします。サーバーは、最近圧縮してクライアントに送信したデータの元のバイトを保持する必要があります。クライアントは、サーバーから最近受信したデータのバイトを解凍した結果を保持する必要があります。保持されるデータのバイト量は、LZ77ウィンドウサイズと呼ばれます。クライアントのLZ77ウィンドウサイズは、サーバーのLZ77ウィンドウサイズ以上でなければなりません。 PMCEネゴシエーションオファーでは、サーバーがクライアントのLZ77ウィンドウサイズを超えないLZ77ウィンドウサイズを使用できるように、クライアントはサーバーにLZ77ウィンドウサイズを通知する必要があります。 LZ77ウィンドウサイズに対するこの制限は、PMCEネゴシエーションオファーの要求の例です。
A hint in a PMCE negotiation offer provides information about the client's behavior that the server may either safely ignore or refer to when the server decides its behavior. For example, suppose that a client sends data compressed with the DEFLATE algorithm to a server. The client must keep the original bytes of data that it recently compressed and sent to the server. The server must keep the result of decompressing the bytes of data that it recently received from the client. The LZ77 window size of the server must not be less than the LZ77 window size of the client. In a PMCE negotiation offer, the client MAY inform the server of the maximum LZ77 window size the client can afford so that the server can choose to use an LZ77 window size that is not greater than the maximum size of the client. This information is an example of a hint in a PMCE negotiation offer. It's waste of memory to use an LZ77 window size greater than the LZ77 window size the client actually uses. Using the hint, the server can avoid the waste of memory. Since the hint itself doesn't specify the constraints on the endpoints, the server must use the "agreed parameters" (defined below) to explicitly ask the client not to use an LZ77 window size greater than the LZ77 window size of the server.
PMCEネゴシエーションオファーのヒントは、サーバーが安全に無視するか、サーバーがその動作を決定するときに参照するクライアントの動作に関する情報を提供します。たとえば、クライアントがDEFLATEアルゴリズムで圧縮されたデータをサーバーに送信するとします。クライアントは、最近圧縮してサーバーに送信したデータの元のバイトを保持する必要があります。サーバーは、クライアントから最近受信したデータのバイトを解凍した結果を保持する必要があります。サーバーのLZ77ウィンドウサイズは、クライアントのLZ77ウィンドウサイズ以上でなければなりません。 PMCEネゴシエーションオファーでは、クライアントはサーバーがクライアントに提供できる最大LZ77ウィンドウサイズをサーバーに通知して、サーバーがクライアントの最大サイズ以下のLZ77ウィンドウサイズを使用できるようにすることができます（MAY）。この情報は、PMCE交渉提案のヒントの例です。クライアントが実際に使用するLZ77ウィンドウサイズよりも大きいLZ77ウィンドウサイズを使用すると、メモリの浪費になります。ヒントを使用すると、サーバーはメモリの浪費を回避できます。ヒント自体はエンドポイントの制約を指定していないため、サーバーは「同意パラメーター」（以下で定義）を使用して、サーバーのLZ77ウィンドウサイズより大きいLZ77ウィンドウサイズを使用しないようにクライアントに明示的に要求する必要があります。
To accept the use of an offered PMCE, a server MUST include the extension name of the PMCE in the "Sec-WebSocket-Extensions" header field of its opening handshake of the WebSocket connection. Extension parameters represent the detailed configuration parameters for the PMCE to use. These extension parameters and their values are called "agreed parameters". The element MUST represent a PMCE that is fully supported by the server. The contents of the element don't need to be exactly the same as those of the received extension negotiation offers. For example, suppose that a server received a PMCE extension negotiation offer with an extension parameter "X" indicating that the client can enable an optional feature named X. The server may accept the PMCE offer with an element without the extension parameter "X", meaning that the server chose not to enable the feature X. In this case, the offer contains the extension parameter "X", but the "agreed parameters" don't contain the extension parameter "X".
提供されたPMCEの使用を受け入れるには、サーバーはWebSocket接続の開始ハンドシェイクの「Sec-WebSocket-Extensions」ヘッダーフィールドにPMCEの拡張名を含める必要があります。拡張パラメーターは、PMCEが使用する詳細な構成パラメーターを表します。これらの拡張パラメーターとその値は、「合意パラメーター」と呼ばれます。要素は、サーバーによって完全にサポートされるPMCEを表す必要があります。要素の内容は、受信した拡張交渉オファーの内容と完全に同じである必要はありません。たとえば、サーバーが、クライアントがXという名前のオプション機能を有効にできることを示す拡張パラメーター「X」を含むPMCE拡張ネゴシエーションオファーを受信したとします。サーバーは、拡張パラメーター「X」のないエレメントを含むPMCEオファーを受け入れることができます。サーバーが機能Xを有効にしないことを選択したことを意味します。この場合、オファーには拡張パラメーター「X」が含まれていますが、「合意済みパラメーター」には拡張パラメーター「X」が含まれていません。
"Agreed parameters" must represent how the requests and hints in the client's extension negotiation offer have been handled in addition to the server's requests and hints on the client's behavior, so that the client can configure its behavior without identifying exactly which PMCE extension negotiation offer has been accepted.
「合意されたパラメータ」は、クライアントの動作に関するサーバーのリクエストとヒントに加えて、クライアントの拡張ネゴシエーションオファーのリクエストとヒントがどのように処理されたかを表す必要があります。これにより、クライアントは、どのPMCE拡張ネゴシエーションオファーがあるかを正確に識別せずに動作を構成できます。受け入れられました。
For example, if a client sends an extension negotiation offer that includes a parameter "enable_compression" and another without this parameter, the server accepts the former and informs the client by sending back an element that includes parameter(s) acknowledging "enable_compression". The name of the acknowledging parameter doesn't need to be exactly the same as the offer. For example, two parameters, "enable_strong_compression" and "enable_weak_compression", may be defined as acknowledging parameters for "enable_compression".
たとえば、クライアントが「enable_compression」パラメータを含む拡張ネゴシエーション提案を送信し、別のパラメータがこのパラメータなしで送信する場合、サーバーは前者を受け入れ、「enable_compression」を確認するパラメータを含む要素を送り返すことによってクライアントに通知します。確認パラメータの名前は、オファーと正確に同じである必要はありません。たとえば、「enable_strong_compression」と「enable_weak_compression」の2つのパラメータは、「enable_compression」の確認応答パラメータとして定義できます。
Compression features can be applied differently for each direction. For such features, the acknowledging parameter and the parameter in the reverse direction must be chosen to distinguish them. For example, in order to make parameters distinguishable, a "server_" prefix can be added to parameters affecting data sent from a server, and a "client_" prefix can be added to parameters affecting data sent from a client.
圧縮機能は、方向ごとに異なる方法で適用できます。このような機能の場合、確認パラメータと逆方向のパラメータを選択して、それらを区別する必要があります。たとえば、パラメータを区別できるようにするために、サーバーから送信されるデータに影響を与えるパラメータに「server_」プレフィックスを追加でき、クライアントから送信されるデータに影響を与えるパラメータに「client_」プレフィックスを追加できます。
A server MUST NOT accept a PMCE extension negotiation offer together with another extension if the PMCE will conflict with the extension on their use of the RSV1 bit. A client that received a response accepting a PMCE extension negotiation offer together with such an extension MUST _Fail the WebSocket Connection_.
PMCEがRSV1ビットの使用時に拡張と競合する場合、サーバーは別の拡張と一緒にPMCE拡張ネゴシエーションオファーを受け入れてはなりません（MUST NOT）。 PMCE拡張ネゴシエーションを受け入れる応答を受け取ったクライアントは、そのような拡張とともに、_WebSocket接続に失敗する必要があります_。
A server MUST NOT accept a PMCE extension negotiation offer together with another extension if the PMCE will be applied to the output of the extension and any of the following conditions applies to the extension:
PMCEが拡張の出力に適用され、以下の条件のいずれかが拡張に適用される場合、サーバーはPMCE拡張ネゴシエーションのオファーを別の拡張と一緒に受け入れてはなりません（MUST NOT）。
o The extension requires the boundary of frames to be preserved between the output from the extension at the sender and the input to the extension at the receiver.
o 拡張では、送信側の拡張からの出力と受信側の拡張への入力との間でフレームの境界を維持する必要があります。
o The extension uses the "Extension data" field or any of the reserved bits on the WebSocket header as a per-frame attribute.
o 拡張機能は、「拡張データ」フィールドまたはWebSocketヘッダーの予約済みビットのいずれかをフレームごとの属性として使用します。
A client that receives a response accepting a PMCE extension negotiation offer together with such an extension MUST _Fail the WebSocket Connection_.
PMCE拡張ネゴシエーションを受け入れる応答を受信したクライアントは、そのような拡張とともに、_WebSocket接続に失敗する必要があります_。
A server declining all offered PMCEs MUST NOT include any element with PMCE names. If a server responds with no PMCE element in the "Sec-WebSocket-Extensions" header, both endpoints proceed without per-message compression once _the WebSocket Connection is established_.
提供されるすべてのPMCEを拒否するサーバーは、PMCE名を持つ要素を含めてはなりません。サーバーが "Sec-WebSocket-Extensions"ヘッダーのPMCE要素で応答しない場合、_WebSocket接続が確立されると、両方のエンドポイントはメッセージごとの圧縮なしで続行します。
If a server gives an invalid response, such as accepting a PMCE that the client did not offer, the client MUST _Fail the WebSocket Connection_.
クライアントが提供していないPMCEを受け入れるなど、サーバーが無効な応答を返した場合、クライアントは_WebSocket接続に失敗する必要があります_。
If a server responds with a valid PMCE element in the "Sec-WebSocket-Extensions" header and _the WebSocket Connection is established_, both endpoints MUST use the algorithm described in Section 6 and the message payload transformation (compressing and decompressing) procedure of the PMCE configured with the "agreed parameters" returned by the server to exchange messages.
サーバーが「Sec-WebSocket-Extensions」ヘッダーの有効なPMCE要素で応答し、_WebSocket接続が確立されている場合、両方のエンドポイントは、セクション6で説明されているアルゴリズムと、PMCEのメッセージペイロード変換（圧縮および解凍）手順を使用する必要があります。メッセージを交換するためにサーバーから返された「合意されたパラメーター」で構成されます。
This section describes a general negotiation flow. How to handle parameters in detail must be specified in the document specifying the PMCE.
このセクションでは、一般的な交渉フローについて説明します。 PMCEを指定するドキュメントでは、パラメータの詳細な処理方法を指定する必要があります。
A client makes an offer including parameters identifying the following:
クライアントは、以下を識別するパラメーターを含むオファーを行います。
o Hints about how the client is planning to compress data
o クライアントがデータを圧縮する方法についてのヒント
o Requests about how the server compresses data
o サーバーがデータを圧縮する方法に関する要求
o Limitations concerning the client's compression functionality
o クライアントの圧縮機能に関する制限
The peer server makes a determination of its behavior based on these parameters. If the server can and wants to proceed with this PMCE enabled, the server responds to the client with parameters identifying the following:
ピアサーバーは、これらのパラメーターに基づいてその動作を決定します。サーバーがこのPMCEを有効にして続行することができ、続行したい場合、サーバーは次のものを識別するパラメーターでクライアントに応答します。
o Requests about how the client compresses data
o クライアントがデータを圧縮する方法に関する要求
o How the server will compress data
o サーバーがデータを圧縮する方法
Based on these parameters received from the server, the client determines its behavior and if it can and wants to proceed with this PMCE enabled. Otherwise, the client starts the closing handshake with close code 1010.
サーバーから受信したこれらのパラメーターに基づいて、クライアントはその動作を決定し、このPMCEを有効にして続行できるかどうか、および続行したいかどうかを決定します。それ以外の場合、クライアントは終了コード1010で終了ハンドシェイクを開始します。
The following are example values for the "Sec-WebSocket-Extensions" header offering PMCEs; permessage-foo and permessage-bar in the examples are hypothetical extension names of PMCEs for the compression algorithm foo and bar.
以下は、PMCEを提供する「Sec-WebSocket-Extensions」ヘッダーの値の例です。例のpermessage-fooおよびpermessage-barは、圧縮アルゴリズムfooおよびbarのPMCEの架空の拡張名です。
o Offer the permessage-foo.
o permessage-fooを提供します。
permessage-foo
permessage-foo
o Offer the permessage-foo with a parameter x with a value of 10.
o 値10のパラメーターxを使用してpermessage-fooを提供します。
permessage-foo; x=10
permessage-foo; x = 10
The value may be quoted.
値は引用することができます。
permessage-foo; x="10"
permessage-foo; x = "10"
o Offer the permessage-foo as first choice and the permessage-bar as a fallback plan.
o 最初の選択肢としてpermessage-fooを、フォールバック計画としてpermessage-barを提供します。
permessage-foo, permessage-bar
permessage-foo、permessage-bar
o Offer the permessage-foo with a parameter use_y, which enables a feature y as first choice, and the permessage-foo without the use_y parameter as a fallback plan.
o 最初の選択肢として機能yを有効にするパラメータuse_yを使用してpermessage-fooを提供し、代替プランとしてuse_yパラメータを使用しないでpermessage-fooを提供します。
permessage-foo; use_y, permessage-foo
permessage-foo; use_y、permessage-foo
PMCEs operate only on data messages.
PMCEはデータメッセージでのみ動作します。
This document allocates the RSV1 bit of the WebSocket header for PMCEs and calls the bit the "Per-Message Compressed" bit. On a WebSocket connection where a PMCE is in use, this bit indicates whether a message is compressed or not.
このドキュメントでは、PMCEにWebSocketヘッダーのRSV1ビットを割り当て、そのビットを「メッセージごとの圧縮」ビットと呼びます。 PMCEが使用されているWebSocket接続では、このビットはメッセージが圧縮されているかどうかを示します。
A message with the "Per-Message Compressed" bit set on the first fragment of the message is called a "compressed message". Frames of a compressed message have compressed data in the payload data portion. An endpoint receiving a compressed message decompresses the concatenation of the compressed data of the frames of the message by following the decompression procedure specified by the PMCE in use. The endpoint uses the bytes corresponding to the application data portion in this decompressed data for the _A WebSocket Message Has Been Received_ event instead of the received data as is.
メッセージの最初のフラグメントに「メッセージごとの圧縮」ビットが設定されたメッセージは、「圧縮メッセージ」と呼ばれます。圧縮メッセージのフレームでは、ペイロードデータ部分に圧縮データが含まれています。圧縮されたメッセージを受信するエンドポイントは、使用中のPMCEによって指定された解凍手順に従って、メッセージのフレームの圧縮データの連結を解凍します。エンドポイントは、この解凍されたデータのアプリケーションデータ部分に対応するバイトを、受信したデータの代わりに、_A WebSocketメッセージが受信されました_イベントに使用します。
A message with the "Per-Message Compressed" bit unset on the first fragment of the message is called an "uncompressed message". Frames of an uncompressed message have uncompressed original data as is in the payload data portion. An endpoint receiving an uncompressed message uses the concatenation of the application data portion of the frames of the message as is for the _A WebSocket Message Has Been Received_ event.
メッセージの最初のフラグメントで「メッセージごとの圧縮」ビットが設定されていないメッセージは、「非圧縮メッセージ」と呼ばれます。非圧縮メッセージのフレームには、ペイロードデータ部分にある非圧縮の元のデータがあります。圧縮されていないメッセージを受信するエンドポイントは、_A WebSocketメッセージが受信されました_イベントの場合と同様に、メッセージのフレームのアプリケーションデータ部分の連結を使用します。
An endpoint MUST use the following algorithm to send a message in the form of a compressed message.
エンドポイントは、次のアルゴリズムを使用して、圧縮されたメッセージの形式でメッセージを送信する必要があります。
1. Compress the message payload of the original message by following the compression procedure of the PMCE. The original message may be input from the application layer or output of another WebSocket extension, depending on which extensions were negotiated.
1. PMCEの圧縮手順に従って、元のメッセージのメッセージペイロードを圧縮します。元のメッセージは、ネゴシエートされた拡張機能に応じて、アプリケーション層からの入力または別のWebSocket拡張機能の出力である可能性があります。
2. Process the compressed data as follows:
2. 次のように圧縮データを処理します。
* If this PMCE is the last extension to process outgoing messages, build frame(s) using the compressed data instead of the original data for the message payload, set the "Per-Message Compressed" bit of the first frame, and then send the frame(s) as described in Section 6.1 of [RFC6455].
* このPMCEが送信メッセージを処理する最後の拡張機能である場合、メッセージペイロードの元のデータの代わりに圧縮データを使用してフレームを構築し、最初のフレームの「メッセージごとの圧縮」ビットを設定して、フレームを送信します。 （s）[RFC6455]のセクション6.1に記載。
* Otherwise, pass the transformed message payload and modified header values, including the "Per-Message Compressed" bit value set to 1, to the next extension after the PMCE. If the extension expects frames for input, build a frame for the message and pass it.
* それ以外の場合は、変換されたメッセージペイロードと、「メッセージごとの圧縮」ビット値が1に設定された変更済みヘッダー値を、PMCEの次の拡張に渡します。拡張機能が入力用のフレームを想定している場合は、メッセージ用のフレームを作成して渡します。
An endpoint MUST use the following algorithm to send a message in the form of an uncompressed message.
エンドポイントは、次のアルゴリズムを使用して、非圧縮メッセージの形式でメッセージを送信する必要があります。
1. Process the original data as follows:
1. 次のように元のデータを処理します。
* If this PMCE is the last extension to process outgoing messages, build frame(s) using the original data for the payload data portion as is, unset the "Per-Message Compressed" bit of the first frame, and then send the frame(s) as described in Section 6.1 of [RFC6455].
* このPMCEが発信メッセージを処理する最後の拡張機能である場合は、ペイロードデータ部分の元のデータをそのまま使用してフレームを作成し、最初のフレームの「メッセージごとの圧縮」ビットの設定を解除してから、フレームを送信します）[RFC6455]のセクション6.1に記載されています。
* Otherwise, pass the message payload and header values to the next extension after the PMCE as is. If the extension expects frames for input, build a frame for the message and pass it.
* それ以外の場合は、メッセージのペイロードとヘッダーの値をそのままPMCEの後にある次の拡張機能に渡します。拡張機能が入力用のフレームを想定している場合は、メッセージ用のフレームを作成して渡します。
An endpoint MUST NOT set the "Per-Message Compressed" bit of control frames and non-first fragments of a data message. An endpoint receiving such a frame MUST _Fail the WebSocket Connection_.
エンドポイントは、制御フレームの「メッセージごとの圧縮」ビットとデータメッセージの非最初のフラグメントを設定してはなりません（MUST NOT）。このようなフレームを受信するエンドポイントは、_WebSocket接続に失敗する必要があります_。
PMCEs do not change the opcode field. The opcode of the first frame of a compressed message indicates the opcode of the original message.
PMCEはopcodeフィールドを変更しません。圧縮メッセージの最初のフレームのオペコードは、元のメッセージのオペコードを示します。
The payload data portion in frames generated by a PMCE is not subject to the constraints for the original data type. For example, the concatenation of the output data corresponding to the application data portion of frames of a compressed text message is not required to be valid UTF-8. At the receiver, the payload data portion after decompression is subject to the constraints for the original data type again.
PMCEによって生成されたフレームのペイロードデータ部分は、元のデータ型の制約を受けません。たとえば、圧縮されたテキストメッセージのフレームのアプリケーションデータ部分に対応する出力データの連結は、有効なUTF-8である必要はありません。受信側では、圧縮解除後のペイロードデータ部分に、元のデータタイプの制約が再度適用されます。
An endpoint MUST use the following algorithm to receive a message in the form of a compressed message.
エンドポイントは、次のアルゴリズムを使用して、圧縮メッセージの形式でメッセージを受信する必要があります。
1. Concatenate the payload data portion of the received frames of the compressed message. The received frames may be direct input from the underlying transport or output of another WebSocket extension, depending on which extensions were negotiated.
1. 圧縮メッセージの受信フレームのペイロードデータ部分を連結します。受信したフレームは、ネゴシエートされた拡張機能に応じて、基になるトランスポートからの直接入力または別のWebSocket拡張機能の出力である可能性があります。
2. Decompress the concatenation by following the decompression procedure of the PMCE.
2. PMCEの解凍手順に従って、連結を解凍します。
3. Process the decompressed message as follows:
3. 解凍されたメッセージを次のように処理します。
* If this is the last extension to process incoming messages, deliver the _A WebSocket Message Has Been Received_ event to the application layer with the decompressed message payload and header values, including the "Per-Message Compressed" bit unset to 0.
* これが着信メッセージを処理する最後の拡張機能である場合は、「メッセージごとの圧縮」ビットが0に設定されていないことを含む、圧縮解除されたメッセージペイロードとヘッダー値を使用して、_A WebSocketメッセージが受信されました_イベントをアプリケーションレイヤーに配信します。
* Otherwise, pass the decompressed message payload and header values, including the "Per-Message Compressed" bit unset to 0, to the extension preceding the PMCE. If the extension expects frames for input, build a frame for the message and pass it.
* それ以外の場合、0に設定されていない「メッセージごとの圧縮」ビットを含む、解凍されたメッセージペイロードとヘッダー値を、PMCEの前の拡張に渡します。拡張機能が入力用のフレームを想定している場合は、メッセージ用のフレームを作成して渡します。
An endpoint MUST use the following algorithm to receive a message in the form of an uncompressed message.
エンドポイントは、次のアルゴリズムを使用して、非圧縮メッセージの形式でメッセージを受信する必要があります。
1. Process the received message as follows:
1. 受信したメッセージを次のように処理します。
* If this PMCE is the last extension to process incoming messages, deliver the _A WebSocket Message Has Been Received_ event to the application layer with the received message payload and header values as is.
* このPMCEが着信メッセージを処理する最後の拡張機能である場合は、_A WebSocketメッセージが受信されました_イベントを、受信したメッセージペイロードとヘッダー値をそのままにして、アプリケーションレイヤーに配信します。
* Otherwise, pass the message payload and header values to the extension preceding the PMCE as is. If the extension expects frames for input, build a frame for the message and pass it.
* それ以外の場合は、メッセージのペイロードとヘッダーの値をそのままPMCEの前の拡張に渡します。拡張機能が入力用のフレームを想定している場合は、メッセージ用のフレームを作成して渡します。
This section defines a specific PMCE called "permessage-deflate". It compresses the payload of a message using the DEFLATE algorithm [RFC1951] and uses the byte boundary alignment method introduced in [RFC1979].
このセクションでは、「permessage-deflate」と呼ばれる特定のPMCEを定義します。 DEFLATEアルゴリズム[RFC1951]を使用してメッセージのペイロードを圧縮し、[RFC1979]で導入されたバイト境界整列方法を使用します。
This section uses the term "byte" with the same meaning as used in [RFC1951], i.e., 8 bits stored or transmitted as a unit (same as an octet).
このセクションでは、[RFC1951]で使用されているのと同じ意味の「バイト」という用語を使用します。つまり、8ビットを1つの単位として格納または送信します（オクテットと同じ）。
The registered extension name for this extension is "permessage-deflate".
この拡張の登録済み拡張名は「permessage-deflate」です。
Four extension parameters are defined for "permessage-deflate" to help endpoints manage per-connection resource usage.
「permessage-deflate」に対して4つの拡張パラメーターが定義され、エンドポイントが接続ごとのリソース使用量を管理するのに役立ちます。
o "server_no_context_takeover"
o 「server_no_context_takeover」
o "client_no_context_takeover"
o 「client_no_context_takeover」
o "server_max_window_bits"
o 「server_max_window_bits」
o "client_max_window_bits"
o 「client_max_window_bits」
These parameters enable two methods (no_context_takeover and max_window_bits) of constraining memory usage that may be applied independently to either direction of WebSocket traffic. The extension parameters with the "client_" prefix are used by the client to configure its compressor and by the server to configure its decompressor. The extension parameters with the "server_" prefix are used by the server to configure its compressor and by the client to configure its decompressor. All four parameters are defined for both a client's extension negotiation offer and a server's extension negotiation response.
これらのパラメーターは、WebSocketトラフィックのいずれかの方向に個別に適用できるメモリ使用量を制限する2つのメソッド（no_context_takeoverおよびmax_window_bits）を有効にします。 「client_」プレフィックスが付いた拡張パラメーターは、クライアントがコンプレッサーを構成するために使用し、サーバーがコンプレッサーを構成するために使用されます。 「server_」接頭辞が付いた拡張パラメータは、サーバーがコンプレッサを構成するために使用し、クライアントがデコンプレッサを構成するために使用されます。 4つのパラメーターはすべて、クライアントの拡張ネゴシエーションオファーとサーバーの拡張ネゴシエーション応答の両方に対して定義されます。
A server MUST decline an extension negotiation offer for this extension if any of the following conditions are met:
次の条件のいずれかが満たされた場合、サーバーはこの拡張の拡張交渉提案を拒否する必要があります。
o The negotiation offer contains an extension parameter not defined for use in an offer.
o 交渉提案には、提案で使用するために定義されていない拡張パラメーターが含まれています。
o The negotiation offer contains an extension parameter with an invalid value.
o 交渉提案に無効な値の拡張パラメーターが含まれています。
o The negotiation offer contains multiple extension parameters with the same name.
o 交渉オファーには、同じ名前の複数の拡張パラメーターが含まれています。
o The server doesn't support the offered configuration.
o サーバーは提供された構成をサポートしていません。
A client MUST _Fail the WebSocket Connection_ if the peer server accepted an extension negotiation offer for this extension with an extension negotiation response meeting any of the following conditions: o The negotiation response contains an extension parameter not defined for use in a response.
ピアサーバーが次の条件のいずれかを満たす拡張ネゴシエーション応答でこの拡張の拡張ネゴシエーションオファーを受け入れた場合、クライアントは_WebSocket接続に失敗する必要があります。
o The negotiation response contains an extension parameter with an invalid value.
o ネゴシエーション応答に無効な値の拡張パラメーターが含まれています。
o The negotiation response contains multiple extension parameters with the same name.
o ネゴシエーション応答には、同じ名前の複数の拡張パラメーターが含まれています。
o The client does not support the configuration that the response represents.
o クライアントは、応答が表す構成をサポートしていません。
The term "LZ77 sliding window" [LZ77] used in this section means the buffer used by the DEFLATE algorithm to store recently processed input. The DEFLATE compression algorithm searches the buffer for a match with the following input.
このセクションで使用される「LZ77スライディングウィンドウ」[LZ77]という用語は、最近処理された入力を格納するためにDEFLATEアルゴリズムによって使用されるバッファを意味します。 DEFLATE圧縮アルゴリズムは、次の入力との一致がないかバッファを検索します。
The term "use context takeover" used in this section means that the same LZ77 sliding window used by the endpoint to build frames of the previous sent message is reused to build frames of the next message to be sent.
このセクションで使用する「コンテキストテイクオーバーを使用する」という用語は、エンドポイントが以前に送信したメッセージのフレームを構築するために使用した同じLZ77スライディングウィンドウを再利用して、次に送信するメッセージのフレームを構築することを意味します。
A client MAY include the "server_no_context_takeover" extension parameter in an extension negotiation offer. This extension parameter has no value. By including this extension parameter in an extension negotiation offer, a client prevents the peer server from using context takeover. If the peer server doesn't use context takeover, the client doesn't need to reserve memory to retain the LZ77 sliding window between messages.
クライアントは、「server_no_context_takeover」拡張パラメーターを拡張交渉オファーに含めることができます（MAY）。この拡張パラメータには値がありません。この拡張パラメーターを拡張ネゴシエーションオファーに含めることにより、クライアントはピアサーバーがコンテキストテイクオーバーを使用するのを防ぎます。ピアサーバーがコンテキストテイクオーバーを使用しない場合、クライアントは、メッセージ間のLZ77スライディングウィンドウを保持するためにメモリを予約する必要はありません。
Absence of this extension parameter in an extension negotiation offer indicates that the client can decompress a message that the server built using context takeover.
拡張ネゴシエーションオファーにこの拡張パラメータがないことは、クライアントがコンテキストテークオーバーを使用して構築したメッセージを解凍できることを示しています。
A server accepts an extension negotiation offer that includes the "server_no_context_takeover" extension parameter by including the "server_no_context_takeover" extension parameter in the corresponding extension negotiation response to send back to the client. The "server_no_context_takeover" extension parameter in an extension negotiation response has no value.
サーバーは、対応する拡張ネゴシエーション応答に「server_no_context_takeover」拡張パラメーターを含めることにより、「server_no_context_takeover」拡張パラメーターを含む拡張ネゴシエーションオファーを受け入れ、クライアントに送り返します。拡張交渉応答の「server_no_context_takeover」拡張パラメーターには値がありません。
It is RECOMMENDED that a server supports the "server_no_context_takeover" extension parameter in an extension negotiation offer.
サーバーが拡張ネゴシエーションのオファーで「server_no_context_takeover」拡張パラメーターをサポートすることをお勧めします。
A server MAY include the "server_no_context_takeover" extension parameter in an extension negotiation response even if the extension negotiation offer being accepted by the extension negotiation response didn't include the "server_no_context_takeover" extension parameter.
拡張交渉応答によって受け入れられている拡張交渉提案に「server_no_context_takeover」拡張パラメータが含まれていなかった場合でも、サーバは、拡張交渉応答に「server_no_context_takeover」拡張パラメータを含めることができます。
A client MAY include the "client_no_context_takeover" extension parameter in an extension negotiation offer. This extension parameter has no value. By including this extension parameter in an extension negotiation offer, a client informs the peer server of a hint that even if the server doesn't include the "client_no_context_takeover" extension parameter in the corresponding extension negotiation response to the offer, the client is not going to use context takeover.
クライアントは、拡張交渉提供に「client_no_context_takeover」拡張パラメータを含めることができます。この拡張パラメータには値がありません。この拡張パラメーターを拡張ネゴシエーションオファーに含めることにより、クライアントはピアサーバーにヒントを通知します。サーバーがオファーの対応する拡張ネゴシエーション応答に「client_no_context_takeover」拡張パラメーターを含めなくても、クライアントはコンテキストテイクオーバーを使用する。
A server MAY include the "client_no_context_takeover" extension parameter in an extension negotiation response. If the received extension negotiation offer includes the "client_no_context_takeover" extension parameter, the server may either ignore the parameter or use the parameter to avoid taking over the LZ77 sliding window unnecessarily by including the "client_no_context_takeover" extension parameter in the corresponding extension negotiation response to the offer. The "client_no_context_takeover" extension parameter in an extension negotiation response has no value. By including the "client_no_context_takeover" extension parameter in an extension negotiation response, a server prevents the peer client from using context takeover. This reduces the amount of memory that the server has to reserve for the connection.
サーバーは、拡張交渉応答に「client_no_context_takeover」拡張パラメーターを含めることができます。受信した拡張交渉オファーに「client_no_context_takeover」拡張パラメーターが含まれている場合、サーバーはパラメーターを無視するか、パラメーターを使用して、「client_no_context_takeover」拡張パラメーターを提供。拡張交渉応答の「client_no_context_takeover」拡張パラメータには値がありません。 "client_no_context_takeover"拡張パラメーターを拡張ネゴシエーション応答に含めることにより、サーバーはピアクライアントがコンテキストテイクオーバーを使用するのを防ぎます。これにより、サーバーが接続用に予約する必要のあるメモリの量が削減されます。
Absence of this extension parameter in an extension negotiation response indicates that the server can decompress messages built by the client using context takeover.
拡張ネゴシエーション応答にこの拡張パラメータがないことは、サーバーがコンテキストテイクオーバーを使用してクライアントによって構築されたメッセージを解凍できることを示しています。
A client MUST support the "client_no_context_takeover" extension parameter in an extension negotiation response.
クライアントは、拡張ネゴシエーション応答で「client_no_context_takeover」拡張パラメータをサポートする必要があります。
A client MAY include the "server_max_window_bits" extension parameter in an extension negotiation offer. This parameter has a decimal integer value without leading zeroes between 8 to 15, inclusive, indicating the base-2 logarithm of the LZ77 sliding window size, and MUST conform to the ABNF below.
クライアントは、拡張交渉オファーに「server_max_window_bits」拡張パラメータを含めることができます。このパラメーターは、LZ77スライディングウィンドウサイズの2を底とする対数を示す8から15までの先行ゼロなしの10進整数値を持ち、以下のABNFに準拠する必要があります。
server-max-window-bits = 1*DIGIT
By including this parameter in an extension negotiation offer, a client limits the LZ77 sliding window size that the server will use to compress messages. If the peer server uses a small LZ77 sliding window to compress messages, the client can reduce the memory needed for the LZ77 sliding window.
このパラメータを拡張ネゴシエーションオファーに含めることにより、クライアントは、サーバーがメッセージの圧縮に使用するLZ77スライディングウィンドウサイズを制限します。ピアサーバーが小さなLZ77スライディングウィンドウを使用してメッセージを圧縮する場合、クライアントはLZ77スライディングウィンドウに必要なメモリを減らすことができます。
A server declines an extension negotiation offer with this parameter if the server doesn't support it.
サーバーがサポートしていない場合、サーバーはこのパラメーターを使用した拡張ネゴシエーションの提案を拒否します。
Absence of this parameter in an extension negotiation offer indicates that the client can receive messages compressed using an LZ77 sliding window of up to 32,768 bytes.
拡張ネゴシエーションオファーにこのパラメータがないことは、クライアントが最大32,768バイトのLZ77スライディングウィンドウを使用して圧縮されたメッセージを受信できることを示しています。
A server accepts an extension negotiation offer with this parameter by including the "server_max_window_bits" extension parameter in the extension negotiation response to send back to the client with the same or smaller value as the offer. The "server_max_window_bits" extension parameter in an extension negotiation response has a decimal integer value without leading zeroes between 8 to 15, inclusive, indicating the base-2 logarithm of the LZ77 sliding window size, and MUST conform to the ABNF below.
サーバーは、エクステンションネゴシエーション応答に「server_max_window_bits」拡張パラメーターを含めることにより、このパラメーターを使用してエクステンションネゴシエーションオファーを受け入れ、オファーと同じかそれよりも小さい値でクライアントに送り返します。拡張ネゴシエーション応答の「server_max_window_bits」拡張パラメーターには、8から15までの先行ゼロなしの10進整数値があり、LZ77スライディングウィンドウサイズの2を底とする対数を示し、以下のABNFに準拠する必要があります。
server-max-window-bits = 1*DIGIT
A server MAY include the "server_max_window_bits" extension parameter in an extension negotiation response even if the extension negotiation offer being accepted by the response didn't include the "server_max_window_bits" extension parameter.
応答によって受け入れられる拡張交渉オファーに「server_max_window_bits」拡張パラメーターが含まれていなくても、サーバーは拡張交渉応答に「server_max_window_bits」拡張パラメーターを含めることができます。
A client MAY include the "client_max_window_bits" extension parameter in an extension negotiation offer. This parameter has no value or a decimal integer value without leading zeroes between 8 to 15 inclusive indicating the base-2 logarithm of the LZ77 sliding window size. If a value is specified for this parameter, the value MUST conform to the ABNF below.
クライアントは、拡張交渉提供に「client_max_window_bits」拡張パラメータを含めることができます。このパラメーターには、LZ77スライディングウィンドウサイズの2を底とする対数を示す8〜15の先行ゼロがない値または10進整数値はありません。このパラメーターに値が指定されている場合、値は以下のABNFに準拠する必要があります。
client-max-window-bits = 1*DIGIT
By including this parameter in an offer, a client informs the peer server that the client supports the "client_max_window_bits" extension parameter in an extension negotiation response and, optionally, a hint by attaching a value to the parameter. If the "client_max_window_bits" extension parameter in an extension negotiation offer has a value, the parameter also informs the peer server of a hint that even if the server doesn't include the "client_max_window_bits" extension parameter in the corresponding extension negotiation response with a value greater than the one in the extension negotiation offer or if the server doesn't include the extension parameter at all, the client is not going to use an LZ77 sliding window size greater than the size specified by the value in the extension negotiation offer to compress messages.
このパラメーターをオファーに含めることにより、クライアントはピアサーバーに、クライアントが拡張ネゴシエーション応答で「client_max_window_bits」拡張パラメーターをサポートすることを通知し、オプションで、パラメーターに値を付加することによってヒントを提供します。拡張ネゴシエーションオファーの「client_max_window_bits」拡張パラメーターに値がある場合、このパラメーターは、サーバーが対応する拡張ネゴシエーション応答に「client_max_window_bits」拡張パラメーターを値に含めない場合でも、ヒントをピアサーバーに通知します拡張ネゴシエーションオファーのサイズよりも大きい場合、またはサーバーに拡張パラメータがまったく含まれていない場合、クライアントは、拡張ネゴシエーションオファーの値で指定されたサイズより大きいLZ77スライディングウィンドウサイズを使用して圧縮しません。メッセージ。
If a received extension negotiation offer has the "client_max_window_bits" extension parameter, the server MAY include the "client_max_window_bits" extension parameter in the corresponding extension negotiation response to the offer. If the "client_max_window_bits" extension parameter in a received extension negotiation offer has a value, the server may either ignore this value or use this value to avoid allocating an unnecessarily big LZ77 sliding window by including the "client_max_window_bits" extension parameter in the corresponding extension negotiation response to the offer with a value equal to or smaller than the received value. The "client_max_window_bits" extension parameter in an extension negotiation response has a decimal integer value without leading zeroes between 8 to 15 inclusive indicating the base-2 logarithm of the LZ77 sliding window size and MUST conform to the ABNF below.
受信した拡張交渉オファーに「client_max_window_bits」拡張パラメーターがある場合、サーバーはオファーに対応する拡張交渉応答に「client_max_window_bits」拡張パラメーターを含めることができます（MAY）。受信した拡張ネゴシエーションオファーの「client_max_window_bits」拡張パラメーターに値がある場合、サーバーはこの値を無視するか、この値を使用して、対応する拡張ネゴシエーションに「client_max_window_bits」拡張パラメーターを含めることで、不必要に大きなLZ77スライディングウィンドウの割り当てを回避します。受け取った値以下の値を持つオファーへの応答。拡張ネゴシエーション応答の "client_max_window_bits"拡張パラメーターには、8から15までの先行ゼロなしの10進整数値があり、LZ77スライディングウィンドウサイズの2を底とする対数を示し、以下のABNFに準拠する必要があります。
client-max-window-bits = 1*DIGIT
By including this extension parameter in an extension negotiation response, a server limits the LZ77 sliding window size that the client uses to compress messages. This reduces the amount of memory for the decompression context that the server has to reserve for the connection.
この拡張パラメータを拡張ネゴシエーション応答に含めることにより、サーバーは、クライアントがメッセージの圧縮に使用するLZ77スライディングウィンドウサイズを制限します。これにより、サーバーが接続用に予約する必要がある解凍コンテキストのメモリ量が削減されます。
If a received extension negotiation offer doesn't have the "client_max_window_bits" extension parameter, the corresponding extension negotiation response to the offer MUST NOT include the "client_max_window_bits" extension parameter.
受信した拡張ネゴシエーションオファーに「client_max_window_bits」拡張パラメーターがない場合、オファーへの対応する拡張ネゴシエーション応答に「client_max_window_bits」拡張パラメーターを含めてはなりません（MUST NOT）。
Absence of this extension parameter in an extension negotiation response indicates that the server can receive messages compressed using an LZ77 sliding window of up to 32,768 bytes.
拡張ネゴシエーション応答にこの拡張パラメータがないことは、サーバーが最大32,768バイトのLZ77スライディングウィンドウを使用して圧縮されたメッセージを受信できることを示します。
The simplest "Sec-WebSocket-Extensions" header in a client's opening handshake to offer use of the "permessage-deflate" extension looks like this:
「permessage-deflate」拡張の使用を提供するためのクライアントの開始ハンドシェイクの最も単純な「Sec-WebSocket-Extensions」ヘッダーは、次のようになります。
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Extensions：permessage-deflate
Since the "client_max_window_bits" extension parameter is not included in this extension negotiation offer, the server must not accept the offer with an extension negotiation response that includes the "client_max_window_bits" extension parameter. The simplest "Sec-WebSocket-Extensions" header in a server's opening handshake to accept use of the "permessage-deflate" extension is the same:
「client_max_window_bits」拡張パラメーターはこの拡張ネゴシエーションオファーに含まれていないため、サーバーは「client_max_window_bits」拡張パラメーターを含む拡張ネゴシエーション応答でオファーを受け入れてはなりません。 「permessage-deflate」拡張の使用を受け入れるサーバーの開始ハンドシェイクの最も単純な「Sec-WebSocket-Extensions」ヘッダーは同じです。
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Extensions：permessage-deflate
The following extension negotiation offer sent by a client is asking the server to use an LZ77 sliding window with a size of 1,024 bytes or less and declaring that the client supports the "client_max_window_bits" extension parameter in an extension negotiation response.
クライアントから送信された次の拡張ネゴシエーションオファーは、1,024バイト以下のサイズのLZ77スライディングウィンドウを使用するようサーバーに要求し、クライアントが拡張ネゴシエーション応答で "client_max_window_bits"拡張パラメーターをサポートすることを宣言しています。
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits; server_max_window_bits=10
Sec-WebSocket-Extensions：permessage-deflate; client_max_window_bits; server_max_window_bits = 10
This extension negotiation offer might be rejected by the server because the server doesn't support the "server_max_window_bits" extension parameter in an extension negotiation offer. This is fine if the client cannot receive messages compressed using a larger sliding window size, but if the client just prefers using a small window but wants to fall back to the "permessage-deflate" without the "server_max_window_bits" extension parameter, the client can make an offer with the fallback option like this:
サーバーは拡張ネゴシエーションオファーの「server_max_window_bits」拡張パラメーターをサポートしていないため、この拡張ネゴシエーションオファーはサーバーによって拒否される可能性があります。これは、クライアントがより大きなスライディングウィンドウサイズを使用して圧縮されたメッセージを受信できない場合は問題ありませんが、クライアントが小さなウィンドウの使用を好むが、「server_max_window_bits」拡張パラメーターなしで「permessage-deflate」にフォールバックしたい場合、クライアントは次のようなフォールバックオプションでオファーを作成します。
Sec-WebSocket-Extensions:
permessage-deflate;
client_max_window_bits; server_max_window_bits=10,
permessage-deflate;
client_max_window_bits
The server can accept "permessage-deflate" by picking any supported one from the listed offers. To accept the first option, for example, the server may send back a response as follows:
サーバーは、リストされているオファーからサポートされているものを選択することにより、「permessage-deflate」を受け入れることができます。たとえば、最初のオプションを受け入れるには、サーバーは次のように応答を返します。
Sec-WebSocket-Extensions: permessage-deflate; server_max_window_bits=10
Sec-WebSocket-Extensions：permessage-deflate; server_max_window_bits = 10
To accept the second option, for example, the server may send back a response as follows:
たとえば、2番目のオプションを受け入れるには、サーバーは次のように応答を返します。
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Extensions：permessage-deflate
An endpoint uses the following algorithm to compress a message.
エンドポイントは、次のアルゴリズムを使用してメッセージを圧縮します。
1. Compress all the octets of the payload of the message using DEFLATE.
1. DEFLATEを使用して、メッセージのペイロードのすべてのオクテットを圧縮します。
2. If the resulting data does not end with an empty DEFLATE block with no compression (the "BTYPE" bits are set to 00), append an empty DEFLATE block with no compression to the tail end.
2. 結果のデータが圧縮されていない空のDEFLATEブロックで終わっていない場合（「BTYPE」ビットが00に設定されている）、圧縮されていない空のDEFLATEブロックをテールエンドに追加します。
3. Remove 4 octets (that are 0x00 0x00 0xff 0xff) from the tail end. After this step, the last octet of the compressed data contains (possibly part of) the DEFLATE header bits with the "BTYPE" bits set to 00.
3. 末尾から4オクテット（0x00 0x00 0xff 0xff）を削除します。このステップの後、圧縮データの最後のオクテットには、「BTYPE」ビットが00に設定されたDEFLATEヘッダービット（場合によってはその一部）が含まれます。
When using DEFLATE in the first step above:
上記の最初のステップでDEFLATEを使用する場合：
o An endpoint MAY use multiple DEFLATE blocks to compress one message.
o エンドポイントは、1つのメッセージを圧縮するために複数のDEFLATEブロックを使用する場合があります。
o An endpoint MAY use DEFLATE blocks of any type.
o エンドポイントは、あらゆるタイプのDEFLATEブロックを使用できます。
o An endpoint MAY use both DEFLATE blocks with the "BFINAL" bit set to 0 and DEFLATE blocks with the "BFINAL" bit set to 1.
o エンドポイントは、「BFINAL」ビットが0に設定されたDEFLATEブロックと、「BFINAL」ビットが1に設定されたDEFLATEブロックの両方を使用する場合があります。
o When any DEFLATE block with the "BFINAL" bit set to 1 doesn't end at a byte boundary, an endpoint MUST add minimal padding bits of 0 to make it end at a byte boundary. The next DEFLATE block follows the padded data if any.
o 「BFINAL」ビットが1に設定されているDEFLATEブロックがバイト境界で終了しない場合、エンドポイントは、バイト境界で終了するように最小のパディングビット0を追加する必要があります。次のDEFLATEブロックは、パディングされたデータがあればそれに続きます。
An endpoint fragments a compressed message by splitting the result of running this algorithm. Even when only part of the payload is available, a fragment can be built by compressing the available data and choosing the block type appropriately so that the end of the resulting compressed data is aligned at a byte boundary. Note that for non-final fragments, the removal of 0x00 0x00 0xff 0xff MUST NOT be done.
エンドポイントは、このアルゴリズムの実行結果を分割することにより、圧縮されたメッセージを断片化します。ペイロードの一部しか利用できない場合でも、利用可能なデータを圧縮し、ブロックタイプを適切に選択することでフラグメントを構築でき、結果として得られる圧縮データの末尾がバイト境界に揃うようにします。最終でないフラグメントの場合、0x00 0x00 0xff 0xffの削除を行ってはならないことに注意してください。
An endpoint MUST NOT use an LZ77 sliding window longer than 32,768 bytes to compress messages to send.
エンドポイントは、送信するメッセージを圧縮するために32,768バイトを超えるLZ77スライディングウィンドウを使用してはなりません（MUST NOT）。
If the "agreed parameters" contain the "client_no_context_takeover" extension parameter, the client MUST start compressing each new message with an empty LZ77 sliding window. Otherwise, the client MAY take over the LZ77 sliding window used to build the last compressed message. Note that even if the client has included the "client_no_context_takeover" extension parameter in its offer, the client MAY take over the LZ77 sliding window used to build the last compressed message if the "agreed parameters" don't contain the "client_no_context_takeover" extension parameter. The client-to-server "client_no_context_takeover" extension parameter is just a hint for the server to build an extension negotiation response.
「合意されたパラメータ」に「client_no_context_takeover」拡張パラメータが含まれている場合、クライアントは空のLZ77スライディングウィンドウで各新しいメッセージの圧縮を開始する必要があります。それ以外の場合、クライアントは、最後の圧縮メッセージの作成に使用されたLZ77スライディングウィンドウを引き継ぐ場合があります（MAY）。クライアントがオファーに「client_no_context_takeover」拡張パラメーターを含めた場合でも、「合意されたパラメーター」に「client_no_context_takeover」拡張パラメーターが含まれていない場合、クライアントは最後の圧縮メッセージの作成に使用されたLZ77スライディングウィンドウを引き継ぐ場合があります。 。クライアントからサーバーへの「client_no_context_takeover」拡張パラメーターは、サーバーが拡張ネゴシエーション応答を作成するためのヒントにすぎません。
If the "agreed parameters" contain the "server_no_context_takeover" extension parameter, the server MUST start compressing each new message with an empty LZ77 sliding window. Otherwise, the server MAY take over the LZ77 sliding window used to build the last compressed message.
「同意されたパラメータ」に「server_no_context_takeover」拡張パラメータが含まれている場合、サーバーは空のLZ77スライディングウィンドウで各新しいメッセージの圧縮を開始する必要があります。それ以外の場合、サーバーは最後の圧縮メッセージの作成に使用されたLZ77スライディングウィンドウを引き継ぐ場合があります（MAY）。
If the "agreed parameters" contain the "client_max_window_bits" extension parameter with a value of w, the client MUST NOT use an LZ77 sliding window longer than the w-th power of 2 bytes to compress messages to send. Note that even if the client has included in its offer the "client_max_window_bits" extension parameter with a value smaller than one in the "agreed parameters", the client MAY use an LZ77 sliding window with any size to compress messages to send as long as the size conforms to the "agreed parameters". The client-to-server "client_max_window_bits" extension parameter is just a hint for the server to build an extension negotiation response.
「合意されたパラメーター」に値wの「client_max_window_bits」拡張パラメーターが含まれている場合、クライアントは送信するメッセージを圧縮するために、2バイトのw乗より長いLZ77スライディングウィンドウを使用してはなりません。クライアントがそのオファーに「合意されたパラメーター」の1より小さい値の「client_max_window_bits」拡張パラメーターを含めた場合でも、クライアントは、任意のサイズのLZ77スライディングウィンドウを使用して、サイズは「合意されたパラメータ」に準拠しています。クライアントからサーバーへの「client_max_window_bits」拡張パラメーターは、サーバーが拡張ネゴシエーション応答を作成するためのヒントにすぎません。
If the "agreed parameters" contain the "server_max_window_bits" extension parameter with a value of w, the server MUST NOT use an LZ77 sliding window longer than the w-th power of 2 bytes to compress messages to send.
「合意されたパラメーター」にwの値を持つ「server_max_window_bits」拡張パラメーターが含まれている場合、サーバーは送信するメッセージを圧縮するために2バイトのw乗より長いLZ77スライディングウィンドウを使用してはなりません。
An endpoint uses the following algorithm to decompress a message.
エンドポイントは、次のアルゴリズムを使用してメッセージを解凍します。
1. Append 4 octets of 0x00 0x00 0xff 0xff to the tail end of the payload of the message.
1. 0x00 0x00 0xff 0xffの4オクテットをメッセージのペイロードの末尾に追加します。
2. Decompress the resulting data using DEFLATE.
2. 結果のデータをDEFLATEを使用して解凍します。
If the "agreed parameters" contain the "server_no_context_takeover" extension parameter, the client MAY decompress each new message with an empty LZ77 sliding window. Otherwise, the client MUST decompress each new message using the LZ77 sliding window used to process the last compressed message.
「合意されたパラメータ」に「server_no_context_takeover」拡張パラメータが含まれている場合、クライアントは空のLZ77スライディングウィンドウで各新しいメッセージを解凍できます（MAY）。それ以外の場合、クライアントは、最後の圧縮メッセージの処理に使用されるLZ77スライディングウィンドウを使用して、新しいメッセージをそれぞれ解凍する必要があります。
If the "agreed parameters" contain the "client_no_context_takeover" extension parameter, the server MAY decompress each new message with an empty LZ77 sliding window. Otherwise, the server MUST decompress each new message using the LZ77 sliding window used to process the last compressed message. Note that even if the client has included the "client_no_context_takeover" extension parameter in its offer, the server MUST decompress each new message using the LZ77 sliding window used to process the last compressed message if the "agreed parameters" don't contain the "client_no_context_takeover" extension parameter. The client-to-server "client_no_context_takeover" extension parameter is just a hint for the server to build an extension negotiation response.
「合意されたパラメータ」に「client_no_context_takeover」拡張パラメータが含まれている場合、サーバーは空のLZ77スライディングウィンドウで各新しいメッセージを解凍する場合があります（MAY）。それ以外の場合、サーバーは、最後に圧縮されたメッセージの処理に使用されるLZ77スライディングウィンドウを使用して、新しいメッセージをそれぞれ解凍する必要があります。クライアントがそのオファーに「client_no_context_takeover」拡張パラメータを含めた場合でも、「合意されたパラメータ」に「client_no_context_takeover」が含まれていない場合、サーバーは最後の圧縮メッセージの処理に使用されるLZ77スライディングウィンドウを使用して各新しいメッセージを解凍する必要があります。 "拡張パラメータ。クライアントからサーバーへの「client_no_context_takeover」拡張パラメーターは、サーバーが拡張ネゴシエーション応答を作成するためのヒントにすぎません。
If the "agreed parameters" contain the "server_max_window_bits" extension parameter with a value of w, the client MAY reduce the size of its LZ77 sliding window to decompress received messages down to the w-th power of 2 bytes. Otherwise, the client MUST use a 32,768-byte LZ77 sliding window to decompress received messages.
「合意されたパラメーター」に値wの「server_max_window_bits」拡張パラメーターが含まれている場合、クライアントはLZ77スライディングウィンドウのサイズを縮小して、受信したメッセージを2バイトのw乗まで圧縮解除できます（MAY）。それ以外の場合、クライアントは32,768バイトのLZ77スライディングウィンドウを使用して、受信したメッセージを解凍する必要があります。
If the "agreed parameters" contain the "client_max_window_bits" extension parameter with a value of w, the server MAY reduce the size of its LZ77 sliding window to decompress received messages down to the w-th power of 2 bytes. Otherwise, the server MUST use a 32,768-byte LZ77 sliding window to decompress received messages. Note that even if the client has included in its offer the "client_max_window_bits" extension parameter with a value smaller than one in the "agreed parameters", the client MUST use an LZ77 sliding window of a size that conforms the "agreed parameters" to compress messages to send. The client-to-server "client_max_window_bits" extension parameter is just a hint for the server to build an extension negotiation response.
「合意されたパラメーター」に値wの「client_max_window_bits」拡張パラメーターが含まれている場合、サーバーはLZ77スライディングウィンドウのサイズを縮小して、受信したメッセージを2バイトのw乗まで圧縮解除できます（MAY）。それ以外の場合、サーバーは32,768バイトのLZ77スライディングウィンドウを使用して、受信したメッセージを解凍する必要があります。クライアントがそのオファーに、「合意されたパラメーター」の1より小さい値を持つ「client_max_window_bits」拡張パラメーターを含めた場合でも、クライアントは、「合意されたパラメーター」に適合するサイズのLZ77スライディングウィンドウを使用して圧縮する必要があります。送信するメッセージ。クライアントからサーバーへの「client_max_window_bits」拡張パラメーターは、サーバーが拡張ネゴシエーション応答を作成するためのヒントにすぎません。
This section introduces examples of how the "permessage-deflate" extension transforms messages.
このセクションでは、「permessage-deflate」拡張機能がメッセージを変換する方法の例を紹介します。
Suppose that an endpoint sends a text message "Hello". If the endpoint uses one compressed DEFLATE block (compressed with fixed Huffman code and the "BFINAL" bit not set) to compress the message, the endpoint obtains the compressed data to use for the message payload as follows.
エンドポイントが「Hello」というテキストメッセージを送信するとします。エンドポイントが1つの圧縮DEFLATEブロック（固定ハフマンコードで圧縮され、「BFINAL」ビットが設定されていない）を使用してメッセージを圧縮する場合、エンドポイントは次のようにメッセージペイロードに使用する圧縮データを取得します。
The endpoint compresses "Hello" into one compressed DEFLATE block and flushes the resulting data into a byte array using an empty DEFLATE block with no compression:
エンドポイントは "Hello"を1つの圧縮DEFLATEブロックに圧縮し、圧縮されていない空のDEFLATEブロックを使用して、結果のデータをバイト配列にフラッシュします。
0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00 0x00 0x00 0xff 0xff
0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00 0x00 0x00 0xff 0xff
By stripping 0x00 0x00 0xff 0xff from the tail end, the endpoint gets the data to use for the message payload:
末尾から0x00 0x00 0xff 0xffを取り除くことにより、エンドポイントはメッセージペイロードに使用するデータを取得します。
0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00
0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00
Suppose that the endpoint sends this compressed message without fragmentation. The endpoint builds one frame by putting all of the compressed data in the payload data portion of the frame:
エンドポイントがフラグメント化せずにこの圧縮メッセージを送信するとします。エンドポイントは、すべての圧縮データをフレームのペイロードデータ部分に配置することにより、1つのフレームを構築します。
0xc1 0x07 0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00
0xc1 0x07 0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00
The first 2 octets (0xc1 0x07) are the WebSocket frame header (FIN=1, RSV1=1, RSV2=0, RSV3=0, opcode=text, MASK=0, Payload length=7). The following figure shows what value is set in each field of the WebSocket frame header.
最初の2オクテット（0xc1 0x07）はWebSocketフレームヘッダーです（FIN = 1、RSV1 = 1、RSV2 = 0、RSV3 = 0、opcode = text、MASK = 0、ペイロード長= 7）。次の図は、WebSocketフレームヘッダーの各フィールドに設定される値を示しています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-------+-+-------------+
|F|R|R|R| opcode|M| Payload len |
|I|S|S|S| |A| |
|N|V|V|V| |S| |
| |1|2|3| |K| |
+-+-+-+-+-------+-+-------------+
|1|1|0|0| 1 |0| 7 |
+-+-+-+-+-------+-+-------------+
Suppose that the endpoint sends the compressed message with fragmentation. The endpoint splits the compressed data into fragments and builds frames for each fragment. For example, if the fragments are 3 and 4 octets, the first frame is:
エンドポイントが断片化された圧縮メッセージを送信するとします。エンドポイントは圧縮データをフラグメントに分割し、フラグメントごとにフレームを作成します。たとえば、フラグメントが3オクテットと4オクテットの場合、最初のフレームは次のようになります。
0x41 0x03 0xf2 0x48 0xcd
0x41 0x03 0xf2 0x48 0xcd
and the second frame is:
そして2番目のフレームは：
0x80 0x04 0xc9 0xc9 0x07 0x00
0x80 0x04 0xc9 0xc9 0x07 0x00
Note that the RSV1 bit is set only on the first frame.
RSV1ビットは最初のフレームでのみ設定されることに注意してください。
Suppose that a client has sent a message "Hello" as a compressed message and will send the same message "Hello" again as a compressed message.
クライアントがメッセージ "Hello"を圧縮メッセージとして送信し、同じメッセージ "Hello"を圧縮メッセージとして再度送信するとします。
0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00
0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00
The above is the payload of the first message that the client has sent. If the "agreed parameters" contain the "client_no_context_takeover" extension parameter, the client compresses the payload of the next message into the same bytes (if the client uses the same "BTYPE" value and "BFINAL" value). So, the payload of the second message will be:
上記は、クライアントが送信した最初のメッセージのペイロードです。 「合意されたパラメーター」に「client_no_context_takeover」拡張パラメーターが含まれている場合、クライアントは次のメッセージのペイロードを同じバイトに圧縮します（クライアントが同じ「BTYPE」値と「BFINAL」値を使用する場合）。したがって、2番目のメッセージのペイロードは次のようになります。
0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00
0xf2 0x48 0xcd 0xc9 0xc9 0x07 0x00
If the "agreed parameters" did not contain the "client_no_context_takeover" extension parameter, the client can compress the payload of the next message into fewer bytes by referencing the history in the LZ77 sliding window. So, the payload of the second message will be:
「合意されたパラメータ」に「client_no_context_takeover」拡張パラメータが含まれていない場合、クライアントはLZ77スライディングウィンドウの履歴を参照することにより、次のメッセージのペイロードをより少ないバイトに圧縮できます。したがって、2番目のメッセージのペイロードは次のようになります。
0xf2 0x00 0x11 0x00 0x00
0xf2 0x00 0x11 0x00 0x00
So, 2 bytes are saved in total.
したがって、合計で2バイトが節約されます。
Note that even if some uncompressed messages (with the RSV1 bit unset) are inserted between the two "Hello" messages, they don't affect the LZ77 sliding window.
2つの「Hello」メッセージの間に非圧縮メッセージ（RSV1ビットが設定されていない）が挿入されていても、LZ77スライディングウィンドウには影響しないことに注意してください。
A DEFLATE block with no compression may be used.
圧縮されていないDEFLATEブロックを使用できます。
0xc1 0x0b 0x00 0x05 0x00 0xfa 0xff 0x48 0x65 0x6c 0x6c 0x6f 0x00
0xc1 0x0b 0x00 0x05 0x00 0xfa 0xff 0x48 0x65 0x6c 0x6c 0x6f 0x00
This is a frame constituting a text message "Hello" built using a DEFLATE block with no compression. The first 2 octets (0xc1 0x0b) are the WebSocket frame header (FIN=1, RSV1=1, RSV2=0, RSV3=0, opcode=text, MASK=0, Payload length=7). Note that the RSV1 bit is set for this message (only on the first fragment if the message is fragmented) because the RSV1 bit is set when DEFLATE is applied to the message, including the case when only DEFLATE blocks with no compression are used. The 3rd to 13th octets consist of the payload data containing "Hello" compressed using a DEFLATE block with no compression.
これは、圧縮されていないDEFLATEブロックを使用して作成されたテキストメッセージ「Hello」を構成するフレームです。最初の2オクテット（0xc1 0x0b）はWebSocketフレームヘッダーです（FIN = 1、RSV1 = 1、RSV2 = 0、RSV3 = 0、opcode = text、MASK = 0、ペイロード長= 7）。 RSV1ビットが設定されているのは、メッセージにDEFLATEが適用されたときにRSV1ビットが設定されるためです（メッセージが断片化されている場合は、最初のフラグメントのみ）。 3〜13オクテットは、圧縮されていないDEFLATEブロックを使用して圧縮された「Hello」を含むペイロードデータで構成されます。
On platforms on which the flush method using an empty DEFLATE block with no compression is not available, implementors can choose to flush data using DEFLATE blocks with "BFINAL" set to 1.
圧縮なしで空のDEFLATEブロックを使用するフラッシュメソッドが利用できないプラットフォームでは、実装者は、「BFINAL」が1に設定されたDEFLATEブロックを使用してデータをフラッシュすることを選択できます。
0xf3 0x48 0xcd 0xc9 0xc9 0x07 0x00 0x00
0xf3 0x48 0xcd 0xc9 0xc9 0x07 0x00 0x00
This is the payload of a message containing "Hello" compressed using a DEFLATE block with "BFINAL" set to 1. The first 7 octets constitute a DEFLATE block with "BFINAL" set to 1 and "BTYPE" set to 01 containing "Hello". The last 1 octet (0x00) contains the header bits with "BFINAL" set to 0 and "BTYPE" set to 00, and 5 padding bits of 0. This octet is necessary to allow the payload to be decompressed in the same manner as messages flushed using DEFLATE blocks with "BFINAL" unset.
これは、「BFINAL」が1に設定されたDEFLATEブロックを使用して圧縮された「Hello」を含むメッセージのペイロードです。最初の7オクテットは、「BFINAL」が1に設定され、「BTYPE」が「Hello」を含む01に設定されたDEFLATEブロックを構成します。 。最後の1オクテット（0x00）には、「BFINAL」が0に設定され、「BTYPE」が00に設定されたヘッダービットと、0の5つのパディングビットが含まれています。このオクテットは、メッセージと同じ方法でペイロードを圧縮解除するために必要です。 「BFINAL」が設定されていないDEFLATEブロックを使用してフラッシュされました。
Two or more DEFLATE blocks may be used in one message.
1つのメッセージで2つ以上のDEFLATEブロックを使用できます。
0xf2 0x48 0x05 0x00 0x00 0x00 0xff 0xff 0xca 0xc9 0xc9 0x07 0x00
0xf2 0x48 0x05 0x00 0x00 0x00 0xff 0xff 0xca 0xc9 0xc9 0x07 0x00
The first 3 octets (0xf2 0x48 0x05) and the least significant two bits of the 4th octet (0x00) constitute one DEFLATE block with "BFINAL" set to 0 and "BTYPE" set to 01 containing "He". The rest of the 4th octet contains the header bits with "BFINAL" set to 0 and "BTYPE" set to 00, and the 3 padding bits of 0. Together with the following 4 octets (0x00 0x00 0xff 0xff), the header bits constitute an empty DEFLATE block with no compression. A DEFLATE block containing "llo" follows the empty DEFLATE block.
最初の3オクテット（0xf2 0x48 0x05）と4番目のオクテットの最下位2ビット（0x00）は、「BFINAL」を0に設定し、「BTYPE」を「He」を含む01に設定した1つのDEFLATEブロックを構成します。 4番目のオクテットの残りには、「BFINAL」が0に設定され、「BTYPE」が00に設定されたヘッダービットと、3つのパディングビット0が含まれます。次の4つのオクテット（0x00 0x00 0xff 0xff）とともに、ヘッダービットは圧縮されていない空のDEFLATEブロック。 「llo」を含むDEFLATEブロックは、空のDEFLATEブロックの後に続きます。
Suppose that an endpoint is sending data of unknown size. The endpoint may encounter the end-of-data signal from the data source when its buffer for uncompressed data is empty. In such a case, the endpoint just needs to send the last fragment with the FIN bit set to 1 and the payload set to the DEFLATE block(s), which contains 0 bytes of data. If the compression library being used doesn't generate any data when its buffer is empty, an empty uncompressed DEFLATE block can be built and used for this purpose as follows:
エンドポイントが不明なサイズのデータを送信しているとします。エンドポイントは、非圧縮データ用のバッファが空のときに、データソースからのデータの終わり信号に遭遇する可能性があります。このような場合、エンドポイントは、FINビットが1に設定され、ペイロードが0バイトのデータを含むDEFLATEブロックに設定された最後のフラグメントを送信するだけで済みます。使用中の圧縮ライブラリーが、バッファーが空のときにデータを生成しない場合は、空の非圧縮DEFLATEブロックを作成し、この目的で次のように使用できます。
0x00
0x00
The single octet 0x00 contains the header bits with "BFINAL" set to 0 and "BTYPE" set to 00, and 5 padding bits of 0.
単一オクテット0x00には、「BFINAL」が0に設定され、「BTYPE」が00に設定されたヘッダービットと、0の5つのパディングビットが含まれています。
On most common software development platforms, the DEFLATE compression library provides a method for aligning compressed data to byte boundaries using an empty DEFLATE block with no compression. For example, zlib [zlib] does this when "Z_SYNC_FLUSH" is passed to the deflate function.
最も一般的なソフトウェア開発プラットフォームでは、DEFLATE圧縮ライブラリは、圧縮なしの空のDEFLATEブロックを使用して、圧縮データをバイト境界に揃える方法を提供します。たとえば、zlib [zlib]は、 "Z_SYNC_FLUSH"がdeflate関数に渡されたときにこれを実行します。
Some platforms may only provide methods to output and process compressed data with a zlib header and an Adler-32 checksum. On such platforms, developers need to write stub code to remove and complement the zlib and Adler-32 checksum by themselves.
一部のプラットフォームでは、zlibヘッダーとAdler-32チェックサムを使用して圧縮データを出力および処理するメソッドしか提供しない場合があります。このようなプラットフォームでは、開発者は自分でzlibとAdler-32チェックサムを削除して補完するスタブコードを作成する必要があります。
To obtain a useful compression ratio, an LZ77 sliding window size of 1,024 or more is RECOMMENDED.
有効な圧縮率を得るには、LZ77のスライディングウィンドウサイズを1,024以上にすることをお勧めします。
If a side disallows context takeover, its endpoint can easily figure out whether or not a certain message will be shorter if compressed. Otherwise, it's not easy to know whether future messages will benefit from having a certain message compressed. Implementors may employ some heuristics to determine this.
サイドがコンテキストのテイクオーバーを許可しない場合、そのエンドポイントは、特定のメッセージが圧縮された場合に短くなるかどうかを簡単に判断できます。そうしないと、特定のメッセージを圧縮することで将来のメッセージにメリットがあるかどうかを知るのは簡単ではありません。実装者は、これを決定するためにいくつかのヒューリスティックを使用できます。
There is a known exploit when history-based compression is combined with a secure transport [CRIME]. Implementors should pay attention to this point when integrating this extension with other extensions or protocols.
履歴ベースの圧縮が安全なトランスポートと組み合わされた場合の既知のエクスプロイトがあります[CRIME]。実装者は、この拡張機能を他の拡張機能またはプロトコルと統合するときに、この点に注意を払う必要があります。
IANA has registered the following WebSocket extension name in the "WebSocket Extension Name Registry" defined in [RFC6455].
IANAは、[RFC6455]で定義されている「WebSocket Extension Name Registry」に以下のWebSocket拡張名を登録しています。
Extension Identifier permessage-deflate
拡張識別子permessage-deflate
Extension Common Name WebSocket Per-Message Deflate
拡張共通名WebSocketメッセージごとのDeflate
Extension Definition This document.
拡張定義このドキュメント。
Known Incompatible Extensions None
既知の互換性のない拡張機能なし
The "permessage-deflate" extension name is used in the "Sec-WebSocket-Extensions" header in the WebSocket opening handshake to negotiate use of the "permessage-deflate" extension.
「permessage-deflate」拡張名は、「permessage-deflate」拡張の使用をネゴシエートするために、WebSocketオープニングハンドシェイクの「Sec-WebSocket-Extensions」ヘッダーで使用されます。
9.2. Registration of the "Per-Message Compressed" WebSocket Framing Header Bit
9.2. 「メッセージごとに圧縮された」WebSocketフレーミングヘッダービットの登録
IANA has registered the following WebSocket framing header bit in the "WebSocket Framing Header Bits Registry" defined in [RFC6455].
IANAは、[RFC6455]で定義されている「WebSocketフレーミングヘッダービットレジストリ」に次のWebSocketフレーミングヘッダービットを登録しました。
Value RSV1
値RSV1
Description The "Per-Message Compressed" bit, which indicates whether or not the message is compressed. RSV1 is set for compressed messages and unset for uncompressed messages.
説明メッセージごとの圧縮ビット。メッセージが圧縮されているかどうかを示します。 RSV1は圧縮メッセージに対して設定され、非圧縮メッセージに対して設定解除されます。
Reference Section 6 of this document.
このドキュメントのセクション6を参照してください。
The "Per-Message Compressed" framing header bit is used on the first fragment of data messages to indicate whether the payload of the message is compressed by the PMCE or not.
「メッセージごとの圧縮」フレーミングヘッダービットは、メッセージのペイロードがPMCEによって圧縮されているかどうかを示すために、データメッセージの最初のフラグメントで使用されます。
[CRIME] Rizzo, J. and T. Duong, "The CRIME attack", EKOparty Security Conference, September 2012.
[犯罪]リッツォJ.とT.デュオン、「犯罪」攻撃、EKOparty Security Conference、2012年9月。
[LZ77] Ziv, J. and A. Lempel, "A Universal Algorithm for Sequential Data Compression", IEEE Transactions on Information Theory, Vol. 23, No. 3, pp. 337-343, DOI 10.1109/TIT.1977.1055714, May 1977, <https://www.cs.duke.edu/courses/spring03/cps296.5/papers/ ziv_lempel_1977_universal_algorithm.pdf>.
[LZ77] Ziv、J。およびA. Lempel、「シーケンシャルデータ圧縮のためのユニバーサルアルゴリズム」、IEEE Transactions on Information Theory、Vol。 23、No. 3、pp。337-343、DOI 10.1109 / TIT.1977.1055714、May 1977、<https://www.cs.duke.edu/courses/spring03/cps296.5/papers/ ziv_lempel_1977_universal_algorithm.pdf>。
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, <http://www.rfc-editor.org/info/rfc1951>.
[RFC1951] Deutsch、P。、「DEFLATE Compressed Data Format Specification version 1.3」、RFC 1951、DOI 10.17487 / RFC1951、1996年5月、<http://www.rfc-editor.org/info/rfc1951>。
[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>。
[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>。
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, <http://www.rfc-editor.org/info/rfc6455>.
[RFC6455] Fette、I。およびA. Melnikov、「The WebSocket Protocol」、RFC 6455、DOI 10.17487 / RFC6455、2011年12月、<http://www.rfc-editor.org/info/rfc6455>。
[RFC1979] Woods, J., "PPP Deflate Protocol", RFC 1979, DOI 10.17487/RFC1979, August 1996, <http://www.rfc-editor.org/info/rfc1979>.
[RFC1979] Woods、J。、「PPP Deflate Protocol」、RFC 1979、DOI 10.17487 / RFC1979、1996年8月、<http://www.rfc-editor.org/info/rfc1979>。
[zlib] Gailly, J. and M. Adler, "zlib", <http://www.zlib.net/>.
[zlib] Gailly、J。およびM. Adler、「zlib」、<http://www.zlib.net/>。
Acknowledgements
謝辞
Special thanks to Patrick McManus who wrote up the initial specification of a DEFLATE-based compression extension for the WebSocket Protocol, which I referred to when writing this specification.
この仕様を作成する際に参照したWebSocketプロトコル用のDEFLATEベースの圧縮拡張機能の初期仕様を作成したPatrick McManusに特に感謝します。
Thanks to the following people who participated in discussions on the HyBi WG and contributed ideas and/or provided detailed reviews (the list is likely incomplete): Adam Rice, Alexander Philippou, Alexey Melnikov, Arman Djusupov, Bjoern Hoehrmann, Brian McKelvey, Dario Crivelli, Greg Wilkins, Inaki Baz Castillo, Jamie Lokier, Joakim Erdfelt, John A. Tamplin, Julian Reschke, Kenichi Ishibashi, Mark Nottingham, Peter Thorson, Roberto Peon, Salvatore Loreto, Simone Bordet, Tobias Oberstein, and Yutaka Hirano. Note that the people listed above didn't necessarily endorse the end result of this work.
HyBi WGのディスカッションに参加し、アイデアを投稿したり、詳細なレビューを提供した次の人々に感謝します（リストはおそらく不完全です）：Adam Rice、Alexander Philippou、Alexey Melnikov、Arman Djusupov、Bjoern Hoehrmann、Brian McKelvey、Dario Crivelli 、グレッグ・ウィルキンス、イナキ・バズ・カスティージョ、ジェイミー・ロキエ、ヨアキム・エルドフェルト、ジョン・A・タンプリン、ジュリアン・レシュケ、石橋健一、マーク・ノッティンガム、ピーター・ソーソン、ロベルト・ペオン、サルヴァトーレ・ロレート、シモーネ・ボルデット、トビアス・オーバースタイン、平野豊上記の人々は、必ずしもこの作業の最終結果を承認したわけではないことに注意してください。
Author's Address
著者のアドレス
Takeshi Yoshino Google, Inc.
たけし よしの ごおｇぇ、 いんｃ。
Email: tyoshino@google.com