摘要：
native模組是攜程的核心業務模組（酒店、機票、火車票、攻略等），native模組的網路服務主要通過tcp連線實現，而非常見的restful http api那種http連線，只有少數輕量級服務使用http介面作為補充。
tcp連線網路服務模組使用了長連線+短連線機制，即有乙個長連線池保持一定數目長連線，用於減少每次服務額外的連線，服務完成後會將該連線socket放回長連線池，繼續保持連線狀態（一段時間空閒後會被**）；短連線作為補充，每次服務完成後便會主動關閉連線。
tcp網路服務的payload使用的是自定義的資料及序列化協議；http服務的payload比較簡單，即常見的json資料格式。
hybrid模組由於是在webview中展示本地或者直連的h5頁面，頁面邏輯發起的網路服務都是通過系統webview的http請求實現的。少量業務場景（需要加密和支付等）以hybrid橋接介面形式的native tcp通道來完成網路服務。
下圖是網路服務的部署架構圖：
要發現常見網路效能問題，先來看看乙個網路服務做了哪些事情：
常見的網路效能問題有如下幾種：
另乙個常見問題就是dns解析慢或者失敗，例如國內中國運營商網路的dns就很慢，一次dns查詢的耗時甚至都能趕上一次連線的耗時，尤其2g網路情況下，dns解析失敗是很常見的。因此如果直接使用dns，對於首次網路服務請求耗時和整體服務成功率都有非常大的影響。
dns成功後拿到ip，便可以發起tcp連線。http協議的網路層也是tcp連線，因此tcp連線的成功和耗時也成為網路效能的乙個因素。我們發現常見的問題有tcp埠被封（例如上海長寬對非http常見埠80、8080、443的封鎖），以及tcp連線超時時長問題。埠被封，直接導致無法連線；連線超時時長過短，在低速網路上可能總是無法連線成果；連線超時過長，又有可能導致使用者長時間等待，使用者體驗差。很多時候盡快失敗重新發起一次連線會很快，這也是流動網路頻寬不穩定情況下的乙個常見情況。
我們還遇到另一類問題，某些酒店wi-fi對使用非80、8080和443等常見http埠的服務進行了限制，即使傳送request是正常的，服務端能夠正常收到，但是response卻被酒店網路proxy或防火牆攔截，客戶端最終會等待讀取超時。
傳的多就傳的慢，如果沒做過特別優化，傳輸payload可能會比實際所需要的大很多，那麼對於整體網路服務耗時影響非常大。
國內運營商互聯和海外訪問國內頻寬低傳輸慢的問題也令人難非常頭疼。
wi-fi使用者佔比已超過60%，4g使用者量正接近3g使用者量，2g使用者在逐步減少，使用者的網路越來越好。4g/3g/2g網路的頻寬和延遲差別很大，而頻寬和延遲是網路效能的重要指標：
注意網路頻寬和延遲並沒有直接相關性，頻寬高不意味著延遲低，延遲再低也不可能快過光速。從上圖我們可以看到海內外頻寬相差很大，但是延遲基本一致。
針對上面這些問題，在網路複雜環境和國內運營商互通狀況無能為力的情況下，就針對性地逐一優化，以期達到目標：連得上、連得快、傳輸時間短。
server ip列表是有權重機制的，dns解析返回的ip很明顯具有最高的權重，每次從server ip列表中取ip會取權重最高的ip。列表中ip權重也是動態更新的，根據連線或者服務的成功失敗來動態調整，這樣即使dns解析失敗，使用者在使用一段時間後也會選取到適合的server ip。
針對網路連線和讀寫操作的超時時間，我們提出了網路質量檢測機制。目前做到的是根據使用者是在2g/3g/4g/wi-fi的網路環境來設定不同的超時引數，以及網路服務的併發數量。2g/3g/4g網路環境對併發tcp連線的數量是有限制的（2g網路下運營商經常只能允許單個host乙個tcp連線），因此網路服務重要引數能夠根據網路質量狀況來動態設定對效能和體驗都非常重要。
流動網路不穩定，如果一次網路服務失敗，就立刻反饋給使用者你失敗了，體驗並不友好。我們提供了網路服務重發機制，即當網路服務在連線失敗、寫request失敗、讀response失敗時自動重發服務；長連線失敗時就用短連線來做重發補償，短連線服務失敗時當然還是用短連線來補償。這種機制增加了使用者體驗到的服務成功概率。
當然不是所有網路服務都可以重發，例如當下訂單服務在讀取response失敗時，就不能重發，因為下單請求可能已經到達伺服器，此時重發服務可能會造成重複訂單，所以我們新增了重發服務開關，業務段可以自行控制是否需要。
我們優化了tcp服務payload資料的格式和序列化/反序列化演算法，從自定義格式轉換到了protocol buffer資料格式，效果非常明顯。序列化/反序列演算法也做了調整，如果大家使用json資料格式，選用乙個高效的反序列化演算法，針對真實業務資料進行測試，收益明顯。
資料格式優化的效果尤其明顯，採用新的protocol buffer資料格式+gzip壓縮後的payload大小降低了15%-45%。資料序列化耗時下降了80%-90%。
經歷了這半年的網路效能優化，體會最深的就是logging基礎設施的重要性。如果我們沒有完整端到端監控和統計的能力，效能優化只能是盲人摸象。logging基礎設施需要包括客戶端埋點採集、服務端t+0處理、後期分析、portal展示、自動告警等多種功能，這也不是單純的客戶端框架團隊可以完成的，而需要公司多個部門合作完成。
攜程基於elastic search開發了網路實時監控portal，能夠實時監控所有的網路服務，包括多種維度，可以跟蹤到單個目標使用者的所有網路請求資訊。
使用者的效能資料都被噴到haddop和hive大資料平台，我們可以輕鬆制定並分析網路效能kpi，例如服務成功率、服務耗時、連線成功率和連線耗時等，我們做到了在時間、網路型別、城市、長短連線、服務號等多緯度的分析。下圖是我們的網路效能kpi portal，可以檢視任一服務的成功率，服務耗時、作業系統、版本等各種資訊，對於某個服務的效能分析非常有用。
最後看看業界網路效能優化的新技術方向，目前最有潛力的是google推出的spdy和quic協議。
quic是基於udp實現的新網路協議，由於tcp協議實現已經內建在作業系統和路由器核心中，google無法直接改進tcp，因此基於無連線的udp協議來設計全新協議可以獲得很多好處。首先能夠大幅減少連線時間，quic可以在傳送資料前只需要0 rtt時間，而傳統tcp/tls連線至少需要1-3 rtt時間才能完成連線（即使採用fast-open tcp或tls snapshot）；其次可以解決tcp head-of-line blocking問題，通常前乙個tcp packet傳送成功前會擁塞後面的packet傳送，而quic可以避免這樣的問題；quic也有更好的流動網路環境下擁塞控制演算法；新的連線方式也大幅減少了connectiont migration問題的影響。
隨著這些新協議的逐漸成熟，相信未來能夠進一步提高移動端的網路服務效能，值得大家保持關注。
攜程App的網路效能優化實踐
native模組是攜程的核心業務模組 酒店 機票 火車票 攻略等 native模組的網路服務主要通過tcp連線實現，而非常見的restful http api那種http連線，只有少數輕量級服務使用http介面作為補充。tcp連線網路服務模組使用了長連線 短連線機制，即有乙個長連線池保持一定數目長連...
攜程App的網路效能優化實踐
收藏 native模組是攜程的核心業務模組 酒店 機票 火車票 攻略等 native模組的網路服務主要通過tcp連線實現，而非常見的restful http api那種http連線，只有少數輕量級服務使用http介面作為補充。tcp連線網路服務模組使用了長連線 短連線機制，即有乙個長連線池保持一定數...
攜程商旅酒店直連平台的實踐（一）
區別 服務都是分為了兩個模型，也就是乙個拉，乙個推。來作為模型。簡單來說，直連平台，就是將多個平台連線起來。並沒有什麼特殊的。乙個個專案堆下來總能解決的。但是從架構上，會逐漸臃腫，直到難以接受的程度，因為接入的直連雖然現在表現很好，但是隨著需求的演進，專案堆下來的方案，是肯定不能接受的。所以要建立平...