仕様書

構文

[2] opcode は、 0x9 です >>1。 Pingフレームは、制御フレームです。

[3] 応用データを含めて構いません >>1。 応用データは特に規定がなく、任意のバイト列で良いようです。 ただし制御フレームの長さ制限から、125バイト以下でなければなりません。

文脈

[5] WebSocket接続の確立の後、任意の時機に送信できます >>1。

[6] keepalive としても、相手がまだ反応するか検証する手段としても使えます >>1。

[8] 利用者エージェントは、必要に応じて (NAT に接続を保持させるため、 接続の切断を検出するためなどの目的で) Pingフレームを送信して構いません >>7。 しかしサーバーを助ける目的で送信してはなりません >>7。

サーバーは必要があるなら自身で適宜送信するべきです。[9] これは fingerprinting vector かもしれません。

[16] Chrome も Firefox も、(少なくても数時間以内には) PingフレームやPongフレームを自発的に送信することはないようです。

[17] Firefox は送信・設定できるようにしたようですが >>12、 その後 TCP keep alive が実装されたことで使われなくなったと思われます。

処理

[4] Pingフレームを受信したら、既に Closeフレームを受信した場合を除き、 Pongフレームを送信しなければなりません。 これはできるだけすぐに送信するべきです。 >>1 応用データを返送しなければなりません。 複数受信した場合は、最後のものにのみ返信することとしても構いません。

[11] Chrome も Firefox も、すべてに順に返信しているように見えます。

[21] Webブラウザーの WebSocket API は Pingフレームや Pongフレームを扱う手段を一切提供していません。 JavaScript 側で扱うべきものではなく、プロトコルの内部処理に過ぎないと考えられています。

[22] Webサーバー側の API や、Webブラウザー以外のクライアントの API は、 Pingフレームや Pongフレームを扱う手段を提供できます。 しかしアプリケーションのデータはすべてテキストフレームやバイナリーフレームで送受信するべきで、 PingフレームやPongフレームがアプリケーションの処理に影響するべきではありません。

関連

[10] HTTP/2 では PING フレーム (ACK 未設定) に相当します。

歴史

[12] 855906 – Set pingInterval on websocket ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=855906

[13] 849364 – Provide per-websocket way to enable keepalive pings ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=849364

[14] 894879 – SimplePush: Adaptive ping for WebSocket ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=894879

[15] 13104 – Enable keepalive on WebSocket API ( 版) https://www.w3.org/Bugs/Public/show_bug.cgi?id=13104

[18] Bitfinex API Reference () http://docs.bitfinex.com/#info-messages

Ping/Pong

// request

{

"event":"ping"

}

// response

{

"event":"pong"

}

Use ping message to test your connection to the websocket server.

[19] Bitfinex API Reference () http://docs.bitfinex.com/#heartbeating

Heartbeating

["<Chan Id>", "hb"]

If there is no new message in the channel for 1 second, Websocket server will send you an heartbeat message in this format.

[20] RFC 7977 - The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP) () https://tools.ietf.org/html/rfc7977#section-6

It is RECOMMENDED that MSRP WebSocket Clients and Servers keep their

WebSocket connections open by sending periodic WebSocket "Ping"

frames as described in Section 5.5.2 of [RFC6455].

The WebSocket API [WS-API] does not provide a mechanism for

applications running in a web browser to control whether or not

periodic WebSocket "Ping" frames are sent to the server. The

implementation of such a keepalive feature is the decision of each

web browser manufacturer and may also depend on the configuration of

the web browser.

A future WebSocket protocol extension providing a similar keepalive

mechanism could also be used.

When MSRP WebSocket Clients or Servers cannot use WebSocket "Ping"

frames to keep connections open, an MSRP implementation MAY use

bodiless SEND requests as described in Section 7.1 of [RFC4975].

MSRP WebSocket Clients or Servers MUST be prepared to receive

bodiless SEND requests.

[23] 机「9」文字事件 - Wikipedia () https://ja.wikipedia.org/wiki/%E6%9C%BA%E3%80%8C9%E3%80%8D%E6%96%87%E5%AD%97%E4%BA%8B%E4%BB%B6