Slashdot Mirror
S+M Vs. SPDY: Microsoft and Google Battle Over HTTP 2.0
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."
S&M - really??
S&M? lol what is it with microsoft and their naming schemes. Turtle phone anyone?
Lets take a little look at the history of Microsoft and clearly understand what we're getting into before we blindly adapt one of their standards.
It's true no man is an island, but if you take a bunch of dead guys and tie 'em together, they make a good raft.
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!
Bitten Apples are still better than dirty Windows...
The Microsoft S&M (TM) standard will mandate the declaration 'use strict' on all pages.
Oh, and I don't think Microsoft can embrace, extend, extinguish this one even if they tried, because everyone knows that IIS is a piece of shit. Apache still has 55%, but nginx is the fastest growing web server; I don't think standards can disrupt what's already a healthy ecosystem.
I like my HTTP protocols to be a little bit kinky.
People discount Microsoft because they fail to realise that Microsoft is relentless. It's like waves of zombies. You might fight off the first wave and become a bit arrogant but before you know they're back and attacking in large numbers. Before you know it your defences are overrun, your bullets have been spent and they're eating your brains.
Mmmm, braiiiiiiins...
Sorry, you were saying?
Bitten Apples are still better than dirty Windows...
Correct me if I am wrong, but encryption prevents caching. That is why Facebook and Google used to encrypt only user/password authentication. Forcing every connection to have encryption would prevent all caching as well...
Is there anything better than clicking through Microsoft ads on Slashdot?
SSL needs to be mandatory .. there is way too much threat from various governments and even non governmental bodies that want to see what people are doing on the web.
Given the centralized nature of SSL certificates, it's downright trivial for a sufficiently interested government to execute a MITM attack on you. All they need to do is force the certificate authority to issue a copy to them.
For every optional feature, the server will need code to deal with clients that do support it and clients that don't. It's more code to write and more potential for bugs. Of course this doesn't mean that every feature should be mandatory, but compression and encryption are already supported by pretty much every browser and server push would be a significant improvement over polling.
On metered connections, compression and server push would be improvements and encryption wouldn't make a difference. For power consumption, server push would be an improvement (polling means sending over a wireless link regularly), compression would probably not make much of a difference (assuming we're talking about gzip here) and encryption might tax the battery a bit more. However, if this is an issue, the common encryption algorithms could be hardware accelerated.
Correct me if I am wrong, but encryption prevents caching.
Well, you are wrong. At least as a general statement. :)
It prevents caching by proxies, but it works fine with regular client/server HTTP caching.
Bitten Apples are still better than dirty Windows...
Firefox, Chrome, Opera, and IE will all cache HTTPS content if permitted by Cache-Control headers. Of course, HTTPS, does prevent transparent proxy caches.
You're wrong. It prevents downstream proxies from caching, but Google is perfectly capable of putting the SSL layer in-front of Varnish/Squid, and caching rather than always hit the backend.
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.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Microsoft proposes HTTP 2.0 come in the following varieties:
HTTP Speed+Mobility Starter Edition
HTTP Speed+Mobility Professional
HTTP Speed+Mobility Enterprise
HTTP Speed+Mobility Ultimate
#DeleteChrome
Well that's kind of the point isn't it? In S&M someone always is the biter and the other one is the bitten.
It'll won't be Microsoft wearing the ballgag.
They don't even need a copy, or interaction with the same CA - any cert issued for the same domain by any CA will do just fine, which is why the creation of a CA in China recently was a hot topic, as it allows global MITM attacks by Chinas government.
I think our anonymous friend is a little out of date, but was kinda right in the past for at least some browsers.
Firefox was one of the last browsers to not cache HTTPS resources even if the headers said to. I think this changed with Firefox 3 (?). The reasoning was that anything transferred over HTTPS was assumed to be private, and shouldn't be saved to disk. And yes this included images and stylesheets etc.
They did come to their senses thankfully.
Drop legacy and force extensions? Sounds like M$/Apple (but in this case it's the opposite) this will lead to "Oh, I'm sorry your App X can't connect to the Internet anymore, you know it's already 3.5 years old? Time to buy a newer version!"
But seriously, in the foreseeable future (lets say 10 years) we wont get to a state where mobile devices can be allays on-line, listening for server pushes and not drain the battery in 4 hours.
"You forgot google.com open in your mobile browser? It servers you right that your battery lasted 2 hours... and here is the bill for the 500mb bandwidth it consumed while at it"
SSL connections are a great thing however with that comes a great deal of cost and overhead for the server operator.
Got Code?
There is ofcourse the problem that using SSL makes it much harder for us to inspect the traffic for malware, bots, and whatnot.
Uhm, just because it's also caching doesn't mean it's the caching that is discussed, so wtf are you even talking about..
What? Just because something is dynamically generated doesn't mean it magically changes each time it's requested, or that it can't use last-modified or etag headers and implement "304 not modified", or be explicit about what is to be cached for how long, and under which circumstances. Again, what are you even talking about. Seems like you're just stringing words together.
...who brought you the Critical Update Notification Tool!
It's not a ballgag, it's a rights-management appliance.
Hence a very long time.
It prevents caching by proxies, but it works fine with regular client/server HTTP caching.
The first is a huge problem. Having a transparent caching proxy easily saves a medium sized company 20-40% bandwidth and increases the perceived speed for users.
Enforced SSL also decreases speed because of a need to encrypt on one end and decrypt on the other. Slow devices pay the heaviest penalty.
My first test of SPDY showed that it slowed down page load by a factor of 2, and consumed a heck of a lot more resources too. Yes, this was on a slow machine. But guess what? Slower machines haven't been banned from accessing the web, and I don't think they should be.
I am not against SSL, but against the use of it for the sake of using it. It's the lazy way out.
No, please let me have HTTP/1.0 and 1.1, also without SSL. Because sometimes the solution creates as many problems as it solves.
Hopefully Microsoft's suggestion is a bit more sensible. But I doubt it. They want controlled slow obsoletion, so customers can be forced to buy new versions of Windows Server, Office and what have you.
Citation Needed.
Certainly the common server-side implementations right now like to use it with encryption, but I can find no mention of that being mandatory in the SPDY IETF draft.
In particular, section 2.1 has all of the following to say about upper-level protocols:
SPDY has protocol elements that are only useful when it's wrapped by TLS/SSL, but then you aren't forced to use those on a given connection, either.
Did you forget Active Directory and Kerberos where Microsoft refused to say WTF they did in the extension field until the Kerberos working group threatened to redefine that field away and turn Microsoft's implementation incompatible?
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.
What's the difference?
Oh, right, if you say the safe word, your partner will remove the ballgag.
I am officially gone from
The safeword is 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0, right?
Does the M$ package comes with proprietary IP?
That'd be a golden shower, not S&M
The safeword is 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0, right?
Hey that's easier to say than this safe word :)
http://www.youtube.com/watch?v=9-2dN9E8vPk&feature=youtube_gdata_player
"Curiouser and Curiouser...." -Alice
Maye it is time to rethink the architecture beyond single encrypted pipe bolted onto a legacy protocol made to mimic even older legacy protocols. There is no reason proxies could not cache opaque encrypted and signed blobs - be it components of documents or fragments of a broadcast stream - they don't need to know whats inside and client does not care who he gets it from as long as the indentity and authenticity can be verified. But we would need to decouple transport from encryption. SSL will not help us there. We'd need encrypted & signed content entities, and content distribution protocols that allow content distribution from multiple sites based on network distance. Take inspiration from the P2P networks lile BitTorrent.
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?