《TCP 缓冲区&&滑动窗口》

TCP滑动窗口和socket缓冲区之间的关系
一、TCP的滑动窗口大小实际上就是socket的接收缓冲区大小的字节数
二、对于server端的socket一定要在listen之前设置缓冲区大小，因为，accept时新产生的socket会继承监听socket的缓冲区大小。对于client端的socket一定要在connet之前设置缓冲区大小，因为connet时需要进行三次握手过程，会通知对方自己的窗口大小。在connet之后再设置缓冲区，已经没有什么意义。

三、由于缓冲区大小在TCP头部只有16位来表示，所以它的最大值是65536，但是对于一些情况来说需要使用更大的滑动窗口，这时候就要使用扩展的滑动窗口，如光纤高速通信网络，或者是卫星长连接网络，需要窗口尽可能的大。这时会使用扩展的32位的滑动窗口大小。

四、滑动窗口移动规则：

1、窗口合拢：在收到对端数据后，自己确认了数据的正确性，这些数据会被存储到缓冲区，等待应用程序获取。但这时候因为已经确认了数据的正确性，需要向对方发送确认响应ACK，又因为这些数据还没有被应用进程取走，这时候便需要进行窗口合拢，缓冲区的窗口左边缘向右滑动。注意响应的ACK序号是对方发送数据包的序号，一个对方发送的序号，可能因为窗口张开会被响应（ACK）多次。

2、窗口张开：窗口收缩后，应用进程一旦从缓冲区中取出数据，TCP的滑动窗口需要进行扩张，这时候窗口的右边缘向右扩张，实际上窗口这是一个环形缓冲区，窗口的右边缘扩张会使用原来被应用进程取走内容的缓冲区。在窗口进行扩张后，需要使用ACK通知对端，这时候ACK的序号依然是上次确认收到包的序号。

3、窗口收缩，窗口的右边缘向左滑动，称为窗口收缩，Host Requirement RFC强烈建议不要这样做，但TCP必须能够在某一端产生这种情况时进行处理。

【一个例子明白发送缓冲区、接受缓冲区、滑动窗口协议之间的关系】

在上面的几篇文章中简单介绍了上述几个概念在TCP网络编程中的关系，也对应了几个基本socket系统调用的几个行为，这里再列举一个例子，由于对于每一个TCP的SOCKET来说，都有一个发送缓冲区和接受缓冲区与之对应，所以这里只做单方向交流，不做互动，在recv端不send,在send端不recv。细细揣摩其中的含义。

一、recv端

在监听套接字上准备accept，在accept结束以后不做什么操作，直接sleep很久，也就是在recv端并不做接受数据的操作，在sleep结束之后再recv数据。

二、send端

通过查看本系统内核默认的支持的最大发送缓冲区大小，cat/proc/sys/net/ipv4/tcp_wmem，最后一个参数为发送缓冲区的最大大小。接受缓冲区最大的配置文件在tcp_rmen中。

将套接字设置为阻塞，一次发送的buffer大于最大发送缓冲区所能容纳的数据量，一次send结束，在发送返回后接着答应发送的数据长度

测试结果：

阶段一：

    接受端表现：在刚开始发送数据时，接收端处于慢启动状态，滑动窗口大小越来愈大，但是由于接收端不处理接受缓冲区内的数据，其滑动窗口越来越小（因为接受端回应发送端中的win大小表示接受端还能够接受多少数据，发送端下次发送的数据大小不能超过回应中win的大小），最后发送端回应给接受端的ACK中显示的win大小为0，表示接收端不能够再接受数据。

发送端表现：发送端一直不能返回，如果接受端一直回应win为0的情况下，发送端的send就会一直不能返回，这种僵局一直持续到接收端的sleep结束。

原因分析：首先需要明白几个事实，阻塞式I/O会一直等待，直达这个操作完成；发送端接受到接收端的回应后才能将发送缓冲区中的数据进行清空。

在接收端不recv，那么接收端的接受缓冲区内会一直有数据，接受缓冲区满，导致滑动窗口为0，导致发送端不能发送数据。但是send操作为何不能反悔呢？send操作只是将应用缓冲区的数据拷贝到发送缓冲区，但是发送缓冲区的数据并没有完全得到接收端的ACK回应，所以暂时不能将发送缓冲区中的数据丢弃，导致发送缓冲区的被填满，这样应用层中的数据也就不能拷贝到内核发送缓冲区内，也就会一直阻塞在这里，直到可以继续讲应用层的数据拷贝到发送缓冲区中，何时触发这个操作呢？等到发送端回应win大于0时才有这样的操作。

阶段二;

    接受端：在sleep结束以后，开始调用recv系统调用。这个时候接受端的滑动窗口又开始大于零。那么这样就唤醒了发送端继续发送数据。

    发送端：发送端接受到接收端win大于0的回应，这个时候发送端又可以将应用层buffer中的数据拷贝到内核的发送缓冲区中。

原因分析：由于接受端调用recv将内核接受缓冲区的数据拷贝到应用层中，这样滑动窗口又大于0了所以激发了发送端继续发送数据，由于发送端可以发送数据了，内核协议栈便将发送缓冲区中的数据发送给接受端，这样发送缓冲区又有空间了，那么send操作就可以将应用层的数据拷贝到发送缓冲区了！这样的操作一直保持到send操作返回，这样代表着将应用层的数据全部拷贝到发送缓冲区内，但不代表将数据发送给对端。发送给对端成功的标志是接受到对端的ACK回应，这个时候发送端才可以将发送缓冲区的数据丢弃。不丢弃的原因是时刻准备重发丢失/出错的数据！

Ps: TCP通信为了保证可靠性，每次发送的数据都需要得到对方的ACK才确认对方收到了(仅保证对方TCP接收缓冲收到 数据了，但不保证对方应用程序取到数据了)，这时如果每次发送一次就要停下来等着对方的ACK消息，显然是一种极大的资源浪费和低下的效率，这时就有了滑动窗口的出现。
发送方的滑动窗口维持着当前发送的帧序号，已发出去帧的计时器，接收方当前的窗口大小(由接收方ACK通知，大体等于接收缓冲大小-未处理的消息包)，接收方滑动窗口保存的有已接收的帧信息、期待的下一帧的帧号等，至于滑动窗口的具体工作原理这里就不说了。