reached the destination, experience a constant delay of up to 500 milliseconds, the "ACK delay". It is recommended to disable either, although traditionally it's easier to disable Nagle, since such a switch already exists for real-time applications. A solution recommended by Nagle is to avoid the algorithm sending premature packets by buffering up application writes and then flushing the buffer: The user-level solution is to avoid write–write–read sequences on sockets. Write–read–write–read is fine. Write–write–write is fine. But write–write–read is a killer. So, if you can, buffer up your little writes to TCP and send them all at once. Using the standard UNIX I/O package and flushing write before each read usually works. Nagle considers delayed ACKs a "bad idea", since the application layer does not usually respond within the time window. For typical use cases, he recommends disabling "delayed ACK" instead of his algorithm, as "quick" ACKs do not incur as much overhead as many small packets do. Disabling either Nagle or delayed ACK TCP implementations usually provide applications with an interface to disable the Nagle algorithm. This is typically called the TCP_NODELAY option. On Microsoft Windows the TcpNoDelay registry switch decides the default. TCP_NODELAY is present since the TCP/IP stack in 4.2BSD of 1983, a stack with many descendents. The interface for disabling delayed ACK is not consistent among systems. The flag is available on Linux since 2001 (2.4.4) and potentially on Windows, where the official interface is . Setting TcpAckFrequency to 1 in the Windows registry turns off delayed ACK by default. Negative effect on larger writes The Nagle algorithm applies to data writes of any size. If the data in a single write spans 2n packets, where there are 2n-1 full-sized TCP segments followed by a partial TCP segment, the original Nagle algorithm would withhold the last packet, waiting for either more data to send (to fill the packet), or the ACK for the previous packet (indicating that all the previous packets have left the network). In any non-pipelined stop-and-wait request-response application protocol where request data can be larger than a packet, this can artificially impose a few hundred milliseconds latency between the requester and the responder. Originally this was not felt to be a problem, since any non-pipelined stop-and-wait protocol is probably not designed to achieve high performance in the first place, so a few hundred milliseconds extra delay should make little difference. A later refinement