Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top


  • Small web farm behind a hardware load balancer
  • No need for server affinity. If one server goes down, another can and should take over.
  • Part of the system requires HTTPS. This is terminated at the servers. SSL certificates are installed on each server.
  • The servers have more than enough capacity, so no worries about which server to route a request to (even if one server is out of rotation.)

With this in mind, it seemed like the most obvious choice for a load balancing strategy was a simple round-robin approach. Source IP based balancing seemed it would be difficult to test, and cookie-based balancing doesn't seem to work with SSL.

I'm worried though that browsers might be re-negotiating their HTTPS connections each time a page is served by a different web server, making the website a lot slower than it should be.

So my questions:

  1. Would this indeed be a problem? Or are load balancers clever enough to somehow only do 1 SSL handshake even when content is served from multiple servers?
  2. Are there any tools (Windows) that one can use to easily monitor SSL handshakes, HTTP keepalives etc when surfing a website?
  3. If we do have a problem here, how can we solve it? (The obvious solution I guess is to offload SSL at our load balancer, but our current hardware doesn't support that, so any other solutions would be preferable at this stage.)
share|improve this question
up vote 8 down vote accepted

Consecutive calls using keepalives are part of the same TCP flow, so only one SSL negotiation is involved, and they should all go to the same server.

Requests without keepalives will be independent flows, each requiring separate SSL negotiation.

So yes, round-robin should be fine.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.