Sobrecarga de latência HTTPS para sites do mundo real

Question

Eu estava testando a adição de HTTPS ao meu site pequeno e, como tinha uma configuração que permitia acessar meu site via HTTP ou via HTTPS, decidi compará-lo usando ab (por exemplo, ab -n 1000 -c 5 http://{mywebsite}/{resource} vs ab -n 1000 -c 5 https://{mywebsite}/{resource} ). Para minha surpresa, descobri que todas as solicitações em todos os percentuais levavam o dobro do tempo para HTTPS.

Estou usando uma caixa bem barata (AWS t2.micro para ser específico) onde hospedo meu aplicativo da web (java / jetty) e nginx que faz gzip e SSL, então, meu primeiro pensamento foi que isso não deveria ser verdade para sites grandes e eu não tenho poder de CPU suficiente lá. Mais desempenho de rede é conhecido por ser pequeno para essas caixas.

Então, por curiosidade, tentei executar a mesma linha ab contra algum site que tenha algum conteúdo disponível em HTTP e HTTPS (como link vs link e link vs link para citar alguns). E adivinha? Eu vi o mesmo padrão para eles também - cada percentil para HTTPS era aproximadamente duas vezes ou três vezes maior que o percentil correspondente para o mesmo recurso servido via HTTP.

Eu pensei que o meu provedor é o culpado, mas tentei executar esses benchmarks ab de uma das caixas da AWS e vi melhor latência, mas ainda o mesmo padrão: solicitações HTTP eram pelo menos duas vezes mais rápidas que HTTPS para a minha e sites de grandes nomes acima.

Eu me pergunto o que pode ser a razão para isso? Eu tentei executar o ab contra localhost (obviamente com verificação cert desativada para HTTPS) e a diferença não era tão grande (eu diria ~ 10-15%).

Eu ficaria feliz em saber um pouco mais sobre a natureza da sobrecarga acima se alguém viu isso. Eu não sou um engenheiro de rede, então tenho pouco ou nenhum entendimento sobre se o handshake TLS é o único contribuinte para este aumento de latência.

O que mais poderia causar esses resultados?

ATUALIZAÇÃO:

Como várias pessoas apontaram o handshake TLS pode ser a causa raiz. E é para os exemplos acima, quando o tempo para executar a solicitação é insignificante (como servir conteúdo estático).

E acabei de encontrar a opção ab que mostra claramente isso, é a opção -k , que permite a reutilização da conexão. Com esta opção ativada, o custo total do HTTPS é muito menor do que quando as conexões não são reutilizadas.

    

Answer 1

Haverá algum nível de sobrecarga devido à criptografia, depende de:

• Hardware
• Servidor
• Proporção de conteúdo dinâmico versus conteúdo estático
• Distância do cliente
• Duração da sessão
• Cache

Servidores que têm conteúdo dinâmico pesado tendem a impactar menos por HTTPS, porque o tempo gasto na criptografia (sobrecarga de SSL) é insignificante comparado ao tempo de geração de conteúdo. Servidores que são pesados em servir um conjunto relativamente pequeno de páginas estáticas que podem ser facilmente armazenados em cache na memória sofrem com uma sobrecarga muito maior, reduzindo a taxa de transferência. Handshaking SSL é o maior custo de HTTPS. Essa é a razão pela qual "Duração da sessão" e "Cache" são importantes. Sessões mais longas significarão que o custo do handshaking será incorrido no início da sessão, mas as solicitações subsequentes terão uma sobrecarga relativamente baixa.

O armazenamento em cache pode ser feito em várias etapas, desde um servidor proxy de grande escala até o cache individual do navegador. Geralmente, o conteúdo HTTPS não será armazenado em cache em um cache compartilhado. Muitos navegadores armazenam em cache conteúdo HTTPS para a sessão atual e, muitas vezes, em todas as sessões. O impacto do não armazenamento em cache ou do armazenamento em cache significa que os clientes recuperarão o mesmo conteúdo com mais frequência. Isso resulta em mais solicitações e largura de banda para atender o mesmo número de usuários.

Fazer muitas solicitações curtas em HTTPS será um pouco mais lento que o HTTP, mas se você transferir a quantidade em massa de dados em uma única solicitação, a diferença será insignificante. No entanto, keepalive é o comportamento padrão no HTTP / 1.1, ele fará um único handshake e, em seguida, muitas solicitações sobre a mesma conexão poderão ser processadas. Isso faz uma diferença significativa para o HTTPS.