Quelle est la différence fondamentale entre WebSockets et TCP pur?

167

J'ai lu sur WebSockets et je me demande pourquoi le navigateur ne pouvait pas simplement ouvrir une connexion TCP triviale et communiquer avec le serveur comme toute autre application de bureau. Et pourquoi cette communication est-elle possible via des websockets?

tcp websocket

— xap4o
source

8

Mais quel est le problème? Laissez-les utiliser TCP.

— xap4o

2

En savoir plus stackoverflow.com/questions/8051516/…

— Hernán Eche

2

"WebSocket est un protocole fournissant des canaux de communication en duplex intégral sur une seule connexion TCP". Vous pouvez également créer des connexions TCP qui sont en duplex intégral? quelle est cette particularité des WebSockets?

— Abhishek Jain

12

Le problème est que les serveurs Web n'ont généralement qu'un seul port ouvert pour des raisons de sécurité, à savoir le port 80. Par définition un port peut attacher à une application seulement . Alors que se passe-t-il si un client souhaite utiliser un service autre que le Web (HTTP) mais qu'il n'y a qu'un seul port disponible? Voila! Websockets!

— Pithikos

3

@Pithikos a frappé de plein fouet les raisons pour lesquelles nous avons besoin de cette complexité de Websockets et pas seulement de sockets TCP simples pour la communication navigateur-serveur.

— Ensoleillé du

260

Il est plus facile de communiquer via des sockets TCP lorsque vous travaillez dans une limite intranet, car vous avez probablement le contrôle sur les machines de ce réseau et pouvez ouvrir des ports adaptés pour établir les connexions TCP.

Sur Internet, vous communiquez avec le serveur de quelqu'un d'autre à l'autre bout. Il est extrêmement improbable qu'ils aient une ancienne prise ouverte pour les connexions. Habituellement, ils n'en auront que quelques-uns standard tels que le port 80 pour HTTP ou 443 pour HTTPS. Ainsi, pour communiquer avec le serveur, vous êtes obligé de vous connecter en utilisant l'un de ces ports.

Etant donné qu'il s'agit de ports standards pour les serveurs web qui parlent généralement HTTP, vous êtes donc obligé de vous conformer au protocole HTTP, sinon le serveur ne vous parlera pas. Le but des web sockets est de vous permettre d'initier une connexion via HTTP, mais ensuite de négocier pour utiliser le protocole web sockets (en supposant que le serveur est capable de le faire) pour permettre un flux de communication plus "socket TCP".

— Cendre
source

2

Merci pour l'explication facile, Ash.

— xap4o

Donc, fondamentalement, WebSocket est simplement un wrapper pour TCP dans le sens où UDP est simplement un wrapper pour IP?

— Pacerier

3

@Pacerier: Un WebSocket nécessite une sorte de protocole de transport pour fonctionner, mais cette couche de transport n'a pas besoin d'être TCP (ce sera presque toujours TCP en pratique cependant). Vous pourriez considérer WebSockets comme une sorte de wrapper autour de TCP, mais je ne pense pas qu'il y ait un lien normatif entre les deux.

— Ash

4

"Sur Internet, vous communiquez avec le serveur de quelqu'un d'autre à l'autre bout." "Etant donné qu'il s'agit de ports standards (80 & 443) pour les serveurs Web qui parlent généralement HTTP, vous êtes donc obligé de vous conformer au protocole HTTP , sinon le serveur ne vous parlera pas. " Habituellement, le serveur Websocket auquel nous accédons est le nôtre. Nous pouvons donc avoir une application avec un protocole que nous définissons pour écouter un port. Alors, pourquoi aurions-nous besoin d'une prise de contact HTTP et d'un changement de protocole? Au lieu de cela, pourquoi ne pouvons-nous pas suivre directement un protocole de type websocket?

— ratul

2

Par RFC6455, WebSocket nécessite d'abord une prise de contact dans HTTP, puis le protocole se met à niveau vers WebSocket. La plupart des navigateurs suivent cela. Je ne sais pas comment votre côté client (navigateur) prendra en charge, si vous utilisez un protocole dans le serveur. C'est comme si nous pouvions communiquer en français, seuls les deux connaissons le français. Et la poignée de main, c'est comme, je vous demande, «pouvons-nous communiquer en français?» En anglais (ici HTTP). Ici, les navigateurs (comme chrome) connaissent le français mais nous devons enseigner le français aux serveurs. Ma question était pourquoi RFC6455 (WebSocketProtocol) veut faire la poignée de main en HTTP et compliquer les choses, pourquoi ne peuvent-ils pas le faire à leur manière?

— ratul

31

Les navigateurs Web fonctionnent au niveau de la couche Application, tandis que TCP fonctionne au niveau de la couche Transport. En tant que développeur d'applications Web, il est plus facile d'envoyer des messages via le réseau via la couche d'application au lieu d'octets bruts au niveau de la couche de transport.

TCP est sous-jacent aux WebSockets , il est simplement abstrait pour plus de simplicité.

— wulfgarpro
source

2

Websocket est un protocole de couche application tandis que TCP est un protocole de couche de transport. Au niveau de la couche de transport, nous avons généralement les protocoles TCP et UDP. Tout message de la couche d'application doit passer par la couche de transport pour être transmis à une autre machine. Par conséquent, websocket et tcp ont une relation entre eux et ne peuvent pas être comparables.

— Minh Trần
source

2

Pour simplifier les choses, les communications Websocket sont effectuées sur le port TCP numéro 80 (ou 443 dans le cas des connexions cryptées TLS), ce qui est avantageux pour les environnements qui bloquent les connexions Internet non Web à l'aide d'un pare - feu .

Souhaitez-vous utiliser le port TCP existant ou ouvrir un nouveau port TCP qui pourrait être bloqué par le pare-feu?

— Eugène
source