Tarification des proxys par GB

Ce que vous payez

Un gigaoctet est une unité de consommation au sein d’un produit proxy. Le produit fournit un chemin vers Internet par ses IP de sortie ; le tarif détermine comment l’utilisation de ce chemin est facturée. Vous pouvez acheter à l’avance un solde de trafic, recevoir un quota récurrent ou payer une utilisation mesurée selon un contrat de compte. Toutes ces formules peuvent avoir un prix par GB, même si leurs dates de paiement et leurs engagements diffèrent.

L’accès passe souvent par une passerelle : votre application se connecte à une adresse fournie par le prestataire, et le service sélectionne une sortie dans un pool disponible. Changer de sortie peut continuer de consommer le même quota du compte. Un grand pool annoncé décrit donc des possibilités d’accès, pas une liste d’adresses qui vous sont réservées. Certains produits combinent plutôt une facturation du trafic avec l’accès à des IP précises.

L’unité de facturation ne détermine ni le type de réseau ni le comportement des sessions. Les produits de centres de données, ISP, résidentiels et mobiles peuvent être vendus au trafic. La rotation, la possibilité de conserver une IP pour une session et l’utilisation exclusive d’une adresse sont des propriétés distinctes du produit. Payer davantage de GB ne prolonge pas une session qui possède sa propre durée limite et ne rétablit pas une sortie indisponible.

Choisissez l’accès requis avant de comparer les tarifs. Pour un test de parcours d’achat régional, le produit utile doit fournir une IP acceptée dans la localisation requise et maintenir la session jusqu’à la validation de la commande. Un quota moins cher qui ne le permet pas ne répond pas à la tâche. À l’inverse, acheter un réseau plus coûteux n’apporte aucun avantage automatique lorsque le plus simple fonctionne déjà de manière fiable.

Le quota ne dit rien non plus de la vitesse de transfert. Le volume détermine la quantité qui peut passer ; le débit détermine à quelle vitesse elle passe ; les connexions simultanées déterminent la quantité de travail qui peut être active ensemble. Un solde important ne compense pas un trajet trop lent pour terminer une tâche dans un délai impératif.

Comment une tâche achevée se traduit en trafic payant

Commencez par l’opération entière. Un programme peut d’abord obtenir une liste de documents, suivre les liens de téléchargement, récupérer les fichiers, puis répéter quelques téléchargements. Chaque étape peut utiliser la connexion payante, même si l’archive finale ne contient qu’un exemplaire de chaque document.

Prenons un exemple de tâche d’archivage qui enregistre correctement 300 documents. Les volumes de trafic supposés ci-dessous décrivent des parties distinctes et sans chevauchement de l’exécution. Il s’agit d’un exemple de comptabilisation, pas de mesures réalisées sur un site ou chez un fournisseur précis.

En unités décimales, cette exécution consomme 0,308 GB. À un tarif supposé de 4,50 $/GB, le coût du trafic est de 1,386 $, soit environ 1,39 $ avant tous autres frais. La distinction utile est celle entre les 240 MB associés aux documents conservés et les 308 MB utilisés par le processus. Supprimer les téléchargements redondants économiserait 48 MB sans réduire l’archive ; supprimer l’étape de recherche des documents pourrait empêcher la tâche de fonctionner.

Le périmètre de mesure du fournisseur compte. Les politiques publiées des services proxy comptabilisent couramment les données envoyées vers le site ainsi que celles reçues, y compris les en-têtes et les corps HTTP. Un travail comportant beaucoup d’envois consomme donc un quota même si la réponse du site est courte. Les politiques diffèrent pour le trafic de connexion, les surcharges du chiffrement et les erreurs générées par le service. Un compteur du contenu des fichiers téléchargés ne suffit pas à reconstituer toutes les factures.

Un tunnel HTTPS peut transporter des octets chiffrés que le proxy mesure sans lire le contenu protégé. Pour le budget, utilisez la méthode annoncée par le fournisseur et une exécution mesurée ; il n’existe pas de pourcentage universel de surcharge à ajouter à chaque requête. Appliquer un tel pourcentage à un compteur qui inclut déjà ces octets les compterait une seconde fois.

Pourquoi les GB et les GiB affichent des nombres différents

Un gigaoctet (GB) contient 1 000 000 000 octets. Un gibioctet (GiB) contient 2³⁰ octets : 1 073 741 824 octets, soit 1 024 MiB. Le GB utilise les puissances décimales ; le GiB utilise les puissances binaires. Ils mesurent la même nature de quantité avec des unités de tailles différentes.

Par exemple, 32 GiB correspondent à 34,359738368 GB, soit environ 34,36 GB. Le nombre exprimé en GB est environ 7,37 % plus élevé, car chaque GiB contient 1,073741824 GB. Aucun trafic supplémentaire n’est apparu : les deux valeurs décrivent le même nombre d’octets. Un quota de 32 GB correspond, quant à lui, à environ 29,80 GiB ; un nombre affiché identique ne rend donc pas deux quotas égaux.

Avant de rapprocher le compteur d’une application de l’utilisation facturée, convertissez les deux valeurs dans la même unité. Vérifiez la définition du fournisseur plutôt que de vous fier à une abréviation, puis vérifiez le périmètre de comptabilisation. L’arrondi est une question distincte : une valeur abrégée dans le tableau de bord ne révèle pas la précision utilisée pour la facturation.

Pourquoi le déroulement du travail compte autant que la page

Les premières visites et les suivantes diffèrent

Une première visite peut télécharger les ressources nécessaires à l’affichage et au fonctionnement d’un site. Une visite ultérieure dans le même navigateur peut réutiliser certaines ressources locales, tandis qu’un nouveau profil de navigateur peut devoir les récupérer à nouveau. La manière de démarrer et de réutiliser les sessions du navigateur fait donc partie du modèle de trafic.

La mise en cache a plusieurs effets possibles. Une copie locale à jour peut être utilisée sans retélécharger la ressource. Une copie périmée peut nécessiter une requête conditionnelle ; une réponse 304 Not Modified autorise la réutilisation du contenu enregistré, mais l’échange de validation utilise tout de même le réseau. Une ressource modifiée ou non réutilisable nécessite un nouveau transfert. Conserver un profil ne garantit pas que toutes les ressources seront mises en cache.

Pour une tâche de surveillance, les ressources en cache peuvent être utiles. Pour un test de l’expérience d’un nouveau visiteur, elles peuvent invalider le test. Mesurez dans les conditions réellement requises par la tâche. Une visite répétée peu coûteuse n’est pas une estimation solide pour des milliers de premières visites indépendantes.

Le format de sortie peut aussi induire en erreur. Faire une capture d’écran localement crée une image à partir d’un contenu déjà chargé ; cela n’envoie pas, en soi, la capture par le proxy. Envoyer cette image par le proxy constituerait un autre transfert. Un navigateur hébergé à distance ou une API de capture d’écran peut avoir un autre modèle de facturation ; la taille de sa sortie ne doit donc pas être considérée comme le trafic d’un navigateur local ordinaire.

Les téléchargements et la vidéo nécessitent des estimations différentes

Pour une tâche de transfert de fichiers, la taille des documents, la détection des doublons et la possibilité de reprendre après une interruption dominent souvent la consommation. Pour un test vidéo, la durée et le débit deviennent plus utiles que le nombre de pages. La page initiale peut être petite alors que le lecteur continue de récupérer des médias pendant toute la durée du test.

Supposons qu’un test reçoive en moyenne 6 mégabits par seconde de données multimédias pendant 18 minutes. Diviser par huit convertit les bits en octets : 6 × 1 080 ÷ 8 = 810 mégaoctets, soit 0,81 GB. Répéter ce test complet depuis 12 localisations transférerait 9,72 GB de médias seuls. Il s’agit d’une charge supposée ; l’interface du lecteur, les autres requêtes et les surcharges comptabilisées s’y ajoutent. La qualité adaptative et la mise en mémoire tampon peuvent modifier le transfert réel.

Réduire la qualité de lecture n’est une économie que si le test répond toujours à sa question. Une brève vérification du démarrage d’une vidéo peut utiliser une courte fenêtre d’observation. Un test de lecture soutenue en haute qualité doit recevoir une portion suffisante de ce flux pour l’évaluer. Les éléments à recueillir déterminent quelles données peuvent être omises.

Ces différences expliquent les cas où la tarification au trafic convient. De brèves vérifications régionales et un accès intermittent à un pool utile peuvent nécessiter peu de données. Des tests multimédias continus ou des téléchargements volumineux répétés peuvent consommer rapidement le même quota. Les deux sont techniquement possibles avec un produit adapté ; leur coût dépend de la quantité de travail, de son calendrier et des autres solutions disponibles.

Construire une prévision à partir des différents types de travail

Définissez l’achèvement avant de mesurer. Une tâche documentaire réussie peut exiger un fichier lisible portant l’identifiant attendu ; un test régional peut nécessiter une interaction achevée et un résultat consigné. Une connexion réussie ou un code d’état HTTP ne suffisent pas, à eux seuls, à établir que le travail est terminé.

Effectuez un essai pilote avec les localisations, les paramètres de session, le logiciel et le niveau d’activité parallèle prévus. Séparez ses identifiants ou ses rapports d’utilisation du travail sans rapport. Relevez l’évolution de l’utilisation sur une période correspondante, en tenant compte du délai de remontée du fournisseur, et comptez les tâches achevées ainsi que les tentatives. Si l’activité en arrière-plan fait partie du fonctionnement normal, incluez-la ou mesurez-la séparément au lieu de l’exclure sans le signaler.

Pondérer les différents types d’opérations

Une prévision utile conserve la répartition attendue. Supposons qu’un essai pilote fournisse les moyennes hypothétiques suivantes, qui incluent déjà les requêtes et les nouvelles tentatives normalement nécessaires pour chaque opération achevée. Chaque opération prévue appartient à une seule catégorie.

Au même tarif supposé de 4,50 $/GB, le coût de trafic prévu est de 67,986 $, soit environ 67,99 $. Les vérifications multimédias représentent moins d’une opération sur treize, mais presque 60 % du trafic. Optimiser les vérifications ultérieures, bien plus nombreuses, peut donc avoir moins d’effet qu’une modification adaptée du test multimédia.

Le calcul général est la somme du nombre de tâches de chaque type multiplié par son trafic moyen mesuré. N’ajoutez les activités de configuration ou communes mesurées séparément que si elles sont exclues de ces moyennes. De même, les nouvelles tentatives déjà présentes dans l’essai pilote ne doivent pas être ajoutées une seconde fois au moyen d’un multiplicateur d’échecs.

Tester ce qui peut modifier la prévision

Une moyenne n’est utile que tant que le travail reste comparable. Le passage à de nouveaux profils de navigateur peut supprimer les économies du cache. Une autre localisation peut recevoir une page ou un flux multimédia différent. Une fenêtre d’observation plus longue peut collecter davantage de données en arrière-plan. Vérifiez de nouveau la catégorie concernée après de tels changements plutôt que d’appliquer l’ancienne moyenne à tout le projet.

Testez aussi une exécution moins favorable mais plausible, en plus de l’exécution habituelle : des documents plus gros, de nouvelles sessions ou une période avec davantage d’interruptions. Gardez ses hypothèses visibles. Une réserve dérivée de ces conditions est plus instructive qu’un pourcentage inexpliqué ajouté à tous les budgets.

Pour choisir entre des services adaptés, convertissez chaque test en dépense pour la même charge de travail achevée. Incluez le trafic réellement consommé et tout engagement d’achat inévitable. Un prix bas par GB peut être utile, mais ne suffit pas à trancher une comparaison lorsqu’un service nécessite un nombre différent de tentatives ou ne peut pas terminer les sessions requises.

Adapter l’achat au calendrier du travail

La prévision ci-dessus estime la consommation. Le montant à payer peut différer parce que le produit vend le trafic en forfaits, impose un abonnement ou ajoute des frais d’accès distincts. Lisez l’offre comme un achat complet : ce qui devient disponible, à quelles dates et quel paiement autorise la poursuite de l’utilisation.

Un exemple de calendrier montre pourquoi les dates comptent. Un projet nécessite 8 GB avant un renouvellement de facturation et 28 GB après. Un quota mensuel hypothétique de 30 GB à 90 $, sans report ni autres frais, nécessite deux paiements mensuels : 180 $. Un solde hypothétique sans expiration vendu par blocs de 20 GB à 80 $ nécessite deux blocs : 160 $, en laissant 4 GB disponibles. Les deux formules sont supposées fournir un accès équivalent. Le tarif mensuel affiché de 3 $ est inférieur au tarif par bloc de 4 $, mais le projet, selon son calendrier, nécessite un décaissement plus élevé avec l’option mensuelle.

Placez ce même projet entièrement dans une période de facturation et la comparaison change : le quota de 30 GB nécessiterait 6 GB supplémentaires, ce qui rendrait le prix de la recharge décisif. C’est pourquoi multiplier la demande totale par le tarif affiché le plus bas ne suffit pas. Modélisez le travail selon les dates de renouvellement, les quantités minimales d’achat et toute date d’expiration du trafic supplémentaire.

Un quota restant n’aide pour le travail ultérieur que s’il reste utilisable selon les conditions du compte. Distinguez l’expiration du trafic du renouvellement de l’abonnement et de toute obligation de maintenir le compte actif. Si le trafic de base et les ajouts achetés ont des durées de validité différentes, déterminez quel solde est utilisé en premier ; la réponse peut influencer ce qui expire sans être utilisé.

La configuration choisie fait aussi partie du prix. L’accès à un réseau précis, une sélection géographique plus fine, des adresses réservées ou d’autres fonctionnalités peuvent modifier le coût. Si un tarif utilise un multiplicateur de consommation, distinguez les octets physiques des unités facturées. N’appliquez le multiplicateur que si le chiffre d’utilisation ne l’a pas déjà fait. La même attention est nécessaire pour les engagements minimaux, le tarif du trafic supplémentaire et les taxes incluses ou exclues du devis.

Pour un travail régulier et intensif, comparez toute la charge prévue à une option à prix fixe adaptée. L’autre solution doit répondre aux mêmes exigences de sites, de localisations, de sessions, de trafic autorisé et de vitesse de transfert. Un prix fixe peut faciliter le budget des gros transferts, tandis que l’accès au trafic peut éviter de maintenir une capacité rarement utilisée par une tâche occasionnelle. Aucune unité de facturation ne détermine quel réseau fonctionnera le mieux.

Reprendre après un échec sans payer deux fois le même travail

La reprise doit commencer par la plus petite partie inachevée de la tâche. Si une exécution a déjà enregistré la plupart de ses documents, relancer toute la liste peut faire payer de nombreux téléchargements identiques. Consignez les identifiants terminés, validez les fichiers enregistrés et reprenez la file restante. Cela réduit le gaspillage sans changer le réseau proxy ni son prix.

Les gros fichiers interrompus nécessitent un mécanisme plus précis. Lorsque le serveur et le client prennent en charge les requêtes de plage, un téléchargement peut demander la partie manquante. Le client doit vérifier qu’il poursuit le téléchargement de la même version du fichier. Une réponse 206 Partial Content fournit une plage ; une réponse complète 200 OK ne doit pas être ajoutée aveuglément à un fragment existant. La reprise peut économiser des octets transférés, mais elle doit être mise en œuvre correctement.

Les erreurs doivent conduire à des décisions différentes. Un échec de connexion temporaire peut justifier une nouvelle tentative limitée. Un refus répété, une connexion au compte expirée, un quota épuisé ou une requête invalide nécessitent une autre réponse. Répéter rapidement un problème inchangé peut dépenser davantage sans faire progresser le travail. Pour les actions qui modifient un compte distant, vérifiez si la première tentative a abouti avant de la soumettre de nouveau.

L’échec d’une tâche n’efface pas les octets déjà transférés. Un téléchargement interrompu ou une page de refus peuvent consommer du trafic payant ; certains services excluent leurs propres erreurs de connexion. Appliquez les conditions du produit proxy réellement utilisé plutôt que d’emprunter à une API d’extraction web une promesse de facturation des seules requêtes réussies.

La continuité de session peut aussi influencer la reprise. Remplacer une IP peut invalider un processus lié à cette session et obliger à répéter des étapes précédentes. Conserver une IP peut préserver la continuité, mais ne rend pas les transferts suivants gratuits et ne garantit pas que la session du site restera valide. Enregistrez la progression lorsque c’est possible et choisissez l’action de reprise qui répond à la défaillance.

Maintenir une tâche en cours dans son budget

Surveillez la progression en parallèle de l’utilisation. Trois indicateurs sont utiles : le quota restant, la consommation récente par minute et les tâches achevées sur le même intervalle. Si l’utilisation augmente alors que les tâches achevées stagnent, il faut intervenir avant que le solde soit épuisé. Si les deux augmentent proportionnellement, l’application accomplit peut-être simplement davantage de travail.

Par exemple, 14 GB restants avec une consommation soutenue de 0,35 GB par minute fournissent environ 40 minutes de trafic à ce rythme. Il s’agit d’une estimation de planification, pas d’une garantie d’arrêt : le débit peut changer, l’utilisation affichée peut être décalée et des transferts actifs peuvent encore être en cours. Comparez ce délai à la file restante et arrêtez ou réduisez les nouvelles opérations assez tôt pour terminer dans de bonnes conditions.

Utilisez des contrôles au niveau de l’achat et de l’application. Sur le compte, décidez explicitement si l’épuisement interrompt l’accès ou autorise un autre achat ou des frais de dépassement. Dans l’application, bornez la file d’attente, les tentatives, les transferts simultanés et la durée des sessions ouvertes. Une recharge automatique maintient le financement de la connexion ; elle ne peut pas décider si le travail mérite encore cette dépense.

Les téléchargements longs et les sessions multimédias nécessitent une condition d’arrêt explicite. Le simple fait de lancer moins de nouvelles requêtes peut laisser les transferts existants consommer des données. L’application doit pouvoir annuler le travail en cours et fermer les sessions inutilisées. Gardez une marge pour les délais de remontée et d’application des limites plutôt que de considérer un seuil du tableau de bord comme un interrupteur instantané.

Lorsque les chiffres semblent incorrects, rapprochez les données d’une seule exécution délimitée. Faites correspondre le compte ou l’utilisateur, l’intervalle de temps, l’unité et le journal de la tâche. Les outils réseau du navigateur aident à repérer les transferts lourds et à distinguer les tailles transférées des tailles décompressées des ressources, mais ils ne couvrent pas nécessairement tous les processus qui utilisent le compte. Suivez la consommation de trafic séparément des achats, des transferts de solde et des expirations ; une variation du solde n’est pas toujours un transfert réseau.

Effectuez ensuite une modification ciblée et répétez la même tâche. Préservez l’état du navigateur nécessaire au test, évitez les téléchargements en double, conservez la compression prise en charge et empêchez le chargement des ressources sans rapport lorsque cela ne casse pas le processus. Le résultat doit montrer à la fois une dépense plus faible et un travail achevé avec succès. Une réduction des transferts qui supprime les éléments que la tâche devait recueillir laisse le travail inachevé.