【转】我怎么控制TCP的延迟确认和延迟发送？

How do I control TCP delayed ACK and delayed sending?

环境

• Red Hat Enterprise Linux MRG
• Network communication over TCP socket

问题

• We see 40ms delays in Linux responding to ACKs. Why is this? How do I control it?
• We see small data sends (eg: one byte) delayed over network communication. Why is this? How do I control it?
• Can I set net.ipv4.tcp_delack_min kernel tubable on RHEL?

决议

Delayed acknowledgements

The 40ms delay in responding to ACK is an method built into the Linux IP stack to improve network performance.

When a participant in a TCP conversation has an ACK to send, the participant is acknowledging some data that has been received, it is expected that the (receiving)participant will have a reply to the data it received.
However the linux kernel will delay the outgoing ACK by up to 40ms to allow the reply to queue, then send both the reply and the ACK together. This is desirable to sending an ACK and then a reply separately, which will cause overhead on the network.

This is controlled at an application level with the TCP_QUICKACK socket option. See man tcp for further details.

This option needs to be set with setsockopt() after each operation of TCP on a given socket.

Delayed small data transmission

The delay in sending small data is an method built into the Linux IP stack to improve efficiency of TCP/IP.
More information about this, is contained in the linked reference to Nagle's Algorithm.

Under normal operation, data is buffered until there is a sufficient amount to send out, thereby avoiding the frequent sending of small packets, which results in poor utilization of the network.

This is controlled at an application level with the TCP_NODELAY socket option. See man tcp for further details.

Kernel tunable net.ipv4.tcp_delack_min

This tunable is not present within RHEL kernels.

This tunable is present in Red Hat MRG kernels, designated with the kernel-rt prefix, or el5rt/el6rt suffix.