[53] フレームは、WebSocket接続の確立の後に WebSocketサーバーとWebSocketクライアントとの間でやり取りされる情報の単位です。
[8] フレームは、次のような構造です >>1。 可変長のヘッダーと、可変長のデータで構成されます。 ヘッダーの長さとデータの長さは、どちらもヘッダーの値により決まります。
FIN0 は最後でないこと、 1 は最後であることを表します。opcodeframe-masking-key)1 はマスクされていること、0 はマスクされていないことを示します。frame-masking-key)1
であれば、本欄が存在します。 0 なら、存在しません。[14] データフレーム (非制御フレーム) の opcode には、
次のものがあります >>1。
[44] 制御フレームの opcode には、次のものがあります >>1。
[45] 制御フレームは、状態を通信するために使うものです >>1。
[51] 予約された opcode は、拡張が使うことができます
>>49。
[18] payloadデータは、 拡張データと応用データを指します >>1。
[47] payload長は、バイト単位のpayloadデータの長さを表すものです。
次のうち、最短の形を使わなければなりません。 >>10-125 なら、これが payload長です。126 なら、次の2バイトがpayload長の16ビット符号無し整数
(ネットワークバイト順) です。127 なら、次の8バイトがpayload長の64ビット符号無し整数
(ネットワークバイト順) です。
ただし最上位ビットは 0 でなければなりません。
[54] 従って最大長は263-1バイトです。 (つまり 8388608 TB 未満まで表現できます。)
[46] 制御フレームの payload長は、125バイト以下でなければなりません >>1。
[50] これらの規定に違反したフレームを受信した時にどう処理するべきかは不明です。
[56] 最短形でない場合、
Chrome は状態符号が 1002 で理由が WebSocket Protocol Error
の Closeフレームを送信します。 Firefox は16ビット整数なら最短形でなくてもよく、
64ビット整数なら送信しないで接続を閉じます。
[57] 値が 232-1 以下なら、 Chrome も Firefox も受信しようと試みるようです。
しかし Chrome は受信し続けた末にクラッシュ、 Firefox は途中で断念して RST
するようです。 232 以上なら (64ビット整数で最上位ビットが立っている場合も)、
Chrome はコンソールに Invalid frame header と表示して
(error イベントは無し) すぐに切断します。
Firefox は error イベントを発火してすぐに切断します。
[58] 制御フレームなのに長さが125を超えていると、
Chrome も Firefox も error イベントを発火し、
Chrome は Closeフレームを送信 (1002 WebSocket Protocol Error)、
Firefox は接続を閉じます。
[55] まとめると、フレームの長さの決定は次のように行えます。
[19] フレームは、マスクする場合とマスクしない場合があります。
[20] マスクしたフレームは、マスク欄の値が 1 でなければなりません
>>1。
[21] マスクキーは、クライアントが無作為に選択した32ビット値です。 マスクキーは、マスクしたフレーム内のマスクキー欄に示されます。 >>1
[2] クライアントは、サーバーに送信するすべてのフレームをマスクしなければなりません >>1。
[5] サーバーは、クライアントにマスクしたフレームを送信してはなりません >>1。
[23] マスクする際に新鮮な値をマスクキーとして選ばなければなりません >>1。 マスクキーは予測不能である必要がありますから、 強いエントロピー源から得なければなりません >>1。 前のフレームから以後のフレームのマスクキーを容易に予測できてはなりません >>1。
[24] マスクの適用と復元は、どちらも次の手順により行います >>1。
[4] サーバーは、マスクされていないフレームを受信したら、
接続を閉じなければなりません >>1。
この場合サーバーは Close フレームを状態符号
1002 で送信して構いません >>1。
[6] クライアントは、マスクされたフレームを受信したら、
接続を閉じなければなりません >>1。
この場合クライアントは Close フレームを状態符号
1002 で送信して構いません >>1。
[68] Microsoft は、 Web ではなく公衆インターネットでもない限られた環境ではマスクしないことでパフォーマンスが向上するとして、 マスクキーを 0 とすることによりデータをマスクしないで送信するオプションを実装しています >>67。
[27] 断片化により、 送信開始時点で送信データの大きさがわからない場合でも送信開始できます >>1。
[29] 断片化は多重化により単一のWebSocket接続を複数の大きなメッセージで共有するために使うことができます。 ただし WebSocket 本体では多重化のための拡張は規定していません。 >>1
[48] 断片化された(かもしれない)状態のものがフレームと呼ばれるのに対し、 そのデータを結合したものがメッセージ >>1 と呼ばれています。
[39] 受信者は断片化に対応しなければなりません >>1。
[31] 1つのメッセージが単一フレームで表現される時は、
FIN が 1 に設定され opcode は 0 以外となります
>>1。
[32] 1つのメッセージが複数フレームで表現される時は、
FIN が 0 に設定され opcode は 0 以外となるフレーム、
0個以上の FIN が 0 に設定され opcode が 0
のフレーム、
FIN が 0 に設定され opcode が 0
のフレームの列となります >>1。
[33] 制御フレームは、断片化してはなりません >>1。 中間器は制御フレームの断片化状態を変更してはなりません >>1。
[59] 制御フレームの FIN が 0 の場合には、
Chrome でも Firefox でも接続が閉じられます。
Chrome は状態符号が 1002 で理由が
WebSocket Protocol Error のCloseフレームを送信します。
[35] 断片は、送信者が送信した順序で受信者に配送しなければなりません >>1。
[34] 制御フレームを他の断片化されたメッセージのフレーム間に注入しても構いません >>1。受信者はこれを扱えなければなりません >>1。
[36] 拡張により特に規定される場合を除き、 断片を他の断片化されたメッセージのフレーム間に注入してはなりません >>1。
[30] 拡張で特に規定される場合を除き、フレーム (の境界) は意味を持ちません。 1つの大きなメッセージも、複数に分割されたフレームを順に連結したものも、等価です。 送信者は任意の大きさに分割できます。 >>1
[37] 中間器は、拡張が適用されない場合や、
すべての適用される拡張を理解し問題ないと判断できる場合には、
フレームを分割したり結合したりするかもしれません。 >>1
RSV1, RSV2, RSV3
のいずれかが設定されているか拡張が用いられていて、その意味を理解できなければ、
断片化の状態を変更してはなりません >>1。
[40] WebSocket handshake を見ていない中間器は、 断片化の状態を変更してはなりません >>1。
[38] 拡張によっては、各フレームにのみ拡張データを含められる、 最初のフレームにのみ含められるといったような規定があるかもしれません。 >>1
[69] WebSocketメッセージ受信を参照。