Tarificación de proxies por solicitud

Por qué pagas

Pagas por el número de solicitudes que contabiliza el proveedor. Puede vender paquetes fijos o cobrar a medida que utilizas el servicio. Los precios suelen indicarse por mil o por un millón de solicitudes. Eso facilita comparar tarifas, pero no dice cuánto debes pagar al comprar: el paquete más pequeño puede contener más solicitudes.

La misma palabra, «solicitud», puede describir servicios diferentes. Un proxy habitual reenvía las solicitudes de tu aplicación a los sitios web y devuelve sus respuestas. Tu aplicación carga las páginas y extrae los datos. Con una API de recopilación de datos, el precio también puede incluir ejecutar un navegador, gestionar restricciones de acceso y preparar los resultados. Por eso no basta con comparar solo el precio de la solicitud; necesitas saber qué hace el servicio por ese precio.

Esta tarificación resulta cómoda para un trabajo con calendario. Puede que ya sepas cuántas páginas debes comprobar y con qué frecuencia. Después, averigua cuántas solicitudes consume cada comprobación. Así puedes estimar el paquete necesario para un mes y cuánto aumentará el uso si añades más páginas.

El tamaño de la respuesta no afecta necesariamente al precio. Si la tarifa cobra lo mismo por cada solicitud, obtener más datos en una respuesta puede costar lo mismo que obtener una respuesta pequeña. Aun así, comprueba qué incluye: puede haber límites de ancho de banda, tamaño de respuesta o tiempo de ejecución. El procesamiento adicional de datos también puede tener un cargo independiente.

Un paquete de solicitudes no determina cuántas direcciones IP recibes. Un servicio rotativo, por ejemplo, puede proporcionar acceso a un grupo de IP mediante un punto de conexión compartido. Los cambios de IP y la conservación de una dirección durante una sesión dependen de los ajustes del servicio. Un cambio de IP por sí solo no indica cuántas solicitudes se cobrarán.

Qué cuenta el servicio como una solicitud

Empieza por separar una solicitud de una conexión. Una solicitud HTTP pide a un sitio web que haga algo, como devolver una página o proporcionar datos. El sitio envía una respuesta. Que los datos viajen en ambos sentidos no significa, por sí solo, que deban descontarse dos solicitudes. Para eso tendría que existir una regla de facturación independiente.

Una conexión es el canal mediante el que la aplicación se comunica con el servidor. Varias solicitudes pueden utilizar la misma conexión. HTTP/1.1 permite reutilizarla, mientras que HTTP/2 permite ejecutar varios intercambios a la vez sobre ella. Por tanto, el número de solicitudes, las conexiones abiertas y las conexiones activas al mismo tiempo son medidas distintas.

HTTPS añade otro detalle. Al conectarse mediante un proxy HTTP, la aplicación suele enviar un comando CONNECT para crear un túnel hasta el sitio web. Las solicitudes posteriores viajan cifradas dentro de ese túnel. El proxy reenvía los datos, pero, en un uso habitual, no puede leer las solicitudes HTTP individuales. Un proxy SOCKS también proporciona una conexión con el destino; cada acción de la aplicación no necesita necesariamente una conexión nueva.

Por eso, algunos servicios utilizan «solicitud» para referirse a una conexión u otro suceso que su servidor proxy puede contar. Otros cuentan solicitudes HTTP individuales o llamadas a una API. Por tanto, el número de solicitudes de las herramientas de desarrollo del navegador puede ser distinto del consumo del panel del proveedor. Admitir HTTP, HTTPS o SOCKS5 no determina por sí solo la regla de recuento.

Antes de comprar un paquete grande, realiza una prueba pequeña. Registra cuántas tareas completa la aplicación y cuántas solicitudes descuenta el servicio. Utiliza la misma aplicación, protocolo y configuración que piensas utilizar después. Una prueba con un cliente HTTP sencillo no muestra el consumo de un navegador que también carga scripts y otros recursos de la página.

Por qué una página puede consumir varias solicitudes

Abrir una página suele requerir más que su documento principal. El navegador carga por separado estilos, scripts, imágenes y datos. Una página abierta puede seguir contactando con el servidor para recibir actualizaciones. Algunas de estas solicitudes también pasan por el proxy, según la configuración de la aplicación. Cómo se cobran depende de la tarifa.

Seguir una redirección añade una solicitud. Si el sitio responde que una página está en otra dirección, una aplicación configurada para seguir la redirección envía otra solicitud HTTP a esa dirección. Por eso, obtener un documento con un cliente sencillo y abrir la página completa en un navegador pueden consumir números distintos de solicitudes. El número de URL de tu lista todavía no dice cuántas solicitudes harán falta para procesarlas.

Una API puede funcionar al revés: una solicitud puede obtener muchos registros. En este ejemplo, un navegador hace cinco solicitudes para cargar una página de auriculares con su precio. Una aplicación utiliza el mismo proxy para llamar a la API de catálogo de ese comercio y obtiene cinco precios de productos en una solicitud. Se trata de la API del comercio, que proporciona los datos de productos. Si devuelve el catálogo por páginas, cada página necesita otra solicitud. A veces puedes aumentar los productos por respuesta, siempre que la API admita ese ajuste y devuelva todos los datos que necesitas.

Este enfoque ayuda a obtener más trabajo útil de un paquete. Cargar repetidamente páginas completas, obtener datos que ya has guardado y comprobar precios más a menudo de lo necesario pueden agotar rápidamente la cuota. Obtener varios productos por llamada, guardar los resultados y elegir una frecuencia de comprobación adecuada reduce las solicitudes necesarias para el mismo trabajo. Con la misma carga, la cuota puede durar más dentro del período de validez del paquete; también puedes utilizarla para comprobar más productos.

Resulta útil medir el consumo por tarea completada. Puede ser comprobar una página, obtener una lista completa o revisar un elemento que aparece después de ejecutar scripts. Mide toda la secuencia necesaria para alcanzar ese resultado. Incluye las cargas de páginas adicionales que es fácil pasar por alto si solo cuentas las URL iniciales.

Cuándo resulta útil este modelo de precios

Supervisión programada

El consumo de solicitudes puede vincularse a comprobaciones regulares. Una aplicación puede supervisar la disponibilidad de páginas, los cambios en anuncios públicos o los resultados de búsqueda de una región determinada. Conoces de antemano el número de destinos y la frecuencia de comprobación. Una prueba muestra cuántas solicitudes utiliza cada comprobación y ayuda a estimar el consumo mensual.

No es necesario comprobar todas las páginas con la misma frecuencia. Si la información cambia una vez al día, comprobarla cada minuto suele devolver los mismos datos. Las comprobaciones más frecuentes pueden reservarse para páginas en las que importe detectar rápidamente un cambio. Así mantienes el paquete disponible para las observaciones que necesitas.

Recopilación de datos mediante API y directorios

Aquí, el consumo depende de cómo facilita el sitio web su información. Si la lista ya contiene todo lo que necesitas, no hay motivo para abrir cada página de detalle. Las solicitudes adicionales pueden reservarse para elementos con datos incompletos o registros que han cambiado desde la ejecución anterior. Cuantos más datos necesarios obtengas en una llamada, menos solicitudes necesitará la recopilación completa.

También debes tener en cuenta qué hace el servicio. Una API de búsqueda puede devolver resultados analizados, mientras que un proxy habitual deja la descarga y el procesamiento a tu aplicación. Son cantidades de trabajo diferentes. Al comparar precios, comprueba qué contiene la respuesta y qué debes seguir haciendo por tu cuenta.

Auditorías de sitios y comprobaciones de navegador

Una auditoría técnica suele tener una secuencia clara: abrir una dirección, comprobar la respuesta, seguir una redirección si hace falta y guardar el resultado. Si la mayoría de las direcciones se tratan de forma parecida, una prueba facilita estimar el consumo. Una comprobación en navegador puede necesitar más solicitudes porque depende de scripts, imágenes y elementos operativos de la página.

Elige el método de comprobación según su propósito. Un cliente sencillo suele bastar para ver si una página responde. Probar un formulario de compra exige cargar lo que necesita para funcionar. Desactivar archivos necesarios reduce las solicitudes, pero la prueba deja de mostrar lo que experimenta el usuario.

Cómo afectan los errores y los reintentos al consumo

Una solicitud enviada no siempre devuelve los datos que necesitas. Un sitio puede devolver un error, una comprobación de acceso o una página diferente. Incluso HTTP 200 no garantiza que la aplicación haya recibido lo que quería: el estado indica éxito a nivel HTTP, mientras que el contenido de la respuesta necesita una comprobación independiente.

Las reglas de facturación de estas solicitudes varían. Algunos servicios cuentan las solicitudes enviadas. Otros cobran solo por respuestas que cumplen su definición de finalización satisfactoria. Una API gestionada puede incluir varios intentos internos de obtener los datos en el precio de una respuesta. Los modos o las funciones adicionales a veces cambian las reglas de facturación. Por tanto, «pago por solicitud» no significa automáticamente «pago solo por los datos obtenidos».

Un reintento de tu aplicación es distinto de uno dentro del servicio. Cuando la aplicación vuelve a enviar la solicitud, crea una solicitud nueva. Cuando el servicio reintenta el trabajo que ya has enviado, esos intentos pueden estar incluidos en su precio. Averigua qué intentos se descuentan de tu paquete.

Durante una prueba, registra tres cifras: tareas iniciadas, solicitudes cobradas y tareas completadas. La finalización depende del propósito. Para recopilar datos, la respuesta debe contener los campos necesarios e información suficientemente reciente. Para supervisar disponibilidad, detectar correctamente un sitio no disponible también es una comprobación completada.

Estas cifras ayudan a mostrar lo que cuesta realmente el trabajo. Las solicitudes baratas pueden resultar poco rentables si las respuestas necesitan constantemente otro intento o deben descartarse. Un servicio más caro puede hacer parte del trabajo por ti. Compara el gasto necesario para obtener el resultado requerido, incluido el trabajo que queda para tu aplicación.

Cómo calcular el paquete que necesitas

Primero, cuenta el trabajo previsto: cuántos destinos debes procesar y con qué frecuencia. Después añade las solicitudes necesarias más allá de la obtención normal, como los reintentos observados en las pruebas. Calcula por separado los grupos de páginas que se comporten de forma distinta. Separa también una reserva para el crecimiento de la carga para no añadir dos veces las mismas solicitudes adicionales.

Veamos un ejemplo ilustrativo. Una aplicación comprueba 150 URL cada 30 minutos durante 30 días. Supongamos que una comprobación normal utiliza una solicitud según la tarifa elegida y que los intentos adicionales aumentan el consumo un 5%. Todas las cifras y los precios de este ejemplo son hipotéticos; no son resultados de pruebas de un proveedor ni una tarifa de ProxyCompass.

El paquete elegido deja una reserva de 23 200 solicitudes. Puede cubrir el crecimiento de la carga mientras el paquete siga siendo válido. Los reintentos previstos ya están incluidos en los 10 800 intentos adicionales; esta reserva no debe volver a contabilizarse como consumo para esos mismos reintentos.

Supongamos que el paquete cuesta 10 $. Contiene 250 mil solicitudes, de modo que el precio nominal por mil es de 0,04 $. Pagas 10 $ por todo el paquete. Multiplicar el consumo previsto de 226 800 solicitudes por esa tarifa da 9,072 $. Es el valor de la parte utilizada, no el importe de compra: el paquete fijo sigue costando 10 $.

Ahora supongamos que, tras los intentos adicionales, la aplicación completa las 216 000 comprobaciones programadas. Mil comprobaciones completadas cuestan aproximadamente 0,0463 $: 10 $ ÷ 216 000 × 1 000. Este importe tiene en cuenta tanto las solicitudes adicionales como la reserva comprada. Si se completan menos comprobaciones, divide el gasto entre su número real.

El cálculo funciona igual para otras tareas. Con facturación por uso, multiplica las solicitudes facturables por la tarifa teniendo en cuenta cuántas solicitudes cubre esa tarifa. Con un paquete, utiliza su precio de compra completo. Después divide el gasto entre el número de tareas completadas. Si varios proyectos comparten un paquete, decide cómo repartir su coste entre ellos.

Comprueba también si la aplicación puede terminar a tiempo. Nuestro ejemplo requiere 7 200 comprobaciones al día, con una media de cinco inicios por minuto. Podrías lanzar las 150 comprobaciones a la vez cada media hora o repartirlas durante el intervalo. El consumo del paquete sería el mismo si cada comprobación necesitara el número supuesto de intentos, pero la carga al iniciarlas sería distinta. Un límite de conexiones o de frecuencia de solicitudes puede impedir que el primer calendario se ejecute como estaba previsto.

Cómo reducir las solicitudes innecesarias

Elimina las direcciones duplicadas y guarda los resultados a medida que avanza el trabajo. Después de un fallo, la aplicación debe continuar desde donde se detuvo. Si reinicia toda la lista cada vez, las páginas ya procesadas vuelven a consumir el paquete. Mantén un registro de las tareas completadas y de las que siguen pendientes.

Utiliza el método de carga necesario para obtener los datos. Si el texto requerido ya está en la respuesta del servidor, ejecutar un navegador puede ser innecesario. Si los datos aparecen solo tras ejecutar scripts, una descarga sencilla puede no bastar. En los servicios de recopilación de datos, el modo navegador y las funciones adicionales a veces consumen más créditos o tienen otra tarifa. Por tanto, un crédito no siempre equivale a una solicitud.

Reducir el tamaño de la respuesta no siempre ahorra solicitudes. Si el proveedor cuenta las llamadas HTTP, una respuesta breve puede consumir tantas solicitudes como una larga. Para reducir el recuento, puedes comprobar menos a menudo los datos que no cambian, reutilizar un resultado guardado u obtener varios registros en una llamada a una API. La información debe seguir siendo suficientemente reciente para tu tarea.

Limita los reintentos y considera por qué falló la solicitud. Si un sitio está temporalmente inaccesible o te pide bajar el ritmo, un reintento inmediato puede devolver la misma respuesta y gastar otra solicitud. Pausar o reducir la frecuencia puede ser más útil. Ten especial cuidado con las acciones que crean o modifican datos: comprueba el resultado del primer intento antes de enviarlo otra vez. Perder una respuesta no significa que el servidor no haya hecho nada.

Después de hacer cambios, comprueba tanto los resultados como el consumo. El número de solicitudes puede haber bajado porque la aplicación ha dejado de realizar parte del trabajo. Una reducción es útil cuando sigues obteniendo los datos necesarios, con la misma integridad y actualidad, utilizando menos solicitudes.

Qué comprobar al elegir una tarifa

Primero, asegúrate de que el servicio funciona con tus sitios web y tu aplicación. Importan el tipo de proxy, los países disponibles, el comportamiento de las sesiones y el acceso a las páginas necesarias mediante las IP proporcionadas. Después compara el trabajo incluido: ¿quién carga la página, ejecuta el navegador, extrae los datos y repite los intentos fallidos? Esto ayuda a explicar por qué dos servicios cobran precios diferentes por solicitud.

Comprueba el período de validez del paquete, las reglas de recarga y el tratamiento de las solicitudes no utilizadas. Un paquete grande con un precio menor por solicitud resulta rentable si puedes utilizarlo a tiempo para trabajo necesario. Si algunas solicitudes compradas quedan sin usar, el coste por tarea completada puede ser mayor que con un paquete pequeño.

Para comparar, elige páginas habituales de tu proyecto, incluidas las que suelen causar dificultades. Registra el tiempo empleado, las solicitudes utilizadas, los resultados obtenidos y la configuración de la aplicación. Esta prueba indicará el tamaño de paquete que necesitas, el coste aproximado del trabajo y si puedes terminarlo a tiempo.