Tworzę małą aplikację do czatowania dla przyjaciół, ale nie jestem pewien, jak uzyskać informacje w odpowiednim czasie, które nie są tak manualne ani tak podstawowe, jak wymuszenie odświeżenia strony.

Obecnie implementuję to za pomocą prostego AJAX, ale ma to wadę polegającą na regularnym uderzaniu w serwer po upływie krótkiego czasu.

Podczas badania długiego / krótkiego odpytywania natknąłem się na WebSockets HTML5. To wydaje się łatwe do wdrożenia, ale nie jestem pewien, czy są jakieś ukryte wady. Na przykład myślę, że WebSockets są obsługiwane tylko przez niektóre przeglądarki. Czy WebSockets ma jeszcze inne wady, o których powinienem wiedzieć?

Ponieważ wydaje się, że obie technologie robią to samo, w jakich scenariuszach wolelibyśmy stosować jedną nad drugą? Mówiąc dokładniej, czy HTML5 WebSockets sprawiło, że ankietowanie AJAX długo / krótkie stało się przestarzałe, czy też istnieją ważne powody, by preferować AJAX zamiast WebSockets?

WebSockets to zdecydowanie przyszłość.

Długie odpytywanie to nieprzyjemne obejście, które uniemożliwia tworzenie połączeń dla każdego żądania, podobnie jak AJAX - ale długie odpytywanie zostało utworzone, gdy WebSockets nie istniało. Teraz dzięki WebSockets długie odpytywanie zanika.

WebRTC pozwala na komunikację peer-to-peer.

Polecam naukę WebSockets .

Porównanie:

różnych technik komunikacji w sieci

• AJAX - request→ response. Tworzy połączenie z serwerem, wysyła nagłówki żądań z opcjonalnymi danymi, otrzymuje odpowiedź z serwera i zamyka połączenie. Obsługiwane we wszystkich głównych przeglądarkach.

• Długa ankieta - request→ wait→ response. Tworzy połączenie z serwerem, tak jak robi to AJAX, ale utrzymuje połączenie utrzymujące połączenie otwarte przez pewien czas (choć nie długo). Podczas połączenia otwarty klient może odbierać dane z serwera. Klient musi łączyć się okresowo po zamknięciu połączenia z powodu przekroczenia limitu czasu lub utraty danych. Po stronie serwera nadal jest traktowane jak żądanie HTTP, tak samo jak AJAX, z tą różnicą, że odpowiedź na żądanie pojawi się teraz lub w przyszłości, zgodnie z logiką aplikacji. tabela wsparcia (pełna) | wikipedia

• WebSockets - client↔ server. Utwórz połączenie TCP z serwerem i utrzymuj je otwarte tak długo, jak to konieczne. Serwer lub klient może łatwo zamknąć połączenie. Klient przechodzi proces uzgadniania zgodny z HTTP. Jeśli się powiedzie, serwer i klient mogą w dowolnym momencie wymieniać dane w obu kierunkach. Jest skuteczny, jeśli aplikacja wymaga częstej wymiany danych w obie strony. WebSockets mają ramkę danych, która obejmuje maskowanie każdej wiadomości wysyłanej od klienta do serwera, więc dane są po prostu szyfrowane. tabela wsparcia (bardzo dobra) | wikipedia

• WebRTC - peer↔ peer. Transport w celu ustanowienia komunikacji między klientami jest niezależny od transportu, dzięki czemu może korzystać z UDP, TCP lub nawet bardziej abstrakcyjnych warstw. Zasadniczo stosuje się to do przesyłania dużych ilości danych, takich jak przesyłanie strumieniowe audio / wideo, gdzie niezawodność ma drugorzędne znaczenie, a kilka klatek lub obniżenie progresji jakości można poświęcić na rzecz czasu odpowiedzi, a przynajmniej transferu danych. Obie strony (rówieśnicy) mogą przekazywać sobie dane niezależnie. Chociaż można go używać całkowicie niezależnie od jakichkolwiek scentralizowanych serwerów, nadal wymaga pewnego sposobu wymiany danych punktów końcowych, gdzie w większości przypadków programiści nadal używają scentralizowanych serwerów do „łączenia” peerów. Jest to wymagane tylko do wymiany niezbędnych danych do nawiązania połączenia, po czym serwer scentralizowany nie jest wymagany. tabela wsparcia (średnia) | wikipedia

• Zdarzenia wysłane przez serwer - client← server. Klient ustanawia trwałe i długoterminowe połączenie z serwerem. Tylko serwer może wysyłać dane do klienta. Jeśli klient chce wysłać dane do serwera, będzie to wymagało użycia innej technologii / protokołu. Ten protokół jest zgodny z HTTP i łatwy do wdrożenia na większości platform po stronie serwera. Jest to preferowany protokół, który należy stosować zamiast opcji Długie odpytywanie. tabela wsparcia (dobra, z wyjątkiem IE) | wikipedia

Zalety:

Główną zaletą serwera WebSockets jest to, że nie jest to żądanie HTTP (po uzgadnianiu), ale właściwy protokół komunikacyjny oparty na wiadomościach. To pozwala na uzyskanie dużych wydajności i architektury zalety . Na przykład w node.js możesz współużytkować tę samą pamięć dla różnych połączeń gniazd, aby każdy mógł uzyskać dostęp do wspólnych zmiennych. Dlatego nie musisz używać bazy danych jako punktu wymiany w środku (jak w przypadku AJAX lub Long Polling w języku takim jak PHP). Możesz przechowywać dane w pamięci RAM, a nawet ponownie publikować między gniazdami.

Względy bezpieczeństwa

Ludzie często martwią się bezpieczeństwem WebSockets. W rzeczywistości nie ma to większego znaczenia, a nawet stawia WebSockets jako lepszą opcję. Przede wszystkim dzięki AJAX istnieje większa szansa na MITM , ponieważ każde żądanie jest nowym połączeniem TCP, które przechodzi przez infrastrukturę internetową. Po podłączeniu do WebSockets znacznie trudniej jest przechwycić pomiędzy nimi, z dodatkowo wymuszonym maskowaniem ramek, gdy dane są przesyłane strumieniowo z klienta na serwer, a także dodatkową kompresją, która wymaga większego wysiłku do sondowania danych. Wszystkie nowoczesne protokoły obsługują zarówno: HTTP, jak i HTTPS (szyfrowane).

PS

Pamiętaj, że WebSockets generalnie mają zupełnie inne podejście do logiki sieci , bardziej jak gry w czasie rzeczywistym przez cały czas, a nie jak http.

Jedną z rywalizujących technologii, którą pominąłeś, są zdarzenia wysyłane przez serwer / źródło zdarzeń. Co to jest Long-Polling, Websockets, Server-Sent Events (SSE) i Comet? dobrze omawia je wszystkie. Pamiętaj, że niektóre z nich są łatwiejsze do zintegrowania po stronie serwera.

WebSocketsNajlepszą opcją są aplikacje czatu lub inne aplikacje, które prowadzą stałą rozmowę z serwerem . Można jednak używać tylko WebSocketsz serwerem, który je obsługuje, więc może to ograniczyć twoją zdolność do korzystania z nich, jeśli nie możesz zainstalować wymaganych bibliotek. W takim przypadku należy użyć, Long Pollingaby uzyskać podobną funkcjonalność.

• Sondowanie XHR Żądanie jest odbierane, gdy wystąpi zdarzenie (może być od razu lub z opóźnieniem). Kolejne prośby będą musiały być składane, aby otrzymywać dalsze wydarzenia.

  Przeglądarka wysyła asynchroniczne żądanie serwera, który może poczekać na dostępność danych przed odpowiedzią. Odpowiedź może zawierać zakodowane dane (zwykle XML lub JSON) lub JavaScript, które mają zostać wykonane przez klienta. Pod koniec przetwarzania odpowiedzi przeglądarka tworzy i wysyła kolejny XHR, aby oczekiwać na następne zdarzenie. W ten sposób przeglądarka zawsze przetwarza żądanie serwera, na które należy odpowiedzieć, gdy wystąpi każde zdarzenie. Wikipedia

• Serwer wysłał zdarzenia Klient wysyła żądanie do serwera. Serwer wysyła w dowolnym momencie nowe dane do strony internetowej.

  Tradycyjnie strona internetowa musi wysłać do serwera żądanie otrzymania nowych danych; oznacza to, że strona żąda danych z serwera. W przypadku zdarzeń wysyłanych przez serwer serwer może w dowolnym momencie wysyłać nowe dane do strony internetowej, wysyłając wiadomości na stronę internetową. Te przychodzące wiadomości można traktować jako zdarzenia + dane na stronie internetowej. Mozilla

• WebSockets Po wstępnym uzgadnianiu (przez protokół HTTP). Komunikacja odbywa się dwukierunkowo przy użyciu protokołu WebSocket.

  Uzgadnianie rozpoczyna się od żądania / odpowiedzi HTTP, co pozwala serwerom obsługiwać połączenia HTTP, a także połączenia WebSocket na tym samym porcie. Po ustanowieniu połączenia komunikacja przełącza się na dwukierunkowy protokół binarny, który nie jest zgodny z protokołem HTTP. Wikipedia