数据链路层流量控制与传输层流量控制对比

一.数据链路层

1.停止等待协议

无差错情况：

有差错情况：

2.滑动窗口协议

（1）后退N帧协议（GBN）

（2）选择重传协议（SR）

二.传输层

1.传输层的可靠传输

1.校验

2.序号

3.重传

2.传输层的流量控制

3.TCP的拥塞控制

慢开始和拥塞控制：

快重传和快恢复：

一.数据链路层

流量控制就是使接收方有足够的缓冲空间来接收每一个帧。

其实停止等待协议也包含滑动窗口机制，只是其比较特殊，发送端和接收端窗口大小都为1，下面会讲，也就是以上协议都用到了滑动窗口机制，那么滑动窗口机制解决了什么问题呢

1.流量控制（收不下就不给确认，想发也发不了）

2.可靠传输（发送方自动重传）

注：在有些教材中，这些协议在数据链路层，一些教材中，这些协议在传输层，但是我们其实不需要纠结它们具体在哪一层，因为在计算机网络发展的前期，通信链路质量不好，所以链路层需要担负起可靠传输的职责，所以链路层需要使用停止等待协议，滑动窗口协议，但随着网络质量的发展，出现差错的可能性下降，因此数据链路层不需要担负起可靠传输的职责，可靠传输的职责交给传输层，数据链路层只需要进行流量控制。

所以在传输层还是数据链路层只是对象不同而已，在数据链路层传输的数据为帧，在传输层传输的数据就是分组。这里我们使用帧来说明协议的原理，同时我们要注意虽然现在常用全双工通信方式，但为了讨论问题方便，仅考虑一方发送数据(发送方)，一方接收数据(接收方)。

1.停止等待协议

发送完一个帧就停止发送，等待对方的确认，在收到确认后再发送下一个帧。

发送窗口大小>1,接收窗口大小=1

使用停止等待协议的原因：

1.除了比特出差错，底层信道还会出现丢包问题（丢包:物理线路故障、设备故障、病毒攻击、路由信息错误等原因，会导致数据包的丢失）。

2.为了实现流量控制。

无差错情况：

每个数据帧都会进行编号，因为每发送1个数据帧就停止并等待,因此用1bit来编号就够。

有差错情况：

（1）发送端发送的数据帧出错情况有两种：帧出错和帧丢失，若接收方没有接收到帧（帧丢失），那么发送方不会返回确认帧，若接收方收到错误数据帧，就会丢弃该帧，发送方也不会收到确认。

超时计时器：每次发送一个帧就启动一个计时器

超时计时器设置的重传时间应当比帧传输的平均RTT（往返传播时延）更长一些。若超时就会重传没有收到确认的帧。从这里我们可以看到:

1.发送方发完一个帧后，必须保留它的副本，这样，如果没有收到确认帧，就发送副本。

2.数据帧和确认帧必须编号，如果发送端出现了相同编号的数据帧，也就是发送端进行了超时重传。如果接收方接收到相同的帧，就表示接收方接收到了重复的帧，将其丢弃。这就解决了帧丢失，重复的问题。

以下为帧丢失的情况：

（2）接收端发送的ACK帧丢失:

由于发送端没有收到帧，那么进行重传帧，接收端收到重复的帧时，丢弃重复的帧，并且重新发送对于该帧的确认。

（3）ACK迟到

以下图为例，接收端发送0帧，超过计时器时间，未收到确认帧，那么重传0帧，接收方本来已经收到0帧，只是确认帧迟到了，所以它会丢弃重复的0帧，重传确认帧，那么发送方收到之前迟到的确认帧时，发现收到了重复的确认帧，那么就会丢弃。

停止等待协议的缺点就是信道利用率很低：

发送方在一个发送周期内，有效地发送数据所需要的时间占整个发送周期的比率。

信道利用率=（L/C）/T

T表示发送周期：从开始发送给数据，到收到第一个确认帧为止。

L表示T内发送L比特数据

C表示发送方数据传输率

信道吞吐率=信道利用率*发送方的发送速率

注：因为这里没有收到确认帧的时间，所以只需要将发送时延+往返传输时延就可以了

2.滑动窗口协议

停止等待协议也可以算作特殊的滑动窗口，因为停止等待协议中发送和接收的滑动窗口为1。由于停等协议利用率太低，那么我们可以连续发送多个帧（流水线技术），这样可以增加信道利用率。

由于需要发送多个帧，所以：
1.必须增加序号的范围。

2.发送方需要缓存多个分组（在停止等待协议中，发送方只需要缓存刚刚发送的一个帧，而这里连续发送多个帧，就要对多个帧进行缓存）

（1）后退N帧协议（GBN）

发送窗口大小>1,接收窗口大小=1

工作流程：

发送窗口:发送方维持一组连续的允许发送的帧的序号。

发送窗口有6个，接收端窗口有1个，此时发送窗口发送0号帧，1号帧....，即发送窗口中的帧。

接收端收到0号帧后，会给发送窗口一个确认帧，并且向前移动1位

接收端收到确认帧后，发送窗口也会向前移动

这里接收方不用每次都发送确认帧，例如发送确认帧（ACK3），就表示3以及前面的帧都正确接收了，那么发送方窗口往前移动到4即可。

发送端窗口如红框所示：

接收端窗口如红框所示：

可以看到，在发送窗口有4类帧：

1.发完被确认的帧

2.已经发送但等待确认的帧

3.还能发送的帧

4.还不能发的帧

设接收端没有收到0号帧，那么就不会发送0号帧的确认，即使发送方再发送1号帧，接收端也会直接丢弃，因为此时接收端想收到0号帧，若没有收到确认帧，即出现超时，发送方重传所有已发送但未被确认的帧（也就是0号帧开始，已发送并且没有被确认的帧）

在这一流程中，着重看接收方做了什么：

1.如果正确收到n号帧，并且按序，那么接收方为n帧发送一个ACK，并将该帧中的数据部分交付给上层。

2.其余情况都丢弃帧，并为最近按序接收的帧重新发送ACK（例如最近按序发送的帧为ACK2，那么发送方就知道0~2号帧都正确接收，则会重发2号帧后面所有的帧）。接收方无需缓存任何失序帧，只需要维护一个信息: expectedseqnum (下一个按序接收的帧序号)

完整流程如下，假设发送窗口尺寸为4：

滑动窗口可以提高信道利用率，那么滑动窗口可以无限大吗：

不能，若采用n个比特对帧编号，那么发送窗口的尺寸W应满足:1<=W<=(2^n)-1。因为发送窗口尺寸过大，就会使得接收方无法区别新帧和旧帧。

例如：采用2个比特对帧编号，也就是2^2=4,4个不同编号0~3，那么发送窗口的尺寸最大为3

如果从0开始就未接收到确认帧，那么如果超过0帧的超时计时器，发送方就会发送0，1，2，接收端累积确认后，发送方下一组会继续发送3，0，1

如果发送窗口为4，从0开始就未接收到确认帧，那么如果超过0帧的超时计时器，发送方就会发送0，1，2，3，接收端累积确认后，发送方下一组发送0，1，2，3，编号和之前一样，那么接收方就无法判断是重复的帧丢弃，还是新的帧接收。

GBN协议的重点：

1.累积确认(偶尔捎带确认)：捎带确认就是接收端要发送数据给发送端时，顺便把确认帧带上
2.接收方只按顺序接收顿，不按序无情丢弃

3.确认序列号是最大的、按序到达的帧
4.发送窗口最大为2^n-1，接收窗口大小为1

例题1：数据链路层采用了后退N帧(GBN)协议，发送方已经发送了编号为0~7的。当计时器超时时，若发送方只收到0、2、3号帧的确认，则发送方需要重发的帧数是(4)。

我们只需要看最大需要的确认帧即可，所以发送方需要重发的帧数为4

例题2：主机甲与主机乙之间使用后退N帧协议(GBN)传输数据，甲的发送窗口尺寸为1000，数据长为1000字节信道带宽为100Mb/s，每收到一个数据立即利用一个短帧(忽略其传输延迟)进行确认，若甲、乙之间的单向传播时延是50ms，则甲可以达到的最大平均数据传输率约为()

A.10Mb/s B.20Mb/s C.80Mb/s D.100Mb/s

甲把自己窗口的数据全部发送出去需要的时间：

1000*1000*8（换算成bit）/100*10^6=80ms

往返的传播时延：

2*50ms=100ms

甲发送第一个数据帧到收到确认帧的时间：

100+1000*8 b/100*10^6 b/s=100.08ms

往返传播时延+甲发送第一个帧的传输时延

所以结合80ms和100.08ms的数据，我们可以看到，甲发送完自己窗口的所有数据后，还不能收到确认帧，还需要等20ms左右的时间，才能收到确认帧，收到确认帧发送窗口才能往前移动。
接下来的流程就是重复以上流程：

所以，甲可以到达的平均数据传输率约为：

1000*1000*8(帧数)/100.08ms(甲发送一个数据帧到收到确认帧所需时间) = 80Mb/s

GBN协议的优点：因连续发送数据帧而提高了信道利用率。

GBN协议的缺点：在重传时必须把原来已经正确传送的数据帧重传，是传送效率降低。

（2）选择重传协议（SR）

发送窗口大小>1,接收窗口大小>1

因为GBN协议中存在累积确认，所以若发送帧出错，就会出现批量重传的问题。

那么解决方法就是设置单个确认，同时加大接收窗口，设置接收缓存，缓存乱序到达的帧。

对于发送方而言有以下帧类型：

1.发完被确认的帧

2.已经发送但等待确认的帧，如下图的2，4帧，这里已经发送但等待确认的帧，可能是已经丢失了，或者是确认帧丢失的帧

3.发完被确认的帧

4.还能发送的帧

5.还不能发送的帧

对于接收方而言有以下帧类型：

1.希望收到但没收到的帧

2.收到且确认的帧（缓存），例如这里的6号帧就是缓存，缓存即暂时存放5号帧，等接收到5号帧后，一起上交到网络层，然后接收端的滑动窗口向前移动2格

3.等待接收的帧

4.1~7号帧表示还不能接收的帧

5.最前面的0~4号帧表示已经接受完并且返回确认的帧（注：这里是返回确认的帧，而不是发送方接收的帧，也就是可能丢失确认帧）

发送方需要做的事情如下：

1.上层的调用：
从上层收到数据后，SR发送方检查下一个可用于该帧的序号，如果序号位于发送窗口内，则发送数据帧；否则就像GBN一样，要么将数据缓存，要么返回给上层之后再传输。

2.收到一个ACK：

如果收到ACK，假如该帧序号在窗口内，则SR发送方将那个被确认的帧标记为已接收。如果该帧序号是窗口的下界(最左边第一个窗口对应的序号)，则窗口向前移动到具有最小序号的未确认帧处。如果窗口移动了，并且有序号在窗口内的未发送帧，则发送这些帧，例如5号帧。

3.超时事件：

每个帧都有自己的定时器，一个超时事件发生后只重传一个帧

接收方需要做的事情如下：

1.SR接收方将确认一个正确接收的帧而不管其是否按序。失序的帧将被缓存，并返回给发送方一个该帧的确认帧[收谁确认谁]，直到所有(即序号更小的帧)皆被收到为止，这时才可以将一批帧按序交付给上层，然后向前移动滑动窗口。

如果收到了窗口序号外的帧，就返回一个ACK，例如收到0号帧前的7号帧，这时可能是之前的数据帧（4~7）返回了确认帧，但是确认帧丢失了，所以就返回一个ACK7，告诉发送方7以及7之前的帧都已正确接收了

那么SR的运行流程：

假设接收窗口和发送窗口尺寸都为4

正常发送并且正常接收

2号帧发送时丢失了，当发送方发送3号帧时，接收方返回对于3号帧的确认，但是是缓存3号帧，并且不移动接收端的滑动窗口

当2号帧超时，即2号帧在超时时间内没有收到确认帧，那么就会重传2帧，在接收端接收2帧，那么此时2-5号帧都接收完毕，并返回确认帧，2-5号帧交付。

这里发送方接收到3号帧，并不会移动滑动窗口，因为还没有接收到2号帧，在3后的4，5还没有需要发送的帧，若有需要发送的数据帧，则放到4，5处。

对于窗口长度可以是无限的吗，举个例子，存在以下两种情况：

第一种情况：

发送方发送0号帧，接收端发送确认帧，并向前移动，1，2帧同理，但是3个确认帧全部丢失，当0号帧超时后，重传0号帧，那么接收端接收的就是超时重传的0号帧。

第二种情况：

以下情况发送端在接收到0号帧的确认后，就向前移动发送窗口，现在还有3号帧可以发送，因为1，2帧已经发送，但没有收到确认帧：

但是3号帧在发送过程丢失：

当发送方收到2号帧的确认帧，就会向前移动，这时发送方可以发送0号帧，这时发送的0号帧是新帧

以上两种情况：接收端接收到发送端的帧都是0，1，2，0：但是一个是重传的0号帧，一个是新的0号帧。

那么应该如何设置呢？

1.发送窗口最好等于接收窗口,若发送窗口过大，接收方来不及接收，造成溢出，若接收窗口过大，则降低传输效率。

其中的n是根据多少比特标序号，对于以上例子0~3（4个），n=2，那么最大窗口应该是2，而这里的窗口大小为3已经超过了最大窗口，所以会出错。

那么我们以2个窗口试一下：

若0帧超时，发送方重发0帧，但是此时接收端窗口为2，3，说明之前已经正确接收了0帧，只是确认帧丢失了，此时接收到的0帧就是重传的帧

SR协议重点：

1.对数据帧逐一确认，收一个确认一个
2.只重传出错帧
3.接收方有缓存

4.

例题1：数据链路层采用了选择重传(SR)协议，发送方已经发送了编号为0~3的现已收到1号帧的确认，而0、2号帧依次超时，则发送方需要重传的帧数是(2)
A.2 B.3 C.4 D.5

需要重新发送0、2号帧

二.传输层

1.传输层的可靠传输

传输层的可靠传输主要通过TCP协议，TCP实现可靠传输一共有4种机制：

1.校验

这里的校验于UDP校验一样，即增加伪首部：

详解·UDP的伪首部 - 知乎 (zhihu.com)

2.序号

TCP的传输是面向字节流的，传输的时候以字节为单位，所以在TCP传输时，会给每个字节编号，但在实际发送时，会把许多字节放在一起组成一个个报文段，报文段的划分则需取决于链路层的MTU（最大传输单元），若不知道报文段如何划分可以看：

http://t.csdnimg.cn/djumm

如上图所示，一个字节占一个序号，TCP格式中的序号字段指的是一个报文段第一个字节的序号。例如，对于1，2，3的报文段，那么他的序号就是1

首先发送第一个报文段，但是在发送端还是会保留这一报文段，若此报文丢失，发送方就会重传此报文段，直到接收方告诉发送方已经正确地，完整地收到此报文段（接收方可以发送只起确认作用的报文段，也可以在需要发其他数据给发送端时捎带确认）。

如下图所示：

1.接收端收到回复的确认帧中，报文段首部确认字段为4，也就表示：

接收端已经正确的接收到了4之前的报文段，期待收到序号为4的报文段

2.发送端收到确认报文段，就会删除这个报文端

3.此时传输4，5，6时报文段丢失，而是接收到了7，8报文段，因为TCP默认使用累计确认，当接收端收到7，8报文段也会接收，但是发送的确认报文仍然是序号4，表示我想要接收的是序号为4的报文段。

4.发送方接收到这一确认报文段，就知道接收方没有正确收到4，5，6的报文段，那么就会重传该报文段。

5.此时已正确接收1~8字节，那么接下来接收端发送的确认报文段序号为9，表示前面的报文段都已正确接收，接下来想要接收9报文段。

3.重传

确认重传不分家，TCP的发送方在规定的时间内没有收到确认就要重传已发送的报文段。也就是超时重传。

这里的重传时间若设置过短，会导致传播时间过长的报文段，还没有发送完成就已超时，进行重传。若重传时间过长，会使网络空闲时间过大，降低传输效率。

TCP采用自适应的算法，动态改变重传时间RTTs(加权平均往返时间)

这个算法可以通俗理解为，首先我们计算第一个报文段发送的往返时间（RTT）,发送第二个报文段时会得出一个RTT，这样两个RTT就能计算得到一个RTTs，接着加入第三个，第四个报文段也是这样。这个RTTs是与每个报文段的RTT相关联的，能够很好的确定超时重传时间。

能不能让发送方在超时事件发生前，就知道是否丢失此报文段

可以使用冗余确认（冗余ACK）的方式，也就是每当比期望序号大的失序报文段到达时，发送一个冗余ACK，指明下一个期待字节的序号。例如：

注：TCP的可靠传输可以使用GBN协议，SR协议，而不使用停等协议，一次性可以发送多个报文段，这里的原理和数据链路层相同。而接收端可以使用累计确认。

2.传输层的流量控制

传输层的流量控制与数据链路层的流量控制不同：

1.数据链路层的流量控制是点对点的，而传输层的流量控制是端到端的

2.数据链路层流量控制手段：接收方收不下就不回复确认。传输层流量控制手段: 接收端给发送端一个窗口公告(告诉发送端缓冲区还剩余多少，让缓冲区控制传输帧的速度)。

在通信过程中，接收方根据自己接收缓存的大小，动态地调整发送方的发送窗口大小，即接收窗口rwnd(接收方设置确认报文段的窗口字段来将rwnd通知给发送方)，发送方的发送窗口取接收窗口rwnd和拥塞窗口wnd的最小值。

工作流程如下：

接收方在建立连接时，返回给发送方确认报文段，这个报文段中的窗口字段为6，表示要求这个发送方的窗口为6，所以发送窗口是动态变化的，取决于接收窗口的窗口字段，若接收端窗口字段是0，那么发送端就不能给接收端发送数据了。

接收方的功能就是将从发送方传来的报文段，上交给应用层进行处理。如果处理结束，接收方又会增加窗口字段大小返回给发送方。

例如：

1.A发送了1到200个字节，都没有问题，201~300字节丢失：

2.接收方累计确认，就会发送ack=201（前200个字节已正确发送，希望收到201个字节），rwnd=300（表示接收端还可接收300个字节），这时发送窗口变为：

3.A继续发送300~500字节，就不能再发送数据了

4.当201~300报文段丢失，并且超时时，A超时重发旧的数据，但不能发送新的数据

5.ack=501（表示500之前的报文段已经正确接收，期待收到501字节），rwnd=100（表示接收端还可接收100个字节），发送501~600，就不能再发送了

6.ack=601（表示600之前的报文段已经正确接收，期待收到601字节），rwnd=0表示不允许A再发送数据了

若接收端发送的确认丢失了，发送端会一直等待接收端的确认报文段，而接收端已经发送确认报文段，不会再发送确认报文段，如何解决：

TCP为每一个连接设有一个持续计时器，只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期就发送一个零窗口探测报文段。接收方收到探测报文段时给出现在的窗口值。（也就是主机A就算收不到主机B的确认报文段，不知道现在的窗口值，在持续计时器到期后，主机B也会重新发送确认报文段）

若窗口仍然是0，那么发送方就重新设置持续计时器。

3.TCP的拥塞控制

若网络中许多资源同时呈现供应不足--->网络性能变化--->网络吞吐量将随输入负荷增大而下降

出现拥塞的条件如下：对资源需求的总和>可用资源

拥塞控制的作用：防止过多的数据注入到网络中。

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

拥塞控制就是多个发送方给接收方发送数据，并且同时使用一个交换结点，这样就会导致网络拥塞，但是接收方不知道是哪几台主机发送数据过多导致。

流量控制是点对点的通信量的控制，那么接收方若接收数据过多，接收方知道是哪台主机发送数据。

拥塞控制的四种算法:

这里我们先假定：
1.数据单方向传送，而另一个方向只传送确认

2.接收方总是有足够大的缓存空间，因而发送窗口大小取决于拥塞程度

发送窗口=Min{接收窗口rwnd，拥塞窗口cwnd}

在讨论时我们假定接收窗口对发送窗口是没有限制的，所以发送窗口=拥塞窗口（cwnd）

接收窗口:接收方根据接受缓存设置的值，并告知给发送方，反映接收方容量。
拥塞窗口:发送方根据自己估算的网络拥塞程度而设置的窗口值，反映网络当前容量。

拥塞窗口cwnd的维护原则:只要网络没有出现拥塞，拥塞窗口就再增大一些;但只要网络出现拥塞，拥塞窗口就减少一些，因为发送窗口=拥塞窗口。

判断出现网络拥塞的依据: 没有按时收到应当到达的确认报文 (即发生超时重传)

慢开始和拥塞控制：

拥塞窗口的初始值默认为1，即cwnd=1（1个报文段），以下横坐标为传输轮次：发送方给接收方发送数据报文后，接收方给发送方发回相应的确认报文段的时间，一个传输轮次所经历的时间其实就是往返时间。

注：往返时间并非是恒定的数值，使用传输轮次是为了强调把拥塞窗口所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个报文段的确认。

工作流程如下：

发送方将拥塞窗口作为发送窗口swnd，即swnd = cwnd

维护一个慢开始门限ssthresh状态变量:
•当cwnd<ssthresh时，使用慢开始算法;

•当cwnd>ssthresh时，停止使用慢开始算法而改用拥塞避免算法;

•当cwnd=ssthresh时，既可以使用慢开始算法，也可以拥塞避免算法;

（1）在TCP双方建立逻辑连接关系时，拥塞窗口的值被设置为1，并设置慢开始门限的初始值。

（2）在进行慢开始算法时，发送方每接收到一个对新报文段的确认时，就把拥塞窗口值成倍增加，并开始下一轮的传输。

（3）当拥塞窗口值增长到慢开始门限值时，就改用拥塞避免算法，即线性增长，每次拥塞窗口只加1。

（4）当发送方检测到网络拥塞，出现丢包现象，则将拥塞窗口降到1，继续执行慢开始算法，同时将新的门限值定为发网络拥塞时的拥塞窗口值/2。

现在我们通过展现拥塞窗口随传输轮次的变化来理解：

步骤一：

发送方到收到确认后，将拥塞窗口值+1（此时窗口值为2），这样拥塞窗口就可以发送2个数据报文段，当发送方收到2个报文段的确认后，将窗口值+2(2+2=4),接下来就可以发送4个数据报文段，以此类推....即拥塞窗口值为2，4，8，16

步骤二：

现在增大到了慢开始门限值，改用拥塞避免算法：

每个传输轮次结束后，拥塞窗口值只能线性+1，发送方给接收方发送17个数据报文段，若收到接收方返回的确认后，继续线性+1

如图所示：

步骤三：

当拥塞窗口为24时，若发送的数据报部分丢失，发送方就会对这些报文段进行超时重传，

并且确定网络出现拥塞，做一下操作：

1.ssthresh值更新为发生拥塞时cwnd值的一半，如图则为12

2.将拥塞窗口值减小为1，并重新开始慢开始算法，当拥塞窗口达到新的门限值时，则改用拥塞避免算法

注：

1.慢开始是指一开始向网络注入的报文段少，并不是指拥塞窗口cwnd增长速度慢

2.“拥塞避免”并非指完全能够避免拥塞，而是指在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。

快重传和快恢复：

有时，个别报文段会在网络中丢失，但实际上网络并未发生拥塞这将导致发送方超时重传，并误认为网络发生了拥塞。于是发送方将拥塞窗口减少为1，并错误地启动慢开始算法，因而降低了传输效率。

所谓快重传，在可靠传输的重传中也有讲到:就是使发送方尽快进行重传，而不是等超时重传计时器超时再重传，采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失。

这就要求接收端：

•接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认;

•即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。

•发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传。

如图所示，接收方收到了M1和M2后都分别及时发出了确认。现假定接收方没有收到 M3但却收到了 M4。本来接收方可以什么都不做。但按照快重传算法，接收方必须立即发送对M2的重复确认，以便让发送方及早知道接收方没有收到报文段 M3。发送方接着发送 M5和 M6。接收方收到后也仍要再次分别发出对 M2的重复确认。这样，发送方共收到了接收方的 4 个对 M2的确认，其中后3个都是重复确认。快重传算法规定，发送方只要一连收到3 个重复确认，就可知道现在并未出现网络拥塞，而只是接收方少收到一个报文段 M3，因而立即进行重传 M3(即“快重传”)。使用快重传可以使整个网络的吞吐量提高约20%

在快重传算法后，就是执行快恢复，也就是发送方一旦收到3个重复确认，就知道现在只是丢失了个别的报文段。于是不启动慢开始算法，而执行快恢复算法。

1.发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半;

2.开始执行拥塞避免算法

注意：也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些，即等于新的ssthresh + 3。既然发送方收到3个重复的确认，就表明有3个数据报文段已经离开了网络；这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中；可见现在网络中不是堆积了报文段而是减少了3个报文段。因此可以适当把拥塞窗口扩大些，也就是将发送窗口增大些，从而增加效率。