CDMAPOII0708 EVDO RevA专题之数据业务性能分析教材.docx
《CDMAPOII0708 EVDO RevA专题之数据业务性能分析教材.docx》由会员分享，可在线阅读，更多相关《CDMAPOII0708 EVDO RevA专题之数据业务性能分析教材.docx（28页珍藏版）》请在冰豆网上搜索。
CDMAPOII0708EVDORevA专题之数据业务性能分析教材
EVDORevA专题之数据业务性能分析教材
目录
第1章数据业务吞吐量低分析1
1.1数据业务基本原理1
1.1.1数据业务网络结构1
1.1.2数据封装基础2
1.1.3TCP/IP关键算法5
1.1.4无线分组和TCP关系7
1.2数据业务吞吐量低的分析方法8
1.2.1检查设置参数8
1.2.2物理带宽和FTP传输能力的检查12
1.2.3无线环境的检查14
1.2.4数据抓包及分析14
1.3总结28
第一章数据业务吞吐量低分析
知识点
数据业务基本知识
数据业务优化分析方法
数据业务分析中使用的工具
本章首先对数据业务进行概略性介绍，然后介绍了数据业务吞吐量低分析优化思路，根据分析优化思路，使用一些工具进行数据分析，以及数据业务一些简单问题的分析处理。
一.1数据业务基本原理
一.1.1数据业务网络结构
数据业务网络结构组网图如下图所示：
图1.11数据业务网络结构组网图
数据业务网络组网图中，我们一般称呼PCF到PDSN之间的接口为RP接口，其数据包的格式为GRE包，而PDSN到公共网络的接口我们称之为Pi接口，其数据包格式为IP包。
值得注意的是，在EVDORevA网络中，不再存在MSC实体，鉴权和加密等功能由AAA服务器负责。
数据业务网络协议栈结构如下图所示：
图1.12数据业务网络协议栈
在接入终端到BTS之间的通讯使用的是空中链路的协议，而在BTS到BSC和PCF之间的通讯使用的是Abist接口，PCF到PDSN之间的通讯使用RP接口完成。
一.1.2数据封装基础
在数据业务之中，主要的数据包封装格式有：
IP数据封装，TCP数据封装，RP接口使用的GRE数据封装，PPP数据封装等。
IP数据包首部的数据格式如下所示：
图1.13IP数据包首部格式
IP是TCP/IP协议族中最为核心的协议。
它提供一种提供不可靠、无连接的数据报传送服务。
不可靠指的是它不保证IP数据报能成功的到达目的地。
无连接指的是它并不维护任何关于后续数据报的状态信息。
每个数据报的处理是相互独立的。
也就是说，IP数据报可以不按发送顺序接收
TCP数据包首部的数据格式如下所示：
图1.14TCP数据包首部格式
TCP提供了一种可靠的面向连接的字节流运输层服务。
每个TCP数据包首部都包含源端和目的端的端口号，用于寻找发端和收端的应用进程。
再加上IP首部中的的源IP地址和目的IP地址，就可以唯一确定一个TCP连接。
TCP首部中的32位序号用于标识每个发送的数据包。
32位的确认序号表示发送确认的一端所期望收到的下一个数据包的序号，所以确认序号应当是上次已成功收到数据字节序号加1。
通过32位的序号和数据包的大小，可以计算出下一个数据包的序号，然后和接收到的确认序号相比较，可以轻易的判断出数据包是否丢失。
GRE指的是通用路由封装（GenericRoutingEncapsulation），它定义了在任意一种网络层协议上封装任意一个其它网络层协议的协议。
在大多数常规情况下，系统拥有一个有效载荷（或负载）包，需要将它封装并发送至某个目的地。
首先将有效载荷封装在一个GRE包中，然后将此GRE包封装在其它某协议中并进行转发。
GRE封装格式如下所示：
图1.15GRE数据包封装格式
其中：
C：
当前校验和
ProtocolType：
包括有效载荷数据包的协议类型
Checksum：
包括GRE头和有效载荷数据包中所有16位字的IP校验和总数。
PPP为点对点协议（Point-to-PointProtocol），它为在点对点连接上传输多协议数据包提供了一个标准方法。
PPP协议与OSI协议栈的对应关系如下图所示：
图1.16PPP协议与OSI协议栈对应关系图
封装格式如下所示：
图1.17PPP封装格式
一.1.3TCP/IP关键算法
慢启动和拥塞避免算法用于控制网络的拥塞。
其算法过程如下：
1、对于一个给定连接，初始化cwnd（发送拥塞窗口）为1个报文段（MSS），ssthresh（慢启动门限）为65535字节。
2、TCP一次数据发送的最大窗口不能超过cwnd和rwnd的最小值。
3、当cwnd小于等于ssthresh，认为TCP连接处于慢启动过程，否则认为TCP连接处于拥塞避免过程。
4、在慢启动过程，每收到对一个新的outgoing报文段的确认，cwnd增加一个报文段大小，这个增加过程一直持续到cwnd大于ssthresh，然后TCP转入拥塞避免过程。
5、拥塞避免过程，每收到对一个新的outgoing报文段的确认，cwnd增加1/cwnd个报文段。
6、当拥塞发生时（超时或收到重复确认），ssthresh被设置为当前工作窗口的一半（cwnd和rwnd（接收通告窗口）的最小值的一半，但至少为2个报文段），如果是超时引起了拥塞，则设置cwnd为1个报文段（缺省设置），这就是所谓的慢启动；如果是重复确认，则采用后面将描述的快速重传和快速恢复算法。
从拥塞控制过程可以看出，所谓的慢启动，是指初始的cwnd设置为一个很小的数值，使得分组进入网络的速率产生很大下降。
根据以上算法，我们可以画出在慢启动和拥塞避免过程中发送窗口的变化曲线：
图1.18在慢启动和拥塞避免过程中发送窗口的变化
快速启动和快速恢复算法，对拥塞避免算法的改进建议，在网络中分组偶尔丢失的情况不希望急剧减小分组进入网络的速率，即不执行慢启动，而采用快速重传和快速恢复。
快速重传和快速恢复算法如下：
1、当收到重复确认（缺省是3次重复确认）导致拥塞，ssthresh被设置为当前工作窗口的一半，但是和慢启动不同，cwnd不是设置为1，而是设置为ssthresh加上3倍报文段大小（3倍报文段大小是由于3个重复确认导致的，在快速重传算法中，每个重复确认将使得cwnd增加一个报文段，因为出现重复确认表示有新的数据报文段到达接收方，说明收发双方仍然有数据交互，出现重复确认只是报文段出现了个别丢失，所以不希望执行慢启动来急剧减小数据进入网络的速率）
2、每收到一个重复确认，cwnd增加一个报文段大小，并根据cwnd情况发送分组。
注意：
这里cwnd的增加算法不同于前面慢启动和拥塞避免过程的算法。
3、当下一个确认新数据的ACK到达后，说明接收方已经收到重传数据，这时进入正常的拥塞避免过程，设置cwnd为ssthresh，按照拥塞避免过程的算法来增加cwnd取值。
根据以上算法，我们可以画出在快速启动和快速恢复过程中发送窗口的变化曲线：
图1.19在快速启动和快速恢复过程中发送窗口的变化
RTT和RTO是网络判断超时与否的根据，RTT和RTO的算法如下所示：
是判断快速启动和快速恢复算法，对拥塞避免算法的改进建议，在网络中分组偶尔丢失的情况不希望急剧减小分组进入网络的速率，即不执行慢启动，而采用快速重传和快速恢复。
快速重传和快速恢复算法如下：
1、Err=M-RTT，Err表示当前RTT测量偏差，M表示当前测量的RTT，RTT表示平滑滤波的值。
2、RTT=RTT+g*Err,即RTT=（1-g）*RTT+g*M，g和上面的a类似，是RTT平滑因子，g的推荐值是1/8（0.125）。
3、D=D+h*（|Err|-D），即D=（1-h）*D+h*|Err|,h是RTT测量偏差的平滑因子，D表示平滑滤波的RTT偏差，h的推荐值是1/4（0.25）。
4、RTO=RTT+4*D，RTO是超时重传定时器的值。
5、RTT的初始值缺省是0s，D的初始值是3s，RTO的初始值使用RTO=RTT+2*D计算，即RTO=6s。
一.1.4无线分组和TCP关系
相对于有限网络，无线网络的链路具有不一样的特性，主要有：
1、误帧率高（RLP校正后的误帧率），约1%左右，远大于有线网络。
2、前反向带宽不对等。
3、带宽可变。
4、时延变化大。
在无线环境高误帧率的影响下，RTO就很可能超时，TCP则认为网络发生拥塞，而不必要地减小吞吐量。
在带宽摆动的影响下，带宽的变化直接导致相应的RTT波动，因为RTO对RTT变化不敏感，网络延时突然加大时，工作在较短估值上的RTO就很可能超时，导致TCP吞吐量锐减。
在带宽不对等的影响下，会引起反向ACK的延时，这将会导致吞吐量的下降。
一.2数据业务吞吐量低的分析方法
数据业务吞吐量低，指的是在网络链路畅通的情况下，数据业务吞吐量低于正常水平。
数据业务吞吐量低，具体原因各不相同，可分为终端原因（如串口速率限制，参数设置不合理等）、无线侧原因（如无线环境恶劣，BTS和BSC时钟不一致，内部丢包等）和网络侧原因（RP口乱序或丢包，PI口丢包等）。
对于数据业务吞吐量低等这类问题，一般可采用分段排查的方法，分别在网络的各个节点查找问题所在。
具体措施有：
1、检查各个节点的物理带宽是否足够。
2、终端和FTP服务器的参数设置。
3、检查无线环境的情况。
4、抓取各个节点的数据包，分析各个节点的丢包率，乱序率，吞吐量，时延等，定位分析问题。
下面，我们结合所使用的工具，具体说明数据业务吞吐量低的分析方法。
一.2.1检查设置参数
TCP参数的设置正确与否，是数据业务吞吐量是否正常的一个重要方面。
所以我们在遇到数据业务吞吐量低的情况时，有必要检查一下TCP参数是否设置正确，包括终端则和FTP服务器等。
与数据业务吞吐量相关的TCP参数如下表所示：
图1.21TCP相关参数表
上表中的参数可以在注册表中找到，在windows系统中，进入注册表的方法为：
进入开始菜单->运行，输入regedit就可以打开注册表。
在注册表中，可以在以下位置找到相关参数：
HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\Interfaces，其中interfaces目录下有可能有好几个选项，对应这网卡，无线网卡，串口等物理接口，需要找到用于传送数据的对应端口（可以根据对应选项下的IPAddress参数标示的IP地址和物理端口的IP地址是否一致来判断）。
找到数据传送端口对应的选项之后，在选项的里面可以找到对应的TCP参数，如果在选项里面没有找到对应的TCP参数，可以手动添加该参数（注意：
由于修改注册表具有一定的风险，建议修改之前首先备份注册表），手动添加参数的方法如下：
图1.22在注册表中添加新的参数
如上图所示，在注册表中数据传送端口对应的选项下，点击右键->新建，选择新建参数对应字节大小选项，然后输入表9.2-1中对应项的名字。
然后选中该新添加的参数，右键选择修改选项，修改新添加参数的值，如下图所示：
图1.23在注册表中修改参数的值
TCP参数中另外一个影响吞吐量的参数是TCP头压缩。
在无线网络中，TCP头压缩应该去掉，检查方法为：
开始菜单->网络连接->拨号->属性->网络->Internet协议（TCP/IP）->属性->高级->使用IP标头压缩，检查TCP头压缩的步骤如下列图所示：
图1.24打开拨号连接的属性
图1.25打开拨号连接的高级选项
图1.26IP标头压缩选项
上图中的使用IP标头压缩选项需要去掉。
BSC中的RLP重传参数也可以影响数据业务的吞吐量，该参数的默认设置为：
{1,2,3}，推荐修改为：
{1,4,7}，该参数的位置在BSC的RLP参数表中。
由于RLP参数是BSC参数，修改该参数具有一定的风险，建议修改之前充分咨询和了解。
一.2.2物理带宽和FTP传输能力的检查
在实际网络中，往往由于物理链路的限制或者是FTP下载服务器软件某些参数的设置不当导致的链路带宽不够，从而导致吞吐量低的问题。
我们可以使用IPERF软件来检查链路的带宽或者是FTP服务器传输能力。
Iperf是个网络测试工具，提供了多种测试网络性能的功能。
其中的UDP测试功能可以测试单向的链路指标。
UDP报文是一种按照上层流量只发不管的报文，不保证报文是否到达对方，不管顺序如何，也不需要反方向确认，甚至于也不关心对端有没有程序收这些报文。
拿它来测试单向链路的指标确实是个很好的选择。
使用Iperf是，需要在网络的一端以服务器的方式启动Iperf，在网络的另一端以客户端的方式启动Iperf，然后从客户端往服务器端灌UDP数据包，测试网络两端的物理链路性能。
Iperf使用方法与部分参数说明如下：
-s以server模式启动
-chost以client模式启动
-isec以秒为单位显示报告间隔
-u使用udp协议
-n指定传输的字节数（客户端专用）
-b指定带宽
Iperf使用的一个简单例子如下：
在网路的一端以服务器的方式打开Iperf软件：
进入windows命令界面，然后进入Iperf软件所在文件夹，输入如下图所示的的命令，以服务器的方式启动Iperf，并且每1秒上报一次数据：
图1.27以服务器方式启动Iperf
在网路的另一端以客户端的方式打开Iperf软件：
进入windows命令界面，然后进入Iperf软件所在文件夹，输入如下图所示的的命令，以客户端的方式启动Iperf，每秒发送800kUDP数据包，共发送10M数据，每秒上报一次：
图1.28以客户端方式启动Iperf
命令中的202.101.10.16是iperf服务器端的ip地址。
从测试的结果，我们可以看出该网络是能够满足800k带宽要求。
一.2.3无线环境的检查
无线环境的检查一般使用我司软件CNT’和CAN，CNT软件负责数据的收集，CAN负责数据的分析功能。
具体使用方法请参考相关文档。
一.2.4数据抓包及分析
使用的主要抓包工具有PPPSniffer和WireShanrk，主要的抓包数据分析工具有SnifferHelp和tcptrace及其补助工具jplot等。
利用PPPSniffer可以抓取PCF上的GRE数据包，可以分析RP接口的丢包率，乱序率等性能。
PPPSniffer软件工作原理：
运行在PC机上的PPPSniffer软件，通过OMP向SPCF单板上的SPCF进程发消息，指定拦截某个用户（用IMSI标识）的GRE包，SPCF根据IMSI查找到对应的GREKey，然后发消息给UPCF，拦截指定GREKey的GRE包。
UPCF在转发Key值匹配的GRE包的同时，复制一份通过OMP转发给后台。
PPPSniffer则从GRE包中解析出PPP包，并显示在图形界面上。
其原理如下图所示：
图1.29PPPSniffer工作原理
PPPSniffer的使用方法：
打开PPPSniffer工组界面：
图1.210PPPSniffer工作界面
进入configure菜单，设置OMP的IP地址：
图1.211设置OMP的IP地址
进入filter菜单，设置终端IMSI：
图1.212设置终端IMSI
进入capture菜单，选择Log选项保存数据，点击Start菜单开始抓包：
图1.213保存数据并开始抓包
查看GRE数据包：
图1.214查看GRE数据包
在GRE数据包界面，可以查看数据包属于前向还是反向，可以查看每个数据包的大小，可以查看数据包的序号，因为发送的GRE数据包的序号是连续的，所以根据抓取的GRE数据包的序号是否连续可以判断是否有丢包发生。
如上图中红色数据包和前一个数据包序号不连续，有丢包现象发生。
从这些基本信息中我们可以大致判断出网络是否存在问题，问题是在PCFRP接口之前或之后。
查看PPP数据包：
图1.215查看PPP数据包
从PPP数据包界面可以查看数据包分原始码流，在对照协议我们可以理解每个数据包头部包含的信息。
WireShark是网上的免费抓包工具。
WireShark工具可以抓取任意进入端口的数据包。
它可以显示数据包是否丢失，是否出错，它还可以显示数据包的原始码流。
WireShark软件界面和抓包接口如下图所示：
图1.216WireShark软件界面
如上图所示，点击WireShark软件界面左上角图标，进入网络端口界面，在网络端口界面上显示几个可用的网络端口，点击使用的网络端口相对应的Options选项，进入上的抓包参数设置界面，如下图所示：
图1.217WireShark抓包参数设置界面
在该抓包参数设置界面上，可以输入筛选条件，只抓取满足特定条件的数据包，可以设置保存文件的方式，也可以设置数据显示的方式等。
设置完抓包条件之后，点击Start菜单，开始抓包，抓包过程中的显示界面如下所示：
图1.218WireShark数据包显示界面
在该界面上，详细显示每个数据包的信息，包括：
序号，时间，源和目的地址，协议类型，数据包解析信息等。
它还显示数据包之间是否有丢失等信息。
WireShark可以包每个数据包用流图的形式显示出来，如下图所示：
图1.219WireShark数据包流图显示界面
针对无线网络数据业务吞吐量低的分析，一般进行网络侧数据采集，RP口抓包（HUB抓包，Switch抓包），PI口抓包等。
网络侧数据采集：
网络侧指PCF以外的IP网络，其中PCF到PDSN之间的叫RP链路（也叫RP口），PDSN以外叫PI口，中间用Switch、路由器来汇接，路由器数量越多，网络也越复杂。
目前对网络侧问题的排查，WireShark抓包是比较常用的方法。
RP口抓包方法：
RP口抓包和普通的有线网络抓包原理是一样的，有两种方式，HUB抓包和Switch抓包。
HUB抓包：
HUB的工作原理非常简单，就是把从任何一个端口收到的数据向其他端口进行广播，利用这个原理，我们可以接一台PC机到HUB上，然后把IPCF的出网口也连接到同一个HUB上，不用做其他配置，启动Ethereal软件，直接就可以抓包了。
Switch抓包：
Switch抓包要复杂一些，Switch属于层二交换，不会对某一个端口的包对所有端口都进行广播。
这就要利用switch的端口镜象功能（并不是所有switch都提供端口镜像功能）。
RP口上的单用户抓包：
对于RP口上的单用户抓包，则需要设置过虑条件，因为RP口上包采用的是GRE封装格式，因此需要用用户的GREKey即可过虑出单用户的包。
GREKey可以从OMC后台的信令跟踪中的A11RegRequest中读取：
图1.220查找GREKey
如上图所示，该用户的GREKey=0x81002ccb。
之后，可以设置过滤条件，只抓取该用户的数据包：
在CaptureFilter中输入”ether[38:
4]==0x81002ccb”即可，其含义是监听从Ether格式的包第38Bytes开始的连续4个字节（正好是GRE包头中的GREKey字段），且等于0x81002ccb。
如下图所示：
图1.221单用户数据包抓取过滤条件设置
对某些问题，如果排查到空口和RP口都没有丢包，此时需要进一步排查PDSN外侧丢包情况，这时我们需要在PDSN的PI口（即PDSN和Internet相连的端口）进行抓包。
PI口抓包和RP口抓包是一样的，也有HUB抓包和Switch抓包两种，这里不再赘述。
唯一不同的是RP口的封包是GRE格式，而PI口封包就是普通的IP格式。
从以上看出，PPPSniffer工具和WireShark抓包工具大多只有数据采集功能和少量的分析功能，对于数据业务吞吐量低的问题分析并不直观和易于理解。
所以我们需要一些补助工具来进行数据分析，而SnifferHelp和tcptrace就是比较常用的工具。
SnifferHelp是我司自己开发的一个小工具，其开发的目的之一是把PPPSniffer软件抓取的数据格式转换成通用的Pcap格式，另一个目的是辅助Wireshark数据的分析，加快数据业务问题的定位速度。
很多时候，在解决数据业务业务性能问题的时候，很多时候需要查看和统计各段数据包的丢包程度。
Wireshark功能强大，但是做起这些简单的分析却很繁琐。
当出现性能问题的时候，需要经过繁杂的分析，往往错过了问题定位的最佳时期。
SnifferHelp工具具有一下功能：
1、PPPSniffer抓取的数据转换成Pcap格式。
2、对RP口所抓的Gre报文进行Gre丢包和乱序统计。
3、Tcp丢包统计：
只统计TCP丢失报文，通常用在RP口抓包的分析，此时发现的丢包，一般为RP或者PI链路的丢包。
4、网络前后节点同时抓取的数据IP包丢包对比。
进行数据格式转换：
进入file菜单项，选择Convertfile，在弹出的界面上选择PPPSnifferConverttoPcap，单机OK按钮即可，如下图所示：
图1.222数据格式转换
对RP口所抓的Gre报文进行Gre丢包和乱序统计：
打开数据文件，选择OpenasGre，如下图所示：
图1.223打开Gre数据文件
文件打开之后如下图所示：
图1.224进行Gre乱序率统计
在打开的文件上，右键选择Static进行乱序率统计，结果如图所示：
图1.225Gre丢包率统计结果
还可以查看每个连接上的Gre数据包详细信息：
图1.226查看Gre详细信息
Tcp丢包统计，其步骤和过程于Gre数据包统计基本类似在此不再详述。
一个数据包在网络上传输过程中，其数据包的IPIdentify是不会变的，我们可以利用这一点，在网络上的不同节点进行抓包，然后比较不同节点数据包的IPIdentify，如果在数据包发送的前一节点存在某个IPIdentify，而在后一个节点该IPIdentify不存在，则我们可以断定该数据包在这两个节点之间的某一处丢失了，如果大量数据包在这两个节点之间丢失，则我们可以断定这两个节点之间的链路存在问题，从而定位问题。
SnifferHelp提供该功能。
首先，先后打开在不同节点同时抓取的数据文件，然后把靠近发送端的文件右键选择排左边，把靠近接收端的文件右键选择排右边，如下图所示：
图1.227前后节点IP数据包比较
选择完之后，点击file->Ipcompare菜单项，进行IP丢包比较，其结果如下图所示：
图1.228前后节点IP数据包比较结果
如上图所示，标注数据包在前一个节点（靠近发送端）没有丢失，在后一节点（靠近接收端）丢失了，说明很可能数据包在这两个节点之间丢失了，从而导致数据业务吞吐量降低。
去除报文中的Gre信息并作PPP组包，如下图所示：
进行数据格式转换：
进入file菜单项，选择Convertfile，在弹出的界面上选择PPPSnifferConverttoPcap，单机OK按钮即可，如下图所示：
抓包之后的数据分析，另一个强大的工具是tcptrace及其补助工具jplot。
该工具可以直接统计吞吐量的大小，可以统计RTT，可以用owin估算发送端发送窗口cwnd。
通过这些数据的分析，我们可以判断出数据业务吞吐量低的原因。
Tcptrace是以命令行的方式运行的。
其部分命令如下：
1、tcptrace-lXXXX：
基本信息显示
2、tcptrace-lrXXXX：
统计RTT
3、tcptrace-lWXXXX：
统计owin（模拟cwnd）
4、-T：
吞吐量图形，生成X.xpl文件，由x
升级会员 