プロキシ経由の WebSocket Ping と TCP Keepalive の比較
生きた TCP ソケットをアプリケーション経路が応答している証拠と見なすのではなく、WebSocket ピアの生存確認を選びましょう。
生きた TCP ソケット、応答する WebSocket ピア、有用なアプリケーションの進捗は、それぞれ別の観測です。
| 証拠 | 何を立証するか |
|---|---|
| TCP レベルの生存 | 検査したトランスポート経路がそのレベルで応答する |
| 一致する WebSocket Pong | ピアがその制御フレームに応答した |
| アプリケーションの確認応答 | アプリケーションが独自プロトコルで操作を確認した |
フォワードプロキシは通常、クライアント側と宛先側で別々の接続を維持します。クライアントの TCP ピアはプロキシであり、確立済みトンネル内の Ping は WebSocket エンドポイントまで届きます。
一致する Pong
プロトコルは、応答する Pong が Ping のアプリケーションデータを運ぶことを要求します。この対応を使って未完了の検査を特定します。要求されていない Pong は許容されますが、確認応答を求めません。各データメッセージの後に送ると別の証拠になります。
ライブラリが対応するハートビート機構を優先してください。ブラウザの JavaScript は代わりにアプリケーション層のハートビート契約を必要とします。間隔と失敗しきい値はワークロードとネットワークポリシーに合わせて選びます。スケジューリングの停止や過負荷のイベントループは、ネットワーク障害を立証しないまま厳しいしきい値を外すことがあります。
受信側を動かし続ける
クライアントは制御フレームを受信して処理するために継続的な入出力を必要とします。その仕組みを止めると、ローカルな逼迫が障害のように見えることがあります。
Ping はトンネルのトラフィックを生みますが、各中間装置が自分のアイドル方針を満たすものを決めます。絶対的な接続寿命の上限に対する保護を保証するハートビートはありません。
ピアはアプリケーションが更新の生成を止めても Ping に応答でき、静かな購読が健全なこともあります。両方が重要な場合は、最後の有効な Pong と意味のあるアプリケーションイベントを別々に追跡してください。失敗時には経路、経過時間、未完了の検査を保持し、対応しているライフサイクルを通じて閉じるか復旧します。