[henryprecheur]

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_Pro...

[dchest]

"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

[henryprecheur]

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://.

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.

[drdaeman]

Same thoughts.

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

[planckscnst]

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.

[igrigorik]

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).

[piotrSikora]

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.

[mbelshe]

SCTP is not available on Windows by default, and you need administrative privileges to deploy it. I'm not trying to start an OS war debate, but this is a very practical problem.

Mobile, oddly enough, may be the best route to bring both IPv6 and SCTP to life.

[piotrSikora]

Good point... But we were talking about servers ;)

[bostonvaulter2]

Wouldn't SCTP need to be installed on both the client and the server?

[piotrSikora]

Yes (for adoption) and no (for having server support).

But those are two very different problems ;)

[mbelshe]

Heh - I didn't think a server side SCTP implementation was very interesting if you don't have clients to use it.

[rfugger]

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]

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]

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.

[newman314]

afaik, nginx does not have support for spdy

[mbelshe]

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.