Jak są implementowane Websockets?

Jak WebSockets są implementowane?

Websockety są zaimplementowane w następujący sposób:

1. klient wysyła żądanie HTTP do serwera z nagłówkiem "upgrade" na żądanie
2. jeśli serwer zgadza się na aktualizację, klient i serwer wymieniają pewne poświadczenia bezpieczeństwa i protokół na istniejącym gnieździe TCP jest przełączany z HTTP na webSocket.
3. istnieje teraz trwałe otwarte Gniazdo TCP łączące klienta i serwer.
4. każda strona może wysłać dane na ten otwórz gniazdo w dowolnym momencie.
5. wszystkie dane muszą być wysyłane w bardzo specyficznym formacie pakietów webSocket.

Ponieważ gniazdo jest otwarte tak długo, jak obie strony zgadzają się, daje to serwerowi kanał do "wypychania" informacji do klienta, gdy jest coś nowego do wysłania. Jest to na ogół znacznie bardziej wydajne niż korzystanie z wywołań Ajax opartych na kliencie, gdzie klient musi regularnie wyszukiwać nowe informacje. I, jeśli klient musi wysłać wiele wiadomości na serwer (być może coś w rodzaju gry mnulti-player), wtedy używanie już otwartego gniazda do wysyłania szybkiej wiadomości na serwer jest również bardziej wydajne niż wywołanie Ajax.

Ze względu na sposób inicjowania websocketów (zaczynając od żądania HTTP, a następnie zmieniając położenie gniazda), są one w 100% kompatybilne z istniejącą infrastrukturą sieciową i mogą nawet działać na tym samym porcie, co istniejące żądania sieciowe(np. port 80 lub 443). To sprawia, że zabezpieczenia cross-origin są prostsze i zatrzymują każdego na kliencie lub Infrastruktura po stronie serwera od konieczności modyfikowania dowolnej infrastruktury w celu obsługi połączeń webSocket.

Jaki jest algorytm stojący za tą nową technologią (w porównaniu do Long-Polling)?

W tym artykule znajduje się bardzo dobre podsumowanie działania algorytmu połączenia webSocket i formatu danych webSocket: pisanie serwerów WebSocket.

Jak mogą być lepsze niż długofalowe sondaże pod względem wyników?

By its very Przyroda, long-polling jest trochę hack. Został wymyślony, ponieważ nie było lepszej alternatywy dla danych inicjowanych przez serwer wysyłanych do klienta. Oto kroki:

1. klient wysyła żądanie http o nowe dane od klienta.
2. jeśli serwer ma nowe dane, natychmiast zwraca te dane, a następnie klient wysyła kolejne żądanie http z prośbą o więcej danych. Jeśli serwer nie ma nowych danych, to po prostu zawiesza się na chwilę na połączenie bez podania odpowiedź, pozostawiając żądanie oczekujące (gniazdo jest otwarte, klient czeka na odpowiedź).
3. jeśli w dowolnym momencie, gdy żądanie jest nadal oczekujące, serwer pobiera pewne dane, wtedy formuje te dane w Odpowiedź i zwraca odpowiedź dla oczekującego żądania.
4. Jeśli przez jakiś czas nie pojawią się żadne dane, to w końcu żądanie przekroczy limit czasu. W tym momencie klient zda sobie sprawę, że żadne nowe dane nie zostały zwrócone i rozpocznie nowe żądanie.
5. płukanie, piana, powtarzam. Każdy fragment danych zwrócony lub każdy limit czasu oczekującego żądania jest następnie kolejne żądanie ajax od klienta.

Tak więc, podczas gdy webSocket używa jednego długotrwałego gniazda, przez które klient lub serwer może wysyłać dane do drugiego, long-polling polega na tym, że klient pyta serwer "czy masz dla mnie więcej danych?"w kółko i w kółko, każdy z nowym żądaniem http.

Długie sondowanie działa, gdy jest zrobione dobrze, po prostu nie jest tak wydajne na serwerze Infrastruktura, wykorzystanie przepustowości, żywotność baterii mobilnych itp...

Chcę wyjaśnić to: fakt, że Websockets przechowują otwarte połączenie między C / S to nie to samo do długiego czekania proces? Innymi słowy, dlaczego Websockets nie przeciążają serwera?

Utrzymywanie otwartego połączenia webSocket między Klientem a serwerem jest bardzo niedrogą rzeczą dla serwera (to tylko gniazdo TCP). Nieaktywne, ale otwarte Gniazdo TCP nie zajmuje serwera Procesora i tylko bardzo mała ilość pamięci do śledzenia gniazda. Odpowiednio skonfigurowane serwery mogą pomieścić setki tysięcy otwartych gniazd jednocześnie.

Z drugiej strony klient przeprowadzający długie ankiety, nawet taki, dla którego nie ma nowych informacji do wysłania, będzie musiał regularnie przywracać połączenie. Za każdym razem, gdy ponownie nawiązuje nowe połączenie, następuje zerwanie gniazda TCP i nowe połączenie, a następnie przychodzące żądanie HTTP do obsługi.

Oto kilka przydatnych odniesień na temat skalowania:

• 600k jednoczesnych połączeń websocket na AWS za pomocą węzła.js
• węzeł.js w / 1m jednoczesnych połączeń!
• HTML5 WebSocket: kwantowy skok w skalowalności dla sieci Web
• czy WebSockets HTML utrzymują otwarte połączenie dla każdego klienta? Czy to się skaluje?