Conexiones simultáneas

Qué es una conexión y cómo funciona

Una conexión de red es un enlace de comunicación que establecen dos programas para intercambiar datos. Por ejemplo, un navegador se conecta a un servidor web para solicitar una página y recibir su contenido. La conexión proporciona el recorrido para ese intercambio; una solicitud y una respuesta son mensajes que se envían a través de ella.

Pensemos en una conexión TCP convencional. La aplicación contacta con la dirección IP del servidor y con el puerto del servicio necesario. Ambas partes intercambian mensajes de control para establecer la conexión. Después, los datos viajan en pequeñas unidades llamadas paquetes. TCP supervisa la entrega, organiza la retransmisión de los datos perdidos y presenta los datos al receptor en el orden correcto. Ambas partes conservan información sobre el intercambio mientras existe la conexión.

Con un proxy TCP convencional, la aplicación se conecta primero al servidor proxy. El proxy establece una conexión independiente con el sitio web de destino y transmite datos entre las dos conexiones en ambos sentidos. Por tanto, mantiene la comunicación tanto con el cliente como con el destino.

La aplicación puede enviar una solicitud, recibir una respuesta y utilizar la conexión establecida para otro intercambio. Recibir una página, por ejemplo, no cierra necesariamente la conexión: el navegador puede conservarla para nuevas solicitudes al servidor. Cuando ya no se necesita, una de las partes la cierra; un error o un tiempo de espera agotado también pueden finalizarla. Hasta que se cierra, una conexión puede existir sin transferir datos continuamente.

Un programa puede mantener varias conexiones de este tipo a la vez: recibir datos por una, esperar una respuesta por otra y mantener una tercera preparada para una solicitud posterior. Son conexiones simultáneas. La cifra describe los canales de comunicación abiertos en ese momento, en lugar del número total de solicitudes realizadas desde que se inició el programa.

Qué mide el límite

Una conexión abierta ocupa una plaza de la capacidad correspondiente. Cuando se cierra y el servicio la retira del recuento, esa plaza vuelve a estar disponible. Es un límite sobre la actividad del momento, de modo que alcanzarlo no consume un saldo mensual de conexiones.

Cómo se contabilizan las conexiones dentro de la capacidad del cliente es una regla independiente del servicio. Los dos tramos de red del proxy no consumen automáticamente dos unidades de la cuota.

Los proveedores establecen estos límites porque las conexiones abiertas consumen recursos del servidor incluso cuando transfieren pocos datos. Una conexión que espera una respuesta sigue necesitando mantenimiento. Controlar su número ayuda al servicio a conservar suficiente capacidad para las cargas que ha acordado admitir.

A un mismo servicio se le pueden aplicar varios límites distintos:

Por tanto, el tráfico ilimitado no dice nada sobre el número de conexiones simultáneas. También puede existir un límite independiente sobre la rapidez con la que se abren conexiones nuevas. Abrirlas y cerrarlas rápidamente puede alcanzar ese límite aunque pocas permanezcan abiertas en cada momento.

Por qué el número de hilos no equivale al de conexiones

El número de hilos o procesos de una aplicación describe cómo organiza las tareas. No indica de forma fiable cuántas conexiones contabilizará el proxy. Una tarea puede contactar con varios servidores, y un script asíncrono puede gestionar muchas operaciones de red sin crear un hilo independiente del sistema operativo para cada una.

Tampoco cada solicitud HTTP exige una conexión nueva. Un cliente puede reutilizar una conexión existente, y HTTP/2 puede transportar varias solicitudes a la vez mediante una sola conexión. Por eso, el número de solicitudes es distinto del número de conexiones.

También importa la terminología del proveedor. Un límite descrito como «hilos» o «sesiones» puede referirse a conexiones abiertas o a solicitudes en procesamiento. Una sesión persistente, que mantiene la misma IP proxy para solicitudes relacionadas, no representa necesariamente una conexión de red. La definición útil es lo que el servicio contabiliza realmente.

¿Qué programas comparten la capacidad?

Un límite puede pertenecer a una cuenta, un paquete comprado, una IP proxy individual o una puerta de enlace concreta. Si el límite se aplica a la cuenta o al paquete, suma las conexiones de todos los programas y dispositivos que utilizan esa capacidad. Repartir una lista de IP entre varios ordenadores no crea una cuota independiente para cada ordenador.

Con un límite por IP, el reparto es distinto: una dirección muy utilizada puede alcanzar su máximo mientras otra tiene capacidad disponible. Trasladar parte del trabajo a la segunda dirección puede ayudar, siempre que el servicio no imponga además un límite compartido inferior. Un paquete puede tener tanto una capacidad total como asignaciones menores para usuarios o IP de cliente individuales.

El número de IP de cliente que pueden autenticarse es otro ajuste. Controla qué redes pueden acceder a los proxies, en lugar de cuántas conexiones pueden abrir esas redes. Varios dispositivos detrás de una IP pública pueden compartir tanto esa regla de acceso como la capacidad de conexiones que tiene asignada.

Cambiar la IP proxy que ve un sitio web no restablece la capacidad de conexiones de toda la cuenta. Del mismo modo, cambiar el nombre de una sesión persistente o el protocolo no proporciona automáticamente más capacidad. El límite sigue asociado a la cuenta, el paquete o el punto de conexión que utilice el proveedor para su recuento.

Por qué se acumulan las conexiones

Las conexiones se acumulan cuando se abren otras nuevas más deprisa de lo que se cierran las existentes. Puede ocurrir al cargar páginas, descargar archivos o ejecutar otras tareas de red en paralelo: algunas conexiones siguen transfiriendo datos o esperando una respuesta mientras la aplicación abre más. Todas se contabilizan a la vez y, juntas, pueden agotar el límite de conexiones del proxy.

Las respuestas lentas mantienen ocupadas las conexiones durante más tiempo. Si un programa sigue iniciando trabajo al mismo ritmo, se acumula trabajo sin terminar. Si, en cambio, mantiene fija la actividad paralela, un sitio más lento suele significar menos tareas completadas por minuto. Ambas situaciones pueden darse sin que cambie el paquete de proxies.

Las descargas largas y las conexiones que esperan a agotar su tiempo de espera pueden tener el mismo efecto. Por eso, un número elevado de conexiones abiertas puede coexistir con una velocidad de transferencia baja: gran parte del tiempo se pasa esperando en lugar de mover datos.

Algunas conexiones se mantienen abiertas deliberadamente entre solicitudes. Esto suele llamarse keep-alive. Evita establecer una conexión nueva cada vez, pero una conexión inactiva puede seguir ocupando una plaza si el servicio contabiliza las conexiones abiertas. Una conexión devuelta al grupo de conexiones de la aplicación está disponible para reutilizarse; no significa necesariamente que se haya cerrado en el proxy.

Otro problema es liberar las conexiones de forma incorrecta. Puede ocurrir tanto en software comercial como en scripts propios. Por ejemplo, el código puede empezar a leer una respuesta, encontrar un error e iniciar otra solicitud sin terminar ni cerrar la respuesta anterior. Si siguen abriéndose conexiones nuevas mientras las antiguas permanecen ocupadas, la aplicación puede agotar su capacidad sin realizar más trabajo útil. Por eso hay que comprobar la liberación tras errores y cancelaciones, no solo después de solicitudes satisfactorias.

Una liberación correcta permite al cliente reutilizar una conexión adecuada o cerrar una que ya no necesita. Los tiempos de espera impiden que las operaciones abandonadas esperen indefinidamente. Desactivar la reutilización en todas partes no es una solución general: añade trabajo de establecimiento de conexiones y puede aumentar el ritmo de conexiones nuevas. El objetivo es mantener un número controlado de conexiones reutilizables y liberar o cerrar correctamente las innecesarias.

Por qué parece que los proxies funcionan, dejan de funcionar y vuelven a funcionar

Los fallos intermitentes bajo carga son un motivo para comprobar pronto el límite de conexiones. Algunas direcciones proxy parecen funcionar mientras otras fallan; poco después, el patrón cambia. Desde la aplicación, puede parecer que distintas partes de la lista de proxies se desconectan continuamente.

Una explicación es que la capacidad compartida está llena. Las conexiones existentes pueden continuar, mientras los intentos de abrir más se rechazan o quedan esperando. A medida que se cierran las conexiones anteriores, algunos intentos nuevos consiguen pasar. Otros fallan cuando las plazas disponibles vuelven a llenarse. El resultado cambia por la competencia por una misma capacidad, en lugar de por un grupo fijo de IP averiadas.

A veces este comportamiento se describe como limitación del tráfico o throttling. Aquí, la restricción afecta a la admisión de conexiones nuevas; no reduce necesariamente la velocidad de todas las conexiones establecidas. La respuesta exacta depende del servicio: puede devolver un mensaje claro sobre el límite, rechazar una conexión o dejar que el cliente agote su tiempo de espera. No se garantiza una cola de espera.

Para comprobar esta explicación, compara los fallos con el número de conexiones y reduce temporalmente la actividad paralela de los programas que comparten la cuota. Si los fallos desaparecen cuando la actividad baja del límite y vuelven cuando se llena, el límite de conexiones es una causa probable. Interrupciones parecidas también pueden proceder del sitio de destino o de la red. Un tiempo de espera agotado o una respuesta HTTP 429, 502 o 503 no demuestran por sí solos que se haya alcanzado el límite de conexiones del proxy; importan el origen y el texto del error.

Cómo mantener el trabajo útil dentro del límite

Empieza por los sitios y las operaciones reales que necesita tu software. Aumenta la actividad paralela gradualmente y observa los resultados satisfactorios, los tiempos de respuesta y los picos de conexiones. Una prueba breve contra una página rápida puede no representar una ejecución completa con inicios de sesión, respuestas grandes y puntos de conexión más lentos.

1. Asigna un presupuesto compartido de conexiones a todos los programas. Deja margen para otras actividades y ráfagas breves. Si varios procesos utilizan el mismo paquete, configurar cada uno con toda la capacidad del paquete puede sobrecargar el servicio cuando se ejecutan juntos.
2. Controla tanto las tareas como las conexiones. Un grupo de conexiones guarda conexiones para reutilizarlas. Comprueba si el ajuste de tamaño es un límite estricto o solo el número que se conserva después; algunos clientes abren conexiones adicionales si no está activado un modo de espera. Mantén la liberación de respuestas y los tiempos de espera, también cuando una tarea falle.
3. Escalona los inicios y los reintentos. Iniciar todos los navegadores a la vez o repetir inmediatamente cada solicitud fallida crea otro pico. Utiliza un número limitado de reintentos con esperas crecientes y mantenlos dentro del mismo presupuesto de carga. Un tiempo de espera agotado tampoco demuestra que una acción enviada haya fallado, así que repetir una compra o una actualización exige cuidado.
4. Mide el trabajo completado. Más procesos solo son útiles mientras mejoran el rendimiento satisfactorio. Cuando sobre todo añaden esperas y errores, una configuración menor puede terminar antes la misma tarea. Si un panel promedia la actividad a lo largo del tiempo, los picos breves pueden ser menos visibles que en las marcas de tiempo de los errores de la aplicación.

En tareas de navegador, evitar descargas innecesarias también puede reducir la actividad de red. Bloquear imágenes o vídeo puede ayudar cuando la tarea no los necesita; eliminar scripts puede romper la propia operación. Valora el cambio según si la tarea prevista sigue completándose correctamente.

Cuándo ayuda un límite más alto

Más capacidad de conexiones resulta útil cuando la aplicación gestiona correctamente sus conexiones y la carga necesaria alcanza de forma continuada el máximo del proveedor. Puede permitir que más tareas se ejecuten juntas sin competir por la misma capacidad reducida.

La compra debe aumentar el límite que realmente se está alcanzando. Añadir IP puede ayudar con una restricción por IP si se reparte el trabajo entre ellas. Con un límite compartido del paquete, el paquete nuevo o el complemento deben aumentar esa capacidad compartida. Un aumento del número de IP, por sí solo, no demuestra que lo haga.

También existen otros máximos. El cliente puede tener un grupo de conexiones menor, el ordenador puede quedarse sin recursos de red o el destino puede limitar las solicitudes. Una conexión móvil individual también tiene su propio ancho de banda disponible, independientemente del número de conexiones proxy permitidas. Comprar más simultaneidad no elimina esas restricciones ni repara un script que sigue dejando conexiones sin liberar.

El objetivo práctico es disponer de margen suficiente para los picos normales de la carga y mantener pocos fallos. Una vez conseguido, una capacidad de conexiones adicional puede ser una mejora útil de capacidad en lugar de una forma de posponer la reparación de la aplicación.