nginxプロキシsocket.ioサービスの落とし穴の詳細な説明

nginx 経由でサービスをリクエストすると、大量の 400 エラーが発生していました。Websocket にアップグレードできる場合もあれば、エラーが報告され続ける場合もありました。ただし、 ip+端口を介して直接アクセスすると、100% 成功します。

分析する

シド

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

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

メッセージを受信した後、サーバーはオブジェクトを作成し、それを接続にバインドし、セッションをマークするための sid (セッション ID) を返します。セッションとは何を意味するのでしょうか? セッションとは一連のインタラクションであり、これらのインタラクションは相互に関連しています。このシナリオでは、次の http リクエストが来たときに、以前に理論上の長い接続にバインドされていたオブジェクトを見つける必要があります (ここでは Websocket がないので、理論上のものです)。 HTTP リクエストはステートレスであり、各リクエストは独立していることがわかっているので、socket.io ではこれを実現するために SID を導入しています。リクエストを受信すると、サーバーは sid を生成し、応答を確認します。

次のようにコードをコピーします。

 {"sid":"EoGaL3fRQlpTOaLp5eST","アップグレード":["websocket"],"pingInterval":8000,"pingTimeout":10000}

後続の各リクエストでは、Websocket リクエストを確立するためのリクエストも含め、この sid を送信する必要があります。したがって、sid はポーリングとポーリングを Websocket にアップグレードするための鍵となります。この後のリクエストは次のようになります。

https://***/?EIO=3&transport=polling&t=1540820717314-1&sid=EoGaL3fRQlpTOaLp5eST

または

wss://***/?EIO=3&transport=websocket&t=1540820717314-1&sid=EoGaL3fRQlpTOaLp5eST

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

無効なSID

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

解決する

ここに2つの解決策があります

Nginx は負荷分散に ip_hash を使用し、クライアントからのすべてのリクエストが 1 つのサーバーに送信されるようにします。
ポーリングモードは使用せず、WebSocketのみを使用してください

どちらの選択肢にも長所と短所があります。 2 番目は明らかで、Websocket をサポートしていない古いブラウザやクライアントは動作しません。最初の問題は、より隠れたものです。マシンを追加または削除するとどうなるか想像してみてください。このとき、ip_hash 戦略のモデルが変更され、以前の接続はすべて無効になります。ただし、マイクロサービスの場合、スケーリングは非常に頻繁に行われる操作であり (特に製品が開発段階にある場合)、このような損失のあるスケーリングはおそらく受け入れられません。

まとめると、websocket を直接使用することをお勧めします。結局のところ、websocket をサポートしていない古いバージョンはわずかな割合を占めており、最初にポーリングするよりも時間がかかりません。

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。

以下もご興味があるかもしれません: