计算机网络——5.流量控制

半夜买了个PDF会员花了我40块，太痛了，作为报复我要发布一个文章，狠狠占用一下资本的网络带宽

1.流量控制

我的学习习惯就是提问，看见这个标题首先就要提问题，为什么要控制流量？什么是流量控制？首先我们知道，网络就像一条高速公路，我们发送的数据就像这条路上的车，而接收方就像一个停车场，我们当然可以源源不断的发车，但是这个停车场能否承受住呢？如果接收方处理不了大量的数据就会触发重传，从而浪费网络资源，为了避免这一现象就引入了流量控制。

1.滑动窗口

客户端和服务器可以相互提供数据流信息的交换，数据流的相关信息主要包括报文段序列号、ACK 号和窗口大小。图中的两个箭头表示数据流方向，数据流方向也就是 TCP 报文段的传输方向。可以看到，每个 TCP 报文段中都包括了序列号、ACK 和窗口信息，可能还会有用户数据。TCP 报文段中的窗口大小表示接收端还能够接收的缓存空间的大小，以字节为单位。这个窗口大小是一种动态的，因为无时无刻都会有报文段的接收和消失，这种动态调整的窗口大小我们称之为滑动窗口。

1.发送窗口

发送方维护的窗口，他由以下部分构成

1.发送并确认报文段：发送方已经发送成功，并且收到确认应答，表示此部分数据已经被成功接收

2.已发送未确认报文段：发送方已发送成功，但是尚未收到应答，此数据包可能在传输中，可能已被接收，但是应答数据包在传输途中，也可能已经丢失

3.等待发送报文段：它属于发送窗口结构的一部分，也就是说，发送窗口结构其实是由已发送未确认 + 等待发送的报文段构成。

4.窗口滑动时才能发送的报文段：当窗口[4,9]发送完毕后向右移动到这一部分时才可以发送的报文段

这时候我们发现这个窗口是[4,9]部分,那么这个窗口的边界就在这两个点，分别是左边界（Left edge）和右边界（Right edge）,这时候我们需要知道一件事，这个窗口大小不是固定的，他就像链表问题中的快慢指针一样是移动的

                                        ​​​​​​​            

当右边界向右移动时，窗口打开允许发送更多的数据。当接收端进程读取缓冲区数据，从而使缓冲区接收更多数据时，就会处于这种状态。

TCP 滑动窗口的 Left edge 永远不可能向左移动，因为发送并确认的报文段永远不可能被取消，就像这世界上没有后悔药一样。这条边缘是由另一段发送的 ACK 号控制的。当 ACK 标号使窗口向右移动但是窗口大小没有改变时，则称该窗口向前滑动。

如果 ACK 的编号增加但是窗口通告信息随着其他 ACK 的到达却变小了，此时左边界会接近 右边界。当左边界和 右边界重合时，此时发送方不会再传输任何数据，这种情况被称为零窗口。此时 TCP 发送方会发起窗口探测，等待合适的时机再发送数据。

2.接收窗口

有人发送就有人接收，那么有发送窗口就会有接收窗口，这个窗口要比发送方的简单很多。这个窗口记录了已经接收并确认的数据，以及它能够接收的最大序列号。接收方的窗口结构不会存储重复的报文段和 ACK，同时接收方的窗口也不会记录不应该收到的报文段和 ACK。

与发送窗口一样，接收窗口也有左边界和右边界，区别在于：

1.左边界：左边界的左边表示已经接收并确认的数据

2.右边界：右边界的右边表示现在不能接收的报文段，因为在此之前的报文段我还没有接收，提前接收的数据我无法处理

对于接收端来说，到达序列号小于 Left efge 的被认为是已经重复的数据，需要丢弃。超过 Right edge 的被认为超出处理范围。只有当到达的报文段等于 Left edge 时，数据才不会被丢弃，窗口才能够向前滑动。接收方窗口结构也会存在零窗口的情况，如果某个应用进程消耗数据很慢，而 TCP 发送方却发送了大量的数据给接收方，会造成 TCP 缓冲区溢出，通告发送方不要再发送数据了，但是应用进程却以非常慢的速度消耗缓冲区的数据（比如 1 字节），就会告诉接收端只能发送一个字节的数据，这个过程慢慢持续，造成网络开销大，效率很低。

3.零窗口和窗口探测

通过前面两个窗口我们知道了，这个窗口的大小不是固定的，他像一个弹簧一样可以伸长压缩，那么当窗口变成0的时候呢？岂不是不能发送或者接收了吗？

TCP 是通过接收端的窗口通告信息来实现流量控制的。通告窗口告诉了 TCP ，接收端能够接收的数据量。当接收方的窗口变为 0 时，可以有效的阻止发送端继续发送数据。当接收端重新获得可用空间时，它会给发送端传输一个 窗口更新 告知自己能够接收数据了。窗口更新一般是纯 ACK ，即不带任何数据。但是纯 ACK 不能保证一定会到达发送端，于是需要有相关的措施能够处理这种丢包。

窗口探测：

如果这个ACK包丢失的话，发送方和接收方都会等待，因为二者都不知道发生了什么，发送方会一位数据成功发送，接收方则会认为发送方尚未发送，为了解决这个问题，TCP会用类似超时重传的方式解决，发送方会采用一个持续计时器来间歇性的查询接收方，看看其窗口是否已经增长。持续计时器会触发窗口探测，强制要求接收方返回带有更新窗口的 ACK。

窗口探测包含一个字节的数据。当 TCP 持续计时器超时后，就会触发窗口探测的发送。一个字节的数据能否被接收端接收，还要取决于其缓冲区的大小。

4.糊涂窗口综合症

我们知道，每一个TCP的数据包都包含一个TCP头部，他的大小至少为20字节，那么不管你发送多少数据，哪怕只有一个字节，也会包含这个头部，发送了21字节的数据包，这样就太浪费了，而这就是糊涂窗口综合征，发送端应用进程产生数据很慢（例如每次只能产生一个字节，所以每次只能发送一个字节）、或接收端应用进程处理接收缓冲区数据很慢，或二者兼而有之；就会使应用进程间传输的报文段很小，造成大量的浪费。

那么如何解决呢？就像死锁的解决方法，从根源避免问题发生！

1.让接收方不通知小窗口给发送方：当我有大量的空闲空间时再通告发送方，这样就可以一次发送更多的有效数据

2.让发送方避免发送小数据：这我就不解释了，跟上一个一样

这就是TCP中的流量控制问题，加油努力，学习要用力！