プロキシ経由の WebSocket 再接続後はセッションも復元する

再接続コールバックが実行され、新しいソケットが開きます。それはトランスポートの回復です。購読、メッセージの確認応答、アプリケーションセッションが前の接続が止まったところから続いたとは限りません。

同じプロキシエンドポイントでも新しい外向き接続が生まれることがあります。出口 IP が変われば、宛先側の独自のセッションポリシーが作動することもあります。新しいソケットは新しい接続として扱い、アプリケーションの文書化された復元手順に従ってください。再接続時にワークフローがプロキシ経路を保持すべきかどうかを決めてください。

最後の URL より少し多く保持する

有用な復元状態には、認可されたセッション ID、望ましい購読、最後に確認されたイベント識別子、確認応答を待っている操作を含められます。これらの項目はアプリケーションのプロトコルに属します。WebSocket は普遍的な再開トークンを定義していません。

カーソルから再開するか、新しいスナップショットを取得するか、欠落を受け入れるかを決めてください。イベントソースが再生インターフェースを提供しない場合、より速く再接続してもメッセージが失われていないことは証明できません。

二度送ることは二度実行することを意味しうる

切断前にローカルでキューに入ったメッセージは、クライアントから出ていない可能性があります。別のメッセージは確認応答が失われたままサーバーに届いた可能性があります。未確認のコマンドをすべて盲目的に再送すると、この二つの場合を同一視してしまいます。

利用できる場合は、サービスのリクエスト識別子、冪等性のサポート、または突き合わせの仕組みを使ってください。トランスポートの再接続は、アプリケーションの操作を可逆にしたり、自動的に重複排除したりはできません。

再接続の試行は上限を設け、アプリケーションのポリシーに従って間隔を空けてください。RFC 6455 は異常終了後のバックオフを推奨しています。一斉に即時再試行するクライアント群は障害時の負荷を増やしかねません。

各試行が選んだプロキシ経路を記録しますが、経路の復元はアプリケーションの復元とは分けてください。「再接続した」は有用な証拠です。「追いついて、さらに作業を送る準備ができた」には、それを確立する追加のアプリケーション交換が必要です。