2.3.2 与WAP模型对比
WAP业务的应用结构是有三部分组成，终端，网关，服务器。
比web多了一个作为中转译码的网关，同时，WAP终端与网关之间依靠无线网络进行通信，
由于无线网络本身的特点必然会造成与有线网络不同的特点。
表2.5 3GPP2的WAP模型与HTTP模型对比
根据对表2.5的参数比较，可以得出以下结论：
1) Web业务由于上下行链路的数据量差距很大，所以建立模型时只针对下行链路进行考虑。
而WAP业务中，下行数据经过压缩，所以数据量相对减少，所以将上行的终端请求也列入考虑范围。
2)对于对象的定义不尽相同，Web业务最初是主对象的生成过程，然后是主页面的解析时间。
这段时间里浏览器解析得到内嵌对象的数量以及网页的配置。接下来是内嵌对象的生成时间。因此，
Web业务将主对象与内嵌对象分开讨论。而以往的WAP业务研究中没有如此区分。我们在实际研究
中发现，对于WAP业务的对象，仍然有主对象与内嵌对象的区别。所以，我们建立模型时将主对象
与内嵌对象加以区分，使得模型更加具体准确。
3) 由于Web业务的主对象与内嵌对象的区别，因此引入了主页解析时间这个参数。而WAP只
讨论了对象之间的间隔，没有将主对象到第一个内嵌对象的时间专门提取出来。这也是以前模型的
一个不足之处。我们通过对现网数据的统计，发现主对象的解析时间大于内嵌对象的解析时间。
因此，我们在对WAP业务进行建模时，对主对象和内置对象的解析时间分别进行了考察
4) WAP业务流程是终端向网关发请求，网关再向服务器发请求。在这个响应时间中，
实际包括了网关对收到请求以及应答的解析时间，有线网络的传输时延,以及服务器端的响应时延。
而Web业务因为服务器的时延较小，所以没有考虑。
5) 对比二者对应参数的分布情况，也有很大的差别。这是由于有线网和无线网不同特性以及WAP
业务用户行为与Web业务差异较大引起的
2.4 构建模型的相关信息2.4.1 Wap业务通信流程介绍
由图2.3可以看出WAP业务的数据传输流程是以WAP网关为中心进行的，由该图我们可得到简化
的WAP业务数据传输流程图如下。
图2.18 WAP业务数据传输流图
在上图共有四段链路，分别用1，2，3，4 标志。这四个链路段分别是
表2.6 WAP业务各段链路分割表
这四段链路中，根据WAP协议版本的不同使用的通信协议也不同，在WAP1.2中，
1，4段使用WTP和WSP协议，2，3段使用TCP和HTTP协议；在WAP2.0中，
所有段使用的都是TCP和HTTP协议。
由于我们采集和分析的所有数据都是基于WAP1.2协议的，因此在这里我们主要针
对WAP1.2协议栈的情况进行分析。
手机终端，WAP网关以及WAP服务器三者之间的数据分组通信流程可用下图表示
图2.19 WAP业务网络通信流图
上图通信流流程可按照以下四个步骤描述如下：
a) 终端将用户请求URL封装成WSP请求报文发送对应网关；
b) 网关接收到该请求后，与请求报文中包含URL所指向服务器建立TCP连接，
然后再将接收到的终端请求报文按照HTTP协议转发到该服务器，同时，
网关在接收到由服务器返回的请求报文被接收的确认报文后向终端
发送终端请求已经被成功发送的确认报文；
c) 服务器接收到请求报文后将请求对象封装成HTTP数据报文发往网关；
d)网关接收到服务器响应报文后，对接收数据采用对应协议转换后发送到终端，
收到终端的确认后与服务器断开TCP连接。
对照图2.18和图2.19,并结合表2.6描述的各段链路使用协议,可以得到WAP业务
各段链路网络传输的主要报文种类如表2.7
表2.7 WAP业务各段链路传输的报文主要种类
2.4.2 Wap业务数据报文分析
上一小结对Wap业务通信流程和通信流程中各段链路采用的通信协议以及对应
的报文种类作了详细介绍，在本小结中，我们将结合上节的内容，对各段链路
中各种通信报文在整个链路传输数据量以及总通信过程中所占数据量进行比较
和讨论，从而确定Wap业务网络传输数据报文的主题特征，为下一步分建立
Wap业务模型确立分析对象。
为了得到Wap数据报文在网络传输过程中的基本特征，我们对大量的采样报
文进行了分析和统计，分别从应用层（HTTP和WSP协议层）传输的Wap业务
有效数据单元（即包含Wap业务有效内容的数据报文）以及传输层（TCP和
WTP协议层）传输的信令单元（该类报文为仅对网络传输正常进行有效，
属于信令部分）分别从报文个数以及流量方面针对不同的链路段进行了统计，
结果如下表所示：表2.8 各种报文的种类和个数在各段链路中所占比例
注：T-GW为终端到网关的上行链路；GW-CP为网关到服务器段的上行链路；
CP-GW为服务器到网关的下行链路；GW-T为网关到终端段的下行链路；
BL为终端到服务器的上行链路；FL为服务器到终端下行链路；
ALLP为终端与服务器之间的上下行链路。
通过上表数据，可以得出以下结论：
1. 手机终端到网关无线链路部分：
手机终端到WAP网关上行无线链路：在整个通信过程中其数据量只占总数据
量的3％左右，但数据报文的数目则占总包总数的十分之一。所以，在整个WAP
业务中，无线上行链路的负载要求比较小。确认报文数据量占整个链路的0.7％，
因此可以忽略不计。
WAP网关到手机终端下行无线链路： 确认报文的数据量很少，占不到这段链路
报文总数的1％，占整个通信中不超过千分之三。这段链路的确认报文的作用有两
个：一种是确认网关已经收到请求，另一种则是通知终端已经将请求成功发往CP
服务器。如果这两类确认报文都收不到，终端将重新提交请求。对于这种情况，
我们将其视为一次新的连接的开始，而不是视为一次重传。因此，我们也可以
将WAP网关到终端这段下行链路的确认报文忽略。
从数据量来看，在无线链路中，数据的不对称性很明显。统计结果表明，
下行数据传输量是上行数据传输量的6倍左右；但从报文的个数来说，上下行数据
报文数都占总包数的十分之一左右，但上行链路报文总数比下行链路报文总数略多些。
2. WAP网关到CP服务器链路：呈现出与WAP网关到终端的明显不同的特性。
在这段链路中，无论是数据包个数和还是数据总量，均占所有链路数据报文总数和
数量和的近百分之八十。
上行链路（WAP网关到CP服务器）的数据报文数量比下行链路（CP服务器到
WAP网关）的报文数量略少，但传输的报文大小却明显高于后者，即在上行链路传输
的数据量比下行链路的数据量还大些。与一般情况下认为的上下行不对称性是完全相反的。
在这段链路中（包括上下行），确认报文占各自链路报文总数的一半以上，其中网关到
服务器上行链路部分略少，确认报文占近百分之六十；而对于从服务器到网关的下行
链路，确认报文则占近百分之七十，这是因为在这一端使用TCP协议，双方的数据传
输需要大量的确认报文。但从数据量来说，无论是下行还是上行非确认报文的数据
量都达到百分之九十以上。对于WAP网关到CP服务器这段上行链路，非确认报文主
要是HTTP请求，数据量大增是因为每次WAP网关向服务器发起一个新的对象请求时，
都会将对应终端参数传送给请求的服务器，这是造成在这一端上下行链路不对称的最主
要原因。但是，由于确认报文的数据总量所占比重比较小，因此也可以忽略不计。
3. 从整体（从WAP终端到WAP服务器之间的上下行链路）来 说，有效数据报文
和信令报文各自的数据报文总数占整个通信过程中产生的数据报文总数的比例几乎一样，
都很接近百分之五十；但从数据量上来说，下行链路稍微高些，比上行链路多几个百分点。
从整个上下行链路看，数据传输的不对称性也就不那么明显了，这与有线网络不同。从报文
的种类来看，虽然确认报文在数量上比其他的数据或请求报文多些，但从二者占的数据量来
看，后者无疑占了绝对优势――百分之九十二左右。
4． 从整个通信过程来分析，由以上的讨论可以得出，在所有数据包中，确认报文数量上
占优（55%左右），而有效数据报文总数则稍微少些（45％左右），但从二者的数据流
量比较，确认报文一般只占到总数据量的8％，而其他的请求数据和应答数据则占了92％,
正因为基于该点认识，在后面的Wap模型够建中将只对有效数据报文即包含Wap业务内容
传输的报文考虑而言。
2.4.3 构建模型的数据来源
本项目使用ethereal软件在Wap网关采集数据传输报文并对采集的数据进行相关处理。
将采集的数据报文信息导出为文本文件，使用编写的程序提取各建模对象分析数据，
得到需要的各种类型的样本。下图为ethereal的数据报文信息显示界面。
图2.20 Ethereal数据图
下面是对上图中几个栏目的内容作出说明：
No 数据报文编号。
Time 相对于第一个数据包的想对发送时间。
Source 源IP地址
Destination 目的IP地址
Protocol 对应报文采用的最高层协议（网关与终端为WSP+WTP协议，
网关与服务器为HTTP协议。）
Info
数据报文信息（GET表示一次请求，REPLY代表返回信息，
ACK表示一次应答信号，SYN为同步标志，FIN为一次连接结束标志。
Continuation表示传送数据。）
Length
数据报文长度，单位为byte（直接读取主对象与内嵌对象数据包的大小）
Src port 源端口号
Dst port 目的端口号
对应不同的数据，其数据包内容不同，
比如，图2.20中高亮显示的确认报文的内容为：
图2.21 数据包信息
数据包内容分层次显示信息，从中可以得到数据包大小，数据包类型（本数据包为主对
象请求信息），源IP地址与目的IP地址，源端口号以及目的端口号等。
用ethereal将数据导出为文本格式,结构显示如下：
图2.22 导出的文本文件内容
从这个文件里能清楚地看到一次会话的具体过程。建立连接后，发送主对象请求，
终端进行解析，依次发送内嵌对象请求。
根据各栏目关键字可以提取到所需要各部分的数据。具体方法如下：
1，通过IP地址与端口号区分网关与各个终端。对应每一次具体连接
（一个终端与网关的通信），读取Info中信息（GET表示一次请求，
主对象请求的URL后缀为.jsp，内嵌对象请求URL后缀为.png、.wbmp等图片，
REPLY为返回数据包），可以直接获得请求包大小，以及主对象和内嵌对象包大小。
通过URL的不同可以区分主对象与内嵌对象。从图中可以看到内嵌对象的URL一般都
是以.png格式为主的图标以及少量的背景音乐等。
2，各种时间的获得都是在通过IP地址区分了不同用户的前提下，经过计算得到的。
Ø 网关响应时间：为网关收到终端主对象的Get请求到网关返回第一个Reply的时间。
Ø 主对象解析时间：收到Reply到发出下一个请求的时间。
Ø 内嵌对象解析时间：收到内嵌对象的Reply到发出下一个请求的时间。
Ø 阅读时间：收到最后一个内嵌对象到下一个主对象请求的时间。
以上对象定义见2.4.4节
3，内嵌对象个数，统计两次主对象之间的内嵌对象请求数。
4，在线时长是从AAA服务器处取得的数据，具体数据格式为：
图2.23 在线时长数据格式图
Active Time 这一列即为用户在线时长。每一行代表每一个用户的一次会话持续时间。
2.4.4 本项目业务模型
通过以上对WAP业务流程特征的分析，我们将WAP业务流程简化为如下模型：
图2.24 WAP业务模型
其中，主对象（main object）与内置对象（Embedded Objects）的区分如下图：
图2.25 主对象与内置对象
2.4.4.1 模型参数
根据图2.24
表2.9 本项目模型参数表
以下是对于模型的分析与解释：
1.对于一个用户而言，其一次连接过程描述为一次session，而描述一
次session的参数比较恰当的可能有二个：
(1) session的持续时间； (2)一次session中用户的点击次数（即主对象请求次数）。 对一次session中用户的点击次数建模是一个合理的选择，但是由于从网关提取数据时
完整的session并不常见，所以无法确定一次session中用户的点击次数。而从用户话
单获得session时长比较方便，所以我们只能定义参数为session时长。
2. 主对象中内置对象的连接请求是依次发起的，即发出一个内置对象请求后，
直到收到该请求对应的数据后才发下一个内置对象请求。
3. 从已采集的数据包来看，WAP终端由于运算能力上的限制，其解析时间可
能会比较长，即手机收到主对象会有一个比较长的解析时间，因此手机收到第一个主对象后
的解析时间也就是从收到主对象到发出第一个内置对象的请求这段时间时有必要考虑。同样，
由于终端能力上的限制，当收到内置对象的数据包时同样会有一个处理时延，这个时延从采
集数据上看是比较长的。上述过程可用图示如下：
图2.26 WAP业务流图
从上图可见t3－t2即为终端处理主对象数据包引起的时延，由于无法通过实际数据对这个时延
加以验证，解决办法是我们将WAP终端到WAP网关这段上行链路，WAP网关到WAP终端这段
下行链路和WAP终端的处理时延加在一块一起考虑，而这个数据也可以从网关采集到的数据报
文传输情况实际反映出来。
现在结论是： 由于主对象的解析时间明显大于内置对象的解析时间，并且这个时间在全部对象的
传输总时间中所占比重较大，我们不能将二者同等看待。因此，需要对主对象解析时间和内置对
象解析时间分别建模。
2. 网关响应时间指网关收到用户发出的对象请求至向用户返回对象数据的时间间隔，
这个参数不区分主对象与内置对象，因为根据实际数据分析，主对象与内置对象的网
关响应并没有什么差别。
3. 终端发出的请求数据包大小，根据采集的包内容来看，这个请求包除了固定的IP，
UDP，WTP头外，主要的不同在于WSP报文部分，而这部分的不同是由于终端请求的URL
长度不同造成的。
4. 在收到请求的主对象后，需要发起的内置对象请求的次数。已有的数据来看，即使是连续
请求的同一个主对象，其每次需要传输的内置对象也是不同的，但可以肯定的一点是，每次许传
递的内置对象的个数肯定小于主对象中包含的内置对象数目。
5. 阅读时间是指收到最后一个内嵌对象返回包到发出一个新的主对象的时间，
这并不是实际意义上的阅读时间，因为用户是从主对象下载到终端后就开始阅读行为的。
6. 在线用户数随时间的变化反映了不同时刻的用户变化情况，对于业务预测等都有实际
的意义。
7. 经过对以前模型与现网数据的分析，我们建立的业务模型的流程如下：
用户发出主对象请求—网关返回主对象—终端解析—发出内置对象请求—网关返回内置对象—
终端解析内置对象—……—网关返回最后一个内置对象—阅读—下一个主对象请求……这样，
模型就可以完整地描述了一次交互过程。
8. 与原有模型相比，我们讨论了多用户情况，引入在线用户数这个对象。
这样就可以分析用户数量的变化情况以及对网络性能的影响等，这对于网络配置、
业务预测等都有现实作用。
9. 我们的模型参数的确定是根据中国联通公司CDMA1x网络实际提取的数据，
所以相对于模拟的WAP网络，模型更加准确，更加符合实际情况。
|
wap底层技术资料(三)
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
