Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment Re:What about pipelining and keep-alive? (Score 2) 275

Yes. Pipelining support was optional in HTTP/1.1 effectively.
Multiplexing in SPDY is so essential that if you mess it up, Google (and probably all other sites that use SPDY) won't work at all.
People are thus strongly motivated to get it right, which wasn't true of many of HTTP/1.1's effectively optional features.

Comment Re:What about pipelining and keep-alive? (Score 1) 275

It all depends on the nature of the loss on the path the packets traverse.
Correlated (i.e. simultaneous) loss will be *worse* to the many-connection case. When a network is congested this is the likely loss-type.
Actual random loss (e.g. when using wifi and someone turns on the microwave) can cause a single connection to perform worse than many.
In most cases, the single connection can outperform multiple connections after a bit of startup time.

In all cases many connections adds to buffer bloat and decreases the ability of the TCP stack to react to real congestion.

Comment Re:What about pipelining and keep-alive? (Score 1) 275

As for server push... in that case, the server determines what the browser may need. The browser can cancel streams if it finds it already has the resource being pushed.
The server must announce what resources it will push before they're referenced in another resource (to avoid data races).
This assumes some smarts in the servers that doesn't exist in typical HTTP servers (unless they're doing inlining).

Comment Re:Supported since Firefox 11 (Score 1) 275

Ask Patrick McManus, who implemented it :)
There was a spec, which has been public since day one (no reverse engineering required), along with open-source implementations of both client and server.
The SSL patch has been available as well and is hopefully going into the next OpenSSL release (but... those take a while).

Unfortunately, the spec was wrong in a couple of places, which Patrick pointed out as he went along (and so we fixed the spec). That is why it is good (and imho I wish it was still necessary) that the IETF wants to see multiple implementations by different implementors of specs.

Comment Re:It'd be a faster still without all the redirect (Score 1) 275

If the server to which you're connecting is authoritative for all of the redirected sites, and you're using server push with SPDY... actually you could eliminate the RTTs for the redirects even if they were still there (by server pushing them all in sequence). ... but that is just too cute. Getting rid of the redirects would be better :)

Comment Re:What about pipelining and keep-alive? (Score 1) 275

Using SPDY, servers are able to publish a setting (whenever they want, including at connect time) which advertises how many concurrent streams are allowed. In all cases SPDY gives more control than HTTP.

And, if you multiplex connections over one SPDY connection, you often end up using less resources overall (including memory) as compared to HTTP connections.
The average page uses ~40 connections, nowhere near just one connection!

If you don't care about resource utilization, it still speeds web up web pages...

Comment Re:What about pipelining and keep-alive? (Score 5, Informative) 275

As one of the creators of SPDY..

No, HTTP suffers from head-of-line blocking. There is no way around that.
HTTP also doesn't have header compression (which matters quite a bit on low-bandwidth pipes) nor prioritization to ensure that your HTTP, javascript and CSS load before the lolkittens :)

Slashdot Top Deals

Many aligators will be slain, but the swamp will remain.