查看: 6014|回复: 5

HTTP上网业务流畅度提升特例分析 [复制链接]

admin

管理员

Rank: 9 Rank: 9

电梯直达

楼主

发表于 2013-3-21 23:57:46 |只看该作者 |倒序浏览

一键分享

本文摘自《电信技术》2011年09期。【作者】周徐；

【机构】中国移动通信集团重庆有限公司；

【摘要】 <正>1概述TD-SCDMA在重庆正式商用后,发展势头最好的终端类型是数据卡和上网本,发展最好的业务是HTTP上网、在线视频和高速下载。业务的发展会带来流量的激增,因此也会成为投诉的热点。经初步分析,高速下载投诉较少,

【关键词】重复报文；上网业务；高速下载；分组业务；初步分析；网络服务器；安全设备；互联网；完全正；网页；

1 概述

TD-SCDMA在重庆正式商用后，发展势头最好的终端类型是数据卡和上网本，发展最好的业务是HTTP上网、在线视频和高速下载。业务的发展会带来流量的激增，因此也会成为投诉的热点。

经初歩分析，高速下载投诉较少，在线视频主要受数据源和空中接口理论最大速率影响，暂定放到后期进行专项优化。HTTP上网投诉较多且具备优化条件，短期内有较大潜力可挖，因此重庆移动集中精力开展了HTTP上网业务流畅度的提升优化。

第一阶段（参数优化阶段）的优化包括3个层面。

（1）NodeB侧的优化参数包括CQI(上下限，调整步长）、BLER(Initial BLER Target/Residual BLER Target)、调度算法（偏正比公平PF)。

(2)RNC侧的优化包括SCCH-SICH远离上下行时隙转换点；SICH反馈的NACK数目较高或16QAM的比例较低（提高PDSCH-SCCH总功率/SCCH MAX PWR—提高HSSICHSIR TARGET/
HSSCCH BLER);DCCC算法（提高上下行初始速率，加快升速）；RLC层参数（RLC windows size);MAC层参数（MAC-hsT1timer、MAC-hswindows size、MAC-hs discard timer、MAC-d PDU size)。

(3)在CN侧对SGSN和HLR进行QoS速率限制，HSDPA绝对速率得到显著提升，HTTP上网体验有所改善。

经过参数优化，仍有部分RNC下经常性存在"网页打不开，点击网页无响应〃的情况，于是转入第二阶段优化，针对这部分网元进行故障的精确定位排查。

2问题描述

通过组织海量的摸底测试，重庆移动网优中心发现在华为设备区域，各网元链路层下载速率均值在1.2Mbit/s的情况下，TD-SCDMA数据卡/上网本使用HTTP上网业务时，仍然会出现无法打开网页的情况，而其他非HTTP的业务使用正常。

在特定条件下，RNC对分组业务的保护机制生效时会双发复制保护报文。由于HTTP业务在安全级别的定义不同，导致双发复制保护报文被互联网安全设备判断为类似网络攻击的行为。在双发保护报文的流量达到安全控制门限后被拦截的情况发生时，引起网络服务器与UE间网页浏览交互流程中断，终端用户的体验即为出现打开网页有时异常的情况。

3 问题分析

3.1问题现象初析

现场问题现象存在两个明显的特殊性：一是出现时间无法确定，据现场用户回忆，已无法准确确认该异常首次出现的时间，这样对历史日志分析、Log解析等分析量和工作量要求更高，短期定位存在一定困难；二是业务现象特殊，从用户反馈情况看，该异常仅针对HTTP业务即打开网页存在异常，而进行高速下载等时无明显异常，且下载平均速率良好，一般在1.2Mbit/s以上。

3.2定位思路

根据上述现象，经初歩分析后，采用端到端网元（SGSN/CE/RNC/UE等）多点联合抓包的操作、共同分析比对的手段、逻辑网元范围排除的方式，环环相扣、循序渐进地缩小排查范围，逐歩进行定位。

（1）问题现象确定：单点测试（枢纽楼）进行问题复现，通过多业务大量测试来确认问题的准确现象，捕捉异常规律，同时注意全业务测试，确认是否有其他未发现的业务异常等。

(2)问题范围确定：在外场对全网逐个RNC进行CQT定点的业务测试，每个RNC下至少测试3~5个NodeB，目的是摸清全网表现，确定问题发生范围。

(3)组网逻辑分析：确定分析切入点，根据歩骤（1)、（2)的实施结果，分析现场组网逻辑是否存在规律，从而确定定位操作的切入点。

（4）网元逐层排除：做好环境测试准备，搭建抓包环境、仪器调试等，逐个网元排除，层层排查问题。

通过排查可以看出，出问题的3套RNC都是挂在同一套CE和同一套核心网下，那么按照故障现象来分析，初歩怀疑出现问题的设备只能集中在GGSN或CMNET上。因为在整个网络中能够对用户面报文进行深度解析并具备控制能力的只有GGSN和CMNET。

4 问题定位及处理

4.1现象复现与问题确认

在问题RNC-GM161R1下挂的枢纽楼微站点下进行故障复现、大量测试，同时进行信令消息、LOG跟踪等。

我们在现场共测试了163、Google、淘宝、新浪以及重庆移动网上营业厅等网站，发现上述网站均存在访问异常现象。具体表现为网页概率性出现无法打开或只能打开一半的情况，在这些网站中，新浪出现问题的概率更大，多次测试中失败率最高一次接近80%。同时，结合在测试时跟踪消息、LOG的分析，在打开网页出现异常时UE上下性吞吐率都非常小，通常只有几kbit/s。

紧接着我们进行了其他业务测试，包括DNS解析测试、Ping测试、FTP下载、E-mail和P2P下载等，结果发现在出现网页打不开时其他几项业务测试完全正常。出现问题时DNS解析完全正常，Ping新浪服务器也完全正常，无论是成功率或时延表现都很好，FTP平均下载速率大于1.4Mbit/s。

从问题重现过程我们可以得到以下结论：

（1）该问题仅对HTTP业务有影响，完全不存在其他PS业务异常；

(2)所有网站都有异常现象，包括重庆移动网上营业厅、新浪网站的表现最明显；

(3)通过DNS解析测试发现DNS解析成功率和时延都非常短，不存在任何问题；

(4)用32 byte、1400byte、1460byte和1500byte分别Ping新浪服务器，无论是否出现问题，Ping时延都在正常范围内，没有出现时延异常增加或Ping不通的情况，证明整条链路不存在丢包或时延异常问题；

(5)包括FTP高速下载在内（除HTTP外）的其他业务表现完全正常，速率良好；

（6）凌晨以后访问成功率变高，异常现象减少明显，可能数十次测试无法复现异常；

（7）拨号操作没有任何问题，排除信令面出现异常的可能；

（8）从现场用户反馈情况看，该异常已经存在一段时间，出现时间无法确认，给问题的定位造成了一定难度。

4.2 组网逻辑分析

仔细分析上述原因可以发现，似乎网络中存在某种设备对HTTP报文进行了深入过滤，从而导致只有HTTP报文受到影响。结合各网元对用户面报文的处理层级可以发现，故障点有较大的可能出现在GGSN或CMNET中。

在GGSN之前，所有的用户面报文均"包裏〃在GTP报文之中，这些设备只能看到GTP层的内容，而无法看到用户报文，更谈不上对用户面报文进行控制和修改，因此我们认为问题的产生极有可能是GGSN、CMNET或互联网上的某层设备/某种处理机制引起。

4.3 问题范围确定

通过外场大量测试问题现象已经确认清楚，问题存在于GM161R1/R2门31R3，其他RNC下正常。从问题范围确认过程，可以得到如下结论：异常区域所在3个RNC存在于同一个机房——人和21楼；3个RNC都下挂于SGSN9下，但SGSN9下挂华为有业务现象一直正常的RNC；3个RNC的PS域传输路径相同，RNC侧接入CE相同，IP承载网通路相同。

结合以上分析，问题似乎指向了GGSN、CMNET等上层，但考虑问题范围确定的几点特征——出现问题的RNC都集中在同一套CE下的现象，也不能排除CE或RNC问题导致故障的可能。

4.4逻辑网元排查

首先我们针对GGSN及其以上区域进行排查。根据重庆移动现场组网策略，在SGSN9下挂了出现问题的几个RNC(也有正常的RNC),还下挂了GM161下的2GBSC，区别在于BSC的Gb接口传输是传统E1/T1中继，并非丨P化的承载网。

于是我们在测试地点闭塞了测试TD-SCDMA网络小区，并强制数据卡重选到2G网络上。在2GEDGE网络拨号成功后，进行大量HTTP业务测试。结果发现，3组测试均正常（ThinkPadX200+ET128数据卡/DELLD630+ET188/HP6910P),除了页面下载速度偏慢以外，没有出现任何网页打开异常的情况，HTTP业务测试完全正常。

4.5 联合抓包分析

我们分别在终端、SGSN和GGSN上对单用户的用户面报文进行了多次联合抓包（以下简称抓包）。抓包分析的主要目的是对比几个节点上的报文的区别以及2G和TD-SCDMA之间的用户面报文的区别。

在抓包完成后，我们对报文进行了仔细的对比。结果显示，除了存在少量的丢包外其他完全正常。同时我们也对比了三点抓包的结果，发现三点抓到的报文完全一致。这至少可以证实从终端到GGSN之间不存在丢包的情况，且由于2G和TD-SCDMA共用一套核心网，那么CMNET和互联网看到的源IP都是一样的，因此可以证明CMNET和互联网也不存在类似的问题。

接着对比TD-SCDMA网络三点抓包的结果，对某次网页打不开的情况下抓到的报文进行分析。首先看到的是整个交互过程中存在大量的TCP、DUP、ACK报文，其次整个交互过程并没有完成。

将抓包情况对比标准流程，不难看出，出现问题时DNS解析过程正常完成，但终端与服务器之间的三次握手都没有完成，开始时终端发出第一次握手请求（SYN）,服务器对此请求进行了第二次握手应答（SYN ACK）,终端根据流程向服务器发送了第三次握手(ACK),但似乎服务器没有收到第三次握手报文，于是重发了二次握手报文(SYNACK),终端侧也一样，在发出GET请求后没有收到服务器应答的报文，于是不停地重发第三次握手报文，从而产生了大量的DUPACK报文，最终因连接建立超时而被服务器断连，导致访问失败。

我们接着对比了核心网GGSN侧报文，直接将GGSN的抓包结果与终端抓包结果进行对比，如果两端报文不一致则可以说明是在GGSN和终端之间存在丢包现象，如果对比结果一致，那么丢包就发生在GGSN以后的网元。

从GGSN上的抓包结果看，整个交互过程与终端侧完全一致，惟一的不同是所有的报文都变成了双份。也就是说，在GGSN之前的某个网元将报文复制了一份内容一模一样的报文同时发了出来，因此在GGSN之前的网元不存在丢包的情况，而除了访问异常时，GGSN收到的报文是双份报文外，除此以外其他没有任何不同。

至此，整个问题定位目标指向了CMNET和之后的互联网。

4.6 原因定位

通过对联合抓包结果的分析，问题集中在确定为何CMNET及其以上公网对报文的处理存在某种异常，尤其是为什么复制报文会导致HTTP访问异常？

从网络结构和功能划分来看，所有终端在使用数据业务时的IP地址都是由GGSN分配的，因此只要是同一台GGSN下使用同一个APN接入的终端，都会获得同一个网段的IP地址，而且都属于私有地址，其有效范围仅限于GGSN前面区域。从GGSN的Gi接口开始到互联网则属于公网范围，此时GGSN类似于一台代理服务器，用一个公网IP地址代理所有终端发出的业务请求，以完成业务交互。

问题发生的直接原因可以描述为：如果在网络内存在设备能够发出较多数量的重复报文，那么这些报文在经过GGSN后会变成同一个地址发出的重复报文，当这些报文达到一定数量时，从网络的角度来看，这些重复报文就变成了对服务器的攻击报文，网络中的安全设备就会对这些攻击报文予以拦截，从而导致上行报文无法到达服务器，进而造成业务访问失败。

为了证实截至目前的判断，需要解决3个问题：双份报文消失后是否HTTP异常就会消失？双份报文的产生源在哪里？双份报文产生的原因？

（1）双份报文的产生源

通过上述第一次联合抓包分析可知，双份报文产生设备是在SGSN以下的CE设备-RNC之间产生的（由于CE上抓包的操作是将RNC到CE的整个吉比特的光口数据镜像到测试仪器上，不但需要专门测试仪器，同时每秒的数据流量非常大，分析量大，所以第一次联合抓包是使用SGSN/GGSN可针对单用户进行抓包的办法初析，并未进行CE抓包），后续报文产生根源需要在RNC-CE之间进行抓包。

第二次抓包的方法是：在两套CE面向RNC—侧的端口搭建好测试环境，进行镜像同歩抓包，如果在两套CE上同时抓到一模一样的报文，则可以证实重复报文是由RNC发出的，否则可能是CE高层转发芯片失效导致产生重复报文。

从两套CE与RNC连接的光口镜像上同时抓到的报文来看，确实是RNC的两个光口同时发出了两个一模一样的报文，由此可以确定重复报文是由RNC产生。

（2）双份报文与HTTP异常的关联

确认双发报文由RNC产生之后，根据RNC的配置和组网情况，对问题RNC的2条分组业务接口板GOUa(GOU0-24/GOU0-25)的一个光口GOUO-25进行了闭塞操作，然后进行业务验证测试和再次抓包。业务测试的结果不出所料：此前异常的RNC下打开网页异常的情况消失，业务正常。

同时，本次操作后，抓包的结果亦是双份报文消失，同时看到从GGSN上抓包发现双份报文已经消失，可以证实该双份数据包是RNC的GOUa光口板发出的。

随后，将闭塞的GOUO-25解闭塞，恢复到正常场景，进行测试和业务验证发现，双发报文消失，业务验证完全正常。

至此可以确定，双发包的情况被互联网上层安全设备处理，从而导致的业务异常。之前对现场业务异常的几个疑问也迎刃而解。

为什么每个网站的失败概率不同？因为每个网站安全设备的策略不同，新浪是国内比较热门的网站，用户量相对较大，其安全策略的制定、对同样现象的处理表现有所区别。

为什么对其他业务不构成影响？其在网络安全设备看来，FTP等业务和HTTP业务的应用层表现是不同的，FTP业务的重复包可能会被认为是一个安全的业务会话中正常的数据重发行为，而大量HTTP业务重复包则可能会被理解为网络攻击；另一方面，HTTP服务器被攻击后造成的影响比其他服务要大得多（网站打不开或页面被篡改对用户的影响更大），绝大部分安全设备都是对HTTP服务进行保护。

为什么工作日的凌晨以后问题出现的概率降低？网络安全策略中存在控制门限和频度的阈值，所以业务低的时候可能性较小。

（3）双份报文产生的触发原因

那么，RNC产生双份报文的原因是什么昵？经过RNC开发人员的代码走读分析、组网模式模拟、配置环境镜像、实验室故障复现等定位，判断该问题的产生是基于目前PS组网模式中的特例触发条件发生后，RNC对报文的底层保护机制生效而表现出的问题，是非常特殊的情况。

根据设计方案，现场RNC的IU-PS接口是采用的GOUa单板主备、端口分担、路由负荷分担的方式来实施的，即PS接口板GOUa配置的2块，单板之间工作方式为主备用，而主备2个单板的端口工作方式是负荷分担机制，一般简称为"分担模式"。

本次异常的出现，从代码分析和实验室模拟情况，确定是某次该3套RNC所在机房与CE间链路快速闪断的异常条件下，BFD检测端口状态快速反复上报，单板端口的系统内变量反复刷新，2个接口板的BFD端口检测UP/DOWN状态不一致（现场实际情况状态都应为正常工作的UP状态）所致；同时，系统内部报文转发的HASH表与端口检测状态相关，HASH表根据端口检测UP/DOWN状态变量判断转发。

在HASH与状态变量的代码实现中，设定了意外失效无条件保护规则为：工作态之外的任何意外情况下，报文在设备配置的端口上同时进行发送。如此，在任何意外情况，即使上述变量/HASH表失效，业务报文仍然可以正常收发，完全保证了业务的连续性。RNC在双GOUa端口上同时发送的数据包正是我们抓包获取到的〃双份报文”，可称之为〃双发复制报文"。

根据上述验证，“双发复制报文"的情况对除开HTTP业务以外的情况都未造成影响，而因HTTP业务在互联网安全设备侧判断的特殊性，导致报文经过相同的GGSN网管后被认定成网络攻击行为，达到安全控制门限后被拦截，造成网络服务器与UE间交互的中断，表现为网页打开异常。

4.7 问题处理

问题出现属特例情况，目前现场所有RNC都已经处理恢复，处理办法并不复杂：一是通过RNC的维护台手动执行BFD功能的开启和关闭，该操作只影响若干秒内端口状态的可靠性检测，与业务无关，涉及命令为STPGATEWAYCHK/STRGATEWAYCHK；二是通过RNC的维护台手动执行闭塞、解闭塞1条光口的操作，同样可达到进行光口BFD状态再检测的效果，该操作会引起该光路进行中的业务包重发，由于是分担组网，不会引起业务中断。

4.8 测试验证

（1）用户感知评估测试主城区每个RNC选取5个点，每个点进行半小时的业务感知测试。规定点为公司综合楼、公司枢纽楼、公司2号楼、金科酒店、君豪酒店、机场航站楼、龙头寺火车站。

（2）测试结果

总的来看，重庆所有RNC下均能流畅打开网页，且下载速率正常，用户浏览网页感知提高明显。

5 问题总结

该问题由于涉及用户量等诸多因素，所以从问题现象去分析原因的话会出现相互矛盾的情况。对于本案例和此类问题总结经验如下。

（1）处理类似问题，了解网络组网情况非常重要，各个专业网元的配合协调工作非常重要。

(2)当遇到这种问题和原因相互矛盾的情况时，可以将所有的问题及导致该问题可能的原因全部列出，然后一一制定有效手段加以确认。通过不断确认和排除，找出根本原因，切不可将所有的问题和原因混在一起分析。

(3)掌握网络中每个网元的功能以及协议栈层级非常重要，会对问题快速定位有所帮助。

（4）对于此类用户感知问题的定位，掌握相应的业务流程非常必要，只有充分掌握业务流程才能在纷杂的现象中梳理分析定位问题的思路，同时也能抓住问题的根本。
(5)熟悉各网元的定位手段、方法和工具，对现场定位业务有很大的帮助。

上网, 提升