Aplikacje internetowe zostały początkowo zaprojektowane jako architektura klient-serwer. Klienci tworzą żądanie HTTP/HTTPS do wyznaczonego serwera, żądając lub modyfikując informacje. Na przykład podstawowa aplikacja internetowa będzie działać w podobny sposób.

1. Klient żąda danych z serwera

2. Load balancer kieruje żądania do odpowiedniego serwera

3. Serwer wysyła zapytanie do odpowiedniej bazy danych o pewne dane

4. Baza danych zwraca żądane dane do serwera

5. Serwer przetwarza dane i wysyła je z powrotem do klienta.

Proste żądanie HTTP jest najczęstszym sposobem otrzymywania informacji z serwera. Co jednak, jeśli chcesz uzyskać dane z powrotem, gdy tylko zostaną dodane do bazy danych lub wysłane na serwer? W przypadku podstawowej aplikacji internetowej zaprojektowanej jako architektura klient-serwer konieczne byłoby powtarzanie tego procesu w kółko, aby sprawdzić, czy do bazy danych zostały dodane nowe informacje. Ten proces jest znany jako odpytywanie lub czasami określany jako krótkie odpytywanie. Wadą tego podejścia jest to, że dane nie będą zwracane przez większość czasu, ponieważ serwer nie otrzymał żadnych nowych informacji. Rozwiążmy ten problem i omówmy zalety i wady Long Polling i Websockets.

Przegląd: Long Polling vs WebSockets

Long Polling

Długie odpytywanie to podejście w którym klient wysyła żądanie API do serwera, ale zamiast otrzymywać natychmiastową odpowiedź od serwera, pociąga za sobą utrzymanie połączenia HTTP. Utrzymywanie połączenia HTTP pozwala serwerowi odpowiedzieć później, gdy dane staną się dostępne lub zostanie osiągnięty próg limitu czasu. Po otrzymaniu odpowiedzi klient natychmiast wyśle kolejne żądanie.

Zamiast wysyłać wiele żądań wielokrotnie, aż serwer otrzyma nowe informacje, jak w przypadku odpytywania, klient musi wysłać tylko jedno żądanie do serwera, aby uzyskać najnowsze informacje. Po otrzymaniu danych klient może zainicjować nowe żądanie, powtarzając ten proces tak często, jak to konieczne.

Przepływ dla Long Polling będzie wyglądał następująco:

1. Strona klienta wysyła żądanie HTTP do serwera, żądając pewnych danych

2. Serwer nie odpowiada natychmiast żądanymi informacjami, ale czeka, aż nowe informacje będą dostępne.

3. Gdy nowe dane stają się dostępne, serwer odpowiada nowymi informacjami.

4. Klient otrzymuje te dane i natychmiast wysyła kolejne żądanie do serwera, ponownie uruchamiając proces.

WebSockets

WebSockets są nowoczesną technologia zbudowaną na szczycie stosu TCP/IP urządzenia. Jedynym związkiem z protokołem HTTP jest to, że serwery HTTP interpretują jego uścisk dłoni w celu nawiązania połączenia. Jest to połączenie dwukierunkowe, pełny dupleks protokół, który jest stanowy, co oznacza, że połączenie między klientem a serwerem będzie trwało, dopóki jedna ze stron nie zdecyduje się go zakończyć.

W przeciwieństwie do długiego odpytywania, które jest tylko rozwiązaniem półdupleksowym, proces nie musi być powtarzany po otrzymaniu najnowszych informacji z serwera. Technologia WebSocket pozwala nam utrzymać połączenie przy życiu po zwróceniu nowych informacji i wykonywać dwukierunkowe aktualizacje. Klient może wysyłać informacje z powrotem do serwera i nasłuchiwać dalszych informacji w tym samym żądaniu.

Przepływ połączenia WebSocket będzie wyglądał mniej więcej tak:

1. Po stronie klienta inicjowane jest połączenie WebSocket poprzez wysłanie żądania, które zawiera nagłówek aktualizacji w celu przełączenia protokołu komunikacyjnego na protokół WebSocket

2. Jeśli serwer może nawiązać połączenie i zgadza się z warunkami klienta, wysyła odpowiedź do klienta potwierdzającą żądanie uzgadniania WebSocket.

3. Gdy klient otrzyma pomyślne połączenie WebSocket, klient i serwer mogą teraz rozpocząć wysyłanie danych w obu kierunkach, umożliwiając komunikację w czasie rzeczywistym.

4. Serwer lub klient decyduje o zakończeniu połączenia.

Kiedy wybrać Long Polling vs WebSockets?

Istnieje debata na temat tego, kiedy używać protokołu Long Polling lub WebSocket. Oba mają swoje zalety i ograniczenia i są często wykorzystywane do różnych celów. W tej sekcji omówimy kluczowe zalety zarówno protokołu Long Polling, jak i WebSockets.

Zalety protokołów Long Polling i WebSockets

Kompatybilność: Long Polling jest starszą technologią używaną bardziej jako technika, dzięki czemu jest bardziej kompatybilną opcją niż WebSockets. Jest ona zbudowana na bazie XMLHttpRequesti jest zgodna z szerszym zakresem przeglądarek internetowych i konfiguracji sieci.

Sieć: Przy dzisiejszej technologii ludzie stale przełączają sieci z 3G na LTE i WiFi. WebSockets muszą być skonfigurowane tak, aby dostosować się do zmiany połączenia sieciowego. Ta konfiguracja wynika z faktu, że połączenie musi zostać ponownie nawiązane z serwerem i nie może zostać przywrócone po tym, jak klient zdecyduje się zamknąć połączenie. W przypadku długiego pollingu nie jest to problemem, ponieważ jest on skonfigurowany w taki sposób, że po określonym czasie (zwykle 20 sekund) klient spróbuje wysłać kolejne żądanie, automatycznie przywracając połączenie z serwerem i nie musi być obsługiwany w stanie błędu, jak w przypadku WebSockets.

Przypadki użycia, aby wybrać długie odpytywanie zamiast WebSockets

Long polling i WebSockets są zwykle używane w przypadkach, w których wymagane są aktualizacje w czasie rzeczywistym. Niektóre przykłady obejmują czat w aplikacji, ustalanie cen w czasie rzeczywistym, śledzenie geograficzne i IoT.

Długie odpytywanie zapewnia korzyści w stosunku do WebSockets w przypadkach użycia z niską częstotliwością aktualizacji w czasie rzeczywistym. Korzyści te wynikają z faktu, że długie odpytywanie jest rozwiązaniem pół-rzeczywistym, w którym połączenie musi zostać ponownie nawiązane. Ponadto, jak wspomniano powyżej, jeśli użytkownicy znajdują się w środowisku o niskiej przepustowości lub niestabilnym dostawcy sieci, długie odpytywanie jest zaprojektowane tak, aby przywrócić połączenie bez dodatkowych komplikacji. Długie odpytywanie jest jednak starszą technologią/techniką wykonywania aktualizacji w czasie rzeczywistym. W rezultacie jest mniej zaawansowana i mniej elastyczna niż WebSockets, ale ma większe wsparcie dla starszych systemów.

Kiedy wybrać WebSockets, a kiedy long polling?

Zalety WebSockets vs long polling

Mniejsze wykorzystanie zasobów: WebSockets utrzymują stałe połączenie między klientem a serwerem, zmniejszając obciążenie związane z nawiązywaniem nowego połączenia dla każdej aktualizacji w czasie rzeczywistym. Stałe połączenie zmniejsza wykorzystanie zasobów po stronie klienta i serwera w zakresie przepustowości sieci, pamięci i procesora w celu osiągnięcia komunikacji w czasie rzeczywistym.

Ulepszona skalowalność: Ze względu na charakter WebSockets i jego dwukierunkową komunikację między klientem a serwerem, serwer może przesyłać aktualizacje do klienta w czasie rzeczywistym, zmniejszając liczbę wysyłanych żądań. Długie odpytywanie musi ponownie nawiązać połączenie za każdym razem, gdy klient potrzebuje nowych informacji. Wraz ze wzrostem bazy użytkowników może to stanowić duże obciążenie dla pojedynczego serwera.

Zaawansowana funkcjonalność: WebSockets zapewniają kanały komunikacyjne full-duplex, które zapewniają transfer danych w czasie rzeczywistym i niskie opóźnienia. Długie odpytywanie jest czasami uważane za rozwiązanie tylko w połowie działające w czasie rzeczywistym i nie jest idealne dla scenariuszy o dużym natężeniu ruchu lub przypadków użycia, które wymagają aktualizacji w czasie rzeczywistym. Zaawansowana funkcjonalność zapewnia płynniejszą obsługę przez użytkowników końcowych, ponieważ otrzymują oni bardziej płynne aktualizacje swoich aplikacji.

Przypadki użycia, aby wybrać WebSockets zamiast długiego odpytywania

WebSockets lepiej nadają się do aplikacji, które wymagają częstych aktualizacji. Przykłady obejmują aplikacje czatu lub źródła danych w czasie rzeczywistym. Stałe połączenie pozwala na wydajną transmisję, dzięki czemu jest bardziej płynne dla użytkownika końcowego. Gry wieloosobowe i narzędzia do współpracy również zazwyczaj wykorzystują WebSockets. Dwukierunkowa komunikacja pozwala serwerowi na sygnalizowanie klientowi, co może być korzystne dla otrzymywania aktualizacji w czasie rzeczywistym od innych klientów. Na przykład, serwer może zasygnalizować klientowi, aby zaktualizował pozycję innego gracza w zależności od jego działań.

Jeśli chodzi o skalowanie lub gdy baza użytkowników zaczyna się skalować, idealnym rozwiązaniem jest przejście na protokół WebSocket. Obciążenie pojedynczego serwera stanie się zbyt duże, jeśli baza klientów korzysta z technologii długiego odpytywania. Wysyłanie żądania co 20 sekund ma słabe wykorzystanie i spowoduje spowolnienie serwera w czasie, zwiększając opóźnienie na żądanie.

Jak PubNub wpisuje się w dyskusję na temat Long Polling vs WebSockets?

WebSockets i long polling oferują cenne rozwiązania do tworzenia aplikacji czasu rzeczywistego. Jednak podczas tworzenia tych przypadków użycia w grę wchodzi wiele innych kwestii. Przy dzisiejszej technologii nic nie jest tak proste, jak wysłanie wiadomości lub danych z jednego klienta do drugiego. Prawie zawsze istnieje wymagana funkcjonalność na szczycie systemu czasu rzeczywistego, który deweloper próbuje stworzyć. Na przykład w czacie w aplikacji można sprawdzić aktualizacje obecności (sygnalizowanie), gdy użytkownicy są online, filtrowanie wulgaryzmów, a nawet odczytywanie/dostarczanie wiadomości.

Oprócz dodawania konkretnych funkcji, nadal istnieją problemy z infrastrukturą bazową, takie jak złożoność obsługi skalowalności. Podczas korzystania z określonych technologii, takich jak Socket.io do tworzenia WebSocket, programiści nadal będą musieli zadbać o dynamiczne odradzanie serwerów na całym świecie za load balancerem, aby zarządzać wykorzystaniem każdego serwera. Problemy te stają się coraz bardziej złożone wraz ze skalowaniem.

Interfejsy API PubNub do obsługi danych w czasie rzeczywistym pozwalają użytkownikom tworzyć potężne, sterowane zdarzeniami aplikacje ułatwiające komunikację w czasie rzeczywistym na wszystkich urządzeniach, niezależnie od konkretnego przypadku użycia. PubNub oferuje różne zestawy SDK, takie jak JavaScript SDK dla aplikacji internetowych i C-Core SDK dla aplikacji IoT, aby zapewnić płynną integrację z wybranym urządzeniem. Dzięki PubNub nie musisz martwić się o wybór odpowiedniej alternatywy lub złożoność implementacji rozwiązania czasu rzeczywistego.

Teraz, gdy już wiesz, kiedy używać long polling vs WebSockets zapisz się na bezpłatny okres próbny lub zaplanuj demo aby dowiedzieć się, co można zbudować za pomocą PubNub.

Jak PubNub może ci pomóc?

Ten artykuł został pierwotnie opublikowany na PubNub .com

Nasza platforma pomaga programistom tworzyć, dostarczać i zarządzać interaktywnością w czasie rzeczywistym dla aplikacji internetowych, aplikacji mobilnych i urządzeń IoT.

Fundamentem naszej platformy jest największa w branży i najbardziej skalowalna sieć przesyłania wiadomości w czasie rzeczywistym. Dzięki ponad 15 punktom obecności na całym świecie obsługującym 800 milionów aktywnych użytkowników miesięcznie i niezawodności na poziomie 99,999%, nigdy nie będziesz musiał martwić się o przestoje, limity współbieżności lub jakiekolwiek opóźnienia spowodowane skokami ruchu.

Poznaj PubNub

Sprawdź Live Tour, aby zrozumieć podstawowe koncepcje każdej aplikacji opartej na PubNub w mniej niż 5 minut.

Rozpocznij konfigurację

Załóż konto PubNub, aby uzyskać natychmiastowy i bezpłatny dostęp do kluczy PubNub.

Rozpocznij

Dokumenty PubNub pozwolą Ci rozpocząć pracę, niezależnie od przypadku użycia lub zestawu SDK.