Hispanopedia Wiki
Articulo de referencia

WebSocket

WebSocket es un protocolo de comunicaciones informáticas que proporciona un canal de comunicación bidireccional a través de una única conexión TCP ( Protocolo de Control de Tran...

Hispanopedia WikiContenido en espanolLectura gratuita

WebSocket es un protocolo de comunicaciones informáticas que proporciona un canal de comunicación bidireccional a través de una única conexión TCP ( Protocolo de Control de Transmisión ). El protocolo fue estandarizado por la IETF como RFC 6455 en 2011. La especificación actual que permite a las aplicaciones web usar este protocolo se conoce como WebSockets . [ 1 ] Es un estándar vivo mantenido por el WHATWG y sucesor de la API WebSocket del W3C . [ 2 ] 

WebSocket es distinto de HTTP, el protocolo utilizado para servir la mayoría de las páginas web. Si bien son diferentes, el RFC 6455 establece que WebSocket "está diseñado para funcionar sobre los puertos HTTP 443 y 80, así como para admitir proxies e intermediarios HTTP", lo que hace que el protocolo WebSocket sea compatible con HTTP. Para lograr esta compatibilidad, el protocolo de enlace de WebSocket utiliza el encabezado HTTP Upgrade [ 3 ] para cambiar del protocolo HTTP al protocolo WebSocket. 

El protocolo WebSocket permite la interacción dúplex completo entre un navegador web (u otra aplicación cliente ) y un servidor web con una sobrecarga menor que las alternativas semidúplex como el sondeo HTTP , facilitando la transferencia de datos en tiempo real desde y hacia el servidor. Esto se logra proporcionando una forma estandarizada para que el servidor envíe contenido al cliente sin que este lo solicite previamente, y permitiendo el intercambio de mensajes mientras se mantiene la conexión abierta. De esta manera, puede tener lugar una conversación bidireccional continua entre el cliente y el servidor. Las comunicaciones generalmente se realizan a través del puerto TCP número 443 (o 80 en el caso de conexiones no seguras), lo cual es beneficioso para entornos que bloquean las conexiones a Internet que no son web mediante un firewall . Además, WebSocket permite flujos de mensajes sobre TCP. TCP por sí solo maneja flujos de bytes sin un concepto inherente de mensaje. Se han logrado comunicaciones bidireccionales similares entre navegador y servidor de maneras no estandarizadas utilizando tecnologías provisionales como Comet o Adobe Flash Player . [ 4 ]

La mayoría de los navegadores admiten el protocolo, incluidos Google Chrome , Firefox , Microsoft Edge , Internet Explorer , Safari y Opera . [ 5 ]

La especificación del protocolo WebSocket define ws(WebSocket) y wss(WebSocket Secure) como dos nuevos esquemas de identificador uniforme de recursos (URI) [ 6 ] que se utilizan para conexiones no cifradas y cifradas, respectivamente. Aparte del nombre del esquema y el fragmento (es decir, #no es compatible), el resto de los componentes del URI se definen para usar la sintaxis genérica de URI . [ 7 ]

Historia

WebSocket se mencionó por primera vez como TCPConnection en la especificación HTML5 , como un marcador de posición para una API de socket basada en TCP. [ 8 ] En junio de 2008, Michael Carter lideró una serie de discusiones que dieron como resultado la primera versión del protocolo conocido como WebSocket. [ 9 ] Antes de WebSocket, la comunicación dúplex completo del puerto 80 era posible utilizando canales Comet ; sin embargo, la implementación de Comet no es trivial y, debido al protocolo de enlace TCP y la sobrecarga del encabezado HTTP, es ineficiente para mensajes pequeños. El protocolo WebSocket tiene como objetivo resolver estos problemas sin comprometer los supuestos de seguridad de la web. El nombre "WebSocket" fue acuñado por Ian Hickson y Michael Carter poco después a través de una colaboración en la sala de chat IRC #whatwg, [ 10 ] y posteriormente fue redactado para su inclusión en la especificación HTML5 por Ian Hickson. En diciembre de 2009, Google Chrome 4 fue el primer navegador en ofrecer soporte completo para el estándar, con WebSocket habilitado por defecto. [ 11 ] El desarrollo del protocolo WebSocket fue posteriormente transferido del grupo W3C y WHATWG al IETF en febrero de 2010, y fue redactado para dos revisiones bajo la dirección de Ian Hickson. [ 12 ]

Tras la distribución del protocolo y su activación por defecto en varios navegadores, el RFC 6455 fue finalizado bajo la dirección de Ian Fette en diciembre de 2011. 

El RFC 7692 introdujo una extensión de compresión para WebSocket utilizando el algoritmo DEFLATE para cada mensaje. 

API web

Una aplicación web (por ejemplo, un navegador web) puede utilizar la WebSocketinterfaz para mantener comunicaciones bidireccionales con un servidor WebSocket. [ 13 ]

Ejemplo de cliente

En TypeScript .

// Conectar al servidor const ws = new WebSocket ( "wss://game.example.com/scoreboard" );// Recibir ArrayBuffer en lugar de Blob ws . binaryType = "arraybuffer" ;// Configurar los detectores de eventosws.onopen = () => { console.log ( " Conexión abierta" ) ; ws.send ( "Hola servidor, por favor envíame el resultado del partido de ayer " ) ; } ;ws.onmessage = ( event : MessageEvent ) => { console.log ( " Datos recibidos" , event.data ) ; ws.close ( ); // Ya obtuvimos la puntuación , así que ya no necesitamos la conexión } ;ws.onclose = ( event : CloseEvent ) = > { console.log ( " Conexión cerrada " , event.code , event.reason , event.wasClean ) ; } ;​​​​ws.onerror = () => { console.log ( "Conexión cerrada debido a un error " ) ; } ;

Interfaz WebSocket

Protocolo

Diagrama que describe una conexión mediante WebSocket.

Pasos:

  1. Apertura del protocolo de enlace : solicitud HTTP y respuesta HTTP .
  2. Intercambio de mensajes basado en tramas : datos, mensajes ping y pong.
  3. Cierre del protocolo de enlace : mensaje de cierre (la solicitud se repite en la respuesta).

Saludo de bienvenida

El cliente envía una solicitud HTTP ( método GET , versión ≥ 1.1 ) y el servidor devuelve una respuesta HTTP con código de estado 101 ( Conmutación de protocolos ) si la operación es exitosa. Los clientes HTTP y WebSocket pueden conectarse a un servidor utilizando el mismo puerto porque el protocolo de enlace inicial utiliza HTTP. Se permite el envío de encabezados HTTP adicionales (que no se encuentran en la tabla a continuación). Los encabezados HTTP pueden enviarse en cualquier orden. Después de la respuesta HTTP de Conmutación de protocolos , el protocolo de enlace inicial se completa, se deja de utilizar el protocolo HTTP y la comunicación cambia a un protocolo basado en tramas binarias. [ 33 ] [ 34 ]

Ejemplo de solicitud: [ 34 ]

GET /chat HTTP / 1.1 Host : server.example.com Upgrade : websocket Connection : Upgrade Sec-WebSocket-Key : dGhlIHNhbXBsZSBub25jZQ== Origin : http://example.com Sec-WebSocket-Protocol : chat, superchat Sec-WebSocket-Version : 13

Ejemplo de respuesta: [ 34 ]

HTTP / 1.1 101 Actualización de protocolos de conmutación : conexión websocket : actualización Sec-WebSocket-Accept : s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol : chat

El siguiente código PythonSec-WebSocket-Key genera un número aleatorio .

importar base64 importar osprint ( base64.b64encode ( os.urandom ( 16 ) ) )​​

El siguiente código Python realiza el cálculo Sec-WebSocket-Accepta Sec-WebSocket-Keypartir de la solicitud de ejemplo anterior.

import base64 import hashlibCLAVE : bytes = b "dGhlIHNhbXBsZSBub25jZQ==" MAGIA : bytes = b "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" print ( base64 . b64encode ( hashlib . sha1 ( CLAVE + MAGIA ) . digest ()))

Sec-WebSocket-Keyy Sec-WebSocket-Accepttienen como objetivo evitar que un proxy de almacenamiento en caché vuelva a enviar una conversación WebSocket anterior, [ 49 ] y no proporciona ninguna autenticación, privacidad o integridad.

Aunque algunos servidores aceptan una solicitud corta Sec-WebSocket-Key, muchos servidores modernos rechazarán la solicitud con el error "encabezado Sec-WebSocket-Key no válido".

Mensaje basado en tramas

Tras el protocolo de enlace inicial, el cliente y el servidor pueden, en cualquier momento, enviarse mensajes de datos (texto o binarios) y mensajes de control ( Close , Ping , Pong ). Un mensaje se compone de una trama si no está fragmentado o de al menos dos tramas si está fragmentado .

La fragmentación divide un mensaje en dos o más tramas . Permite enviar mensajes con datos iniciales disponibles, pero con longitud completa desconocida. Sin fragmentación, el mensaje completo debe enviarse en una sola trama, por lo que se necesita la longitud completa antes de poder enviar el primer byte, lo que requiere un búfer. [ 50 ] Se propuso extender esta función para permitir la multiplexación de varios flujos simultáneamente (por ejemplo, para evitar monopolizar un socket para una única carga útil grande ), pero la extensión del protocolo nunca fue aceptada. [ 51 ]

  • Un mensaje no fragmentado consta de un marco con FIN = 1y opcode ≠ 0.
  • Un mensaje fragmentado consta de una trama con FIN = 0y opcode ≠ 0, seguida de cero o más tramas con FIN = 0y opcode = 0, y termina con una trama con FIN = 1y opcode = 0.

Estructura del armazón

Códigos de operación

Enmascaramiento de cliente a servidor

Un cliente debe enmascarar todos los fotogramas enviados al servidor. Un servidor no debe enmascarar ningún fotograma enviado al cliente. [ 68 ] El enmascaramiento de fotogramas aplica una operación XOR entre la carga útil y la clave de enmascaramiento . El siguiente pseudocódigo describe el algoritmo utilizado para enmascarar y desenmascarar un fotograma. [ 57 ]

para i desde 0 hasta payload_length − 1 payload[i] := payload[i] xor masking_key[i mod 4]

Códigos de estado

Extensión de compresión

La permessage-deflateextensión permite comprimir los mensajes de datos mediante el algoritmo DEFLATE . Por ejemplo, durante el protocolo de enlace inicial, el cliente y el servidor pueden usar el siguiente encabezado para habilitar la extensión. El RSV1campo del primer marco de un mensaje de datos debe configurarse para indicar que los datos de la carga útil están comprimidos. [ 71 ]

Sec-WebSocket-Extensions: permessage-deflate

Ejemplo de implementación del servidor

En Python.

Nota: recv()devuelve hasta la cantidad de bytes solicitada. Para mayor claridad, el código no tiene en cuenta este dato, por lo que podría fallar en condiciones de red no ideales.

import base64 import hashlib import struct from typing import Optional from socket import socket as Socketdef handle_websocket_connection ( ws : Socket ) -> None : # Aceptar conexión conn , addr = ws . accept ()# Recibir y analizar la clave de solicitud HTTP : Opcional [ bytes ] = Ninguno para línea en conn.recv ( 4096 ) .split ( b " \ r\n " ) : si línea.startswith ( b " Sec -WebSocket-Key" ) : clave = línea.split ( ) [ - 1 ]Si la clave es None : generar ValueError ( "Sec-WebSocket-Key no encontrada" )# Enviar respuesta HTTP sec_accept = base64 . b64encode ( hashlib . sha1 ( key + b "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" ) . digest ()) conn . sendall ( b " \r\n " . join ([ b "HTTP/1.1 101 Switching Protocols" , b "Connection: Upgrade" , b "Upgrade: websocket" , b "Sec-WebSocket-Accept: " + sec_accept , b "" , b "" , ]) )# Decodificar e imprimir tramas while True : byte0 , byte1 = conn . recv ( 2 ) fin : int = byte0 >> 7 opcode : int = byte0 & 0b1111 masked : int = byte1 >> 7 assert masked , "El cliente debe enmascarar todas las tramas" if opcode >= 8 : assert fin , "Las tramas de control no se pueden fragmentar"# Tamaño de la carga útil payload_size : int = byte1 & 0b111_1111 if payload_size == 126 : payload_size , = struct.unpack ( " > H " , conn.recv ( 2 ) ) assert payload_size > 125 , " Se debe usar el número mínimo de bits" elif payload_size == 127 : payload_size , = struct.unpack ( " > Q" , conn.recv ( 8 )) assert payload_size > 2 ** 16 - 1 , "Se debe usar el número mínimo de bits" assert payload_size <= 2 ** 63 - 1 , " El bit más significativo debe ser cero" if opcode >= 8 : assert payload_size <= 125 , "Los marcos de control deben tener hasta 125 bytes"# Desenmascarar masking_key : bytes = conn.recv ( 4 ) payload : bytearray = bytearray ( conn.recv ( payload_size ) ) for i in range ( payload_size ) : payload [ i ] = payload [ i ] ^ masking_key [ i % 4 ]​imprimir ( "Marco recibido" , FIN , opcode , payload )if __name__ == "__main__" : # Aceptar conexión TCP en cualquier interfaz en el puerto 80 ws : Socket = Socket () ws.bind (( " " , 80 ) ) ws.listen ( )manejar_conexión_websocket ( ws )

Compatibilidad con navegadores

Una versión segura del protocolo WebSocket está implementada en Firefox 6, [ 72 ] Safari 6, Google Chrome 14, [ 73 ] Opera 12.10 e Internet Explorer 10. [ 74 ] Un informe detallado del conjunto de pruebas del protocolo [ 75 ] enumera la conformidad de esos navegadores con aspectos específicos del protocolo.

Una versión anterior y menos segura del protocolo se implementó en Opera 11 y Safari 5, así como en la versión móvil de Safari en iOS 4.2 . [ 76 ] El navegador BlackBerry en OS7 implementa WebSockets. [ 77 ] Debido a vulnerabilidades, se deshabilitó en Firefox 4 y 5, [ 78 ] y Opera 11. [ 79 ] Usando las herramientas para desarrolladores del navegador, los desarrolladores pueden inspeccionar el handshake de WebSocket, así como las tramas de WebSocket. [ 80 ]

Implementaciones de servidor

  • Apache HTTP Server ha sido compatible con WebSockets desde julio de 2013, implementado en la versión 2.4.5 [ 91 ] [ 92 ]
  • Los Servicios de Información de Internet agregaron soporte para WebSockets en la versión 8 que se lanzó con Windows Server 2012. [ 93 ]
  • lighttpd ha sido compatible con WebSockets desde 2017, implementado en lighttpd 1.4.46. [ 94 ] lighttpd mod_proxy puede actuar como un proxy inverso y balanceador de carga de aplicaciones WebSocket. lighttpd mod_wstunnel puede actuar como un punto final WebSocket para transmitir datos arbitrarios, incluso en formato JSON , a una aplicación de backend. lighttpd es compatible con WebSockets sobre HTTP/2 desde 2022, implementado en lighttpd 1.4.65. [ 95 ]
  • Eclipse Mosquitto es un broker MQTT , pero admite MQTT sobre WebSocket. Por lo tanto, puede considerarse un tipo de implementación de WebSocket.

ASP.NET Core tiene soporte para WebSockets mediante app.UseWebSockets();middleware. [ 96 ]

Consideraciones de seguridad

A diferencia de las solicitudes HTTP entre dominios regulares, las solicitudes WebSocket no están restringidas por la política del mismo origen . Por lo tanto, los servidores WebSocket deben validar el encabezado "Origin" contra los orígenes esperados durante el establecimiento de la conexión, para evitar ataques de secuestro de WebSocket entre sitios (similares a la falsificación de solicitudes entre sitios ), que podrían ser posibles cuando la conexión se autentica con cookies o autenticación HTTP. Es mejor usar tokens o mecanismos de protección similares para autenticar la conexión WebSocket cuando se transfieren datos sensibles (privados) a través de WebSocket. [ 97 ] Un ejemplo real de vulnerabilidad se vio en 2020 en forma de Cable Haunt .

Recorrido proxy

Las implementaciones de cliente del protocolo WebSocket intentan detectar si el agente de usuario está configurado para usar un proxy al conectarse al host y puerto de destino, y si lo está, utilizan el método HTTP CONNECT para establecer un túnel persistente.

El protocolo WebSocket no reconoce los servidores proxy ni los cortafuegos. Algunos servidores proxy son transparentes y funcionan correctamente con WebSocket; otros impiden su correcto funcionamiento, provocando fallos en la conexión. En algunos casos, puede ser necesaria una configuración adicional del servidor proxy, e incluso actualizarlo para que sea compatible con WebSocket.

Si el tráfico WebSocket no cifrado fluye a través de un servidor proxy explícito o transparente sin soporte para WebSockets, es probable que la conexión falle. [ 98 ]

Si se utiliza una conexión WebSocket cifrada, el uso de Transport Layer Security (TLS) en la conexión WebSocket Secure garantiza que HTTP CONNECTse emita un comando cuando el navegador esté configurado para usar un servidor proxy explícito. Esto establece un túnel que proporciona comunicación TCP de extremo a extremo de bajo nivel a través del proxy HTTP, entre el cliente WebSocket Secure y el servidor WebSocket. En el caso de servidores proxy transparentes, el navegador desconoce la existencia del servidor proxy, por lo que no HTTP CONNECTse envía ningún comando. Sin embargo, dado que el tráfico de red está cifrado, los servidores proxy transparentes intermedios pueden simplemente permitir el paso del tráfico cifrado, por lo que existe una probabilidad mucho mayor de que la conexión WebSocket se establezca correctamente si se utiliza WebSocket Secure. El uso del cifrado no está exento de costes de recursos, pero suele proporcionar la mayor tasa de éxito, ya que el tráfico viajaría a través de un túnel seguro.

Un borrador de mediados de 2010 (versión hixie-76) rompió la compatibilidad con proxies inversos y pasarelas al incluir ocho bytes de datos clave después de las cabeceras, pero sin anunciar esos datos en una Content-Length: 8cabecera. [ 99 ] Estos datos no fueron reenviados por todos los intermediarios, lo que podía provocar un fallo del protocolo. Borradores más recientes (por ejemplo, hybi-09 [ 100 ] ) colocaron los datos clave en una Sec-WebSocket-Keycabecera, solucionando este problema.

Véase también

Notas

  1. ↑ El algoritmo de análisis de URL se describe en https://url.spec.whatwg.org/#concept-basic-url-parser
  2. ↑ El signo más representa la concatenación de cadenas .
  3. ↑ La especificación solo restringe explícitamente las tramas de control. Por lo tanto, todas las demás tramas están restringidas por el límite del protocolo de 63 bits para la longitud de la carga útil (ya que el bit más significativo debe ser cero).
  4. 1 2 Los navegadores basados ​​en Gecko versiones 6–10 implementan el objeto WebSocket como "MozWebSocket", [ 83 ] lo que requiere código adicional para integrarse con el código existente habilitado para WebSocket.

Referencias

  1. ↑ "Estándar WebSockets" . WHATWG WebSockets . Archivado del original el 12 de marzo de 2023. Consultado el 16 de mayo de 2022 .
  2. ↑ "La API de WebSocket" . www.w3.org . Archivado del original el 8 de junio de 2022. Consultado el 16 de mayo de 2022 .
  3. ↑ Ian Fette; Alexey Melnikov (diciembre de 2011). "Relación con TCP y HTTP" . RFC 6455 El protocolo WebSocket . IETF . sec. 1.7. doi : 10.17487/RFC6455 . RFC 6455 . 
  4. ↑ "Plataforma Adobe Flash – Sockets" . help.adobe.com . Archivado del original el 18/04/2021 . Consultado el 28/07/2021 . Las conexiones TCP requieren un "cliente" y un "servidor". Flash Player puede crear sockets de cliente.
  5. ↑ "La API de WebSocket (WebSockets)" . MDN Web Docs . Mozilla Developer Network. 6 de abril de 2023. Archivado del original el 28 de julio de 2021. Consultado el 26 de julio de 2021 .
  6. ↑ Graham Klyne, ed. (14 de noviembre de 2011). "Esquemas de identificadores uniformes de recursos (URI) de IANA" . Autoridad de números asignados de Internet . Archivado del original el 25 de abril de 2013. Recuperado el 10 de diciembre de 2011 .
  7. ↑ Ian Fette; Alexey Melnikov (diciembre de 2011). "URI de WebSocket" . RFC 6455 El protocolo WebSocket . IETF . sec. 3. doi : 10.17487/RFC6455 . RFC 6455 . 
  8. ↑ "HTML 5" . www.w3.org . Archivado del original el 16 de septiembre de 2016. Consultado el 17 de abril de 2016 .
  9. ↑ " [ whatwg ] Comentarios sobre TCPConnection de Michael Carter el 18-06-2008 (whatwg.org desde junio de 2008)" . lists.w3.org . Archivado del original el 27-04-2016 . Recuperado el 17-04-2016 .
  10. ↑ "Registros de IRC: freenode / #whatwg / 20080618" . krijnhoetmer.nl . Archivado del original el 21-08-2016 . Recuperado el 18-04-2016 .
  11. ↑ "Web Sockets ya disponible en Google Chrome" . Blog de Chromium . Archivado del original el 9 de diciembre de 2021. Consultado el 17 de abril de 2016 .
  12. ↑ <ian@hixie.ch>, Ian Hickson (6 de mayo de 2010). "El protocolo WebSocket" . Ietf Datatracker . Archivado del original el 17 de marzo de 2017. Recuperado el 17 de abril de 2016 .
  13. ↑ "Introducción" . WEBSockets de WHATWG . sec. 1.
  14. ↑ "Definición de interfaz" . WHATWG WebSockets . sec. 3.1. Archivado del original el 12 de marzo de 2023. Recuperado el 10 de abril de 2024 .
  15. ↑ "new WebSocket(url, protocols)" . WHATWG WebSockets . sec. 3.1. Archivado del original el 12-03-2023 . Recuperado el 30-04-2024 .
  16. ↑ "send(data)" . WHATWG WebSockets . sec. 3.1.
  17. ↑ "close(code, reason)" . WHATWG WebSockets . sec. 3.1. Archivado del original el 12-03-2023 . Recuperado el 10-04-2024 .
  18. ↑ "Cuando se ha recibido un mensaje WebSocket" . WHATWG WebSockets . sec. 4.
  19. 1 2 "Cuando se cierra la conexión WebSocket; subpaso 3" . WHATWG WebSockets . sec. 4. Archivado del original el 12-03-2023 . Recuperado el 13-04-2024 .
  20. 1 2 La conexión WebSocket está cerrada . IETF . sec. 7.1.4. doi : 10.17487/RFC6455 . RFC 6455 . 
  21. ↑ El código de cierre de conexión WebSocket . IETF . sec. 7.1.5. doi : 10.17487/RFC6455 . RFC 6455 . 
  22. ↑ El motivo del cierre de la conexión WebSocket . IETF . sec. 7.1.6. doi : 10.17487/RFC6455 . RFC 6455 . 
  23. ↑ "socket.binaryType" . WHATWG WebSockets . sec. 3.1.
  24. ↑ "socket.bufferedAmount" . WHATWG WebSockets . sec. 3.1.
  25. ↑ "estado listo" . WHATWG WebSockets . sec. 3.1.
  26. ↑ "CONECTANDO" . WHATWG WebSockets . sec. 3.1. Archivado del original el 12-03-2023 . Recuperado el 13-04-2024 .
  27. ↑ Requisitos del cliente . IETF . pág. 14. sec. 4.1. doi : 10.17487/RFC6455 . RFC 6455 .   
  28. ↑ "OPEN" . WHATWG WebSockets . sec. 3.1. Archivado del original el 12 de marzo de 2023. Recuperado el 10 de abril de 2024 .
  29. ↑ _Se establece la conexión WebSocket_ . IETF . p. 20. doi : 10.17487/RFC6455 . RFC 6455 . 
  30. ↑ "CIERRE" . WHATWG WebSockets . sec. 3.1. Archivado del original el 12-03-2023 . Recuperado el 10-04-2024 .
  31. ↑ Se inicia el protocolo de cierre de WebSocket . IETF . sec. 7.1.3. doi : 10.17487/RFC6455 . RFC 6455 . 
  32. ↑ "CERRADO" . WHATWG WebSockets . sec. 3.1. Archivado del original el 12-03-2023 . Recuperado el 10-04-2024 .
  33. ↑ Apertura del saludo . IETF . sec. 1.3. doi : 10.17487/RFC6455 . RFC 6455 . 
  34. 1 2 3 Descripción general del protocolo . IETF . sec. 1.2. doi : 10.17487/RFC6455 . RFC 6455 . 
  35. ↑ Requisito del cliente 8. IETF . pág. 18. doi : 10.17487/RFC6455 . RFC 6455 . 
  36. ↑ Requisito del cliente 4. IETF . pág. 17. doi : 10.17487/RFC6455 . RFC 6455 . 
  37. ↑ Requisito del cliente 9. IETF . pág. 18. doi : 10.17487/RFC6455 . RFC 6455 . 
  38. ↑ Requisito del cliente 7. IETF . pág. 18. doi : 10.17487/RFC6455 . RFC 6455 . 
  39. ↑ Paso 5.4 del servidor. IETF . pág. 24. doi : 10.17487/RFC6455 . RFC 6455 . 
  40. ↑ Requisito del cliente 6. IETF . pág. 18. doi : 10.17487/RFC6455 . RFC 6455 . 
  41. ↑ Paso 5.3 del servidor . IETF . pág. 24. doi : 10.17487/RFC6455 . RFC 6455 . 
  42. ↑ Requisito del cliente 5. IETF . pág. 17. doi : 10.17487/RFC6455 . RFC 6455 . 
  43. ↑ Paso 5.2 del servidor . IETF . pág. 24. doi : 10.17487/RFC6455 . RFC 6455 . 
  44. ↑ Requisito del cliente 10. IETF . pág. 18. doi : 10.17487/RFC6455 . RFC 6455 . 
  45. ↑ Requisito del cliente 11. IETF . pág. 19. doi : 10.17487/RFC6455 . RFC 6455 . 
  46. ↑ Sec-WebSocket-Extensions . IETF . sec. 11.3.2. doi : 10.17487/RFC6455 . RFC 6455 . 
  47. ↑ Extensiones . IETF . sec. 9. doi : 10.17487/RFC6455 . RFC 6455 . 
  48. ↑ Negociación de extensiones . IETF . sec. 9.1. doi : 10.17487/RFC6455 . RFC 6455 . 
  49. ↑ "Objetivo principal del protocolo WebSocket" . IETF. Archivado del original el 22 de abril de 2016. Recuperado el 25 de julio de 2015. El cálculo [...] tiene como objetivo evitar que un intermediario de almacenamiento en caché proporcione a un cliente WS una respuesta almacenada en caché del servidor WS sin una interacción real con el servidor WS.
  50. ↑ Fragmentación . IETF . sec. 5.4. doi : 10.17487/RFC6455 . RFC 6455 . 
  51. ↑ John A. Tamplin; Takeshi Yoshino (2013). Una extensión de multiplexación para WebSockets . IETF . ID draft-ietf-hybi-websocket-multiplexing.
  52. ↑ Protocolo de trama base . IETF . sec. 5.2. doi : 10.17487/RFC6455 . RFC 6455 . 
  53. ↑ FIN . IETF . p. 28. doi : 10.17487/RFC6455 . RFC 6455 . 
  54. ↑ RSV1, RSV2, RSV3 . IETF . p. 28. doi : 10.17487/RFC6455 . RFC 6455 . 
  55. ↑ Máscara . IETF . pág. 29. doi : 10.17487/RFC6455 . RFC 6455 . 
  56. ↑ Longitud de la carga útil . IETF . pág. 29. doi : 10.17487/RFC6455 . RFC 6455 . 
  57. 1 2 Enmascaramiento de cliente a servidor . IETF . sec. 5.3. doi : 10.17487/RFC6455 . RFC 6455 . 
  58. ↑ frame-opcode . IETF . p. 31. doi : 10.17487/RFC6455 . RFC 6455 . 
  59. ↑ Opcode . IETF . p. 29. doi : 10.17487/RFC6455 . RFC 6455 . 
  60. 1 2 Extensibilidad . IETF . sec. 5.8. doi : 10.17487/RFC6455 . RFC 6455 . 
  61. ↑ Marcos de control . IETF . sec. 5.5. doi : 10.17487/RFC6455 . RFC 6455 . 
  62. ↑ Se inicia el protocolo de cierre de WebSocket . IETF . sec. 7.1.3. doi : 10.17487/RFC6455 . RFC 6455 . 
  63. ↑ Cierre del apretón de manos . IETF . sec. 1.4. doi : 10.17487/RFC6455 . RFC 6455 . 
  64. ↑ Cerrar . IETF . sec. 5.5.1. doi : 10.17487/RFC6455 . RFC 6455 . 
  65. ↑ Ping . IETF . sec. 5.5.2. doi : 10.17487/RFC6455 . RFC 6455 . 
  66. ↑ Pong . IETF . sec. 5.5.3. doi : 10.17487/RFC6455 . RFC 6455 . 
  67. ↑ "Tramas Ping y Pong" . WebSockets de WHATWG .
  68. ↑ Resumen . IETF . sec. 5.1. doi : 10.17487/RFC6455 . RFC 6455 . 
  69. ↑ Rangos de códigos de estado reservados . IETF . sec. 7.4.2. doi : 10.17487/RFC6455 . RFC 6455 . 
  70. ↑ Códigos de estado definidos . IETF . sec. 7.4.1. doi : 10.17487/RFC6455 . RFC 6455 . 
  71. ↑ Extensiones de compresión para WebSocket . IETF . doi : 10.17487/RFC7692 . RFC 7692 .
  72. ↑ Dirkjan Ochtman (27 de mayo de 2011). "WebSocket habilitado en Firefox 6" . Mozilla.org . Archivado del original el 26 de mayo de 2012. Consultado el 30 de junio de 2011 .
  73. ↑ "Estado de la plataforma web Chromium" . Archivado del original el 4 de marzo de 2017. Consultado el 3 de agosto de 2011 .
  74. ↑ "WebSockets (Windows)" . Microsoft. 28 de septiembre de 2012. Archivado del original el 25 de marzo de 2015. Consultado el 7 de noviembre de 2012 .
  75. ↑ "Informe de prueba del protocolo WebSockets" . Tavendo.de. 27 de octubre de 2011. Archivado del original el 22 de septiembre de 2016. Consultado el 10 de diciembre de 2011 .
  76. ↑ Katie Marsal (23 de noviembre de 2010). "Apple añade compatibilidad con acelerómetro y WebSockets a Safari en iOS 4.2" . AppleInsider.com . Archivado del original el 1 de marzo de 2011. Consultado el 9 de mayo de 2011 .
  77. ↑ "API de Web Sockets" . BlackBerry . Archivado del original el 10 de junio de 2011. Consultado el 8 de julio de 2011 .
  78. ↑ Chris Heilmann (8 de diciembre de 2010). "WebSocket deshabilitado en Firefox 4" . Hacks.Mozilla.org . Archivado del original el 6 de marzo de 2017. Consultado el 9 de mayo de 2011 .
  79. ↑ Aleksander Aas (10 de diciembre de 2010). "Respecto a WebSocket" . Mi blog de Opera . Archivado del original el 15 de diciembre de 2010. Consultado el 9 de mayo de 2011 .
  80. ↑ Wang, Vanessa; Salim, Frank; Moskovits, Peter (febrero de 2013). «APÉNDICE A: Inspección de marcos WebSocket con las herramientas para desarrolladores de Google Chrome» . La guía definitiva de HTML5 WebSocket . Apress. ISBN 978-1-4302-4740-1Archivado del original el 31 de diciembre de 2015. Consultado el 7 de abril de 2013 .
  81. ↑ "WebSockets (compatibilidad con Firefox)" . developer.mozilla.org . Fundación Mozilla. 30 de septiembre de 2011. Archivado del original el 26 de mayo de 2012. Consultado el 10 de diciembre de 2011 .
  82. ↑ "Error 640003 - WebSockets - actualización a ietf-06" . Fundación Mozilla. 8 de marzo de 2011. Archivado del original el 1 de abril de 2021. Consultado el 10 de diciembre de 2011 .
  83. ↑ "WebSockets - MDN" . developer.mozilla.org . Fundación Mozilla. 30 de septiembre de 2011. Archivado del original el 26 de mayo de 2012. Consultado el 10 de diciembre de 2011 .
  84. ↑ "Bug 640003 - WebSockets - actualización a ietf-07 (comentario 91)" . Fundación Mozilla. 22 de julio de 2011. Archivado del original el 1 de abril de 2021. Consultado el 28 de julio de 2011 .
  85. ↑ "Chromium bug 64470" . code.google.com . 25/11/2010. Archivado del original el 31/12/2015 . Consultado el 10/12/2011 .
  86. ↑ "WebSockets en la versión preliminar para consumidores de Windows" . Equipo de ingeniería de IE . Microsoft. 19 de marzo de 2012. Archivado del original el 6 de septiembre de 2015. Consultado el 23 de julio de 2012 .
  87. ↑ "WebKit Changeset 97247: WebSocket: Actualizar el protocolo WebSocket a hybi-17" . trac.webkit.org . Archivado del original el 5 de enero de 2012. Consultado el 10 de diciembre de 2011 .
  88. ↑ "Una instantánea veraniega de Opera 12.50" . Noticias para desarrolladores de Opera. 3 de agosto de 2012. Archivado del original el 5 de agosto de 2012. Consultado el 3 de agosto de 2012 .
  89. ↑ "¡Bienvenido a nginx!" . nginx.org . Archivado del original el 17 de julio de 2012 . Consultado el 3 de febrero de 2022 .
  90. ↑ "Uso de NGINX como proxy WebSocket" . NGINX . 17 de mayo de 2014. Archivado del original el 6 de octubre de 2019. Consultado el 3 de noviembre de 2019 .
  91. ↑ "Descripción general de las nuevas características del servidor HTTP Apache 2.4" . Apache . Archivado del original el 11 de noviembre de 2020. Consultado el 26 de enero de 2021 .
  92. ↑ "Registro de cambios Apache 2.4" . Apache Lounge . Archivado del original el 22/01/2021 . Consultado el 26/01/2021 .
  93. ↑ "Compatibilidad con el protocolo WebSocket de IIS 8.0" . Microsoft Docs . 28 de noviembre de 2012. Archivado del original el 18 de febrero de 2020. Consultado el 18 de febrero de 2020 .
  94. ↑ "Release-1 4 46 - Lighttpd - lighty labs" . Archivado del original el 16 de enero de 2021. Consultado el 29 de diciembre de 2020 .
  95. ↑ "Release-1 4 65 - Lighttpd - lighty labs" . Archivado del original el 3 de mayo de 2024. Consultado el 3 de mayo de 2024 .
  96. ↑ "Soporte para WebSockets en ASP.NET Core" . learn.microsoft.com . Consultado el 2 de mayo de 2025 .
  97. ↑ Christian Schneider (31 de agosto de 2013). "Secuestro de WebSocket entre sitios (CSWSH)" . Blog de seguridad de aplicaciones web . Archivado del original el 31 de diciembre de 2016. Consultado el 30 de diciembre de 2015 .
  98. ↑ Peter Lubbers (16 de marzo de 2010). "Cómo interactúan los Web Sockets de HTML5 con los servidores proxy" . Infoq.com . C4Media Inc. Archivado del original el 8 de mayo de 2016. Consultado el 10 de diciembre de 2011 .
  99. ↑ Willy Tarreau (6 de julio de 2010). "WebSocket -76 es incompatible con proxies inversos HTTP" . ietf.org (correo electrónico). Grupo de Trabajo de Ingeniería de Internet. Archivado del original el 17 de septiembre de 2016. Consultado el 10 de diciembre de 2011 .
  100. ↑ Ian Fette (13 de junio de 2011). "Sec-WebSocket-Key" . El protocolo WebSocket, borrador hybi-09 . IETF . sec. 11.4 . Consultado el 15 de junio de 2011 . Archivado el 1 de febrero de 2016 en Wayback Machine .
  • Grupo de trabajo de hipertexto bidireccional (HyBi) de la IETF
    • RFC 6455 El protocolo WebSocket: estándar propuesto publicado por el Grupo de Trabajo HyBi de la IETF. 
    • El protocolo WebSocket : borrador de Internet publicado por el Grupo de Trabajo HyBi de la IETF.
    • El protocolo WebSocket : propuesta de protocolo original de Ian Hickson.
  • La API WebSocket archivada el 7 de junio de 2015 en Wayback Machine : especificación preliminar de la API del W3C.
  • La API WebSocket : especificación de la API candidata a recomendación del W3C
  • WebSocket.org Archivado el 16/09/2018 en Wayback Machine. Demostraciones de WebSocket, pruebas de bucle invertido, información general y comunidad.
Lecturas relacionadas
6 articulos
Figura 2. Protocolos en relación con el esquema de capas de Internet.Protocolo de comunicaciónUn protocolo de comunicación es un sistema de reglas que permite que dos o más entidades de un sistema de comunicaciones transmitan información a t...Duplex (telecomunicaciones)Duplex (telecomunicaciones)Un sistema de comunicación dúplex es un sistema punto a punto compuesto por dos o más partes o dispositivos conectados que pueden comunicarse entre...Protocolo de control de transmisiónProtocolo de control de transmisiónEl Protocolo de Control de Transmisión ( TCP ) es uno de los principales protocolos de la suite de protocolos de Internet . Se originó en la implem...Grupo de trabajo de ingeniería de InternetEl Grupo de Trabajo de Ingeniería de Internet ( IETF ) es una organización de normalización para Internet y es responsable de los estándares técnic...Solicitud de comentariosUna solicitud de comentarios ( RFC ) es una publicación de una serie de los principales organismos de desarrollo técnico y establecimiento de están...Edita esto en Wikidata¿QUÉ?El Grupo de Trabajo de Tecnología de Aplicaciones de Hipertexto Web ( WHATWG ) fue fundado en 2004 por representantes de Apple Inc. , la Fundación ...