Long-Polling, WebSockets, SSE y Comet en PHP: guía completa con código

¿Qué hay detrás de la actualización de datos «en vivo»? Analizamos las tecnologías en tiempo real

¿Alguna vez te has preguntado cómo funciona un chat donde los mensajes llegan al instante, o un panel de cotizaciones bursátiles que se actualiza solo? La clásica petición HTTP (donde el navegador llama al servidor y el servidor responde) no sirve aquí: es demasiado lenta e ineficiente. Necesitamos la magia del tiempo real.

En Stack Overflow, la pregunta «What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet?» tiene miles de visitas. Esto significa que la confusión con estos términos es algo normal. Hoy vamos a poner todo en orden, escribiremos código real en PHP y entenderemos cuándo usar cada tecnología.

No usaremos frameworks complejos, solo PHP puro y un par de bibliotecas populares. ¡Allá vamos!

1. HTTP Polling (Consulta periódica): el abuelo de las tecnologías

Antes de hablar de cosas avanzadas, recordemos el polling básico. El cliente (JavaScript) simplemente envía una petición al servidor cada N segundos. El servidor responde: «No hay datos nuevos» o «Aquí están los datos».

Código en PHP (parte del servidor):

<?php\n// polling_server.php\nheader('Content-Type: application/json');\n\n// Simulamos la obtención de datos\n$data = ['message' => 'Hola a las ' . date('H:i:s')];\necho json_encode($data);\n

Parte del cliente (JavaScript):

setInterval(() => {\n    fetch('polling_server.php')\n        .then(response => response.json())\n        .then(data => console.log(data.message));\n}, 3000); // Cada 3 segundos

Ventajas: simplicidad. Desventajas: montones de peticiones innecesarias, carga en el servidor, retraso de hasta N segundos. Para un chat, esto es fatal.

2. Long-Polling: una solución elegante

Long-Polling es una versión mejorada del polling. El cliente abre una petición HTTP, y el servidor no responde de inmediato si no hay datos. Mantiene la conexión abierta (espera). En cuanto aparecen los datos, el servidor envía la respuesta y cierra la conexión. El cliente abre inmediatamente una nueva petición.

Desde el punto de vista del cliente, es un fetch normal. Desde el punto de vista del servidor, hay que saber «dormirse» y despertarse.

Ejemplo de Long-Polling en PHP

<?php\n// long_polling.php\nheader('Content-Type: application/json');\nheader('Cache-Control: no-cache');\n\n// Simulamos la espera de nuevos mensajes (por ejemplo, de un archivo o BD)\n$lastCheck = time();\n$timeout = 30; // esperamos un máximo de 30 segundos\n\nwhile (time() - $lastCheck < $timeout) {\n    // Verificamos si hay datos nuevos\n    $newData = checkForNewMessages(); // tu función\n    if ($newData !== null) {\n        echo json_encode(['status' => 'ok', 'data' => $newData]);\n        exit;\n    }\n    // Dormimos 1 segundo para no sobrecargar el procesador\n    sleep(1);\n}\n\n// Si no hay datos en 30 segundos, respondemos con vacío\necho json_encode(['status' => 'timeout', 'data' => null]);\n

Importante: En un proyecto real, reemplaza sleep(1) por usleep(500000) (0.5 seg) y usa comprobaciones no bloqueantes (por ejemplo, filemtime() para un archivo o SELECT ... FOR UPDATE con timeout en la BD).

¿Dónde se usa? En chats antiguos, notificaciones en sitios sin WebSockets. Desventaja: siguen siendo muchas conexiones, el servidor gasta recursos en peticiones «colgadas».

3. Server-Sent Events (SSE): canal unidireccional desde el servidor

SSE (Server-Sent Events) es una tecnología integrada en HTML5. El servidor puede enviar datos al cliente en cualquier momento, pero solo en una dirección (servidor → cliente). El cliente es un EventSource normal en JavaScript.

SSE es ideal para: feeds de noticias, cotizaciones, registros (logs), notificaciones.

Código en PHP (servidor):

<?php\n// sse_server.php\nheader('Content-Type: text/event-stream');\nheader('Cache-Control: no-cache'