CN1794651B

CN1794651B - 用于通信网络中问题解决的系统和方法

Info

Publication number: CN1794651B
Application number: CN200510115298.1A
Authority: CN
Inventors: R·M·西尔弗曼
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2004-12-23
Filing date: 2005-11-11
Publication date: 2010-10-06
Anticipated expiration: 2025-11-11
Also published as: US7475130B2; US20060143496A1; CN1794651A

Abstract

本发明提供一种用于使用网络资产管理数据对网络性能建模并识别性能问题的系统和方法，网络资产管理数据包括诸如设备类型、位置及链路速度的属性。可以采用系统的功能上完整的数学特征化，以创建用于问题识别和解决的系统，其中只在必要时才对物理和逻辑系统组件进行破坏性改变。可单独进行查验(或其它时戳标记的通信流)的数学分析及MIB和其它资产数据的数学分析，并将结果与“自检查”比较，构成和检验网络系统的完整数学特征化。另外，本发明可提供对基于所建议的对网络中一个或多个组件的改变的性能影响的预计。性能度量、查验时间、MIB数据、链路速度、传播延迟、设备等待时间、串行化速率、会话速度、会话利用及其它数据用来对网络建模。

Description

用于通信网络中问题解决的系统和方法

相关申请的交叉引用

本申请涉及2004年12月23日提交的序号待定(IBM公开号END920040162US)的专利申请，在此整体引入该申请作为参考。

技术领域

本发明总体涉及用于对通信网络进行故障诊断的系统和方法，更具体地，涉及监控通信网络的可用性和性能以改进通信网络的故障诊断的系统和方法。

背景技术

存在至少两种类型的网络问题：停机和性能差。“停机”通常指不可用的资源，而“性能差”通常指用户不满意的系统响应度不在SLA(服务级别协议)或其它要求中阐述的范围之内。每一类型的问题可能是由各种类型的网络问题原因中的任何一个所引起的，网络问题例如是物理问题、逻辑问题或容量问题。这些类型的问题可能进一步地以各种条件为特征。“物理问题”通常是某硬件部分损坏，并且或者处于已故障状态，或者是间歇地出故障。“逻辑问题”通常指的是因为在设计或配置或定制中的缺陷，软件或固件不像预期的那样工作。此外，“容量”问题通常意味着一个组件中或一组组件之上的数学阈值(实际的或人为限制的)已经以不利地影响可用性或性能的这样一种方式所超过。

已经有问题管理工具被开发出来，并且与系统范围的情形相反，它们在识别引发问题的个别组件方面最强。这应该是不令人惊讶的，因为由个别组件所引起的问题状态的识别通常显著地比由跨多个组件范围内的问题所引起的问题状态的识别要容易。事实上，最普遍用于网络管理的两种类型的工具说明了这个事实。实例包括具有网络的图符显示的基于控制台的工具，诸如IBM的NetView^TM、Hewlett-Packard的OpenView^TM，以及MIB控制块读取工具，诸如Concord的e-Health^TM和Lucent的Vitalnet^TM。

NetView^TM和Hewlett-Packard OpenView^TM最初是在20世纪八十年代开发的，它们是网络管理的基石。这些工具，按常规，轮询网络以发现网络的设备以及连接这些设备的通信链路。在管理控制台显示上，每一个所发现的设备通常由一个图标来代表，而每一个连接通常由一条线来代表，然后，该管理控制台显示示出该网络。这些图标和线往往着红色、琥珀色或绿色(因此控制台的名字是“RAG”显示)，这取决于该设备的状态是停机(红色)、未知或可使用但受损(琥珀色)、还是正常运转(绿色)。这些工具在发现设备之后继续轮询它们，以便RAG显示可以随着设备可达性改变而改变，从而给操作人员提供关于网络设备状态方面的改变的迅速、可容易辨识的通知。

在20世纪九十年代，由于微处理器变得不那么昂贵并且更加强大，所以将附加智能和存储器嵌入到网络设备中成为可能。结果，使网络设备在它们可以辨识它们自己的内部状态(诸如它们的内部处理器和存储器状况和利用以及它们的网络端口的状况和利用)方面更加“自知”成为可能。此外，新近可用的自知性数据是通过称作MIB的设备控制块中的标准正文来正式地加以组织的。

同时，诸如TCP和APPC此类的对等协议层出不穷，这不仅允许NetView^TM和OpenView^TM工具更加容易地从网络设备检索这种新的和附加的数据，而且为了向操作人员进行更加快速的问题通知，还允许新近智能网络设备向管理工具发送非请求型的、重要的状态信息。当20世纪九十年代接近结束千禧年过去的时候，网络和系统管理研究和开发人员继续沿着通过增强基于微处理器的设备的自知性来改进系统管理的道路前进，甚至使该规程正式化，并称其为“自主性”。

诸如e-Health^TM和Vitalnet^TM的工具展现了与控制台工具的相似的发展历史。像控制台工具一样，e-Health^TM和Vitalnet^TM能够检索MIB数据。然而，与预期提供网络的实时管理的控制台工具不一样的是，这些工具通常用于趋势报告。这些工具的典型用途有，而且继续是，开发“热图(heatmap)”报告。这些报告识别其利用在某指定时期中超过某预置阈值的网络链路。通常，热图报告的目的是双重的：第一，识别可能是性能差的原因的利用过热点；以及，第二，识别可能要求速度升级的链路，特别是由于这样的升级常常需要在实际安装之前就安排和计划好。

另外的一类问题是“逻辑问题”。这些包括设计、定制以及配置问题。一般来说，诊断这些类型的问题的工具还未开发出来。目前实际可用且可能能够建立最优网络路由选择的模型的工具的实例，诸如OpNet^TM，其运行需要大量的时间以及专门技能，并且不是通用的。

关于网络管理的技术现状，自诊断自主性和可达性测试的加入已改善了损坏设备的诊断的成功率和速度。多年来没有较大改变的通常已知的热图概念一般在涉及过度利用(overutilization)的辨识和防止问题上保持有效。但是，这些工具不是百分之百有效的，当这些工具未能诊断的问题出现的时候，解决工作常常变得混乱并且具有不可接受的持续时间。之所以这些问题变得难以控制的原因常常是因为，一旦这些工具未能提供针对一个问题的结论性诊断，就依然没有针对诊断和解决的有序过程或方法，结果是沿用“所有”可能的诊断途径，这拉长了解决时间并且增大了使问题更复杂的风险。

根据上文，目前网络问题确定的技术可能遇到了一个或更多的问题。例如，当有性能或停机问题的时候，它可能是由物理问题、逻辑问题或容量问题所引起的。物理和逻辑问题的补救一般需要故障组件的替换或修复，而不管它是设备中的主板(logic board)还是一个版本的软件。容量问题的补救一般包括增加容量或调节系统调谐。当诊断工具未能获得停机或性能差的实例的真正原因的时候，问题解决工作常常回到这样的各种尝试，即诸如交换卡、清洁电缆、改变软件和微码级别、增加容量、重新调谐系统等等的全面试错法。所希望的是这些改变(通常一次进行一种)中的一个可以给出肯定的结果。

这种方法的缺陷包括花费太多的时间，它是有风险的，而且它倾向于使硬件、软件和系统人员彼此竞争。更具体的是，在管理工具未能导致现有问题的正确诊断的时候回到散网式方法(shotgun approach)，存在这样的风险，即对系统进行的试错补救努力改变可能使状况更糟。例如，当存在难于诊断的硬或间歇性问题的时候，补救努力可能包括重插拔卡和交换或清洁电缆，而这些努力中的每一个都使该问题加重。作为说明地，重插拔卡可能导致插针弯曲，从而使问题恶化。类似地，清洁电缆连接器、改变微码级别或交换卡有将新问题引入系统的风险。类似地，交换电缆路径来测试替换的连通性可能需要改变电缆交换设备设置，这是一个易出错的过程，其可能会引起其他的问题而使状况更糟。

目前用于故障诊断的方法通常包括，例如，检查RAG控制台(例如NetView^TM或OpenView^TM)上指示损坏或状态未知的设备的红色或黄色图标，并修理损坏的设备。也可以检查已知的过度利用的链路的热图报告，以及沿着涉及问题的路径检查过度利用的MIB值。作为对策，可以制定，如果存在资源的过度利用就增加容量或减少通信量。如果通过前面的两个动作中的任何一个都没有修复问题，那么就可按任何由管理所认可的顺序，对系统和系统的度量进行改变(其中对系统的改变包括诸如重插拔、交换和替换硬件以及修改软件和微码此类的动作；而对网络的数学或度量的改变包括增加容量或改变调谐)。在目前的方法中，如果管理控制台和MIB工具的使用未能带来解决方案，那么在对策的希望中，可无特定顺序地尝试有风险且费时的探查和推测性的系统改变。

发明内容

在本发明的一个方面，提供一种用于管理网络的方法。该方法包括步骤：对具有一个或多个网络组件的网络的性能建模，以根据网络速度、等待时间、调谐和利用的任一组合定位数学上受损的网络组件的实例；以及根据建模对与该一个或多个网络组件相关的一个或多个参数进行修改，以改善网络性能。

在本发明的另一方面，提供了一种用于管理网络性能的方法。该方法包括步骤：创建具有一个或多个网络组件的网络的基线网络模型，并将MIB数据添加到该基线网络模型中，以创建当前条件的模型。该方法还包括步骤：查验该网络中的路径以检验当前条件的模型，根据通过查验检验过的当前条件的模型识别该路径的最优调谐，以及根据识别出的最优调谐修改该一个或多个网络组件中至少一个的一个或多个参数，以至少沿着该路径改善网络性能。

在本发明的另一方面，提供一种用于管理网络的系统。该系统包括：用于对具有一个或多个网络组件的网络的性能建模，以至少根据网络速度、等待时间、调谐和利用中的任何一个定位数学上受损的网络组件的实例的装置；以及用于根据上述建模对一个或多个网络组件进行修改，以至少沿着该网络的一路径改善网络性能的装置，其中该一个或多个网络组件包括网络组件参数和网络组件配置中的至少任何一个。

在另一方面，提供一种计算机程序产品，包括计算机可用介质，该介质具有包括在该介质中的可读程序代码。该计算机程序产品包括至少一个组件以对具有一个或多个网络组件的网络的性能建模，以至少根据网络速度、等待时间、调谐和利用中的任何一个定位数学上受损的网络组件的实例；以及根据上述建模对与该一个或多个网络组件相关的一个或多个参数进行修改，以改善网络性能。

附图说明

图1是本发明示例性环境的实施例的框图；

图2A和2B是经由路由器的两跳客户机与服务器连接的示例性实施例；以及

图3-10是示出使用本发明的步骤的实施例的流程图。

具体实施方式

本发明总体涉及用于使用网络资产管理数据(诸如来自用户文档、路由跟踪(Traceroute)和其它探查发现命令或技术，以及来自例如网络管理工具VitalNet^TM和Concord)来创建网络连通性的数据库模型的系统和方法，其中网络资产管理数据包括诸如设备类型、位置以及链路速度的属性。这个模型包括网络设备以及连接它们的通信链路的描述。每一个这样的设备-链路-设备连接称为一个“网络跳”。包括在该数据库的初始设置中的是这样的数据，根据该数据可以执行网络的基线数学分析；包括链路端点位置(或距离)、设备位置和设备等待时间。查验(pinging)是使用较长和较短的彼此隔离且以短脉冲串传输的查验包来执行的，以为基线网络性能的分析提供数据，该分析是独立的文档和基于MIB的基线分析。

通常，“网络基线性能”指的是在处理单个新用户执行单个、特定的任务的工作中不存在其它用户的网络(即，网络路径)的性能。这样基线化回答这样的问题，即诸如“每一个端到端网络路径上的最佳可能的文件传输速率是多少，以及每一个端到端网络路径上的最佳可能的网络级事务响应时间是多少？”。

除了基线性能之外，该系统和方法还提供对网络的当前性能的分析。“网络当前性能”一般指的是在处理单个新用户执行单个、特定任务的工作中在其当前利用下的网络的性能。这样确定网络的当前性能回答了这样的问题，即诸如“每一个端到端网络路径上的当前可达到的最佳可能的文件传输速率是多少，以及每一个端到端网络路径上的当前可达到的最佳可能的网络级事务响应时间是多少？”。

除了确定网络的基线和当前性能水平之外，本发明的系统和方法还能够对网络的潜在改变建立容易和准确的“假设分析”模型，这些对网络的潜在改变诸如影响其他通信流的性能、链路速度增加或客户机和服务器之间的距离的改变。通过提供对于因为队列堵塞、传播延迟或网络通信流的较慢串行化或处理而正在使网络连接之上的总性能变慢的组件的快速识别，使这一级别的分析能力构建到网络资产数据库中也有助于问题分析和解决。

一旦根据网络资产数据库构造了网络的模型，并且通过对查验结果或用户通信流的分析而使其得到了验证，它就可以使用在网络管理和问题解决方法中，其中系统控制台识别损坏的设备(如果存在任何损坏的设备的话)，然后该网络模型识别任何的性能问题。通过高度成功地识别性能问题，使用该新方法能够将基于问题解决目的而执行的有风险的试错法系统改变保持在最低限度。

因此，本发明为一个或多个网络段(例如一个或多个跳跃或端到端)提供度量和观测到的性能数据，以便可完成网络中削弱了的性能的识别，并且可以通过设置合理的服务级别协议和期望来避免问题。本发明还提供建立调谐需求，并迅速识别性能差是否由网络所引起，如果是的话，则提供该问题在该网络中出现的所在以及出现的原因。另外，本发明可以提供基于所建议的对网络中一个或多个组件的改变的性能影响的预测，从而有助于利用有效的网络改变来补救问题。

为了改进该技术，提出了一个新的不同点，其中系统问题被特征化为数学上或非数学上的。本发明的系统和方法使用功能上完全数学的系统特征化，以便创建用于问题辨识和解决的系统，其中对物理和逻辑系统组件的破坏性改变只在必要的时候才执行。“数学”问题指的是由容量、利用、等待时间或调谐问题所导致的性能问题。

这样，网络性能分析提供了增强网络故障诊断技术，以便限制在问题确定和修复期间执行的破坏性系统改变的机会。在该新的方法中，当网络控制台未能提供准确诊断的时候，建立网络容量和调谐的完全数学的模型可以用来修复或排除该问题的潜在“数学”原因。如果数学上的改变被认为得到批准(例如，容量的增加或调谐的改动)，那么该改变就可按其将成功的高度置信度来加以执行。本发明的系统和方法是对当前方法的改进。在本发明之前的方法中，当RAG控制台未能识别问题的时候，该问题可能是数学上的(即，调谐或容量)，否则该问题就可能是需要修复或以其他方式改变的资源，并且该问题的工作会变得混乱。在本发明中，对于更加困难的问题(例如，没有被RAG控制台识别的那些)，该系统和方法可以识别该问题是否是数学上的，从而使风险降低并且增进了问题解决的速度。

作为一个实例，假设在网络连接的中间存在专门的存储转发中继设备。进一步假设它不包含标准MIB，因为它是新近开发出的技术，并且因为它可能正在执行专门的功能，诸如从操作系统通道协议转换到广域网协议。最后，假设它的缓冲区已经依照厂家提供的默认值而加以设置了，并且所分配的缓冲区的数目是不够的且其正导致连接失败。通常，这个问题的数学方面(例如分派适当数目的缓冲区)可能直到种种有风险、费时的物理和逻辑动作(诸如换出硬件和软件组件或电缆清洁和替换)已经被执行了才由技术人员所解决。

但是，本发明的系统和方法通过提供由下面描述的分析方法从网络资产管理和查验-测试数据导出的网络的数学分析，以便可以得知连接上的传播延迟、流速度、会话速度以及设备等待时间，而提供了一种改进的解决方案。根据此数据，如下所述的，可以容易地(或甚至自动地)计算窗口大小和缓冲区大小要求。因此，缓冲区大小的调谐要求可以容易地获得，并且使问题可以容易得到诊断或可能避免其开始等，而且在这个实例中大量的破坏性交换、重插拔、重新定制、清洁等等可得以避免。

在某些方面，该用于问题解决的系统和方法提供至少下列内容：

-检查RAG控制台中指示损坏或状态未知的设备的红色或黄色图标(例如NetView^TM或OpenView^TM)。

-检验匹配影响终端用户的问题的简档(profile)的网络容量或调谐问题的数学模型。

-如果问题未由前面的动作所修复，则进行系统改变直到该问题被修复，其中的系统改变包括例如换出卡、换出设备、改变微码、交换电缆、清洁通信电缆、改变应用程序以及重插拔卡。

图1是本发明的示例性环境的实施例的框图，该示例性环境总体由参考标号100表示。环境100可以包括用于运行性能跟踪、模型建立和基线软件的性能管理服务器105。还可以包括用于显示所监控的网络部件和状态的仪表板110(即，显示器)，以及用于在性能管理服务器105的控制下存储性能和状态数据的性能数据库115。

该示例性环境100还可以包括一个或多个网络链路125A-125D以及适合于它们在该网络中的位置和功能的各种网络组件120A-120I，诸如网络设备、路由器、应用、桥、网关、服务器等。网络组件120A-120I中的每一个也可以包括依照每一个网络组件的类型和职责由该组件进行维护的管理信息库(MIB)。

在本发明中，可以对网络中的每一跳(即，整个网络中的每一跳或端到端路径中的每一跳)进行分析，以提供在一个时期段中与每一跳的性能有关的度量。正如本领域的普通技术人员会认识到的，这些度量可以包括，但不限于：

-与该跳相关的速度，其可以包括理论的和参数控制的速度。

-传播延迟。

-设备等待时间。

-利用(例如，以测量到的与理论的百分比或比率)。

-丢包率。

-入字节速率。(在特定时间间隔期间在设备的网络接口上接收到的字节或八位组数。该时间间隔是由网络管理设置的MIB刷新率，其通常以5、10或15分钟来设置。)

-出字节速率。

-入包速率。(在特定时间间隔期间在设备的网络接口上接收到的包数。)

-出包速率。

-跨跳的查验时间，其可以包括对较小和较大包的单独查验时间。

这些度量中的利用、丢包率、入/出字节速率、跳查验时间以及入/出包速率随时间而变化。其余的度量(即，速度、等待时间、传播延迟等等)通常保持不变，除非被有意修改，这可能是由网络工程师进行的。

根据这些度量的值，可以针对给定跳来计算性能计算(即，一个或多个性能定级)。一旦计算出，就可以将多跳的各个跳值结合地用来确定网络路径的端到端行为，如此以提供对网络的不同方面的理解，其中包括如下方面：

(i)特征化不同类型的应用，并计算它们将如何在网络上执行。

(ii)哪一个网络组件可能形成削弱性能的原因(例如，瓶颈节点)以及该组件可能引发削弱性能到什么程度。

(iii)对该网络中任一链路上的任一组件的改变(例如，升级或替换)可能对该整个端到端路径的性能有什么影响进行预测。

通常，网络为了支持分布式应用而存在，分布式应用可以特征化为运行在某点要求跨网络向伙伴传输数据的代码的那些应用。通常，数据传输在用户应用程序(例如，开放系统互连(OSI)层7)例如对数据进行缓冲并且发出“SEND”命令的时候开始，其中“SEND”命令将要通过API(例如，OSI层6)传输的数据转发到诸如传输控制协议(TCP)或网际控制报文协议(ICMP)的功能，以便开始为跨网络向伙伴传输数据而格式化数据的过程。

应用建档(profiling)可以用来确定由应用呈现给网络的通信流的特性。在某种意义上既对业务线(LoB)人员来说有意义的又可以由网络人员测量的对应用通信流的实例的特征化使得网络人员能够将网络管理工具收集的数据变成关于该网络满足LoB需求的程度的准确信息。在一个方面，本发明的系统和方法通过将有关网络组件的数据处理成关于应用性能的有意义的信息，而提供将网络性能数据与LoB需求相关联。

因为应用建档可能直接与使网络性能与业务需求相互关联有关，所以应用建档的准确描述也可以由本发明的系统和方法来提供。根据本发明，可以将应用建档为包括工作单元组，为了完成，每一工作单元要求特定数量的字节以特定数量的换向(turnaround)(跨网络的行程)传送和接收。要由应用执行的工作单元的实例包括，但并不限于：

-会话工作单元，其包括具有“m”字节的单个传送以及“n”字节的单个接收(例如，TN3270查询/响应)

-多换向会话工作单元，其包括“p”次换向，具有所传送的“m”字节和所接收的“n”字节的总数(例如，使用确认和“get-next(获得下一个)”功能的基于SQL的数据库行的检索)

-流工作单元，其由要传送的“n”兆字节的数据组成(例如，文件传输应用)

该系统和方法还提供要加以特征化的网络组件，以便可以在下列的一种或多种情况下提供支持应用工作单元的它们的性能的计算：

-当提供新的工作单元的时候，基线条件是正经历零利用的时候的组件的特征化。

-当向正经历当前(例如，已知的)利用水平的组件呈现工作单元的时候，当前条件该组件的特征化。

-假设分析条件是组件的特征化，在这些组件中在改变的条件下的工作单元的性能是为了建模的目的而加以计算的。

根据本发明，网络组件性能计算可以基于组件的固定度量(例如，速度、设备等待时间和/或距离)和可变度量(例如，利用、平均包大小和/或丢包率)来进行。此外，可以根据组件的固定和可变度量来计算组件在基线、当前以及假设分析条件下执行工作单元的能力。组件的固定度量通常是从资产管理数据中导出的，并且其可以在对资产进行改变的时候改变。可变度量可从MIB数据中导出，并且其在每当存在MIB的SNMP“get(获得)”时可以改变，这通常大约每5至15分钟便发生，但这是可以变化的。应用简档特性也可以得自于踪迹、应用通信流分析软件、应用文档或应用设计者。一旦已经建立了基线和当前性能的网络模型，便可以用这样的方法来帮助网络问题解决，即在该方法中系统控制台和数学模型被用来定位损坏的设备和容量/调谐问题，以便限制有风险的试错类型问题解决并且使整个网络可用性最大化，同时使操作和设备成本最小化。

仪表板的考虑因素

LoB的管理人员和网络的管理人员可能根据他们的目标或关心区域要求反映状态的不同仪表板(例如，110)。例如，如果一条路径中的链路故障并且具有适当的性能的再生路由承载着用户通信流，那么从网络管理员的角度看存在红色条件(即，链路故障)，而从LoB管理员的角度看存在绿色或黄色条件。或者，如果存在丢失或延迟的通信流，则LoB管理员可以看到黄色条件。

由于LoB通常直接或间接地支付网络费用，所以LoB的管理通常希望了解网络支持它们的业务的有效程度。LoB的管理可能希望了解网络始终如一地以适当安全级别联系所有期望伙伴，该安全级别可能是为了可靠性、弹性、性能以及成本有效性而由服务级别协议(SLA)所强制的。

响应目前的LoB管理需要，网络管理员可以部署具有链路和组件冗余的防火墙保护的IP网络，如普遍知道的那样。可以通过发送查验(例如，回送包)以及收集MIB数据(例如，设备控制块计数器记录)来实现网络性能的度量。例如，可以由性能管理服务器105来控制度量过程，而结果被存储在性能数据库115中。

查验常常用于回答关于可用性和性能的问题，因为当查验不能成功地进行它们的往返行程的时候，通常这是某网络组件的不可用性的结果，而当查验确实成功的时候，可以存储它们的往返行程时间结果，随后加以比较，以便查明在查验传输时的性能水平。但是，与常常是依靠IP网络的TCP协议的用户应用通信流不同，查验是IP之上的ICMP协议，并且其倾向于经历延迟和丢弃，而这并不是实际用户通信流正经历的表示。尽管事实是查验不提供网络性能和可用性的确切度量，但是查验在很好地执行和表示网络的性能和可用性以使其成为重要价值方面是容易且低成本的。

尽管查验最经常被执行以反映端到端性能，但MIB数据反映在用户指定的时间间隔期间跨网络的网络逐个设备和逐个端口的状态。对于所特别关心的性能和容量管理，MIB按时间间隔收集并记录通信流和丢包率，根据这些通信流和丢包率可以容易地推断出资源利用。如果查验正被撤消，或如果查验往返行程时间正花费比平常要多的时间；那么MIB分析就可以沿着该查验路径来执行，以沿着该网络路径确定哪个特定组件(如果有的话)正遭遇丢弃或过度利用。不管是独立还是与查验协作的MIB数据都因此作为问题、容量以及性能分析的基础。查验分析用来提供用于基于网络资产数据库和MIB数据的数学分析的检查机制。

网络性能可以依照度量来定义。例如，可以将在9：30AM执行的花费835毫秒完成的查验可以与7AM的562毫秒的查验进行比较。可以标记其利用达到峰值92％或其它预定阈值的链路，以便进行升级。此外，指示web应用响应时间是工业的平均标准以下的第三方度量可以触发对边缘网络服务的提供者的调用。在所有这些实例中，技术分析员或管理员都使用度量作为决策的基础。

本发明的系统和方法提供根据网络度量提取正确的推断，不管该推断涉及问题、调谐、服务级别还是所建议的改变的建模。该系统和方法提供至少以下各项：

-确定单或多跳连接的网络度量，

-计算连接的度量对它所服务的各应用的复合影响，

-随后是用于全面、经济的问题解决的算法过程，以及

-提供一种用于准确确定在哪里以及何时在基础结构方面投资的方法。

进一步地，可以包括能够捕获踪迹并存储在接口上发现的所有包的新工具，从而扩展并最大化当前工具投资的使用，同时在有意义的地方和时间提供有序的投资路径并实现更新工具技术。此外，该系统和方法提供了使网络服务级别管理与业务需求匹配的基础，并且提供了智能、准确和前摄的问题避免和解决的基础。

收集网络性能数据

网络性能数据通常来自于一个或多个可包括查验、MIB数据、踪迹数据以及用户文档的源。

查验

查验(ping)包括由ICMP发送和接收的回送包，ICMP也计算查验的总的往返行程时间。由于ICMP通常是几乎所有TCP/IP栈的组件，所以如果用户可以访问能够发送查验的设备，并且如果查验不是被路由器过滤器所阻塞的，那么几乎所有IP设备都响应此设备的查验。简而言之，查验一般是各处可用的，它是低成本的，并且它容易使用。

一种查验策略是使用普遍知道的“Traceroute(路由跟踪)”命令来确定例如沿着一条路径的路由器的出现和顺序，然后根据该确定，沿着该路径将查验从测试站源发送到每一路由器，然后发送到端点目标。以这种方式，可以沿着该路径观察延迟的增大。

一般而言，如果对一个目标执行多个查验，那么该组查验中具有最小往返行程时间的查验表示通过该网络最佳可能的时间，因此，表示基本的基准网络物理特性。由于所有到该目标的查验都历经相同的基准网络物理特性，所以如果一个查验花费比最小时间多的时间来遍历该网络，那么所有额外的时间包括花费在等待来自繁忙网络设备的服务的网络队列上的时间。

尽管查验可能是丰富信息性的，但是还存在应该加以考虑的限制。每一个限制反映了基本事实的某个方面，该基本事实是查验不是终端用户通信流。首先，查验开销本身可能为网络增加压力。测试表现较差且可能已经过度利用的网络的查验可能助长差性能。第二，使路由器作为目标或起点的查验测试可能显示出显著高于网络中实际用户通信流正接收的等待时间和丢包率。这更高的等待时间通常是因为与由路由器处理的用户通信流不同，到路由器的查验通过路由器的ICMP栈，查验在其中是以很低的优先级备处理的。第三，对于到终端站目标的查验测试来说，如果实际用户应用正在TCP上运行，那么查验测试只能够通过度量ICMP性能来模拟端到端的性能。此外，用于查验ICMP通信流的路由器路径可能不同于由用户TCP通信流所采用的路由器路径。第四，资源的查验通常是一般每隔几分钟便发生。如果出现持续一分钟或更少时间的通信流的尖峰，那么查验可能不能识别它们。这个事实使得查验方法对于某一高度的简档性能问题(诸如中介交易厅的多点传送微爆以及影响web站点的临时通信流尖峰)的诊断效果降低。

MIB数据

通常，MIB数据驻留在路由器以及其它网络设备的控制块中。MIB数据的实例可以包括在十五分钟间隔期间在接口入字节和出字节的计数以及路由器CPU利用的度量。由SNMP来轮询设备MIB，以便收集供在分析或趋向中使用的性能数据。

但是，与不是用户通信流的查验不同的是，对于网络分析员来说，MIB有这样的优势，即包括作为实际用户通信流和设备状态的计数和度量的统计。但是，尽管查验提供了用于获得端到端性能的描述的快速且容易的手段，但MIB仅给出了个别组件的详细视图，并且当前没有根据MIB数据导出端到端性能评估的系统的方法。该系统和方法提供了一种用于使用MIB数据分析通信网络(即，其端到端网络连接)的分析方法。此外，该系统和方法提供了使用查验分析作为检查机制来克服已知的MIB数据的不准确性。本发明进一步的目的是使用新的MIB分析方法的结果来克服已知的查验分析中的不准确性。

单或多跳网络路径的数值分析

本发明的系统和方法提供对网络路径执行数值分析，其包括至少沿着该路径确定速度、长度、设备特性以及利用，这可以包括单跳路径的数值分析和/或多跳路径的数值分析。

单跳路径分析

基于下列两个原因，单跳分析可能是有价值的。第一，通常，多跳终端用户连接的任何详细分析都需要对组件跳的理解。第二，根据多跳端到端连接的各个跳的和可以构造该多跳端到端连接的准确视图。但是，确定多跳连接上的网络性能可能会需要额外的考虑，这将在下面的多跳分析部分中描述。

单跳连接性能可以由四个度量来特征化，如下面进一步论述的那样。这四个度量包括链路速度、传播延迟、设备等待时间以及利用(其根据数学函数与性能影响排队相关)。

链路速度

链路速度可以通过对诸如调制解调器(模拟链路)、数字服务单元(DSU)/信道服务单元(CSU)(数字链路)、网络接口连接(NIC)(LAN)或吉比特接口转换器(GBIC)(光纤信道)的连通性的计时来确定。速度计时确定商用机器的链路输出队列上的字节流被切为位并放置在网络上的速度。使所发送消息的字节变成位所花费的时间称做串行化时间。消息的串行化时间的公式可以数学地规定为：

(串行化的字节＊8)/链路速度＝串行化时间 (等式1)

例如：使用19.2kbps调制解调器跨单跳网络单向发送的1200字节消息得出这样的计算：

8＊1200/19200＝9600/19200＝0.5s。

传播延迟

传播延迟与示例性NIC、调制解调器，DSU/CSU或GBIC所传播的信号行进的距离成比例。在广域网中，信号通常以略小于光速的一半的速度行进，用于估算广域网连接的传播延迟的适宜公式可以由下式来描述：

(链路距离/186000)＊2.1＝传播延迟 (等式2)

例如，连接纽约市与旧金山的数据链路(大约2582英里的距离)的传播延迟可以通过下式来计算：

(2582英里/186000)＊2.1＝29ms单向传播延迟，估算。

设备等待时间

设备等待时间是沿着传输路径的设备处理包所需的处理时间。对于处于连接的中间的路由器来说，包处理可以包括接收包、执行校验和处理以及确定通过哪个端口来转发该包。在第一代路由器中，这一处理的一部分是由路由器的CPU来执行的，并且每个包的平均处理时间是4毫秒。更多近来的路由器在没有CPU介入的情况下处理包，设备等待时间通常小于1毫秒，即使在使用诸如QoS(服务质量优先级排队)的复杂功能的时候也是如此。类似地，在其TCP或ICMP层可能涉及到传输中的网络的端点处，在比较老的设备中普遍使用3或4毫秒设备等待时间，但是在目前的终端设备中，设备等待时间一般也显著小于1毫秒。一个值得注意的例外是在查验路由器的时候。当路由器作为查验的目标的时候，它的处理器通常涉及到ICMP包的处理之中，并且这是以最低的优先级进行的。在被查验的时候，路由器通常显示出比当它们仅作为通信流的网中转发器时更高的等待时间以及更大比例的丢包率。

利用

利用影响用户通信流，因为当提供服务的设备已经被其它设备使用时，则到达该服务器的新通信流通常必须在服务的队列中等待，直到前面的通信流已被处理为止。利用对单跳连接的影响是直接的。凡是由其它设备使用中的设备对于新用户都不可用。如果19.2kbps链路的利用是30％，那么该链路的70％是可用的，所以可用带宽是0.7＊19200＝13440bps可用带宽。基于可用带宽计算性能给出了包括串行化时间加上队列影响的结果。例如，如果19.2kbps的链路被50％利用，那么对于进入该跳的1200字节包的新通信流来说，该链路上的可用带宽要求：

0.5＊19200＝9600bps可用带宽的排队和串行化时间，并且由于1200字节包的长度是9600位(1200字节＊8位)，所以队列加串行化时间的公式是：

消息大小/可用带宽＝队列时间加串行化时间 (等式3)

结果导出：

9600位消息/9600bps带宽＝1秒队列时间加串行化时间。

此外，由于队列时间加服务时间等于1秒，并且由于链路速度是19200bps，所以当1200字节消息被串行化为9600位的时候，串行化花费了0.5秒来进行。由于串行化加队列时间合计为1秒，并且由于串行化部分是0.5秒，所以队列时间因此也是0.5秒。

多跳路径分析

终端用户通信流实际上常常改变，并且通常遍历它的端到端网络路径中的几个跳。为了更正确地设置服务级别协议阈值并正确地对网络数据应用数值分析，有必要理解不同类型的用户应用怎样在多跳网络中表现。

图2A和2B是经由路由器的两跳客户机到服务器连接的示例性实施例。图2A示出了具有相同速度(即，9.6kbps)的两跳220和225的两条链路，图2B示出了一个类似的配置，而第二跳230具有不同于第一跳220的速度(即9.6kbps)的速度19.2kbps。

参照图2A，如果在客户机205处的用户发送1200字节包到服务器215，那么跨该连接的端到端网络速度(串行化速率)因此是4800位每秒。但是，从客户机205跨该网络发送到服务器的文件的网络速度(串行化速率)是9600位每秒。

图2A的这两个表面上相等的实例的结果是不同的(下面论述了原因)，这意味着对于多跳网络来说，从端到端的观点看，对于问题“网络的速度是多少”来说没有单个“正确”答案。答案取决于应用的类型，可以对于会话、突发以及流应用有所不同。这对于服务级别协议来说具有深刻的含义。

这两个不同的示例性应用的不同速度的原因可以这种方式找到，即其中当代路由器处理包。在当代路由器接收包的时候，路由器在处理包之前接收整个包。路由器可以执行代数校验和处理，来确定是否有任何位已丢失或被破坏。如果被损坏，则该包被简单地丢弃。如果未丢失或被破坏，那么就可以执行一些附加处理，以从正确端口路由出该包以使其沿着该路径移动。可以引发进一步的处理来处理最大传输单元(MTU)段或QoS排队。在以前，此处理的总和称为“设备等待时间”，而在最新一代的路由器中，此处理常常在亚毫秒时间内进行。

尽管亚毫秒设备等待时间不是很大的问题，但路由器在处理包之前引入整个包的事实是相当重要的，因为它意味着路由器正执行存储-转发操作。这含义是，在多跳、层3网络中，在每一跳处重新串行化该包。所以，上面图2A的表面上对立的结果可以得到解释，因为4800bps结果来自于这样的事实，即当客户机205发送9600位包的时候，存在使它到达路由器210所需的一秒串行化时间。在路由器210接收并处理该包之后，该路由器的调制解调器重新串行化该包，并将它转发到服务器215。这重新串行化花费了另一秒。在这个示范性网络中，花费了合计两秒的端到端串行化来发送9600位包。两秒的时间来执行9600位的工作意味着端到端串行化速率因此是4800bps。

但是，对于诸如文件传输的流应用来说，网络的串行化速率接近于连接路径中瓶颈设备的速度。在图2A的第二个实例中，有两个9600bps链路，它们包括两个相等的瓶颈，因此从流应用的观点看，该网络的速度是9600bps。

多跳网络中速度的另一观点是距离之上的包处理(PHOD)。PHOD度量的合适载体是1000字节查验的端到端处理，这可以称为网络的“1kPHOD速度”。作为一个实例，假设网络具有3000英里的端到端距离，其中包括两个T1跳，并且两个终端站和该网络中间的路由器各自具有500微秒设备等待时间。假定该网络以零利用运行(即，没有其它用户的通信流)，则往返行程查验时间和1kPHOD速度可以特征化如下。

往返行程时间是“两倍的”单向时间(假定输出和输入路径相同)。单向时间包括单向穿越该路径所招致的设备等待时间、传播延迟以及串行化时间的和。在该情况下，在该单向路径中：

设备等待时间总数为3＊0.0005＝0.0015秒；

传播延迟是(3000英里/186000bps)＊2.1(调整系数)＝0.0339秒；

第一跳的串行化时间是1000字节＊8位/1536000(通常且已知可用的T1bps)＝0.0052秒；

单向路径上的第二跳的串行化时间是1000＊8/1536000＝0.0052秒，所以总的1向串行化时间是0.0104秒(第一跳加第二跳)；

总的单向查验时间是：0.0015+0.0339+0.0104＝0.0463秒；

总的往返行程查验时间是(双倍的单向时间)＝0.0926秒；

PHOD速度＝所完成的工作/所用时间。所以1k包的往返行程PHOD是：

1k PHOD速度＝1000字节＊2向＊8位/0.926＝16000/0.0926＝172786bps。

同样，如果对长800英里但是在其它所有方面与前面的实例相同的网络进行测试，那么该网络的1000字节单向查验时间应该是0.0209秒，总的(往返行程)查验时间应该是0.0418秒，这个(除了距离之外都相同的)连接的1k PHOD速度应该是382775bps。

网络分析员常常参照跨网络的64字节查验结果来定义网络的等待时间。由于许多服务级别协议是基于短(常常是64字节)查验的往返行程查验时间的，因此单个短查验表示沿着该路径的(i)设备等待时间、(ii)串行化、(iii)传播延迟以及(iv)排队的沿着该路径的往返行程时间。但是，相反，沿着一条路径的一“大”组查验中的最佳查验时间表示(i)设备等待时间、(ii)串行化、(iii)传播延迟的往返行程时间，而没有任何排队。

此外，尽管查验提供会话应用(诸如TN3270查询-响应)如何跨网络连接表现的合理表示，但是各个查验并不自己提供用于估计流应用(诸如文件传输协议(FTP))的性能和它们在相同连接上的表现的合理手段。上面PHOD速度的基于查验的计算实例将此示出的很清楚-3000英里网络具有172.8kbps的PHOD速度，另外相同的800英里网络具有382.8kbps的PHOD速度，尽管实际上这些网路中的每一个的流速度(大文件传输可以得以处理的速度)是相同的，接近T1速度1532kbps。

因此，可以推断出跨适当调谐了的连接的流应用是基本上不受跳的数量和距离的影响的；然而，查验和会话应用可能对跳的数量和距离是高度敏感的。当设置然后度量对服务级别协议的符合性的时候，查验最多有时准确地表示终端用户体验的一部分，而很少准确地描述整个范围。

通过查看端到端利用可以进一步举例说明查验的限制。考虑图2B的实例，图2B示出了具有不相同的链路速度(即，9.6kbps和19.2kbps)的两跳网络220和230。连接的流速度有效地是它的瓶颈设备的速度，所以在这一连接中，流速度是9.6kbps。该网络的会话速度可以通过确定包的串行化速率来计算，而不用考虑设备等待时间或传播延迟。可以通过用跨该网络的包的总串行化时间来除该包中的位数，来计算会话速度。在没有一般性损耗的情况下，考虑1200字节包。对于总的1.5秒串行化时间来说，它的9600位具有在第一跳上的1秒的串行化时间以及在第二跳上的0.5秒。所以，根据本发明，该网络的会话速度是6400bps，如数学地示为：

所执行的工作/串行化时间＝9600位/1.5秒＝6400bps。(等式4)

例如，假设平均起来在十五分钟间隔期间，在该网络的9.6kbps部分(例如，链路220)上具有0％的利用，而在该网络的19.2kbps部分(即，链路230)上具有50％的利用。那么，根据该系统和方法，从会话应用的观点看，可以如下面的解释所示的那样来理解和计算当前可用带宽。

由于1200字节包跨具有0％的利用的9.6kbps跳的串行化时间是1秒，而跨具有50％利用的19.2kbps跳的串行化时间也是1秒，并且因为当前可用带宽是9.6kbps(即，平均起来，19.2kbps设备的50％是对用户可用的)，那么在这个示例性当前利用之下，对于1200字节包来说，端到端串行化时间是2秒。因此，基于该1200字节的包大小：

当前可用的会话速度＝9600位(所完成的工作)/2秒(总时间)＝4800bps。 (等式5)

由于该网络的会话速度是6400bps(根据等式4)，所以端到端会话利用是：

(1-(当前可用的会话速度/会话速度))＊100＝

(1-(4800/6400))＊100＝25％会话利用。 (等式6)

因此，从流应用的观点看，当前可用的网络瓶颈是9600bps，这是在0％利用的9.6kbps跳(即，链路220)上当前可用的，也是在50％利用的19.2kbps跳(即链路230)上当前可用的。从流应用的观点看，当前利用是0％，因为该网络的流速度＝9600bps，而当前可用的网络速度是9600

bps，所以流利用＝(1-(9600/9600))＊100＝0。

根据这个示例性实例，一个网络跳上的利用对流和会话应用通信流的端到端影响非常不同，这意味着从端到端的角度看，在多跳网络中不存在表示利用的单个数值。而是，根据本发明，通过用于网络的会话和流速度的单独计算，使得利用得以更好地描述。

从SLA的角度看，清楚的是，最多反映会话通信流的行为的方面的查验可以不单是终端用户体验的全体的SLA构造或SLA监视的坚实基础。类似地，根据MIB数据推断个别组件的利用对端到端连接的性能影响常常是不可能的，并且根据MIB数据来计算设备等待时间或传播延迟是不可能的。该系统和方法合并查验和MIB数据，促进了该技术，提供了调解这些缺陷的全面视图，并且提供了SLA信息和评估的坚实基础，其好处是还提供了问题检测、问题分析、调谐以及容量计划的坚实基础。

使用MIB数据和查验结果的网络数值分析

为了管理网络，所期望的是理解支持终端用户应用的网络的基线能力和在当前(负荷)条件下支持终端用户应用的网络的能力。下列数据输入提供了确定这种信息的基础：

-对要由构成网络路径的特定路由器和端口管理的该路径的识别，

-对在定时间隔期间在这些端口处的MIB数据、每定时间隔入和出字节以及每定时间隔丢失的包的收集，

-较长或较短长度彼此隔离地进行的查验，其中较长的查验不超过沿着该路径的任何接口的MTU大小，以及

-指定在每一个接口处的(输入和输出)速度的用户文档或MIB数据。

给定这一输入，该系统和方法提供可以对每一个这样的路径执行的分析，该分析计算下列输出，包括：

-路径的基线和当前可用的流速度，

-网络的基线和当前可用的会话速度，

-网络的等待时间，由沿着路径的设备等待时间加传播延迟组成，

-路径的当前流利用，

-路径的当前会话利用，以及

-沿着路径的当前队列时间。

根据本发明，以上的输出可以用作对具有一个或多个下列输出的应用、调谐以及容量建模分析的输入：

-流应用的基线和当前性能，

-单和多换向会话应用的基线和当前性能，

-在基线和当前条件下流应用的调谐，以及

-对于用户指定的改变的条件的任一组合对于以上全部进行“假设分析”建模，其中改变的条件是服务器或客户机移动和添加、用户通信流方面的改变以及链路速度方面的改变。

为了使用MIB数据和用户文档数据来确定多跳、端到端性能，使用下列数据和公式。在没有一般性损耗的情况下，考虑具有跳a、b、c以及d的四跳网络。设(sa，sb，sc，sd)是沿着该网络路径的跳链路速度组。

设(la，lb，lc，ld)是这些网络跳以英里表示的长度。在四跳网络中，会有五个跨该网络的端到端设备。根据当前技术速度，认为沿着该路径的每一设备的属性是0.1毫秒往返行程的设备等待时间。

再次在没有一般性损耗的情况下，设每一跳是半双工的(所以在每一跳上的利用是其输入和输出利用的累积)，并设(ua，ub，uc，以及ud)表示沿着该网络路径的跳利用。应该指出，利用被表示为小数值。所以如果跳的利用是60％，那么ua＝0.6。

于是，

最小值(sa，sb，sc，sd)＝表示为“S”的路径流速度。

1/(1/sa+1/sb+1/sc+1/sd)＝表示为“C”的路径会话速度。

(跳数+1)＊0.1ms＝表示为“L”的路径往返行程设备等待时间估算。

[((la+lb+lc+ld)＊2)＊2.1]/186,000＝表示为“P”的往返行程传播延迟估算。

S、C、L和P在上面完全从MIB和用户文档中导出，并包括网络的基线性能参数，根据这些参数可以执行基线性能、调谐以及假设分析建模。

作为基线分析的实例，

设sa＝9600，sb＝19200，se＝19200，以及sd＝9600(所有速度都以位每秒为单位)。

设la＝500，lb＝1000，lc＝1000，以及ld＝500(所有距离都以英里为单位)。

则min(9600，19200，19200，9600)＝9600bps＝S。

以及，1/(1/9600+1/19200+1/19200+1/9600)＝3200bps＝C。

以及对于四跳网络来说，(5＊0.1)＝5ms＝L。

以及(500+1000+1000+500)＊2＊2.2/186000＝71ms＝P。

在这个实例中，S、C、L以及P包括网络性能的基线值。

对会话应用(诸如查询-响应以及事务)以及对流应用(诸如文件传输、远程盘复制以及打印)执行如下的性能分析：

基线会话应用分析

假设事务由200字节(即，由8位构成的八位组)查询和1400字节响应组成。每个事务的总字节数是200+1400＝1600字节＝12,800位。网络的会话速率C是3200bps，所以查询响应的总串行化时间将是12800位/3200bps＝4秒。

往返行程设备等待时间L＝0.005秒，往返行程传播延迟P＝0.071秒。

查询响应的总网络往返行程时间＝4+0.005+0.71＝4.715秒。这个基线值表示这个查询响应应用最佳可能的响应时间。如果在该网络的任何部分上存在活动的用户，那么将引入排队延迟，且平均响应时间将增大，这涵盖在下面的当前会话性能部分中。

基线流应用分析

网络的基线流速度是完全由S＝9600bps来描述的。网络的调谐包括窗口大小分析。对于诸如TCP和SNA的开窗协议来说，基线窗口大小(以位为单位)等于完成往返行程确认功能所花费的秒数乘以网络的流速度。作为一个实例，如果窗口大小定步请求包含在1500字节的文件传输包中，并且窗口大小定步确认包括在64字节响应包中，那么该网络中的确认时间是[(1500+64)字节＊8位/C]+D+P＝3.91+0.005+0.071＝3.986秒。确认窗口是3.986＊S＝3.986秒＊9600bps＝38266位＝4783字节窗口大小，该窗口大小是调谐以允许流应用保持网络满载(并因而允许文件传输在尽可能短的时间内完成)所需的。

通常，窗口大小最好表示为在该连接上要被允许进入网络的包的数量。在这一实例中，文件传输应用包大小是1500字节。由于窗口大小是4783字节，所以这意味着能够在确认之间发送的包的数量是窗口大小字节/此连接上的平均包大小＝4783/1500＝3.19个包。保持网络满载需要四舍五入到包窗口大小4。通过推导控制应用性能的窗口调谐值，使得计算所需网络设备缓冲区大小的附加网络调谐参数成为可能。缓冲区需求估算是使用缓冲区为每一连接计算如下的：

[(2＊每窗口包数)-1]＊连接包大小＝此TCP连接的缓冲区需求。

该计算的(2＊每窗口包数)-1部分的原因是在“最坏情况”的缓冲情形下，一个完整窗口被传送，该窗口中的第一包已得到确认，但是其余包因为某原因而保留在网络缓冲区中，当发送者接收到该确认的时候，发送另一个满窗。在这样的情况下，包窗口的两倍减去1的包必须在网络中缓冲。在上述面的实例中，文件传输连接的包窗口为4，且平均包大小为1500字节，所以沿着此连接的路径的设备中所需的网络缓冲区的计算是[(2＊4)-1]＊1500＝10500字节。估算网络设备所需的总缓冲区需要使用设备和它们的窗口需求来估算连接的数量，执行所述计算，并对结果求和。

基线假设分析模型化分析

对网络的潜在基线改变的模型化是容易地通过替换任一所提出的值改变，诸如在链路距离和/或链路速率方面的增加，并将这些值应用到所提供的公式中来完成的。因此通过使用上述新的方法手段来分析资产管理数据库中的链路速率以及固有距离的基值，可以执行包括基线调谐和模型化的完整的基线网络分析。

当前会话应用分析

网络上当前会话应用性能的分析可以利用类似于基线会话分析的计算来进行。等待时间和传播延迟计算是不变的。串行化计算被修改为反映当前可用的带宽，其是在平均当前利用(其它用户的带宽消耗)被减去时的可用带宽数量。使用来自上面实例的值，

sa＝9600，sb＝19200，sc＝19200，sd＝9600(所有速度都是以位每秒为单位)，D＝0.005，P＝0.071。

控制排队对当前性能的影响的变量是链路利用。

假定(a，b，c，d)的表示为ua、ub、uc和ud的链路利用分别是20％、60％、10％和0％。以小数表示，ua＝0.2，ub＝0.6，uc＝0.1，而ud＝0。于是每一跳的当前可用网络速度计算为：

{[(1-0.2)＊sa]，[(1-0.6)＊sb]，[(1-0.1)＊sc]，[(1-0.0)＊sd]}＝

(0.8＊9600)，(0.4＊19200)，(0.9＊19200)，(1＊9600)＝

(7680，7680，17280，9600)＝当前可用链路速度。

该端到端连接的当前可用会话速率是：

1/[(1/7680)+(1/7680)+(1/17280)+(1/9600)]＝2301bps＝当前可用会话网络速度。

当前可用会话速率的通式是：1/[(1-(ua＊sa))+(1-(ub＊sb))+(1-(uc＊sc))+(1-(ud＊sd))]。该网络会话应用的性能的所有分析都将确切地如上面那样进行，例外的是网络路径的当前可用会话速度的值将替代网络路径的会话速度。

多换向会话应用分析

某些事务在它们完成之前要求若干跨网络的“握手”。这些被称为“多换向”的应用。一个实例可以是要求检索多个数据库行的发送者和接收者之间的跨网数据库操作，其中在这多个数据库行中所接收的每一行都必须在发送者可以发送下一行之前得到确认。

根据本发明，可以如下地计算和建模包括多换向的会话应用的性能：

i)用户输入每整个事务(即，包括该事务的所有换向部分)的总入字节(来自客户机)以及总出字节(来自服务器)。将每整个事务的总字节表示为“b”。

ii)用户输入表示为“n”的每事务(通常是3270查询/响应类型事务中的一个)的换向数。

于是，每事务的最佳可能的网络时间(即没有在任何跳处的队列延迟的基线值)是：

(b＊8/C)+(n＊(D+P))＝任一包括多换向的会话事务的最佳可能的网络响应时间。

在具有h跳的网络连接中当前条件下的平均事务时间是：

[(每总事务的字节＊8/当前可用的会话速度)+(设备等待时间+传播延迟)]＊n＝当前条件下的事务时间。这对一般的情况表示为：

{[b＊8/{1/{[1-(ua＊sa)]+[1-(ub＊sb)]+...+[1-(uh＊sh)]}}]+(D+P)}＊n＝当前网络条件下执行跨h跳网络路径的n换向事务的时间。

当前网络条件下的流应用性能分析

在上面的实例中，在当前利用下，网络跳速度是(7680，7680，17280，9600)＝当前可用的链路速度。该实例中的网络的当前流速度将是：

最小值(7680，7680，17280，9600)＝7680bps。

所有对于窗口大小和缓冲区调谐的流分析都将确切地如上面的基线流情况中的那样来执行，只是用当前流速度值替换基线流速度值。

上述基于MIB和用户文档数据输入的用于基线和当前网络分析的方法实现了容易和准确的端到端网络分析。但是，如果数据输入是不正确的，那么对该数据进行的分析将提供不正确的结果。所以在方法上，具有一种检验输入和结果的手段是值得的。这可以用查验来实现。

查验检验方法

查验分析可以跨网络端到端地执行，并且也可以用当前可用的技术，跨网络路径逐跳地执行。在没有一般性损耗的情况下，使用逐跳查验的方法在此被描述为一种分析网络并检验上述基于MIB和用户文档的分析的技术。

对于沿着要被分析的网络路径的所有跳，可以从跳的一端的路由器(或其它层3设备)开始到该跳的另一端的路由器(或其它层3设备)来执行查验。可以使用众所周知的技术来发现沿着该路径的MTU大小。(MTU是最大的网络包大小。)在下面的所有实例中，不发送大于MTU大小的查验。并且在优选实施例中，可以在查验期间采用数据压缩，以最小化正沿着该路径发生的任何其它网络压缩的影响。

对于沿着该路径的每一跳，执行如下测试：

在充足持续时间的时期内彼此隔离地发送较长查验和较短查验，以完成以下的(a)和(b)：

(a)使用户确信附加的测试将不产生用于较长或较短查验的往返行程时间的更快速的实例(换句话说，使用户确信已经观测到最佳可能的较长和较短查验的例子)，以及

(b)采样持续时间足够长，基于查验样本的平均网络性能值的任何计算都将是有意义的。出于使用查验样本来检验MIB计算的分析的目的，优选的是，查验采样持续时间与MIB收集周期一致。

设m是短查验中的字节数(包括头部)。

设p是长查验中的字节数(包括头部)。

设bs是在采样间隔内观测到的最短查验时间(以秒为单位)。

设bl是在采样间隔内观测到的最长查验时间(以秒为单位)。

设as是在采样间隔内观测到的平均短查验时间(以秒为单位)。

设al是在采样间隔内观测到的平均长查验时间(以秒为单位)。

于是，对于每一跳“h”，可以进行下面的计算：

[(p-m)＊2]/(bl-bs)＝查验度量的跳速度。

查验度量的跳速度应该等于上面表示为“sh”的MIB或用户文档跳速度。如果它们匹配，那么MIB或用户文档值是正确的。如果它们不匹配，则必须进行附加的查验以确保已经获得了最佳可能的查验结果，并且必须进行检查以确保查验的发送和返回路径恰好是所讨论的跳而且该跳的发送和接收段的速度都是相同的。如果所有这些都是情况良好的，可是存在与MIB/文档速度值的不匹配，那么很可能MIB/文档值是错的。在该情况下，如果该链路的实际速度是所期望的速度，那么MIB值和文档值就需要加以校正以确保管理工具计算正确地工作。如果该链路速度不是所期望的速度，那么就需要联系该通信设备的厂商或管理员，来解释(以及在适当的时候修复)该缺陷。在任何情况下，都应该使MIB/文档值与实际链路速度匹配。

这一过程可以确保跳的基线速度是所期望的速度，并且确保它被正确地建立文档，以便所有性能计算都可以是可靠的。在这个步骤结束的时候，[(p-m)＊2]/(bl-bs)＝sh将已得到检验，其中该等式的左侧是基于查验的，右侧是基于MIB/用户文档的。

一旦对沿着路径的所有跳都检验(并且校正了，如果必要的话)了跳速度“sh”，使用查验来检验基于MIB的分析的下一步骤就将计算网络的固定等待时间“F”。固定等待时间是由查验所确定的沿着网络的总传播和设备延迟。该计算是：

bl-(bl/sh)＝F。

为了检验MIB基线分析，执行检查来确定是否F＝(D+P)。

如果是，那么网络跳的设备等待时间加传播延迟的查验测试度量与MIB/文档分析匹配，并且基线值是正确的。如果F与D+P的和之间存在不匹配，那么就必须确定查验的稳定性是否有问题(不太可能，因为在前面步骤中的速度匹配检查)，或更可能地，网络跳的实际长度是否比缘于基于MIB或文档的值中的链路的距离长。(还应该检验设备等待时间不是过量的-一种实现方法是在相当短的距离上进行自查验或查验并确定是否存在延长了的查验时间)。通常的情况是链路的实际距离不同于建立文档的，执行如下用于不正确的MIB/文档距离值的校正：

(F-D)＝P’(其中P’是查验导出的跳传播延迟)。

正确的链路距离值＝(186000＊P’)/(2＊2.1)，并且这是应该用在MIB/文档计算中的校正后的值。

如果已确定设备等待时间值是有错的，则在非常短的连接上的自查验测试或查验测试将提供校正后的设备等待时间值，以替换具有0.001ms的往返行程设备等待时间的MIB计算中使用的MIB/文档计算(经验法则)。

这些步骤提供了用于检验和校正基于MIB的网络基线计算输入的方法。在这些步骤完成的时候，可以很有把握地执行基线计算。

检验和校正基于MIB的当前网络评估

为了检验基于MIB的当前网络性能的分析起见，当前网络评估的查验分析由如下计算组成(在没有一般性损耗的情况下)：

al-bl＝由“pq”表示的查验检测到的网络跳队列延迟。

一种校准基于MIB的当前网络条件的评估的方法是建立在所讨论的采样周期期间的查验结果的模型，并查看MIB建模结果是否与所观测到的查验结果相配。

对于网络跳h上的长查验中的1字节往返行程的基于MIB的计算是：

[(1字节＊8＊2)/sh]+(D+P)＝bl(由于前面的校准步骤而为真)

设“Tw”表示平均等待时间的排队理论值。

那么如果MIB与网络当前条件的查验结果相匹配，那么bl+Tw应该等于al，因此需要确定是否Tw＝al-bl。如果是，那么MIB与从查验导出的分析彼此相符，该模型正确地得到了校准和交叉检查。

可以根据MIB值来如下计算Tw：

1)使用在采样周期期间在接口上入和出字节来计算跳利用。(注意，在没有一般性损耗的情况下，假设该链路是半双工的)

(入字节+出字节)＊8/(sh＊MIB采样周期内的秒数)＝采样周期期间的跳利用。

2)计算在采样周期期间在跳h上的平均消息大小：(入字节+出字节)/(入包+出包)＝采样周期期间跳h上的平均消息大小。

3)根据排队理论，其中uh表示采样周期期间跳h的利用，

uh/(1-uh)＝跳h上的队列上的(跳h上的平均跳h大小的)消息数量

4)于是队列上的平均消息数＊8/sh＝Tw。

5)确定是否Tw＝al-bl。如果是，那么查验与MIB分析相关，并且每一个的结果都是可靠的。如果否，那么MIB计数器的超限或其它问题进行检查，并对查验结果的任何反常进行检查。如果在这一采样周期内的检查没有产生任何明显的有关上面不一致的原因，那么就检查其它采样周期以确定MIB和利用的查验结果是否一直匹配。对于不匹配的情况，MIB值应该被视为是与系统对实际终端用户通信流的处理相关的系统的实际状态的表示，因为很有可能不一致的原因是在这一跳上的查验结果正被不影响常规用户通信流的低优先级处理所时滞。

可以通过仅允许用户改变速度、利用和等待时间字段来容易地追加假设分析建模。调整传播延迟以反映客户机或服务器移动的距离加和减系数也可以通过使用之前提供的“经验法则”、以及将该结果应用到包括调谐计算的所有计算来容易地添加。因此，显而易见的是，根据MIB和查验数据，该系统和方法提供全面的分析和预示性能、调谐以及建模结果。在这一范围的信息可用的时候，有序管理得到极大促进。考虑用户抱怨性能的情况。不管该应用是会话、突发还是流，本发明都能够实现有序双重检验的分析。

图3是示出使用本发明的步骤的实施例的流程图，其从步骤300开始。图3(以及图4-10)可以同样地表示实现本发明的步骤的本发明组件的高级框图。图3(以及图4-10)的步骤可以结合适当硬件在计算机程序代码上实现。该计算机程序代码可以存储在诸如磁盘、硬盘、CD-ROM、DVD-ROM或磁带的存储介质，以及诸如只读存储器(ROM)或随机存储器(RAM)的存储设备或存储设备的集合上。此外，该计算机程序代码可以通过因特网或一些其它类型的网络传送到工作站。图3(以及其它流程图)的步骤可以通过图1的实施例来实现。

继续图3，在步骤305，可以获取网络组件和/或跳的度量，以特征化该网络的组件和/或一部分(或整体)。在步骤310，可以根据包括跳和端到端性能的度量的值来计算性能计算。在步骤315，可以对一个或多个应用建档，以确定这些应用呈现给该网络的通信流的特征。

在步骤320，可以识别网络组件并可以基于网络组件的固定和/或可变度量来计算和/或收集网络性能数据，其中这些度量可从查验、MIB数据、踪迹数据和/或用户文档导出。在步骤325，可以通过跟踪或度量来收集其它网络性能数据，诸如等待时间、延迟、吞吐量。在步骤330，可以建立网络性能的模型。这一模型可以包括一个或多个网络组件、单跳、多跳、端到端的特征化、使削弱了的性能与网络组件关联、预计未改变的组件的影响、应用对网络的影响等等。在步骤335，该过程结束。

图4是示出使用本发明的步骤的实施例的流程图，其从步骤400开始。在步骤405，可以为一个或多个网络设备获取MIB数据和/或用户文档数据。在步骤410，可以为一或多跳或对一个或多个网络设备获取查验时间。在步骤415，为一个或多个网络设备获取踪迹。在可选的步骤420，可以执行一个或多个单跳分析。在可选的步骤425，可以执行一个或多个多跳分析。在步骤430，该过程结束。

图5是示出本发明步骤的实施例的流程图，其从步骤500开始。在步骤505，可以确定一个或多个链路的速度。在步骤510，可以确定一个或多个跳或端到端的传播延迟。在步骤515，可以为一个或多个网络组件确定设备等待时间。在步骤520，可以为网络或网络的一部分确定利用。在步骤525，该过程结束。

图6是示出使用本发明的步骤的实施例的流程图，其从步骤600开始。在步骤605，可以为一个或多个跳或端到端确定串行化速率。在步骤610，可以为网络或网络的一部分确定传播延迟。在步骤615，可以对跨一或多跳的一个或多个设备确定一个或多个查验值。在步骤620，可以在一个或多个多跳或端到端上确定PHOD。在步骤625，可以确定网络的会话速度或网络的一部分的会话速度。在步骤630，可以确定网络的会话利用或网络的一部分的会话利用。在步骤635，可以确定网络问题，或基于根据一个或多个计算或一个或多个度量而创建的模型来(例如为网络中的变化)生成性能预报。在实施例中，这种确定或预报可以通过对于网络或网络的一部分，将所度量的和/或所计算的性能与所预期的或预先协定的性能要求相比较来完成。在步骤640，该过程结束。

图7A-7C是示出使用本发明的步骤的实施例的流程图，其从步骤700开始。在步骤705，可以识别一个或多个网络路径(其可能是端到端的)以便分析或建模。在步骤710，可以为沿着一条或多条路径的一个或多个网络设备获取MIB数据。在步骤715，可以从该一条或多条路径中的一个或多个网络设备收集查验数据。在可选的步骤720，可以查阅用户文档来确定沿着该一条或多条路径的网络的特征。在步骤725，可以沿着该一条或多条路径来基线化流速度。在步骤730，可以沿着该一条或多条路径来基线化会话速度。

在步骤735，可以计算沿着一条或多条路径的网络的等待时间。在步骤740，可以沿着该一条或多条路径计算流利用。在步骤745，可以沿着该一条或多条路径计算会话利用。在步骤750，可以为沿着该一条或多条路径的一个或多个网络设备计算当前队列时间。在步骤755，可以为流应用生成基线和当前性能。在步骤760，可以生成单和/或多换向会话应用的基线和当前性能。在步骤765，可以在网络窗口大小和网络缓冲区的基线和当前条件下提供流应用的调谐建议。

在步骤770，可以为任何所建议的度量参数改变的组合提供假设分析建模，以确定对沿着该一条或多条路径的性能的潜在影响，其中的度量参数改变诸如速度改变、设备改变、配置改变、计算出的度量等等。当与所建议的网络中的改变相比较时，基于改变一个或多个参数(例如，按用户所请求的)预计性能模型并重新计算任何性能计算提供了性能与基线或已知条件的增量比较。性能模型可以在仪表板或类似的显示设备上显示出。可选地，如果计算证明了与预定性能标准相比是不可接受的性能，则可以沿着该一条或多条路径来识别瓶颈点。

图8是示出本发明的步骤的实施例的流程图，其在步骤800处开始。在步骤805，可能例如使用与可以正运行NetView^TM或OpenView^TM的性能管理服务器互连的性能控制台或仪表板，根据可达性和自主性来定位损坏设备。在步骤810，通常根据度量出或计算出的网络速度、等待时间、调谐和利用问题，可以建立网络性能的模型以定位数学上的损伤(即度量出或计算出的缺陷)。

在步骤815，检查问题是否已被隔离。如果是，则在步骤820，可以进行适合于该故障的修理，并且该过程在步骤835处结束。但是，如果该问题还未被识别或隔离，则在步骤825，可以尝试试错尝试来解决该问题。在步骤830，检查试错改变是否已经修复了该问题。如果没有，则在步骤825继续试错过程。如果该问题被解决，则该过程在步骤835处结束。

图9是示出使用本发明的步骤的实施例的流程图，其在步骤900处开始。在步骤905，可以使用资产数据(即关于网络中的链路和组件的信息)来创建基线模型。在步骤910，可以添加MIB数据，以在当前条件下创建网络的模型。在步骤915，可以使用查验技术来检验或校准基线和当前性能模型。

在步骤920，可以创建网络上的应用性能的“假设分析”模型，以便进行调谐。在步骤925，可以根据例如查验、从工具度量出的活动、用户文档、分析等等，来确定与可疑性能差问题相关联的一条或多条使用中的网络路径。在步骤930，可以识别网络速度和/或排队阻塞点。在步骤935，可以沿着该路径识别一个或多个跳和任何过量的等待时间。在步骤940，可以识别最优调谐标准(例如改变与网络设备相关的参数或重新分配多个资源中的一个，或重新配置网络等等)。在步骤945，可以根据有关识别出的问题的共业标准(如果有的话)、内部形成的标准或SLA，来补救识别出的问题。

在步骤950，检查是否所有数学上的问题都已得到解决。如果没有，在步骤945处理继续。否则，如果是，则在步骤955，检查是否在步骤955的所有问题都已被修复。如果不是，则在步骤960，可以开始试错法问题解决，直到解决和/或该过程在步骤965处结束。但是，如果所有问题都已被解决，则该过程在步骤965处结束，而无需试错尝试。

图10是示出使用本发明的步骤的实施例的流程图，其在步骤1000处开始。在步骤1005，可以接收用户报告以启动问题解决会话。在步骤1010，可以检验和/或度量所报告的问题。在步骤1015，当检验表明性能处于限度内(例如，在SLA之内)时，可以向用户提交该问题报告，以保证从用户的观点看所报告的问题仍然是正确的和/或有效的。

在步骤1020，判定度量出或观测出的性能是否是一个问题。如果不是，那么该过程在步骤1025处结束。否则如果其被视为问题，则在步骤1030，可能通过RAG控制台进行检查，以确定设备是损坏还是不可达。如果不是损坏，则处理在步骤1040继续。如果该设备被损坏，则在步骤1035修复该设备或使其可达。

在步骤1040，可以根据基于度量出或计算出的网络速度、等待时间、调谐和利用问题的数学度量或计算，使用数学模型来分析该用户路径。在步骤1045，可以判定是否可以实现数学上的解决(例如对于一个或多个设备的参数改变等等)。如果不可以，则可以执行试错尝试来解决该问题，并且处理在步骤1010处继续。如果可以，则在步骤1055，可以执行基于数学的补救或修改。在步骤1010，该过程继续。

尽管本发明已经根据实施例加以描述，但本领域的技术人员将认识到，可以利用在所附权利要求的精神和范围内的修改来实现本发明。

Claims

1.一种管理网络的方法，包括步骤：

建立具有一个或多个网络组件的网络的性能的模型，以根据网络速度、等待时间、调谐和利用的任一组合定位数学上受损的网络组件的实例；

提供对于网络的潜在改变的预测模型，以提高因队列堵塞、传播延迟或网络通信流的较慢串行化或处理而使网络连接之上的总性能变慢的一个或多个网络组件的问题解决的速度，其中对于网络的潜在改变包括对于其他通信流的性能的影响、链路速度增加以及客户机和服务器之间的距离的改变；以及

根据上述模型修改与上述一个或多个网络组件相关的一个或多个参数，以改善网络性能。

2.如权利要求1所述的方法，还包括步骤：当上述模型未能定位上述数学上受损的网络组件的实例时，采用试错改变来补救网络问题。

3.如权利要求1所述的方法，其中上述数学上受损的组件包括度量出或计算出的与上述一个或多个网络组件相关的缺陷。

4.如权利要求1所述的方法，还包括根据上述模型重新配置上述一个或多个组件，以补救上述网络问题。

5.如权利要求1所述的方法，还包括预测对于所述网络中的一个链路上的一个或多个网络组件的改变对于端到端路径的性能有什么影响。

6.如权利要求1所述的方法，其中建立具有一个或多个网络组件的网络的性能的模型中的性能包括所述网络的基线性能和当前性能水平。

7.如权利要求1所述的方法，其中所述预测模型是假设分析模型。

8.一种用于管理网络性能的方法，包括步骤：

创建具有一个或多个网络组件的网络的基线网络模型；

将管理信息库数据添加到该基线网络模型中，以创建当前条件的模型；

Ping该网络中的路径，以检验该当前条件的模型；

根据通过Ping检验过的该当前条件的模型，识别所述路径的最优调谐；

根据识别出的最优调谐修改所述一个或多个网络组件中至少一个的一个或多个参数，以至少沿着所述路径改善网络性能；以及

提供对于网络的潜在改变的预测模型，以提高因队列堵塞、传播延迟或网络通信流的较慢串行化或处理而使网络连接之上的总性能变慢的一个或多个网络组件的问题解决的速度，其中对于网络的潜在改变包括对于其他通信流的性能的影响、链路速度增加以及客户机和服务器之间的距离的改变。

9.如权利要求8所述的方法，还包括步骤：为上述网络中的应用性能创建假设分析模型。

10.如权利要求8所述的方法，还包括步骤：

识别所述网络中具有过量等待时间的跳；以及

识别所述路径中的网络速度和排队阻塞点。

11.如权利要求8所述的方法，还包括根据用户文档、检测出的活动和度量出的性能中的至少任何一个，确定当前性能差的可疑实例的使用中的网络路径。

12.如权利要求8所述的方法，还包括步骤：

补救任何数学上的问题，其中数学上的问题包括计算出的问题和度量出的问题中的至少任何一个；以及

检验基于所述补救的改变是否改善所述网络性能。

13.如权利要求8所述的方法，还包括检查所述一个或多个网络组件中的一个是损坏还是不可达。

14.一种用于管理网络的系统，包括：

用于建立具有一个或多个网络组件的网络的性能的模型，以至少根据网络速度、等待时间、调谐和利用中的任何一个定位数学上受损的网络组件的实例的装置；

用于提供对于网络的潜在改变的预测模型，以提高因队列堵塞、传播延迟或网络通信流的较慢串行化或处理而使网络连接之上的总性能变慢的一个或多个网络组件的问题解决的速度的装置，其中对于网络的潜在改变包括对于其他通信流的性能的影响、链路速度增加以及客户机和服务器之间的距离的改变；以及

用于根据所述模型修改一个或多个网络组件，以至少沿着该网络的一路径改善网络性能的装置，其中该一个或多个网络组件包括网络组件参数和网络组件配置中的至少任何一个。

15.如权利要求14所述的系统，还包括用于在所述模型未能定位所述数学上受损的网络组件的实例时，采用试错改变来补救网络问题的装置。

16.如权利要求14所述的系统，其中所述数学上受损的组件包括度量出或计算出的与所述一个或多个网络组件相关的缺陷。

17.如权利要求14所述的系统，还包括用于根据所述模型重新配置所述一个或多个组件以补救所述网络问题的装置。

18.如权利要求14所述的系统，还包括用于度量和检验所述网络中的可疑问题的装置。

19.如权利要求14所述的系统，还包括用于识别所述网络中的跳和过量等待时间的装置。

20.如权利要求14所述的系统，还包括：

用于识别至少沿着所述路径的最优调谐的装置；以及

用于识别所述网络中的速度和排队阻塞点的装置。

21.如权利要求14所述的系统，还包括：

用于创建基线模型的装置；以及

用于利用管理信息库数据创建当前条件模型的装置。

22.如权利要求14所述的系统，还包括用于对网络性能建模以隔离性能问题的装置。