puertos - Diferencias entre sockets TCP y sockets web, una vez más
sockets java (2)
Tratando de entender lo mejor que puedo las diferencias entre el socket TCP y el websocket, ya encontré mucha información útil en estas preguntas:
- diferencia fundamental entre websockets y TCP puro
- ¿Cómo establecer una conexión TCP Socket desde un navegador web (lado del cliente)?
y así...
En mis investigaciones, pasé por esta oración en wikipedia :
Websocket difiere de TCP en que habilita una secuencia de mensajes en lugar de una secuencia de bytes
No estoy totalmente seguro de lo que significa exactamente. ¿Cuáles son tus interpretaciones?
Cuando envía bytes desde un búfer con un zócalo TCP normal, la función de envío devuelve el número de bytes del búfer que se enviaron. Si es un socket no bloqueante o un envío no bloqueante, entonces el número de bytes enviados puede ser menor que el tamaño del buffer. Si se trata de un socket de bloqueo o un envío bloqueado, 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 de envío siempre se envían como un "mensaje" completo o no se envían en absoluto. Además, las implementaciones de 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 realiza un recv (o lee) en un socket TCP, no hay garantía de que el número de bytes devueltos corresponda a un único 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, la recepción de un mensaje depende de los eventos (generalmente registra una rutina de manejo de mensajes), y los datos en el evento son siempre el mensaje completo enviado por el otro lado.
Tenga en cuenta que puede realizar una comunicación basada en mensajes utilizando sockets TCP, pero necesita una capa / encapsulación adicional que agregue datos de límite de mensaje / marco a los mensajes para que los mensajes originales puedan reensamblarse a partir de las piezas. De hecho, WebSockets se basa en sockets TCP normales y usa encabezados de cuadros que contienen el tamaño de cada cuadro e indican qué cuadros son parte de un mensaje. La API de WebSocket vuelve a ensamblar los trozos de datos TCP en cuadros que se ensamblan en mensajes antes de invocar el controlador de eventos de mensaje una vez por mensaje.
WebSocket es básicamente un protocolo de aplicación (con referencia a la pila de red ISO / OSI), orientado a mensajes, que hace uso de TCP como capa de transporte.
La idea detrás del protocolo WebSocket consiste en reutilizar la conexión TCP establecida entre un Cliente y Servidor. Después del protocolo de enlace HTTP, el Cliente y el Servidor comienzan a hablar el protocolo WebSocket intercambiando sobres WebSocket. El protocolo de enlace HTTP se utiliza para superar cualquier barrera (por ejemplo, firewalls) entre un Cliente y un Servidor que ofrezca algunos servicios (por lo general, cualquiera puede acceder al puerto 80 desde cualquier lugar). El cliente y el servidor pueden cambiar de hablar HTTP en cualquier momento, haciendo uso de la misma conexión TCP (que nunca se libera).
Detrás de las escenas, WebSocket reconstruye las tramas TCP en sobres / mensajes consistentes. El servidor utiliza el canal de dúplex completo para enviar actualizaciones hacia el Cliente de forma asíncrona: el canal está abierto y el Cliente puede llamar a futuros / devoluciones de llamada / promesas para gestionar cualquier mensaje recibido de WebSocket asincrónico.
Para decirlo simplemente, WebSocket es un protocolo de alto nivel (como el HTTP) basado en TCP (capa de transporte confiable, en cada frame) que hace posible la creación de aplicaciones efectivas en tiempo real con JS Clients (anteriormente Comet y long-polling techniques se usaron para extraer actualizaciones del Servidor).