“Backconnect” é um daqueles termos que aparece na documentação de proxies sem nunca ser definido, geralmente porque quem escreveu já esqueceu que um dia ele foi estranho. Ele descreve uma arquitetura, e uma vez que você entende essa arquitetura o resto do produto faz sentido: por que existe apenas um endereço para configurar, por que sua segmentação vive em um nome de usuário, e por que seu cliente HTTP pode quebrar silenciosamente a rotação sem que nada pareça estar errado.
De onde vem o nome
O modelo mais antigo era uma lista. Você comprava um conjunto de proxies e recebia um arquivo de endereços e portas, e seu código se conectava diretamente a cada um deles. Gerenciá-los era problema seu: quais estavam ativos, quais estavam bloqueados em qual alvo, como distribuir a carga entre eles, o que fazer quando a lista mudava.
O backconnect inverte isso. Você se conecta a um único endereço de gateway, e o gateway se conecta de volta através de um dos muitos nós de sua rede em seu nome. Você nunca descobre o endereço de saída com antecedência e nunca gerencia uma lista, porque a decisão de roteamento acontece do lado do provedor no momento da requisição. Essa é a ideia inteira: uma porta de entrada estável, muitas portas de saída rotativas.
Na prática, “backconnect proxy”, “proxy rotativo” e “gateway proxy” são usados hoje de forma mais ou menos intercambiável, com backconnect enfatizando a arquitetura e rotação enfatizando o comportamento que ela produz.
O que acontece em uma única requisição
Concretamente, quando seu cliente envia uma requisição através de um gateway backconnect:
- Seu cliente abre uma conexão com o gateway,
p.shifter.io:443, e se autentica com um nome de usuário e senha. - O gateway analisa seu nome de usuário, que carrega mais do que identidade. Quaisquer flags de segmentação para país, região, cidade ou ASN, e qualquer identificador de sessão e TTL, são codificados ali.
- Ele seleciona um nó de saída que corresponda a essas restrições a partir do pool atualmente disponível. Disponível é a palavra-chave, já que o pool é uma população que se renova continuamente, como abordado em como os provedores constroem e renovam pools.
- Ele encaminha sua requisição através daquele nó, de modo que o alvo veja o endereço residencial do nó em vez do seu ou do gateway.
- A resposta retorna pelo mesmo caminho.
Se você forneceu um identificador de sessão, o gateway lembra o mapeamento e roteia requisições subsequentes que carreguem esse identificador através do mesmo nó até que o TTL expire ou o nó caia. Se você não forneceu, a próxima requisição recebe uma saída selecionada de forma independente.
É por isso que a segmentação vive no nome de usuário. Existe apenas um endpoint, então as instruções por requisição precisam viajar no único campo por requisição que o protocolo de proxy oferece antes que o túnel seja estabelecido.
# mesmo host e porta, comportamento diferente, expresso inteiramente no nome de usuário
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/jsonO que isso muda no seu código
Três consequências práticas decorrem dessa arquitetura, e a primeira causa mais confusão do que qualquer outra coisa neste produto.
A rotação acontece por conexão, não por requisição. A saída é escolhida quando o túnel com o gateway é estabelecido. Clientes HTTP modernos mantêm conexões ativas e as reutilizam, então se seu cliente envia dez requisições por uma conexão reutilizada, todas as dez saem pela mesma saída, e parece exatamente que a rotação está quebrada. Não está: seu cliente está fazendo o que foi projetado para fazer. A correção e o diagnóstico estão em IP não rotacionando, e a versão curta é que um loop com curl em processos separados vai rotacionar enquanto um objeto de sessão compartilhado não vai.
Não há lista de IPs para gerenciar, nem IP para culpar. A saúde é uma propriedade de uma rota, ou seja, alvo mais geografia, e de uma sessão, em vez de um endereço que você poderia adicionar a uma lista de bloqueio. Isso reformula completamente o monitoramento e o tratamento de falhas, conforme monitoramento de saúde de proxy em escala.
A configuração é estática, o comportamento é dinâmico. O host e a porta nunca mudam, então trocar uma tarefa de saídas rotativas nos EUA para saídas fixas na Alemanha é uma mudança de string em vez de um redeploy. É isso que torna a coleta multi-mercado uma questão de configuração em vez de um projeto de infraestrutura.
Backconnect versus o modelo de lista de portas
O modelo mais antigo ainda existe, e a comparação é útil porque explica por que o setor migrou.
Com uma lista de portas você conhecia seus endereços, o que soa como uma vantagem e na maior parte das vezes não é: você herdava o trabalho de verificação de disponibilidade, distribuição de carga e substituição, e sua capacidade era um número fixo de portas em vez de algo que se ajustava à demanda. O preço seguia o mesmo formato, por porta em vez de por unidade de trabalho, que é o modelo discutido em por que a era por porta acabou.
Com o backconnect você abre mão de conhecer a saída com antecedência e ganha não ter que gerenciar uma. A capacidade se torna uma questão de largura de banda e concorrência em vez de quantas portas você comprou, e a rotação é um parâmetro em vez de uma implementação que você mesmo escreve.
Onde o formato mais antigo ainda vence é quando você genuinamente precisa que o mesmo endereço persista, que é para o que existem os proxies estáticos de ISP, conforme ISP versus residencial.
Sessões fixas dentro de um gateway backconnect
Vale entender as sessões fixas pelo que elas são: um mapeamento que o gateway mantém, não uma alocação que você possui.
Você escolhe um identificador, o gateway o associa a um nó de saída, e requisições que carregam esse identificador seguem a mesma rota até o TTL acabar. Como o nó é um dispositivo doméstico real, ele também pode desaparecer antes do TTL, e é por isso que uma sessão fixa é um esforço de melhor esforço, não um contrato garantido. Código que trata uma mudança de endereço no meio de uma sequência como um erro em vez de um evento normal vai ser instável por razões que não têm nada a ver com o provedor. O comportamento é abordado em fixo versus rotativo e a renovação subjacente em como funciona a rotação.
Conclusão
Backconnect significa que você se conecta a um endpoint e ele se conecta de volta através de muitos, escolhendo a saída por requisição a partir do que estiver disponível no momento. Essa arquitetura é o motivo de existir um único host e porta, do país, cidade, sessão e TTL estarem codificados no nome de usuário, e de você nunca gerenciar uma lista de endereços. Ela também explica a fonte mais comum de confusão neste produto: a rotação é decidida quando uma conexão é estabelecida, então um cliente HTTP que reutiliza uma conexão reutilizada vai enviar todas as requisições pela mesma saída e parecer que está falhando em rotacionar. Trate as saídas como efêmeras, as sessões como um mapeamento em vez de uma alocação, e a saúde como uma propriedade de rotas, e a arquitetura para de te surpreender.
Esse gateway é toda a interface para proxies residenciais: um host, um par de credenciais, com rotação, geografia e comportamento de sessão expressos por requisição e cobrados por GB em vez de por porta. Se você é novo na terminologia, o glossário cobre o resto.