什么是TCP流量控制？（解释说明+过程+示例）

数据在网络中的可靠传输首先是要解决数据丢包的问题。产生丢包的主要原因有：

处理数据的速度有限，装不下。发送方发送数据速率太快，接受方处理不过来，导致缓冲区装不下溢出丢失；

网络情况差。报文段因为网络拥塞或者情况不太好，导致迟迟不到，超时丢包。

不可控因素。物理传输过程中受损、丢失，或者路由错误导致的数据包丢失。

TCP的流量控制就是解决第一种问题的，通过滑动窗口协议来实现。

流量控制是一种TCP的可靠性传输机制，用于控制发送方向接收方发送数据的速率，以避免发送方发送的数据过多、过快而导致接收方无法及时处理和接收。

TCP的分段重排机制，将超过MSS（Maximum segment size）的报文分割为n个单位为MSS的报文段。在发送时，会给每个报文段分配一个序列号（sequence），放在TCP头部，接受方每收到一个报文段会返回一个ack应答，ack的值表示期望收到的下一个报文段编号。

好处: 如果发生丢包, 那么不用将整个报文都重传, 只用重传丢失的那小段报文段。

问题：TCP 发送一个数据，如果需要收到确认应答，才会发送下一个数据。这样的话就会有个缺点：效率会比较低。

“用一个比喻，我们在微信上聊天，你打完一句话，我回复一句之后，你才能打下一句。假如我没有及时回复呢？你是把话憋着不说吗？然后傻傻等到我回复之后再接着发下一句？”

解决方案：为了解决这个问题，TCP根据缓冲区的思想，引入了窗口，它是操作系统开辟的一个缓存空间。窗口大小值表示无需等待确认应答，而可以继续发送数据的最大值。

TCP 头部有个字段叫 win，也即那个 16 位的窗口大小，它告诉对方本端的 TCP 接收缓冲区还能容纳多少字节的数据，这样对方就可以控制发送数据的速度，从而达到流量控制的目的。

“通俗点讲，就是接受方每次收到数据包，在发送确认报文的时候，同时告诉发送方，自己的缓存区还有多少空余空间，缓冲区的空余空间，我们就称之为接受窗口大小。这就是 win。”

TCP 滑动窗口分为两种: 发送窗口和接收窗口。

关于滑动窗口具体详情可以看我下面这一篇文章:

什么是TCP滑动窗口？（解释+流程示例）-CSDN博客

TCP的流量控制主要通过以下两个机制实现：

滑动窗口（Sliding Window）：TCP使用滑动窗口来进行流量控制。接收方在TCP报文段的首部中通过"接收窗口"win字段告知自己的可接收数据量，即剩余的缓冲区大小。发送方根据接收方提供的窗口大小来决定发送数据的量，保证接收方能及时处理和接收数据。

基于确认的流量控制：能确保发送方不会超出接收方的处理能力。接收方通过发送确认（ACK）报文来告知发送方已成功接收数据的字节数。发送方根据接收到的确认信息来调整发送数据的速率，避免发送过多的数据。

TCP首部有个win字段, 即那个16位窗口大小, 能告诉对方自己接受缓存区当还能接收多少个字节的数据，这样就可以根据接收窗口的大小控制发送速率，达到流量控制的目的。

初始化窗口大小。 在建立TCP连接时，双方协商并初始化流量控制的参数（TCP三次握手时, 接收方会跟据自身处理数据能力和接收缓冲区大小, 告诉发送方自己的接收窗口大小; 发送方据此设置自己的初始化发送窗口大小）。 其中包括窗口大小（通常是以字节为单位的接收缓冲区大小）和初始的拥塞窗口大小。

接收窗口通告。 每次发送数据，接收方通过TCP报文段中的win"窗口大小"字段，通知发送方其当前可接收的字节数。这个窗口大小可以动态调整以反映接收方缓冲区的可用空间。

发送数据，确认等待。 发送方维护一个发送窗口，它表示发送方可以发送的字节数。发送方根据接收方通告的窗口大小，不等一个一个地接收ACK，先把发送窗口内的数据都发送给接收方，但不会超出发送窗口限制，然后收到一个ACK移动一次，直到丢包一直等待收到丢包数据段ACK。

接收数据，动态调整窗口大小：发送ACK。

接收方接收到数据报段后，会返回一个ACK确认报文给接收方，ACK就是他期待收到的下一个数据报的序列号；发送方等待接收方对已发送数据的确认，随后看情况移动窗口。

接收方同时会根据自身的可用缓冲区空间和处理能力，动态调整窗口大小，并将新的窗口大小放在首部win字段中随ACK应答通告给发送方，这样，发送方根据win大小进行数据发送控制。

接收方窗口滑动。 发送方根据接收方的ACK报文和通告窗口大小，将窗口在发送缓冲区中向前滑动。ACK报文有以下几种情况:

如果报文中win=0，发送方停止发送，开启一个定时任务，每隔一段时间，就去询问接受方，直到 win 大于 0，才继续开始发送；

如果接收的ACK值等于接收窗口最左侧的报文段序号, 说明该报文段还没收到、接收方一直期待接收它，窗口停止滑动，直到超时重传或者接收到该报文段的ACK（ACK值为窗口右端下一个报文段序号）。

如果一直在发送请求某个报文段的确认ACK，并且超过三次，或者有报文段超时重传，发送方会假设网络发生拥塞，并采取相应的拥塞控制机制。

TCP的拥塞机制详情可以参考我以下文章：） 什么是TCP的拥塞控制（解释+常见算法）-CSDN博客

(接收窗口决定发送窗口大小, 一般来说, 双方窗口大小一致, 对应发送和接收哪几个序列号的报文段)

假如当前发送方给接收方发送了 200 个字节，那么，发送方的SND.NXT（下一个发送位置）会右移 200 个字节，也就是说当前的可用窗口减少了 200 个字节。

接受方收到后，放到缓冲队列里面，窗口大小REV.WND =400-200=200 字节，所以 win=200 字节返回给发送方。接收方会在 ACK 的报文首部带上缩小后的滑动窗口 200 字节

发送方又发送 200 字节过来，200 字节到达，继续放到缓冲队列。不过这时候，由于大量负载的原因，接受方处理不了这么多字节，只能处理 100 字节，剩余的 100 字节继续放到缓冲队列。这时候，REV.WND = 400-200-100=100 字节，即 win=100 返回发送方。

发送方继续发送 100 字节过来，这时候，接收窗口 win 变为 0。

发送方停止发送，开启一个定时任务，每隔一段时间，就去询问接受方，直到 win 大于 0，才继续开始发送。

注：窗口单位大小一般是MSS的整数倍。