Qué es un WebSocket y cuándo lo necesitás de verdad
Publicado el 2026-09-12 por frfrand
Una conexión que queda abierta en las dos direcciones. Cómo empieza siendo HTTP y deja de serlo, qué cuesta mantenerla, y por qué muchas veces alcanza con algo más simple.
HTTP tiene una propiedad que define casi todo el desarrollo web: el cliente pregunta y el servidor responde. El servidor nunca habla primero.
Para una web de contenido eso está perfecto. Para un chat, un tablero en vivo o una edición colaborativa, es un problema: el servidor sabe algo nuevo y no tiene forma de avisarte.
Los WebSockets resuelven exactamente eso.
Cómo empieza
Lo interesante es que arranca como una petición HTTP normal, con una cabecera especial:
GET /ws HTTP/1.1 Upgrade: websocket Connection: Upgrade
Si el servidor acepta, responde con un código poco común:
HTTP/1.1 101 Switching Protocols
A partir de ese momento esa conexión TCP deja de hablar HTTP. Queda abierta, y los dos lados pueden mandar mensajes cuando quieran, sin pedir permiso.
Ese diseño (empezar como HTTP y después cambiar) no es capricho: es lo que permite que funcione a través de proxies y firewalls que sólo esperan tráfico web. Usa los mismos puertos 80 y 443.
Qué cuesta
Una conexión abierta por cliente. Mil usuarios conectados son mil conexiones vivas, cada una ocupando memoria y un descriptor de archivo. Es manejable, pero hay que dimensionarlo a propósito: los límites por defecto de descriptores abiertos se alcanzan antes de lo que uno espera.
El estado deja de ser trivial. Con HTTP podés poner diez servidores detrás de un balanceador y cada petición va a cualquiera. Con WebSockets, el cliente queda atado a un servidor concreto. Si querés que un mensaje llegue a un usuario conectado a otro servidor, necesitás algo en el medio que reparta (típicamente Redis).
La reconexión es tuya. Las conexiones se cortan: cambia de wifi a datos, el teléfono se duerme, un proxy corta por inactividad. El navegador no reconecta solo. Hay que implementar reintentos con espera creciente y, sobre todo, recuperar lo que pasó mientras estuviste desconectado. Ese segundo punto es el que más se olvida y el que produce bugs difíciles.
Los intermediarios cortan. Muchos proxies cierran conexiones inactivas al minuto o a los cinco. Por eso se manda un ping periódico, no por el protocolo sino para que nadie crea que está muerta.
Cuándo conviene y cuándo no
Conviene cuando el servidor tiene que hablar primero, seguido: chat, notificaciones instantáneas, cotizaciones en vivo, edición colaborativa, juegos, paneles que se actualizan solos.
No conviene cuando el evento es poco frecuente o cuando el cliente puede preguntar sin costo. Mantener mil conexiones abiertas para avisar de algo que pasa tres veces por día es un desperdicio con mantenimiento incluido.
Las alternativas que se olvidan
Consultar cada tanto. Suena primitivo y muchas veces es la respuesta correcta. Si el dato cambia cada pocos minutos y la aplicación no necesita reaccionar en el instante, una consulta periódica es infinitamente más simple de operar.
Server-Sent Events. Una conexión abierta donde sólo el servidor manda, sobre HTTP normal. El navegador reconecta solo, lo cual elimina la parte más molesta. Si sólo necesitás recibir (notificaciones, progreso de una tarea, un panel que se actualiza), esto suele ser mejor que un WebSocket y casi nadie lo considera.
La pregunta que ordena la decisión: ¿necesito mandar datos del cliente al servidor por ese mismo canal, y muy seguido? Si la respuesta es no, probablemente no necesites un WebSocket.
Una nota sobre el proxy
Si ponés nginx adelante, hace falta configurarlo para que no rompa la actualización de protocolo:
location /ws { proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 3600s; }
Sin esas líneas la conexión se establece y se corta al minuto, que es uno de los errores más frustrantes de diagnosticar porque "en local anda".