Le keep-alive HTTP et la réutilisation de connexion : pools, délais d'inactivité et la course à la connexion périmée

Ce que c'est

La RFC 9112 indique que HTTP/1.1 utilise par défaut des connexions persistantes, portant plusieurs requêtes et réponses sur une seule connexion. Une connexion reste ouverte à moins qu'un message ne porte l'option de connexion close ou que le pair parle HTTP/1.0 sans keep-alive ; un client ou un serveur qui ne prend pas en charge la persistance doit envoyer close sur chaque message. Pour rester persistant, chaque message a besoin d'une longueur auto-définie (Content-Length ou encodage par blocs). Les serveurs ferment généralement les connexions inactives après un délai dont la longueur n'est pas contrainte par la spécification, les connexions peuvent se fermer à tout moment, et les clients devraient limiter le nombre de connexions simultanées vers un même serveur. MDN décrit les mêmes modèles et note que le pipelining, bien que défini, n'est pas activé par défaut dans les navigateurs modernes.

Pourquoi c'est important

Chaque nouvelle connexion coûte une poignée de main TCP et, avec TLS, une poignée de main cryptographique en plus, ainsi qu'un socket en TIME_WAIT ensuite. Un client qui effectue de nombreuses petites requêtes vers un même hôte peut passer plus de temps à établir des connexions qu'à transférer des données, et un serveur peut consommer plus de CPU en poignées de main TLS qu'en traitement des requêtes. La réutilisation supprime ce coût de chaque requête après la première.

Comment l'appliquer

• Garder un seul objet client avec un pool de connexions pendant toute la durée de vie du processus (requests.Session, httpx.Client, un Agent Node avec keep-alive) plutôt que d'en créer un par appel. La documentation de Requests indique que le keep-alive est automatique au sein d'une session.
• Consommer ou fermer chaque corps de réponse. La même documentation note que les connexions ne retournent au pool qu'une fois toutes les données du corps lues ; une réponse en flux non lue occupe une connexion.
• Fixer le délai d'inactivité du client en dessous de celui du serveur et du proxy. Sinon le client choisit une connexion que le serveur vient de fermer, et la première requête après une période d'inactivité échoue avec une réinitialisation. La RFC 9112 indique que les implémentations devraient anticiper de telles fermetures asynchrones et renvoie à la RFC 9110 pour savoir quand une requête peut être retentée automatiquement ; retenter une seule fois, et uniquement les requêtes idempotentes.
• Borner le pool par hôte à ce que le serveur accepte, et recycler les connexions après un certain nombre de requêtes ou un âge maximal afin que des connexions de longue durée n'immobilisent pas un client sur un seul backend derrière un répartiteur de charge.
• Vérifier les en-têtes de réponse : un serveur qui répond Connection: close neutralise le pool silencieusement.

Pièges

Les équipements intermédiaires (middleboxes) abandonnent les connexions inactives sans en avertir aucune des deux extrémités ; la question ouverte sur les délais d'inactivité NAT couvre ce point. Une connexion TLS authentifiée avec un certificat client est liée à cette identité ; ne pas partager une telle connexion entre tenants. HTTP/2 multiplexe de nombreux flux sur une seule connexion, donc ses règles de pooling diffèrent de celles de HTTP/1.1.