[53]

フレームframeは、WebSocket接続の確立の後に WebSocketサーバーとWebSocketクライアントとの間でやり取りされる情報の単位です。

構文

[8] フレームは、次のような構造です >>1。可変長のヘッダーと、可変長のデータで構成されます。ヘッダーの長さとデータの長さは、どちらもヘッダーの値により決まります。

width: 32

1 FIN
1 RSV1
1 RSV2
1 RSV3
4 opcode
1 マスク
23 payload長
32 マスクキー
32... Payload Data

フレーム

FIN: メッセージの最後の断片fragmentであるかどうかを示します。 0 は最後でないこと、 1 は最後であることを表します。
RSV1: 拡張WebSocket拡張により規定される場合を除き、 0 でなければなりません。
RSV2: 拡張WebSocket拡張により規定される場合を除き、 0 でなければなりません。
RSV3: 拡張WebSocket拡張により規定される場合を除き、 0 でなければなりません。
opcode: payload data の解釈を規定するものです。
マスクmask (frame-masking-key): payload data がマスクされるかどうかを示します。 1 はマスクされていること、0 はマスクされていないことを示します。
payload長payload length: payload data の長さをバイト単位で示します。
マスクキーmasking key (frame-masking-key): マスクする際に使う32ビットの値です。マスクビットが 1 であれば、本欄が存在します。 0 なら、存在しません。
拡張データ: 拡張により規定された長さと用途のデータです。拡張がなければ長さ0です。
応用データapplication data: 任意の応用のデータです。

opcode

[14] データフレーム (非制御フレーム) の opcode には、次のものがあります >>1。

0 - 継続フレーム
1 - テキストフレーム
2 - バイナリーフレーム
3 - 非制御フレームに予約
4 - 非制御フレームに予約
5 - 非制御フレームに予約
6 - 非制御フレームに予約
7 - 非制御フレームに予約

[44] 制御フレームcontrol frameの opcode には、次のものがあります >>1。

8 - Closeフレーム
9 - Pingフレーム
A - Pongフレーム
B - 制御フレームに予約
C - 制御フレームに予約
D - 制御フレームに予約
E - 制御フレームに予約
F - 制御フレームに予約

[45] 制御フレームは、状態を通信するために使うものです >>1。

[51] 予約された opcode は、拡張WebSocket拡張が使うことができます >>49。

[62] opcode にはIANA登録簿があります >>61, >>65。

[10] 未知の opcode のフレームWebSocketフレームを受信した場合 WebSocket接続失敗としなければなりません >>1。

payload

[18] payloadデータpayload dataは、拡張データと応用データを指します >>1。

[47] payload長は、バイト単位のpayloadデータの長さを表すものです。次のうち、最短の形を使わなければなりません。 >>1

[15] 0-125 なら、これが payload長です。
[16] 126 なら、次の2バイトがpayload長の16ビット符号無し整数 (ネットワークバイト順) です。
[17] 127 なら、次の8バイトがpayload長の64ビット符号無し整数 (ネットワークバイト順) です。ただし最上位ビットは 0 でなければなりません。

[54] 従って最大長は2⁶³-1バイトです。 (つまり 8388608 TB 未満まで表現できます。)

[46] 制御フレームの payload長は、125バイト以下でなければなりません >>1。

[50] これらの規定に違反したフレームを受信した時にどう処理するべきかは不明です。

[56] 最短形でない場合、 Chrome は状態符号が 1002 で理由が WebSocket Protocol Error の Closeフレームを送信します。 Firefox は16ビット整数なら最短形でなくてもよく、 64ビット整数なら送信しないで接続を閉じます。 2015-08-16T13:59:43.200Z

[57] 値が 2³²-1 以下なら、 Chrome も Firefox も受信しようと試みるようです。しかし Chrome は受信し続けた末にクラッシュ、 Firefox は途中で断念して RST するようです。 2³² 以上なら (64ビット整数で最上位ビットが立っている場合も)、 Chrome はコンソールに Invalid frame header と表示して (error イベントは無し) すぐに切断します。 Firefox は error イベントを発火してすぐに切断します。 2015-08-16T14:29:01.600Z

[58] 制御フレームなのに長さが125を超えていると、 Chrome も Firefox も error イベントを発火し、 Chrome は Closeフレームを送信 (1002 WebSocket Protocol Error)、 Firefox は接続を閉じます。 2015-08-16T14:40:37.500Z

[55] まとめると、フレームの長さの決定は次のように行えます。

次の2バイトを取得します。
長さを、取得した2バイト目の下位7ビットとします。
長さが 126 なら、
1. 次の2バイトを取得します。
2. 長さを、ネットワークバイト順の16ビット符号無し整数として解釈した値に設定します。
3. 長さが 126 未満なら、WebSocket接続失敗とします。
長さが 127 なら、
1. 次の8バイトを取得します。
2. 長さを、ネットワークバイト順の64ビット符号無し整数として解釈した値に設定します。
3. 長さが 2¹⁶ 未満なら、 WebSocket接続失敗とします。
長さが2⁶³以上なら、 WebSocket接続失敗とします。
長さが実装の扱える範囲を超えていれば、 WebSocket接続失敗とします。
制御フレームで、長さが125バイトを超えているなら、
1. WebSocket接続失敗とします。
2バイト目の最上位ビットが立っていれば、
1. 次の32ビットを取得します。

マスク

[19] フレームは、マスクmaskする場合とマスクしない場合があります。

[20] マスクしたフレームは、マスク欄の値が 1 でなければなりません >>1。

[21] マスクキーmasking keyは、クライアントが無作為に選択した32ビット値です。マスクキーは、マスクしたフレーム内のマスクキー欄に示されます。 >>1

[2] クライアントは、サーバーに送信するすべてのフレームをマスクしなければなりません >>1。

[5] サーバーは、クライアントにマスクしたフレームを送信してはなりません >>1。

[23] マスクする際に新鮮な値をマスクキーとして選ばなければなりません >>1。マスクキーは予測不能である必要がありますから、強いエントロピー源から得なければなりません >>1。前のフレームから以後のフレームのマスクキーを容易に予測できてはなりません >>1。

[3] これは、プロキシ等の中間器の混乱を防ぐため、またセキュリティーのために必要な措置です >>1, >>43。

[22]

RFC 4086 に強いエントロピー源についての議論があります

>>1

。

[24] マスクの適用と復元は、どちらも次の手順により行います >>1。

[25] 入力データの各オクテットについて、
1. [26] 出力のオクテット i は、入力のオクテット i とマスクデータのオクテット i mod 4 の XOR とします。

[4] サーバーは、マスクされていないフレームを受信したら、接続を閉じなければなりません >>1。この場合サーバーは Close フレームを状態符号 1002 で送信して構いません >>1。

[6] クライアントは、マスクされたフレームを受信したら、接続を閉じなければなりません >>1。この場合クライアントは Close フレームを状態符号 1002 で送信して構いません >>1。

[68] Microsoft は、 Web ではなく公衆インターネットでもない限られた環境ではマスクしないことでパフォーマンスが向上するとして、マスクキーを 0 とすることによりデータをマスクしないで送信するオプションを実装しています >>67。

[67] [MS-WSPE]: WebSocket Protocol Extensions (2015-05-17 00:10:16 +09:00 版) https://msdn.microsoft.com/en-us/library/hh553781.aspx

断片化

[27] 断片化fragmentationにより、送信開始時点で送信データの大きさがわからない場合でも送信開始できます >>1。

[28]

断片化を使って、送信データの末端を待たずに適度にバッファーにデータが溜まった時点で送信できます

>>1

。

[29] 断片化は多重化multiplexingにより単一のWebSocket接続を複数の大きなメッセージで共有するために使うことができます。ただし WebSocket 本体では多重化のための拡張は規定していません。 >>1

[48] 断片化された(かもしれない)状態のものがフレームと呼ばれるのに対し、そのデータを結合したものがメッセージmessage >>1 と呼ばれています。

[39] 受信者は断片化に対応しなければなりません >>1。

[31] 1つのメッセージが単一フレームで表現される時は、 FIN が 1 に設定され opcode は 0 以外となります >>1。

(FIN = 1, opcode ≠ 0)

[32] 1つのメッセージが複数フレームで表現される時は、 FIN が 0 に設定され opcode は 0 以外となるフレーム、 0個以上の FIN が 0 に設定され opcode が 0 のフレーム、 FIN が 0 に設定され opcode が 0 のフレームの列となります >>1。

(FIN = 0, opcode ≠ 0)
*
1. (FIN = 0, opcode = 0)
(FIN = 1, opcode = 0)

[33] 制御フレームは、断片化してはなりません >>1。中間器は制御フレームの断片化状態を変更してはなりません >>1。

[59] 制御フレームの FIN が 0 の場合には、 Chrome でも Firefox でも接続が閉じられます。 Chrome は状態符号が 1002 で理由が WebSocket Protocol Error のCloseフレームを送信します。 2015-08-17T07:12:56.800Z

[35] 断片は、送信者が送信した順序で受信者に配送しなければなりません >>1。

[34] 制御フレームを他の断片化されたメッセージのフレーム間に注入しても構いません >>1。受信者はこれを扱えなければなりません >>1。

[42] 大きなメッセージの転送中に ping の遅延が大きくなることを防ぐためです

>>1

。

[36] 拡張により特に規定される場合を除き、断片を他の断片化されたメッセージのフレーム間に注入してはなりません >>1。

[52] これら禁止規定に反した場合にどう処理するべきかは不明です。

[30] 拡張で特に規定される場合を除き、フレーム (の境界) は意味を持ちません。 1つの大きなメッセージも、複数に分割されたフレームを順に連結したものも、等価です。送信者は任意の大きさに分割できます。 >>1

[37] 中間器は、拡張が適用されない場合や、すべての適用される拡張を理解し問題ないと判断できる場合には、フレームを分割したり結合したりするかもしれません。 >>1 RSV1, RSV2, RSV3 のいずれかが設定されているか拡張が用いられていて、その意味を理解できなければ、断片化の状態を変更してはなりません >>1。

[40] WebSocket handshake を見ていない中間器は、断片化の状態を変更してはなりません >>1。

[41] どういう状況でしょうか? WebSocket接続の確立とそれ以後の処理を別の中間器で行う場合??

[38] 拡張によっては、各フレームにのみ拡張データを含められる、最初のフレームにのみ含められるといったような規定があるかもしれません。 >>1

仕様書

構文

opcode

payload

マスク

断片化

受信