CN1860734A - 网络吞吐量测定的方法和装置 - Google Patents

Abstract

一种用于测定网络吞吐量的系统。传输数据块(324)并确定每个块的数据速率(326)。通过收集和平均特定块的吞吐量做出精确的测定(326)。该系统结合连接到呼叫中心的诊断单元来说明。当发生客户问题，把用户引导至诊断网页。一旦用户访问该网页(316)，诊断单元或者可以向用户计算机发送数据块(216)，或者可以在网页中嵌入代码，使得用户计算机向诊断单元发送数据块(324)。

Description

网络吞吐量测定的方法和装置

技术领域

本发明一般涉及数据网络，特别涉及测试数据网络。

背景技术

数据网络被广泛使用。多数办公场所，甚至许多家庭，都拥有局域网。许多企业使用链接了不同地方的局域网的广域网。而且，在企业里和在家庭里人们已经广泛使用因特网来访问位于世界各地的计算机上的数据。由因特网携带的数据可以表示文本、图画、音频、视频或其他类型的信息。这里使用因特网作为数据网络的例子。

数据网络的增长产生了对网络测试工具的需求。通过测试来发现网络中的故障，并验证网络提供的服务质量是否合适。例如，因特网服务提供商(ISP)销售因特网接入服务，因此必须保证其客户可以按照与该ISP所销售服务水平相一致的等级与网络上的计算机交换数据。在作为网络的一部分或者通过该网络连接的两个设备(更一般地称作节点)之间传递数据的速率被称作吞吐量。

低吞吐量可能表示在网络的某些部分存在物理故障，如线路、服务器、路由器或其他网络节点。或者，低吞吐量可能表示没有适当地配置网络设备，或该网络缺乏足够的设备来同时传送用于网络用户的数据。

不论网络吞吐量不足的原因是什么，网络用户都将体验低劣的服务。为了让客户满意或者保证可对高吞吐量网络连接收取高额费用，ISP需要知道网络中个节点之间的吞吐量。

伊利诺斯州迪尔菲尔德的泰拉丁公司提供了名为NetFlare^TM的产品，用以帮助ISP或其他网络运营商来跟踪对其客户所提供服务的质量。该产品的一项功能就是可以测定吞吐量。

测定吞吐量的传统方法就是简单地从网络的一个节点向另一个节点发送数据块。通过测量传输该数据块所用时间的量，可以计算传输该数据的速率，该速率就是吞吐量的表示。

这种方法有几个缺点。一个缺点就是为了精确测定吞吐量而必须传输的数据量取决于该吞吐量。例如，应该按56KB每秒传输数据的两个节点之间的链路，为得到合理的网络性能样本，较之以100MB每秒操作的链路，所需要传输的数据量要少的多。

另外，不考虑操作速度，为了精确测量网络连接吞吐量而发送所需要的足够大的数据样本，这样的方法通常也是不合适的。如果数据样本足够大，能够以高速度提供精确的测量，但如果网络实际是以低速操作，为了运行该测试就要用非常长的时间。要完成该测试，所用的时间可能远超过网络用户所能接受的时间。还有，如果该测试把大量数据置于较慢的网络上，则测试数据本身会使网络过载或使其操作变慢。

许多做吞吐量测定的系统都限制做吞吐量测定的时间。如果测试数据在指定的时间之内没有传输，则测试终结。但是，如果在待测试链路上传送测试数据之前该测试就终结了，测试系统就不能区分是链路上有阻塞数据传输的故障还是该网络以非常低的吞吐量在操作。

某些系统试图通过从运营商那里获得网络吞吐量的估计值，然后按此数据速率利用适合于做精确吞吐量测定的数据量来运行测试，因此来克服上述的这些吞吐量测定问题。例如，称作PCPITSTOP.COM的实用程序就按这种方式操作。当预期该链路具有低的数据速率，就使用少量的数据，这样就可以在为该测试限定的时间内传输该测试数据。

这种方法也有几个缺点。其中一个缺点就是运营商可能不知道该链路预期的吞吐量，因此提供不确切的信息。另外的问题是，常常是在网络中出现问题并且不是按其期望数据速率操作的时候运行吞吐量测试。因此，用户输入可能还是导致指定了比适合该网络更大的测试数据包。

希望能有改进的技术来测定网络的吞吐量。

发明内容

考虑到上述的现有技术的问题，本发明的一个目的是提供更方便和更精确的系统和方法来测定网络的吞吐量。

本发明的另一个目的是提供测定网络吞吐量的系统和方法，不增加该网络的负担。

本发明的另一个目的是提供在ADSL网络或有线宽带网络的上行和下行链路中测定网络吞吐量的系统和方法。

上述和其他的目的通过利用传输多个数据块的过程来达到。测量每个数据块的传输时间。继续该测量直到获得精确的吞吐量测定值或预定的时间期满。

在一个实施例中，通过在web服务器上的用户接口提供HTML页面来测定ADSL网络中上行链路的吞吐量。该HTML页面包括测试有效负载和自动向服务器按块传输该有效负载的JavaScript脚本。

在另一个实施例中，统计分析对各个块所做的吞吐量测量，以提高该测量的精确性。优选地，只对“非突发”网络使用统计分析。

附图说明

通过参考下面的详细说明和附图可以更好地理解本发明。附图包括：

图1可使用本发明的网络的略图；

图2是用于计算比特率的过程的流程图；以及

图3是用于沿上行方向计算比特率的过程的流程图。

具体实施方式

本发明的应用不限于下面说明中所叙述的和附图所示出的构造和布置的细节。本发明还可有其他的实施例，并可按不同的方式来实施和执行。而且，这里使用的词汇和术语是为了说明的目的，不应该被看作是限制。“包含”、“包括”或“具有”、“包含有”、“含有”及其变种是指包含其后所列各项及其等价物以及附加的各项。

图1示出了大大简化形式的网络100，其中要测定吞吐量。将结合测定接入因特网的用户所体验的吞吐量来说明本发明的优选实施例。在这里的情况下，网络100表示由因特网服务提供商所提供的接入网络。但是，本发明并不限于在这种应用中使用。

数据终端连接到网络。在图1中，计算机112表示数据终端。计算机112例如可以是家用计算机。

当使用因特网，用户访问网络110上的其他数据终端。在图1的例子中，待测试的网络是因特网，这些数据终端大都是对因特网用户接收或提供信息的服务器。服务器114表示这类数据终端。应该理解，因特网具有许多链接到该网络上的用户和许多服务器，但这里只简化地示出了两个。用于实现计算机112和服务器114的确切设备类型对本发明是无关紧要的。但是，这里说明的优选实施例使用包括标准浏览器的计算机112。在所说明的实施例中，该浏览器可接收和响应包含有JavaScript^程序的HTML页面。

图1还示出诊断单元116也连接到该网络。在优选的实施例中，该诊断单元116属于伊利诺斯州迪尔菲尔德的泰拉丁公司在Netflare名义下出售的产品类型。但是，也可以使用任何可执行后面所述程序的诊断单元。而且不一定必须使用单独的诊断单元。下面所说明的程序可以在任何连接到待测试网络110的计算机上执行。例如，该程序可在服务器114上执行。

编程诊断单元116使得执行吞吐量测量算法120。如下面将详细说明的那样。吞吐量算法作为计算机程序实现在诊断单元116中。该计算机程序可以用任何合适的语言来编写。但是，该优选实施例的优点是该吞吐量程序可以编写成计算机应用程序。在该优选实施例中，该应用程序使用标准的计算机实用程序来管理网络110上的通信。按OSI五层网络协议模型的术语，吞吐量程序实现在第5层，因此不需要修改实现网络1至4层的标准软件或硬件。

图1示出诊断单元116包含缓冲区118，缓冲区118处于该网络和运行吞吐量算法120的该软件之间。缓冲区118表示一种由大多数计算机和服务器的操作系统所执行的功能。当应用程序产生要在网络上发送的数据，操作系统通常缓存该数据，直到该操作系统确定要在网络上发送的消息已经准备就绪。例如，传统的网络协议规定消息要按分组来传送，每个分组具有某些控制位和若干数据位。如果操作系统从应用程序接收到每个数据字节时就传输该数据字节，每个分组就具有许多控制位和较少的数据位。因此，大部分网络流量都用于传输控制信息，而只有非常少的实际数据传输，导致低效的网络。

通常希望有缓冲区118。但是，当测量网络吞吐量，也可能不期望有缓冲区。该缓冲区可在应用程序消息传输中引入可变的延迟量。在优选实施例中，吞吐量测量软件实现成应用程序。但是，为了避免操作系统可能引入可变的延迟，如下面所述的，设计优选实施例来避免缓冲区引起的相当大的延迟。

在优选实施例中，吞吐量测量程序120测量经过网络110到达计算机112、或从计算机112经网络110到服务器114的通信中的数据速率。通常，这些测量值被分别称作上行和下行吞吐量。

在优选实施例中，从吞吐量测量中获得的数据由因特网服务提供商来使用以提供客户的管理。把该吞吐量测量值提供给呼叫中心122。呼叫中心参考由因特网服务提供商所操作的设施，在此客户可对网络服务进行投诉。通常，呼叫中心122设有人工操作员来接听来自客户的电话呼叫和电子类通信。应该理解，呼叫中心122不必具有实际的位置。客户服务操作员可位于任何可从客户接收通信的地方。例如，客户服务操作员可以包含在网络操作中心(NOC)。还应该理解，不是必须由人工操作员来提供客户服务。各种人工智能技术已经用于响应客户投诉。

在优选的实施例中，引导那些向客户中心122投诉有关网络连接吞吐量的客户去使用他们的计算机访问诊断单元116。优选地，诊断单元116对用户而言是服务器，可经网络110来访问。为了便于计算机112和诊断单元116之间的连接，呼叫中心122向用户提供诊断单元116的网址。应该理解，用户也可以从呼叫中心以外的地方获取诊断单元116的网址。例如，可以从自服务网站下载诊断单元116的网址。

无论如何启动计算机112和诊断单元116之间的连接，一旦建立这种连接，就可以执行吞吐量算法。图2示出了该过程的用于测量上行吞吐量的部分。在图2左侧所示出的步骤在优选实施例中在作为“宿主”的计算机112执行。在图2右侧的步骤在作为服务器的某个计算机上执行。在优选实施例中，该计算机就是诊断单元116。

当宿主计算机连接到该服务器，该过程在步骤210开始。如上所述，在优选实施例中，当用作宿主的用户计算机112登录到诊断网页，就完成这种连接。

一旦建立该连接，该过程进到步骤212，该步骤在服务器上执行。在步骤212，启动测试定时器。优选地，吞吐量测定要在预定的最大时间量之内完成，不论网络的吞吐量如何。在步骤212启动的测试定时器将跟踪最大允许的测试时间。如果超过了该最大允许时间并且该测试没有完成，测试定时器超时(time out)，测试将停止。在本领域中已知许多方法使过程超时停止。例如，测试定时器的超时触发软件中断。可替换地，该过程可以包含一个重复询问该定时器时间的步骤，并且在任何时候，如该询问指示定时器已超时，则该过程停止。使测试超时停止的特定方法对于本发明无关紧要。

在步骤214，开始单独的时间持续过程。该时间持续过程用于测量从服务器向宿主传输一个数据块所用的时间量。步骤214建立传输间隔的起始。在优选实施例中，通过记录系统时钟所指示的时间来记录传输间隔的起始。但是，还有许多已知的测定时间间隔的替换方法，并且所使用的特定方法对本发明是无关紧要的。

过程进到步骤216。在步骤216，从服务器向宿主计算机发送数据块。如上所述，步骤216优选实现成诊断单元116上的应用程序。它依赖在诊断单元116中编程的已有系统实用程序来实际在网络110上传输数据。但是，为了应用程序可精确测量数据块的传输时间，从应用层发送的数据块必须在没有缓冲区引起延迟的情况下在实现OSI网络模型的第1至4层的诊断单元116的硬件和软件中传递。当数据块在该网络协议的第4至1层传递时，为了保证不缓存该数据块，应该根据低层的网络协议来选择数据块的长度以填充将要在网络110上传送的数据分组。还希望设置套接字缓冲区的长度来减少有可变延迟的缓冲消息的机会。

在优选实施例中，执行吞吐量测试的应用程序运行在标准操作系统上。在一个实施例中，该操作系统是Linux。在这样的环境中，宿主和服务器之间的连接被表示成“套接字”。当应用程序访问特定的套接字，该操作系统控制下层的软件和硬件按适当的格式在网络上发送消息。尽管控制吞吐量测量的应用程序优选地不直接控制下层的硬件和软件，在优选实施例中，它确实设置套接字的参数以减少消息被延迟的机会。特别地，套接字缓冲区的长度是可变的。优选地，针对每个套接字来改变套接字缓冲区，并且只对用于吞吐量测量的套接字做改变，从而不破坏其他的通信。由于控制TCP会话的软件将把用于对应该套接字的特定会话的TCP窗口设置成小于该套接字缓冲区的长度，从应用级调节套接字缓冲区直接影响低级的网络操作。因此，对数据块的适当长度和套接字缓冲区长度的应用级选择会导致更精确的吞吐量测量。

例如，在传统的操作系统中，套接字缓冲区长度的默认值近似是64K。我们发现把套接字缓冲区长度减少到近似9K字节时会导致更精确的测量。该值部分依赖于经验选择。在实验室环境建立测试设定值。使用分组分析器来测量实际的吞吐量。调节缓冲区长度，直到利用这里所述技术测量接近由分组分析器测量的实际吞吐量。但是，不能让缓冲区长度小于数据块，否则，在接收单个的分组之前就发生缓冲区的溢出。因此，套接字缓冲区的长度优选在2K字节和16K字节之间，更优选在8K字节和12K字节之间。

为了设置数据块长度，要考虑网络协议。例如，在使用以太网协议的因特网上传输数据。以太网协议规定在网络上传输的消息的帧的长度应该是1518字节。帧中的特定信息是用于控制的，留下1497字节的数据空间。包含在帧或消息分组中的数据有时候称作有效负载。在优选实施例中，在步骤216发送的数据块优选与该网络协议规定的最大消息有效负载的长度一样。

应该理解，优选的有效负载长度因网络不同而不同。但是，我们认识到使用近似等于有效负载长度的数据块有几个好处。如上所述，一个好处是它使得可在不需要应用程序直接控制TCP栈或其他低级网络要素的情况下可执行测试。第二个好处是它可以在比通常为了执行吞吐量测量测试所分配整体时间少得多的时间内发送一个数据块。按这种方式，可以使用多个数据块完成多数的吞吐量测量。可以对这些测量值做平均以建立更精确的吞吐量测量值。优选地，选择块长度还要考虑这样的实事，某些网络连接速度很慢，执行需要大量数据块的测试可能会使该测试不能在所分配的时间内完成。在优选实施例中，选择块长度来测量在范围56Kbps至8Mbps的网络吞吐量，导致块长度在1.2K字节至2.5K字节的范围内，优选的长度是近似2K字节。

当该宿主接收了数据块，按照如步骤218所指出的，它通过发送确认来响应。当该服务器接收到该确认，该过程在步骤220继续。在步骤220记录接收确认消息的时间。该时间与在步骤214设置的起始时间做比较以确定该数据块的传输时间。通过把该块的长度除以传输时间，可以计算出在该块传输期间的比特率或吞吐量。

该过程的执行然后进到步骤222。在步骤222检查是否已经传输了足够数量的块以提供吞吐量的精确测量值。在优选实施例中，在确定已经传输的数据块数量之后，吞吐量测量测试就结束。优选地，块的数量在200到500之间。在优选实施例中使用400个块。但是，也不必把预定数量的数据块传输当作停止吞吐量测量的判据。例如，对在前的各数据块的各吞吐量测量值的统计特性可被用作在步骤222确定是否传输了足够数据块的判据。当对在前的各数据块的吞吐量测量值的标准偏差小于5％时，则可以停止该测试。因此，在步骤222使用的用来确定是否传输了足够数据块的技术对本发明是无关紧要的。

如果还没有传输了足够的数据块，该过程返回到步骤214。返回步骤214引起发送另外的块，并对该块测定比特率。如果发送了足够的块，该过程进到步骤224。如上所述，如果在步骤212设置的定时器超时，数据传输也要结束。因此，步骤224在当发送了足够多块的时候执行，也在当超过了最大允许测试时间的时候执行。

在步骤224，通过对在步骤220计算的各数据块的比特率做平均来计算整体比特率。比特率是网络吞吐量的度量。但可以使用更精细的处理来计算整体比特率。例如，可以对各数据块的比特率做统计分析，以便从步骤224的比特率整个计算中排除那些可能表示异常操作条件的数据块。排除那些在异常操作条件下所做的测量可以提高吞吐量测量值的整体精度。但是，在某些情况下，根据统计特性排除对个别块的比特率测量值会实际降低整体吞吐量测量值的精度。某些网络按“突发模式”传输数据包。例如，如果网络110表示由有线公司运营的因特网接入网络，发送到计算机112的分组的传输时间将依赖于当地线缆回路中的网络流量。因此，对各块测定的吞吐量将根据网络流量随时间变化。我们使用术语“突发(bursty)”来指这样的网络，在该网络中，在所分配的吞吐量测试的时间期间，预期瞬时吞吐量是变化的。另一方面，当网络110表示由提供ADSL服务的电话公司运营的因特网接入网络时，在测试中对各块测定的比特率可能依赖于网络中线路的物理条件或者在测试期间可能变化的其他因素。我们称这种网络是“非突发”网络。对非突发网络，利用统计分析来排除那些瞬时吞吐量显著不同于平均吞吐量的个别块的测量值，可能会提高吞吐量测量值的整体精确度。

在当前的优选实施例中，在步骤224的处理将通过计算机软件来实现，可以配置该软件来排除所选择的对个别块计算的吞吐量。但是，当用于测定突发网络的吞吐量时，该软件要包括禁用该特性的功能。

应该理解，图2中的步骤是说明性的，该过程不必严格按所示出的那样来执行。例如，图2示出块的传输时间被测定为发送块和接收确认之间的时间差。优选地，可以通过测量服务器接收相继传输块的确认之间的时间来测定块的传输时间。按这种方式，对到达服务器的确认的时间和传输时间中的任何其他固定延迟都在比特率的计算中被排除。

图3示出了类似的过程，用于测量上行吞吐量。图3示出的过程在步骤310开始，其中诸如用户计算机112的宿主连接到服务器。如同图2，在优选实施例中该服务器是诊断单元116。但是，也可以使用网络上的任何其他服务器。而且，应该理解，在步骤310，到服务器的连接不需要在步骤210的连接中的那种单独用户交互。在图2的过程完成之后，图3的过程可自动执行。

不论如何建立连接，一旦该连接建立，处理就进到步骤312。在步骤312，服务器启动测试计时器。如图2所示的下行测定过程，如果在预定的时间量内没有完成，该上行测定过程结束。

服务器向宿主计算机发送HTML页面。到网站的登录通常引起HTML页面的传输，在图2和图3中不祥述HTML页面的发送步骤。但是，在步骤314发送的特定页面要特别修改以使得宿主计算机执行上行吞吐量测定的过程部分。

在步骤314发送的HTML页面示意性地示出为HTML页面316。HTML页面316包括可执行代码，在这里表示成JavaScript318318。另外，HTML页面316包括有效负载320。在优选实施例中，有效负载320是类似于在步骤216所传输数据块的数据块。如上所述，选择有效负载的长度来填充信息的分组，该信息的分组在网络110上传输，并且没有因在实现低层网络协议层的硬件或软件中的缓冲而引起的延迟。

所示出的HTML页面316还包括提交按钮322。提交按钮322可以是当接收到HTML页面316时由web浏览器在计算机112上显示的实际用户控件。当用户激活提交按钮322，JavaScript318318开始执行。在优选实施例中，JavaScript318318是简单程序，使包含有效负载320的消息反复向服务器传输。在预定的时间周期内JavaScript318318重复运行。优选地，该时间周期与对上行吞吐量测量周期所分配的时间量相匹配。在当前的优选实施例中，该时间优选在1至15秒，最优选为近似10秒。应该理解，让用户点击提交按钮322不是该过程必不可少的步骤。作为替换，可以配置HTML页面316，使得当网页316下载到计算机112时JavaScript318自动做提交。

在步骤324所发送的数据块由服务器接收并如在步骤326指出的那样来处理。步骤326如前面结合图2所述的那样对数据块做分析。诊断单元116或其他用作服务器的计算机记录从宿主计算机接收每个数据块的时间。相继数据块之间的时间差是该数据块在网络110上传递所花费的时间量的指示。通过用传输时间来除该块的长度，可以确定该块传输的吞吐量的估计值。步骤326分析各块的吞吐量测量值，如上面结合图2所述的那样。该分析包括确定为了精确计算吞吐量是否已经接收了足够多的数据块。步骤326还做检查以确定是否已经超过了用于上行吞吐量测量的最大时间量。如上所述，可以按许多方式来执行这种检查，例如通过检查在步骤312设置的测试时间的值是否已经超过了预定的值。

当已经收集了足够多的数据，或者已经接收了足够数量的块，或者经过了足够长的时间，在步骤326还计算整体的吞吐量。在优选实施例中，把整体吞吐量报告给呼叫中心122，在呼叫中心使用该信息来诊断网络问题或为解决用户投诉提供便利。

如果服务器在步骤326确定应该根据已经接收的块的测量值来计算整体吞吐量，服务器可以向宿主发送消息，指示宿主和服务器之间的连接是断开的。HTML协议包括会话受控消息，使服务器向宿主发出连接已断开的信号。对可用于宿主计算机的大多数产品化的web浏览器，接收这种消息将导致JavaScript318318执行的终结。按这种方式，该宿主不会传输更多的不必要数据。但是，我们观察到发送会话消息的结尾会导致某些产品化web浏览器向用户显示通知。如果希望避免向计算机112的用户显示这种通知，服务器112可不必发送会话消息的结尾。在这种情况下，当JavaScript318318运行了预定的时段就停止执行。在当前的优选实施例中，在优选为5至10秒的时间之后JavaScript318318就超时，并停止发送数据。

图2和图3所示的过程是程序的高级逻辑表示，可以编写所述程序以实现根据本发明的技术。本领域的技术人员可以开发也使用本发明的替换程序。例如，所示出的步骤220对各块计算比特率，步骤224计算整体比特率。其中所执行的各种数学运算的次序对本发明是无关紧要的。例如，对各块的比特率的平均，可以先计算各个块的比特率，然后再对这些数计算平均值。但是，也可以通过把所传输的所有块的比特数加在一起，然后再除以传输这些块所花费的时间，从而得到数字相同的结果。作为另外的替换，应该注意，在优选的实施例中，所有块的长度是一样的。但所有块的长度不必是一样。但是，当块长度是一样的，块的长度成为常数比例因数，可以应用到在任何方便的时候计算比特率的公式中。

上面说明了本发明至少一个实施例的几个方面，应该理解，本领域的技术人员可以做出各种替换、修改和改进。这些替换、修改和改进也是本公开的一部分，属于本发明的精神和范围之内。因此，上述的说明和附图只是作为例子。

Claims (27)

1.一种测定网络吞吐量的方法，包括：

a)在该网络上传输数据块；

b)测定表示所述块的传输时间的值；

c)计算该块的数据传输速率；

d)重复步骤a)、b)和c)，直到发生停止事件，其中所述停止事件是下述事件中首先发生的事件：传输了一定数量的块或经过了一定量的时间；以及

e)通过计算所述各块中所选出的一些块的数据传输速率的平均值来计算所述网络吞吐量。

2.如权利要求1所述的方法，其中，当已知所述网络是突发网络时，所述的各块中选出的一些块包括所有这样的块：在测定期间对该块计算了数据速率。

3.如权利要求1所述的方法，其中，当已知所述网络是非突发网络时，所述的各块中选出的一些块只包括这样的块：在测定期间对该块计算的数据速率小于指定数量，该指定数量来自所传输的所有块的平均数据传输速率。

4.如权利要求1所述的方法，其中，选择数据块的长度以适合容纳在网络分组中。

5.如权利要求4所述的方法，其中，选择数据块的长度，以使得连接到该网络的计算机应用层把包含该块的消息在无缓冲延迟的情况下传递给该网络。

6.如权利要求5所述的方法，其中，在连接到该网络的计算机应用程序层测定所述传输时间。

7.如权利要求1所述的方法，其中，传输数据块包括由运行在操作系统上的应用程序产生消息，该应用程序建立具有缓冲区的套接字，并且所述方法另外还包括设置该套接字缓冲区的长度。

8.如权利要求1所述的方法，其中，所述的数据块的长度小于2K字节。

9.如权利要求1所述的方法，其中，按上行吞吐量来测定所述吞吐量，并且所述方法另外还包括测定下行吞吐量。

10.一种测定网络吞吐量的方法，包括：

a)建立用户计算机和服务器之间的连接；

b)利用该服务器向所述用户提供诊断网页；

c)在该网络上在该用户和该服务器之间重复传输数据块，直到发生停止事件，其中所述停止事件是下述事件中首先发生的事件：传输了一定数量的块或经过了一定量的时间；

d)测定表示所述块的传输时间的值；

e)通过计算所述块中选出的一些块的数据传输速率的平均值来计算网络吞吐量。

11.如权利要求10所述的方法，其中，所述网页作为HTML页面提供给所述用户，该HTML页面包含脚本，该脚本使得该用户计算机向所述服务器传输数据块。

12.如权利要求11所述的方法，其中，所述网络是ADSL网络，并且所计算的吞吐量表示上行吞吐量。

13.如权利要求12所述的方法，其中，单独测定下行吞吐量。

14.如权利要求11所述的方法，其中，所述HTML页面还包含测试用有效负载，该有效负载按数据块形式传输。

15.如权利要求10所述的方法，其中重复传输数据块，其中：

a)传输数据块包括从所述服务器向所述用户计算机传输块；以及

b)由来自用户计算机的相继确认之间的时间导出表示传输时间的值。

16.如权利要求10所述的方法，其中，所述服务器是安装在所述网络中的诊断单元。

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

a)在由网络操作员操作的呼叫中心接收来自网络用户的呼叫；

b)指导该用户访问该诊断网页并接收结果；

c)接收所计算的网络吞吐量，用于在所述呼叫中心使用。

18.如权利要求10所述的方法，其中，所述经过的时间小于10秒。

19.如权利要求10所述的方法，还包括向因特网服务提供商的呼叫中心提供所计算的吞吐量。

20.如权利要求10所述的方法，其中，该网络是非突发网络，并且根据所述块的传输时间和所有其他块的传输时间的平均值之间的关系来选择所述的各块中选出的一些块。

21.一种网络，配置该网络用来在该网络的接入部分测定用户所体验的吞吐量，该网络包括连接到该网络的诊断单元，所述诊断单元具有程序，该程序使得：

a)当用户访问该诊断单元时，向该用户计算机提供诊断网页；

b)在该接入网络上在该用户计算机和该诊断单元之间控制数据块的重复传输；

c)测定表示所述块的传输时间的值；以及

d)通过计算在停止事件发生之前所接收各块中选出的一些块的数据传输速率的平均值来计算网络吞吐量，其中所述停止事件是下述事件中首先发生的事件：传输了一定数量的块或经过了一定量的时间。

22.如权利要求21所述的网络，其中，编程所述诊断单元以便沿上行方向和下行方向测定吞吐量。

23.如权利要求22所述的网络，其中，所述诊断单元向用户计算机传输数据块，并通过测定该用户计算机所发送的各确认消息之间的时间差来测定表示时间的值，由此该诊断单元测定下行吞吐量。

24.如权利要求23所述的网络，其中，所述诊断单元在向所述用户计算机提供网页时在该网页中嵌入代码，并且该代码使得用户计算机向该诊断单元发送相继的数据块，由此该诊断单元测定上行吞吐量。

25.如权利要求21所述的网络，其中，所述程序是运行在操作系统上的应用程序，并且该操作系统通过建立套接字使得在该网络上在该应用程序和该用户计算机之间可通信，该套接字具有缓冲区，并且所述应用程序另外还包括设置该套接字缓冲区长度的程序。

26.如权利要求25所述的网络，其中，该套接字缓冲区的长度设置在2K字节到16K字节之间。

27.如权利要求26所述的网络，其中，该套接字缓冲区的长度设置在8K字节到12K字节之间。

Images