CSDN博客

img chifire

RFC2757-Long Thin Networks-chifire自译本(3)

发表于2001/5/8 13:03:00  559人阅读

 

 

 

      -  ESRO [RFC2188]

 

      -  RDP [RFC908, RFC1151]

 

      -  VMTP [VMTP]

 

3 TCP协议的状况(The Case for TCP

 

       这是无线领域争论最为激烈的问题,这里列出几个主要反对观点:

      

-          通常认为,TCP在实现无堵塞损失方面做得不够好。TCP的反对者认为,与其为无线媒介而修补TCP还不如重新设计来得方便。

 

-          TCP的报头开销太大。

 

-          是到了该理顺机制的时机了,TCP协议实在是太笨重了,不适合轻型的、可移动的设备使用。

 

当然,支持TCP的观点也不少:

 

-          从兼容性角度出发,在Internet的剩余领域中使用同样的协议是完美的解决方案。任何无线连接的扩展规范都应当被审议。

 

-          传统的机制可以被重新使用(例如:three-way handshake,即三向握手)

 

-          链路层的FECARQ技术可以降低BER,这样TCP丢包主要原因只是堵塞或网络连接的持续中断。现代W-WAN科技((CDPD, US-TDMA, CDMA, GSM)已经这样做了,极大地提高了TCP的吞吐能力。

 

-          通过移动IPMobile IP [RFC2002])可以实现不同技术间的切换,但自始至终贯穿的是同一个协议,即TCP/IP协议。

 

-          假设有TCP那么丰富的研发经验,随便哪个协议都会显得相对不够成熟,这一点并非象TCP应用广泛那样容易被人理解。

 

总而言之,我们认为TCP在远程-窄带网络上的性能还可以有显著地改善。在后续的章节我们将讨论其实现机制。

 

 

Montenegro, et al.           Informational                     [Page 11]


 

 

4 候选优化(Candidate Optimizations

 

       在无线介质上优化TCP操作还有大量的工作要做。即使卫星网络通常归于LFN(远程肥胖网)体系,我们当前关注的LTN(远程窄带网)仍可从其身上受益。例如,IETF的卫星TCP工作组的工作为本节内容提供了极大帮助[AGS98, ADGGHOSSTT98]

 

4.1 TCP:当前机制(TCP: Current Mechanisms

 

       TCP发送方基于接收方的反馈信号来调整其对带宽的使用,由于LTN网络的等待时间长,这种调整就比其它延迟短的网络相对慢些。同样,延迟的确认(ACKs)也不利于连接等待时间的估算。假定TCP能增大其段内单元的拥塞窗口,少量的MTU可能更会减慢这种调整过程。

 

4.1.1 慢启动与拥塞避免(Slow Start and Congestion Avoidance

 

       慢启动与拥塞避免[RFC2581]的实质就是Internet的稳定性。有两种理由说明无线媒介的反面效果:

 

-          只要TCP中继的计时期满,发送方就会认为网络发生拥挤,并调用慢启动。正如TCP所期望的那样,抛开拥塞所引起的损耗,尽可能地减小因讹误而引起的损耗。

 

-          发送方根据收到的确认(ACKs)信号数量来增大其窗口,当然,其到达速率依赖于发送方与接收方间的往返周期(RTTround-trip-time),这意味着长等待时间的连接(象LTN网络),有较长的斜坡时间(ramp-up),这种依赖性将持续到管道被充满为止。

 

-          在慢启动过程中,发送方会增大其段内单元的窗口,这就是这样做的重要原因,即要使用适当大小的MTU,且要降低链路层的损耗。

 

4.1.2快中继和快恢复(Fast Retransmit and Fast Recovery

 

       TCP发送方收到重复的确认(ACKs),快中继(fast retransmit[RFC2581])将推断一个段已经丢失,从而发送方将对此包进行重新发送,而不必等待超时,进而节省了时间。

 

 

 

 

 

Montenegro, et al.           Informational                     [Page 12]


 

 

       在快中继之后,发送方会调用快恢复[RFC2581]算法。快恢复允许发送方通过减半其传输速率(在避免堵塞基础上调节其窗口的增长)来避免慢启动,从而节省时间。

 

       通常,除了带宽延迟乘积以外,TCP也能增长其窗口。然而在LTN连接中,堵塞窗口可能会保持非常小,不到四段,在很长时间内是因为下列原因:

 

1.      典型情况下,通过连接传递的文件的尺寸都相对要小些(如Web请求、Web文件对象、email消息、文件等等),尤其是LTN的用户,在回应时间已经很长的情况下,更不愿意进行大尺寸文件的传输。

 

2.      如果连接的位错率高(BER)的话,堵塞窗口往往会停在很小的状态。

 

3.      LTN与高度堵塞的有线Internet入口结合时,堵塞引起的丢包产生的效果与2类似。

 

4.      通常,ISP/操作员在他们的拨号路由器(dialup router)中为每个用户配置的缓冲数目很小(甚至少到只有3个包)。

 

5.      通常,在LTN中建议采用小的socket缓冲,以避免实时操作(RTOreal time operation)中的数据膨胀,并减小竞争传输包的数量。

 

小窗口极大地阻碍了发送方利用快中继的好处,而且,在单个窗口中实现多重损耗的高效恢复也需要采用新的建议(NewReno [RFC2582])。另外,在没有包重排序的慢速通道上,要等待三次重复的ACK确认信号到达,这样延迟中继也没有什么必要。

      

       建议:尽快实现快中继及快恢复,这是优化实现的普遍方式,同时也是建议标准([AGS98])所推荐的卫星环境下快中继/快恢复的实现方式。很显然,NewReno [RFC2582]在发送方处理单个窗口中局部ACK确认信号及多重损耗方面还是很有帮助的,但是由于其属于实验性的机制,所以并不受到推荐。做为替代,SACK [RFC2018]是建议采用的机制。

 

 

 

 

 

 

 

 

 

Montenegro, et al.           Informational                     [Page 13]


 

 

4.2 基于T/TCP[RFC1397, RFC1644]的连结设置(Connection Setup with T/TCP [RFC1397, RFC1644]

 

       TCP在新连接建立时要进行三向握手("three-way handshake"),只有当此会话成功完成后,方可进行数据的传输。T/TCP允许在建立连接的同时,并行地进行数据的交换,从而使等待时间长的远程网络能够节省小事务的操作时间。

 

       建议:T/TCP并不受推荐,原因如下:

 

   -  它是实验性的RFC

 

   -  它的应用范围并不十分广泛,而且必须在连接的两端进行配置。

 

   -  从安全性角度看,T/TCPTCP本身更易受到殊如地址伪装之类的攻击。

 

   -  T/TCP的一些好的特性(如消除了并发过程中的三向握手过程,查询-回应式的事务处理等)也同样被HTTP/1.1上的连接所采用,而且后者更加稳固,应用范围也更广泛。

      

       [ADGGHOSSTT98]中并没有对卫星环境下的T/TCP做出建议。

 

4.3 慢启动建议(Slow Start Proposals

      

       交互式用户在TCP连接开始时能看到由于慢启动而产生的网络回应,因此大量的建议都提出,在等待时间长的环境中应取消慢启动。

 

       Internet的稳定性是极为重要的,因而这些建议必须论证其在重要路线上不会对Internet的堵塞水平产生负面影响。

 

4.3.1 大初始化窗口(Larger Initial Window

      

       传统的慢启动含有一个段的初始化窗,是LTN上耗时的带宽改造方案。由于TCP标准支持的最大值为2,大于一个段的初始化窗尚在研究阶段 [RFC2414, AHO98],至于更高的取值,本质上还是实验性的。

 

 

 

 

 

 

Montenegro, et al.           Informational                     [Page 14]


 

 

       [RFC2415]描述了对初始化窗进行增加三个信息包的模拟,但它并没有为信息包衰减率提供有效的解决办法,但它还是有助于在端设备慢启动(见下个建议)阶段缩短初始化的回应时间。

 

       [RFC2416]中论述了当初始化窗超过TCP协议可用的缓冲区数目时的状况,并指明,这种情况与堵塞窗口超过缓冲区数目时的情形是一样的。

 

       [RFC2581]中,允许有两个段的初始化堵塞窗口。在将来,当LFNLTN的性能得到极大提高后,可能会出现更大的多达四个段的初始化窗口。

 

       建议:立即在设备上实现该提议。优化研究表明,3个段是安全的初始化设定,即在234三种选择中取中间的。现在,使用2个段的(遵照RFC2581)方式至少允许客户端通过运行质询-回应式的应用,从未经修改的服务器上获取初始ACK确认信号,而不用再等待200毫秒的ACK超时,从而少走了两个往返过程。使用3个段的初始化窗[RFC2415]看来 有前途,可能在未来的研究和实验中被采用。 

 

4.3.2 在慢启动期间增大窗口(Growing the Window during Slow Start

 

       发送方可根据从接收方处返回的ACK应答信号流来增大其窗口。特别是在慢启动过程中,该信号流非常重要。有两个建议已经被研究过,一是ACK应答计数,二是ACK每节应答。

 

4.3.2.1 应答计数(ACK Counting

 

       ACK应答计数是主要思想是:

 

-          根据获取的数据(按字节计数),而非ACK的数量(即ACK应答计数)来增大窗口,以使每个ACK应答计数达到最满状态,这将使信息膨胀而引起堵塞。[Allman98]中解释了有限字节计数(Limited Byte Counting,LBC),即窗口增大被限制在2个段内则不会产生严重的信息膨胀,从而有助于提高性能。

 

建议:不可采用不加限制的字节计数方式。因为字节计数将会导致信息膨胀,对此Van Jacobson提出了警告[TCPSATMIN],并建议采用应答间隔([ACKSPACING])做为替代。

 

 

 

 

 

 

Montenegro, et al.           Informational                     [Page 15]

0 0

相关博文

我的热门文章

img
取 消
img