Czy WebSockets HTML utrzymują otwarte połączenie dla każdego klienta? Czy to się skaluje?

Jestem ciekaw, czy ktoś ma jakieś informacje na temat skalowalności WEBSOCKETÓW HTML. Z tego co przeczytałem wynika, że każdy klient będzie utrzymywał otwartą linię komunikacji z serwerem. Zastanawiam się tylko, jak to skaluje i ile otwartych połączeń WebSocket serwer może obsłużyć. Może pozostawienie tych połączeń otwartych nie jest problemem w rzeczywistości, ale wydaje się, że jest.

Author: Ryan Montgomery, 2011-01-31
Source

5 answers

W większości przypadków WebSockets będą prawdopodobnie skalowane lepiej niż żądania AJAX/HTML. Nie oznacza to jednak, że WebSockets jest zamiennikiem dla wszystkich zastosowań AJAX/HTML.

Każde połączenie TCP samo w sobie zużywa bardzo mało zasobów serwera. Często konfigurowanie połączenia może być kosztowne, ale utrzymanie bezczynnego połączenia jest prawie bezpłatne. Pierwszym ograniczeniem, które jest zwykle spotykane, jest maksymalna liczba deskryptorów plików (gniazda zużywają deskryptory plików), które mogą być otwórz jednocześnie. Często domyślnie jest to 1024, ale można go łatwo skonfigurować wyżej.

Próbowałeś kiedyś skonfigurować serwer WWW do obsługi dziesiątek tysięcy jednoczesnych klientów AJAX? Zmień tych klientów na klientów WebSockets i może to być wykonalne.

Połączenia HTTP, chociaż nie tworzą otwartych plików ani nie zużywają numerów portów przez długi czas, są droższe w prawie każdy inny sposób:

  • Każde połączenie HTTP niesie ze sobą dużo bagażu, który nie są używane przez większość czasu: Pliki cookie, typ treści, długość konetentu, user-agent, identyfikator serwera, Data, Ostatnio zmodyfikowane itp. Po nawiązaniu połączenia WebSockets, tylko dane wymagane przez aplikację muszą być wysyłane tam iz powrotem.

  • Zazwyczaj serwery HTTP są skonfigurowane do rejestrowania początku i zakończenia każdego żądania HTTP zajmującego czas dysku i procesora. Stanie się standardem rejestrowanie rozpoczęcia i zakończenia danych WebSockets, ale podczas gdy połączenie WebSockets podczas transferu dupleksu nie będzie żadnych dodatkowych kosztów logowania(z wyjątkiem aplikacji/usługi, jeśli jest do tego przeznaczona).

  • Zazwyczaj aplikacje interaktywne, które używają AJAX albo w sposób ciągły ankieta lub użyć pewnego rodzaju mechanizm długiego ankiety. WebSockets jest o wiele czystszym (i niższym zasobem) sposobem na zrobienie bardziej event ' d modelu, w którym serwer i klient powiadamiają się nawzajem, gdy mają coś do zgłoszenia nad istniejącym połączeniem.

  • Większość z popularne Serwery WWW w produkcji mają pulę procesów (lub wątków) do obsługi żądań HTTP. Wraz ze wzrostem ciśnienia rozmiar puli zostanie zwiększony, ponieważ każdy proces / wątek obsługuje jedno żądanie HTTP na raz. Każdy dodatkowy proces / wątek zużywa więcej pamięci, a tworzenie nowych procesów / wątków jest o wiele droższe niż tworzenie nowych połączeń gniazd (co te procesy/wątki nadal muszą robić). Większość popularnych frameworków serwerowych WebSockets idzie na imprezę trasa, która ma tendencję do skalowania i osiągania lepszych wyników.

Podstawową zaletą WebSockets będą mniejsze opóźnienia połączeń dla interaktywnych aplikacji internetowych. Będzie to skalować lepiej i zużywać mniej zasobów serwera niż HTTP AJAX / long-poll( zakładając, że aplikacja / serwer jest poprawnie zaprojektowany), ale IMO mniejsze opóźnienia jest podstawową zaletą WebSockets, ponieważ umożliwi nowe klasy aplikacji internetowych, które nie są możliwe przy bieżącym napowietrzaniu i opóźnieniu AJAX / long-poll.

Gdy standard WebSockets stanie się bardziej sfinalizowany i będzie miał szersze wsparcie, sensowne będzie używanie go w większości nowych interaktywnych aplikacji internetowych, które muszą często komunikować się z serwerem. W przypadku istniejących interaktywnych aplikacji internetowych będzie to naprawdę zależało od tego, jak dobrze działa obecny model AJAX/long-poll. Próba konwersji będzie nietrywialna, więc w wielu przypadkach koszt po prostu nie będzie wart korzyści.

Update :

Przydatne link: 600k jednoczesnych połączeń websocket na AWS za pomocą węzła.js

 190
Author: kanaka,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-04-13 16:17:03

Tylko Wyjaśnienie: liczba połączeń klienckich, które serwer może obsługiwać, nie ma nic wspólnego z portami w tym scenariuszu, ponieważ serwer [zazwyczaj] nasłuchuje tylko połączeń WS/WSS na jednym porcie. Myślę, że to, co inni komentatorzy mieli na myśli, to deskryptory plików. Możesz ustawić maksymalną liczbę deskryptorów plików dość wysoko, ale wtedy musisz uważać, aby rozmiary buforów gniazd sumowały się dla każdego otwartego gniazda TCP / IP. Oto kilka dodatkowych informacji: https://serverfault.com/questions/48717/practical-maximum-open-file-descriptors-ulimit-n-for-a-high-volume-system

Jeśli chodzi o zmniejszone opóźnienie poprzez WS vs. HTTP, to prawda, ponieważ nie ma już parsowania nagłówków HTTP poza początkowym uściskiem dłoni WS. Dodatkowo, w miarę jak coraz więcej pakietów jest wysyłanych z powodzeniem, okno zatorów TCP rozszerza się, skutecznie zmniejszając RTT.

 35
Author: Michael,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-04-13 12:13:44

Każdy nowoczesny pojedynczy serwer jest w stanie obsługiwać tysiące klientów na raz. Jego oprogramowanie serwera HTTP musi być zorientowane na zdarzenia (Iocp) (nie jesteśmy już w starym równaniu Apache one connection = one thread / process). Nawet serwer HTTP wbudowany w Windows (http.sys) jest zorientowany na IOCP i bardzo wydajny (działa w trybie jądra). Z tego punktu widzenia nie będzie dużej różnicy w skalowaniu między Websocketami a zwykłym połączeniem HTTP. Jeden TCP / IP połączenie wykorzystuje niewiele zasobów (znacznie mniej niż wątek), a nowoczesne systemy operacyjne są zoptymalizowane do obsługi wielu jednoczesnych połączeń: WebSockets i HTTP to tylko protokoły warstwy aplikacji OSI 7, dziedziczące z tej specyfikacji TCP / IP.

Ale z eksperymentu widziałem dwa główne problemy z Websocketami:

  1. nie obsługują CDN;
    2. Mają potencjalne problemy z bezpieczeństwem.

Więc polecam następujące, dla każdego projektu:

  • używaj WebSockets tylko do powiadomień o klientach (z mechanizmem awaryjnym do long-ankietowania - wokół jest wiele bibliotek);
  • Użyj RESTful / JSON dla wszystkich innych danych, używając CDN lub proxy dla pamięci podręcznej.

W praktyce pełne aplikacje WebSockets nie skalują się dobrze. Wystarczy użyć WebSockets do tego, do czego zostały zaprojektowane: powiadomienia push z serwera do klienta.

O potencjalnych problemach korzystania z WebSockets:

1. Rozważ użycie CDN

Obecnie (prawie 4 lata później) skalowanie sieci Web polega na użyciu front endów Content Delivery Network (CDN), nie tylko dla statycznych treści (html,css,js), ale także danych aplikacji (JSON) .

Oczywiście nie umieścisz wszystkich danych w pamięci podręcznej CDN, ale w praktyce wiele popularnych treści nie zmienia się często. Podejrzewam, że 80% Twoich zasobów może być buforowane... Nawet jedna minuta (lub 30 sekund) limit czasu wygaśnięcia CDN może to wystarczyć, aby zapewnić centralnemu serwerowi nowe działanie i znacznie zwiększyć responsywność aplikacji, ponieważ CDN może być dostrojony geograficznie...

Według mojej wiedzy, nie ma jeszcze wsparcia WebSockets w CDN i podejrzewam, że nigdy nie będzie. WebSockets są statefull, podczas gdy HTTP jest bezstanowy, więc jest znacznie łatwo buforowane. W rzeczywistości, aby WebSockets CDN był przyjazny, może być konieczne przejście na bezpaństwowe podejście RESTful... co nie byłoby już WebSockets.

2. Bezpieczeństwo zagadnienia

WebSockets mają potencjalne problemy z bezpieczeństwem, szczególnie dotyczące ataków DOS. Aby uzyskać ilustrację dotyczącą nowych luk w zabezpieczeniach, zobacz ten zestaw slajdów i ten bilet webkit .

WebSockets unikają możliwości kontroli pakietów na poziomie warstwy aplikacji OSI 7, co w dzisiejszych czasach jest dość standardem w każdym zabezpieczeniu biznesowym. W rzeczywistości WebSockets powoduje zaciemnienie transmisji, więc może to być poważne naruszenie bezpieczeństwa.

 13
Author: Arnaud Bouchez,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-08-16 14:25:17

Pomyśl o tym w ten sposób: co jest tańsze, utrzymywanie otwartego połączenia lub otwieranie nowego połączenia dla każdego żądania (z kosztami negocjacji tego, pamiętaj, że to TCP.)

Oczywiście zależy to od aplikacji, ale w przypadku długotrwałych połączeń w czasie rzeczywistym (np. czat AJAX) znacznie lepiej jest utrzymać połączenie Otwarte.

Maksymalna liczba połączeń zostanie ograniczona przez maksymalną liczbę wolnych portów dla gniazd.

 8
Author: kaoD,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-07-31 07:16:08

Nie Nie skaluje się, daje ogromną pracę pośrednim przełącznikom tras. Następnie po stronie serwera błędy strony (musisz zachować wszystkie te deskryptory) osiągają wysokie wartości, a czas na wprowadzenie zasobu do obszaru roboczego wzrasta. Są to głównie serwery napisane w Javie i może być szybciej trzymać się tych gazilionów gniazd, a następnie zniszczyć/utworzyć jeden. Kiedy uruchamiasz taki serwer na komputerze, żaden inny proces nie może się już poruszać.

 -3
Author: user2195463,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-05-25 03:27:08