S+M Vs. SPDY: Microsoft and Google Battle Over HTTP 2.0 180
MrSeb writes "HTTP, the protocol that underpins almost every inch of the world wide web, is about to make the jump from version 1.1 to 2.0 after some 13 years of stagnation. For a long time it looked like Google's experimental SPDY protocol would be the only viable option for the Internet Engineering Task Force to ratify as HTTP 2.0, but now out of left field comes a competing proposal from Microsoft. Lumbered with the truly awful name of HTTP Speed+Mobility, or HTTP S+M for short, Microsoft's vision of HTTP 2.0 is mostly very similar to SPDY, but with additional features that cater toward apps and mobile devices. 'The HTTP Speed+Mobility proposal starts from both the Google SPDY protocol and the work the industry has done around WebSockets,' says Jean Paoli from the Microsoft Interoperability team. Basically, the S+M proposal looks like it's less brute-force than SPDY: Where server push, encryption, and compression are all built into SPDY, Microsoft, citing low-powered devices and metered connections, wants them to be optional extensions. Judging by the speed at which the internet (and the internet of things) is developing, I think MS's extensible, flexible solution has its merits."
Re:Optional extensions? (Score:5, Insightful)
I really like that SPDY insists on SSL secured connections. This is what we should be moving towards and having it forced upon us in the next HTTP revision is a great step. But of course Microsoft tries to be backwards compatible, as they always are.
I say SPDY for modern devices, HTTP 1.1 for the foreseeable future for low powered devices. It still works fine, you know? And by the time HTTP 1.1 is retired, there will be no more devices so underpowered they can't establish a SPDY connection. For the love of god, drop legacy when you get the chance!
Re:I'm weary of any standard coming out of Redmond (Score:4, Insightful)
Wary.
But yes, it's always a good idea to take a closer look... although tbh, the same thing applies for Google's alternative ;)
Re:Not a fan of optional (Score:5, Insightful)
Those devices can stay on http 1.1 which will be supported for the foreseeable future. That's a much better way to manage backwards compatibility than trying to make certain features optional.
Re:Optional extensions? (Score:5, Insightful)
It hardly matters, these days. So much of the web is dynamically generated that caching hasn't been very useful in a long time, for anything but images.
Wrong. A lot of downloads are http. Do you really want all your users to download the same 80 MB updates or 2 GB iso files as separate copies through a shared internet connection, or get them from the cache after the first download?
And while a lot of content is dynamically generated, the javascript and css files generally aren't. The earlier they can be loaded in a client, the snappier the experience for the user.
Once you subtract downloads, streaming http video and audio, static pages, javascript, css and images, you'll find that what's left is a small part of the overall bandwidth.
What hurts with web 2.0 and abloodyjax is the ridiculous number of connections you establish and break down. Latency kills you. Re-using connections and keeping them more persistent helps, at the cost of maintaining unused connections at both ends. And caching what is cacheable (instead of the web devs taking the lazy cop-out of marking everything as dynamic) helps a lot.
SPDY is like the stores handing out a huge shopping cart to everyone whether they need it or not, to solve the problem of certain buyers pushing a train of two or more carts. It'll piss of those who just want a bottle of milk. It's a solution looking for a problem.
Evaluate the proposal on its own merits (Score:4, Insightful)
No one -- even Microsoft -- is asking for "blind adoption". The Microsoft proposal offers numerous explicit issues for discussion and raises and provides a recommendations for addressing numerous issues with regards to Google's earlier proposal (both as regards to pragmatics and consistency with the HTTP/2.0 charter.) Its a discussion draft. Its not intended for blind adoption, its intended to spur further discussion in the work group.
Why not address the merits of the proposal?