人間最美四月天，天氣晴好，暗香浮動!迎着春風，騎着共享單車，已成為京城的流動風景之一。筆者就是千千萬萬共享單車的愛好者與使用者之一，最多時，筆者手機中共享單車的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的使用将更普及，更快速!
本文轉自d1net（原創）