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: Cloud Computing, Enterprise Mashups, Twitter on Ulitzer, SEO Journal, Infrastructure 2.0 Journal, Microsoft Developer, Mobile Web Developer, CIO/CTO Update, Telecom Innovation, F5 Networks

Blog Feed Post

The HTTP 2.0 War Has Just Begun

Microsoft takes on Google as the war to win the standard for an overdue overhaul of HTTP starts to pick up steam


It’s also not clear how Speed + Mobility will “retain as much compatibility as possible with the existing Web infrastructure” – a noble and laudable sentiment, to be sure – while still adopting most of the core concepts including in SPDY:

HTTP Speed+Mobility RFC

It [the session layer] would maintain the integrity of the layered architecture.

      It would use an upgrade mechanism similar to that of WebSockets.
      This would enable compatibility with existing proxies and
      connection models, without creating a mandatory dependency on TLS.

      [Same as SPDY] The protocol would define two types of frames: data
      and control.

      [Same as SPDY] The session layer would enable negotiation of
      multiple simultaneous streams for HTTP requests with minimal

      [Same as SPDY] The session layer would allow for prioritizing
      delivery of content to ensure highest value traffic is delivered

There’s not much in the Speed + Mobility RFC on which to base a technical impact assessment on infrastructure (existing proxies and other HTTP mediating devices like load balancers) but what Microsoft appears to be saying is that it wants to leverage the concepts introduced by Google with SPDY (acknowledging their performance and ultimately scaling benefits) without leaving the familiar world of HTTP. That’s actually important, assuming it can be done, because SPDY requires significant changes to existing infrastructure – network and server – in order to operate, and it is not inherently interoperable with HTTP.

Despite this, SPDY interest and inquiries are beginning to become more frequent, which means it’s getting the attention it deserves. Being the only kid on the block to really address the performance issues inherent with HTTP (especially with respect to mobile devices) that’s no surprise as the investment in new solutions to support SPDY would ostensibly see a return in the form of scalability on the server side by requiring fewer server resources to support as many if not more users.

But SPDY isn’t so far along (see previous note) as to be a clear front runner. It’s still too new despite interest to have garnered widespread support or mindshare, and despite Google’s ubiquitous status as a household term for search, it isn’t necessarily synonymous with web standards. Chrome may be gaining on IE, but in the minds of most users, IE is still synonymous with web browsing. It also has a serious advantage over Google in its relationship with the enterprise and IT, and in its more intimate understanding of data center infrastructure, as is evident from its blog on the introduction of its proposal:

quote-badgeWe think that rapid adoption of HTTP 2.0 is important. To make that happen, HTTP 2.0 needs to retain as much compatibility as possible with the existing Web infrastructure. Awareness of HTTP is built into nearly every switch, router, proxy, Load balancer, and security system in use today. If the new protocol is “HTTP” in name only, upgrading all of this infrastructure would take too long. By building on existing web standards, the community can set HTTP 2.0 up for rapid adoption throughout the web.

-- Speed and Mobility: An Approach for HTTP 2.0 to Make Mobile Apps and the Web Faster

Google, while not necessarily openly hostile to the enterprise or infrastructure vendors who’d need to support SPDY, certainly appears indifferent to the impact of a rip-and-replace protocol model.

That’s not to say Google’s approach isn’t feasible or desirable. Indeed, in some cases a “rip-and-replace” strategy is the only way to clean out the cobwebs that otherwise seem to hang onto technology for years after they’ve been superceded and superceded again. Think COBOL, which in some industries is still under active development, augmented by a hundred other technologies designed to workaround the reality that it’s an aged, outdated technology that for various reasons we are unable to simply walk away from.


translation layer spdy sm httpNope. Not gonna take a side yet – if ever. Personal preferences aside (which it’s hard to have at this point without more technical details from Microsoft) the decision whether an organization eventually wants to go with SPDY or Speed+Mobility will not at all impact negatively mediating devices. In fact, the existence of both would not negatively impact such devices because of their strategic location in the network. The existence of all three – SPDY, S+M, HTTP – would actually not negatively impact these devices as long as they were able to support all three, which seems more likely than simply choosing a side.

There will be a need to support both – and likely all three (do I hear a fourth?) – protocols moving forward. Regardless of who wins this particular war and comes out crowned HTTP 2.0 champion, there will still be a need to implement support across infrastructure vendors. There will be a transitory period during which browsers and servers and infrastructure all must “get up to speed” (ha!) and will do so at different rates, making the need for intermediating devices critical. Just as is the case with the migration from IPv4 to IPv6, intermediating application delivery solutions provide the means by which organizations with substantial infrastructure investments to maintain the value of those investments while moving forward to support emerging standards. Being able to translate, for example, between SPDY and HTTP today would be a significant boon for organizations, as it requires no changes to what is likely an extensive application and server infrastructure. Similarly, assuming a pilot of Speed+Mobility, if the application delivery tier can support it, it can mediate – translate – and provide an opportunity to support users via either standard without radically disrupting the application server infrastructure. A full-proxy based application delivery infrastructure is full of advantages, after all.

I like SPDY. I like it’s approach and I actually admire Google’s chutzpah in diverging from HTTP as a solution, recognizing perhaps the inherent tendency to be more concerned with backwards compatibility than with improving upon the model. But I like what Microsoft is saying from an enterprise perspective because honestly, replacing an entire infrastructure architecture to support one protocol out of many is not an appealing option, no matter the benefits.

Both approaches have merit, and the bigger story is that an overhaul of HTTP is necessary - and long overdue.

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.