移動端IM開發(fā)者必讀(三)：愛奇藝移動端跨國弱網(wǎng)通信的優(yōu)化實踐

Posted on 2024-06-27 11:51 Jack Jiang 閱讀(97) 評論(0) 編輯收藏

本文由愛奇藝技術(shù)團隊分享，作者isno，原題“愛奇藝海外App的網(wǎng)絡優(yōu)化實踐”，下文進行了排版和內(nèi)容優(yōu)化等。

1、引言

做海外市場，特別目標是面向全球的用戶，網(wǎng)絡的重要性不言而喻。試想一個移動端應用，比如即時通訊IM，聊天消息的本質(zhì)就是人跟人在說話，一條消息從發(fā)送到接受需要10秒的時間，這恐怕會讓用戶崩潰，隨之就是被無情地卸載，開拓海外市場那就是做夢了。

本次分享的文章內(nèi)容，基于愛奇藝面向全球用戶推出的國際版，在海外跨國網(wǎng)絡環(huán)境復雜的前提下，針對性地做了一系列弱網(wǎng)優(yōu)化實踐，取得了不錯的效果，在此總結(jié)分享我們的一些做法和優(yōu)化思路，希望對你有所幫助。

總結(jié)下來，跨國弱網(wǎng)優(yōu)化實踐的幾個核心就是：

1）能不請求網(wǎng)絡就不請求；
2）請求的鏈接目標 0-RTT；
3）請求的內(nèi)容越小越好。

正文內(nèi)容我們將逐個技術(shù)點展開了分享。

技術(shù)交流：

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發(fā)布于：http://www.52im.net/thread-4669-1-1.html）

2、系列文章

本文是系列文章中的第 3 篇，本系列文章的大綱如下：

《移動端IM開發(fā)者必讀(一)：通俗易懂，理解移動網(wǎng)絡的“弱”和“慢”》
《移動端IM開發(fā)者必讀(二)：史上最全移動弱網(wǎng)絡優(yōu)化方法總結(jié)》
《移動端IM開發(fā)者必讀(三)：愛奇藝移動端跨國弱網(wǎng)通信的優(yōu)化實踐》（* 本文）

如果您是IM開發(fā)初學者，強烈建議首先閱讀《新手入門一篇就夠：從零開發(fā)移動端IM》。

3、跨國弱網(wǎng)樣本摸底

在 App 初期版本內(nèi)增加請求鏈路的采樣。樣本數(shù)足夠的情況下，可以清楚你要推廣的市場是怎樣的環(huán)境。樣本數(shù)據(jù)讓我們清楚發(fā)現(xiàn)了各個國家、地區(qū)網(wǎng)絡的問題，在大規(guī)模宣傳和投入前，做好 App 的基礎工作非常重要。

海外用戶至海外數(shù)據(jù)中心的網(wǎng)絡延遲（這是監(jiān)測節(jié)點數(shù)據(jù)，用戶端延遲更高）：

海外主要國家、地區(qū)移動網(wǎng)絡情況：

在調(diào)研階段，我們發(fā)現(xiàn)了以下問題比較明顯，切實影響我們的運營及 App 體驗。

這些問題主要是：

1）運營商劫持嚴重，DNS 劫持、HTTP 劫持；
2）移動端網(wǎng)絡復雜，東南亞的網(wǎng)絡基礎建設還待改善；
3）低端 Android 機有一定的占比，數(shù)量級別影響決策；
4）國際網(wǎng)絡用戶端到服務器的延遲高。

在初期階段，技術(shù)工作的核心是解決以上問題，為后續(xù)的運營做好基礎建設。因為業(yè)務接口大部分為 HTTP 形式，就開始圍繞 HTTPS 進行針對性改進。

一個HTTPS請求階段分析：

一個 HTTPS 在第一請求會有 5 個 RTT：

1RTT(DNS)+ 1RTT(TCP 握手)+ 2RTT(TLS1.2)+ 1RTT(HTTP 鏈接)

如果以端到服務 50ms 延遲為例：

一個 HTTPS 的接口延遲 = 350ms = 50*5+ 100ms（服務端）

如果目標是一個非國內(nèi)用戶，打開首頁需要 1.1s, 這個時間顯然有點長。

下面開始進行技術(shù)改進的正文，以下是概括技術(shù)性優(yōu)化的關鍵點：

4、基礎鏈路的改進優(yōu)化

4.1DNS 優(yōu)化調(diào)整

DNS 的解析改為 HTTPDNS，DNS 的改進上線后觀察初始連接請求提升 17% 的效率。

目的主要是：

1）解決域名劫持問題（東南亞地區(qū)回傳的數(shù)據(jù)顯示有不少劫持）；
2）解決 LocalDNS 非就近分配問題；
3）結(jié)合業(yè)務可以做解析預熱。

4.2傳輸層的優(yōu)化調(diào)整

MTU 的問題：

1）Client 端和 Server 端不同的 MTU 值會導致丟包率過高。AWS 某些場景實例默認巨型幀：MTU 是 9001，但接收端默認 1500，這時候就會出現(xiàn)一些丟包的現(xiàn)象；
2）如果你用了多個云商服務，用 VPN 組網(wǎng)，IP隧道封裝的數(shù)據(jù)臨界 1500，又會造成丟包、包重傳問題；
3）最嚴重的情況：部分網(wǎng)絡封殺 ICMP 協(xié)議，導致 MTU 無法自動協(xié)商。

TCP 擁塞控制優(yōu)化：

擁塞窗口 CongWin 是未接收到接收端確認情況下連續(xù)發(fā)送的字節(jié)數(shù); 。CongWin 是動態(tài)調(diào)整，取決于帶寬和延遲的積，比如 100MB 的帶寬 100ms 的延遲環(huán)境。

時延帶寬積 = 100Mbps*100ms = (100/8)*(100/1000) = 1.25MB

理論上 CongWin 窗口可以最大化到 1.25MB。CentOS 默認CongWin = 20*MSS，在 29KB 左右，離上限 1.26MB 差太多了，默認值上調(diào)TCP的啟動會更快。

TCP 快速打開 (TCP Fast Open：TFO)：

TCP 的 keepalive 下依然會有鏈接斷掉重建的情況，TFO 是針對這種情況的優(yōu)化。

TFO 的原理機制：

在我們觀察中開啟 TFO 機制，海外業(yè)務一個 RTT 通常時間在 100ms 以上，HTTP 請求效率提升了 12% 左右。

5、應用層的改進優(yōu)化

5.1HTTP 的優(yōu)化

HTTP1.1 有個 keep-alive 作用是復用 TCP 鏈接，減少新建的消耗，對于瀏覽器的業(yè)務比較適用，但對于移動端這種時間分散的請求，大部分請求還是新建連接。

HTTP1.1 的串行機制有頭部阻塞的問題。

5.2SSL 層優(yōu)化

盡量升級到 TLS1.3（微信的TLS1.3實踐：《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》），利用 Pre-shared Key 機制，開啟 ssl_early_data 可以進一步優(yōu)化 “0-RTT ”，如果無法升級 TLS 版本，優(yōu)化密鑰算法為 ECDHE，運算速度快，握手的消息往返由 2-RTT 減少到 1-RTT，能達到與 TLS1.3 類似的效果。

TLS 版本的區(qū)別：

TLS1.3 經(jīng)過優(yōu)化后，一個 HTTP 請求由之前的 4 個 RTT 減少為 3 個 RTT。

5.3升級 HTTP2.0

幾個重要的改進點：

1）分幀傳輸；
2）多路復用；
3）頭部壓縮。

多路復用：

在 HTTP/2 中，兩個非常重要的概念：幀（frame）和流（stream）。幀代表著最小的數(shù)據(jù)單位，每個幀會標識出該幀屬于哪個流，流也就是多個幀組成的數(shù)據(jù)流。多路復用，就是在一個 TCP 連接中可以存在多條流。這些改進可以避免 HTTP 隊頭阻塞問題，提高傳輸性能。

頭部壓縮：

開發(fā)人員如果不注意對 header 內(nèi)容的控制，會造成 header 內(nèi)容失控的現(xiàn)象，客戶端極容易存儲一個非常大的 Cookie。

HTTP2 的分幀傳輸機制：