Layer 4 load balancing uses information defined at the networking transport layer (Layer 4) as the basis for deciding how to distribute client requests across a group of servers. For Internet traffic specifically, a Layer 4 load balancer bases the load-balancing decision on the source and destination IP addresses and ports recorded in the packet header, without considering the contents of the packet.
There are seven networking layers in all, defined by the Open Systems Interconnection [OSI] Reference Model. For more information, see Layers in the OSI and Internet Models below.
For more information about load balancing, see Application Load Balancing with NGINX Plus.
Today the term “Layer 4 load balancing” most commonly refers to a deployment where the load balancer’s IP address is the one advertised to clients for a web site or service (via DNS, for example). As a result, clients record the load balancer’s address as the destination IP address in their requests.
When the Layer 4 load balancer receives a request and makes the load balancing decision, it also performs Network Address Translation (NAT) on the request packet, changing the recorded destination IP address from its own to that of the content server it has chosen on the internal network. Similarly, before forwarding server responses to clients, the load balancer changes the source address recorded in the packet header from the server’s IP address to its own. (The destination and source TCP port numbers recorded in the packets are sometimes also changed in a similar way.)
Layer 4 load balancers make their routing decisions based on address information extracted from the first few packets in the TCP stream, and do not inspect packet content. A Layer 4 load balancer is often a dedicated hardware device supplied by a vendor and runs proprietary load-balancing software, and the NAT operations might be performed by specialized chips rather than in software.
Layer 4 load balancing was a popular architectural approach to traffic handling when commodity hardware was not as powerful as it is now, and the interaction between clients and application servers was much less complex. It requires less computation than more sophisticated load balancing methods (such as Layer 7), but CPU and memory are now sufficiently fast and cheap that the performance advantage for Layer 4 load balancing has become negligible or irrelevant in most situations.
Layer 7 load balancers operate at the highest level in the OSI model, the application layer (on the Internet, HTTP is the dominant protocol at this layer). Layer 7 load balancers base their routing decisions on various characteristics of the HTTP header and on the actual contents of the message, such as the URL, the type of data (text, video, graphics), or information in a cookie.
Taking into consideration so many more aspects of the information being transferred can make Layer 7 load balancing more expensive than Layer 4 in terms of time and required computing power, but it can nevertheless lead to greater overall efficiency. For instance, because a Layer 7 load balancer can determine what type of data (video, text, and so on) a client is requesting, you don’t have to duplicate the same data on all of the load-balanced servers.
Modern general-purpose load balancers, such as NGINX Plus and the open source NGINX software, generally operate at Layer 7 and serve as full reverse proxies. Rather than manage traffic on a packet-by-packet basis like Layer 4 load balancers that use NAT, Layer 7 load balancing proxies can read requests and responses in their entirety. They manage and manipulate traffic based on a full understanding of the transaction between the client and the application server.
Some load balancers can be configured to provide Layer 4 or Layer 7 load balancing, depending on the nature of the service. As mentioned previously, modern commodity hardware is generally powerful enough that the savings in computational cost from Layer 4 load balancing are not large enough to outweigh the benefits of greater flexibility and efficiency from Layer 7 load balancing.
NGINX Plus and NGINX are the best-in-class load balancing solutions used by high-traffic websites such as Dropbox, Netflix, and Zynga. More than 350 million websites worldwide rely on NGINX Plus and NGINX Open Source to deliver their content quickly, reliably, and securely.
As a software-based load balancer, NGINX Plus is much less expensive than hardware-based solutions with similar capabilities. The comprehensive load balancing capabilities in NGINX Plus enable you to build a highly optimized application delivery network.
When you insert NGINX Plus as a load balancer in front of your server farm, it increases your entire website’s efficiency, performance, reliability, and scale. NGINX Plus helps you maximize both customer satisfaction and the return on your IT investments.
For Internet traffic, referring to “Layer 4” and “Layer 7” load balancing is a convenient shorthand, but not strictly accurate. If you’re interested, read on.
The notion of seven networking layers comes from the Open Systems Interconnection (OSI) Reference Model. The model separates network functions into seven abstracted layers, commonly referred to by their numbers (Layer 1 through Layer 7). At each layer there are standards that define how data is packaged and transported. Among other things, the standards define how to segment the stream of bits that constitute a request or response into discrete packages called protocol data units (PDUs). The standards also define the metadata added to each PDU in the form of a header; the metadata might specify the addresses of the origin and destination hosts, for example.
Assigning different aspects of network functionality to different layers simplifies the processing at each layer, because a protocol only has to know how to deal with its own layer’s PDUs, and what metadata to include in the header so that the protocols at the adjacent layers can repackage the PDUs at their own level of data segmentation.
The distribution of network functions among the basic protocols for traffic on the World Wide Web – which are collectively referred to as the Internet protocol (IP) suite – does not conform exactly to the OSI model. This is because the IP suite was defined and implemented before the finalized OSI model was published in 1984. Nonetheless, the various protocols in the IP suite do perform distinct functions that roughly correspond to OSI layers.
There are multiple protocols defined at each level, but the following are the protocols and levels relevant to load balancing of website traffic:
As this list makes clear, referring to “Layer 4 load balancing” of Internet traffic is a convenient shorthand, but the more accurate term is “Layer 3/4 load balancing” – because the load balancer bases its decision on both the IP addresses of the origin and destination servers (Layer 3) and the TCP port number of the applications (Layer 4). The more exact term for “Layer 7 load balancing” might be “Layer 5 through 7 load balancing” because HTTP combines the functions of OSI Layers 5, 6, and 7.