人间最美四月天，天气晴好，暗香浮动!迎着春风，骑着共享单车，已成为京城的流动风景之一。笔者就是千千万万共享单车的爱好者与使用者之一，最多时，笔者手机中共享单车的APP多达五个，而现在只保留了两个。究其原因，除了使用车辆的便宜因素之外，另一个重要原因，是打开APP时运行速度慢，有时候着急出行，忍受不了APP缓慢带来的焦急感。

APP运行缓慢与人们需求断层

作为IT类媒体人士，笔者特别调研了一些数据，发现APP缓慢运行的现象较为普遍，并严重影响到人们的使用：

79%的移动APP用户在使用APP的第一次出现问题后，只会额外再尝试1到两次;

78%的移动APP用户期望着使用移动APP的速度会快于访问移动网站的速度;

61%的移动APP用户能接受最多4秒钟的load等待时间;

49%的移动APP用户期待APP能在两秒内给出响应。

APP运行缓慢的原因分析：移动最后一英里

笔者就是那种只能接受最多4秒钟的load等待时间，并期待APP能在两秒内给出响应的用户之一，尽管要求较高，但移动网络有自己的特征：比如容易出现连接频繁中断、传输失败与丢包等问题，这是相比较网络宽带出现的新问题。

实际上，无线网络传输给移动应用的速度和可靠性带来了新的挑战。有数据表明：“移动最后一英里”占移动应用总延迟(往返时间)的70%。最主要的表现是会话中断与移动延迟。

会话中断：间歇性移动连接是移动应用程序必须处理的事实。在会话期间中断要求应用程序重复操作，减慢对用户请求的响应速度。

移动延迟：由于必须通过蜂窝和WiFi网络到达公共互联网，移动应用程序不得不面对一个额外延迟层。由移动网络导致的额外往返使应用程序崩溃，进而无响应。

由于“移动网络最后一公里占据了整体时延的70%”，并且伴有大量的连接中断和数据包丢失。因此，会话阻断间歇性中断的移动网络状况这个事实是所有移动App都需要面对的并需要设法解决的。这样的中断问题体现在静态内容分发上表现为速度缓慢，体现在API 调用这类动态应用上则为失败。移动网络时延移动App不得不接受由于蜂窝网络、WiFi网络引入的额外的时延，以及由于切换移动网络基站带来的额外的Round Trip时间。

如何解决上述问题?这是笔者非常期望能解开的迷题。

解开移动应用加速的技术迷题

笔者近日在蓝汛(ChinaCache)与美国公司PacketZoom达成战略合作的一次媒体发布会上，采访到了PacketZoom首席执行官ShlomiGian先生，并得到了关于移动应用加速的答案。

上图为：PacketZoom首席执行官ShlomiGian

hlomiGian说：“PacketZoom解决移动应用加速问题的方法是：将软件开发包(SDK)嵌入到 APP 时会使用到PacketZoom提供的 App id 和API 密匙，当打开嵌入了PacketZoom软件开发包(SDK)的 APP 时，软件开发包(SDK) 会连接到分布在全球的 PacketZoom 服务器。在得到PacketZoom某一台服务器发送的确认之后，APP 中嵌入的 PacketZoom SDK 才会开始运行，与此同时软件开发包(SDK)开始代理并加速此 APP 的请求。“

而当 SDK 代理请求时，它会根据 PacketZoom 控制面板中客户设定的匹配规则(正则表达式)进行匹配，并将匹配条件的请求发送到 PacketZoom ，或根据设定的匹配规则的结果使用 APP 默认行为。PacketZoom接收到请求后，会将请求转发到离用户端最近的一台PacketZoom服务器上并从这里开始对客户的加速服务。于此同时，PacketZoom服务器会查看服务器本地是否有对应的缓存数据，如果没有则去客户源站获取到内容后返回给客户。Response 的数据将使用PacketZoom的协议被送到对应的客户端设备，不管数据是来自于服务器缓存还是源站。

PacketZoom 协议发送数据的速率由PacketZoom发送算法所决定。算法会根据网络类型，地点，终端设备类型等因素来决定发送多少数据及以哪种速率发送到客户端。在数据发送给客户终端的同时，SDK 会周期性发送确认信号，这些确认会用来优化发送速率，并通知服务器哪些数据包需要重传。服务器持续优化发送速率，以尽可能快地发送最多的数据，同时避免发送超过网络所能处理能力的数据量。

ShlomiGian强调：“在这些功能当中有些是 HTTP/TCP 已经内置的，但和PacketZoom 的存在明显的差异。比如， TCP 也会发送确认来通知服务器哪些数据包已收到。如果服务器已发送数据包 100-150，接收端没有确认收到包 110，TCP 会重新发送数据包 110-150。同样的情况，PacketZoom只会重传数据包 110，并在数据包 150 的位置继续传送数据。TCP 数据包没有优化 TCP 发送速率，它只是盲目发送数据，加倍传送速率直到有丢包发生。移动网络继承了这个特性，但反映出来的是移动网络的网络拥塞。”

移动应用加速在中国

据笔者了解，基于PacketZoom在移动应用加速方面的能力，中国专业的互联网内容传输整体解决方案提供商蓝汛ChinaCache近日与PacketZoom签署了独家合作协议。根据合作协议，蓝汛ChinaCache享有中国建立适用于移动设备的Packet Zoom Expresslanes™传输基础架构的专有权利，目的在于加速和提高中国移动应用内容传输的可靠性。

蓝汛ChinaCache与PacketZoom合作后，中国的客户也将享受到移动加速的便捷服务，并得到移动应用的极大优化：

移动吞吐效率优化：实现相对传统Web协议的更高效的传输机制。通过减少通信的往返交互次数实现。通过关注移动网络环境特有的参数，比如网络类型，连接时延，可用带宽，丢包率和信号强度来降低TCP的缓慢启动带来的性能降低。PacketZoom的服务器可以缓存静态内容，但对不可缓存的动态内容是工作在透明代理的模式。

智能内容缓存：PacketZoom的App层和服务器层的内容缓存技术，可以实现在向后端获取内容时减少对CDN或源站的往返交互的消耗。App层和PacketZoom服务器层的储存都可以由用户的工程师实现实时的管理和控制，比如缓存的大小和刷新状态因为我们只关注在移动网络环境的数据传输，所以PacketZoom是传统Web CDN的绝好补充，无额外的运营成本。

会话保障：PacketZoom 会话保障功能工作在移动设备到接入Internet的第一跳，更好的控制这之间的连通性以实现应用层会话的可用性。随着你的移动用户在相同运营商的网络中移动，甚至是在不同类型的网络之间移动(2G、3G、LTE或WiFi)，PacketZoom都可以做到数据传输顺畅的、持续进行。

全局网络的知识认知引擎：可以做到减少甚至消除TCP协议的慢启动、请求数据重连和重传次数 – 这些对于传统的Web协议是没法做到的。 通过使用PacketZoom的智能，移动App可以在任何类型的移动网络中最大化利用网络吞吐能力。使用平台收集到并共享的详细信息，移动App可以节省自主侦测周边网络状况的时间开销。

失效转发：PacketZoom的多播会话初始化进程可以针对某个时刻、任意一个手持终端设备自动找到对其来说最优、最快的服务器，择优接入。

采访小结

蓝汛ChinaCache与PacketZoom的独家合作，是将移动应用加速技术引入到中国的最快速的办法，对于蓝汛、PacketZoom或者是大量需要进行移动应用加速的企业而言，都是利好。当然，对笔者等最终用户而言，移动APP的使用将更普及，更快速!