4-7：TCP协议之流量控制

Posted 2021-08-28 快乐江湖

文章目录

• 一：流量控制
• 一：操作系统缓冲区与滑动窗口的关系
• • （1）若应用程序没有及时读取缓冲区
  • （2）操作系统直接减少缓冲区大小

本文大部分内容来自小林coding《图解网络》，感谢分享，简单整理。

一：流量控制

我们知道发送方是不能无脑发送数据给接受方的，如果一直无脑发送，而导致对方处理不过来，那么就会触发重传，从而引起资源浪费

为了解决这一问题，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

一：操作系统缓冲区与滑动窗口的关系

前面流量控制的例子，我们假定了发送窗口和接受窗口是不变的，但实际上，发送窗口和接受窗口中存放的字节数，都是存放在操作系统的内存缓冲区中的，因此一定收到操作系统控制而被调整

当应用程序由于各种原因未及时读取缓冲区中的内容时，也会对缓冲区造成影响

（1）若应用程序没有及时读取缓冲区

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

• 客户端为发送方，服务端为接收方，发送窗口和额接受窗口初始大小为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时，发送方实际上会定时发送窗口探测报文，以便知道接受方的窗口是否发生了改变。

（2）操作系统直接减少缓冲区大小

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