6 ms·

I don't like SPDY. It's trying to solve a transport problem at the application level. Plus it seems to be quite complex. I'd love to see Google promote a trans

I don't like SPDY. It's trying to solve a transport problem at the application level. Plus it seems to be quite complex. I'd love to see Google promote a transport protocol like SCTP[1], and do HTTP over SCTP instead. If Google pushed SCTP a little bit, we might see it pop on Linux and Windows within a few years. [1]:http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol http://en.wikipedia.org/wiki/Stream_Control_Transmission_Pro...

drdaeman 15y ago
Same thoughts. Present-day GNU/Linux should work with IPPROTO_SCTP, it's only Windows who lack the implementation out of the box.
- deleted 15y ago
  [deleted]
- nimrody 15y ago
  There are a lot more devices on the route between the browser and the server -- they all currently expect TCP. Few examples: firewalls, load balancers, etc.
- planckscnst 15y ago
  Correct me if I'm wrong, but as far as I'm aware, GNU has nothing to do with SCTP. Linux supports SCTP. My non-GNU Linux system talks SCTP just fine.
dchest 15y ago
"Q: What about SCTP? A: SCTP is an interesting potential alternate transport, which offers multiple streams over a single connection. However, again, it requires changing the transport stack, which will make it very difficult to deploy across existing home routers. Also, SCTP alone isn't the silver bullet; application-layer changes still need to be made to efficiently use the channel between the server and client." http://www.chromium.org/spdy/spdy-whitepaper http://www.chromium.org/spdy/spdy-whitepaper
- henryprecheur 15y ago
  I agree that SPDY would be a "quicker" solution. Just modify the browsers and wait a year or two, and 30%+ of the people browsing the web will have it. SCTP have the nice side effect of improving things like streaming, and games. As for application-layer changes, I don't think it would be too difficult to do, kind of like ipv6 (I don't have anything to back this up, it's just a hunch). SCTP deployment will much longer than SPDY, but SCTP seems to be the "right thing to do". Not only for the web, but for other things that use the network. Internet is not only http:// http://. UPDATE: I just realized that saying that the transition to SCTP will be like IPv6 isn't necessarily a good point for SCTP :-D ... I guess I'm a purist and not a pragmatist.
igrigorik 15y ago
SCTP addresses some of the same needs (primarily the multiplexing), but the major hurdle there is the fact that we're ditching TCP. As far as an upgrade path goes: it is much harder to get existing servers to support SCTP (think about Apache, Nginx, etc), then to bolt on support for a different application-level protocl (replace/augment HTTP with SPDY).
- newman314 15y ago
  afaik, nginx does not have support for spdy
- piotrSikora 15y ago
  I disagree. It's much, much easier to support SCTP (since it's already provided by the operating system) than it is to support SPDY with all the server pushes, etc. But to be honest, I don't know what was the source of such comparison... It's apples to oranges.
  - rfugger 15y ago
    The source of the comparison is that the main thrust of both SCTP and SPDY is multiplexing multiple independent data streams on a single connection.
    - piotrSikora 15y ago
      Is is, really? For me multiplexing is just nice addition to SPDY. Personally, I consider "server pushes" as the main feature and "full encryption and compression" as nice improvements.
      - Lennie 15y ago
        Well, the primary reason for the existence of SPDY is encryption everywhere and speed. Something which with current HTTP/HTTPS doesn't really exist. HTTPS is still slower than HTTP and HTTP is slower than SPDY. A lot of the speed increase comes from the use of multiplexing. So without it, it wouldn't be able to achieve most of it's goals.
mbelshe 15y ago
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.

drdaeman 15y ago

Same thoughts. Present-day GNU/Linux should work with IPPROTO_SCTP, it's only Windows who lack the implementation out of the box.

deleted 15y ago
[deleted]
nimrody 15y ago
There are a lot more devices on the route between the browser and the server -- they all currently expect TCP. Few examples: firewalls, load balancers, etc.
planckscnst 15y ago
Correct me if I'm wrong, but as far as I'm aware, GNU has nothing to do with SCTP. Linux supports SCTP. My non-GNU Linux system talks SCTP just fine.

dchest 15y ago

"Q: What about SCTP? A: SCTP is an interesting potential alternate transport, which offers multiple streams over a single connection. However, again, it requires changing the transport stack, which will make it very difficult to deploy across existing home routers. Also, SCTP alone isn't the silver bullet; application-layer changes still need to be made to efficiently use the channel between the server and client." http://www.chromium.org/spdy/spdy-whitepaper http://www.chromium.org/spdy/spdy-whitepaper

henryprecheur 15y ago
I agree that SPDY would be a "quicker" solution. Just modify the browsers and wait a year or two, and 30%+ of the people browsing the web will have it. SCTP have the nice side effect of improving things like streaming, and games. As for application-layer changes, I don't think it would be too difficult to do, kind of like ipv6 (I don't have anything to back this up, it's just a hunch). SCTP deployment will much longer than SPDY, but SCTP seems to be the "right thing to do". Not only for the web, but for other things that use the network. Internet is not only http:// http://. UPDATE: I just realized that saying that the transition to SCTP will be like IPv6 isn't necessarily a good point for SCTP :-D ... I guess I'm a purist and not a pragmatist.

igrigorik 15y ago

SCTP addresses some of the same needs (primarily the multiplexing), but the major hurdle there is the fact that we're ditching TCP. As far as an upgrade path goes: it is much harder to get existing servers to support SCTP (think about Apache, Nginx, etc), then to bolt on support for a different application-level protocl (replace/augment HTTP with SPDY).

newman314 15y ago
afaik, nginx does not have support for spdy
piotrSikora 15y ago
I disagree. It's much, much easier to support SCTP (since it's already provided by the operating system) than it is to support SPDY with all the server pushes, etc. But to be honest, I don't know what was the source of such comparison... It's apples to oranges.
- rfugger 15y ago
  The source of the comparison is that the main thrust of both SCTP and SPDY is multiplexing multiple independent data streams on a single connection.
  - piotrSikora 15y ago
    Is is, really? For me multiplexing is just nice addition to SPDY. Personally, I consider "server pushes" as the main feature and "full encryption and compression" as nice improvements.
    - Lennie 15y ago
      Well, the primary reason for the existence of SPDY is encryption everywhere and speed. Something which with current HTTP/HTTPS doesn't really exist. HTTPS is still slower than HTTP and HTTP is slower than SPDY. A lot of the speed increase comes from the use of multiplexing. So without it, it wouldn't be able to achieve most of it's goals.

mbelshe 15y ago

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.