生きた TCP ソケット、応答する WebSocket ピア、有用なアプリケーションの進捗は、それぞれ別の観測です。

証拠何を立証するか
TCP レベルの生存検査したトランスポート経路がそのレベルで応答する
一致する WebSocket Pongピアがその制御フレームに応答した
アプリケーションの確認応答アプリケーションが独自プロトコルで操作を確認した

フォワードプロキシは通常、クライアント側と宛先側で別々の接続を維持します。クライアントの TCP ピアはプロキシであり、確立済みトンネル内の Ping は WebSocket エンドポイントまで届きます。

一致する Pong

プロトコルは、応答する Pong が Ping のアプリケーションデータを運ぶことを要求します。この対応を使って未完了の検査を特定します。要求されていない Pong は許容されますが、確認応答を求めません。各データメッセージの後に送ると別の証拠になります。

ライブラリが対応するハートビート機構を優先してください。ブラウザの JavaScript は代わりにアプリケーション層のハートビート契約を必要とします。間隔と失敗しきい値はワークロードとネットワークポリシーに合わせて選びます。スケジューリングの停止や過負荷のイベントループは、ネットワーク障害を立証しないまま厳しいしきい値を外すことがあります。

受信側を動かし続ける

クライアントは制御フレームを受信して処理するために継続的な入出力を必要とします。その仕組みを止めると、ローカルな逼迫が障害のように見えることがあります。

Ping はトンネルのトラフィックを生みますが、各中間装置が自分のアイドル方針を満たすものを決めます。絶対的な接続寿命の上限に対する保護を保証するハートビートはありません。

ピアはアプリケーションが更新の生成を止めても Ping に応答でき、静かな購読が健全なこともあります。両方が重要な場合は、最後の有効な Pong と意味のあるアプリケーションイベントを別々に追跡してください。失敗時には経路、経過時間、未完了の検査を保持し、対応しているライフサイクルを通じて閉じるか復旧します。

関連記事