40、性能问题(传输层)

本文深入探讨了计算机网络中性能问题的关键点,从传输层的角度出发,涵盖网络性能测量、快速网络设计、数据包处理优化、头部压缩以及长肥网络协议的挑战。文章指出,性能瓶颈往往源于主机而非网络本身,强调了减少软件开销、优化缓冲管理和计时器管理的重要性。此外,头压缩技术如ROHC用于减少带宽需求和降低延迟,而针对长肥网络,需要设计适应高带宽和长延迟的协议策略,如避免序号回绕和采用选择重传协议。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

引言

  • 在计算机网络中,性能问题非常重要。当成百上千台计算机相互连接在一起时,无法预知结果的复杂交互过程很常见。这种复杂性常常会导致很差的性能,而且无人知道其中的缘由。在下面的章节中,我们将讨论许多与网络性能有关的问题,以便了解可能存在哪些问题以及如何处理这些问题。
  • 不幸的是,理解网络性能更像是一门艺术,而不是一门科学。这里很少有可在实践中应用的基础理论。我们能够做的最好方法是给出一些来自于实践的经验规则,并且展示一些真实世界中的例子。我们有意将这部分讨论推迟到学习了TCP 的传输层之后,因为应用程序获得的性能依赖于传输层、网络层和链路层的结合,而且能够在不同场合中使用TCP作为例子。
  • 在下面的章节中,我们将考查网络性能的如下6 个方面。
    Cl )性能问题。
    (2 )网络性能的测量。
    (3 )快速网络中的主机设计。
    (4 )快速处理段。
    (5 )头的压缩。
    (6 )“长肥”网路的协议。
    上述这些方面同时从主机和网络,以及网络速度和规模增长来考虑网络性能。
1、计算机网络中的性能问题
  • 有些性能问题(比如拥塞)是由于临时资源过载所引起的。如果到达一台路由器的流量突然超过了它的处理能力,那么,拥塞就会发生,从而导致性能问题。当网络中存在结构性的资源不平衡时,性能也会退化。例如,如果将一条千兆位的通信线路连接到一台低档的PC 上,则性能较差的CPU 将无法快速地处理入境数据包,因此有些数据包将会被丢失。这些数据包最终会被重传,既增加了延迟,又浪费了带宽,而且往往降低了性能。
  • 过载也可能被同步触发。例如,如果一个段包含了一个坏参数(比如,它的目标端口),那么,在许多情形下,接收端会尽职地返回一个错误通知。现在请考虑,如果将一个坏段广播给1000 台机器将发生什么样的情况:每台机器都可能送回一个错误消息。由此引发的广播风暴( broadcast storm )可能会严重地削弱网络的性能。以前, UDP 协议就遭受过这个问题,直到ICMP 协议作了修改,使主机不再对发送给广播地址的UDP 段中错误做出响应,以免遭受广播风暴。对于无线网络来说,由于广播本质上会发生,而且无线带宽有限,因此尤其要小心避免未经检查的广播响应。同步触发过载的另一个例子是掉电之后发生的情形。当电源恢复时,所有的机器同时启动系统。一个典型的启动序列可能如下:首先与某一台(DHCP )服务器联系,以便获得一个真实的身份:然后与某一台文件服务器联系,以便获得操作系统的一份副本。如果一个数据中心的成千上万台机器同时做这些事情,则服务器可能因不堪重负而崩溃。即使不存在同步过载,并且资源也足够,同样也可能由于缺少系统总体协调而发生性能退化的现象。例如,如果一台机器有足够的CPU 能力和内存,但是并没有为缓冲区空间分配足够多的内存,则流量控制机制将放缓段的接收,从而限制了传输性能。当Internet 变得越来越快,而流量控制窗口仍然维持在64 KB大小时,许多TCP 连接都存在这个问题。
  • 另一个调整问题是超时间隔的设置。当一个段被发送出去时, TCP 通常会设置一个计时器来预防该段的丢失。如果超时间隔设置得太短,将会发生不必要的重传,从而堵塞线路:如果超时间隔设置得太长,当段被丢失之后将导致不必要的延迟。其他可以调整的参数包括捎带确认应该等待数据段多长时间之后未果才发送单独的确认以及应该尝试经过多少次重传之后再放弃。
  • 对于诸如音频和视频的实时应用,它们的另一个性能问题是抖动。仅仅有足够的平均带宽还不足以有良好的性能。这些应用还要求较小的传输延迟。要想同时获得较短的延迟必须小心规划网络中的流量负载,同时还需要链路层和网络层共同支持服务质量。
2、网络性能测量
  • 当一个网络的运行效果很差时,它的用户通常会向网络运营商抱怨并要求提高网络质量。为了改善网络性能,网络操作人员首先必须弄清楚发生了什么问题。为了找出真正的问题所在,操作人员需要对网络进行测量。在本小节中,我们来考查网络性能的测量问题。下面的许多讨论以( Mogul, 1993 )的工作为基础。
  • 测量工作可以有许多不同的方式,也可以在不同的地点进行(既指物理位置,也指协议战中的位置)。最基本的一种测量手段是在开始某一个动作时启动一个计时器,然后确定该动作需要多长时间。例如,知道一个段需要多长时间才能被确认是很关键的一个测量指标。其他一些测量指标可以通过计数器来完成,即记录某种事件发生的次数(比如丢失的段数量)。最后,人们通常对于某些事物的数量比较感兴趣,比如在特定的时间间隔内所处理的字节数。
  • 测量网络的性能和参数有许多潜在的陷阱。以下我们列出其中一部分。任何一种系统化的网络性能测量手段都应该小心地避免这些陷阱。

确保样值空间足够大

  • 不要仅仅测量发送一个段的时间,而是要重复地测量,比如说测量100 万次,然后再取平均值。启动效应可能放慢第一个段的速度,而且排队会引入变化,比如802.16 NIC 或者线缆调制解调器在一个空闲周期后获得带宽预留。采用大量的样本可以减小测量均值和标准方差中的不确定性。这种不确定性可以利用标准的统计公式计算出来。

确保样值具有代表性

  • 理想情况下,这一百万次测量的完整序列应该分布在一天或者一周的不同时刻重复进行,以此来看不同的网络条件对测量数值的影响。例如,对于拥塞的测量,如果仅仅在没有拥塞的那一刻来测量网络拥塞,那么这样的测量以及结果没什么用。有时候测量结果初看起来可能不符合直觉,比如在上午11 点和下午1 点钟网络严重拥塞,但是中午时候却没有拥塞(所有的用户都去吃午饭了〉。
  • 在无线网络中,信号的传播位置是一个很重要的变量。由于天线的差异,即使测量节点放置在靠近无线客户端也可能无法观察到与客户端相同的数据包。在研究中最好从无线客户端进行测量,考查它究竟看到了什么。如果做不到这一点,那就使用技术把从不同角度的无线测量结合起来以便对正在发生的事情有个更全面的了解( Mahajan 等, 2006 )。

缓存可以破坏测量结果

  • 如果协议使用了缓存机制,那么重复多次测量将返回一个不可预测的快速答复。例如,获取一个Web 页面或者查询一个DNS 名字(来发现其IP 地址〉可能只有第一次涉及网络交换,以后返回的都是从缓冲区获得的结果,没有真正往网络上发送任何数据包。这样的测量结果本质上是没有什么价值的(除非你要测量的就是缓冲性能〉。
  • 缓冲机制也有类似的影响。己经有TCP/IP 性能测试报告称UDP 可以获得比网络允许的要好得多的性能。这是怎么发生的呢?调用UDP 时一旦内核接受了消息并且消息被排入传输队列之后,通常控制权就马上返回给应用程序了。如果主机上有足够的缓冲空间,则执行1000 次UDP 调用也不意味着所有的数据都己经被发送出去。大多数数据包仍然在内核中,但是性能测试程序却认为它们都己经被传送出去了。建议测试时,你要绝对确保网络操作是如何缓存以及缓冲数据的。

确保测试

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值