Long-Polling, WebSockets, SSE e Comet em PHP: guia completo com código

O que está por trás da atualização "ao vivo" de dados? Entendendo as tecnologias em tempo real

Você já se perguntou como funciona um chat onde as mensagens chegam instantaneamente, ou um feed de cotações da bolsa que se atualiza sozinho? A clássica requisição HTTP (quando o navegador "bate" no servidor e o servidor responde) não funciona aqui — é muito lenta e ineficiente. É necessária a mágica do tempo real.

No Stack Overflow, a pergunta "What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet?" tem milhares de visualizações. Isso significa que a confusão com esses termos é normal. Hoje vamos organizar tudo, escrever código real em PHP e entender quando usar cada tecnologia.

Não vamos usar frameworks complexos — apenas PHP puro e algumas bibliotecas populares. Vamos nessa!

1. HTTP Polling (Polling Comum) — o avô das tecnologias

Antes de falar sobre coisas avançadas, vamos relembrar o básico do polling. O cliente (JavaScript) simplesmente envia uma requisição ao servidor a cada N segundos. O servidor responde: "Sem dados novos" ou "Aqui estão os dados".

Código PHP (lado do servidor):

<?php\n// polling_server.php\nheader('Content-Type: application/json');\n\n// Simula a obtenção de dados\n$data = ['message' => 'Olá às ' . date('H:i:s')];\necho json_encode($data);\n

Lado do cliente (JavaScript):

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

Vantagens: simplicidade. Desvantagens: muitas requisições desnecessárias, sobrecarga no servidor, latência de até N segundos. Para um chat, isso é inviável.

2. Long-Polling — uma solução elegante

Long-Polling é uma versão melhorada do polling. O cliente abre uma requisição HTTP, e o servidor não responde imediatamente se não houver dados. Ele mantém a conexão aberta (fica "esperando"). Assim que os dados aparecem, o servidor envia a resposta e fecha a conexão. O cliente imediatamente abre uma nova requisição.

Do ponto de vista do cliente, é um fetch comum. Do ponto de vista do servidor, é preciso saber "dormir" e "acordar".

Exemplo de Long-Polling em PHP

<?php\n// long_polling.php\nheader('Content-Type: application/json');\nheader('Cache-Control: no-cache');\n\n// Simula a espera por novas mensagens (exemplo: de um arquivo ou BD)\n$lastCheck = time();\n$timeout = 30; // espera no máximo 30 segundos\n\nwhile (time() - $lastCheck < $timeout) {\n    // Verifica se novos dados apareceram\n    $newData = checkForNewMessages(); // sua função\n    if ($newData !== null) {\n        echo json_encode(['status' => 'ok', 'data' => $newData]);\n        exit;\n    }\n    // "Dorme" por 1 segundo para não sobrecarregar a CPU\n    sleep(1);\n}\n\n// Se não houver dados em 30 segundos, responde com vazio\necho json_encode(['status' => 'timeout', 'data' => null]);\n

Importante: Em um projeto real, substitua sleep(1) por usleep(500000) (0,5 seg) e use verificações não bloqueantes (ex.: filemtime() para arquivos ou SELECT ... FOR UPDATE com timeout no BD).

Onde é usado: chats antigos, notificações em sites sem WebSockets. Desvantagem: ainda muitas conexões, o servidor gasta recursos com requisições "penduradas".

3. Server-Sent Events (SSE) — canal unidirecional do servidor

SSE (Server-Sent Events) é uma tecnologia nativa do HTML5. O servidor pode enviar dados ao cliente a qualquer momento, mas apenas em uma direção (servidor → cliente). O cliente usa um simples EventSource em JavaScript.

SSE é ideal para: feeds de notícias, cotações, logs, notificações.

Código PHP (servidor):

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