6 ms·

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

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.
    - forgotusername 14y ago
      I love the anecdote (and loathe working with that stereotype), but don't think it applies here. We're not exactly drawing a box labelled "DATA", one labelled "SERVER", and drawing a line between them: these protocols are significant, incompatible implementations that do almost the same thing internally, and interact equally as badly with the remainder of the stack externally. To say the similarity is only superficial seems inaccurate. It's a bit like redesigning a car from scratch just because you need snow chains for certain roads, and upholstery covers for certain passengers.
    - batista 14y ago
      This "architecture astronaut" phrase. I don't think it means what you think it means. The two descriptions you make below describe much more essentially than superficially or "astronautically", the same kind of thing, optimized for slightly different use cases (not even THAT different).
      - tptacek 14y ago
        I didn't call anyone an architecture astronaut; I'm just citing the first paragraph of that post.
- wmf 14y 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.
- cheatercheater 14y 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 14y 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.)
- gecko 14y 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.
  - bgilroy26 14y ago
    >Microsoft's variant has a clear advantage for the user in at least the short-to-medium term. The approach also often comes out on top when the client is a business and accounting considerations take the lead, as opposed to B2C situations. When you divide the cost of a Microsoft license by 7 (number of years a business will be running XP on a workstation) it turns into a really great price. The reverse compatibility mentality is universal in the enterprise.
  - huggyface 14y ago
    Ajax, notably, is a Microsoft invention. To put that into proper context, XmlHttpRequest was a hack by a single person at Microsoft -- with zero input or coordination or working groups or long term planning -- on the MSXML team to do a favour to the Outlook team. Further it could only happen because of ActiveX, and paralleled various other light request tools that existed at the time. XmlHttpRequest is a great demonstration of a hacker getting a solution out there. EDIT: Downvotes? I am intimately aware of how XmlHttpRequest came into existence, having been closely involved with its birth, so if someone has some correction to add, please add it. But in no universe does XmlHttpRequest vindicate Microsoft on moving web standards along. Their contribution was unintentional and largely accidental.
spot 14y ago
http://peter.sh/experiments/chromium-command-line-switches/#enable-websocket-over-spdy http://peter.sh/experiments/chromium-command-line-switches/#...
BarkMore 14y 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 14y ago
It's interesting that Google Analytics Realtime just updates using a never-ending GET with type text/chat.
adgar 14y 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 http://dev.chromium.org/spdy/spdy-whitepaper
- sciurus 14y 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.
  - mbelshe 14y ago
    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.
rafaelferreira 14y 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.

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.
  - forgotusername 14y ago
    I love the anecdote (and loathe working with that stereotype), but don't think it applies here. We're not exactly drawing a box labelled "DATA", one labelled "SERVER", and drawing a line between them: these protocols are significant, incompatible implementations that do almost the same thing internally, and interact equally as badly with the remainder of the stack externally. To say the similarity is only superficial seems inaccurate. It's a bit like redesigning a car from scratch just because you need snow chains for certain roads, and upholstery covers for certain passengers.
  - batista 14y ago
    This "architecture astronaut" phrase. I don't think it means what you think it means. The two descriptions you make below describe much more essentially than superficially or "astronautically", the same kind of thing, optimized for slightly different use cases (not even THAT different).
    - tptacek 14y ago
      I didn't call anyone an architecture astronaut; I'm just citing the first paragraph of that post.
wmf 14y 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.
cheatercheater 14y 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 14y 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.)

gecko 14y 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.
- bgilroy26 14y ago
  >Microsoft's variant has a clear advantage for the user in at least the short-to-medium term. The approach also often comes out on top when the client is a business and accounting considerations take the lead, as opposed to B2C situations. When you divide the cost of a Microsoft license by 7 (number of years a business will be running XP on a workstation) it turns into a really great price. The reverse compatibility mentality is universal in the enterprise.
- huggyface 14y ago
  Ajax, notably, is a Microsoft invention. To put that into proper context, XmlHttpRequest was a hack by a single person at Microsoft -- with zero input or coordination or working groups or long term planning -- on the MSXML team to do a favour to the Outlook team. Further it could only happen because of ActiveX, and paralleled various other light request tools that existed at the time. XmlHttpRequest is a great demonstration of a hacker getting a solution out there. EDIT: Downvotes? I am intimately aware of how XmlHttpRequest came into existence, having been closely involved with its birth, so if someone has some correction to add, please add it. But in no universe does XmlHttpRequest vindicate Microsoft on moving web standards along. Their contribution was unintentional and largely accidental.

spot 14y ago

http://peter.sh/experiments/chromium-command-line-switches/#enable-websocket-over-spdy http://peter.sh/experiments/chromium-command-line-switches/#...

BarkMore 14y 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 14y ago

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

adgar 14y 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 http://dev.chromium.org/spdy/spdy-whitepaper

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

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