Detaillierte Erläuterung der Fallstricke des Nginx-Proxy-Socket.io-Dienstes

Nginx fungiert als Proxy für zwei socket.io-Server. Der Arbeitsmodus von socket.io ist Polling und wurde auf WebSocket aktualisiert.

Phänomen

Beim Anfordern von Diensten über nginx traten zahlreiche 400-Fehler auf. Manchmal konnten sie auf WebSocket aktualisiert werden, und manchmal meldeten sie weiterhin Fehler. Aber beim direkten Zugriff über ip+端口ist die Erfolgsquote 100 %.

analysieren

Seite

SID ist der Schlüssel zu unserem Problem. Beim ersten Herstellen einer Verbindung (der Polling-Modus simuliert eine lange Verbindung) initiiert der Client eine Anfrage wie diese:

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

Nach Erhalt der Nachricht erstellt der Server ein Objekt, bindet es an die Verbindung und gibt eine SID (Sitzungs-ID) zurück, um die Sitzung zu markieren. Was bedeutet eine Sitzung? Eine Sitzung ist eine Reihe von Interaktionen, und diese Interaktionen sind miteinander verknüpft. In unserem Szenario muss ich bei der nächsten HTTP-Anforderung das Objekt finden, das zuvor an die theoretisch lange Verbindung gebunden war (hier gibt es keinen WebSocket, es ist also theoretisch). Wir wissen, dass HTTP-Anfragen zustandslos sind und jede Anfrage unabhängig ist, daher führt socket.io zu diesem Zweck SID ein. Nach Erhalt der Anfrage generiert der Server eine SID und sieht sich die Antwort an:

Jede nachfolgende Anfrage muss diese SID enthalten, einschließlich der Anfrage zum Erstellen einer WebSocket-Anfrage. Daher ist Sid der Schlüssel zum Polling und zum Upgraden des Pollings auf Websocket. Die Anfrage danach sieht folgendermaßen aus:

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

oder

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

Die Frage ist also, was passiert, wenn die in der Anforderung enthaltene SID nicht vom Server generiert wird? Der Server erkennt es nicht und gibt eine 400 zurück und sagt Ihnen

ungültige Seite

Dies ist das Problem, auf das wir gestoßen sind. Die standardmäßige Lastausgleichsstrategie von nginx ist Polling, sodass die Anforderung möglicherweise auf einem Computer eintrifft, der nicht derjenige ist, der die SID generiert hat. Zu diesem Zeitpunkt erhalten wir eine 400. Wenn wir Glück haben, kann sie auch auf dem ursprünglichen Computer eintreffen. Wenn wir mehr Glück haben, können wir sogar so lange weitermachen, bis die WebSocket-Verbindung hergestellt ist.

lösen

Hier sind zwei Lösungen

1. Nginx verwendet ip_hash zum Lastenausgleich, wodurch sichergestellt wird, dass alle Anfragen eines Clients an einen Server gehen.
2. Verwenden Sie keinen Polling-Modus, sondern nur WebSocket

Beide Optionen haben ihre Vor- und Nachteile. Der zweite Grund liegt auf der Hand: Alte Browser und Clients, die WebSockets nicht unterstützen, funktionieren nicht. Das erste Problem ist eher versteckt. Stellen Sie sich vor, was passieren würde, wenn Sie Maschinen hinzufügen oder entfernen würden. In diesem Moment würde sich das Modell der ip_hash-Strategie ändern und alle vorherigen Verbindungen würden ungültig. Bei Microservices ist die Skalierung jedoch ein sehr häufiger Vorgang (insbesondere, wenn sich das Produkt in der Entwicklungsphase befindet), und diese verlustbehaftete Skalierung ist höchstwahrscheinlich nicht akzeptabel.

Zusammenfassend wird empfohlen, WebSocket direkt zu verwenden. Schließlich machen die alten Versionen, die WebSocket nicht unterstützen, einen kleinen Anteil aus und es dauert weniger Zeit, als zuerst abzufragen.

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.