TCP可靠性

TCP可靠性

      TCP采用的可靠性技术主要包括差错控制、流量控制和拥塞控制。

TCP差错控制

     TCP的差错控制包括检测损坏的报文段，失序的报文段、丢失的报文段和重复的报文段，并进行纠正。应用程序将数据流交给TCP后，就依靠TCP将整个数据流按顺序且没有损坏的传给另一个程序。TCP中的差错检测和差错纠正的方法有校验和、确认和重传。

1.校验和

    数据损坏可以通过TCP的校验和检测出来。每一个报文段都包括校验和字段，用来检查受损的报文段。若报文段遭到破坏，就由接收方TCP将其丢弃，并且被认为丢失了。

2．确认

     TCP采用确认来证实收到了报文段。控制报文段不携带数据，但消耗一个序列号。控制报文段也需要被确认。只有ACK报文段永远不需要被确认。目前ACK的确认机制最常用的规则有以下几种。(主要根据报文段中的序列号)

          (1）ACK报文段不需要确认，也不消耗序列号。

       （2）发送数据时尽量包含（捎带）确认，给出对方所期望接收的下一个序列号，以减少通信量。

       （3）如果接收方没有数据要发送，并且收到了按序到达的报文段，同时前一个报文段也已经确认了，那么接收端就推迟发送确认报文段，直到另一个报文段到达，或再经过了一段时间（通常是500 ms）。

       （4）当具有所期望的序列号的报文段到达时，同时前一个按序到达的报文段还没有被确认，那么接收端就要立即发送ACK报文段。任何时候不能有两个以上的按序的未被确认的报文段，以避免不必要的重传而导致网络的拥塞。

      （5）当收到一个序列号比期望序列号还大的报文段时，立即发送ACK报文段，让对方快速重传任何丢失的报文段。

      （6）当收到丢失的报文段，立即发送ACK报文段，告知对方已经收到了丢失的报文端。

      （7）当收到重复的报文段，立即发送ACK报文段进行确认。这就解决了ACK报文段丢失所带来的问题。

3．重传

       差错控制机制的核心就是报文段的重传。当一个报文段损坏、丢失或者被延迟了，就要重传。目前的TCP实现中，有以下两种报文段重传机制。

     1）超时重传

           TCP为每一个发送的报文段都设置一个超时重传（Retransmission Time Out,RTO）计时器。计时器时间一到，就认为相应的报文段损坏或者丢失，需要重传。注意仅携带ACK的报文段不设置超时计时器，因而也就不重传这种报文段。

           在TCP中RTO的值根据报文段的往返时间（Round Trip Time, RTT）动态更新。RTT是一个报文段到达终点和收到对该报文段的确认所需的时间。由于在Internet中传输延迟变化范围很大，因此从发出数据到收到确认所需的往返时间是动态变化的，很难确定。TCP的重传定时值也要不断调整，并通过测试连接的往返时间对重传定时值进行修正。

     2）快重传

           如果RTO值不是太大，上述超时重传比较可行。但是，有时一个报文段丢失了，而接收方会收到很多的失序报文段以致无法保存它们（缓冲区空间有限）。要解决这个问题，现在一般采用三个重复的ACK报文段之后重传的规则。也就是说，发送方收到了3个重复的ACK报文段之后，立即重传这个丢失的报文段。需要注意的是，不消耗序列号的报文段不进行重传，特别是对ACK段不进行重传。

4．失序报文段的处置

       当一个报文段推迟到达、丢失或被丢弃，在这个报文段后面的几个报文段就是失序到达。最初的TCP设计是丢弃所有的失序报文段，这就导致重传丢失的报文段和后续的一些报文段。现在大多数的实现是不丢弃这些失序的报文段，而是把这些报文段暂时存储下来，并把它们标志为失序报文段，直到丢失的报文段到达。注意失序的报文段并不交付到进程。TCP保证数据必须按序交付到进程。

5．重复报文段的处置

      重复的报文段一般是由超时重传造成的，接收方可以根据序列号判断是否是重复报文段，对于重复报文段只需要简单丢弃即可。TCP的确认和重传技术对每一个报文段都有唯一的序列号，这样当对方收到了重复的报文段后很容易区分，报文段丢失后也容易定位重传的报文段的序列号。

TCP流量控制

     TCP在传输层上实现端到端的流量控制，为接收方对发送方发送数据进行控制，以避免发送端发送大量的数据而接收端来不及接收导致接收方瘫痪，这是通过滑动窗口机制来实现的。利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。

1．滑动窗口机制

     在面向连接的传输过程中，收发双方在发送和接收报文时要协调一致。如果发送方不考虑对方是否确认，一味地发送数据，则有可能造成网络拥塞或因接收方来不及处理而丢失数据。如果发送方每发出一个报文（极端的情况下甚至只发送一个字节的数据）都要等待对方的确认，则又造成效率低下，网络资源得不到充分利用。为此，TCP采用一种折中的方法，即在缓冲区（暂时存放从应用程字传出并准备发送的数据）上使用滑动窗口，TCP发送数据的多少由这个滑动窗口定义。这样既能够保证可靠性，又可以充分利用网络的传输能力。

    滑动窗口机制通过发送方窗口和接收方窗口的配合来完成传输控制。发送方窗口如图7-30所示。发送缓冲区中是一组按顺序编号的字节数据，这些数据的一部分在发送窗口之中，另一部分在发送窗口之外。发送缓冲区左端和右端空白处表示可以加入数据的空闲空间，整个缓冲区就是一个左端和右端相连的环。发送窗口左侧是已发送并被接收方确认的数据，相应的缓冲区部分被释放。发送窗口中靠左的部分是已发送但尚未得到确认的数据，靠右的部分是可以立即发送的数据，也就是当前可用的窗口。发送窗口右侧是暂时不能发送的数据，一旦发送窗口内的部分数据得到确认，窗口便向右滑动，将已确认的数据移到窗口左侧空闲空间。发送窗口右边界的移动使新的数据又进入到窗口中，成为可以立即发送的数据。

       接收方窗口反映当前能够接收的数据的数量，大小取决于接收方处理数据的速度和发送方发送数据的速度，当从缓冲区中取出数据的速度低于数据进入缓冲区的速度时，接收窗口逐渐缩小，反之则逐渐扩大。接收方将当前窗口大小通告给发送方（利用TCP报文段首部的窗口大小字段），发送方根据接收窗口调整其发送窗口，使发送窗口始终小于或等于接收窗口的大小。只有在接收窗口滑动时（与此同时也发送了确认），发送窗口才有可能滑动。收发双方的窗口按照以上规律不断地向前滑动，因此这种协议又称为滑动窗口协议。

       当发送窗口和接收窗口的大小都等于1时，每发送一个字节的数据都要等待对方的确认，这就是停止等待协议。当发送窗口大于1，接收窗口等于1时，就是回退N步协议。当发送窗口和接收窗口的大小均大于1时，就是选择重发协议。协议中规定窗口内未经确认的分组需要重发。这种分组的数量最多可以等于发送窗口的大小，即滑动窗口的大小n减去1（因为发送窗口不可能大于（n-1），起码接收窗口要大于等于1）。

       TCP的窗口以字节为单位进行调整，以适应接收方的处理能力。处理过程如下。

          （1）TCP连接阶段，双方协商窗口大小，同时接收方预留数据缓存区；

          （2）发送方根据协商的结果，发送符合窗口大小的数据字节流，并等待对方的确认；

         （ 3）发送方根据确认信息，改变窗口大小，增加或者减少发送未得到确认的字节流中的字节数。如果出现发送拥塞，发送窗口缩小为原来的一半，同时将超时重传的时间间隔扩大一倍。

      在滑动窗口的操作中可能出现一个严重的问题，这就是发送应用程序产生数据很慢，或者接收应用程序消耗数据很慢，或者两者都有。不管是上述情况中的哪一种，都使得发送数据的报文很小，这就引起操作效率的降低，这个问题叫做糊涂窗口综合症（Silly Window Syndrome）。

     2．发送方产生的糊涂窗口综合症如果发送方TCP为生产数据很慢的应用程序服务，就可能产生糊涂窗口综合症。解决的方法是防止发送方TCP逐个字节地发送数据，强迫发送方TCP等待，凑成大块数据再发送。为了使TCP等待的时间更为合理，采用了Nagle算法，具体解决方法如下。

        （1）发送方将其从发送应用程序收到的第一块数据（即使只有1字节）发送出去。

        （2）发送第1个报文段以后，发送方TCP就在输出缓冲区中积累数据并等待，直到或者接收方TCP发送出确认，或者已积累到足够的数据可以装成最大长度的报文段。这时，发送方TCP就可以发送这个报文段。

        （3）对剩下的传输，重复步骤2。如果收到了对报文段2的确认，或者已积累到足够的数据可以装成最大长度的报文段，报文段3就必须发送出去。采用Nagle算法，如果应用程序比网络更快，则报文段就较大（最大长度报文段）。若应用程序比网络慢，则报文段就较小（小于最大长度报文段）。

提示：滑动窗口机制为端到端设备间的数据传输提供了可靠的流量控制机制。然而，它只能在源端设备和目的端设备起作用，当网络中间设备（如路由器等）发生拥塞时，滑动窗口机制将不起作用。

TCP拥塞控制

      流量控制是由于接收方不能及时处理数据而引起的控制机制，拥塞是由于网络阻塞引起的严重时延现象。拥塞会造成数据的丢失，数据的丢失会引起超时重传，而超时重传会进一步的加剧网络阻塞，如果不加以控制，最终会导致系统崩溃。对于拥塞造成的数据损失，仅仅靠超时重传是无法解决的。为此TCP提供了拥塞控制的机制。发送方所能发送的数据量受接收方的控制（流量控制），而且还有有网络的拥塞程度来决定。

      为了避免和消除拥塞，RFC 2581为TCP定义了4种拥塞控制机制，分别是慢启动（Slow Start）、拥塞避免（Congestion Avoidance）、快重传（FastRetransmit）和快恢复（Fast Recovery）。

1．拥塞窗口

     网络中一个重要的问题就是阻塞。如果网络上的负载超过服务端能够处理的程度，就会发生网络阻塞。在TCP的拥塞控制中还是发送串口来控制数据流入速度，减缓网络的流入速度，拥塞就会慢慢解除。发送窗口的大小取决于两个因素：一个是接收方的处理能力，由确认报文段所通告的大小接收窗口表示；另一个就是网络处理能力，由接收方所发送的拥塞窗口所决定。发送窗口的大小最终却决于接收窗口和拥塞窗口中最小的那个所决定。与接收窗口一样，拥塞窗口也处于不断的调整中，一旦发现拥塞，TCP将减小拥塞窗口，进而控制发送窗口。

2．拥塞策略

      TCP处理拥塞基于3个阶段：慢启动、拥塞避免和拥塞检测。在慢开始阶段，发送方逐渐增大发送窗口的大小，很快就增大到一个阈值（门限值），当达到阀值时，数据发送速率的增大就放慢以避免拥塞；最后，如果检测到拥塞，发送方就又回到慢启动或拥塞避免阶段。为了避免和消除拥塞，TCP循环往复地采用3种策略来控制拥塞窗口的大小。

 

 

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

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

慢开始算法：

    当主机开始发送数据时，如果立即所大量数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。因此，较好的方法是 先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。

   通常在刚刚开始发送报文段时，先把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口 cwnd ，可以使分组注入到网络的速率更加合理。

     每经过一个传输轮次，拥塞窗口 cwnd 就加倍。一个传输轮次所经历的时间其实就是往返时间RTT。不过“传输轮次”更加强调：把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。

     另，慢开始的“慢”并不是指cwnd的增长速率慢，而是指在TCP开始发送报文段时先设置cwnd=1，使得发送方在开始时只发送一个报文段（目的是试探一下网络的拥塞情况），然后再逐渐增大cwnd。

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

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

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

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

拥塞避免

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

     无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送 方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。

    这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生 拥塞的路由器有足够时间把队列中积压的分组处理完毕。

    如下图，用具体数值说明了上述拥塞控制的过程。现在发送窗口的大小和拥塞窗口一样大。

 

快重传和快恢复

快重传

    快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时才进行捎带确认。

      接收方收到了M1和M2后都分别发出了确认。现在假定接收方没有收到M3但接着收到了M4。

      显然，接收方不能确认M4，因为M4是收到的失序报文段。根据 可靠传输原理，接收方可以什么都不做，也可以在适当时机发送一次对M2的确认。

    但按照快重传算法的规定，接收方应及时发送对M2的重复确认，这样做可以让 发送方及早知道报文段M3没有到达接收方。发送方接着发送了M5和M6。接收方收到这两个报文后，也还要再次发出对M2的重复确认。这样，发送方共收到了 接收方的四个对M2的确认，其中后三个都是重复确认。

    快重传算法还规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段M3，而不必 继续等待M3设置的重传计时器到期。

    由于发送方尽早重传未被确认的报文段，因此采用快重传后可以使整个网络吞吐量提高约20%。

快恢复

    与快重传配合使用的还有快恢复算法，其过程有以下两个要点：

• 当发送方连续收到三个重复确认，就执行“乘法减小”算法，把慢开始门限ssthresh减半。
• 与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口cwnd现在不设置为1），而是把cwnd值设置为 慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。