Diferencias entre sockets TCP y web sockets, una vez más [duplicar]

Cuando envía bytes desde un búfer con un socket TCP normal, la función send devuelve el número de bytes del búfer que se enviaron. Si es un socket sin bloqueo o un envío sin bloqueo, el número de bytes enviados puede ser menor que el tamaño del búfer. Si es un socket de bloqueo o un envío de bloqueo, entonces el número devuelto coincidirá con el tamaño del búfer, pero la llamada puede bloquearse. Con WebSockets, los datos que se pasan al método send siempre se envían como un "mensaje" completo" o no en absoluto. Además, las implementaciones WebSocket del navegador no se bloquean en la llamada de envío.

Pero hay diferencias más importantes en el lado receptor de las cosas. Cuando el receptor hace un recv (o lectura) en un socket TCP, no hay garantía de que el número de bytes devueltos corresponda a un solo envío (o escritura) en el lado del remitente. Puede ser lo mismo, puede ser menos (o cero) e incluso puede ser más (en cuyo caso se reciben bytes de múltiples envíos/escrituras). Con WebSockets, el la recepción de un mensaje está impulsada por eventos (generalmente registra una rutina de manejador de mensajes), y los datos en el evento siempre son el mensaje completo que el otro lado envió.

Tenga en cuenta que puede hacer comunicación basada en mensajes usando sockets TCP, pero necesita alguna capa/encapsulación adicional que agregue datos de encuadre/límite de mensajes a los mensajes para que los mensajes originales puedan ser re-ensamblados a partir de las piezas. De hecho, WebSockets está construido sobre sockets TCP normales y utiliza encabezados de marco que contiene el tamaño de cada fotograma e indica qué fotogramas son parte de un mensaje. La API WebSocket vuelve a ensamblar los trozos TCP de datos en marcos que se ensamblan en mensajes antes de invocar el controlador de eventos de mensajes una vez por mensaje.