104 | Revolución en tiempo real: Inmersión en el mundo de WebSockets y Long Polling

Introducción

Los usuarios modernos esperan que las aplicaciones web funcionen con la misma rapidez y capacidad de respuesta que las aplicaciones nativas. Chats, cotizaciones en bolsa, edición colaborativa de documentos: todos estos escenarios requieren intercambio de datos instantáneo. En este artículo analizaremos cómo funciona el Long Polling, por qué fue reemplazado por WebSockets, y cómo configurar correctamente el soporte de estas tecnologías en los servidores web más populares.

El problema del tiempo real y la primera solución: Long Polling

HTTP fue diseñado originalmente bajo el modelo solicitud-respuesta: el cliente hace una petición al servidor, el servidor responde y cierra la conexión. Para aplicaciones dinámicas esto resulta inconveniente.

Long Polling

Long Polling se convirtió en una solución de compromiso:

1. El cliente envía una solicitud.
2. El servidor espera a que aparezcan datos y no responde de inmediato.
3. En cuanto hay datos — el servidor responde.
4. El cliente recibe la respuesta y abre inmediatamente una nueva conexión.

Ventajas:

• menos solicitudes innecesarias que con el polling habitual;
• los datos se entregan con mínima latencia.

Desventajas:

• sobrecarga de HTTP (cabeceras, sesiones);
• la escalabilidad sufre con miles de conexiones.

Comunicación bidireccional real: WebSockets

WebSockets cambiaron radicalmente el enfoque. Después del handshake por HTTP se realiza un “upgrade” de la conexión, que permanece abierta y permite al servidor y al cliente intercambiar datos en ambas direcciones.

Ventajas clave:

• full-duplex — intercambio bidireccional sin solicitudes adicionales;
• una sola conexión TCP — menos sobrecarga;
• baja latencia — ideal para chats, juegos, plataformas de trading;
• eficiencia — solo se transmite la carga útil.

Configuración del soporte para WebSockets

Nginx

En la configuración es importante reenviar explícitamente las cabeceras Upgrade y Connection:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend_server;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
    }
}

• proxy_http_version 1.1; — obligatorio para Upgrade.
• proxy_set_header Upgrade $http_upgrade; — transmite el protocolo.
• proxy_set_header Connection "upgrade"; — permite el upgrade.

HAProxy

HAProxy soporta WebSockets “out of the box”, pero es importante configurar los timeouts:

frontend http_front
    bind *:80
    default_backend http_back

backend http_back
    balance roundrobin
    server server1 10.0.0.10:8080 check
    timeout tunnel 1h

• timeout tunnel 1h; — previene cortes en conexiones de larga duración.

Caddy

Caddy hace todo automáticamente. Basta con una configuración básica:

example.com {
    reverse_proxy localhost:8080
}

Si se necesita más control:

example.com {
    reverse_proxy /ws/* localhost:8080 {
        header_up -Origin
    }
}

Caddy maneja el Upgrade/Connection por sí mismo, evitando ediciones manuales.

¿En qué mejora esto la experiencia de los sitios?

• Interactividad: chat, notificaciones y acciones de juego ocurren al instante.
• Reducción de carga: no hay peticiones constantes → ahorro de recursos.
• Eficiencia: las aplicaciones son más reactivas y se acercan a lo “en vivo”.

Conclusión

Long Polling fue el primer paso hacia el tiempo real, pero hoy en día el estándar de facto son los WebSockets. Entender los principios de su funcionamiento y configurar correctamente el proxy en Nginx, HAProxy o Caddy es una habilidad importante para el ingeniero DevOps y el desarrollador web moderno.

Recursos

• RFC 6455 — El protocolo WebSocket
• Nginx Docs — WebSocket proxying
• HAProxy Docs
• Proxy inverso de Caddy