The Next Generation of Traffic Management

Today’s IT departments face enormous challenges in optimizing their networks to deliver complex Web-based applications to a growing base of end-users. In addition, common-sense business constraints and security-conscious end-users mandate that these applications be secure so that communications remain private. But as these applications have become a “business-critical” component to the growth of companies, the required levels of availability, performance, and network scalability are not being met.

To date, no single technology addresses these challenges. Instead, IT managers have been forced to introduce significant complexity, latency and cost to their networks as they attempt  to cobble together solutions from multiple point products. As a result, businesses have compromised both the protection and secure delivery of their applications, and pay the price of degraded end-user responsiveness and network performance.

NetScaler’s patented Request Switching technology solves all of these problems. By inspecting and directing incoming traffic based on the client request, Request Switching delivers applications in an accelerated, secure, and optimized manner.

Traffic management originated with the need to distribute Web

traffic across different servers to enable more efficient utilization

of site resources and increase overall site availability. In a properly

configured and managed site, servers are configured so that if

one server in a server farm goes down, the other servers are able

to continue servicing user requests, shielding users from the

server failure.

The first stage in the evolution of traffic management was the

use of round-robin DNS. With this technique, the IP addresses

of multiple servers are bound to a DNS name. When clients

request the address associated with the DNS name, the DNS

server responds with each server address in turn. In this manner,

client traffic is spread among all the servers. This approach,

while a good first step, did not provide the ability to monitor

server state therefore leading to non-uniform load distribution.

With unequal load distribution, some servers overloaded, with

server requests being directed to failed servers, resulting in

unacceptable service levels for clients and poor scalability for

content providers.

To address some of the deficiencies of the round-robin

DNS approach, traffic management evolved to server load

balancers based on connection-level traffic management.

Products in this category typically use a pass-through model

in which modifications are made to client packets in order to

route them to the appropriate servers. While these products

were an improvement over earlier solutions, they were not able

to efficiently process individual requests. Rather, they made a

single, key decision for all of a particular client’s connections

based solely on the first individual request received. The result

was that connections were bound to a specific server based on

a pre-configured load balancing algorithm, and the effect was

non-uniform load distribution and server overload.

The next step in the evolution of traffic management brought

products that make traffic distribution decisions at the content

level. Traffic managers in this category take a deeper look

within the packet data payload, but still distribute requests at

the connection level. However, since most content switching

devices still use the pass-through model, they are unable

to accommodate HTTP 1.1’s connection keep-alive feature.

Because content switches must make a switching decision

before a connection is forwarded to a server, they cannot affect

requests that occur on an already-established connection. This

means that each connection can only contain one request

in order for content switching to be effective. By restricting

connections to one and only one request, content switches

preclude the connection keep-alive benefits of reduced TCP

connection load for servers and improved response time for

clients. In addition, due to the deeper inspection required

for making a switching decision based on content, content

switching is often much slower than connection-based load

balancing.

Learn More>>

IT News

NetScaler