sockets - nodejs - ¿Cuál es la diferencia entre WebSocket y la comunicación de socket simple?

websocket nodejs (2)

Según la Wikipedia , la única relación entre HTTP y WebSocket es un apretón de manos adicional en la forma de una Upgrade HTTP request . Y después de eso, parece que el navegador y el servidor HTTP simplemente se comunicarán en un viejo paradigma C / S sobre un socket simple.

Entonces mis preguntas son:

¿WebSocket es solo una comunicación de socket simple?
¿Se llama Web Socket porque la comunicación se dirige al 80 puerto del servidor? es decir, el port 80 es sinónimo de web .
El puerto 80 está en el lado del servidor, ¿qué puertos se usan en el cliente?
Si es simplemente como la comunicación de socket simple entre un navegador y un servidor, ¿por qué WebSocket no está implementado en los navegadores hasta hace poco? Parece nada más que una pequeña extensión C / S para el paradigma B / S.

AGREGAR 1 (9:46 a. M. 23/05/2017)

Hoy, revisé la excelente respuesta de @ jfriend00. Vamos a resumir mi entendimiento.

Socket es solo un canal de comunicación de extremo a extremo. No impone restricciones sobre qué protocolo de comunicación se puede usar en él.
webSocket, como HTTP, es solo otro protocolo de comunicación independiente. Aunque la palabra socket en el nombre me confundió al principio.
webSocket aprovecha el mismo número de puerto que HTTP para que si podemos comunicarnos a través de HTTP, podemos estar seguros de que se puede hacer la comunicación webSocket. Debido a que el canal ha terminado, podemos elegir la forma más adecuada de hablar a lo largo del canal.

No, los WebSockets son más que simples sockets. Usan un protocolo de encuadre que requiere un apretón de manos y luego intercambian mensajes enmascarados por XORint con un número aleatorio de 32 bits. Para obtener más información, lea el RFC que los estandariza .

El motivo de esta capa de codificación adicional es que permitir que un navegador web cree conexiones de socket arbitrarias abriría varios problemas de seguridad. Podría, por ejemplo, hacer que los visitantes de su sitio web se conecten a servidores de correo arbitrarios a través de SMTP y hacer que envíen spam sin que el usuario se dé cuenta. Es por eso que el protocolo fue diseñado de manera que las aplicaciones del lado del servidor necesitan implementarlo intencionalmente antes de que puedan ser utilizadas desde los navegadores web.

Con respecto a los puertos: de forma predeterminada, WebSocket se conecta al puerto 80, pero la API puede recibir cualquier puerto. El puerto del lado del cliente se aleatoriza, como en la mayoría de los protocolos basados en TCP / IP.

¿Por qué no se implementó antes? Porque hasta hace poco, WhatWG y W3C no contaban con el soporte unificado de todos los principales desarrolladores de navegadores para obtener la autoridad que requieren para introducir nuevos estándares. Es por eso que hay una avalancha de nuevas características del navegador bajo la etiqueta HTML5 recientemente.

webSockets y sockets regulares no son lo mismo. Un webSocket se ejecuta sobre un socket regular, pero ejecuta su propio esquema de conexión, esquema de seguridad y protocolo de encuadre en la parte superior del socket normal y ambos puntos finales deben seguir esos pasos adicionales para que incluso se establezca una conexión. Puede ver el protocolo webSocket aquí: http://tools.ietf.org/html/rfc6455

La mayor diferencia de inmediato es que TODAS las conexiones webSocket comienzan con una solicitud HTTP de cliente a servidor. El cliente envía una solicitud HTTP al mismo servidor y puerto que está abierto para la comunicación web normal (valor predeterminado del puerto 80, pero si el servidor web se ejecuta en un puerto diferente, la comunicación webSocket lo seguiría en ese otro puerto) . El cliente establece algunos encabezados personalizados, el más importante de los cuales es un encabezado que indica que el cliente desea "actualizar" al protocolo webSocket. Además, ambos lados intercambian algunas claves de seguridad. Si el servidor acepta la "actualización", tanto el cliente como el servidor cambian el protocolo que se habla sobre ese zócalo original de HTTP a webSocket y ahora se utiliza el protocolo de encuadre webSocket.

Además, la solicitud HTTP inicial puede tener una ruta de solicitud para indicar un "destino secundario" para la solicitud webSocket. Esto permite que todo tipo de solicitudes webSocket diferentes se inicien con el mismo servidor y puerto.

También hay un especificador de sub-protocolo opcional con el encabezado Sec-WebSocket-Protocol que permite que la solicitud identifique más sub protocolos (uno común podría ser "chat") para que ambas partes puedan acordar un conjunto específico de identificadores de mensajes y sus significado correspondiente que podría ser utilizado.

El hecho de que una conexión webSocket comience con una conexión HTTP es de vital importancia porque si puede comunicarse con el servidor web para una comunicación web normal, puede obtener una solicitud webSocket sin necesidad de ninguna infraestructura de red entre el cliente y el servidor para abrir nuevos huecos en el firewall o abrir nuevos puertos o algo por el estilo.

Puede ver un excelente resumen de cómo se inicia una conexión webSocket aquí: https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_servers .

El protocolo webSocket también define paquetes ping y pong que ayudan a ambas partes a saber si un webSocket inactivo todavía está conectado.

Uno solo puede suponer que la razón por la que tomó un tiempo conseguir WebSockets en todos los navegadores comunes es la misma razón por la que muchas capacidades útiles tomaron un tiempo. Primero, un grupo de personas motivadas tiene que identificar y acordar una necesidad; luego, ese grupo debe liderar el desarrollo de un enfoque para resolver el problema; luego la idea se resuelve por un tiempo, ya sea reuniendo apoyo y lidiando con objeciones o compitiendo con formas alternativas de resolver ese problema y luego parece tener suficiente impulso como para ser algo que podría convertirse en un estándar, luego alguien decide hacer una prueba / implementación de prueba en un navegador y una implementación de servidor correspondiente (a veces este paso viene mucho antes) ) Luego, si todavía está encontrando impulso y parece estar en una senda de estándares, otros fabricantes de navegadores captarán la idea y comenzarán su implementación. Una vez que todos los fabricantes de navegadores tengan una implementación de trabajo decente (generalmente hay rondas de mejora de estándares ya que las diferentes implementaciones encuentran agujeros en la especificación o cuando los primeros desarrolladores identifican problemas o faltan capacidades o surgen problemas de seguridad). Luego, llega al punto en que al menos dos navegadores principales tienen la función en sus últimos lanzamientos, el estándar se considera relativamente sólido y los consumidores comienzan a adoptar esos navegadores y algunos sitios comienzan a mejorar su experiencia de usuario al usar la nueva capacidad. En ese punto, los navegadores finales comienzan a sentir presión para implementarlo. Luego, algunas veces años después, todos los principales navegadores tienen la función y esos navegadores tienen suficiente adopción general por parte de los usuarios que los sitios web pueden confiar en la característica (sin tener que tener un segundo diseño secundario importante que funcione cuando un navegador no admita la función). . Todo este proceso puede tomar muchos, muchos años.

Aquí hay un ejemplo de la solicitud HTTP inicial para iniciar una conexión webSocket:

GET /chat HTTP/1.1 Host: example.com:8000 Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Version: 13

Y, la respuesta del servidor:

HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Y, un ejemplo de marco de datos:

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-------+-+-------------+-------------------------------+ |F|R|R|R| opcode|M| Payload len | Extended payload length | |I|S|S|S| (4) |A| (7) | (16/64) | |N|V|V|V| |S| | (if payload len==126/127) | | |1|2|3| |K| | | +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + | Extended payload length continued, if payload len == 127 | + - - - - - - - - - - - - - - - +-------------------------------+ | |Masking-key, if MASK set to 1 | +-------------------------------+-------------------------------+ | Masking-key (continued) | Payload Data | +-------------------------------- - - - - - - - - - - - - - - - + : Payload Data continued ... : + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Payload Data continued ... | +---------------------------------------------------------------+