9 ms·

SPDY Review by Opera Software

225 points by jacobr 14y ago

rfugger 14y 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?
- forgotusername 14y 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 14y ago
  There are billions of dollars worth of ASICs in the wild designed to accelerate processing TCP.
  - cheatercheater 14y ago
    There were billions of dollars worth of silicon in the wild designed to execute PDP-11 microcode.
- wmf 14y ago
  SCTP doesn't pass through NATs.
- tptacek 14y 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.
- mbelshe 14y 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 14y 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.
- jerf 14y ago
  It is well known that Opera has done a lot of work in this area: http://en.wikipedia.org/wiki/Opera_Mini#Functionality 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.
  - mdwelsh 14y ago
    There's a big difference between having a closed, proprietary protocol and releasing something as open source with a public spec.
    - jerf 14y ago
      I'm having a lot of trouble with people imputing argument to me I'm not making this week. My point is that this is a known thing that they have this experience, not that Opera Mini solves anything else, and that their experience is highly relevant.
      - mdwelsh 14y ago
        Sorry for not being clear. I completely agree that Opera's experience is relevant and useful. They have done some great work on optimizing mobile web performance and it would be fantastic to draw on that expertise to make open standards which everyone can benefit from. However, don't forget that SPDY and related technologies create a problem for Opera, which is based on a closed protocol and ecosystem. Personally, I believe in an open web based on open technologies which can be implemented by anyone. Without releasing code or a spec, it's easy to take a position that your approach is better - since nobody can scrutinize you to prove otherwise.
rbhm 14y 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.
- gecko 14y 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.
  - rbhm 14y ago
    still working my way through it, but was certainly put off by a lack of respect for the language it was written in.
    - silvestrov 14y ago
      Opera Software is located in Norway. Let's see how much "respect" you have for the language if you have to write in Norwegian. I bet their English is better than yours. You didn't even start the first word using a capital 'S', so you have a mistake already when writing a single sentence.
      - hoppipolla 14y ago
        Random pedantic fact: Martin, and several of the listed contributers work in our office in Linköping, Sweden.
    - breadbox 14y ago
      Why is it when people say things like "lack of respect for [insert language here]", it's always to defend their own lack of respectful behavior towards, you know, actual human beings?
    - jerf 14y ago
forgotusername 14y 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.
- huggyface 14y 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.
  - forgotusername 14y 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.
    - tptacek 14y ago
      That's only superficially accurate, working in the same way as the first graf of Spolsky's "Architecture Astronauts" post from several years back: http://www.joelonsoftware.com/articles/fog0000000018.html http://www.joelonsoftware.com/articles/fog0000000018.html In reality, SPDY and WebSockets have two very different goals: * SPDY is a transport optimized for the HTTP request/response service model, down to specific features to compress HTTP-style headers. * WebSockets is a transport optimized for tunneling bidirectional application-level protocols over an HTTP-style transport.
b7kich 14y ago
Great read. Thanks for sharing!
majke 14y 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 14y 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 14y 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-caching 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/discussion https://groups.google.com/d/topic/spdy-dev/TetVOinB-LM/discu....
j_s 14y 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 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 14y 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 14y ago
    Does it work in Opera?
    - gsnedders 14y ago
      Reinterpreting content? Nope. Opera (and only Opera) does anything with them — they're available through `XMLHttpRequest`.
ricardobeat 14y 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)
- mbelshe 14y 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.

225 points by jacobr 14y 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?

forgotusername 14y 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 14y ago
There are billions of dollars worth of ASICs in the wild designed to accelerate processing TCP.
- cheatercheater 14y ago
  There were billions of dollars worth of silicon in the wild designed to execute PDP-11 microcode.
wmf 14y ago
SCTP doesn't pass through NATs.
tptacek 14y 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.
mbelshe 14y 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 14y 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.

jerf 14y ago
It is well known that Opera has done a lot of work in this area: http://en.wikipedia.org/wiki/Opera_Mini#Functionality 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.
- mdwelsh 14y ago
  There's a big difference between having a closed, proprietary protocol and releasing something as open source with a public spec.
  - jerf 14y ago
    I'm having a lot of trouble with people imputing argument to me I'm not making this week. My point is that this is a known thing that they have this experience, not that Opera Mini solves anything else, and that their experience is highly relevant.
    - mdwelsh 14y ago
      Sorry for not being clear. I completely agree that Opera's experience is relevant and useful. They have done some great work on optimizing mobile web performance and it would be fantastic to draw on that expertise to make open standards which everyone can benefit from. However, don't forget that SPDY and related technologies create a problem for Opera, which is based on a closed protocol and ecosystem. Personally, I believe in an open web based on open technologies which can be implemented by anyone. Without releasing code or a spec, it's easy to take a position that your approach is better - since nobody can scrutinize you to prove otherwise.

rbhm 14y 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.

gecko 14y 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.
- rbhm 14y ago
  still working my way through it, but was certainly put off by a lack of respect for the language it was written in.
  - silvestrov 14y ago
    Opera Software is located in Norway. Let's see how much "respect" you have for the language if you have to write in Norwegian. I bet their English is better than yours. You didn't even start the first word using a capital 'S', so you have a mistake already when writing a single sentence.
    - hoppipolla 14y ago
      Random pedantic fact: Martin, and several of the listed contributers work in our office in Linköping, Sweden.
  - breadbox 14y ago
    Why is it when people say things like "lack of respect for [insert language here]", it's always to defend their own lack of respectful behavior towards, you know, actual human beings?
  - jerf 14y ago

forgotusername 14y 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.

huggyface 14y 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.
- forgotusername 14y 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.
  - tptacek 14y ago
    That's only superficially accurate, working in the same way as the first graf of Spolsky's "Architecture Astronauts" post from several years back: http://www.joelonsoftware.com/articles/fog0000000018.html http://www.joelonsoftware.com/articles/fog0000000018.html In reality, SPDY and WebSockets have two very different goals: * SPDY is a transport optimized for the HTTP request/response service model, down to specific features to compress HTTP-style headers. * WebSockets is a transport optimized for tunneling bidirectional application-level protocols over an HTTP-style transport.

b7kich 14y ago

Great read. Thanks for sharing!

majke 14y 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 14y 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 14y 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-caching 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/discussion https://groups.google.com/d/topic/spdy-dev/TetVOinB-LM/discu....

j_s 14y 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 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 14y 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 14y ago
  Does it work in Opera?
  - gsnedders 14y ago
    Reinterpreting content? Nope. Opera (and only Opera) does anything with them — they're available through `XMLHttpRequest`.

ricardobeat 14y 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)

mbelshe 14y 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.