O balanceamento de carga round-robin afeta o desempenho do HTTPS?

Question

Cenário:

• Web farm pequeno por trás de um balanceador de carga de hardware
• Não há necessidade de afinidade do servidor. Se um servidor ficar inoperante, outro pode e deve assumir.
• Parte do sistema requer HTTPS. Isso é terminado nos servidores. Certificados SSL são instalados em cada servidor.
• Os servidores têm capacidade mais que suficiente, por isso não se preocupe com qual servidor encaminhar uma solicitação (mesmo se um servidor estiver fora de rotação).

Com isso em mente, parecia que a escolha mais óbvia para uma estratégia de balanceamento de carga era uma simples abordagem round-robin. O balanceamento baseado em IP de origem parecia ser difícil de testar, e o balanceamento baseado em cookie não parece funcionar com SSL.

Estou preocupado que os navegadores possam renegociar suas conexões HTTPS cada vez que uma página é atendida por um servidor da Web diferente, tornando o site muito mais lento do que deveria.

Então, minhas perguntas:

1. Isso seria realmente um problema? Ou os balanceadores de carga são inteligentes o suficiente para, de alguma forma, fazer apenas 1 handshake SSL, mesmo quando o conteúdo é servido por vários servidores?
2. Existem ferramentas (Windows) que podem ser usadas para monitorar facilmente handshakes SSL, keepalives de HTTP, etc. ao navegar em um site?
3. Se tivermos um problema aqui, como podemos resolvê-lo? (A solução óbvia, eu acho, é descarregar o SSL em nosso balanceador de carga, mas nosso hardware atual não suporta isso, portanto, quaisquer outras soluções seriam preferíveis nesse estágio.)

Answer 1

Chamadas consecutivas usando keepalives fazem parte do mesmo fluxo TCP, então apenas uma negociação SSL está envolvida, e todas elas devem ir para o mesmo servidor.

Solicitações sem keepalives serão fluxos independentes, cada um exigindo negociação SSL separada.

Então, sim, round-robin deve estar bem.