快牵着我的袜子

  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

一、TCP可靠性

  TCP可靠传输主要通过两种方式保证可靠性,分别为滑动窗口、超时重传。

  1.1、以字节为单位的滑动窗口

    1)假定数据传输只在一个方向进行,即A发送数据,B给出确认。这样的好处是使讨论限于两个窗口,即发送方A的发送窗口和接收方B的接收窗口。

    现假定A收到了B发来的确认报文段,其中窗口是20字节,而确认号是31(这表明B期望收到的下一个序号是31,而序号30为止的数据已经收到了)。根据这两个数据,A就构造出自己的发送窗口。

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

    2)发送数据发送窗口变化

      现在假定A发送了序号为31~41的数据。这时,发送窗口位置并未改变(图5-16),但发送窗口内靠后面有11个字节(灰色小方框表示)表示已发送但未收到确认。

    而发送窗口内靠前面的9个字节(42~50)是允许发送但尚未发送的。

 

 

 

      从上图可以看出,要描述一个发送窗口的状态需要三个指针: Pp,Pz和 P3(图5-16)。指针都指向字节的序号。这三个指针指向的几个部分的意义如下:
      1、小于P的是已发送并已收到确认的部分,而大于P圈的是不允许发送的部分。P3-Pi=A的发送窗口
      2、P-Pr=已发送但尚未收到确认的字节数
      3、Ps-Pz=允许发送但当前尚未发送的字节数(又称为可用窗口或有效窗口)

    3)接收到确认发送窗口变化

 

 

 

      现在假定B收到了序号为31的数据,并把序号为31~33的数据交付主机,然后B删除这些数据。接着把接收窗口向前移动3个序号(图5-17),同时给A发送确认,其中窗口值仍为20,

    但确认号是34。这表明B已经收到了到序号33为止的数据。我们注意到,B还收到了序号为37,38和40 的数据,但这些都没有按序到达,只能先暂存在接收窗口中。A收到B的确认后,

    就可以把发送窗口向前滑动3个序号,但指针P不动。可以看出,现在A的可用窗口增大了,可发送的序号范围是42~~53。

     4)发送窗口已满

    

 

 

 

        A在继续发送完序号42~53的数据后,指针P向前移动和P重合。发送窗口内的序号都已用完,但还没有再收到确认(图5-18)。由于A的发送窗口已满,可用窗口已减小到零,

      因此必须停止发送。请注意,存在下面这种可能性,就是发送窗口内所有的数据都已正确到达B,B也早已发出了确认。但不幸的是,所有这些确认都滞留在网络中。在没有收到B的确认时,

      A不能猜测:“或许B收到了吧!”为了保证可靠传输,A只能认为B还没有收到这些数据。于是,A在经过一段时间后(由超时计时器控制)就重传这部分数据,重新设置超时计时器,

      直到收到B的确认为止。如果A收到确认号落在发送窗口内,那么A就可以使发送窗口继续向前滑动,并发送新的数据。

    5)窗口和缓存的关系

 

 

    

    发送缓存用来暂时存放:
      1、发送应用程序传送给发送方TCP准备发送的数据;

      2、TCP已发送出但尚未收到确认的数据。


    注意:发送窗口通常只是发送缓存的一部分。已被确认的数据应当从发送缓存中删除,因此发送缓存和发送窗口的后沿是重合的。发送应用程序最后写入发送缓存的字节减去最后被确认

    的字节,就是还保留在发送缓存中的被写入的字节数。发送应用程序必须控制写入缓存的速率,不能太快,否则发送缓存就会没有存放数据的空间。

     

    接收缓存用来暂时存放:
      1、按序到达的、但尚未被接收应用程序读取的数据;

      2、未按序到达的数据。
    注意:如果收到的分组被检测出有差错,则要丢弃。如果接收应用程序来不及读取收到的数据,接收缓存最终就会被填满,使接收窗口减小到零。反之,如果接收应用程序能够及时从

    接收缓存中读取收到的数据,接收窗口就可以增大,但最大不能超过接收缓存的大小。

    

    强调事项:

      1、虽然A的发送窗口是根据B的接收窗口设置的,但在同一时刻,A的发送窗口并不总是和 B的接收窗口一样大。这是因为通过网络传送窗口值需要经历一定的时间滞后(这个时间

      还是不确定的)。另外,发送方A还可能根据网络当时的拥塞情况适当减小自己的发送窗口数值。

      2、对于不按序到达的数据应如何处理,TCP标准并无明确规定。如果接收方把不按序到达的数据一律丢弃,那么接收窗口的管理将会比较简单,但这样做对网络资源的利用不利

      (因为发送方会重复传送较多的数据)。因此TCP通常对不按序到达的数据是先临时存放在接收窗口中,等到字节流中所缺少的字节收到后,再按序交付上层的应用进程。

      3、TCP要求接收方必须有累积确认的功能,这样可以减小传输开销。接收方可以在合适的时候发送确认,也可以在自己有数据要发送时把确认信息顺便捎带上。但请注意两点。

      一是接收方不应过分推迟发送确认,否则会导致发送方不必要的重传,这反而浪费了网络的资源。TCP标准规定,确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段,

      则必须每隔一个报文段就发送一个确认[RFC 1122]。二是捎带确认实际上并不经常发生,因为大多数应用程序很少同时在两个方向上发送数据。

   滑动窗口注意事项:

    1、TCP的通信是全双工通信。通信中的每一-方都在发送和接收报文段。因此,每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时,一定要弄清是哪一方的窗口。

    2、发送方的发送窗口不能超过接收方的接收窗口的数值。

    3、TCP的窗口单位是字节,不是报文段。

  1.2、超时重传

    1)超时重传时间

      TCP采用了一种自适应算法,它记录一个报文段发出的时间,以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT。TCP保留了RTT的一个加权平均往返

    时间RTTs(这又称为平滑的往返时间,S表示Smoothed。因为进行的是加权平均,因此得出的结果更加平滑)。每当第一次测量到RTT样本时,RTTs值就取为所测量到的RTT样本值。

    但以后每测量到一个新的RTT样本,就按下式重新计算一次RTTs:

    

    注:已成为建议标准的RFC 6298推荐的α值为1/8,即 0.125。用这种方法得出的加权平均往返时间RTT、就比测量出的RTT值更加平滑。

 

    显然,超时计时器设置的超时重传时间RTO (RetransmissionTime-Out)应略大于上面得出的加权平均往返时间RTTs。RFC 6298建议使用下式计算RTO:

 

 

 

    而RTTD是 RTT的偏差的加权平均值,它与 RTTs和新的 RTT样本之差有关。RFC6298建议这样计算 RTTD。当第一次测量时,RTTD值取为测量到的RTT样本值的一半。在以后

    的测量中,则使用下式计算加权平均的RTTD:

 

 

 

    注:这里β是个小于1的系数,它的推荐值是1/4,即0.25。

 

     2)确认和重传的确认顺序  

        方法:报文段每重传一次,就把超时重传时间RTO增大一些。典型的做法是取新的重传时间为旧的重传时间的2倍。当不再发生报文段的重传时,才根据上面给

      出的上面公式计算超时重传时间。实践证明,这种策略较为合理。

 

二、流量控制

    让发送方的发送速率不要太快,要让接收方来得及接收。流量控制往往是指点对点通信量的控制,是个端到端的问题(接收端控制发送端)。流量控制所要做的就是抑制发送端发送

  数据的速率,以便使接收端来得及接收。

  2.1 滑动窗口(原理第一章)

  2.2 nagle算法:

      算法如下:TCP连接上最多只能有一个未被确认的小分组,在该分组的确认到达之前不能发送其他的小分组。若发送应用进程把要发送的数据逐个字节地送到TCP的发送缓存,则发

    送方就把第一个数据字节先发送出去,把后面到达的数据字节都缓存起来。当发送方收到对第一个数据字符的确认后,再把发送缓存中的所有数据组装成一个报文段发送出去,同时继

    续对随后到达的数据进行缓存。只有在收到对前一个报文段的确认后才继续发送下一个报文段。当数据到达较快而网络速率较慢时,用这样的方法可明显地减少所用的网络带宽。Nagle 算

    法还规定,当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时,就立即发送一个报文段。这样做,就可以有效地提高网络的吞吐量。

三、拥塞控制

    拥塞控制就是防止过多的数据注入到网络中,这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提,就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程,

  涉及到所有的主机、所有的路由器,以及与降低网络传输性能有关的所有因素。

    TCP进行拥塞控制的算法有四种,即慢开始(slow-start)、拥塞避免(congestionavoidance)、快重传(fast retransmit)和快恢复(fast recovery)。

    下面讨论的拥塞控制也叫做基于窗口的拥塞控制。为此,发送方维持一个叫做拥塞窗cwnd (congestion window)的状态变量。拥塞窗口的大小取决于网络的拥塞程度,并且动态地在变

  化。发送方让自己的发送窗口等于拥塞窗口。

  

  3.1、慢开始

    1、原理:

      慢开始算法的思路是这样的:当主机开始发送数据时,由于并不清楚网络的负荷情况,所以如果立即把大量数据字节注入到网络,那么就有可能引起网络发生拥塞。

    经验证明,较好的方法是先探测一下,即由小到大逐渐增大发送窗口,也就是说,由小到大逐渐增大拥塞窗口数值(“指数增大”的特点)。

    2、算法解析

      请注意,虽然实际上TCP是用字节数作为窗口大小的单位。但为叙述方便起见,我们用报文段的个数作为窗口大小的单位,这样可以使用较小的数字来阐明拥塞控制的原理。
      在一开始发送方先设置cwnd= 1,发送第一个报文段M1,接收方收到后确认M1。发送方收到对M的确认后,把 cwnd 从1增大到2,于是发送方接着发送M2和 M3,两个报文段。

    接收方收到后发回对 M2和 M3,的确认。发送方每收到一个对新报文段的确认(重传的不算在内)就使发送方的拥塞窗口加1,因此发送方在收到两个确认后,cwnd 就从⒉增大到4,

    并可发送M4~M7共4个报文段。因此使用慢开始算法后,每经过一个传输轮次(transmission round),拥塞窗口cwnd就加倍。

      

    

        慢开始的“慢”并不是指cwnd 的增长速率慢,而是指在TCP开始发送报文段时先设置cwnd= 1,使得发送方在开始时只发送一个报文段(目的是试探一下网络的拥塞情况),

      然后再逐渐增大 cwnd。这当然比设置大的cwnd 值一下子把许多报文段注入到网络中要“慢得多”。这对防止网络出现拥塞是一个非常好的方法。在TCP的实际运行中,发送方只

      要收到一个对新报文段的确认,其拥塞窗口 cwnd 就立即加1,并可以立即发送新的报文段,而不需要等这个轮次中所有的确认都收到后(如图上所示的那样)再发送新的报文段。

 

 

     3、门限值  

        为了防止拥塞窗口 cwnd 增长过大引起网络拥塞,还需要设置一个慢开始门限 ssthresh状态变量。慢开始门限ssthresh 的用法如下:
        1)当cwnd < ssthresh时,使用上述的慢开始算法。
        2)当cwnd > ssthresh 时,停止使用慢开始算法而改用拥塞避免算法。当cwnd = ssthresh时,既可使用慢开始算法,也可使用拥塞避免算法。

    4、对应图中位置:图中点1之前部分都是执行慢开始算法,刚开始从1开始,经过一个传输轮次后变为2,再经过一个轮次后变为4,以此类推。

  3.2、拥塞避免

    1、原理:  

      让拥塞窗口 cwnd缓慢地增大(“加法增大”的特点),即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1,而不是像慢开始阶段那样加倍增长。因此在拥塞避免阶段就有“加法增大”AI (Additive Increase)的

    特点。这表明在拥塞避免阶段,拥塞窗口cwnd按线性规律缓慢增长,比慢开始算法的拥塞窗口增长速率缓慢得多。

    2、算法解析:

        当拥塞窗口cwnd达到门限值时,开始采用拥塞避免算法,按线性规律增长。

    3、对应图中位置:图中点1至点2部分执行拥塞避免算法,当达到门限值16后(点1),开始执行拥塞避免算法,每个传输轮次后拥塞窗口cwnd加1。

  3.3、快重传

    1、原理:

      发送方只要一连收到3个重复确认,就知道接收方确实没有收到报文段M,因而应当立即进行重传(即“快重传”),这样就不会出现超时,发送方也不就会误认为出现了网络拥塞。采用快重传

    算法可以让发送方尽早知道发生了个别报文段的丢失。

    2、对应图中位置:当拥塞窗口cwnd = 16时(图中的点4),出现了一个新的情况,就是发送方一连收到3个对同一个报文段的重复确认,即进行快重传,马上发送丢失的数据,不需要等待重传定时器。    

  3.4、快恢复

    1、原理

        发送方知道现在只是丢失了个别的报文段,于是不启动慢开始,而是执行快恢复算法。这时,发送方调整门限值调整为之前设置的门限值ssthresh的一半,同时设置拥塞窗口cwnd与门限值ssthresh相同并

        开始执行拥塞避免算法。

    2、对应图中位置:

        当拥塞窗口cwnd = 16时(图中的点4),出现了一个新的情况,就是发送方一个报文段的重复确认,发送方知道现在只是丢失个别的报文段,于是不启动慢开始,而是执行快恢

      复算法。这时,发送方调整门限值ssthresh = cwnd / 2 =8,同时设置拥塞窗口cwnd = ssthresh =8(见图5-25中的点⑤),并开始执行拥塞避免算法。

 

posted on 2022-04-16 17:25  快牵着我的袜子  阅读(423)  评论(0编辑  收藏  举报