Sessões persistentes

Uma sessão persistente com manutenção do IP (sticky session) instrui um serviço de proxy a manter um IP de saída para solicitações relacionadas. Seu aplicativo pode abrir páginas, enviar dados e receber um resultado por esse endereço enquanto a atribuição for válida e a saída permanecer disponível. Quando a tarefa termina, seu aplicativo pode iniciar uma sessão separada para a próxima tarefa.

Esse costuma ser um modo de acesso a um pool rotativo. A comparação mais ampla é abordada em Proxies estáticos ou rotativos. Aqui, a questão é como manter um endereço para uma tarefa, quanto tempo essa atribuição dura e o que pode interrompê-la.

Como o serviço mantém o IP selecionado

O serviço precisa reconhecer quais conexões pertencem à mesma tarefa. Um método comum é um identificador de sessão nas configurações de proxy. Na primeira conexão, o serviço seleciona uma saída e a vincula a esse identificador. Conexões posteriores com as mesmas configurações de sessão usam a saída atribuída enquanto a sessão permanecer ativa.

Por exemplo, um teste no navegador usa o nome de sessão task1. Sua primeira conexão recebe o IP de saída de exemplo 198.51.100.27. Abrir a próxima página e enviar um formulário pela mesma atribuição ativa também usa esse endereço. O nome identifica a atribuição; ele não codifica o IP nem o reserva permanentemente.

O identificador de sessão pode ser adicionado ao nome de usuário do proxy, selecionado por uma API ou representado por uma porta configurada. Alguns serviços também oferecem uma sessão padrão sem nome separado. São formas diferentes de gerenciar a atribuição; por isso, não existe um formato universal de nome de usuário nem um número de porta universal para acesso persistente.

Uma sessão persistente pode abranger várias conexões de rede. Isso difere de apenas reutilizar uma conexão aberta: as solicitações dentro da mesma conexão TCP comum já mantêm seu IP de saída. Para verificar se uma sessão mantém o endereço entre conexões, a observação útil é o que acontece quando uma nova conexão se abre com as mesmas configurações de sessão.

Quando várias solicitações precisam de um IP

Um teste de navegador com várias etapas é um exemplo claro. Ele pode entrar na conta, abrir uma página de configurações, enviar uma alteração e verificar o resultado. Manter o IP de origem estável elimina uma mudança evitável durante o teste, especialmente se o site usa o endereço como uma de suas verificações de sessão.

Um teste de compra ou reserva também pode depender de uma experiência regional consistente. O aplicativo pesquisa, escolhe uma opção e verifica a próxima etapa pela mesma saída. Isso ajuda a manter a localização de rede consistente entre as etapas, embora o site também possa usar configurações de conta, dados de entrega ou cookies para decidir o que exibir.

Outro caso é uma sequência de chamadas de API em que o serviço de destino espera ações relacionadas a partir de um endereço de origem consistente. A atribuição deve cobrir a sequência inteira, incluindo pausas e novas tentativas. Já consultas sem relação entre si a páginas públicas não precisam necessariamente de um IP. Manter um endereço é útil quando a continuidade importa para a tarefa; isso não melhora, por si só, a reputação do endereço nem garante que o site aceitará uma solicitação.

Uma sessão de proxy não preserva o login em um site

O serviço de proxy controla o endereço de saída. O site controla sua própria sessão: seu estado de login, carrinho ou progresso em um formulário. Um navegador ou cliente HTTP normalmente transporta esse estado por cookies ou tokens de autenticação. Os dois sistemas podem usar a palavra sessão, mas mantêm informações diferentes.

Isso significa que um login pode expirar enquanto o IP de saída permanece igual. Limpar os cookies também pode fazer o site deixar de reconhecer o usuário sem afetar a atribuição do proxy. O inverso também é possível: um site pode aceitar um login válido após uma mudança de IP. Seu comportamento depende das próprias regras.

Um objeto de sessão em uma biblioteca HTTP costuma armazenar cookies e reutilizar conexões. Criar esse objeto não ativa automaticamente o acesso persistente no serviço de proxy. Para um fluxo de trabalho completo, o aplicativo deve manter o estado no site e a atribuição de proxy pretendida em conjunto. Perfis de navegador separados ou estados de cliente isolados continuam necessários quando tarefas diferentes não podem compartilhar cookies.

O que a duração da sessão realmente significa

Dois temporizadores podem ser descritos como duração da sessão. Uma duração fixa limita por quanto tempo a atribuição existe a partir do seu ponto inicial. Um tempo limite de inatividade limita a pausa após a última solicitação válida para essa contagem. Novas solicitações podem reiniciar o temporizador de inatividade sem estender uma duração fixa separada.

Considere duas sessões ilustrativas com um limite de dez minutos. Ambas começam às 14:00 e recebem outra solicitação às 14:08. Com duração fixa, o prazo permanece em 14:10. Com tempo limite de inatividade, essa solicitação move o prazo de inatividade para 14:18. Portanto, a mesma duração informada pode produzir comportamentos muito diferentes durante uma tarefa ativa.

Um serviço pode aplicar os dois limites. Nesse caso, a atribuição termina quando qualquer um deles é atingido. O padrão comum também pode ser diferente da maior duração disponível nas configurações. Manter o tráfego fluindo pode evitar a expiração por inatividade, mas não remove uma duração máxima separada.

A expiração encerra a atribuição à saída antiga. Uma conexão posterior pode receber outro endereço, mesmo com o mesmo nome de sessão. Uma conexão aberta pode ter permissão para terminar ou pode ser fechada, dependendo do serviço. O temporizador não transfere uma troca TCP inacabada para outro IP.

Escolha uma janela que inclua a tarefa inteira, respostas lentas e pausas esperadas. Iniciar um novo fluxo de trabalho perto do fim de uma atribuição anterior deixa menos tempo do que a duração configurada sugere. Solicitações destinadas apenas a manter uma sessão ociosa ativa também continuam sendo tráfego real e podem contar para a cota de solicitações ou tráfego do serviço.

Como manter tarefas paralelas separadas

Quando tarefas independentes precisam, cada uma, de um endereço estável, dê a cada tarefa seu próprio identificador de sessão e mantenha esse identificador ao longo das etapas. Um processo que carrega a próxima página deve reutilizar a sessão da tarefa, em vez de gerar um novo nome para cada solicitação. Uma nova tentativa dentro dessa tarefa não deve mudar silenciosamente para configurações de proxy sem relação com ela.

Suponha que dois testes de navegador sejam executados ao mesmo tempo. O primeiro usa task1, o segundo usa task2, e cada um mantém seus próprios cookies. Atribuir o mesmo nome de sessão aos dois testes pediria ao serviço que compartilhasse uma atribuição quando as outras configurações também correspondessem. Abrir uma nova aba comum não cria, por si só, configurações de proxy separadas nem um armazenamento separado de cookies.

Identificadores diferentes solicitam atribuições separadas, mas não garantem universalmente IPs de saída diferentes. A promessa de endereços distintos pelo serviço é uma propriedade separada do produto. O acesso persistente também não torna uma saída exclusiva da sua conta: outros clientes ainda podem usar o endereço se ele pertencer a um pool compartilhado.

Onde há suporte, várias conexões podem usar a mesma sessão de uma vez. Elas compartilham a saída e continuam sujeitas aos limites de conexão e uso da conta. Mais nomes de sessão não aumentam esses limites. Antes de uma execução completa, verifique tanto o número de tarefas paralelas quanto o número de conexões que cada tarefa abre.

Por que o endereço pode mudar antes do esperado

Um temporizador válido não consegue manter uma saída indisponível funcionando. Um dispositivo residencial pode ficar offline, uma conexão móvel pode receber outro IP público ou um servidor pode se tornar inacessível. A duração solicitada descreve as regras de tempo da atribuição; por si só, ela não garante que a saída original permanecerá disponível.

Há duas respostas possíveis à perda dessa saída. Um serviço pode selecionar uma substituta para que as solicitações posteriores continuem ou retornar um erro e preservar a exigência de usar a saída original. Alguns produtos permitem escolher. A substituição automática prioriza fazer outra conexão; um erro dá ao aplicativo a oportunidade de parar antes de continuar a partir de outro endereço.

Um nome inalterado não prova que o restante das configurações de sessão permaneceu igual. Mudar para outro gateway ou alterar um filtro de país pode criar outra atribuição. O alcance relevante depende do serviço: uma sessão pode pertencer a uma conta, produto ou servidor de entrada específico, em vez de estar disponível em qualquer lugar com esse nome.

Se o endereço muda durante uma tarefa, a próxima decisão diz respeito ao estado dessa tarefa. Uma etapa somente de leitura pode ser segura para repetir. Uma ação que enviou um pedido ou alterou dados exige mais cuidado: uma resposta perdida não prova que a ação falhou. Determine o que foi concluído antes de reiniciar ou continuar por outra saída.

Quando a continuidade temporária é suficiente

O acesso persistente atende a uma tarefa com início e fim claros quando um IP é necessário apenas durante essa execução. Teste três coisas: se a atribuição resiste às pausas esperadas, dura a tarefa inteira e lida com a perda de uma saída conforme o necessário. Inclua no teste uma nova conexão após uma pausa normal; a atividade dentro de uma conexão já aberta não prova que a atribuição resistirá à próxima conexão.

Se o mesmo endereço precisa permanecer na lista de IPs permitidos de um servidor ou estar disponível novamente amanhã, use um serviço que forneça uma atribuição fixa para essa finalidade. Reutilizar o nome de uma sessão persistente após a expiração não recupera o endereço anterior de forma confiável. A manutenção temporária e um IP atribuído duradouro atendem a requisitos de continuidade diferentes.