Qué es WebSocket: cómo funciona y para qué sirve

WebSocket es un protocolo que mantiene un canal abierto y bidireccional entre cliente y servidor sobre una única conexión TCP. En vez de que el navegador pregunte una y otra vez «¿hay algo nuevo?», los dos extremos dejan la línea abierta y cualquiera puede enviar datos en cuanto los tenga. Esa es la base del chat en vivo, los juegos multijugador y los paneles que se actualizan solos.

Veremos cómo se abre aprovechando HTTP, qué significa «full-duplex», en qué se diferencia del polling y de SSE, sus usos y su seguridad, con las fuentes primarias a mano: el RFC 6455 del IETF y la documentación de MDN.

Qué es WebSocket

WebSocket es un protocolo de capa de aplicación que da a la web algo que HTTP no ofrece de serie: una conexión persistente donde los mensajes viajan en las dos direcciones. Un socket clásico es el punto por el que un programa se conecta a otro; WebSocket lleva esa idea al navegador sobre los mismos puertos que ya usa la web.

WebSocket no sustituye a HTTP, se apoya en él para arrancar: la conexión se abre como una petición HTTP, pide un cambio de protocolo y, a partir de ahí, empieza a usar su propio formato. Por debajo sigue habiendo TCP, el mismo transporte fiable de la web y el correo, así que todo lo que sabes sobre las capas de TCP/IP sigue aplicando.

Se estandarizó en el IETF como RFC 6455, publicado en diciembre de 2011, en plena eclosión de HTML5. La parte que usa el programador —el objeto WebSocket de JavaScript— la define el estándar vivo de HTML del WHATWG. Sus dos esquemas de URL lo resumen todo:

• ws://: WebSocket sin cifrar, puerto 80 por defecto (como HTTP).
• wss://: WebSocket sobre TLS, puerto 443 por defecto (como HTTPS).

Cómo se establece la conexión: el handshake HTTP

Lo más elegante del diseño es que WebSocket entra por donde ya entra todo: una petición HTTP. El cliente lanza un GET con tres cabeceras clave, Upgrade: websocket es la pregunta —«¿pasamos a WebSocket?»—, Sec-WebSocket-Key es un valor aleatorio que evita respuestas cacheadas y Sec-WebSocket-Version: 13 fija la versión del protocolo:

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

Si el servidor acepta, no responde con un 200 sino con 101 Switching Protocols, y devuelve una Sec-WebSocket-Accept calculada a partir de la clave del cliente. El cliente comprueba que el cálculo cuadra; si no, corta. A partir de ese 101 la conexión deja de ser HTTP y los mensajes viajan como tramas del protocolo. Si el servidor no sabe atender WebSocket, responde con un HTTP normal y no pasa nada: el cliente se queda con una página web cualquiera. Esa convivencia es la que permite atravesar servidores, proxies y firewalls que no conocen el protocolo.

Ya dentro del canal, cada mensaje viaja en una o varias tramas con un opcode que indica el tipo: texto, binario, continuación, cierre, ping o pong. El estándar exige que las tramas del cliente vayan enmascaradas (ofuscadas con una clave aleatoria) para no envenenar cachés intermedias; las del servidor, no. Y como un proxy puede cerrar una conexión inactiva, el protocolo incluye mensajes de ping/pong que las aplicaciones usan como latido. Para cerrar ordenadamente existe un close handshake con código de estado, el más común el 1000.

Full-duplex: qué significa

Decir que WebSocket es full-duplex significa que los dos extremos pueden enviar y recibir a la vez, sin turnos. En una conversación HTTP clásica el patrón es rígido: uno pide y el otro responde, y hasta que no vuelve la respuesta no hay siguiente mensaje; eso es half-duplex. WebSocket rompe el turno: el servidor empuja un dato en cuanto lo tiene, sin que nadie se lo pida, y el cliente puede hacer lo mismo en paralelo. Ahí está la clave del tiempo real.

Conviene ser honesto con el matiz: full-duplex describe el canal, no promete velocidad. WebSocket no arregla una red lenta; la latencia de ida y vuelta sigue ahí y en tiempo real importa tanto como el ancho de banda. Si la red va con retraso, antes de culpar al protocolo merece la pena medir y mejorar la velocidad de Internet.

WebSocket frente a polling, long polling y SSE

Antes de WebSocket, el tiempo real se simulaba con trucos sobre HTTP. El polling pregunta cada cierto tiempo si hay novedades: fácil, pero desperdicia, porque casi todas las peticiones vuelven vacías. El long polling deja la petición abierta hasta que hay algo que enviar o vence un tiempo de espera, y reduce el desperdicio a cambio de mantener conexiones colgadas. SSE (Server-Sent Events) es un canal de un solo sentido, del servidor al cliente, sobre un flujo text/event-stream que el navegador gestiona con EventSource y reconecta solo. Y WebSocket es el único de los cuatro que es bidireccional de verdad.

La regla práctica: si solo el servidor tiene cosas que contar, SSE suele bastar y es más simple; si hacen falta las dos direcciones y la latencia importa, WebSocket; y si los datos cambian cada mucho rato, el polling de siempre sigue siendo razonable. Las limitaciones conocidas del long polling y del streaming sobre HTTP están recogidas en el RFC 6202.

Para qué se usa WebSocket

Aparece cuando la información debe llegar sin que nadie la pida:

• Chat y mensajería. El ejemplo de manual: un mensaje tiene que aparecer al instante en la pantalla de otra persona, junto con el «escribiendo…» o los acuses de lectura.
• Juegos multijugador. Cada jugador necesita ver y enviar movimientos con el menor retraso posible; un canal persistente evita el baile de peticiones.
• Datos en vivo. Cotizaciones, resultados deportivos, telemetría de sensores o métricas que se refrescan solas en un panel.
• Edición colaborativa. Varias personas tocando el mismo documento a la vez sincronizan cambios continuamente en ambos sentidos.
• Señalización de WebRTC. Antes de que una videollamada tenga audio y vídeo, las partes intercambian información de conexión; WebSocket es una vía habitual.

Seguridad: WSS y buenas prácticas

Un WebSocket es una puerta que se queda abierta, así que conviene saber quién entra. La primera medida es usar siempre WSS: igual que hoy nadie sirve un login por HTTP en claro, no tiene sentido mover datos por un ws:// expuesto. wss:// va sobre TLS —su versión actual, TLS 1.3, está en el RFC 8446— y cifra todo el canal, credenciales incluidas. El cifrado no lo resuelve todo; estas son las precauciones que marcan la diferencia, alineadas con la guía de OWASP:

• Comprobar el origen. El navegador envía la cabecera Origin en el handshake; validarla evita que una web ajena abra una conexión en nombre de tu usuario (el cross-site WebSocket hijacking). El CORS de siempre no cubre este caso.
• Autenticar tras conectar y en cada mensaje. El canal se queda vivo mucho tiempo: hay que verificar identidad y permisos para cada acción, no solo al abrirlo.
• Desconfiar de lo que llega. Un mensaje de WebSocket es entrada de usuario: se valida, se limita su tamaño y se comprueba su formato.
• Poner límites y no colar secretos en la URL. Tamaño máximo de mensaje, número de conexiones y tiempos de espera; y los tokens van en la autenticación, no a la vista en la dirección.

Ningún protocolo es inseguro por sí mismo: lo que falla casi siempre es la configuración. Los mismos descuidos de siempre —validar poco, confiar en el origen equivocado, olvidar los permisos— son los que reaparecen; el artículo sobre qué es un hacker y qué tipos existen ayuda a ponerse en la piel de quien busca el hueco.

El estado actual de WebSocket

El protocolo cumple más de una década sin cambios de fondo, y eso es buena señal: RFC 6455 sigue siendo el estándar, la versión 13 es la que se negocia y el soporte en navegadores es universal desde hace años. HTTP/2 y HTTP/3 —este último definido en el RFC 9114— trajeron mejoras importantes, pero no han desbancado a WebSocket: resuelven cosas distintas.

Sí hay evoluciones a su alrededor. Por un lado, extensiones como permessage-deflate, descrita en el RFC 7692, que comprime los mensajes. Por otro, WebTransport, una API más reciente pensada para HTTP/3 con flujos y datagramas de muy baja latencia, que cubre casos donde WebSocket se queda corto. No viene a sustituirlo: se suma a la caja de herramientas.

Conclusión

WebSocket convirtió la web en un medio de tiempo real con una idea sencilla: arranca como una petición HTTP, pide cambiar de protocolo con un handshake y, tras el 101, mantiene un canal persistente y bidireccional donde los dos extremos hablan cuando quieren. Sobre esa base se construyen el chat, los juegos y los paneles en vivo.

La decisión no es automática: WebSocket gana cuando hacen falta las dos direcciones y baja latencia; cuando solo hay que recibir, SSE evita complicaciones. Y en cualquier caso, con wss://, validación del origen y permisos bien puestos. Handshake, full-duplex, comparación con las alternativas y seguridad: entender esas cuatro piezas es lo que separa usarlo de usarlo bien.

Preguntas frecuentes

¿WebSocket sustituye a HTTP?

No, lo complementa. La conexión empieza como una petición HTTP que pide un cambio de protocolo y, tras el 101, deja de ser HTTP. HTTP sigue sirviendo páginas y APIs; WebSocket solo se ocupa de la parte que necesita ir en tiempo real y en las dos direcciones.

¿Cuál es la diferencia entre WebSocket y un socket normal?

Un socket es el concepto general de punto de conexión entre dos programas, a más bajo nivel. WebSocket es un protocolo concreto para la web que se apoya en HTTP para abrirse y luego define sus propias tramas. Todo WebSocket usa sockets, pero no todo uso de sockets es WebSocket.

¿Qué puerto usa WebSocket?

Los mismos que HTTP: el 80 para ws:// y el 443 para wss://. Es una de sus ventajas, porque son puertos abiertos en casi cualquier red. Se puede cambiar, pero no suele hacer falta.

¿Por qué se me cae la conexión WebSocket?

Casi siempre por inactividad intermedia: proxies, balanceadores y cortafuegos cierran conexiones que llevan mucho tiempo sin tráfico. La solución estándar es el latido de ping/pong y, sobre todo, que la aplicación sepa reconectar sola. Una conexión WebSocket no es eterna: hay que asumir que se caerá y prepararse.