何时应使用 TCP_NODELAY，何时应使用 TCP_CORK？

问题描述：

我知道它们都禁用了 Nagle 算法。

我什么时候应该/不应该使用它们？

解决方案 1：

首先，它们并非都禁用 Nagle 算法。

Nagle 算法用于减少线路中小网络数据包的数量。该算法是：如果数据小于限制（通常是 MSS），则等待直到收到先前发送的数据包的 ACK，同时累积来自用户的数据。然后发送累积的数据。

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)

这将有助于 telnet 等应用程序。但是，等待 ACK 可能会增加发送流数据时的延迟。此外，如果接收方实施“延迟 ACK 策略”，则会导致暂时的死锁情况。在这种情况下，禁用 Nagle 算法是更好的选择。

因此 TCP_NODELAY 用于禁用 Nagle 算法。

TCP_CORK 积极地积累数据。如果在套接字中启用了 TCP_CORK，它将不会发送数据，直到缓冲区填满到固定限制。与 Nagle 算法类似，它也会积累来自用户的数据，但直到缓冲区填满到固定限制，而不是直到收到 ACK。这在发送多个数据块时很有用。但使用 TCP_CORK 时必须更加小心。

直到 2.6 内核，这两个选项都是互斥的。但在更高版本的内核中，它们可以共存。在这种情况下，TCP_CORK 将具有更高的优先级。

参考：

• http://baus.net/on-tcp_cork/

• http://ccr.sigcomm.org/archive/2001/jan01/ccr-200101-mogul.pdf

解决方案 2：

TCP_NODELAY

用于禁用 Nagle 算法来改善 TCP/IP 网络，并通过等待直到收到先前发送的数据的确认来发送累积的数据包来减少数据包的数量。

//摘自 tcp(7) 手册：

TCP_CORK（或TCP_NOPUSH在 FreeBSD 中）

如果设置，则不发送部分帧。当再次清除该选项时，将发送所有排队的部分帧。这对于在调用之前添加标题sendfile(2)或进行吞吐量优化很有用。按照目前的实现，输出被塞住的时间上限为 200 毫秒TCP_CORK。如果达到此上限，则排队数据将自动传输。此选项只能与TCP_NODELAYLinux 2.5.71 结合使用。不应在旨在可移植的代码中使用此选项。

解决方案 3：

这是一种优化，就像任何优化一样：

1. 不要使用它

2. 等到性能成为问题时，确定套接字延迟肯定是造成问题的原因，并且测试证明这肯定可以解决问题，而且这是解决问题的最简单方法，那就这样做吧。

基本上，目的是避免使用 sendfile() 及其朋友发送可使用单帧的多个帧。

例如，在 Web 服务器中，您先发送标头，然后发送文件内容，标头将在内存中组装，然后内核将直接发送文件。TCP_CORK 允许您在单个帧中发送标头和文件开头，即使使用 TCP_NODELAY，否则会导致立即发送第一个块。

解决方案 4：

TCP_CORK 与 TCP_NODELAY 相反。前者强制数据包累积延迟，后者禁用该延迟。