六、TCP可靠传输的实现

首先介绍以字节为单位的滑动窗口。为了讲述可靠传输原理的方便，假定数据传输只在一个方向进行，即A发送数据，B给出确认。

1.以字节为单位的滑动窗口

Ⅰ、概述

①发送窗口

表示：在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。

发送窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因为可能有较高的传输效率。但接收方必须来得及处理这些收到的数据。

发送窗口的位置由窗口前沿和后沿的位置共同确定。

②发送窗口后沿

它的变化情况有两种，即不动（没有收到新的确认）和前移（收到了新的确认）。发送窗口后沿不可能向后移动，因为不能撤销已收到的确认。

③发送窗口前沿

通常是不断向前移动，也有可能不移动，这对应于两种情况，一是没有收到新的确认，对方通知的窗口大小也不变；二是收到了新的确认但对方通知的窗口缩小了，使得发送窗口前沿正好不动。发送窗口前沿也有可能向后收缩，这发生在对方通知的窗口缩小了，但TCP标准不赞成这样做，因为很可能发送方在收到这个通知以前已经发送了窗口中的许多数据，现在收缩会产生一些错误。

Ⅱ、发送窗口和接收窗口

假定A发送了序号为31~41的数据，这时发送窗口位置并未改变。三个指针：P1、P2、P3。

P3-P1=A的发送窗口（又称为通知窗口）

P2-P1=已发送但尚未收到确认的字节数

P3-P2=允许发送但尚未发送的字节数（又称为可用窗口或有效窗口）

再看一下B的接收窗口。到30号为止的数据是已经发送过确认，并且已经交付给主机了，此时B可以不再保留这些数据。32和33号数据没有按序到达，而B只能对按序收到的数据中的最高序号给出确认，因此B发送的确认报文段中的确认号仍然是31（即期望收到的序号），而不能是32或33。

现假定B收到了31号数据，并把31~33的数据交付给主机，然后B删除这些数据。接着把接收窗口向前移动3个序号（图5-17），同时给A发送确认，其中窗口值仍为20，但确认号是34。A收到B的确认后，就可以把发送窗口向前滑动3个序号，但指针P2不动。A的可用窗口增大了，可发送的序号范围是42~53。

A在继续发完42~53的数据后，指针P2向前移动和P3重合，发送窗口内的序号都已用完，但还没有再收到确认（图5-18）。由于A的发送窗口已满，可用窗口已减小到零，因此必须停止发送。请注意，存在下面这种可能性：就是发送窗口内所有的数据都已正确到达B，B也早已发出来确认。但不幸的是，所有这些确认都滞留在网络中。在没有收到B的确认时，A在经过一段时间后（由超时计时器控制）就重传这部分数据，重新设置超时计时器，直到收到B的确认为止。如果A收到确认号落在发送窗口内，那么A就可以使发送窗口继续向前滑动，并发送新的数据。

Ⅲ、发送缓存和接收缓存

缓存空间和序号空间都是有限的，并且都是循环使用的。

发送缓存暂时用来存放：①发送应用程序传送给发送方TCP准备发送的数据；②TCP已发送出但尚未收到确认的数据。

发送窗口通常只是发送缓存的一部分，已被确认的数据应当从发送缓存中删除，因此发送缓存和发送窗口的后沿是重合的。发送应用程序最后写入发送缓存的字节减去最后被确认的字节，就是还保留在发送缓存中的被写入的字节数。发送应用程序必须控制写入缓存的速率，不能太快，否则发送缓存就会没有存放数据的空间。

接收缓存用来暂时存放：①按序到达的、但尚未被接收应用程序读取的数据；②未按序到达的数据。

如果收到的分组被检测出有差错，则要丢弃。如果接收应用程序来不及读取收到的数据，接收缓存最终就会被填满，使接收窗口减小到零。反之，如果接收应用程序能够及时从接收缓存中读取收到的数据，接收窗口就可以增大，但最短不能超过接收缓存的大小。

注意：

①虽然A的发送窗口是根据B的接收窗口设置的，但在同一时刻，A的发送窗口并不总是和B的接收窗口一样大。这是因为通过网络传送窗口值需要经历一定的时间滞后，另外发送方A还可能根据网络当时的拥堵情况适当减小自己的发送窗口数值。

②对于不按序到达的数据应如何处理，TCP标准无明确规定。如果接收方把不按序到达的数据一律丢弃，则这样对网络资源的利用不利（因为发送方会重复传送较多的数据）。因此，TCP通常对不按序到达的数据先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付非上层的应用进程。

③TCP要求接收方必须有累积确认的功能，这样可减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。但请注意两点： 第一，接收方不应过分推迟发送确认，否则会导致发送方不必要的重传，这反而浪费了网络的资源。TCP标准规定，确认推迟时间不应超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就要发送一个确认。第二，捎带确认实际上并不经常发生，因为大多数应用程序不同时在两个方向上发送数据。

2.超时重传时间的选择

Ⅰ、背景

设置短了，会引起报文段不必要的重传，使网络负荷增大。设置长了，网络空闲时间大，降低了传输效率。于是TCP采用了一种自适应算法。

Ⅱ、自适应算法

它记录一个报文段发出的时间，以及收到相应的确认的时间，这两个时间之差就是报文段的往返时间RTT。TCP保留了RTT的一个加权平均往返时间RTTs（又称为平滑往返时间，S代表smoothed）。

新的RTTs=（1-α）*（旧的RTTs）+α*（新的RTT样本）

上式中，0≦α﹤1。若α接近0，则表示新的RTTs值和旧的RTTs值相比变化不大，而对新的RTT样本影响不大（RTT值更新较慢）。若α接近1，则表示新的RTTs值受新的RTT样本的影响较大（RTT更新较快）。RFC 2988推荐的α值为1/8，即0.125。

显然，超时计时器设置的超时重传时间RTO（retransmission time-out）应略大于上面得出的加权往返时间RTTs。

RTO=RTTs+4*RTTd

RTTd——RTT的偏差的加权平均值

新的RTTd=（1-β）*（旧的RTTd）+β*| RTTs - 新的RTT样本 |

β推荐值为1/4，即0.25。

Ⅲ、问题及解决

往返时间测量是复杂的——比如，发送一个报文段，重传时间到了，还没收到确认，于是重传报文段。经过一段时间，收到了报文段。问题是：如何判定此确认报文段是对先发送的报文段的确认，还是对后来重传的报文段的确认？正确的判定对确认加权平均RTTs的值关系很大。

解决——Karn提出，在计算加权平均RTTs时，只要报文段重传了，就不采用其往返时间样本。这样得出的加权平均RTTs和RTO就较准确。

新问题——设想报文段的时延突然增大了很多。因此在原来得出的重传时间内，不会收到确认报文段。于是重传报文段，但根据Karn算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。

修正——报文段每重传一次，就把超时重传时间RTO增大一些。典型做法是取新的重传时间为2倍的旧的重传时间。当不再发生报文段的重传时，才根据上面给出的式子计算超时重传时间。

3.选择确认SACK

Ⅰ、背景

若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？

Ⅱ、工作原理

我们知道，TCP的首部没有哪个字段能够提供上述这些字节块的边界信息。RFC 2018规定，如果要使用选择确认，那么在建立TCP连接时，就要在TCP首部的选项中加上“允许SACK”的选项，而双方必须都事先商定好，如果使用选择确认，那么原来首部中的“确认号字段”的用法仍然不变。只是以后在TCP报文段的首部中都增加了SACK选项，以便报告收到的不连续的字节块的边界。

由于首部选项的长度最多只有40字节，而指明一个边界就要用掉4字节（因为序号有32位，需要使用4个字节表示），因此在选项中最多只能指明4个字节块的边界信息。这是因为4个字节块共有8个边界，因而需要用32字节来描述。另外还需要两个字节。一个字节用来指明是SACK选项，另一个字节是指明这个选项要占用多少字节。如果要报告五个字节块的边界信息，那么至少需要42字节。这就超过了选项长度的40字节的上限。RFC 2018还对报告这些边界信息的格式都做出来非常明确的规定。

然而，SACK文档并没有指明发送方应当怎样响应SACK，因此大多数的实现还是重传所有未被确认的数据块。

七、TCP的流量控制

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

流量控制——flow control，让发送方的发送速率不要太快，要让接收方来得及接收。不然就会造成数据丢失。

举例——设A向B发送数据。在建立连接时，B告诉了A：“我的接收窗口rwnd=400”（receiver window）。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。TCP的窗口单位是字节，不是报文段。再设每一个报文段为100字节长，而数据报文段序号的初始值设为1（见图seq=1）。大写ACK表示首部中的确认位ACK，小写ack表示确认字段的值。只有在ACK=1时确认号字段才有意义。接收方的主机B进行了三次流量控制。

问题——B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwnd=400的报文段。然而这个报文段在传送过程中丢失了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。

解决——TCP为每一个连接设有一个持续计时器（persistences timer）。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。如果窗口仍然是零，那么受到这个报文段的一方就重新设置持续计时器。如果窗口不是零，那么死锁的僵局就可以打破了。

注：TCP规定，即使设置为零窗口，也必须接收以下几种报文段：零窗口探测报文段、确认报文段和携带紧急数据的报文段。

2.必须考虑传输效率

Ⅰ、三种机制来控制TCP报文段的发送时机

应用进程把数据报传送到TCP的缓存后，剩下的发送任务就由TCP来控制了。可以用不同的机制来控制TCP报文段的发送时机。

第一种：TCP维持一个变量，它等于最大报文长度MSS。只要缓存中存放的数据达到MSS时，就组装成一个TCP报文段发送出去。

第二种：由发送方的应用进程指明要求发送报文段，即TCP支持的推送（push）操作。

第三种：发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不超过MSS）发送出去。

Ⅱ、如何控制TCP发送报文段的时机

为什么要控制——当只发送一个字符时，传送效率不高，所以应适当推迟发回确认报文，并尽量使用捎带确认的方法。

Nagle算法——若发送应用进程要把发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来。当发送方收到对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对随后到达的数据进行缓存。只有在收到对前一个报文段的确认后才继续发送下一个报文段。当数据到达较快而网络速率较慢时，用这样的方法可明显地减少所用的网络带宽。此算法还规定，当到达的数据已到达发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。

糊涂窗口综合症——silly window syndrome，有时也会使TCP的性能变坏。

定义：当发送端应用进程产生数据很慢、或接收端应用进程处理接收缓冲区数据很慢，或二者兼而有之；就会使应用进程间传送的报文段很小，特别是有效载荷很小。 极端情况下，有效载荷可能只有1个字节；而传输开销有40字节(20字节的IP头+20字节的TCP头) 这种现象就叫糊涂窗口综合症。

设想一种情况：TCP接收方的缓存已满，而交互式的应用进程一次只从接受缓存中读取1个字节（这就使接收缓存空间仅腾出1个字节），然后向发送方发送确认，并把窗口设置为1个字节（但发送的数据报是40字节长）。接着，发送方又发来1个字节的数据（请注意，发送方发送的IP数据报是41字节长）。接收方发回确认，仍然将窗口设置为1个字节。这样进行下去，网络的效率很低。

解决：让接收方等待一段时间，使得或者接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲的时间。只要出现这两种情况之一，接收方就发出确认报文，并向发送方通知当前的窗口大小。此外，发送方也不要发送太小的报文段，而是把数据积累成足够大的报文段，或达到接收方缓存空间的一半大小。

八、TCP的拥塞控制

1.拥塞控制的一般原理

Ⅰ、拥塞原因

网络资源有：计算机网络中的链路容量（即带宽）、交换结点中的缓存和处理机等。

拥塞条件：∑对资源的需求>可用资源

结点缓存——如果太小，到达该结点的分组因无存储空间暂存而不得不丢弃。如果太大，凡是到达该结点的分组均可在结点的缓存队列中排队，不受任何限制，但输出链路的容量和处理机的速度并未提高，导致这队列中的绝大多数分组的排队等待时间太长，上层软件只好把它们重传（因为早就超时了），从而加剧拥塞。

处理机——速度太慢会因此网络拥塞。太快则会将瓶颈转移到其他地方。问题实质是整个系统的各个部分不匹配。

Ⅱ、拥塞控制与流量控制的关系

拥塞控制——防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制前提是：网络能够承受现有的网络负荷。它是全局性的问题，涉及到所有的主机、所有的路由信息、以及与降低网络传输性能有关的所有因素。但TCP连接的端点只要迟迟不能收到对方的确认信息，就猜想哪里有堵塞，不知是什么原因。

流量控制——指点对点通信量的控制，是个端到端的问题（接收端控制发送端）。流量控制就是要抑制发送端发送数据的速率，以便使接收端来得及接收。

相似之处——某些拥塞控制算法是向发送端发送控制报文，并告诉发送端，网络已出现麻烦，必须放慢发送速率。这点和流量控制是相似的。

Ⅲ、拥塞控制所起的作用

①理想的拥塞控制

提供的负载：offered load，也叫输入负载、网络负载，代表单位时间内输入给网络的分组数目

吞吐量：throughput，代表单位时间内从网络输出的分组数目

在吞吐量达到饱和前，吞吐量=提供的负载。但当负载超过某一限度时，由于网络资源受限，吞吐量不再增长。这表明提供的负载中有一部分损失掉了（例如，输入到网络的某些分组被某个结点丢弃了）。虽然如此，在理想的拥塞控制作用下，网络的吞吐量仍然维持在其所能达到的最大值。

②实际的拥塞控制

在网络吞吐量还未达到饱和时，就已经有一部分的输入分组被丢弃了。当网络的吞吐量明显小于理想的吞吐量时，网络就进入了轻度拥塞的状态。

当提供的负载达到某一数值时，网络的吞吐量反而随提供的负载的增大而下降，这是网络就进入了拥塞状态。当提供的负载继续增大到某一数值时，网络的吞吐量就下降到零，网络已无法工作。这就是死锁（deadlock）。

Ⅳ、如何进行拥塞控制

增大网络的某些可用资源、减少一些用户对某些资源的需求。拥塞控制难以设计是因为它是一个动态问题。分组丢失是网络发生拥塞的征兆而不是原因，许多情况下正是拥塞控制机制本身成为引起网络性能恶化甚至发生死锁的原因。

①开环控制

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

②闭环控制

（a）监测网络系统以便检测到拥塞在何时、何处发生

主要指标有：平均队列长度、超时重传的分组数、平均分组时延

（b）把拥塞发生的信息传送到可采取行动的地方

一般发送到产生分组的源站，当然会更加堵塞；或者是在路由器转发的分组中保留一个比特或字段，用来表示网络没有堵塞或产生了堵塞；或由一些主机或路由器周期性地发出探测分组，以询问拥塞是否发生。

频繁采取行动会使系统产生不稳定的振荡，迟缓采取行动又不具有任何实用价值。因此，要折中采取正确的时间是想当困难的。

（c）调整网络系统的运行以解决出现的问题

2.拥塞控制方法——慢开始（slow-start）和拥塞避免（congestion avoidance）

Ⅰ、预备

假定：（1）数据是单方向传送，而另一个方向只传送确认；

（2）接收方总是有足够大的缓存空间，因而发送窗口的大小由网络的拥塞程度来决定。

发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量，它的大小取决于网络的拥塞程度，并且在动态变化。发送方让自己的发送窗口等于拥塞窗口。考虑到接收方的接收能力，发送窗口要小于拥塞窗口。

发送方控制窗口的原则——只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。

发送方怎么知道网络出现了拥塞——发送方没有按时收到应当到达的确认报文

下面讨论拥塞窗口cwnd的大小是怎样变化的。

Ⅱ、慢开始算法的思路

当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。经验证明，最好是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。通常在刚刚开始发送报文时，把cwnd设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值（通常是指数倍）。

为方便起见，我们用报文段的个数作为窗口大小的单位（实际上，TCP是用字节作为窗口的单位）。看下图，首先发送方先设置cwnd=1，发送一个报文段M1。发送方每收到一个对新报文段的确认（重传的不算在内）就使发送方的拥塞窗口加1。每经过一个传输轮次，拥塞窗口就加倍。传输轮次更加强调：把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。

慢开始的“慢”不是指cwnd的增长速度慢，而是指TCP开始发送报文段时先设置cwnd=1，使得发送方在开始时只发送一个报文段（目的是试探一下网络的拥塞情况），然后逐渐增大cwnd。这比一下子把许多报文段突然注入到网络中要“慢得多”。

慢开始门限ssthresh状态变量：

当cwnd<ssthresh时，使用上述的慢开始算法；

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

当cwnd=ssthresh时，两种方法都可以用。

慢开始门限是为防止拥塞窗口增长过大引起网络拥塞，如何设置，后面要讲。

Ⅲ、拥塞避免算法的思路

是让拥塞窗口cwnd缓慢增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样，拥塞窗口按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速度缓慢得多。

无论在慢开始还是在拥塞避免阶段，只要发送方判断出无论出现拥塞（其根据就是没有按时收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的是迅速减少主机发送到网络中的分组数，使得发生拥堵的路由器有足够时间把队列中积压的分组处理完毕。

Ⅳ、慢开始和拥塞避免算法的实现举例

上图中，当TCP连接初始化时，把拥塞窗口cwnd置为1（不使用字节而使用报文段的个数）。

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

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

上述两种合称为AIMD算法（加法增大乘法减小）。注意：拥塞避免并非指完全避免了拥塞，只是说在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。

3.拥塞控制方法——快重传（fast retransmit）快恢复（fast recovery）

Ⅰ、快重传

不使用快重传时，如果发送方设置的超时计时器时限已到但还没有收到确认，那么很可能是网络出现了拥塞，致使报文段在网络中的某处被丢弃。于是，TCP马上把拥塞窗口cwnd减小到1，并执行慢开始算法，同时把慢开始门限值ssthresh减半。

使用快重传时，要求接收方每收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等待自己发送数据时才进行确认。看下例，接收方不能确认M4因为它是收到的失序报文段（M3还没有收到）。根据可靠传输原理，接收方可以什么都不做，也可以在适当时机发送一次对M2的确认。但按照快重传算法的规定，接收方应及时发送对M2的重复确认，这样做可以让发送方及早知道报文段M3没有到达接收方。发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段M3，而不必继续等待为M3设置的重传计时器到期。

Ⅱ、快恢复

过程有以下两个要点：（1）当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把慢开始门限ssthresh减半。这是为了预防网络发生堵塞。请注意，接下来不执行慢开始算法。

（2）由于发送方现在认为网络很可能没有发生拥塞（如果网络发生了严重的拥塞，就不会一连好几个报文段连续到达接收方，就不会导致接收方连续发送重复确认），因此与慢开始不同之处就是现在不执行慢开始算法（即拥塞窗口cwnd现在不设置为1），而是把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。

注意：也有的快重传是把开始时的拥塞窗口cwnd值再增大一些（增大3个报文段的长度），即等于ssthresh+3*MSS。这样做的理由是：既然发送方收到三个重复确认，就表明有三个分组已离开了网络。这三个分组不再消耗网络的资源而是停留在接收方的缓存中（接收方发送出三个重复的确认就证明了这个事实）。可见现在网络中并不是堆积了分组而是减少了三个分组。因此可以适当地把拥塞窗口扩大些。

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

Ⅲ、拥塞控制方法假定条件

在一开始我们假定接收方总是有足够大的缓存空间，因而发送窗口的大小由网络的拥塞程度来决定。但实际上接收方的缓存空间是有限的。接收方根据自己的接收能力设定了接收窗口rwnd，并把这个窗口值写入TCP首部中的窗口字段，传送给发送方。因此，接收窗口又称为通知窗口（advertised window）。因此，从接收方对发送方的流量控制的角度考虑，发送方的发送窗口一定不能超过对方给出的接收窗口值rwnd。

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

rwnd和cwnd中较小的一个控制发送方发送数据的速率。

4.随机早期检测RED

Ⅰ、背景

TCP拥塞控制和网络层采取的策略有密切的关系。

路由器处理分组时间长→发送方对这些分组中的数据部分（即报文段）重传→使TCP连接的发送端认为网络发生拥塞→发生端采取拥塞控制策略（实际上未拥塞）

尾部丢弃策略——网络层的策略对TCP拥塞控制影响最大的是路由器的分组控制丢弃策略。简单情况下，路由器队列“先进先出”，队列满时，后面的分组丢弃。

全局同步（global syncronization）——尾部丢弃→一连串分组丢失→发送方超时重传→TCP进入拥堵控制的慢开始状态→TCP连接的发送方突然把数据的发送速率降低到很小的数值，更为严重的是，在网络层有很多的TCP连接中的报文段是复用在网络层的UP数据报中传送→影响到很多条TCP连接→TCP连接在同一时间突然进入慢开始状态→全网通信量突然下降很多，网络正常后，通信量又突然增大。

为避免全局同步，路由器采用随机早期检测的措施。

Ⅱ、随机早期检测RED原理

使路由器的队列维持两个参数，即队列长度最小门限THmin和最大门限THmax。当每一个分组到达时RED组就先计算平均队列长度Lav（后面讲如何计算）。RED算法是：

（1）若平均队列长度小于最小门限THmin，则把新到达的分组放入队列进行排队。

（2）若平均队列长度超过最大门限THmax，则把新到达的分组丢弃。

（3）若平均队列长度在最小门限THmin和最大门限THmax之间，则按某一概率p将新到达的分组丢弃。

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

Ⅲ、最小门限THmin、最大门限THmax、p的选择

最小门限THmin必须足够大，以保证连接路由器的输出链路有较高的利用率。THmin和THmax之差也应当足够大，使得在一个TCP往返时间RTT中队列的正常增长仍在最大门限THmax之内。经验表明，使最大门限THmax等于最小门限THmin值的两倍是最合适的。如果门限值设定的不好，则会引起类似于尾部丢弃那样的全局振荡。

p的选择有以下三原则：

①平均队列长度Lav<THmin，p=0；

②平均队列长度Lav>THmax，p=1；

③THmin<平均队列长度Lav<THmax，0<p<1。

假设，p按照线性变化，从0变到pmax。看下图。

Ⅳ、为什么使用平均队列长度

数据有突发性特点→路由器中的队列长度经常会出现很快的起伏变化，如果丢弃概率p是按照瞬时队列长度来计算，那就可能出现一些不合理的现象。比如，很短的突发数据不太可能使队列溢出，造成不必要的拥塞控制。

平均队列长度Lan=（1-δ）*（旧的Lan）+δ*（当前的队列长度样本）

Ⅴ、p怎么求

P=Ptemp/（1-count*Ptemp）

count是一个变量，代表新到达的分组有多少个已经进去到了队列（没有被丢弃）；Ptemp是过渡的分组丢弃概率：

Ptemp=Pmax*（Lav-THmin）/（THmax-THmin）

分组丢弃概率p不仅与平均队列长度有关，而且还随着队列中不被丢弃的分组数目的增多而逐渐增大，就可以避免分组的丢弃过于集中。

Ⅵ、评价

好处就是当平均队列长度超过门限值THmin时，就会有少量的分组被丢弃，这就使得有少量的TCP连接会减小其窗口值，使得到达路由器的分组的数量减少。结果，队列平均长度就减小了，从而避免了网络拥塞的发生。应当注意到，网络的吞吐量仍然保持在较高的数值，因此丢弃的分组的数量是很少的。

路由器在某一时刻的瞬时队列长度完全可能远远超过平均队列长度。算出的丢弃概率很小，但路由器的队列已经没有空间可接纳新到达的分组，这时RED的操作和“尾部丢弃”的方式是一样的。RED只是在可能的条件下尽量使“尾部丢弃”不要发生。

RED机制使得路由器可以更好地管理其队列长度。但多长的队列是最佳长度仍然有待进一步的研究。

九、TCP的运输连接管理

运输连接三阶段：连接建立、数据传送、连接释放

TCP连接建立时要解决以下三个问题：

①要使每一方能够确知对方的存在；

②要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）；

③能够对运输实体资源（如缓存大小、连接表中的项目）进行分配。

TCP连接的建立采用客户服务器方式。客户——主动发起连接建立的应用进程。服务器——被动等待连接建立的应用进程。

1.TCP的连接建立

图片发自简书App

三次握手过程如下：

第一次握手：建立连接，客户端A发送SYN包(seq=x)到服务器，并进入SYN_SEND状态，等待服务器B确认。

第二次握手：服务器收到SYN包，必须确认客户端A的SYN包（ack=x+1），同时自己也发送一个SYN包（seq=y），即SYN+ACK包。此时服务器进入SYN_RECV状态。

第三次握手：客户端A收到服务器B的SYN+ACK包，向服务器B发送确认包ACK(ack=y+1),此包发送完毕，客户端A

和服务器端B都进入ESTABLISHED状态，完成三次握手。

完成三次握手，客户端与服务器端开始传送数据。

疑问：为什么是三次握手而不是两次握手？

防止已失效的连接请求报文段突然又传到了B，因此产生错误。

已失效的连接请求报文段是这样产生的。譬如，A发出请求，但丢失未收到确切，又重传一次，后收到确认建立了连接，这是正常情况。异常情况是，A发出的请求时延了，B误认为是A又发出的一次新的连接请求，于是向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了。由于A并没有发出建立连接的请求，因此不会理睬B的确认也不会向B发送数据，但B误以为连接建立了，并等A发送数据，这样B的资源浪费了。

2.TCP连接的断开

图片发自简书App

四次挥手过程如下：

连接的一个A的某个应用程序首先调用close，执行主动关闭。他的TCP发送一个FIN分节，表示数据发送完毕；

接受的到的这个FIN分节的对端B执行被动关闭，并由其TCP确认这个FIN(向A发送确认)。然后将这个FIN作为文件结束符发送给他自身的应用进程；

一点时间后（中间有个close-waite），B调用close关闭套接字，并由其TCP发送一个FIN给A；

接受到这个FIN的A端TCP发送ACK确认这个FIN;

注意：TCP连接还没有释放时，必须经过时间等待计时器（time wait timer）设置的时间2MSL后，A才进入到CLOSED状态。时间MSL叫做最长报文段寿命。

为什么要等待2MSL的时间？

理由一：为了保证A发送的最后一个ACK报文段能够到达B（可能重传）

理由二：防止上一节提到的“已失效的连接请求报文段”出现在本连接中。A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

保活计时器——设想：客户已主动与服务器建立了TCP连接，到后来客户端出现故障，服务器以后不再收到客户发来的数据。因此，必须有措施使服务器不再白白等待下去。这就是保活计时器，服务器每收到一次客户的数据，就重新设置保活计时器，发送一个探测报文段。若10个探测报文段没有响应，服务器就认为客户端出了故障，接着就关闭这个连接。

3.TCP的有限状态机

粗实线剪头：对客户进程的正常变迁

粗虚线剪头：对服务器进程的正常变迁

细线剪头：异常变迁