HTTP has had a glorious reign. Originally designed as the communications protocol to oil the wheels of the web and transport simple HTML down 14k modems , it has become the protocol of choice for broadband mobile and desktop apps, server-to-server communication, APIs, secure tunnels – you name it, HTTP is serving it. This is in no doubt partly due to its ubiquitous adoption in firewall rules – the web door must be left open! The web can get in anywhere and so it sneaks a few friends in for good measure. Try using another protocol or wander from port 80 and you’ll come unstuck pretty quickly in real-world rollout. I’ve had personal, painful experience of this trying to peddle a custom e-commerce solution in the late-90’s to corporate environments where even the internal firewalls seemed to be made of stone and tied up with pretty red-tape ribbon.  Of course, HTTP has also been successful because it’s quite simply a great general purpose protocol for delivering digital documents.

There are many people who think the use of HTTP 1.1 has far outgrown its shoes and it shouldn’t be struggling along carrying such a weight of complex traffic. We can do better. So what will HTTP 2.0 look like? The HTTPbis working group have started to consider this potentially radical change in web content delivery, as this article at InfoQ summarises.

But wait, there are potential new kids on the block!

Google has proposed SPDY – an entirely new protocol (pronounced “speedy” for obvious reasons) which is aimed at addressing the performance problems HTTP  suffers every day due to being flogged to death for crimes it wasn’t designed to commit. As described in this Ars Technica article, our huge and complex websites with bolts-ons like SSL and cookies could be delivered much more efficiently with SPDY.

That sounds great, but it’s a whole new protocol – and therefore faces an enormous challenge reaching critical mass. Network infrastructure providers such as F5 are already proposing gateways to enable HTTP and SPDY to work together so it’s possible that the neatly layered stack of the OSI model will truly show  its purpose here to allow us the flexibility we need to advance.

Microsoft has also proposed the (ridiculously named) HTTP S+M, which appears aimed more at optimising mobile while accommodating HTML5-related communications technologies such as WebSockets to enable fast bi-directional communications suited to games and peer applications (of course Google would prefer you went with Protocol Buffers, but that’s another story). Interestingly they are directly proposing this as a possible HTTP 2.0 in contrast to Google’s proposition which could be seen as a more radical shift, but then possibly adopted as HTTP 2.0 anyway.

Whatever succeeds HTTP/1.1, it has certainly earned its graceful retirement. It can sit with a blanket over its knees, sipping a sherry and reflect on the billions, trillions, quadrillions of interesting, revolutionary media it so faithfully delivered to our insatiable browsers over the last 20 years.

Let’s just hope it doesn’t take as long to happen as IPv6.