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...

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 tenemos la puntuación , así que 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 ignora 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

A secure version of the WebSocket protocol is implemented in Firefox 6,[72] Safari 6, Google Chrome 14,[73]Opera 12.10 and Internet Explorer 10.[74] A detailed protocol test suite report[75] lists the conformance of those browsers to specific protocol aspects.

An older, less secure version of the protocol was implemented in Opera 11 and Safari 5, as well as the mobile version of Safari in iOS 4.2.[76] The BlackBerry Browser in OS7 implements WebSockets.[77] Because of vulnerabilities, it was disabled in Firefox 4 and 5,[78] and Opera 11.[79] Using browser developer tools, developers can inspect the WebSocket handshake as well as the WebSocket frames.[80]

Server implementations

  • Apache HTTP Server has supported WebSockets since July, 2013, implemented in version 2.4.5[91][92]
  • Internet Information Services added support for WebSockets in version 8 which was released with 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 ]

If an encrypted WebSocket connection is used, then the use of Transport Layer Security (TLS) in the WebSocket Secure connection ensures that an HTTP CONNECT command is issued when the browser is configured to use an explicit proxy server. This sets up a tunnel, which provides low-level end-to-end TCP communication through the HTTP proxy, between the WebSocket Secure client and the WebSocket server. In the case of transparent proxy servers, the browser is unaware of the proxy server, so no HTTP CONNECT is sent. However, since the wire traffic is encrypted, intermediate transparent proxy servers may simply allow the encrypted traffic through, so there is a much better chance that the WebSocket connection will succeed if WebSocket Secure is used. Using encryption is not free of resource cost, but often provides the highest success rate, since it would be travelling through a secure tunnel.

A mid-2010 draft (version hixie-76) broke compatibility with reverse proxies and gateways by including eight bytes of key data after the headers, but not advertising that data in a Content-Length: 8 header.[99] This data was not forwarded by all intermediates, which could lead to protocol failure. More recent drafts (e.g., hybi-09[100]) put the key data in a Sec-WebSocket-Key header, solving this problem.

See also

Notes

  1. The URL parsing algorithm is described at https://url.spec.whatwg.org/#concept-basic-url-parser
  2. The plus sign represents string concatenation.
  3. The specification only explicitly restricts control frames. Thus, all other frames are restricted by the protocol limit of 63 bits for payload length (as the most significant bit must be zero).
  4. 12Gecko-based browsers versions 6–10 implement the WebSocket object as "MozWebSocket",[83] requiring extra code to integrate with existing WebSocket-enabled code.

References

  1. "WebSockets Standard". WHATWG WebSockets. Archived from the original on 2023-03-12. Retrieved 2022-05-16.
  2. "The WebSocket API". www.w3.org. Archived from the original on 2022-06-08. Retrieved 2022-05-16.
  3. Ian Fette; Alexey Melnikov (December 2011). "Relationship to TCP and HTTP". RFC 6455 The WebSocket Protocol. IETF. sec. 1.7. doi:10.17487/RFC6455. RFC6455.
  4. "Adobe Flash Platform – Sockets". help.adobe.com. Archived from the original on 2021-04-18. Retrieved 2021-07-28. TCP connections require a "client" and a "server". Flash Player can create client sockets.
  5. "The WebSocket API (WebSockets)". MDN Web Docs. Mozilla Developer Network. 2023-04-06. Archived from the original on 2021-07-28. Retrieved 2021-07-26.
  6. Graham Klyne, ed. (2011-11-14). "IANA Uniform Resource Identifier (URI) Schemes". Internet Assigned Numbers Authority. Archived from the original on 2013-04-25. Retrieved 2011-12-10.
  7. Ian Fette; Alexey Melnikov (December 2011). "WebSocket URIs". RFC 6455 The WebSocket Protocol. IETF. sec. 3. doi:10.17487/RFC6455. RFC6455.
  8. "HTML 5". www.w3.org. Archived from the original on 2016-09-16. Retrieved 2016-04-17.
  9. "[whatwg] TCPConnection feedback from Michael Carter on 2008-06-18 (whatwg.org from June 2008)". lists.w3.org. Archived from the original on 2016-04-27. Retrieved 2016-04-17.
  10. "IRC logs: freenode / #whatwg / 20080618". krijnhoetmer.nl. Archived from the original on 2016-08-21. Retrieved 2016-04-18.
  11. "Web Sockets Now Available In Google Chrome". Chromium Blog. Archived from the original on 2021-12-09. Retrieved 2016-04-17.
  12. <ian@hixie.ch>, Ian Hickson (6 May 2010). "The WebSocket protocol". Ietf Datatracker. Archived from the original on 2017-03-17. Retrieved 2016-04-17.
  13. "Introduction". WHATWG WebSockets. sec. 1.
  14. "Interface definition". WHATWG WebSockets. sec. 3.1. Archived from the original on 2023-03-12. Retrieved 2024-04-10.
  15. "new WebSocket(url, protocols)". WHATWG WebSockets. sec. 3.1. Archived from the original on 2023-03-12. Retrieved 2024-04-30.
  16. "send(data)". WHATWG WebSockets. sec. 3.1.
  17. "close(code, reason)". WHATWG WebSockets. sec. 3.1. Archived from the original on 2023-03-12. Retrieved 2024-04-10.
  18. "When a WebSocket message has been received". WHATWG WebSockets. sec. 4.
  19. 12"When the WebSocket connection is closed; substep 3". WHATWG WebSockets. sec. 4. Archived from the original on 2023-03-12. Retrieved 2024-04-13.
  20. 12The WebSocket Connection is Closed. IETF. sec. 7.1.4. doi:10.17487/RFC6455. RFC6455.
  21. The WebSocket Connection Close Code. IETF. sec. 7.1.5. doi:10.17487/RFC6455. RFC6455.
  22. The WebSocket Connection Close Reason. IETF. sec. 7.1.6. doi:10.17487/RFC6455. RFC6455.
  23. "socket.binaryType". WHATWG WebSockets. sec. 3.1.
  24. "socket.bufferedAmount". WHATWG WebSockets. sec. 3.1.
  25. "ready state". WHATWG WebSockets. sec. 3.1.
  26. "CONNECTING". WHATWG WebSockets. sec. 3.1. Archived from the original on 2023-03-12. Retrieved 2024-04-13.
  27. Client Requirements. IETF. p. 14. sec. 4.1. doi:10.17487/RFC6455. RFC6455.
  28. "OPEN". WHATWG WebSockets. sec. 3.1. Archived from the original on 2023-03-12. Retrieved 2024-04-10.
  29. _The WebSocket Connection is Established_. IETF. p. 20. doi:10.17487/RFC6455. RFC6455.
  30. "CLOSING". WHATWG WebSockets. sec. 3.1. Archived from the original on 2023-03-12. Retrieved 2024-04-10.
  31. The WebSocket Closing Handshake is Started. IETF. sec. 7.1.3. doi:10.17487/RFC6455. RFC6455.
  32. "CLOSED". WHATWG WebSockets. sec. 3.1. Archived from the original on 2023-03-12. Retrieved 2024-04-10.
  33. Opening Handshake. IETF. sec. 1.3. doi:10.17487/RFC6455. RFC6455.
  34. 123Protocol Overview. IETF. sec. 1.2. doi:10.17487/RFC6455. RFC6455.
  35. Client requirement 8.IETF. p. 18. doi:10.17487/RFC6455. RFC6455.
  36. Client requirement 4.IETF. p. 17. doi:10.17487/RFC6455. RFC6455.
  37. Client requirement 9.IETF. p. 18. doi:10.17487/RFC6455. RFC6455.
  38. Client requirement 7.IETF. p. 18. doi:10.17487/RFC6455. RFC6455.
  39. Server step 5.4.IETF. p. 24. doi:10.17487/RFC6455. RFC6455.
  40. Client requirement 6.IETF. p. 18. doi:10.17487/RFC6455. RFC6455.
  41. Server step 5.3. IETF. p. 24. doi:10.17487/RFC6455. RFC6455.
  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. Reserved Status Code Ranges. IETF. sec. 7.4.2. doi:10.17487/RFC6455. RFC6455.
  70. Defined Status Codes. IETF. sec. 7.4.1. doi:10.17487/RFC6455. RFC6455.
  71. Compression Extensions for WebSocket. IETF. doi:10.17487/RFC7692. RFC7692.
  72. Dirkjan Ochtman (May 27, 2011). "WebSocket enabled in Firefox 6". Mozilla.org. Archived from the original on 2012-05-26. Retrieved 2011-06-30.
  73. "Chromium Web Platform Status". Archived from the original on 2017-03-04. Retrieved 2011-08-03.
  74. "WebSockets (Windows)". Microsoft. 2012-09-28. Archived from the original on 2015-03-25. Retrieved 2012-11-07.
  75. "WebSockets Protocol Test Report". Tavendo.de. 2011-10-27. Archived from the original on 2016-09-22. Retrieved 2011-12-10.
  76. Katie Marsal (November 23, 2010). "Apple adds accelerometer, WebSockets support to Safari in iOS 4.2". AppleInsider.com. Archived from the original on 2011-03-01. Retrieved 2011-05-09.
  77. "Web Sockets API". BlackBerry. Archived from the original on June 10, 2011. Retrieved 8 July 2011.
  78. Chris Heilmann (December 8, 2010). "WebSocket disabled in Firefox 4". Hacks.Mozilla.org. Archived from the original on 2017-03-06. Retrieved 2011-05-09.
  79. Aleksander Aas (December 10, 2010). "Regarding WebSocket". My Opera Blog. Archived from the original on 2010-12-15. Retrieved 2011-05-09.
  80. Wang, Vanessa; Salim, Frank; Moskovits, Peter (February 2013). "APPENDIX A: WebSocket Frame Inspection with Google Chrome Developer Tools". The Definitive Guide to HTML5 WebSocket. Apress. ISBN 978-1-4302-4740-1. Archived from the original on 31 December 2015. Retrieved 7 April 2013.
  81. "WebSockets (support in Firefox)". developer.mozilla.org. Mozilla Foundation. 2011-09-30. Archived from the original on 2012-05-26. Retrieved 2011-12-10.
  82. "Bug 640003 - WebSockets - upgrade to ietf-06". Mozilla Foundation. 2011-03-08. Archived from the original on 2021-04-01. Retrieved 2011-12-10.
  83. "WebSockets - MDN". developer.mozilla.org. Mozilla Foundation. 2011-09-30. Archived from the original on 2012-05-26. Retrieved 2011-12-10.
  84. "Bug 640003 - WebSockets - upgrade to ietf-07(comment 91)". Mozilla Foundation. 2011-07-22. Archived from the original on 2021-04-01. Retrieved 2011-07-28.
  85. "Chromium bug 64470". code.google.com. 2010-11-25. Archived from the original on 2015-12-31. Retrieved 2011-12-10.
  86. "WebSockets in Windows Consumer Preview". IE Engineering Team. Microsoft. 2012-03-19. Archived from the original on 2015-09-06. Retrieved 2012-07-23.
  87. "WebKit Changeset 97247: WebSocket: Update WebSocket protocol to hybi-17". trac.webkit.org. Archived from the original on 2012-01-05. Retrieved 2011-12-10.
  88. "A hot Opera 12.50 summer-time snapshot". Opera Developer News. 2012-08-03. Archived from the original on 2012-08-05. Retrieved 2012-08-03.
  89. "Welcome to nginx!". nginx.org. Archived from the original on 17 July 2012. Retrieved 3 February 2022.
  90. "Using NGINX as a WebSocket Proxy". NGINX. May 17, 2014. Archived from the original on October 6, 2019. Retrieved November 3, 2019.
  91. "Overview of new features in Apache HTTP Server 2.4". Apache. Archived from the original on 2020-11-11. Retrieved 2021-01-26.
  92. "Changelog Apache 2.4". Apache Lounge. Archived from the original on 2021-01-22. Retrieved 2021-01-26.
  93. "IIS 8.0 WebSocket Protocol Support". Microsoft Docs. 28 November 2012. Archived from the original on 2020-02-18. Retrieved 2020-02-18.
  94. "Release-1 4 46 - Lighttpd - lighty labs". Archived from the original on 2021-01-16. Retrieved 2020-12-29.
  95. "Release-1 4 65 - Lighttpd - lighty labs". Archived from the original on 2024-05-03. Retrieved 2024-05-03.
  96. "WebSockets support in ASP.NET Core". learn.microsoft.com. Retrieved 2 May 2025.
  97. Christian Schneider (August 31, 2013). "Cross-Site WebSocket Hijacking (CSWSH)". Web Application Security Blog. Archived from the original on December 31, 2016. Retrieved December 30, 2015.
  98. Peter Lubbers (March 16, 2010). "How HTML5 Web Sockets Interact With Proxy Servers". Infoq.com. C4Media Inc. Archived from the original on 2016-05-08. Retrieved 2011-12-10.
  99. Willy Tarreau (2010-07-06). "WebSocket -76 is incompatible with HTTP reverse proxies". ietf.org (email). Internet Engineering Task Force. Archived from the original on 2016-09-17. Retrieved 2011-12-10.
  100. Ian Fette (June 13, 2011). "Sec-WebSocket-Key". The WebSocket protocol, draft hybi-09. IETF. sec. 11.4. Retrieved June 15, 2011.Archived February 1, 2016, at the Wayback Machine
  • IETF Hypertext-Bidirectional (HyBi) working group
    • RFC 6455 The WebSocket protocol – Proposed Standard published by the IETF HyBi Working Group
    • The WebSocket protocol – Internet-Draft published by the IETF HyBi Working Group
    • The WebSocket protocol – Original protocol proposal by Ian Hickson
  • The WebSocket APIArchived 2015-06-07 at the Wayback Machine – W3C Working Draft specification of the API
  • 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.
Obtenido de " https://en.wikipedia.org/w/index.php?title=WebSocket&oldid=1344988474 "