移动互联网性能提升端到端优化建议指导书V1.0.doc

移动互联网业务性能提升端到端优化建议指导书

（试用版）

中国电信集团公司网运部
二O一三年六月

编写说明：
随着智能终端的普及，移动互联网上的业务得到蓬勃发展，用户对移动互联网业务的要求也越来越高。在当前异常激烈的移动互联网竞争环境下，移动运营商必须推动业务的精细化管理，迅速提升业务质量，最终提升用户对业务的感知、满足用户的各项需求。
用户真实的业务感知涉及到从终端到业务平台整个业务流程各环节，因此感知的提升也是端到端优化的过程。本文结合分公司在业务优化过程中的经验，建立移动业务感知评估模型，从端到端的各个环节来探索网页浏览业务和QQ业务感知的提升优化方法，为分公司进行业务优化提供参考，同时希望各地能在具体的现网优化实践中建立端到端的优化概念，拓宽对移动互联网业务提升的分析视野，通过分析端到端影响业务质量的各种因素，建立从终端、无线网、核心网、业务平台等各个环节的协同优化的思路，全面提升端到端的网络承载性能、业务性能和用户感知，提高运营支撑能力。

本指导书主要完成单位：
中国电信集团公司网运部
中国电信股份有限公司广州研究院
中国电信江苏省分公司
中国电信河北省分公司
中国电信黑龙江省分公司
中国电信江西省分公司

中兴通信股份有限公司

编制历史：
版本
更新日期
修改
更新说明
主要撰写人
V1.0
2013-4-19

完成V1.0版
罗萍、钱少波、王兵

目录
中国电信移动互联网性能提升端到端优化建议指导书 1
1 概述 5
2 端到端的分析优化思路 5
3 分析工具介绍 6
4 选取优化业务 7
4.1 市场渗透率分析 7
4.2 流量占比分析 8
4.3 网络使用效益分析 8
5 确定评估业务质量的指标 8
5.1 业务流程分析 9
5.2 确定评估业务质量的指标 9
5.2.1 业务成功率 10
5.2.2 业务时延 10
5.2.3 业务达到的速率 11
5.2.4 业务丢包率 12
6 评估业务质量，制定优化策略 12
6.1 确定取样的时间和空间 12
6.1.1 业务流量、用户数发展趋势 12
6.1.2 业务忙时分析 13
6.1.3 业务分区域统计 13
6.2 评估业务质量 13
6.3 查问题，制定优化策略 14
6.3.1 业务成功率分析 14
6.3.2 业务时延分析 15
6.3.3 终端对业务的使用特特征 17
7 附录一：网页HTTP类业务的流程和指标 20
7.1 业务流程 20
7.2 网页浏览业务的评估指标 22
7.2.1 网页完整打开率 22
7.2.2 GET响应率 22
7.2.3 网页首次点击成功率 22
7.2.4 业务时延 23
7.2.5 网页业务初始阶段下载速率 24
7.2.6 业务丢包率 24
8 附录二：手机QQ业务的流程和指标 25
8.1 业务流程 25
8.2 手机QQ业务的评估指标 26
8.2.1 手机QQ接入成功率 26
8.2.2 手机QQ接收消息成功率 26
8.2.3 手机QQ发送消息成功率 27
8.2.4 手机QQ接收消息时延 27
8.2.5 手机QQ发送消息时延 27
8.2.6 手机QQ接收消息重传率 27
8.2.7 手机QQ发送消息重传率 28

1 概述
本文档介绍了基于1xEVDO网络移动互联网业务的分析和优化机制思路，适用于网络维护和优化人员对移动互联网业务进行分析，发现和预测数据网络业务运行和维护中的问题和隐患，针对相关问题进行网络调整、优化和管控，提高移动互联网业务业务的质量和用户满意度。
手册说明
1、本手册主要研究EVDO网络。
2、移动互联网业务的分析优化具体体现为对业务整体端到端流程的分析和优化，不仅需要考虑网络，同时需要关注用户和终端、业务和应用。
3、分析周期为月粒度。
4、由于各省的具体情况各不相同，因此该分析机制提供一种分析和优化的思路，各省公司可根据自身具体情况参照执行。

2 端到端的分析优化思路
移动互联网业务端到端的分析和优化指的是数据业务从终端出发，达到业务平台并返回结果到终端的整个环路，不仅考虑网络，同时关注用户和终端、业务和应用，因为端到端环路上的任何一点的问题，都将导致用户体验的下降。移动互联网业务端到端分析和优化的各环节如图2-1所示，端到端的分析优化思路如图2-2所示。

图2-1：移动互联网业务端到端分析和优化的各环节

图2-2端到端的分析优化思路

针对数据业务的端到端分析优化可分为三大步骤：
n 选取优化业务：首先按照一定的标准选取需要优化的业务，初期可选取渗透率高的业务、网络使用效率低的业务、流量占比高的业务作为对象进行分析。
n 确定评估业务质量的指标：研究业务流程，选取关键业务质量评估指标。
n 评估业务质量，制定优化策略：确定业务分析数据样本取样的时间和空间，采用数据采集工具获取样本；通过样本评估业务质量，查找终端、无线网、核心网、业务网、SP等端到端环节影响数据业务质量的短板问题，进行针对性的整改、提升。
3 分析工具介绍
为了评估业务质量和分析业务特征，需要用到以下分析工具：
1) RP接口数据采集和分析工具
这类工具主要通过采集的RP口流量数据对A11和A10进行关联分析，得到每用户的具体行为、全网各种应用的渗透率、各种业务对网络资源（流量、空口时间和空口连接次数）的使用程度和使用效率，充分体现用户在使用业务时具体的体验，如无线网络时延、有线网络时延、DNS时延、包的丢包率等。目前，主流设备厂家如阿朗、中兴和华为等都能提供这类工具。
2) IP包分析工具
此类工具可以解析每个IP包，并对抓取的数据包进行解析、过滤和关联分析。以主流工具Wireshark Network Protocol Analyzer为例，图3-1为Wireshark解开的IP包和针对某个IP包的详细解析。

图3-1Wireshark Network Protocol Analyzer针对某个IP包的详细解析

4 选取优化业务
对移动互联网业务的分析和优化，目的是提升业务质量和用户感知，提高用户对网络质量的评价。因此一般考虑选取渗透率高的业务、流量占比高的业务网络、网络使用效益低的业务作为对象进行分析，这些指标可以利用RP接口数据业务采集和分析工具获得。
一般市场部门也有相应的指标，需要注意的是，从RP口获取的指标与市场部门的指标在定义上有所区别，因此指标值也会有所不同。
4.1 市场渗透率分析
& 分析目的：市场渗透率在宏观上反映业务在市场中受关注的程度及用户的使用情况，对于市场渗透率高的业务应予以重点关注、保障。
& 数据来源：RP接口数据
& 指标说明
? 市场渗透率 = 统计周期内单个业务用户数/ 全部数据业务总用户数* 100%；
4.2 流量占比分析
& 分析目的: 以流量计费为基础的移动数据网络，关注流量占比高的业务并提高这类业务的业务感知，对提高数据业务的盈利能力有重要意义。
& 数据来源：RP接口数据
& 指标说明
? 计算每个业务在单位时间内的累计流量和单位时间内所有数据业务的总流量
? 业务流量占比 ＝ 单位时间内的某业务的累计流量/单位时间内所有数据业务的总流量
? 针对业务流量占比做排名来获得高流量占比业务。
4.3 网络使用效益分析
& 分析目的：以流量计费为基础的移动数据网络，关注流量低网络资源消耗高的业务并减少这类业务对网络资源的消耗，对提高网络使用效益有重要意义。
& 数据来源：RP接口数据
& 分析方法：
? 统计分析若干周期内每种业务的流量、占用的空口时间和引发的空口连接次数。
? 针对业务每兆字节消耗的空口时间以及每兆字节引起的连接次数做排名来获得使用效益低下的业务。
& 指标说明
? 每兆字节消耗的空口时间 ＝ 空口时间（小时）/流量（M）；
? 每兆字节引起的空口连接次数 = 空口连接次数（次）/流量（M）。
5 确定评估业务质量的指标
通常影响用户体验的指标主要有业务达到的速率和吞吐率、业务的时延、业务的成功率等，不同业务对用户感知的影响不同，如HTTP用户对时延相对敏感，而视频业务对抖动、时延等都很敏感。
在提升业务质量前首先需要确定不同业务影响用户感知的关键指标（例如成功率、时延、速率、吞吐率、丢包率等），并在掌握业务流程基础上分析指标所反映的问题。。
5.1 业务流程分析
& 分析目的：采用RP口针对单用户抓取IP流，分析业务流程和工作原理，作为后续分析追踪问题的基础。
& 数据来源：RP接口数据
& 分析方法
? 采用RP口针对单用户抓取IP流；
? 对IP包进行详细分析，了解业务流程和工作原理；
& 呈现方式：以网页HTTP类业务为例
? 从流程上分析得到网页浏览是基于HTTP的。影响用户从终端上对浏览业务体验的原因主要有两种：等待时间很长才出结果或告知服务不可达。
第一个数据包的Ack消息
第一个数据包
响应消息200 OK
Get请求

5.2 确定评估业务质量的指标
在制定影响业务质量指标时，需要考虑业务对包时延的容忍度、业务对于丢包的容忍度、业务对于速率的需求、业务本身成功率对业务体验的影响。不同业务可选择用户感知比较敏感的方面，最终确定影响业务感知的指标。如：
业务类别
评价指标
网页浏览类
成功率、时延、速率
即时通信类
成功率、时延
微博
成功率、时延
游戏类
时延、丢包率
5.2.1 业务成功率
& 分析目的：通过针对特定业务的成功率和失败率的计算，并按照失败类型做终端、网元和SP做统计，最终可帮助定位引起业务失败的原因。
& 数据来源：RP接口数据
& 分析方法：
? 从RP接口数据业务采集和分析工具提取数据；
? 针对不同业务可以定义不同的成功判定方法，进行计算
? 可按照业务的特性，把业务进行更细的分类，分别计算成功率
& 指标说明
? 成功率＝业务成功次数/所有业务次数
5.2.2 业务时延
& 分析目的：通过针对特定业务的时延的计算，并且分解时延到无线时延（无线侧）、有线时延（核心＋业务网侧）。最终利用算法定位到网元，实现时延问题定位。
& 数据来源：RP接口数据
& 分析方法：
? 由于RP接口数据采集和分析工具工作在RP口，无法获得用户发起请求到RP口截获请求的时间。
? 可以针对不同业务的流程，以及用户从发起请求到在终端上呈现可阅读的内容为标准，定义业务时延的计算方法。
? 在计算的时候，无线网络延迟和有线网络延迟分开计算。
& 指标说明：以网页HTTP类业务为例说明
? 有线时延 ＝t2 - t1 ,即：RP口获得业务第一个数据包的时间 － RP口获得业务请求的时间
? 无线时延 ＝t3 – t2 ，即：RP口获得业务第一个数据包Ack消息的时间 － RP口获得业务第一个包的时间。通过计算第一个包的无线时延t3-t2，最大限度排除手机性能对无线延迟的影响。
t3
t2
t1

5.2.3 业务达到的速率
& 分析目的：计算业务在当前网络下达到的平均速率和最好体验速率。如果这些速率足以支撑用户良好的体验，则表明此业务适合在本网络环境下；否则，需要考虑业务分流或其它优化策略。
& 数据来源：RP接口数据
& 分析方法：
? 从RP接口数据业务采集和分析工具提取数据，计算速率
& 指标说明
? 速率＝流量/时间。这里的时间需要去除没有流量的时间。如下图，速率＝从t1到t9的流量/((t6 – t1)+(t9 – t8)

? 要计算用户感受到最好的下载体验的速率，需考察业务数据包达到恒定速率后的速率。（以TCP为例子，计算最好速率时要去除TCP在窗口协商开始，到窗口恒定之间的过程）
5.2.4 业务丢包率
& 分析目的：通过针对特定业务的业务丢包率的计算，并按照网跳做统计，最终可帮助定位引起业务丢包率高的原因。
& 数据来源：RP接口数据
& 分析方法：
? 从RP接口数据业务采集和分析工具提取数据；
? 基于TCP协议，计算丢包率＝重传的报文数目/全部报文数*100%
6 评估业务质量，制定优化策略
通过研究选定业务的使用特征，如：业务的使用忙时和业务区域分布。通过对这些特征的分析，确定选定业务的取样时间和空间，采用数据采集工具获取样本支持后续的分析。
通过数据样本评估业务质量，查找终端、无线网、核心网、业务网、SP等端到端环节影响数据业务质量的短板问题，进行针对性的整改、提升。
6.1 确定取样的时间和空间
6.1.1 业务流量、用户数发展趋势
& 分析目的：通过对该业务流量、用户数在一段时间内的变化，得出业务发展趋势。
& 数据来源：RP接口数据分析；
& 分析方法：
? 按选定粒度统计分析流量、用户数的变化趋势；最新的流量、用户数统计数据
6.1.2 业务忙时分析
& 分析目的：通过对特定业务访问次数的统计，可以获得该业务访问主要集中在什么时段。针对业务的分析可以针对访问忙时。
& 数据来源：RP接口数据
& 分析方法：
? 针对若干周期分析统计业务访问的次数，并做时序分布。
? 针对业务访问次数，通常按照流来计算（不同的五元组为不同的流）。针对HTTP类业务比较特殊，一个HTTP通常就是一个流。但是一个HTTP请求，会引发多个后续HTTP请求，但是从用户角度来看，用户只点击了一次。针对这类业务，建议使用间隔超过一定时长（例如10分钟）的业务请求记为一次新的访问。
6.1.3 业务量分区域统计
& 分析目的：统计特定业务在不同区域（如：商业区、居民区、学校等）的使用人数，以获得业务的使用热点地区。
& 数据来源：RP接口数据
& 分析方法
? 计算若干周期内各个区域下所有小区针对选定业务的人数（去重复），并做占比分析。同时针对每个区域统计每小区的使用人数。
6.2 评估业务质量
选取关键指标，将当地自定义的指标值正常范围作为提升目标，通过数据采用工具采集分析样本数据，评估业务质量和客户感知。例如：
影响网页HTTP类业务的用户业务感知的主要环节为网页刷新、网页刷新时延等，包括下面5个指标：
客户感知
指标
指标定义
接口
指标正常值范围
页面能否刷新
页面完整打开率
页面首次点击成功率
GET响应率
所有页面刷新的成功率
页面首次点击刷新的成功率
所有GET请求的响应率
RP
自定义
页面刷新时延
网页首次点击时延
网页首次点击时延（有线部分）
网页首次点击时延（无线部分）
RP
自定义

6.3 查问题，制定优化策略
6.3.1 业务成功率分析
& 分析方法：以网页HTTP类业务为例
? 计算HTTP响应代码各类失败码（即4XX和5XX的返回码）的分布，针对失败率高的小区、SP等维度进行筛选。
小区名
使用网页HTTP类业务人数
错误码
错误码发生次数
错误引起的人数
单小区的失败率

4XX

…

5XX

…

说明：
1、4XX的返回码，主要是用户原因引起的。通过做终端和返回码的对应关系，分析4XX的错误发生和终端是否具有关联性。
2、5XX的返回码，主要是SP原因引起。针对5XX发生的SP进行统计分析，定位具体哪个SP的5XX的失败率较高。针对这类问题，可以通知SP协查解决。
? 进行基于APN的网页浏览中的GET/POST响应率指标的分析。
& 案例：以网页HTTP类业务为例
? 某BSC一个小时的统计数据分析得到网页响应成功率指标如下，可知，当APN设置为ctwap时， GET响应率仅为75%，偏低。
APN
GET请求数据占比
GET响应率
GET时延（ms）
ctnet@
63.79%
95.23%
428.0837
ctwap@
31.60%
75.03%
820.7459
? 找出APN为ctwap的各个Host中，响应率最低的前10名，从中可以看到“”的GET响应率仅为3%，而且GET请求高达27393次。这严重影响ctwap的整体指标。
Host
GET请求次数
GET响应次数
GET响应成功率

21160
853
3.11%

179
13
7.26%
211.137.127.208:8080
21
2
9.52%
10.234.113.8
749
91
12.15%
r10.mo.baidunection: Keep-Alive
7
1
14.29%

7
1
14.29%

10
2
20.00%

11
3
27.27%

17
5
29.41%

3
1
33.33%
? 剔除HOST为“”的网站后，统计指标正常。经过ctwap的请求响应时延约800ms，这个和网关KPI统计报表结果一致。
APN
GET响应率
GET时延（ms）
ctnet@
95.50%
412.3807
ctwap@
93.18%
795.3654
? WAP网关排查：通过在WAP网关抓包分析，发现SP存在tcp握手后，主动断链的现象，原因是SP对WAP网关地址做了限制，造成当APN设置为ctwap时，GET响应率偏低的问题。
说明：Host为不同APN GET指标统计中，CTWAP的访问不是所有都失败。解释如下：这个跟统计手段有关，统计工具使用GreKEY标识一次连接，但存在CTNET用户被分配了重复的GreKEY的可能性（之前由CTWAP用户使用，由于PPP断链不再使用）。
6.3.2 业务时延分析
通过针对特定业务的时延的计算，并且分解时延到无线侧、核心＋业务网侧。通过抓取定位现网问题区域，逐层详细分析导致高时延的网络环节及具体因素，并通过针对性优化解决问题。
& 分析方法：以网页HTTP类业务为例
? 总时延分区间统计分析:
HTTP响应代码
大于2s
（次数）
1s - 2s
（次数）
小于1s
（次数）
高时延（大于2s）的占比
1XX

2XX

3XX

4XX

5XX

? 统计网页面刷新平均时延，计算其中无线段平均时延、核心段平均时延，并计算无线时延在总时延的占比。
? 网络层初步定位：进一步分解各网元时延详细值，发现无线侧原因引发的高时延小区、业务侧原因引发的高时延小区。
6.3.2.1 业务时延分析–无线侧问题
& 分析方法：以网页HTTP类业务为例
? 选取时延最大且远高于时延平均值的Top10小区作为分析对象
? 针对无线侧引起的时延过长，开展针对性优化
& 案例：
某校园室分载扇测试现场SINR值良好，但该室分下的用户在早忙时HTTP业务的无线部分时延平均612ms，而在空口质量良好的情况下，HTTP 类业务的空口时延不超过200ms。
以下是现场测试的感知时延和分析系统统计的空口时延指标。
现场测试感知
RP口分析系统空口时延指标
10:16分 新浪全部打开1分钟
728ms
10:26分 新浪全部打开70秒
696ms
10:26分 新浪全部打开70秒
739ms
10:36分 新浪全部打开2分钟
987ms
10:42分 新浪全部打开2分钟
887ms
10:42分 新浪全部打开2分钟
1092ms
由于该环境是室分环境，且经测试现场SINR 值良好，不存在覆盖差和接入远点的问题，通过CDR 话单的过滤，发现该室分系统在早上10 点的SINR 大于-5 的比例达到了97.68%，且现场测试的话单的接入SINR 值都很高，排除前向问题。
将该载扇下的早忙时接入话单RSSI 进行统计，得出了以下分布情况：在接入RSSI 的统计中，有56.71%的话单在接入时的RSSI 大于-90dBm，造成用户使用时感知不好。
该载扇在负荷较低的时候RSSI 为-113.8dBm，说明该室分不存在由于质量差导致RSSI 高的问题。从RSSI 统计指标上看，其在忙时迅速升高的原因还是由于用户数量较多。
从功控参数、ACK Gain 参数对RSSI 进行控制。整前后性能指标对比如下表所示：
性能指标
DO:连接成功率（%）
DO:无线掉线率（%）
DO:RSSI均值（主集）
现场测试感知（时延）
首次点击时延（无线部分）
调整前
99.58
0.73
-873.5
超过1分钟
612ms
调整后
99.44
0.97
-987.2
23秒
112ms
可以看出，连接成功率和掉线率略有恶化，但是RSSI和用户感知提升了。
从本次参数修改试验中可以得到以下结论：
1、对于用户数较多的室分场景，反向RSSI会迅速升高；
2、由于反向链路的恶化，ACK 消息不能成功地上传，因此前向的速率、流量和时延都会受到影响，从而影响用户业务感知；
3、通过优化反向功控参数，可有效降低底噪，提升用户感知。
6.3.2.2 业务时延分析–核心侧问题
& 分析方法：以网页HTTP类业务为例
? 针对核心或SP的时延过大的小区，可针对这小区中访问时延过长的TOP用户分析
? 时延过大小区中，时延较大用户经常访问的SP的时延排名, 判断是否由于某些地址资源响应时延异常导致整体访问时间过长
用户
响应IP
有线网络响应时延（ms）
网络侧响应代码
http_host

502

XXX

注：网络侧响应代码=502，表示服务器过载不能及时响应，说明相关服务器服务能力不足。影响了用户体验，需要协调解决。
? 即使是成功的使用记录，某些服务器也可能具有较高的时延。如果存在某些服务器响应时延远高于同类性服务器平均响应时延，说明某些服务器存在性能瓶颈，影响了用户体验，需要协调解决。
? 进行基于APN的网页浏览中的GET/POST时延指标的分析。
6.3.3 终端对业务特征的影响
分析终端和终端参数设置对业务的影响。
& 分析方法：
? 以HTTP业务为例，通过RP口抓包数据，分析用户的HTTP协议相关业务使用情况，再通过UserAgent字段获取到相应用户所使用的终端类型。将某款终端的所有用户的业务使用情况进行累加统计，得到某款终端的HTTP相关指标。
? 通过与呼叫详单数据的对接，使用IMSI作为关联条件，统计得到某款终端的无线侧相关指标。
? 统计RP口Chap-Challege消息中的APN字段统计终端的APN参数设置情况
& 案例1：终端对业务感知的影响：以iPhone4s 和XT800进行对比，分析两种终端在处理业务时采用不同机制导致用户感知差异的问题。
? 微博业务感知评估：

iPhone4S 运行微博业务情况良好，用户在点击成功率、时延、速率、重传等各方面的感知都超越XT800。
? 感知差异原因分析：
1、测试发现，XT800在新浪微博发送的初始阶段数据包普遍较小，如图6-1所示，XT800发送新浪微博速率计算：
22050*8/(46.1818-44.8862)=136.153kbps

图 6-1 XT800微博初始包分析
2、iPhone4s 在初始阶段会迅速地将发送的数据包增大至最大的1400，如图6-2所示，iPhone4s 发送新浪微博速率计算：
24050*8/(35.1818-34.0606)=171.632kbps

图6-2 iPhone4s微博初始包分析
3、由此可见，微博发送初始阶段数据包的大小对微博发送速率用一定的影响。
& 案例2：分析终端APN参数设置情况
? 国内运营商虽也有终端定制模式，但生产厂商的直接分销零售仍是主要模式，导致终端的规范性、通用性、可靠性存在诸多问题。如，终端在APN、代理地址/端口、彩信URL的设置上往往各异，在普通用户并不清楚如何正确设置的情况下，会直接导致用户不能正常发起数据应用业务。终端的正确设置如下表所示：
应用需WAP网关代理的业务的
终端设置
应用不需WAP网关代理的业务的终端设置
应用彩信业务的终端设置
终端设置项
正确的设置
终端设置项
正确的设置
终端设置项
正确的设置
接入点名称（APN）
ctwap@
接入点名称（APN）
ctnet@
接入点名称（APN）
ctwap@
代理地址
10.0.0.200
代理地址
无
代理地址
10.0.0.200
代理端口
80
代理端口
无
代理端口
80

彩信URI
http://mmsc.vnet.mobi

? 统计RP口Chap-Challege消息中的APN字段可知终端的APN设置。某BSC晚忙时21:00~22:00 RP口抓包数据得到用户APN设置如下表所示：
用户数
APN类型
用户接入点类型
836
ctwap@
互联星空
191
ctnet@
互联网
3
0000000000@
其它
1
[e-mail]
政企客户
1
wap2@
互联星空
16
460030xxxxxxxxx@
其它
从上表可以发现大量设置错误的APN的格式为：IMSI@。用户使用终端上网，如果APN设置错误是无法正常进行业务的，解决办法包括：用户修改终端APN设置，在PDSN-AAA对有误的APN完成手动纠错、或PDSN-AAA提供APN自动纠错功能。
7 附录一：网页HTTP类业务的流程和指标
7.1 业务流程
网页浏览，是指利用终端（手机或个人电脑）通过第三方软件或是内置的浏览器程序（如Internet Explorer、UCWEB等），访问互联网上各种页面类型的资讯信息（如文字、图片、动画等）。网页浏览实现的模式一般如图7-1所示。

7-1 网页浏览实现的模式
我们所浏览的网页，一般有Web网页和WAP网页两种类型。使用支持HTTP协议的终端浏览Web网页，有两种接入方式。当终端APN（Access Point Name，接入点）设置为CTWAP时，终端将通过WAP网关代理，与Web服务器建立连接；当终端APN设置为CTNET时，无需WAP网关代理，直接通过IP骨干网与Web服务器建立连接。也就是说，APN的设置决定了移动终端是否通过WAP网关代理的方式来访问互联网。
对于终端和移动网络侧来说，这两种接入方式的业务流程是基本一致的，如图7-2所示，所不同的仅是与终端建立TCP连接的是WAP网关，还是Web服务器。

图7-2 网页HTTP类业务的业务流程
7.2 网页浏览业务的评估指标
7.2.1 网页完整打开率
& 指标说明：
? 网页完整打开率= （HTTP响应码小于400次数 / HTTP请求次数）*100%
& 算法说明：
? HTTP响应代码：
HTTP（Hyper Text Transfer Protocol）是超文本传输协议的缩写，它用于传送WWW方式的数据，关于HTTP协议的详细内容请参考RFC2616。HTTP响应消息中包含响应代码Status-Code，是一个三个数字的结果代码，第一个数字可能取5个不同的值：
HTTP响应代码
描述
1xx
报告的，表示接收到请求，继续进程
2xx
成功，步骤成功接收，被理解，并被接受，如：200 OK
3xx
重定向类(Redirection)，表示请求没有成功，客户必须采取进一步的动作
4xx
客户端错误（Client Error）,表示客户端提交的请求有错误，例如：404 NOT Fount，意味着请求中所引用的文档不存在。
5xx
服务器错误（Server Error），主要包括服务器内部错误、无法提供服务、服务超时等，如：500服务器内部错误。
? HTTP响应码小于400（包括3XX重定向、1XX临时响应等）计为成功。
7.2.2 GET响应率
& 指标说明：
? GET响应率= 系统侧响应HTTP GET消息的次数 / 系统侧收到终端发起的HTTP GET消息的次数
& 算法说明：
? 在空口建立成功、PPP建立成功、DNS查询成功的条件下，反映客户端接收到所请求网页内容的概率。
7.2.3 网页首次点击成功率
用户发起第一个符合网页业务的Get请求，服务器收到Get请求后会回复Response消息并下发的第一个数据包，手机收到数据包后会对数据包发起一个Ack响应的时间，分为无线部分和有线部分。
& 指标说明：
? 首次点击成功率（有线部分）＝ PCF收到的第一个数据包（response）的次数/PCF发起的第一个Get请求次数
? 首次点击成功率（无线部分）＝PCF发起的Ack次数/ PCF收到的第一个数据包（response）的次数
& 算法说明：
该指标能够较客观反映网页首次点击打开成功率，有线部分可反映从PCF端发起GET请求后收到PDSN下发的第一个数据包，包含PDSN、PCF、SP服务器部分；无线部分可反映从PDSN下发的第一个下行数据包到PCF发起的相应的第一个数据包的ACK的过程，包含无线空口、Abis接口部分。
7.2.4 业务时延
用户发起第一个符合网页业务的Get请求，服务器收到Get请求后会回复Response消息并下发的第一个数据包，手机收到数据包后会对数据包发起一个Ack响应的时间，分为无线部分和有线部分。
& 指标说明：
? 网页首次点击时延（有线部分）=PDSN发起的第一个数据包时间点 – PCF发起的首个GET时间点
? 网页首次点击时延（无线部分）=PCF发起相应的第一个数据包ACK时间点 - PDSN发出的第一个数据包的时间点
& 算法说明：如下图
? 网页首次点击时延（有线部分）= t2 – t1
? 网页首次点击时延（无线部分）= t3 – t2
t3
t2
t1

7.2.5 网页业务初始阶段下载速率
& 指标说明：
? 网页下载平均速率 = 网页大小（kbits） / 网页完全响应时延(s)
& 算法说明：
? 网页大小：网页的每个元素大小求和（每个Response消息的Content-Length或者Chunk Size之和）。
? 网页完全响应时延： T 网页最后1个Response消息时间点 – T网页第1个GET请求时间点。
7.2.6 业务丢包率
& 指标说明：
? 业务丢包率 ＝ 重传的报文数目/全部报文数*100%
& 算法说明：
指标说明：基于TCP协议，计算丢包率，丢包率＝重传的报文数目/全部报文数*100%
8 附录二：手机QQ业务的流程和指标
8.1 业务流程
QQ使用的应用层协议是OICQ，OICQ使用的传输层协议是UDP或TCP。有别于有线网络的QQ业务，手机QQ业务建立在TCP传输协议上，手机QQ服务器的TCP端口号一般为14000。
手机QQ用户点击QQ程序登陆后，应用程序将和腾讯服务器通过TCP三步握手方式进行连接。由于手机QQ业务的会话与应用协议无法解析，因此仅能从TCP层对QQ业务性能进行分析。QQ业务信息交互是以“Ack,Push”形式进行的，即带PUSH位的TCP交互，TCP传输层一旦收到TCP数据包就会传送给应用层，接收端以“Ack”或“Ack,Push”消息对接收的信息进行确认。
QQ业务的主要消息流程包括：业务接入、上行发送消息、下行发送消息。
n 业务接入
QQ业务的接入是用户向网络发起连接请求，网络对用户进行响应的过程，QQ业务的接入是采用TCP三步握手的方式，以下是QQ业务TCP三步握手(Three-way Handshake)流程图：
PCF
PDSN

第一次握手：建立连接时，客户端发送SYN包到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到SYN包，必须对客户的SYN进行确认ACK，同时自己也发送一个SYN包，即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
n 上行发送消息
QQ业务上行发送消息的交互，首先由QQ用户向服务器发送的TCP包消息，QQ服务器收到消息以后返回对应的确认消息“Ack”或“Ack,Push”。以下是QQ业务一次上行消息交互的流程图：
PDSN
PCF

n 下行发送消息
QQ业务下行消息的交互，首先由QQ服务器向用户发出“Ack,Push”消息，QQ用户收到消息以后返回对应的确认消息“Ack”或“Ack,Push”。以下是QQ业务一次下行消息交互的流程图：

8.2 手机QQ业务的评估指标
8.2.1 手机QQ接入成功率
& 指标说明：
? 手机QQ接入成功率 = （第三次握手Ack总次数)/第一次握手SYN总次数)*100%
& 算法说明：
手机QQ接入成功率，是指终端用户应用手机QQ业务，点击登录后，终端能够成功与QQ服务器建立TCP连接的概率，即TCP三次握手成功率。
8.2.2 手机QQ接收消息成功率
& 指标说明：
? 手机QQ接收消息成功率 = （下行消息响应次数/下行消息发送次数）*100%
& 算法说明：
手机QQ接收消息成功率，是指终端与QQ服务器之间下行发送消息成功的概率，也就是QQ用户终端收到服务器发来的信息并予以确认的成功概率。
8.2.3 手机QQ发送消息成功率
& 指标说明：
? 手机QQ发送消息成功率 = （上行消息响应次数/上行消息发送次数）*100%
& 算法说明：
手机QQ发送消息成功率，是指终端与QQ服务器之间上行发送消息成功的概率，也就是QQ服务器收到终端发来的信息并予以确认的成功概率。
8.2.4 手机QQ接收消息时延
& 指标说明：
? 手机QQ接收消息时延 = 下行消息响应的时间点–下行消息发送的时间点
& 算法说明：
以QQ服务器发往用户的“Ack,Push”消息为起点，以 QQ用户回复的相应确认消息“Ack”或“Ack,Push”为终点，两条消息之间的时间间隔。
8.2.5 手机QQ发送消息时延
& 指标说明：
? 手机QQ发送消息时延 = 上行消息响应的时间点–上行消息发送的