tcp的Nagle算法

http://blog.chinaunix.net/uid-28387257-id-3766565.html

http://blog.csdn.net/ithzhang/article/details/8520026

一、背景

    先谈一下TCP nagle算法在实际网络中的表现。
        当有一个TCP数据段不足MSS，比如要发送700Byte数据，MSS为1460Byte的情况。nagle算法会延迟这个数据段的发送，等待，直到有足够的数据填充成一个完整数据段。也许有人会问，这有什么影响呢？没有太大的影响，总体上来说，这种措施能节省不必要的资源消耗。但是要发送的总体数据很小时，这种措施就是拖后腿了。比如，用户请求一个网页，大约十几KB的数据，TCP先发送了八九个数据包，剩下几百字节一直不发送，要等到另一个RTT才发送，这时候前面发送数据的ACK已经返回了。这样的用户体验是很不好的。 所以，现在很多服务器都选择主动关闭nagle算法，因为带宽够大，资源消耗不是问题，速度反而是个大问题。

二、Nagle算法的起源和机制

        nagle算法由John Nagle发明，最初是为了解决福特航空通信的拥塞控制。

        这要从糊涂窗口综合症说起，糊涂窗口综合症指的是报文段有效负载过小。产生的原因有两类：1.发送方产生数据过慢；2.接收方吸收数据过慢。详细解释一下：1.如果发送方是远程登录，每次传输的数据可能只有几个字节。占报文段比重很小。2.接收方没有足够的缓存和处理速度，总是通告过小的窗口，导致数据包有效负荷减少。相应的解决方案也有两种：1.发送端使用Nagle算法；2.接收端使用clark算法或者delay ack。发送方Nagle算法的实质是拼接小数据包，如果当前数据不够一个MSS，则等待，直到有足够的数据能拼到一起或者新的ACK到来。接收方Clark算法是一有数据包就发送ACK，但通告窗口为0，直到有足够的接收缓存，再通告较大的窗口，delay ack是指不立即回复ACK，直到有多个数据包到来，或者有足够的缓冲区。

        linux-2.6.32.12/net/ipv4/tcp_output.c
        tcp_write_xmit函数，发送数据主循环

1. if (tso_segs == 1) {
   
2.             if (unlikely(!tcp_nagle_test(tp, skb, mss_now,
   
3.                          (tcp_skb_is_last(sk, skb) ?
   
4.                          nonagle : TCP_NAGLE_PUSH))))
   
5.                 break;
   
6.         } else {
   
7.             if (!push_one && tcp_tso_should_defer(sk, skb))
   
8.                 break;
   
9.         }

       这一段代码的意思是，如果要发送的数据不够大，不能够分段时，调用tcp_nagle_test进行发送检查。

1. static inline int tcp_nagle_test(struct tcp_sock *tp, struct sk_buff *skb,
   
2.                  unsigned int cur_mss, int nonagle)
   
3. {
   
4.     /* Nagle rule does not apply to frames, which sit in the middle of the
   
5.      * write_queue (they have no chances to get new data).
   
6.      *
   
7.      * This is implemented in the callers, where they modify the 'nonagle'
   
8.      * argument based upon the location of SKB in the send queue.
   
9.      */
   
10.     if (nonagle & TCP_NAGLE_PUSH)
    
11.         return 1;
    
12. 
    
13.     /* Don't use the nagle rule for urgent data (or for the final FIN).
    
14.      * Nagle can be ignored during F-RTO too (see RFC4138).
    
15.      */
    
16.     if (tcp_urg_mode(tp) || (tp->frto_counter == 2) ||
    
17.      (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN))
    
18.         return 1;
    
19. 
    
20.     if (!tcp_nagle_check(tp, skb, cur_mss, nonagle))
    
21.         return 1;
    
22. 
    
23.     return 0;
    
24. }

        如果nonagle已经启用，则返回1，表示不使用nagle算法，立即发送数据。对于有紧急标志位的报文段或者最后的FIN，以及虚假RTO的情况，也不启用nagle算法，立即发送数据。
        最后的tcp_nagle_check:
        

1. /* Return 0, if packet can be sent now without violation Nagle's rules:
   
2.  * 1. It is full sized.
   
3.  * 2. Or it contains FIN. (already checked by caller)
   
4.  * 3. Or TCP_NODELAY was set.
   
5.  * 4. Or TCP_CORK is not set, and all sent packets are ACKed.
   
6.  * With Minshall's modification: all sent small packets are ACKed.
   
7.  */
   
8. static inline int tcp_nagle_check(const struct tcp_sock *tp,
   
9.                  const struct sk_buff *skb,
   
10.                  unsigned mss_now, int nonagle)
    
11. {
    
12.     return (skb->len < mss_now &&
    
13.         ((nonagle & TCP_NAGLE_CORK) ||
    
14.          (!nonagle && tp->packets_out && tcp_minshall_check(tp))));
    
15. }

        该函数返回0表示不启用nagle算法。如果当前报文段数据小于MSS，或者包含FIN，或者已经设置TCP_NODELAY系统参数，或者没有设置TCP_CORK选项，而所有已发出的包都已经被确认了。TCP_CORK是从另一种角度对NAGLE算法的优化。TCP_NODELAY本质在于立即发送，而TCP_CORK比NAGLE算法等待发送的时间更长，只有当数据包大于一个MSS或者取消了TCP_CORK选项时，才能发送[5]。

1. /* Flags in tp->nonagle */
   
2. #define TCP_NAGLE_OFF        1    /* Nagle's algo is disabled */
   
3. #define TCP_NAGLE_CORK        2    /* Socket is corked     */
   
4. #define TCP_NAGLE_PUSH        4    /* Cork is overridden for already queued data */

        NAGLE算法和DELAY ACK机制的分析至此告一段落。下面将针对各个不同版本的TCP协议进行分析讲解。

引用：
[1]  http://www.cnblogs.com/zhaoyl/archive/2012/09/20/2695799.html 糊涂窗口综合症和nagle算法
[2]  http://283631583.blog.163.com/blog/static/787455022008102505836334/ 糊涂窗口综合症和nagle算法
[3]  http://tools.ietf.org/html/rfc896 Nagle算法RFC标准896
[4]  http://www.slyar.com/blog/c-operator-priority.html C算符优先级
[5]  http://lenky.info/2013/02/24/socket%E9%80%89%E9%A1%B9%E7%B3%BB%E5%88%97%E4%B9%8Btcp_cork/ TCP_CORK

TCP/IP协议中，无论发送多少数据，总是要在数据前面加上协议头，同时，对方接收到数据，也需要发送ACK表示确认。为了尽可能的利用网络带宽，TCP总是希望尽可能的发送足够大的数据。（一个连接会设置MSS参数，因此，TCP/IP希望每次都能够以MSS尺寸的数据块来发送数据）。Nagle算法就是为了尽可能发送大块数据，避免网络中充斥着许多小数据块。

      Nagle算法的基本定义是任意时刻，最多只能有一个未被确认的小段。 所谓“小段”，指的是小于MSS尺寸的数据块，所谓“未被确认”，是指一个数据块发送出去后，没有收到对方发送的ACK确认该数据已收到。

        Nagle算法的规则（：

      （1）如果包长度达到MSS，则允许发送；

      （2）如果该包含有FIN，则允许发送；

      （3）设置了TCP_NODELAY选项，则允许发送；

      （4）未设置TCP_CORK选项时，若所有发出去的小数据包（包长度小于MSS）均被确认，则允许发送；

      （5）上述条件都未满足，但发生了超时（一般为200ms），则立即发送。

     Nagle算法只允许一个未被ACK的包存在于网络，它并不管包的大小，因此它事实上就是一个扩展的停-等协议，只不过它是基于包停-等的，而不是基于字节停-等的。Nagle算法完全由TCP协议的ACK机制决定，这会带来一些问题，比如如果对端ACK回复很快的话，Nagle事实上不会拼接太多的数据包，虽然避免了网络拥塞，网络总体的利用率依然很低。

      Nagle算法是silly window syndrome(SWS)预防算法的一个半集。SWS算法预防发送少量的数据，Nagle算法是其在发送方的实现，而接收方要做的时不要通告缓冲空间的很小增长，不通知小窗口，除非缓冲区空间有显著的增长。这里显著的增长定义为完全大小的段（MSS）或增长到大于最大窗口的一半。

 注意：BSD的实现是允许在空闲链接上发送大的写操作剩下的最后的小段，也就是说，当超过1个MSS数据发送时，内核先依次发送完n个MSS的数据包，然后再发送尾部的小数据包，其间不再延时等待。（假设网络不阻塞且接收窗口足够大）。

     举个例子，一开始client端调用socket的write操作将一个int型数据（称为A块）写入到网络中，由于此时连接是空闲的（也就是说还没有未被确认的小段），因此这个int型数据会被马上发送到server端，接着，client端又调用write操作写入‘\r\n’（简称B块），这个时候，A块的ACK没有返回，所以可以认为已经存在了一个未被确认的小段，所以B块没有立即被发送，一直等待A块的ACK收到（大概40ms之后），B块才被发送。整个过程如图所示：

      这里还隐藏了一个问题，就是A块数据的ACK为什么40ms之后才收到？这是因为TCP/IP中不仅仅有nagle算法，还有一个TCP确认延迟机制 。当Server端收到数据之后，它并不会马上向client端发送ACK，而是会将ACK的发送延迟一段时间（假设为t），它希望在t时间内server端会向client端发送应答数据，这样ACK就能够和应答数据一起发送，就像是应答数据捎带着ACK过去。在我之前的时间中，t大概就是40ms。这就解释了为什么'\r\n'（B块）总是在A块之后40ms才发出。

       当然，TCP确认延迟40ms并不是一直不变的，TCP连接的延迟确认时间一般初始化为最小值40ms，随后根据连接的重传超时时间（RTO）、上次收到数据包与本次接收数据包的时间间隔等参数进行不断调整。另外可以通过设置TCP_QUICKACK选项来取消确认延迟。

      关于TCP确认延迟的详细介绍可参考：http://blog.csdn.net/turkeyzhou/article/details/6764389

2. TCP_NODELAY 选项

      默认情况下，发送数据采用Negale 算法。这样虽然提高了网络吞吐量，但是实时性却降低了，在一些交互性很强的应用程序来说是不允许的，使用TCP_NODELAY选项可以禁止Negale 算法。

      此时，应用程序向内核递交的每个数据包都会立即发送出去。需要注意的是，虽然禁止了Negale 算法，但网络的传输仍然受到TCP确认延迟机制的影响。

3. TCP_CORK 选项

     所谓的CORK就是塞子的意思，形象地理解就是用CORK将连接塞住，使得数据先不发出去，等到拔去塞子后再发出去。设置该选项后，内核会尽力把小数据包拼接成一个大的数据包（一个MTU）再发送出去，当然若一定时间后（一般为200ms，该值尚待确认），内核仍然没有组合成一个MTU时也必须发送现有的数据（不可能让数据一直等待吧）。

      然而，TCP_CORK的实现可能并不像你想象的那么完美，CORK并不会将连接完全塞住。内核其实并不知道应用层到底什么时候会发送第二批数据用于和第一批数据拼接以达到MTU的大小，因此内核会给出一个时间限制，在该时间内没有拼接成一个大包（努力接近MTU）的话，内核就会无条件发送。也就是说若应用层程序发送小包数据的间隔不够短时，TCP_CORK就没有一点作用，反而失去了数据的实时性（每个小包数据都会延时一定时间再发送）。

4. Nagle算法与CORK算法区别

     Nagle算法和CORK算法非常类似，但是它们的着眼点不一样，Nagle算法主要避免网络因为太多的小包（协议头的比例非常之大）而拥塞，而CORK算法则是为了提高网络的利用率，使得总体上协议头占用的比例尽可能的小。如此看来这二者在避免发送小包上是一致的，在用户控制的层面上，Nagle算法完全不受用户socket的控制，你只能简单的设置TCP_NODELAY而禁用它，CORK算法同样也是通过设置或者清除TCP_CORK使能或者禁用之，然而Nagle算法关心的是网络拥塞问题，只要所有的ACK回来则发包，而CORK算法却可以关心内容，在前后数据包发送间隔很短的前提下（很重要，否则内核会帮你将分散的包发出），即使你是分散发送多个小数据包，你也可以通过使能CORK算法将这些内容拼接在一个包内，如果此时用Nagle算法的话，则可能做不到这一点。

    实际上Nagle算法并不是很复杂，他的主要职责是数据的累积，实际上有两个门槛：一个就是缓 冲区中的字节数达到了一定量，另一个就是等待了一定的时间（一般的Nagle算法都是等待200ms）；这两个门槛的任何一个达到都必须发送数据了。一般 情况下，如果数据流量很大，第二个条件是永远不会起作用的，但当发送小的数据包时，第二个门槛就发挥作用了，防止数据被无限的缓存在缓冲区不是好事情哦。 了解了TCP的Nagle算法的原理之后我们可以自己动手来实现一个类似的算法了，在动手之前我们还要记住一个重要的事情，也是我们动手实现Nagle算 法的主要动机就是我想要紧急发送数据的时候就要发送了，所以对于上面的两个门槛之外还的增加一个门槛就是紧急数据发送。

    对于我现在每秒钟10次数据发送，每次数据发送量固定在85~100字节的应用而言，如果采用默认的开启Nagle算法，我在发送端，固定每帧数据85个，间隔100ms发送一次，我在接受端（阻塞方式使用）接受的数据是43 138交替出现，可能就是这个算法的时间阈值问题，如果关闭Nagle算法，在接收端就可以保证数据每次接收到的都是85帧。

    Nagle算法适用于小包、高延迟的场合，而对于要求交互速度的b/s或c/s就不合适了。socket在创建的时候，默认都是使用Nagle算法的，这会导致交互速度严重下降，所以需要setsockopt函数来设置TCP_NODELAY为1.不过取消了Nagle算法，就会导致TCP碎片增多，效率可能会降低。

关闭nagle算法,以免影响性能，因为控制时控制端要发送很多数据量很小的数据包,需要马上发送。

 const char chOpt = 1;

int nErr = setsockopt(pContext->m_Socket, IPPROTO_TCP, TCP_NODELAY, &chOpt, sizeof(char));

if (nErr == -1)

{

    TRACE(_T("setsockopt() error\n"),WSAGetLastError());

    return;

}