Long Polling vs WebSocket: ¿qué elegir para tiempo real?

Long Polling vs WebSocket en JavaScript: la batalla épica por el tiempo real

Érase una vez, en una era donde internet era lento y los navegadores eran simples, la única forma de saber si había nuevos datos en el servidor era presionar F5. Luego llegó AJAX, y aprendimos a consultar el servidor manualmente. Pero, ¿qué pasa si los datos deben llegar solos, sin nuestra intervención? Bienvenidos al mundo de las comunicaciones en tiempo real.

En este artículo analizaremos los dos enfoques principales que aún dividen a la comunidad de desarrolladores: el viejo y confiable Long Polling y el moderno y audaz WebSocket. Escribiremos código en JavaScript, veremos su funcionamiento interno y entenderemos qué herramienta elegir para tu próximo proyecto. Si quieres entender de una vez por todas long polling vs websocket, estás en el lugar correcto.

El problema: ¿cómo hacer que el servidor hable primero?

HTTP es un protocolo unidireccional. El cliente (navegador) envía una solicitud, el servidor responde y listo, la comunicación termina. Pero en el mundo real (chats, cotizaciones bursátiles, notificaciones) los datos deben fluir en dirección inversa. Durante mucho tiempo, los desarrolladores tuvieron que ingeniárselas. Y aquí están las dos formas principales de resolver este problema.

Long Polling: un truco astuto con el tiempo

Imagina que llamas al servicio de atención al cliente y dices: «Esperaré en la línea hasta que un operador esté libre». No cuelgas. Así es exactamente como funciona Long Polling (también conocido como «consulta larga»).

Cómo funciona:

\n
• El cliente envía una solicitud HTTP normal.
\n
• El servidor no responde de inmediato si no hay datos. «Se queda en espera» y aguarda.
\n
• Tan pronto como aparecen datos, el servidor envía la respuesta.
\n
• El cliente procesa la respuesta e inmediatamente abre una nueva conexión.
\n

Código en el cliente (JavaScript):

function longPoll() {\n  fetch('/updates')\n    .then(response => response.json())\n    .then(data => {\n      console.log('Nuevos datos:', data);\n      // Inmediatamente iniciamos una nueva consulta\n      longPoll();\n    })\n    .catch(error => {\n      console.error('Error, reconectando en 2 seg:', error);\n      setTimeout(longPoll, 2000);\n    });\n}\n\n// Iniciamos\nlongPoll();

Ventajas:

\n
• Funciona en cualquier servidor y cualquier navegador (incluso en IE6).
\n
• No requiere protocolos especiales — es HTTP puro.
\n
• Atraviesa cualquier proxy corporativo y firewall.
\n

Desventajas:

\n
• Cada mensaje es una nueva solicitud HTTP (encabezados, cookies, gastos generales).
\n
• El servidor mantiene muchas conexiones abiertas (problema C10k — 10 mil clientes).
\n
• La latencia es mayor que en WebSocket.
\n

WebSocket: un canal de comunicación permanente

WebSocket es como una línea abierta entre una nave espacial y el centro de control. Estableces la conexión una vez, y luego ambas partes pueden enviar datos en cualquier momento, sin ceremonias adicionales.

Cómo funciona:

\n
• El cliente inicia un handshake (apretón de manos) a través de HTTP.
\n
• El servidor cambia el protocolo a ws:// o wss://.
\n
• Se establece una conexión bidireccional permanente.
\n
• Los datos se transmiten en tramas — de forma ligera y rápida.
\n

Código en el cliente (JavaScript):

const socket = new WebSocket('wss://example.com/chat');\n\n// Cuando la conexión está abierta\nsocket.onopen = function() {\n  console.log('Conexión establecida');\n  socket.send(JSON.stringify({ type: 'greeting', text: '¡Hola, servidor!' }));\n};\n\n// Cuando llega un mensaje\nsocket.onmessage = function(event) {\n  const data = JSON.parse(event.data);\n  console.log('Mensaje del servidor:', data);\n};\n\n// En caso de error\nsocket.onerror = function(error) {\n  console.error('Error de WebSocket:', error);\n};\n\n// Al cerrar\nsocket.onclose = function(event) {\n  console.log('Conexión cerrada. Código:', even