RFC 1945 – “Hypertext Transfer
Protocol -- HTTP/1.0” – was published in May 1996. In June of 1999, RFC 2616 –
“Hypertext Transfer Protocol -- HTTP/1.1” was published. In the ensuing 13
years there has been no substantial changes to the HTTP standard. None. Nada.
Zilch.
Even as the size and number of
objects has ballooned over that time, and the overall composition of web pages
grown increasingly complex, still there’s been no substantial efforts to
improve upon the now entrenched HTTP standard. Even as sites struggled to maintain
availability and performance in the face of exploding usage growth – fueled by
mobile device proliferation, increasingly affordable access enabling everything
from plants to cows to users to “get online” – HTTP 1.1 remained the standard
for web-everything, despite the growing fact that it simply wasn’t the most
optimal means of connecting users with the resources they expect and
increasingly, demand.
AJAX and Web 2.0 gave us better
interactive models that alleviated some of the pain associated with performance
problems, but as that model took hold and video became the medium du jour even
its advantages have become unable to produce the acceptable results.
And then Google introduced SPDY. The
first shot in the HTTP 2.0 war. Now Microsoft has fired back with
“Speed+Mobility” and the battle appears about to be fully engaged.
Although SPDY has been out and about
for some time, it only recently made it to the status of “Internet-Draft” in
the RFC system, being officially published in Feb 2012. Along comes March 2012,
and Microsoft has (sort of) countered with Speed+Mobility.
What will be interesting as the
battle progresses is to see which other organizations and vendors will side
with which version (if not both). Invariably other organizations will want to
be able to claim to have been co-authors of whichever standard becomes, well,
the standard but choosing sides so early in a war is hardly appropriate,
especially when the technical details are still (as of this writing) missing
from Microsoft’s proposal.
RIP-REPLACE versus UPGRADE
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
overhead.
[Same as SPDY] The session layer would
allow for prioritizing
delivery of content to ensure highest
value traffic is delivered
first.
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:
We 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.
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.
TAKE a SIDE ALREADY, WILL YOU?!
Nope. 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.
No comments:
Post a Comment