WebSocket es un protocolo de comunicación sobre una conexión TCP diseñado para intercambiar mensajes entre un navegador y un servidor web mediante una conexión persistente.
Actualmente, el W3C está estandarizando la API de Web Sockets. El proyecto de norma para este protocolo ha sido aprobado por el IETF .
WebSocket está diseñado para implementarse en navegadores web y servidores web, pero puede usarse para cualquier aplicación cliente o servidor. El protocolo WebSocket es un protocolo independiente basado en el protocolo TCP. Permite una interacción más cercana entre el navegador y el sitio web, facilitando la distribución de contenido interactivo y la creación de aplicaciones en tiempo real.
El cliente y el servidor utilizan un protocolo similar a HTTP para establecer una conexión WebSocket . El cliente genera una solicitud HTTP especial, a la que el servidor responde de cierta manera.
Antes de la revisión del borrador del protocolo número 75 Copia de archivo con fecha del 8 de junio de 2010 en Wayback Machine inclusive, la conexión WebSocket se estableció de la siguiente manera. Solicitud del cliente:
OBTENER /demostración HTTP/1.1 Actualizar: WebSocket Conexión: Actualizar host: ejemplo.com Origen: http://ejemplo.com Protocolo WebSocket: muestraRespuesta del servidor que confirma el cambio a WebSocket:
Protocolo de enlace HTTP/1.1 101 Web Socket Actualizar: WebSocket Conexión: Actualizar Origen de WebSocket: http://ejemplo.com Ubicación de WebSocket: ws://example.com/demo Protocolo WebSocket: muestraInmediatamente después de enviar la respuesta, la conexión WebSocket se considera establecida, el cliente y el servidor pueden iniciar la mensajería bidireccional a través de la misma conexión TCP . Para enviar un mensaje de texto (en codificación UTF-8 ), debe enviar un byte nulo antes y después, un byte con el valor 255.
El 2 de junio de 2010, se modificó el protocolo WebSocket para cambiar el procedimiento para establecer una conexión WebSocket sin mantener la compatibilidad con versiones anteriores. A los 76 Archivado el 19 de abril de 2012. El borrador de revisión del protocolo WebSocket agregó protección contra solicitudes falsificadas. Un cliente que admite el nuevo esquema envía la siguiente solicitud:
OBTENER /demostración HTTP/1.1 Actualizar: WebSocket Conexión: Actualizar Sec-WebSocket-Key2: 4 @1 46546xW%0l 1 5 host: ejemplo.com Sec-WebSocket-Key1: 12998 5 Y3 1 .P00 Origen: http://ejemplo.com Protocolo WebSocket: muestra ^n:ds[4USe agregaron nuevos encabezados "Sec-WebSocket-Key1" y "Sec-WebSocket-Key2" y un cuerpo de solicitud de 8 bytes a la solicitud. Todos ellos son generados aleatoriamente por el cliente.
Respuesta del servidor que confirma el cambio a WebSocket:
Protocolo de enlace HTTP/1.1 101 Web Socket Actualizar: WebSocket Conexión: Actualizar Sec-WebSocket-Origin: http://example.com Sec-WebSocket-Ubicación: ws://example.com/demo Sec-WebSocket-Protocol: muestra 8jKS'y:G*Co,Wxa-La respuesta contiene nuevos nombres de encabezado ("Sec-WebSocket-Origin", "Sec-WebSocket-Location", "Sec-WebSocket-Protocol" en lugar de "WebSocket-Origin", "WebSocket-Location", "WebSocket-Protocol") y cuerpo de respuesta de 16 bytes, evaluado de la siguiente manera:
notas
A pesar de la "similitud" de las nuevas solicitudes y respuestas a las solicitudes y respuestas del protocolo HTTP , no lo son. Por ejemplo, la solicitud tiene un cuerpo, pero falta el campo "Content-Length" en los encabezados (lo que viola las convenciones de HTTP ).
El backend DEBERÍA admitir ambos tipos de clientes y distinguirlos por la presencia o ausencia de los encabezados Sec-WebSocket-Key1 y Sec-WebSocket-Key2 en la solicitud.
A la versión 07 Archivado el 19 de abril de 2012. se modificó el proyecto de protocolo de fecha 22 de abril de 2011.
A diferencia del protocolo 76, según el cual los datos se transmiten sin encriptar [1] , cada byte de datos transmitido desde el cliente (navegador) al servidor en esta versión del protocolo está necesariamente enmascarado con una máscara de 4 bytes [2] . Se crea para cada mensaje de nuevo.
El mensaje que se envía ahora tiene un encabezado que contiene datos como:
La interacción entre el cliente y el servidor comienza con una solicitud del cliente:
OBTENER /chat HTTP/1.1 Host: servidor.ejemplo.com Actualización: websocket Conexión: Actualizar Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Origin: http://example.com Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Versión: 7La respuesta del servidor se ve así:
HTTP/1.1 101 Protocolos de conmutación Actualización: websocket Conexión: Actualizar Sec-WebSocket-Aceptar: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocolo: chatLa respuesta contiene un encabezado Sec-WebSocket-Protocol con un solo protocolo elegido por el servidor (chat) de todos los admitidos por el cliente (chat, superchat). El encabezado Sec-WebSocket-Accept se forma de la siguiente manera:
Un ejemplo de la implementación del algoritmo anterior en PHP :
<?php echo base64_encode ( SHA1 ( "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-C5AB0DC85B11" , verdadero )); ?>El 11 de diciembre de 2011, el protocolo adquirió el estatus de RFC .
El encabezado Sec-WebSocket-Origin ahora es solo Origin .
El protocolo Web Socket define dos esquemas de URI , ws: (conexión sin cifrar) y wss: (conexión cifrada).
Para establecer una conexión, la secuencia de comandos del cliente crea un objeto WebSocket, pasa el parámetro URI de WebSocket a su constructor y define las funciones de devolución de llamada para conectarse, recibir un mensaje y desconectarse.
< html > < encabezado > < script > const webSocket = new WebSocket ( 'ws://localhost/echo' ); webSocket . onopen = evento => { alerta ( 'onopen' ); webSocket . enviar ( "¡Hola Web Socket!" ); }; webSocket . onmessage = evento => { alerta ( 'onmessage, ' + event . data ); }; webSocket . onclose = evento => { alerta ( 'onclose' ); }; </ script > </ head > < cuerpo > </ cuerpo > </ html >Actualmente, WebSocket es compatible con los siguientes navegadores:
Puede verificar si su navegador es compatible con WebSocket siguiendo el enlace: http://caniuse.com/#feat=websockets Archivado el 8 de abril de 2017 en Wayback Machine .
A finales de noviembre de 2010, Adam Barth publicó los resultados de un estudio sobre la fiabilidad del protocolo utilizado [3] . Según sus resultados, resultó que en el caso de usar servidores proxy transparentes, es posible reemplazar el caché de datos transmitidos para que, en lugar de datos reales, los usuarios reciban una versión de los datos de un atacante. El problema resultó ser lo suficientemente grave como para que los desarrolladores de Firefox y Opera anunciaran en Wayback Machine. Archivado el 11 de enero de 2011 que en futuras versiones de sus navegadores, la compatibilidad con sockets web estará deshabilitada de forma predeterminada hasta que se solucione la inseguridad de este protocolo ( aunque sigue siendo posible encenderlos).