开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第7天，点击查看活动详情
引言
TCP: 传输控制协议（初步）(一)—— ARQ 和重传的片尾，提出了当多个分组同时进入网络时，发送方不仅要确定时间时间发送分组，还要考虑发送多少个，发送方在等待 ACK 时，怎样维持计时器，同时还要保存未确认的分组的一个副本以防需要重传；接收方需要一个更复杂的 ACK 与分组保存机制，用以区分哪些分组收到哪些分组没收到，同时还要处理收到乱序的分组。TCP 通过对窗口的定义，来解决上述问题。
分组窗口与滑动窗口
首先我们假设每个唯一的分组都有一个新的序列号，接收方可以使用这个序列号来判断它是否已经见过这个分组。
定义分组窗口（window）作为已被发送方注入但还没确认的分组（或者他们的序列号）的集合，我们把这个窗口中的分组数量称为窗口大小(window size)。如图所示为发送方窗口：
这个图显示了当前三个分组的窗口，整个窗口大小是3。3号分组已经被发送和确认，所以由发送方保存的它的副本可以被释放。分组7在发送方已经准备好，但是还没被发送，因为它还没进入窗口。随着数据从发送方流向接收方，ACK 开始从接收方流向发送方，当发送方接收到分组4的 ACK 时，窗口向右“滑动”一个分组，于是分组4被释放而分组7可以被发送。窗口的这种滑动类型的协议就是
滑动窗口（sliding window）协议。
一般来说，滑动窗口结构在发送方和接收方都有，在发送方，它记录着哪些分组可被释放，哪些分组在等待 ACK，以及哪些分组还不能被发送；在接收方，它记录着哪些分组已经被接收和确认，哪些分组是下一步期望的被接收的和哪些分组即使被接收也会因内存限制而丢弃。
变量窗口：流量控制与拥塞控制
窗口很好的解决了发送方和接收方之间流动数据的记录，但窗口大小定义多少，接收方或者网络处理不了发送方速率时，窗口好像都没有很好的解决。为了处理当接收方相对发送方太慢时产生的问题，我们以流量控制（flow control）中两种常用方式来解决。
- 基于
速率（rate-based）流量控制：给发送方指定某个速率，同时确保数据永远不能超过这个速率发送，这种类型的流量控制最适合流应用程序，可被用于广播和组播发现。 - 基于
窗口（window-based）流量控制：是使用滑动窗口时最流行的方法，即窗口不是固定的，是允许随时间发送而变动的。
基于窗口（window-based）进行流量控制，必须通过窗口通告（window advertisement）或窗口更新（window update）来告知发送方使用多大的窗口，对 TCP 来说窗口更新和 ACK 是由同一分组携带的，即发送方往往会在它的窗口滑动到右边的同时调整它的大小。
变量窗口通过接收方告知的窗口大小限制发送方发送速率不超过接收方处理速率，这种方式很好地保护接收方，但对于中间网络，发送方的速率可能超过某个有限内存的路由器的能力，从而导致丢包。此时通过拥塞控制（congestion control）的流量形式来处理，拥塞控制涉及发送方减低速率以不至于压垮其与接收方之间的网络。
后面我们再详细介绍实际用于 TCP 中的拥塞控制技术。
资料来源
《TCP/IP 详解：卷1:协议》
