网络协议TCP的流量控制机制

Posted 2020-09-17 jhcelue

    一般来说，我们总是希望传输数据的更快一些，但假设发送方把数据发送的非常快。而接收方来不及接收，这就可能造成数据的丢失。流量控制就是让发送方的发送速率不要太快。让接收方来得及接收。

    对于成块数据流，TCP利用滑动窗体机制来实现流量的控制，对于交互数据流，TCP利用捎带ACK和Nagle算法来实现流量的控制。

    后两种就不说了，上篇博文中将已经写得比較清楚了，对于滑动窗体机制。上篇博文中也又说到，仅仅是没有刻意提到用滑动窗体来实现流量的控制。以下就具体说下利用滑动窗体机制来实现流量控制的机制，先看下图：

     我们假设A向B发送数据。在连接建立时，B告诉了A：“我的接收窗体是 rwnd = 400 ”(这里的 rwnd 表示 receiver window) 。

因此，发送方的发送窗体不能超过接收方给出的接收窗体的数值。

请注意，TCP的窗体单位是字节。不是报文段。TCP连接建立时的窗体协商过程在图中没有显示出来。再设每个报文段为100字节长，而数据报文段序号的初始值设为1。大写ACK表示首部中的确认位ACK，小写ack表示确认字段的值。 

    从图中能够看出，B进行了三次流量控制。

第一次把窗体降低到 rwnd = 300 。第二次又减到了 rwnd = 100 ，最后减到 rwnd = 0 。即不同意发送方再发送数据了。这样的使发送方暂停发送的状态将持续到主机B又一次发出一个新的窗体值为止。

    我们考虑一种特殊情况。假设B在向A发送了零窗体报文段后不久，B的接收缓存又有了一些存储空间，于是B向A发送了一个rwnd=400的报文段，然而这个报文段在传送过程中丢失了，A就一直等待B发送非零窗体的报文通知，而B一直等待A发送数据，假设没有不论什么措施的话。这话死锁的局面会一直延续下去。

    为了解决问题，TCP为每个连接设有一个持续计时器(也叫坚持定时器)。仅仅要TCP连接的一方收到对方的零窗体通知，就启动持续计时器。

若持续计时器设置的时间到期，就发送一个零窗体控測报文段（携1字节的数据），对方在收到探測报文段后。在对该报文段的确认洪给出如今的窗体值，假设窗体值仍未零，则收到这个报文段的一方就又一次设置持续计时器，假设窗体不为零。那么死锁的僵局就被打破了。

    糊涂窗体综合症。

设想一种情况。TCP接收方的缓存已满。而应用进程一次仅仅从接收缓存中读取1字节（这样就使接收缓存空间仅腾出1字节），然后向发送方发送确认，并把窗体设置为1个字节（但发送的数据报为40字节长）。接收，发送方又发来1个字节的数据（发送方的IP数据报是41字节）。接收方发回确认，仍然将窗体设置为1个字节。这样，网络的效率非常低。要解决问题。可让接收方等待一段时间，或者等到接收方缓存已有一半空暇的空间。仅仅要出现这两种情况之中的一个。接收方就发回确认报文，并向发送方通知当前的窗体大小。

此外。发送方也不要发送太小的报文段。而是把数据报积累成足够大的报文段。或达到接收方缓存的空间的一半大小时再发送给接收端。