Scenario:
- 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:
- 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?
- Are there any tools (Windows) that one can use to easily monitor SSL handshakes, HTTP keepalives etc when surfing a website?
- 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.)