Différences entre les sockets TCP et les sockets web, une fois de plus [dupliquer]
Cette question a déjà une réponse ici:
Essayant de comprendre du mieux que je peux les différences entre TCP socket et websocket, j'ai déjà trouvé beaucoup d'informations utiles dans ces questions:
- différence fondamentale entre websockets et TCP pur
- Comment établir une connexion de Socket TCP à partir d'un navigateur web (côté client)?
Et ainsi de suite...
Dans mes enquêtes, je suis passé par cette phrase sur wikipedia:
Websocket diffère de TCP en ce qu'il active 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?
2 réponses
Lorsque vous envoyez des octets à partir d'un tampon avec un socket TCP normal, la fonction send renvoie le nombre d'octets du tampon qui ont été envoyés. 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 retourné correspondra à la taille du tampon, mais l'appel peut bloquer. Avec WebSockets, les données transmises à la méthode send sont toujours envoyées dans leur ensemble " 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 des choses. Lorsque le récepteur effectue un recv (ou une lecture) sur un socket TCP, il n'y a aucune garantie que le nombre d'octets renvoyés correspond à un seul envoi (ou écriture) du côté de l'expéditeur. Il peut être le même, il peut être moins (ou zéro) et il peut même être plus (auquel cas les octets de plusieurs send / writes sont reçus). Avec les WebSockets, l' la réception d'un message est pilotée par les événements (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 effectuer une communication basée sur des messages à l'aide de sockets TCP, mais vous avez besoin d'une couche/encapsulation supplémentaire qui ajoute des données de cadrage/limite de message aux messages afin que les messages d'origine puissent être réassemblés à partir des pièces. En fait, WebSockets est construit sur des sockets TCP normaux et utilise des en-têtes de trame qui contient la taille de chaque image et indique quelles images 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'appeler le gestionnaire d'événements de message Une fois par message.
WebSocket est essentiellement un protocole d'application (en référence à la pile 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 la liaison HTTP, le Client et le serveur commencent à parler le protocole WebSocket en échangeant des enveloppes WebSocket. HTTP handshaking 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 basculer sur HTTP parlant à tout moment, en utilisant la même connexion TCP (qui n'est jamais libérée).
Dans les coulisses WebSocket reconstruit les trames TCP dans des enveloppes/messages cohérents. Le canal duplex intégral est utilisé par le serveur pour pousser les mises à jour vers le Client de manière asynchrone: le canal est ouvert et le Client peut appeler futures / callbacks / promet de gérer tout message reçu WebSocket asynchrone.
Pour le dire simplement, WebSocket est un protocole de haut niveau (comme HTTP lui-même) construit sur TCP (reliable transport layer, on per frame basis) qui permet de construire une application en temps réel efficace avec des Clients JS (auparavant, les techniques Comet et long-polling étaient utilisées pour extraire les mises à jour du serveur avant Voir StackOverflow post: différences entre les websockets et longue interrogation pour le serveur de jeu au tour par tour).