作者：凝睇，螞蟻金服移動開發平臺 mPaaS 技術專家。目前負責螞蟻金服移動開發平臺 mPaaS 服務端組件體系優化與架構設計。 內容采編自 CodeDay#1 杭州站現場分享，主題是《弱網優化在支付寶的深度實踐》。

現場視頻： tech.antfin.com/activities/…

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」：

  developers.google.com/protocol-bu…

• 進一步學習「ZSTD」：

  facebook.github.io/zstd/

• 進一步學習「HPACK」：

  www.rfc-editor.org/rfc/pdfrfc/…

| 移動開發平臺 mPaaS 三款組件重磅上線螞蟻金服開放平臺：

• 公測期，歡迎體驗試用。支付寶掃碼或登錄開放平臺

往期閱讀

《開篇 | 螞蟻金服 mPaaS 服務端核心組件體系概述》

《螞蟻金服 mPaaS 服務端核心組件體系概述：移動 API 網關 MGS》

《螞蟻金服 mPaaS 服務端核心組件：億級并發下的移動端到端網絡接入架構解析》

《支付寶 App 構建優化解析：通過安裝包重排布優化 Android 端啟動性能》

《支付寶 App 構建優化解析：Android 包大小極致壓縮》

關注我們公眾號，獲得第一手 mPaaS 技術實踐干貨

釘釘群：通過釘釘搜索群號“23124039”

期待你的加入～

總結

以上是生活随笔為你收集整理的弱网优化在支付宝的深度实践 | mPaaS 线下沙龙 CodeDay#1 分享实录的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。