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

En essayant de comprendre au mieux les différences entre socket TCP 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 à partir d’un navigateur Web (côté client)?

etc…

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

Websocket diffère de TCP en ce sens qu’il active un stream de messages au lieu d’un stream d’octets

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

Lorsque vous envoyez des octets à partir d’un tampon avec un socket TCP normal, la fonction d’envoi renvoie le nombre d’octets du tampon envoyé. S’il s’agit d’un socket non bloquant 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’un socket bloquant ou d’un envoi bloquant, le numéro renvoyé correspondra à la taille du tampon, mais l’appel peut être bloqué. Avec WebSockets, les données transmises à la méthode d’envoi sont toujours envoyées sous forme de “message” ou pas du tout. En outre, les implémentations WebSocket du navigateur ne bloquent pas l’appel d’envoi.

Mais il y a des différences plus importantes du côté de la réception. Lorsque le récepteur effectue un recv (ou lecture) sur un socket TCP, rien ne garantit que le nombre d’octets renvoyés correspond à un seul envoi (ou écriture) du côté de l’expéditeur. C’est peut-être la même chose, ce peut être moins (ou zéro) et cela pourrait même être plus (auquel cas des octets provenant de plusieurs envois / écritures sont reçus). Avec WebSockets, la réception d’un message est pilotée par un événement (vous enregistrez généralement une routine de gestionnaire de messages) et les données de l’événement sont toujours le message entier envoyé par l’autre côté.

Notez que vous pouvez faire une communication basée sur des messages en utilisant des sockets TCP, mais vous avez besoin d’une couche / encapsulation supplémentaire qui ajoute des données de limite de cadrage / message aux messages afin que les messages originaux puissent être réassemblés à partir des morceaux. En fait, WebSockets est construit sur des sockets TCP normaux et utilise des en-têtes de trame contenant la taille de chaque image et indiquant quelles images font partie d’un message. L’API WebSocket assemble à nouveau les blocs de données TCP en trames assemblées en messages avant d’appeler le gestionnaire d’événements de message une fois par message.

WebSocket est essentiellement un protocole d’application (avec référence à la stack réseau ISO / OSI), orienté message, qui utilise 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 protocole HTTP, le client et le serveur commencent à parler du protocole WebSocket en échangeant des enveloppes WebSocket. Le protocole HTTP est utilisé pour surmonter toute barrière (par exemple, pare-feu) entre un client et un serveur offrant certains services (le port 80 est généralement accessible de n’importe où et par n’importe qui). Le client et le serveur peuvent basculer en parlant à tout moment via HTTP, en utilisant la même connexion TCP (qui n’est jamais libérée).

WebSocket reconstruit les images TCP dans des enveloppes / messages cohérents. Le canal full-duplex est utilisé par le serveur pour transmettre les mises à jour vers le client de manière asynchrone: le canal est ouvert et le client peut appeler tout futur / callback / promis pour gérer tout message reçu asynchrone de WebSocket.

Pour le dire simplement, WebSocket est un protocole de haut niveau (comme HTTP lui-même) construit sur TCP (couche de transport fiable, par trame) qui permet de créer des applications temps réel efficaces avec les clients JS (précédemment techniques Comet et longue ont été utilisés pour extraire les mises à jour du serveur avant la mise en œuvre de WebSockets (voir l’article sur Stackoverflow): Différences entre les Websockets et l’interrogation longue pour les serveurs de jeux au tour par tour ).