Pytanie Jakie są pułapki używania Websockets zamiast RESTful HTTP?


Obecnie pracuję nad projektem, który wymaga od klienta żądania dużej pracy i wysłania go na serwer. Następnie serwer dzieli zadanie i odpowiada tablicą adresów URL, aby klient mógł wykonać wywołanie GET i odesłać dane. Jestem zielonogiem projektu i obecnie używam wiosennych stron internetowych, aby poprawić efektywność. Zamiast klientów nieustannie pingujących serwer, aby sprawdzić, czy wyniki są gotowe do powrotu, websocket będzie teraz bezpośrednio kontaktować się z hukiem klienta!

Czy nie byłoby dobrze, gdyby strony internetowe zarządzały całym procesem od początku do końca? Używam STOMP z Spring websockets, czy nadal będą poważne problemy z rezygnacją z REST?


34
2018-04-28 17:21


pochodzenie




Odpowiedzi:


Z RESTful HTTP masz bezpaństwowy system żądań / odpowiedzi gdzie klient wysyła żądanie, a serwer zwraca odpowiedź.

Z webSockets masz stateful (lub potencjalnie stateful) system przekazywania wiadomości, w którym wiadomości mogą być wysyłane w dowolny sposób a wysłanie dowolnej wiadomości jest mniejsze niż w przypadku żądania / odpowiedzi HTTP RESTful.

Obie są dość różne struktury o różnych mocach.

Główne zalety połączonego webSocket to:

  1. Dwukierunkowa komunikacja.  Tak więc serwer może w każdej chwili powiadomić klienta o wszystkim. Zamiast odpytywania serwera w regularnych odstępach czasu, aby sprawdzić, czy jest coś nowego, klient może ustanowić webSocket i po prostu nasłuchiwać wiadomości przychodzących z serwera. Z punktu widzenia serwera, gdy wydarzenie jest interesujące dla klienta, serwer po prostu wysyła wiadomość do klienta. Serwer nie może tego zrobić za pomocą zwykłego HTTP.

  2. Niższy narzut na wiadomość.  Jeśli spodziewasz się dużego ruchu między klientem a serwerem, wówczas na każdą wiadomość z webSocket jest niższy narzut. Wynika to z faktu, że połączenie TCP zostało już ustanowione i wystarczy wysłać wiadomość do już otwartego gniazda. Za pomocą żądania REST HTTP musisz najpierw ustanowić połączenie TCP, które jest kilka razy w jedną i drugą stronę między klientem a serwerem. Następnie wyślesz żądanie HTTP, otrzymasz odpowiedź i zamkniesz połączenie TCP. Żądanie HTTP będzie musiało zawierać pewne obciążenie, takie jak wszystkie pliki cookie, które są wyrównane z tym serwerem, nawet jeśli nie są one związane z konkretnym żądaniem. HTTP / 2 (najnowsza specyfikacja HTTP) pozwala na pewną dodatkową wydajność w tym zakresie, jeśli jest używany przez klienta i serwer, ponieważ jedno połączenie TCP może być używane dla więcej niż jednego żądania / odpowiedzi. Jeśli zaznaczysz wszystkie żądania / odpowiedzi na poziomie TCP tylko po to, aby utworzyć żądanie / odpowiedź REST protokołu HTTPS, możesz być zaskoczony, jak wiele się dzieje w porównaniu z wysyłaniem wiadomości przez już ustanowiony webSocket.

  3. Wyższa skala w niektórych okolicznościach.  Dzięki niższemu narzutowi na komunikat i bez odpytywania klienta, aby dowiedzieć się, czy coś jest nowe, może to prowadzić do dodatkowej skalowalności (większa liczba klientów, których dany serwer może obsługiwać). Istnieją również wady w stosunku do skalowalności webSocket (patrz poniżej).

  4. Połączenia stanowe.  Bez uciekania się do plików cookie i identyfikatorów sesji możesz bezpośrednio zapisać stan w swoim programie dla danego połączenia. Podczas gdy wiele rozwiązań zostało opracowanych w przypadku połączeń bezpaństwowych w celu rozwiązania większości problemów, czasami jest to po prostu prostsze z połączeniami stanowymi.

Głównymi zaletami żądania / odpowiedzi HTTP RESTful są:

  1. Uniwersalne wsparcie.  Trudno jest uzyskać bardziej uniwersalną obsługę niż HTTP. Chociaż webSockets mają teraz stosunkowo dobre wsparcie, wciąż istnieją pewne okoliczności, w których obsługa webSocket nie jest regularnie dostępna.

  2. Zgodny z większością środowisk serwerowych.  Istnieją środowiska serwerów, które nie pozwalają na długotrwałe procesy serwera (niektóre współdzielone sytuacje hostingu). Te środowiska mogą obsługiwać żądania HTTP, ale nie obsługują długich połączeń webSocket.

  3. Wyższa skala w niektórych okolicznościach.  Wymaganie webSocket dla stale podłączonego gniazda TCP dodaje pewne nowe wymagania skalowania do infrastruktury serwera, których żądania HTTP nie wymagają. Tak więc kończy się to kompromisem. Jeśli zalety webSockets nie są naprawdę potrzebne lub są wykorzystywane w znaczący sposób, wówczas żądania HTTP mogą być rzeczywiście skalowane. To zdecydowanie zależy od konkretnego profilu użytkowania.

  4. Na jednorazowe wymagać odpowiedzi, jedno żądanie HTTP jest bardziej wydajne niż ustanowienie webSocket, użycie go, a następnie zamknięcie. Jest tak dlatego, że otwarcie WebSocket rozpoczyna się od żądania / odpowiedzi HTTP, a następnie po tym, jak obie strony zgodzą się na uaktualnienie do połączenia webSocket, faktyczna wiadomość webSocket może zostać wysłana.

  5. Bezpaństwowy.  Jeśli twoja praca nie jest jeszcze bardziej skomplikowana dzięki temu, że posiadasz status bezpaństwowca, wówczas bezpaństwowy świat może znacznie ułatwić skalowanie (po prostu dodaj więcej procesów serwerowych za modułem równoważenia obciążenia).

  6. Automatycznie buforowany.  Przy odpowiednich ustawieniach serwera odpowiedzi HTTP mogą być buforowane przez przeglądarkę lub przez serwery proxy. Nie ma takiego wbudowanego mechanizmu dla żądań wysyłanych za pośrednictwem WebSockets.


Aby odpowiedzieć na pytanie, w jaki sposób zadałeś pytanie:

Jakie są pułapki korzystania z websockets zamiast RESTful HTTP?

  1. Na dużą skalę (setki tysięcy klientów), możesz potrzebować specjalnej pracy z serwerem, aby obsłużyć dużą liczbę jednocześnie podłączonych webSockets.

  2. Wszyscy potencjalni klienci lub zestawy narzędzi nie obsługują usług WebSockets ani żądań przesłanych za ich pośrednictwem na tym samym poziomie, na którym obsługują żądania HTTP.

  3. Niektóre z tańszych środowisk serwerowych nie obsługują długo działających procesów serwerowych wymaganych do obsługi WebSockets.

Jeśli ważne jest, aby aplikacja otrzymywała powiadomienia o postępach z powrotem do klienta, możesz użyć długotrwałego połączenia http z dalszym wysyłaniem postępu lub użyć webSocket. WebSocket jest prawdopodobnie łatwiejszy. Jeśli naprawdę potrzebujesz tylko WebSocket na względnie krótki czas trwania tej konkretnej czynności, możesz znaleźć najlepszy ogólny zestaw kompromisów za pomocą webSocket tylko na czas, kiedy potrzebujesz możliwości przekazania danych do klienta i następnie przy użyciu żądań HTTP dla normalnych działań żądania / odpowiedzi.


68
2018-04-29 02:46



Dziękuję za szczegółową odpowiedź. Wciąż czekam na magiczne ramy, które sprawiają, że strony internetowe są de facto sposobem na tworzenie aplikacji internetowych. Naprawdę podoba mi się, co Spring robi z Websockets. Może to rozwinie się w coś wielkiego na drodze. - smuggledPancakes
Dlaczego nikt nie wspomina, że ​​odpowiedzi REST są buforowalne i nie ma łatwego / automatycznego sposobu buforowania wyniku Websocket? - metamaker
@metamaker - To rozsądny punkt i dodam go. Jednak połączenia webSocket zwykle nie są używane w przypadku działań typu żądanie / odpowiedź, w których buforowanie jest odpowiednie i w rzeczywistości http jest zwykle zalecanym wyborem dla czystego żądania / odpowiedzi. - jfriend00
@ jfriend00 Dokładnie, ale jest to określony przypadek użycia REST w porównaniu do WebSockets. - metamaker


To naprawdę zależy od twoich wymagań. Usługi REST mogą być znacznie bardziej przejrzyste i łatwiejsze do zdobycia przez programistę niż Websockets.

Korzystając z Websockets, usuwasz większość zalet oferowanych przez RESTful webservices, takich jak możliwość odniesienia do zasobu poprzez URI. Naprawdę powinieneś zrobić, to dowiedzieć się, jakie są zalety REST i hipermedia, i na podstawie tego zdecydować, czy te zalety są dla ciebie ważne.

Oczywiście możliwe jest stworzenie usługi internetowej RESTful i rozszerzenie jej za pomocą interfejsu API opartego na websocket dla odpowiedzi w czasie rzeczywistym.

Ale jeśli tworzysz usługę, którą tylko ty będziesz zużywał w kontrolowanym środowisku, jedyną wadą może być to, że nie każdy klient obsługuje strony internetowe, podczas gdy prawie każdy typ środowiska może wykonywać proste wywołania http.


2
2018-04-28 21:42



Dzięki Spring-websockets i Spring-messaging mogę zrobić / @ MessageMapping, by mieć URI. Mogę również wykonać wywołanie Spring-mvc / @ RequestMapping! Wygląda na to, że Spring-websockets mogą pozwalać na RESTful jak abstrakcje? To tutaj się gubię, prawdopodobnie dlatego, że jestem naiwny, ale sprawia, że ​​tworzenie stron internetowych wydaje się naprawdę atrakcyjne, ale nie słyszę o tym zbyt wiele. - smuggledPancakes