Tarificación de proxies por GB

Por qué pagas

Un gigabyte es una unidad de consumo dentro de un producto proxy. El producto proporciona una ruta a Internet a través de sus IP de salida; la tarifa determina cómo se cobra el uso de esa ruta. Puedes comprar saldo de tráfico por adelantado, recibir una cuota recurrente o pagar por el uso medido según un acuerdo de cuenta. Todos estos sistemas pueden tener un precio por GB, aunque sus fechas de pago y compromisos sean diferentes.

El acceso suele funcionar mediante una puerta de enlace: tu aplicación se conecta a una dirección proporcionada por el proveedor y el servicio elige una salida de un grupo disponible. Cambiar la salida puede seguir utilizando la misma cuota de la cuenta. Por tanto, un grupo grande anunciado describe un acceso posible, no una lista de direcciones reservadas para ti. En cambio, algunos productos combinan un cargo por tráfico con el acceso a IP concretas.

La unidad de facturación no determina el tipo de red ni el comportamiento de las sesiones. Los productos de centro de datos, ISP, residenciales y móviles pueden venderse por tráfico. La rotación, la posibilidad de conservar una IP durante una sesión y el uso exclusivo de una dirección son propiedades independientes del producto. Pagar más GB no prolonga una sesión que tiene su propio límite temporal ni restablece una salida no disponible.

Elige el acceso necesario antes de comparar tarifas. Para probar un proceso de compra regional, el producto útil debe proporcionar una IP aceptada en la ubicación requerida y mantener la sesión operativa hasta terminar la compra. Una cuota más barata que no pueda hacerlo no cumple la tarea. A la inversa, comprar una red más cara no aporta una ventaja automática cuando la más sencilla ya funciona de forma fiable.

La cuota tampoco dice nada sobre la velocidad de entrega. El volumen determina cuánto puede pasar; el caudal, a qué velocidad pasa; la simultaneidad, cuánto trabajo puede estar activo a la vez. Un saldo grande no compensa una ruta demasiado lenta para terminar una tarea con plazo estricto.

Cómo un trabajo completado se convierte en tráfico de pago

Empieza por la operación completa. Un programa puede obtener primero una lista de documentos, seguir los enlaces de descarga, recuperar los archivos y después repetir algunas descargas. Cada etapa puede utilizar la conexión de pago, aunque el archivo final contenga solo una copia de cada documento.

Pensemos en una tarea ilustrativa de archivo que guarda correctamente 300 documentos. Los totales de tráfico supuestos a continuación describen partes independientes de la ejecución que no se solapan. Son un ejemplo de contabilización, no mediciones de un sitio o proveedor concreto.

En unidades decimales, esa ejecución consume 0,308 GB. Con una tarifa supuesta de 4,50 $/GB, su cargo por tráfico es de 1,386 $, o aproximadamente 1,39 $ antes de otros cargos. La distinción útil está entre los 240 MB asociados a los documentos conservados y los 308 MB utilizados por el proceso. Eliminar las descargas redundantes ahorraría 48 MB sin reducir el archivo; eliminar la fase de búsqueda de documentos podría impedir que el trabajo funcionara.

Importa qué abarca la medición del proveedor. Las políticas publicadas de los servicios proxy suelen contabilizar tanto los datos enviados al sitio como los recibidos, incluidas las cabeceras y los cuerpos HTTP. Por eso, un trabajo con muchas subidas consume cuota aunque la respuesta del sitio sea breve. Las políticas varían respecto al tráfico de conexión, la sobrecarga del cifrado y los errores generados por el propio servicio. Un contador del contenido de los archivos descargados no basta para reconstruir cualquier factura.

Un túnel HTTPS puede transportar bytes cifrados que el proxy mide sin leer el contenido protegido. Para presupuestar, utiliza el método declarado por el proveedor y una ejecución medida; no existe un porcentaje universal de sobrecarga que añadir a cada solicitud. Aplicarlo a un contador que ya incluye esos bytes los contabilizaría dos veces.

Por qué GB y GiB muestran cifras distintas

Un gigabyte (GB) contiene 1 000 000 000 bytes. Un gibibyte (GiB) contiene 2³⁰ bytes: 1 073 741 824 bytes, o 1 024 MiB. GB utiliza potencias decimales; GiB, potencias binarias. Miden el mismo tipo de cantidad con unidades de distinto tamaño.

Por ejemplo, 32 GiB equivalen a 34,359738368 GB, aproximadamente 34,36 GB. La cifra expresada en GB es alrededor de un 7,37% mayor porque cada GiB contiene 1,073741824 GB. No ha aparecido tráfico adicional: ambas lecturas describen el mismo número de bytes. Una cuota de 32 GB, a su vez, equivale aproximadamente a 29,80 GiB, de modo que igualar la cifra impresa no hace iguales dos cuotas.

Antes de comparar el contador de una aplicación con el uso facturado, convierte ambos valores a la misma unidad. Comprueba la definición del proveedor en lugar de fiarte de una etiqueta abreviada y después revisa qué abarca la contabilización. El redondeo es otra cuestión: una lectura abreviada del panel no revela la precisión utilizada para facturar.

Por qué el proceso de trabajo importa tanto como la página

La primera visita y las siguientes son diferentes

Una primera visita puede descargar los recursos necesarios para mostrar y utilizar un sitio. Una visita posterior en el mismo navegador puede reutilizar algunos recursos locales, mientras que un perfil nuevo puede tener que obtenerlos otra vez. Así, la forma de iniciar y reutilizar las sesiones del navegador pasa a formar parte del modelo de tráfico.

La caché puede producir distintos resultados. Puede utilizarse una copia local vigente sin volver a descargar ese recurso. Una copia caducada puede requerir una solicitud condicional; una respuesta 304 Not Modified permite reutilizar el contenido guardado, pero el intercambio de validación sigue utilizando la red. Un recurso modificado o no reutilizable exige una transferencia nueva. Conservar un perfil no garantiza que todos los recursos queden en caché.

En un trabajo de supervisión, los recursos en caché pueden ser útiles. En una prueba de la experiencia de un visitante nuevo, pueden invalidar la prueba. Mide en las condiciones que la tarea requiere realmente. Una visita repetida barata no es una estimación sólida para miles de primeras visitas independientes.

El formato de salida también puede inducir a error. Hacer una captura local crea una imagen a partir de contenido ya cargado; por sí solo, no envía la captura de vuelta a través del proxy. Subir esa imagen mediante el proxy sería otra transferencia. Un navegador alojado de forma remota o una API de capturas pueden tener otro modelo de cobro, de modo que el tamaño de su salida no debe tratarse como el tráfico de un navegador local habitual.

Las descargas y el vídeo necesitan estimaciones diferentes

En una tarea de transferencia de archivos, el tamaño de los documentos, la detección de duplicados y la posibilidad de reanudar interrupciones suelen dominar el consumo. Para una prueba de vídeo, la duración y la tasa de bits son más útiles que el número de páginas. La página inicial puede ser pequeña mientras el reproductor sigue obteniendo contenido multimedia durante toda la prueba.

Supongamos que una prueba recibe una media de 6 megabits por segundo de datos multimedia durante 18 minutos. Dividir entre ocho convierte bits en bytes: 6 × 1 080 ÷ 8 = 810 megabytes, o 0,81 GB. Repetir esa prueba completa desde 12 ubicaciones transferiría 9,72 GB solo de contenido multimedia. Es una carga supuesta; la interfaz del reproductor, las demás solicitudes y la sobrecarga contabilizada se añaden aparte. La calidad adaptativa y el almacenamiento en búfer pueden cambiar la transferencia real.

Bajar la calidad de reproducción solo supone un ahorro si la prueba sigue respondiendo a su pregunta. Una comprobación breve de que un vídeo se inicia puede utilizar un período de observación corto. Una prueba de reproducción sostenida en alta calidad necesita recibir suficiente contenido de ese flujo para evaluarlo. Las pruebas necesarias determinan qué datos pueden omitirse.

Estas diferencias explican cuándo encaja la tarificación por tráfico. Las comprobaciones regionales breves y el acceso intermitente a un grupo útil pueden necesitar pocos datos. Las pruebas multimedia continuas o las descargas grandes repetidas pueden consumir rápidamente la misma cuota. Ambas son técnicamente posibles con un producto adecuado; su coste depende de la cantidad de trabajo, de su calendario y de las alternativas disponibles.

Elabora una previsión a partir de los distintos trabajos

Define qué significa completar la tarea antes de medirla. Una tarea documental satisfactoria puede requerir un archivo legible con el identificador esperado; una prueba regional puede exigir una interacción completada y un resultado registrado. Una conexión satisfactoria o un estado HTTP, por sí solos, no demuestran que el trabajo esté completo.

Haz una prueba piloto con las ubicaciones, los ajustes de sesión, el software y el nivel de actividad paralela previstos. Separa sus credenciales o informes de uso de otros trabajos ajenos. Registra el cambio de uso durante un período coincidente, teniendo en cuenta el retraso de los informes del proveedor, y cuenta las tareas completadas además de los intentos. Si la actividad en segundo plano forma parte del funcionamiento normal, inclúyela o mídela por separado en lugar de excluirla sin indicarlo.

Pondera los distintos tipos de operación

Una previsión útil conserva la combinación esperada. Supongamos que una prueba piloto proporciona las siguientes medias supuestas, que ya incluyen las solicitudes y los reintentos habituales necesarios para cada operación completada. Cada operación prevista pertenece a una sola categoría.

Con la misma tarifa supuesta de 4,50 $/GB, el cargo por tráfico previsto es de 67,986 $, aproximadamente 67,99 $. Las comprobaciones multimedia suponen menos de una de cada trece operaciones, pero casi el 60% del tráfico. Por eso, optimizar las comprobaciones posteriores, mucho más numerosas, puede tener menos efecto que modificar adecuadamente la prueba multimedia.

El cálculo general es la suma del número de tareas de cada tipo multiplicado por su tráfico medio medido. Añade las actividades iniciales o compartidas medidas por separado solo si quedan fuera de esas medias. Del mismo modo, los reintentos ya presentes en la prueba piloto no deben añadirse una segunda vez mediante un multiplicador de fallos.

Prueba qué puede cambiar la previsión

Una media solo es útil mientras el trabajo siga siendo comparable. Pasar a perfiles nuevos de navegador puede eliminar el ahorro de la caché. Una ubicación distinta puede recibir otra página o flujo multimedia. Un período de observación más largo puede recopilar más datos en segundo plano. Vuelve a comprobar la categoría afectada tras estos cambios en lugar de aplicar la media anterior a todo el proyecto.

Prueba también una ejecución menos favorable, pero plausible, además de la habitual: documentos mayores, sesiones nuevas o un período con más interrupciones. Deja visibles sus supuestos. Una reserva derivada de esas condiciones informa más que un porcentaje sin explicar añadido a todos los presupuestos.

Para elegir entre servicios adecuados, convierte cada prueba en gasto para la misma carga completada. Incluye el tráfico realmente consumido y cualquier compromiso de compra inevitable. Un precio bajo por GB puede ser útil, pero no resuelve una comparación si un servicio necesita un número diferente de intentos o no puede terminar las sesiones necesarias.

Ajusta la compra al calendario de trabajo

La previsión anterior estima el consumo. El importe que debes pagar puede ser distinto porque el producto vende tráfico en paquetes, exige una suscripción o añade un cargo de acceso independiente. Lee la oferta como una compra completa: qué se pone a tu disposición, en qué fechas y qué pago autoriza a seguir utilizándolo.

Un problema ilustrativo de calendario muestra por qué importan las fechas. Un proyecto necesita 8 GB antes de una renovación de facturación y 28 GB después. Una cuota mensual hipotética de 30 GB que cuesta 90 $, sin acumulación ni otros cargos, exige dos pagos mensuales: 180 $. Un saldo hipotético sin caducidad, vendido en bloques de 20 GB a 80 $, exige dos bloques: 160 $, y deja 4 GB disponibles. Se supone que ambos sistemas proporcionan un acceso equivalente. La tarifa mensual anunciada de 3 $ es inferior a la tarifa por bloques de 4 $, pero el proyecto, con ese calendario, requiere más dinero con la opción mensual.

Si trasladas ese mismo proyecto por completo a un único período de facturación, la comparación cambia: a la cuota de 30 GB le faltarían otros 6 GB, por lo que el precio de la recarga pasa a ser decisivo. Por eso no basta con multiplicar la demanda total por la tarifa mostrada más barata. Calcula el trabajo teniendo en cuenta las fechas de renovación, los incrementos de compra y cualquier caducidad del tráfico adicional.

La cuota restante solo ayuda con trabajos posteriores mientras siga siendo utilizable según las condiciones de la cuenta. Separa la caducidad del tráfico de la renovación de la suscripción y de cualquier requisito para mantener activa la cuenta. Si el tráfico base y las ampliaciones compradas tienen períodos de validez distintos, establece qué saldo se utiliza primero; la respuesta puede afectar a lo que caduca sin utilizarse.

La configuración elegida también forma parte del precio. Acceder a una red concreta, seleccionar ubicaciones con mayor precisión, reservar direcciones u otras funciones pueden cambiar el cargo. Si una tarifa utiliza un multiplicador de consumo, distingue los bytes físicos de las unidades facturadas. Aplica el multiplicador solo si la cifra de uso no lo incluye ya. Se necesita el mismo cuidado con los compromisos mínimos, la tarifa del tráfico adicional y los impuestos incluidos o excluidos del presupuesto.

Para un trabajo intenso y regular, compara toda la carga prevista con una opción adecuada de precio fijo. La alternativa debe cumplir los mismos requisitos de sitios, ubicaciones, sesiones, tráfico permitido y velocidad de entrega. Una cuota fija puede facilitar presupuestar transferencias grandes, mientras que el acceso por tráfico puede evitar mantener una capacidad que una tarea ocasional apenas utiliza. Ninguna de las dos unidades de facturación determina qué red funcionará mejor.

Recupérate de los fallos sin volver a comprar el mismo trabajo

La recuperación debe empezar por la parte pendiente más pequeña de la tarea. Si una ejecución ya ha guardado la mayoría de sus documentos, reiniciar toda la lista puede volver a pagar muchas descargas idénticas. Registra los identificadores completados, valida los archivos guardados y reanuda la cola pendiente. Así reduces el desperdicio sin cambiar la red proxy ni su precio.

Los archivos grandes interrumpidos necesitan un mecanismo más específico. Cuando el servidor y el cliente admiten solicitudes de rango, una descarga puede pedir la parte que falta. El cliente debe verificar que continúa la misma versión del archivo. Una respuesta 206 Partial Content proporciona un rango; una respuesta completa 200 OK no debe añadirse sin comprobar al fragmento existente. Poder reanudar puede ahorrar bytes transferidos, pero hay que implementarlo correctamente.

Los errores deben conducir a decisiones diferentes. Un fallo temporal de conexión puede justificar un reintento limitado. Un rechazo repetido, un inicio de sesión caducado, una cuota de cuenta agotada o una solicitud no válida necesitan otra respuesta. Repetir rápidamente un problema sin cambios puede gastar más sin avanzar. Para acciones que modifican una cuenta remota, establece si el primer intento se completó antes de enviarlo otra vez.

Que una tarea falle no borra los bytes ya transferidos. Una descarga interrumpida o una página de rechazo pueden consumir tráfico de pago; algunos servicios excluyen sus propios errores de conexión. Aplica las condiciones del producto proxy real en lugar de trasladarle una promesa de facturación por solicitud satisfactoria de una API de extracción.

La continuidad de la sesión también puede afectar a la recuperación. Sustituir una IP puede invalidar un proceso ligado a esa sesión y obligar a repetir pasos anteriores. Mantener una IP puede conservar la continuidad, pero no hace gratuitas las transferencias posteriores ni garantiza que la sesión del sitio web siga siendo válida. Guarda el progreso cuando sea posible y elige la acción de recuperación que resuelva el fallo.

Mantén una tarea en curso dentro de su presupuesto

Vigila el progreso junto con el consumo. Tres lecturas útiles son la cuota restante, el consumo reciente por minuto y las tareas completadas durante ese mismo intervalo. Si el uso aumenta mientras las tareas completadas se estancan, hay que revisar el trabajo antes de agotar el saldo. Si ambos aumentan proporcionalmente, puede que la aplicación simplemente esté haciendo más trabajo.

Por ejemplo, un saldo de 14 GB con un consumo sostenido de 0,35 GB por minuto proporciona unos 40 minutos de tráfico a ese ritmo. Es una estimación de planificación, no una garantía de detención: el ritmo puede cambiar, el uso mostrado puede llevar retraso y las transferencias activas pueden seguir terminándose. Compara ese tiempo con la cola pendiente y detén o reduce el trabajo nuevo con margen suficiente para terminar de forma segura.

Utiliza controles tanto en la compra como en la aplicación. En la cuenta, decide expresamente si el agotamiento detiene el acceso o autoriza otra compra o un cargo por exceso. En la aplicación, limita la cola, los intentos, las transferencias simultáneas y la duración de las sesiones abiertas. Una recarga automática mantiene financiada la conexión; no puede decidir si el trabajo sigue mereciendo ese gasto.

Las descargas largas y las sesiones multimedia necesitan una condición explícita de parada. Iniciar menos solicitudes nuevas puede dejar transferencias existentes que siguen consumiendo datos. La aplicación debe poder cancelar el trabajo en curso y cerrar las sesiones sin uso. Deja margen para los retrasos de los informes y de la aplicación de los límites, en lugar de tratar un umbral del panel como un interruptor instantáneo.

Cuando las cifras parezcan incorrectas, concilia una ejecución acotada. Haz coincidir la cuenta o el usuario, el intervalo temporal, la unidad y el registro de tareas. Las herramientas de red del navegador ayudan a localizar transferencias pesadas y a distinguir el tamaño transferido del tamaño descomprimido de los recursos, pero no abarcan necesariamente todos los procesos que utilizan la cuenta. Sigue el consumo de tráfico por separado de las compras, los traspasos de saldo y la caducidad; un cambio de saldo no siempre es una transferencia de red.

Después, realiza un cambio concreto y repite la misma tarea. Conserva el estado del navegador que necesita la prueba, evita descargas duplicadas, mantén la compresión admitida e impide que se inicien recursos irrelevantes cuando eso no rompa el proceso. El resultado debe mostrar tanto menos gasto como una finalización correcta. Reducir las transferencias eliminando las pruebas que la tarea pretendía recopilar deja el trabajo incompleto.