美團點評的移動端網絡優化實踐：大幅提高鏈接成功率、速度等

一、引言

網絡優化對於移動端App產品的用戶體驗相當重要，也與公司的運營和營收息息相關。

這裏列舉兩個公開的數據：

「 《頁面加載超過3秒，57%的用戶會離開》」
「 《Amazon頁面加載延長1秒，一年就會減小16億美金營收》」

網絡性能對於用戶體驗的影響，將很是直接地反饋到業務的運營上。

並且，移動網絡固有的弱網問題、DNS問題、鏈接性能等等都沒法跟傳統的固定網絡相比。因此，優化移動端網絡，顯的尤爲必要。

對於即時通信應用（IM、消息推送）的開發者來講，不管是短鏈接仍是長鏈接優化，都會直接體如今APP的體驗上，必竟IM或類IM應用都是用戶使用頻度很高的場景，網絡有關的體驗問題稍有懈怠，就會被用戶無限放大，因此迴避也不是解決問題的正確之道。

有鑑於此，即時通信網整理收集了至關多有關移動弱網的文章（包括本篇），但願能爲你移動端網絡優化帶來一些啓發。

本文同步發佈於「即時通信技術圈」公衆號，歡迎關注：

本文的來源是：http://www.52im.net/thread-3015-1-1.html

二、本文做者 

周輝：美團點評移動技術專家，移動架構負責人。移動端開發10年以上經驗。

* 領導和參加過公司大部分移動客戶端產品的架構設計和業務開發；
* 2010 年加入原大衆點評，現專一於美團點評客戶端底層架構的開發和維護；
* 2016 年所負責的移動端通訊架構得到公司級別技術突破大獎。

三、相關文章

《 現代移動端網絡短鏈接的優化手段總結：請求速度、弱網適應、安全保障》
《 移動端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開發者的零基礎通訊技術入門(十四)：高鐵上無線上網有多難？一文即懂！》

四、內容概述

如何防止網絡通訊被劫持？
如何提高用戶頁面打開速度？
老闆反饋頁面打不開時你該怎麼辦？

來看看美團點評客戶端網絡優化實踐中的經驗分享吧。 

在這篇文章裏你能夠了解到美團點評移動架構團隊在提高移動通訊質量方面所作的嘗試，以及逐漸發展出的一整套監控和通訊方案，爲你優化本身App的網絡通訊質量打開新的思路。

五、問題現狀

在討論解決方法以前，咱們來梳理一下，在移動網絡請求過程當中，主要都出現了哪些最多見的問題？

▼ 首先：是網絡不可用問題。主要由如下幾種緣由致使：

• 1）GFW的攔截，緣由你懂的；
• 2）DNS的劫持，端口的意外封禁等；
• 3）偏遠地區網絡基礎設施比較差。

▼ 其次：是網絡加載時間長問題。這些緣由包括：

• 1）移動設備出於省電的目的，發出網絡請求前須要先預熱通訊芯片；
• 2）網絡請求須要跨網絡運營商，物理路徑長；
• 3）HTTP請求是基於Socket設計的，請求發起以前會經歷三次握手，斷開時又會進行四次揮手。

▼ 最後：是HTTP協議的數據安全問題。具體的緣由有：

• 1）HTTP協議的數據容易被抓包；
• 2）Post包體數據通過加密可以避免泄露，但協議中的URL和header部分仍是會暴露給抓包軟件（HTTPS也面臨類似的問題）；
• 3）運營商數據惡意篡改嚴重。

以下圖中，App的網頁中就被運營商插入了廣告：

固然，上述問題並不是咱們憑空想象。在美團點評，監控團隊開發了基於端到端的客戶端監控平臺。這裏要先解釋一下「端到端」的含義：是指請求從客戶端發出到服務端響應返回的整個過程。它區別於後臺服務監控，是一種從用戶角度觀察到的真實體驗監控。

經過美團點評的監控工具，能夠很清晰地看到各類網絡緣由和佔比：

六、短鏈接優化方案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/co...3" 在SLB中被還原爲 「http://ad.api.dianping.com/co...3" 。 SLB的做用是將請求分發到不一樣的業務服務器，在通過域名還原以後，請求已經與客戶端業務代碼中原始請求一致了。

該方案具備以下優點：

• 1）域名獲得了收編，減小了DNS調用次數，下降了DNS劫持風險；
• 2）針對同一域名，能夠利用Keep-Alive來複用Http的鏈接；
• 3）客戶端業務層不須要修改代碼，後端業務服務也不須要進行任何修改。

七、短鏈接優化方案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.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提供推送的能力。利用通知推送，能夠在服務器數據發生變化時及時通知客戶端。推送方案能夠替換掉代碼中常見的耗時低效的輪詢方案。

九、實際案例展現

下圖展現了某開機接口在接入長連後的端到端成功率對比：

上圖中黑色曲線是某開機接口在短連通道下的成功率曲線。成功率平均只有81%，抖動的特別劇烈，說明網絡服務穩定性不夠。藍色曲線是同一接口在長連通道下的成功率曲線。成功率平均已達到99%，抖動大幅減少。

成功延時對比圖：

上圖中展現了一樣狀況下的成功延時曲線。藍色線爲長連延時曲線，黑色線爲短連延時曲線。

接下來咱們看Failover的效果展現圖。下圖展現了2015年的一次長連服務器故障。

當時Android客戶端採用了Failover方案，在長連不可用時Failover到短鏈或者UDP通道上。與未採用Failover方案的iOS客戶端相比，Failover機制在維持網絡總體可用性方面體現出了很是大的優點。

十、網絡配置系統展現

網絡通道SDK包含了CIP | WNS | HTTP 三大通道，不一樣的通道具備各自的優缺點，控制各請求選擇合適的網絡通道成了迫在眉睫的重要課題。

爲此咱們開發了網絡配置系統，經過下發指令，調整App中網絡通道SDK中的通道選擇策略，能夠控制不一樣的API請求動態切換網絡通道。

下圖是某接口的線上通道切換示意圖：

上圖中展現了某接口切換WNS通道的過程。圖中的黑色線表明短連通道下的請求數量曲線，藍色線表明WNS通道下的請求數量曲線。經過線上控制系統下發了通道切換指令後，絕大部分的短連請求在5分鐘以內被切換成了WNS通道請求。

十一、在優化開發過程當中，咱們發現的規律

在移動端網絡優化開發過程當中，咱們發現如下這些規律。

▼ 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中的鍵值對用不加處理的字典方式保存和傳輸，就會形成數據的丟失。

十二、小小的建議

對於正在成長中的創業公司，咱們有以下改善網絡情況的建議。

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）