[122] WebSocketクライアント は close メソッド によって接続を閉じることができます。 WebSocket接続 を閉じる際は
Closeフレームclosing handshake
[123] その他に、 Closeフレーム
仕様書 [1] RFC 6455 - The WebSocket Protocol (2015-03-11 20:42:50 +09:00 版) http://tools.ietf.org/html/rfc6455#section-5.5.1 [12] RFC 6455 - The WebSocket Protocol (2015-03-11 20:42:50 +09:00 版) http://tools.ietf.org/html/rfc6455#section-7 [49] RFC 6455 - The WebSocket Protocol (2015-03-11 20:42:50 +09:00 版) http://tools.ietf.org/html/rfc6455#section-8 [42] RFC 6455 - The WebSocket Protocol (2015-03-11 20:42:50 +09:00 版) http://tools.ietf.org/html/rfc6455#section-10.7 [54] RFC Errata Report (2015-05-16 22:26:12 +09:00 版) http://www.rfc-editor.org/errata_search.php?rfc=6455 [58] HTML Standard (2015-05-06 10:42:35 +09:00 版) https://html.spec.whatwg.org/#dom-websocket-close [62] HTML Standard (2015-05-06 10:42:35 +09:00 版) https://html.spec.whatwg.org/#feedback-from-the-protocol [77] HTML Standard (2015-05-06 10:42:35 +09:00 版) https://html.spec.whatwg.org/#closeevent [84] HTML Standard (2015-05-06 10:42:35 +09:00 版) https://html.spec.whatwg.org/#garbage-collection-3 接続の終了 [44] WebSocket接続 の終了は、次のような動作により開始されます。[45] WebSocket オブジェクト の close >>59 ) や、それに相当する操作[105] 相手からの Closeフレーム>>25 )[47] WebSocket オブジェクト の make disappear (>>90 )[48] WebSocket オブジェクト のごみ収集 (>>89 )[46] WebSocket handshake や WebSocketメッセージ受信 によるWebSocket接続失敗 [55] WebSocket handshake による Abort the WebSocket Connection (>>38 )[56] 下位層の接続が切断されることによるWebSocket接続失敗 (>>37 )[104] その他の理由での Start the WebSocket Closing Handshake (>>36 , >>40 )
[128] 接続を閉じる動作の大まかな流れは次のようになります。
handshake 接続確立 -> failed -> abort -> normal v >> 3 disconnected 下位層切断 v >> 1 -> failed normal 送受信 -> failed -> Close received >> 5 make disappear disappear v -> failed -> abort >> 1 close method close -> start closing >> 3 gc ごみ収集 -> start closing >> 4 abort Abort -> close v failed 接続失敗 -> send Close 1 >> 2 start closing Closing -> send Close 1 >> 3 send Close 1 Close -> close -> Close received >> 2 v Close received Close -> send Close 2 -> close v >> 5 send Close 2 Close v >> 5 -> close close 閉じる v >> 1 [37] クライアント は、トランスポート層 の接続 が失われたら、
WebSocket接続失敗 を実行しなければなりません >>12
[57] なぜかサーバー に関する規定はありません。[36] クライアント は、応用 から指示された場合やプロトコル で規定されている場合を除き、
接続 を閉じるべきではありません >>12 Start the WebSocket Closing Handshake を実行します >>12
[40] サーバー は、適宜接続を閉じて構いません >>12 Start the WebSocket Closing Handshake を実行します >>12
[131] Chrome は異常終了時 (で可能なとき) に、
状態符号 1001 空文字列 のCloseフレーム を送信するようです。
2015-08-22T06:18:57.300Z
WebSocket インターフェイス close メソッド[59] WebSocket インターフェイス の
close メソッド >>58 WebSocket の接続 を閉じることを指示するものです。
[159] 第1引数として、WebSocket状態符号 (数値) を指定できます。
この引数は省略可能です。指定された場合は、 Closeフレーム でサーバー に送られます。
いくつかの状態符号 の値はプロトコル により定められていますが、
サーバー とクライアント の裁量で決められる値の範囲もあります。
WebSocket状態符号 参照。[160] 第2引数として、WebSocket接続閉じ理由 (文字列) を指定できます。
この引数は省略可能です。指定された場合は、Closeフレーム でサーバー に送られます。
サーバー とクライアント の裁量で任意の文字列を使うことができますが、
UTF-8 で符号化 したときに123バイト 以下 に収まらなければなりません。
[161] このメソッド は接続を閉じることを指示するものですが、
送受信の状態によっては、すぐには接続が閉じられない場合もあります。
[158] 本メソッド は、次のようにしなければなりません >>58
[140] 符号 を、省略可能な第1引数を unsigned short として解釈した結果に設定します。
Clamp 拡張属性 を適用します。[141] 理由 を、省略可能な第2引数を USVString として解釈した結果に設定します。[142] 符号 が 1000 か [ 3000, 4999 ] の範囲になければ、[143] InvalidAccessError 例外 を投げ 、ここで停止します。[144] 理由 が null でなければ、[145] 理由 を、理由 にUTF-8符号化 を適用した結果に設定します。[146] 理由 の長さが123バイト より大きければ、[147] SyntaxError 例外 を投げ 、ここで停止します。[148] 文脈オブジェクト の readyState が CLOSING 2 CLOSED 3 [149] ここで停止します。[150] それ以外で、文脈オブジェクト がまだWebSocket接続確立 に達していなければ
(= 接続の状態 が CONNECTING [151] 文脈オブジェクト についてWebSocket接続失敗 を実行します。[152] 文脈オブジェクト の readyState を、
CLOSING 2 [153] それ以外で、文脈オブジェクト がまだ
The WebSocket Closing Handshake is Started に達していなければ
(= 接続の状態 が OPEN [154] 文脈オブジェクト について Start the WebSocket closing handshake を実行します。
状態符号 は符号 、理由は理由 とします。[155] 文脈オブジェクト の readyState を、
CLOSING 2 [156] それ以外なら、[157] 文脈オブジェクト の readyState を、
CLOSING 2 [60] 接続の状態と readyState WebSocket接続 を参照。[134] Chrome は、 接続 を開いて handshake を開始した後で確立する前に
close Closeフレーム を送信するようです。
handshake 失敗時は送信しません。 2015-08-22T07:47:25.300Z
文書の破棄 [90] WebSocket オブジェクト の make disappear なりません >>84
接続の状態が CONNECTING WebSocket接続失敗 を実行します。 接続の状態が OPEN Start the WebSocket Closing Handshake を実行します。
状態符号 は 1001 [91] これは unloading document cleanup steps から呼び出されます。ごみ収集 [87] WebSocket オブジェクト のごみ収集 は、
次のように規定されています。
[85] event loop step 1 時点での readyState CONNECTING open message error close イベントリスナー が登録されているなら、
ごみ収集 してはなりません >>84 OPEN message error close イベントリスナー が登録されているなら、
ごみ収集 してはなりません >>84 CLOSING error close イベントリスナー が登録されているなら、
ごみ収集 してはなりません >>84
[116] 言い換えると、まだ実行される可能性のあるイベントリスナー が存在している間は、
強い参照 を保持し続ける必要があります。 event loop step 1
時点でそのようなイベントリスナー が存在しなくなっていれば、
強い参照 を破棄できます。[86] 送信バッファー が空でないなら、ごみ収集 してはなりません >>84
[88] このバッファー は WebSocket オブジェクト に関連付けられたアプリケーション 層のものであり、OS (ソケット ) 側のバッファー とは異なります。[89] ごみ収集 により破棄する直前に、次の処理を実行しなければなりません [52] 接続の状態が OPEN [53] Start the WebSocket Closing Handshake を状態符号 なしで実行します >>84
閉じ handshake [20] Start the WebSocket Closing Handshake 状態符号 符号 (整数 または null ) と理由 理由
(バイト列 または null ) について、
次のようにしなければなりません 。[21] フレーム を送信します >>12 , >>58 フレーム
opcode Close 状態符号 符号 が null 以外なら、符号 close reason 符号 と理由 が null 以外なら、理由 [10] Closeフレーム[24] WebSocket接続 の状態を CLOSING >>12 [11] The WebSocket Closing Handshake is Started を実行します >>12 [26] Closeフレーム[23] WebSocket接続を閉じる を実行します >>1 , >>12 cleanly は真 に設定します >>12 状態符号 と close reason を引き渡します。
[25] Closeフレーム[100] Closeフレーム[101] WebSocket接続を閉じる を実行します >>1 , >>12 cleanly は真 に設定します >>12 状態符号 と close reason を引き渡します。[108] そうでなければ、[98] WebSocket接続 の状態を CLOSING >>12 [99] The WebSocket Closing Handshake is Started を実行します >>12 [8] WebSocket接続失敗 フラグが設定されていなければ、>>12 [7] フレーム を送信します >>1 べきです >>1 フレーム
opcode Close 状態符号 あれば、受信した値とするのが普通です >>1 [126] Closeフレーム[127] 下位層の接続を閉じます >>1 WebSocket接続を閉じる 処理 (>>13 )
を実行するので良いと思われます。
[61] 利用者エージェント は、the WebSocket closing handshake is started なりません [102] 次のタスク をタスクキュー に追加します >>62 タスク
タスク源 WebSocketタスク源 処理 [103] readyState CLOSING 2 [63] 既に CLOSING
接続失敗 [7] WebSocket接続の確立 やWebSocketメッセージ受信 により、
WebSocket接続失敗Fail the WebSocket Connection
[33] 次のようにしなければなりません [34] WebSocket接続失敗 フラグを真 に設定します。[80] 接続の状態が OPEN [81] 適切な状態符号 の Closeフレームべきです >>12 [93] WebSocket接続を閉じる 処理を実行します。 >>12 [94] クライアント なら利用者 に問題を報告しても構いません。 >>12 [95] サーバー なら問題を記録するべきです >>12
[76] RFC は「WebSocket接続確立 を過ぎていれば」 >>12 Closeフレームサーバー にはWebSocket接続確立 が無く、また CLOSING Closeフレーム[109] 接続の状態を OPEN CLOSING [35] WebSocket接続失敗 以後、受信したデータを処理し続けようとしてはなりません Closeフレーム>>12
[38] サーバー が Abort the WebSocket Connection WebSocket接続を閉じる 処理を実行しなければなりません >>12
接続を閉じる [13] WebSocket接続を閉じるClose the WebSocket Connection TCP接続 を閉じます >>12
[14] TCP接続 とTLSセッション を綺麗に閉じる方法を使い、
受信したかもしれないバイト は捨てるべきです >>12
[16] 最も通常な場合には、まず (クライアント からではなく)
サーバー から TCP接続 を閉じるべきです >>12 サーバー は、直ちに TCP を閉じるべきです >>12 , >>1 クライアント は、サーバー から TCP が閉じられるのを待つべきです >>12 , >>1
[17] そうすることで、クライアント ではなくサーバー の TCP
が TIME_WAIT TIME_WAIT 最大セグメント寿命 の2倍 (2MSL ) の間は改めて接続 を開くことができませんが、
サーバー 側ならより大きなシーケンス番号 の SYN 接続 を開けるので問題となりません。 >>12 [19] 例えば socket API では、
まず SHUT_WR shutdown 0 recv close >>12
[18] 十分な時間サーバー から TCP Close を受信しない場合などにはクライアント から
TCP を閉じて構いません >>12 , >>1
[132] Chrome は、 Closeフレーム の送信から 60s で Closeフレーム を受信しないとき、
TCP 接続 を閉じるようです。 Firefox は、 20s で閉じるようです。
2015-08-22T07:44:50.500Z
[133] Chrome も Firefox も、 Closeフレーム を送信した後
Closeフレーム を受信したら、 TCP接続 を閉じるようです。
切断まで Chrome は 2s 強、 Firefox は 1s 強待つようです。 2015-08-22T07:44:49.500Z
[135] Closeフレーム を受信した後 Closeフレーム を送信してから、
Chrome は 2s、Firefox は 1s 待機した後、
TCP接続 を閉じるようです。 2015-08-22T08:07:34.000Z
[136] Chrome は Closeフレーム 受信後にもフレーム の解釈を続け、
エラーがあったらコンソール に報告します。 Firefox はそのような報告はしないので、
解釈しているのかどうかは不明です。 2015-08-22T08:09:26.000Z
[15] 攻撃されている時など、必要に応じて他の方法で閉じても構いません >>12
[137] Chrome も Firefox も、WebSocket接続失敗 時にすぐに
TCP接続 を閉じるようです。 2015-08-22T09:34:03.000Z
[27] TCP接続 が閉じられた時、次のようにしなければなりません。[29] WebSocket接続 の状態を、 CLOSED >>12 [110] The WebSocket Connection is Closed を実行します >>12 cleanly
[64] 利用者エージェント は The WebSocket Connection is Closed なりません [118] WebSocket接続失敗 フラグが設定されているか、
flagged as full フラグが設定されているなら、[119] 失敗 を、真 に設定します。[120] それ以外なら、[121] 失敗 を、偽 に設定します。[111] 次のタスク をタスクキュー に追加します >>62 タスク
タスク源 WebSocketタスク源 処理 [112] readyState CLOSED 3 [113] 失敗 が真 なら、
単純イベントを発火 します。単純イベント
イベント型 error 対象オブジェクト WebSocket オブジェクト [114] イベント を発火 します。イベント
インターフェイス CloseEvent イベント型 close 対象オブジェクト WebSocket オブジェクト bubbles 偽 取り消し可能 偽 既定動作 なし wasClean cleanly code WebSocket接続閉じ符号 reason WebSocket接続閉じ理由 [115] WebSocket接続閉じ符号 と WebSocket接続閉じ理由 は、
(あれば) 指定された状態符号 と close reason から決まります。
[28] cleanly WebSocket接続 の閉じ handshake が完了してから TCP接続 が閉じられた >>12
[78] CloseEvent インターフェイス の
wasClean 属性 は、 cleanly
に閉じられたかどうかを表します。
[79] この属性 は、その属性値 として設定された値を返さなければなりません >>77 データ型 は boolean 偽 です >>77
[130] flagged as full バッファー が満杯でデータを送信できないことを表します。
send メソッド からデータを送信する時に設定されることがあります。
[66] 利用者エージェント は、スクリプト に次の状況を区別できる情報を提供してはなりません >>62 [67] ホスト名 が名前解決 できなかった場合[68] サーバー にパケット を配送する経路 を見つけられなかった場合[69] ポート への接続 が拒まれた場合[70] TLS handshake に失敗した場合 (例えば証明書 を検証できなかった場合)[71] WebSocket handshake を完了できなかった場合[72] WebSocket handshake は完了したものの、クライアント が接続 を閉じる状況となった場合 (例えばクライアント が想定しない部分プロトコル をサーバー が指定した場合)[73] WebSocket handshake は成功したものの接続 が予期せず閉じられた場合
[74] このような場合のWebSocket接続閉じ符号 はいずれも 1006 >>62
[75] こうした状況を区別できるとすると、スクリプト が利用者 の属するネットワークの状態を調べるために使えてしまいます >>62 再接続待ち [39] クライアント が異常終了の後再接続を試みる際は、
何らかの backoff を行うべきです 無作為 に決めた時間だけ遅延させるべきです 無作為 に決めるのが妥当でしょうが、
実装経験や応用 に基づき任意の方法で決めて構いません。
それ以後の再接続は、冪乗打ち切り待機法 truncated binary exponential backoff べきです >>12
[65] これを誰が実装するべきなのかは不明です。 WebSocket API の内部で実装するべきなのでしょうか?
それともスクリプト が個別に実装するべきなのでしょうか?Close フレーム[96] CloseフレームWebSocket接続 を閉じる際に用いられます。
[97] 正常終了にも異常終了にも用いられます。もっとも、異常終了時は
Closeフレーム構文 [2] opcode は、 0x8 です >>1 Close フレーム は、制御フレーム です。
[3] 閉じる理由を示す本体 body 応用データ ) を含んで構いません >>1
width 16 16 状態符号 16... close reason [4] 本体がある場合、最初の2バイトはネットワークバイト順 の2バイト符号無し整数 でなければなりません 整数 は、状態符号 でなければなりません >>1
[5] 本体は更に UTF-8 符号化されたデータを含めることができます。
その解釈は WebSocket 仕様書では規定されておらず、人間可読 である必要もありませんが、
デバッグ などに有用かもしれません。クライアント はこれを末端利用者 に示してはなりません >>1
[22] この部分は「close reason >>12 ?状態符号 *Unicode文字 [125] 利用する場面によっては、状態符号 とclose reason は指定されていません。
そのような場合にどうするべきか、 RFC 上は明確ではありません。
実装は状況に応じた適当な値を指定できると思われます。これはデバッグ には有用かもしれませんが、
一方で fingerprinting vector となったり、不必要な内部情報を送ってしまったりするかもしれませんから、
クライアント は特に注意が必要です。
処理 [107] >>25 参照。
[6] 応用 は、 Close フレーム より後にデータフレーム を送ってはなりません >>1
[31] 応用データ が1バイトのみしかない場合にどう解釈するべきかは不明です。
非妥当なデータを受信した場合はWebSocket接続を閉じる ことが認められており >>42
[43] 規定が曖昧だと相互運用性 に問題は無いのでしょうかね?[50] 理由が UTF-8 として妥当 でなければ、WebSocket接続失敗 しなければなりません >>49
[51] が、無視して閉じる処理を続ける方が適切かもしれません。[129] Chrome は、 payload が1バイトのみの時、状態符号 1002 空文字列 のCloseフレーム を送信します。
理由が UTF-8 として正しくない時、状態符号 1002 Invalid UTF-8 in Close frame を送信します。
状態符号 が 1005 1006 状態符号 1002 空文字列 を送信します。
Firefox はこれらの時、データなしの Closeフレーム を送信します。
Firefox は状態符号 が 0 Closeフレーム を送信します。 2015-08-16T15:31:14.200Z
状態符号と理由 [41] Closeフレーム状態符号 と、任意の文字列を記述できます。
受信者による理由の解釈や処理方法は、 WebSocket Protocol
としては規定されていません >>12
[30] WebSocket状態符号 も参照。[124] close reason は、制御フレーム の制約と状態符号 が2バイトであることから、
123バイト以下 である必要があります。 (UTF-8 符号化 されたバイト列 の制限で、
文字列 の制限ではありません。) WebSocket インターフェイス の
close メソッド では、この制限を超えると例外 が投げられます。
[32] WebSocket接続閉じ理由The WebSocket Connection Close Reason 応用 が最初に受信した CloseフレームUTF-8 decode without BOM を適用 >>62 文字列 )
です。そのようなものが無ければ、
空文字列 です。 >>12
[82] CloseEvent インターフェイス の
reason 属性 は、WebSocket接続閉じ理由 を表します。
[83] この属性 は、その属性値 として設定された値を返さなければなりません >>77 データ型 は DOMString 空文字列 です >>77
close イベント[117] close onclose CloseEvent
歴史 [92] Web Applications 1.0 r2870 Drop <eventsource>. Replace the API with an EventSource object. Rename onclosed to onclose on WebSocket. Remove the mostly worthless event definitions. I'll add more useful intro text to replace them later. Defined garbage collection specialness for WebSocket and EventSource. (2009-02-26 17:33:00 +09:00 版) http://html5.org/tools/web-apps-tracker?from=2869&to=2870 メモ [9] RFC には同じようにみえる規定が複数あり、助動詞 が MUST だったり SHOULD
だり無かったりしていたり、しかし微妙に条件が違っていて矛盾しているのかどうか判断が難しかったりします。
IETF の仕様書ではよくあることですが、RFC の細部は信頼せず、
相互運用性 が高いと思われる方法を推測して実装する必要がありそうです。
[138] Use utf-8 decode without BOM rather than UTF-8 decoder · whatwg/html@39a2e6c
(2016-02-10 21:50:21 +09:00 版)
https://github.com/whatwg/html/commit/39a2e6cde3b4820db56fabe1859de0dc0e6ed8d9
[139] Editorial: xref UTF-8 encode in WebSocket's close() · whatwg/html@e2bd61d
(2016-03-29 00:35:19 +09:00 版)
https://github.com/whatwg/html/commit/e2bd61d1e4bd356b747e15c4e724a75eadbb25ac