HTTPS aquecido contra VPN aquecida: compare o mesmo caminho de requisição

Provavelmente você leu que o HTTPS abre uma nova conexão TCP e um novo handshake TLS a cada requisição de API, então um túnel que fica aberto por uma hora parece mais barato. A primeira metade disso costuma ser falsa. Um cliente suportado reutiliza uma conexão já estabelecida para muitas trocas, e um benchmark que cria um cliente novo a cada chamada mede o ciclo de vida, não a proteção. O resto desta página trata do que medir em vez disso.

O que a reutilização realmente exige

A persistência faz parte do modelo HTTP e não é um truque: uma conexão carrega várias trocas de requisição e resposta. A conexão termina quando um dos lados a fecha, quando o servidor retira uma conexão ociosa ou sobrecarregada, ou quando um cabeçalho ou regra de protocolo diz que a conexão não pode ser reutilizada. O HTTPS coloca essa conversa dentro do TLS sem exigir um novo handshake a cada troca. Assim, uma segunda requisição não repete o handshake da primeira, a menos que algo tenha encerrado a conexão nesse meio-tempo.

A reutilização também tem uma condição que as aplicações quebram com facilidade. Um cliente que pretende reutilizar uma conexão precisa ler o corpo completo da resposta, e uma resposta abandonada no meio é a forma usual de um pool de conexões desaparecer sem que ninguém perceba.

Verifique o cliente suportado pela biblioteca e o ciclo de vida do pool de conexões em vez de supor que o agrupamento está ligado ou desligado. Registre também a versão HTTP negociada, porque HTTP/2 e HTTP/3 tratam a reutilização de conexões de forma diferente de HTTP/1.1. Trate a versão negociada como parte da medição, não como nota de rodapé.

Por que a comparação mede o ciclo de vida

Criar um cliente novo para cada operação e compará-lo com um túnel conectado há uma hora compara a configuração da conexão com um estado estacionário. Isso é um benchmark legítimo, e não é HTTPS contra VPN. Duas execuções com a mesma configuração de cliente descrevem o comportamento melhor do que uma, sobretudo quando a primeira execução aquece um resolvedor ou um cache de conexões.

Mantenha constantes a operação de API, o servidor, a conta e os dados, senão a comparação carrega mais de uma variável. Decida de antemão onde coloca o cronômetro, porque configuração, negociação TLS, execução da aplicação e entrega da resposta contribuem de modo diferente para o total. Um único cronômetro da primeira requisição caracteriza a configuração e não diz nada sobre o tráfego estável que você realmente opera. Anote os limites do cronômetro ao lado dos números.

Separe a configuração fria das requisições aquecidas

Meça a primeira requisição separadamente das que a seguem. Depois acrescente o que o serviço realmente vê: períodos de ociosidade, picos, concorrência, tamanho da resposta e reconexões.

Mantenha a validação de certificados e o HTTPS ativos nos dois caminhos, porque removê-los mede um desenho de segurança diferente e não um mais rápido. Se o túnel muda a rota ou a localização do gateway, informe essa diferença separadamente em vez de atribuir toda mudança de tempo à criptografia, já que rota, perda e fila podem dominar uma requisição pequena. Execute cada caminho duas vezes pela mesma rota antes de concluir. Anote o protocolo negociado e os limites do cronômetro nas duas execuções.

Planeje a conexão que se fecha

Persistente não significa permanente. Um servidor, um proxy ou uma mudança de rede podem fechar uma conexão durante um período de ociosidade, e o cliente precisa se recuperar pelo comportamento suportado pela sua biblioteca. Essa recuperação tem uma máquina de estados: a requisição pode ter sido concluída no servidor ou pode ter falhado antes de o servidor lê-la, e um socket fechado não diz a quem chamou qual dos casos ocorreu. Uma operação não idempotente nessa posição não pode ser simplesmente repetida, porque uma repetição transforma um resultado desconhecido em escrita duplicada. Aqui um túnel aquecido e uma conexão aquecida se comportam do mesmo jeito, já que ambos podem falhar no momento em que o trabalho está em curso.

Use o mecanismo documentado de nova tentativa ou de idempotência do serviço em vez de um laço que reabre o socket. Teste a recuperação de forma explícita: feche uma conexão ociosa e observe o que o cliente faz em seguida. Reabrir um socket não torna seguro repetir uma chamada que muda o estado.

Escolha a fronteira primeiro e depois ajuste

Escolha a fronteira de rede a partir dos requisitos de acesso e confiança antes de otimizar qualquer coisa. Uma VPN protege o segmento entre seus pares, enquanto os endpoints da aplicação e qualquer segmento em texto claro fora do túnel continuam importantes. Depois ajuste o ciclo de vida da conexão dentro dessa fronteira. A conclusão do túnel mais barato decorre apenas da crença de que cada requisição repete o handshake, e é essa crença que está sendo testada aqui.

A seção sobre persistência no RFC 9112 é a referência para o que a reutilização realmente promete, incluindo as condições que encerram uma conexão. Leia uma vez antes de confiar em um benchmark que as ignora.