324-TCP的流量控制

水深无声 2022-10-16 07:15 165阅读 0赞

## TCP的流量控制 ##

## 利用滑动窗口实现流量控制 ##

一般来说，我们总是希望数据传输得更快一些。**但如果发送方把数据发送得过快，接收方可能来不及接收，这就会造成数据的丢失**。  
所谓**流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。**  
**利用滑动窗口机制**可以很方便地在TCP连接上实现对发送方的流量控制。  
**下面通过图5-22的例子说明如何利用滑动窗口机制进行流量控制。**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70]  
**设A向B发送数据**。在连接建立时，**B告诉了A**：“我的接收窗口 rwnd=400”（这里rwnd表示receiver window）。**因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值**。请注意，TCP的窗口单位是**字节**，不是报文段。TCP连接建立时的窗口协商过程在图中没有显示出来。再设每一个报文段为100字节长，而数据报文段序号的 初始值设为1（见图中第一个箭头上面的序号seq=1。图中右边的注释可帮助理解整个过程）。请注意，**图中箭头上面大写ACK表示首部中的确认位ACK，小写ack表示确认字段的值。**  
我们应该注意到，**接收方的主机B进行了3次流量控制**。第一次把窗口减小到rwnd=300,第二次又减到rwnd=100，最后减到rwnd=0，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。我们还应注意到，B向A发送的三个报文段都设置了ACK=1,只有在ACK=1时确认号字段才有意。  
**现在我们考虑一种情况。在图5-22中，B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间**。于是B向A发送了rwnd=400的报文段。然而这个报文段在传送过程中丢失了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。  
**为了解决这个问题，TCP为每一个连接设有一个持续计时器**。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。如果窗口值任然是零，那么收到这个报文段的一方就重新设置持续计时器。如果窗口不是零，那么死锁的僵局就可以打破了。

## TCP的传输效率 ##

前面已经讲过，应用进程把数据传送到TCP的发送缓存后，剩下的发送任务就由TCP来控制了。**可以用不同的机制来控制TCP报文段的发送时机**。例如，**第一种机制**是TCP维持一个变量，它等于最大报文段长度MSS。只要缓存中存放的数据达到MSS字节时，就组装成一个TCP报文段发送出去。**第二种机制**是由发送方的应用进程指明要求发送报文段，即TCP支持的推送操作。**第三种机制**是发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不能超过MSS）发送出去。  
但是，如何控制TCP发送报文段的时机仍然是一个较为复杂的问题。  
**例如**，一个交互式用户使用一条TELNET连接（运输层为TCP协议）。假设用户只发1个字符，加上20字节的首部后，得到21字节长的TCP报文段。再加上20字节的IP首部，形成41字节长的IP数据报。在接收方TCP立即发出确认，构成的数据报是40字节长（假定没有数据发送）。若用户要求远地主机回送这一字符，则又要发回41字节长的IP数据报和40字节长的确认IP数据报。这样，用户仅发1个字符时，线路上就需传送总长度为162字节共4个报文段。当线路带宽并不富裕时，这种传送方法的效率的确不高。**因此应适当推迟发回确认报文，并尽量使用捎带确认的方法。**  
**在TCP的实现中广泛使用Nagle算法**。**算法如下**：若发送应用进程把要发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来。当发送方收到对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对随后到达的数据进行缓存。只有在收到对前一个报文段的确认后才继续发送下一个报文段。当数据到达比较快而网络速率较慢时，用这样的方法可明显地减少所用的网络带宽。**Nagle算法还规定**，当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。这样做，就可以有效地提高网络的吞吐量。  
**另一个问题叫做糊涂窗口综合征，有时也会使TCP的性能变坏**。设想一种情况：TCP接收方的缓存已满，而交互式的应用进程一次只从接收缓存中读取1个字节（这样就使缓存空间仅腾出1个字节），然后向发送方发送确认，并把窗口设置为1个字节（但发送的数据报是40字节长）。接着，发送方又发来1个字节的数据（请注意，发送方发送的IP数据报是41字节长）。接收方发回确认，仍然将窗口设置为1个字节。这样进行下去，使网络的效率很低。  
**要解决这个问题，可以让接收方等待一段时间，使得或者接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲的空间**。**只要出现这两种情况之一，接收方就发出确认报文，并向发送方通知当前的窗口大小。此外，发送方也不要发送太小的报文段，而是把数据积累成足够大的报文段，或达到接收方缓存的空间的一半大小。**  
**上述两种方法可配合使用**。使得在发送方不发送很小的报文段的同时，接收方也不要在缓存刚刚有了一点小的空间就急忙把这个很小的窗口大小信息通知给发送方。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70]: /images/20221014/4cd4a261539d4d24b5ca2ac8f2a2da9a.png