TCP滑动窗口和流量控制详解

1. 什么是滑动窗口

TCP 每发送⼀个数据，都需要⼀次应答，然后继续发送，这样为每个数据包都进⾏确认应答，缺点是：数据往返时间越⻓，⽹络吞吐量越低。为了解决这个问题，TCP 引⼊了窗⼝这个概念。即使在往返时间较⻓的情况下，它也不会降低⽹络通信的效率。⽽窗⼝的⼤⼩呢，就是⽆需等待确认应答，可以继续发送数据的最⼤值。

假设窗⼝⼤⼩为 3 个 TCP 段，那么发送⽅就可以「连续发送」 3 个 TCP 段，并且中途若有 ACK 丢失，可以通过「下⼀个确认应答进⾏确认」。如下图：

窗⼝的实现就是操作系统开辟的⼀个缓存空间，发送⽅主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。

图中的 ACK 600 确认应答报⽂丢失，也没关系，因为可以通过下⼀个确认应答进⾏确认，只要发送⽅收到了 ACK700 确认应答，就意味着 700 之前的所有数据「接收⽅」都收到了。这个模式就叫 累计确认或者累计应答 。

TCP 头部有⼀个字段叫 window ，窗⼝⼤⼩。

这个字段是接收端告诉发送端⾃⼰还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能⼒来 发送数据，⽽不会导致接收端处理不过来

通常窗⼝的⼤⼩是由接收⽅的窗⼝⼤⼩来决定的。

发送⽅发送的数据⼤⼩不能超过接收⽅的窗⼝⼤⼩，否则接收⽅就⽆法正常接收到数据。

下图就是发送⽅缓存的数据，根据处理的情况分成四个部分：

#1 是已发送并收到 ACK 确认的数据： 1 到 31 字节

#2 是已发送但未收到 ACK 确认的数据： 32 到 45 字节

#3 是未发送但总⼤⼩在接收⽅处理范围内（接收⽅还有空间）： 46 到 51 字节

#4 是未发送但总⼤⼩超过接收⽅处理范围（接收⽅没有空间）： 52 字节以后

下图表示数据全都发送以后，可⽤窗⼝⼤⼩为 0 ，在没收到 ACK 确认应答之前⽆法继续发送数据。

下图，当收到之前发送的数据 32~36 字节的 ACK 确认应答后，如果发送窗⼝的⼤⼩没有变化，则 滑动窗⼝往右边 移动 5 个字节，因为有 5 个字节的数据被应答确认 ，接下来 52~56 字节⼜变成了可⽤窗⼝，那么后续也就可以发送 52~56 这 5 个字节的数据了。

在收到 32-36 的 ACK 应答后，如果窗⼝⼤⼩不变，则滑动窗⼝先后移动 5 个字节，那么 52-56 变成可⽤窗⼝，可以继续发送数据。

TCP 滑动窗⼝⽅案使⽤三个指针来跟踪在四个传输类别中的每⼀个类别中的字节。其中两个指针是绝对指针（指特定的序列号），⼀个是相对指针（需要做偏移）。

那么可用窗口大小的计算就可以是：

可用窗口大小 = SND.WND -（SND.NXT - SND.UNA）

已发送未确认 = （SND.NXT - SND.UNA)

接收窗⼝根据处理的情况划分成三个部分：

其中三个接收部分，使用两个指针进行划分:

并不是完全相等，接收窗口的大小是约等于发送窗口的大小的。

因为滑动窗口并不是一成不变的。比如，当接收方的应用进程读取数据的速度非常快的话，这样的话接收窗口可以很快的就空缺出来。那么新的接收窗口大小，是通过 TCP 报文中的 Windows 字段来告诉发送方。那么这个传输过程是存在时延的，所以接收窗口和发送窗口是约等于的关系。

TCP 流量控制（Flow Control）机制是为了防止发送方发送数据过快，导致接收方的缓冲区溢出而设计的一种控制机制。TCP 使用一种被称为“滑动窗口协议”的方法来实现流量控制。

滑动窗口（Sliding Window）：
- 滑动窗口是一种流量控制技术，它允许发送方在等待接收方确认之前发送多个数据包。
- 窗口大小决定了发送方在等待确认之前可以连续发送的最大数据量。
接收窗口（Receive Window）：
- 接收窗口（rwnd）是接收方用于通知发送方自己可以接收的数据量。
- 接收窗口的大小通常由接收方的缓冲区大小决定，接收方会在每次发送确认包时，包含当前的接收窗口大小。
拥塞窗口（Congestion Window）：
- 拥塞窗口（cwnd）是为了防止网络拥塞而引入的窗口。
- 拥塞控制是另一个独立的机制，用于调整发送方在网络中实际发送的数据量。