Cobrança de proxies por GB

Pelo que você paga

Um gigabyte é uma unidade de consumo em um produto de proxy. O produto fornece uma rota para a internet por seus IPs de saída; a tarifa determina como o uso dessa rota é cobrado. Você pode comprar antecipadamente um saldo de tráfego, receber uma franquia recorrente ou pagar pelo uso medido conforme um contrato de conta. Todos esses formatos podem ter um preço por GB, embora suas datas de pagamento e compromissos sejam diferentes.

O acesso costuma funcionar por um gateway: sua aplicação se conecta a um endereço fornecido pelo provedor, e o serviço seleciona uma saída de um pool disponível. Mudar a saída pode continuar usando a mesma franquia da conta. Portanto, um grande pool anunciado descreve possibilidades de acesso, e não uma lista de endereços reservados para você. Alguns produtos, em vez disso, combinam uma cobrança por tráfego com acesso a IPs específicos.

A unidade de cobrança não determina o tipo de rede nem o comportamento da sessão. Produtos de datacenter, ISP, residenciais e móveis podem ser vendidos por tráfego. A rotação, a possibilidade de manter um IP durante uma sessão e o uso exclusivo de um endereço são propriedades separadas do produto. Pagar por mais GB não prolonga uma sessão que tem seu próprio limite de tempo nem restaura uma saída indisponível.

Escolha o acesso necessário antes de comparar tarifas. Para um teste regional de finalização de compra, o produto útil precisa fornecer um IP aceito na localização necessária e manter a sessão funcionando até o fim da compra. Uma franquia mais barata que não consiga fazer isso não atende à tarefa. Por outro lado, comprar uma rede mais cara não traz benefício automático quando a mais simples já funciona de forma confiável.

A franquia também não informa nada sobre a velocidade de entrega. O volume determina quanto pode passar; a taxa de transferência determina com que rapidez isso passa; a simultaneidade determina quanto trabalho pode estar ativo ao mesmo tempo. Um saldo grande não compensa uma rota lenta demais para concluir um trabalho com prazo crítico.

Como um trabalho concluído se transforma em tráfego pago

Comece pela transação inteira. Um programa pode primeiro obter uma lista de documentos, seguir links de download, baixar os arquivos e depois repetir alguns downloads. Cada etapa pode usar a conexão paga, embora o arquivo final contenha apenas uma cópia de cada documento.

Considere um trabalho ilustrativo de arquivamento que armazena com sucesso 300 documentos. Os totais de tráfego hipotéticos a seguir descrevem partes separadas da execução, sem sobreposição. São um exemplo de contabilização, e não medições de um site ou provedor específico.

Com unidades decimais, essa execução consome 0.308 GB. A uma tarifa hipotética de $4.50/GB, a cobrança de tráfego é de $1.386, ou cerca de $1.39 antes de quaisquer outras cobranças. A distinção útil é entre os 240 MB associados aos documentos mantidos e os 308 MB usados pelo processo. Remover os downloads redundantes economizaria 48 MB sem reduzir o acervo; remover a etapa de descoberta de documentos poderia impedir o funcionamento do trabalho.

O escopo de medição do provedor importa. Políticas de proxy publicadas costumam contabilizar tanto os dados enviados ao site quanto os recebidos, incluindo cabeçalhos e corpos HTTP. Por isso, trabalhos com muitos envios consomem franquia mesmo quando a resposta do site é curta. As políticas diferem quanto ao tráfego de conexão, à sobrecarga de criptografia e aos erros gerados pelo serviço. Um contador do conteúdo dos arquivos baixados não basta para reconstituir todas as contas.

Um túnel HTTPS pode transportar bytes criptografados que o proxy mede sem ler o conteúdo protegido. Para planejar o orçamento, use o método declarado pelo provedor e uma execução medida; não existe uma porcentagem universal de sobrecarga a acrescentar a cada solicitação. Aplicar essa porcentagem a um contador que já inclui esses bytes os contabilizaria novamente.

Por que GB e GiB mostram números diferentes

Um gigabyte (GB) contém 1 000 000 000 bytes. Um gibibyte (GiB) contém 2³⁰ bytes: 1 073 741 824 bytes, ou 1 024 MiB. GB usa potências decimais; GiB usa potências binárias. Eles medem o mesmo tipo de grandeza com unidades de tamanhos diferentes.

Por exemplo, 32 GiB equivalem a 34.359738368 GB, aproximadamente 34.36 GB. O número expresso em GB é cerca de 7.37% maior porque cada GiB contém 1.073741824 GB. Não surgiu tráfego extra: as duas leituras descrevem a mesma contagem de bytes. Uma franquia de 32 GB, por sua vez, equivale a aproximadamente 29.80 GiB; portanto, ter o mesmo número impresso não torna duas franquias iguais.

Antes de conciliar o contador de uma aplicação com o uso cobrado, converta os dois valores para a mesma unidade. Verifique a definição do provedor, em vez de confiar em um rótulo abreviado; depois, verifique o escopo da contabilização. O arredondamento é uma questão separada: uma leitura abreviada no painel não revela a precisão usada na cobrança.

Por que o fluxo de trabalho importa tanto quanto a página

A primeira visita e as visitas repetidas são diferentes

Uma primeira visita pode baixar os recursos necessários para exibir e operar um site. Uma visita posterior no mesmo navegador pode reutilizar alguns recursos locais, enquanto um perfil de navegador novo talvez precise obtê-los novamente. Isso faz com que a forma de iniciar e reutilizar sessões do navegador seja parte do modelo de tráfego.

O cache tem vários resultados possíveis. Uma cópia local atualizada pode ser usada sem baixar novamente aquele recurso. Uma cópia desatualizada pode exigir uma solicitação condicional; uma resposta 304 Not Modified permite reutilizar o conteúdo armazenado, mas a troca de validação ainda usa a rede. Um recurso alterado ou não reutilizável exige uma nova transferência. Manter um perfil não garante que todos os recursos ficarão em cache.

Para um trabalho de monitoramento, os recursos em cache podem ser úteis. Para um teste da experiência de um novo visitante, eles podem invalidar o teste. Meça nas condições que a tarefa realmente exige. Uma visita repetida barata não é uma estimativa sólida para milhares de primeiras visitas independentes.

O formato de saída também pode induzir ao erro. Fazer uma captura de tela localmente cria uma imagem a partir de conteúdo já carregado; isso, por si só, não envia a captura de volta pelo proxy. Enviar essa imagem pelo proxy seria outra transferência. Um navegador hospedado remotamente ou uma API de captura de tela pode ter um modelo de cobrança diferente; portanto, o tamanho de sua saída não deve ser tratado como o tráfego de um navegador local comum.

Downloads e vídeos precisam de estimativas diferentes

Em um trabalho de transferência de arquivos, o tamanho dos documentos, a detecção de duplicatas e a possibilidade de retomar após interrupções costumam dominar o consumo. Em um teste de vídeo, a duração e a taxa de bits se tornam mais úteis do que a contagem de páginas. A página inicial pode ser pequena enquanto o reprodutor continua buscando mídia durante todo o teste.

Suponha que um teste receba uma média de 6 megabits por segundo de dados de mídia durante 18 minutos. Dividir por oito converte bits em bytes: 6 × 1 080 ÷ 8 = 810 megabytes, ou 0.81 GB. Repetir esse teste completo a partir de 12 localizações transferiria 9.72 GB apenas de mídia. Essa é uma carga de trabalho hipotética; a interface do reprodutor, outras solicitações e a sobrecarga contabilizada são adicionais. A qualidade adaptativa e o armazenamento em buffer podem alterar a transferência real.

Reduzir a qualidade da reprodução só é uma economia quando o teste continua respondendo à sua pergunta. Uma verificação breve de que um vídeo inicia pode usar uma janela curta de observação. Um teste de reprodução contínua em alta qualidade precisa receber uma parte suficiente daquele fluxo para avaliá-lo. A evidência necessária determina quais dados podem ser omitidos.

Essas diferenças explicam onde a cobrança por tráfego se encaixa. Verificações regionais breves e acesso intermitente a um pool útil podem precisar de poucos dados. Testes contínuos de mídia ou downloads grandes e repetidos podem consumir rapidamente a mesma franquia. Ambos são tecnicamente possíveis com um produto adequado; sua viabilidade econômica depende do volume de trabalho, da programação e das alternativas disponíveis.

Monte uma previsão a partir da composição do trabalho

Defina a conclusão antes de medir. Uma tarefa de documentos bem-sucedida pode significar um arquivo legível com o identificador esperado; um teste regional pode exigir uma interação concluída e um resultado registrado. Uma conexão bem-sucedida ou um status HTTP, por si só, não comprova que o trabalho foi concluído.

Use um piloto com as localizações, configurações de sessão, software e nível de atividade paralela pretendidos. Separe suas credenciais ou seus relatórios de uso dos trabalhos não relacionados. Registre a variação de uso em um período correspondente, considerando o atraso de relatórios do provedor, e conte tanto as tarefas concluídas quanto as tentativas. Se a atividade em segundo plano fizer parte da operação normal, inclua-a ou meça-a separadamente, em vez de excluí-la sem indicação.

Pondere os diferentes tipos de operação

Uma previsão útil preserva a composição esperada. Suponha que um piloto forneça as médias hipotéticas a seguir, já incluindo as solicitações e novas tentativas normais necessárias para cada operação concluída. Cada operação planejada pertence a apenas uma categoria.

À mesma tarifa hipotética de $4.50/GB, a cobrança prevista de tráfego é de $67.986, aproximadamente $67.99. As verificações de mídia representam menos de uma em treze operações, mas quase 60% do tráfego. Portanto, otimizar as verificações posteriores, muito mais numerosas, pode ter menos efeito do que alterar adequadamente o teste de mídia.

O cálculo geral é a soma da quantidade de cada tarefa multiplicada por seu tráfego médio medido. Acrescente atividades de configuração ou compartilhadas medidas separadamente somente se estiverem fora dessas médias. Da mesma forma, novas tentativas já presentes no piloto não devem ser adicionadas uma segunda vez por meio de um multiplicador de falhas.

Teste o que pode mudar a previsão

Uma média só é útil enquanto o trabalho permanece comparável. Mudar para novos perfis de navegador pode eliminar a economia do cache. Uma localização diferente pode receber uma página ou fluxo de mídia diferente. Uma janela maior de observação pode coletar mais dados em segundo plano. Verifique novamente a categoria afetada após essas mudanças, em vez de aplicar a média antiga ao projeto inteiro.

Teste também uma execução menos favorável, mas plausível, além da comum: documentos maiores, sessões novas ou um período com mais interrupções. Mantenha suas premissas visíveis. Uma reserva derivada dessas condições é mais informativa do que uma porcentagem sem explicação acrescentada a todo orçamento.

Para escolher entre serviços adequados, converta cada teste em gasto para a mesma carga de trabalho concluída. Inclua o tráfego realmente consumido e qualquer compromisso de compra inevitável. Um preço baixo por GB pode ser útil, mas não encerra uma comparação quando um serviço precisa de um número diferente de tentativas ou não consegue concluir as sessões necessárias.

Adeque a compra ao calendário de trabalho

A previsão acima estima o consumo. O valor a pagar pode ser diferente porque o produto vende tráfego em pacotes, exige uma assinatura ou acrescenta uma taxa separada de acesso. Leia a oferta como uma compra completa: o que fica disponível, em quais datas e qual pagamento autoriza o uso posterior.

Um problema ilustrativo de programação mostra por que as datas importam. Um projeto precisa de 8 GB antes de uma renovação de cobrança e de 28 GB depois. Uma franquia mensal hipotética de 30 GB que custa $90, sem acúmulo e sem outras taxas, exige dois pagamentos mensais: $180. Um saldo hipotético sem vencimento, vendido em blocos de 20 GB por $80, exige dois blocos: $160, deixando 4 GB disponíveis. Pressupõe-se que os dois formatos forneçam acesso equivalente. A tarifa mensal anunciada de $3 é menor que a tarifa de $4 na compra em blocos, mas o projeto programado exige mais desembolso na opção mensal.

Mova esse mesmo projeto inteiramente para dentro de um período de cobrança, e a comparação muda: a franquia de 30 GB precisaria de mais 6 GB; portanto, seu preço de recarga se torna decisivo. É por isso que multiplicar a demanda total pela menor tarifa exibida não basta. Modele o trabalho em relação às datas de renovação, aos incrementos de compra e a qualquer vencimento do tráfego extra.

Uma franquia restante só ajuda em trabalhos posteriores enquanto continuar utilizável nas condições da conta. Separe o vencimento do tráfego da renovação da assinatura e de qualquer exigência de manter a conta ativa. Se o tráfego básico e os adicionais comprados tiverem prazos de validade diferentes, determine qual saldo é usado primeiro; a resposta pode afetar o que vence sem uso.

A configuração selecionada também faz parte do preço. O acesso a uma rede específica, uma seleção de localização mais precisa, endereços reservados ou outros recursos podem alterar a cobrança. Se uma tarifa usar um multiplicador de consumo, mantenha os bytes físicos e as unidades cobradas distintos. Aplique o multiplicador apenas se o valor de uso ainda não o tiver aplicado. O mesmo cuidado é necessário com compromissos mínimos, a tarifa do tráfego adicional e os impostos incluídos ou excluídos da cotação.

Para trabalho intenso e regular, compare toda a carga de trabalho planejada com uma opção adequada de preço fixo. A alternativa precisa atender aos mesmos requisitos de sites, localizações, sessões, tráfego permitido e velocidade de entrega. Uma taxa fixa pode facilitar o orçamento de grandes transferências, enquanto o acesso por tráfego pode evitar a manutenção de uma capacidade raramente usada por uma tarefa ocasional. Nenhuma unidade de cobrança determina qual rede funcionará melhor.

Recupere-se das falhas sem comprar o mesmo trabalho novamente

A recuperação deve começar pela menor parte inacabada da tarefa. Se uma execução já armazenou a maioria dos documentos, reiniciar a lista inteira pode fazer você pagar por muitos downloads idênticos. Registre os identificadores concluídos, valide os arquivos salvos e retome a fila restante. Isso reduz o desperdício sem mudar a rede de proxies nem seu preço.

Arquivos grandes interrompidos precisam de um mecanismo mais específico. Quando o servidor e o cliente oferecem suporte a solicitações de intervalo, um download pode solicitar a parte que falta. O cliente deve verificar se está continuando a mesma versão do arquivo. Uma resposta 206 Partial Content fornece um intervalo; uma resposta completa 200 OK não deve ser anexada cegamente a um fragmento existente. O suporte à retomada pode economizar bytes transferidos, mas precisa ser implementado corretamente.

Erros devem levar a decisões diferentes. Uma falha temporária de conexão pode justificar uma nova tentativa limitada. Uma recusa repetida, um login expirado, uma franquia de conta esgotada ou uma solicitação inválida exige outra resposta. Repetir rapidamente um problema inalterado pode gastar mais sem gerar progresso. Para ações que alteram uma conta remota, determine se a primeira tentativa foi concluída antes de enviá-la novamente.

O fato de uma tarefa falhar não apaga os bytes já transferidos. Um download interrompido ou uma página de rejeição pode consumir tráfego pago; alguns serviços excluem seus próprios erros de conexão. Aplique os termos do produto de proxy real, em vez de tomar emprestada a promessa de cobrança por solicitação bem-sucedida de uma API de coleta de dados.

A continuidade da sessão também pode afetar a recuperação. Substituir um IP pode invalidar um fluxo de trabalho associado àquela sessão e exigir a repetição de etapas anteriores. Manter um IP pode preservar a continuidade, mas não torna gratuitas as transferências posteriores nem garante que a sessão no site continue válida. Salve o progresso sempre que possível e escolha a ação de recuperação que trate a falha.

Mantenha um trabalho em execução dentro do orçamento

Acompanhe o progresso junto com o uso. Três leituras úteis são a franquia restante, o consumo recente por minuto e as tarefas concluídas no mesmo intervalo. Se o uso aumentar enquanto as conclusões estagnam, o trabalho precisará de atenção antes de esgotar o saldo. Se ambos aumentarem proporcionalmente, a aplicação pode simplesmente estar fazendo mais trabalho.

Por exemplo, 14 GB restantes a um consumo sustentado de 0.35 GB por minuto fornecem cerca de 40 minutos de tráfego nessa taxa. Essa é uma estimativa de planejamento, e não uma garantia de desligamento: a taxa pode mudar, o uso exibido pode estar atrasado e transferências ativas ainda podem estar sendo concluídas. Compare esse tempo com a fila restante e interrompa ou reduza novos trabalhos com antecedência suficiente para terminar com segurança.

Use controles tanto na compra quanto na aplicação. Na conta, escolha deliberadamente se o esgotamento interrompe o acesso ou autoriza outra compra ou uma cobrança por excedente. Na aplicação, limite a fila, as tentativas, as transferências simultâneas e a duração das sessões abertas. Uma recarga automática mantém a conexão com fundos; ela não pode decidir se o trabalho ainda merece o dinheiro.

Downloads longos e sessões de mídia precisam de uma condição explícita de parada. Apenas iniciar menos solicitações novas pode deixar as transferências existentes consumindo dados. A aplicação deve conseguir cancelar trabalhos em andamento e fechar sessões não utilizadas. Deixe margem para atrasos nos relatórios e na aplicação dos limites, em vez de tratar um limite no painel como um interruptor instantâneo.

Quando os números parecerem errados, concilie uma execução delimitada. Faça corresponder a conta ou usuário, o intervalo de tempo, a unidade e o registro de tarefas. As ferramentas de rede do navegador ajudam a localizar transferências pesadas e distinguir os tamanhos transferidos dos tamanhos descompactados dos recursos, mas não necessariamente abrangem todos os processos que usam a conta. Acompanhe o consumo de tráfego separadamente das compras, transferências de saldo e vencimentos; uma mudança de saldo nem sempre é uma transferência de rede.

Depois, faça uma mudança direcionada e repita a mesma tarefa. Preserve o estado do navegador necessário ao teste, evite downloads duplicados, mantenha a compressão compatível e impeça o início de recursos irrelevantes quando isso não quebrar o fluxo de trabalho. O resultado deve mostrar tanto menor gasto quanto conclusão bem-sucedida. Uma redução de transferência que remove a evidência que a tarefa deveria coletar é um trabalho incompleto.