Limites d’utilisation des proxys

Ce qu’un fournisseur peut limiter

Certaines limites décrivent une ressource consommée sur une période. D’autres encadrent la charge à un instant donné ou décident si une connexion est autorisée. Les distinctions suivantes sont utiles même lorsqu’un forfait n’affiche qu’un ou deux de ces paramètres.

Un fournisseur utilise ces règles pour répartir la capacité du réseau et les ressources de traitement, maîtriser les coûts et restreindre les activités indésirables. Leurs effets diffèrent : une limite de connexions plus élevée autorise davantage de connexions à la fois, tandis que l’autorisation d’atteindre une destination bloquée change les tâches que le service peut accomplir. Modifier une condition ne modifie pas automatiquement les autres.

Connexions simultanées

Une limite de connexions simultanées fixe le nombre de connexions qui peuvent rester ouvertes à la fois. Un navigateur ou une autre application peut en ouvrir plusieurs pour une seule tâche. Le nombre d’onglets, de profils ou de fils d’exécution d’un programme ne permet donc pas de savoir exactement quelle part de ce quota est utilisée.

Les connexions peuvent rester ouvertes entre les requêtes, et HTTP/2 peut transporter plusieurs requêtes sur une seule connexion. Envoyer moins de requêtes par minute ne libère pas nécessairement les connexions occupées. L’article sur les connexions simultanées explique ce qui consomme ce quota et pourquoi il diffère du nombre de requêtes.

Les limites peuvent s’influencer mutuellement. Si une réponse volumineuse prend plus de temps à transférer, sa connexion peut rester occupée plus longtemps. Un programme qui continue de lancer de nouvelles opérations peut alors atteindre sa limite de connexions, même au même débit de requêtes. Ajouter du travail en parallèle à ce stade peut accroître l’attente et les échecs sans augmenter le débit de travail achevé.

Sites et applications bloqués

Un fournisseur peut restreindre l’accès à certains sites, adresses ou opérations. Une destination peut figurer sur sa liste de blocage même si le trafic est illimité et que des connexions sont encore disponibles. L’accès peut aussi différer entre les produits d’un même fournisseur. L’article sur les sites et applications bloqués explique l’origine de ces listes et ce qui détermine l’accès à une ressource donnée.

Une application peut utiliser plusieurs destinations : sa page principale peut s’ouvrir alors qu’une fonction distincte échoue. Le site de destination peut aussi imposer ses propres restrictions, même si le fournisseur de proxys autorise l’accès. Pour comprendre un échec, identifiez d’abord la ressource indisponible et le côté qui a refusé la requête.

Ports bloqués

L’accès à un site ne prouve pas que tous les services réseau du même serveur sont disponibles. Un fournisseur peut autoriser le trafic web tout en bloquant un port de soumission de courriels. Ce qui compte ici est le port de destination demandé par l’application. L’article sur les ports bloqués explique en quoi il diffère du port utilisé pour se connecter au proxy lui-même.

La prise en charge du transport fait également partie de cette autorisation. TCP et UDP sont deux façons différentes de transporter des données, et l’accès à un port TCP donné ne garantit pas l’accès au port UDP de même numéro. Le transport requis doit être pris en charge et autorisé par le produit. Davantage d’IP ou un quota de connexions plus élevé ne peuvent pas fournir une autorisation manquante.

Volume de données, vitesse de transfert et nombre de requêtes

Volume de trafic

Selon le fournisseur et le produit, le trafic peut être illimité ou vendu avec un quota de données. Certains fournisseurs vendent un volume fixe, par exemple un forfait mensuel en gigaoctets. Pour ce type de forfait, vérifiez la durée de validité, la date de réinitialisation du quota et le report éventuel des données inutilisées. Ces règles de comptabilisation s’appliquent aux produits avec un quota de données ; elles ne constituent pas une condition universelle de l’accès aux proxys.

La taille d’un résultat enregistré n’est pas une estimation fiable du trafic. Extraire un prix ou un nom de produit très court peut nécessiter le téléchargement d’une page entière. Un navigateur peut aussi demander des images, des scripts et d’autres fichiers. De nouvelles tentatives peuvent transférer les données à nouveau. Mesurer l’application réelle aide à estimer la charge réseau. Si le produit est facturé au volume de trafic, vérifiez aussi quels octets transférés le fournisseur comptabilise.

Vitesse de transfert

Une limite de débit de transfert encadre la quantité de données qui peut passer pendant une unité de temps. Elle est généralement exprimée en bits par seconde, comme les Mbps, ou en octets par seconde, comme les MB/s. Un octet contient huit bits : 80 Mbps correspondent à 10 MB/s avant les surcharges liées aux protocoles. Il s’agit d’unités de vitesse ; un quota mensuel exprimé en GB répond à une autre question.

La portée de la vitesse annoncée compte. Un port serveur donné pour une certaine vitesse ne signifie pas que chaque client ou chaque connexion reçoit ce débit. Plusieurs transferts peuvent partager une même capacité. La vitesse réelle dépend aussi du trajet, du serveur de destination et de la connexion du client : le plafond indiqué par un fournisseur n’est donc pas un résultat garanti pour chaque téléchargement.

Le temps de réponse compte aussi, en plus de la vitesse de transfert. Un serveur peut faire attendre une application avant d’envoyer une petite réponse, même si la capacité disponible suffit largement à transférer les octets. Les téléchargements volumineux sont plus sensibles au débit de transfert soutenu ; les charges composées de nombreuses requêtes courtes peuvent être davantage affectées par les délais de réponse et le débit de requêtes autorisé.

Quota et débit de requêtes

Un quota de requêtes précise le nombre d’opérations comptabilisées incluses. Une limite de débit de requêtes précise l’intervalle auquel elles peuvent être envoyées. Disposer d’un solde important ne signifie pas qu’il peut être entièrement consommé en une brève rafale. Ces deux limites peuvent exister indépendamment, y compris dans un produit qui ne facture pas le volume de trafic.

L’opération comptabilisée doit aussi être clairement définie. Un clic, une visite de page, une requête HTTP et une tâche d’extraction web achevée sont des événements différents. Une visite de page peut générer de nombreuses requêtes HTTP ; une tâche d’API gérée peut nécessiter plusieurs tentatives effectuées par le fournisseur. Le fait que ces tentatives consomment ou non le quota du client dépend des règles de comptabilisation du produit.

Une limite de débit comporte aussi une fenêtre temporelle et des règles pour les courtes rafales. Diviser une limite par minute par soixante donne une moyenne, mais n’indique pas comment le service traite un lot envoyé d’un seul coup. Répartir les opérations autorisées dans le temps peut permettre de respecter une limite de débit sans changer leur volume total. Cela ne reconstitue pas un quota de requêtes déjà consommé.

Le compte, l’IP ou le produit qui partage la limite

Un chiffre n’est utile que si vous savez ce qui le partage. Un fournisseur peut appliquer une limite à un compte, à une commande, à une IP proxy individuelle, à une IP client autorisée ou à un autre groupe défini. Par exemple, un débit de transfert total alloué à un compte est partagé entre les programmes qui l’utilisent. Attribuer des IP de sortie différentes à ces programmes ne crée pas une capacité distincte pour chacun.

Plusieurs niveaux peuvent s’appliquer ensemble. Un service peut fixer un maximum pour chaque IP proxy et un second pour l’ensemble du forfait. Répartir le travail entre les IP peut aider à respecter la première contrainte, mais le total du forfait reste applicable. Une limite liée à l’IP publique du client peut aussi être partagée entre plusieurs appareils qui accèdent à Internet par cette adresse.

Les règles propres au produit comptent également. Une connexion proxy directe, une API d’extraction web gérée et un autre réseau vendu par le même fournisseur peuvent avoir des quotas et des autorisations différents. L’unité comptée par une API peut être une tâche ou un résultat plutôt qu’une connexion réseau. Consultez les limites du produit que vous comptez utiliser, y compris les réglages appliqués spécifiquement à votre compte.

Ce qui se passe lorsqu’une limite est atteinte

La réaction du service dépend de la règle. Au plafond de débit de transfert, les données peuvent continuer à circuler à une vitesse limitée. Avec une limite de débit de requêtes, les opérations excédentaires peuvent attendre ou être rejetées. À la limite de connexions, le service peut refuser les nouvelles connexions tandis que les connexions existantes restent utilisables. Pour les produits avec un quota de trafic ou de requêtes, l’épuisement de ce quota peut nécessiter un renouvellement ou un achat supplémentaire ; les conditions du fournisseur déterminent les options disponibles.

Le mot « illimité » doit donc préciser ce qui l’est : le trafic, les requêtes ou les connexions. Chacun décrit un paramètre. Un forfait avec trafic illimité peut tout de même avoir une vitesse de transfert finie et une limite de connexions. Lorsqu’un fournisseur utilise des conditions d’utilisation équitable pour modifier une capacité après une forte utilisation prolongée, ces conditions font aussi partie du forfait. Le mot seul ne définit pas l’ensemble des règles.

Un message explicite du fournisseur est plus utile qu’un échec générique. HTTP 429 signifie que le service qui répond juge le nombre de requêtes trop élevé selon ses règles. Identifiez d’abord si la réponse provient du service proxy ou de la destination. Un dépassement de délai peut avoir d’autres causes, notamment une destination lente ou un problème réseau. Les statistiques d’utilisation, les détails de l’erreur et l’heure de la tentative aident à distinguer un problème de quota d’une défaillance ailleurs.

Renvoyer sans cesse des opérations refusées peut aggraver un problème de débit et consommer du quota supplémentaire. Une modification utile cible la condition connue : réduire la fréquence d’envoi, fermer les connexions devenues inutiles, recharger le quota épuisé ou confirmer l’autorisation d’accès à la destination. Passer à un forfait supérieur n’aide que si cela modifie cette condition précise.

Adapter les limites à la tâche complète

Commencez par le résultat requis et l’échéance. À titre d’exemple de calcul, supposons qu’une tâche nécessite 6 000 requêtes HTTP en 30 minutes, avec une réponse moyenne de 0,5 MB. Cela représente en moyenne 200 requêtes par minute et environ 3 GB de données de réponse en unités décimales. L’estimation exclut les données sortantes, les ressources supplémentaires du navigateur et les nouvelles tentatives. Il faut les inclure si la tâche réelle en génère et si le service les comptabilise.

Ces totaux ne suffisent pas encore à déterminer le quota de connexions nécessaire. Testez l’activité parallèle réelle de l’application et la durée pendant laquelle les connexions restent occupées. Incluez les autres programmes qui partagent la même limite et les courtes rafales qui se produisent lorsque plusieurs tâches démarrent ensemble. Mesurez séparément le volume de données, le débit de requêtes et les connexions simultanées ; un compteur ne peut pas remplacer les trois.

Utilisez le produit et les destinations prévus pour le test, en incluant les fonctions de l’application nécessaires à l’achèvement de la tâche. Une petite vérification réussie montre qu’une opération a fonctionné. Une exécution représentative apporte des éléments sur la charge soutenue, les pics et les ressources nécessaires à la tâche complète. Gardez une marge pour les variations observées pendant le test plutôt que de considérer la moyenne comme un maximum sûr.

Si un besoin manque de clarté, fournissez à l’assistance une description concrète : produit, hôtes cibles, ports et transport de destination, volume de données prévu, débit de requêtes, pic de connexions et message d’erreur exact, le cas échéant. Cela permet au fournisseur de vérifier le quota ou l’autorisation concernés. L’objectif est de faire correspondre les limites annoncées du service à la charge de travail prévue.