Passer au contenu 
HTTP Keep-Alive réduit les handshakes et maintient les connexions ouvertes afin que plusieurs requêtes puissent passer par le même socket et que la Charge du serveur diminue. Grâce à un réglage ciblé, je contrôle les délais d'attente, les limites et les travailleurs, je réduis Latence et augmentez le débit sans modifier le code.
Points centraux
- Réutilisation de la connexion réduit la charge CPU et les handshakes.
- Court Timeouts empêchent les connexions inactives.
- Propre Limites pour stabiliser la charge keepalive_requests.
- HTTP/2 et HTTP/3 encore plus étroitement.
- Réaliste tests de charge Enregistrer les paramètres.
Comment fonctionne HTTP Keep-Alive
Au lieu d'ouvrir une nouvelle connexion TCP pour chaque ressource, je réutilise une connexion existante et économise ainsi Poignées de main et les allers-retours. Cela réduit les temps d'attente, car ni les configurations TCP ni TLS ne doivent fonctionner en permanence et le pipeline répond rapidement. Le client reconnaît via l'en-tête que la connexion reste ouverte et envoie d'autres requêtes les unes après les autres ou avec multiplexage (avec HTTP/2/3) via le même prise. Le serveur gère la phase d'inactivité via un délai d'expiration Keep-Alive et met fin à la connexion si aucune requête n'est reçue pendant une période trop longue. Ce comportement accélère sensiblement les pages contenant de nombreux éléments et soulage le processeur, car il y a moins de connexions à établir.
Réutilisation des connexions : impact sur la charge du serveur
Chaque nouvelle connexion évitée permet d'économiser temps CPU pour le travail du noyau et TLS, ce que je constate dans la surveillance sous la forme d'une courbe de charge plus régulière. Les données montrent que la réutilisation des sockets existants peut augmenter le débit jusqu'à 50 % lorsque de nombreuses petites requêtes sont générées. Dans les benchmarks avec de nombreuses requêtes GET, la durée totale est parfois réduite de moitié, car il y a moins de handshakes et moins de changements de contexte. La charge réseau diminue également, car les paquets SYN/ACK sont moins fréquents et le serveur dispose de plus de ressources pour la logique d'application proprement dite. Cette interaction permet d'obtenir des réponses plus rapides et plus stables. Temps de réaction en charge.
Risques : délais d'attente trop longs et connexions ouvertes
Un délai d'expiration Keep-Alive trop généreux laisse les connexions inactives et bloque Travailleur ou des threads, même si aucune requête n'est en attente. En cas de trafic élevé, les sockets ouverts augmentent, atteignent les limites des descripteurs de fichiers et font grimper la consommation de mémoire. De plus, des délais d'attente client inappropriés génèrent des connexions „ mortes “ qui envoient des requêtes à des sockets déjà fermées et produisent des messages d'erreur. Les passerelles d'entrée et NAT peuvent fermer les lignes inactives avant le serveur, ce qui entraîne des réinitialisations sporadiques. C'est pourquoi je limite délibérément les temps d'inactivité, fixe des limites claires et maintiens la contrepartie (clients, proxys).
HTTP Keep-Alive vs TCP Keepalive
Je fais une distinction stricte entre HTTP Keep-Alive (connexions persistantes au niveau de l'application) et le mécanisme TCP „ keepalive “. HTTP Keep-Alive contrôle si d'autres requêtes HTTP passent par le même socket. TCP Keepalive, en revanche, envoie des paquets de test à intervalles réguliers afin de détecter les contreparties „ mortes “. Pour l'optimisation des performances, c'est principalement HTTP Keep-Alive qui compte. J'utilise TCP Keepalive de manière ciblée pour les longues phases d'inactivité (par exemple, pour les connexions périphériques ou dans les réseaux d'entreprise avec des pare-feu agressifs), mais je définis les intervalles de manière défensive afin d'éviter toute charge réseau inutile.
Cas particuliers : long polling, SSE et WebSockets
Les flux longue durée (événements envoyés par le serveur), le long polling ou les WebSockets entrent en conflit avec les délais d'inactivité courts. Je sépare ces points de terminaison des routes API ou Asset standard, je leur attribue des délais d'attente plus longs et des pools de travailleurs dédiés, et je limite les flux simultanés par IP. Ainsi, les flux longue durée ne bloquent pas les ressources pour les requêtes courtes classiques. Pour les SSE et les WebSockets, il vaut mieux définir des limites claires, des délais d'attente en lecture/écriture et un intervalle de heartbeat ou ping/pong précis plutôt que d'augmenter globalement tous les délais d'attente.
Paramètres Keep Alive centraux dans le serveur Web
J'active presque toujours Keep-Alive, je définis un délai d'inactivité court et je limite le nombre de requêtes par connexion afin de préserver les ressources. recycler. De plus, je régule les pools de travailleurs/threads afin que les connexions inactives n'occupent pas trop de processus. Le tableau suivant présente les directives, les objectifs et les valeurs de départ types que j'utilise régulièrement dans la pratique. Les valeurs varient en fonction de l'application et du profil de latence, mais elles constituent une base solide pour les premiers tests. Ensuite, je peaufine progressivement les délais d'attente, les limites et Fils de discussion à partir de données de mesure réelles.
| Serveur/composant | directive | Objectif | valeur initiale |
|---|---|---|---|
| Apache | KeepAlive | Activer les connexions persistantes | On |
| Apache | KeepAliveTimeout | Temps d'inactivité jusqu'à la fin de la connexion | 5 à 15 s |
| Apache | MaxKeepAliveRequests | Nombre maximal de requêtes par connexion | 100–500 |
| Nginx | keepalive_timeout | Temps d'inactivité jusqu'à la fin de la connexion | 5 à 15 s |
| Nginx | keepalive_requests | Nombre maximal de requêtes par connexion | 100 |
| HAProxy | option http-keep-alive | Autoriser les connexions persistantes | actif |
| Noyau/Système d'exploitation | somaxconn, tcp_max_syn_backlog | Files d'attente pour les connexions | adapté au trafic |
| Noyau/Système d'exploitation | Limites FD (ulimit -n) | Fichiers ouverts/sockets | >= 100k en cas de trafic élevé |
Apache : valeurs de démarrage, MPM et contrôle des workers
Pour les sites très parallèles, j'utilise le MPM dans Apache. événement, car il gère les connexions Idle-Keep-Alive plus efficacement que l'ancien prefork. En pratique, je choisis souvent 5 à 15 secondes pour KeepAliveTimeout afin que les clients puissent regrouper les ressources sans bloquer les travailleurs pendant longtemps. Avec MaxKeepAliveRequests 100-500, j'impose un recyclage modéré, ce qui prévient les fuites et lisse les pics de charge. Je réduis le délai d'expiration général à 120-150 secondes afin que les requêtes bloquées ne monopolisent pas les processus. Si vous souhaitez approfondir vos connaissances sur les threads et les processus, vous trouverez des informations importantes sur Paramètres du pool de threads pour différents serveurs web.
Nginx et HAProxy : modèles pratiques et anti-modèles
Avec les proxys inversés, j'observe souvent deux erreurs : soit Keep-Alive est désactivé globalement pour des „ raisons de sécurité “ (ce qui entraîne une charge de handshake massive), soit les délais d'inactivité sont élevés alors que le trafic est faible (ce qui mobilise des ressources). Je considère que les délais d'attente front-end sont plus courts que les délais d'attente back-end, afin que les proxys puissent rester ouverts même lorsque les clients ferment la connexion. De plus, je sépare les pools en amont par classes de service (actifs statiques vs API), car leur séquence de requêtes et leur temps d'inactivité dépendent du profil. Il est également essentiel de disposer d'un Longueur du contenu/Encodage de transfert-Manipulation : des indications de longueur erronées empêchent la réutilisation des connexions et provoquent „ connection: close “, ce qui entraîne des reconnexions inutiles.
Nginx et HAProxy : utiliser correctement les pools en amont
Avec Nginx, je gagne beaucoup de temps lorsque je maintiens des connexions en amont vers les backends et que j'utilise keepalive J'ajuste la taille des pools. Cela réduit les configurations TLS vers les serveurs d'applications et diminue considérablement la charge CPU à cet endroit. J'observe le nombre de sockets en amont ouverts, les taux de réutilisation et les distributions de latence dans les journaux afin d'augmenter ou de réduire la taille des pools de manière ciblée. Du côté du noyau, j'augmente les limites FD et j'ajuste somaxconn et tcp_max_syn_backlog afin que les files d'attente ne débordent pas. Ainsi, le proxy reste réactif même en cas de parallélisme élevé et répartit le trafic de manière uniforme sur les back-ends.
Optimisation TLS et QUIC pour réduire la surcharge
Pour que Keep-Alive puisse déployer pleinement ses effets, j'optimise la couche TLS : TLS 1.3 avec reprise (tickets de session) raccourcit les handshakes, OCSP-Stapling raccourcit les vérifications de certificats, une chaîne de certificats allégée réduit les octets et le CPU. Je n'utilise 0-RTT que pour les requêtes idempotentes et avec prudence afin d'éviter les risques de rejeu. Avec HTTP/3 (QUIC), c'est idle_timeout décisif : trop élevé, le stockage coûte cher, trop bas, les flux s'interrompent. Je teste également comment fenêtre de congestion initiale et les limites d'amplification agissent sur les connexions froides, en particulier sur de longues distances.
Utilisation ciblée de HTTP/2, HTTP/3 et du multiplexage
HTTP/2 et HTTP/3 regroupent plusieurs requêtes sur une seule connexion et éliminent Tête de ligne-Blocage au niveau de l'application. Cela profite encore davantage à Keep-Alive, car moins de connexions sont établies. Dans mes configurations, je veille à configurer les priorités et le contrôle de flux de manière à ce que les ressources critiques fonctionnent en premier. Je vérifie également si le regroupement des connexions est utile, par exemple lorsque plusieurs noms d'hôtes utilisent le même certificat. Un coup d'œil à HTTP/3 vs. HTTP/2 aide à choisir le protocole adapté aux profils d'utilisateurs mondiaux.
Clients et piles d'applications : configurer correctement le pooling
Le côté client et application détermine également la réutilisation : dans Node.js, j'active pour HTTP/HTTPS le keepAliveAgent avec un nombre limité de sockets par hôte. En Java, je définis des tailles de pool et des délais d'inactivité raisonnables pour HttpClient/OkHttp ; en Go, j'ajuste MaxIdleConns et MaxIdleConnsPerHost Les clients gRPC bénéficient de connexions longues, mais je définis des intervalles de ping et délais d'expiration keepalive de manière à ce que les proxys ne provoquent pas de flood. La cohérence est importante : des reconnexions client trop agressives compromettent toute optimisation du serveur.
Essais de charge et stratégie de mesure
Tourner à l'aveuglette lors des temps morts apporte rarement une stabilité Résultats, c'est pourquoi je procède à des mesures systématiques. Je simule des chemins d'utilisateurs typiques avec de nombreux petits fichiers, un degré de parallélisation réaliste et une latence répartie géographiquement. Pendant ce temps, j'enregistre les taux de réutilisation, la durée moyenne de connexion, les codes d'erreur et le rapport entre les sockets ouverts et le nombre de travailleurs. Je varie ensuite le KeepAliveTimeout par petits paliers et je compare les courbes des temps de réponse et de la consommation CPU. Ce n'est que lorsque les métriques restent stables sur plusieurs exécutions que je reprends les valeurs dans le Production.
Observabilité : quelles métriques comptent ?
Je surveille des indicateurs concrets : nouvelles connexions par seconde, rapport réutilisation/reconstruction, poignées de main TLS par seconde, sockets ouverts et leur temps de séjour, 95e/99e centile de latence, répartition des codes d'état (y compris 408/499), ainsi que les états du noyau tels que TIME_WAIT/FIN_WAIT2. Les pics de handshakes, l'augmentation des 499 et la croissance des buckets TIME_WAIT indiquent souvent des délais d'inactivité trop courts ou des pools trop petits. Une logique correctement instrumentée rend le réglage reproductible et empêche les optimisations de n'avoir qu'un effet placebo.
Synchronisation du délai d'attente entre le client et le serveur
Les clients doivent fermer les connexions inactives un peu plus tôt que le serveur afin d'éviter les „ morts “.“ Prises apparaissent. Dans les applications frontales, je définis donc des délais d'attente HTTP client plus courts que sur le serveur web et je documente ces spécifications. Il en va de même pour les équilibreurs de charge : leur délai d'attente inactif ne doit pas être inférieur à celui du serveur. Je surveille également les valeurs d'inactivité NAT et pare-feu afin que les connexions ne disparaissent pas dans le chemin réseau. Cette interaction fluide empêche les réinitialisations sporadiques et stabilise Retransmissions.
Résilience et sécurité sous charge
Les connexions persistantes ne doivent pas être une invitation pour Slowloris & Co. Je définis des délais d'attente courts pour la lecture des en-têtes/corps, je limite la taille des en-têtes, je limite les connexions simultanées par IP et je veille à la contre-pression dans les flux ascendants. En cas d'erreurs de protocole, je ferme systématiquement les connexions (au lieu de les laisser ouvertes) et empêche ainsi le Request Smuggling. De plus, je définis des grâce-Temps lors de la fermeture, afin que le serveur termine proprement les réponses ouvertes sans laisser les connexions indéfiniment dans persistant-conditions.
Facteurs d'hébergement et architecture
Des processeurs puissants, des cartes réseau rapides et suffisamment de mémoire vive RAM accélèrent les poignées de main, les changements de contexte et le cryptage, ce qui permet d'exploiter pleinement le réglage Keep-Alive. Un proxy inverse devant l'application simplifie le déchargement, centralise les délais d'expiration et augmente le taux de réutilisation vers les backends. Pour plus de contrôle sur TLS, la mise en cache et le routage, je mise sur une approche claire. Architecture proxy inverse. Il reste important de supprimer rapidement les limites telles que ulimit -n et accept-Queues afin que l'infrastructure puisse supporter un parallélisme élevé. Grâce à une observabilité claire, je détecte plus rapidement les goulots d'étranglement et je peux Limites Serrer correctement.
Déploiements, drainage et subtilités du système d'exploitation
Lors des déploiements progressifs, je laisse les connexions Keep-Alive s'éteindre de manière contrôlée : je n'accepte plus de nouvelles requêtes, mais celles qui existent peuvent être brièvement servies (drain). Cela me permet d'éviter les interruptions de connexion et les pics 5xx. Au niveau du système d'exploitation, je garde un œil sur la plage de ports éphémères, somaxconn, SYN-Backlog et tcp_fin_timeout, sans utiliser d'astuces obsolètes telles que la réutilisation agressive de TIME_WAIT. SO_REUSEPORT Je répartis la charge sur plusieurs processus de travail afin de réduire la concurrence Accept. L'objectif est toujours le même : traiter de manière stable un grand nombre de connexions de courte durée sans engorger les files d'attente du noyau.
Résumé : le tuning comme levier de performance
L'utilisation systématique de HTTP Keep-Alive réduit le nombre de connexions établies et diminue la charge du serveur. Charge CPU et des réponses nettement plus rapides. Des délais d'inactivité courts, des limites claires par connexion et des travailleurs suffisamment dimensionnés permettent de maîtriser les sockets inactifs. Grâce à HTTP/2/3, aux pools en amont et aux limites OS coordonnées, je peux faire évoluer le parallélisme sans perdre en stabilité. Des tests de charge réalistes montrent si les réglages sont vraiment efficaces et où se trouvent les prochains points de pourcentage. En combinant ces éléments, vous augmentez le débit, maintenez les latences à un faible niveau et utilisez les ressources existantes. Ressources au maximum.
