Análise Profunda: Como Funciona uma Rede de Proxy Residencial? Arquitetura Explicada

Esta é uma pergunta que muitas pessoas na indústria de proxies fazem. Abaixo está uma explicação da arquitetura aproximada por trás de toda rede de proxy residencial.

Para começar, vamos definir o que é uma rede residencial: uma rede de peers capaz de rotear pacotes para destinos.

Em termos simples, uma rede de proxy residencial roteia suas solicitações de internet através dos dispositivos de pessoas reais. Esses dispositivos são recrutados por meio de aplicativos com os quais consentiram, a rede escolhe o melhor dispositivo para cada solicitação, e a resposta volta para você como se você tivesse navegado daquele local. A complexidade por baixo da superfície é o que separa uma rede residencial rápida e confiável de uma lenta e pouco confiável.

1. O SDK

Os peers são recrutados por meio de um SDK (Software Development Kit), que é integrado em aplicativos para consumidores. Com base no consentimento do usuário, o SDK permite que a rede de proxy residencial roteie pacotes através do dispositivo para destinos. Este é o elemento fundamental que facilita o proxy de solicitações através de dispositivos residenciais reais.

2. Solicitações Padrão vs. Solicitações com Proxy

Veja como uma solicitação HTTPS padrão é roteada (L4 a L7). As contagens de RTT abaixo são cumulativas; cada camada se adiciona ao total em execução e assume uma conexão nova:

TCP Handshake (Etapa: 1 RTT | Cumulativo: 1 RTT)

1. Usuário envia SYN para Destino

2. Destino envia SYN-ACK para Usuário

3. Usuário envia ACK para Destino (dados podem viajar neste segmento final)

Custo da Etapa: 1 RTT, trazendo o tempo cumulativo em execução para 1 RTT. RFC 9293.

L5/L6: (Etapa: 1 RTT para TLS 1,3 / 2 RTTs para TLS 1,2 | Cumulativo: 2 RTTs com TLS 1,3 / 3 RTTs com TLS 1,2)

1. Usuário envia ClientHello para Destino

2. Destino envia ServerHello, EncryptedExtensions, Certificate, CertificateVerify, Finished para Usuário

Custo da Etapa: 1 RTT para TLS 1,3 moderno (Cumulativo: 2 RTTs), ou 2 RTTs para TLS 1,2 legado (Cumulativo: 3 RTTs)

Por si só, TLS 1,3 é um handshake de 1-RTT, e TLS 1,2 é de 2-RTT; os totais aqui são cumulativos e incluem a volta TCP, portanto TLS 1,2 adiciona um RTT extra completo (3 RTTs no total). TLS 1,3 também pode fazer retomada 0-RTT em conexões repetidas, com uma desvantagem de replay conhecida.

L7: Camada de Aplicação (Etapa: 1 RTT | Cumulativo: 3 RTTs com TLS 1,3 / 4 RTTs com TLS 1,2)

1. Usuário envia Solicitação + Headers para Destino

2. Destino envia Resposta + Headers para Usuário

Custo da Etapa: 1 RTT, trazendo o tempo final até o primeiro byte de dados para 3 RTTs com TLS 1,3 ou 4 RTTs com TLS 1,2

Uma vez que você adiciona um proxy, sempre adiciona pelo menos um salto e alguma latência: o caminho é mais longo (usuário → proxy → destino, e volta), e o proxy adiciona seu próprio tempo de processamento. Quer ele também adicione round-trips depende do tipo de proxy.

Um proxy terminador (um proxy forward HTTP usando CONNECT, ou um gateway residencial que abre sua própria conexão upstream) adiciona: o cliente faz handshake com o proxy primeiro, e para HTTPS, a solicitação CONNECT e sua resposta «200 Connection Established» são uma volta antes do handshake TLS ponta a ponta começar, então o proxy faz handshake adiante para o destino.

Um encaminhador transparente L3/L4 que não termina a conexão deixa os handshakes ponta a ponta e não adiciona voltas extras, apenas o caminho mais longo. De qualquer forma, mais distância e mais intermediários significam mais latência, que é exatamente o que o resto deste artigo se trata de minimizar.

3. O Problema do «Congestionamento de Tráfego»

Redes residenciais são extremamente complicadas porque há muitos detalhes no roteamento inteligente de solicitações sem desacelerar a rede.

Uma boa analogia é a rede rodoviária. Se muitos carros pegam uma rota, ela fica congestionada. O ideal é zero congestionamento em cada rota, alcançável apenas roteando inteligentemente solicitações baseado na capacidade de cada rota.

Cada peer tem uma capacidade limitada antes de ficar congestionado. Redes de proxy residencial devem constantemente coletar informações sobre a capacidade de nível de rede de cada dispositivo para equilibrar carga entre peers, satisfazendo clientes sem congestionar os peers.

4. Otimizações do Lado do Provedor

4a. DNS e Datacenters

A rede residencial deve aproveitar o transporte de nível datacenter sempre que possível. Por exemplo, se um cliente na Europa Ocidental está roteando através de peers da Europa Oriental, a rede deve usar um balanceador de carga DNS para receber esses pacotes na Europa Ocidental e transmiti-los através de uma rota direta de datacenter para o gateway mais próximo, minimizando significativamente a sobrecarga de latência.

4b. Otimização Interna da Camada 4

Através de nós de datacenter de gateway, a rede deve usar rotas diretas e distribuir gateways globalmente para boa cobertura. Entre gateways e peers, cada gateway deve manter conexões TCP aquecidas e usar criptografia TLS mútua para proteger tanto o dispositivo quanto o gateway.

4c. Otimização Externa da Camada 4

O SDK pode manter conexões TCP aquecidas para destinos populares para economizar 1 RTT entre o peer e o destino, já que a camada de aplicação sempre pode ser reconstruída em cima de uma conexão TCP existente.

4d. Configurações de Parâmetros

Parâmetros de TCP podem ser ajustados em tempo real para tornar a transmissão de pacotes mais eficiente e reduzir o uso de CPU/RAM pelo SDK. Minimizar o consumo de recursos é crítico. Se o SDK criar uma experiência negativa no dispositivo do peer, os publishers descontinuarão o contrato do SDK.

4e. Algoritmo de Roteamento Inteligente (Baseado em Desempenho)

Esta é a otimização mais difícil, mas mais eficaz. A rede mantém um banco de dados em tempo real, em memória, em todos os gateways que pode ser consultado instantaneamente para responder: «Qual dispositivo é o melhor ajuste para rotear esta solicitação?»

Sem este algoritmo, a cada segundo há risco de a solicitação ser roteada para um peer lento ou congestionado, e a rede quebrará sob carga modesta.

4f. Algoritmo de Limitação de IP (Baseado em Reputação)

Redes residenciais têm interesse em preservar reputação de IP por destino. Se um terço do pool estiver na lista negra dos Destinos A, B e C, usuários visando esses destinos veem uma taxa de erro de 33 %. Roteando apenas através dos 67 % restantes e colocando IPs na lista negra em cooldown, a rede oferece uma experiência de cliente substancialmente melhor.

Algoritmos de Limitação de IP são complexos de construir e manter, mas geram melhorias significativas na qualidade da rede quando feitos corretamente.

5. Otimizações do Lado do Cliente

5a. Datacenters

Clientes devem usar servidores em datacenters localizados o mais próximo possível do gateway mais próximo para sua região de peer alvo. Para peers nos Países Baixos, datacenters de Amsterdã são a escolha lógica. Você também pode fazer traceroute para o gateway e escolher o provedor com o caminho mais curto.

5b. DNS

Passe o nome de domínio em si em vez do seu endereço IP resolvido. Isso permite que o peer execute resolução DNS, o que pode resultar em roteamento mais eficiente. Sempre inclua o domínio no campo SNI para que o handshake TLS possa ter sucesso.

5c. Direcionamento Geográfico

Embora o direcionamento geográfico possa reduzir latência para peers alvo, também tem desvantagens. Se uma geo específica não tiver peers suficientes para satisfazer sua simultaneidade, solicitações falharão ou latência aumentará. Estude os limites da sua geo alvo e monitore suas métricas de saúde antes de depender dela exclusivamente.

5d. Otimizações de L4 e Sessão Persistente

Conforme o padrão da indústria, autenticação é passada via um cabeçalho Proxy-Authorization codificado em Base64, junto com parâmetros de solicitação como sessão persistente e direcionamento geográfico. Uma vez que as solicitações chegam ao gateway, esses parâmetros são decodificados e aplicados.

Um usuário profissional de proxy mantém uma conexão por IP, monitora o IP de saída a cada 10 a 20 segundos para confirmar que o peer ainda está vivo, e equilibra carga entre peers baseado em desempenho. Por exemplo, se um destino aplica rate limit após 50 solicitações, recue em 25 a 30, ou faça rotação assim que o limite for atingido.

O princípio central: quando peers insuficientes estão disponíveis, maximize a capacidade de cada peer, em termos de limites de taxa, velocidade de rede e gerenciamento de congestionamento.

Publicado por Alon Levi, CEO da FlashProxy

Sobre o autor: Alon Levi é CEO da FlashProxy e tem experiência extensiva em infraestrutura de proxy, arquitetura de rede e tecnologias de roteamento de IP em larga escala.  

Conecte-se no LinkedIn  ·  Contato: [email protected]

Perguntas Frequentes

Por que proxies residenciais são mais lentos que proxies de datacenter?

Proxies residenciais roteiam solicitações através de dispositivos reais de consumidores em conexões de internet residencial. Isso adiciona pelo menos um salto de rede extra, e para gateways terminadores, round trips de configuração extras, em cima das velocidades variáveis de banda larga residencial, tornando-os mais lentos que proxies hospedados diretamente em datacenters.

O que é uma sessão persistente em proxies?

Uma sessão persistente mantém solicitações roteadas através do mesmo endereço IP por uma duração definida. Isso é útil para tarefas que exigem continuidade de sessão, como manter um estado de login ou manter um carrinho de compras.

Por que IPs de proxy residencial são colocados na lista negra?

Quando um IP residencial envia muitas solicitações para um destino específico, aquele site pode sinalizar e bloqueá-lo. Redes que estão supersaturadas ou mal gerenciadas aceleram este processo, reduzindo o pool de IP utilizável para todos os usuários.

O que é um peer de proxy?

Um peer de proxy é um dispositivo real de consumidor (telefone, computador ou smart TV) cuja conexão de internet é usada para rotear tráfego de proxy, com consentimento do proprietário do dispositivo, através de um SDK integrado em um aplicativo que ele instalou.

Fontes e Referências

• IETF RFC 9293, Transmission Control Protocol: https://datatracker.ietf.org/doc/html/rfc9293

• IETF RFC 8446, TLS 1,3 (handshake de 1-RTT; retomada 0-RTT): https://datatracker.ietf.org/doc/html/rfc8446

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

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

• IETF RFC 6066, TLS Server Name Indication (SNI): https://datatracker.ietf.org/doc/html/rfc6066

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

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

• Cloudflare, forward-proxy latency: https://blog.cloudflare.com/how-we-think-about-zero-trust-performance/

• Cloudflare Learning Center, What is SNI?: https://www.cloudflare.com/learning/ssl/what-is-sni/

• Ilya Grigorik, High Performance Browser Networking: https://hpbn.co/