Quanto sobrecarga o SSL impõe?

Sei que não há uma resposta única e definitiva, mas existe uma estimativa genérica de ordem de magnitude aproximada para a sobrecarga de criptografia do SSL versus a comunicação de soquete não criptografada? Estou falando apenas do processamento da comunicação e do tempo de ligação, sem contar o processamento no nível do aplicativo.

Atualizar

Há uma pergunta sobre HTTPS versus HTTP , mas estou interessado em olhar mais baixo na pilha.

(Substituí a frase "ordem de grandeza" para evitar confusão; eu a estava usando como jargão informal, e não no sentido formal do CompSci. É claro que se eu tivesse falado formalmente, como um verdadeiro nerd, eu estaria pensando em binário em vez de decimal! ;-)

Atualizar

Por solicitação no comentário, suponha que estamos falando de mensagens de bom tamanho (intervalo de 1 a 10 k) em conexões persistentes. Portanto, a configuração da conexão e a sobrecarga de pacotes não são problemas significativos.

Ordem de magnitude: zero.

Em outras palavras, você não verá sua produtividade cortada pela metade ou algo parecido quando adicionar o TLS. As respostas para a pergunta "duplicada" se concentram muito no desempenho do aplicativo e em como isso se compara à sobrecarga do SSL. Esta pergunta exclui especificamente o processamento do aplicativo e procura comparar apenas não SSL com SSL. Embora faça sentido ter uma visão global do desempenho ao otimizar, não é isso que esta pergunta está perguntando.

A principal sobrecarga do SSL é o handshake. É aí que a criptografia assimétrica cara acontece. Após a negociação, são usadas cifras simétricas relativamente eficientes. É por isso que pode ser muito útil habilitar sessões SSL para o seu serviço HTTPS, onde muitas conexões são feitas. Para uma conexão de longa duração, esse "efeito final" não é tão significativo e as sessões não são tão úteis.

Aqui está uma anedota interessante. Quando o Google mudou o Gmail para usar HTTPS, nenhum recurso adicional foi necessário; sem hardware de rede, sem novos hosts. Apenas aumentou a carga da CPU em cerca de 1%.

Segundo @erickson: A penalidade pura da velocidade de transferência de dados é desprezível. As CPUs modernas atingem uma taxa de transferência de criptografia / AES de várias centenas de MBit / s. Portanto, a menos que você esteja no sistema com recursos limitados (telefone celular), o TLS / SSL é rápido o suficiente para coletar dados.

Mas lembre-se de que a criptografia torna o cache e o balanceamento de carga muito mais difíceis. Isso pode resultar em uma enorme penalidade de desempenho.

Mas a configuração da conexão é realmente uma rolha de exibição para muitos aplicativos. Em baixa largura de banda, alta perda de pacotes e conexões de alta latência (dispositivo móvel no campo), as viagens de ida e volta adicionais exigidas pelo TLS podem tornar algo lento em algo inutilizável.

Por exemplo, tivemos que abandonar o requisito de criptografia para acessar alguns de nossos aplicativos Web internos - eles eram quase inutilizáveis ​​se usados ​​na China.

Supondo que você não conte a configuração da conexão (como você indicou na atualização), isso depende muito da cifra escolhida. A sobrecarga da rede (em termos de largura de banda) será insignificante. A sobrecarga da CPU será dominada pela criptografia. No meu Core i5 móvel, posso criptografar em torno de 250 MB por segundo com o RC4 em um único núcleo. (RC4 é o que você deve escolher para obter o desempenho máximo.) O AES é mais lento, fornecendo "apenas" cerca de 50 MB / s. Portanto, se você escolher cifras corretas, não conseguirá manter um único núcleo atual ocupado com a sobrecarga de criptografia, mesmo se você tiver uma linha de 1 Gbit totalmente utilizada. [ Editar : RC4 não deve ser usado porque não é mais seguro. No entanto, o suporte ao hardware da AES agora está presente em muitas CPUs, o que torna a criptografia AES realmente rápida nessas plataformas.]

O estabelecimento da conexão, no entanto, é diferente. Dependendo da implementação (por exemplo, suporte ao TLS false start), ele adiciona viagens de ida e volta, o que pode causar atrasos visíveis. Além disso, a criptografia cara ocorre no primeiro estabelecimento de conexão (a CPU mencionada acima só pode aceitar 14 conexões por núcleo por segundo se você usar bobagens chaves de 4096 bits e 100 se usar chaves de 2048 bits). Nas conexões subsequentes, as sessões anteriores geralmente são reutilizadas, evitando a criptografia cara.

Então, para resumir:

Transferência na conexão estabelecida:

• Atraso: quase nenhum
• CPU: insignificante
• Largura de banda: insignificante

Primeiro estabelecimento de conexão:

• Atraso: viagens adicionais de ida e volta
• Largura de banda: vários kilobytes (certificados)
• CPU no cliente: média
• CPU no servidor: alta

Estabelecimentos de conexão subsequentes:

• Atraso: ida e volta adicional (não tenho certeza se um ou vários, pode depender da implementação)
• Largura de banda: insignificante
• CPU: quase nenhum