Long Polling contre WebSocket en Rust : la bataille du temps réel

Introduction : Pourquoi Rust est-il le candidat idéal pour le temps réel ?

Imaginez la situation : vous écrivez un serveur de chat, un terminal boursier ou un système de surveillance en Rust. Les utilisateurs veulent recevoir les mises à jour instantanément. Personne n'aime cliquer sur le bouton « Actualiser » manuellement – c'est dépassé. Mais comment organiser la livraison des données du serveur au client ?

Pendant longtemps, la seule méthode était le long polling – une astuce élégante mais un peu « bancale ». Ensuite sont arrivés les WebSocket et ont bouleversé le monde du développement web. Et maintenant nous avons Rust – un langage qui permet d'extraire le maximum des deux approches, sans sacrifier la sécurité mémoire.

Dans cet article, nous ne comparerons pas simplement le long polling et WebSocket en Rust – nous écrirons des exemples fonctionnels, les lancerons et verrons ce qui se passe sous le capot. Si vous écrivez une application temps réel en Rust et hésitez sur le choix de la technologie – vous êtes au bon endroit.

Qu'est-ce que le Long Polling expliqué simplement

Le long polling est une technique où le client ouvre une requête HTTP vers le serveur et… attend. Le serveur ne répond pas immédiatement, mais maintient la connexion ouverte jusqu'à ce qu'un nouvel événement se produise ou qu'un délai d'attente expire.

Imaginez que vous appelez un ami et dites : « Appelle-moi quand le colis arrive » – et vous restez en ligne pendant une heure. C'est le long polling. Le polling normal, c'est quand vous rappelez toutes les 5 minutes : « Alors, il est arrivé ? »

Implémentation du Long Polling en Rust avec Actix-web

Écrivons un serveur très simple avec actix-web qui utilise le long polling. Nous aurons une file d'attente de messages – lorsqu'un nouveau message apparaît, tous les « attenteurs » le reçoivent.

use actix_web::{web, App, HttpServer, HttpRequest, HttpResponse};\nuse std::sync::Mutex;\nuse tokio::sync::broadcast;\n\nstruct AppState {\n    tx: broadcast::Sender<String>,\n}\n\nasync fn long_poll_handler(data: web::Data<Mutex<AppState>>) -> HttpResponse {\n    let mut rx = {\n        let state = data.lock().unwrap();\n        state.tx.subscribe()\n    };\n\n    // Attend un nouveau message pendant 30 secondes\n    match tokio::time::timeout(\n        std::time::Duration::from_secs(30),\n        rx.recv()\n    ).await {\n        Ok(Ok(msg)) => HttpResponse::Ok().body(msg),\n        Ok(Err(_)) => HttpResponse::InternalServerError().finish(),\n        Err(_) => HttpResponse::NoContent().finish(), // timeout\n    }\n}\n\n#[actix_web::main]\nasync fn main() -> std::io::Result<()> {\n    let (tx, _) = broadcast::channel::<String>(100);\n\n    HttpServer::new(move || {\n        App::new()\n            .app_data(web::Data::new(Mutex::new(AppState { tx: tx.clone() })))\n            .route("/poll", web::get().to(long_poll_handler))\n    })\n    .bind("127.0.0.1:8080")?\n    .run()\n    .await\n}

Le client restera simplement connecté sur GET /poll. Lorsqu'un message arrive – le serveur répond. Si rien ne se passe pendant 30 secondes – il renvoie 204 No Content, et le client refait la demande.

Avantages :

\n
• Fonctionne via HTTP standard – pas besoin de serveurs proxy supportant WebSocket
\n
• Simplicité d'intégration avec les API REST existantes
\n
• Idéal pour les réseaux d'entreprise où les proxys bloquent WebSocket
\n

Inconvénients :

\n
• Chaque « polling » maintient une connexion – avec 10 000 clients, cela fait 10 000 connexions TCP ouvertes
\n
• Latence : le client se reconnecte quand même après le délai d'attente
\n
• Le serveur consomme des ressources pour maintenir les requêtes « en attente »
\n

WebSocket en Rust : quand on veut de la vitesse

WebSocket n'est plus un « appel et attente », mais un véritable canal bidirectionnel. Le serveur et le client peuvent échanger des messages à tout moment, sans le surcoût des en-têtes HTTP.

Dans l'écosystème Rust, WebSocket est riche : tokio-tungstenite pour le travail de bas niveau, actix-web avec son support intégré, et bien d'autres. Avec Rust, vous obtenez à la fois la sécurité et la performance – un vrai atout pour les applications temps réel.