移動 APP 網路最佳化概述

（點選上方公眾號，可快速關註）

來源：bang，

blog.cnbang.net/tech/3531/

一般開發一個 APP，會直接呼叫系統提供的網路請求介面去服務端請求資料，再針對傳回的資料進行一些處理，或者使用AFNetworking/OKHttp這樣的網路庫，管理好請求執行緒和佇列，再自動做一些資料解析，就結束了。

但對於一些大型 APP，還會想針對網路的一些問題進行進一步最佳化，包括：

• 速度：網路請求的速度怎樣能進一步提升？

• 弱網：移動端網路環境隨時變化，經常出現網路連線很不穩定可用性差的情況，怎樣在這種情況下最大限度最快地成功請求？

• 安全：怎樣防止被第三方竊聽/篡改或冒充，防止運營商劫持，同時又不影響效能？

對基於瀏覽器的前端開發來說，網路這塊能做的事情很少，但對於客戶端 APP 來說，整個網路請求過程是自由控制的，可以做很多事情，很多大型 APP 都針對這三個問題做了很多網路層的最佳化，一些新的網路層協議像 HTTP2 / QUIC 也是在這些方面進行了不少最佳化，在這裡邊學習邊整理，大致列舉一下常見的做法。

速度

正常一條網路請求需要經過的流程是這樣：

1. DNS 解析，請求DNS伺服器，獲取域名對應的 IP 地址。

2. 與服務端建立連線，包括 tcp 三次握手，安全協議同步流程。

3. 連線建立完成，傳送和接收資料，解碼資料。

這裡有明顯的三個最佳化點：

1. 直接使用 IP 地址，去除 DNS 解析步驟。

2. 不要每次請求都重新建立連線，復用連線或一直使用同一條連線(長連線)。

3. 壓縮資料，減小傳輸的資料大小。

逐條來看能做什麼。

1.DNS

DNS 完整的解析流程很長，會先從本地系統快取取，若沒有就到最近的 DNS 伺服器取，若沒有再到主域名伺服器取，每一層都有快取，但為了域名解析的實時性，每一層快取都有過期時間，這種 DNS 解析機制有幾個缺點：

1. 快取時間設定得長，域名更新不及時，設定得短，大量 DNS 解析請求影響請求速度。

2. 域名劫持，容易被中間人攻擊，或被運營商劫持，把域名解析到第三方 IP 地址，據統計劫持率會達到7%。

3. DNS 解析過程不受控制，無法保證解析到最快的IP

4. 一次請求只能解析一個域名。

為瞭解決這些問題，就有了 HTTPDNS，原理很簡單，就是自己做域名解析的工作，透過 HTTP 請求後臺去拿到域名對應的 IP 地址，直接解決上述所有問題：

1. 域名解析與請求分離，所有請求都直接用IP地址，無需 DNS 解析，APP 定時請求 HTTPDNS 伺服器更新IP地址即可。

2. 透過簽名等方式，保證 HTTPDNS 請求的安全，避免被劫持。

3. DNS 解析由自己控制，可以確保根據使用者所在地傳回就近的 IP 地址，或根據客戶端測速結果使用速度最快的 IP。

4. 一次請求可以解析多個域名。

其餘細節就不多說了，HTTPDNS 優點這麼多，幾乎成為中大型 APP 的標配。至此解決了第一個問題 — DNS 解析耗時的問題，順便把一部分安全問題 — DNS 劫持也解決了。

2.連線

第二個問題，連線建立耗時的問題，這裡主要的最佳化思路是復用連線，不用每次請求都重新建立連線，如何更有效率地復用連線，可以說是網路請求速度最佳化裡最主要的點了，並且這裡的最佳化仍在演進過程中，值得瞭解下。

keep-alive

HTTP 協議裡有個 keep-alive，HTTP1.1預設開啟，一定程度上緩解了每次請求都要進行TCP三次握手建立連線的耗時。原理是請求完成後不立即釋放連線，而是放入連線池中，若這時有另一個請求要發出，請求的域名和埠是一樣的，就直接拿出連線池中的連線進行傳送和接收資料，少了建立連線的耗時。

實際上現在無論是客戶端還是瀏覽器都預設開啟了keep-alive，對同個域名不會再有每發一個請求就進行一次建連的情況，純短連線已經不存在了。但有個問題，就是這個 keep-alive 的連線一次只能傳送接收一個請求，在上一個請求處理完成之前，無法接受新的請求。若同時發起多個請求，就有兩種情況：

1. 若序列傳送請求，可以一直復用一個連線，但速度很慢，每個請求都要等待上個請求完成再進行傳送。

2. 若並行傳送這些請求，那麼首次每個請求都要進行tcp三次握手建立新的連線，雖然第二次可以復用連線池裡這堆連線，但若連線池裡保持的連線過多，對服務端資源產生較大浪費，若限制了保持的連線數，並行請求裡超出的連線仍每次要建連。

對這個問題，新一代協議 HTTP2 提出了多路復用去解決。

多路復用

HTTP2 的多路復用機制一樣是復用連線，但它復用的這條連線支援同時處理多條請求，所有請求都可以併發在這條連線上進行，也就解決了上面說的併發請求需要建立多條連線帶來的問題，網路上有張圖可以較形象地表現這個過程：



HTTP1.1的協議裡，在一個連線裡傳送資料都是序列順序傳送的，必須等上一個請求全部處理完後，下一個請求才能進行處理，導致這些請求期間這條連線並不是滿頻寬傳輸的，即使是HTTP1.1的pipelining可以同時傳送多個request，但response仍是按請求的順序序列傳回，只要其中一個請求的response稍微大一點或發生錯誤，就會阻塞住後面的請求。

HTTP2 這裡的多路復用協議解決了這些問題，它把在連線裡傳輸的資料都封裝成一個個stream，每個stream都有標識，stream的傳送和接收可以是亂序的，不依賴順序，也就不會有阻塞的問題，接收端可以根據stream的標識去區分屬於哪個請求，再進行資料拼接，得到最終資料。

解釋下多路復用這個詞，多路可以認為是多個連線，多個操作，復用就是字面上的意思，復用一條連線或一個執行緒。HTTP2這裡是連線的多路復用，網路相關的還有一個I/O的多路復用(select/epoll)，指透過事件驅動的方式讓多個網路請求傳回的資料在同一條執行緒裡完成讀寫。

客戶端來說，iOS9 以上 NSURLSession 原生支援 HTTP2，只要服務端也支援就可以直接使用，Android 的 okhttp3 以上也支援了 HTTP2，國內一些大型 APP 會自建網路層，支援 HTTP2 的多路復用，避免系統的限制以及根據自身業務需要增加一些特性，例如微信的開源網路庫 mars，做到一條長連線處理微信上的大部分請求，多路復用的特性上基本跟 HTTP2 一致。

TCP隊頭阻塞

HTTP2 的多路復用看起來是完美的解決方案，但還有個問題，就是隊頭阻塞，這是受限於 TCP 協議，TCP 協議為了保證資料的可靠性，若傳輸過程中一個 TCP 包丟失，會等待這個包重傳後，才會處理後續的包。HTTP2的多路復用讓所有請求都在同一條連線進行，中間有一個包丟失，就會阻塞等待重傳，所有請求也就被阻塞了。

對於這個問題不改變 TCP 協議就無法最佳化，但 TCP 協議依賴作業系統實現以及部分硬體的定製，改進緩慢，於是 GOOGLE 提出 QUIC 協議，相當於在 UDP 協議之上再定義一套可靠傳輸協議，解決 TCP 的一些缺陷，包括隊頭阻塞。具體解決原理網上資料較多，可以看看。

QUIC 處於起步階段，少有客戶端接入，QUIC 協議相對於 HTTP2 最大的優勢是對TCP隊頭阻塞的解決，其他的像安全握手 0RTT / 證書壓縮等最佳化 TLS1.3 已跟進，可以用於 HTTP2，並不是獨有特性。TCP 隊頭阻塞在 HTTP2 上對效能的影響有多大，在速度上 QUIC 能帶來多大提升待研究。

3.資料

第三個問題，傳輸資料大小的問題。資料對請求速度的影響分兩方面，一是壓縮率，二是解壓序列化反序列化的速度。目前最流行的兩種資料格式是 json 和 protobuf，json 是字串，protobuf 是二進位制，即使用各種壓縮演演算法壓縮後，protobuf 仍會比 json 小，資料量上 protobuf 有優勢，序列化速度 protobuf 也有一些優勢，這兩者的對比就不細說了。

壓縮演演算法多種多樣，也在不斷演進，最新出的 Brotli 和Z-standard實現了更高的壓縮率，Z-standard 可以根據業務資料樣本訓練出適合的字典，進一步提高壓縮率，目前壓縮率表現最好的演演算法。

除了傳輸的 body 資料，每個請求 HTTP 協議頭的資料也是不可忽視，HTTP2 裡對 HTTP 協議頭也進行了壓縮，HTTP 頭大多是重覆資料，固定的欄位如 method 可以用靜態字典，不固定但多個請求重覆的欄位例如 cookie 用動態字典，可以達到非常高的壓縮率，這裡有詳細介紹。

透過 HTTPDNS，連線多路復用，更好的資料壓縮演演算法，可以把網路請求的速度最佳化到較不錯的程度了，接下來再看看弱網和安全上可以做的事情。

弱網

手機無線網路環境不穩定，針對弱網的最佳化，微信有較多實踐和分享，包括：

提升連線成功率

複合連線，建立連線時，階梯式併發連線，其中一條連通後其他連線都關閉。這個方案結合序列和併發的優勢，提高弱網下的連線成功率，同時又不會增加伺服器資源消耗：



制定最合適的超時時間

對總讀寫超時(從請求到響應的超時)、首包超時、包包超時(兩個資料段之間的超時)時間制定不同的計算方案，加快對超時的判斷，減少等待時間，儘早重試。這裡的超時時間還可以根據網路狀態動態設定。

調優TCP引數，使用TCP最佳化演演算法。

對服務端的TCP協議引數進行調優，以及開啟各種最佳化演演算法，使得適合業務特性和移動端網路環境，包括RTO初始值，混合慢啟動，TLP，F-RTO等。

針對弱網的這些細緻最佳化未成為標準，系統網路庫沒有內建，不過前兩個客戶端最佳化微信的開源網路庫 mars 有實現，若有需要可以使用。

安全

標準協議 TLS 保證了網路傳輸的安全，前身是 SSL，不斷在演進，目前最新是 TLS1.3。常見的 HTTPS 就是 HTTP 協議加上 TLS 安全協議。

安全協議概括性地說解決兩個問題：1.保證安全 2. 降低加密成本

在保證安全上：

1. 使用加密演演算法組合對傳輸資料加密，避免被竊聽和篡改。

2. 認證對方身份，避免被第三方冒充。

3. 加密演演算法保持靈活可更新，防止定死演演算法被破解後無法更換，禁用已被破解的演演算法。

降低加密成本上：

1. 用對稱加密演演算法加密傳輸資料，解決非對稱加密演演算法的效能低以及長度限制問題。

2. 快取安全協議握手後的金鑰等資料，加快第二次建連的速度。

3. 加快握手過程：2RTT-> 0RTT。加快握手的思路，就是原本客戶端和服務端需要協商使用什麼演演算法後才能加密傳送資料，變成透過內建的公鑰和預設的演演算法，在握手的同時就把資料發出去，也就是不需要等待握手就開始傳送資料，達到0RTT。

這些點涉及的細節非常多，對 TLS 的介紹有一篇雄文，說得很詳細，在此推薦。

https://blog.helong.info/blog/2015/09/07/tls-protocol-analysis-and-crypto-protocol-design/

目前基本主流都支援 TLS1.2，iOS 網路庫預設使用 TLS1.2，Android4.4 以上支援 1.2。TLS1.3 iOS 還處於測試階段，Android 未查到訊息。對於普通 APP，只要正確配置證書，TLS1.2 已經能保證傳輸安全，只是在建連速度上會有所損耗，有一些大型 APP 像微信就自行實現了 TLS1.3 的部分協議，早一步全平臺支援。

最後

網路最佳化這個話題非常龐大，本文只是在學習過程中從最佳化思路上列舉了目前業界常見的最佳化點，還有很多細節很多更深入的最佳化沒涉及到，網路層實踐開發經驗不足，若有錯誤歡迎指出。

看完本文有收穫？請轉發分享給更多人

關註「ImportNew」，提升Java技能