Long Polling : qu'est-ce que c'est, comment ça fonctionne et où s'utilise

Qu'est-ce que le Long Polling

Long Polling est un modèle de communication dans une architecture client-serveur où un client initie une requête HTTP et le serveur retarde l'envoi d'une réponse jusqu'à ce que de nouvelles données soient disponibles ou qu'un délai d'attente spécifié expire. Après avoir reçu la réponse, le client envoie immédiatement la requête suivante, créant l'effet d'une connexion continue.

La technique Long Polling est apparue comme un développement évolutif du Short Polling pour réduire le nombre de requêtes HTTP vides. Dans le sondage traditionnel, le client envoie des requêtes toutes les N secondes et le serveur répond même lorsqu'il n'y a pas de nouvelles données. Dans Long Polling, le serveur utilise un mécanisme de maintien de connexion, ce qui réduit considérablement le trafic inutile.

Histoire du Long Polling

Avant l'avènement de WebSocket en 2011, le Long Polling était la principale méthode de communication en temps réel sur le web. Des entreprises comme Facebook et Gmail ont utilisé cette technique pour leurs chats et notifications au début des années 2010. Selon High Performance Browser Networking (Grigorik, 2013), le Long Polling traitait jusqu'à 95 % de toutes les connexions en temps réel dans les principales applications web de cette période.

Principe de base du Long Polling

Un client envoie une requête HTTP standard au serveur. En recevant la requête, le serveur ne renvoie pas immédiatement une réponse — il place la requête dans une file d'attente. Lorsqu'un événement se produit sur le serveur (un nouveau message, un changement de données), le serveur forme une réponse et l'envoie au client. Après avoir reçu la réponse, le client crée immédiatement une nouvelle requête Long Polling et le cycle se répète.

Comment fonctionne le Long Polling

Long Polling fonctionne selon la séquence d'étapes suivante. Le client envoie une requête HTTP GET à un endpoint du serveur. En recevant la requête, le serveur vérifie la présence de nouvelles données dans la file d'événements. S'il n'y a pas de données, le serveur maintient la requête dans un état d'attente, sans envoyer de réponse immédiatement. Le mécanisme de maintien dépend de l'implémentation du serveur — le plus souvent, un traitement asynchrone avec callbacks ou une architecture orientée événements est utilisé.

Lorsqu'un événement se produit côté serveur (par exemple, un utilisateur a envoyé un message dans un chat), le serveur forme une réponse HTTP avec un corps contenant ces données et termine la connexion. Le client reçoit la réponse, traite les données et initie immédiatement une nouvelle requête. Si aucune donnée n'apparaît pendant la période d'attente, le serveur envoie une réponse vide après l'expiration du délai d'attente, et le client rétablit également la connexion. Le délai d'attente est généralement de 30 à 60 secondes pour équilibrer la charge et la latence.

Délais d'attente et gestion de connexion

Un paramètre de configuration clé pour Long Polling est le délai d'attente. Un délai d'attente trop court (moins de 10 secondes) augmente le nombre de requêtes, rapprochant la technique du Short Polling. Un délai d'attente trop long (plus de 120 secondes) peut provoquer des ruptures de connexion par les proxies intermédiaires et les équilibreurs de charge. La valeur recommandée pour la plupart des scénarios est de 30 à 45 secondes.

Traitement des événements multiples

Si plusieurs événements se produisent sur le serveur pendant une seule requête Long Polling, le serveur doit les transmettre tous dans une seule réponse ou organiser une file d'événements côté client. Pour cela, la mise en tampon des événements est utilisée : le serveur accumule les événements survenus pendant le temps de maintien de la requête et les transmet sous forme de tableau de données dans le corps de la réponse.

Exemple d'implémentation de Long Polling en JavaScript

Regardons une implémentation simple de Long Polling côté client en utilisant la Fetch API moderne. La fonction client envoie une requête et s'appelle récursivement après avoir reçu une réponse.

async function longPoll(url) {
    try {
        const response = await fetch(url);
        const data = await response.json();

        handleData(data);
        longPoll(url);
    } catch (error) {
        console.error("Erreur de Long Polling", error);
        setTimeout(() => longPoll(url), 3000);
    }
}

function handleData(data) {
    if (data.events && data.events.length > 0) {
        data.events.forEach(event => {
            console.log("Nouvel événement :", event);
        });
    }
}

longPoll("/api/events");

Ce code crée une boucle infinie de Long Polling : après avoir reçu une réponse, la fonction envoie immédiatement une nouvelle requête. En cas d'erreur de connexion, un délai de trois secondes est défini avant la nouvelle tentative pour éviter une charge avalanche sur le serveur.

Implémentation serveur sur Node.js

Côté serveur, il est nécessaire de maintenir la requête jusqu'à ce qu'un événement se produise ou qu'un délai d'attente expire. Un exemple d'implémentation utilisant EventEmitter dans Node.js démontre ce mécanisme.

const express = require("express");
const EventEmitter = require("events");
const app = express();

const eventBus = new EventEmitter();

app.get("/api/events", (req, res) => {
    const timeout = setTimeout(() => {
        res.json({ events: [] });
    }, 30000);

    eventBus.once("new-event", (data) => {
        clearTimeout(timeout);
        res.json({ events: [data] });
    });
});

app.post("/api/events", (req, res) => {
    eventBus.emit("new-event", req.body);
    res.send({ status: "ok" });
});

app.listen(3000);

La partie serveur utilise EventEmitter pour notifier les connexions Long Polling en attente lorsque de nouvelles données apparaissent. En atteignant le délai d'attente de 30 secondes, le serveur renvoie un tableau vide d'événements et le client crée une nouvelle requête.

Quand utiliser le Long Polling

Long Polling est utilisé dans les scénarios où la livraison de données en temps réel est nécessaire mais l'utilisation de WebSocket est impossible pour des raisons techniques ou d'infrastructure. Les cas les plus courants sont les proxies d'entreprise et les pare-feu qui bloquent les connexions WebSocket, ainsi que les environnements avec un support de protocole limité côté serveur.

• Chats et messageries — Long Polling assure la livraison des messages dans les versions web des messageries fonctionnant via HTTP sans WebSocket.
• Tableaux de bord — systèmes en temps réel pour les métriques DevOps, les journaux et les alertes où l'actualité des données avec un délai de 1 à 5 secondes est importante.
• Notifications — livraison de type push d'alertes dans le navigateur sans utiliser Service Workers et Push API.
• Fils d'activité — réseaux sociaux et fils d'actualité avec mise à jour automatique du contenu lors de l'apparition de nouvelles publications.
• Collaboration — éditeurs de type Google Docs avec synchronisation de base des modifications entre utilisateurs.

Le facteur clé du choix du Long Polling est la compatibilité ascendante. Tous les clients et serveurs HTTP prennent en charge cette méthode, ce qui en fait une solution universelle pour les fonctionnalités en temps réel sans dépendances supplémentaires. Selon HTTP Archive (2024), environ 8 % de tous les sites web continuent d'utiliser Long Polling pour les fonctionnalités de base en temps réel.

Long Polling vs Short Polling

Long Polling et Short Polling résolvent le même problème — la livraison de données du serveur au client — mais diffèrent fondamentalement par leur mécanisme et leur efficacité. Short Polling utilise un intervalle de sondage fixe où le client envoie des requêtes HTTP à intervalles réguliers, indépendamment de l'apparition de nouvelles données sur le serveur.

Short Polling est plus simple à implémenter mais crée une charge significativement plus élevée sur le serveur et le réseau pour une même fréquence de mise à jour des données. Si une latence inférieure à 5 secondes est requise, Short Polling génère des dizaines de requêtes par minute, tandis que Long Polling utilise une requête par événement ou délai d'attente. Pour les applications à événements rares, Long Polling est infiniment plus efficace en termes de trafic.

Long Polling vs WebSocket

WebSocket est un protocole bidirectionnel complet en temps réel fonctionnant sur TCP après une poignée de main HTTP initiale. Contrairement à Long Polling, WebSocket établit une seule connexion persistante et permet au serveur d'envoyer des données au client à tout moment sans créer une nouvelle requête HTTP.

Le choix entre Long Polling et WebSocket dépend de plusieurs facteurs. Compatibilité : Long Polling fonctionne via n'importe quel proxy et pare-feu, tandis que WebSocket peut être bloqué par les réseaux d'entreprise. Performances : WebSocket a une surcharge moindre (2 octets par frame contre des en-têtes HTTP complets), ce qui est critique à haute fréquence de messages. Évolutivité : Long Polling nécessite plus de ressources côté serveur en raison du maintien de nombreuses connexions, tandis que WebSocket utilise une connexion fixe par session.

• Long Polling — le meilleur choix pour les applications à faible fréquence d'événements (1–10 événements par minute), à infrastructure limitée ou nécessitant la prise en charge de navigateurs anciens.
• WebSocket — la solution optimale pour les applications en temps réel à forte charge (données boursières, jeux en ligne, éditeurs collaboratifs) avec des centaines de messages par seconde.
• Approche hybride — certaines applications utilisent Long Polling comme solution de repli pour les clients qui ne prennent pas en charge WebSocket, avec commutation automatique de protocole.

Selon Mozilla Developer Network (2024), WebSocket est pris en charge par tous les navigateurs modernes depuis les versions 2011–2015, mais les proxies d'entreprise (par exemple, Symantec Blue Coat) continuent de le bloquer dans 15 à 20 % des réseaux d'entreprise, ce qui maintient la pertinence de Long Polling comme solution de repli.