perhaps this is one of the not-so-obvious benefits of running a web proxy cache such as squid. the greater internet can have larger packets floating around, and the local proxy of the ISP can deal with horrible tcp stacks, retransmissions and client machine with small receive buffer sizes.

what we did in our transparent web cache was to always try to use persistence when talking to origin servers, fix everything we could fix in our TCP stack, and use a quota so that we would only talk to the same origin server N times in parallel. this means when clients disconnect from what they think of as the origin server after 15 seconds of inactivity, and then (happens a lot!) reconnect and grab something else, their requests are interleaved on one of our persistent connections to the origin server. this also means that if too many clients try (doesn't happen often) to use our quota of connections to an origin server, some of them have to wait for a slot on one of our persistent connections. we will ultimately time out or LRU our origin connections but while we have them open, TCP's window size and RTT estimates are more accurate than when a bazillion new connections keep coming up and doing slow start and the fratricide thing someone else mentioned earlier today. this hurts our benchmark numbers but helps the backbones (where i came from) and the origin servers (where some of my friends are). quite the dilemma.