您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 咨询培训 > TCP增强总结(一)
TCP增强总结(一)1TCP问题分析传输控制协议TCP最初的设计是针对有线网络而设计的,随着技术的发展,远距离传输和无线传输成为必需。由于长时延和高误码传输的出现,原有的TCP协议在这样的传输条件下的性能会急剧下降,已经不能很好的满足我们的要求了。其主要变化为下:1)原版本TCP慢启动所需的时间表达式为:其中r指慢启动门限值。可以看出,RTT越大,慢启动所需时间就越长,同时慢启动门限值是网络拥塞时窗口的一半。在带宽固定的情况下,RTT越长,网络容量也越大,网络自然发生拥塞时的窗口也就越大,一般情况下慢启动门限值必然越大,这样使慢启动时间变得更长。而我们知道,TCP在慢启动阶段的传输速率比较低,所以慢启动过长会降低它的传输性能。2)长RTT网络中,RTT的估计值往往有延迟,并不是当时网络准确的RTT值。而TCP的超时重传机制需要它具备较准确的估计RTO,如果RTT的估计值不准确,RTO的估计值必然不准确。不准确的RTO估计值将会引起TCP的过早或过晚重传。过晚重传只会稍微影响TCP的传输速率。但是过早重传将会使TCP重传本来不必要的数据报文段,并且会使TCP拥塞控制进入慢启动间断,从而严重影响TCP的传输性能。3)TCP本身并没有区分丢包是由网络拥塞还是由误码引起的,如果发生丢包现象,TCP会认为网络已经发生拥塞,TCP协议进入慢启动,拥塞窗口变成等于1个最大报文段的大小(MSS),从而降低TCP的发送速率。使用这个技术的一个前提是:TCP假设绝大多数数据段或确认的丢失是由于因特网的拥塞。对大多数因特网链路来说,这种假设是有效的,尤其是考虑到光纤链路(它们构成了因特网中的许多连接)。但如果是高误码率链路条件下,这样的假设是不成立的。在此情况下,TCP会时常因为误码而进入慢启动,从而使TCP窗口一直比较低,最终会严重影响其性能。4)除此之外,从上面我们已经知道长时延网络中TCP的慢启动阶段会很长,如果在加上网络是高误码的,在长时间的慢启动过程中,要TCP连接不发生误码的可能性会很低。也就是说,TCP在未完成慢启动时很有可能又再次重新开始慢启动。这样会使窗口一直很小,最终的结果是传输速率极低,网络利用率也极低。5)另一个可能被忽略的原因是,TCP拥塞窗口的变化时以segments为单位的,所以我们在利用TCP传输数据时,应该尽可能大的加大MTU,但是这需要以低误码的链路层作为保障。在高误码情况下,链路层的误码也可能比较高。2TCP性能解决方案TCP性能解决方案是多层次的,几乎所有解决方案都可以按照以下的分类方法分成三类。A.链路层解决机制B.传输层解决机制C.版本改进方案2.1SnoopProtocol2.1.1Snoop协议介绍Snoop协议是链路层机制中的典型代表,也是TCP性能改进最显著有效的方案。Snoop协议是由Berkeley大学的Balakrishnan等人提出了关于无线网络链路层改进协议。是通过在基站里增加了一个Snoop代理模块,它是用来探测以及缓存将要发送到可移动性主机上的数据包,以及通过传发接收端发送过来数据包进行确认。当Snoop探测代理的相关模块发现了将需要发往接收端的分组在它的定时器超时又或者是接收到三个重复的数据确认包后,还是没有接收到从接收端返回的确认数据包时,那么它就会通过基站再次重新发送这个分组。当它连续接收到三个重复的ACK数据时,重复确认的数据包将会在这里被丢弃掉,而不是转发到相关的发送端,以免使得发送端会误认为它们是网络拥塞信号。因此,该改进方案中是不用修改原网络中已有的TCP/IP协议,只需要在链路层进行相应的改进就可以了,从而保证了TCP/IP网络端到端的语义。Snoop模块主要包含data处理和ACK处理,处理如下。数据流data处理:(1)新的数据包,且序号正确当基站在接收到相应的数据包时,该数据包将会被缓存到基站的缓存区中去,并且会被传输到移动接收终端,同时会在这个数据包附带上一个时间戳,目的是为可以及时判断出这个数据包是否存在传输超时,代理的时候也会使用这个时间戳来进行计算无线链路时所用到传输时延。(2)新的数据包但是序号不正确这种情况是属于代表发生了拥塞丢包的现象,也就是说在这个数据包接收到之前,因有一些数据包在有线网络传输时发生了网络拥塞从而导致了相关数据包在到达基站之前就被他们丢弃了。这样的数据包就一定会被标记为拥塞的数据包,此后就会被发送到TCP接收终端。接收端可以根据这个标记来进行增加相应的ack()选项,告知发送端在有线网络发生了相关的拥塞丢包现象。发送端就会知道这个信息在有线网络传输中发生了拥塞,此时就会启动相应的拥塞控制机制来处理。(3)旧的数据包这情现象相对来说少一些,发生类似这种情况的主要是由于TCP发送端出现了超时计数器出现了超时,这时就会重新传输超时的数据包,这种基站会收到序号小于基站缓存中缓存的最大序号的数据包信息。这种情况是由于TCP在发送端超时而重传的数据包也会被转发到相应的TCP接收终端。ACK流处理下面是Snoop对接收到的确认数据包时所处理流程,Snoop是属于代理接收到的ACK,ACK分为三种情况:第一种是新的ACK、第二种是旧的且是不重复的ACK、第三种是旧的且重复的ACK。Snoop在代理时对他们进行不同的情况进行处理。(1)新ACK这是属于正常的情况,Snoop代理对于ACK已经所确认的数据包会从缓存中删除掉,而且又要重新开始计算无线网络端到端的传输时延值。此时的ACK会被传送给TCP的发送终端。(2)旧的ACK而且不是重复的ACK类似这种情况相对来说会少一些。Snoop代理会丢弃这个ACK。(3)旧的ACK并且是重复的ACK这种情况是代表了TCP在接收端并且没有收到这个ACK时所确认的下一个需要的数据包。假如这个ACK所确认的下一个数据包是没有直接被data()标记为拥塞的数据包时,那么就会知道这个数据包是在无线网络的传输中被丢失的。当不断重复地确认数据包数大于或等于3时,Snoop代理就会马上重新传输这个数据包。假如被标记为拥塞数据包时则会发送到相应的接收端。2.1.2Snoop协议分析Snoop协议是通过滤除重复的ACK从而达到维持TCP窗口在一个更大的值。这样必然能够提高TCP在无线链路上的性能。同时Snoop方案对TCP性能的改进不必要修改原来发送端的任何东西,这也是它一个重要的优点。但是Snoop协议也有它自己的缺点:1.TCP的发送端拥塞控制不及时由于Snoop代理存在过滤一些重复的确认数据包功能,因此,使得TCP发送端不能通过接收到三个重复的确认数据包进行拥塞控制。这样TCP的发送端只允许通过超时计数器的超时行为方可以作相应的拥塞控制处理,这样就会使得TCP在发送端出现网络拥塞时无法进行及时的拥塞控制,从而导致网络性能出现更差的现象。2.TCP存在交叉层问题因为无线链路出现了错误从而导致了相应数据包丢失的现象,此时Snoop代理就会在本地重新传输已经丢失掉的数据包。通常在这种情况下,TCP在发送端的超时计数器出现超时之前,部分重传数据还没有完成,TCP的发送端就会认为网络已经出现了拥塞现象,此时就会进行相应的拥塞控制处理,TCP进入慢启动。TCP盲目地降低了网络数据传输速度,这样就导致了链路的利用率出现降低状况,从而使得整个系统的吞吐量出现了下降,此时丢失的数据包在传输层以及链路层将会同时被重传,这样就会浪费了有限的带宽资源。2.2版本改进方案TCP最初提出是在数十年前,随着需求的发展,TCP也出现了众多版本,其中有些版本正是针对长时延高误码情况下的TCP改进。2.2.1TCP-HyblaHybla主要是针对长时延的TCP改进,同时也有效解决了TCP在不同时延链路上的公平性问题。它由一系列过程组成,包括增强了的慢启动(SS)和拥塞避免阶段(CA),强制采用的SACK策略和信道带宽估计算法(Hoe’schannelbandwidthestimation),并且使用了时间戳(timestamps)和新的打包技术(packetspacingtechniques)。它这样改进的主要目的是希望长RTT连接的情况能够获得与有线网络一样快的传输速率。其基本算法思想为:长RTT会导致速率的较慢增长,所以引进了一个归一化的RTT值,即实际的RTT值与参考RTT0值的比值,该RTT0值为期望达到的性能。0/RTTRTT根据该比值来计算拥塞窗口的值W(t)(以MSS为单位),其定义如下:CAWWSSWWiiii/1221这样的拥塞窗口变化机制比标准TCP算法的窗口增长要快,以上表达式中的的值最小为1,避免将已经较快的速率减慢。采用Hybla窗口机制和newReno进行对比,可以得到如下的图。显然Hybla的窗口控制机制要优于newReno。而且它消除了RTT的影响,更适合在长RTT环境下传输。Hybla的优点是消除了长RTT对TCP拥塞控制机制的影响,使TCP在长RTT条件下提供较高传输速率。但它的缺点也相当明显,Hybla的关键思想在于归一化RTT值的提出,它需要一个我们期望的RTT0的设定,在现实网络中,链路的RTT是时刻变化的,我们是很难选择一个合适的RTT0的。2.2.2TCP-PeachPeach是TCP改进版本中针对卫星链路这样的长时延高误码环境下提出的。它沿用了传统TCP协议拥塞控制的4个核心算法,但在继承的基础上加以修改,形成了自己的控制算法。其4个核心算法分别为突然启动、拥塞控制、快速重传和迅速恢复。其中突然启动和迅速恢复就是在传统的慢启动和快速恢复基础上的改进。Peach改进的两个算法的设计思想在于它使用一种低优先级、不包含任何有用数据的报文段,即哑元(Dummy),来探测网络的拥塞情况。哑元应答的顺利接收标志着网络情况良好,发送方可以增大拥塞窗口,以传输更多的报文段。而一旦发生网络拥塞,哑元优先级比较低,将被首先丢弃。由于哑元不含任何有用的数据,其丢弃率不但可以反映网络拥塞的情况,而且丢弃的哑元不需要被重传,拥塞窗口也不需要“回退”。Peach不涉及中间节点的改造,能和传统的TCP相兼容。2.2.2.1哑元哑元是由发送者产生的不携带任何发往接收者新信息的数据段,它是根据发送者最新的数据段的拷贝生成的,并且具有很低的优先级别。发送者可以利用TCP头部中不使用的6个比特位中的1位或者多位用以表明哑元,根据这些设定位,接收者可以识别并且应答这些哑元。哑元的应答同样也需要表明TCP头部中的这几个比特位,也使用低优先级别的IP包来承载它们,这需要在接收端的实现上作少量的调整。2.2.2.2突然启动算法在Peach的设计中,突然启动算法替代了慢启动算法。设定rwnd代表接收窗口大小,它被置为拥塞窗口cwnd的最大上限值。突然启动的基本思想是在连接的开始阶段,发送者设置拥塞窗口cwnd为1,并且在发送完第1个数据段后,它每隔时间τ=RTT/rwnd就发送1个哑元。这样在第一个RTT内发送了一个数据段和(rwnd-1)个哑元,以这样的方式,数据段和哑元被均匀分布在RTT的时间间隔内,结果是在随后的第2个RTT时间内,普通数据段和哑元的ACK相继到来,拥塞窗口的大小增长非常快。需要注意的是,发送者在连接建立的初始阶段必须能够估计RTT。如果接收端没有实现Peach所需要的修改,那么哑元的应答就不会以希望的格式返回。如果出现这样的情况,发送者就会终止哑元的发送,转而开始使用传统TCP。对于一些小的文件传输,如HTTP,传输可以很快完成,算法具有很大的优势,它能在网络良好时很快到达一个理想的窗口大小,同时又不会像大初始化窗口协议(RFC1323)那样突进。2.2.2.3迅速恢复算法Peach迅速恢复算法替代传统的快速恢复算法的主要目的是,解决由于链路错误导致的吞吐量下降的问题。在Peach中,当一个丢失数据段通过重复应答机制被检查出来后,再使用传统的快速重传算法,在完成了快速重传之后,我们使用的是新的快速恢复算法,它将在时刻tEND(重传时刻+RTT)终止,这时丢失段的应答被接收到。迅速恢复
本文标题:TCP增强总结(一)
链接地址:https://www.777doc.com/doc-2862229 .html