一文带你搞定TCP流量控制

　　摘要理想的流量控制实际的流量控制窗口关闭糊涂窗口综合征理想的流量控制
　　什么是流量控制？
　　流量控制就是发送方不能无脑的给接收方发送数据，它需要根据接收方的处理能力来发送数据。
　　理想下的流量控制？
　　理想意味着在实际中不存在，这里只是简单的说一下流量控制的作用，我们假设的理想通信发生条件为：客户端是接收方、服务端是发送方接收窗口和发送窗口相同，为200接收方和发送方在通信过程中始终保持相同的窗口大小
　　客户端发送请求数据服务端收到请求后，发送确认报文和80字节的数据，可用窗口减少为120（20080），SND。NXT指针变为321，表示发送方下次发送序列号为321的数据客户端收到数据后，接收窗口右移80字节，RCV。NXT为321，表示客户端段期望下一个收到的报文的序列号为321，并且发送ACK报文给服务端服务端发送120字节的数据，可用窗口变为0，服务端无法发送数据客户端收到120字节的数据，接收窗口右移120字节，接着发送ACK报文给客户端服务端收到序列号为241（长度为80字节）的ACK报文，因此SND。UNA右移80字节变为321（24180），可用窗口变为80字节服务端收到序列号321（长度为120字节）的ACK报文，因此SND。UNA右移120字节变为441（321120），可用窗口变为200字节服务端发送160字节的数据，可用窗口变为40字节，并且SND。NXT右移160个字节变为601（441160）客户端在收到数据后，接收窗口右移160字节，接着发送ACK报文给服务端服务端在收到ACK报文后，SND。UNAK右移160字节，并且可用窗口再次恢复为200字节实际的流量控制
　　操作系统缓冲区和滑动窗口的关系
　　由于我们发送的数据都是暂存在操作系统的内存缓冲区，所以滑动窗口会收操作系统缓冲区的影响：操作系统内存缓冲区会动态调整，影响窗口大小如果应用程序如果无法及时从缓冲区读取内容，也会导致缓冲区减少，此时滑动窗口需要适当调小，避免缓冲区内容溢出。
　　应用程序无法及时读取缓存
　　假设以下场景：客户端为发送方，服务端为接收方，初始化发送窗口和接收窗口都为360服务端繁忙，收到客户端数据后，应用层无法及时读取数据
　　客户端发送140字节的数据，可用窗口变为220（360140），SND。NXT右移140变为141（1140）服务端收到140字节的数据，应用程序只读取了40节数据，还有100字节存在于缓冲区中，于是接收窗口变为260（360100），服务端在给客户端发送ACK报文时会把新的窗口大小告知客户端。客户端在收到ACK报文以后，发送窗口减少为260，并且由于收到了数据的ACK，因此SND。UNA会右移140个字节变为141，此时可用窗口为260客户端继续发送180字节的数据，SND。NXT变为321，可用窗口变为80（26080）服务端在收到数据后，应用进程没有读取任何数据，于是接收窗口从260缩小为80（260180），并且在发送ACK报文时告知客户端客户端收到ACK报文以后，会将发送窗口减少为80，可用窗口此时也是80，因此到这里客户端最多只能发送80字节的数据给服务端客户端发送最后80字节的数据给服务端，可用窗口变为0服务端收到80字节的数据后，应用进程依然没有读取任何数据，于是接收窗口减少为0，并在发送ACK报文告知客户端客户端收到ACK报文以后，发现窗口大小为0，因此将发送窗口减少为0。
　　这里会有个问题，窗口变为0也就是发生了窗口关闭。
　　操作系统缓冲区变化
　　当服务器资源紧张，操作系统有可能会减少缓冲区的大小，如果此时应用程序还无法读取数据，那么将会出现数据包丢失现象。
　　客户端发送140字节数据，可用窗口变为220（360140）服务端收到140字节数据后，但是系统资源紧张，操作系统减少120字节的缓冲区，并且应用层没有读取任何数据，于是接收窗口变为100（360120140），然后发送ACK报文告知客户端在收到服务端的ACK报文前，客户端又发送了180字节的数据，可用窗口减少到40服务器收到180字节的数据后，由于接收窗口只有100字节，超出了缓冲区的大小，因此会丢弃该数据包客户端此时收到之前的ACK报文，会将发送窗口减少为100，此时可用窗口出现了负值80（100（321141））
　　在上述情况中，减少缓存先于收缩窗口发生，出现丢包现象。
　　为了防止上述情况，TCP规定是先收缩窗口，过段时间再减少缓存，这样避免丢包。窗口关闭
　　什么是窗口关闭
　　窗口大小为0，阻止发送方给接收方发送数据，直到窗口变为非0才能恢复发送。
　　窗口关闭的危险
　　窗口关闭以后发送端无法发送数据给接收端，只有当接收端处理完数据以后，这时候窗口回复，发送ACK报文信息给客户端，客户端才能恢复发送。但是一旦该ACK报文丢失，那么发送方会一直等待接收方的非0窗口通知，接收方也一直在等待发送方的数据，容易造成死锁现象。
　　如何解决窗口关闭带来的死锁？
　　只要TCP连接的一方收到对方0窗口的通知，就启动计时器，如果计时器超时就会发送窗口探测报文给对端，对端会给出自己的接收窗口大小。如果收到的窗口依然为0，发送方重启启动持续计时器如果收到的窗口不为0，恢复正常发送
　　窗口探测的次数一般为3次，每次大约3060s。如果三次以后接收窗口还是0，有的TCP实现就会发送RST报文来中止连接。糊涂窗口综合征
　　什么是糊涂窗口综合征？
　　如果接收方太忙，来不及取走缓冲区的数据，发送方的窗口会越来越小，最后如果接收方空出几个字节并告诉发送方现在有几个字节的窗口，发送方便会发送这几个字节，这就是糊涂窗口综合征。
　　糊涂窗口综合征的缺点？
　　TCPIP头部大约有40个字节，为了几个字节数据，需要加上头部相对大的开销，性价比极低。
　　糊涂窗口综合征的原因是？接收方会告知发送方一个小的窗口发送方可以发送小数据
　　如何避免接收方告知小窗口？
　　接收方在告知窗口时会采取一种策略：当窗口大小小于min（MSS，缓存空间2），就会向发送方告知窗口为0，避免发送方发送数据，等到接收方处理完一些数据后，窗口大小MSS或者有一半以上缓存空间可以使用时，就可以把窗口打开让发送方发送数据。
　　如何避免发送方发送小数据？
　　发送方在发送数据时采用Nagle算法，该算法的思路是延时处理，满足以下两个条件才可以发送数据：窗口大小MSS或是数据大小MSS收到之前发送数据的ACK报文
　　对于telnet或ssh这种小数据包交互场景的应用程序，需要关闭Nagle算法。在Java中，对Socket进行以下设置可以关闭Nagle算法。SocketsocketnewSocket（）；socket。setTcpNoDelay（true）；