Jaka jest podstawowa różnica między WebSockets a czystym TCP?

167

Czytałem o WebSockets i zastanawiam się, dlaczego przeglądarka nie mogła po prostu otworzyć trywialnego połączenia TCP i komunikować się z serwerem jak każda inna aplikacja desktopowa. I dlaczego ta komunikacja jest możliwa przez websockety?

tcp websocket

— xap4o
źródło

8

Ale w czym problem? Pozwól im używać TCP.

— xap4o

2

Więcej informacji stackoverflow.com/questions/8051516/…

— Hernán Eche

2

„WebSocket to protokół zapewniający pełnodupleksowe kanały komunikacyjne za pośrednictwem pojedynczego połączenia TCP”. Możesz tworzyć połączenia TCP również w trybie pełnego dupleksu? co jest takiego specjalnego w WebSockets?

— Abhishek Jain

12

Problem polega na tym, że zazwyczaj serwery WWW mają otwarty tylko jeden port ze względów bezpieczeństwa, a mianowicie port 80. Z definicji jeden port można podłączyć TYLKO do jednej aplikacji . A co, jeśli klient chce skorzystać z usługi innej niż WWW (HTTP), ale dostępny jest tylko jeden port? Voila! Websockets!

— Pithikos

3

@Pithikos trafił w dziesiątkę, dlaczego potrzebujemy tej złożoności gniazd sieciowych, a nie tylko zajmować się prostymi gniazdami TCP do komunikacji między przeglądarką a serwerem.

— Słoneczny

260

Komunikacja przez gniazda TCP jest łatwiejsza, gdy pracujesz w granicach intranetu, ponieważ prawdopodobnie masz kontrolę nad komputerami w tej sieci i możesz otwierać porty odpowiednie do nawiązywania połączeń TCP.

Przez Internet komunikujesz się z serwerem innej osoby na drugim końcu. Są niesamowicie mało prawdopodobne, aby jakiekolwiek stare gniazdo było otwarte dla połączeń. Zwykle mają tylko kilka standardowych, takich jak port 80 dla HTTP lub 443 dla HTTPS. Tak więc, aby komunikować się z serwerem, musisz połączyć się za pomocą jednego z tych portów.

Biorąc pod uwagę, że są to standardowe porty dla serwerów internetowych, które generalnie mówią po HTTP, jesteś zobowiązany do przestrzegania protokołu HTTP, w przeciwnym razie serwer nie będzie z tobą rozmawiać. Celem gniazd sieciowych jest umożliwienie zainicjowania połączenia przez HTTP, a następnie negocjowanie użycia protokołu gniazd sieciowych (zakładając, że serwer jest w stanie to zrobić), aby zezwolić na strumień komunikacyjny bardziej podobny do gniazda TCP.

— Popiół
źródło

2

Dzięki za łatwe wyjaśnienie, Ash.

— xap4o

Więc zasadniczo WebSocket jest po prostu opakowaniem dla TCP w tym sensie, że UDP jest po prostu opakowaniem dla IP?

— Pacerier

3

@Pacerier: WebSocket wymaga pewnego rodzaju protokołu transportowego do działania, ale ta warstwa transportowa nie musi być TCP (w praktyce prawie zawsze będzie to TCP). Można by pomyśleć o WebSockets jako o rodzaju otoki wokół TCP, ale nie wierzę, że istnieje jakieś normatywne łącze między nimi.

— Ash

4

„Przez Internet komunikujesz się z serwerem innej osoby na drugim końcu”. „Biorąc pod uwagę, że są to standardowe porty (80 i 443) dla serwerów internetowych, które zazwyczaj używają protokołu HTTP, jesteś zobowiązany do przestrzegania protokołu HTTP w przeciwnym razie serwer nie będzie z tobą rozmawiać. " Zwykle serwer sieci Web, do którego uzyskujemy dostęp, byłby naszym własnym. Więc możemy mieć aplikację z protokołem, który zdefiniujemy, nasłuchuje portu. Po co więc uzgadnianie HTTP i przełączanie protokołów? Zamiast tego, dlaczego nie możemy bezpośrednio śledzić protokołu podobnego do gniazda sieciowego?

— ratul

2

Zgodnie z RFC6455, WebSocket wymaga najpierw uzgadniania w HTTP, a następnie protokołu aktualizuje się do WebSocket. Większość przeglądarek podąża za tym. Nie wiem, jak będzie obsługiwana strona klienta (przeglądarka), jeśli używasz dowolnego protokołu na serwerze. To tak, jakbyśmy mogli porozumiewać się po francusku, tylko oboje znamy francuski. Uścisk dłoni to jak pytanie: „Czy możemy porozumiewać się po francusku?” Po angielsku (tutaj HTTP). Tutaj przeglądarki (takie jak chrome) znają francuski, ale musimy nauczyć serwer francuskiego. Moje pytanie brzmiało: dlaczego RFC6455 (WebSocketProtocol) chce wykonać uzgadnianie w HTTP i skomplikować sprawy, dlaczego nie mogą tego zrobić po swojemu?

— ratul

31

Przeglądarki internetowe działają w warstwie aplikacji, podczas gdy TCP działa w warstwie transportowej. Jako twórca aplikacji internetowych łatwiej jest wysyłać wiadomości przez sieć kablową za pośrednictwem warstwy aplikacji zamiast surowych bajtów w warstwie transportowej.

Podstawą WebSockets jest TCP, jest on po prostu wyodrębniony dla uproszczenia.

— wulfgarpro
źródło

2

Websocket jest protokołem warstwy aplikacji, podczas gdy TCP jest protokołem warstwy transportowej. W warstwie transportowej mamy zwykle protokoły TCP i UDP. Każda wiadomość z warstwy aplikacji musi przejść przez warstwę transportową, aby została przesłana do innej maszyny. Dlatego websocket i tcp są ze sobą powiązane i nie mogą być porównywalne.

— Minh Trần
źródło

2

Aby to uprościć, komunikacja przez gniazdo sieciowe odbywa się za pośrednictwem portu TCP numer 80 (lub 443 w przypadku połączeń szyfrowanych TLS), co jest korzystne dla środowisk, które blokują połączenia internetowe inne niż internetowe za pomocą zapory .

Czy chcesz użyć istniejącego portu TCP, czy otworzyć nowy port TCP, który może być blokowany przez zaporę?

— Eugene
źródło