So you know about the seven layers of the OSI Network model, but now I hear you ask, “what can it do for me, as a developer?”
One of the key architectural decisions you’ll have to make when building a new networked system is how to apply load balancing. Load balancing is simply the spreading of requests between several servers running the same application, and is normally done at the network architecture level. I’m not going to go into the pros and cons of different strategies, but one thing you should know about is the difference between load balancing at the transport layer (TCP/IP, or Layer 4) and the application layer (Later 7) as this will massively impact how your application is structured, especially if you are using TLS/PKI/HTTPS….
Transport Layer Load Balancing (Layer 4)
Layer four simply concerns itself with delivering packets of data. Remember how I outlined in my previous post that Layer 3 (Network Layer) is like the basic post system, and Layer 4 (Transport Layer) is like the Post Office? Well imagine the load balancing is like sending letters to different PO Boxes owned by the same person and coming under the same postal address. We don’t look inside the letters (at least, we’re not supposed to) but we can clearly see that each one is addressed to that person and can distribute them among that persons PO Boxes either randomly or using some other strategy. It’s simple, quick and content agnostic. Also, because we don’t care about the contents of the letter, if there is any special treatment that needs to be carried out (say, decryption of the contents if it’s a spooky spy letter) it can be carried out where-ever we like -even before the letter gets to the post office! (assuming the network itself is secure at this stage, of course).
Application Layer Load Balancing (Layer 7)
If Layer 3/4 is the postal system, the Layer 7, the application layer, is the point at which all these letters (packets of data) are actually read and utilised -it’s where the actual semantic meaning is reified. It’s HTTP, or Email, or SOAP; it’s the point where all this data is actually used.
And yet, we can still apply load balancing here, but it’s different than Layer 4. Because we are balancing at the application layer and so understand the letters (packets) and can see what they contain, we can employ much more advanced strategies. For example, we can see the query string and the path requested in the requests URL -this allows us to send requests for particular paths to particular servers. We can also see the headers and cookies -this allows us to do things like send all requests with the same SessionId to the same server.
When it comes to HTTPS or SSL encrypted traffic, though, you need to know that you can’t do this at Layer 7 without first decrypting the packets (this is known as SSL Termination). This is not a bad thing -in fact, Layer 7 Load Balancers are often used as secure network endpoints, handling the SSL overhead so that the application servers don’t need to (the forwarded requests to the actual servers would be in plain text/HTTP, and assume that that part of the network is secure).
Layer Seven Load Balancers allow you to offload SSL duties and perform much smarter load balancing (that can incorporate application logic such as sticky session -not that this is a good idea!), and these days are pretty fast (though not as fast Layer 4). They do however locate your SSL termination at a particular point in the network, which is something of a conflict of concerns (where you should load balance and where you should terminate SSL are two very different questions).
Layer 4 Load Balancers are quicker, don’t put any constraints on where you perform your SSL termination, but are limited to how clever they can be and what kind of strategies they can use and what application architectures they can enhance.
So there you have it. There are no right or wrong answers in cases like these, it’s about picking the right solution for your architecture. I hope this has been informative!