计算机网络：TCP滑动窗口的流量控制和拥塞控制

矫情吗；* 2022-03-26 12:07 375阅读 0赞

# 1. 前言 #

最近在研究网络通信底层通信原理，所以不得不复习一波计算机网络传输控制协议。那么对于程序开发人员，了解底层网络通信原理，对于我们理解BIO、NIO网络通信十分重要。所以对于程序开发人员来说，我们需要了解这方面的知识。

# 2. 传输控制协议简介 #

TCP网络传输是面向字节流：TCP中的流（Stream）就是指的是流入到进程或者从进程流出的字节序列。虽然应用程序和TCP的交互是一次一个数据块（也就是我们定义的不同大小的Buffer长度），但是TCP把应用程序交互下来的数据仅仅是看成是一连串的无结构的字节流，并且将这一连串应用程序交互下来的数据放入TCP中的发送缓存中。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70]

TCP并不关心应用程序一次把多长的报文发送到TPC的缓存中去，而是根据对方给出的窗口值的大小和当前网络拥塞程度来决定一个报文段应该包含多少个字节。如果应用进程传输到TCP缓存的数据块太长，TCP就可以把它划分短一些再进行数据传输，TCP也可以积累足够长的数据之后再进行网络传输。那么我们可能会问？对于TCP报文段的长度问题，TCP如何划分多长的长度为一个TCP报文呢？对于这个问题我们后面再讨论，具体和对方给出的窗口值的大小和网络拥塞程度有关。

## 2.1 TCP 可靠传输的原理 ##

由于TCP需要提供可靠的网络传输。理想的网络传输条件有以下两个条件：

> 1.  传输信道不产生差错
> 2.  不管发送方以多块的速度发送数据，接收方总能来得及处理收到的数据。

### 停止等待协议 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 1]

“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。这种停止等待协议存在问题：信道利用率太低，每一个发送的分组必须等待上一个发送的分组确认后，才能发送下一个分组。这种传输协议，效率太低，对于网络数据传输不可接受。

### ARQ协议 ###

![在这里插入图片描述][2019011710064292.png]

连续重发请求ARQ方案是指发送方可以连续发送一系列信息帧，即不用等前一帧被确认便可继续发送下一帧，效率大大提高。但在这种重发请求方案中，需要在发送方设置一个较大的缓冲存储空间（称作重发表），用以存放若干待确认的以及待发送信息帧。当发送方收到对某信息帧的确认帧后，便可从重发表中将该信息帧删除。所以，连续重发请求ARQ方案的链路传输效率大大提高，但相应地需要更大的缓冲存储空间。

连续ARQ协议规定，发送方维持一个发送窗口，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。接收方一般都是采用累积确认的方式。就是说，接收方不必对收到的分组阻隔发送确认，而是在和搜到几个分组后，对按序到达的最后一个分组发送确认。这样做的优点是实现容易，节省带宽；缺点是容易发生Go-back-N问题。

### 发送缓存和接受缓存 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 2]

*  发送缓存用来暂时存放：
    
     *  发送应用程序传送给发送方 TCP 准备发送的数据；
     *  TCP 已发送出但尚未收到确认的数据。
 *  接收缓存用来暂时存放：
    
     *  按序到达的、但尚未被接收应用程序读取的数据；
     *  不按序到达的数据。

**缓存与窗口的区别**

发送/接收缓存与发送/接收窗口并不是同一个概念，窗口通常只是缓存的一部分。

发送缓存用来暂时存放：

>  *  发送应用程序传送给发送方TCP准备发送的数据；
>  *  TCP已发送出但尚未收到确认的数据（以备重传需要）

## 2.2 滑动窗口定义 ##

滑动窗口协议（Sliding Window Protocol），属于TCP协议的一种应用，用于网络数据传输时的流量控制，以避免拥塞的发生。该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输，提高网络吞吐量。

![在这里插入图片描述][20190117100700116.png]

TCP的滑动窗口是以字节为单位的。这个时候我们可能会问？在TCP传输层的数据传输，不是以报文为单位进行数据传输的呢？这个问题可以这样解释，其实TCP的滑动窗口也缓存的一种。滑动窗口这是在发送缓存和接受缓存之间用来流量控制和拥塞控制的一个组件。那么在后面TCP会从滑动窗口中提出可以发送的数据字节，并且把这些数据字节封装成一个TCP报文段，然后通过传输层、网络层、数据链路层、物理层进行进一步数据传输。

这个时候我们就来回答我们之前提到的问题？对于TCP报文段的长度问题，TCP如何划分多长的长度为一个TCP报文呢？

>  *  第一种机制是 TCP 维持一个变量，它等于最大报文段长度 MSS。只要缓存中存放的数据达到 MSS 字节时，就组装成一个 TCP 报文段发送出去。
>  *  第二种机制是由发送方的应用进程指明要求发送报文段，即 TCP 支持的推送(push)操作。
>  *  第三种机制是发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不能超过 MSS）发送出去。

### TCP滑动窗口具体结构 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 3]

# 3. TCP流量控制和拥塞控制 #

通过以上的基础知识的掌握，下面我们就可以来讲解TCP是如何做到流量控制和拥塞控制的。

## 3.1 TCP的流量控制 ##

所谓的流量控制就是让发送方的发送速率不要太快，让接收方来得及接受。利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。TCP的窗口单位是字节，不是报文段，发送方的发送窗口不能超过接收方给出的接收窗口的数值。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 4]

如图所示，说明了利用可变窗口大小进行流量控制。设主机A向主机B发送数据。双方确定的窗口值是400.再设每一个报文段为100字节长，序号的初始值为seq=1,图中的箭头上面大写ACK，表示首部中的却认为为ACK，小写ack表示确认字段的值。

接收方的主机B进行了三次流量控制。第一次把窗口设置为rwind=300，第二次减小到rwind=100最后减到rwind=0，即不允许发送方再发送过数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。

假如，B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwind=400的报文段，然而这个报文段在传送中丢失 了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。这样就死锁了。为了解决这种死锁状态，TCP为每个连接设有一个持续计时器。只 要TCP连接的一方收到对方的零窗口通知，就启动持续计时器，若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。

**在TCP的ACK超时重传，大部分实现都是重传所有未被确认的数据块。**

### TCP报文段发送时机的选择 ###

TCP报文段发送时机主要有以下几种选择途径。

*  1）TCP维持一个变量，它等于最大报文段长度MSS，只要缓存中存放的数据达到MSS字节就组装成一个TCP报文段发送出去。
 *  2）由发送方的应用程序指明要求发送报文段，即TCP支持的推送操作
 *  3）是发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段发送出去。

## 3.2 TCP的拥塞控制 ##

### 3.2.1 拥塞控制的原理 ###

**在某段时间，若对网络中的某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变化，这种情况叫做拥塞**网络拥塞往往是由许多因素引起的，简单的提高节点处理机的速度或者扩大结点缓存的存储空间并不能解决拥塞问题。**拥塞问题的是指往往是整个系统的各个部分不匹配，只有各个部分平衡了，问题才会得到解决**

### 3.2.2 拥塞控制和流量控制的差别 ###

**所谓拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载**拥塞控制所要做的都有一个前提，就是网络能承受现有的网络负荷。拥塞问题是一个全局性的问题,涉及到所有的主机、所有的路由器、以及与降低网络传输性能有关的所有因素。**流量控制往往指的是点对点通信量的控制，是个端到端的问题**流量控制所要做的就是控制发送端发送数据的速率，以便使接收端来得及接受。

### 3.2.3 拥塞控制设计 ###

拥塞控制是很难设计的，因为它是一个动态的问题，许多情况下，甚至正是拥塞控制机制本身成为引起网络性能恶化甚至死锁的原因。从控制理论的角度来看拥塞控制这个问题，可以分为开环控制和闭环控制两种方法。开环控制就是在设计网络时事先将有关拥塞发生的所有因素考虑周到，一旦系统运行起来就不能在中途改正。

闭环控制是基于反馈环路的概念，包括如下措施：

>  *  1）监测网路系统以便检测拥塞在何时、何地发生
>  *  2）把拥塞发生的信息传送到可采取行动的地方
>  *  3）调整网络系统的行动以解决出现的问题。

### 3.2.4 拥塞控制方法 ###

因特网建议标准RFC2581定义了进行拥塞控制的四种算法，即慢开始（Slow-start)、拥塞避免（Congestion Avoidance)、快重传（Fast Restrangsmit)和快回复（Fast Recovery）。我们假定

>  *  1）数据是单方向传送，而另外一个方向只传送确认
>  *  2）接收方总是有足够大的缓存空间，因为发送窗口的大小由网络的拥塞程度来决定。

### 慢开始和拥塞避免 ###

发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口，另外考虑到接受方的接收能力，发送窗口可能小于拥塞窗口。**发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就增大一些，以便把更多的分组发送出去。但是只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络的分组数**

慢开始算法的思路就是：最初的TCP在连接建立成功后会向网络中发送大量的数据包，这样很容易导致网络中路由器缓存空间耗尽，从而发生拥塞。因此**新建立的连接不能够一开始就大量发送数据包，而只能根据网络情况逐步增加每次发送的数据量，以避免上述现象的发生。具体来说，当新建连接时，cwnd初始化为1个最大报文段(MSS)大小，发送端开始按照拥塞窗口大小发送数据，每当有一个报文段被确认，cwnd就增加至多1个MSS大小。用这样的方法来逐步增大拥塞窗口CWND**

> 最大报文段长度MSS选项是TCP协议定义的一个选项，MSS选项用于在TCP连接建立时，收发双方协商通信时每一个报文段所能承载的最大数据长度。

这里用报文段的个数的拥塞窗口大小举例说明慢开始算法，实时拥塞窗口大小是以字节为单位的。如下图：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 5]

为了防止cwnd增长过大引起网络拥塞，还需设置一个慢开始门限ssthresh状态变量。ssthresh的用法如下：

>  *  当cwnd<ssthresh时，使用慢开始算法。
>  *  当cwnd>ssthresh时，改用拥塞避免算法。
>  *  当cwnd=ssthresh时，慢开始与拥塞避免算法任意。

拥塞避免算法思路：**让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口按线性规律缓慢增长**

**无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，所以都当做拥塞来处理），就把慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕**

如下图：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 6]

### 乘法减小和加法增大 ###

乘法减小：是指不论在慢开始阶段还是拥塞避免阶段，只要出现超时，就把慢开始门限sshresh减半，即设置为当前的拥塞窗口的一半（于此同时，执行慢开始算法）。当网络出现频繁拥塞时，ssthresh值就下降的很快，以大大将小注入到网络中的分组数。

加法增大：是指执行拥塞避免算法后是拥塞窗口缓慢增大，以防止网络过早出现拥塞。

### 快重传和快恢复 ###

一条TCP连接有时会因等待重传计时器的超时而空闲较长的时间，慢开始和拥塞避免无法很好的解决这类问题，因此提出了快重传和快恢复的拥塞控制方法。**快重传算法并非取消了重传机制，只是在某些情况下更早的重传丢失的报文段（如果当发送端接收到三个重复的确认ACK时，则断定分组丢失，立即重传丢失的报文段，而不必等待重传计时器超时）**

快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。**快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期** 如下图：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 7]

快重传配合使用的还有快恢复算法，有以下两个要点:

> 1.  当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半。但是接下去并不执行慢开始算法。
> 2.  考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh减半后的大小，然后执行拥塞避免算法。如下图：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 8]

**在采用快恢复算法时，慢开始算法只是在TCP连接建立时和网络出现超时时才使用**

接受窗口又称为通知窗口(rwnd)。因此从接收方对发送方的流量控制角度考虑，发送方的发送窗口一定不能超过对方给出的接受窗口的RWND。

也就是说：发送窗口的上限=Min\[rwnd,cwnd\].

### 随机早期检测RED ###

以上的拥塞避免算法并没有和网络层联系起来，实际上网络层的策略对拥塞避免算法影响最大的就是路由器的丢弃策略。在简单的情况下路由器通常按照先进先出的策略处理到来的分组。当路由器的缓存装不下分组的时候就丢弃到来的分组，这叫做尾部丢弃策略。这样就会导致分组丢失，发送方认为网络产生拥塞。更为严重的是网络中存在很多的TCP连接，这些连接中的报文段通常是复用路由路径。**若发生路由器的尾部丢弃，可能影响到很多条TCP连接，结果就是这许多的TCP连接在同一时间进入慢开始状态。这在术语中称为全局同步。全局同步会使得网络的通信量突然下降很多，而在网络恢复正常之后，其通信量又突然增大很多**

为避免发生网路中的全局同步现象，路由器采用随机早期检测(RED:randomearly detection)。该算法要点如下：

使路由器的队列维持两个参数，即队列长队最小门限min和最大门限max，每当一个分组到达的时候，RED就计算平均队列长度。然后分情况对待到来的分组：

> 1.  平均队列长度小于最小门限——把新到达的分组放入队列排队。
> 2.  平均队列长度在最小门限与最大门限之间——则按照某一概率将分组丢弃。
> 3.  平均队列长度大于最大门限——丢弃新到达的分组。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 9]

**RED不是等到已经发生拥塞后才把所有队列尾部的分组全部丢弃，而是在检测到网络拥塞的早期征兆时（即路由器的平均队列长度超过一定门限值时），以概率p随机丢弃分组，让拥塞控制只在个别的TCP连接上执行，因而避免全局性的拥塞控制**

RED的关键就是选择三个参数最小门限、最大门限、丢弃概率和计算平均队列长度。最小门线必须足够大，以保证路由器的输出链路有较高的利用率。而最大门限和最小门限只差也应该足够大，是的在一个TCP往返时间RTT中队列的正常增长仍在最大门限之内。经验证明：使最大门限等于最小门限的二倍是合适的。

![xxx][]

**平均队列长度采用加权平均的方法计算平均队列长度，这和往返时间（RTT）的计算策略是一样的**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 10]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70]: /images/20220326/87c14d75b80e49bc977e67c551230ebc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 1]: /images/20220326/858a50342b2843988a668907f1ce1136.png
[2019011710064292.png]: /images/20220326/8c76038b120447e6af54e1aa35b72b72.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 2]: /images/20220326/9cac64ecee404f39b24c2dd3c716447d.png
[20190117100700116.png]: /images/20220326/1e96a8555bba4d06a2bf69f2ce57f9a6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 3]: /images/20220326/d4572fb618d448cf9e3a3426fedd4d14.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 4]: /images/20220326/0d30de81226e4926a577f51ba9131a4b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 5]: /images/20220326/c6682b89d09a48a68d82efcefce3b9fa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 6]: /images/20220326/0209fb67bdde40ba8b93882b7d628f74.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 7]: /images/20220326/555f38a30c8b40fd8884e7838ef30133.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 8]: /images/20220326/436eddabd8084be89ba6b642b96f0fdf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 9]: /images/20220326/b34c2baca5be4ffa9d73a10af6df1534.png
[xxx]: /images/20220326/f54bc5af30994e3f99d570fdf2cfe290.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 10]: /images/20220326/76283596a406411a9cb4fa15c4b5ea38.png