Un chat support déployé en Node.js fonctionne parfaitement en staging : vingt testeurs, latence instantanée. En production sur le même VPS, 300 agents connectés — le serveur atteint « too many open files », nginx renvoie 502, et les connexions tombent toutes les 60 secondes parce que personne n'a relevé le proxy_read_timeout par défaut.
WebSocket n'est pas du HTTP un peu plus long. C'est un modèle de ressources différent : connexions persistantes, mémoire par client, heartbeats, et souvent diffusion qui amplifie chaque message. Héberger du temps réel sans plan, c'est convertir un succès produit en incident infrastructure prévisible.
WebSocket versus HTTP : ce que consomme vraiment une connexion
| Ressource | Requête HTTP courte | WebSocket ouverte |
|---|---|---|
| Descripteurs de fichiers | 1 puis libéré | 1 maintenu des heures |
| Mémoire serveur app | Pool worker recyclé | Tampon + état session |
| Processeur | Pic à la requête | Heartbeat + messages continus |
| Proxy | Sans état, facile | Upgrade + timeout à configurer |
| Montée en charge | Horizontal simple | Affinité ou pub/sub obligatoire |
Règle empirique : estimez 50 Ko à 200 Ko de mémoire par connexion selon la pile (Node, Go, Elixir varient). 5 000 connexions × 100 Ko ≈ 500 Mo — avant le code métier.
Le chiffre qui tue en premier n'est pas le processeur — c'est
ulimit -net le timeout du proxy.
Reverse proxy : nginx devant l'application temps réel
Configuration minimale nginx :
location /ws/ {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
}
Points souvent oubliés : la limite globale worker_connections nginx versus connexions WebSocket ; la termination TLS au proxy — certains hébergeurs limitent les connexions SSL simultanées ; HTTP/2 côté client public, HTTP/1.1 Upgrade vers l'amont.
Voir aussi WebSocket timeout proxy et Nginx ou Apache.
Scaling horizontal : affinité versus broker
Option A — Sessions persistantes (sticky). Le répartiteur de charge route le client vers le même nœud. Simple, fragile si le nœud tombe (reconnexion massive).
Option B — Redis pub/sub ou adaptateur Socket.IO. Messages routés entre nœuds ; connexions réparties. Requis dès deux instances ou plus.
Option C — Service managé (Pusher, Ably, hub Mercure managé). Externalise la complexité ; coût par message.
Pour un MVP sérieux, l'option B sur deux petits VPS bat un gros serveur unique sans pub/sub.
Hébergement : questions à poser au fournisseur
Avant de choisir, demandez si les connexions longues sont autorisées (le mutualisé coupe souvent), quelle est la limite de descripteurs de fichiers, si UDP ou QUIC sont filtrés pour WebTransport, si le répartiteur de charge couche 7 supporte l'Upgrade WebSocket, et si l'anti-DDoS peut bloquer des connexions lentes à tort.
Cloud VPS (Hetzner, OVH, Scaleway) avec nginx reste le combo le plus prévisible pour WebSocket auto-hébergé.
Heartbeats, reconnexion et observabilité
Envoyez un ping/pong applicatif toutes les 30 secondes pour détecter les connexions mortes. Appliquez un backoff exponentiel côté client pour éviter la ruée vers le serveur au redémarrage. Mesurez connexions actives, messages par seconde, latence de diffusion au 99e centile. Prévoyez un arrêt gracieux : signal d'arrêt, stop accept, drain 30 secondes.
Le sommet : le temps réel scale en connexions, pas en pages vues
Vendre du « chat en direct » sans chiffre de connexions max, timeout proxy et plan pub/sub, c'est vendre une fonctionnalité qui ne survit pas au premier succès.
Décider et avancer sans angle mort
Calculez d'abord connexions max × mémoire et vérifiez ulimit. Configurez les timeouts nginx avant le lancement. Testez la reconnexion après déploiement — pas seulement le parcours nominal. Prévoyez Redis pub/sub avant le second serveur. Mettez en place un tableau de bord des connexions actives avec alerte à 80 % du seuil.
Explorez VPS et cloud dans l'annuaire et le comparateur.
Questions fréquentes
Combien de connexions WebSocket un serveur peut-il tenir ?
Cela dépend de la mémoire par connexion, des descripteurs de fichiers et de nginx. Des milliers de connexions inactives sont possibles ; beaucoup moins si chaque message déclenche du travail lourd.
Faut-il du sticky session derrière un load balancer ?
Oui si l'état vit en mémoire processus. Sinon, utilisez Redis pub/sub ou un hub dédié pour partager l'état entre nœuds.
Le mutualisé supporte-t-il WebSocket ?
Souvent partiellement ou avec timeouts courts (30 à 60 secondes). Vérifiez la documentation de l'hébergeur — certains panels coupent les connexions longues.
Nginx ou Apache devant Node.js WebSocket ?
Nginx est plus courant avec en-têtes Upgrade et proxy_read_timeout adapté (souvent 3600 secondes ou plus). Apache mod_proxy_wstunnel fonctionne mais est moins répandu en production temps réel.
Le temps réel se dimensionne en connexions ouvertes — pas en visiteurs uniques du mois dernier.