Límites de uso de los proxies

Qué puede limitar un proveedor

Algunos límites describen un recurso que consumes durante un período. Otros controlan la carga en un momento concreto o deciden si una conexión está permitida. Las distinciones siguientes son útiles incluso cuando un plan anuncia solo uno o dos de estos parámetros.

Un proveedor utiliza estas reglas para repartir la capacidad de red y los recursos de procesamiento, controlar los costes y restringir actividades no deseadas. Sus efectos son distintos: un límite de conexiones más alto permite más conexiones a la vez, mientras que permitir un destino bloqueado cambia qué tarea puede realizar el servicio. Cambiar una condición no modifica automáticamente las demás.

Conexiones simultáneas

Un límite de conexiones simultáneas establece cuántas conexiones pueden permanecer abiertas a la vez. Un navegador u otra aplicación pueden abrir varias conexiones para una sola tarea. Por eso, el número de pestañas, perfiles o hilos de un programa no indica exactamente cuánto de esta capacidad se está utilizando.

Las conexiones pueden permanecer abiertas entre solicitudes, y HTTP/2 puede transportar varias solicitudes por una conexión. Enviar menos solicitudes por minuto no libera necesariamente las conexiones ocupadas. El artículo sobre conexiones simultáneas explica qué consume esta capacidad y por qué se diferencia del número de solicitudes.

Los límites pueden afectarse entre sí. Si una respuesta grande tarda más en transferirse, su conexión puede permanecer ocupada más tiempo. Un programa que sigue iniciando trabajo puede alcanzar entonces su límite de conexiones, incluso con la misma frecuencia de solicitudes. Añadir trabajo paralelo en ese punto puede aumentar las esperas y los fallos sin incrementar el trabajo completado.

Sitios web y aplicaciones bloqueados

Un proveedor puede restringir el acceso a determinados sitios web, direcciones u operaciones. Un destino puede estar en su lista de bloqueo aunque el tráfico sea ilimitado y haya capacidad de conexión disponible. El acceso también puede variar entre productos del mismo proveedor. El artículo sobre sitios web y aplicaciones bloqueados explica cómo surgen estas listas y qué determina el acceso a un recurso concreto.

Una aplicación puede utilizar varios destinos: su página principal puede abrirse mientras una función independiente falla. El sitio web de destino también puede imponer sus propias restricciones aunque el proveedor de proxies permita el acceso. Para entender un fallo, identifica primero qué recurso no está disponible y qué parte rechazó la solicitud.

Puertos bloqueados

Acceder a un sitio web no demuestra que estén disponibles todos los servicios de red de ese mismo servidor. Un proveedor puede permitir el tráfico web y bloquear un puerto de envío de correo. Aquí importa el puerto de destino que solicita la aplicación. El artículo sobre puertos bloqueados explica en qué se diferencia del puerto utilizado para conectarse al propio proxy.

La compatibilidad con el transporte es otra parte de ese permiso. TCP y UDP son formas distintas de transportar datos, y tener acceso a un puerto TCP con un número concreto no demuestra que se pueda acceder al mismo puerto UDP. El producto debe admitir y permitir el transporte necesario. Más IP o una capacidad de conexiones mayor no aportan un permiso que falta.

Volumen de datos, velocidad de transferencia y número de solicitudes

Volumen de tráfico

El tráfico puede ser ilimitado o venderse con una cuota de datos, según el proveedor y el producto. Algunos proveedores venden una cantidad fija, como un paquete mensual en gigabytes. En ese caso, comprueba el período de validez, cuándo se renueva la cuota y si los datos no consumidos se acumulan. Estas reglas de contabilización se aplican a productos con una cuota de datos; no son una condición universal del acceso mediante proxies.

El tamaño de un resultado guardado no permite estimar el tráfico de forma fiable. Extraer un precio o un nombre de producto breves puede requerir descargar una página entera. Un navegador también puede solicitar imágenes, scripts y otros archivos. Los reintentos pueden volver a transferir datos. Medir la aplicación real ayuda a estimar la carga de red. Si el producto se factura por volumen de tráfico, comprueba también qué bytes transferidos contabiliza el proveedor.

Velocidad de transferencia

Un límite de velocidad de transferencia controla cuántos datos pueden pasar en una unidad de tiempo. Suele expresarse en bits por segundo, como Mbps, o en bytes por segundo, como MB/s. Un byte contiene ocho bits: 80 Mbps equivalen a 10 MB/s antes de la sobrecarga del protocolo. Son unidades de velocidad; una cuota mensual expresada en GB responde a otra pregunta.

Importa a qué se aplica la velocidad anunciada. Un puerto de servidor con una velocidad nominal determinada no demuestra que cada cliente o conexión reciban esa velocidad. Varias transferencias pueden compartir una misma capacidad. La velocidad real también depende de la ruta, del servidor de destino y de la conexión del propio cliente, de modo que el máximo declarado por el proveedor no garantiza ese resultado en cada descarga.

El tiempo de respuesta importa además de la velocidad de transferencia. Un servidor puede hacer esperar a una aplicación antes de enviar una respuesta pequeña, incluso cuando hay capacidad de sobra para transferir los bytes. Las descargas grandes son más sensibles a la velocidad sostenida; las cargas formadas por muchas solicitudes breves pueden verse más afectadas por los retardos de respuesta y por la frecuencia de solicitudes permitida.

Cuota y frecuencia de solicitudes

Una cuota de solicitudes especifica cuántas operaciones contabilizadas se incluyen. Un límite de frecuencia de solicitudes establece con qué separación pueden enviarse. Tener mucho saldo disponible no demuestra que pueda utilizarse entero en una ráfaga breve. Estos dos límites pueden existir de forma independiente, incluso en un producto que no factura por volumen de tráfico.

La operación contabilizada también necesita una definición clara. Un clic, una visita a una página, una solicitud HTTP y una tarea de extracción completada son sucesos distintos. Una visita puede generar muchas solicitudes HTTP; una tarea de API gestionada puede incluir varios intentos realizados por el proveedor. Que esos intentos consuman la cuota del cliente depende de las reglas de contabilización del producto.

Un límite de frecuencia también tiene una ventana temporal y reglas para las ráfagas breves. Dividir un límite por minuto entre sesenta da una media, pero no revela cómo trata el servicio un lote enviado de golpe. Repartir en el tiempo el trabajo permitido puede ajustarlo al límite de frecuencia sin cambiar su volumen total. Eso no recupera una cuota de solicitudes ya consumida.

Qué cuenta, IP o producto comparte el límite

Una cifra solo resulta útil cuando sabes quién la comparte. Un proveedor puede aplicar un límite a una cuenta, un pedido, una IP proxy individual, una IP de cliente autorizada u otro grupo definido. Por ejemplo, la velocidad total de transferencia asignada a una cuenta se comparte entre los programas que la utilizan. Dar a esos programas IP de salida distintas no crea una capacidad independiente para cada uno.

Pueden aplicarse varios niveles a la vez. Un servicio puede establecer un máximo para cada IP proxy y otro para todo el paquete. Repartir el trabajo entre las IP puede ayudar con la primera restricción, pero el total del paquete sigue vigente. Un límite asociado a la IP pública del cliente también puede compartirse entre varios dispositivos que acceden a Internet a través de esa dirección.

También importan las reglas del producto. Una conexión proxy directa, una API de extracción gestionada y otra red vendida por el mismo proveedor pueden tener cuotas y permisos distintos. La unidad que contabiliza una API puede ser una tarea o un resultado en lugar de una conexión de red. Lee los límites del producto que piensas utilizar, incluidos los ajustes específicos de tu cuenta.

Qué ocurre cuando se alcanza un límite

La respuesta del servicio depende de la regla. Al llegar a un máximo de transferencia, los datos pueden seguir circulando a una velocidad limitada. Con un límite de frecuencia de solicitudes, el trabajo que lo supera puede esperar o rechazarse. Al alcanzar un límite de conexiones, el servicio puede rechazar conexiones nuevas mientras las existentes siguen siendo utilizables. En productos con una cuota de tráfico o solicitudes, agotarla puede exigir una renovación o una compra adicional; las condiciones del proveedor determinan las opciones disponibles.

Por eso, la palabra «ilimitado» necesita un objeto: tráfico, solicitudes o conexiones ilimitados. Cada expresión describe un parámetro. Un plan con tráfico ilimitado puede seguir teniendo una velocidad finita y un límite de conexiones. Si un proveedor utiliza condiciones de uso razonable para cambiar una cuota tras un uso intenso y sostenido, esas condiciones también forman parte del plan. La palabra por sí sola no define todas las reglas.

Un mensaje explícito del proveedor es más útil que un fallo genérico. HTTP 429 significa que el servicio que responde considera excesivo el número de solicitudes según sus reglas. Identifica primero si la respuesta procede del servicio proxy o del destino. Un tiempo de espera agotado puede tener otras causas, como un destino lento o un problema de red. Las estadísticas de uso, los detalles del error y la hora del intento ayudan a distinguir un problema de cuota de un fallo en otro punto.

Reenviar repetidamente trabajo rechazado puede empeorar un problema de frecuencia y consumir más cuota. Un cambio útil actúa sobre la condición conocida: reduce el ritmo de envío, cierra conexiones que ya no necesitas, amplía la cuota agotada o confirma el permiso para acceder al destino. Una mejora general del paquete solo ayuda si modifica esa condición concreta.

Adapta los límites a la tarea completa

Empieza por el resultado necesario y el plazo. Como cálculo ilustrativo, supongamos que una tarea necesita 6 000 solicitudes HTTP en 30 minutos, con una respuesta media de 0,5 MB. Eso equivale a una media de 200 solicitudes por minuto y unos 3 GB de datos de respuesta en unidades decimales. La estimación excluye los datos salientes, los recursos adicionales del navegador y los reintentos. Deben incluirse si el trabajo real los genera y el servicio los contabiliza.

Estos totales aún no establecen la capacidad de conexiones que necesitas. Prueba la actividad paralela real de la aplicación y cuánto tiempo permanecen ocupadas las conexiones. Incluye otros programas que compartan el mismo límite y las ráfagas breves que se producen cuando varias tareas empiezan juntas. Mide por separado el volumen de datos, la frecuencia de solicitudes y las conexiones simultáneas; un contador no puede representar las tres cosas.

Utiliza en la prueba el producto y los destinos previstos, incluidas las funciones de la aplicación necesarias para terminar el trabajo. Una pequeña comprobación satisfactoria demuestra que una operación funcionó. Una ejecución representativa aporta información sobre la carga sostenida, los picos y los recursos que necesita la tarea completa. Reserva capacidad para la variación observada en la prueba en lugar de considerar la media un máximo seguro.

Si un requisito no está claro, proporciona a soporte una descripción concreta: el producto, los hosts de destino, los puertos de destino y el transporte, el volumen de datos previsto, la frecuencia de solicitudes, los picos de conexiones y el error exacto, si existe. Así, el proveedor puede comprobar la cuota o el permiso correspondiente. Lo que necesitas es que los límites declarados del servicio se ajusten a la carga que piensas ejecutar.