Le changement le plus efficace à lui seul pour améliorer les performances d'un proxy n'est pas d'acheter un proxy plus rapide ; c'est de réutiliser la connexion existante. Un client qui ouvre une nouvelle connexion pour chaque requête paie en permanence le coût d'établissement de la connexion, et ce coût se démultiplie lorsqu'il passe par un proxy.
Le coût réel de l'établissement d'une connexion
Ces 200 ms sont repayées à chaque nouvelle connexion. Si vous envoyez 1 000 requêtes en ouvrant une nouvelle connexion à chaque fois, vous dépensez 200 secondes rien qu'en établissement.
Comment fonctionne le Keep-Alive ?
En HTTP/1.1, les connexions sont persistantes par défaut : la connexion ne se ferme pas après la réception de la réponse, la requête suivante est envoyée sur le même socket. Trois choses cassent ce comportement :
- Le serveur
Connection: closeenvoie — la connexion est fermée. - Le client crée un nouvel objet session à chaque requête — le pool ne fonctionne jamais.
- Le délai d'inactivité est dépassé — le proxy ou le serveur coupe la connexion.
Créer dans le code un nouvel objet Session, Client ou Agent pour chaque requête. Cela désactive totalement la réutilisation des connexions, quelle que soit votre configuration de pool.
La bonne configuration
Gardez la taille du pool juste en dessous de la limite de concurrence de votre fournisseur. Si vous la dépassez, des connexions supplémentaires sont ouvertes puis immédiatement fermées.
Quel est le gain ?
Dans cette mesure d'exemple, l'utilisation d'un pool réduit la durée totale à environ un tiers. Le gain augmente à mesure que la latence vers le proxy s'accroît.
Réutilisation de session TLS
À côté du pool de connexions, il existe une deuxième source de gain : le ticket de session TLS. Lors d'une reconnexion vers la même cible, un handshake abrégé peut remplacer le handshake complet. La plupart des clients modernes le font automatiquement ; l'essentiel est de réutiliser l'objet client.
Si vous recréez l'objet client à chaque requête, le ticket de session est perdu et un handshake complet est effectué à chaque fois.
L'équilibre du délai d'inactivité
Garder une connexion ouverte trop longtemps peut aussi poser problème : le proxy ou le serveur cible peut couper la connexion silencieusement et votre client ne s'en apercevra qu'à la requête suivante. D'où le schéma « la première requête échoue, la seconde réussit ».
| Réglage | Recommandé | Pourquoi |
|---|---|---|
| keepalive_expiry | 30–60 s | Doit être inférieur au timeout du serveur |
| Taille du pool | En dessous de la limite de concurrence | Au-delà, des handshakes pour rien |
| Nouvelle tentative | 1 fois | Compense une connexion coupée |
| Limite de durée de vie des connexions | 5–10 min | Les connexions à longue durée de vie s'éventent |
Gardez le délai d'inactivité plus court que le timeout du serveur. Ainsi c'est vous qui fermez la connexion et la situation « le serveur a fermé mais je l'ignore » ne se produit pas.
Le conflit avec la rotation
La réutilisation des connexions et la rotation d'IP s'opposent naturellement : utiliser la même connexion revient à rester sur la même IP de sortie. Ce n'est pas un problème, c'est un arbitrage :
Dans la plupart des scénarios, la deuxième option est la bonne : réutilisez la connexion un certain temps (par exemple 30 requêtes ou 5 minutes), puis renouvelez-la.
Pour les stratégies de rotation, notre article sur les réglages de rotation vous pouvez le consulter.
Résumé
Le keep-alive et le pool de connexions constituent le principal levier des performances proxy. Créez l'objet client une seule fois et réutilisez-le, gardez la taille du pool en dessous de la limite du fournisseur, réglez le délai d'inactivité en deçà du timeout du serveur et ajoutez une seule nouvelle tentative. Si vous avez besoin de rotation, préférez un renouvellement périodique à la désactivation du pool. Pour la mesure, test de ping et vérification de proxy vous pouvez utiliser nos outils.