[小学教育]9 - EVDO数据业务性能问题定位方法100425.pptVIP

Iperf UDP测试 目的：采用iperf UDP测试的目的是判断系统的物理层前向（或者反向）是否提供期望的带宽、丢包率、时延等指标。 原理：FTP使用TCP传送，影响TCP性能的因素很多，但人们首先会怀疑无线网线会不会存在瓶颈：比如带宽不够、时延大、丢包多。因此，有必要验证整条物理层特别是无线网线（MS到BSC之间）前向和反向的链路是否可以达到应有指标。 UDP报文是一种按照上层流量只发不管的报文，不保证报文是否到达对方，不管顺序如何，也不需要反方向确认，甚至于也不关心对端有没有程序收这些报文。拿它来测试单向链路的指标确实是个很好的选择。 Iperf使用方法与参数说明 -s 以server模式启动 -c host以client模式启动 -i sec 以秒为单位显示报告间隔 -u 使用udp协议 - n 指定传输的字节数(客户端专用) -b 指定带宽 * Iperf UDP测试 举例 AT侧起服务器端： iperf -u -s -i 1 服务器侧起客户端：iperf -c 6 -i 1 -u -b 800k -n 10m：每秒发送800kUDP数据包，共发送10M数据，每秒上报一次。 结果分析： iperf UDP测试出现带宽不够、丢包率较大，必然导致ftp性能不好。 iperf UDP 前反向测试正常说明整个系统包括网络侧特别是无线侧提供了足够的物理层性能指标，但并不能说明ftp下载就没有问题。 如果出现iperf UDP测试正常而ftp性能测试不好，请重点关注下页。 * Iperf UDP测试 * 结果分析： 手机侧笔记本注册表中TCP参数配置 服务器性能 网络侧拓扑带来的问题：比如时延等 PDSN问题 其他…… Tcptrace和xplot 下载地址： 使用方法：命令行方式 部分选项： tcptrace -l XXXX： 基本信息显示 tcptrace -lr XXXX：统计RTT tcptrace -lW XXXX：统计owin（模拟cwnd） -T ：吞吐量图形，生成X.xpl文件，由xplot或jplot查看。 -R：生成RTT图形 -N：生成owin图形 * 使用tcptrace分析实例 问题：在印尼试验局，反映下载数据速率低，在DRC稳定2.4Mbps条件下进行TCP下载，对TCP服务器抓包数据进行TCPTRACE分析后，得到如下分析数据： * 使用tcptrace分析实例 和正常分析数据进行比较： * 我们发现： 平均接收通告窗口rwnd均在64000bytes以上 平均owin值存在巨大差异 使用tcptrace分析实例 我们发现： 平均RTT反而比正常的平均RTT小平 从发送分片大小对比，其小于正常值，发送效率更差一些，可以优化接收侧的MTU配置 分析： 平均RTT反而比正常的平均RTT小的原因，是因为TCP发送流量不足，减少了数据在缓存的时间。 owin值不足，有可能是TCP服务器本身的原因 ；或者TCP参数配置的原因 ；也有可能是频繁丢包导致。 从统计看，3次重复确认的情况发生了11次，是否是这11次丢包情况导致了owin偏低，我们需要通过owin全程变化曲线进一步确认： * 使用tcptrace分析实例 分析： 其owin曲线和正常owin曲线对比： * 使用tcptrace分析实例 分析： 根据owin曲线，用ethereal打开抓包报文后，查找每次owin下降的时间点附近，均存在2次重复确认导致的快速重传和恢复，说明的确是周期性链路丢包导致了TCP性能低下。 该问题在更换FTP服务器相连的交换机后解决，可能还是网口模式不匹配导致了P-I口丢包。 * * * * * * 三个时间值代表：到达中续主机的往返时间，为了便于统计，显示三个。 * PPPSniffer可以很方便地用来分析RP口是否存在丢包，如上图显示的，蓝色为前向包，绿色为反向包，红色为序号不连续包，从上图看，序号229~232之间的前向包丢失了，而序号为233，234，235的包乱序了，同时序号为235~240之间的前向包也丢失了。 * 常用工具：Ethereal或者WireShark 免费的网络协议分析工具，差不多就是一个东西。两者的关系简单一说（网上自己搜一下便知）：NIS公司Ethereal核心程序员Gerald Coombs离开了该公司, 加入CaceTech公司。 NIS公司不放弃Ethereal商标，故改名为Wireshark。 下载地址： Ethereal：/ WireShark：/ 安装起来，很简单，而且不用重启机器。 * 用于在网卡级别过滤报文。比如只想抓tcp的报文： 则在该区域键入：tcp 想在RP口抓GRE（IP报文，协议为0x2f）报文咋办： GRE就是IP报文协议字段（第10