Send to Kindle

Thursday, June 30, 2011

Firefox CWND

‹prev | My Chain | next›

Up today, I release the beta version of SPDY Book! But the gods of my chain must first be appeased. Today is not the day to draw their ire.

So I take a break from my recent deep-in-the-bowels coding of node-spdy to play a bit with, of all things, Firefox. The latest version of Firefox boasts sorting of open HTTP pipes by TCP/IP congestion window (CWND). The CWND is the amount of data a TCP/IP connection will accept before an acknowledgement is sent. The CWND starts small, but increases quickly as the TCP/IP tubes are warmed by fresh data flowing through them.

Browsers open up 6 TCP/IP connections to a server. Sorting them by CWND does not address nearly the breadth of what SPDY is meant for, but it still might be a nice performance boost.

The test page put out by Patrick McManus includes 2 very large images and several smaller images. Loading this page should open up two interweb tubes for the large images and several other tubes for the small images.

By the the time the page is done loading the large images, the two tubes used to download those images should have very large CWNDs. The tubes that transport only tiny images will not have enough data flow through them to warm them (and increase their CWNDs). If Firefox truly does sort tubes by CWND, another click on the site should use one of those tubes.

To the Wiresharks!

I am only interested in which tubes are used for which HTTP requests, so I use Wireshark filters to only show packets with HTTP requests or responses in them. I then move through each tube (Wireshark calls them streams for some reason) in turn increasing the tube in in the filter expression: "(http.request or http.response) and eq 0".

The first tube contains, as expected the web page itself and one of the small images:

The second tube contains just a small image:

The third tube also holds only a small image.

On the fourth tube, I hit the jackpot:

It is the tube that downloaded the first large image and, as promised, it is also used by Firefox to download the secondary request that I made (a PNG) after the homepage and big images had finished loading.

Nice! That is a clever little change from the Firefox devs that did not require much code change, does not muck with TCP/IP, but ought to give users a nice performance boost. Kudos Firefox devs!

Day #62

No comments:

Post a Comment