Was sind die Fallstricke bei der Verwendung von WebSockets anstelle von RESTful HTTP?

Question

Ich arbeite gerade an einem Projekt, das erfordert, dass der Client einen großen Job anfordert und ihn an den Server sendet. Dann teilt der Server den Job auf und antwortet mit einem Array von URLs, damit der Client einen GET-Aufruf durchführt und die Daten zurückströmt. Ich bin der Grünschnabel des Projekts und verwende derzeit Spring Websockets, um die Effizienz zu verbessern. Anstatt dass die Clients ständig den Server anpingen, um zu sehen, ob die Ergebnisse bereit sind, zurück zu streamen, wird der Websocket nun direkt mit dem Client Kontakt aufnehmen.

Wäre es eine schlechte Idee, dass Websockets den gesamten Prozess von Ende zu Ende verwalten? Ich benutze STOMP mit Spring websockets, wird es immer noch große Probleme mit REST geben?

Answer 1

Mit RESTful HTTP haben Sie ein Stateless Request/Response-System wo der Client Anfrage sendet und der Server die Antwort zurückgibt.

Mit webSockets haben Sie eine Stateful (oder potenziell stateful) Nachrichtenübergabe-System, wo Nachrichten gesendet werden können, und Senden einer gegebenen Nachricht ist niedriger Aufwand als mit einem RESTful HTTP-Anfrage/Antwort.

Die beiden sind ziemlich unterschiedliche Strukturen mit unterschiedlichen Stärken.

Die Hauptvorteile eines angeschlossenen WebSocket sind:

1. Zwei-Wege-Kommunikation. So kann der Server den Kunden jederzeit über alles informieren. Anstatt einen Server in regelmäßigen Abständen abzufragen, um festzustellen, ob es etwas Neues gibt, kann ein Client einen webSocket einrichten und nur auf Nachrichten warten, die vom Server kommen. Aus Sicht des Servers sendet der Server, wenn ein Ereignis auftritt, das für einen Client von Interesse ist, einfach eine Nachricht an den Client. Der Server kann dies nicht mit einfachem HTTP tun.

2. Geringerer Overhead pro Nachricht. Wenn Sie erwarten, dass viel Verkehr zwischen Client und Server fließt, ist der Aufwand pro Nachricht mit einem webSocket geringer. Dies liegt daran, dass die TCP-Verbindung bereits hergestellt ist und Sie lediglich eine Nachricht an einen bereits geöffneten Socket senden müssen. Bei einer HTTP-REST-Anforderung müssen Sie zunächst eine TCP-Verbindung herstellen, bei der es sich um mehrere Rück- und Herleitungen zwischen Client und Server handelt. Dann senden Sie eine HTTP-Anfrage, erhalten die Antwort und schließen die TCP-Verbindung. Die HTTP-Anforderung enthält notwendigerweise einen gewissen Overhead, z. B. alle Cookies, die mit diesem Server ausgerichtet sind, auch wenn diese für die jeweilige Anforderung nicht relevant sind.HTTP/2 (neueste HTTP-Spezifikation) ermöglicht in dieser Hinsicht eine zusätzliche Effizienz, wenn es sowohl vom Client als auch vom Server verwendet wird, da eine einzelne TCP-Verbindung für mehr als nur eine einzelne Anfrage/Antwort verwendet werden kann. Wenn Sie alle Anfragen/Antworten auf TCP-Ebene kartiert haben, nur um eine HTTPS-REST-Anfrage/-Antwort zu erstellen, würden Sie überrascht sein, wie viel los ist, verglichen mit dem Senden einer Nachricht über einen bereits eingerichteten WebSocket.

3. Höhere Skalierung in einigen Fällen. Mit geringerem Overhead pro Nachricht und keiner Clientabfrage, um herauszufinden, ob etwas neu ist, kann dies zu zusätzlicher Skalierbarkeit führen (höhere Anzahl von Clients, die ein bestimmter Server bedienen kann). Die Skalierbarkeit von webSocket hat ebenfalls Nachteile (siehe unten).

4. Stateful Verbindungen. Ohne auf Cookies und Sitzungs-IDs zurückgreifen zu müssen, können Sie den Status für eine bestimmte Verbindung direkt in Ihrem Programm speichern. Während mit statuslosen Verbindungen viele Entwicklungen zur Lösung der meisten Probleme gemacht wurden, ist es manchmal einfacher mit zustandsbehafteten Verbindungen.

Die primären Vorteile einer RESTful HTTP-Anforderung/Antwort, sind:

1. Universal-Unterstützung. Es ist schwierig, universeller als HTTP zu unterstützen. Obwohl webSockets jetzt relativ gut unterstützt werden, gibt es immer noch Fälle, in denen der webSocket-Support nicht regelmäßig verfügbar ist.

2. Kompatibel mit mehr Serverumgebungen. Es gibt Serverumgebungen, die keine lang andauernden Serverprozesse zulassen (einige Shared Hosting-Situationen). Diese Umgebungen können HTTP-Anforderungen unterstützen, lange WebSocket-Verbindungen jedoch nicht.

3. Höhere Skalierung in einigen Fällen. Die webSocket-Anforderung für einen kontinuierlich verbundenen TCP-Socket fügt der Serverinfrastruktur einige neue Skalierungsanforderungen hinzu, die von HTTP-Anforderungen nicht verlangt werden. Also, dies endet als Tradeoff-Raum. Wenn die Vorteile von webSockets nicht wirklich benötigt werden oder in signifikanter Weise genutzt werden, können HTTP-Anfragen tatsächlich besser skalieren. Es hängt definitiv vom spezifischen Nutzungsprofil ab.

4. Für eine einmalige Anfrage/Antwort ist eine einzelne HTTP-Anfrage effizienter als das Einrichten eines webSocket, den es verwendet und dann schließt. Dies liegt daran, dass das Öffnen eines webSockets mit einer HTTP-Anfrage/Antwort beginnt. Nachdem beide Seiten die Aktualisierung auf eine webSocket-Verbindung vereinbart haben, kann die eigentliche webSocket-Nachricht gesendet werden.

5. Staatenlos. Wenn Ihre Aufgabe nicht durch eine zustandslose Infrastruktur komplizierter wird, kann eine staatenlose Welt die Skalierung erheblich vereinfachen (fügen Sie einfach mehr Serverprozesse hinter einem Load Balancer hinzu).

6. Automatisch zwischenspeichern. Mit den richtigen Servereinstellungen können HTTP-Antworten vom Browser oder von Proxies zwischengespeichert werden. Es gibt keinen solchen integrierten Mechanismus für Anfragen, die über webSockets gesendet werden.

---

Also fragte den Weg zur Adresse, die Sie sich die Frage:

Was sind die Gefahren der Verwendung von WebSockets anstelle von RESTful HTTP sind?

1. in großem Maßstab (Hunderttausende von Kunden), können Sie eine spezielle Server-Arbeit zu unterstützen, um eine große Anzahl von gleichzeitig verbundenen WebSockets zu tun haben.

2. Alle möglichen Clients oder Toolsets unterstützen WebSockets oder Anforderungen, die über sie vorgenommen werden, nicht auf derselben Ebene, auf der sie HTTP-Anforderungen unterstützen.

3. Einige der weniger kostspieligen Serverumgebungen unterstützen nicht die langwierigen Serverprozesse, die zur Unterstützung von webSockets erforderlich sind.

Wenn es um Ihre Anwendung wichtig ist, Benachrichtigungen zu erhalten, an den Client Fortschritt zurück, könnten Sie entweder eine lange laufenden HTTP-Verbindung mit kontinuierlichen Fortschritte herabgesandt wird, oder Sie können einen WebSocket verwenden. Der webSocket ist wahrscheinlich einfacher. Wenn Sie wirklich nur den webSocket für die relativ kurze Dauer dieser bestimmten Aktivität benötigen, dann finden Sie möglicherweise die beste Gesamtmenge von Kompromissen, indem Sie einen webSocket nur für die Dauer der Zeit verwenden, wenn Sie die Fähigkeit haben, Daten zum Klienten zu schieben und Dann werden HTTP-Anfragen für die normalen Anfrage/Antwort-Aktivitäten verwendet.

Answer 2

Es hängt wirklich von Ihren Anforderungen ab. REST-Services können im Vergleich zu Websockets wesentlich transparenter und einfacher von Entwicklern abgerufen werden.

Mit WebSockets entfernen Sie die meisten Vorteile, die RESTful-Webdienste bieten, z. B. die Möglichkeit, über einen URI auf eine Ressource zu verweisen. Was Sie wirklich tun sollten, ist herauszufinden, welche Vorteile REST und Hypermedia haben, und basierend darauf entscheiden Sie, ob diese Vorteile für Sie wichtig sind.

Es ist natürlich durchaus möglich, einen REST-fähigen Webservice zu erstellen und ihn mit einer websocketbasierten API für Echtzeitantworten zu erweitern.

Wenn Sie jedoch einen Dienst erstellen, den nur Sie in einer kontrollierten Umgebung konsumieren, kann der einzige Nachteil sein, dass nicht jeder Client Websockets unterstützt, während so ziemlich jede Umgebung einen einfachen HTTP-Aufruf ausführen kann.