软件测试管理

当前位置:首页 > 软件测试管理

《计算机网络:自顶向下方法》第三章 续8

6.经高带宽路径的TCP


认识到下列事实是重要的: TCP拥塞控制已经演化了多年并仍在继续演化。对当前TCP变量的总结和TCP演化的讨论,参见[ Floyd 2001, RFC 5681, Afanasyev 2010]。以往对因特网有益的东西( 那时大量的TCP连接承载的是SMTP、FTP 和Telnet流量),不.定对当今HTTP主宰的因特网或具有难以想象的服务的未来因特网还是有益的。


TCP继续演化的需求能够通过考虑网格和云计算应用所需要的高速TCP连接加以阐述。例如,考虑一条具有1500字节报文段和100ms RTT的TCP连接,假定我们要通过这条连接以10Gbps速率发送数据。根据[ RFC 3649],我们注意到使用上述TCP吞吐量公式,为了取得10Cbps吞吐量,平均拥塞窗口长度将需要是83 333个报文段。对如此大量的报文段,使我们相当关注这83 333个传输中的报文段也许会丢失。在丢失的情况下,将会出现什么情况呢?或者以另一种 方式说,这些传输的报文段能以何种比例丢失,使得在图3-52中列出的TCP拥塞控制算法仍能取得所希望的10Gbps速率?在本章的课后习题中,要求读者推导出一条TCP连接的吞吐量公式,该公式作为丢包率(L)、往返时间(RTT)和最大报文段长度(MSS)的函数:


《计算机网络:自顶向下方法》第三章 续7


使用该公式,我们能够看到,为了取得10Gbps的吞吐量,今天的TCP拥塞控制算法仅能容忍2x10-10的报文段丢失概率(或等价地说,对每5 000000000个报文段有一个丢包),这是一个非常低的值。这种观察导致许多研究人员为这种高速环境特别设计新版TCP,对这些努力的讨论参见[Jin 2004,RFC 3649, Kelly 2003,Ha 2008 ]。


公平性


考虑K条TCP连接,每条都有不同的端到端路径,但是都经过一段传输速率为R bps的瓶颈链路。(所谓瓶颈链路,是指对于每条连接,沿着该连接路径上的所有其他段链路都不拥塞,而且与该瓶颈链路的传输容量相比,它们都有充足的传输容量。)假设每条连接都在传输一个大文件,而且无UDP流量通过该段瓶颈链路。如果每条连接的平均传输速率接近R/K,即每条连接都得到相同份额的链路带宽,则认为该拥塞控制机制是公平的。


TCP的AIMD算法公平吗?尤其是假定可在不同时间启动并因此在某个给定的时间点可能具有不同的窗口长度情况下,对这些不同的TCP连接还是公平的吗? TCP趋于在竞争的多条TCP连接之间提供对一段瓶颈链路带宽的平等分享,其理由[Chiu 1989]给出了一个极好的、直观的解释。


我们考虑有两条TCP连接共享一段传输速率为R的链路的简单例子,如图3-55中所示。我们将假设这两条连接有相同的MSS和RTT (这样如果它们有相同的拥塞窗口长度,就会有相同的吞吐量),它们有大量的数据要发送,且没有其他TCP连接或UDP数据报穿越该段共享链路。我们还将忽略TCP的慢启动阶段,并假设TCP连接-直按 CA模式(AIMD)运行。


《计算机网络:自顶向下方法》第三章 续8


图3-56描绘了两条TCP连接实现的吞吐量情况。如果TCP要在这两条TCP连接之间平等地共享链路带宽,那么实现的吞吐量曲线应当是从原点沿459方向的箭头向外辐射(平等带宽共享)。理想情况是,两个吞吐量的和应等于R。( 当然,每条连接得到相同但容量为0的共享链路容量并非我们所期望的情况!)所以我们的目标应该是使取得的吞吐量落在图3-56中平等带宽共享曲线与全带宽利用曲线的交叉点附近的某处。


假定TCP窗口长度是这样的,即在某给定时刻,连接1和连接2实现了由图3-56中A点所指明的吞吐量。因为这两条连接共同消耗的链路带宽量小于R,所以无丢包事件发生,根据TCP的拥塞避免算法的结果,这两条连接每过一个RTT都要将其窗口增加1个MSS。因此,这两条连接的总吞吐量就会从A点开始沿45°线前行( 两条连接都有相同的增长)。最终,这两条连接共同消耗的带宽将超过R,最终将发生分组丢失。假设连接I和连接2实现B点指明的吞吐量时,它们都经历了分组丢失。连接1和连接2于是就按二分之一减小其窗口。 所产生的结果实现了C点指明的吞吐量,它正好位于始于B点止于原点的一个向量的中间。因为在C点,共同消耗的带宽小于R,所以这两条连接再次沿着始于C点的45°线增加其吞吐量。最终,再次发生丢包事件,如在D点,这两条连接再次将其窗口长度减半,如此等等。你应当搞清楚这两条连接实现的带宽最终将沿着平等带宽共享曲线在波动。还应该搞清楚无论这两条连接位于二维空间的何处,它们最终都会收敛到该状态!虽然此时我们做了许多理想化的假设,但是它仍然能对解释为什么TCP会导致在多条连接之间的平等共享带宽这个问题提供一个直观的感觉。


在理想化情形中,我们假设仅有TCP连接穿过瓶颈链路,所有的连接具有相同的RTT值,且对于一个主机-目的地对而言只有一条TCP连接与之相关联。实践中,这些条件通常是得不到满足的,客户-服务器应用因此能获得非常不平等的链路带宽份额。特别是,已经表明当多条连接共享一个共同的瓶颈链路时,那些具有较小RTT的连接能够在链路空闲时更快地抢到可用带宽(即较快地打开其拥塞窗口),因而将比那些具有较大RTT的连接享用更高的吞吐量[ Laksman 1997]。


1.公平性和UDP


我们刚才已经看到,TCP 拥塞控制是如何通过拥塞窗口机制来调节一个应用程序的传输速率的。许多多媒体应用如因特网电话和视频会议,经常就因为这种特定原因而不在TCP上运行,因为它们不想其传输速率被扼制,即使在网络非常拥塞的情况下。相反,这些应用宁可在UDP上运行,UDP是没有内置的拥塞控制的。当运行在UDP上时,这些应用能够以恒定的速率将其音频和视频数据注人网络之中并且偶尔会丢失分组,而不愿在拥塞时将其发送速率降至“公平”级别并且不丢失任何分组。从TCP的观点来看,运行在UDP上的多媒体应用是不公平的,因为它们不与其他连接合作,也不适时地调整其传输速率。因为TCP拥塞控制在面临拥塞增加(丢包)时,将降低其传输速率,而UDP源则不必这样做,UDP 源有可能压制TCP流量。当今的一.个主要研究领域就是开发种因特网中的拥塞控制机制,用于阻止UDP流量不断压制直至中断因特网吞吐量的情况[Floyd1999; Floyd 2000; Kohler 2006 ]。


2.公平性和并行TCP连接


即使我们能够迫使UDP流量具有公平的行为,但公平性问题仍然没有完全解决。这是因为我们没有什么办法阻止基于TCP的应用使用多个并行连接。例如,Web 浏览器通常使用多个并行TCP连接来传送一个 Web页中的多个对象。(多条连接的确切数目可以在多数浏览器中进行配置。)当一个应用使用多条并行连接时,它占用了一条拥塞链路中较大比例的带宽。举例来说,考虑一段速率为R 且支持9个在线客户-服务器应用的链路,每个应用使用一条TCP连接。如果一个 新的应用加入进来, 也使用一条TCP连接,则每个应用得到差不多相同的传输速率R/10。但是如果这个新的应用这次使用了11个并行TCP连接,则这个新应用就不公平地分到超过R/2的带宽。Web 流量在因特网中是非常普遍的,所以多条并行连接并非不常见。


3.8 小结


本章我们首先学习了运输层协议能够向网络应用程序提供的服务。在一个极端, 运输层协议非常简单,并向应用程序不提供不必要的服务,而仅向通信进程提供多路复用/分解的功能。因特网中的UDP协议就是这样一种不提供不必要服务的运输层协议。在另一个极端,运输层协议能够向应用程序提供各种各样的保证,例如数据的可靠交付、时延保证和带宽保证。无论如何,运输层协议能够提供的服务经常受下面网络层协议服务模型的限制。如果网络层协议不能向运输层报文段提供时延或带宽保证,那么运输层协议就不能向进程间发送的报文提供时延或带宽保证。


在3.4节中,我们学习了运输层协议能够提供可靠数据传输,即使下面的网络层是不可靠的。我们看到了提供可靠的数据传送会遇到许多微妙的问题,但都可以通过精心地结合确认、定时器、重传以及序号机制来完成任务。


尽管在本章中我们包含了可靠数据传送,但是我们应该理解在链路层、网络层、运输层或应用层协议中都可以提供可靠数据传送。该协议栈中,上面4层的任意一层 都可以实现确认、定时器、重传以及序号,能够向其上层提供可靠数据传送。事实上,在过去数年中,工程师以及计算机科学家们已经独立地设计并实现了提供可靠数据传送的链路层、网络层、运输层以及应用层协议( 虽然这些协议中的许多已经销声匿迹了)。


在3.5节中,我们详细地研究了TCP协议,它是因特网中面向连接和可靠的运输层协议。我们知道TCP是非常复杂的,它涉及了连接管理、流量控制、往返时间估计以及可靠数据传送。事实上,TCP比我们描述的要更为复杂,即我们有意地避而不谈在各种TCP实现版本中广泛实现的各种TCP补丁、修复和改进。然而,所有这些复杂性都对网络层应用隐藏了起来。如果某主机上的客户希望向另一台主机上的服务器可靠地发送数据,它只需要打开对该服务器的一个TCP套接字,然后将数据注入该套接字。客户-服务器应用程序则乐于对TCP的复杂性视而不见。


在3.6节中,我们从广泛的角度研究了拥塞控制,在3. 7节中我们阐述了TCP是如何实现拥塞控制的。我们知道了拥塞控制对于网络良好运行是必不可少的。没有拥塞控制,网络很容易出现死锁,使得端到端之间很少或没有数据能被传输。在3.7节中我们学习了TCP实现的一种端到端拥塞控制机制,即当TCP连接的路径上判断不拥塞时,其传输速率就加性增;当出现丢包时,传输速率就乘性减。这种机制也致力于做到每一个通过拥塞链路的TCP连接能平等地共享该链路带宽。我们也深人探讨了TCP连接建立和慢启动对时延的影响。我们观察到在许多重要场合,连接建立和慢启动会对端到端时延产生严重影响。我们再次强调,尽管TCP在这几年一直在发展,但它仍然是一个值得深入研究的领域,并且在未来的几年中还可能持续演化。


在本章中我们对特定因特网运输协议的讨论集中在UDP和TCP上,它们是因特网运输层的两匹“驮马”。然而,对这两个协议的二十多年的经验已经使人们认识到,这两个协议都不是完美无缺的。研究人员因此在忙于研制其他的运输层协议,其中的几种现在已经成为IETF建议的标准。


数据报拥塞控制协议( Datagram Congestion Control Protocol, DCCP) [ RFC 4340]提供了一种低开销、面向报文、类似于UDP的不可靠服务,但是具有应用程序可选择的拥塞控制形式,该机制与TCP相兼容。如果某应用程序需要可靠的或半可靠的数据传送,则这将在应用程序自身中执行(也许使用我们已经在3.4节中学过的机制)。DCCP 被设想用于诸如流媒体(参见第7章)等应用程序中,DCCP能够利用数据交付的预定时间和可靠性之间的折中,但是要对网络拥塞作出响应。流控制传输协议( Stream Control Transmission Protocol, SCTP) [ RFC 4960, RFC3286]是一种可靠的、面向报文的协议,该协议允许几个不同的应用层次的“流”复用到单个SCTP连接上(一种称之为“多流”的方法)。从可靠性的角度看,在该连接中的不同流被分别处理,因此在一条流中的分组 丢失不会影响其他流中数据的交付。当一台主机与两个或更多个网络连接时,SCTP也允许数据经两条出路径传输,还具有失序数据的选项交付和一些其他特色。SCTP的流控制和拥塞控制算法基本上与TCP中的相同。


TCP友好速率控制(TCP- Friendly Rate Control, TFRC)协议[ RFC 5348]是一种拥塞控制协议而不是一种功能齐全的运输层协议。它定义了一种拥塞控制机制,该机制能被用于诸如DCCP等其他运输协议(事实上在DCCP中可供使用的两种应用程序可选的协议之一就是TFRC)。TFRC的目标是平滑在TCP拥塞控制中的“锯齿"行为(参见图3-54),同时维护一种长期的发送速率, 该速率“合理地”接近TCP的速率。使用比TCP更为平滑的发送速率,TFRC非常适合诸如IP电话或流媒体等多媒体应用,这种平滑的速率对于这些应用是重要的。TFRC是一种“基于方程"的协议,这些协议使用测得的丢包率作为方程的输人[ Padhye 2000],即使用方程估计一个TCP会话在该丢包率下TCP的吞吐量将是多大。该速率则被取为TFRC的目标发送速率。


唯有未来才能告诉我们DCCP、SCTP或TFRC是否能得到广泛实施。虽然这些协议明确地提供了超过TCP和UDP的强化能力,但是多年来已经证明了TCP和UDP自身是“足够好”的。是否“更好”将胜出“足够好”,这将取决于技术、社会和商业考虑的复杂组合。


在第1章中,我们讲到计算机网络能被划分成“网络边缘”和“网络核心”。网络边缘包含了在端系统中发生的所有事情。既然已经覆盖了应用层和运输层,我们关于网络边缘的讨论也就结束了。接下来是探寻网络核心的时候了!我们的旅程从下一章开始,下一章将学习网络层,并且将在第5章继续学习链路层。



相关内容

文章评论

表情

共 0 条评论,查看全部
  • 这篇文章还没有收到评论,赶紧来抢沙发吧~