Conexões simultâneas
Os proxies podem funcionar de forma confiável com uma carga de trabalho leve, mas começar a retornar erros quando mais processos de trabalho ou programas são executados juntos. Uma possível causa é exceder o número de conexões simultâneas permitidas.
Esse é um dos limites de uso dos proxies. Para entender o que ele controla e por que é atingido, primeiro precisamos explicar o que é uma conexão de rede e como ela funciona por meio de um proxy.
O que é uma conexão e como ela funciona
Uma conexão de rede é um vínculo de comunicação que dois programas estabelecem para trocar dados. Por exemplo, um navegador se conecta a um servidor web para solicitar uma página e receber seu conteúdo. A conexão fornece o caminho para essa troca; uma solicitação e uma resposta são mensagens enviadas por ela.
Considere uma conexão TCP convencional. A aplicação contata o endereço IP do servidor e a porta do serviço necessário. Os dois lados trocam mensagens de controle para estabelecer a conexão. Em seguida, os dados circulam em pequenas unidades chamadas pacotes. O TCP acompanha a entrega, providencia a retransmissão de dados perdidos e apresenta os dados ao destinatário na ordem correta. Os dois lados mantêm informações sobre a troca enquanto a conexão existe.
Com um proxy TCP convencional, a aplicação primeiro se conecta ao servidor proxy. O proxy estabelece uma conexão separada com o site de destino e repassa dados entre as duas conexões, nos dois sentidos. Portanto, ele mantém comunicação tanto com o cliente quanto com o destino.
A aplicação pode enviar uma solicitação, receber uma resposta e usar a conexão estabelecida para outra troca. Receber uma página, por exemplo, não necessariamente fecha a conexão: o navegador pode mantê-la para outras solicitações ao servidor. Quando ela deixa de ser necessária, um dos lados a fecha; um erro ou um tempo limite excedido também pode encerrá-la. Até ser fechada, uma conexão pode existir sem transferir dados continuamente.
Um programa pode manter várias conexões desse tipo ao mesmo tempo: recebendo dados por uma, aguardando uma resposta em outra e mantendo uma terceira pronta para uma solicitação posterior. Essas são conexões simultâneas. A contagem descreve os canais de comunicação abertos naquele momento, e não o total de solicitações feitas desde que o programa iniciou.
O que o limite mede
Uma conexão aberta ocupa uma vaga na franquia correspondente. Quando ela é fechada e o serviço a remove da contagem, essa vaga volta a ficar disponível. Esse é um limite de atividade atual; portanto, atingi-lo não esgota um saldo mensal de conexões.
A forma como as conexões são contabilizadas na franquia do cliente é uma regra separada do serviço. Dois trechos de rede no proxy não consomem automaticamente duas unidades da cota.
Os provedores definem esses limites porque conexões abertas consomem recursos do servidor mesmo quando transferem poucos dados. Uma conexão que aguarda uma resposta ainda precisa ser mantida. Controlar seu número ajuda o serviço a manter capacidade suficiente para as cargas de trabalho que se comprometeu a atender.
Vários limites diferentes podem se aplicar ao mesmo serviço:
| Limite | O que controla |
|---|---|
| Conexões simultâneas | Quantas conexões podem permanecer abertas ao mesmo tempo |
| Solicitações simultâneas | Quantas solicitações podem estar em andamento ao mesmo tempo |
| Solicitações por segundo | Com que frequência as solicitações podem ser enviadas ou processadas |
| Velocidade de transferência | Qual volume de dados pode circular por segundo |
| Franquia de tráfego | Qual volume de dados pode ser transferido em um período de cobrança |
Portanto, tráfego ilimitado não informa nada sobre o número de conexões simultâneas. Também pode haver um limite separado para a frequência de abertura de novas conexões. Abri-las e fechá-las rapidamente pode atingir esse limite mesmo quando poucas permanecem abertas em um dado momento.
Por que a contagem de threads não é igual à de conexões
O número de threads ou processos de trabalho em uma aplicação descreve como ela organiza as tarefas. Ele não informa de forma confiável quantas conexões o proxy contabilizará. Uma tarefa pode contatar vários servidores, e um script assíncrono pode gerenciar muitas operações de rede sem criar uma thread separada do sistema operacional para cada uma.
Nem toda solicitação HTTP exige uma nova conexão. Um cliente pode reutilizar uma conexão existente, e o HTTP/2 pode transportar várias solicitações ao mesmo tempo por uma única conexão. Por isso, a contagem de solicitações é diferente da contagem de conexões.
A terminologia do provedor também importa. Um limite descrito como “threads” ou “sessões” pode se referir a conexões abertas ou a solicitações em processamento. Uma sessão persistente com manutenção do IP (sticky session), que mantém o mesmo IP de proxy para solicitações relacionadas, não representa necessariamente uma conexão de rede. A definição útil é aquilo que o serviço realmente contabiliza.
Quais programas compartilham a franquia?
Um limite pode pertencer a uma conta, a um pacote comprado, a um IP de proxy individual ou a um gateway específico. Para um limite de conta ou pacote, some as conexões de todos os programas e dispositivos que usam aquela franquia. Dividir uma lista de IPs entre vários computadores não cria uma cota separada para cada computador.
Com um limite por IP, a distribuição é diferente: um endereço muito ocupado pode atingir seu teto enquanto outro tem espaço disponível. Transferir parte do trabalho para o segundo endereço pode ajudar, desde que o serviço não imponha também um limite compartilhado menor. Um pacote pode ter tanto uma franquia total quanto parcelas menores para usuários individuais ou IPs de clientes.
O número de IPs de clientes autorizados a se autenticar é outra configuração. Ela controla quais redes podem acessar os proxies, e não quantas conexões essas redes podem abrir. Vários dispositivos atrás de um só IP público podem compartilhar tanto essa regra de acesso quanto a parcela de conexões associada a ele.
Mudar o IP do proxy visto por um site não reinicia uma franquia de conexões que vale para toda a conta. Da mesma forma, mudar um nome de sessão persistente ou protocolo não oferece automaticamente mais capacidade. O limite continua associado à conta, ao pacote ou ao ponto de conexão que o provedor usa na contagem.
Por que as conexões se acumulam
As conexões se acumulam quando novas conexões são abertas mais rapidamente do que as existentes são fechadas. Isso pode acontecer durante o carregamento de páginas, o download de arquivos ou a execução de outras tarefas de rede em paralelo: algumas conexões ainda estão transferindo dados ou aguardando uma resposta enquanto a aplicação abre outras. Essas conexões são contabilizadas na franquia ao mesmo tempo e, juntas, podem esgotar o limite de conexões do proxy.
Respostas lentas mantêm as conexões ocupadas por mais tempo. Se um programa continuar iniciando novos trabalhos no mesmo ritmo, o trabalho inacabado se acumulará. Se, em vez disso, ele mantiver a atividade paralela em um nível fixo, um site mais lento geralmente significará menos tarefas concluídas por minuto. As duas situações podem ocorrer sem nenhuma mudança no pacote de proxies.
Downloads longos e conexões que aguardam até o tempo limite podem ter o mesmo efeito. Por isso, um grande número de conexões abertas pode coexistir com uma velocidade de transferência baixa: boa parte do tempo é gasta esperando, em vez de movimentando dados.
Algumas conexões são mantidas abertas deliberadamente entre solicitações. Isso costuma ser chamado de keep-alive. Isso evita estabelecer uma nova conexão a cada vez, mas uma conexão ociosa ainda pode ocupar uma vaga se o serviço contabilizar conexões abertas. Uma conexão devolvida ao pool da aplicação está disponível para reutilização; ela não foi necessariamente fechada no proxy.
Um problema separado é a liberação incorreta de conexões. Isso pode ocorrer tanto em softwares prontos quanto em scripts personalizados. Por exemplo, o código pode começar a ler uma resposta, encontrar um erro e iniciar outra solicitação sem terminar ou fechar a resposta anterior. Se novas conexões continuarem sendo abertas enquanto as antigas permanecem ocupadas, a aplicação poderá esgotar sua franquia sem realizar mais trabalho útil. Esse é um motivo para verificar a liberação após erros e cancelamentos, e não apenas após solicitações bem-sucedidas.
A liberação correta permite ao cliente reutilizar uma conexão adequada ou fechar uma de que não precisa mais. Os tempos limite evitam que operações abandonadas esperem indefinidamente. Desativar a reutilização em todos os casos não é uma solução geral: isso acrescenta trabalho de estabelecimento de conexões e pode aumentar a frequência de novas conexões. O objetivo é manter um número controlado de conexões reutilizáveis, liberando ou fechando corretamente as desnecessárias.
Por que os proxies parecem funcionar, parar e voltar a funcionar
Falhas intermitentes sob carga são um motivo para verificar o limite de conexões logo no início. Alguns endereços de proxy parecem funcionar enquanto outros falham; pouco depois, o padrão muda. Do ponto de vista da aplicação, pode parecer que diferentes partes da lista de proxies ficam saindo do ar.
Uma explicação é que a franquia compartilhada está cheia. As conexões existentes podem continuar enquanto as tentativas de abrir mais conexões são rejeitadas ou ficam esperando. À medida que as conexões anteriores são fechadas, algumas novas tentativas passam. Outras falham quando as vagas disponíveis se esgotam novamente. A mudança no resultado vem da disputa pela mesma franquia, e não de um grupo fixo de IPs com defeito.
Esse comportamento às vezes é chamado de throttling. Aqui, a restrição afeta a admissão de novas conexões; ela não necessariamente reduz a velocidade de cada conexão já estabelecida. A resposta exata depende do serviço: ele pode retornar uma mensagem clara sobre o limite, recusar uma conexão ou deixar o cliente atingir o tempo limite. Uma fila de espera não é garantida.
Para verificar essa explicação, compare as falhas com a contagem de conexões e reduza temporariamente a atividade paralela nos programas que compartilham a cota. Se as falhas pararem quando a atividade cair abaixo do limite e voltarem quando ele se preencher novamente, o teto de conexões será uma causa provável. Interrupções semelhantes também podem vir do site de destino ou da rede. Um tempo limite excedido ou uma resposta HTTP 429, 502 ou 503, isoladamente, não comprova que o limite de conexões do proxy foi atingido; a origem e o texto do erro importam.
Como manter o trabalho útil dentro do limite
Comece pelos sites e operações reais que seu software precisa executar. Aumente a atividade paralela aos poucos e observe os resultados bem-sucedidos, os tempos de resposta e os picos de conexões. Um teste breve em uma página rápida pode não representar uma execução completa que envolva logins, respostas grandes e pontos de conexão mais lentos.
- Defina um orçamento compartilhado de conexões para todos os programas. Deixe espaço para outras atividades e rajadas curtas. Se vários processos usarem o mesmo pacote, configurar cada processo com a franquia total do pacote poderá sobrecarregar o serviço quando eles forem executados juntos.
- Controle tanto as tarefas quanto as conexões. Um pool de conexões armazena conexões para reutilização. Verifique se sua configuração de tamanho é um limite rígido ou apenas o número mantido posteriormente; alguns clientes abrem conexões extras a menos que um modo de espera esteja habilitado. Mantenha a liberação de respostas e os tempos limite, inclusive quando um trabalho falhar.
- Distribua as inicializações e as novas tentativas ao longo do tempo. Iniciar todos os navegadores de uma só vez ou repetir imediatamente cada solicitação que falhou cria outro pico. Use um número limitado de novas tentativas, com intervalos crescentes, e mantenha-as dentro do mesmo orçamento de carga de trabalho. Um tempo limite excedido também não comprova que uma ação enviada falhou; por isso, repetir uma compra ou atualização exige cuidado.
- Meça o trabalho concluído. Mais processos de trabalho só são úteis enquanto aumentam a quantidade de resultados bem-sucedidos por unidade de tempo. Quando eles acrescentam principalmente espera e erros, uma configuração menor pode concluir o mesmo trabalho mais cedo. Se um painel apresentar médias de atividade ao longo do tempo, os picos breves poderão ficar menos visíveis do que nos horários dos erros da aplicação.
Para tarefas em navegadores, evitar downloads desnecessários também pode reduzir a atividade de rede. Bloquear imagens ou vídeos pode ajudar quando a tarefa não precisa deles; remover scripts pode impedir a própria operação. Avalie a mudança verificando se a tarefa pretendida continua sendo concluída corretamente.
Quando um limite maior ajuda
Mais capacidade de conexão é útil quando a aplicação gerencia suas conexões corretamente e a carga de trabalho necessária atinge de forma consistente o teto do provedor. Ela pode permitir que mais tarefas sejam executadas juntas sem disputar a mesma franquia pequena.
A compra deve aumentar o limite que está de fato sendo atingido. Acrescentar IPs pode ajudar com uma restrição por IP quando o trabalho é distribuído entre eles. Para um limite compartilhado do pacote, o novo pacote ou adicional precisa aumentar essa franquia compartilhada. Um aumento apenas na quantidade de IPs não comprova que isso acontecerá.
Também existem outros tetos. O cliente pode ter um pool menor, o computador pode ficar sem recursos de rede ou o destino pode limitar as solicitações. Uma única conexão móvel também tem sua própria largura de banda disponível, independentemente do número de conexões de proxy permitidas. Comprar mais capacidade de conexões simultâneas não elimina essas restrições e não corrige um script que continua deixando conexões sem liberar.
O objetivo prático é ter espaço suficiente para os picos normais da carga de trabalho, mantendo poucas falhas. Depois de estabelecer isso, uma franquia adicional de conexões pode ser um aumento útil de capacidade, em vez de uma forma de adiar a correção da aplicação.
