Análisis profundo: ¿Cómo funciona realmente una red de proxies residenciales? Arquitectura explicada

Esta es una pregunta que muchas personas en la industria de proxies se hacen. A continuación se presenta una explicación de la arquitectura aproximada detrás de cada red de proxies residenciales.

Para empezar, definamos qué es una red residencial: una red de pares capaces de enrutar paquetes hacia destinos.

En términos simples, una red de proxies residenciales enruta tus solicitudes de internet a través de los dispositivos de personas reales. Esos dispositivos se reclutan a través de aplicaciones a las que han dado su consentimiento, la red elige el mejor dispositivo para cada solicitud, y la respuesta regresa a ti como si hubieras navegado desde esa ubicación. La complejidad debajo de la superficie es lo que diferencia una red residencial rápida y fiable de una lenta e inestable.

1. El SDK

Los pares se reclutan a través de un SDK (Kit de desarrollo de software), que se integra en aplicaciones de consumidor. Basándose en el consentimiento del usuario, el SDK permite que la red de proxies residenciales enrute paquetes a través del dispositivo hacia destinos. Este es el elemento fundamental que facilita el uso de proxies para solicitudes a través de dispositivos residenciales reales.

2. Solicitudes estándar frente a solicitudes mediante proxy

Así es como se enruta una solicitud HTTPS estándar (L4 a L7). Los recuentos de RTT a continuación son acumulativos; cada capa se suma al total en curso y asume una conexión nueva:

Protocolo de enlace TCP (Paso: 1 RTT | Acumulativo: 1 RTT)

1. El usuario envía SYN al destino

2. El destino envía SYN-ACK al usuario

3. El usuario envía ACK al destino (los datos pueden viajar en este segmento final)

Costo del paso: 1 RTT, llevando el tiempo acumulativo en curso a 1 RTT. RFC 9293.

L5/L6: (Paso: 1 RTT para TLS 1,3 / 2 RTTs para TLS 1,2 | Acumulativo: 2 RTTs con TLS 1,3 / 3 RTTs con TLS 1,2)

1. El usuario envía ClientHello al destino

2. El destino envía ServerHello, EncryptedExtensions, Certificate, CertificateVerify, Finished al usuario

Costo del paso: 1 RTT para TLS 1,3 moderno (Acumulativo: 2 RTTs), o 2 RTTs para TLS 1,2 heredado (Acumulativo: 3 RTTs)

Por sí solo, TLS 1,3 es un protocolo de enlace de 1 RTT, y TLS 1,2 es de 2 RTT; los totales aquí son acumulativos e incluyen el viaje de ida y vuelta TCP, por lo que TLS 1,2 añade un RTT adicional completo (3 RTTs en total). TLS 1,3 también puede realizar reanudación 0-RTT en conexiones repetidas, con una compensación de repetición conocida.

L7: Capa de aplicación (Paso: 1 RTT | Acumulativo: 3 RTTs con TLS 1,3 / 4 RTTs con TLS 1,2)

1. El usuario envía solicitud + encabezados al destino

2. El destino envía respuesta + encabezados al usuario

Costo del paso: 1 RTT, llevando el tiempo final al primer byte de datos a 3 RTTs con TLS 1,3 o 4 RTTs con TLS 1,2

Una vez que se añade un proxy, este siempre agrega al menos un salto y algo de latencia: la ruta es más larga (usuario → proxy → destino, y vuelta), y el proxy añade su propio tiempo de procesamiento. Si también añade viajes de ida y vuelta adicionales depende del tipo de proxy.

Un proxy de terminación (un proxy de reenvío HTTP que usa CONNECT, o una puerta de enlace residencial que abre su propia conexión ascendente) sí los añade: el cliente primero realiza el protocolo de enlace con el proxy, y para HTTPS, la solicitud CONNECT y su respuesta «200 Connection Established» constituyen un viaje de ida y vuelta propio antes de que comience siquiera el protocolo de enlace TLS de extremo a extremo; luego el proxy realiza el protocolo de enlace hacia el destino.

Un reenviador transparente L3/L4 que no termina la conexión deja los protocolos de enlace de extremo a extremo y no añade viajes de ida y vuelta adicionales, solo la ruta más larga. En cualquier caso, más distancia e intermediarios adicionales significan más latencia, que es exactamente lo que el resto de este artículo trata de minimizar.

3. El problema del «embotellamiento»

Las redes residenciales son extremadamente complicadas porque hay muchos matices en el enrutamiento inteligente de solicitudes sin ralentizar la red.

Una buena analogía es la red de carreteras. Si demasiados coches toman una ruta, se congestiona. Lo ideal es cero congestión en cada ruta, algo que solo es alcanzable enrutando inteligentemente las solicitudes en función de la capacidad de cada ruta.

Cada par tiene una capacidad limitada antes de congestionarse. Las redes de proxies residenciales deben recopilar constantemente información sobre la capacidad a nivel de red de cada dispositivo para equilibrar la carga entre pares, satisfaciendo a los clientes sin congestionar los pares.

4. Optimizaciones del lado del proveedor

4a. DNS y centros de datos

La red residencial debería aprovechar el transporte de calidad de centro de datos donde sea posible. Por ejemplo, si un cliente en Europa occidental se enruta a través de pares de Europa oriental, la red debería usar un equilibrador de carga DNS para recibir esos paquetes en Europa occidental y transmitirlos a través de una ruta directa de centro de datos a la puerta de enlace más cercana, minimizando significativamente la sobrecarga de latencia.

4b. Optimización interna de capa 4

En los nodos de centro de datos de puerta de enlace, la red debería usar rutas directas y distribuir puertas de enlace globalmente para una buena cobertura. Entre puertas de enlace y pares, cada puerta de enlace debería mantener conexiones TCP precalentadas y usar cifrado TLS mutuo para proteger tanto el dispositivo como la puerta de enlace.

4c. Optimización externa de capa 4

El SDK puede mantener conexiones TCP precalentadas a destinos populares para ahorrar 1 RTT entre el par y el destino, ya que la capa de aplicación siempre puede reconstruirse sobre una conexión TCP existente.

4d. Configuraciones de parámetros

Los parámetros TCP se pueden ajustar en tiempo real para hacer la transmisión de paquetes más eficiente y reducir el uso de CPU/RAM por parte del SDK. Minimizar el consumo de recursos es fundamental. Si el SDK genera una experiencia negativa en el dispositivo del par, los editores rescindirán el contrato del SDK.

4e. Algoritmo de enrutamiento inteligente (basado en rendimiento)

Esta es la optimización más difícil, pero también la más efectiva. La red mantiene una base de datos en tiempo real en memoria en todas las puertas de enlace que puede consultarse al instante para responder: «¿Cuál es el dispositivo más adecuado para enrutar esta solicitud?»

Sin este algoritmo, cada segunda solicitud corre el riesgo de ser enrutada a un par lento o congestionado, y la red colapsará bajo una carga modesta.

4f. Algoritmo de limitación de IP (basado en reputación)

Las redes residenciales tienen interés en preservar la reputación de IP por destino. Si un tercio del grupo está en lista negra de los destinos A, B y C, los usuarios que apunten a esos destinos verán una tasa de error del 33 %. Al enrutar solo a través del 67 % restante y poner las IPs en lista negra en período de enfriamiento, la red ofrece una experiencia de cliente sustancialmente mejor.

Los algoritmos de limitación de IP son complejos de construir y mantener, pero generan mejoras significativas en la calidad de la red cuando se implementan correctamente.

5. Optimizaciones del lado del cliente

5a. Centros de datos

Los clientes deberían usar servidores en centros de datos ubicados lo más cerca posible de la puerta de enlace más cercana para su región de par objetivo. Para pares en los Países Bajos, los centros de datos de Ámsterdam son la opción lógica. También puedes hacer traceroute a la puerta de enlace y elegir el proveedor con la ruta más corta.

5b. DNS

Pasa el nombre de dominio en sí en lugar de su dirección IP resuelta. Esto permite que el par realice la resolución DNS, lo que puede resultar en un enrutamiento más eficiente. Incluye siempre el dominio en el campo SNI para que el protocolo de enlace TLS pueda completarse con éxito.

5c. Segmentación geográfica

Si bien la segmentación geográfica puede reducir la latencia hacia los pares objetivo, también tiene desventajas. Si una geografía específica no tiene suficientes pares para satisfacer tu concurrencia, las solicitudes fallarán o la latencia se disparará. Estudia los límites de tu geografía objetivo y monitorea sus métricas de salud antes de confiar exclusivamente en ella.

5d. Optimizaciones de L4 y sesión persistente

Por estándar de la industria, la autenticación se transmite a través de un encabezado Proxy-Authorization codificado en Base64, junto con parámetros de solicitud como la sesión persistente y la segmentación geográfica. Una vez que las solicitudes llegan a la puerta de enlace, estos parámetros se decodifican y se aplican.

Un usuario de proxy profesional mantiene una conexión por IP, monitorea la IP de salida cada 10 a 20 segundos para confirmar que el par sigue activo, y equilibra la carga entre pares en función del rendimiento. Por ejemplo, si un destino aplica límite de velocidad después de 50 solicitudes, retrocede a las 25 o 30, o rota una vez que se alcanza el límite.

El principio central: cuando hay pares insuficientes disponibles, maximiza la capacidad de cada par en términos de límites de velocidad, velocidad de red y gestión de congestión.

Publicado por Alon Levi, CEO de FlashProxy

Sobre el autor: Alon Levi es el CEO de FlashProxy y cuenta con amplia experiencia en infraestructura de proxies, arquitectura de red y tecnologías de enrutamiento de IP a gran escala.  

Conéctate en LinkedIn  ·  Contacto: [email protected]

Preguntas frecuentes

¿Por qué los proxies residenciales son más lentos que los proxies de centro de datos?

Los proxies residenciales enrutan solicitudes a través de dispositivos de consumidor reales en conexiones de internet doméstico. Esto añade al menos un salto de red adicional y, en el caso de puertas de enlace de terminación, viajes de ida y vuelta de configuración adicionales, además de las velocidades variables del acceso de banda ancha doméstico, lo que los hace más lentos que los proxies alojados directamente en centros de datos.

¿Qué es una sesión persistente en proxies?

Una sesión persistente mantiene las solicitudes enrutadas a través de la misma dirección IP durante un período establecido. Esto es útil para tareas que requieren continuidad de sesión, como mantener un estado de inicio de sesión o conservar un carrito de compras.

¿Por qué las IPs de proxy residencial se ponen en lista negra?

Cuando una IP residencial envía demasiadas solicitudes a un destino específico, ese sitio puede marcarla y bloquearla. Las redes que están sobresaturadas o mal gestionadas aceleran este proceso, reduciendo el grupo de IPs utilizable para todos los usuarios.

¿Qué es un par de proxy?

Un par de proxy es un dispositivo de consumidor real (teléfono, computadora o televisor inteligente) cuya conexión a internet se usa para enrutar tráfico de proxy, con el consentimiento del propietario del dispositivo, a través de un SDK integrado en una aplicación que han instalado.

Fuentes y referencias

• IETF RFC 9293, Protocolo de control de transmisión: https://datatracker.ietf.org/doc/html/rfc9293

• IETF RFC 8446, TLS 1,3 (protocolo de enlace 1-RTT; reanudación 0-RTT): https://datatracker.ietf.org/doc/html/rfc8446

• IETF RFC 5246, TLS 1,2 (protocolo de enlace 2-RTT): https://datatracker.ietf.org/doc/html/rfc5246

• IETF RFC 9110, Semántica HTTP (método CONNECT): https://datatracker.ietf.org/doc/html/rfc9110

• IETF RFC 6066, Indicación de nombre de servidor TLS (SNI): https://datatracker.ietf.org/doc/html/rfc6066

• IETF RFC 7235, Autenticación HTTP/1,1 (Proxy-Authorization): https://datatracker.ietf.org/doc/html/rfc7235

• MDN Web Docs, método HTTP CONNECT: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/CONNECT

• Cloudflare, latencia de proxy de reenvío: https://blog.cloudflare.com/how-we-think-about-zero-trust-performance/

• Centro de aprendizaje de Cloudflare, ¿Qué es SNI?: https://www.cloudflare.com/learning/ssl/what-is-sni/

• Ilya Grigorik, Redes de navegador de alto rendimiento: https://hpbn.co/