Long polling vs WebSocket en PHP : que choisir pour un projet en temps réel

Introduction : pourquoi votre site « rame » en temps réel ?

Imaginez que vous êtes sur un site boursier et que le taux de change du dollar ne se met à jour qu'après un rechargement de la page. Ou vous avez envoyé un message dans un chat, et votre interlocuteur ne l'a vu que 10 secondes plus tard. Ça vous parle ? C'est la douleur de tout développeur qui tente de rendre une application « vivante ».

Dans le monde du PHP, où chaque requête vit sa courte vie, implémenter des fonctionnalités en temps réel est une tâche ardue. Les deux principales approches qui viennent à la rescousse sont le Long polling et le WebSocket. Lequel choisir pour votre projet PHP ? Décortiquons cela sans blabla, avec des exemples de code concrets.

Qu'est-ce que le Long polling en PHP ? Une requête longue avec un secret

Long polling est une astuce élégante qui permet d'imiter une connexion en temps réel en utilisant des requêtes HTTP classiques. Le client envoie une requête au serveur, mais le serveur ne répond pas immédiatement. Il maintient la connexion ouverte jusqu'à ce qu'un nouvel événement se produise (par exemple, un nouveau message dans le chat). Dès que l'événement se produit, le serveur envoie la réponse, le client la traite et crée immédiatement une nouvelle requête « longue ».

Comment ça fonctionne en PHP : un exemple simple

Supposons que nous ayons un chat simple. Le client envoie une requête AJAX à un script PHP qui « reste en attente » dans une boucle jusqu'à ce qu'un nouveau message apparaisse dans la base de données.

<?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; // on attend jusqu'à 30 secondes\n$startTime = time();\n\nwhile (time() - $startTime < $timeout) {\n    // On simule une vérification de la BDD (en réalité, une requête 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    // On dort 1 seconde pour ne pas surcharger le CPU\n    sleep(1);\n}\n\n// Si rien n'est arrivé après 30 secondes\necho json_encode(['status' => 'timeout', 'messages' => []]);\nexit;\n?>

Côté client (JavaScript), cela ressemble à ceci :

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 — on redémarre simplement\n            }\n        })\n        .catch(() => setTimeout(() => startLongPolling(lastId), 1000));\n}\n

Avantages du Long polling en PHP

\n
• Simplicité d'implémentation — pas besoin de serveurs ou de bibliothèques supplémentaires. Tout fonctionne sur un Apache/Nginx + PHP-FPM classique.
\n
• Compatibilité — fonctionne partout où il y a HTTP. Aucun problème avec les proxys ou les pare-feux d'entreprise.
\n
• Faible barrière à l'entrée — si vous connaissez PHP et AJAX, vous pouvez déjà faire du Long polling.
\n

Inconvénients du Long polling

\n
• Charge sur le serveur — chaque requête « longue » maintient un processus PHP-FPM occupé. Avec 1000 utilisateurs, vous aurez besoin de 1000 processus.
\n
• Latence — la latence minimale est de 1 seconde (à cause du sleep). Si vous réduisez le sleep, le CPU va chauffer.
\n
• Difficulté de passage à l'échelle — le Long polling s'entend mal avec les répartiteurs de charge (il faut attacher l'utilisateur à un serveur spécifique).
\n

WebSocket en PHP : un vrai temps réel sans compromis

WebSocket est un canal de communication bidirectionnel complet au-dessus de TCP. Après une poignée de main (handshake) via HTTP,