従来のWebサーバー上で実行されているWebアプリケーションを配備する場合、通常はコードの更新後にWebサーバーを再起動します。 HTTPの性質上、これはユーザーにとって問題ではありません。次のリクエストで最新のアップデートを入手します。WebSocketサーバーを配備する方法は？
しかし、WebSocketサーバーはどうですか？古いプロセスを再起動または強制終了すると、接続されているすべてのユーザーが切断されます。ですから、私の質問は、WebSocketサーバーを円滑に展開するためにどのような戦略を使用していますか？
正常です。サーバが再起動すると、接続されているすべてのユーザが切断されます。
クライアントのonCloseメソッドで再接続するようにクライアントに指示するのが悪い解決策だと思います。
クライアントがすべてのソケットネットワーキングおよびアプリケーションロジックを実行するサーバーに直接接続されている場合は、接続を保持するTCPレイヤーによって接続が切断されます。
クライアントに接続するゲートウェイがあり、そのゲートウェイアプリケーションが別のサーバー上で実行されているが、通信して論理サーバーにメッセージを転送する場合、論理サーバーはそれらを戻し、ゲートウェイはクライアントの応答に返信します。このようなインフラストラクチャでは、論理サーバーとの接続を再確立するまで、パケットをスタッキングしてゲートウェイに実装する必要があります。論理サーバーは、再起動する前にゲートウェイサーバーに通知することがあります。そうすれば、クライアントは接続を持っています。ただ応答がありません。
また、クライアント側の再接続で実装することもできます。 HTTPを使用すると、移動するたびにブラウザは実際にサーバーとのソケット接続を作成し、すべてのデータを送信して閉じます（ほとんどの場合）。そしてあなたが離れて行くまで、すべてのウェブサイトのデータはローカルです。
ウェブソケットを使用すると、継続的な接続であり、要求の再接続はありません。なぜWebSocketがクロージングイベントを受け取ったときに、クライアント側で定期的に再接続を試みるかという簡単な仕組みを実装しなければならない理由があります。
これは具体的なニーズに基づいています。
WebSocketsは単なるトランスポートメカニズムです。 socket.ioのようなライブラリが存在し、ハートビート、ブラウザフォールバック、優雅な再接続を提供し、リアルタイムアプリケーションに見られる他のエッジケースを処理します。
WebSocket対応のアプリケーションでは、socket.ioは、継続的な配備設定がユーザーのアクティブなソケット接続を壊さないようにするための中心的な役割を果たします。