CN103036746B - 基于网络中间点的网页响应时间被动测量方法及*** - Google Patents

基于网络中间点的网页响应时间被动测量方法及*** Download PDF

Info

Publication number
CN103036746B
CN103036746B CN201210563218.9A CN201210563218A CN103036746B CN 103036746 B CN103036746 B CN 103036746B CN 201210563218 A CN201210563218 A CN 201210563218A CN 103036746 B CN103036746 B CN 103036746B
Authority
CN
China
Prior art keywords
packet
http
information
webpage
module
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.)
Active
Application number
CN201210563218.9A
Other languages
English (en)
Other versions
CN103036746A (zh
Inventor
徐翔
张广兴
谢高岗
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Institute of Computing Technology of CAS
Original Assignee
Institute of Computing Technology of CAS
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Institute of Computing Technology of CAS filed Critical Institute of Computing Technology of CAS
Priority to CN201210563218.9A priority Critical patent/CN103036746B/zh
Publication of CN103036746A publication Critical patent/CN103036746A/zh
Application granted granted Critical
Publication of CN103036746B publication Critical patent/CN103036746B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Information Transfer Between Computers (AREA)

Abstract

本发明提供一种基于网络中间点的网页响应时间被动测量方法及***,该方法包括:步骤1,数据包获取:数据包获取模块通过网卡或板卡在网络中间点实时捕获所有用户与网页交互的网络数据包,并将所述网络数据包发送给数据包分用模块;步骤2,数据包分用:数据包分用模块根据所述网络数据包的链路层、网络层和传输层协议对其进行分用处理;步骤3,数据包解析:数据包解析模块解析所述网络数据包并提取其IP、TCP和HTTP头部信息,根据所述IP、TCP和HTTP头部信息标记网络数据包类型;步骤4,响应时间测量:响应时间测量模块对不同类型的网络数据包进行相应处理,测量所有网页的响应时间。本发明的测量准确、实时、全面、高效。

Description

基于网络中间点的网页响应时间被动测量方法及***
技术领域
本发明涉及计算机网络流量测量领域,尤其涉及一种基于网络中间点的网页响应时间被动测量方法及***。
背景技术
随着万维网(WWW)的广泛应用,越来越多的应用业务通过万维网提供给用户,如:新闻浏览、在线视频、网络购物、社交网络等等。对于用户而言,他们希望获取高质量的在线服务,而用户感知的网页响应时间大小在很大程度上决定着用户对服务质量的体验。当感知的网页响应时间超过期望阈值时,用户便会放弃使用当前服务而转向同类型其他服务。因此网页响应时间的大小在一定程度上决定着业务的成败,对网页响应时间进行实时准确地测量对于业务提供商具有重要的意义,以便他们在网页响应时间出现异常时作出及时反馈并采取措施。另一方面,提供商也面临着提供区分服务的挑战,为了保证不同类型的用户都能获得预先约定的服务质量,网页响应时间不会超过限值,有必要对网页响应时间进行准确实时地测量,以便根据测量数据动态调整提供的网络资源。当前主要的网页响应时间测量方法有以下几种:
(1)主动测量方法。这种方法需要在尽量分散的多个地理位置上部署多个监控器,这些监控器周期性地主动发送网页请求,以部分时间和地点测量的网页响应时间来反映整体的网页响应时间状况。该方法的缺点是主动测量的流量并不能很好地代表真实网络流量,这种粗粒度的时间和空间上的网页响应时间采样会使得测量结果有一定偏差。
(2)客户端被动测量方法。被动测量方法不需要监控设备主动发送网页请求,而是通过捕获经过测量点的网络数据包或监听特定事件来完成测量过程。客户端被动测量方法可以对被测量网站内的所有网页配置客户端执行脚本,在客户端浏览器下载了该网站的网页之后,任何后续的点击链接产生的站内网页都会通过客户端脚本进行被动测量,并且自动将网页响应时间的测量结果通信给测量服务器。这种方法的缺点是测量限制太多,并且无法将网页响应时间分解为网络部分和服务器部分。另一种方法是对客户端浏览器进行配置。然而使用这种方法进行大规模测量时,配置太过复杂,缺乏扩展性。
(3)服务器端被动测量方法。最初的服务器端被动测量方法通过跟踪HTTP请求到达和应答完成,进行应用级或内核级的测量。不过这种方法忽视了TCP连接建立带来的延迟,导致测量结果不准确。后来ksniffer提出了一套较为完整的网页响应时间的服务器端被动测量体系,比起应用级或内核级的测量有了很大改进。只不过ksniffer在测量过程中将所有的HTML类型文件的HTTP请求都作为了网页首个请求,这种方法在当今网页构成十分复杂的情况下是无法准确测量网页响应时间的。除此之外,所有的服务器端被动测量方法都无法测量需要从多个服务器获取内容的网页的响应时间,也无法测量客户端附近的活动,如DNS请求与应答。
(4)离线测量方法。离线测量是通过将捕获的网络数据包或数据包主要信息记录到磁盘上,然后对这些数据包和信息进行扫描分析,以此来重构先前的网页响应时间。比起以上几种实时测量方法,离线测量的方法即便能够进行更全面地测量,也由于其实时性差难以满足现实要求。
总之,当前存在的网络响应时间测量方法都存在着一定的缺陷,难以完成对当今复杂度更高的网页进行准确、实时、全面地测量。
发明内容
本发明的发明目的在于提供一种测量方法及***,能对当前构成复杂的网页的响应时间进行准确、实时、全面、简单、高效率地测量。
为实现上述目的,本发明提供一种基于网络中间点的网页响应时间被动测量方法,该方法包括:
步骤1,数据包获取:数据包获取模块通过网卡或板卡在网络中间点实时捕获所有用户与网页交互的网络数据包,并将所述网络数据包发送给数据包分用模块;
步骤2,数据包分用:数据包分用模块根据所述网络数据包的链路层、网络层和传输层协议对其进行分用处理;
步骤3,数据包解析:数据包解析模块解析所述网络数据包并提取其IP、TCP和HTTP头部信息,根据所述IP、TCP和HTTP头部信息标记网络数据包类型;
步骤4,响应时间测量:响应时间测量模块对不同类型的网络数据包进行相应处理,测量所有网页的响应时间。
进一步的,所述步骤2包括:
步骤21,将端口号为53的UDP数据包交给DNS处理模块,测量所有DNS查询的响应时间,将端口号为80或8080的TCP数据包交给TCP处理模块,维护用户与网页交互过程建立的所有TCP连接的flow信息。
进一步的,所述步骤21包括:
步骤211,如果UDP数据包是DNS查询包,则DNS处理模块为该次查询新建dns-record结构,记录查询开始时间信息并将其***hash表;
如果UDP数据包是DNS应答包,则DNS处理模块从所述hash表查找匹配的dns-record结构,记录应答结束时间。
所述步骤21还包括:
步骤221,如果TCP数据包是SYN包,则TCP处理模块创建一个flow结构,记录连接建立开始时间后并将其***流表;
如果TCP数据包是其它数据包,则TCP处理模块查找流表确定该数据包所在连接的flow结构,并更新流表的相关信息。
进一步的,所述步骤4中:
响应时间测量模块查找所述网络数据包所属的http-pair,根据所述http-pair的Referer、请求文件类型和超时机制判断记录网页请求开始时间和网页响应结束时间。
为实现上述目的,本发明还提供一种基于网络中间点的网页响应时间被动测量***,该***包括:
数据包获取模块,用于通过网卡或板卡在网络中间点实时捕获所有用户与网页交互的网络数据包,并将所述网络数据包发送给数据包分用模块;
数据包分用模块,用于根据所述网络数据包的链路层、网络层和传输层协议对其进行分用处理;
数据包解析模块,用于解析所述网络数据包并提取其IP、TCP和HTTP头部信息,根据所述IP、TCP和HTTP头部信息标记网络数据包类型;
响应时间测量模块,用于对不同类型的网络数据包进行相应处理,测量所有网页的响应时间。
进一步的,所述数据包分用模块包括:
分用处理模块,将端口号为53的UDP数据包交给DNS处理模块,测量所有DNS查询的响应时间,将端口号为80或8080的TCP数据包交给TCP处理模块,维护用户与网页交互过程建立的所有TCP连接的flow信息。
进一步的,所述分用处理模块包括:
DNS处理模块,如果UDP数据包是DNS查询包,则DNS处理模块为该次查询新建dns-record结构,记录查询开始时间信息并将其***hash表;
如果UDP数据包是DNS应答包,则DNS处理模块从所述hash表查找匹配的dns-record结构,记录应答结束时间。
所述分用处理模块还包括:
TCP处理模块,如果TCP数据包是SYN包,则TCP处理模块创建一个flow结构,记录连接建立开始时间后并将其***流表;
如果TCP数据包是其它数据包,则TCP处理模块查找流表确定该数据包所在连接的flow结构,并更新流表的相关信息。
进一步的,所述响应时间测量模块中:
响应时间测量模块查找所述网络数据包所属的http-pair,根据所述http-pair的Referer、请求文件类型和超时机制判断记录网页请求开始时间和网页响应结束时间。
本发明的有益功效在于,
(1)准确性。基于提出的新型的网页首个HTTP请求的识别方法,我们不仅可以准确测量简单网页的响应时间,还可以对当今较为复杂的网页的响应时间进行准确地测量。
(2)实时性。我们采用的是在线的被动测量方法,每一次网页响应结束后便可将用户感知的网页响应时间现状反馈给业务提供商,实时性较好。
(3)全面性。首先我们对每一个用户的每次网页访问都进行测量,不存在采样导致的测量结果的有偏性。其次我们可以对网页包含的每个对象的请求应答过程进行测量,以便在出现性能问题时进行全面而深入的分析。最后我们还能够测量DNS响应时间。
(4)简单性。我们的测量方法无需对网页、浏览器或服务器进行任何修改,配置简单。
(5)效率高。在进行网页响应时间的测量过程中,我们只检查TCP/IP和HTTP的头部信息,不分析HTTP载荷数据,速度更快。只需访问一次数据包,提取头部信息处理后便可将其丢弃,节省了大量保存数据包所需的空间。
总之本发明中提出的方法可以有效克服现有网页响应时间测量方法的缺陷,能够对当前构成复杂的网页的响应时间进行准确、实时、全面、简单、高效率地测量。
以下结合附图和具体实施例对本发明进行详细描述,但不作为对本发明的限定。
附图说明
图1是本发明的基于网络中间点的网页响应时间被动测量方法流程图;
图2是本发明的基于网络中间点的网页响应时间被动测量***示意图;
图3是本发明的一实施例的网页响应时间的测量流程图。
具体实施方式
图1是本发明的基于网络中间点的网页响应时间被动测量方法流程图。如图1所示,该方法包括:
步骤1,数据包获取:数据包获取模块通过网卡或板卡在网络中间点实时捕获所有用户与网页交互的网络数据包,并将所述网络数据包发送给数据包分用模块;
步骤2,数据包分用:数据包分用模块根据所述网络数据包的链路层、网络层和传输层协议对其进行分用处理;
步骤3,数据包解析:数据包解析模块解析所述网络数据包并提取其IP、TCP和HTTP头部信息,根据所述IP、TCP和HTTP头部信息标记网络数据包类型;
步骤4,响应时间测量:响应时间测量模块对不同类型的网络数据包进行相应处理,测量所有网页的响应时间。
进一步的,所述步骤2包括:
步骤21,将端口号为53的UDP数据包交给DNS处理模块,测量所有DNS查询的响应时间,将端口号为80或8080的TCP数据包交给TCP处理模块,维护用户与网页交互过程建立的所有TCP连接的flow信息。
进一步的,所述步骤21包括:
步骤211,如果UDP数据包是DNS查询包,则DNS处理模块为该次查询新建dns-record结构,记录查询开始时间信息并将其***hash表;
如果UDP数据包是DNS应答包,则DNS处理模块从所述hash表查找匹配的dns-record结构,记录应答结束时间。
所述步骤21还包括:
步骤221,如果TCP数据包是SYN包,则TCP处理模块创建一个flow结构,记录连接建立开始时间后并将其***流表;
如果TCP数据包是其它数据包,则TCP处理模块查找流表确定该数据包所在连接的flow结构,并更新流表的相关信息。
进一步的,所述步骤4中:
响应时间测量模块查找所述网络数据包所属的http-pair,根据所述http-pair的Referer、请求文件类型和超时机制判断记录网页请求开始时间和网页响应结束时间。
为了完成网页响应时间的测量,我们使用了几种辅助结构。对于每个用户产生的每次网页请求,我们使用pageview结构来记录网页开始时间,并且通过跟踪其请求应答过程确定网页响应结束时间。类似地,我们使用http-pair结构来跟踪某次HTTP请求应答过程,使用flow结构来跟踪某个TCP连接的建立和传输过程,使用dns-record结构来跟踪某次DNS查询应答过程,使用refer-record结构来记录http-pair和pageview的URL关联。为了实现快速查找,以上所有的结构都分别以hash形式维护在内存中,定期进行扫描老化。其中pageview的hash表根据URL进行hash,http-pair的hash表根据四元组(源IP、目的IP、源端口、目的端口)hash,flow的hash表(简称为流表)同样根据四元组hash,dns-record的hash表根据域名hash,refer-record的hash表(简称为关联记录hash表)根据http-pair中的请求URL进行hash。
基于上述结构,我们便可以展开网页响应时间的测量过程。前面提到的各步骤的具体说明如下:
(1)数据包获取:如果测量点在速度不是很快的链路上,该步骤可以使用Libpcap库通过网卡进行抓包。如果测量点所在的链路速度较快,则该步骤应该使用抓包效率更高的板卡实时捕获网络数据包。无论是采用网卡还是板卡,都将捕获的数据包交给数据包分用模块继续处理。
(2)数据包分用:根据数据包的链路层、网络层和传输层协议依次进行分用。为了完成网页响应时间的测量,我们只需要过滤出端口号为53(DNS)的UDP数据包以及端口号为80和8080(HTTP)的TCP数据包,分别交给DNS处理模块和TCP处理模块继续处理。
(3)DNS处理:测量所有用户产生的所有DNS查询的响应时间。如果到来的数据包是DNS查询包,就为该次查询新建dns-record结构,记录查询开始时间等信息后***hash表。如果到来的数据包是DNS应答包,就去hash表查找匹配的dns-record结构,记录应答结束时间。这样DNS响应时间测量结果就存储在dns-record结构的hash表中,在响应时间测量模块需要时将其传送出去或通过hash表扫描老化。
(4)TCP处理:维护网页请求与响应过程中建立的若干TCP连接的flow信息。如果到来的数据包是SYN包,则创建一个新的flow结构,记录连接建立开始时间后***流表。如果到来的数据包是其它数据包,则查找流表确定该数据包所在连接的flow结构,更新相关信息。流表中记录了TCP连接建立信息以及后续的数据传输信息,我们将数据包和其所在连接的这些flow信息都传给数据包解析模块进行后续处理。
(5)数据包解析:主要任务是解析并提取数据包的IP、TCP和HTTP头部信息,根据提取的信息标记数据包类型。在所有类型的数据包中,我们将HTTP请求首个数据包、后续数据包,HTTP应答首个数据包、后续数据包的提取信息和flow信息一并交给响应时间测量模块继续处理。
(6)响应时间测量:该步骤是网页响应时间测量的核心,将测量所有用户产生的所有网页的响应时间。基于数据包解析模块提取的数据包头部信息,数据包所在连接的flow信息以及标记的数据包类型,该步骤对网页响应时间的测量流程的一个实施例如图3所示,图3是本发明的一实施例的网页响应时间的测量流程图:
(a)若提取的信息来自HTTP请求首个数据包,则为该请求创建一个新的http-pair,初始化并记录提取的信息,然后***到http-pair的hash表中。如果提取的信息中有Host和Uri(在少数情况下Host不在请求首个数据包中,而出现在后续数据包中,这种情况下在Host出现的后续数据包到来时,延迟进行下述处理),使用它们与请求的Referer、时间戳等信息,结合超时机制初步判断该HTTP请求是否为网页首个HTTP请求。如果判定为是,则将该http-pair标记为网页首个HTTP请求的候选,待请求的应答到来后根据Content-Type标示的请求文件类型做进一步判断;如果判定为否,则认定该请求为网页后续HTTP请求,将请求的http-pair关联到所在的pageview(关于网页首个HTTP请求的判断问题与后续HTTP请求的关联问题后面会有更详细的说明)。最后根据flow信息判断该请求是否为所在连接的首个HTTP请求,如果为是则根据Host等信息向DNS处理模块获取该请求所在连接建立之前的DNS查询响应时间。
(b)若提取的信息来自HTTP请求后续数据包,则使用提取信息中的四元组从http-pair的hash表找到该数据包所属的http-pair,并使用提取信息更新http-pair的相关信息。如果该http-pair已经关联到了所在的pageview,则还需要更新pageview的信息。
(c)若提取的信息来自HTTP应答首个数据包,则首先使用提取信息中的四元组查找该应答包所属的http-pair并更新相关信息。然后根据该http-pair是否已经标记为网页首个HTTP请求的候选做以下不同的处理:
如果不是候选,则该http-pair属于网页后续HTTP请求,且已经关联到了所在的pageview,我们只需更新pageview的相关信息,主要是将网页响应结束时间更新为该应答的时间。如果标记为候选,则进一步根据应答的Content-Type标示的请求文件类型判断该http-pair是否为网页首个HTTP请求。如果为HTML类型,则认定该http-pair为网页首个HTTP请求,为该http-pair创建一个新的pageview,初始化相关信息,主要是将http-pair的开始时间记录到pageview的网页请求开始时间,然后将该http-pair和pageview相互关联。如果是其它类型,则认定该http-pair属于网页后续HTTP请求,重新将其关联到所在的pageview。
(d)若提取的信息来自HTTP应答后续数据包,则同样使用提取信息中的四元组查找该应答包所属的http-pair并更新相关信息。此时该http-pair应该已经关联到了所在的pageview,我们需要更新pageview的信息,将网页响应结束时间更新为该应答的时间。
在网页响应结束之后,pageview的hash表中就存放了该网页的响应时间。我们定期扫描hash表,认为30s内没有数据包到达更新的pageview所代表的网页请求的响应已经结束,老化导出其网页响应时间,这样便完成了整个网页响应时间的测量流程。
在上述网页响应时间的测量流程中,有以下两点需要重点说明:
(1)首先一个是网页首个HTTP请求的判断问题。网页首个HTTP请求不仅决定了网页请求的开始时间,还关系着后续HTTP请求应答的关联是否准确完整,因此也间接影响着网页响应的结束时间。可以说网页首个HTTP请求的识别是否准确直接影响着网页响应时间的测量是否准确。由于当今的网页日益复杂,以前的方法都不再适用,我们提出了一种结合Referer、超时机制以及请求文件类型等信息的识别方法。具体做法如下:
如果HTTP请求的Referer为空,则很有可能为用户在浏览器输入URL产生的网页首个HTTP请求,将其标记为网页首个HTTP请求的候选。如果HTTP请求的Referer存在,则使用Referer去关联记录hash表查找该请求引用的请求所在的pageview的URL,进而到pageview的hash表中查找对应的pageview。如果找到并且该HTTP请求与pageview的前一个HTTP请求的时间差小于某一阈值(此处即应用超时机制),则认定该请求为网页后续HTTP请求,将其与该pageview关联。否则该请求有可能为用户点击链接产生的网页首个HTTP请求,将其标记为网页首个HTTP请求的候选。待请求的应答到来后,对于所有标记为候选的请求判断其应答的Content-Type标示的请求文件类型是否为HTML类型,如果为是则判定该请求为网页首个HTTP请求,否则判定该请求为网页后续HTTP请求,并重新将该请求与所在的pageview关联。
(2)另外一个问题是网页后续HTTP请求关联到所在的网页,只有将所有的网页后续HTTP请求及其应答都完整地关联到所在的网页,才能准确确定网页响应的结束时间,从而保证网页响应时间测量的准确性。为了保证测量的效率,我们使用请求的Referer信息来作为关联的依据,将后续HTTP请求关联到Referer中引用的请求所在的网页中。由于http-pair的hash表使用四元组进行hash,为了找到请求的Referer引用的请求,必须遍历整个hash表进行查找,速度较慢。为了提高查找的速度,我们采用了空间换取时间的方法,额外维护了一个前面已经提到过的关联记录hash表,其中每个关联记录保存了HTTP请求的URL以及请求所在的网页的URL等。***关联记录时根据请求URL进行hash,这样在查找时使用Referer进行hash便可以快速找到Referer引用的请求,进而根据其关联记录中的网页URL快速找到其所在的pageview,完成后续HTTP请求的关联。
在维护关联记录hash表时,我们还使用了两个技巧,可以进一步提高查找和关联的效率。首先,我们不必将所有HTTP请求的URL和所在网页的URL都添加到关联记录中,因为有些文件类型的HTTP请求是不可能被后续HTTP请求的Referer引用到的,比如Content-Type为image/xxx的图片请求等。这样我们只需维护那些可能被后续HTTP请求引用的文件类型的请求,从而大大减少所需维护的关联记录以及hash表的规模。经过实验发现,只有Content-Type为text/xxx和application/xxx的HTTP请求才可能被后续HTTP请求引用到。其次,我们在实验中发现网页的首个HTTP请求会在整个网页请求的过程中频繁被后续HTTP请求引用到,这样在使用链表解决hash冲突时,可以将网页首个HTTP请求的关联记录优先放在链表头部,从而达到更快的查找速度。
图2是本发明的基于网络中间点的网页响应时间被动测量***示意图。如图2所示,该***包括:
数据包获取模块100,用于通过网卡或板卡在网络中间点实时捕获所有用户与网页交互的网络数据包,并将所述网络数据包发送给数据包分用模块;
数据包分用模块200,用于根据所述网络数据包的链路层、网络层和传输层协议对其进行分用处理;
数据包解析模块300,用于解析所述网络数据包并提取其IP、TCP和HTTP头部信息,根据所述IP、TCP和HTTP头部信息标记网络数据包类型;
响应时间测量模块400,用于对不同类型的网络数据包进行相应处理,测量所有网页的响应时间。
进一步的,所述数据包分用模块200包括:
分用处理模块210,将端口号为53的UDP数据包交给DNS处理模块,测量所有DNS查询的响应时间,将端口号为80或8080的TCP数据包交给TCP处理模块,维护用户与网页交互过程建立的所有TCP连接的flow信息。
进一步的,所述分用处理模块210包括:
DNS处理模块2110,如果UDP数据包是DNS查询包,则DNS处理模块为该次查询新建dns-record结构,记录查询开始时间信息并将其***hash表;
如果UDP数据包是DNS应答包,则DNS处理模块从所述hash表查找匹配的dns-record结构,记录应答结束时间。
所述分用处理模块210还包括:
TCP处理模块2210,如果TCP数据包是SYN包,则TCP处理模块创建一个flow结构,记录连接建立开始时间后并将其***流表;
如果TCP数据包是其它数据包,则TCP处理模块查找流表确定该数据包所在连接的flow结构,并更新流表的相关信息。
进一步的,所述响应时间测量模块400中:
响应时间测量模块查找所述网络数据包所属的http-pair,根据所述http-pair的Referer、请求文件类型和超时机制判断记录网页请求开始时间和网页响应结束时间。
为了完成网页响应时间的测量,我们使用了几种辅助结构。对于每个用户产生的每次网页请求,我们使用pageview结构来记录网页开始时间,并且通过跟踪其请求应答过程确定网页响应结束时间。类似地,我们使用http-pair结构来跟踪某次HTTP请求应答过程,使用flow结构来跟踪某个TCP连接的建立和传输过程,使用dns-record结构来跟踪某次DNS查询应答过程,使用refer-record结构来记录http-pair和pageview的URL关联。为了实现快速查找,以上所有的结构都分别以hash形式维护在内存中,定期进行扫描老化。其中pageview的hash表根据URL进行hash,http-pair的hash表根据四元组(源IP、目的IP、源端口、目的端口)hash,flow的hash表(简称为流表)同样根据四元组hash,dns-record的hash表根据域名hash,refer-record的hash表(简称为关联记录hash表)根据http-pair中的请求URL进行hash。
基于上述结构,我们便可以展开网页响应时间的测量过程。说明如下:
(1)数据包获取模块:如果测量点在速度不是很快的链路上,该模块可以使用Libpcap库通过网卡进行抓包。如果测量点所在的链路速度较快,则该模块应该使用抓包效率更高的板卡实时捕获网络数据包。无论是采用网卡还是板卡,都将捕获的数据包交给数据包分用模块继续处理。
(2)数据包分用模块:该模块根据数据包的链路层、网络层和传输层协议依次进行分用。为了完成网页响应时间的测量,我们只需要过滤出端口号为53(DNS)的UDP数据包以及端口号为80和8080(HTTP)的TCP数据包,分别交给DNS处理模块和TCP处理模块继续处理。
(3)DNS处理模块:该模块测量所有用户产生的所有DNS查询的响应时间。如果到来的数据包是DNS查询包,就为该次查询新建dns-record结构,记录查询开始时间等信息后***hash表。如果到来的数据包是DNS应答包,就去hash表查找匹配的dns-record结构,记录应答结束时间。这样DNS响应时间测量结果就存储在dns-record结构的hash表中,在响应时间测量模块需要时将其传送出去或通过hash表扫描老化。
(4)TCP处理模块:该模块维护网页请求与响应过程中建立的若干TCP连接的flow信息。如果到来的数据包是SYN包,则创建一个新的flow结构,记录连接建立开始时间后***流表。如果到来的数据包是其它数据包,则查找流表确定该数据包所在连接的flow结构,更新相关信息。流表中记录了TCP连接建立信息以及后续的数据传输信息,我们将数据包和其所在连接的这些flow信息都传给数据包解析模块进行后续处理。
(5)数据包解析模块:该模块的主要任务是解析并提取数据包的IP、TCP和HTTP头部信息,根据提取的信息标记数据包类型。在所有类型的数据包中,我们将HTTP请求首个数据包、后续数据包,HTTP应答首个数据包、后续数据包的提取信息和flow信息一并交给响应时间测量模块继续处理。
(6)响应时间测量模块:该模块是网页响应时间测量的核心模块,将测量所有用户产生的所有网页的响应时间。基于数据包解析模块提取的数据包头部信息,数据包所在连接的flow信息以及标记的数据包类型,该模块对网页响应时间的测量流程的一个实施例的一个实施例如图3所示,图3是本发明的一实施例的网页响应时间的测量流程图::
(a)若提取的信息来自HTTP请求首个数据包,则为该请求创建一个新的http-pair,初始化并记录提取的信息,然后***到http-pair的hash表中。如果提取的信息中有Host和Uri(在少数情况下Host不在请求首个数据包中,而出现在后续数据包中,这种情况下在Host出现的后续数据包到来时,延迟进行下述处理),使用它们与请求的Referer、时间戳等信息,结合超时机制初步判断该HTTP请求是否为网页首个HTTP请求。如果判定为是,则将该http-pair标记为网页首个HTTP请求的候选,待请求的应答到来后根据Content-Type标示的请求文件类型做进一步判断;如果判定为否,则认定该请求为网页后续HTTP请求,将请求的http-pair关联到所在的pageview(关于网页首个HTTP请求的判断问题与后续HTTP请求的关联问题后面会有更详细的说明)。最后根据flow信息判断该请求是否为所在连接的首个HTTP请求,如果为是则根据Host等信息向DNS处理模块获取该请求所在连接建立之前的DNS查询响应时间。
(b)若提取的信息来自HTTP请求后续数据包,则使用提取信息中的四元组从http-pair的hash表找到该数据包所属的http-pair,并使用提取信息更新http-pair的相关信息。如果该http-pair已经关联到了所在的pageview,则还需要更新pageview的信息。
(c)若提取的信息来自HTTP应答首个数据包,则首先使用提取信息中的四元组查找该应答包所属的http-pair并更新相关信息。然后根据该http-pair是否已经标记为网页首个HTTP请求的候选做以下不同的处理:
如果不是候选,则该http-pair属于网页后续HTTP请求,且已经关联到了所在的pageview,我们只需更新pageview的相关信息,主要是将网页响应结束时间更新为该应答的时间。如果标记为候选,则进一步根据应答的Content-Type标示的请求文件类型判断该http-pair是否为网页首个HTTP请求。如果为HTML类型,则认定该http-pair为网页首个HTTP请求,为该http-pair创建一个新的pageview,初始化相关信息,主要是将http-pair的开始时间记录到pageview的网页请求开始时间,然后将该http-pair和pageview相互关联。如果是其它类型,则认定该http-pair属于网页后续HTTP请求,重新将其关联到所在的pageview。
(d)若提取的信息来自HTTP应答后续数据包,则同样使用提取信息中的四元组查找该应答包所属的http-pair并更新相关信息。此时该http-pair应该已经关联到了所在的pageview,我们需要更新pageview的信息,将网页响应结束时间更新为该应答的时间。
在网页响应结束之后,pageview的hash表中就存放了该网页的响应时间。我们定期扫描hash表,认为30s内没有数据包到达更新的pageview所代表的网页请求的响应已经结束,老化导出其网页响应时间,这样便完成了整个网页响应时间的测量流程。
在上述网页响应时间的测量流程中,有以下两点需要重点说明:
(1)首先一个是网页首个HTTP请求的判断问题。网页首个HTTP请求不仅决定了网页请求的开始时间,还关系着后续HTTP请求应答的关联是否准确完整,因此也间接影响着网页响应的结束时间。可以说网页首个HTTP请求的识别是否准确直接影响着网页响应时间的测量是否准确。由于当今的网页日益复杂,以前的方法都不再适用,我们提出了一种结合Referer、超时机制以及请求文件类型等信息的识别方法。具体做法如下:
如果HTTP请求的Referer为空,则很有可能为用户在浏览器输入URL产生的网页首个HTTP请求,将其标记为网页首个HTTP请求的候选。如果HTTP请求的Referer存在,则使用Referer去关联记录hash表查找该请求引用的请求所在的pageview的URL,进而到pageview的hash表中查找对应的pageview。如果找到并且该HTTP请求与pageview的前一个HTTP请求的时间差小于某一阈值(此处即应用超时机制),则认定该请求为网页后续HTTP请求,将其与该pageview关联。否则该请求有可能为用户点击链接产生的网页首个HTTP请求,将其标记为网页首个HTTP请求的候选。待请求的应答到来后,对于所有标记为候选的请求判断其应答的Content-Type标示的请求文件类型是否为HTML类型,如果为是则判定该请求为网页首个HTTP请求,否则判定该请求为网页后续HTTP请求,并重新将该请求与所在的pageview关联。
(2)另外一个问题是网页后续HTTP请求关联到所在的网页,只有将所有的网页后续HTTP请求及其应答都完整地关联到所在的网页,才能准确确定网页响应的结束时间,从而保证网页响应时间测量的准确性。为了保证测量的效率,我们使用请求的Referer信息来作为关联的依据,将后续HTTP请求关联到Referer中引用的请求所在的网页中。由于http-pair的hash表使用四元组进行hash,为了找到请求的Referer引用的请求,必须遍历整个hash表进行查找,速度较慢。为了提高查找的速度,我们采用了空间换取时间的方法,额外维护了一个前面已经提到过的关联记录hash表,其中每个关联记录保存了HTTP请求的URL以及请求所在的网页的URL等。***关联记录时根据请求URL进行hash,这样在查找时使用Referer进行hash便可以快速找到Referer引用的请求,进而根据其关联记录中的网页URL快速找到其所在的pageview,完成后续HTTP请求的关联。
在维护关联记录hash表时,我们还使用了两个技巧,可以进一步提高查找和关联的效率。首先,我们不必将所有HTTP请求的URL和所在网页的URL都添加到关联记录中,因为有些文件类型的HTTP请求是不可能被后续HTTP请求的Referer引用到的,比如Content-Type为image/xxx的图片请求等。这样我们只需维护那些可能被后续HTTP请求引用的文件类型的请求,从而大大减少所需维护的关联记录以及hash表的规模。经过实验发现,只有Content-Type为text/xxx和application/xxx的HTTP请求才可能被后续HTTP请求引用到。其次,我们在实验中发现网页的首个HTTP请求会在整个网页请求的过程中频繁被后续HTTP请求引用到,这样在使用链表解决hash冲突时,可以将网页首个HTTP请求的关联记录优先放在链表头部,从而达到更快的查找速度。
当然,本发明还可有其它多种实施例,在不背离本发明精神及其实质的情况下,熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形,但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。

Claims (4)

1.一种基于网络中间点的网页响应时间被动测量方法,其特征在于,包括:
步骤1,数据包获取:数据包获取模块通过网卡或板卡在网络中间点实时捕获所有用户与网页交互的网络数据包,并将所述网络数据包发送给数据包分用模块;
步骤2,数据包分用:数据包分用模块根据所述网络数据包的链路层、网络层和传输层协议对其进行分用处理,其中所述步骤2包括步骤21,数据包分用模块将端口号为53的UDP数据包交给DNS处理模块测量所有DNS查询的响应时间,将端口号为80或8080的TCP数据包交给TCP处理模块,维护用户与网页交互过程建立的所有TCP连接的flow信息,所述步骤21包括步骤211,如果UDP数据包是DNS查询包,则DNS处理模块为该次查询新建dns-record结构,记录查询开始时间信息并将其***hash表,如果UDP数据包是DNS应答包,则DNS处理模块从所述hash表查找匹配的dns-record结构,记录应答结束时间;步骤221,如果TCP数据包是SYN包,则TCP处理模块创建一个flow结构,记录连接建立开始时间后并将其***流表,如果TCP数据包是其它数据包,则TCP处理模块查找流表确定该数据包所在连接的flow结构,并更新流表的相关信息;
步骤3,数据包解析:数据包解析模块解析并提取数据包的IP、TCP和HTTP头部信息,根据提取的信息标记数据包类型,在所有类型的数据包中,将HTTP请求首个数据包、后续数据包,HTTP应答首个数据包、后续数据包的提取信息和flow信息一并交给响应时间测量模块继续处理;
步骤4,响应时间测量:所述响应时间测量模块对不同类型的网络数据包进行相应处理,测量所有网页的响应时间,其中所述步骤4包括若提取的信息来自HTTP请求首个数据包,则为该请求创建一个新的http-pair,初始化并记录提取的信息,然后***到http-pair的hash表中;若提取的信息来自HTTP请求后续数据包,则使用提取信息中的四元组从http-pair的hash表找到该数据包所属的http-pair,并使用提取信息更新http-pair的相关信息;若提取的信息来自HTTP应答首个数据包,则首先使用提取信息中的四元组查找该应答包所属的http-pair并更新相关信息;若提取的信息来自HTTP应答后续数据包,则同样使用提取信息中的四元组查找该应答包所属的http-pair并更新相关信息。
2.如权利要求1所述的网页响应时间被动测量方法,其特征在于,所述步骤4中:
响应时间测量模块查找所述网络数据包所属的http-pair,根据所述http-pair的Referer、请求文件类型和超时机制判断记录网页请求开始时间和网页响应结束时间。
3.一种基于网络中间点的网页响应时间被动测量***,其特征在于,包括:
数据包获取模块,用于通过网卡或板卡在网络中间点实时捕获所有用户与网页交互的网络数据包,并将所述网络数据包发送给数据包分用模块;
数据包分用模块,用于根据所述网络数据包的链路层、网络层和传输层协议对其进行分用处理,获得所述网络数据包的flow信息,所述数据包分用模块包括分用处理模块,将端口号为53的UDP数据包交给DNS处理模块测量所有DNS查询的响应时间,将端口号为80或8080的TCP数据包交给TCP处理模块,维护用户与网页交互过程建立的所有TCP连接的flow信息,所述分用处理模块包括DNS处理模块,如果UDP数据包是DNS查询包,则DNS处理模块为该次查询新建dns-record结构,记录查询开始时间信息并将其***hash表,如果UDP数据包是DNS应答包,则DNS处理模块从所述hash表查找匹配的dns-record结构,记录应答结束时间;TCP处理模块,如果TCP数据包是SYN包,则TCP处理模块创建一个flow结构,记录连接建立开始时间后并将其***流表,如果TCP数据包是其它数据包,则TCP处理模块查找流表确定该数据包所在连接的flow结构,并更新流表的相关信息;
数据包解析模块,用于解析并提取数据包的IP、TCP和HTTP头部信息,根据提取的信息标记数据包类型,在所有类型的数据包中,将HTTP请求首个数据包、后续数据包,HTTP应答首个数据包、后续数据包的提取信息和flow信息一并交给响应时间测量模块继续处理;
所述响应时间测量模块,用于对不同类型的网络数据包进行相应处理,测量所有网页的响应时间,其中所述响应时间测量模块包括若提取的信息来自HTTP请求首个数据包,则为该请求创建一个新的http-pair,初始化并记录提取的信息,然后***到http-pair的hash表中;若提取的信息来自HTTP请求后续数据包,则使用提取信息中的四元组从http-pair的hash表找到该数据包所属的http-pair,并使用提取信息更新http-pair的相关信息;若提取的信息来自HTTP应答首个数据包,则首先使用提取信息中的四元组查找该应答包所属的http-pair并更新相关信息;若提取的信息来自HTTP应答后续数据包,则同样使用提取信息中的四元组查找该应答包所属的http-pair并更新相关信息。
4.如权利要求3所述的网页响应时间被动测量***,其特征在于,所述响应时间测量模块中:
响应时间测量模块查找所述网络数据包所属的http-pair,根据所述http-pair的Referer、请求文件类型和超时机制判断记录网页请求开始时间和网页响应结束时间。
CN201210563218.9A 2012-12-21 2012-12-21 基于网络中间点的网页响应时间被动测量方法及*** Active CN103036746B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201210563218.9A CN103036746B (zh) 2012-12-21 2012-12-21 基于网络中间点的网页响应时间被动测量方法及***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201210563218.9A CN103036746B (zh) 2012-12-21 2012-12-21 基于网络中间点的网页响应时间被动测量方法及***

Publications (2)

Publication Number Publication Date
CN103036746A CN103036746A (zh) 2013-04-10
CN103036746B true CN103036746B (zh) 2015-07-08

Family

ID=48023256

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201210563218.9A Active CN103036746B (zh) 2012-12-21 2012-12-21 基于网络中间点的网页响应时间被动测量方法及***

Country Status (1)

Country Link
CN (1) CN103036746B (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103729458B (zh) * 2014-01-10 2017-01-11 湖南神州祥网科技有限公司 一种网页请求的区分方法及装置
CN103714182A (zh) * 2014-01-10 2014-04-09 湖南神州祥网科技有限公司 一种网页请求的关联方法及装置
CN105451260B (zh) * 2014-08-12 2019-12-20 优视科技有限公司 网络请求方法、网络波动性衡量方法及装置
CN106937322B (zh) * 2015-12-29 2020-11-06 阿里巴巴(中国)有限公司 流量消耗监测方法及装置
CN107181701B (zh) * 2017-05-18 2018-07-20 腾讯科技(深圳)有限公司 公共网关接口数据的收集方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1561036A (zh) * 2004-02-24 2005-01-05 华中科技大学 基于tpc-w基准的网站服务器性能测试***
CN101267361A (zh) * 2008-05-09 2008-09-17 武汉飞思科技有限公司 一种基于零拷贝技术的高速网络数据包捕获方法
CN102790700A (zh) * 2011-05-19 2012-11-21 北京启明星辰信息技术股份有限公司 一种识别网页爬虫的方法和装置

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9276903B2 (en) * 2007-01-11 2016-03-01 Nice-Systems Ltd. Branch IP recording

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1561036A (zh) * 2004-02-24 2005-01-05 华中科技大学 基于tpc-w基准的网站服务器性能测试***
CN101267361A (zh) * 2008-05-09 2008-09-17 武汉飞思科技有限公司 一种基于零拷贝技术的高速网络数据包捕获方法
CN102790700A (zh) * 2011-05-19 2012-11-21 北京启明星辰信息技术股份有限公司 一种识别网页爬虫的方法和装置

Also Published As

Publication number Publication date
CN103036746A (zh) 2013-04-10

Similar Documents

Publication Publication Date Title
CN103036746B (zh) 基于网络中间点的网页响应时间被动测量方法及***
US9426046B2 (en) Web page download time analysis
US8180376B1 (en) Mobile analytics tracking and reporting
US20140310392A1 (en) Method and apparatus for processing composite web transactions
US9042863B2 (en) Service classification of web traffic
US20130191890A1 (en) Method and system for user identity recognition based on specific information
CN103279507B (zh) 网页爬虫操作方法和***
CN104394211A (zh) 一种基于Hadoop用户行为分析***设计与实现方法
WO2017071179A1 (zh) 基于流量分析识别用户行为对象的方法和装置
CN102752288A (zh) 网络访问行为识别方法和装置
CN102870118B (zh) 用户行为的获取方法、设备及***
CN103347092A (zh) 一种识别缓存文件的方法及装置
CN102752154A (zh) Web网站死链检测方法
CN105930502B (zh) 一种收集数据的***、客户端和方法
CN107835132B (zh) 一种流量来源跟踪的方法及装置
US20180062950A1 (en) Network traffic monitoring and classification
CN106790593B (zh) 一种页面处理方法和装置
CN107911466A (zh) 一种多层架构下应用关联方法
CN109361575A (zh) 一种获取分析dns流量数据的方法及其***
CN113656673A (zh) 面向广告投放的主从分布内容爬取机器人
CN104202418B (zh) 为内容提供商推荐商业的内容分发网络的方法和***
CN105721519B (zh) 一种网页数据采集方法、装置及***
GB2569678A (en) Automation of SQL tuning method and system using statistic SQL pattern analysis
CN109783330B (zh) 日志处理方法、显示方法和相关装置、***
Wang et al. Smart devices information extraction in home wi‐fi networks

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant