Welcome!

If everyone is thinking the same, someone isn't thinking

Lori MacVittie

Subscribe to Lori MacVittie: eMailAlertsEmail Alerts
Get Lori MacVittie via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: SSL Journal, Citrix Virtualization Journal, Apache Web Server Journal, Twitter on Ulitzer, SEO Journal, Facebook on Ulitzer, Marketing and Sales, Microsoft Developer, CIO/CTO Update, Telecom Innovation, The Social Media Guide, DevOps for Business Application Services, DevOps Journal

DevOpsJournal: Blog Feed Post

Y U No Support SPDY Yet?

Mega-sites like Twitter and popular browsers are all moving to support SPDY – but there’s one small glitch in the game plan…

SPDY is gaining momentum as “big” sites begin to enable support for the would-be HTTP 2.0 protocol of choice.

Most recently Twitter announced its support for SPDY:

quote-badgeTwitter has embraced Google’s vision of a faster web and is now serving webpages over the SPDY protocol to browsers that support it.

SPDY is still only available for about 40 percent of desktop users. But with large services like Twitter throwing their weight behind it, SPDY may well start to take the web by storm — the more websites that embrace SPDY the more likely it is that other browsers will add support for the faster protocol.

-- Twitter Catches the ‘SPDY’ Train

But even with existing support from Google (where the protocol originated) and Amazon, there’s a speed bump on the road to fast for SPDY:

quote-badgeThere is not yet any spdy support for the images on the Akamai CDN that twitter uses, and that's obviously a big part of performance. But still real deployed users of this are Twitter, Google Web, Firefox, Chrome, Silk, node etc.. this really has momentum because it solves the right problems.

Big pieces still left are a popular CDN, open standardization, a http<>spdy gateway like nginx, a stable big standalone server like apache, and support in a load balancing appliance like F5 or citrix. And the wind is blowing the right way on all of those things. This is happening very fast.

-- Twitter, SPDY, and Firefox

translation layer spdy sm http

The “big pieces” missing theme is one that’s familiar at this point; many folks are citing the lack of SPDY support at various infrastructure layers (in particular the application delivery tier and load balancing services) as an impediment embracing what is certainly the early frontrunner in the HTTP 2.0 War. While mod_spdy may address the basic requirement to support SPDY at the web server infrastructure layer, mod_spdy does not (and really can not) address the lack of support in the rest of the infrastructure.

Like the IPv4 to IPv6 transition, the move to support SPDY is transitory in nature and counts on HTTP 2.0 adopting SPDY as part of its overhaul of the aging HTTP protocol. Thus, infrastructure must maintain a dual SPDY-HTTP stack, much in the same way it must support both IPv4 and IPv6 until adoption is complete - or a firm cutover date is arrived at (unlikely).

U No Support SPDY because SPDY Support is No Easy

The use of SPDY is transparent to the user. But for IT the process of supporting SPDY is no simple task. To understand the impact on infrastructure first take a look at the typical steps a browser uses to switch to SPDY from HTTP:

  • The first request to a server is sent over HTTP
  • The server-side end-point (server or application delivery service), when it supports SPDY, can reply with an HTTP header 'Alternative-Protocols: 443:npn-spdy/2', indicating that the content can also be retrieved on this server on port 443, and on that port there is a TLS 1.2 endpoint that understands NPN and SPDY can be negotiated
  • Alternatively the server can just 301 redirect the user to an https end-point.
  • The client starts a TLS connection to the port described and when the server-side end-point indicates SPDY as part of the TLS NPN extension, it will use SPDY on that connection.supporting spdy

What this means is that infrastructure must be updated not just to handle SPDY – which has some unique behavior in its bi-directional messaging model – but also TLS 1.2 and NPN (Next Protocol Negotiation). This is no trivial task, mind you, and it’s not only relevant to infrastructure, it’s relevant to site administrators who want to enable SPDY support. Doing so has several pre-requisites that will make the task a challenging one, including supporting TLS 1.2 and the NPN extension and careful attention to links served, which must use HTTPS instead of HTTP.

While you technically can force SPDY to be used without TLS, this is not something a typical user will (or in the case of many mobile platforms can) attempt. For testing purposes, running SPDY without TLS can be beneficial, but for general deployment? SSL Everywhere will become a reality. Doing so without negatively impacting performance,  however, is going to be a challenge.

quote-badgeEstablishing a secure SSL connection requires 15x more processing power on the server than on the client.

-- THC SSL DOS Tool Released

The need to support secure connections becomes a big issue for sites desiring to support both HTTP and HTTPS without forcing SSL everywhere on every user, because there must be a way to rewrite links from HTTP to HTTPS (or vice-versa) without incurring a huge performance penalty. Network-scripting provides a solution to this quandary, with many options available – all carrying varying performance penalties from minimal to unacceptable.

PROS and CONS

Basically, there are a whole lot of pros to SPDY – and a whole lot of cons. Expect to see more sites – particularly social media focused sites like Facebook – continue to jump on the SPDY bandwagon. HTTP was not designed to support the real-time interaction inherent in social media today, and its bursty, synchronous nature often hinders the user-experience. SPDY has shown the highest benefits to just such sites – highly interactive applications with lots of small object transfers – so we anticipate a high rate of early adoption amongst those who depend on such applications to support its business model.

Supporting SPDY will be much easier for organizations that take advantage of an intelligent intermediary. Such solutions will be able to provide support for both HTTP and SPDY simultaneously – including all the pre-requisite capabilities. Using an intermediary application delivery platform further alleviates the need to attempt to deploy pre-production quality modules on critical application server infrastructure, and reduces the burden on operations to manage certificate sprawl (and all the associated costs that go along with that).

SPDY is likely to continue to gain more and more momentum, especially in the mobile device community. Unless Microsoft’s Speed+Mobility offers a compelling reason it should ascend to the top of the HTTP 2.0 stack over SPDY, it’s likely that supporting SPDY will become a “must do” instead of “might do” sooner rather than later.

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.