Você ainda atualiza a página manualmente? Hora de migrar para o tempo real
\n\nImagine: você abriu uma bolsa de valores online, e a cotação do dólar está congelada. Você aperta F5, aperta de novo — e ela não muda. Familiar? Agora imagine que a cotação se atualiza sozinha, como num filme — suavemente e sem atrasos. Isso não é mágica, são tecnologias em tempo real. São elas que transformam um site estático em um organismo vivo: chats, notificações, dashboards com atualização em tempo real.
\n\nHoje vamos analisar os quatro pilares que sustentam toda a web em tempo real: Long-Polling, WebSockets, Server-Sent Events (SSE) e Comet. Vou mostrar como funcionam "por baixo dos panos" e fornecer código pronto em PHP que você poderá usar agora mesmo. Vamos lá!
\n\nArtigo escrito para o portal educacional pythonlib.ru — aqui transformamos conceitos complexos em ferramentas compreensíveis.
\n\nResumindo: o que está por trás dos termos?
\n\nQuando você abre uma página comum, o navegador faz uma requisição, o servidor responde — a conexão é encerrada. Simples. Mas e se o servidor quiser "bater na sua porta" com novos dados? É aí que começam as complicações.
\n\n- \n
- Long-Polling (Polling longo) — o velho, mas confiável. O cliente "fica pendurado" no servidor e espera até que ele se digne a responder. \n
- WebSockets (WebSockets) — a tendência dos últimos anos. Um canal bidirecional completo, como uma linha telefônica. \n
- Server-Sent Events (SSE) — transmissão unidirecional do servidor para o cliente. Ideal para feeds de notícias e cotações. \n
- Comet — nome genérico para técnicas onde o servidor "empurra" dados para o cliente sem requisição adicional. Long-Polling e SSE são casos específicos de Comet. \n
Tecnologia nº1: Long-Polling — o avô do tempo real
\n\nLong-Polling é quando o cliente diz ao servidor: "Vou esperar o tempo que for preciso, só responda quando houver dados". O cliente abre uma conexão e a mantém aberta até o servidor enviar uma resposta. Após receber a resposta, o cliente imediatamente cria uma nova requisição. O resultado é uma corrente infinita.
\n\nVantagens: funciona em qualquer hospedagem, não requer bibliotecas adicionais, suportado por todos os navegadores.
\nDesvantagens: muitos cabeçalhos desnecessários, carga no servidor, atrasos com grande número de clientes.
\n\nExemplo em PHP (Long-Polling)
\n\n<?php\n// long_polling.php\nheader('Content-Type: text/plain; charset=utf-8');\nheader('Cache-Control: no-cache');\n\n$timeout = 30; // espera no máximo 30 segundos\n$start = time();\n\n// Simula o surgimento de novos dados\n$data = getNewDataFromDB(); // sua função para obter dados\n\nwhile (empty($data)) {\n if ((time() - $start) > $timeout) {\n echo json_encode(['status' => 'timeout', 'data' => null]);\n flush();\n exit;\n }\n usleep(500000); // dorme por 0.5 segundos\n $data = getNewDataFromDB();\n}\n\necho json_encode(['status' => 'ok', 'data' => $data]);\nflush();\n?>\n\nNo cliente (JavaScript) ficará assim:
\n\nfunction longPoll() {\n fetch('/long_polling.php')\n .then(response => response.json())\n .then(data => {\n if (data.status === 'ok') {\n console.log('Novos dados:', data.data);\n // atualiza a interface\n }\n longPoll(); // cria imediatamente uma nova requisição\n })\n .catch(error => {\n console.error('Erro:', error);\n setTimeout(longPoll, 1000); // reconecta após um segundo\n });\n}\nlongPoll();\n\nViu? O cliente fica pendurado, espera, recebe os dados — e se pendura novamente. Isso é Long-Polling em PHP em sua forma mais pura.
\n\nTecnologia nº2: WebSockets — a via de mão dupla
\n\nWebSockets