TCP滑动窗口nagle算法相关

Nagle的文档里定义了处理他所谓的小包问题的方法，这种问题指的是应用程序一次产生一字节数据，这样会导致网络由于太多的包而过载（一个常见的情况是发送端的"糊涂窗口综合症(Silly Window Syndrome)"）。从键盘输入的一个字符，占用一个字节，可能在传输上造成41字节的包，其中包括1字节的有用信息和40字节的首部数据。这种情况转变成了4000%的消耗。Nagle的算法通常会在TCP程序里添加两行代码，在未确认数据发送的时候让发送器把数据送到缓存里。任何数据随后继续直到得到明显的数据确认或者直到攒到了一定数量的数据了再发包。

说明：1、缓存区这篇文章解释蛮好

①发送方
发送窗口只是发送缓存的一部分。已发送但未被确认数据大小<=发送窗口的大小。已被确认的数据会从发送缓存中删除。发送缓存和发送窗口后沿（这里的左边）是重合的，因为一被确认就会删除。删除后发送缓存和发送窗口的后沿同时向左移。发送应用程序必须控制写入缓存的速率，不能太快，否则发送缓存会没有存放数据的空间。
②接收方
如果接收应用程序来不及读取收到的数据，接收缓存最终会被填满，使接收窗口减少到0.反之，如果接收应用程序能够及时从接收缓存中读取收到的数据，接收窗口可以增大，但最大不能超过接收缓存的大小。接收缓存和接收窗口的前沿（图的右）是重合的。因为等应用程序读取数据后，可能向前沿移动。如果接收窗口<通告时指定大小，则同时向前移。如果接收窗口不能扩大了，则不移动，接收缓存有空闲区域。记住数据只能填充接收窗口，并不是正个接收缓存。

nagle算法：
TCP/IP协议中，无论发送多少数据，总是要在数据前面加上协议头，同时，对方接收到数据，也需要发送ACK表示确认。为了尽可能的利用网络带宽，TCP总是希望尽可能的发送足够大的数据。（一个连接会设置MSS参数，因此，TCP/IP希望每次都能够以MSS尺寸的数据块来发送数据）。Nagle算法就是为了尽可能发送大块数据，避免网络中充斥着许多小数据块。
Nagle算法的基本定义是任意时刻，最多只能有一个未被确认的小段。 所谓“小段”，指的是小于MSS尺寸的数据块，所谓“未被确认”，是指一个数据块发送出去后，没有收到对方发送的ACK确认该数据已收到。
Nagle算法的规则（可参考tcp_output.c文件里tcp_nagle_check函数注释）：
（1）如果包长度达到MSS，则允许发送；
（2）如果该包含有FIN，则允许发送；
（3）设置了TCP_NODELAY选项，则允许发送；
（4）未设置TCP_CORK选项时，若所有发出去的小数据包（包长度小于MSS）均被确认，则允许发送；
（5）上述条件都未满足，但发生了超时（一般为200ms），则立即发送。

[注]MSS尺寸：MSS是在MTU的基础上减去网络层的IP Header和传输层的TCP Header的部分，这就是TCP协议一次可以发送的实际应用数据的最大大小。 MSS = MTU (1500) -IP Header (20 or 40)-TCP Header (20) 由于IPV4和IPV6的长度不同，在IPV4中，以太网MSS可以达到1460byte;在IPV6中，以太网MSS可以达到1440byte。
关于MTU的值看这里MTU

Nagle算法的利弊分析
利：很明显，可以减少网络中的小分组，保持较高的网络资源利用率。

弊：由于发送方会控制小的分组，并期望合并成为较大的分组一起发送给接收方，因此实时的单向的发送数据并及时获取响应的场景需要谨慎。另外，如果接收方设置了DELAY ACK，情况可能会比较糟糕：因为如果接收方设置了DELAY ACK，接收方接收到发送方发过来的小分组后，并不及时发送ACK，只有等到Delay ACK的Timer到期后，才会给发送方回ACK。