Content (or Layer 7) switching was all the rage in the late 1990s - the biggest and most outrageously-priced deals during the last gasps of the dotcom boom involved the sale of content switching companies such as Arrowpoint and Alteon. Now Sun has just bought Nauticus, a content switching company, to put the technology into its servers. So is the edge of the network the right place to switch content? An Ethernet switch adds efficiency to a network by providing a barrier between traffic and the network segments it doesn't need to go down. A packet entering on port A, which the switch knows is destined for a machine on port B, is passed only to port B, not to any other port on the switch and thus overall network traffic levels are kept to a minimum. Ethernet switches work, of course, at layer 2 in the ISO model. Over the past few years, increases in the speed of microprocessors and improvements in the technology of custom ASICs have made network devices more powerful and have enabled them to realistically extend the traffic-passing decisions they make up through the ISO layers. (The higher up the ISO stack you go, the more work there is to do, and the more complex the circuitry is, so the hardware technology has been the main constraint over the years). What is content switching?
Content switching, then, is the ability for a device to examine each traffic stream as it comes in and pass the request to the appropriate back-end machine(s) for the request, whatever it is, to be fulfilled. At the most basic level a content switch may be told to forward all HTTP requests for items that look like graphics to server A, and all HTTP requests that look like HTML page requests to server B. One can, of course, take the concept to extremes and start digging more deeply into the data streams in order to make much more fine-grained forwarding decisions. Load balancing
One of the higher-layer content switching functions is load-balancing. It's very common to want to have a number of Web servers dealing with incoming requests, particularly because the trend over the past few years is to put more and more intelligence into the building of pages. Whereas in the old days, dishing up a static HTML page was a case of opening a text file and squirting it down the wire, the ubiquity of PHP, ASP and other such Web programming languages has placed a much greater load on the Web server, as it now has to parse and compile program code and perform potentially complex logic, loops and database lookups in order to generate the HTML text that will be sent to the receiver. So, where we used to have a single Web server, we now often have two or three, at the very least, sharing the load. Where does content switching belong?
The obvious place, at first glance, is to put a content switch is at the edge of the network, so that it can make the forwarding decision as early as possible. In the context of what you might consider the "pure" definition of content switching this is the right thing to do, since the switch can make the decision regarding how to forward the traffic with no external intervention at all. The crunch comes, however, when you look at some of the lower-level aspects of the content switching task, not least session preservation and server loading. Session preservation is all to do with ensuring that the server that receives a particular request stream is aware of the context of that stream. If, for instance, your site is based on ASP or PHP, the server can generate a "session cookie" which is used to pass state information (your user ID, perhaps, or some reference into a database table listing the products you've browsed in this session). However, unless you implement potentially complex mechanisms for your servers to exchange session information, no server knows anything about sessions generated by others, and so it's up to the content switch to ensure that all transmissions relating to a given session are always routed to the same server. Server loading is another factor that's dealt with by most of the load balancing hardware products on the market, to varying extents. Because the load balancers, at least at the basic level, are unable to get accurate ongoing information about the performance of the servers, they use calculations based upon response times and the number of currently active connections that have been passed to each server, in order to decide which machine is likely to be able to best deal with an incoming connection. Content switchblade
With the current trend toward blade-based servers, though, there's an opportunity for the server manufacturers to provide the content switching hardware with direct access to low-level information about the servers' performance. If you have a chassis with a dozen server blades in, there's no reason why you couldn't work with a content switching manufacturer (or, in Sun's case, acquire one outright) to produce a blade that sits in the server chassis and can make its forwarding decisions based on a combination of (a) the session information that it would have even if it were still a stand-alone device; and (b) performance and loading information that it can acquire, on an ongoing basis and in real time, from each server blade via the direct connections that it now has into the server's own hardware. Conclusion
Because the content switching function itself - the deep-level investigation into each incoming request, and the decision of where to route the request - is largely independent of the actual servers doing the work, it could conceivably be left at the "edge" of the network. By bringing the function into the switch chassis, though, you immediately overcome two closely related issues, namely the balancing of the load between servers and the preservation of the session information. In short, then: stand-alone content switches will always work fine, but those that exist as blades in the server chassis will work better.