mbelshe

Kinda makes you wish the IETF had adopted all-TLS-all-the-time in HTTP/2.0.

We need HTTP/3.0 to be SSL all the time and nix the CAs so we can avoid MITM from VZ.

As soon as Microsoft embeds SCTP in every Windows device, we might be able to start discussing this...

Standardization is a critical step. It verifies that we use open IP which is available to everyone, provides a open forum for discussion, and archives the protocol in a way all vendors can use to resolve disputes about how we communicate.

BTW - TCP & SSL maintain connection level state too. This isn't anything new to SPDY and is transparent to the application above.

The biggest difference between SPDY and Microsoft's proposal is that Microsoft's proposal is only theory at this point. The SPDY proposal has dozens of independent implementations behind it and 3 years of operational experience.

I'm not trying to dis the proposal; just point out that it is in its infancy. To jump start it, Microsoft started with SPDY at its core, but changed the syntax.

Changing the transport requires patching the kernels of billions of installed devices. SCTP is not available on Windows, Mac, or any popular mobile device I know of.

The Opera guys posted this today, and the author didn't understand the nature of stateful compression.

SPDY is getting well over 85% compression in the real world across millions of installed users.

If you want 100% support; just wait for the IETF to finish HTTP/2.0. It may not be the exact SPDY protocol, but it will most likely support a reasonable form of multiplexing, and I am confident all major browsers will implement it. But its probably ~2yrs away.

We removed the alternate-protocol stuff only because we thought it needed more work. It is implemented in chrome, so you can try it, but we're still considering how we'll deal with it going forward.

You can see this for yourself - run the test referenced in Rob's post above. IE9, right now, reports a 13-14x slowdown on that test with trivial changes.

There were multiple issues. There was a straight up bug, which was fixed. But the perf delta remains.

Sorry to surprise you, Maciej. As others on this thread have already have already surmised, we were not trying to change (or fork) SunSpider. We just wanted to demonstrate the impact of the smallest possible change when we make it a longer test.

The great thing and the worst thing about benchmarks is that vendors optimize to them :-)

IE9 claims speed, but the only benchmark it performs better than other browsers on is the SunSpider benchmark. If it is so fast, why does it only do well on a single benchmark? It has already been documented that trivial changes to SS make IE9's performance change dramatically: http://blog.mozilla.com/rob-sayre/2010/11/16/reporting-a-bug...

Personally, I believe SunSpider is just too-easy-to-game. Historically, this problem comes up now and then with compiler vendors and benchmarks. The only solution is to have long-running benchmarks which exercise many parts of the JS engine so that gaming is not so easy.

That's basically what SPDY is. It has two halves, a framing layer (which is generic), and a definition of how to embed HTTP within that framing layer. In theory, you could use the framing layer for other purposes, but we designed it tailor-made for http.

For the original question - HTTP can only send one request at a time. SPDY can send many all at the same time, avoiding lots of round trips. As a side effect, it sends fewer bytes and packets too. look for the IETF slides for the latest data.

No, this is pure conspiracy theory. :-)

The decision to drop "http:// from the display was a UI decision and had nothing to do with the internals. The idea is that the "http:// is just user-confusion. Most users can't spell HTTP, much less know why it is there. Why do we subject our poor users to it? Personally, I don't care.

Chrome does not recognize "spdy://" as a protocol scheme, and the UI display changes nothing with respect to how chrome selects protocols.

Alright, but that is just theory. The reason you'd want a text protocol is so that humans could read it. Once you secure the protocol, you can't read it without a machine to help you.

Heh - I didn't think a server side SCTP implementation was very interesting if you don't have clients to use it.

Yes, its all open, and there are non-google SPDY servers out there already. My own site (you can probably find it) will speak SPDY for you.

If you have any trouble, please hop on to the spdy-dev@google.com mailing list for help.

Nobody questions that a secure protocol is not readable text :-)

I fundamentally believe the protocol has to be server authenticated and encrypted always. We've seen breach after breach of user privacy and the desire for governments to crack down on its citizens has no bound. We simply have to encrypt. Once we do that, text is off the table, and it doesn't really matter if it is binary or not.

Of course, we need much better tools for managing the encryption, I'm not a believer that the status quo is adequate in any way.

The reason we didn't like the Upgrade header is because it requires yet-another-round-trip in the protocol. Round trips are expensive, and getting worse both for desktops and mobile. (average RTT is ~114ms to Google, which has pretty good global presence)

As for SCTP, I think applications generally drive progress better than OSes do. Certainly the OSes have had enough time to sort out SCTP, but they haven't done it, and the end-game is nowhere in sight. Until there is an app that showcases it, will it ever happen?

My recommendation is to first prove new protocols at the application layer (perhaps run SCTP over UDP just to grease the skids). When people are addicted to how much better the experience is (multihoming + concurrent streams), then the OSes will pull it into the kernel to make it more scalable.

What do you think?

SCTP is not available on Windows by default, and you need administrative privileges to deploy it. I'm not trying to start an OS war debate, but this is a very practical problem.

Mobile, oddly enough, may be the best route to bring both IPv6 and SCTP to life.

SCTP is a good start for sure, and someday may make sense. The problem is a deployment one: it can't pass through NAT, making it off limits to most users today.

As for solving problems from the transport, that is not true. I assume you're suggesting that streams can only be tackled at the transport layer, but SPDY's compression is clearly an app-level endeavor.