CN103023624A - 基于http应用层解析实现tcp重传分析的方法 - Google Patents

Abstract

本发明提出了一种基于HTTP应用层解析实现TCP重传分析的方法，包括如下步骤：基于HTTP浏览业务应用层协议响应包分析得到理论数据流量；根据响应包中TCP分段数据负载(payload)计算得出实际数据流量及实际传输数据包数；根据理论数据流量和实际数据流量确定数据重传比；根据实际数据流量和实际传输数据包数确定数据包数平均负载；根据理论数据流量和数据包数平均负载确定理论传输数据包数；根据实际传输数据包数和理论传输数据包数确定重传数据包数。采用这种整合机制，可有效提高合成精度、硬件资源使用更加合理，指标集中展现，有利于上层应用分析。

Description

基于HTTP应用层解析实现TCP重传分析的方法

技术领域

本发明属于通信领域，特别涉及中国移动、中国联通所属的GSM、GPRS、TD-SCDMA、WCDMA运营支撑系统、信令监测系统技术领域。

背景技术

随着移动互联网的高速发展，基于移动数据业务的用户行为分析、感知分析已成为支撑运营商市场决策的重要依据。

因HTTP浏览业务在移动互联网应用中占比最大，且结合HTTP浏览业务携带上网URL及流量信息等特点，基于HTTP浏览业务的用户行为分析、用户感知分析为现阶段主要分析指标。

下载速率与TCP重传率为HTTP浏览业务的感知分析的重要指标。目前，主流分析手段中，下载速率通常基于应用层每次HTTP业务过程数据流量与下行时延分析实现，TCP重传率分析通常基于承载层协议分析实现。以上述指导原则，支撑系统通常规划不同的合成机制、数据库分表存储、应用层分别展现。

现有的移动互联网业务数据分析流程如附图1所示，其中存在如下缺陷：

(1)应用层分别展现，使用不便。

在现有机制下，基于HTTP感知分析通常分为基于应用层实现的下载速率呈现，以及TCP重传率呈现，整体感知指标需要离线关联分析，使用不便。

(2)采用分立的合成机制，硬件开销较大，成本利用不合理。

采用分立的合成机制，对应用层、承载层分别分析，合成服务器开销翻倍，且需要规划不同的数据库表，用户身份信息、位置信息等公共信息重复存储，存储开销不合理。

(3)分析精度相对较低：

在现有机制下，TCP重传分析单元为一次TCP连接，HTTP业务分析单元为一次HTTP业务过程。根据移动互联网业务协议特点，一次TCP连接可包含多个HTTP请求，考虑移动互联网用户的移动性特点，现有机制下，TCP重传率分析精度与HTTP下载速率分析存在分析精度不匹配，且分析精度较低。

发明内容

为了解决现有移动互联网业务数据分析中上述缺陷，本发明结合HTTP业务的协议及传输特征，计划基于HTTP应用层信令解析，实现HTTP业务流量解析的同进，实现承载层TCP重传分析。采用这种整合机制，可有效提高合成精度、硬件资源使用更加合理，指标集中展现，有利于上层应用分析。

本发明提出了一种基于HTTP应用层解析实现TCP重传分析的方法，包括如下步骤：基于HTTP浏览业务应用层协议响应包分析得到理论数据流量；根据响应包中TCP分段数据负载(payload)计算得出实际数据流量及实际传输数据包数；根据理论数据流量和实际数据流量确定数据重传比；根据实际数据流量和实际传输数据包数确定数据包数平均负载；根据理论数据流量和数据包数平均负载确定理论传输数据包数；根据实际传输数据包数和理论传输数据包数确定重传数据包数。

根据本发明的一个方面，HTTP浏览业务过程中的理论数据流量，是通过提取响应消息Content-Length实体报头域定义内容来获取，即实体正文的长度，以字节方式存储的十进制数字来表示。

根据本发明的一个方面，实际数据流量是通过将所有响应消息的payload求和来获得，即HTTP响应消息中，TCP承载层之上不包含状态行、消息报头的响应正文部分字节数的总和。

根据本发明的一个方面，所述基于HTTP应用层解析实现TCP重传分析的方法结合了HTTP应用层解析，同时将应用层与承载层整合分析，得出理论数据流量、实际数据流量和实际传输数据包数。

根据本发明的一个方面，数据重传比、数据包数平均负载、理论传输数据包数、重传数据包数是通过下面的方式而确定的：

数据重传比＝1-((实际数据流量-理论数据流量)/理论数据流量)*100％；

数据包数平均负载＝实际数据流量/实际传输数据包数；

理论传输数据包数＝理论数据流量/数据包数平均负载；

重传数据包数＝实际传输数据包数-理论传输数据包数。

附图说明

下面结合附图及具体实施例对本发明再作进一步详细的说明：

附图1为现有的移动互联网业务数据分析流程。

附图2所示为根据本发明实施例的HTTP业务流量合成示意图。

附图3所示为根据本发明实施例的典型HTTP业务过程示意图。

附图4所示为根据本发明实施例的终端和服务器之间的数据交互过程示意图。

附图5所示为根据本发明实施例的状态行、消息报头、响应正文信令位置示意图。

附图6所示为根据本发明实施例的HTTP业务记录开关闭示意图。

附图7所示为根据本发明实施例的理论数据流量示意图。

附图8所示为根据本发明实施例的数据包信令提取位置示意图。

附图9所示为根据本发明实施例的数据包信令提取位置示意图。

附图10所示为根据本发明实施例的数据传输业务过程示意图。

附图11所示为根据本发明实施例的数据传输业务过程中的信令截图。

附图12所示为根据本发明实施例的数据传输业务过程中的信令截图。

附图13所示为根据本发明实施例的数据传输业务过程中的信令截图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

参照附图2所示，现有机制下，HTTP业务基于应用层合成，TCP重传分析基于传输层合成。

现有机制下，HTTP业务流量合成原则，为记录所有传输数据流量，即所有payload总和。附图3所示为典型HTTP业务过程示例，从该图可看出，现有机制下，HTTP业务流量实际已记入TCP重传流量。

现有机制下，TCP重传基于传输层协议分析，以一个TCP连接为分析单元，通过匹配数据包序号及TCP DUP ACK消息来识别重传包，这种合成机制，需要对不断变换的数据包序号做分析识别，在现阶段移动互联网数据量暴增的情况下，实际对合成服务器硬件开销极大，不适合全网推广使用。

附图4示出了终端和服务器之间的数据交互过程。从附图4可看出，第(11)包Seq＝1788与第(9)包Seq＝4688不连续，可看出，第(11)包为重传包。

接下来对合并分析可行性进行详细的描述。结合HTTP合成机制可看出，一次HTTP业务过程包括TCP重传包在内所有数据流量的分析，待解决的主要是TCP重传包识别的问题。

结合HTTP业务协议及传输特点，对TCP重传包识别思路阐述：首先，我们给出如下的术语约定：payload，即“有效载荷”，在HTTP协议中指TCP承载层之上不包含状态行、消息报头的响应正文部分。

基于应用层重传分析主要基于HTTP响应数据分析实现，以下对HTTP响应消息组成详细说明：

HTTP响应由三个部分组成，分别是：状态行、消息报头、响应正文。

1、状态行格式如下：

HTTP-Version Status-Code Reason-Phrase CRLF

其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。

2、HTTP响应消息报头由响应报头及实体报头组成，实际应用中并不一定包含所有下文中列出的字段内容：

(1)响应报头

响应报头允许服务器传递不能放在状态行中的附加响应信息，以及关于服务器的信息和对Request-URI所标识的资源进行下一步访问的信息。

常用的响应报头：

Location响应报头域用于重定向接受者到一个新的位置。Location响应报头域常用在更换域名的时候。

Server响应报头域包含了服务器用来处理请求的软件信息。与User-Agent请求报头域是相对应的。

WWW-Authenticate响应报头域必须被包含在401(未授权的)响应消息中，客户端收到401响应消息时候，并发送Authorization报头域请求服务器对其进行验证时，服务端响应报头就包含该报头域。

eg：WWW-Authenticate：Basic realm＝″Basic Auth Test！″//可以看出服务器对请求资源采用的是基本验证机制。

(2)实体报头

请求和响应消息都可以传送一个实体。一个实体由实体报头域和实体正文组成，但并不是说实体报头域和实体正文要在一起发送，可以只发送实体报头域。实体报头定义了关于实体正文(eg：有无实体正文)和请求所标识的资源的元信息。

常用的实体报头：

Content-Encoding实体报头域被用作媒体类型的修饰符，它的值指示了已经被应用到实体正文的附加内容的编码，因而要获得Content-Type报头域中所引用的媒体类型，必须采用相应的解码机制。Content-Encoding这样用于记录文档的压缩方法，eg：Content-Encoding：gzip

Content-Language实体报头域描述了资源所用的自然语言。没有设置该域则认为实体内容将提供给所有的语言阅读者。

Content-Length实体报头域用于指明实体正文的长度，以字节方式存储的十进制数字来表示。

Content-Type实体报头域用于指明发送给接收者的实体正文的媒体类型。

Last-Modified实体报头域用于指示资源的最后修改日期和时间。

Expires实体报头域给出响应过期的日期和时间。为了让代理服务器或浏览器在一段时间以后更新缓存中(再次访问曾访问过的页面时，直接从缓存中加载，缩短响应时间和降低服务器负载)的页面，我们可以使用Expires实体报头域指定页面过期的时间。

3、响应正文：响应正文即payload。

附图5示出了状态行、消息报头、响应正文信令位置示意说明：

接下来对理论数据流量算法进行详细的描述。

一次HTTP业务过程理论数据流量，可通过提取响应消息Content-Length实体报头域定义内容获取，即实体正文的长度，以字节方式存储的十进制数字来表示。

实际数据流量指所有响应消息payload总和，即HTTP响应消息中，TCP承载层之上不包含状态行、消息报头的响应正文部分字节数总和。具体信令提取位置在后面详述。

数据重传比，及重传数据包数可采用如下算法：

(1)数据重传比：

数据重传比＝1-((实际数据流量-理论数据流量)/理论数据流量)*100％

(2)重传数据包数：

数据包数平均payload＝实际数据流量/实际传输数据包数

理论传输数据包数＝理论数据流量/数据包数平均payload

重传数据包数＝带payload数据包数-理论传输数据包数

需要注意的是：由于实际传输数据携带pay1oad不一定为定长，因此重传数据包数需做取整处理。

接下来描述相应的实现方案。HTTP业务记录开关闭示意图如附图6所示。

HTTP业务记录需确保一次HTTP业务过程所有数据包合成完整，即以一次TCP连接过程为缓存单元，一次HTTP业务过程为分析单元，以HTTP请求做为HTTP业务记录开始条件，下一次HTTP请求或TCP连接拆除做为HTTP业务记录关闭条件，HTTP业务记录超时时间可设。

HTTP业务涉及流量及数据包数合成规则如下所述：

1、理论数据流量合成规则

理论数据流量即为HTTP响应包的Content-Length字段内容，如附图7所示，图中的content length字段值为5439，5439即为理论数据流量。

2、实际传输数据流量合成规则

实际数据流量指所有响应消息payload总和，即HTTP响应消息中，TCP承载层之上不包含状态行、消息报头的响应正文部分字节数总和.

接下来描述信令提取位置。

(1)第一个带payload的响应包，通常包含状态行、消息报头，需做去除，单位为：字节。信令提取位置如图8所示，图8中，1256字节即为该包实际数据流量。

(2)只包含payload的响应包提取TCP segment data内容即可，单位为：字节。信令提取位置如附图9所示，图9中，1440字节即为该包实际数据流量。

3、实际传输数据包数合成规则

统计一次HTTP业务过程中，所有响应包中带payload的数据包数。如附图10所示，第(3)包全部为HTTP响应包头数据，不记入统计值，(4)、(6)、(7)、(9)、(11)为带payload的响应数据包，因此实际传输数据包数为5。

接下来详细描述具体的指标算法。

(1)数据重传比：

数据重传比＝1-((实际数据流量-理论数据流量)/理论数据流量)*100％

(2)重传数据包数：

数据包数平均payload＝实际数据流量/实际传输数据包数；

理论传输数据包数＝理论数据流量/数据包数平均payload；

重传数据包数＝带payload数据包数-理论传输数据包数。

需要注意的是：由于实际传输数据携带payload不一定为定长，因此重传数据包数需做取整处理。

在本发明中，结合HTTP应用层解析，同时实现应用层与承载层整合分析的理念，通过应用层分析得出理论数据流量、实际数据流量、实际传输数据包数，并以此推算出数据重传比及重传数据包数。信令提取位置及指标算法如下：

理论数据流量的获取：

一次HTTP业务过程理论数据流量，可通过提取响应消息Content-Length实体报头域定义内容获取，即实体正文的长度，以字节方式存储的十进制数字来表示。

实际数据流量的获取：

实际数据流量指所有响应消息payload总和，即HTTP响应消息中，TCP承载层之上不包含状态行、消息报头的响应正文部分字节数总和。

实际传输数据包数，即一次HTTP业务过程中，所有响应包中带payload的数据包数。具体信令提取位置在前面已经有详细描述。

数据重传比，及重传数据包数的计算：

(1)数据重传比：

数据重传比＝1-((实际数据流量-理论数据流量)/理论数据流量)*100％

(2)重传数据包数：

数据包数平均payload＝实际数据流量/实际传输数据包数；

理论传输数据包数＝理论数据流量/数据包数平均payload；

重传数据包数＝带payload数据包数-理论传输数据包数。

通过理论数据流量、实际数据传输流量差得可计算得出重传数据量、数据重传比，及重传数据包数算法。

本发明实现了如下所述的内容：

(1)基于HTTP应用层解析，同时实现应用层与承载层整合分析的理念。

(2)基于HTTP浏览业务应用层协议响应包分析得到理论数据流量，再根据响应包中TCP分段数据payload计算得出实际传输数据流量及实际传输数据包数。

接下来，采用一个具体的分析示例，使出：

以附图10所示业务过程为例，对理论数据流量、实际数据流量、实际传输数据包数合成规则，以及数据重传比、重传数据包数算法做详细说明。

图10中，第(1)包为HTTP请求包，第(2)包回ACK后，第(3)包开始为响应数据包，通过信令可看出该包内容全部为数据包头，不含payload。信令截图如附图11所示。包(4)、(6)、(7)、(9)、(11)为带payload的响应包。信令截图如附图12所示。

结合第(11)包Seq＝1788与第(9)包Seq＝4688不连续，可看出，第(11)包为重传包。在响应消息中Content-Length值为：5439。信令截图如附图13所示。

结合以上分析结果：

理论数据流量＝5439；

实际数据流量＝1440+1440+1440+1119+1440＝6879；

实际传输数据包数＝5，包序号为：(4)、(6)、(7)、(9)、(11)；

数据重传比＝1-((6879-5439)/5439)*100％＝26.5％；

数据包数平均payload＝6879/5＝1376；

理论传输数据包数＝5439/1376＝3.95向上取整后为：4，即理论传输数据包数为：4；

重传数据包数＝5-4＝1。

经验证，以上分析结果，与实际情况相同。

通过采用本发明的技术方案，可以实现如下所述的技术优点：

1、同机合成，精度高

结合HTTP协议传输特点，在一台设备同时实现HTTP业务流量及TCP重传包合成分析，合成精度高。

2、同表存储，成本低

采用同机合成机制，硬件成本更趋合理。数据同表存储，对用户身份信息、位置信息回填只需一次完成，节省服务器资源。且业务记录开始时间、用户身份信息、位置信息等只存储一份，有效提升存储利用率。

3、统一展现，更便捷

由于采用统一的基础分析单元合成，并采用同表存储，使得应用层可采用相同的维度及时间粒度展现，指标更准确，使用更便捷。

本领域的技术人员应该理解，本发明的方法和装置可以采用硬件、软件、或硬件和软件相结合的方式，通过微处理器、数字信号处理器、现场可编程逻辑单元、或门阵列等各种方式实现。

综上所述，虽然本发明已以优选实施例披露如上，然而其并非用以限定本发明。本发明所属技术领域的普通技术人员，在不脱离本发明的精神和范围内，可作各种变动与修饰。因此，本发明的保护范围当视后附的权利要求所界定的范围为准。

Claims (5)

1.一种基于HTTP应用层解析实现TCP重传分析的方法，其特征在于，包括如下步骤：

基于HTTP浏览业务应用层协议响应包分析得到理论数据流量；

根据响应包中TCP分段数据负载(payload)计算得出实际数据流量及实际传输数据包数；

根据理论数据流量和实际数据流量确定数据重传比；

根据实际数据流量和实际传输数据包数确定数据包数平均负载；

根据理论数据流量和数据包数平均负载确定理论传输数据包数；

根据实际传输数据包数和理论传输数据包数确定重传数据包数。

2.如权利要求1中所述的方法，其特征在于：

HTTP浏览业务过程中的理论数据流量，是通过提取响应消息Content-Length实体报头域定义内容来获取，即实体正文的长度，以字节方式存储的十进制数字来表示。

3.如权利要求1中所述的方法，其特征在于：

实际数据流量是通过将所有响应消息的payload求和来获得，即HTTP响应消息中，TCP承载层之上不包含状态行、消息报头的响应正文部分字节数的总和。

4.如权利要求1中所述的方法，其特征在于：

所述基于HTTP应用层解析实现TCP重传分析的方法结合了HTTP应用层解析，同时将应用层与承载层整合分析，得出理论数据流量、实际数据流量和实际传输数据包数。

5.如权利要求1中所述的方法，其特征在于：

数据重传比、数据包数平均负载、理论传输数据包数、重传数据包数是通过下面的方式而确定的：

数据重传比＝1-((实际数据流量-理论数据流量)/理论数据流量)*100％；

数据包数平均负载＝实际数据流量/实际传输数据包数；

理论传输数据包数＝理论数据流量/数据包数平均负载；

重传数据包数＝实际传输数据包数-理论传输数据包数。

Images