SPDY Review by Opera Software

http://lists.w3.org/Archives/Public/ietf-http-wg/2012AprJun/0498

by jacobr • 14 years ago

225 65 14 years ago

lists.w3.org

rfugger• 14 years ago

Seems like a lot of the issues they bring up would be addressed by using SCTP as a transport instead of TCP. Why aren't we moving in that direction?

forgotusername4• 14 years ago

Because SPDY "looks like" SSL at layer 5, while SCTP does not: common deployments of Squid (one of the most popular HTTP proxies on earth) will pass through SPDY if they allow SSL, without any config changes.

On the other hand, SCTP has much stronger interactions with basically any deployed firewall/proxy anywhere, lacks widely used implementation for popular operating systems (Windows!), etc. For many networks, deployment of SCTP might mean replacing millions of $ networking hardware.

bradleyjg• 14 years ago

There are billions of dollars worth of ASICs in the wild designed to accelerate processing TCP.

cheatercheater3• 14 years ago

There were billions of dollars worth of silicon in the wild designed to execute PDP-11 microcode.

wmf2• 14 years ago

SCTP doesn't pass through NATs.

tptacek3• 14 years ago

For one obvious reason, SCTP won't make it through firewalls. Part of the design goal of SPDY is to minimize changes at every other layer of the web protocol stack.

mbelshe3• 14 years ago

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.

dkhenry• 14 years ago

The biggest takeaway I get form this is that Opera has done this before but never shared it with the outside world. At a minimum we know that the kind of speed up SDPY proposes is possible and apparently used in production systems.

jerf4• 14 years ago

It is well known that Opera has done a lot of work in this area: http://en.wikipedia.org/wiki/Opera_Mini#Functionality

Of all the parties Google should listen to for SPDY feedback, Opera is probably the top of the list. It looks like Opera took it quite seriously and shared a lot of good work with us all, and I thank them for it. I'd say their point about the asynchronous headers is one that requires serious addressing ASAP. For one example, is it valid to push down a header redeclaring the encoding of the response at the very end? What would that even mean? It's a good point.

mdwelsh2• 14 years ago

There's a big difference between having a closed, proprietary protocol and releasing something as open source with a public spec.

rbhm2• 14 years ago

"so lots of heuristics has to be applied"

I would think if I was going to submit something to W3C I'd consider asking someone to proofread it.

gecko2• 14 years ago

It's a 2200-word document written by someone whose native language isn't English, and there is a single verb that doesn't agree with its subject. Since that's the only actual complaint you appear to have about the document, I'll assume you agreed with the very well reasoned, well researched viewpoints therein. Overall worth reading, I'd say.

rbhm2• 14 years ago

still working my way through it, but was certainly put off by a lack of respect for the language it was written in.

forgotusername4• 14 years ago

Another dirty little secret is that WebSocket does not (yet) work over SPDY, despite the fact both protocols essentially originated in house at the same company.

Both are effectively hacks on existing well established protocols, but both affecting different layers. With WebSocket, you cannot use your tried and tested HTTP parser. With SPDY, you cannot use your tried and tested SSL implementation. With a little bit of foresight, implementation of both might have involved use of only SSL Next Protocol Negotation (SPDY's approach) and a completely separate, orthogonal SPDY/WebSocket parser. This would also remove some of the more "innovative" features of WebSocket (Sec-WebSocket-Key and that magical fixed UUID).

This is a testament to how heavily rushed both protocols were, and the kind of thing that could be avoided with a more strongly community lead process, which was missing at least in the early stages of WebSocket. I have no idea what it was like for SPDY, but given that the "innovative" header compression feature somehow survived, I'm guessing not good.

huggyface2• 14 years ago

could be avoided with a more strongly community lead process

Would that have yielded something better? I would argue that it would have yielded nothing.

Though nonetheless I am a bit confused by your comparison of the two. WebSockets are not "another way of doing HTTP". SPDY is. They are separate solutions for different problems.

forgotusername4• 14 years ago

Despite being entirely different beasts from a design perspective, they solve essentially the same problem: bidirectional communication designed to minimize latency over a single established TCP connection, with protocol-internal notions of channels and framing.

wmf2• 14 years ago

SPDY and WebSocket both have protocol negotiation and framing but they are implemented differently. That's why Microsoft's S+M proposal essentially recasts SPDY on top of WebSocket so they can share the negotiation and framing code.

cheatercheater3• 14 years ago

> Would that have yielded something better?

It would have yielded the same thing as W3C's decade long stagnation during the development of XHTML: everyone gets bored and they set up WhatWG instead.

fibertbh• 14 years ago

"Rushed" is the wrong opinion to have about it.

What's impressive is that at no other company you could wake up one morning and say, "HTTP is slow, so let's change that." Google, amazingly, can do stuff like that, and I'd rather them ship early than not ship at all.

(Well I guess Microsoft could have done it but they would have screwed it up like every other net technology they introduce and then we'd have two internets or something worse.)

gecko2• 14 years ago

I'm not sure it's fair to say that Microsoft has "screwed up" every technology they've had a hand in. Ajax, notably, is a Microsoft invention. What I do think is a fair statement is that Microsoft has historically been slavishly backwards-compatible even with obvious design mistakes and implementation artifacts, whereas the other two 800-pound gorillas (Google and Apple) have a mantra of never keeping legacy tech around when it can safely be replaced. The latter results in cleaner technologies; the former results in longer-living technologies. As a programmer, I prefer the Google/Apple take, but it's worth noting that Microsoft's variant has a clear advantage for the user in at least the short-to-medium term.

dpark• 14 years ago

> Well I guess Microsoft could have done it but they would have screwed it up like every other net technology they introduce

http://en.wikipedia.org/wiki/XMLHttpRequest

flomo• 14 years ago

> Well I guess Microsoft could have done it but...

"Why is IE faster? It cheats!" http://www.mail-archive.com/foib@ianbell.com/msg00031.html

fusiongyro3• 14 years ago

HTTP wasn't, and isn't, broken. Google alone had the combination of a financial incentive to improve, engineers capable of improving, and few application-level opportunities to exploit instead. This is literally the last thing you should worry about optimizing. Very few of us are privileged enough to work at a place that is so short on real problems we can worry about one like this.

In this industry we have a 15-25 year rewrite cycle. The cycle always begins with something deceptively simple that wins wide support through being easy, and ends with multilayered nonsense of dizzying complexity. Efficiency was not a design goal of HTTP. "Changing" that isn't just insulting to the spirit of HTTP, it expresses a complete lack of regard for history.

I don't know how we're going to break the rewrite cycle, but I can tell you heaping complexity atop complexity appears to be exactly the engine driving it, and just when things reach the pinnacle of the absurd, someone comes along with a disruptive, simple alternative and takes over the world with it. SPDY is late-game technology. The end of this loop is near, and we'd be better served keeping an eye open for the start of the next one than trying to master the intricacies of one more difficult and unnecessary improvement.

sparkie• 14 years ago

Two internets looks like the direction Google are taking us, not Microsoft. No other company is so willing to bypass the standardization process so willingly, and force other browser vendors to use their technology or face compatibility issues.

SPDY, NaCl, Dart are among some of the examples. Developed behind closed doors where nobody else can have a say, then released as an "open standard", but at the same time slipped into the browser and promoted for use - thereby eliminating the option for others to propose an alternative, or any major (breaking) change.

I'm all for pushing forward with tehcnology, but google should open their doors earlier, or we'll end up in a situation where they're effectively dictating the direction of the web and other browser vendors are busy playing catch-up.

It'll only be impressive if Google actually take the advice from Opera et al, and adjust their SPDY protocol to suit everyone - not just Chrome users. (And the same for NaCl, Dart, and the next "new standard" Google push for).

spot• 14 years ago

http://peter.sh/experiments/chromium-command-line-switches/#...

BarkMore• 14 years ago

With WebSocket, you cannot use your tried and tested HTTP parser.

Why? I am using my tried and tested HTTP parser for WebSocket. I am doing something wrong?

euroclydon• 14 years ago

It's interesting that Google Analytics Realtime just updates using a never-ending GET with type text/chat.

adgar• 14 years ago

> I have no idea what it was like for SPDY, but given that the "innovative" header compression feature somehow survived, I'm guessing not good.

Considering the overwhelming majority of HTTP requests are nearly all headers, and request headers see 88% compression with SPDY [0], you seem to have an awfully negative view of header compression.

[0] http://dev.chromium.org/spdy/spdy-whitepaper

sciurus• 14 years ago

The complaint is about how the compression is implemented-

   Header compression is a good feature with real world applications,
   and deflate with persistent context is a good approach to achieve
   it. A fixed dictionary is probably not very effective as it
   complicates the implementation while only providing initial value to
   the compression. As an example, this is how the average requests
   sizes compares between HTTP and SPDY in different modes, using the
   set of captured headers used to train the current SPDY 3 dictionary.

     HTTP                             821.1
     HTTP zlib compressed             543.5
     HTTP compressed with dictionary  497.0
     SPDY                             913.7
     SPDY zlib compressed             606.5
     SPDY compressed with dictionary  517.0

   I.e. Just putting the HTTP request in a SPDY stream (after removing
   disallowed headers) only differs by 20 bytes to SPDY binary header
   format with dictionary based zlib compression. The benefit of using
   a dictionary basically goes away entirely on the subsequent request.

rafaelferreira• 14 years ago

The discussion on the original article is in the context of basing Http 2 on SPDY. In other words, the very community-lead process you say does not exist.

b7kich• 14 years ago

Great read. Thanks for sharing!

majke• 14 years ago

> While the concerns is valid, flow control looks like overkill to something where a per-channel pause control frame could do the same job with less implementation and protocol overhead.

Coming from messaging world I can say: nope. "Pause" frames are a very, very bad idea and lead to more problems than they solve. Windowing is much better engineering choice.

> Also note that TCP provides the URG channel for exception messaging.

Which doesn't work.

> 2.6. Push ... The client has the option to read and discard this information, but that may be a costly waste of bandwidth.

It's worth noting that caching and Push don't play together.

dboat• 14 years ago

All your assertions are unsubstantiated. I'm not saying they're wrong, I'm just pointing out that you haven't explained any of your claims. You needn't go to any great length to cite sources, but a sentence or two of facts or explanation to match each assertion would make your post more useful to read.

afimrishi• 14 years ago

It's worth noting that some common web performance techniques also don't play well with caching. Take a look at http://stackoverflow.com/questions/4791807/data-uris-and-cac.... SPDY server push at least allows the resource to still be named (via its URL) so it can be cached and speed up page load times, although goodput may suffer due to unnecessary pushes. This is an area where there are active proposals: https://groups.google.com/d/topic/spdy-dev/TetVOinB-LM/discu....

j_s• 14 years ago

> 2.5. Asynchronous headers ... While this is already possible to do with chunked encoding trailer, it is not a feature in popular use.

Can anyone point to a working example of this use of a chunked encoding trailer? It seems like a solution to the primary problem that came up on the discussion of HTTP Streaming: http://news.ycombinator.com/item?id=4042247

> And if it for instance needs to redirect the user, it can’t change the status/headers to a 302/Location if it’s already ...

cwp• 14 years ago

Yeah, I went down this road too. It looks like a good way to handle exceptions during streaming, but browser support is essentially zero.

smallblacksun• 14 years ago

Does it work in Opera?

ricardobeat• 14 years ago

They sound defensive. That's probably a good thing.

Can someone explain how Microsoft's S+M proposal differs and how well it would work in the real world with proxies, firewalls, NAT etc? (I'm being lazy and haven't read the paper)

mbelshe3• 14 years ago

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.

SPDY Review by Opera Software

Related Stories