Long polling vs WebSocket em PHP: qual escolher para projetos em tempo real

Treinador Online de Python para Iniciantes

Aprenda Python facilmente sem sobrecarga teórica. Resolva tarefas práticas com verificação automática e escreva código diretamente no navegador.

Start Course

Introdução: por que seu site "travou" em tempo real?

\n\n

Imagine que você acessou um site de câmbio, mas a cotação do dólar só atualiza quando você recarrega a página. Ou você enviou uma mensagem no chat, mas o interlocutor só viu depois de 10 segundos. Familiar? Essa é a dor de qualquer desenvolvedor que tenta tornar uma aplicação "viva".

\n\n

No mundo do PHP, onde cada requisição vive sua curta vida, implementar funcionalidades em tempo real é um desafio. As duas principais abordagens que vêm ao resgate são Long polling e WebSocket. Qual delas escolher para o seu projeto em PHP? Vamos descobrir sem rodeios, com exemplos práticos de código.

\n\n

O que é Long polling em PHP? Uma requisição longa com segredo

\n\n

Long polling é um truque elegante que simula uma conexão em tempo real usando requisições HTTP comuns. O cliente envia uma requisição ao servidor, mas o servidor não responde imediatamente. Ele mantém a conexão aberta até que um novo evento ocorra (por exemplo, uma nova mensagem no chat). Assim que o evento acontece, o servidor envia a resposta, o cliente a processa e imediatamente cria uma nova requisição "longa".

\n\n

Como funciona no PHP: exemplo simples

\n\n

Suponha que temos um chat simples. O cliente envia uma requisição AJAX para um script PHP que "fica" em loop até que uma nova mensagem apareça no banco de dados.

\n\n
<?php\n// long_polling.php\nheader('Content-Type: application/json');\nheader('Cache-Control: no-cache');\n\n$lastMessageId = $_GET['last_id'] ?? 0;\n$timeout = 30; // espera até 30 segundos\n$startTime = time();\n\nwhile (time() - $startTime < $timeout) {\n    // Simula uma consulta ao BD (na prática, uma query MySQL/PostgreSQL)\n    $newMessages = getNewMessagesFromDB($lastMessageId);\n    \n    if (!empty($newMessages)) {\n        echo json_encode([\n            'status' => 'success',\n            'messages' => $newMessages\n        ]);\n        exit;\n    }\n    \n    // Dorme 1 segundo para não sobrecarregar a CPU\n    sleep(1);\n}\n\n// Se nada chegou em 30 segundos\necho json_encode(['status' => 'timeout', 'messages' => []]);\nexit;\n?>
\n\n

No lado do cliente (JavaScript), fica assim:

\n\n
function startLongPolling(lastId) {\n    fetch('/long_polling.php?last_id=' + lastId)\n        .then(response => response.json())\n        .then(data => {\n            if (data.status === 'success') {\n                data.messages.forEach(msg => addMessageToChat(msg));\n                startLongPolling(data.messages[data.messages.length - 1].id);\n            } else {\n                startLongPolling(lastId); // timeout — apenas reinicia\n            }\n        })\n        .catch(() => setTimeout(() => startLongPolling(lastId), 1000));\n}\n
\n\n

Vantagens do Long polling em PHP

\n
    \n
  • Simplicidade de implementação — não requer servidores ou bibliotecas adicionais. Funciona em Apache/Nginx + PHP-FPM comuns.
  • \n
  • Compatibilidade — funciona em qualquer lugar com HTTP. Sem problemas com proxies ou firewalls corporativos.
  • \n
  • Baixa barreira de entrada — se você conhece PHP e AJAX, já consegue implementar Long polling.
  • \n
\n\n

Desvantagens do Long polling

\n
    \n
  • Carga no servidor — cada requisição "longa" mantém um processo PHP-FPM ocupado. Com 1000 usuários, você precisará de 1000 processos.
  • \n
  • Latência — a latência mínima é de 1 segundo (devido ao sleep). Se reduzir o sleep, a CPU começa a sofrer.
  • \n
  • Dificuldade de escalabilidade — Long polling não se dá bem com balanceadores de carga (é necessário prender o usuário a um servidor específico).
  • \n
\n\n

WebSocket em PHP: tempo real de verdade, sem concessões

\n\n

WebSocket é um canal de comunicação bidirecional completo sobre TCP. Após o handshake via HTTP, a conexão é atualizada para o protocolo WebSocket, permitindo que servidor e cliente enviem dados a qualquer momento, sem a sobrecarga de requisições HTTP repetidas.

Blogs

Book Recommendations