[解決済み] WebSocketsのピン/ポン、なぜTCPキープアライブではないのですか？

疑問点

ウェブソケット オプションがある というオプションがあり、相手側に ping を送信し、相手側が pong で応答することになっています。

Ping フレームを受信すると、エンドポイントはその応答として Pong フレームを送信しなければなりません (MUST)。 ただし、すでに Close フレームを受信している場合を除きます。 エンドポイントは はできるだけ早く Pong フレームで応答すべきです。

TCP は似たようなものを提供します をキープアライブという形で提供しています。

[データが入っておらず、ACKフラグがオンになっているkeepaliveプローブパケットを相手に送ります。TCP/IPの仕様上、一種の重複したACKとしてこれを行うことができ、TCPはストリーム指向のプロトコルであるため、リモートエンドポイントは何も引数を持ちません。一方、リモートホスト（TCP/IPだけで、キープアライブをサポートする必要は全くありません）からの応答は、データなしで、ACKが設定されたものを受け取ることになります。

なぜなら、ユーザー空間までデータを転送し、websocket フレームを解析し、応答フレームを作成し、送信のためにカーネルにデータを戻す必要がないからです。また、ネットワーク トラフィックも少なくなります。

さらに、WebSocket は は明示的に指定された トランスポートレイヤーに依存しないため、TCP キープアライブが常に利用可能です。

WebSocket プロトコルは、独立した TCP ベースのプロトコルです。

では、なぜ TCP キープアライブの代わりに WebSocket のピン/ポンを使おうと思ったのでしょうか?

どのように解決するのですか?

TCPキープアライブの問題点は。

1. デフォルトではオフになっています。
2. Ping/Pongプロトコルが提供するオンデマンドではなく、デフォルトで2時間間隔で動作します。
3. エンドツーエンドではなく、プロキシ間で動作します。
4. DavidSchwartz によって指摘されたように、アプリケーション間ではなく TCP スタック間で動作するため、アプリケーションが生きているかどうかを知ることはできません。

WebSocket の ping/pong との比較は意味がありません。TCP キープアライブは、有効になると自動的に時間指定されるのに対し、WebSocket の ping/pong はアプリケーションによって要求されると実行されます。