Accueil › Glossaire › Long Polling

Long Polling

Le long polling est une technique de communication HTTP dans laquelle le client envoie une requête au serveur, qui maintient la connexion ouverte jusqu’à ce qu’une donnée soit disponible ou qu’un délai d’expiration (timeout) soit atteint, permettant ainsi des mises à jour quasi temps réel sans recourir à un protocole spécialisé.

Comment fonctionne le long polling

Le long polling repose sur un détournement élégant du modèle requête-réponse HTTP. Plutôt que de répondre immédiatement (comme dans le short polling classique), le serveur garde la connexion ouverte et ne renvoie une réponse que lorsqu’il a effectivement quelque chose à transmettre. Voici le cycle complet :

1. Le client envoie une requête HTTP standard (généralement un GET). Cette requête contient souvent un identifiant de séquence (par exemple ?since=msg_999) pour indiquer au serveur les données déjà reçues.

2. Le serveur réceptionne la requête et vérifie ses données. Deux scénarios se présentent : si de nouvelles données existent, il répond immédiatement ; sinon, il maintient la connexion ouverte et attend.

3. Un timeout est configuré côté serveur (typiquement entre 20 et 60 secondes). Si aucune donnée n’arrive dans ce délai, le serveur renvoie une réponse vide pour éviter que la connexion ne soit coupée par un proxy intermédiaire ou par le navigateur lui-même.

4. Dès réception de la réponse (avec ou sans données), le client ouvre immédiatement une nouvelle requête. Le cycle recommence, créant une boucle quasi permanente de connexion entre le client et le serveur.

Ce mécanisme crée l’illusion d’un push serveur, alors qu’en réalité le client initie systématiquement chaque échange. C’est ce qui différencie fondamentalement le long polling des WebSockets, où la connexion est bidirectionnelle et persistante par nature.

Exemple d’implémentation côté client (JavaScript)

Voici un squelette minimaliste en JavaScript pur, tel qu’on le retrouve dans de nombreuses documentations de référence :

async function subscribe() {
  try {
    const response = await fetch('/api/updates?since=' + lastId);

    if (response.status === 502) {
      // Timeout de connexion, on relance immédiatement
      await subscribe();
    } else if (response.status !== 200) {
      // Erreur serveur, on attend 1 seconde avant de réessayer
      await new Promise(resolve => setTimeout(resolve, 1000));
      await subscribe();
    } else {
      const data = await response.json();
      handleNewData(data);
      lastId = data.lastId;
      await subscribe(); // Relance immédiate
    }
  } catch (err) {
    // Erreur réseau, on attend avant de réessayer
    await new Promise(resolve => setTimeout(resolve, 3000));
    await subscribe();
  }
}

subscribe();

Ce code illustre les trois cas à gérer impérativement : la réponse valide (on traite les données puis on relance), le timeout (HTTP 502, on relance sans délai), et l’erreur (on introduit un délai d’attente avant de réessayer pour éviter de bombarder le serveur).

Exemple côté serveur (Node.js / Express)

app.get('/api/updates', (req, res) => {
  const since = req.query.since;

  // Vérifier si de nouvelles données existent
  const newData = checkForUpdates(since);

  if (newData) {
    return res.json(newData);
  }

  // Pas de données : on attend avec un timeout de 30s
  const timeout = setTimeout(() => {
    res.json({ data: [], lastId: since });
  }, 30000);

  // Si de nouvelles données arrivent entre-temps
  dataEmitter.once('update', (data) => {
    clearTimeout(timeout);
    res.json(data);
  });
});

Le point crucial côté serveur est la gestion de la mémoire : chaque connexion en attente consomme des ressources. Un serveur threadé classique (comme Apache en mode prefork) atteindra rapidement ses limites. C’est pourquoi les implémentations de long polling fonctionnent bien mieux sur des serveurs événementiels comme Node.js, Go avec goroutines, ou des frameworks Python asynchrones (FastAPI, Tornado).

Short polling vs long polling : la différence clé

La confusion entre short polling et long polling est fréquente. Pourtant, la distinction est nette :

Pour illustrer concrètement : avec 100 000 utilisateurs connectés et un intervalle de polling de 5 secondes, le short polling génère environ 20 000 requêtes par seconde, dont la grande majorité retourne un corps vide. Le long polling ne génère du trafic que lorsqu’il y a effectivement de la donnée à transmettre, ce qui réduit drastiquement la charge réseau.

Long polling vs WebSocket vs SSE : comparatif complet

Le long polling n’est qu’une des trois approches principales pour la communication temps réel sur le web. Voici comment il se positionne face aux WebSockets et aux Server-Sent Events (SSE) :

Impact sur les performances à grande échelle

Les chiffres parlent d’eux-mêmes. Avec 1 million d’événements par jour, la différence d’overhead entre le long polling (~800 octets d’en-têtes HTTP par livraison) et les WebSockets (~2 à 6 octets par frame) représente environ 760 Mo de trafic économisé quotidiennement côté WebSocket.

Un cas réel documenté illustre bien cette réalité : un service SaaS de notifications avec 30 000 utilisateurs simultanés consommait 8 serveurs c5.2xlarge AWS (environ 6 000 $/mois) avec du long polling, pour un usage CPU de 60 à 80 %. Après migration vers SSE, la même charge était gérée par 3 serveurs (environ 2 200 $/mois) avec un CPU à 20-30 %. L’économie annuelle : environ 45 000 $.

Avantages du long polling

Malgré son âge, le long polling conserve des atouts réels dans certains contextes :

Compatibilité universelle. Le long polling fonctionne avec n’importe quel client HTTP, n’importe quel navigateur, n’importe quel proxy. Aucun protocole spécial n’est requis. C’est du HTTP standard de bout en bout, ce qui le rend compatible même avec les infrastructures les plus anciennes ou les plus restrictives.

Traverse les firewalls sans configuration. Contrairement aux WebSockets, qui nécessitent un upgrade de protocole que certains proxies d’entreprise ou firewalls refusent, le long polling passe partout. Pour les applications déployées dans des environnements réseau contraints (intranets d’entreprise, réseaux gouvernementaux), c’est un avantage décisif.

Simple à comprendre et à débugger. Chaque échange est une requête-réponse HTTP classique, inspectable dans n’importe quel outil de développement (Chrome DevTools, Fiddler, Wireshark). Pas de protocole binaire à décoder, pas de frames WebSocket à interpréter.

Implémentation côté client triviale. Quelques lignes de JavaScript suffisent (comme montré plus haut). Pas besoin de bibliothèque tierce.

Fallback fiable pour les protocoles modernes. Des bibliothèques comme Socket.IO négocient automatiquement le meilleur transport disponible : WebSocket si possible, long polling sinon. Avoir cette solution de repli garantit que votre application fonctionne même dans les pires conditions réseau.

Limites et inconvénients

Le long polling présente des limitations structurelles qui expliquent pourquoi il est progressivement remplacé :

Chaque client monopolise une connexion serveur. Un serveur qui gère 10 000 clients en long polling maintient 10 000 connexions HTTP ouvertes simultanément. Sur un serveur threadé, cela signifie 10 000 threads ou processus en attente, ce qui est intenable. Même sur des serveurs événementiels (Node.js, Go), la consommation mémoire et le coût de gestion des descripteurs de fichiers restent significatifs.

L’overhead HTTP est élevé. Chaque cycle requête-réponse transporte l’intégralité des en-têtes HTTP (cookies, user-agent, content-type, etc.), soit 150 à 200 octets minimum par échange. Pour des applications à haute fréquence de messages, ce surcoût devient prohibitif.

La gestion des timeouts est délicate. Les proxies intermédiaires, les load balancers et les CDN ont chacun leurs propres limites de timeout. Si un proxy coupe la connexion avant le timeout du serveur, le client ne reçoit pas la réponse attendue. Il faut aligner les timeouts à tous les niveaux de l’infrastructure, ce qui est une source fréquente de bugs en production.

Pas de garantie d’ordre des messages. Si un client a plusieurs onglets ouverts ou si la reconnexion chevauche une réponse en cours, il est possible de recevoir des messages en double ou dans le désordre. La RFC 6202 documente explicitement ce problème.

Les tempêtes de reconnexion (reconnect storms). Lorsqu’un serveur redémarre ou qu’un réseau bascule, tous les clients tentent de se reconnecter simultanément. Sans mécanisme de backoff exponentiel côté client, cette avalanche de requêtes peut écraser le serveur au redémarrage.

Scalabilité horizontale complexe. Répartir des connexions long polling entre plusieurs serveurs via un load balancer nécessite une gestion de session (sticky sessions ou état partagé). Si le client est redirigé vers un autre serveur entre deux requêtes, le contexte de sa session est perdu.

Quand utiliser le long polling

Le long polling reste pertinent dans des scénarios précis. Voici les cas où il constitue un choix raisonnable :

Comme mécanisme de fallback. Votre application utilise les WebSockets en priorité, mais certains de vos utilisateurs sont derrière des proxies d’entreprise qui bloquent l’upgrade WebSocket. Le long polling prend le relais automatiquement. C’est exactement l’approche de bibliothèques comme Socket.IO ou SignalR (ASP.NET).

Pour des mises à jour peu fréquentes. Si vos événements surviennent moins d’une fois par minute (notification de livraison, alerte système, mise à jour de statut), le long polling est plus économique en ressources qu’une connexion WebSocket permanente qui consomme de l’énergie pour maintenir son heartbeat.

Dans des environnements réseau très contraints. Certains réseaux d’entreprise, gouvernementaux ou industriels n’autorisent que le trafic HTTP/HTTPS standard sur les ports 80 et 443. Le long polling est alors la seule option temps réel disponible.

Sur des infrastructures legacy. Si votre backend est un serveur HTTP classique sans support WebSocket et que vous ne pouvez pas le migrer à court terme, le long polling vous offre du temps réel sans changement d’infrastructure.

Quand ne pas l’utiliser

Inversement, évitez le long polling si :

Vos messages arrivent à haute fréquence (plus d’un par seconde) : l’overhead HTTP devient un goulot d’étranglement. Vous avez besoin de communication bidirectionnelle (chat interactif, édition collaborative) : les WebSockets sont conçus pour cela. Vous visez une échelle massive (des dizaines de milliers de connexions simultanées) : le coût par connexion du long polling rend la scalabilité trop coûteuse. Vous démarrez un projet neuf sans contrainte legacy : SSE ou WebSockets offrent de meilleures performances dès le départ.

Bonnes pratiques d’implémentation

Côté client

Implémentez un backoff exponentiel. Après une erreur, attendez 1 seconde, puis 2, puis 4, puis 8, jusqu’à un maximum (par exemple 30 secondes). Cela évite les tempêtes de reconnexion.

let retryDelay = 1000;
const maxDelay = 30000;

async function subscribe() {
  try {
    const res = await fetch('/api/poll');
    retryDelay = 1000; // Réinitialiser après un succès
    // ... traiter la réponse
    subscribe();
  } catch (err) {
    await new Promise(r => setTimeout(r, retryDelay));
    retryDelay = Math.min(retryDelay * 2, maxDelay);
    subscribe();
  }
}

Envoyez un identifiant de séquence. Chaque requête doit indiquer au serveur le dernier message reçu (via un paramètre since, un timestamp ou un ID de séquence). Cela permet au serveur de ne renvoyer que les données nouvelles et de rattraper les messages manqués lors d’une déconnexion.

Limitez à une seule connexion long poll par onglet. Les navigateurs limitent le nombre de connexions HTTP simultanées vers un même domaine (6 pour la plupart). Si votre application ouvre un long poll par onglet, vous risquez de saturer cette limite et de bloquer les autres requêtes HTTP de votre page.

Côté serveur

Utilisez un runtime asynchrone. Node.js, Go, ou des frameworks Python asynchrones (FastAPI, Tornado) gèrent des milliers de connexions en attente sans bloquer de threads. Un serveur threadé comme Apache en mode prefork est fondamentalement inadapté au long polling.

Configurez un timeout cohérent avec votre infrastructure. Si votre load balancer (AWS ALB, Nginx, Cloudflare) coupe les connexions inactives après 60 secondes, configurez votre timeout de long polling à 50 secondes maximum. Gardez toujours une marge de sécurité.

Implémentez un rate limiting. Limitez le nombre de connexions long poll par client (par adresse IP ou par token d’authentification) pour vous protéger contre les abus et les attaques DDoS.

Gérez proprement la fermeture des connexions. Lorsqu’un client se déconnecte (événement close ou aborted en Node.js), libérez immédiatement les ressources associées (timers, listeners) pour éviter les fuites mémoire.

Le long polling dans l’écosystème moderne

Frameworks et bibliothèques

Plusieurs bibliothèques populaires intègrent le long polling comme transport de repli :

Socket.IO négocie automatiquement le meilleur transport disponible. Il commence par le long polling (pour une connexion rapide), puis bascule vers les WebSockets si le réseau le permet. Cette approche hybride garantit une compatibilité maximale.

SignalR (écosystème .NET) utilise la même stratégie : WebSocket en priorité, SSE ensuite, long polling en dernier recours.

Le protocole Bayeux (développé par la fondation Dojo en 2006-2007) a été l’un des premiers à formaliser l’utilisation du long polling pour la communication bidirectionnelle sur HTTP. Il est aujourd’hui principalement historique.

BOSH (Bidirectional-streams Over Synchronous HTTP), utilisé dans le monde XMPP, est une autre implémentation notable qui repose sur le long polling avec deux connexions TCP simultanées.

Contexte historique

Le long polling a été la première technique réellement fonctionnelle pour simuler du push serveur dans les navigateurs web. Avant la standardisation des WebSockets (RFC 6455 en 2011), le long polling et la technique apparentée de « Comet » étaient les seules options pour construire des applications web temps réel.

Le chat Facebook web a longtemps utilisé le long polling avant de migrer vers d’autres protocoles. Le terme « Comet » (inventé en 2006 par Alex Russell) désignait un ensemble de techniques, dont le long polling, pour pousser des données du serveur vers le client via HTTP. Ce terme est aujourd’hui considéré comme obsolète.

RFC 6202 : la référence officielle

Publiée en avril 2011, la RFC 6202 documente les problèmes connus et les bonnes pratiques pour l’utilisation du long polling et du streaming HTTP bidirectionnel. Elle couvre notamment la limite à deux connexions simultanées par domaine (héritée de HTTP/1.1), la gestion des proxies intermédiaires, et les stratégies de timeout. Si vous implémentez du long polling en production, cette RFC est une lecture indispensable.

Long polling et les outils IA temps réel

Dans le contexte de l’IA, le long polling apparaît dans certains cas spécifiques. Les API de modèles de langage qui génèrent des réponses longues utilisent parfois une variante du long polling pour vérifier la complétion d’une tâche asynchrone : le client soumet un prompt, reçoit un identifiant de tâche, puis interroge régulièrement le serveur pour savoir si la réponse est prête.

Cependant, la tendance dominante dans les API IA modernes est le streaming via SSE. L’API d’OpenAI, l’API d’Anthropic (Claude), et la plupart des fournisseurs d’inférence utilisent des Server-Sent Events pour transmettre les tokens au fur et à mesure de leur génération. Le long polling est trop grossier pour ce cas d’usage : il obligerait à attendre la fin complète de la génération avant de renvoyer le résultat, ce qui dégraderait l’expérience utilisateur.

Les outils de productivité IA comme Slack AI ou Notion AI s’appuient sur les WebSockets de leurs plateformes respectives pour diffuser les réponses en temps réel dans l’interface, pas sur du long polling.

Glossaire des termes associés

Verdict

Le long polling est une technique historiquement importante qui a permis l’essor des applications web temps réel avant l’arrivée des WebSockets. Il reste pertinent comme mécanisme de fallback dans les environnements réseau contraints et pour les cas d’usage à faible fréquence de messages.

Pour un projet neuf, la recommandation est claire : utilisez les SSE pour les flux unidirectionnels (notifications, dashboards, streaming de tokens IA) et les WebSockets pour les interactions bidirectionnelles (chat, collaboration). Ne démarrez un long polling qu’en dernier recours ou comme couche de compatibilité automatique via une bibliothèque comme Socket.IO.

En résumé : le long polling n’est pas mort, mais il n’est plus le premier choix. Considérez-le comme le diesel de la communication temps réel : fiable, universellement compatible, mais dépassé en performances par les alternatives modernes.