When should you use TCP_NODELAY and TCP_CORK?

I realized that both of them disabled the Nagle algorithm.

When / Should Not Each Be Used?

+56
linux sockets tcp
Sep 21 2018-10-21
source share
4 answers

First of all, both of them do not cancel the Nagle algorithm.

The Nagle algorithm is designed to reduce the number of small network packets in the wire. Algorithm: if the data is less than the limit (usually MSS), wait for the ACK to be received for previously sent packets and, on average, accumulate data from the user. Then send the accumulated data.

if [ data > MSS ] send(data) else wait until ACK for previously sent data and accumulate data in send buffer (data) And after receiving the ACK send(data) 

This will help in applications like telnet. However, waiting for an ACK may increase the delay in sending streaming data. In addition, if the recipient implements a “delayed ACK policy”, this will lead to a temporary deadlock situation. In such cases, it is best to disable the Nagle algorithm.

Therefore, TCP_NODELAY is used to disable the Nagle algorithm.

TCP_CORK aggressively accumulates data. If TCP_CORK is enabled on the socket, it will not send data until the buffer fills a fixed limit. Like the Nagle algorithm, it also accumulates data from the user, but until the buffer fills a fixed limit until an ACK is received. This will be useful when sending multiple data blocks. But you have to be more careful when using TCP_CORK.

Prior to kernel 2.6, both of these options are mutually exclusive. But in a later core, both can exist together. In this case, preference will be given to TCP_CORK.

Ref:

+67
Nov 15 '13 at 7:19
source share

TCP_NODELAY

Used to disable the Nagle algorithm to improve TCP / IP networks and reduce the number of packets, waiting for confirmation of previously sent data to send accumulated packets.

// From the tcp (7) manual:

TCP_CORK (or TCP_NOPUSH on FreeBSD)

If set, do not send partial frames. All queued partial frames are sent when the option is cleared again. This is useful for adding headers before calling sendfile(2) or for optimizing throughput. As currently implemented, there is a ** 200 millisecond ceiling ** of time during which the TCP_CORK . If this ceiling is reached, the data in the queue is transferred automatically . This option can only be combined with TCP_NODELAY since Linux 2.5.71. This option should not be used in code intended for portability.

+20
Jul 24 '14 at 14:02
source share

This is an optimization, so any optimization:

  • Do not use it
  • Wait until performance becomes a problem and then determines that socket latency is definitely the cause of this, and testing proves that it will definitely fix it, and this is the easiest way to fix it. Do it.

Basically the goal is to not send multiple frames where one frame can be used, with sendfile () and his friends.

So, for example, on a web server you send headers followed by the contents of the file, headers will be collected in memory, then the file will be sent directly by the kernel. TCP_CORK allows you to have headers and the beginning of a file sent in one frame, even with TCP_NODELAY, which would otherwise send the first piece immediately.

+6
Sep 21 2018-10-21
source share

TCP_CORK is the opposite of TCP_NODELAY. Former packet accumulation delay; the latter disables it.

0
Nov 25 '12 at 18:27
source share



All Articles