Différences entre les sockets TCP et les sockets web, une fois de plus

Question

En essayant de comprendre au mieux les différences entre TCP socket et websocket, j'ai déjà trouvé beaucoup d'informations utiles dans ces questions :

• différence fondamentale entre les websockets et le TCP pur
• Comment établir une connexion TCP Socket depuis un navigateur web (côté client) ?

et ainsi de suite...

Dans mes investigations, j'ai parcouru cette phrase sur wikipedia :

Websocket diffère de TCP en ce qu'il permet un flux de messages au lieu d'un flux d'octets.

Je ne suis pas totalement sûr de ce que cela signifie exactement. Quelles sont vos interprétations ?

Answer 1

Lorsque vous envoyez des octets à partir d'un tampon avec une socket TCP normale, la fonction send renvoie le nombre d'octets du tampon qui ont été envoyés. S'il s'agit d'une socket non bloquante ou d'un envoi non bloquant, le nombre d'octets envoyés peut être inférieur à la taille du tampon. S'il s'agit d'une socket bloquante ou d'un envoi bloquant, le nombre d'octets renvoyés correspondra à la taille du tampon, mais l'appel peut être bloqué. Avec les WebSockets, les données transmises à la méthode d'envoi sont toujours envoyées sous forme de "message" complet ou pas du tout. En outre, les implémentations WebSocket des navigateurs ne bloquent pas l'appel send.

Mais il existe des différences plus importantes du côté de la réception. Lorsque le récepteur fait un recv (ou read ) sur une socket TCP, il n'y a aucune garantie que le nombre d'octets retournés corresponde à un seul envoi (ou écriture) du côté de l'expéditeur. Il peut être identique, inférieur (ou nul) ou supérieur (dans ce cas, des octets provenant de plusieurs envois/écritures sont reçus). Avec les WebSockets, le destinataire d'un message est guidé par un événement (vous enregistrez généralement une routine de gestion des messages), et les données contenues dans l'événement sont toujours le message complet envoyé par l'autre partie.

Notez qu'il est possible d'établir une communication basée sur des messages à l'aide de sockets TCP, mais il faut une couche/encapsulation supplémentaire qui ajoute des données d'encadrement/de limite de message aux messages afin que les messages originaux puissent être réassemblés à partir des morceaux. En fait, les WebSockets sont construits sur des sockets TCP normaux et utilisent des en-têtes de trame qui contiennent la taille de chaque trame et indiquent quelles trames font partie d'un message. L'API WebSocket réassemble les morceaux de données TCP en trames qui sont assemblées en messages avant d'invoquer le gestionnaire d'événement de message une fois par message.

Answer 2

WebSocket est essentiellement un protocole d'application (en référence à la pile réseau ISO/OSI), orienté message, qui utilise le protocole TCP comme couche de transport.

L'idée derrière le protocole WebSocket consiste à réutiliser la connexion TCP établie entre un client et un serveur. Après le handshake HTTP, le client et le serveur commencent à parler le protocole WebSocket en échangeant des enveloppes WebSocket. Le handshake HTTP est utilisé pour surmonter toute barrière (par exemple, les pare-feu) entre un client et un serveur offrant certains services (généralement, le port 80 est accessible de n'importe où, par n'importe qui). Le client et le serveur peuvent passer au protocole HTTP à tout moment, en utilisant la même connexion TCP (qui n'est jamais libérée).

En coulisses, WebSocket reconstruit les trames TCP en enveloppes/messages cohérents. Le canal full-duplex est utilisé par le Serveur à pousser les mises à jour vers le client de manière asynchrone : le canal est ouvert et le client peut appeler n'importe quel futur/callback/promesses pour gérer tout message WebSocket asynchrone reçu.

Pour faire simple, WebSocket est un protocole de haut niveau (comme HTTP lui-même) construit sur TCP (couche de transport fiable, sur une base par trame) qui permet de construire des applications en temps réel efficaces avec des clients JS (auparavant, les techniques Comet et de sondage long étaient utilisées). pour tirer des mises à jour du serveur avant la mise en œuvre des WebSockets. Voir le post de Stackoverflow : Différences entre les websockets et le polling long pour un serveur de jeu à tour de rôle ).