传输层-第四节：TCP流量控制

Posted 2023-03-08 快乐江湖

• 获取pdf：密码7281
• 专栏目录首页：【专栏必读】王道考研408计算机网络+湖科大教书匠计算机网络+网络编程万字笔记、题目题型总结、注意事项、目录导航和思维导图
• 王道考研408计算机组成原理万字笔记
• 王道考研408数据结构+计算机算法设计与分析万字笔记
• 王道考研408操作系统+Linux系统编程万字笔记

文章目录

• 一：流量控制概述
• 二：流量控制举例
• 三：拓展阅读（可不看）
• • （1）TCP流量控制完整例子
  • （2）操作系统缓冲区与滑动窗口的关系
  • • A：若应用程序没有及时读取缓冲区
    • B：操作系统直接减少缓冲区大小

本节对应视频如下

• 【计算机网络微课堂（有字幕无背景音乐版）】：TCP流量控制

一：流量控制概述

流量控制：一般来说，我们总希望数据能够传输得更快一些，但是存在一个问题，如果发送方发送数据过快那么接收方就有可能来不及接收，从而造成数据的丢失。所谓流量控制，就是让发送方的发送速率不要太快，让接收方能够来得及接收，TCP流量控制是利用滑动窗口机制来实现流量控制的

二：流量控制举例

如下图，A和B是因特网行两台主机，它们之间已经建立了TCP连接，A给B发送数据，B对A进行流量控制。左上角是主机A中待发送数据的字节序号，假设主机A发送的每个TCP报文段可携带100字节数据，因此图中每个小格子表示100字节数据的序号。在主机A和B建立TCP连接时，B告诉A“我的接收窗口为400”，因此主机A将自己的发送窗口也设置为400，这意味着主机A在未收到主机B发来的确认时可将序号落入发送窗口中的全部数据发送出去

主机B对主机A进行流量控制过程如下

• 主机A将发送窗口内序号1-100的数据封装为一个TCP报文段发送出去，发送窗口内还有300字节可以发送

  • seq是TCP报文段首部中的序号字段，取值为1表示TCP报文段数据载荷的第一个字节序号是1
  • Data是TCP数据报文段

• 主机A将发送窗口内序号101-200的数据封装为一个TCP报文段发送出去，发送窗口内还有200字节可以发送
  

• 主机A将发送窗口内序号201-300的数据封装为一个TCP报文段发送出去，但丢失了，发送窗口内还有100字节可以发送
  

• 主机B对主机A所发送的201号之前的数据进行累积确认，并在该累积确认中将窗口字段额值调整为300，也就是对主机A进行流量控制

  • ACK是TCP报文段首部中的标志位，取值为1表示这是一个TCP确认报文段
  • ack是TCP报文段首部中的确认号字段，取值为201表示201之前的数据已全部正确接收，现在希望收到序号201及其后续数据
  • rwnd是TCP报文段首部中的窗口字段，取值300表示自己的接收窗口大小为300
    

• 主机A收到该累积确认后，将发送窗口向前滑动，使已发送并收到确认的这些数据的序号移出发送窗口

• 由于主机B在该累积确认中将自己的接收窗口调整为了300，因此主机A相应地也将自己的发送窗口调整为300
  

• 主机A现在可以将发送缓存中序号1-200的字节数据全部删除了，因为已经收到了主机B对它们的累积确认

• 目前，主机A发送窗口内的序号为201-500，也即主机A还可以发送这300字节

  • 201-300：是已发送的数据，若重传计时器超时，它们会被重传
  • 301-400和401-500：还未被发送，可被分别封装在一个TCP报文段中发送
    

• 主机A将发送窗口内序号301-400的数据封装成一个TCP报文段发送出去，发送窗口内还有100字节可以发送

• 主机A将发送窗口内序号401-500的数据封装成一个TCP报文段发送出去。

• 至此，序号落在发送窗口内的数据已经全部被发送出去了，不能再发送新数据了
  

• 现在，发送窗口内序号201-300这100字节数据的重传计时器超时了，主机A将它们重新封装为一个TCP报文段发送出去，暂时不能发送其他数据
  

• 主机B收到重传的TCP报文段后，对主机A所发送的501号之前的数据进行累积确认，并在该累积确认中将接收窗口调整为100，这是主机B对主机A进行的第二次流量控制
  

• 主机A收到该累积确认后，将发送窗口向前滑动，使以发送并收到确认的这些数据的序号移出发送窗口

• 由于主机B在该累积确认中将自己的接收窗口调整为了100，因此主机A相应地也将自己的发送窗口调整为100
  

• 主机A现在可以将发送缓存中序号201-500的字节数据全部删除了，因为已经收到了主机B对它们的累积确认

• 目前，主机A发送窗口内的序号为501-600，也即主机A还可以发送这100字节
  

• 主机A将发送窗口内序号501-600的数据封装成一个TCP报文段发送出去

• 至此，序号落在发送窗口内的数据已经全部被发送出去了，不能再发送新数据了
  

• 主机B对主机A所发送的601号之前的数据进行累积确认，并在该累积确认中将窗口字段的值调整为0，这是主机B对主机A进行的第三次流量控制
  

• 主机A收到该累积确认后，将发送窗口向前滑动，使以发送并收到确认的这些数据的序号移出发送窗口

• 由于主机B在该累积确认中将自己的接收窗口调整为了0，因此主机A相应地也将自己的发送窗口调整为0

• 目前，主机A不能再发送一般的TCP报文段了
  

• 主机A现在可以将发送缓存中序号501-600的字节数据全部删除了，因为已经收到了主机B对它们的累积确认
  

• 假设主机B向主机A发送了零窗口的报文段后不久，主机B的接收缓存又有了一些存储空间

• 于是，主机B向主机A发送了接收窗口为300的报文段，然后它在传输过程中丢失了
  

• 主机A一直等待主机B发送的非零窗口的通知

• 主机B一直等到主机A发送的数据

• 如果不采取措施，这种互相等待的死锁局面将会一直持续下去
  

• 为了解决这个问题，TCP为每一个连接设置了一个持续计时器，只要TCP连接的一方收到对方的零窗口通知就启动持续计时器；若持续计时器超时，就发送一个零窗口探测报文，仅携带一字节的数据，而对方在确认这个探测报文段时，给出自己现在的接收窗口值。TCP规定：即使接收窗口为0也必须接收零窗口探测报文段、确认报文段以及携带有紧急数据的报文段

  • 如果接收窗口仍然为0：那么收到这个报文段的一方就会重新启动持续计时器
  • 如果接收窗口不是0：那么死锁局面就可以被打破

• 对于本例，主机A收到零窗口通知时，就启动一个持续计时器，当持续计时器超时，主机A立刻发送一个仅携带一字节数据的零窗口探测报文段
  

• 假设此时主机B的接收窗口又为0了，主机B就在确认这个零窗口探测报文段时，给出自己现在的接收窗口值为0
  

• 主机A再次收到零窗口通知，就再次启动一个持续计时器，当持续计时器超时，主机A立刻发送一个仅携带一字节数据的零窗口探测报文段
  

• 假设主机B此时的接收缓存又有了一些存储空间，于是将自己的接收窗口调整为了300

• 主机B就在确认这个零窗口探测报文段时，给出自己现在的接收窗口值为300
  

三：拓展阅读（可不看）

（1）TCP流量控制完整例子

如下图是一个经典的场景，其中客户端是接收方，服务端是发送方。假设接受窗口和发送窗口都为200。假设两个设备在传输过程中都保持相同的窗口大小，不受外界影响

过程如下

• 1：客户端向服务端发送请求数据报文
• 2：服务端受到请求报文后，发送确认报文和80字节的数据，于是可用窗口可用窗口减少为120字节。同时，SND.NXT指针也向右移动80字节，指向321，意味着下次发送数据序列号为321
• 3：客户端收到80字节数据后，其接受窗口向右移动80字节，RCV.NXT指向321，意味着客户端期望的下一个报文序列号是321，接着发送确认报文给服务端
• 4：服务端再次发送120字节数据，可用窗口耗尽为0，无法再发送数据
• 5：客户端收到120字节数据后，接受窗口向右移动120字节，RCV.NXT指向441，接着发送ACK
• 6：服务端收到对80字节数据的确认报文后，SUD.UNA指针向右偏移指向321，于是可用窗口增大到80
• 7：服务端受到对120字节的确认报文后，SUD.UNA指针向右偏移指向441，于是可用窗口增大到200
• 8：服务端现在可以继续发送，发送160个字节的数据后，SND.NXT指向601，可用窗口减少到40
• 9：客户端收到160字节后，接收窗口向右移动160字节，RCV.NXT指向601，接着发送ACK
• 10：服务端收到对160字节数据的确认报文后，发送窗口向右面移动60字节，SND.UNA指针偏移160后指向601，可用窗口增大至200

（2）操作系统缓冲区与滑动窗口的关系

上面的例子中，发送窗口和接受窗口的大小是不变的。但在实际情况中，发送窗口和接受窗口中存放的字节数，都会存放在操作系统中的内存缓冲区，因此一定会受到操作系统的控制而被调整。当应用程序由于各种原因未及时读取缓冲区中的内容时，也会对缓冲区造成影响

A：若应用程序没有及时读取缓冲区

下面的例子展示的是由于应用程序没有及时读取缓冲区时，发送窗口和接受窗口的变化情况，其中

• 客户端为发送方，服务端为接收方，发送窗口和额接受窗口初始大小为360
• 服务端很忙，收到客户端数据时，应用层未能及时处理数据

过程如下

• 1：客户端发送140字节数据，可用窗口变为220
• 2：服务端受到140字节数据，由于服务器繁忙，应用程序仅仅读取了40字节，还有100字节占用缓冲区，因此接收窗口缩小到260（360-100），最后发送ACK时，将窗口大小告知客户端
• 3：客户端收到ACK后，将发送窗口减少为260
• 4：客户端发送180字节数据，可用窗口减少到80
• 5：服务端收到180字节后，但是应用层没有读取任何数据，180字节直接留在了缓冲区，于是接收窗口缩小到了80（260-180），最后发送ACK时，将窗口大小告知客户端
• 6：客户端收到ACK后，将发送窗口减少为80
• 7：客户端发送80字节数据后，可用窗口耗尽
• 8：服务端收到80字节数据，但是应用程序依然没有读取任何数据，这80字节仍然留在缓冲区，于是接收窗口缩小到了0，最后发送ACK时，将窗口大小告知客户端
• 9：客户端收到ACK后，将发送窗口减少为0

最后窗口变为了0，也即是发生了窗口关闭。当发送方窗口为0时，发送方实际上会定时发送窗口探测报文，以便知道接受方的窗口是否发生了改变

B：操作系统直接减少缓冲区大小

当服务器系统资源很紧张的时候，操作系统可能会直接减少接受缓冲区的大小，这时应用程序又无法及时读取缓冲区数据的话，那么可能导致丢包现象的产生

过程解释如下

• 1：客户端发送140字节的数据，可用窗口减少到了220
• 2：服务端因为现在非常繁忙，操作系统于是就把接受缓存减少了120字节，当收到140字节数据后，由因为应用程序没有及时读取数据，所以140字节留在了缓冲区中，于是接受窗口大小由360缩小到了100。最后发送ACK时，通知窗口大小给对方
• 3：此时客户端因为还没有收到服务端的ACK，所以不知道此时接受窗口缩减到了100，客户端只会看到自己的可用窗口还有220，于是客户端发送了180字节数据，可用窗口减少到了40
• 4：服务端收到了140字节数据，发现数据大小超过了接收窗口的大小，于是直接把数据丢了
• 5：客户端收到第2步服务端发送的ACK后，尝试减少发送窗口到100，把窗口的右端向左收缩了80，但是在第3步时，已经发送了超过100字节的数据，所以可用窗口出现负值

所以如果发生了先减少缓存，再收缩窗口，就会出现丢包的现象。因此为了防止这种情况发生，TCP规定不允许同时减少缓存又收缩窗口的，而是先收缩窗口，一定时间后再减少缓存