akalin

Thanks for the feedback! In my defense, I can only say that I was a less-experienced coder when I wrote that. :)

The comments were intended to extend the preceding prose explanation rather than being comments per se. The actual code is not much longer than the naive version, though, so if I get around to writing an updated version, I'd probably find some other method of conveying that info.

Some other things I'd do differently if I were to update it today:

- I'd write it in Javascript and provide a little interactive applet to play with it. (Similar to my posts on primality testing: http://www.akalin.cx/intro-primality-testing and http://www.akalin.cx/primality-testing-polynomial-time-part-... .)

- I'd upload the code to GitHub.

- I'd add unit tests.

Cheers!

Re. multiplexing at the HTTP layer, because an HTTP replacement has to be deployable and testable. However, now that the ideas in SPDY have been proven and are on their way to being standardized, you can look at QUIC to see what can be done when not limited to TCP and HTTP.

By overhead I mean latency overhead -- running a program to download a site to a local file and then displaying it in a browser will almost certainly have a higher time to start render. Not to mention you're hitting everything cold (i.e., not using the browser's cache).

Re. Patrick's sentence, you're right, but as I mentioned above, SPDY/4 will become HTTP/2 (we're working through the standardization process). So I think most of the major players are on board with "fixing" HTTP pipelining by using SPDY-style multiplexing.

Re. thinking bigger, you might want to read up on QUIC, which was announced recently: http://en.wikipedia.org/wiki/QUIC . Based on that, I would content that at least we on the Chromium team don't have tunnel vision. :)

Re. your question, Patrick's data is from Firefox only I believe. You're right that it's not surprising his stats show that SPDY helps over HTTP without pipelining. But the more interesting thing is that HTTP with pipelining still doesn't help that much over HTTP without pipelining (on average) and SPDY still beats it by orders of magnitude. I'd have to dig, but I'm pretty sure there are similar stats on the Chromium side.

I didn't have to look hard to find bug reports for pipelining. An example is https://bugs.launchpad.net/ubuntu/+source/apt/+bug/948461 for Amazon's S3. I'd be interested if the problem is still reproducible now. Also, one of the comments mentions Squid 2.0.2 as being buggy.

Also, see https://insouciant.org/tech/status-of-http-pipelining-in-chr... for a link to Firefox's blacklist of buggy servers (and a good discussion of pipelining in Chromium).

Most of the improvements in SPDY are latency improvements, so if you're downloading sites with netcat and then viewing them in a browser, I'm pretty sure the overhead of that would dwarf anything SPDY would save. That having been said, there's ample evidence of SPDY improving things. From http://bitsup.blogspot.com/2012/11/a-brief-note-on-pipelines... :

"Also see telemetry for TRANSACTION_WAIT_TIME_HTTP and TRANSACTON_WAIT_TIME_HTTP_PIPELINES - you'll see that pipelines do marginally reduce queuing time, but not by a heck of a lot in practice. (~65% of transactions are sent within 50ms using straight HTTP, ~75% with pipelining enabled).... Check out TRANSACTON_WAIT_TIME_SPDY and you'll see that 93% of all transactions wait less than 1ms in the queue!"

What is the caution?

HTTP pipelining is turned off by default in most browsers due to concerns with buggy proxies and servers (see https://bugzilla.mozilla.org/show_bug.cgi?id=264354 ). It may work for you and the particular set of servers you visit, but I suspect browser developers would rather have a browser that by default works with the widest possible range of configurations.

Unfortunately, it being turned off by default in most browsers means that most people won't see the benefits from it. Hopefully, the upcoming HTTP/2 standard will fare better (latest draft: https://tools.ietf.org/html/draft-unicorn-httpbis-http2-01 ).

Note that HTTP/2 will be based on SPDY (in particular, SPDY/4 with the new header compressor). Hopefully, when the standard is finalized and we have multiple strong implementations, that will allay the concerns you seem to have with SPDY today.

(Disclaimer: I work on SPDY / HTTP/2 for Chromium.)

Disabling gzip compression isn't the only workaround to the CRIME attack. For Chromium, Adam Langley patched zlib to differentiate between various classes of data; see https://code.google.com/p/chromium/issues/detail?id=139744#c... and https://chromiumcodereview.appspot.com/10837057/ .

However, it's more difficult for other SPDY implementations to use the patched zlib, so this isn't an ideal solution. For SPDY/4 / HTTP/2, we will have a custom header compressor which is intended to eliminate CRIME-like attacks: https://tools.ietf.org/html/draft-ietf-httpbis-header-compre... .

(Disclaimer: I work on SPDY / HTTP/2 for Chromium.)