Websocketについて読むとき、ハートビートは通常、必要なものとして言及されています。 MDNは ハートビートの特別なオペコード についても記述しています。
しかし、ハートビートはWebSocketの必須部分ですか?私はそれを実装する必要がありますか、そうでなければ私のWebソケットはブラウザや他の標準によって終了しますか?
WebSocketプロトコルの現在の参照である RFC 6455 は、WebSocketに関する状態を通信するためのいくつかのコントロールフレームを定義します。
0x8
0x9
0xA
PingとPongはheartbeatに使用され、クライアントがまだ応答しているかどうかを確認できます。以下の quote を参照してください。
Pingフレームは、キープアライブとして、またはリモートエンドポイントがまだ応答していることを確認する手段として機能します。
ただし、クライアントがPingを取得すると、Pongをサーバーに送り返す必要があります。 quote を参照してください:
Pingフレームを受信すると、エンドポイントは、既にCloseフレームを受信していない限り、応答としてPongフレームを送信する必要があります。実用的であるとすぐにPongフレームで応答する必要があります。
bothクライアントとサーバーの両方を設計するとき、ハートビートのサポートはあなた次第です。ただし、接続がまだ有効かどうかを確認する必要がある場合は、PingフレームとPongフレームが標準的な方法です。
Pingが送信され、Pongが返送されない場合、一方のピアはもう一方のピアがもう生きていないと想定する可能性があることに注意してください。
これは必須であるか、クライアントとサーバーの実装に依存しません。 PONGでPINGに応答する必要があるサーバーに接続している場合、返信しない場合はおそらく切断されます。あなたがサーバーであり、クライアントがPINGを送信している場合も同じです。
サーバーとクライアントの実装はさまざまです(無数にあります)が、ブラウザーのjavascriptクライアントはPINGを送信せず、PONGを使用してPINGに応答しますが、そうするためのAPIも提供しません。
ピンとピンポンは必須ではありません。これらは、ドロップされた接続を検出できるため便利です。 (回線上のトラフィックがなければ、接続の切断を検出する方法はありません。)
ブラウザーでは、WebSocketハートビートにアクセスできないことに注意してください。切断された接続を検出するためにブラウザクライアントコードが必要な場合は、アプリケーションレベルでハートビートを実装する必要があります。