Long Polling vs WebSocket en JavaScript : une bataille épique pour le temps réel
\n\nIl était une fois, à une époque où Internet était lent et les navigateurs naïfs, le seul moyen de savoir si de nouvelles données étaient apparues sur le serveur était d'appuyer sur F5. Puis AJAX est arrivé, et nous avons appris à interroger le serveur manuellement. Mais que faire si les données doivent arriver d'elles-mêmes, sans notre intervention ? Bienvenue dans le monde des communications en temps réel.
\n\nDans cet article, nous allons décortiquer les deux principales approches qui divisent encore la communauté des développeurs : le bon vieux Long Polling et le moderne et audacieux WebSocket. Nous écrirons du code en JavaScript, examinerons leur fonctionnement interne et comprendrons quel outil choisir pour votre prochain projet. Si vous voulez comprendre une fois pour toutes le long polling vs websocket, vous êtes au bon endroit.
\n\nLe problème : comment faire parler le serveur en premier ?
\n\nHTTP est un protocole unidirectionnel. Le client (navigateur) envoie une requête, le serveur répond – et voilà, le repas est terminé. Mais dans le monde réel (chats, cotations boursières, notifications), les données doivent circuler dans l'autre sens. Pendant longtemps, les développeurs ont dû ruser. Voici les deux principales façons de résoudre ce problème.
\n\nLong Polling : une astuce avec le temps
\n\nImaginez que vous appelez le service client et que vous dites : « Je vais attendre en ligne jusqu'à ce qu'un opérateur se libère ». Vous ne raccrochez pas. C'est exactement ainsi que fonctionne le Long Polling (également appelé « sondage long »).
\n\nComment ça marche :
\n- \n
- Le client envoie une requête HTTP standard. \n
- Le serveur ne répond pas immédiatement s'il n'y a pas de données. Il « reste en attente » et attend. \n
- Dès que des données apparaissent – le serveur envoie une réponse. \n
- Le client traite la réponse et ouvre immédiatement une nouvelle connexion. \n
Code côté client (JavaScript) :
\nfunction longPoll() {\n fetch('/updates')\n .then(response => response.json())\n .then(data => {\n console.log('Nouvelles données :', data);\n // On commence immédiatement un nouveau sondage\n longPoll();\n })\n .catch(error => {\n console.error('Erreur, reconnexion dans 2 secondes :', error);\n setTimeout(longPoll, 2000);\n });\n}\n\n// On lance\nlongPoll();\n\nAvantages :
\n- \n
- Fonctionne sur n'importe quel serveur et n'importe quel navigateur (même sur IE6). \n
- Ne nécessite pas de protocoles spéciaux – HTTP pur. \n
- Passe à travers tous les proxys et pare-feux d'entreprise. \n
Inconvénients :
\n- \n
- Chaque message est une nouvelle requête HTTP (en-têtes, cookies, frais généraux). \n
- Le serveur maintient de nombreuses connexions ouvertes (problème C10k – 10 000 clients). \n
- La latence est plus élevée qu'avec WebSocket. \n
WebSocket : un canal de communication permanent
\n\nWebSocket est comme une ligne ouverte entre un vaisseau spatial et un centre de contrôle. Vous établissez la connexion une fois, et ensuite les deux parties peuvent envoyer des données à tout moment, sans cérémonie superflue.
\n\nComment ça marche :
\n- \n
- Le client initie une poignée de main (handshake) via HTTP. \n
- Le serveur change de protocole vers ws:// ou wss://. \n
- Une connexion bidirectionnelle permanente est établie. \n
- Les données sont transmises par trames – légères et rapides. \n
Code côté client (JavaScript) :
\nconst socket = new WebSocket('wss://example.com/chat');\n\n// Quand la connexion est ouverte\nsocket.onopen = function() {\n console.log('Connexion établie');\n socket.send(JSON.stringify({ type: 'greeting', text: 'Bonjour, serveur !' }));\n};\n\n// Quand un message arrive\nsocket.onmessage = function(event) {\n const data = JSON.parse(event.data);\n console.log('Message du serveur :', data);\n};\n\n// En cas d'erreur\nsocket.onerror = function(error) {\n console.error('Erreur WebSocket :', error);\n};\n\n// À la fermeture\nsocket.onclose = function(event) {\n console.log('Connexion fermée. Code :', even