Existem diferenças importantes no desempenho entre http e https? Lembro-me de ler 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, existem documentos técnicos para apoiá-lo?

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

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

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

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

De acordo com minha experiência, os servidores pesados ​​em conteúdo dinâmico tendem a ser menos afetados pelo HTTPS porque o tempo gasto na criptografia (sobrecarga de SSL) é insignificante em comparação ao tempo de geração de conteúdo.

Os servidores que prestam serviços pesados ​​em 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 (em um caso, a taxa de transferência foi armazenada em uma "intranet").

Edit: Um ponto que foi levantado por vários outros é que o handshaking 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 cache dos clientes" são importantes.

Muitas sessões muito curtas significam que o tempo de handshake sobrecarregará outros fatores de desempenho. Sessões mais longas significam que o custo do handshake será incorrido no início da sessão, mas as solicitações subsequentes terão despesas gerais relativamente baixas.

O cache do cliente pode ser feito em várias etapas, desde um servidor proxy em grande escala até o cache do navegador individual. Geralmente, o conteúdo HTTPS não é armazenado em cache em um cache compartilhado (embora alguns servidores proxy possam explorar um comportamento do tipo intermediário 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 cache ou menos cache significa que os clientes recuperam o mesmo conteúdo com mais frequência. Isso resulta em mais solicitações e largura de banda para atender ao mesmo número de usuários.

O HTTPS requer um aperto de mão inicial que pode ser muito lento. A quantidade real de dados transferidos como parte do handshake não é enorme (geralmente inferior a 5 kB), mas para solicitações muito pequenas, isso pode ser um pouco de sobrecarga. No entanto, assim que o handshake é concluído, é usada uma forma muito rápida de criptografia simétrica, de modo que a sobrecarga é mínima. Conclusão: fazer muitas solicitações curtas por 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, keepalive é o comportamento padrão no HTTP / 1.1, portanto, você fará um único handshake e, em seguida, muitos pedidos pela mesma conexão. Isso faz uma diferença significativa para o HTTPS. Você provavelmente deve criar um perfil do seu site (como outros sugeriram) para garantir, mas suspeito que a diferença de desempenho não será 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 receberá dados até pelo menos quatro pernas (duas viagens de ida e volta) . Portanto, se levar 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 paralisação inicial ao carregar um site HTTPS.

A sobrecarga NÃO é devido à criptografia. Em uma CPU moderna, a criptografia exigida pelo SSL é trivial.

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

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

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

• Garantir que seu servidor esteja usando keepalives HTTP - isso permite que o cliente reutilize sessões SSL, o que evita a necessidade de outro handshake
• Reduzir o número de solicitações para o mínimo possível - combinando recursos sempre que possível (por exemplo, .js incluem arquivos, CSS) e incentivando o cache do lado do cliente
• 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 script do cliente.

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 site HTTP vs HTTPS Test da AnthumChris : “Esta página mede seu tempo de carregamento em conexões HTTP e HTTPS não seguras e criptografadas. Ambas as páginas carregam 360 imagens exclusivas e não armazenadas em cache (total de 2,04 MB). ”

Os resultados podem te surpreender.

É importante ter um conhecimento atualizado sobre o desempenho do HTTPS, porque a Autoridade de Certificação Let's Encrypt criptografará os certificados SSL gratuitos, automatizados e abertos no verão de 2015, graças à Mozilla, Akamai, Cisco, Electronic Frontier Foundation e IdenTrust.

Atualização de junho de 2015

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

• Criptografar a programação de lançamentos (16 de junho de 2015)
• Vamos criptografar certificados raiz e intermediários (4 de junho de 2015)
• Projeto de contrato Vamos criptografar o assinante (21 de maio de 2015)

Mais informações no Twitter: @letsencrypt

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

• O TLS é rápido ainda?
• Rede de navegador de alto desempenho, Capítulo 4: Segurança da camada de transporte
• Overclocking SSL
• Anatomia e desempenho do processamento SSL

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

• Por que HTTPS para tudo? (O padrão somente HTTPS)
• Vamos criptografar (Internet Security Research Group)
• HTTPS em todos os lugares (Electronic Frontier Foundation)

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

Agradecemos a Chris - autor do benchmark HTTP vs HTTPS Test - por seus comentários abaixo.

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

Como outros já apontaram aqui, https requer handshaking e, portanto, faz mais viagens de ida e volta 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 (tempo de viagem).

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

Além de tudo mencionado até agora, lembre-se de que alguns (todos?) Navegadores da Web não armazenam conteúdo em cache obtido por HTTPS no disco rígido local por motivos de segurança. Isso significa que, a partir das páginas de perspectiva do usuário, com bastante conteúdo estático parecerá 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 por HTTPS será maior do que o HTTP.

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

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

Mais caro do que a criptografia em massa é 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, com o custo de manter antigos segredos da sessão até que eles expirem. Isso significa que pequenas solicitações de um cliente que não retornam mais são as mais caras.

Para tráfego cruzado da Internet, você pode não perceber 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.

Posso dizer (como usuário discado) que a mesma página sobre SSL é várias vezes mais lenta do que via HTTP comum ...

Em vários casos, o impacto no desempenho dos handshakes SSL será atenuado pelo fato de a sessão SSL poder ser armazenada em cache nas duas extremidades (desktop e servidor). Em máquinas Windows, por exemplo, a sessão SSL pode ser armazenada em cache por até 10 horas. Consulte http://support.microsoft.com/kb/247658/EN-US . Alguns aceleradores SSL também terão parâmetros que permitem ajustar o tempo em que a sessão é armazenada em cache.

Outro impacto a considerar é que o conteúdo estático veiculado por HTTPS não será armazenado em cache por proxies, e isso pode reduzir o desempenho de vários usuários que acessam o site pelo mesmo proxy. Isso pode ser atenuado pelo fato de que o conteúdo estático também será armazenado em cache nas áreas de trabalho. As versões 6 e 7 do Internet Explorer armazenam em cache o conteúdo estático HTTPS em cache, a menos que seja instruído a fazer o contrário (Menu Ferramentas / Opções da Internet / Avançado / Segurança / Não salvar páginas criptografadas para o 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

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

Aqui está um ótimo artigo (um pouco antigo, mas ainda ótimo) sobre a latência do handshake SSL. Ajudou-me a identificar o SSL como a principal causa de lentidão para clientes que estavam usando meu aplicativo por meio de conexões lentas com a Internet:

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

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

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

Parece haver um caso desagradável aqui: Ajax por wifi congestionado.

Ajax geralmente significa que o KeepAlive atingiu o tempo limite após, digamos, 20 segundos. No entanto, o wifi significa que a conexão ajax (idealmente rápida) precisa fazer várias viagens de ida e volta. Pior, o wifi geralmente perde pacotes e há retransmissões de TCP. Nesse caso, o HTTPS executa realmente muito mal!

O TLS ainda é rápido? Sim.

• Assista: https://www.youtube.com/watch?v=0EB7zh_7UE4
• Leia: https://istlsfastyet.com/

Existem muitos projetos por aí que visam desfocar as linhas e tornar o HTTPS tão rápido quanto. Como SPDY e mod-spdy .

COMPARAÇÃO DE DESEMPENHO HTTP VS HTTPS

Sempre associei o HTTPS a tempos de carregamento de página mais lentos quando comparados ao HTTP antigo simples. Como desenvolvedor da Web, o desempenho das páginas 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 quando você solicita um recurso usando HTTPS.

Como você pode ver no diagrama acima, existem algumas etapas extras que precisam ocorrer ao usar HTTPS em comparação ao HTTP simples. Quando você faz uma solicitação usando HTTPS, é necessário um handshake para verificar a autenticidade da solicitação. Esse handshake é uma etapa extra quando comparado a uma solicitação HTTP e, infelizmente, incorre em alguma sobrecarga.

Para entender as implicações no desempenho e verificar se o impacto no desempenho seria significativo ou não, usei este site como uma plataforma de teste. Fui até o webpagetest.org e usei a ferramenta de comparação visual para comparar o carregamento deste site usando HTTPS vs HTTP.

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

Seu site pode ser diferente e é importante testá-lo completamente e verificar o impacto no desempenho envolvido na mudança para HTTPS.

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 jmeter, em um ambiente controlado, com e sem SSL, deverá obter uma comparação precisa do custo relativo. Eu estaria interessado nos seus resultados.

O HTTPS possui sobrecarga de criptografia / descriptografia, portanto será sempre um pouco mais lento. A terminação SSL consome muito CPU. Se você possui dispositivos para descarregar SSL, a diferença de latências pode ser quase imperceptível, dependendo da carga em que seus servidores estão.

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

Se você estiver 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.

O HTTPS realmente afeta a velocidade da página ...

As citações acima revelam a tolice de muitas pessoas sobre segurança e velocidade do site. O handshaking do servidor HTTPS / SSL cria uma paralisação inicial na conexão com a Internet. Há um atraso lento antes que qualquer coisa comece a renderizar na tela do navegador do visitante. Esse atraso é medido nas informações de tempo até o primeiro byte.

A sobrecarga do handshake HTTPS aparece nas informações de tempo até o primeiro byte (TTFB). O TTFB comum varia de menos de 100 milissegundos (melhor caso) a mais de 1,5 segundos (pior caso). Mas, é claro, com HTTPS é 500 milissegundos pior.

As conexões 3G sem fio de ida e volta podem ter 500 milissegundos ou mais. As viagens extras duplicam o atraso para 1 segundo ou mais. Esse é um grande impacto negativo no desempenho móvel. Más notícias.

Meu conselho, se você não estiver trocando dados confidenciais, não precisará de SSL, mas se gosta de um site de comércio eletrônico, basta ativar o HTTPS em determinadas páginas em que dados confidenciais são trocados, como Login e checkout.

Fonte: Pagepipe

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 o HTTP / 2.0, em média, 4-5 vezes mais rápido que o HTTP / 1.1. Além disso, nos sites que implementam HTTPS, a maioria o faz através do 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 o 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 o HTTPS.

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

HTTPS sobre HTTP / 1.1:

• Tempo médio de carregamento da página 0,47 segundos
• 0.05 segundos mais lento que HTTP sobre HTTP / 1.1
• 0,37 segundos mais lento que HTTPS sobre HTTP / 2.0

HTTP sobre HTTP / 1.1

• Tempo médio de carregamento da página 0,42 segundos
• 0.05 segundos mais rápido que HTTPS sobre HTTP / 1.1
• 0,32 segundos mais lento que HTTPS sobre HTTP / 2.0

HTTPS sobre HTTP / 2.0

• Tempo médio de carregamento de 0,10 segundos
• 0.32 segundos mais rápido que HTTP sobre HTTP / 1.1
• 0.37 segundos mais rápido que HTTPS sobre HTTPS / 1.1