作者：凝睇，螞蟻金服移動開發平臺 mPaaS 技術專家。目前負責螞蟻金服移動開發平臺 mPaaS 服務端元件體系優化與架構設計。 內容採編自 CodeDay#1 杭州站現場分享，主題是《弱網優化在支付寶的深度實踐》。
0. 背景
隨著 PC 端場景越來越重，其發展已日趨飽和，而隨著智慧移動裝置的興起，移動網際網路呈現出了井噴式發展形態。相比於 PC 網際網路時代的有線網路，無線網路通訊的穩定性卻有著巨大的差別；因此，開發者總會面對使用者反饋諸如 App “不通”、“不快”等各種“網路問題”。
作為國民級 App，支付寶需要服務在各種複雜的行動網路環境下的億級使用者，因而在網路優化的道路上也是一走就很多年，本文的目的即是將我們遇到的問題做一個總結，並把在一些實際可行的優化和實踐經驗分享給各位開發者，期望能從某個角度能給各開發者提供一些靈感以幫助大家建設更好的移動 App。
問題歸總
網路問題，從使用者反饋過來的表象可分為“不通”或者“不快”，這兩詞雖然只有一字之差，但本質卻完全不同：
- “不通”，一般為服務可用性的問題，比如：由伺服器當機引起的“網路異常”、“操作無響應”、“白屏”或者“完全收不到訊息”等問題；
- “不快”，則一般為真實的效能問題，比如：“轉菊花”、“操作響應慢”、“訊息接受慢”等。
對於“不通”的問題，主要原因為客戶端真實網路確實不可用或者服務端系統穩定性不足導致，從優化的角度，更偏向於優化服務端架構設計或者從互動角度讓客戶端在異常情況如何更友好的呈現給使用者，而對於“不快”的問題，我們則可從技術上做更多的優化和改進，因而也是本文的重點。
問題來源
首先我們來看一下行動網路的鏈路：
- 移動端通過無線網路協議，從運營商的基站獲得無線鏈路分配用以滿足跟網路進行通訊；
- 運營商的網路基站、控制器，給移動終端進行訊號的分配以完成與終端的連線和互動；
- 獲得無線鏈路後，會進行網路附著、加密、鑑權，核心網路則會檢查終端是否可以連線在這個網路上，是否有開通套餐，是不是處於漫遊等。目前核心網路有 SGSN 和 GGSN，這一步主要目的是完成無線網路協議和有線乙太網的協議的轉換；
- SGSN 和 GGSN 核心網路會根據終端的情況進行 APN 的選擇、IP 分配、並啟動計費；
- 之後才是我們所接觸的傳統網路的步驟：DNS 查詢、響應，TCP 連結，HTTP GET 請求，RTTP RESPONSE 200，HTTP RESPONSE DATA，LAST HTTP RESPONSE DATA 和 UI 展現等等。
由此可見，行動網路本身鏈路上就相較有線網路複雜很多，同時終端因為其強烈的“移動”屬性，在很多場景下網路情況確實不如人意，比如在地下室、電梯、偏遠地區等等，總會帶來頻寬不足、頻繁丟包、高延遲的問題。與此同時，在進入後端伺服器應用網路之後還有一層層的防火牆、路由器、負載均衡、IDC 分機房部署。 再到客戶端應用程式、服務端的系統設計、介面設計等問題也會極大的影響到在弱網環境下使用者的體驗，如：
- 客戶端啟動時各種併發 RPC 請求導致網路或者執行緒擁塞
- 服務端流程設計冗長，慢 SQL 等；
- RPC 介面模型設計沉重，請求或相應模型大量冗餘資料；
- 靜態未壓縮，或者未分網路環境，不分使用者使用場景進行資源拉取導致首屏堵塞，遲遲未響應等。
除此之外，傳統網路協議在流程設計上限定，如果移動 App 自身沒有進行改良和優化，在弱網環境下也可能會成為絆腳石。
如：
- TCP 傳輸過程中為防止過多的資料注入到網路中，會先探測一下網路的擁塞程度，會有由小到大逐漸增加擁塞視窗的大小；
- 在絕大部分 App 中，均需要進行SSL鏈路加密，因此需要耗費 2 個 RTT 來做證照的交換；
- 除此之外，不同運營商、在不同地區對於 DNS 域名解析的支援能力也有所不同，絕大部分需要 1 秒以上，在某些情況下甚至可能超過7秒，並且此處也需要消耗 1 個 RTT。
- 通過分析上面的幾個可能產生問題的根源，我們基本就可以知道在網路鏈路上、客戶端&服務端流程設計上、以及網路協議上本都做一些事情來達到優化的效果。
1. 優化指標
做優化一定需要有可量化的指標來衡量和記錄我們的勞動成果和效果，因此，可以主要從以下幾個指標入手：
- 建連成功率：可通過客戶端端埋點的手段進行開展，並通過MAS的資料採集和資料分析等功能來記錄、統計、分析；
- 建連時⻓（耗時）：依然通過客戶端端埋點的方式，來記錄、統計、分析耗時資訊；
- 連線保持時長：此處可以在服務端和客戶端分別進行實時，主要用以評估終端 TCP 連線的穩定性；
- 移動閘道器 RPC API 方法的呼叫成功率（錯誤率）、包大小、耗時等；
- MSS、MPS 資料同步推送成功率、耗時、包大小等。
其中各種指標均需要區分網路型別（WiFi、4G、3G等等）、機型等引數進行分別監控，至於其他的資料則可根據不同場景繼續延伸挖掘，並可針對諸如“當面付”等重點業務做專題分析。
2. 優化方向
在前面的章節已經有提到，根據行動網路的特性，我們可以分別從網路鏈路上，客戶端&服務端流程設計以及網路協議上下手，在實際的操作過程中，則通過以下幾方面開展：
- 網路服務架構升級：主要組成部分為AccGW網路接入閘道器、MGS移動API閘道器、MPS訊息推送服務、MSS資料同步服務以及MDC移動排程服務。
- 定製網路協議：MMTP（螞蟻移動傳輸協議）+MTLS（螞蟻移動安全傳輸協議）；
- 網路資料處理：HybridPB 序列化、gzip、zstd、hpack 等壓縮方式升級；
- 連線策略細化：建（斷）連控制、連線保持、智慧心跳、假連線偵測等；
- 持續業務治理：介面設計優化、靜態資源優化、監控體系建設等。
網路服務架構升級
如圖中所示，客戶端可拆分為主程式和 Service 程式，主程式主要承載具體的功能元件和業務模組，Service 程式則主要負責與服務端進行網路協議和網路資料對接，並負責程式保活。
在穿過公網、LVS、以及一系列防火牆、路由器之後，進入後端具體應用可直接感知 SLB，在這之後才正式進入我們可操作和優化的後端架構：AccGW、ApiGW(MGS)、SyncGW(MSS)、PushGW(MPS)，並由 LinkMng 來統一管理終端的連線資訊和連線生命週期，移動排程這使用 MDC 配合 HTTPDNS 來完成。
AccGW
接入閘道器目前由 Spanner 來承接：
Spanner 是螞蟻集團基於 Nginx 二次開發的一套事件驅動型系統，其主要功能大致可分為：
- 進行 SSL 解除安裝：可支援標準的 TLS1.0、1.1、1.2、1.3 以及 mtls；
- 配置管控：可通過控制檯動態的管理配置項、上線、下線，並提供一系列的API可供後端系統動態呼叫；
- 動態 UPSTREAM 路由：因需要對接不同的基於 mmtp 協議的後端基礎元件，因此需要區分資料包渠道型別（upstream 路由到哪個基礎元件），並可實時、動態的掛載和下線後端伺服器；
- MMTP 協議處理：包括資料的序列化、反序列化、壓縮、解壓縮；
- 連線保持：需要掛載所有終端的 TCP 連線，並通過智慧心跳維持住連線；
- 資料埋點：可在最上層進行資料包的埋點記錄，並使用者監控體系為後續流量管控及網路分析提供一手資料。
- 流量管控：其核心目的是在大促場景下，可在最上層將業務流量進行限制和管理，以確保下游系統能安全存活。
MSS 訊息同步服務
在基礎服務架構升級中，MSS（SYNC）的出現同樣扮演了及其重要的角色：
在之前的文章中已經有介紹 MSS 是通過一個安全的資料通道 TCP+SSL，及時、準確、有序地將伺服器端的業務資料，主動的同步到客戶端 App，其定位是一個客戶端與服務端之間的訊息中介軟體。
MSS 主體思想是：類似 MySQL 資料庫 binlog 原理的基礎上定義了一個 oplog 概念，伺服器和客戶端 SDK 之間傳遞的最小資料單元被稱為一個 oplog，每當業務需要同步一個資料變更到指定的使用者/裝置的時候，業務呼叫MSS服務端的 SyncData 介面，MSS 會將業務需要同步的資料變更包裝為一個 oplog 持久化到資料庫，然後在客戶端線上的時候把oplog 推送給客戶端，如果當前則立即觸發推送。每個 oplog 擁有一個唯一的 oplog id，oplog ID 在確定的使用者、確定的業務範圍內保證唯一併且單調遞增（按呼叫順序）。MSS 按照 oplog ID 從小到大的順序把每一條 oplog 都推送到客戶端。通過 ACK 機制服務端和客戶端均會記錄客戶端已同步資料的最大 oplog ID（亦可理解為資料版本），後續產生新資料時進行差量計算和差量同步。
通過 MSS 可以給客戶端帶來幾大好處：
- 業務合併：一次初始化命令，推送多業務資料，減少冗餘的請求資料；
- 增量推送：增量資料相對較少，減少冗餘資料的傳輸，降低網路成本；
- 減少請求：沒有增量資料時，將不會消耗請求成本，減少了無謂的請求；
- 提高時效：當服務端發生資料變化，可以直接推送至客戶端，無需等待客戶端請求；
- 提升體驗：在渲染介面之前，資料已經到位，降低了使用者等待的時間；
這些優勢可非常有效的減少客戶端 RPC 介面互動次數，減少需要傳輸的業務資料內容，並由於其主動推送的特性又可極大的提升使用者的體驗效果。
移動排程
在移動排程的升級上，採用的是 MDC 配合 HTTPDNS，傳統的 DNS 有幾大弊端：
- 終端網路請求需要消耗 1 個 RTT 先進行域名解析，需要額外的網路和時間開支。
- 運營商 DNS 參差不齊：不同的地區、環境、不同的運營商 DNS 解析效率完全不同，快則1秒，滿則 7~8 秒甚至由於快取等問題解析失敗。
- 目前大型 App 均需要進行多機房、多中心部署，傳統 DNS 無法在客戶端直接路由到指定機房或中心，並且由於快取等問題容災效率也不高。
- 無法滿足自定義的排程需求：灰度、白名單、特殊業務場景指定到具體機房、中心或指定到某一個臺伺服器上。
- 存在 DNS 劫持問題。
通過 MDC 配合 HTTPDNS 則可以完美的解決以上問題：客戶端通過獨立的網路請求到伺服器拉取可用的 IP 列表，IP 列表資訊中已包含了服務端的機房、中心以及白名單相關資訊，客戶端在獲取到 IP 列表之後既可根據當前使用者（裝置）資訊在後面的網路請求中直接路由到對應的機房、中心、某臺具體伺服器或者海外 POP 加速站點。IP 列表可長期的儲存在客戶端中，後續的請求中均只需要通過本地 DNS 解析即可以完成 IP 對映，用以節省 1 次 RTT 請求時間，也可以有效的防範 DNS 域名劫持，於此同時可結合 MSS 等服務來指定實際更新策略來確保第一時間更新 IP 列表。此外，客戶端也可通過定期檢測、定製質量模型等方式來計算、評估獲取最優 IP 地址。
協議優化
- MMTP
MMTP：全稱螞蟻移動傳輸協議，是二進位制的 TLV(型別、⻓度、值)結構的協議；是並駕於 HTTP、HTTP2.0、spdy 的私有化傳輸協議。
其主要優點為：
- 打包解包效率高，省記憶體；
- 可多路複用，並具有極高的擴充套件性；
- 由於高度的自定義，引入了諸多的特性，如：資料包重發、Sequence 檢測假連線、柔性斷鏈並可做到精細管控等。
- MTLS
MTLS：全稱螞蟻移動安全傳輸協議是基於 TLS1.3 擴充套件的安全傳輸協議。
TLS1.3 可通過證照 cache、session Ticket 等機制支援 1RTT 握手，加密套件則可選用ECDHE，根據有關資料驗證，160 位元 ECC 金鑰和 1024 位元的 RSA 金鑰的安全性相當，小資料量在速度、效率、頻寬、儲存上都會體現出明顯優勢，此外在某些特殊功能上，甚至可以使用 0RTT 的方式直接完成資料互動。
資料優化
-
序列化方式：目前在螞蟻體現內已基本普及了 protobuf。Protobuf 全稱 Google Protocol Buffer，是一種輕便高效的結構化資料儲存格式，主要滿足結構化資料序列化，或者說序列化。它很適合做資料儲存或 RPC 資料交換格式。可用於通訊協議、資料儲存等領域的語言無關、平臺無關、可擴充套件的序列化結構資料格式。
而通過 protobuf 官方工具生成的客戶端檔案較大，可能會引起安裝包過大，函式方法過多等問題，螞蟻內部在此基礎上又重新定製了生產工具，最終產出物被定義成 HybridPB。
-
ZSTD 壓縮演算法：在上一代產品中業務資料 body 主要使用的 gzip 壓縮，而在目前的產品中則主要採用了 ZSTD 壓縮：
ZSTD 全稱 Zstandard，是一款免費的開源，快速實時資料壓縮程式，具有更好的壓縮比，由 Facebook 開發。 它是用 C 語言編寫的無失真壓縮演算法 （在 Java 中有一個重新實現） ， 因此它是一個本地 Linux 程式。在行動網路中，它可以需要將壓縮速度交換為更高的壓縮比率（壓縮速度與壓縮比率的權衡可以通過小增量來配置），它具有小資料壓縮的特殊模式，稱為字典壓縮，可以從任何提供的樣本集中構建字典。更高的壓縮比意味著更小的網路傳輸成本消耗，而這也是在移動端被採用的主要原因之一。
- HPACK 壓縮演算法：網路協議上，壓縮演算法目前採用的是 HPACK。簡單的說，HPACK 使用 2 個索引表（靜態索引表和動態索引表）來把頭部對映到索引值，對不存在的頭部使用huffman編碼，並動態快取到索引，從而達到壓縮頭部的效果。
連線策略
TCP 建連行為由移動終端發起：目前主要在終端啟動時、前後臺切換時、網路超時、連線錯誤或者網路型別切換時會發生建連動作，而建聯的策略上主要由以下幾種：
- 並行建連：當客戶端序列建連失敗一定次數後、則會進入併發建聯模式，期目的是為了併發爭取通道，增加建立成功率。
- 短頻建連：在弱網情況下可加快建立連線的頻率，以踩中一閃而過的可用間隙，第一個連結還沒建上，也可開始第二個。
- 柔性斷連：因併發建聯引起，某些場景業務可做重連重發，因此對可能並存的多條連線，需要做延遲迴收，以等待在這條即將被回收的連線上的可能存在的回包。
- 長短連線並存：在某些場景下，因為tcp無法長久保持，則可通過http短連線來提高請求瞬間衝擊能力，快速完成業務請求，並釋放資源。
對於連線的保持，傳統的做法就是心跳，心跳包可由客戶端發起，也可由服務端發起。由於移動端終端的運營商、手機廠商等各種定製、非定製的因素干擾，對於 TCP 連線保持能力上各不相同，因此恆定的心跳時間未必能滿足各種情況，過快、過慢都會帶來問題，因此支付寶採用的是動態心跳的方式來維持連線，客戶端通過一定的質量模型來評估某一心跳週期的連線維持質量，並在過程中逐步增加或減少心跳週期，在到一個最優的模型質量之後記錄下最優心跳時間，並用改週期時間來維持之後的一段時間。
連線超時控制上：除了傳統的業務請求超時和建連超時，還引入了包 sequence 概念，每個上行包傳送時，加入遞增序號，服務端收到帶序的包後，如果有下行包，就把當時收到的最大序號返回給客戶端。客戶端收到後，既可確認所有小於等於這個序號的上行包都已被服務端接受；如果某個上行包的序號在一段時間還沒有收到確認，可懷疑出現“假連線”，需要進入回收評估階段，服務端下行包亦然。
3. 業務治理：持久戰
在上面的內容中，我們一直在基礎服務上做文章，而實際的生產過程中，業務介面的設計也極大的影響著使用者的真實網路體驗，並且由於業務在持續發展，人員也持續的迭代，對於優化的規範和設計的思路上並非都在同一水平上，因此業務治理絕對是一個需要持續堅持不懈戰鬥的過程。在業務治理過程中也可總結為幾個方面：
- 介面設計優化：主要為介面資料模型設計需要在滿足業務功能的基礎儘量精簡、減少不必要的資料傳輸；客戶端併發請求優化，區分優先順序，讓客戶端在合適的場景做合適的事情，千萬不可大量併發爭搶資源而影響使用者核心流程的使用，服務端介面流程優化，比如採用非同步、快取、減少慢 SQL 等；
- 資源拉取策略優化：使用更快捷的圖片格式、在不同網路環境使用不同縮放程度的圖片、資源合併、圖片壓縮等；
- 減少資料量、資料包大小：推廣各業務方接入例如 PB 等更高效的序列化方式，推薦業務接入 MSS，SYNC 服務，通過增量推送的方式減少客戶端請求次數與服務端返回資料的大小；
- 監控體系持續完善：全鏈路資料打通，問題剖析一杆子到底；多維評價模型，監控預警，資料化研發；做到管控決策有依據，結果有資料，推動有根據；
- 大戶專項治理：針對重大業務、核心業務，網路同學直接深入業務流程設計，協助業務方發現問題並推動不斷改善。
最後： 持之以恆。無論是效能優化、網路優化，都是一個長期的過程，這也將伴隨著整個終端和服務端的生命週期，因此持之以恆的優化改進才是重中之重。
*注（更多詳細內容）：
-
進一步學習「protobuf」：
-
進一步學習「ZSTD」：
-
進一步學習「HPACK」：
| 移動開發平臺 mPaaS 三款元件重磅上線螞蟻金服開放平臺：
- 公測期，歡迎體驗試用。支付寶掃碼或登入開放平臺
往期閱讀
《螞蟻金服 mPaaS 服務端核心元件體系概述：移動 API 閘道器 MGS》
《螞蟻金服 mPaaS 服務端核心元件：億級併發下的移動端到端網路接入架構解析》
關注我們公眾號，獲得第一手 mPaaS 技術實踐乾貨
釘釘群：通過釘釘搜尋群號“23124039”
期待你的加入～