特别是,如果我有一个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,..); optval = 0; setsockopt(sk,sizeof(int)); // release the cork
或使用TCP_NODELAY(伪代码)：
int optval = 0; setsockopt(sk,IPPROTO_TCP,TCP_NODELAY,sizeof(int)); // turn on Nagle's send(sk,..); optval = 1; setsockopt(sk,sizeof(int)); // turn Nagle's back off
我已经使用后一种技术多年,效果很好,并且具有便携式到非Linux操作系统的好处(尽管在Linux之外,您必须在Nagle退后关闭之后再次调用send()以确保数据包立即发送,并避免Nagle-delay – send()’零字节就足够了).
现在Linux开发者是聪明的,所以我怀疑TCP_NODELAY的上述用法从未发生过.必须有一些原因,他们觉得不够,这导致他们引入一个新的/专有的TCP_CORK标志.有人可以解释这个原因吗
解决方法
>这个用例在TCP_CORK和TCP_NODELAY之间有什么区别吗？
>必须有一些原因,这导致他们引入一个新的/专有的TCP_CORK标志.有人可以解释这个原因吗
首先看看这个Stack Overflow Question中的答案,因为在这个问题中是相关的,因为这个问题一般都是描述两者之间的区别,而不参考你的使用.
> TCP_NODELAY ON表示在您获得的时间内发送数据(部分帧),无论您是否有足够的帧用于完整的网络数据包.
> TCP_NODELAY OFF表示Nagles Algoritm,这意味着当数据大于MSS时发送数据,或者在发送较小的数据之前等待接收确认.
> TCP_CORK ON表示不要发送任何小于MSS的数据(部分帧),直到应用程序显示为止或直到200ms.
> TCP_CORK OFF表示现在发送所有数据(部分帧).
这意味着在第一个示例中给定的用例中,没有部分帧发送到最后,但在第二个示例中,将发送具有接收确认的部分帧.
在第一个例子中也是最后发送,Nagle的算法仍然适用于解除锁定后的部分帧,在第二个例子中,它不是.
短版本是TCP_NODELAY发送不会在发送之前累积逻辑数据包作为网络数据包,Nagle的算法根据算法,TCP_CORK根据应用设置它.
这样做的副作用是Nagle的算法将在空闲连接上发送部分帧,TCP_CORK不会.
另外TCP_CORK在2.2中被引入了Linux内核(具体是2.1.127参见here),但直到2.5.71与TCP_NODELAY是互斥的.例如,2.4内核可以使用一个或另一个内核,但在2.6中,您可以组合两者,并且TCP_CORK在应用时将优先.
关于你的第二个问题
引用Linus Torvalds
Now,TCP_CORK is basically me telling David Miller that I refuse to play
games to have good packet size distribution,and that I wanted a way for
the application to just tell the OS: I want big packets,please wait until
you get enough data from me that you can make big packets.Basically,TCP_CORK is a kind of “anti-nagle” flag. It’s the reverse of
“no-nagle”.
Linus的另一个报导是关于TCP_CORK的使用情况如下
Basically,TCP_CORK is useful whenever the server knows the patterns of
its bulk transfers. Which is just about 100% of the time with any kind of
file serving.
总之,除了TCP_MAXSEG和MSGMORE之外,当调用writev时,TCP_CORK是允许用户空间中的应用程序对数据包大小分布进行更细粒度控制的另一个工具.
参考并进一步阅读
> Earthquaky kernel interfaces
> Sendfile Kernel Mailing Discussion (where the quote comes from)
> TCP/IP options for high-performance data transmission
> Rethinking the TCP Nagle Algorithm
> TCP_CORK: More than you ever wanted to know
> The C10K problem
> TCP man page
> The Linux Programming Interface Page 1262
