“Backconnect” es uno de esos términos que aparecen en la documentación de proxies sin definirse nunca, normalmente porque quienes la escriben han olvidado que alguna vez resultó desconocido. Describe una arquitectura, y en cuanto se ve la arquitectura el resto del producto cobra sentido: por qué solo hay una dirección que configurar, por qué la segmentación vive en un nombre de usuario, y por qué tu cliente HTTP puede romper la rotación silenciosamente sin que nada parezca ir mal.
De dónde viene el nombre
El modelo antiguo era una lista. Comprabas un conjunto de proxies y recibías un archivo de direcciones y puertos, y tu código se conectaba directamente a cada uno. Gestionarlos era tu problema: cuáles están activos, cuáles están bloqueados en qué destino, cómo repartir la carga entre ellos, qué hacer cuando la lista cambiaba.
Backconnect invierte esto. Te conectas a una única dirección de puerta de enlace, y la puerta de enlace se conecta hacia fuera a través de uno de los muchos nodos de su red en tu nombre. Nunca conoces la dirección de salida por adelantado y nunca gestionas una lista, porque la decisión de enrutamiento ocurre en el lado del proveedor en el momento de la solicitud. Esa es toda la idea: una puerta delantera estable, muchas puertas traseras rotativas.
En la práctica, “backconnect proxy”, “rotating proxy” y “gateway proxy” se usan hoy más o menos indistintamente, con backconnect enfatizando la arquitectura y rotation enfatizando el comportamiento que produce.
Qué ocurre en una sola solicitud
Concretamente, cuando tu cliente envía una solicitud a través de una puerta de enlace backconnect:
- Tu cliente abre una conexión a la puerta de enlace,
p.shifter.io:443, y se autentica con un nombre de usuario y una contraseña. - La puerta de enlace analiza tu nombre de usuario, que transporta más que identidad. Cualquier indicador de segmentación de país, región, ciudad o ASN, y cualquier identificador de sesión y TTL, se codifican ahí.
- Selecciona un nodo de salida que coincida con esas restricciones del conjunto actualmente disponible. Disponible es la palabra clave, ya que el conjunto es una población que se renueva continuamente, tal como se trata en cómo los proveedores construyen y renuevan los pools.
- Reenvía tu solicitud a través de ese nodo, de modo que el destino ve la dirección residencial del nodo en lugar de la tuya o la de la puerta de enlace.
- La respuesta vuelve por el mismo camino.
Si proporcionaste un identificador de sesión, la puerta de enlace recuerda la asignación y enruta las solicitudes posteriores que lleven ese identificador a través del mismo nodo hasta que el TTL expire o el nodo se caiga. Si no lo hiciste, la siguiente solicitud obtiene una salida seleccionada de forma independiente.
Por eso la segmentación vive en el nombre de usuario. Solo hay un endpoint, así que las instrucciones por solicitud tienen que viajar en el único campo por solicitud que el protocolo de proxy te ofrece antes de que se establezca el túnel.
# mismo host y puerto, comportamiento distinto, expresado enteramente en el nombre de usuario
curl -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/json
curl -x customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 https://ipinfo.io/json
curl -x customer-USERNAME-country-de-sid-abc123-ttl-600:PASSWORD@p.shifter.io:443 https://ipinfo.io/jsonQué cambia esto en tu código
De la arquitectura se derivan tres consecuencias prácticas, y la primera causa más confusión que cualquier otra cosa en este producto.
La rotación ocurre por conexión, no por solicitud. La salida se elige cuando se establece el túnel hacia la puerta de enlace. Los clientes HTTP modernos mantienen las conexiones activas y las reutilizan, así que si tu cliente envía diez solicitudes por una conexión reutilizada, las diez salen por la misma salida, y parece exactamente que la rotación está rota. No lo está: tu cliente hace lo que fue diseñado para hacer. La solución y el diagnóstico están en la IP no rota, y la versión corta es que un bucle de curl en procesos separados rotará mientras que un objeto de sesión compartido no lo hará.
No hay una lista de IPs que gestionar, ni una IP a la que culpar. La salud es una propiedad de una ruta, es decir de destino más geografía, y de una sesión, en lugar de una dirección que se pudiera añadir a una lista de bloqueo. Eso replantea por completo la monitorización y el manejo de fallos, según monitorizar la salud de los proxies a escala.
La configuración es estática, el comportamiento es dinámico. El host y el puerto nunca cambian, así que pasar un trabajo de salidas rotativas de EE. UU. a otras fijas de Alemania es un cambio de cadena de texto en lugar de un redespliegue. Eso es lo que convierte la recolección multimercado en un asunto de configuración en lugar de un proyecto de infraestructura.
Backconnect frente al modelo de lista de puertos
El modelo antiguo todavía existe, y la comparación es útil porque explica por qué la industria se desplazó.
Con una lista de puertos conocías tus direcciones, lo cual suena como una ventaja y en su mayor parte no lo es: heredabas el trabajo de comprobar la actividad, repartir la carga y hacer reemplazos, y tu capacidad era un número fijo de puertos en lugar de algo que se ajustara a la demanda. El precio seguía la misma forma, por puerto en lugar de por unidad de trabajo, que es el modelo que se trata en por qué la era del precio por puerto ha terminado.
Con backconnect renuncias a conocer la salida por adelantado y ganas no tener que gestionar una. La capacidad se convierte en una cuestión de ancho de banda y concurrencia en lugar de cuántos puertos compraste, y la rotación es un parámetro en lugar de una implementación que escribes tú mismo.
Donde la forma antigua todavía gana es cuando realmente necesitas que la misma dirección persista, que es para lo que existen los proxies ISP estáticos, según ISP frente a residencial.
Sesiones fijas dentro de una puerta de enlace backconnect
Vale la pena entender las sesiones fijas como lo que son: una asignación que mantiene la puerta de enlace, no una asignación que tú posees.
Eliges un identificador, la puerta de enlace lo asocia con un nodo de salida, y las solicitudes que lleven ese identificador siguen la misma ruta hasta que se agote el TTL. Como el nodo es un dispositivo doméstico real, también puede desaparecer antes de que lo haga el TTL, por lo que una sesión fija es de mejor esfuerzo en lugar de un arrendamiento. El código que trata un cambio de dirección a mitad de secuencia como un error en lugar de un evento normal será inestable por razones que no tienen nada que ver con el proveedor. El comportamiento se trata en fijas frente a rotativas y la renovación subyacente en cómo funciona la rotación.
La conclusión
Backconnect significa que te conectas a un único endpoint y este se conecta hacia fuera a través de muchos, eligiendo la salida por solicitud entre lo que esté disponible en ese momento. Esa arquitectura es la razón de que haya un único host y puerto, de que el país, la ciudad, la sesión y el TTL se codifiquen en el nombre de usuario, y de que nunca gestiones una lista de direcciones. También explica la fuente de confusión más común en este producto: la rotación se decide cuando se establece una conexión, así que un cliente HTTP que reutiliza una conexión en pool enviará todas las solicitudes por la misma salida y parecerá que no logra rotar. Trata las salidas como efímeras, las sesiones como una asignación en lugar de una reserva, y la salud como una propiedad de las rutas, y la arquitectura dejará de sorprenderte.
Esa puerta de enlace es toda la interfaz hacia los proxies residenciales: un host, un par de credenciales, con la rotación, la geografía y el comportamiento de sesión expresados por solicitud y facturados por GB en lugar de por puerto. Si eres nuevo en la terminología, el glosario cubre el resto.