Quanta sobrecarga o SSL impõe?

Eu sei que não há uma resposta simples e rápida, mas existe uma aproximação genérica de estimativas de ordem de grandeza para a sobrecarga de criptografia do SSL versus a comunicação de soquete não criptografada? Estou falando apenas sobre o processamento de comunicação e o tempo de transmissão, sem contar o processamento no nível do aplicativo.

Atualizar

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

(Eu substituí a frase “ordem de magnitude” para evitar confusão; eu estava usando isso como um jargão informal e não no sentido formal CompSci. É claro que se eu tivesse querido dizer isso formalmente, como um geek verdadeiro eu estaria pensando binária ao invés de decimal! 😉

Atualizar

Por solicitação no comentário, suponha que estamos falando de mensagens de bom tamanho (faixa de 1k a 10k) 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 taxa de transferência reduzida pela metade, ou algo parecido, ao adicionar o TLS. As respostas à pergunta “duplicada” concentram-se principalmente no desempenho dos aplicativos e em como isso se compara à sobrecarga de SSL. Essa questão exclui especificamente o processamento de aplicativos e procura comparar apenas os não SSL com o SSL. Embora faça sentido ter uma visão global do desempenho ao otimizar, não é isso que essa pergunta está fazendo.

A principal sobrecarga do SSL é o aperto de mão. É aí que a criptografia assimétrica cara acontece. Após a negociação, cifras simétricas relativamente eficientes são usadas. É por isso que pode ser muito útil ativar sessões SSL para 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, não foram necessários resources adicionais. sem hardware de rede, sem novos hosts. Isso só aumentou a carga da CPU em cerca de 1%.

Eu segundo @erickson: A penalidade de velocidade de transferência de dados é insignificante. As CPUs modernas atingem um throughput de criptografia / AES de várias centenas de MBit / s. Portanto, a menos que você esteja em um sistema com resources restritos (telefone celular), o TLS / SSL é rápido o suficiente para inserir dados.

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

Mas a configuração da conexão é realmente um obstáculo para muitas aplicações. Em baixa largura de banda, alta perda de pacotes, 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 descartar o requisito de criptografia para o access a alguns dos nossos aplicativos da Web internos – onde eles seriam inúteis se usados ​​da China.

Assumindo que você não conta a configuração da conexão (como você indicou em sua atualização), isso depende fortemente da cifra escolhida. A sobrecarga de 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 cerca de 250 MB por segundo com o RC4 em um único núcleo. (RC4 é o que você deve escolher para desempenho máximo.) O AES é mais lento, fornecendo “apenas” cerca de 50 MB / s. Portanto, se você escolher as 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. [ Edit : RC4 não deve ser usado porque não é mais seguro. No entanto, o suporte de hardware AES agora está presente em muitas CPUs, o que torna a criptografia AES realmente rápida em tais plataformas.]

O estabelecimento de conexão, no entanto, é diferente. Dependendo da implementação (por exemplo, suporte para início falso de TLS), ele adicionará viagens de ida e volta, o que pode causar atrasos perceptíveis. Além disso, a criptografia dispendiosa ocorre no primeiro estabelecimento de conexão (a CPU mencionada acima só pode aceitar 14 conexões por núcleo por segundo se você usou tolices de 4096 bits e 100 se usa chaves de 2048 bits). Nas conexões subsequentes, as sessões anteriores são frequentemente reutilizadas, evitando a criptografia dispendiosa.

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 de ida e volta adicionais
  • Largura de banda: vários kilobytes (certificados)
  • CPU no cliente: médio
  • CPU no servidor: alta

Estabelecimentos de conexão subseqüentes:

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