Several posts back I explained the curious phenomenon of the majority of TCP connections on busy Web servers being in the TIME_WAIT state, due to the peculiar way TCP has of closing connections (namely, via a full duplex handshake). Alert readers will have noticed that the explanation was incomplete. It never said anything about why it is that Web servers, in particular, that experience this problem (and not, say, database servers, file servers, or what have you).
Really alert readers will also have figured out the answer by now: Web servers, not Web clients, tend to initiate the connection close. The example I used to describe the full duplex handshake assumed this. But if you actually go look this stuff up in the TCP spec or a good reference, you will that the server and client roles are reversed. TCP tends to assume that it will be the client initiating the close, not the server.
And when that is the case, the TIME_WAITs don't accumulate the way they do on a busy Web server. Since the client has the active close, it's the client that winds up in the TIME_WAIT. The burden of keeping old and new data from intermixing is dispersed among cilents, instead of being concentrated on servers.
All of which in turn points to the odd fact that HTTP actually uses TCP in ways that are not entirely consonant with the what the creators of the latter envisioned. TCP has been well-described as a connection-oriented protocol layered over a connectionless one (IP). With HTTP, we get a stateless protocol layered over one that inherently maintains states (such as TIME_WAIT), even while tearing down a connection.
When you think about it like that, it's quite astonishing that all this works as well as it does!