Zarówno HTTP, jak i WebSocket są protokołami komunikacyjnymi używanymi w komunikacji klient-serwer.

Protokół HTTP: HTTP jest jednokierunkowy, gdzie klient wysyła żądanie, a serwer wysyła odpowiedź. Weźmy przykład, gdy użytkownik wysyła żądanie do serwera, żądanie to odbywa się w formie HTTP lub HTTPS, po otrzymaniu żądania serwer wysyła odpowiedź do klienta, każde żądanie jest kojarzone z odpowiednią odpowiedzią, po wysłaniu odpowiedzi połączenie zostanie zamknięte, każde żądanie HTTP lub HTTPS za każdym razem ustanawia nowe połączenie z serwerem, a po otrzymaniu odpowiedzi połączenie zostaje samoczynnie zakończone.
HTTP to protokół bezstanowy działający na bazie protokołu TCP, który jest protokołem zorientowanym na połączenie, gwarantuje dostarczanie transferu pakietów danych przy użyciu metod trójstronnego uzgadniania i retransmisję utraconych pakietów.

HTTP może działać na dowolnym niezawodnym protokole połączeniowym, takim jak TCP, SCTP. Kiedy klient wysyła żądanie HTTP do serwera, połączenie TCP pomiędzy klientem a serwerem zostaje otwarte, a po otrzymaniu odpowiedzi połączenie TCP zostaje zakończone, każde żądanie HTTP otwiera oddzielne połączenie TCP z serwerem, np.: jeśli klient wyśle ​​10 żądań do serwera, zostanie otwartych 10 oddzielnych połączeń TCP. i zamykaj się po otrzymaniu odpowiedzi/rezerwy.

Informacje o komunikacie HTTP zakodowane w formacie ASCII, każdy komunikat żądania HTTP składa się z wersji protokołu HTTP (HTTP/1.1, HTTP/2), metod HTTP (GET/POST itp.), nagłówków HTTP (typ treści, długość treści), informacji o hoście itp. . i treść, które zawierają faktyczną wiadomość przesyłaną na serwer. Nagłówki HTTP miały rozmiar od 200 bajtów do 2 KB, typowy rozmiar nagłówka HTTP to 700-800 bajtów. Gdy aplikacja internetowa korzysta z większej liczby plików cookie i innych narzędzi po stronie klienta, które rozszerzają funkcje pamięci agenta, zmniejsza to ładunek nagłówka HTTP.

Gniazdo internetowe: WebSocket jest dwukierunkowym, pełnodupleksowym protokołem używanym w tym samym scenariuszu komunikacji klient-serwer, w przeciwieństwie do protokołu HTTP, od którego zaczyna się ws:// Lub wss:// . Jest to protokół stanowy, co oznacza, że ​​połączenie między klientem a serwerem będzie aktywne, dopóki nie zostanie zakończone przez którąkolwiek ze stron (klienta lub serwer). Po zamknięciu połączenia przez klienta i serwer połączenie zostaje zakończone z obu stron.

parametr w skrypcie powłoki

Weźmy przykład komunikacji klient-serwer, jest klient, który jest przeglądarką internetową i serwerem, za każdym razem, gdy inicjujemy połączenie między klientem a serwerem, klient-serwer uzgadnia i decyduje o utworzeniu nowego połączenia i tego połączenia pozostanie przy życiu aż do zakończenia przez którekolwiek z nich. Kiedy połączenie jest nawiązane i aktywne, komunikacja odbywa się przy użyciu tego samego kanału połączenia, aż do jego zakończenia.

W ten sposób po uzgodnieniu klient-serwer klient-serwer decyduje o nowym połączeniu, aby utrzymać je przy życiu. To nowe połączenie będzie znane jako WebSocket. Po ustanowieniu łącza komunikacyjnego i otwarciu połączenia, wymiana komunikatów będzie odbywać się w trybie dwukierunkowym, aż do utrzymania połączenia pomiędzy klientem a serwerem. Jeśli którykolwiek z nich (klient-serwer) umrze lub zdecyduje się zamknąć połączenie jest zamykane przez obie strony. Sposób działania gniazda różni się nieco od działania protokołu HTTP, kod stanu 101 oznacza protokół przełączania w WebSocket.

Kiedy można wykorzystać gniazdo internetowe:

Aplikacja internetowa działająca w czasie rzeczywistym: Aplikacja internetowa działająca w czasie rzeczywistym wykorzystuje gniazdo sieciowe do wyświetlania po stronie klienta danych, które są stale wysyłane przez serwer zaplecza. W WebSocket dane są w sposób ciągły przesyłane/wypychane do tego samego połączenia, które jest już otwarte, dlatego WebSocket jest szybszy i poprawia wydajność aplikacji.
Dla np. w witrynie handlowej lub handlu bitcoinami, w celu wyświetlania wahań cen i danych o ruchu są w sposób ciągły przesyłane przez serwer zaplecza do klienta za pomocą kanału WebSocket.
Aplikacja do gier: W aplikacji do gier możesz się na tym skupić, dane są stale odbierane przez serwer i bez odświeżania interfejsu użytkownika zostaną one zastosowane na ekranie, interfejs użytkownika zostanie automatycznie odświeżony nawet bez ustanawiania nowego połączenia, więc jest bardzo pomocne w aplikacji do gier.
Aplikacja do czatowania: Aplikacje do czatowania korzystają z protokołu WebSockets w celu nawiązania połączenia tylko raz w celu wymiany, publikowania i rozpowszechniania wiadomości wśród subskrybentów. Wykorzystuje ponownie to samo połączenie WebSocket do wysyłania i odbierania wiadomości oraz do przesyłania wiadomości jeden do jednego.

Kiedy nie używać protokołu WebSocket: WebSocket można wykorzystać, jeśli chcemy aktualizowanych w czasie rzeczywistym lub ciągłych strumieni danych przesyłanych przez sieć. Jeśli chcemy pobrać stare dane lub chcemy uzyskać dane tylko raz, aby przetworzyć je za pomocą aplikacji, powinniśmy skorzystać z Protokół HTTP , stare dane, które nie są wymagane zbyt często lub pobierane tylko raz, można sprawdzić za pomocą prostego żądania HTTP, więc w tym scenariuszu lepiej nie używać protokołu WebSocket.

Notatka: Usługi sieciowe RESTful wystarczą, aby pobrać dane z serwera, jeśli ładujemy dane tylko raz.

Różnice między połączeniem HTTP i WebSocket:

Notatka: W zależności od projektu musisz wybrać, gdzie będzie to połączenie WebSocket lub HTTP.