CN102150395A - 用于网络数据路径质量的非协作测量方法 - Google Patents
用于网络数据路径质量的非协作测量方法 Download PDFInfo
- Publication number
- CN102150395A CN102150395A CN201080001287XA CN201080001287A CN102150395A CN 102150395 A CN102150395 A CN 102150395A CN 201080001287X A CN201080001287X A CN 201080001287XA CN 201080001287 A CN201080001287 A CN 201080001287A CN 102150395 A CN102150395 A CN 102150395A
- Authority
- CN
- China
- Prior art keywords
- response
- packet
- detection
- tcp
- bag
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0823—Errors, e.g. transmission errors
- H04L43/0829—Packet loss
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0852—Delays
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0852—Delays
- H04L43/0864—Round trip delays
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0852—Delays
- H04L43/087—Jitter
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/12—Network monitoring probes
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明涉及一种以非协作方式测量网络路径质量的方法和设备,其发送由多组探测网络包组成的探测给远端节点,并从该远端节点接收由至少一个响应网络包组成的响应。探测和响应网络包均携带正常网络应用的消息并可根据其传输协议进行交换,这样本方法避免了使用非数据网络包的方法所面临的可靠性问题。同时本方法所触发的响应数据包能提供足够的信息来以有效的方法获取一组丰富的数据路径质量度量。
Description
技术领域
本发明涉及通信网络中网络路径质量的测量方法,更具体地说,涉及一种用于从路径的单个端点测量数据路径质量的方法和设备。
背景技术
对于数据中心、因特网服务提供者、网上交易、因特网行为的科学研究以及许多其他目的来说,测量通信网络(特别是因特网)的端到端路径质量的能力是至关重要的。可通过丢包、包乱序(包的接收顺序与其发送顺序不同)、延时以及其他路径度量来测量路径质量。测量这些路径度量的方法被粗略划分为主动测量和被动测量。主动测量方法包括在设计成仅用于路径测量目的的网络路径的两个端点之间发送网络包。被动测量方法并不发送任何网络包,而是分析采集到的网络包来推测网络路径质量。
许多主动测量方法需要网络路径的两个端点之间的协作,并且需要在这两个端点上安装特定的程序或者装置。通过控制这两个端点,这类方法可以测量许多路径度量,并控制和校准测量精度。然而,因为网络路径一般跨越多个自主网络,需要控制两个端点的需求严重限制这类方法的使用和应用范围。另外,对于不同网络应用和环境,安装所需的软件或装置也是不容易的。非协作测量方法不会受到这一限制,其允许单个端点(或测量节点)进行海量网络路径的测量。非协作测量方法的测量节点发送探测包(probe packet)以获得来自远端端点(或节点)的响应包以用于路径测量。
虽然非协作测量方法已经被研究和发展多年了,但是其依然受到至少两个主要问题的限制。第一个主要问题是绝大多数现有的方法并不能提供可靠的测量。首先,他们发送的探测包(或其发送速率)常被看作是异常的,从而被路径上的防火墙、入侵检测系统和其他安全装置滤除。因此,将不会有响应包返回到测量节点。第二,某些方法的探测包可以成功地获得响应包,但是这些响应包不能包含路径测量所需的信息。第三,虽然某些方法的探测包可以成功地获得包含路径测量所需的信息的响应包,但是这些测量结果不能反映正常数据包所经历的实际路径质量(也就是,数据路径质量)。
对于第一类不可靠问题,众所周知的是,现在路由器和端系统并不总能响应来自ICMP Ping以及其他依赖ICMP包的测量工具所发出的(高速率的)ICMP数据包,因为ICMP包常被应用在各类网络攻击中。对于使用TCP SYN包、TCP RST包和向封闭端口(closed port)发送UDP包的测量方法也受到同样的制约。例如,S.Savage在“Sting:一种基于TCP的网络测量工具”(USENIX会议文集,因特网技术和系统1999(Sting:a TCP-based Network MeasurementTool,”Proc.USENIX Symp.Internet Technologies and Systems 1999))中提出Sting。其通过发送一系列具有零广告窗大小的乱序探测TCP数据包来测量正向传输路径(或正向)或反向传输路径(或反向)丢包统计。这些高度异常的数据包很容易被包过滤机制屏蔽掉。作为另一实施例,X.Luo和R.Zhang在“用于端到端包乱序测量的新方法”(ACM/USENIX IMC 2005会议文集)(“Novel Approaches to End-to-End Packet Reordering Measurement”Proc.ACM/USENIX IMC 2005)中提出的指示字(POINTER)通过发送具有不可接受的TCP序列(unacceptable TCP sequence)和确认号来测量正向传输路径和反向传输路径包乱序统计。
对于第二类不可靠问题,R.Mahajan,N.Spring,D.Wetherall和T.Anderson在“用户级因特网路径诊断”(ACM SOSP 2003会议文集)(“User-Level InternetPath Diagnosis,”Proc.ACM SOSP 2003)提出了Tulip。Tulip使用UDP包和ICMP包来定位(localize)网络路径上的丢包和包乱序事件。其丢包和乱序的测量都是基于位于路径上的路由器和远端节点支持因特网协议(IP)的标识字段的连续增量的假设。然而,对于此时的许多端系统和路由器来说,该假设并不成立。
第三类不可靠问题涉及使用非数据探测包进行测量的方法。非数据探测包或响应(包)指不被用于传送网络应用的数据的网络包,如ICMP包、TCPSYN包、TCP RST包和纯TCP确认包(TCPACK)的包。非数据探测包和响应包并不能准确测量数据包所经历的网络路径质量,因为路由器和端系统对数据包和非数据包进行不同的处理。这两者之间的差异是相当显著的。除了基于ICMP和UDP的方法,Sting、POINTER、和R.Sherwood和N.Spring在“在TCP边车(sidecar)中巡测因特网”(ACM/USENIX IMC 2006会议文集)(″Touring the Internet in a TCP Sidecar,″Proc.ACM/USENIX IMC 2006)中提出的TCP边车也面临这一问题,因为它们要获取TCPACK以用于反向传输路径测量。
上述方法均面临可靠性问题,这是由于它们通过非数据信道(在数据传输协议中的单个或多个控制包)或异常协议行为来测量数据路径的质量。它们的测量结果容易被路径上的中间节点(intermediary node)出于善意(如监视袭击)或恶意(如操纵测量结果)篡改。
现有技术的第二个主要问题是,它们提供了一组非常有限的路径质量度量。由于不同的网络应用需要经历具有不同质量的网络路径,因此使用尽可能多的度量来测量路径质量是至关重要的。三种限制导致了有限的质量度量组。首先,许多非协作方法,如Ping及其变形的方法,可以测量往返路径的度量,而不能测量单向路径的度量,例如在正向传输路径中发生的丢包(也就是,从测量节点到远端节点),和在反向传输路径中发生的丢包(也就是,从远端节点到测量节点)。因为网络路径通常是非对称的,并且在它们的通信量中,许多应用也是非对称的,所以正向传输路径的质量和反向传输路径质量在应用性能上的影响是不同的。
第二个限制是现有方法一般仅可测量一种或两种类型的质量度量。例如,Ping可测量往返延时和往返丢包,sideping(基于TCP边车框架的协议)可以测量往返延时,Sting可以测量正向传输路径和反向传输路径的丢包统计,POINTER可以测量正向传输路径和反向传输路径的包乱序统计。虽然Tulip可测量丢包、包乱序和排队延时,但是其也面临上述的可靠性问题,如其使用不同的探测包来测量丢包和乱序,但其不能测量所有的丢包场景。虽然可以使用多个工具来获得更多组质量度量,但是实际上该方法效率很低,难以调整且易于出现测量和配置错误。
第三个限制是现有方法不能测量不同响应包大小的路径度量。虽然Sting可以测量单向丢包,但是其仅可测量TCP ACK的反向传输路径丢包,该TCPACK是很小、大小固定的包。POINTER也出现同样的限制,其获取TCPACK来测量反向传输路径包乱序。众所周知的是,大包更容易出现丢包,而小包更容易出现包乱序。由于不对响应包大小进行控制,现有方法仅能测量特定包大小的路径度量。
使用同一探测来测量多个度量是一个难题,因为探测包必须在返回的响应包中获取足够的信息用于路径质量测量。使用ICMP不能获得该目的,这是由于响应包包含的信息非常有限。使用TCP SYN、TCP RST和TCP ACK也不能获得该目的,这是因为单个这类包不能测量多个度量,并且它们的大小也不能被测量节点所控制。
结果表明,现在缺乏可测量多种质量度量并确保足够的测量精度和可靠性的方法和工具。
发明内容
本发明提供了从路径的单个端点(其可称为测量节点)同时测量网络路径多个质量度量的新方法和新设备。测量节点发送由多个探测数据包组成的探测以获取至少一个来自测量路径的远端端点(或节点)的响应包。为实现本发明,该探测的探测数据包必须一个接一个地发送而不能有延时,或者延时不会引起从远端节点发起的包重传。而且探测数据包的大小可以由测量节点来设置。
探测和响应数据包携带正常网络应用的数据。响应数据包的可能顺序是可预先确定的,并且提供足以确定各个探测包的传送状态和每个新响应数据包的传送状态的信息。探测数据包能够以与它们的发送次序相同或不同的次序接收。此外,每个探测数据包都可以在正向传输路径上接收或丢失,每个响应数据包都可以在反向传输路径上接收或丢失。如果多个响应数据包被接受,它们的接收次序可以与它们的发送次序相同或不同。该包传送状态可用于计算正向传输路径和反向传输路径丢包统计、正向传输路径和反向传输路径包乱序统计和每一数据包的往返时间(RTT)。
作为本发明的第一个重要方面,所述探测数据包和正常网络应用的数据包无法通过包头值进行区分。此外,探测数据包可根据正常网络应用的协议来设置以获得响应数据包。根据以上这些,其结果是,探测和响应数据包都可以看作是正常的数据通信。另一好处是探测数据包与同一路径上传送的正常应用数据包将被用相同的方法来处理。因此,测量结果更加精确地反应了正常应用数据包所经历的路径质量。
作为本发明第二个重要方面,探测包携带至少一个正常网络应用的真实消息,该消息被设计成用于获取来自远端节点的至少一个真实消息以用于数据路径质量测量。因此,响应包携带来自远端节点的至少一个消息或者一个应用消息的一部分。出于本发明的目的,这些应用消息可以是任何在应用层协议中被允许的消息。换句话说,通过该探测和响应包发送的消息是根据正常应用层协议进行交换的。其结果是,应用消息可被看作是正常的网络应用的通信。
作为本发明的第三重要方面,每个响应数据包被设计成包含一个序列号和一个确认号(用于数据可靠性服务)。对于每个探测包的传送场景(如,以相同的次序接收该探测包、以及第一探测包丢失),在正向传输链路上该响应数据包的顺序(由它们的次序和确认号确定)是可区别的。此外,这些顺序可以在发送探测数据包之后通过测量节点预先确定。因此,响应数据包包含足够的信息来确定每个探测数据包的传送状态和每个响应数据包的传送状态。另外,一个可靠的数据传输协议有可能提供测量节点以控制响应数据包的大小的机制。
作为本发明的一个实施例,传输控制协议(TCP)数据包可用于测量数据路径质量以显示本发明在此应用中的实例。当然,其他类型的数据包(如流控制传输协议)也可以使用。根据本发明的指导思想,本领域技术人员也可采用其他数据包实现本发明。在使用TCP数据包的实施例中,发送两个探测TCP数据包来获取至多两个新的响应TCP数据包用于数据路径质量测量。每个探测TCP数据包携带超文本传输通讯协议(HTTP)GET数据,该数据可触发由一个或多个响应TCP数据包携带的HTTP响应数据。
从上述内容可以看出,本发明避免了现有的非协作测量方法所面临的两个主要问题。由于使用正常数据包互换和正常的网络应用数据互换来实现测量,本发明提供了可靠的测量。此外,响应数据包包含足够的信息来获得至少三种类型的数据路径质量度量。丢包和包乱序度量被用于正向传输路径、反向传输路径、和不同大小的探测和响应数据包的组合。
在后附的权利要求中特别指出了本发明的各个具有新颖性的特征,并且该权利要求进一步构成了本发明公开的一部分。为了更好地理解本发明,其运行优势,和使用目的,可以参照示出并描述了本发明的优选实施例的附图和下列说明书。
附图说明
参考下列说明书结合附图,能够更容易地理解本发明的目的、特征和优点。附图中,相同的附图标记在各幅附图中用于表示相同的部件或功能相似的部件,其中,带有字母符号的附图标记可用于识别各幅附图中选定组成实施例的附加类型、实施例或变形,其中:
图1是示出本发明的特定实施例的框图;
图2是示出了在根据本发明的特定实施例中的连续探测回合(successiveprobe round)的流程图;
图3是示出了在根据本发明的典型测量节点的框图;
图4是示出了根据本发明的用于网络服务的测量节点执行的典型测量进程的时间轴图表;
图5是示出了在根据本发明的特定实施例中的两个连续探测回合中的服务器响应的时间轴图表;
图6是示出了在根据本发明的特定实施例中的接收乱序的探测的服务器响应的时间轴图表;
图7是示出了在根据本发明的特定实施例中的仅接收第二探测数据包的服务器响应的时间轴图表;
图8是示出了在根据本发明的特定实施例中的仅接收第一探测数据包的服务器响应的时间轴图表;
图9是示出了在根据本发明的特定实施例中的不接收探测数据包的服务器响应的时间轴图表;
图10是示出了在根据本发明的特定实施例中的接收乱序的探测(包括TCP ACK)的服务器响应的时间轴图表;
图11是示出了在根据本发明的特定实施例中支持的部分路径度量组的框图。
具体实施方式
总论
图1是示出了根据本发明的特定实施例的框图。其包括测量节点101和远端节点103、105和107。该测量节点101通过网络113通常包括多个跳转点(hop)(如路由器)发送两个探测TCP数据包P1 109和P2 111到远端节点103。该远端节点103,响应接收109和111,并发送两个响应TCP数据包R1 115和R2 117到101。该数据包109、111、115和117可在101和103之间建立的同一TCP连接中发送。该探测TCP数据包在正向传输路径119上发送,在此所述响应TCP数据包在反向传输路径121上发送。
同时,测量节点101可在101和105之间建立的另一TCP连接中将两个探测数据包P1’123和p2’125发送给远端节点105。然而,P1’123和p2’125以逆序被105接收。两个乱序的数据包从105获取两个响应数据包R1’127和R2’129。
同时,测量节点101可在101和107之间建立的另一TCP连接中将两个探测数据包P1”131和p2”133发送给远端节点107。然而,p2”133在网络113中丢失。P1”131从107获取两个响应数据包R1”135和R2”137。
响应TCP数据包和它们的到达次序提供足够的信息给101以确定P1 109是被103接收了还是在119上丢失了,P2 111是被103接收了还是在119上丢失了。如果109和111都被103接收的话,101可确定它们是以相同的次序接收或是以相反的次序接收。同时,101可确定R1 115是否在121上丢失,或R2 117是否在121上丢失。如果115和117均被接收,101可确定它们是以与传输次序相同的次序接收或是相反的次序接收。此外,如果探测TCP数据包和该探测包获取的响应TCP数据包都没有丢失的话,可以计算每个探测TCP数据包的往返时间(RTT)。
图2是示出了在根据本发明的特定实施例中的连续探测回合的流程图。在发送两个探测TCP数据包201之后,该测量节点是处于接收模式,以用于从远端节点获取响应TCP数据包。在接收响应TCP数据包203之后,发送探测包201之后的响应TCP数据包将用于确定每个探测TCP数据包的传送状态和每个响应TCP数据包的传送状态205。如果在207能作出判断,在发送两个新的探测TCP数据包201之前,可在209执行某些准备工作。如果不能在211作出这一判断,该测量节点将等待下一响应TCP数据包203。
在收集连续数量的探测回合的包传送状态和RTT之后,可计算多个数据路径质量的度量的统计量。例如,可计算第一个探测TCP数据包的平均RTT。同时,也可以计算第一个探测TCP数据包的平均丢包率(也就是,正向传输路径丢包率)。同样的,也可以计算第一个响应TCP数据包的平均丢包率(也就是反向传输路径丢包率)。如果可以接收两个探测TCP数据包,可计算它们的平均包乱序率(也就是,正向传输路径包乱序率)。类似地,如果可以接收两个响应TCP数据包,可计算它们的平均包乱序率(也就是,反向传输路径包乱序率)。
在Web会话中的测量
图3是示出了在根据本发明的典型测量节点的详细框图。测量节点301从用户305获得http URL 303。使用该URL 303,HTTP模块307在HTTP层327准备用于URL 303的HTTP GET消息309,并将该消息309传递给TCP层313的测量核心311。该测量核心311负责准备和分发探测TCP数据包P1 315和P2 317。该探测TCP数据包315和317在其数据载荷中携带HTTP GET消息309。
该测量核心311还可负责接收在其数据载荷中携带HTTP响应消息的响应TCP数据包R1 319和R2 321,和负责确定数据包传送状态和计算每个包RTT。另外,用户305可输入探测和响应包大小323、采样率和样式325。该包大小请求323被传递给HTTP模块307以满足包大小的要求。采样率和样式325被传递给测量核心311以满足采样处理的要求。
图4是示出了根据本发明的用于web服务的测量节点执行的典型测量的时间轴图表。该测量节点401发送TCP SYN包403以与web服务器405建立TCP连接。在接收TCP SYN-ACK数据包407以后,该测量节点401发送携带用于url-1的HTTP GET消息431的探测TCP数据包C0’409。在接收请求431之后,web服务器405准备用于url-1的HTTP GET消息441,该用于url-1的HTTP GET消息441在连续的多个响应TCP数据包S1 413、S2 415、S3 417、S4 419、S5 421等中发送。
在接收由TCP ACK 433获取的S2 415和S3 417之后,该测量节点401通过分发第一个两双探测TCP数据包C1’423和C2’425,启动第一个探测回合来进行数据路径质量测量,这两个探测TCP数据包分别获取两个响应TCP数据包S4 419和S5 421。这两个探测TCP数据包C1’423和C2’425也可携带相同的用于url-1的HTTP GET消息431。新的探测回合可在接收到响应TCP数据包S5 421后开始。因此,这一TCP连接中执行的测量由两个连续阶段:准备阶段427和探测阶段429组成。
HTTP模块
HTTP模块利用应用层的HTTP进行路径测量,但是测量核心可利用任何基于TCP的应用层协议进行路径测量。HTTP模块和测量核心之间的接口是基于从HTTP模块传递给测量核心的HTTP GET消息的。因此可独立于测量核心之外设计和实现HTTP模块。该HTTP模块的主要任务包括找到一个或多个用于用户指定包大小的合格http URL和准备用于该合格http URL的HTTPGET消息。
如果http URL的HTTP GET消息能够被改造成具有特定探测包大小的探测数据包,且该HTTP GET消息能够从服务器获取具有特定响应包大小的至少5个响应数据包,那么该http URL可以被认为是合格的。提出最少5个相应数据包的要求是因为在准备阶段427有三个额外的数据响应包413,415和417。用Zp和Zr分别表示以字节为单位的用户指定探测包大小和响应包大小。所有的包大小包括IP和TCP报头。因此,合格的URL的HTTP GET消息的长度将不会超过Zp-40字节(假定40比特TCP/IP报头)。此外,对应的HTTP响应消息的长度,包括HTTP响应报头和消息体,必须是至少5×(Zr-40)字节。
校验HTTP GET消息的长度是较为简单的。然而,检验URL是否符合响应数据包的大小要求需要进行一些工作。如果在HTTP响应消息中出现内容长度报头字段,那么总长度是该字段值和HTTP响应报头长度之和。否则,HTTP模块将下载整个HTTP响应消息以确定其长度。如果不能获得合格的URL,该HTTP模块将执行web信息采集以重获所有的可用URL,该网页信息采集始于web服务器的根部并向下采集一定的深度。
此外,合格URL的HTTP GET消息必须包括200(OK)响应。该404(未找到)响应不能使用以避免在该站点上引起安全警报。类似地,需要避免那些不具有消息体的HTTP响应消息(例如,304(未被修改的))。
为了制作用于HTTP GET消息的Zp-字节探测数据包,该HTTP模块通过HTTP参考字段来扩展包大小。因为某些网站服务器仅仅接受与其自身网页相关的请求,该HTTP模块首先将请求的URL添加到参考字段以避免可能的阻滞。如果该包大小仍然不足,该HTTP模块进一步不断重复添加一个定制串直到满足用户指定包大小,其中该定制串包括探测ID和可能的其他合适信息(如联系邮件地址)。此外,为了降低在分发探测过程中由于可能存在的上下文切换引起的延时,该HTTP模块将在开始测量之前制作用于合格的http URL的HTTP GET消息。
该HTTP模块通过在每个用于路径测量的探测数据包中包括HTTP GET消息来使用HTTP/1.1的请求管线特征(request pipelining feature)。该管线HTTPGET消息可以请求单个或多个URL。也可以采用其他方法来配置探测数据包,例如在数个连续探测数据包之间发送大HTTP GET消息,或在单个探测数据包中包括多个HTTP GET消息。但是这些可选方法将会引入响应数据包返回延时和发送太多HTTP GET消息的问题。
此外,HTTP响应消息通常不会完全占据最后一个响应数据包。因此,响应数据包可以包含一部分来自两个HTTP响应消息的数据。另一方面,可以看到某些响应数据包仅包含HTTP响应消息的最后一个组块。因此,这些响应包不满足包大小需求。在这种情况下,该HTTP模块将使用下一HTTP响应消息来继续同一TCP连接中的测量。
另一重要机制是防止web服务器压缩HTTP响应消息,例如,该压缩可以是由Apache服务器的mod_deflate模块来执行的。压缩的HTTP响应消息将影响测量,这是因为用于合格URL的响应数据包的预计数量减少了。因此,每个HTTP GET消息指定Accept编码:identity;q=1,*;q=0″,在此,″identity;q=1″是指″identity″编码(也就是,无转换)将在整个响应上执行,且″*;q=0″意指避免其他编码方法。
除了使用合格URL用于测量,也可在HTTP/1.1中使用范围请求特征来使用不合格的URL用于路径测量。范围请求可用于请求来自接收范围请求的web服务器的同一对象的多个交迭范围。对于不合格的URL,可以通过范围请求来进行扩展以满足最小的大小要求(也就是,5个响应数据包)。例如,如果一个web服务器仅包含200字节的单个网络对象,下列范围请求报头可以嵌入到每个HTTP GET消息中:″范围:字节=-200,-200,-200,-200″。每个字节-范围-指定器“-200”请求服务器返回网络对象的最后200字节。为响应该范围请求,服务器将返回800字节的单个HTTP响应消息中的4个范围响应。
测量核心
测量核心的设计和实现独立于特定TCP应用。其在一个或多个并行TCP连接中执行测量。为了支持更高的采样率和非周期性采样样式,通常使用多个TCP连接。POSIX线程库(Threads library)可以用来管理单个TCP连接和整个测量进程。此外,因为某些web服务器可能限制一个IP地址发起的并行TCP连接的数量,可将不同的源IP地址分配给这些连接。
在一个测量进程中使用到的TCP连接的数量是可配置参数。该测量核心建立并维持用于测量进程的多个TCP连接。其还可以根据用户指定的采样样式(如周期的和泊松的)和采样率在测量开始前准备探测计划表。该探测计划表包含一个探测任务列表,每个探测任务包含分发时间和探测数量。探测任务一生成就入队到探测进度队列中。
执行测量的方式和机制对于每个TCP连接来说都是相同的。每个TCP连接中的测量是在两个连续阶段中执行的:准备阶段和探测阶段。准备阶段是用作于执行探测阶段的基础工作的。在探测阶段,分发由HTTP模块准备好的HTTP GET消息的探测,分析响应数据包和当进程结束或遇到异常时终止连接。
在准备阶段,测量节点配置探测和响应数据包大小。测量节点401在TCPSYN包403中公告其最大段长(MSS),称为MSSc字节。服务器405在TCPSYN-ACK包407中公告其最大段长(MSS),称为MSSs字节。接着,该测量节点401可将探测数据包大小设置成至多MSSs+40字节,将响应数据包大小设置成至多min{MSSc,MSSs}+40字节。这一阶段的另一目的是,增大服务器对两个TCP数据段的拥塞窗口以开始该探测阶段429。如果服务器的初始拥塞窗口已经是至少两个TCP数据段(通过接收初始HTTP GET消息431之后的两个响应数据包来检测),接着第一探测回合可以开始而不发送TCP ACK 433。
探测阶段在接收到来自服务器405的两个新的响应TCP数据包415和417后就立刻开始。为了分发探测,测量核心首先从探测-计划表队列中重获探测任务。此外,任何已过期的探测任务(其分发时间已经过了当前时间)将从队列中移除并丢弃。当所述探测计划表为空时,测量核心关闭TCP连接。
在获得未过期的探测任务后,该测量核心执行高精度休眠(high resolutionsleep)(例如,使用clock_nanosleep()in time.h)直到到达分发时间。在醒来后,从HTTP模块已经准备好的HTTP GET消息列表中随机获取一对HTTP GET消息,其中每一个HTTP GET消息都在探测数据包中发送。
可使用Linux原始套接字来制作和发送探测数据包,且libpcap 1.0.0库可以用于捕获探测和响应数据包。由于绕过了Linux的TCP/IP数据栈,Linux核心将不会发现测量核心发起的TCP连接,因而它会用TCP RST包响应每个接收到的响应数据包。解决这一问题通常的方法是使用Linux的IP表来滤掉RST包。
另一重要问题是精确地给每个探测和响应数据包产生时间戳以用于RTT测量。如果将libpcap用于捕获这些包,来自每个探测和响应数据包的pcap_pkthdr结构的时间戳可用于以微秒的精度测量RTT。作为另一可选方案,使用来自gettimeofday()的用户级时间戳不是那么可靠,因为该其精确性将受到系统上下文切换的影响。
图5是示出了在根据本发明的两个连续探测回合中的服务器响应的时间轴图表。测量节点501在第一个探测回合发送两个探测数据包503和505以获取来自服务器511的两个响应数据包507与509。在接收新响应数据包507和509之后,测量节点501在第二个测试回合发送两个新的探测数据包513和515以从服务器511获取两个新的响应数据包517和519。
分别采用Cm|n来表示探测数据包和采用Sm|n来表示响应数据包,且m和n分别为TCP数据包的序列号(SN)和确认号(AN)。因为探测和响应数据包包含MSS-大小的TCP数据段,仅是出于方便的目的,m(=1,2,...)用于列举响应TCP数据段,且n(=1′,2′,...)用于列举响应TCP数据段。例如C3′|1521携带来自测量节点501的第三数据段和来自服务器的用于第一数据段的确认,且S3|3′523携带来自服务器511的第三数据段和来自测量节点501的用于第一个三段数据的确认。当AN不重要时,仅使用Cm和Sm,例如第一个两个探测数据包C1′525和C2′527。
虽然在发送第一探测数据包的时刻,两个数据段都会被接收到,但是每个探测数据包仅确认从服务器接收到的一个数据段。例如,甚至在接收两个响应数据包507和509之后,C3′|1 521仅确认服务器的第一数据段。此外,探测数据包公告两个TCP数据段的接收窗以约束服务器的发送窗。其结果是,每个探测数据包,如果没有乱序的话,仅获取一个新的响应数据包。例如,C3′|1 521获取S3|3′523,且C4′|2 529获取S4|4′531。新响应数据包是携带来自服务器的新数据段的TCP数据包。
RTT是基于探测数据包和其获取的新响应数据包(例如C3′|1 513和S3|3′517)而测量的。因此,在没有丢包时,通常可以在一个探测回合中获得两个RTT观测值。然而,使用第一个探测包的RTT来测量更加精确,因为所述第二个探测包的RTT可能被第一个包偏置。
在正向传输路径上,两个探测TCP数据包可能发生5种可能路径事件:F0:两个探测数据包以相同的次序到达服务器;FR:两个探测数据包以相反的次序到达服务器;F1:第一个探测数据包丢失,但是第二个到达服务器;F2:第一个探测数据包到达服务器,但是第二个丢失,和F3:两个探测数据包均丢失。在反向传输路径上,两个新响应数据包也可能发生5种可能路径事件:R0,RR,R1,R2和R3(通过将F0-F3中的“探测”替换成“响应”,并将“服务器”替换成“测量节点”)。其结果是,可能有18中可能的丢失-乱序,如表1中所示:17个事件用″√″表示,一个事件用F3表示。其他用“-”表示的事件是不可能事件,因为最多只能有一个新响应数据包被获取(也就是,没有第二个响应数据包)。对于F3,没有新的响应数据包被获取。
表1
R0 | RR | R1 | R2 | R3 | |
F0 | √ | √ | √ | √ | √ |
FR | √ | √ | √ | √ | √ |
F1 | √ | √ | √ | √ | √ |
F2 | √ | - | √ | - | - |
F3 | - | - | - | - | - |
考虑到两个探测数据包C3′|1 521和C4′|2 529,表2总结了基于“传输控制协议(Transmission Control Protocol)”J.Postel(编辑),RFC 793,IETF,198为这18个事件获取的响应数据包。除了新TCP数据段3和4,服务器有可能重新发送旧TCP数据段1、2和3,用表示数据重发包。因为服务器响应是基于TCP的两个基本数据传输机制:确认-定时传输和超时重传,所有的操作系统都被认为可以产生相同的响应。
表2
对于事件F0×R0,探测数据包获取新响应数据包。因此,C3′|1 521获取S3|3′523,且C4′|2 529获取S4|4′531,且S3|3′523和S4|4′531以相同的次序接收。
图6是示出了根据本发明服务器对接收乱序探测(事件FR×R0)的响应的时间轴图表。乱序C4’|2 533获取两个新响应数据包S3|2’537和S4|2’539,这是因为C4’|2 533确认来自服务器511的两个TCP数据段。然而,新探测将不会被分发,因为两个响应数据包不是确认来自测量节点501的这两个TCP数据段3’和4’。结果,服务器超时且在中重发TCP数据段3。
图7是示出了在根据本发明的特定实施例中的仅接收第二个探测数据包的服务器响应(事件F1×R0)的时间轴图表。第一个探测数据包丢失543。因此,与事件FR×R0中相同,乱序的C4’|2 545获取两个新响应数据包S3|2’547和S4|2’549。出于与事件FR×R0相同的原因,服务器超时且在中重发TCP数据段3。然而,这次数据重发包511是不同于事件FR×R0 541,因为它们的AN不同。
图8是示出了根据本发明的仅接收第一个探测数据包的服务器响应(事件F2×R0)的时间轴图表。第一个探测数据包C3’|1 553获取响应数据包S3|3’557,但是第二个探测数据包C4’|2丢失555。出于与路径事件FR×R0相同的原因,服务器超时且在中重发TCP数据段2。不同于事件FR×R0和F1×R0重传TCP数据段3,这里TCP数据段2是被重传的。因此,数据重发包在FR×R0、F1×R0和F2×R0中是全部可以被区分的。
图9是示出了在根据本发明的没有接收到探测数据包的服务器响应(事件F3×R0)的时间轴图表。C3’|1 561和C4’|2 563均丢失。出于与路径事件FR×R0相同的原因,服务器超时且在重发TCP数据段1。不同于事件FR×R0,F1×R0和F2×R0重传TCP数据段2和3的情况,这里TCP数据段1是被重传的。因此,数据重发包在FR×R0、F1×R0、F2×R0和F3×R0中是全部可以被区分的。
本领域技术人员能够从图5-9轻易地构建其他的路径事件。例如,对于三个反向传输路径乱序事件F0-F1×RR,图5-7中的两个响应数据包的确以逆序被接收,对于4个事件F0-F2×R1,图5-8中的第一个响应数据包丢失。对于三个事件F0-F1×R2,图5-7中的第二个响应数据包丢失。对于三个事件F0-F1×R3,图5-7中的两个响应数据包都丢失。
在响应数据包中不同的SN和AN组合使得对几乎所有的18个路径事件的检测都可实现。通过根据响应数据包分类表2,表3整理出了响应数据包的每个序列唯一地匹配路径事件,下列三种情况除外:A1(F1×R2和F1×R3),A2(F1×RR和F1×R1),和A3(F0×R3和FR×R3)。对于A1,这两个事件不能基于响应数据包区分,这是因为S3|2′和是相同的,且服务器可能重发多次。对于A2,它们不能被区分的原因与A1相同。对于A3,两个事件具有相同的响应数据包
表3
A1和A2的不确定性可以通过区别S3|2′和的RTT来区分。的RTT通常要比S3|2′的RTT要长的多。另一方面,A3中的不确定性可以通过TCP时间戳选项来解决。每个探测数据包在TCP选项字段中包含一个独特的时间戳。如果服务器支持TCP时间戳选项,它会保留从提升其接收窗的最近探测数据包接收到的时间戳,并将该时间戳在下一响应数据包中重复。因此,服务器保留了用于事件F0×R3的时间戳C4′和用于事件FR×R3的时间戳C3′。两个路径事件因此可以基于中不同的时间戳加以区分。
图10是示出了在根据本发明的接收乱序的探测(包括TCP ACK)的服务器响应的时间轴图表。正向传输路径乱序事件的检测可以基于接收TCP ACK567加速,因为该TCP ACK 567的发送通常比数据重发包569要早得多。其他正向传输路径乱序事件(FR×RR,FR×R1,FR×R2和FR×R3)的检测可以以相同的方式加速。
对于路径事件1-2,新探测回合将在接收两个新响应数据包之后立刻开始。对于每一个剩余路径事件,远端节点会超时重发旧的响应TCP数据包,而不依靠TCP ACK,并将拥塞窗口重置到一个TCP数据段。为了开始新的探测回合,该测量核心将首先发送一个或多个新的TCP ACK以增大服务器的拥塞窗口,使其回到两个TCP数据段以用于路径事件3-18。在接收两个新响应数据包之后,测量节点将分发新的探测C5′和C6′用于事件3-10,C4′和C5′用于事件16-17,以及C3′和C4′用于事件18。处理事件11-15是更棘手的。如果使用新的探测C3′和C4′,服务器将丢弃C4′,因为其已经被接收到了。可用的方法是重发具有各自AN的C3′,并在成功重传C3′之后,使用新探测C5′和C6′用于下一探测回合。
在可接受模式下的测量核心捕获响应数据包(例如,使用libpcap)并滤除与该测量无关的数据包,如TCP窗口更新。通过基于表3中的响应数据包的顺序和TCP ACK的协助确定路径事件,接着可以计算出每个数据包RTT的各种统计量、正向传输路径和反向传输路径丢包和正向传输路径和反向传输路径包乱序。例如,在一分钟执行多次连续探测回合(如120)之后,可以通过将第一-探测-丢包事件的数量(和第一个响应-丢包事件)除以120来计算平均正向传输路径(反向传输路径)丢包率。可以以同样的方式计算平均包乱序率。
可以在线或离线处理连续探测回合的测量结果。在线处理是可能的,因为测量节点仅需要基于从服务器接收到的响应数据包的顺序来确定路径事件。离线处理的优点是可以防止处理工作量影响探测过程,且有利于更精确地基于在测量中收集的RTT采样区分A1和A2。
图11是示出了根据本发明支持的部分路径度量组的框图。全部的数据路径质量601由每个包RTT603、正向传输路径质量605和反向传输路径质量607测得。该正向传输路径质量605依次由正向传输路径丢包率609和正向传输路径包乱序率611测得。类似地,反向传输路径质量607依次由反向传输路径丢包率613和反向传输路径包乱序率615测得。正向传输路径丢包率609可通过将第一探测数据丢包数量617除以探测发送总数619来计算。类似地,反向传输路径丢包率613通过将第一响应数据丢包数量621除以探测发送总数619来计算。正向传输路径包乱序率611是基于没有探测数据包丢失的探测627而计算的。该正向传输路径包乱序率611可以通过将乱序的探测数据包623的数量除以627来计算。反向传输路径包乱序率615是基于没有响应数据包丢失的探测629而计算的。该反向传输路径包乱序率615可以通过将乱序的响应数据包625的数量除以629来计算。
一个自我诊断也被包含在此,用于确认此测量是不受自身引起的丢包的影响的。对于正向传输路径测量,尽管包传输可通过成功调用sendto()函数验证,也可能出现发送探测数据包失败。为了检测这些自身引起的丢包,libpcap被用于验证每个向网络外发的探测数据包的发送,对于反向传输路径测量,由于缓存空间不足,自身引起的丢包可能发生在响应数据包上。Libpcap的pcap_stats()函数返回的ps_drop变量能够用于检测这一丢失。
典型探测和响应数据包
表5作为实施例示出了探测和响应数据包的结构(包括TCP报头和TCP有效载荷,每行包含32比特长的字)。属于协议栈下层的其他元素(如IP报头和以太网报头和拖尾(trailer))都被排除,因为它们并不直接涉及该典型实施例。
表5
典型探测和响应数据包的实质内容在下列实施例中示出,
实施例1:路径事件F0×R0
表6是第一个探测数据包C3′|1(具有240字节的TCP数据有效载荷):
表6
表7是第二个探测数据包C4′|2(具有240字节的TCP数据有效载荷):
表7
表8是第一个响应数据包S3|3’(具有240字节的TCP数据有效载荷):
表8
表9是第二个响应数据包S4|4’(具有240字节的TCP数据有效载荷):
表9
实施例2:路径事件FR×R0
表10是第一个探测数据包C3′|1(具有240字节的TCP数据有效载荷):
表10
表11是第二个探测数据包C4′|2(具有240字节的TCP数据有效载荷):
表11
表12是第一个响应数据包S3|2’(具有240字节的TCP数据有效载荷):
表12
表13是第二个响应数据包S4|2’(具有240字节的TCP数据有效载荷):
表13
表14
响应TCP数据包的验证
一小组的验证测试被用来验证操作系统或web服务器返回的响应数据包的正确性。表4描述了四个验证测试V0-V2,其分别“模拟”了正向传输路径事件F0-F2。该测试探测以公告的接收窗口发出以设置两个TCP数据段,且该响应数据包并不被确认以模拟正向传输路径丢包。因此该数据重发被认为应当是和表2中相同。此外,反向传输路径丢包测试已经包含F3的测试,因为不发送下一探测与丢失该探测是一样的。
表4
该验证在实验室和互联网上进行了测试,其结果对测试的所有操作系统和web服务器都是成功的:FreeBSD v4.5/4.11/5.5/6.0/6.2、Linux核v2.4.20/2.6.5/2.6.11/2.6.15/2.6.18/2.6.20、MacOSX 10.4服务器、NetBSD 3.1、OpenBSD 4.1、Solaris 10.1、Windows 2000/XP/Vista、AIX、AS/400、BSD/OS、Compaq Tru64、F5 Big-IP、HP-UX、IRIX、MacOS、NetApp NetCache、NetWare、OpenVMS、OS/2、SCO Unix、Solaris 8/9、SunOS 4、VM、Microsoft WindowsNT4/98/服务器2003/2008、Abyss、Apache、Lighttpd、Microsoft IIS、Nginx、AOL服务器、Araneida、Apache Tomcat、GFE、GWS-GRFE、IBM HTTP服务器、Jetty、Jigsaw、LiteSpeed、Lotus-Domino、Mongrel、Netscape-Enterprise、OmniSecure、Oracle HTTP服务器、Orion、Red Hat Secure、Redfoot、Roxen、Slinger、Stronghold、Sun Java System、thttpd、Twisted Web、Virtuoso、WebLogic、WebSiphon、Yaws、Zeus和Zope。
其他实施例
另一个典型实施例在单个探测中使用三个或更多探测TCP数据包,该探测能够激发两个以上的新响应TCP数据包用于路径测量。该实施例的优点是比第一个实施例包含更多的丢包-包乱序场景。然而,其缺点是该探测的传输更为复杂,难以管理,且响应包的分析更加困难。
另一个典型实施例是执行来自网络服务器(而非网络客户端)的测量。该实施例对于监控大量的网络客户端的数据路径质量是很有用的。
另一个典型实施例使用流控制传输协议(SCTP)代替TCP用于路径测量。由于SCTP支持多个并流TCP类流,该SCTP包含用于实现本发明所需的协议元素。
另一典型实施例使用其他的基于TCP的应用协议用于应用模块,如FTP和P2P、或基于SCTP的应用。
典型计算环境
本发明的方法可用于多个其他通用或专用计算系统环境或配置。众所周知的适合实现本发明的计算系统、环境和/或配置的实施例包括但不限于个人计算机、服务器计算机、瘦客户端、胖客户端、掌上或膝上型设备、多处理器系统、基于微处理器的系统、机顶盒、可编程电子消费品、无线电话、无线通信设备、网络PC、迷你计算机、主机计算机、包括任何上述设备的分布式计算环境或类似产品。
本发明的测量节点能被计算机执行的通用含义来描述,如有计算机执行的程序模块。通常,程序模块包括例行程序、程序、对象、组件、数据结构等等,可以执行特定任务或实现特定抽象数据类型。本发明的测量节点可以在分布式计算环境中实现,在该分布式计算机环境中,由通过通信网络连接的远端处理设备来完成任务。在分布式计算环境中,程序模块可以位于本地或远端计算机存储媒介,包括存储器设备,中。
虽然已经描述和指出了当本发明应用到首选的实施例的基本创新特征,应当理解,本领域的技术人员可以在不离开本发明的精神和范围情况下,在形式上和细节上还可以对其进行各种省略、替换和变化。因此,本发明的保护范围不应当仅局限于以上描述的任一实施例,而应该依照权利要求来限定。
Claims (18)
1.一种非协作测量通信网络的数据路径质量的方法,其特征在于,包括:
(a)测量节点发送探测包并接收从远端节点来的响应数据包,所述探测数据包包括至少两个携带正常网络应用的数据的数据包,且来自所述远端节点的响应包含至少一个数据包,该所述至少一个数据包携带网络应用消息;
(b)接收并处理所述远端响应中的所述数据包,所述响应能提供至少三种类型的数据路径质量度量,和
(c)从所述步骤(b)中处理的所述数据路径质量获得关于所述测量节点和所述远端节点之间的数据路径质量测量或估计。
2.根据权利要求1所述的方法,其特征在于,进一步包括在执行步骤(c)之前多次重复步骤(a)和(b)。
3.根据权利要求2所述的方法,其特征在于,所述三种类型的路径质量度量是往返时间、丢包率和包乱序率。
4.根据权利要求3所述的方法,其特征在于,所述丢包率包括独立的正向路径丢包率和反向路径丢包率。
5.根据权利要求3所述的方法,其特征在于,所述包乱序率包括独立的正向路径包乱序率和反向路径包乱序率。
6.根据权利要求1所述的方法,其特征在于,所述通信网络支持TCP/IP协议且所述网络应用使用TCP协议且所述探测和所述响应的所述数据包是TCP数据包。
7.根据权利要求6所述的方法,其特征在于,所述远端节点是网络服务器,来自所述测量节点的应用消息是HTTP GET消息,且来自所述网络服务器的应用消息是HTTP响应消息。
8.根据权利要求7所述的方法,其特征在于,所述在步骤(a)中以用户指定的预定的探测包大小、预定的采样率和预定的采样样式发送所述探测。
9.根据权利要求7所述的方法,其特征在于,在所述步骤(b)中,以用户指定的预定响应包大小接收所述响应。
10.一种用于执行权利要求1的方法、并能发送探测数据包给远端节点、接收和处理来自所述远端节点的响应的设备,其特征在于,包括:
(a)用户输入终端,
(b)探测准备模块,和
(c)测量核心;
其中所述用户输入终端用于指定关于所述远端节点的特性、用于所述探测和所述响应的包大小、以及探测采样率和采样样式的信息,所述探测准备模块使用来自所述用户终端的关于所述远端节点的特性、以及用于所述探测和所述响应的包大小的信息配置所述探测;所述测量核心负责以基于所述用户输入终端指定的所述信息的探测采样率和采样样式发送所述探测给所述远端节点,和处理来自所述远端节点的响应以获取一组数据路径质量度量。
11.根据权利要求10所述的设备,其特征在于,所述设备是连接处于测量中的通信网络的通用计算机,其中所述用户输入终端、探测准备模块和测量核心是至少部分通过软件执行构建的。
12.根据权利要求10所述的设备,其特征在于,所述探测准备模块是使用网络服务器用于数据路径质量测量的HTTP模块,所述HTTP模块能够找到一个或多个合格http URL用于用户指定包大小,和准备用于每个所述合格httpURL的HTTP GET消息。
13.根据权利要求12所述的设备,其特征在于,所述HTTP GET消息必须引起来自所述远端节点的200(OK)响应。
14.根据权利要求12所述的设备,其特征在于,所述HTTP GET消息不包含来自所述远端节点的404(未找到)响应或304(未修改)响应。
15.根据权利要求10所述的设备,其特征在于,所述测量核心独立于所述探测准备模块基于的所述TCP应用的类型进行操作。
16.根据权利要求10所述的设备,其特征在于,所述测量核心以单个TCP连接操作,或以两个或多个并行TCP连接进行操作。
17.根据权利要求1所述的设备,其特征在于,所述响应的所述数据包包括序列号和确认号。
18.根据权利要求17所述的设备,其特征在于,所述响应的所述数据包的大小由用户预定。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/482,470 | 2009-06-11 | ||
US12/482,470 US20100315958A1 (en) | 2009-06-11 | 2009-06-11 | Method for non-cooperative measurement of network data-path quality |
PCT/CN2010/073805 WO2010142250A1 (en) | 2009-06-11 | 2010-06-11 | Method for non-cooperative measurement of network data-path quality |
Publications (1)
Publication Number | Publication Date |
---|---|
CN102150395A true CN102150395A (zh) | 2011-08-10 |
Family
ID=43306365
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201080001287XA Pending CN102150395A (zh) | 2009-06-11 | 2010-06-11 | 用于网络数据路径质量的非协作测量方法 |
Country Status (3)
Country | Link |
---|---|
US (2) | US20100315958A1 (zh) |
CN (1) | CN102150395A (zh) |
WO (1) | WO2010142250A1 (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103036696A (zh) * | 2011-09-30 | 2013-04-10 | 中国移动通信集团甘肃有限公司 | 一种联机业务的实现方法、系统及相应设备 |
CN103765822A (zh) * | 2011-09-09 | 2014-04-30 | 高通股份有限公司 | 用于端到端多径网络系统的反馈协议 |
CN107925591A (zh) * | 2015-09-30 | 2018-04-17 | 英国电讯有限公司 | 网络性能的分析 |
US10277498B2 (en) | 2015-10-08 | 2019-04-30 | British Telecommunications Public Limited Company | Analysis of network performance |
US10320648B2 (en) | 2015-09-30 | 2019-06-11 | British Telecommunications Public Limited Company | Analysis of network performance |
CN110022240A (zh) * | 2018-01-09 | 2019-07-16 | 香港理工大学深圳研究院 | 一种网络状态的测试方法、测试装置及终端设备 |
Families Citing this family (49)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7633917B2 (en) * | 2006-03-10 | 2009-12-15 | Cisco Technology, Inc. | Mobile network device multi-link optimizations |
US8576715B2 (en) * | 2009-10-26 | 2013-11-05 | Mellanox Technologies Ltd. | High-performance adaptive routing |
US8370521B2 (en) * | 2010-07-27 | 2013-02-05 | Sap Ag | Reliable data message exchange |
US8717916B2 (en) * | 2011-03-28 | 2014-05-06 | Citrix Systems, Inc. | Systems and methods for learning MSS of services |
US9225628B2 (en) | 2011-05-24 | 2015-12-29 | Mellanox Technologies Ltd. | Topology-based consolidation of link state information |
US9444887B2 (en) | 2011-05-26 | 2016-09-13 | Qualcomm Incorporated | Multipath overlay network and its multipath management protocol |
US8995338B2 (en) | 2011-05-26 | 2015-03-31 | Qualcomm Incorporated | Multipath overlay network and its multipath management protocol |
US8849910B2 (en) * | 2011-06-03 | 2014-09-30 | Oracle International Corporation | System and method for using quality of service with workload management in an application server environment |
US9215283B2 (en) * | 2011-09-30 | 2015-12-15 | Alcatel Lucent | System and method for mobility and multi-homing content retrieval applications |
CN103095517B (zh) * | 2011-11-04 | 2016-12-07 | 华为技术有限公司 | 流媒体传输质量评估和信息获取方法及相关设备和系统 |
US9397960B2 (en) | 2011-11-08 | 2016-07-19 | Mellanox Technologies Ltd. | Packet steering |
US8885473B2 (en) | 2011-11-30 | 2014-11-11 | The Hong Kong Polytechnic University | Method for measurement of asymmetric network capacities |
US9871734B2 (en) | 2012-05-28 | 2018-01-16 | Mellanox Technologies, Ltd. | Prioritized handling of incoming packets by a network interface controller |
US10333820B1 (en) | 2012-10-23 | 2019-06-25 | Quest Software Inc. | System for inferring dependencies among computing systems |
US9557879B1 (en) | 2012-10-23 | 2017-01-31 | Dell Software Inc. | System for inferring dependencies among computing systems |
US9014006B2 (en) | 2013-01-31 | 2015-04-21 | Mellanox Technologies Ltd. | Adaptive routing using inter-switch notifications |
US10389608B2 (en) | 2013-03-15 | 2019-08-20 | Amazon Technologies, Inc. | Network traffic mapping and performance analysis |
US9742638B1 (en) * | 2013-08-05 | 2017-08-22 | Amazon Technologies, Inc. | Determining impact of network failures |
US10454991B2 (en) | 2014-03-24 | 2019-10-22 | Mellanox Technologies, Ltd. | NIC with switching functionality between network ports |
US11005738B1 (en) | 2014-04-09 | 2021-05-11 | Quest Software Inc. | System and method for end-to-end response-time analysis |
US9479414B1 (en) | 2014-05-30 | 2016-10-25 | Dell Software Inc. | System and method for analyzing computing performance |
US20150359016A1 (en) * | 2014-06-09 | 2015-12-10 | Qualcomm Incorporated | Apparatus and method to estimate round trip time via transport control protocol signals |
US9729473B2 (en) | 2014-06-23 | 2017-08-08 | Mellanox Technologies, Ltd. | Network high availability using temporary re-routing |
US9806994B2 (en) | 2014-06-24 | 2017-10-31 | Mellanox Technologies, Ltd. | Routing via multiple paths with efficient traffic distribution |
US9699067B2 (en) | 2014-07-22 | 2017-07-04 | Mellanox Technologies, Ltd. | Dragonfly plus: communication over bipartite node groups connected by a mesh network |
CN105634836B (zh) * | 2014-10-27 | 2020-03-17 | 香港理工大学 | 信息处理方法及装置 |
US10291493B1 (en) * | 2014-12-05 | 2019-05-14 | Quest Software Inc. | System and method for determining relevant computer performance events |
US9996577B1 (en) | 2015-02-11 | 2018-06-12 | Quest Software Inc. | Systems and methods for graphically filtering code call trees |
KR102286882B1 (ko) * | 2015-03-06 | 2021-08-06 | 삼성전자 주식회사 | 이동 통신 시스템에서 사용자 체감 품질 관리 방법 및 장치 |
US9894005B2 (en) | 2015-03-31 | 2018-02-13 | Mellanox Technologies, Ltd. | Adaptive routing controlled by source node |
US10187260B1 (en) | 2015-05-29 | 2019-01-22 | Quest Software Inc. | Systems and methods for multilayer monitoring of network function virtualization architectures |
CN106341342A (zh) * | 2015-07-09 | 2017-01-18 | 阿里巴巴集团控股有限公司 | 维持通信连接的方法、装置、终端及服务器 |
US10200252B1 (en) | 2015-09-18 | 2019-02-05 | Quest Software Inc. | Systems and methods for integrated modeling of monitored virtual desktop infrastructure systems |
CN107925590B (zh) | 2015-09-30 | 2018-12-18 | 英国电讯有限公司 | 分析与网络的一个或更多个部分有关的网络性能的方法和设备 |
US9973435B2 (en) | 2015-12-16 | 2018-05-15 | Mellanox Technologies Tlv Ltd. | Loopback-free adaptive routing |
US10819621B2 (en) | 2016-02-23 | 2020-10-27 | Mellanox Technologies Tlv Ltd. | Unicast forwarding of adaptive-routing notifications |
US10178029B2 (en) | 2016-05-11 | 2019-01-08 | Mellanox Technologies Tlv Ltd. | Forwarding of adaptive routing notifications |
US10230601B1 (en) | 2016-07-05 | 2019-03-12 | Quest Software Inc. | Systems and methods for integrated modeling and performance measurements of monitored virtual desktop infrastructure systems |
US10200294B2 (en) | 2016-12-22 | 2019-02-05 | Mellanox Technologies Tlv Ltd. | Adaptive routing based on flow-control credits |
US10644995B2 (en) | 2018-02-14 | 2020-05-05 | Mellanox Technologies Tlv Ltd. | Adaptive routing in a box |
US10819562B2 (en) * | 2018-07-24 | 2020-10-27 | Zscaler, Inc. | Cloud services management systems utilizing in-band communication conveying situational awareness |
US11005724B1 (en) | 2019-01-06 | 2021-05-11 | Mellanox Technologies, Ltd. | Network topology having minimal number of long connections among groups of network elements |
CN114009089A (zh) * | 2019-06-30 | 2022-02-01 | 瑞典爱立信有限公司 | 在通信网络中估计时延敏感业务流的质量度量 |
US11575594B2 (en) | 2020-09-10 | 2023-02-07 | Mellanox Technologies, Ltd. | Deadlock-free rerouting for resolving local link failures using detour paths |
US11411911B2 (en) | 2020-10-26 | 2022-08-09 | Mellanox Technologies, Ltd. | Routing across multiple subnetworks using address mapping |
US11398979B2 (en) | 2020-10-28 | 2022-07-26 | Mellanox Technologies, Ltd. | Dynamic processing trees |
WO2022257140A1 (zh) * | 2021-06-11 | 2022-12-15 | 华为技术有限公司 | 数据发送的方法和通信装置 |
US11870682B2 (en) | 2021-06-22 | 2024-01-09 | Mellanox Technologies, Ltd. | Deadlock-free local rerouting for handling multiple local link failures in hierarchical network topologies |
US11765103B2 (en) | 2021-12-01 | 2023-09-19 | Mellanox Technologies, Ltd. | Large-scale network with high port utilization |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060085420A1 (en) * | 2004-09-27 | 2006-04-20 | Symphoniq Corp. | Method and apparatus for monitoring real users experience with a website |
US20070076605A1 (en) * | 2005-09-13 | 2007-04-05 | Israel Cidon | Quality of service testing of communications networks |
US7457868B1 (en) * | 2003-12-30 | 2008-11-25 | Emc Corporation | Methods and apparatus for measuring network performance |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2001285400A (ja) * | 2000-03-29 | 2001-10-12 | Kddi Corp | トラヒック統計情報収集方法 |
US20090116402A1 (en) * | 2004-10-21 | 2009-05-07 | Nec Corporation | Communication quality measuring apparatus and communication quality measuring method |
WO2007078008A1 (ja) * | 2006-01-06 | 2007-07-12 | Nec Corporation | 伝送路の品質計測装置、通信システム、品質計測方法および品質計測プログラム |
US8051069B2 (en) * | 2008-01-02 | 2011-11-01 | At&T Intellectual Property I, Lp | Efficient predicate prefilter for high speed data analysis |
JP5056438B2 (ja) * | 2008-01-29 | 2012-10-24 | 富士通株式会社 | パケット解析方法 |
CN101404597B (zh) * | 2008-11-19 | 2013-06-05 | 华为技术有限公司 | 一种网络质量指标的获取方法、系统及装置 |
US20100265833A1 (en) * | 2009-04-16 | 2010-10-21 | Ou Frank Y | Network bandwidth determination |
-
2009
- 2009-06-11 US US12/482,470 patent/US20100315958A1/en not_active Abandoned
-
2010
- 2010-06-11 CN CN201080001287XA patent/CN102150395A/zh active Pending
- 2010-06-11 WO PCT/CN2010/073805 patent/WO2010142250A1/en active Application Filing
-
2012
- 2012-10-22 US US13/657,489 patent/US20130044625A1/en not_active Abandoned
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7457868B1 (en) * | 2003-12-30 | 2008-11-25 | Emc Corporation | Methods and apparatus for measuring network performance |
US20060085420A1 (en) * | 2004-09-27 | 2006-04-20 | Symphoniq Corp. | Method and apparatus for monitoring real users experience with a website |
US20070076605A1 (en) * | 2005-09-13 | 2007-04-05 | Israel Cidon | Quality of service testing of communications networks |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103765822A (zh) * | 2011-09-09 | 2014-04-30 | 高通股份有限公司 | 用于端到端多径网络系统的反馈协议 |
CN103765822B (zh) * | 2011-09-09 | 2017-05-10 | 高通股份有限公司 | 用于端到端多径网络系统的反馈协议 |
CN103036696A (zh) * | 2011-09-30 | 2013-04-10 | 中国移动通信集团甘肃有限公司 | 一种联机业务的实现方法、系统及相应设备 |
CN103036696B (zh) * | 2011-09-30 | 2016-05-25 | 中国移动通信集团甘肃有限公司 | 一种联机业务的实现方法、系统及相应设备 |
CN107925591A (zh) * | 2015-09-30 | 2018-04-17 | 英国电讯有限公司 | 网络性能的分析 |
CN107925591B (zh) * | 2015-09-30 | 2018-12-18 | 英国电讯有限公司 | 分析包括多个网络节点的网络的网络性能的方法和设备 |
US10320648B2 (en) | 2015-09-30 | 2019-06-11 | British Telecommunications Public Limited Company | Analysis of network performance |
US10419324B2 (en) | 2015-09-30 | 2019-09-17 | British Telecommunications Public Limited Company | Analysis of network performance |
US10277498B2 (en) | 2015-10-08 | 2019-04-30 | British Telecommunications Public Limited Company | Analysis of network performance |
CN110022240A (zh) * | 2018-01-09 | 2019-07-16 | 香港理工大学深圳研究院 | 一种网络状态的测试方法、测试装置及终端设备 |
CN110022240B (zh) * | 2018-01-09 | 2021-03-23 | 香港理工大学深圳研究院 | 一种网络状态的测试方法、测试装置及终端设备 |
Also Published As
Publication number | Publication date |
---|---|
US20100315958A1 (en) | 2010-12-16 |
WO2010142250A1 (en) | 2010-12-16 |
US20130044625A1 (en) | 2013-02-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102150395A (zh) | 用于网络数据路径质量的非协作测量方法 | |
US8938532B2 (en) | Methods, systems, and computer program products for network server performance anomaly detection | |
Mogul | Observing TCP dynamics in real networks | |
US8085673B2 (en) | Method and apparatus for generating bi-directional network traffic and collecting statistics on same | |
CN101217429B (zh) | 基于tcp时间戳选项确定tcp报文之间的引发关系的方法 | |
US7779133B2 (en) | Estimation of web client response time | |
US8885473B2 (en) | Method for measurement of asymmetric network capacities | |
US20070217448A1 (en) | Estimating Available Bandwidth With Multiple Overloading Streams | |
CN105634836A (zh) | 信息处理方法及装置 | |
Luo et al. | Design and Implementation of TCP Data Probes for Reliable and Metric-Rich Network Path Monitoring. | |
JP5669853B2 (ja) | 改善されたクロック・オフセット測定の技術 | |
US7221649B2 (en) | Method and apparatus for identifying delay causes in traffic traversing a network | |
Hegde et al. | FAST TCP in high-speed networks: An experimental study | |
Ding et al. | TCP stretch acknowledgements and timestamps: findings and implications for passive RTT measurement | |
Pögel et al. | Passive client-based bandwidth and latency measurements in cellular networks | |
CN102694736A (zh) | 吞吐率的获取方法和装置 | |
US20050102391A1 (en) | Method and apparatus providing an asymmetric ping procedure | |
Luo et al. | Novel approaches to end-to-end packet reordering measurement | |
Rajaboevich et al. | Analysis of methods for measuring available bandwidth and classification of network traffic | |
US20140078911A1 (en) | Method and apparatus to determine the amount of delay in round trip latency for a connection where the tcp traffic does not contain multi-packet responses or may not be transaction oriented traffic. | |
CN105611406A (zh) | 一种接入网服务商监测用户到视频服务器延迟特性方法 | |
WO2015110620A1 (en) | Reliable network probing session | |
Li et al. | ART: Adaptive Retransmission for Wide-Area Loss Recovery in the Wild | |
CN115150283B (zh) | 网络带宽探测方法、装置、计算机设备和存储介质 | |
Lance | Network state estimation via passive traffic monitoring |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20110810 |