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."
Oh god... (Score:5, Funny)
Re:Oh god... (Score:5, Funny)
Going to make for some great domain names! :)
Re:Oh god... (Score:5, Funny)
Going to make for some great domain names! :)
And some interesting work time search results. Imagine:
S+M maximum speed
S+M large payload
S+M security accessories
Re:Oh god... (Score:5, Funny)
Not to forget the job market:
"Wanted senior S&M specialist with python experience and high availability background"
Re: (Score:3, Funny)
On the bright side it may be possible for some people to actually have 5 years experience when this first comes out, just as recruiters demand.
Re:Oh god... (Score:5, Funny)
I guess its a role where you'll be chained to your desk.
Re:Oh god... (Score:5, Funny)
Re:Oh god... (Score:5, Funny)
Use strict (Score:2)
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.
Re: (Score:3, Funny)
Re: (Score:2)
Also "Windows OneCare" (read it in an Inspector Clouseau voice...)
Not to mention Steve Ballmer talking about 'squirting' and those awful Seinfeld ads.
Re: (Score:3)
GNU Image Manipulation Program
Re: (Score:3)
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.
Re:Microsoft ? Proprietary IP ? (Score:5, Funny)
Re:Microsoft ? Proprietary IP ? (Score:4, Funny)
What's the difference?
Oh, right, if you say the safe word, your partner will remove the ballgag.
Re: (Score:3)
Oblig video :) (Score:2)
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 [youtube.com]
Re: (Score:2)
How do you say a safeword while wearing a ballgag?
Re: (Score:3, Funny)
Does the M$ package comes with proprietary IP?
That'd be a golden shower, not S&M
Re:Microsoft ? Proprietary IP ? (Score:5, Informative)
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?
Optional extensions? (Score:2)
I wonder if all the options of all the extensions will be part of the spec, or is this another embrace, extend, extinguish?
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:Optional extensions? (Score:5, Interesting)
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...
Re:Optional extensions? (Score:5, Informative)
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.
Re:Optional extensions? (Score:5, Interesting)
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.
Re: (Score:2)
I think that's what he meant; he was just being brief. Encryption prevents sharing caches, which happens to usually be the whole point of caching.
Re: (Score:3)
Firefox, Chrome, Opera, and IE will all cache HTTPS content if permitted by Cache-Control headers. Of course, HTTPS, does prevent transparent proxy caches.
Re: (Score:2)
Of course, HTTPS, does prevent transparent proxy caches.
Hooray! My ISP is really shitty at this anyway. Tired of them creating problems for me because they want to save some bandwidth.
Re: (Score:3)
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.
Re: (Score:3)
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 requ
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.
Re: (Score:2)
the browsers won't cache as a precaution -- it can be overridden.
Say what now? Precaution against what?
And browsers cache assets transferred over HTTPS just fine.
Re:No (Score:5, Informative)
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.
Caching encrypted stuff (Score:2)
Re: (Score:2)
It could be argued that encryption should be done at the IP level, not HTTP level, and therefore having mandatory HTTPS is redundant
Re: (Score:2)
It ca, but I disagree. It'll be a very long time 'till IPsec is widely supported, while SPDY can be used right now.
Re: (Score:2)
IPsec is a mandatory part of IPv6.
Re: (Score:2, Funny)
Hence a very long time.
Re: (Score:2)
Using any number of operating systems, try to total 5% of the market share with operating systems that don't support IPSec.
Re: (Score:2)
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
Re: (Score:2)
Nothing forces an application to be continuously on-line to support server push.
Server Push is to enable servers to push content to the client that it didn't specifically ask for; for example, /. could push the logo image right after getting a request for the HTML part, so that the client doesn't have to parse the HTML, find the image tag and then do a new request to ask for it.
Supporting server push actually reduces battery and traffic, since you don't need to send requests or keep the connection open for
Re: (Score:3)
SSL connections are a great thing however with that comes a great deal of cost and overhead for the server operator.
Re: (Score:2)
Think again. Today's server CPUs all already have hardware AES support. There is no reason why the next generation's can't support RSA/DH for the handshake too. And if you make SSL mandatory, they will. Which makes the overhead disappear into a tiny fraction of the number of transistors on each core, while making everything more secure.
"There is going to be a transition period" is no excuse for not doing something which has long-term benefits.
Re: (Score:2)
There are statements (I cant find a source right now but I think they got a mention here a while back) where top technical guys from some big sites that have gone "HTTPS for everyone all the time" said that the overhead of SSL is minimal even when doing millions of page views.
Re: (Score:2)
There is ofcourse the problem that using SSL makes it much harder for us to inspect the traffic for malware, bots, and whatnot.
Re: (Score:2)
SSL already exists. There is nothing stopping malware distributors from using it whether it is mandatory or not.
Re:Optional extensions? (Score:4, Informative)
Citation Needed.
Certainly the common server-side implementations right now like [wikipedia.org] to use it with encryption, but I can find no mention of that being mandatory in the SPDY IETF draft [ietf.org].
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.
Really? (Score:3)
Re: (Score:3)
Well, they could have gone with "Hypertext Transfer Protocol 2.0 Speed and Mobility Express Professional Server 2013 Edition for Workgroups" instead, or httpsmepew:// for short. I think "S&M" is already a pretty good try for them.
Re:Really? (Score:5, Funny)
Re: (Score:2)
I actually wouldn't mind typing that in or dictating it.
msblows://microsoft.com
Re: (Score:2)
I'm weary of any standard coming out of Redmond (Score:5, Informative)
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.
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: (Score:2)
Re: (Score:2)
While "wary" is likely the originally intended meaning, "weary" also parses fine ^^
Re: (Score:2)
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.
They even called it HTTP Sadism & Masochism, it's not like we aren't warned.
Re: (Score:2, Funny)
As if the name of the proposed standard wasn't already a dead giveaway. It's obviously another ploy for them to place the world back under their bondage and domination. I think some marketing drone at Microsoft hadn't thought the name through, or perhaps they are here trying to display a frank and contemptuous display of their true motives in introducing such a protocol. I hear a song by Rihanna playing in the background....
Re: (Score:2)
Urine Control: The Game (Score:2)
Microsoft has a history of marketing intelligence. They released the first version of Windows Update as the Critical Update Notification Tool (make the acronym...).
That or FC: Fluffy Creatures 2009 (SWF; NSFW) [newgrounds.com].
They also had a campaign in System Center with the tagline "You're in control!" Spoken, it sounds like "hitting the bowl"
That or "Urine Control" sounds like what "Nintendo Wii" would mean if it were literal [slashdot.org]
the same way that "gun control is hitting what you're aiming at"
Re: (Score:2)
You're just not masochistic enough for Microsoft standards.
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?
S+M it is then (Score:3)
Interesting (Score:2)
How many HTTP protocols do you use on your way to the ATM machine?
S&M (Score:2)
Well, the internet is for porn...
SSL needs to be mandatory (Score:2)
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.
If wish somebody would ship an SSL-only browser.
Re: (Score:3)
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.
Re: (Score:2)
Well that part needs to be changed. I guess I should have said encryption rather than SSL.
Re:SSL needs to be mandatory (Score:5, Informative)
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.
Re: (Score:2)
Re: (Score:2)
That is an issue with the CA system, not SSL.
Re: (Score:2)
Re: (Score:2)
apparently you don't understand the difference between a technological and non-technological problem.
They can replace the CA system with something that functions more reliably and SSL would not need to change.
Re: (Score:2)
The solution is to eliminate CAs altogether and do 4 things instead:
1.Stop storing identifying information (individual or company names etc) in SSL certificates and only store authenticating information. The only thing web page encryption should be doing is verifying that the web page you think you are talking to is the one you are actually talking to.
2.Store certificates (or certificate hashes) in DNSSEC-secured DNS records. Its much harder for a malicious attacker to break the encryption on DNSSEC or to c
Not a fan of optional (Score:3)
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.
Re: (Score:2)
You do realize some devices just don't have those hardware accelerators you're speaking of?
Re: (Score:2)
Today some don't have it, but this is a design for a future standard. Smartphones already have MPEG4 acceleration and I think hardware AES would take less transistors than MPEG4. Also, a software fallback for encryption is possible, so even if it would take a bit more power you'd still be able to use it. And when transistors continue to shrink computation will become cheaper over time, while the amount of power spent on the display and the radio will probably not decrease a lot.
I also realize that not all d
Re: (Score:2)
Re: (Score:2)
So all older devices would become incapable of connecting to modern websites, even with software upgrades?
Re: (Score:2)
No, they would spend a bit more power by doing decryption in software instead of hardware.
Re: (Score:2)
Maybe they don't have sufficiently fast software decryption to meet their operational requirements.
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: (Score:2)
Re: (Score:2)
Related assets being pushed with out request will be a huge deal too...I call up the webpage, I want the webpage, so you might as well give me everything without waiting for me to ask for the next image/javascript block...etc.
Re: (Score:2)
Microsoft the market leader in Mobile phone OS's is obviously the right way to go rather than the minority player Google ... oh sorry got that the wrong way round ...
Re: (Score:2)
I guess optional isn't good for protocols. If a device might not support it then you can't rely on it, and if you can't rely on it, you might as well not bother trying to use it.
Of course, if all this happens under the covers of the network stack, then things might be different, but can you really implement push notifications on the server if the client only supports pull.
I particularly worry that MS will introduce another 'optional' component that is available on Window server and Window Phone, and make it
Microsoft and the mobility fiasco (Score:2)
Microsoft, with the ridicule market share of Windows Phone, you are probably not in the position to tell to Google how to do this kind of technology.
Re: (Score:2)
Don't rewrite the history: ODF alliance, aside of a comparative document, never tried actively to stop MS to standardize Open XML. MS did try very actively to stop ODF alliance to standardize ODF. Search a bit in the Slashdot archive on how Microsoft have made pressure into many governments bodies.
SIM card is not used only in smartphone and, actually Nokia still sell far far more phones+smartphone than Apple. Well, this will quickly change if there continue there WP crap...
Summary oversimplifies the proposal (Score:5, Funny)
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
Re: (Score:3)
Re: (Score:3)
HTTP S & M Leather Edition
HTTP S & M Chain Edition
and for the Asian market HTTP S & M Tentacle Edition
Re: (Score:2)
Re: (Score:2)
S&M Ultimate doesn't come with a safeword.
From the people... (Score:4, Funny)
...who brought you the Critical Update Notification Tool!
When will they ever learn. (Score:2)
When any part of a standard is optional, then you can't really depend on it. If you can't depend on it then you can't really use it for any real life scenarios. Optional features in standards are bad.
Re:Sigh. Microsoft copies Google yet again. (Score:4, Funny)
Re: (Score:3)
Mmmm, braiiiiiiins...
Sorry, you were saying?
Re: (Score:2)
Then they stumble around blindly and starve, because they ate/transformed all humans. Then they eat each other. Then the sun rises and life forms anew on the planet.
Re: (Score:2)
... why they don't go whole hog, and call it "HTTP BSDM".
I'm sure they could come up with a good backronym.
Nah... too suggestive on what MS are going to do to their clients... blindfolding, binding, gagging and abusing them and making them pay for the service. Some of them may like it (e.g. I actually fail to understand the Mac fans, entering in a consensual relation of the same nature... and deriving pleasure from it), but it is not a predominant part of the populace (or should I have said... not the predominated part of the populace?).
Well, to make sure I'm politically correct, I'll admit that my fetish is re
Re: (Score:2)
Are you on crack? None of that stuff has anything whatsoever to do with having a single connection. If you were so inclined, you could do any of it entirely with existing technology.
The purpose of a single connection is purely performance. It allows you to have SSL on everything without doing a thousand handshakes. It allows the server to provide data it knows you're about to request ahead of time rather than waiting for a round trip to your browser.
People who think SSL is any good for DRM are deluded. Anyo