移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的「弱」和「慢」

時間 2019-11-17

原文原文鏈接

本系列文章引用了騰訊技術專家樊華恆《海量之道系列文章之弱聯網優化》的部分章節，感謝原做者。php

一、前言

隨着移動互聯網的高速發展，移動端IM以移動網絡做爲物理通訊載體早已深刻人心，這其中的成功者就包括微信、手機QQ、支付寶（從即時通信產品的角度來看，支付寶已經算的上是半個IM了）等等，也爲移動端即時通信開發者帶來了各類能夠參考的標杆功能和理念：語音對講、具備移動端體驗特性的圖片消息、全時在線的概念、真正突破物理體驗的實時通知等。

上述IM產品、功能和概念，在開發者間討論時，無一例外都會被打上「移動端」這個特性，從網絡通訊的角度來講，這個特性的本質能夠認爲就是移動網絡的特性。

以文件發送爲例，傳統的PC端IM（能夠簡單地理解爲傳統有線網絡上的IM）能夠直接實時點對點發送（理論上無需通過服務器中轉）。

但在移動端IM裏咱們並不能這麼幹，緣由是：

html

1）3G/4G/5G網絡下P2P成功率並無那麼高（由於是對稱型NAT，詳見《通俗易懂：快速理解P2P技術中的NAT穿透原理》）；
2）移動網絡的信號跳變、抖動很難預測（甚至在你轉身的瞬間，信號可能會立馬由強變弱）；
3）移動網絡的延遲、丟包、重傳等致使通訊體驗不好（就像從國內訪問國外的網站那種「慢」，體驗上是類似的）；
4）延遲、丟包、重傳帶來的另外一個後果就是電量消耗、流量消耗過大，這些都是不可接受的；
5）智能手機（主要是Android、iOS）的系統省電策略，致使網絡可能被阻斷，甚至進程被殺死，功能沒辦法在後臺繼續工做。

因此，正是移動網絡的這些特性，使得本來在傳統PC端再普通不過的功能（好比上面說的文件發送），在移動端IM中卻不得不另想辦法：以文件發送爲例——主流的移動端IM如今都是使用服務器中轉來搞定的。使用相似技術實現的功能，還有移動端IM里語音短消息的AMR音頻小文件、圖片消息的圖片文件等。

那麼迴歸到本文的正題：移動網絡爲何會存在「弱」和「慢」這樣的特性？

這個問題網絡工程師來回答最爲合適，對但於應用層的程序員來講，有關移動網絡的理論太生澀枯燥，太難理解了。而對於網絡工程師來講，他們也不理解「大家這些程序員到底在糾結移動網絡的什麼鬼？」。

就像黃品源的那首《那麼愛你爲何》的歌曲裏面莫文蔚的一段唸白：「我講又講不清，你聽又聽不懂......」。這大概是應用層程序員很難能找到通俗易懂的有關移動網絡資料的緣由吧。

因此本文的目的，就是但願以通俗易懂的語言，幫助移動端IM開發者更好地理解移動網絡的各類特性，使得開發出的功能能更好地適應移動網絡，給用戶帶來更好的使用體驗。

另外，《現代移動端網絡短鏈接的優化手段總結：請求速度、弱網適應、安全保障》這篇文章也提到了本文所闡述的相關內容，強烈建議閱讀。前端

學習交流：程序員

- 即時通信開發交流3羣：185926912[推薦]編程

- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》緩存

（本文同步發佈於：http://www.52im.net/thread-1587-1-1.html）安全

二、系列文章

▼ 本文是《移動端IM開發者必讀》系列文章的第1篇：

服務器

若是您是IM開發初學者，強烈建議首先閱讀《新手入門一篇就夠：從零開發移動端IM》。微信

三、相關文章

1）關於網絡通訊的基礎文章：

網絡

若是您對網絡通訊知識瞭解甚少，建議閱讀《網絡編程懶人入門系列文章》，更高深的網絡通訊文章能夠閱讀《鮮爲人知的網絡編程系列文章》。

2）涉及移動端網絡特性的文章：

四、正文引言

移動互聯網顛覆着咱們的生活方式，這個每時每刻伴隨着咱們的網絡到底有哪些特色，又是如何影響咱們接入信息世界的體驗呢。

如下場景如似曾相識，敬請對號入座：

1）上班路上收到朋友分享的一張美女圖片，縮略圖目測衣服用料至關節儉，立馬興奮點開欲詳細鑽研，卻發現怎麼脫也脫不下來，不對，是「拖」不是「脫」，仰望蒼天，欲哭無淚。

2）進電梯前收到女朋友一條消息：「你到底愛不愛我！」，固然立刻回覆「必須的必！」，電梯門關閉了，北風那個吹，菊花那個轉，等到春暖梯開，滿屏都是女朋友的問候「在嗎！」、「這都要想那麼久！」、「跟哪一個MM聊天呢！」、「我生氣了！」、「你是好人，再見！」，看着本身的回覆剛剛發送成功，停在最後一行，整個互動信息一鼓作氣，都是眼淚。

3）和朋友聚餐，菜端上先拍照分享，再大快朵頤，明明坐在對面，恰恰還得用手機聊天，世界最遠的距離，莫過於咱們坐在一塊兒，卻只能用手指切磋。

有因有果，有道有術，不入虎穴焉得虎子，不扯了，進入正題。

五、移動網絡的特色

理論上說，咱們看到移動網絡有以下三個典型特色：

1）移動狀態網絡信號不穩定，高時延、易抖動丟包、通道狹窄；
2）移動狀態網絡接入類型和接入點變化頻繁；
3）移動狀態用戶使用高頻化、碎片化、非WIFI流量敏感。

爲何？

參考【圖一無線網絡鏈路示意】，咱們嘗試從物理上追根溯源：
<ignore_js_op>
▲ 圖一：無線網絡鏈路示意

根據「圖一：無線網絡鏈路示意」所示內容，咱們能夠獲得如下信息。

第1、直觀印象是通信鏈路長而複雜：從（移動）終端設備到應用服務器之間，相較有線互聯網，要多通過基站、核心網、WAP網關（好消息是WAP網關正在被依法取締）等環節，這就像送快遞，中間環節越多就越慢，每一箇中轉站的服務質量和服務效率不一，每次傳遞都要從新交接入庫和分派調度，一不當心還能把包裹給弄丟了。

第2、這是個資源受限網絡：移動設備接入基站空中信道數量很是有限，信道調度更是至關複雜，如何複雜就不展開了，莫文蔚那首歌詞用在這裏正合適：「我講又講不清，你聽又聽不懂......」，最最重要的是分配的業務信道單元若是1秒鐘不傳數據就會立馬被釋放回收，六親不認童叟無欺。

第3、這個鏈條前端（無線端）是高時延（除某些WIFI場景外）、低帶寬（除某些WIFI場景外）、易抖動的網絡：無線各類制式網絡帶寬上限都比較低而傳輸時延比較大（參見【表一運營商移動信號制式帶寬標準】），而且，沒事就能丟個包裹玩玩，最最重要的是，距離基站的遠近，把玩手機的角度、地下室的深度等等都能影響無線信號的質量，讓包裹在空中飛一會，再飛一會......。這些因素也形成了移動互聯網網絡質量穩定性差、接入變化頻繁，與有線互聯網對比更是天上人間的差異，從【圖二有線互聯網和移動互聯網網絡質量差別】中能夠有更直觀的感覺。

<ignore_js_op>
▲ 圖二：有線互聯網和移動互聯網網絡質量差別

【表一運營商移動信號制式帶寬標準】數據來自互聯網各類百科，定性不定量，僅供參考；
<ignore_js_op>
<ignore_js_op> 【表一-運營商移動信號制式帶寬標準】-清晰圖.rar (252.64 KB , 下載次數: 0 )

第4、這是個局部封閉網絡：空中信道接入後要作鑑權、計費等預處理，WAP網絡甚至還要作數據過濾後再轉發，在業務數據有效流動前太多中間代理人求參與，效率可想而知。產品研發爲何又慢又亂，廣大程序猿內心明鏡似的；最最重要的是，不一樣運營商之間跨網傳輸既貴且慢又有諸多限制，聰明的運營商便也用上了緩存技術，催生了所謂網絡「劫持」的現象。

若是咱們再結合用戶在移動狀態下2G/3G/4G/WIFI的基站/AP之間，或者不一樣網絡制式之間頻繁的切換，狀況就更加複雜了。

六、移動網絡爲何「慢」

咱們在移動網絡的特色介紹中，很容易的獲得了三個關鍵字：

1）「高時延」；
2）「易抖動」；
3）「通道窄」。

這些物理上的約束確實限制了咱們移動衝浪時的速度體驗，那麼，還有別的因素嗎。

固然有，汗牛充棟、罄竹難書：

1）DNS解析，這個在有線互聯網上司空見慣的服務，在移動互聯網上變成了一種負擔，一個往復最少1s，還別提遇到移動運營商DNS故障時的尷尬；
2）鏈路創建成本暨TCP三次握手，在一個高時延易抖動的網絡環境，而且大部分業務數據交互限於一個HTTP的往返，建鏈成本尤爲顯著；
3）TCP協議層慢啓動、擁塞控制、超時重傳等機制在移動網絡下參數設定的不適宜；
4）很差的產品需求規定或粗放的技術方案實現，使得不受控的大數據包、頻繁的數據網絡交互等，在移動網絡側TCP鏈路上傳輸引發的負荷；
5）很差的協議格式和數據結構設計，使得協議封裝和解析計算耗時、耗內存、耗帶寬，甚至協議格式臃腫冗餘，使得網絡傳輸效能低下；
6）很差的緩存設計，使得數據的加載和渲染計算耗時、耗內存、耗帶寬。

如今終於知道時間都去哪了，太浪費太奢侈，還讓不讓人愉快的玩手機了。天下武功，惟快不破，咱們一塊兒踏上「快」的探索之路吧。

更多有關TCP的基礎理論性文章，能夠看看下面的文章：

七、針對移動網絡「弱」和「慢」的特色，有優化辦法嗎？

答案是：有。

在移動互聯網時代，對咱們的產品和技術追求提出了更高的挑戰，如何從容和優雅的面對，須要先從精神上作好充分的準備，用一套統一的思考和行動準則武裝到牙齒。

歷來就沒有什麼救世主，只有程序猿征服一切技術問題的夢想在空中飄蕩。屢敗屢戰，把過往實踐中的經驗教訓總結出來，共同研討。針對移動網絡的特色，咱們總結一些實用方法，請看下篇《移動端IM開發者必讀(二)：針對移動弱網絡特性的優化方法總結》。

（意猶未盡？請看下篇：《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》）