Browsers and TCP revisited….

Over a decade ago, I was the editor of the HTTP spec (for both proposed and draft standard; thankfully I didn’t sign up to do the full standard work). Roy Fielding has had that headache for the full standard.

As will become clear as this blog unfolds, there is a problem that browsers are exacerbating.

One of the details in RFC 2068 and 2616 is that a single client is supposed to use no more than two TCP connections at once between a client to an a single server.  The reason for this was several fold:

1. You can actually make a single TCP connection move data faster than many connections, if you do it properly, with less overhead, as we showed in our SIGCOMM paper (for which I’ve never seen other data showing otherwise).  Now, many people don’t understand how to do so, but we explained in that paper. For most TCP applications, doing this is very easy requiring only a slight amount of care; HTTP is quite ugly, and yo could suffer from “head of line” blocking in HTTP by having large embedded objects queued over one or two TCP connections. You have to use range requests, and similar hacks so that one big image doesn’t block everything else you might want to do with that server.
2. At the time of those RFC’s, there were a lot of dial up routers out there with very little packet storage; if you ran a lot of TCP connections in parallel (and did GETs over them at the same time, like for a bunch of embedded images), it could very easily self-congest your dial up connection and get high packet loss/retransmission.  You could easily get enough packets in flight arriving on your connection that those routers could not hold the burst while dribbling them out over the dialup.

So over the last few years, I’ve noticed that various browsers have begun ignoring the HTTP spec, and didn’t think about it all that hard, as the reasons for the 2 connection limit have passed, though wondered why, given they’d already have done most of the more painful HTTP work in the past.

Here’s part of the answer I think: as broadband connections have increased,  XP’s very old TCP stack has become a serious limitation.  Over a 100ms delay path, you can’t get more than approximately 6 megabits/second out of XP, as it does not enable TCP window scaling by default (Vista, Win7, Linux and Mac all do).  To get TCP window scaling, you have to hack the XP registry, which is not for the faint of heart. So if you have a decent broadband connection (running at 20-50Mbits/second), still run Windows XP, and obey the HTTP spec, you’d lose, all because Windows XP long beyond its expiration date (but still has something like 60% share and mercifully dropping at last).

I think current Chrome is using 6 TCP connections, and Firefox seemed to be set to 15 when I went looking a week or so ago.

Unfortunately, I think this may be another puzzle piece in my puzzle that could be causing some serious headaches, so I’m going to take some data this week to find out.  Getting real data is so liberating; you start having to deal with the way things actually are rather than endure hand waving and obfuscation.  How important a puzzle piece even if I find what I expect to see in the traces won’t become clear until I also see some current HTTP traffic stats and take some measurements against today’s popular web sites: the web of 1997 is quite different from today. While it will be interesting to revisit the hack microscape web site we used for testing then, that won’t actually tell me all that much about how serious the problem may be on today’s Internet.

I’ll report back here once I have a bit of actual data…

I do have one question for those of you who have might IE 9 beta: how many connections is Microsoft using in in IE9?  I don’t have time right now to try to mess with Win7 and install IE9 myself….