The problem with HTTP (okay, one of the problems with HTTP, happy now?) is that it resides at the top of the “stack” regardless of whether we identify the “stack” as based  upon the TCP/IP stack or the OSI model stack. In either case, HTTP sits at the top like a a king upon his throne. There’s nothing “higher” than the application in today’s networking models.

But like every good king, HTTP has a crown: the actual application data exchanged in the body of an HTTP transaction. In the good old days, when intermediaries (proxies) were only able to see the protocol portion of HTTP, i.e. its headers, this wasn’t a problem. When someone said “layer 7 switching” we understood it to mean the capability to make load balancing or routing decisions based on the HTTP headers. But then load balancers got even smarter and became “application aware” and suddenly “layer 7 switching” came to represent both load balancing/routing decisions based on HTTP headers or on its payload, i.e. the application data, a.k.a. “content based routing (CBR)” on the software side of the data center.

We have yet to come up with a way to separate the two and clearly distinguish what it is we mean when we say “layer 7” and yet the performance and capacity limits of intermediaries can be impacted significantly by the difference between the two. When configuring some intermediaries you have the ability to specify which type of layer 7 switching you will performing as it requires different behavior on the part of the intermediary. Thus it’s important to understand the difference between layer 7 “protocol” (HTTP and its headers) and layer 7 “application” (data).

Layer 7 (protocol) includes everything “below” it in the stack – TCP ports, IP addresses, etc… – in addition to HTTP protocol attributes, including HTTP headers.

Layer 7 (application) includes everything “below” it in the stack – HTTP protocol, TCP ports, IP addresses, etc… – in addition to the application data being exchanged.  In the case of application switching/load balancing for the protocol only, the intermediary does not need to “wait” for the application data to arrive before making a decision. The HTTP headers are almost always contained in the first few packets exchanged and a decision can be made as soon as all the headers have been received. This can, when considering round trip times and size of data being submitted, shave off response time from the perspective of the application user. It also uses less memory on the intermediary because there is very little buffering required as the headers are received relatively quickly and are limited in number and size. This is important when considering capacity needs/constraints. Completely buffering requests/responses requires a lot more memory than just making decisions based on HTTP headers.

In the case of application switching/load balancing for the application, the intermediary must wait for the application data to arrive before making a decision. While leveraging a streaming strategy, as is often the case with XML-parsing capable intermediaries, can reduce the buffering requirements and the time between submission and a routing decision, if the data upon which the intermediary needs to base its decision is at the end of the application data, and that data is large, then the device must effectively buffer the entire application message before it can make a decision and send the transaction on its way. This results in sessions being held open longer, which impacts the overall capacity of the device in terms of concurrent connections.

If you’re using an intermediary (load balancer) and are only applying layer 7 (protocol) routing capabilities, make sure you’re using – if it’s available – a configuration that matches. If you’re looking at intermediaries now because, well, you’re looking into virtualization and cloud computing models for its elastic scalability and will need a Load balancer as part of that architecture, then ask about how the load balancing solution supports layer 7 switching. And makes sure it recognizes that there’s a difference between layer 7 protocol and layer 7 application routing, and understand which it is you really need to be using.

WILS: Write It Like Seth. Seth Godin always gets his point across with brevity and wit. WILS is an ATTEMPT TO BE concise about application delivery TOPICS AND just get straight to the point. NO DILLY DALLYING AROUND.