以下是基于iPhone App使用长短连接在不同网络情况下的真实业务测试结果:
Very Bad NetWork(类似与手机信号为E或者O的情况)
Edge(2.5G)
测试场景:
a.同一手机,同一用户。
b.用iOS 的developer 模拟不同Network link condition来做仿真测试。
c.短连接直接连接真实的淘宝开放平台和无线后台,长连接通过服务端代理间接访问淘宝开放平台和无线后台。
d.短连接数据压缩交给web容器处理(gzip),长连接代理服务器负责压缩(gzip)。
e.短连接数据报文为标准的http协议报文,长连接私有协议。
注意:
由于每一个业务请求也受到真实后台业务的影响,因此请垂直比较,横向比较没有意义。
结果图表:
结论:
REST模式在移动应用中受网络影响很大,数据包越大受影响越大(分包重传的情况)。(wifi高速网络下长连接没有任何优势,还会带来管理复杂性)
场外话:
客户端设计需要比较好的代码实现能力,否则可能得不偿失。(连接管理,并发管理,事件机制,缓存管理,客户端资源消耗控制)
当Tunnel无法运作的时候,自动采用REST短连接方式做业务处理。
在可识别网络情况的前提下,wifi自动采用REST短连接方式。
具体实现和设计以及测试过程中iOS这边的各种坑,后续慢慢放出。(千牛团队的Rainbow技术项目)