nginxプロキシsocket.ioサービスの落とし穴を解決する方法

nginx は 2 つのsocket.io サーバーのプロキシとして機能します。 socket.io の動作モードは、ポーリングと websocket へのアップグレードです

現象

nginx 経由でサービスをリクエストすると、大量の 400 エラーが表示されます。 WebSocket にアップグレードされました。時々、エラーが報告され続けることがあります。ただし、ip ポート 経由で直接アクセスすると、100% 成功します。

分析

sid

sid が問題の鍵です。最初に接続を作成するとき (ポーリング モードは長い接続をシミュレートします)、クライアントは次のようなリクエストを開始します:

https://***/?eio=3&transport=polling&t=1540820717277-0

それを受信した後、サーバーはオブジェクトを作成し、それを接続にバインドし、セッションをマークするための sid (セッション ID) を返します。セッションとは何を指しますか? セッションは一連のインタラクションであり、これらのインタラクションは関連しています。私たちのシナリオでは、次の http リクエストが来たときに、以前に理論にバインドされていた長い接続を見つける必要があります (ここではまだ説明されていません) ) websocket なので理論上)。 http リクエストはステートレスであり、各リクエストは独立していることがわかっているため、socket.io はこれを行うために sid を導入しました。サーバーはリクエストを受信した後に SID を生成します。レスポンスを見てください:

コードをコピーします。コードは次のとおりです:

{"sid":"eogal3frqlptoalp5est","upgrades":[ "websocket"] ,"pinginterval":8000,"pingtimeout":10000}

後続のすべてのリクエストではこの SID が必要であり、WebSocket リクエストを確立するための接続も例外ではありません。したがって、sid はポーリングとポーリングを WebSocket にアップグレードするための鍵となります。この後のリクエストは次のようになります:

https://***/?eio=3&transport=polling&t=1540820717314-1&sid=eogal3frqlptoalp5est

or

wss://***/?eio=3&transport=websocket&t=1540820717314-1&sid=eogal3frqlptoalp5est

次に質問は、リクエスト内の sid がサーバーによって生成されなかった場合はどうなるかということです。サーバーはそれを認識せず、400 を返し、

invalid sid

これが私たちが遭遇した問題です。nginx のデフォルトの負荷分散戦略はポーリングであるため、リクエストは生成されない可能性があります。この SID を持つマシンに移動すると、この時点で 400 を受信します。運が良ければ、元のマシンに送信される可能性があります。運が良ければ、WebSocket 接続が確立されるまで持続することもできます。

ソリューション

ここでは 2 つのソリューションを提案します

1. nginx の負荷分散は、クライアントのリクエストを保証できる ip_hash を使用します。 1 つのサーバーに接続する

2. ポーリング モードを使用せず、WebSocket のみを使用します

どちらのオプションにもそれぞれ長所と短所があります。 2 番目の明らかな点は、WebSocket をサポートしていない古いブラウザとクライアントは動作しないことです。最初のタイプの問題は、さらに奥深くに隠されています。マシンを追加または削除すると何が起こるかを想像してみてください。このとき、ip_hash ポリシーのモードが変更され、以前のすべての接続が無効になります。マイクロサービスの場合、拡張と縮小は非常に重要です。操作が頻繁に行われる場合 (特に製品が開発段階にある場合)、この種の損失を伴う拡張や縮小はおそらく許容できません。

以上がnginxプロキシsocket.ioサービスの落とし穴を解決する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。