Shared publicly  - 
 
Microsoft isn't going to let Google's SPDY get the last word about faster HTTP. It just announced HTTP Speed+Mobility. Maybe we'll get some fireworks at IETF meeting this week. Or maybe just some discussion. What are you expecting, +Mike Belshe?
19
10
Sudhakar S's profile photoNicholas Meredith's profile photoEmmanuel Taban's profile photo王秋's profile photo
8 comments
Mike Belshe
+
29
30
29
 
Microsoft has a great crew of engineers, and getting their help in this problem space is awesome for the web. I'd love to work more closely with them! It's also nice to hear their flattering words about SPDY. I can't comment on their proposal yet, however, because they haven't released it :-) I look forward to them providing real-world performance metrics and open source implementations so that we can all evaluate them.

In their post, they imply that SPDY is not optimized for mobile, which is not true. SPDY is now over 3 years in the making with a lot of implementation knowledge and deployment expertise on both desktops and mobile. My current company, Twist, is a mobile apps company, and we're optimizing our mobile performance using SPDY. (Our iPhone SPDY implementation is open source and available here: https://github.com/sorced-jim/SPDY-for-iPhone) Given what other implementors have said about SPDY and mobile, I'd say its working pretty well. But it could always be better, of course.

So if Microsoft has some new ideas that prove to work, that's fantastic. The goal is not to take one vendor's implementation, but to aggregate the best concepts together and make the best protocol we can. I look forward to engaging more with Microsoft soon.
 
+Mike Belshe I don't have any extra insight than you do (in fact, I doubtless have considerably less) but I suspected that their "mobile" sales pitch perhaps meant "works with mobile apps, not just with browsers." It's not clear, though. And I'm still fuzzy on how something on a client device besides a browser engine would use HTTP.
 
I'd guess that nearly all mobile apps are using HTTP - they just don't use it to transfer HTML. Instead, they use it to transfer JSON, XML, or other data types. So while you don't optimize this the same way you'd optimize a web page, the principles of network optimizations are the same - send fewer bytes over fewer connections.
 
Seriously? which microsoft works as smooth and fast as google's? I can think of none. I think Microsoft is out of date for a long time regarding web technology.
 
I think Microsoft raised a valid point in getting a smooth and fast transition to HTTP/2.0. I can't see this how this can happen as long as SSL is a strict requirement.
Furthermore, it can't be anything other than good news that someone outside Google picks up this ball. Google's needs are quite different than my needs and HTTP/2.0 needs to be just as useful and "right" for me as for Google.
 
+Per Buer SPDY is not a Google project anymore. With independent implementations from vendors like Amazon, Mozilla, and Twitter, SPDY is clearly more than just Google's pet.

Furthermore, the SSL requirement is solely to benefit consumers. Privacy regulations in the US and the EU are clear - consumers want software vendors to be more careful about protecting private data and private data transmissions. I have yet to meet a user, any user, that wants his data transferred over the internet in an unsecured fashion.

I suspect most Internet users have no idea that the vast majority of their communications online are unsecured and can be trivially hijacked or stolen. If 2012 isn't the year we finally take steps to make the web secure, when will we ever do it?
 
+Mike Belshe: The problem with SSL is that it requires a certificate. Currently, in Iran, due to the embargo, credit card and SWIFT payments are down and you are unable to procure a SSL certificate. So, with SPDY as HTTP 2.0, no one would be able to launch a website.
Now, neither Google, Amazon or Twitter gives a damn about the Iranians, but we should care. What has made the web a wonderful place is its openness.

Futhermore, why does SSL have to be tied into the application protocol? HTTP and HTTP over SSL (https) work fine and I can't see one single reason why SPDY should work any different.

Until we're rid of the horrid cert system (DNSSEC can transport keys far more efficient than those CAs) SSL use will be somewhat limited and HTTP 2.0 needs to take that into account.

And then there are the technical reasons why forcing SSL in SPDY is a bad idea.....
Add a comment...