What affect does SSL have on the way load balancing works?

Using SSL in terms of load balancing, you get a couple of options:

• Use a load-balancer that is your SSL/TLS endpoint. In this case, the load-balancing will be done at the HTTP level: the client connects to the load-balancer and the load-balancer unwraps the SSL/TLS connection to pass on the HTTP content (then in clear) to its workers. In that case you don’t need to install SSL cert on each app server/worker node.
• Use a load-balancer at the TCP/IP level, which redirects entire the TCP connection directly to a worker node. In this case, each worker node would have to have the certificate and private key (which isn’t necessarily a problem if they’re administered consistently). Using this technique, the load balancer doesn’t do any HTTP processing at all (since it doesn’t look within the SSL/TLS connection): on the one hand this reduces the processing done by the load-balancer itself, on the other hand it would prevent you from dispatching to a particular worker node based on the URL structure for example. Both methods have their advantages and disadvantages.

A disadvantages of the second method are:

1. the load balancer cannot see the HTTP request inside of all of that SSL and cannot add a header stating the real client IP; so to the web server, it will look as though all requests come from a single web client: the IP address of the load balancer itself.
2. the load balancer would not be able to use cookie based HTTP session affinity, since the cookies would be part of the encrypted data not visible to the load balancer. This means that different web servers would sometimes be getting HTTP requests for the same HTTP session, which has significant ramifications for the web server code