Programación · Web · Redes
¿Qué es un WebSocket?
La mayor parte de la web funciona por petición y respuesta: el navegador pregunta, el servidor responde, la conexión se cierra. Eso está bien para cargar una página, pero se viene abajo cuando quieres actualizaciones en vivo — un mensaje de chat, una cotización bursátil, una jugada multijugador — que el servidor necesita enviar en el instante en que ocurren. Un WebSocket es la respuesta estándar. Esta guía explica qué es un WebSocket, en qué se diferencia del HTTP corriente y cuándo lo necesitas de verdad.
La idea central: una conexión, ambos sentidos
Un WebSocket es una conexión persistente y bidireccional (full-duplex) entre un cliente — normalmente un navegador — y un servidor. Una vez abierta, cualquiera de los dos lados puede enviar un mensaje en cualquier momento, sin que el otro tenga que pedirlo primero. Esa es la diferencia clave con una API HTTP normal: HTTP es una petición, una respuesta, y se acabó; un WebSocket permanece abierto y lleva mensajes en ambos sentidos durante todo el tiempo que lo necesites.
Como la conexión ya está abierta, los mensajes llegan con muy poca sobrecarga y casi sin retardo. No hay cabeceras repetidas, ni un nuevo handshake por mensaje — solo una pequeña frame de datos en cada sentido. Eso es lo que hace que los WebSockets sean idóneos para cualquier cosa que deba sentirse instantánea.
Cómo arranca un WebSocket: el handshake HTTP
Un WebSocket no aparece de la nada — empieza como una petición HTTP corriente. El navegador envía una petición normal con una cabecera Upgrade: websocket, pidiéndole en esencia al servidor que cambie de protocolo. Si el servidor acepta, responde con el estado 101 Switching Protocols, y a partir de ese momento la misma conexión TCP deja de hablar HTTP y empieza a hablar el protocolo WebSocket. Por eso los WebSockets viajan por los mismos puertos que la web (80 y 443) y atraviesan la mayoría de los cortafuegos que ya permiten el tráfico web.
Tras el handshake, los datos se mueven como frames ligeras. Cada mensaje puede ser texto — muy a menudo JSON — o binario, y no hay una forma fija de petición/respuesta: los mensajes simplemente fluyen cuando hay algo que enviar.
ws vs wss
Las URL de WebSocket usan su propio esquema. ws:// es una conexión sin cifrar, y wss:// es la versión cifrada, asegurada con TLS exactamente igual que lo está https://. En la práctica deberías usar siempre wss:// en producción — está cifrado y es mucho menos probable que lo bloqueen los proxies y las redes corporativas que desconfían del tráfico ws:// en claro.
WebSocket, y luego escuchas los mensajes a medida que llegan.Cuándo usar un WebSocket (y cuándo no)
Los WebSockets brillan siempre que el servidor tiene que enviar datos al cliente en cuanto ocurren:
- Chat y mensajería — los mensajes aparecen en el instante en que se envían.
- Paneles y cotizaciones en vivo — tickers bursátiles, métricas, resultados deportivos.
- Colaboración — documentos y pizarras compartidos donde las ediciones se sincronizan en vivo.
- Juegos multijugador — actualizaciones de estado de baja latencia en ambos sentidos.
- Notificaciones — cualquier cosa que el usuario deba ver sin recargar.
No son la herramienta adecuada para todo. Si el cliente solo pregunta y el servidor solo responde — cargar una página, enviar un formulario, obtener un registro — una simple API HTTP es más sencilla, cacheable y más fácil de escalar. Recurre a un WebSocket cuando sea el servidor quien deba iniciar la conversación.
WebSockets vs polling vs SSE
Antes de los WebSockets, el truco habitual para datos «en vivo» era el polling: el cliente pregunta al servidor «¿hay algo nuevo?» cada pocos segundos. Funciona, pero es un desperdicio — la mayoría de las peticiones vuelven vacías, y las actualizaciones siguen llegando con el retardo del intervalo de polling. Un WebSocket reemplaza todo eso con una conexión abierta y cero peticiones desperdiciadas.
También están los Server-Sent Events (SSE), que te dan un flujo de un solo sentido del servidor al cliente sobre HTTP simple. SSE es más sencillo cuando solo necesitas que el servidor envíe (un feed de noticias, una barra de progreso). Elige un WebSocket cuando necesites que los mensajes fluyan en ambos sentidos, y SSE cuando un solo sentido basta.
Una nota sobre la infraestructura
Como un WebSocket mantiene una conexión abierta, cambia tu forma de desplegar. Las conexiones de larga duración necesitan un servidor y un proxy inverso configurados para mantenerlas vivas en lugar de cerrarlas por timeout, y escalar muchas conexiones simultáneas es un problema de diseño en sí mismo. Ese es el compromiso: un WebSocket te da comunicación instantánea y bidireccional a cambio de mantener un estado abierto en el servidor.
En resumen
Un WebSocket es una conexión única, persistente y bidireccional que permite al servidor y al navegador intercambiar mensajes en el momento en que ocurren — sin el ritmo de pedir-y-esperar del HTTP. Empieza su vida como una petición HTTP que se actualiza (upgrade), y luego lleva frames ligeras en ambos sentidos. Usa wss://, recurre a él cuando el servidor necesite enviar datos en vivo, y quédate con una API HTTP normal cuando baste con una simple petición y respuesta.