代理、VPN 高防服务器作为两种古老的数通网络安全解决方案，在当今移动互联网时代，伴随着游戏网络加速、WiFi安全性等用户硬性需求，再次焕发青春。

在数通网络中，VPN一般拓扑如下图一。需要测试VPN系统的网络性能，只需要使用背靠背网络（如图二），测试仪器从Client端发包，Server端收包，就可以轻松测算到系统带来的延时、丢包、网络的吞吐性能以及TCP新建、并发等性能指标。IETF组织的RFC2544和RFC3511也详尽的阐述了如何测算这些指标。而这些指标，也会成为设备供应商参与竞标必备的技术指标，采购方也会详细对比各厂商的设备性能，再决定采购谁的设备。

图一 数通网络VPN一般拓扑

图二 背靠背测试网络

同理，在移动APP测试范畴内，我们也需要进行可靠的竞品测试，验证自己产品提供的VPN、proxy服务，性能是否优于竞品。顺理成章，笔者首先想到的是，能否搭建一套类似于图二的背靠背网络来测试其网络性能？马上会出现两个问题：

笔者无法搭建测试环境的竞品Vpn Server Gate所知；竞品的实现方案也不为笔者所知；

在快节奏的互联网产品迭代中，也不允许如此复杂的测试环境搭建。

不管怎样，借鉴其思路，我们还是能够找到一个可行的的方案来获取可靠的竞品对比数据。

测试方法篇

延迟、带宽这类指标，都需要在大量样本上运用统计学进行分析才是有意义的。所以收集数据，是专项性能测试的第一步。

在简单的网络测试中，我们一般采用ICMP来进行网络延迟检测。笔者选用的方案并不是简单的ICMP，而是HTTP GET一个单数据包能够容纳的页面。而带宽测试，则是通过HTTP下载一个500M左右的文件，并记录每一秒收发数据量来获得带宽数据。

这样选择，主要有两方面原因。

一、从业务上说，Android的VpnService按应用导入流量，ping程序的ICMP包不会进VPN，导致测试数据错误；同时，TCP和UDP的流量更贴近用户场景的真实流量。

二、从测试方案上说，使用HTTP的接入成本更低。这样延迟、带宽等各种参数均可以使用同一个数据接口来实现。

延迟测试原理

相比于使用背靠背网络，可以测得数据单向传输所需的时延。在笔者的方案中，单位数据样本是计算测试APP发出HTTP GET请求，到收到 200 OK的响应所耗时长。如下图，这次延迟的数据，计算的是发出52号包，到收到59号包所耗用的时长222ms。

延迟测试HTTP GET数据的选择，笔者是选用的是。原则是尽量选择GET内容能够单个IP数据包能够返回的页面。

图三 延迟测试抓包

如果没有现成的好用的target，笔者推荐httpbin。它有点像一个蜜罐，时刻等待着你的光临，然后根据你的请求，给你返回你想要的东西。我们可以放心大胆的黑他，而不用担心他报复你。（官网| github）唯一的缺点是，这东西在美国，未加VPN之前的访问延迟和抖动就比较大。（要吐槽下，为什么免费的，好用的，技术性的东西，都在美国？）。图三的截图，就是 的结果。

延迟测试逻辑

在coding阶段，为了更低的代码成本。笔者选用了Retrofit，而不是自己去实现一大堆网络通信的东西。当然，作为一个深爱技术的测试，深入去理解下原理还是非常有必要的（Retrofit官网）。具体的Retrofit使用方法不详细介绍，有兴趣的同学可以详细了解官网或CSDN的例子。

如下代码中，需要注意下call.execute()的第一次执行，start的时间点是在TCP三次握手首包SYN之前，end是在收到HTTP 200 OK回应之后，所以首包的时延会比较长。尤其是在测试代理场景时，因为proxy先跟client建立tcp连接，再去跟server三次握手，然后才是数据转发。在选择样本时，可以选择过滤掉首次数据。但是，别忘了，首包时延值，其实也可以成为你衡量一个VPN系统或Proxy系统性能的关键指标。