网络抖动下移动应用性能测试仿真

何美玲 李佩雅

（1.浙江中医药大学信息技术中心 浙江省杭州市 310000 2.暨南大学网络空间安全学院 广东省广州市 510632）

1 引言

随着手机的普及和深度使用，移动应用的使用达到了空前的热度。移动应用的特点在于网络状态不稳定，网络模式不固定。移动终端随着用户发生地理位置变更，其网络模式相应发生切换、网络信号强弱发生变化，就是所谓的网络抖动。网络抖动会影响应用的使用体验，若应用研发过程中未做好高可用性保护容易导致应用出现弱网络条件下的慢响应、无响应设置崩溃。因此，研究网络抖动下的应用性能仿真测试具有深远意义。

2 研究依据及可行性

统计表明，全球超过70%的应用部署都是失败的，因为几乎所有应用的研发和质量保障都是在网络性能较好的局域网实验室完成的，技术人员重点关注的是上层应用实现，而忽略了下层数据连接。

利用技术手段尽可能对网络条件进行抖动模拟仿真，使其产生网络损伤，即生成较弱性能的网络条件，在低于或接近现实中弱网络模型的状态下进行移动应用的功能和性能校验确保其在现实生产环境中也能达到使用标准。

另外，网络抖动仿真的意义还可以对应用健壮性进行检验。在抖动网络条件下，应用的容错机制开启，应用终端和服务器的响应时间拉长，如研发人员会预设一些容错控制，类似加载等待UI 等。正是检验应用的高可用性的一种手段。

网络仿真模拟是否存在可行性，取决于网络性能的核心指标以及如何通过模拟变更这些指标数据来控制不同网络模式的强弱。网络的主要性能指标有带宽、时延和带宽时延积。三者关系如下公式：

带宽Band width：在一个固定的时间内（1 秒），网络中能通过的最大位数据。就像高速公路的车道一样，带宽越大，车道越多。即数据传输率。它的主要影响因素是网络设备。

时延Delay：一个数据包从用户的计算机发送到网站服务器，再从网站服务器返回用户计算机的来回时间。即数据从电脑这边传到那边所用的时间。时延包括发送时延、传播时延和处理时延。带宽是影响时延的其中一个因素，因带宽小会导致交换机和路由器等待。另外硬件性能如路由器跳数等也会影响时延。网络中各个传输和处理节点的延时都会增加总的网络时延。网络时延越高，网速越慢。通常使用PING(Packet Internet Grope)来测量网络延时。由于互联网络的复杂性、网络流量的动态变化和网络路由的动态选择，网络延时随时都在不停的变化(称为抖动)。网络延时和网络延时的抖动越小，网络的质量就越好。

带宽时延积Bandwidth-Delay Product：带宽乘以传播时延，即链路上的最大比特数。也就是信道中正在传输的数据总量。这个指标虽然是评测网络性能的指标，但其很大程度上依赖前两个指标，前两个指标在一定程度上足够反应，故此处不作考虑。

网络丢包率：丢包指源端在t 时刻发送分组P 到宿端，若宿端接收到该分组，则t 时刻从源端到宿端的丢包为0，否则为1。丢包率指在两台主机的交互过程中，宿端没有成功接收的分组占源端所发送分组总数的比例[1]。正常传输时网络丢包率应该控制在一定范围内。丢包率受带宽和时延的影响，带宽小或时延高造成数据包发送遇到阻碍，当达到处理不过来的情况该包就会被丢弃。该参数不是主要的评估依据，但能较直观地反应网络的整体性能。丢包率也可以用PING 来检测。

表1：不同类型网络损伤模拟工具

图1：NEWT 界面解析

图2：某网站使用WCDMA 限流前后响应对比

带宽、时延和丢包率是我们进行仿真测试首要考虑的三个参数，我们通过最优变更这些参数的方式来达到模拟不同网络状态的目的。从上面对几个参数的分析来看，最直接的方式是修改网络设备，比如传输介质，或者更换不同性能的路由器。然而这种方式成本过高，几乎不存在可行性，促成了我们对网络抖动模拟的以下探索[2-3]。

图3：Android APP 在不同网络模式下响应对比

图5：Edge 网络基准下不同延时下的响应对比

3 模拟方法和工具

目前已知的具备可行性的网络环境控制方式主要有两种。一种是使用网络损伤仪。这种方式需要购买设备，成本较高，对于有限的测试目标——比如单个应用的请求——投入产出比太高，一般作为备选。另一种是使用软件进行网络损伤配置。使用软件也分为两种情况，其一是应用层的代理软件，如Fiddler,提供编码接口供测试人员调用，直接对请求进行过滤、限流以及限速，但无法做到丢包，也没有真实网络的参考值可供参考。其二是作用在网卡层面的一类软件。这类软件不止一种，但原理类同。Windows 上可以使用Network Emulator for Windows Toolkit(NEWT)。这类软件可以做到对以上所说的参数进行随心所欲的配置，模拟不同的网速、延时、丢包等。另外，软件本身预置了2G、3G 等常用网络制式的参数配置。[4-5]

如表1 所示，显然是NEWT 更符合需求。NEWT 是通过监控相应的网卡，通过目标网卡提供的接口对以目标网卡为出口的请求按照各种过滤器规则进行过滤，从配置文件中读取配置，进行丢包、设置请求等待时间、限制带宽等操作。图1 是Network Emulator for Windows Toolkit 的操作界面。

NEWT 对带宽、时延已经丢包等参数的设置是通过配置文件来读取的，用户通过图形界面来设置实际上也会生成一份对应的配置文件。以下是不使用和使用WCDMA 这种配置时PING 某网站的响应对比情况如图2。

当然，我们可以自定义其他的参数配置，模拟抖动，NEWT 提供各个参数的各种变化模型，比如Gilbert 丢包模型，设置最好情况和最糟糕的情况等等。具体的配置情况需要测试人员对网络属性和原理有更加深刻的认识，高阶用法设置可以提供网络更底层的测试服务。

图4：Edge 网络基准下不同带宽下的响应对比

图6：Edge 网络基准不同丢包率下的响应对比

4 工程实践仿真

4.1 实验环境优化改造

4.1.1 Mock 服务使网络更单一纯粹

为了尽可能地减少服务请求需要耗费的路由转换和多个网络之间的访问隔离，我们使用mock 服务的方式将移动应用的后端服务架设再本地服务器上，排除了办公网和机房网络之间寻址的时间耗费和这部分网络耗时，使实验采集到的数据更单一。

4.1.2 脚本自动统计响应时间

由于人脑人眼存在思考等待时间且UI 返回有延时，数据不够精准，我们采用在每个接口调用处插入脚本统计接口请求到响应返回的耗时，并通过图表绘制展示。这种方式使采集数据更方便且精确。

4.1.3 循环多次采样

为了提高数据的可参考性，我们对每组数据采样超过30 次，这是平衡了实验成本和准确度的一个结果。并且采样数据必须排除因为设备卡顿等个例导致的偏离较大的值。

4.2 单因子试验

以Android 端应用为例介绍网络抖动下的性能测试仿真思路和解决方案[6]。通过标准为在正常网络条件下20s 内成功返回，在较差网络条件下无论请求成功与否，必须在60s 内作出超时返回。实验时我们通过单因子和多因子角度对接口响应做出评测，尝试找出临界值并给出测试建议。

表2：复合因子网络参数变化下的响应情况

图7：多因子网络参数变化下的响应情况

怎样的网络情况算是正常，苹果官方给出的参考值如下：

（1）3G（330kbit 的上行速率，780kbit 的下行速率，100ms的延迟和0%的丢包率）

（2）Edge（200kbit的上行速率，2400kbit的下行速率，400ms 的延迟和0%的丢包率）

（3）Wi-Fi（33000kbit 的上行速率，40000kbit 的下行速率，1ms 的延迟和0%的丢包率）

这样的网络状况下，以Android 端APP 为对象，分别进行多组测试后得出如图3 的结果（响应时间以毫秒记）。

可以看到这样的网络情况下几乎没有任何的性能问题，全部相应成功且几乎无等待。由于Edge 网络条件相对较苛刻，更具有参考意义，因此我们选取Edge 的正常值作为基准参考，进行单因子试验，绘制如图4。

图4 中可以看到将带宽限制到30kb/s 时请求仍然成功，但响应时间拉长，但当带宽调整到10kb/s 时，请求失败且等待时间达到60s。可见临界值在10-30kb/s 之间。单独做了一组20kb/s 的试验，发现大部分请求成功且响应时间达到将近50s。结论是：160kb/s 即20KB/s，算是Edge 网络正常情况，延时在2s 多可以接受，较差的情况下如30kb/s，请求仍然能响应但超时较为严重。

同样的，如图5 所示，在时延高达2000ms 时目标在15s 左右响应成功，5000ms 时请求失败且响应时间拉大到60s 且大部分请求失败。客户端认为在20s 内响应成功算是可接受，延时达到2000ms 仍然能响应可以接受，因此是符合生产标准的。

另外，如图6 所示，相对于前两个指标，实验表明丢包率显得不那么具有数值参考意义。采集到的数据跨度较大，原因是随机丢包导致部分请求响应较快部分较慢，响应时间似乎不那么具有参考意义。实验表明，在丢包率达到10%的情况下，请求成功率仍然在90%以上，当丢包率达到20%，请求成功率50%，我们认为其符合质量标准。

4.3 复合因子试验

单因子的质量评估已经给出，多因子的就更为复杂一些。表2是多组参数组合取值获得的采样表格。

我们选择多组数据实验并绘制图7。从图7 中可以看出，当参数维持在时延100ms、带宽100kb/s 和5%丢包（略差于2G 网络）时接口几乎无性能问题，保持无察觉延时请求成功。当网络时延加大，带宽进一步放低，丢包率提升，则请求的响应时间越来越长，但请求仍然能保持成功，用户体验越来越差。当时延达到1000ms以上且带宽为2G 较为糟糕的状况时请求开始大量失败，响应时间也进一步提高，达到一个峰值（小于60s）后再降下来，这之后的请求几乎是100%失败丢弃了。当然，我们的取值是从2G 网络较为正常的一个配置开始，4000ms 和20kb/s 的一个配置几乎是2G网络最为糟糕的参数配比，在该条件下，SDK 能在规定时间内做出响应我们认为其符合上线标准。

4.4 继续研究与展望

此研究仍处于初期阶段，需要挖掘和改进的点很多，如：

4.4.1 寻求更稳定的网络提供方式

网络抖动下移动端测试我们采用的是在PC 上模拟环境，让手机连接PC 虚拟出网络热点，达到同时限制手机网络的目的。由于PC 虚拟出的网络存在不稳定性，需要寻求一种更稳定的网络提供方式。

4.4.2 寻求服务的可视化

目前数据统计和分析门槛较高，想要获得更精确的响应数据需要通过脚本或变更源码来控制。服务可视化将使得数据统计更方便，且反馈方式更直接，缩小测试成本并提高测试体验。

5 总结

本文为测试移动应用在网络抖动下的性能表现进行网络仿真模拟，从网络基本性能的参数原理角度探讨，实验模拟弱网条件，对网络带宽、延时和丢包率参数采用单因子与符合因子变更比较法进行数据对比分析，是计算机应用网络仿真条件下的创新型研究方法。经过优化实验环境改善统计方法，使实验结果更具说服力，得出结论：实验用移动应用软件在网络仿真条件下的测试结论和生产环境匹配。但实验处于初级阶段，未来需要需求更稳定的仿真防落生成方式，并在数据分析角度做进一步探索，实现平台化的数据可视化方案。