Does round-robin load balancing affect HTTPS performance

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:

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.)