1、引言
網絡優化對于移動端App產品的用戶體驗至關重要，也與公司的運營和營收息息相關。
這里列舉兩個公開的數據：
“《頁面加載超過3秒，57%的用戶會離開》”
“《Amazon頁面加載延長1秒，一年就會減少16億美金營收》”
網絡性能對于用戶體驗的影響，將非常直接地反饋到業務的運營上。
而且，移動網絡固有的弱網問題、DNS問題、連接性能等等都無法跟傳統的固定網絡相比。所以，優化移動端網絡，顯的尤其必要。
對于即時通訊應用（IM、消息推送）的開發者來說，無論是短連接還是長連接優化，都會直接體現在APP的體驗上，必竟IM或類IM應用都是用戶使用頻度很高的場景，網絡有關的體驗問題稍有懈怠，就會被用戶無限放大，所以回避也不是解決問題的正確之道。
有鑒于此，即時通訊網整理收集了相當多有關移動弱網的文章（包括本篇），希望能為你移動端網絡優化帶來一些啟發。
本文同步發布于“即時通訊技術圈”公眾號，歡迎關注：
2、本文作者
周輝：美團點評移動技術專家，移動架構負責人。移動端開發10年以上經驗。
* 領導和參加過公司大部分移動客戶端產品的架構設計和業務開發；
* 2010 年加入原大眾點評，現專注于美團點評客戶端底層架構的開發和維護；
* 2016 年所負責的移動端通信架構獲得公司級別技術突破大獎。
3、相關文章
《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》（推薦）
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》（推薦）
《全面了解移動端DNS域名劫持等雜癥：原理、根源、HttpDNS解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減小近半》
《百度APP移動端網絡深度優化實踐分享(一)：DNS優化篇》（推薦）
《百度APP移動端網絡深度優化實踐分享(二)：網絡連接優化篇》（推薦）
《百度APP移動端網絡深度優化實踐分享(三)：移動端弱網優化篇》
《愛奇藝移動端網絡優化實踐分享：網絡請求成功率優化篇》（推薦）
《5G時代已經到來，TCP/IP老矣，尚能飯否？》
《微信Mars：微信內部正在使用的網絡層封裝庫，即將開源》
《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《談談移動端 IM 開發中登錄請求的優化》
《騰訊原創分享(一)：如何大幅提升移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》
《騰訊原創分享(三)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》
《IM開發者的零基礎通信技術入門(十一)：為什么WiFi信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十二)：上網卡頓？網絡掉線？一文即懂！》
《IM開發者的零基礎通信技術入門(十三)：為什么手機信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十四)：高鐵上無線上網有多難？一文即懂！》
4、內容概述
如何防止網絡通信被劫持？
如何提升用戶頁面打開速度？
老板反饋頁面打不開時你該怎么辦？
來看看美團點評客戶端網絡優化實踐中的經驗分享吧。
在這篇文章里你可以了解到美團點評移動架構團隊在提升移動通信質量方面所做的嘗試，以及逐漸發展出的一整套監控和通信方案，為你優化自己App的網絡通信質量打開新的思路。
5、問題現狀
在討論解決方法之前，我們來梳理一下，在移動網絡請求過程中，主要都出現了哪些最常見的問題？
▼ 首先：是網絡不可用問題。主要由以下幾種原因導致：
- 1）GFW的攔截，原因你懂的；
- 2）DNS的劫持，端口的意外封禁等；
- 3）偏遠地區網絡基礎設施比較差。
▼ 其次：是網絡加載時間長問題。這些原因包括：
- 1）移動設備出于省電的目的，發出網絡請求前需要先預熱通信芯片；
- 2）網絡請求需要跨網絡運營商，物理路徑長；
- 3）HTTP請求是基于Socket設計的，請求發起之前會經歷三次握手，斷開時又會進行四次揮手。
▼ 最后：是HTTP協議的數據安全問題。具體的原因有：
- 1）HTTP協議的數據容易被抓包；
- 2）Post包體數據經過加密能夠避免泄露，但協議中的URL和header部分還是會暴露給抓包軟件（HTTPS也面臨相似的問題）；
- 3）運營商數據惡意篡改嚴重。
如下圖中，App的網頁中就被運營商插入了廣告：
當然，上述問題并非我們憑空想象。在美團點評，監控團隊開發了基于端到端的客戶端監控平臺。這里要先解釋一下“端到端”的含義：是指請求從客戶端發出到服務端響應返回的整個過程。它區別于后臺服務監控，是一種從用戶角度觀察到的真實體驗監控。
通過美團點評的監控工具，可以很清晰地看到各種網絡原因和占比：
6、短連接優化方案1：域名合并
面對上節中提到的網絡問題，我們首先在HTTP短連請求中進行了一些優化嘗試。
隨著開發規模逐漸擴大，各業務團隊出于獨立性和穩定性的考慮，紛紛申請了自己的三級域名。
App中的API域名越來越多，如下所示：
search.api.dianping.com
ad.api.dianping.com
tuangou.api.dianping.com
waimai.api.dianping.com
movie.api.dianping.com
… ...
App中域名多了之后，將面臨下面幾個問題：
- 1）HTTP請求需要跟不同服務器建立連接，增加了網絡的并發連接數量損耗；
- 2）每條域名都需要經過DNS服務來解析服務器IP。
如果想將所有的三級域名都合并為一個域名，又會面臨巨大的項目推進難題。因為不同業務團隊當初正是出于獨立性和穩定性的考慮才把域名進行拆分，現在再想把域名合并起來，勢必會遭遇巨大的阻力。
所以我們面臨的是：
- 1）既要將域名合并；
- 2）又要提升網絡連接效率；
- 3）又不能改造后端業務服務器。
經過討論，我們想到了一個折中的方案。
如上圖所示，該方案的核心思想在于：保持客戶端業務層代碼編寫的網絡請求與后端業務服務器收到的請求保持一致，請求發出前，在客戶端網絡層對域名收編，請求送入后端，在SLB（Server Load Balancing）中對域名進行還原。
▼ 網絡請求發出前，在客戶端的網絡底層將URL中的域名做簡單的替換，我們稱之為“域名收編”。
例如：URL “http:// ad.api.dianping.com/command?param1=123" 在網絡底層被修改為 “http:// api.dianping.com/ad/command?param1=123" 。
這里，將域名“ad.api.dianping.com”替換成了”api.dianping.com”，而緊跟在域名后的其后的”ad”表示了這是一條與廣告業務有關的域名請求。
依此類推，所有URL的域名都被合并為“api.dianping.com”。子級域名信息被隱藏在了域名后的path中。
▼ 被改造的請求被送到網絡后端，在SLB中，擁有與客戶端網絡層相反的一套域名反收編邏輯，稱為“域名還原”。
例如：“http://api.dianping.com/ad/command?param1=123" 在SLB中被還原為 “http://ad.api.dianping.com/command?param1=123" 。 SLB的作用是將請求分發到不同的業務服務器，在經過域名還原之后，請求已經與客戶端業務代碼中原始請求一致了。
該方案具有如下優勢：
- 1）域名得到了收編，減少了DNS調用次數，降低了DNS劫持風險；
- 2）針對同一域名，可以利用Keep-Alive來復用Http的連接；
- 3）客戶端業務層不需要修改代碼，后端業務服務也不需要進行任何修改。
7、短連接優化方案2：IP直連
經過域名合并方案，我們已經將所有的域名都統一成了“api.dianping.com”。針對這唯一的域名，我們可以在客戶端架設自己的DNS服務。
方案很簡單：
- 1）程序啟動的時候拉取“api.dianping.com”對應的所有的IP列表；
- 2）對所有IP進行跑馬測試，找到速度最快的IP（后續所有的HTTPS請求都將域名更換為跑馬最快的IP即可）。
舉個例子，假如：經過跑馬測試發現域名“api.dianping.com”對應最快的IP是“1.23.456.789”。
URL“http:// api.dianping.com/ad/command?param1=123”將被替換為“http:// 1.23.456.789/ad/command?param1=123”
IP直連方案有下面幾大優勢：
- 1）摒棄了系統DNS，減少外界干擾，擺脫DNS劫持困擾；
- 2）自建DNS更新時機可以控制；
- 3）IP列表更換方便。
此外，如果你的App域名沒有經過合并，域名比較多，也建議可以嘗試使用HttpDNS方案。
可以參考以下幾篇文章：
《全面了解移動端DNS域名劫持等雜癥：技術原理、問題根源、解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減小近半》
《百度APP移動端網絡深度優化實踐分享(一)：DNS優化篇》
《愛奇藝移動端網絡優化實踐分享：網絡請求成功率優化篇》
另外，IP直連方案對HTTPS中證書的處理需要注意：HTTPS由于要求證書綁定域名，如果做IP直連方案可能會遇到一些麻煩，這時我們需要對客戶端的HTTPS的域名校驗部分進行改造，參見《https信任證書的三種方式》 。
經過域名合并加上IP直連方案改造后，HTTP短連的端到端成功率從95%提升到97.5%，網絡延時從1500毫秒降低到了1000毫秒，可謂小投入大產出。
8、進一步提升端到端成功率：長連通道的建設
接下來要想進一步提升端到端成功率，就要開始進行長連通道建設了。
8.1 HTTP/2技術
提到長連通道建設，首先讓人想到的應該是HTTP/2技術（見：《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》）——它具有異步連接多路復用、頭部壓縮、請求響應管線化等眾多優點。
如果查看HTTP/2的拓撲結構，其實非常簡單：
HTTP/2在客戶端與服務器之間建立長連通道，將同一域名的請求都放在長連通道上進行。
這種拓撲結構有如下一些缺點：
- 1）請求基于DNS，仍將面臨DNS劫持風險；
- 2）不同域名的請求需要建立多條連接；
- 3）網絡通道難以優化：客戶端與服務器之間是公網鏈路，如果在多地部署服務器，成本消耗又會很大；
- 4）業務改造難度大：部署HTTP/2，需要對業務服務器進行改造，而且使用的業務服務器越多，需要改造的成本也越大；
- 5）網絡協議可訂制程度小。
8.2 代理長連的模式
與HTTP/2相區別，我們這里推薦另一種代理長連的模式。
這種模式的拓撲圖如下：
基本思路為：
- 1）在客戶端與業務服務器之間架設代理長連服務器；
- 2）客戶端與代理服務器建立TCP長連通道；
- 3）客戶端的HTTP請求被轉換為了TCP通道上的二進制數據包；
- 4）代理服務器負責與業務服務器進行HTTP請求，請求的結果通過長連通道送回客戶端。
與HTTP/2模式對比，代理長連模式具有下面一些優勢：
1）對DNS無依賴：
客戶端與代理服務器之間的長連通道是通過IP建立的，與DNS沒有關系。客戶端的HTTP請求被轉換為二進制數據流送到代理服務器，也不需要進行DNS解析。代理服務器轉發請求到業務服務器時，都處于同一內網，因此可以自己搭建DNS服務，減少對公網DNS服務的依賴。從這個層面上說，代理長連模式天生具有防DNS劫持的能力。
2）不同域名的請求可以復用同一條長連通道；
3）通道易優化：
與部署業務服務器相比，部署代理長連服務器的代價就小了很多，可以在全國甚至全世界多地部署代理長連服務器。客戶端在選擇代理長連服務器時，可以通過跑馬找到最快的服務器IP進行連接。另一方面，代理服務器與業務服務器之間的網絡通道也可以進行優化，通過架設專線或者租用騰訊云等方式可以大大提升通道服務質量；
4）對業務完全透明：
客戶端的業務代碼只要接入網絡層的SDK即可，完全不用關心網絡請求使用的是長連通道還是短連通道。代理服務器將客戶端的請求還原為HTTP短連方式送到業務服務器，業務服務器不需要進行任何改造。
5）網絡協議完全自定義。
8.3 自建代理長連模式的過程
自建長連建設大概可以分為以下幾個周期。
▼ ① 中轉服務的開發和部署：
作為開發的初級階段，這一時期的任務主要是搭建代理中轉服務器，并架設完整鏈路結構。
▼ ② 加密通道的建設：
為了保護TCP通道上數據的安全性，客戶端與代理長連服務器之間的二進制通信數據可以利用加密來保障數據安全。
▼ ③ 專線建設：
在代理長連服務器與后臺業務服務器之間建設專線。使用專線，可以大大降低公網環境的干擾，保障服務的穩定性。
▼ ④ 自動降級Failover建設：
由于客戶端的請求都放在TCP通道上進行，當代理長連服務器需要升級或者由于極端情況發生了故障時，將會造成客戶端的整體網絡服務不可用。
為了解決這個問題，我們準備了Failover降級方案——當TCP通道無法建立或者發生故障時，可以使用UDP面向無連接的特性提供另一條請求通道，或者繞過代理長連服務器之間向業務服務器發起HTTP公網請求（本文的后面章節將展示Failover機制的實際效果）。
▼ ⑤ 多地部署接入點：
在全國多地部署代理長連接入點。客戶端與接入點建立長連通道時，可以選擇最快的服務器就近接入，從而大大降低通道連接速度并提升通信質量。 我們在近兩年的網絡優化實踐中，將客戶端的網絡通道服務整理成了一個獨立的SDK，SDK包含了自建的長連通信服務。
完整的網絡通道拓撲圖如下所示：
圖中網絡通道SDK包含了三大通信通道：
1）CIP通道：
CIP通道就是上文中提到的自建代理長連通道。CIP是China Internet Plus的縮寫，為美團點評集團的注冊英文名稱。App中絕大部分的請求通過CIP通道中的TCP子通道與長連服務器（CIP Connection Server）通信，長連服務器將收到的請求代理轉發到業務服務器（API Server）。由于TCP子通道在一些極端情況下可能會無法工作，我們在CIP通道中額外部署了UDP子通道和HTTP子通道，其中HTTP子通道通過公網繞過長連服務器與業務服務器進行直接請求。CIP通道的平均端到端成功率目前已達99.7%，耗時平均在350毫秒左右；
2）WNS通道：
出于災備的需要，騰訊的WNS目前仍被包含在網絡通道SDK中。當極端情況發生，CIP通道不可用時，WNS通道還可以作為備用的長連替代方案；
3）HTTP通道：
此處的HTTP通道是在公網直接請求API Server的網絡通道。出于長連通道重要性的考慮，上傳和下載大數據包的請求如果放在長連上進行都有可能導致長連通道的擁堵，因此我們將CDN訪問、文件上傳和頻繁的日志上報等放在公網利用HTTP短連進行請求，同時也減輕代理長連服務器的負擔。
推送方案：在網絡通道拓撲圖的右上角，有個Push Server。它是考慮到TCP通道的雙工特性，為網絡通道SDK提供推送的能力。利用通知推送，可以在服務器數據發生變化時及時通知客戶端。推送方案可以替換掉代碼中常見的耗時低效的輪詢方案。
9、實際案例展示
下圖展示了某開機接口在接入長連后的端到端成功率對比：
上圖中黑色曲線是某開機接口在短連通道下的成功率曲線。成功率平均只有81%，抖動的特別劇烈，說明網絡服務穩定性不夠。藍色曲線是同一接口在長連通道下的成功率曲線。成功率平均已達到99%，抖動大幅減小。
成功延時對比圖：
上圖中展示了同樣情況下的成功延時曲線。藍色線為長連延時曲線，黑色線為短連延時曲線。
接下來我們看Failover的效果展示圖。下圖展示了2015年的一次長連服務器故障。
當時Android客戶端采用了Failover方案，在長連不可用時Failover到短鏈或者UDP通道上。與未采用Failover方案的iOS客戶端相比，Failover機制在維持網絡整體可用性方面體現出了非常大的優勢。
10、網絡配置系統展示
網絡通道SDK包含了CIP | WNS | HTTP 三大通道，不同的通道具有各自的優缺點，控制各請求選擇合適的網絡通道成了迫在眉睫的重要課題。
為此我們開發了網絡配置系統，通過下發指令，調整App中網絡通道SDK中的通道選擇策略，可以控制不同的API請求動態切換網絡通道。
下圖是某接口的線上通道切換示意圖：
上圖中展示了某接口切換WNS通道的過程。圖中的黑色線代表短連通道下的請求數量曲線，藍色線代表WNS通道下的請求數量曲線。通過線上控制系統下發了通道切換指令后，絕大部分的短連請求在5分鐘之內被切換成了WNS通道請求。
11、在優化開發過程中，我們發現的規律
在移動端網絡優化開發過程中，我們發現以下這些規律。
▼ 1）長連通道建立越早，成功率越高：
長連通道越早建立，越多的請求能夠在長連通道上進行。特別是當App剛打開時，數量眾多的請求同時需要發出。
面對這種情況，我們采取的策略是首先建立長連通道，將眾多請求放入等待發送隊列中，待長連通道建立完畢后再將等待隊列中的請求放在長連通道上依次送出。
采用這種策略后，我們發現啟動時的接口成功率平均提升了1.4%，延時平均降低了160毫秒。
▼ 2）TCP數據包越大，傳輸時間越長：
如果長連通道未采用類似HTTP/2中的數據切片技術，大的數據包非常容易導致長連通道的堵塞。
▼ 3）底層SDK上線新功能一定要有線上降級手段：
當新功能上線了發生故障時，可以通過開關或參數控制，或是采用ABTest方式等進行降級，防止故障擴大化。
▼ 4）iOS和Android系統網絡庫存在很多默認行：
例如系統網絡庫會在內部處理網絡重定向，再比如請求頭中如果沒有填寫Accept-Encoding或Content-Type等字段，系統網絡庫會自動填寫默認值。
▼ 5）一個容易忽視的地方：
HTTP的請求頭鍵值對中的的鍵是允許相同和重復的。例如下圖所示的”Set-Cookie”字段就是包含了多組的相同的鍵名稱。與之類似的還有”Cookie”字段。在長連通信中，如果對header中的鍵值對用不加處理的字典方式保存和傳輸，就會造成數據的丟失。
12、小小的建議
對于正在成長中的創業公司，我們有如下改善網絡狀況的建議。
1）收攏網絡底層：隨著公司的成長，開發團隊越來越多，不可避免的將會引入越來越多的網絡庫。網絡庫多了之后，再對網絡請求進行集中管理就非常困難了。我們的建議是在網絡庫與業務代碼之間架設自己的網絡層，業務的網絡請求全部經過網絡層代碼進行請求。這樣未來進行底層網絡庫的更換，或者網絡通道的優化將變得容易很多。
2）使用網絡監控：引入網絡監控機制，發現網絡問題。這里推薦我公司開發的開源的Cat監控系統。Cat開源地址為：http://github.com/dianping/cat 。
3）嘗試進行短連優化：前文中提到的域名合并和IP直連方案都是簡單有效的手段。
4）可以嘗試HTTP/2或騰訊WNS長連服務（注：騰訊云的WNS已停止服務）。
附錄：更多網絡編程基礎資料
[1.1] 移動端弱網相關資料：
《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》
《聊聊iOS中網絡編程長連接的那些事》
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
《全面了解移動端DNS域名劫持等雜癥：技術原理、問題根源、解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減小近半》
《百度APP移動端網絡深度優化實踐分享(一)：DNS優化篇》
《百度APP移動端網絡深度優化實踐分享(二)：網絡連接優化篇》
《百度APP移動端網絡深度優化實踐分享(三)：移動端弱網優化篇》
《愛奇藝移動端網絡優化實踐分享：網絡請求成功率優化篇》
《美團點評的移動端網絡優化實踐：大幅提升連接成功率、速度等》
《5G時代已經到來，TCP/IP老矣，尚能飯否？》
《微信Mars：微信內部正在使用的網絡層封裝庫，即將開源》
《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《談談移動端 IM 開發中登錄請求的優化》
《騰訊原創分享(一)：如何大幅提升移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》
《騰訊原創分享(三)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》
《IM開發者的零基礎通信技術入門(十一)：為什么WiFi信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十二)：上網卡頓？網絡掉線？一文即懂！》
《IM開發者的零基礎通信技術入門(十三)：為什么手機信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十四)：高鐵上無線上網有多難？一文即懂！》
>> 更多同類文章 ……
[1.2] 網絡編程基礎資料：
《TCP/IP詳解 - 第11章·UDP：用戶數據報協議》
《TCP/IP詳解 - 第17章·TCP：傳輸控制協議》
《TCP/IP詳解 - 第18章·TCP連接的建立與終止》
《TCP/IP詳解 - 第21章·TCP的超時與重傳》
《技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點）》
《通俗易懂-深入理解TCP協議（上）：理論基礎》
《通俗易懂-深入理解TCP協議（下）：RTT、滑動窗口、擁塞處理》
《理論經典：TCP協議的3次握手與4次揮手過程詳解》
《理論聯系實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》
《計算機網絡通訊協議關系圖（中文珍藏版）》
《UDP中一個包的大小最大能多大？》
《P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介》
《P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解(基本原理篇)》
《P2P技術詳解(三)：P2P中的NAT穿越(打洞)方案詳解(進階分析篇)》
《P2P技術詳解(四)：P2P技術之STUN、TURN、ICE詳解》
《通俗易懂：快速理解P2P技術中的NAT穿透原理》
《高性能網絡編程(一)：單臺服務器并發TCP連接數到底可以有多少》
《高性能網絡編程(二)：上一個10年，著名的C10K并發連接問題》
《高性能網絡編程(三)：下一個10年，是時候考慮C10M并發問題了》
《高性能網絡編程(四)：從C10K到C10M高性能網絡應用的理論探索》
《高性能網絡編程(五)：一文讀懂高性能網絡編程中的I/O模型》
《高性能網絡編程(六)：一文讀懂高性能網絡編程中的線程模型》
《Java的BIO和NIO很難懂？用代碼實踐給你看，再不懂我轉行！》
《不為人知的網絡編程(一)：淺析TCP協議中的疑難雜癥(上篇)》
《不為人知的網絡編程(二)：淺析TCP協議中的疑難雜癥(下篇)》
《不為人知的網絡編程(三)：關閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》
《不為人知的網絡編程(四)：深入研究分析TCP的異常關閉》
《不為人知的網絡編程(五)：UDP的連接性和負載均衡》
《不為人知的網絡編程(六)：深入地理解UDP協議并用好它》
《不為人知的網絡編程(七)：如何讓不可靠的UDP變的可靠？》
《不為人知的網絡編程(八)：從數據傳輸層深度解密HTTP》
《不為人知的網絡編程(九)：理論聯系實際，全方位深入理解DNS》
《網絡編程懶人入門(一)：快速理解網絡通信協議（上篇）》
《網絡編程懶人入門(二)：快速理解網絡通信協議（下篇）》
《網絡編程懶人入門(三)：快速理解TCP協議一篇就夠》
《網絡編程懶人入門(四)：快速理解TCP和UDP的差異》
《網絡編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優勢》
《網絡編程懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》
《網絡編程懶人入門(七)：深入淺出，全面理解HTTP協議》
《網絡編程懶人入門(八)：手把手教你寫基于TCP的Socket長連接》
《網絡編程懶人入門(九)：通俗講解，有了IP地址，為何還要用MAC地址？》
《網絡編程懶人入門(十)：一泡尿的時間，快速讀懂QUIC協議》
《網絡編程懶人入門(十一)：一文讀懂什么是IPv6》
《技術掃盲：新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解》
《讓互聯網更快：新一代QUIC協議在騰訊的技術實踐分享》
《聊聊iOS中網絡編程長連接的那些事》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（上篇）》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（下篇）》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》
《腦殘式網絡編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》
《腦殘式網絡編程入門(二)：我們在讀寫Socket時，究竟在讀寫什么？》
《腦殘式網絡編程入門(三)：HTTP協議必知必會的一些知識》
《腦殘式網絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)》
《腦殘式網絡編程入門(五)：每天都在用的Ping命令，它到底是什么？》
《腦殘式網絡編程入門(六)：什么是公網IP和內網IP？NAT轉換又是什么鬼？》
《腦殘式網絡編程入門(七)：面視必備，史上最通俗計算機網絡分層詳解》
《腦殘式網絡編程入門(八)：你真的了解127.0.0.1和0.0.0.0的區別？》
《以網游服務端的網絡接入層設計為例，理解實時通信的技術挑戰》
《邁向高階：優秀Android程序員必知必會的網絡基礎》
《全面了解移動端DNS域名劫持等雜癥：技術原理、問題根源、解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減小近半》
《Android程序員必知必會的網絡通信傳輸層協議——UDP和TCP》
《IM開發者的零基礎通信技術入門(一)：通信交換技術的百年發展史(上)》
《IM開發者的零基礎通信技術入門(二)：通信交換技術的百年發展史(下)》
《IM開發者的零基礎通信技術入門(三)：國人通信方式的百年變遷》
《IM開發者的零基礎通信技術入門(四)：手機的演進，史上最全移動終端發展史》
《IM開發者的零基礎通信技術入門(五)：1G到5G，30年移動通信技術演進史》
《IM開發者的零基礎通信技術入門(六)：移動終端的接頭人——“基站”技術》
《IM開發者的零基礎通信技術入門(七)：移動終端的千里馬——“電磁波”》
《IM開發者的零基礎通信技術入門(八)：零基礎，史上最強“天線”原理掃盲》
《IM開發者的零基礎通信技術入門(九)：無線通信網絡的中樞——“核心網”》
《IM開發者的零基礎通信技術入門(十)：零基礎，史上最強5G技術掃盲》
《IM開發者的零基礎通信技術入門(十一)：為什么WiFi信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十二)：上網卡頓？網絡掉線？一文即懂！》
《IM開發者的零基礎通信技術入門(十三)：為什么手機信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十四)：高鐵上無線上網有多難？一文即懂！》
《IM開發者的零基礎通信技術入門(十五)：理解定位技術，一篇就夠》
《技術大牛陳碩的分享：由淺入深，網絡編程學習經驗干貨總結》
《可能會搞砸你的面試：你知道一個TCP連接上能發起多少個HTTP請求嗎？》
《知乎技術分享：知乎千萬級并發的高性能長連接網關技術實踐》
《5G時代已經到來，TCP/IP老矣，尚能飯否？》
>> 更多同類文章 ……
（本文已同步發布于：http://www.52im.net/thread-3015-1-1.html）