When it comes to speeding up content delivery, Web administrators want it all. While they’ve relied on Web server load balancers to address ever-increasing loads on high-traffic sites, these switches don’t generally address other acceleration and security requirements. Enter a new class of specialized devices from Array Networks, NetScaler and Redline Networks.
When it comes to speeding up content delivery, Web administrators want it all. Until recently they couldn’t get it.
While they’ve relied on Web server load balancers to address ever-increasing loads on high-traffic sites, these switches don’t generally address other acceleration and security requirements. Enter a new class of specialized devices from Array Networks, NetScaler and Redline Networks (see Clear Choice Test).
What to call these new boxes – as well as what constitutes an appropriate feature set – is open to debate, given the immaturity of the market space. Vendors are toying with the term application front-end devices in an attempt to promote how they might improve the delivery of all applications within the corporate enterprise network. But this moniker does not indicate that the devices are best suited, at least for now, toward improving the delivery of Web-based applications. So for now, we’re calling them Web front-end devices.
Most Web front-end devices focus on speed, scale and security. Features such as URL rewriting that can clean up complex URLs for usability or to improve search engine ranking are useful to an owner or a complex Web application. But other features included in these boxes – such as SSL VPN – seem out of place for fronting a Web farm. These features could be useful if the device is meant for a variety of other duties on the edge of the network, though.
Scale: Load balancers, Take 2
Traditional load balancers evenly distribute traffic among a group of Web servers based on simple metrics such as round robin, least load and fastest network response. Web front-end devices typically offer the same feature, but their load and health checks are performed higher up in the protocol stack. For example, these boxes might look at HTTP response time for an entire transaction to determine speed, while traditional load balancers might look at simpler TCP level type response time.
Web front ends also can be used to improve the utilization of back-end servers. Typically Web servers might have to maintain numerous user requests at once or have to address dozens of requests from one user for a typical Web page. The Web server might be tied up with network duties long after a request is served because it cannot terminate connections until the client receives the last packet acknowledgment. The devices can improve server utilization by terminating and multiplexing TCP and HTTP connections.
With a feature called TCP offload or connection multiplexing, a Web front-end device can set up multiple TCP connections to a back-end Web server and channel numerous client requests over these connections. These devices also might be able to make one HTTP request for an object and cache the result for multiple responses like a traditionally reverse-proxy cache. A Web front-end box can further reduce server load by offloading CPU-intensive duties such as SSL encryption/decryption and have features that help buffer load in surge conditions, holding connections for later fulfillment, and keeping the back-end farm from hitting a critical load.
Scale is not speed
As valuable as these features are, don’t confuse them with site acceleration. While these server-offloading techniques might seem to speed things up because they reduce load on an oversaturated server, they are just allowing your existing hardware to handle more traffic, more efficiently.
When it comes to increasing Web performance there are two simple rules: deliver less data and deliver it less often. When employed properly these basic principles result in faster page loads and better bandwidth utilization.
Web front-end devices hone in on the first rule in the form of HTTP compression. Nearly all Web browsers support HTTP encoding using either the Gzip or deflate compression algorithms. Browsers indicate their preferences for compressed content using the HTTP header accept-encoding mechanism in a request packet. A Web front-end device will compress the content if possible before returning it. HTTP compression is generally only used on textual content like plain text files, (X)HTML, XML, Cascading Style Sheets and JavaScript, although you also might see it used in conjunction with more text-heavy formats for Microsoft Word, PowerPoint and PDF files.
HTTP compression can result in size reduction of more than 70% in many cases, but this might not translate into significant overall savings, depending on the composition of a delivered Web page. It’s more likely that overall savings for a typical page will not exceed more than 20% to 30%.
While HTTP compression helps, it might not necessarily let end users see pages faster, particularly within low latency LAN/WAN environments. Unless the objects are pre-compressed and cached, there generally will be a longer time to first byte (TTFB) with compressed pages. Of course, the time to last byte (TTLB) will be shorter. However, in a LAN environment the TTFB generally will be more noticeable to the user given that the difference in TTLB between compressed and uncompressed content will be very small, and likely undetectable by users. On a long latency connection like a dial-up line or over long distances, compression will significantly improve page-load times for end users, as the reduced TTLB should be very noticeable.
Security: Don’t give up your firewall
These devices also can improve site security. Because they terminate the network with users rather than the origin server, they often are well equipped to address denial-of-service attacks. Also, because they are forwarding requests to origin servers, they can perform request filtering and deny bad HTTP requests before they are sent on to the origin server. Unfortunately, most of these products do not offer a significant library of attack signatures, so administrators are forced to add their own. Finally, because requests are terminated and forwarded to origin servers, it often is possible for the Web front-end device to reduce the “fingerprinting” of an origin server, thus helping to camouflage it from hacker reconnaissance and potentially reduce future attacks.
The future of Web front-end products?
The future for these Web front-end devices can go either way.
Connection multiplexing, in particular, should be considered a must-have for any product sitting in front of a Web farm. Already, traditional load-balancing vendors including F5 Networks are including such features in their latest offerings. Compression is also something that vendors have realized is free bandwidth savings for the taking and should be included in their offerings.
However, while the features provided by these devices are useful, they point out fundamental problems with Web servers (see low-cost alternatives). Web servers should be better optimized for network connections, utilize compression and caching, filter requests better and have specialized crypto hardware, if necessary. Yet for those who have existing traffic headaches and not enough time and energy to improve their servers directly, these products can offer some instant relief and ROI.
Back to review: “Web site front-end devices”
