Desempenho HTTP versus HTTPS

StackOverflow https://stackoverflow.com/questions/149274

  •  02-07-2019
  •  | 
  •  

Pergunta

Existem grandes diferenças no desempenho entre http e https?Parece que me lembro de ter lido que o HTTPS pode ser um quinto mais rápido que o HTTP.Isso é válido com os servidores/navegadores da geração atual?Em caso afirmativo, há algum documento técnico para apoiá-lo?

Foi útil?

Solução

Há uma resposta muito simples para isso: Analise o desempenho do seu servidor web para ver qual é a penalidade de desempenho para sua situação específica. Existem várias ferramentas para comparar o desempenho de um servidor HTTP versus HTTPS (JMeter e Visual Studio vêm à mente) e são bastante fáceis de usar.

Ninguém pode lhe dar uma resposta significativa sem alguns informações sobre a natureza do seu site, hardware, software e configuração de rede.

Como já foi dito, haverá algum nível de sobrecarga devido à criptografia, mas é altamente dependente de:

  • Hardware
  • Software de servidor
  • Proporção entre conteúdo dinâmico e estático
  • Distância do cliente ao servidor
  • Duração típica da sessão
  • Etc (meu favorito)
  • Comportamento de cache dos clientes

Na minha experiência, servidores que usam muito conteúdo dinâmico tendem a ser menos impactados por HTTPS porque o tempo gasto na criptografia (sobrecarga de SSL) é insignificante em comparação com o tempo de geração de conteúdo.

Servidores que atendem um conjunto relativamente pequeno de páginas estáticas que podem ser facilmente armazenadas em cache na memória sofrem com uma sobrecarga muito maior (em um caso, a taxa de transferência foi reduzida em uma "intranet").

Editar:Um ponto levantado por vários outros é que o handshake SSL é o principal custo do HTTPS.Isso está correto, e é por isso que a "duração típica da sessão" e o "comportamento de armazenamento em cache dos clientes" são importantes.

Muitas sessões muito curtas significam que o tempo de aperto de mão superará quaisquer outros fatores de desempenho.Sessões mais longas significarão que o custo do handshake será incorrido no início da sessão, mas as solicitações subsequentes terão uma sobrecarga relativamente baixa.

O cache do cliente pode ser feito em várias etapas, desde um servidor proxy de grande escala até o cache do navegador individual.Geralmente o conteúdo HTTPS não será armazenado em cache em um cache compartilhado (embora alguns servidores proxy possam explorar um comportamento do tipo man-in-the-middle para conseguir isso).Muitos navegadores armazenam em cache o conteúdo HTTPS para a sessão atual e, muitas vezes, entre sessões.O impacto do não armazenamento em cache ou de menos 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.

Outras dicas

O HTTPS requer um aperto de mão inicial que pode ser muito lento. A quantidade real de dados transferidos como parte do aperto de mão não é enorme (menos de 5 kb normalmente), mas para solicitações muito pequenas, isso pode ser um pouco de sobrecarga. No entanto, uma vez feito o aperto de mão, uma forma muito rápida de criptografia simétrica é usada, de modo que a sobrecarga é mínima. Conclusão: fazer muitas solicitações curtas sobre o HTTPS será um pouco mais lento que o HTTP, mas se você transferir muitos dados em uma única solicitação, a diferença será insignificante.

No entanto, o Keepalive é o comportamento padrão em http/1.1, então você fará um solteiro aperto de mão e muitas solicitações sobre a mesma conexão. Isso faz uma diferença significativa para HTTPS. Você provavelmente deve criar um perfil do seu site (como outros sugeriram) para ter certeza, mas suspeito que a diferença de desempenho não seja perceptível.

Para realmente entender como o HTTPS aumentará sua latência, você precisa entender como as conexões HTTPS são estabelecidas. Aqui está um Bom diagrama. A chave é que, em vez de o cliente obter os dados após 2 "pernas" (uma viagem de ida e volta, você envia uma solicitação, o servidor envia uma resposta), o cliente não obterá dados até pelo menos 4 pernas (2 viagens redondas) . Portanto, se for necessário 100 ms para um pacote se mover entre o cliente e o servidor, sua primeira solicitação HTTPS levará pelo menos 500 ms.

Obviamente, isso pode ser atenuado reutilizando a conexão HTTPS (que os navegadores devem fazer), mas explica parte dessa barraca inicial ao carregar um site HTTPS.

A sobrecarga não se deve à criptografia. Em uma CPU moderna, a criptografia exigida pelo SSL é trivial.

A sobrecarga se deve aos apertos de mão SSL, que são longos e aumentam drasticamente o número de viagens de ida e volta necessárias para uma sessão HTTPS sobre uma HTTP.

Meça (usando uma ferramenta como o Firebug) o tempo de carregamento da página enquanto o servidor está no final de um link simulado de alta latência. Existem ferramentas para simular um link de alta latência - para o Linux, existe "netem". Compare HTTP com HTTPS na mesma configuração.

A latência pode ser atenuada até certo ponto por:

  • Garantindo que seu servidor esteja usando o HTTP Keepalives - isso permite que o cliente reutilize sessões SSL, o que evita a necessidade de outro aperto de mão
  • Reduzindo o número de solicitações para o mínimo possível - combinando recursos sempre que possível (por exemplo.
  • Reduza o número de carregamentos de página, por exemplo, carregando dados não necessários na página (talvez em um elemento HTML oculto) e mostrando-os usando o cliente-script.

Atualização de dezembro de 2014

Você pode testar facilmente a diferença entre o desempenho HTTP e HTTPS em seu próprio navegador usando o Teste http vs https site por Antumchris: “Esta página mede seu tempo de carregamento em relação às conexões HTTP não seguras e HTTPS criptografadas. Ambas as páginas carregam 360 imagens exclusivas e não-gaches (total de 2,04 MB). ”

Os resultados podem te surpreender.

É importante ter um conhecimento atualizado sobre o desempenho HTTPS porque o Vamos criptografar A Autoridade de Certificação começará a emitir certificados SSL gratuitos, automatizados e abertos no verão de 2015, graças a Mozilla, Akamai, Cisco, Electronic Frontier Foundation e Identrust.

Atualização de junho de 2015

Atualizações sobre Let's Encrypt - Chegando a setembro de 2015:

Mais informações no Twitter: @letSencrypt

Para mais informações sobre o desempenho HTTPS e SSL/TLS, consulte:

Para obter mais informações sobre a importância de usar HTTPS, consulte:

Para resumir, deixe -me citar Ilya Grigorik: "O TLS tem exatamente um problema de desempenho: não é usado amplamente. Todo o resto pode ser otimizado".

Graças a Chris - autor do Teste http vs https Benchmark - para seus comentários abaixo.

A resposta superior atual não está totalmente correto.

Como outros apontaram aqui, o HTTPS requer aperto de mão e, portanto, faz mais petiscos de redondos TCP/IP.

Em um ambiente WAN normalmente, a latência se torna o fator limitante e não o aumento do uso da CPU no servidor.

Lembre -se de que a latência da Europa para os EUA pode ser de cerca de 200 ms (Torundtrip Time).

Você pode medir facilmente isso (para o caso de usuário único) com Httpwatch.

Além de tudo o que mencionou até agora, lembre-se de que alguns (todos?) Navegadores da Web não armazenam conteúdo em cache obtido sobre HTTPs no dígito local por motivos de segurança. Isso significa que, das páginas de perspectiva do usuário, com muito conteúdo estático, parece carregar mais lentamente após a reinicialização do navegador e, da perspectiva do servidor, o volume de solicitações de conteúdo estático sobre HTTPS será maior do que teria sido sobre o HTTP.

Não há uma única resposta para isso.

A criptografia sempre consumirá mais CPU. Isso pode ser descarregado para hardware dedicado em muitos casos, e o custo variará de acordo com o algoritmo selecionado. O 3DES é mais caro que o AES, por exemplo. Alguns algoritmos são mais caros para o criptografia do que o descripto. Alguns têm o custo oposto.

Mais caro do que a criptografia a granel é o custo do aperto de mão. Novas conexões consumirão muito mais CPU. Isso pode ser reduzido com a retomada da sessão, à custa de manter os segredos antigos da sessão até que expirem. Isso significa que pequenas solicitações de um cliente que não voltam para mais são as mais caras.

Para o tráfego cruzado da Internet, você pode não notar esse custo na sua taxa de dados, porque a largura de banda disponível é muito baixa. Mas você certamente notará isso no uso da CPU em um servidor ocupado.

Eu posso lhe dizer (como usuário dialup) que a mesma página sobre SSL é várias vezes mais lenta do que via HTTP regular ...

Em vários casos, o impacto de desempenho dos apertos de mão SSL será mitigado pelo fato de que a sessão SSL pode ser armazenada em cache nas duas extremidades (desktop e servidor). Nas máquinas do Windows, por exemplo, a sessão SSL pode ser armazenada em cache por até 10 horas. Ver http://support.microsoft.com/kb/247658/en-us . Alguns aceleradores SSL também terão parâmetros, permitindo que você ajuste o tempo em que a sessão estiver em cache.

Outro impacto a considerar é que o conteúdo estático servido sobre o HTTPS não será armazenado em cache por proxies, e isso pode reduzir o desempenho em vários usuários que acessam o site pelo mesmo proxy. Isso pode ser mitigado pelo fato de que o conteúdo estático também será armazenado em cache nos desktops, as versões do Internet Explorer 6 e 7 em cache de conteúdo estático HTTPS, a menos que seja instruído a fazer o contrário (Menu Ferramentas/Opções da Internet/Advanced/Security/Não Salvar páginas criptografadas para disco).

Fiz um pequeno experimento e obtive 16% de diferença de tempo para a mesma imagem do Flickr (233 KB):

http://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

https://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

enter image description here

É claro que esses números dependem de muitos fatores, como desempenho do computador, velocidade de conexão, carga do servidor, QoS no caminho (o caminho de rede específico retirado do navegador para o servidor), mas mostra a ideia geral: HTTPS é Slowser e Http, pois ele Requisres mais operações para concluir (Dados de handshaking e codificação/codificação SSL).

Aqui está um ótimo artigo (um pouco antigo, mas ainda ótimo) na latência do SSL Handshake. Me ajudou a identificar o SSL como a principal causa de lentidão para clientes que estavam usando meu aplicativo através de conexões lentas da Internet:

http://www.semicomplete.com/blog/geekery/ssl-laticy.html

Como estou investigando o mesmo problema para o meu projeto, encontrei esses slides. Mais velho, mas interessante:

http://www.cs.nyu.edu/artg/research/comparison/comparison_slides/sld001.htm

Parece haver um caso de borda desagradável aqui: Ajax sobre Wi -Fi congestionado.

O Ajax geralmente significa que o Keepalive se elevou depois de 20 segundos. No entanto, o Wi -Fi significa que a conexão (idealmente rápida) deve fazer várias viagens de ida e volta. Pior, o wifi geralmente perde pacotes e existem retransmissões de TCP. Nesse caso, o HTTPS tem um desempenho muito ruim!

O TLS já é rápido? Sim.

Existem muitos projetos por aí que visam desfocar as linhas e fazer HTTPs tão rápido. Curti Spdy e mod-spdy.

Comparação de desempenho HTTP vs HTTPS

Sempre associei HTTPs a tempos de carregamento da página mais lentos quando comparados ao HTTP antigo e simples. Como desenvolvedor da Web, o desempenho da página da web é importante para mim e qualquer coisa que diminua o desempenho das minhas páginas da Web é um não-não.

Para entender as implicações de desempenho envolvidas, o diagrama abaixo fornece uma idéia básica do que acontece sob o capô quando você solicita um recurso usando HTTPS.

enter image description here

Como você pode ver no diagrama acima, existem algumas etapas extras que precisam ocorrer ao usar HTTPS em comparação com o uso de HTTP simples. Quando você faz uma solicitação usando HTTPS, um aperto de mão precisa ocorrer para verificar a autenticidade da solicitação. Esse aperto de mão é uma etapa extra quando comparado a uma solicitação HTTP e infelizmente incorre em algumas sobrecargas.

Para entender as implicações de desempenho e ver por mim mesmo se o impacto do desempenho seria ou não significativo, usei este site como uma plataforma de teste. Fui para o webpagetest.org e usei a ferramenta de comparação visual para comparar esse carregamento de site usando HTTPS vs HTTP.

Como você pode ver de Aqui está o resultado do vídeo de teste O uso do HTTPS teve um impacto nos tempos de carregamento da minha página, no entanto, a diferença é insignificante e eu só notei uma diferença de 300 milissegundos. É importante observar que esses tempos dependem de muitos fatores, como desempenho do computador, velocidade de conexão, carga do servidor e distância do servidor.

Seu site pode ser diferente e é importante testar seu site e verificar o impacto do desempenho envolvido na mudança para HTTPS.

Podemos melhorar o desempenho? Visite aqui Para obter informações detalhadas

Existe uma maneira de medir isso. A ferramenta do Apache chamada JMeter medirá a taxa de transferência. Se você configurar uma grande amostra de seu serviço com o JMeter, em um ambiente controlado, com e sem SSL, você deve obter uma comparação precisa do custo relativo. Eu estaria interessado em seus resultados.

O HTTPS possui uma sobrecarga de criptografia/descriptografia, para que sempre seja um pouco mais lento. A terminação SSL é muito intensiva na CPU. Se você tiver dispositivos para descarregar o SSL, a diferença de latências pode ser quase perceptível, dependendo da carga que seus servidores estão abaixo.

Uma diferença de desempenho mais importante é que uma sessão HTTPS está aberta Ketp enquanto o usuário está conectado. Uma 'sessão' http dura apenas para uma única solicitação de item.

Você está executando um site com um grande número de usuários simultâneos, espere comprar muita memória.

Isso quase certamente será verdade, uma vez que o SSL requer uma etapa extra de criptografia que simplesmente não é exigida pelo HTTP não-SLL.

Os navegadores podem aceitar o protocolo HTTP/1.1 com HTTP ou HTTPS, mas os navegadores podem lidar apenas com o protocolo HTTP/2.0 com HTTPS. As diferenças de protocolo de HTTP/1.1 para HTTP/2.0 tornam HTTP/2.0, em média, 4-5 vezes mais rápido que HTTP/1.1. Além disso, de sites que implementam HTTPs, a maioria o faz no protocolo HTTP/2.0. Portanto, o HTTPS quase sempre será mais rápido que o HTTP simplesmente devido ao protocolo diferente que geralmente usa. No entanto, se http sobre http/1.1 for comparado com https sobre http/1.1, o http será um pouco mais rápido, em média, que https.

Aqui estão algumas comparações que executei usando o Chrome (ver. 64):

HTTPS sobre HTTP/1.1:

  • 0,47 segundos Página média tempo de carregamento
  • 0,05 segundos mais lento que o HTTP sobre HTTP/1.1
  • 0,37 segundos mais lentos que HTTPs sobre HTTP/2.0

HTTP sobre HTTP/1.1

  • 0,42 segundos Página média tempo de carregamento
  • 0,05 segundos mais rápido que HTTPS sobre HTTP/1.1
  • 0,32 segundos mais lentos que HTTPs sobre HTTP/2.0

HTTPS sobre HTTP/2.0

  • 0,10 segundos de tempo de carga média
  • 0,32 segundos mais rápido que o HTTP sobre HTTP/1.1
  • 0,37 segundos mais rápido que HTTPS sobre HTTPS/1.1
Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top