运输层 之 流量控制 与 拥塞控制

每篇一句：成熟的稻子，往往会低下它那高贵的头。  ——《洛克菲勒留给儿子的38封信》

 

TCP 流量控制

利用滑动窗口实现流量控制

流量控制 就是让发送方的发送效率不要太快，要让接收方来得及接收

利用滑动窗口机制可以方便地在 TCP 连接上实现对发送方的流量控制。下面举例说明如何进行流量控制

设 A 向 B 发送数据。在连接建立，接收方会告诉发送方接收窗口的大小，因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。

在图中，接收方的主机 B 进行了三次流量控制，第一次把窗口减小到 rwnd = 300, 第二次又减到 rwnd = 100，最后减到 rwnd = 0，即不允许发送方再发送数据了

如果 B 向 A 发送了零窗口的报文段后不久，B 的接收缓存又有了一段存储空间，于是 B 向 A 发送了 rwnd = 400 的报文段，然而这个报文段在传送过程中丢失了，A 一直等待收到 B 发送的非零窗口的通知，而 B 也一直等待 A 发送的数据，就造成了 互相等待的死锁局面

TCP 为每一个连接设有一个 持续计时器。只要 TCP 连接的一方收到对方的零窗口通知，就启动持续计时器。若设置的时间到了，就发送一个零窗口探测报文段，而对方在确认这个探测报文段时给出了现在的窗口值。如果为零，就重新设置持续计时器，如果不是，那么死锁的僵局也就打破了

 

TCP 的传输效率

使用不同的机制来控制 TCP 报文段的发送时机。有三种机制：

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

第一个问题：如何控制 TCP 发送报文段的时机？

有时，用户仅发送一个字符，但线路上却需要很长的报文段，当线路宽带并不宽裕时，这种传送方法效率就不高。因此，应适当推迟发回确认报文，并尽量捎带确认的方法

可以使用 Nagle 算法。算法如下：

• 若发送应用进程把要发送的数据逐个字节地送到 TCP 的发送缓存，则发送方就把第一个数据字节先发送出去，把后面的数据都缓存起来。
• 当发送方收到第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对随后到达的数据进行缓存。
• 只有在收到对前一个报文段的确认后才继续发送下一个报文段。
• 还有，当数据到达的已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。

第二个问题：糊涂窗口综合症

有时，TCP 接收方的缓存已满，而交互式应用进程一次只能从接收缓存中读取 1 个字节，然后向发送方发送确认，并把窗口设置为 1 个字节。接着，发送方又发来 1 个字节的数据。接收方发回确认，仍然将窗口设置为 1 个字节，如此，网络效率很低。

可以让接收方等待一段时间，如果接受缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半的空闲空间时，接收方就发出确认报文，并向发送方通知当前的窗口大小。此外，发送方也不要发送太小的报文段，而是把数据积累成足够大的报文段，或达到接收方缓存的空间的一半大小。

 

TCP 拥塞控制

拥塞控制的一般原理

在某段时间中，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就会变坏，这种情况叫做 拥塞。写成关系式：

Σ对资源的需求 > 可用资源

网络拥塞往往是由很多因素引起的。例如：

• 结点缓存的存储空间太小
• 链路传输速率太低
• 结点处理机的运算速度太低

但是若简单地增大结点缓存的存储空间，或将链路转换为更高速率的链路，或提高结点处理机的运算速度。不但不能解决问题，还会使网络性能更坏。

例如，当某个结点缓存的容量太小时，到达该结点的分组因无存储空间而被丢弃，但是若只将结点容量增大，于是凡是到达该结点的分组均在结点的缓存队列中排队。由于其他方面并未改善，未被及时处理，就会因为超时而进行重传，这样就会造成网络资源的严重浪费

拥塞控制 与 流量控制 的区别

拥塞控制 是 防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。它所要做的一个前提就是，网络能够承受现有的网路负荷。并且它是一个 全局性的过程，涉及到所有的主机. 所有的路由器，以及与降低网络传输性能有关的所有因素。

流量控制 往往是指 点对点通信量的控制，是个 端到端 ( 接收端控制发送端 ) 的问题。流量控制要做的是控制发送端发送数据的速率，以便使接收端来得及接收。

进行拥塞控制需要付出代价：

• 首先需要获得网络内部流量分布的信息。
• 在实施拥塞控制时，需要在结点之间交换信息和各种命令，以便选择控制的策略和实施控制。
• 有时还需要将一些资源分配给个别用户单独使用

所以，设计拥塞控制策略时，必须全面衡量得失

如图，横坐标是 提供的负载，代表单位时间内输入给网络的分组数目。纵坐标是 吞吐量，代表单位时间内从网络输出的分组数组。

具有理想拥塞控制的网络，在吞吐量饱和之前，网络吞吐量等于提供的负载。但是提供的负载超过一定限度时，吞吐量不再增长而达到饱和。这就表明提供的负载中一部分肯定丢失掉了

但是实际上，随着提供的负载的增大，网络吞吐量的增长速率逐渐减小。当网络吞吐量明显小于理想的吞吐量时，网络就进入了轻度拥塞状态。当达到某个数值时，网络的吞吐量反而会下降，进入了拥塞状态。甚至会下降到零，造成死锁局面

设计拥塞控制，可以分为 开环控制 和 闭环控制 两种方法。

开环控制 是在设计网络时事先将有关发生拥塞的因素考虑周到，力求网络在工作时不产生拥塞。但一旦整个系统运行起来，就不在中途进行改正

闭环控制 是基于反馈环路的概念，主要有以下几种措施：

• 监测网络系统以便检测到拥塞在何时. 何处发生
• 把拥塞发生的信息传送到可采取行动的地方
• 调整网络系统的运行以解决出现的问题

可以通过检测 由于缺少缓存空间而被丢弃的分组的百分数. 平均队列长度. 超时重传的分组数. 平均分组时延等 来检测网络的拥塞。

一般在检测到拥塞发生时，要将拥塞发生的信息传送到产生分组的源站。或者在路由器转发的分组中保留一个比特或字段，用该比特表示是否发生拥塞。也可以由一些主机或路由器周期性地发出探测分组，以询问是否发生拥塞

 

拥塞控制的方法

拥塞控制的算法有四种：慢开始. 拥塞避免. 快重传 和 快恢复。
这里假定：

• 数据是单方向传送的，对方只传送确认报文
• 接收方总是有足够大的缓存空间，因而发送窗口的大小由网络的拥塞程度类决定

1.慢开始

发送方维持一个叫做 拥塞窗口 cwnd ( congestion window ) 的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地变化。发送方让自己的发送窗口等于拥塞窗口。

发送方控制拥塞的原则是：只要网络没有出现拥塞，拥塞窗口就可以再增大一些，以便把更多的分组发送出去，这样可以提高网络的利用率。但只要网络出现拥塞或有可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，以便缓解网络出现的拥塞。

而判断网络拥塞的依据就是出现了超时。

慢开始算法的思路：先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。

新的规定把初始窗口 cwnd 设置为不超过 2 至 4 个 SMSS 的数值。具体规定如下：

• 若 SMSS > 2190 字节，则设置初始窗口 cwnd = 2 * SMSS 字节，且不得超过 2 个报文段
• 若 ( SMSS > 1095 个字节 ) 且 ( SMSS <= 2190 字节 )，则设置初始窗口 cwnd = 3 * SMSS 个字节，且不得超过 3 个字节段
• 若 SMSS <= 1095 个字节，则设置初始拥塞窗口 cwnd = 4 * SMSS 字节，且不得超过 4 个报文段

可见这个规定就是限制初始拥塞窗口的字节数。

慢开始固定，在每收到一个对新的报文段的确认后，可以把拥塞窗口增加最多一个 SMSS 的数值。就是

拥塞窗口 cwnd 每次的增加量 = min( N, SMSS )

其中 N 是原先未被确认的. 但现在被刚收到的确认报文段所确认的字节数。

慢开始的 “慢” 并不是指 cwnd 的增长速率慢，而是指在 TCP 开始发送报文段时先设置 cwnd = 1，使得发送方开始时只发送一个报文段，然后再逐渐增大 cwnd。这比直接设置大的 cwnd 的值要 “慢得多”，可以有效地防止网络拥塞

在实际运行中，发送方只要收到一个对新报文段的确认，其拥塞窗口 cwnd 就立即加 1，并可以立即发送新的报文段，而不需要等这个轮次中所有的确认都收到后再发送新的报文段。

2.拥塞避免

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

• 当 cwnd < ssthresh 时，使用满开始算法
• 当 cwnd > ssthresh 时，停止使用满开始算法而改用拥塞避免算法
• 当 cwnd = ssthresh 时，两者都可使用

拥塞避免 算法的思路：让拥塞窗口 cwnd 缓慢地增大，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是像慢开始算法那样加倍增长。

3.快重传

有时，个别报文段会在网络中丢失，但实际上并未发生拥塞。如果发送方迟迟收不到确认，就会产生超时，就会误认为网络发生了拥塞。这就导致发送方错误地启动慢开始算法，把拥塞窗口又设置为 1，因而降低了传输效率

采用快重传算法可以让发送方 尽早知道发生了个别报文段的丢失。快重传算法首先要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即时收到了失序的报文段也要立即对已收到的报文段的重复确认。

还规定，发送方只要一连收到 3 个重复确认，就知道接收方确认没有收到此报文段，因而立即进行重传，这样就不会出现重传，发送方也就不会误认为出现了网络拥塞。

4.快恢复

对于发送方知道只是丢失了个别的报文段，不会启动慢开始算法，而是执行 快恢复 算法。

发送方会调整门限值 ssthresh = cwnd / 2 ，同时设置拥塞窗口 cwnd = ssthresh，并开始执行拥塞避免算法。

 
在拥塞避免阶段，拥塞窗口是按照现行规律增大的，这常称为加法增大 AI ( Additive Increase)。而一旦出现超过或 3 个重复的确认，就要把门限值设置为当时拥塞窗口值的一半，并大大减小拥塞窗口的数值，这常被称为 “乘法减小” MD。二者合在一起就是所谓的 AIMD 算法。

 
TCP 的拥塞控制可以归纳为如图所示

实际上接收方的缓存空间是有限的，接收方根据自己的接受能力设定接收方窗口 rwnd，并把这个窗口值写入 TCP 首部中的窗口字段，传送给发送方。

如果把拥塞机制和接收方对发送方的流量控制一起考虑，发送方的窗口的上限值应当取为接收方窗口 rwnd 和拥塞窗口 cwnd 两个变量中较小的一个：

发送方窗口的上限值 = Min [rwnd, cwnd]

也就是说，rwnd 和 cwnd 中数值较小的一个，决定了发送方发送数据的速率

 

主动队列管理 AQM

网络层的策略对 TCP 的拥塞控制影响最大的是 路由器的分组丢弃策略。一般，路由器的队列通常都是 “先进先出” FIFO 的规则处理到来的分组。由于队列长度有限，当队列已满时，以后到达的分组会被丢弃。这就叫做 尾部丢弃策略。

路由器的尾部丢弃往往会导致一连串分组的丢失，这就使发送方出现超时重传，使 TCP 进入拥塞控制的慢开始状态，使数据发送率大大降低。通常网络中有很多 TCP 连接，并且报文段复用在网络层的 IP 数据报中传送。如果发生路由器的尾部丢弃，就可能影响多条 TCP 连接，使许多 TCP 连接在同一时间突然进入到慢开始状态。这叫做 全局同步。

为避免 全局同步现象，提出了 主动队列管理 AQM。”主动” 就是不要等到路由器的队列长度已经达到最大值时才不得不丢弃后面到达的分组。而是 在队列长度达到某个值得警惕的数值 时，就丢弃到达的分组，以提醒发送方放慢发送速率。

AQM 可有多种实现方法，比如 随机早期检测 RED。实现 RED 时需要两个参数，即队列长度最小门限和最大门限。当每一个分组到达时，RED 就按照规定的算法先计算当前的平均队列长度。

• 若平均对列长度小于最小门限，则把新到达的分组放入队列进行排队
• 若平均队列长度超多最大门限，则把新到达的分组丢弃
• 若平均对列长度在最小门限和最大门限之间，则按照某一丢弃概率 p 把新到达的分组丢弃

RED 在检测到网络拥塞的 早期前兆 时 ( 即路由器的平均队列长度达到一定数值时 )，就以概率 p 丢弃个别分组，让拥塞控制只在个别的 TCP 连接上进行，而避免发生全局性的拥塞控制。

 

写在最后

如果有任何问题，欢迎交流学习。