Różnice między gniazd TCP i gniazd internetowych, jeszcze raz

Question

Próbując zrozumieć, jak najlepiej mogę różnice między gniazda TCP i websocket, już znaleźć wiele użytecznych informacji w tych kwestiach:

• fundamental difference between websockets and pure TCP
• How to establish a TCP Socket connection from a web browser (client side)?

i tak dalej ...

W moich badaniach, przeszedłem przez to zdanie na wikipedia:

websocket różni się od TCP w to, że umożliwia strumień wiadomości zamiast strumienia bajtów

nie jestem całkowicie pewien, co to znaczy dokładnie. Jakie są twoje interpretacje?

Answer 1

Podczas wysyłania bajtów z bufora z normalnym gniazdem TCP, funkcja wysyłania zwraca liczbę bajtów wysłanego bufora. Jeśli jest to gniazdo bez blokowania lub wysyłanie nieblokujące, liczba wysłanych bajtów może być mniejsza niż rozmiar bufora. Jeśli jest to blokujące gniazdo lub blokowanie wysyłania, wówczas zwrócona liczba będzie odpowiadać rozmiarowi bufora, ale połączenie może blokować. W przypadku WebSockets dane przekazywane do metody wysyłania są zawsze wysyłane jako całość "wiadomości" lub wcale. Ponadto implementacje przeglądarki WebSocket nie blokują połączenia wysyłanego.

Istnieją jednak ważniejsze różnice po stronie odbiorcy. Kiedy odbiornik robi recv (lub czyta) na gnieździe TCP, nie ma gwarancji, że liczba zwróconych bajtów odpowiada pojedynczemu wysłaniu (lub zapisaniu) po stronie nadawcy. Może być taki sam, może być mniejszy (lub zero) i może być nawet większy (w tym przypadku odbierane są bajty z wielu wysyłek/zapisów). W przypadku WebSockets, odbiór komunikatu jest sterowany zdarzeniami (generalnie rejestruje się procedurę obsługi komunikatów), a dane w zdarzeniu są zawsze całą wiadomością wysłaną przez drugą stronę.

Zauważ, że możesz komunikować się przez komunikację za pomocą gniazd TCP, ale potrzebujesz dodatkowej warstwy/enkapsulacji, która dodaje do wiadomości dane ramek/granic wiadomości, dzięki czemu oryginalne wiadomości mogą zostać ponownie złożone z fragmentów. W rzeczywistości WebSockets jest zbudowany na normalnych gniazdach TCP i używa nagłówków ramek, które zawierają rozmiar każdej klatki i wskazują, które ramki są częścią wiadomości. Interfejs WebSocket API ponownie składa porcje danych TCP na ramki, które są składane w wiadomościach przed wywołaniem obsługi zdarzeń komunikatu raz na wiadomość.

Answer 2

WebSocket to w zasadzie protokół aplikacji (w odniesieniu do stosu sieci ISO/OSI), zorientowany na komunikaty, który wykorzystuje TCP jako warstwę transportową.

Idea protokołu WebSocket polega na ponownym wykorzystaniu nawiązanego połączenia TCP między klientem a serwerem. Po uzgadnianiu HTTP klient i serwer zaczynają mówić protokołem WebSocket, wymieniając koperty WebSocket. Uzgadnianie HTTP jest używane do pokonania dowolnej bariery (np. Zapory ogniowej) między klientem a serwerem oferującym niektóre usługi (zwykle port 80 jest dostępny z dowolnego miejsca, przez dowolną osobę). Klient i serwer mogą w dowolnym momencie przełączać się na komunikaty HTTP, korzystając z tego samego połączenia TCP (które nigdy nie jest wydawane).

Za kulisami WebSocket odbudowuje ramki TCP w spójnych kopertach/wiadomościach.Kanał full-duplex jest wykorzystywany przez serwer do przesyłania aktualizacji w stronę klienta w sposób asynchroniczny: kanał jest otwarty, a Klient może wywoływać wszelkie transakcje futures/callbacks/promises w celu zarządzania wszelkimi asynchronicznymi wiadomościami odebranymi przez WebSocket.

Mówiąc prościej, WebSocket jest protokołem wysokiego poziomu (podobnie jak sam HTTP) opartym na TCP (niezawodna warstwa transportowa, w oparciu o jedną ramkę), który umożliwia budowanie efektywnej aplikacji czasu rzeczywistego z klientami JS (wcześniej Kometa i wykorzystano techniki długiego odpytywania: , aby pobrać aktualizacje z serwera na serwer).