相关疑难解决方法(0)

在写了关于TCP_NODELAY和TCP_CORK 的答案之后,我意识到我对TCP_CORK的细节点的了解一定是缺乏的,因为我不清楚为什么Linux开发人员认为有必要引入新的TCP_CORK标志,而不仅仅是依赖于应用程序在适当的时间设置或清除现有的TCP_NODELAY标志.

特别是,如果我有一个Linux应用程序想要通过TCP流发送()一些小的/非连续的数据片段而不支付200mS Nagle延迟税,同时最小化发送所需的数据包数量它,我可以这两种方式中的任何一种:

使用TCP_CORK(伪代码):

int optval = 1;
setsockopt(sk, SOL_TCP, TCP_CORK, &optval, sizeof(int));   // put a cork in it
send(sk, ..);
send(sk, ..);
send(sk, ..);
optval = 0;
setsockopt(sk, SOL_TCP, TCP_CORK, &optval, sizeof(int));   // release the cork

或者使用TCP_NODELAY(伪代码):

int optval = 0;
setsockopt(sk, IPPROTO_TCP, TCP_NODELAY, &optval, sizeof(int));   // turn on Nagle's
send(sk, ..);
send(sk, ..);
send(sk, ..);
optval = 1;
setsockopt(sk, IPPROTO_TCP, TCP_NODELAY, &optval, sizeof(int));   // turn Nagle's back off

多年来我一直在使用后一种技术并取得了良好的效果,并且它具有可移植到非Linux操作系统的优点(尽管在Linux之后你必须在关闭Nagle之后再次调用send(),以便确保数据包立即发送并避免Nagle-delay - send()'零字节就足够了).

现在Linux开发人员都很聪明,所以我怀疑上面的TCP_NODELAY用法从未发生过.必须有一些理由让他们认为这是不够的,这导致他们引入了一个新的/专有的TCP_CORK标志.任何人都能解释一下这个原因是什么吗？