以下是基于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技术项目）