WebSockets標準

1. 序章

このセクションは規範的ではありません。

ウェブアプリケーションがサーバーサイドプロセスと双方向通信を維持できるようにするため、この仕様はWebSocket インターフェイスを導入します。

このインターフェイスは、基盤となるネットワークへの生のアクセスを許可しません。例えば、このインターフェイスを使用してカスタムサーバーを介さずにIRCクライアントを実装することはできません。

2. WebSocketプロトコルの変更

このセクションは、Fetchで定義されたアルゴリズムと統合するためにWebSocketプロトコルのオープニングハンドシェイクのクライアント要件の一部を置き換えます。これにより、CSP、クッキー、HSTS、その他のFetch関連プロトコルが単一の場所で処理されます。理想的には、RFCがこの文言を反映して更新されるべきですが、それは簡単ではありません。このWebSocket APIは、以下に定義される言語を使用します。[WSP] [FETCH]

この動作は、WebSocketプロトコルの「WebSocket接続を確立する」アルゴリズムをFetchと統合する新しいものと置き換えることによって機能します。「WebSocket接続を確立する」は3つのアルゴリズムで構成されます：接続のセットアップ、ハンドシェイクリクエストの作成と送信、ハンドシェイクの応答の検証。この階層構造はFetchとは異なり、最初にハンドシェイクを作成し、その後接続をセットアップしてハンドシェイクを送信し、最後に応答を検証します。これらの変更を読む際にその点を留意してください。

2.1. 接続

urlを与えられた場合にWebSocket接続を取得するには、次の手順を実行します：

hostをurlのホストとします。
portをurlのポートとします。
resource nameをU+002F (/)およびurlのパス（空文字列を含む）があればそれらをU+002F (/)で区切って連結した文字列とします。
もしurlのクエリが空でない場合は、U+003F (?)とurlのクエリをresource nameに追加します。
secureをurlのスキームが"http"の場合はfalse、それ以外の場合はtrueとします。
セクション4.1の最初の手順セットのステップ2から5（含む）の要件に従い、host、port、resource name、secureを渡してWebSocket接続を確立します。[WSP]
もし接続が確立された場合はそれを返し、そうでなければ失敗を返します。

構造や保持するプロパティが若干異なるため共有はできませんが、WebSocket接続は「通常の」接続と非常に近いものです。

2.2. オープニングハンドシェイク

url、protocols、およびclientを与えられた場合にWebSocket接続を確立するには、次の手順を実行します：

requestURLをurlのコピーとし、urlのスキームが"ws"の場合は"http"に、そうでない場合は"https"に設定します。

このスキームの変更は、fetchingと適切に統合するために重要です。例えば、HSTSはこれがないと機能しません。WebSocketが独自のスキームを持つ必要は実際にはなく、それはレガシーの名残です。 [HSTS]
requestを新しいリクエストとし、そのURLをrequestURL、クライアントをclient、サービスワーカーのモードを"none"、リファラーを"no-referrer"、モードを"websocket"、認証モードを"include"、キャッシュモードを"no-store"、リダイレクトモードを"error"とします。
追加 (`Upgrade`, `websocket`) をrequestのヘッダーリストに行います。
追加 (`Connection`, `Upgrade`) をrequestのヘッダーリストに行います。
keyValueをランダムに選択された16バイトの値で構成され、 forgiving-base64エンコードされ、等価エンコードされたノンスとします。

もしランダムに選択された値がバイト列0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10だった場合、keyValueは forgiving-base64エンコードされ"AQIDBAUGBwgJCgsMDQ4PEC=="となり、等価エンコードされ`AQIDBAUGBwgJCgsMDQ4PEC==`となります。
追加 (`Sec-WebSocket-Key`, keyValue) をrequestのヘッダーリストに行います。
追加 (`Sec-WebSocket-Version`, `13`) をrequestのヘッダーリストに行います。
各protocolについて、protocolsの中から`Sec-WebSocket-Protocol`とprotocolで結合をrequestのヘッダーリストに行います。
permessageDeflateをユーザーエージェントが定義した"permessage-deflate"拡張のヘッダー値とします。[WSP]

`permessage-deflate; client_max_window_bits`
追加 (`Sec-WebSocket-Extensions`, permessageDeflate) を requestのヘッダーリストに行います。
Fetch requestをuseParallelQueueをtrueに設定し、 processResponseとして以下のresponseのステップを指定して行います：
1. もしresponseがネットワークエラーであるか、ステータスが101でない場合、WebSocket接続を失敗させます。
2. もしprotocolsが空リストでなく、`Sec-WebSocket-Protocol`およびresponseのヘッダーリストを指定してヘッダーリスト値を抽出する結果がnull、失敗、または空バイト列である場合、WebSocket接続を失敗させます。
  
  これはWebSocketプロトコルで定義されたこのヘッダーのチェックと異なります。それはクライアントによって要求されていないサブプロトコルのみをカバーします。これはクライアントによって要求されたがサーバーによって認識されなかったサブプロトコルをカバーします。
3. セクション4.1の最後の手順セットのステップ2からステップ6（含む）の要件に従い、responseを検証します。これによりWebSocket接続を失敗させるまたはWebSocket接続が確立されます。

WebSocket接続を失敗させるおよびWebSocket接続が確立されるは、WebSocketプロトコルで定義されています。 [WSP]

リダイレクトがフォローされず、このハンドシェイクが一般的に制限される理由は、Webブラウザーのコンテキストで深刻なセキュリティ問題を引き起こす可能性があるためです。例えば、あるホストが1つのパスにWebSocketサーバーを持ち、別のパスにオープンなHTTPリダイレクタを持っているとします。この場合、特定のWebSocket URLを指定するスクリプトは、正しいホスト名を持つURLであることをチェックしても、インターネット上の任意のホストと通信し（そしておそらく秘密を共有する）ように騙される可能性があります。

3. `WebSocket` インターフェイス

3.1. インターフェイス定義

WebSocket クラスのWeb IDL定義は以下の通りです:

enum BinaryType { "blob", "arraybuffer" };

[Exposed=(Window,Worker)]
interface WebSocket : EventTarget {
  constructor(USVString url, optional (DOMString or sequence<DOMString>) protocols = []);
  readonly attribute USVString url;

  // ready state
  const unsigned short CONNECTING = 0;
  const unsigned short OPEN = 1;
  const unsigned short CLOSING = 2;
  const unsigned short CLOSED = 3;
  readonly attribute unsigned short readyState;
  readonly attribute unsigned long long bufferedAmount;

  // networking
  attribute EventHandler onopen;
  attribute EventHandler onerror;
  attribute EventHandler onclose;
  readonly attribute DOMString extensions;
  readonly attribute DOMString protocol;
  undefined close(optional [Clamp] unsigned short code, optional USVString reason);

  // messaging
  attribute EventHandler onmessage;
  attribute BinaryType binaryType;
  undefined send((BufferSource or Blob or USVString) data);
};

各WebSocket オブジェクトには、関連付けられたurlがあります。これはURLレコードです。

各WebSocket オブジェクトには関連付けられたbinary typeがあり、これはBinaryType です。初期値は "blob" に設定される必要があります。

各WebSocket オブジェクトには関連付けられたready stateがあり、これは接続状態を表す数値です。初期値はCONNECTING (0)に設定される必要があります。以下の値を取ることができます:

CONNECTING (数値値 0): 接続がまだ確立されていません。
OPEN (数値値 1): WebSocket接続が確立され、通信が可能です。
CLOSING (数値値 2): 接続が終了ハンドシェイクを行っているか、close() メソッドが呼び出されました。
CLOSED (数値値 3): 接続が閉じられたか、開くことができませんでした。

socket = new WebSocket(url [, protocols ])

新しいWebSocket オブジェクトを作成し、関連付けられたWebSocket接続を直ちに確立します。

urlは、接続が確立されるURLを示す文字列です。 "ws", "wss", "http", "https"スキームのみが許可されます。他のスキームは "SyntaxError" DOMException を引き起こします。フラグメントを含むURLも常に例外を引き起こします。

protocolsは文字列または文字列の配列です。文字列の場合、それはその文字列だけを含む配列と同等であり、省略された場合、空の配列と同等です。配列内の各文字列はサブプロトコル名です。接続は、サーバーがこれらのサブプロトコルのいずれかを選択したことを報告した場合にのみ確立されます。サブプロトコル名は、`Sec-WebSocket-Protocol`フィールドの値を構成する要素に対する要件に一致している必要があります。 [WSP]

socket.send(data)

WebSocket接続を使用してdataを送信します。dataは文字列、Blob、 ArrayBuffer、またはArrayBufferView です。

socket.close([ code ] [, reason ])

WebSocket接続を閉じます。オプションでcodeをWebSocket接続終了コードとして、reasonをWebSocket接続終了理由として使用します。

socket.url

WebSocket接続を確立するために使用されたURLを返します。

socket.readyState

WebSocket接続の状態を返します。上記で説明した値を取ることができます。

socket.bufferedAmount

send() を使用してキューに入れられたがまだネットワークに送信されていないアプリケーションデータ（UTF-8テキストおよびバイナリデータ）のバイト数を返します。

WebSocket接続が閉じられている場合、この属性の値はsend() メソッドの呼び出しごとに増加するだけです。（接続が閉じた後にゼロにリセットされることはありません。）

socket.extensions

サーバーによって選択された拡張機能を返します（存在する場合）。

socket.protocol

サーバーによって選択されたサブプロトコルを返します（存在する場合）。これは、コンストラクタの第2引数の配列形式と組み合わせてサブプロトコルのネゴシエーションを行うために使用できます。

socket.binaryType

socketからスクリプトに公開されるバイナリデータを示す文字列を返します:

"blob": バイナリデータはBlob 形式で返されます。
"arraybuffer": バイナリデータはArrayBuffer 形式で返されます。

デフォルトは"blob"です。

socket.binaryType = value

バイナリデータの返され方を変更します。

new
 WebSocket(url, protocols)

コンストラクタの手順は以下の通りです:

baseURLをthisの関連する設定オブジェクトのAPIベースURLとします。
urlRecordを、urlにbaseURLを適用してURLパーサーを実行した結果とします。
もしurlRecordが失敗ならば、"SyntaxError" DOMException をスローします。
もしurlRecordのスキームが"http"ならば、 urlRecordのスキームを"ws"に設定します。
それ以外の場合、もしurlRecordのスキームが"https"ならば、 urlRecordのスキームを"wss"に設定します。
もしurlRecordのスキームが "ws"または "wss"でない場合、 "SyntaxError" DOMException をスローします。
もしurlRecordのフラグメントが非nullならば、"SyntaxError" DOMException をスローします。
もしprotocolsが文字列ならば、protocolsをその文字列だけを含むシーケンスに設定します。
もしprotocols内の値のいずれかが複数回出現するか、または `Sec-WebSocket-Protocol`フィールドの値を構成する要素の要件に一致しない場合、 "SyntaxError" DOMException をスローします。 [WSP]
thisのurlをurlRecordに設定します。
clientをthisの関連する設定オブジェクトとします。
この手順を並列で実行します:
1. urlRecord、protocols、およびclientを与えて WebSocket接続を確立します。 [FETCH]
  
  もし WebSocket接続を確立するアルゴリズムが失敗した場合、それはWebSocket接続を失敗させるアルゴリズムをトリガーし、それはWebSocket接続を閉じるアルゴリズムを呼び出し、それがWebSocket接続が閉じられることを確立し、それが以下に記載されているように close イベントを発生させます。

The urlのgetter手順は、thisの urlをシリアライズして返します。

The readyStateのgetter手順は、thisの ready stateを返します。

The extensions属性は初期状態では空文字列を返さなければなりません。 WebSocket接続が確立された後、その値が変更されることがあります（以下参照）。

The protocol属性は初期状態では空文字列を返さなければなりません。 WebSocket接続が確立された後、その値が変更されることがあります（以下参照）。

The close(code, reason)メソッドの手順は以下の通りです:

もしcodeが存在し、1000に等しい整数でも3000から4999（含む）の範囲内の整数でもない場合は、 "InvalidAccessError" DOMException をスローします。
もしreasonが存在する場合、以下のサブステップを実行します:
1. reasonBytesをreasonをUTF-8でエンコードした結果とします。
2. もしreasonBytesの長さが123バイトを超える場合、 "SyntaxError" DOMException をスローします。
以下のリストから最初に一致する手順を実行します:

もしthisのready stateが CLOSING (2)またはCLOSED (3)の場合

何もしません。

接続はすでに閉じようとしているか、すでに閉じられています。もしまだであれば、close イベントが最終的に以下に記載されているように発生します。

もしWebSocket接続がまだ確立されていない [WSP]場合

WebSocket接続を失敗させ、 thisのready stateを CLOSING (2)に設定します。 [WSP]

WebSocket接続を失敗させるアルゴリズムは、 WebSocket接続を閉じるアルゴリズムを呼び出し、それがWebSocket接続が閉じられることを確立し、 close イベントを以下に記載されているように発生させます。

もしWebSocketのクローズハンドシェイクがまだ開始されていない [WSP]場合

WebSocketのクローズハンドシェイクを開始し、 thisのready stateを CLOSING (2)に設定します。 [WSP]

もしcodeとreasonのどちらも存在しない場合、WebSocketのCloseメッセージはボディを持ってはなりません。

WebSocket Protocolは、WebSocketのクローズハンドシェイクを開始アルゴリズムのステータスコードが必須であると誤って記述しています。

もしcodeが存在する場合、WebSocketのCloseメッセージに使用されるステータスコードはcodeによって与えられる整数でなければなりません。 [WSP]

もしreasonも存在する場合、reasonBytesはCloseメッセージのステータスコードの後に提供されなければなりません。 [WSP]

WebSocketのクローズハンドシェイクを開始アルゴリズムは最終的に WebSocket接続を閉じるアルゴリズムを呼び出し、それがWebSocket接続が閉じられることを確立し、 close イベントを以下に記載されているように発生させます。

その他の場合

thisのready stateを CLOSING (2)に設定します。

WebSocketのクローズハンドシェイクが開始され、最終的に WebSocket接続を閉じるアルゴリズムを呼び出し、それがWebSocket接続が閉じられることを確立し、 close イベントが発生します。以下に記載されているように。

close() メソッドは、WebSocketクローズハンドシェイクを開始する前に以前送信したメッセージを破棄しません。実際には、ユーザーエージェントがそれらのメッセージの送信にまだ忙しい場合でも、ハンドシェイクはメッセージの送信が完了した後にのみ開始されます。

bufferedAmountのgetter手順は、send() を使用してキューに入れられた、しかしイベントループがステップ1に到達した時点でまだネットワークに送信されていないアプリケーションデータ（UTF-8テキストおよびバイナリデータ）のバイト数を返します。（これは、スクリプトの実行中に送信されたテキストを含みます。ユーザーエージェントがスクリプトの実行と並列でテキストを送信できるかどうかに関係なく）。これは、プロトコルによって発生するフレーミングオーバーヘッドや、オペレーティングシステムやネットワークハードウェアによるバッファリングを含みません。

この簡単な例では、bufferedAmount 属性を使用して、ネットワークがその速度を処理できる場合は50msごとに1回の更新を送信し、そうでない場合はネットワークが処理できる任意の速度で更新を送信します。

var socket = new WebSocket('ws://game.example.com:12010/updates');
socket.onopen = function () {
  setInterval(function() {
    if (socket.bufferedAmount == 0)
      socket.send(getUpdateData());
  }, 50);
};

bufferedAmount 属性は、ネットワークが処理できる速度以上のデータを送信しないようにしながら、ネットワークを完全に使用するためにも利用できますが、これには時間の経過とともに属性値を注意深く監視する必要があります。

binaryTypeのgetter手順は、thisの binary typeを返します。

binaryType のsetter手順は、thisのbinary typeを the given valueに設定します。

ユーザーエージェントは、binary typeを使用して、受信したバイナリデータをどのように処理するかのヒントとして使用できます。 "blob" の場合、安全にディスクにスプールでき、 "arraybuffer" の場合、データをメモリに保持する方が効率的である可能性が高いです。当然のことながら、ユーザーエージェントは、受信したデータをメモリに保持するかどうかを決定するために、データのサイズやスクリプトが最後の瞬間に属性を変更する頻度などに基づいて、より微妙なヒューリスティックを使用することを推奨されます。特に重要なのは、ユーザーエージェントがデータを受信した後、イベントを発生させる前に属性が変更される可能性が十分にあるという点です。

send(data)メソッドの手順は以下の通りです:

もしthisのready stateがCONNECTING ならば、"InvalidStateError" DOMException をスローします。
以下のリストから適切な手順セットを実行します:

もしdataが文字列の場合

もしWebSocket接続が確立されており、 WebSocketクローズハンドシェイクがまだ開始されていない場合、ユーザーエージェントはdata引数をテキストフレームオペコードを使用して構成されたWebSocketメッセージを送信しなければなりません。データを送信できない場合（例：バッファリングが必要だがバッファが満杯の場合）、ユーザーエージェントはWebSocketをフルとしてフラグ付けし、その後WebSocket接続を閉じなければなりません。このメソッドが例外をスローせずに文字列引数で呼び出された場合、 bufferedAmount 属性をUTF-8として引数を表現するのに必要なバイト数だけ増加させなければなりません。 [UNICODE] [ENCODING] [WSP]

もしdataがBlob オブジェクトの場合

もしWebSocket接続が確立されており、 WebSocketクローズハンドシェイクがまだ開始されていない場合、ユーザーエージェントはdataをバイナリフレームオペコードを用いて構成されたWebSocketメッセージを送信しなければなりません。データを送信できない場合、ユーザーエージェントはWebSocketをフルとしてフラグ付けし、その後WebSocket接続を閉じなければなりません。送信されるデータはBlob オブジェクトが表す生データです。このメソッドが例外をスローせずにBlob 引数で呼び出された場合、 bufferedAmount 属性をBlob オブジェクトの生データのサイズ（バイト単位）だけ増加させなければなりません。 [WSP] [FILEAPI]

もしdataがArrayBuffer の場合

もしWebSocket接続が確立されており、 WebSocketクローズハンドシェイクがまだ開始されていない場合、ユーザーエージェントはdataをバイナリフレームオペコードを用いて構成されたWebSocketメッセージを送信しなければなりません。データを送信できない場合、ユーザーエージェントはWebSocketをフルとしてフラグ付けし、その後WebSocket接続を閉じなければなりません。送信されるデータは、ArrayBuffer オブジェクトが記述するバッファに格納されたデータです。このメソッドが例外をスローせずにArrayBuffer 引数で呼び出された場合、 bufferedAmount 属性をArrayBuffer の長さ（バイト単位）だけ増加させなければなりません。 [WSP]

もしdataがArrayBufferView の場合

もしWebSocket接続が確立されており、 WebSocketクローズハンドシェイクがまだ開始されていない場合、ユーザーエージェントはdataをバイナリフレームオペコードを用いて構成されたWebSocketメッセージを送信しなければなりません。データを送信できない場合、ユーザーエージェントはWebSocketをフルとしてフラグ付けし、その後WebSocket接続を閉じなければなりません。送信されるデータは、dataが参照するバッファのセクションに格納されたデータです。この種の引数でこのメソッドが例外をスローせずに呼び出された場合、 bufferedAmount 属性をdataのバッファの長さ（バイト単位）だけ増加させなければなりません。 [WSP]

以下は、イベントハンドラ（および対応するイベントハンドライベントタイプ）であり、イベントハンドラIDL属性として、 WebSocket インターフェースを実装するすべてのオブジェクトによってサポートされなければなりません:

イベントハンドラ	イベントハンドライベントタイプ
`onopen`	`open`
`onmessage`	`message`
`onerror`	`error`
`onclose`	`close`

4. プロトコルからのフィードバック

WebSocket接続が確立されたとき、ユーザーエージェントはタスクをキューに入れ以下の手順を実行しなければなりません:

ready stateをOPEN (1)に変更する。
extensions 属性の値を使用されている拡張機能に変更する。ただし、それがnull値でない場合に限る。 [WSP]
protocol 属性の値を使用されているサブプロトコルに変更する。ただし、それがnull値でない場合に限る。 [WSP]
イベントを発火し、名前をopenとし、WebSocket オブジェクトで行う。

上記のアルゴリズムはタスクとしてキューに入れられるため、WebSocket接続が確立されることと、スクリプトがopen イベントのためのイベントリスナーを設定する間に競合状態は発生しません。

WebSocketメッセージが受信され、タイプtypeとデータdataが存在する場合、ユーザーエージェントはタスクをキューに入れ以下の手順を実行しなければなりません: [WSP]

ready stateがOPEN (1)でない場合、終了する。
typeとbinary typeに基づいてdataForEventを決定する:

typeがテキストデータを示す場合

dataを含む新しいDOMString

typeがバイナリデータを示しbinary typeが "blob"の場合

新しいBlob オブジェクト。このオブジェクトはWebSocket オブジェクトの関連する領域内で作成され、dataをその生データとして表現します。 [FILEAPI]

typeがバイナリデータを示しbinary typeが "arraybuffer"の場合

新しいArrayBuffer オブジェクト。このオブジェクトはWebSocket オブジェクトの関連する領域内で作成され、その内容はdataです。
イベントを発火し、名前をmessageとし、WebSocket オブジェクトで行い、 MessageEvent を使用し、origin 属性をWebSocket オブジェクトのurlのoriginへのシリアライズに初期化し、data 属性をdataForEventに初期化する。

ユーザーエージェントは、上記の手順を効率的に実行できるかどうかをタスク実行前に確認し、バッファの準備中に他のタスクキューからタスクを選択することが推奨されます。例えば、データが到着した時点でbinary typeが"blob" であり、ユーザーエージェントがすべてのデータをディスクにスプールしていた場合、上記の特定のメッセージに対するタスクを実行する直前にスクリプトがbinary typeを"arraybuffer" に切り替えた場合、メインスレッドがArrayBuffer オブジェクトを作成する間にスタールしないよう、このタスクを実行する前にデータをRAMに戻すことを望むでしょう。

以下は、テキストフレームの場合におけるmessage イベントのハンドラーを定義する例です:

mysocket.onmessage = function (event) {
  if (event.data == 'on') {
    turnLampOn();
  } else if (event.data == 'off') {
    turnLampOff();
  }
};

ここでのプロトコルは単純で、サーバーは単に "on" または "off" のメッセージを送信するだけです。

WebSocketのクローズハンドシェイクが開始されるとき、ユーザーエージェントはタスクをキューに入れ ready stateをCLOSING (2)に変更しなければなりません。（close() メソッドが呼び出された場合、このタスクが実行されるときにはready stateはすでにCLOSING (2)に設定されています。）[WSP]

WebSocket接続が閉じられ、場合によっては正常に閉じられた場合、ユーザーエージェントはタスクをキューに入れ次のサブステップを実行しなければなりません:

ready stateをCLOSED (3)に変更する。
ユーザーエージェントがWebSocket接続を失敗させる必要があった場合、またはWebSocket接続が閉じられた後にフルとしてフラグ付けされた場合、イベントを発火し、名前をerrorとし WebSocket オブジェクトで行う。[WSP]
イベントを発火し、名前をcloseとし、WebSocket オブジェクトで行い、 CloseEvent を使用し、wasClean 属性を接続が正常に閉じられた場合にtrue、それ以外の場合はfalseに初期化し、code 属性をWebSocket接続終了コードに初期化し、reason 属性をUTF-8デコード（BOMなし）をWebSocket接続終了理由に適用した結果に初期化する。[WSP]

ユーザーエージェントは、スクリプトが以下の状況を区別できるような形で失敗情報を伝達してはなりません:

ホスト名が解決できなかったサーバー。
パケットを正常にルーティングできなかったサーバー。
指定されたポートで接続を拒否したサーバー。
TLSハンドシェイクを正しく実行できなかったサーバー（例: サーバー証明書を検証できない場合）。
オープニングハンドシェイクを完了しなかったサーバー（例: WebSocketサーバーでないため）。
正しいオープニングハンドシェイクを送信したが、クライアントが接続を切断する原因となるオプションを指定したWebSocketサーバー（例: サーバーがクライアントが提供しなかったサブプロトコルを指定した場合）。
オープニングハンドシェイクを正常に完了した後に接続を突然閉じたWebSocketサーバー。

これらすべての場合、WebSocket接続終了コードはWebSocket Protocolにより要求される通り1006となります。[WSP]

スクリプトがこれらのケースを区別できるようにすることは、攻撃の準備としてユーザーのローカルネットワークを調査することを可能にするでしょう。

特に、コード1015はユーザーエージェントによって使用されないことを意味します（ただし、サーバーが誤ってそのクローズフレーム内で使用した場合を除く）。

このセクションでキューに入れられるすべてのタスクのタスクソースはWebSocketタスクソースです。

5. PingとPongフレーム

WebSocketプロトコルでは、PingフレームとPongフレームが定義されており、キープアライブやハートビート、ネットワーク状態のプロービング、遅延の計測などに使用できます。これらは現在APIでは公開されていません。

ユーザーエージェントは、例えばローカルネットワークのNATマッピングを維持する試みとして、失敗した接続を検出するため、またはユーザーに遅延メトリクスを表示するために、Pingおよび未要求のPongフレームを任意に送信することができます。ユーザーエージェントは、サーバーを支援するためにPingや未要求のPongを使用してはなりません。サーバーが必要に応じてPongを要求することが前提とされています。

6. `CloseEvent` インターフェース

WebSocket オブジェクトは、CloseEvent インターフェースをclose イベントに使用します:

[Exposed=(Window,Worker)]
interface CloseEvent : Event {
  constructor(DOMString type, optional CloseEventInit eventInitDict = {});

  readonly attribute boolean wasClean;
  readonly attribute unsigned short code;
  readonly attribute USVString reason;
};

dictionary CloseEventInit : EventInit {
  boolean wasClean = false;
  unsigned short code = 0;
  USVString reason = "";
};

event . wasClean: 接続が正常に閉じられた場合はtrueを、それ以外の場合はfalseを返します。
event . code: サーバーによって提供されたWebSocket接続終了コードを返します。
event . reason: サーバーによって提供されたWebSocket接続終了理由を返します。

wasClean 属性は初期化された値を返さなければなりません。これは接続が正常に閉じられたかどうかを表します。

code 属性は初期化された値を返さなければなりません。これはサーバーによって提供されたWebSocket接続終了コードを表します。

reason 属性は初期化された値を返さなければなりません。これはサーバーによって提供されたWebSocket接続終了理由を表します。

7. ガベージコレクション

WebSocket オブジェクトで、そのready stateが最後にイベントループがステップ1に到達した時点でCONNECTING (0)に設定されていた場合、openイベント、 messageイベント、errorイベント、またはcloseイベントのために登録されたイベントリスナーが存在する場合、ガベージコレクションされてはなりません。

WebSocket オブジェクトで、そのready stateが最後にイベントループがステップ1に到達した時点でOPEN (1)に設定されていた場合、messageイベント、errorイベント、またはcloseイベントのために登録されたイベントリスナーが存在する場合、ガベージコレクションされてはなりません。

WebSocket オブジェクトで、そのready stateが最後にイベントループがステップ1に到達した時点でCLOSING (2)に設定されていた場合、errorイベントまたはcloseイベントのために登録されたイベントリスナーが存在する場合、ガベージコレクションされてはなりません。

WebSocket オブジェクトで、確立された接続があり、ネットワークに送信されるデータがキューに入れられている場合、ガベージコレクションされてはなりません。 [WSP]

接続がまだ開いている間にWebSocket オブジェクトがガベージコレクションされた場合、ユーザーエージェントはWebSocketのクローズハンドシェイクを開始しなければならず、Closeメッセージにはステータスコードを指定しません。 [WSP]

ユーザーエージェントが消失させるWebSocket オブジェクト（これはDocument オブジェクトが消失する場合に発生します）である場合、ユーザーエージェントは以下のリストから最初に該当する手順セットを実行しなければなりません:

WebSocket接続がまだ確立されていない場合 [WSP]: WebSocket接続を失敗させる。[WSP]
WebSocketのクローズハンドシェイクがまだ開始されていない場合 [WSP]: WebSocketのクローズハンドシェイクを開始し、WebSocket Closeメッセージで使用されるステータスコードを1001とする。 [WSP]
それ以外の場合: 何もしない。

謝辞

この現行標準が2021年に作成されるまで、ここにあるテキストはHTML現行標準とFetch現行標準で管理されていました。これらのリポジトリに貢献し、仕様の開発を助けてくださったすべての方々、特にそれぞれのオリジナル作者であるIan Hickson氏とAnne van Kesteren氏に感謝します。

devsnek氏と平野裕 (Yutaka Hirano)氏にも、WebSockets標準の作成後の貢献に感謝します。

この標準はAdam Rice氏 (Google, ricea@chromium.org) によって執筆されています。

知的財産権

著作権 © WHATWG (Apple, Google, Mozilla, Microsoft)。この作業はクリエイティブ・コモンズ表示 4.0 国際ライセンスの下でライセンスされています。ソースコードに組み込まれた部分については、それらの部分はBSD 3-Clauseライセンスの下でライセンスされています。

これは現行標準です。特許レビュー版に興味がある方は、現行標準レビュー草案をご覧ください。

WebSockets

概要

1. 序章

2. WebSocketプロトコルの変更

2.1. 接続

2.2. オープニングハンドシェイク

3. `WebSocket` インターフェイス

3.1. インターフェイス定義

4. プロトコルからのフィードバック

5. PingとPongフレーム

6. `CloseEvent` インターフェース

7. ガベージコレクション

謝辞

知的財産権

索引

この仕様により定義された用語

参照により定義された用語

参照

規範参照

IDL索引

WebSockets

概要

1. 序章

2. WebSocketプロトコルの変更

2.1. 接続

2.2. オープニングハンドシェイク

3. WebSocket インターフェイス

3.1. インターフェイス定義

4. プロトコルからのフィードバック

5. PingとPongフレーム

6. CloseEvent インターフェース

7. ガベージコレクション

謝辞

知的財産権

索引

この仕様により定義された用語

参照により定義された用語

参照

規範参照

IDL索引

3. `WebSocket` インターフェイス

6. `CloseEvent` インターフェース