计算机网络中的滑动窗口与流量控制

根据前述，接收方接收到数据后需发回报文响应，如采用这种传输策略，发送端必须接收到接收端的应答后才能发送下一个数据分组，那么网络将有一段空闲时间（接收端对数据包处理所需时间）。这样会浪费网络带宽，降低效率，网络延时越大，浪费就越严重。为使网络高效运行和控制流量，TCP采用另一策略：滑动窗口机制（Sliding window mechanism）。

1.滑动窗口机制

图6-19所示是一个包含8B的窗口，窗口里是正发送的数据（未收到应答），窗口右边是还不能发送的数据。当收到前4个B应答时，窗口将向右滑动。窗口是基于字节来操作而非报文段，窗口大小是以包含多少字节来计算。对被窗口框住的数据分组，发送端可无延时地发送而不必等待应答的到来。

图6-19 滑动窗口示例

a）窗口滑动以前 b）窗口滑动以后

发送方的窗口由三个指针确定（图6-20）。左边的指针是已发送并得到确认的数据和未得到确认的数据的分界；右边的指针指出当前可以发送的数据的上界；中间的指针的左边是已发送的数据，而右边是还未发送的数据。

图6-20 滑动窗口的3个指针

窗口大小决定可发送的数据大小的上限，但发送端不一定要发送整个窗口大小的数据。TCP协议规定窗口大小是可根据需要而改变的，由于这个特性，窗口机制还有流量控制的功能。如图6-21a所示，设原先窗口大小为8，发送端把数据发送出去之后，接收到接收端发回的两个数据的确认，并发现在确认报文中窗口通告的值为10，表明可以接收更多数据所以它在滑动窗口的同时也增大了窗口大小。现在可一次发送10个数据，如图6-21b所示。如接收到确认同时发现窗口通告值变小，就知道接收端不能接收太多的数据，在滑动窗口的同时也将窗口缩小，如图6-21c所示。

图6-21 可变大小的滑动窗口(https://www.xing528.com)

a）原始窗口大小为8 b）增大窗口至10 c）减小发送窗口至6

窗口的大小由接收端来设置，它可控制发送端发送数据的速率和数量。如接收端认为自己空闲的接收缓冲区有限或网络负载过重（接收端发现自己发送的数据到接收到确认之间的延时很长或报文丢失增多，就估计此时网络负载可能过重），就可减小窗口通告的值来限制发送端发送数据，以免让网络陷入更糟的情形。

在接收方对接收到的数据确认中有一个窗口通告，它告知发送方最多可发送的字节数。该数字可认为是接收方当前的空闲缓冲区大小，反映了接收端接收数据能力的大小。若接收端的缓冲区已装满而应用程序还未取走数据，那么它返回的窗口通告为0。这时发送方定期发送一个字节的报文段以试探接收端是否可接收数据，接收方对每一个这样的报文都要有一个应答以告诉对方此时可接收多少数据。

2.糊涂窗口症状

每次通告的窗口很小，而发送端每次也只发出少量数据时，会出现糊涂窗口症状（Silly window syndrome），如图6-22所示。假设接收端的缓冲区已装满，而应用程序只读取了一个字节的数据，此时缓冲区有空位，接收端发送大小为一个字节的通告窗口，发送端接收到通告窗口后，知道接收端只能接收一个字节的数据，将一个字节的数据打包后发送出去，从而填满接收端的缓冲区。

上述过程中，发送程序为了打包一个字节的数据必须为其加上20B的TCP头部和20B的IP头部，总共需发送41个B，而其中有用的数据只占总数的1/41。该方法不仅浪费大量带宽，而且发送端和接收端主机为生成报文头部和计算校验和而花费了更多的CPU时间。

图6-22 糊涂窗口示例

从上面论述可知糊涂窗口的发生与发送端和接收端均有关。为了避免糊涂窗口，需让双方的协议软件都遵守一定规则：在发送端必须防止逐个字节的发送数据，而在收集了一定数量的数据后再打包发送。采用Nagle算法，让TCP在发送完应用程序的第一块数据后，只有在接收到接收端的确认或缓冲区数据积累到可组成一个最大的报文段才发送数据。

接收端糊涂窗口的一种解决方法是延迟发送确认，即当接收到报文段时，并不立即发送确认而是等待缓冲区有足够的空间。另一种解决方法称为Clark方法，它不推迟确认，但是发回的确认通告窗口都为零，直到空闲缓冲区大小达到最大报文段长度或达到缓冲区一半。