When you just pointed people at servers based on their source address, it was pretty easy to keep them going to the same server all the time. Now that you’re directing people according to web page addresses and type of content, it’s more difficult to keep control. But there are times when it’s vital that just one server handles all of a user’s transactions for the length of that session. The obvious one is online shopping. Regardless of how the user jumps about looking at brochure content, their shopping cart entries have to go to the same place all the time. This is known as persistence.

Persistent load balancing can be achieved using IP address hashing (see Content Switching) or the use of cookies - the latter being the more flexible. If the server application isn’t written to insert/request cookies, most content switches can do it transparently, putting the control with the network team rather than the software developers: however if your company has an ecommerce site, it’s pretty certain that this will be done at the server.

The problem here is that if you’re running secure HTTP - which is more than likely on an ecommerce site where you’re exchanging financial and personal information - the cookie is within the encrypted SSL payload, so the content server can’t see it to action it.

One option here is not to run SSL straight through to the servers, but to offload it onto a dedicated device connected to the content switch, or indeed, as some manufacturers offer, an SSL processing engine within the switch itself. This relies on the fact that the network between the switch and the servers is secure, and that incorporating this functionality into the switch, or configuring it to redirect secure traffic to another device doesn’t impact performance. It does have the benefit for the servers that it removes all the SSL processing impact, thus freeing up the servers to concentrate on serving data.

Before a client issues a GET request, there is a TCP handshake process between the client and server. Now with Layer 4 load balancing, these packets contain all the addressing information needed to allow the content switch to pass the handshake traffic straight through to the server. If the load balancing decision is to be made based on HTTP header information, though, which won’t be sent until after the handshake is complete, the switch will have to in effect proxy that process, negotiate with the client, find out what information it needs, decide on the best server, and then carry out a handshake with the server, pretending it’s the client. All while keeping TCP sequence numbers in order on both sides. This is what’s known as delayed binding, and it’s a prerequisite to Layer 7 load balancing.

And that’s not the end of the handshaking the switch will have to do. The client will assume that it is always communicating with the same server. If this transaction doesn’t require persistence, they may well not be, so the switch will have to bring up a TCP session to every new server it sends traffic to, while tearing down connections that are no longer required.

All of which adds to a fair bit of processing. And explains why Layer 7 load balancers are more powerful, more complex - and more expensive - than those that use purely addressing information to make their decisions.