February 2001

Web Switching For High Performance E-Business

BY TONY RYBCZYNSKI

Enterprises have been driven to deploy hundreds of specialized and general purpose Web servers to meet the demands of today's rapidly growing e-business world. Managing content and making this complexity totally transparent to end users has been a challenge.

THE PROBLEM IS IN THE CONTENT
Technically, while the use of content- and function-specific server appliances drives the need for content segregation, the need to be able to route the information (at Layer 3) across the Internet drives the representation of all these servers collectively by a single virtual IP address. For example, dynamic Web content, video streaming, and graphic compression are best hosted on high-performance servers optimized for executing scripts and applets. Conversely, static content such as logos, templates, and the like can be hosted on low-end servers with large storage capacity to reduce costs. In short, virtualization and content segregation of Web servers drives the need for Web switching, providing intelligent (Layer 4 and above) routing of user requests to the correct content locations. Web switching is typically implemented at the server farms close to the application.

Two other factors complicate the implementations of Web switching. First, with the widespread use of proxies at Internet access points, repeated requests generated by an end user to the same Web site may actually carry different source IP addresses. This gets in the way of providing any sort of service continuity. To solve this problem, many Web sites insert electronic "cookies," representing unique user identifiers, into new visitors' browsers. The browser will automatically transmit the cookie in subsequent visits to a given Web site. Web switches must have the ability to recognize these cookies and direct requests to the appropriate server.

Second, new multimedia applications such as streaming and IP telephony use separate channels for transmitting control and data traffic between a client and a server. To properly route these applications to the right servers, a Web switch must parse the control channels to extract the dynamic socket numbers for the data channels, so related control and data channels can be processed as a single, logical session.

DELIVERING THE GOODS
To manage and switch application sessions correctly, Web switches need to not only look deep into the packet header but also, in some cases, keep track of the state of the user's session. They have to handle hundreds of thousands of sessions every second, and do this reliability without dropping packets and incurring noticeable delay. A good way to understand what Web switches do is to actually look at what benefits they deliver.

Web switches ease the content management challenges at large Web sites by allowing partial instead of entire content mirroring on each server, and making it easy for e-businesses to deploy servers optimized for specific content types or processing functions.

Web switches ensure persistent application support and transaction integrity by parsing content and accurately associating consecutive requests from a user. Applications such as shopping cart, payment transactions, and multi-page forms require persistent connections. This means a client must constantly talk to the same real server for the duration of the transaction, which typically spans multiple TCP connections. In some environments, the only reliable way to match multiple connections to the same user is by matching the cookies embedded in non-secure HTTP connections or the SSL (Secure Socket Layer) session identifiers embedded in secure HTTP-S sessions. If a client-server association is not persistent, then it will result in broken interactions (e.g., shopping carts) and disgruntled users.

Even if an application doesn't break when visitors are sent to different servers during the course of a transaction, there are other reasons for persistent sessions. Servers store recently accessed information in memory. Retrieving information from local memory is many times faster than retrieving it from a back-end database or hard drive. A content-intelligent Web switch can send successive requests with the same cookie to the same server, taking advantage of server cache memory to improve server efficiency and performance. Where cache servers are used, the Web switch can intelligently filter incoming client requests to avoid passing irrelevant requests to the cache servers. For example, requests for dynamic content, requests with embedded cookies, requests other than HTTP GET, etc., can be forwarded directly to the original server to reduce unnecessary load on the cache servers.

HTTP version 1.1 allows multiple HTTP transactions to be transported over a single TCP connection to reduce TCP processing overhead. A Web switch with no content intelligence will forward all HTTP 1.1 requests on each TCP connection to a single server. In contrast, a content-aware Web switch can forward each request within the TCP connection to a different server, increasing load distribution granularity. This optimizes resource utilization and speeds overall Web site performance.

In order to provide preferential services based on user categories (e.g., highly profitable customers versus occasional browsers), a Web switch needs to enforce the appropriate bandwidth and jitter characteristics for transporting different content types, by being URL-aware and supporting comprehensive traffic management capabilities. Without cookie and URL awareness, traffic classification, and hence quality of service, can only be applied at gross levels such as per IP address or application port.

As the amount of content grows and information is distributed across different server farms, the Web switch's responsibilities expand to provide content routing and load balancing across a distributed network.

PARSING AND PROCESSING
Web switches have to scan through session traffic for a specific string of varying lengths, and in unpredictable locations, to extract content identifiers such as URLs and cookies. Parsing content requests means temporarily terminating the TCP connection from a client. In other words, the Web switch must first pretend that it is the server, ask the client what it wants, examine the request, and then open a connection to an appropriate server. While this is happening, the Web switch must temporarily buffer the request, which consumes system memory. This temporary termination is called a "delayed binding." With delayed binding, two independent TCP connections span a Web session: one from the client to the Web switch and the second from the Web switch to the selected server. The Web switch must modify the TCP header, including performing TCP sequence number translation and recalculating checksums on every packet that travels between the client and the server, for the duration of the session. This latter function, known as "TCP connection splicing," heavily tasks a Web switch, particularly when the switch must process thousands of these sessions simultaneously.

In addition to real-time traffic and connection processing, a Web switch needs to monitor the servers to ensure that requests are forwarded to the best performing and healthy servers. This monitoring involves more than simple ICMP (Internet Control Message Protocol) or TCP connection tests. Since content is often segregated across different servers in a server farm, the Web switch must provide a flexible, user-customizable mechanism, allowing a relevant set of application and content tests to be applied to each server or server farm.

To fulfill the requirements described above, a Web switch needs to perform numerous processing tasks for each incoming session, including connection setup, traffic parsing, applying server selection algorithms, splicing connections and translating session addresses, metering and controlling server bandwidth usage, processing traffic filters, collecting statistics, and so on. Not only are these functions CPU-intensive, they are executed whenever a new request arrives. In addition, the switch must also perform background functions such as updating network topology, health-checking servers, applications and server sites, measuring server performance, etc., on a periodic basis.

Imagine the processing load that the Web switch has to bear during a flash crowd when millions of requests flood a site within a 15-minute period! Consequently, a Web switch is fundamentally different from a conventional packet switch in that high performance and availability is dependent on powerful software processing capabilities, in addition to massive switch fabric capacity.

WEB SWITCHING: A CRITICAL COMPONENT FOR THE SECOND WAVE OF E-BUSINESS
Web switching has evolved with the Web, and in fact the explosion in Web traffic associated with the first wave of e-business has only been possible because of Web switching. As the industry moves from browsing and simple transactions to return-on-relationship-driven omnimedia collaboration (the second wave), Web switching will become even more critical. The value proposition includes better use of critical server resources on a global basis, the ability to offer differentiated customer service, higher reliability, and optimized use of server resources. State-of-the-art Web switches are built on distributed processing architectures for operation at multi-gigabit speeds, supporting bullet-proof persistence services and granular traffic classification.

Tony Rybczynski is director of strategic marketing and technologies for Nortel Networks' Enterprise Solutions unit. E-mail questions or comments to tonyryb@nortelnetworks.com.

[ Return To The February 2001 Table Of Contents ]