Existem alguns fatores de retrocesso em relação ao balanceamento de carga HTTPS?

Question

Há algum fator de retrocesso em relação ao balanceamento de carga HTTPS versus o balanceamento de carga HTTP?

Esta pode ser uma razão, por que o HTTPS não se espalha em vários sites? (existem CA's baratas no mercado)

    

Answer 1

Eu não tenho certeza se James está correto. Meu entendimento é que o handshake SSL começa e termina com o par solicitação / resposta. Mesmo que o HTTPS suporte o retorno do TLS via chaves de sessão, essas chaves de retorno estariam no balanceador de carga de front-end com o cliente, que sempre estaria atingindo o mesmo balanceador de carga.

Dito isso, é perfeitamente possível balancear a carga para servidores HTTPS, as razões que a maioria das pessoas não acredita:

• Há uma sobrecarga significativa na descriptografia do SSL. Muitos produtos do balanceador de carga fazem isso em hardware e economizam tempo de computação nos servidores da web (ou servidores de aplicativos em uma configuração de 2 camadas)
• Há mais sobrecarga (dupla, provavelmente) na descriptografia e na criptografia no mesmo dispositivo.
• Requer que você configure certificados válidos internamente, idealmente. Isso não precisa custar nada, mas exigiria dinheiro ou uma CA interna confiável e segura. Simplificando, é mais sobrecarga de gerenciamento.

Answer 2

Não é tanto o custo do certificado (embora isso seja discutível e tende a ser baseado em qual CA está sendo utilizado e que os requisitos de licenciamento da CA), mas o custo dos servidores. O tráfego HTTPS de balanceamento de carga versus tráfego HTTP também não é muito diferente do ponto de vista da implementação. Tudo é orientado pelo custo. O SSL pode ser uma operação dispendiosa do ponto de vista da CPU, tanto para a troca de chaves quanto para a criptografia / descriptografia de dados. O número total de usuários simultâneos que você pode obter de um servidor será menor com HTTPS do que o número total de usuários simultâneos em HTTP, o que significa que você precisará de mais servidores para fazer a mesma coisa.

Embora funcionem muito bem, os dispositivos que descarregam essas operações ssl também podem ser bastante caros.

Web sites "tradicionais" (em oposição a aplicativos da Web) tendem a ter um componente altamente veiculado do site que é estritamente conteúdo de marketing, que é principalmente tráfego anônimo e sem estado. Embora importantes para o negócio, comunicados à imprensa, comunicações de marketing, fichas de especificações de produtos, demonstrações para download ou on-line, etc., são todos projetados para converter esses usuários anônimos em compradores, mas por que criptografar esse tráfego anônimo? Acho que os administradores do site tendem a ver isso como um uso não ideal e desnecessário de recursos de computação.

A Web 2.0, as redes sociais e os aplicativos da Web são diferentes e devem ser criptografados ssl principalmente porque, por sua própria natureza, não há anonimato entre o usuário e o site. Afinal, a primeira coisa que alguém tende a fazer em um Twitter ou Facebook é entrar.

    

Answer 3

Sua pergunta parece um pouco confusa.

Se você quer dizer quais são as desvantagens do HTTPS em comparação com o HTTP, então:

1) é muito mais lento - apesar de a sobrecarga de largura de banda não ser tão boa, o problema de sempre é a latência - o SSL requer pelo menos 2 viagens de ida e volta adicionais por solicitação.

2) Proxies não podem armazenar dados em cache - tornando-os ainda mais lentos

3) Há um impacto significativo em qualquer coisa que queira manipular o processamento - como firewalls de conteúdo e balanceadores de carga

A sobrecarga de processamento não é tão grande - os problemas de desempenho são todos sobre a latência da rede - e terminar o SSL fora do servidor da Web não ajuda.

    

Answer 4

Bem, o HTTPS não é sem estado / sem conexão; o cliente deve retornar ao mesmo servidor para as conexões subsequentes, porque as chaves da sessão são mantidas em cache nesse servidor. Com o HTTP, desde que o conteúdo seja replicado em seus servidores, não importa qual servidor o cliente acessa e eles podem ser enviados para um servidor diferente em solicitações subseqüentes.

Além disso, uma das principais razões pelas quais as pessoas encerram o SSL em um balanceador de carga é economizar custos em certificados; Coloque um certificado no LB, descriptografe o tráfego, passe para seus servidores como HTTP simples e criptografe novamente o tráfego de retorno pelo balanceador de carga.

Sugiro ler mais sobre o processo de handshake SSL / TLS: link