Connexions simultanées

Ce qu’est une connexion et comment elle fonctionne

Une connexion réseau est un lien de communication que deux programmes établissent pour échanger des données. Par exemple, un navigateur se connecte à un serveur web pour demander une page et en recevoir le contenu. La connexion fournit le chemin de cet échange ; une requête et une réponse sont des messages qui y circulent.

Prenons une connexion TCP classique. L’application contacte l’adresse IP du serveur et le port du service requis. Les deux côtés échangent des messages de contrôle pour établir la connexion. Les données circulent ensuite en petites unités appelées paquets. TCP suit leur livraison, organise la retransmission des données perdues et présente les données au destinataire dans le bon ordre. Les deux côtés conservent des informations sur l’échange pendant toute la durée de la connexion.

Avec un proxy TCP classique, l’application se connecte d’abord au serveur proxy. Celui-ci établit une connexion distincte au site de destination et transmet les données entre les deux connexions, dans les deux sens. Il maintient donc une communication avec le client et avec la destination.

L’application peut envoyer une requête, recevoir une réponse, puis utiliser la connexion établie pour un autre échange. Recevoir une page, par exemple, ne ferme pas nécessairement la connexion : le navigateur peut la conserver pour d’autres requêtes au serveur. Lorsqu’elle n’est plus nécessaire, l’un des côtés la ferme ; une erreur ou un dépassement de délai peut aussi y mettre fin. Jusqu’à sa fermeture, une connexion peut exister sans transférer des données en continu.

Un programme peut maintenir plusieurs connexions de ce type à la fois : recevoir des données sur l’une, attendre une réponse sur une autre et en garder une troisième prête pour une requête ultérieure. Ce sont des connexions simultanées. Le compteur décrit les canaux de communication ouverts à cet instant, plutôt que le nombre total de requêtes effectuées depuis le démarrage du programme.

Ce que mesure la limite

Une connexion ouverte occupe une place dans le quota concerné. Une fois fermée et retirée du compteur par le service, cette place redevient disponible. Il s’agit d’une limite d’activité en cours : l’atteindre ne consomme donc pas un solde mensuel de connexions.

La façon dont les connexions sont décomptées du quota du client est une règle de service distincte. Les deux segments réseau au niveau du proxy ne consomment pas automatiquement deux unités du quota.

Les fournisseurs fixent ces limites parce que les connexions ouvertes consomment des ressources serveur, même lorsqu’elles transfèrent peu de données. Une connexion en attente de réponse doit toujours être maintenue. En maîtriser le nombre aide le service à conserver une capacité suffisante pour les charges qu’il s’est engagé à prendre en charge.

Plusieurs limites différentes peuvent s’appliquer au même service :

Un trafic illimité ne dit donc rien du nombre de connexions simultanées. Il peut aussi exister une limite distincte sur la vitesse d’ouverture de nouvelles connexions. Les ouvrir et les fermer rapidement peut atteindre cette limite même si peu d’entre elles restent ouvertes à un instant donné.

Pourquoi le nombre de fils d’exécution ne correspond pas au nombre de connexions

Le nombre de fils d’exécution ou de processus de travail d’une application décrit la façon dont elle organise ses tâches. Il n’indique pas de manière fiable le nombre de connexions que le proxy comptabilisera. Une tâche peut contacter plusieurs serveurs, et un script asynchrone peut gérer de nombreuses opérations réseau sans créer un fil d’exécution du système d’exploitation pour chacune.

Chaque requête HTTP ne nécessite pas non plus une nouvelle connexion. Un client peut réutiliser une connexion existante, et HTTP/2 peut transporter plusieurs requêtes en même temps sur une seule connexion. Le nombre de requêtes diffère donc du nombre de connexions.

La terminologie du fournisseur compte aussi. Une limite décrite en « threads » ou en « sessions » peut désigner des connexions ouvertes ou des requêtes en cours de traitement. Une session persistante avec maintien de l’IP, qui conserve la même IP proxy pour des requêtes liées, ne représente pas nécessairement une seule connexion réseau. La définition utile est celle de ce que le service comptabilise réellement.

Quels programmes partagent le quota ?

Une limite peut être rattachée à un compte, à un forfait acheté, à une IP proxy individuelle ou à une passerelle précise. Pour une limite par compte ou par forfait, additionnez les connexions de tous les programmes et appareils qui utilisent ce quota. Répartir une liste d’IP entre plusieurs ordinateurs ne crée pas un quota distinct pour chaque ordinateur.

Avec une limite par IP, la répartition est différente : une adresse très sollicitée peut atteindre son plafond alors qu’une autre dispose encore de places. Déplacer une partie du travail vers la seconde adresse peut aider, à condition que le service n’impose pas aussi une limite commune plus basse. Un forfait peut comporter à la fois un quota global et des allocations plus petites pour chaque utilisateur ou IP client.

Le nombre d’IP clients autorisées à s’authentifier est un autre réglage. Il détermine quels réseaux peuvent accéder aux proxys, plutôt que le nombre de connexions que ces réseaux peuvent ouvrir. Plusieurs appareils derrière une même IP publique peuvent partager à la fois cette règle d’accès et l’allocation de connexions qui lui est attachée.

Changer l’IP proxy visible par un site ne réinitialise pas un quota de connexions applicable à tout le compte. De même, changer le nom d’une session persistante ou le protocole ne fournit pas automatiquement davantage de capacité. La limite reste rattachée au compte, au forfait ou au point de connexion utilisé par le fournisseur pour son décompte.

Pourquoi les connexions s’accumulent

Les connexions s’accumulent lorsque de nouvelles connexions sont ouvertes plus vite que les anciennes ne sont fermées. Cela peut se produire pendant le chargement de pages, le téléchargement de fichiers ou l’exécution parallèle d’autres tâches réseau : certaines connexions transfèrent encore des données ou attendent une réponse pendant que l’application en ouvre d’autres. Elles sont décomptées du quota en même temps et peuvent, ensemble, épuiser la limite de connexions proxy.

Les réponses lentes maintiennent les connexions occupées plus longtemps. Si un programme continue de lancer de nouvelles opérations au même rythme, le travail inachevé s’accumule. S’il maintient plutôt l’activité parallèle à un niveau fixe, un site plus lent signifie généralement moins de tâches achevées par minute. Les deux situations peuvent se produire sans aucun changement du forfait proxy.

Les longs téléchargements et les connexions en attente d’un dépassement de délai peuvent avoir le même effet. Un grand nombre de connexions ouvertes peut donc coexister avec une faible vitesse de transfert : une grande partie du temps est passée à attendre plutôt qu’à déplacer des données.

Certaines connexions restent délibérément ouvertes entre les requêtes. Ce fonctionnement est généralement appelé keep-alive. Il évite d’établir une nouvelle connexion à chaque fois, mais une connexion inactive peut encore occuper une place si le service compte les connexions ouvertes. Une connexion remise dans le pool de l’application est disponible pour être réutilisée ; elle n’a pas nécessairement été fermée au niveau du proxy.

Un autre problème est la mauvaise libération des connexions. Cela peut arriver dans des logiciels prêts à l’emploi comme dans des scripts personnalisés. Par exemple, le code peut commencer à lire une réponse, rencontrer une erreur et lancer une autre requête sans terminer ni fermer la réponse précédente. Si de nouvelles connexions continuent de s’ouvrir tandis que les anciennes restent occupées, l’application peut épuiser son quota sans accomplir davantage de travail utile. C’est une raison de vérifier la libération des connexions après les erreurs et les annulations, et pas seulement après les requêtes réussies.

Une libération correcte permet au client de réutiliser une connexion adaptée ou de fermer celle dont il n’a plus besoin. Les délais d’expiration empêchent les opérations abandonnées d’attendre indéfiniment. Désactiver partout la réutilisation n’est pas une solution générale : cela ajoute du travail d’établissement de connexions et peut augmenter la fréquence des nouvelles connexions. L’objectif est de maîtriser le nombre de connexions réutilisables, en libérant ou en fermant correctement celles qui sont inutiles.

Pourquoi les proxys semblent fonctionner, s’arrêter, puis fonctionner de nouveau

Des échecs intermittents sous charge justifient de vérifier rapidement la limite de connexions. Certaines adresses proxy semblent fonctionner tandis que d’autres échouent ; peu après, la répartition change. Du point de vue de l’application, différentes parties de la liste de proxys peuvent sembler se déconnecter à tour de rôle.

Une explication est que le quota partagé est plein. Les connexions existantes peuvent continuer, tandis que les tentatives d’en ouvrir davantage sont rejetées ou laissées en attente. À mesure que les anciennes connexions se ferment, certaines nouvelles tentatives aboutissent. D’autres échouent lorsque les places disponibles sont de nouveau occupées. Le résultat change en raison de la concurrence pour un même quota, plutôt qu’à cause d’un groupe fixe d’IP défaillantes.

Ce comportement est parfois décrit comme une limitation. Ici, la restriction porte sur l’admission de nouvelles connexions ; elle ne réduit pas nécessairement la vitesse de chaque connexion établie. La réaction précise dépend du service : il peut renvoyer un message clair de limite atteinte, refuser une connexion ou laisser le client dépasser son délai d’attente. Une file d’attente n’est pas garantie.

Pour vérifier cette explication, comparez les échecs au nombre de connexions et réduisez temporairement l’activité parallèle des programmes qui partagent le quota. Si les échecs cessent lorsque l’activité passe sous la limite et reviennent quand elle est de nouveau atteinte, le plafond de connexions est une cause probable. Des interruptions similaires peuvent aussi venir du site cible ou du réseau. Un dépassement de délai ou une réponse HTTP 429, 502 ou 503 ne suffisent pas, à eux seuls, à établir que la limite de connexions proxy a été atteinte ; l’origine et le libellé de l’erreur comptent.

Comment maintenir le travail utile dans la limite

Commencez par les sites et les opérations que votre logiciel doit réellement utiliser. Augmentez progressivement l’activité parallèle et observez les résultats réussis, les temps de réponse et les pics de connexions. Un bref test sur une page rapide peut ne pas représenter une exécution complète comprenant des authentifications, des réponses volumineuses et des points de connexion plus lents.

1. Attribuez à tous les programmes un budget de connexions commun. Gardez une marge pour les autres activités et les courtes rafales. Si plusieurs processus utilisent le même forfait, donner à chacun le quota complet du forfait peut surcharger le service lorsqu’ils fonctionnent ensemble.
2. Maîtrisez les tâches et les connexions. Un pool de connexions conserve les connexions pour les réutiliser. Vérifiez si son réglage de taille constitue une limite stricte ou simplement le nombre conservé ensuite ; certains clients ouvrent des connexions supplémentaires si aucun mode d’attente n’est activé. Maintenez la libération des réponses et les délais d’expiration, y compris lorsqu’une tâche échoue.
3. Échelonnez les lancements et les nouvelles tentatives. Démarrer tous les navigateurs à la fois ou répéter immédiatement chaque requête échouée crée un nouveau pic. Limitez le nombre de nouvelles tentatives, avec des délais croissants, et incluez-les dans le même budget de charge. Un dépassement de délai ne prouve pas non plus qu’une action soumise a échoué ; répéter un achat ou une mise à jour demande donc de la prudence.
4. Mesurez le travail achevé. Davantage de processus de travail ne sont utiles que s’ils améliorent le débit de résultats réussis. S’ils ajoutent surtout de l’attente et des erreurs, un réglage plus bas peut terminer la même tâche plus vite. Si un tableau de bord présente une moyenne d’activité dans le temps, les pics brefs peuvent être moins visibles que dans les horodatages d’erreurs de l’application.

Pour les tâches dans un navigateur, éviter les téléchargements inutiles peut aussi réduire l’activité réseau. Bloquer les images ou la vidéo peut aider lorsque la tâche n’en a pas besoin ; supprimer des scripts peut casser l’opération elle-même. Évaluez la modification selon que la tâche prévue se termine toujours correctement ou non.

Quand une limite plus élevée est utile

Une capacité de connexions supplémentaire est utile lorsque l’application gère correctement ses connexions et que la charge requise atteint régulièrement le plafond du fournisseur. Elle peut permettre à davantage de tâches de s’exécuter ensemble sans se disputer le même petit quota.

L’achat doit augmenter la limite réellement atteinte. Ajouter des IP peut aider en cas de restriction par IP lorsque le travail est réparti entre elles. Pour une limite de forfait partagée, le nouveau forfait ou l’option supplémentaire doit relever ce quota commun. Une augmentation du nombre d’IP ne prouve pas, à elle seule, que ce sera le cas.

Il existe aussi d’autres plafonds. Le client peut avoir un pool plus petit, l’ordinateur peut manquer de ressources réseau ou la destination peut limiter les requêtes. Une connexion mobile unique dispose également de sa propre bande passante, quel que soit le nombre de connexions proxy autorisées. Acheter davantage de connexions simultanées ne supprime pas ces contraintes et ne répare pas un script qui laisse ses connexions s’accumuler.

L’objectif pratique est de disposer d’assez de marge pour les pics habituels de la charge tout en limitant les échecs. Une fois ce fonctionnement établi, un quota de connexions supplémentaire peut constituer une augmentation de capacité utile plutôt qu’un moyen de repousser la correction de l’application.