> Regarding nagling, HTTP1.0 is so aggressively sub-optimal that it is always > tempting to turn it off, yet TCP_NODELAY on long haul links is both > anti-social and often counter-productive. Maybe clients should decide > dynamically whether to delay or not depending on whether or not the endpoint > is local subnet or not -or even on the experience of the latest call. The > indiana paper used HTTP1.1
I ran some tests and looked at some traces, and I never saw the typical Nagle delay. This has nothing to do with HTTP 1.1, however; the behavior is the same for HTTP 1.0. The key is the buffer size specified for the BufferedOutputStream. With an 8k buffer, multiple writes to the underlying stream occur only when headers+payload > 8192. When this happens, either the headers are > 1460 (Ethernet MSS), in which case there would be no delayed ACK on the first write, since a full segment would be sent, or the payload is > 1460, in which case more than a segment of output is queued behind the headers, which causes the TCP/IP stacks I tested to abandon the Nagle wait and send the next (full) segment before an ACK is received for the first segment. Scott Nichol
