AFAIK there's no way to initiate TLS over a SPDY stream (i guess SPDY could be extended to add TLS handshake control frames, but that's downright crazy) which would mean that the third diagram is misleading. End to end SSL would not be possible with a SPDY proxy. Instead, the client's SSL connection would extend to the SPDY proxy, and the proxy would have it's own SSL (HTTP, HTTPS or SPDY) connection to the remote server. If that's the case, the proxy would have unencrypted access to all traffic.

This is arguably not a problem for clients that explicitly opt in for this sort of proxy setup. But it sounds like this is not the case for the Kindle Fire. Based on this article (i don't have a Kindle Fire to test this theory), i'm guessing the browser has custom CA's for the SPDY proxy so that the SPDY proxy can spoof any domain through the magic of SNI. If all this is true, then it's pretty evil. People who know enough to check for the "secure connection" badge in the browser would be fooled into thinking they have end to end encryption to the website they are viewing. In reality, the proxy, and whoever runs it, silently has complete access to your unecrypted traffic.

There's quite a few assumptions here. And I'm not a SPDY expert so I may be overlooking something. But this doesn't sound like an optimization i'd be comfortable with.

You might be able to run HTTP CONNECT over SPDY.

Based on this article (i don't have a Kindle Fire to test this theory), i'm guessing the browser has custom CA's for the SPDY proxy so that the SPDY proxy can spoof any domain through the magic of SNI. If all this is true, then it's pretty evil.

I don't think this is correct, although I can't describe how Silk actually works.

speeding up that last mile concerned a lot of other people before, especially on slow mobile connections.

One example is Opera, they are even compressing http data, pictures etc. before transmitting to the client over a binary socket.

You don't make the same argument pivot yourself, but this is something that crosses my mind every time I read about SPDY too. All this stuff has been done before. It's not a new problem, and none of the old solutions caught on. What makes SPDY special?

Google makes SPDY special. If something is unquestionably useful but hasn't caught on, what you have is fundamentally a marketing problem. Google is the biggest marketing company on the Internet.

I mean, SPDY has some technical benefits of its own, but the biggest items in the "Pro" column are that it's an open spec and Google has thrown its weight behind it, even dogfooding it in their top sites and a major open-source project. This got people's attention, which previous efforts didn't really manage so well.

More specifically, because Google builds one of the most popular Web sites and one of the top browsers, they can break chicken-egg problems by JFDI. Things like SSL improvements, SPDY, SDCH, etc. have probably already paid for themselves.

It hasn't been done before. A single entity working to channel all of the web's traffic through a single cached pipeline and using a special protocol to do so is not SPDY. SPDY is a competitor to HTTP, it doesn't implicitly have to be used for caching or for proxying, and it shows some significant advantages when used on its one independent of those functions, warranting an expansion of its use on high traffic sites.

From November, so when it says "early next year" (w.r.t. Firefox implementing SPDY) it means "early this year".

Specifically, SPDY is available in Firefox 11:

http://download.cnet.com/8301-2007_4-57351535-12/whats-comin...

It'll be in Firefox 11.

http://download.cnet.com/8301-2007_4-57351535-12/whats-comin...

Just grab a Nightly if you want it now.

http://nightly.mozilla.org/

Is there a good (fast, secure, stable) Apache or Nginx SPDY module yet?

There's mod-spdy for Apache, and that's the future of SPDY adoption.

SPDY of the future today: opera turbo the article is about proxying SPDY, actually, like opera turbo does for http. in fact, using opera turbo gives a similar performance (except opera also compresses stuff, and the proxy is at opera, not at the isp, which adds some latency)

Note also that newest pre-versions of Firefox have SPDY (need to enable via about:config)

If you don't trust your ISP, this doesn't really improve security at all. If anything, it gives them a choke point which makes it easier to inject content or slurp your data.

The whole point of IP networking was that you could connect to an unlimited number of destinations in parallel using a single phone line. How is this still a mind-blowing concept?

What about infra-structure? That SPDY gateway will have to handle a hell lot of load. Will we really need that extreme optimization in 2 years?

I see this as awful for "real-world" because of the privacy concerns. Think Amazon won't analyze the heck out of that traffic? Uhh.

Also, before, gov't would need to install wiretapping stuff at central offices. With this, Amazon or whatever SPDY provider could just let them have "virtual wiretaps" which I'm sure won't be abused.

From an engineering standpoint, this is cool, but I can't see how this would function without introducing way worse privacy problems. In a world where we'll most likely need to rely on a decentralized Internet that is impossible to regulate, this is a step in the wrong direction.

The "SPDY gateway" is in no different a role than the "last mile" ISP. In fact, your SPDY gateway may for all intents and purpose be your ISP; or your ISP may offer an SPDY gateway.

So, we need an open source SPDY gateway then? We all know our mobile ISPs won't develop it themselves...

SPDY stands for SPeeDY? What the hell is that?

"I spent a fair amount of time running network traces of the Kindle Fire, and I honestly don’t know quite what they’re doing yet."

That's a problem with binary protocols. How does Spdy help the 'open web' when you can't even tell what's even going on at the network layer even after spending lots of time trying?

This blog also like every other advocating Spdy ignores that HTTP tunneling in practice provides the same benefits. And the last graph is the same as for an HTTP proxy, nothing to see there.

Once everything becomes encrypted you're going to need specialized tools (Wireshark) for debugging anyway, so does it matter whether the inside is text or binary?

Also, efficient formats/protocols need to use byte counting, and byte-counted "text" protocols (BEEP and bencode come to mind) are effectively human-unreadable anyway.

Yeah, I've got no problem with binary protocols, especially when they need to encapsulate arbitrary data (e.g. containing NULLs, etc). Just keep the protocol design sane and it's trivial to write a pretty printing trace tool. Requiring machine-to-machine communication to do heavy parsing is a bad idea.

> Requiring machine-to-machine communication to do heavy parsing is a bad idea.

Why? Machine-to-machine communication is for machines, after all, isn't it?

What you call "heavy parsing" is heavy parsing for humans. It's actually easier for machines, because they simply reference (and verify) an offset.

Are you advocating designing a protocol primarily around how easy it is to interactively troubleshoot? Certainly that has value, but on the modern Internet, is it really the dominating concern?

To the point:

- try checking what a webapp does. TRIVIAL. We're talking minutes.

- try checking what a binary app on your computer does. one with DRMs or advanced "anti crack" stuff for example. FREAKING HARD. Even if you're a wizard, it still takes a few hours. For mortals, we're talking weeks. Weeks!

And that my friend, is why what you wrote is wrong.

Definitely not the case with HTTPS, which looks like binary garbage over the wire but whose payload is quite transparent once decoded by SSL.

How are you "checking what a webapp does"?

You're using the browser or WireShark almost guaranteedly. You can continue to use the same methods with SPDY or compressed/proxied SPDY.