本文由百度技術(shù)團(tuán)隊(duì)“蔡銳”原創(chuàng)發(fā)表于“百度App技術(shù)”公眾號(hào)，原題為《百度App網(wǎng)絡(luò)深度優(yōu)化系列《二》連接優(yōu)化》，感謝原作者的無(wú)私分享。
一、前言
在《百度APP移動(dòng)端網(wǎng)絡(luò)深度優(yōu)化實(shí)踐分享(一)：DNS優(yōu)化篇》里大家了解到網(wǎng)絡(luò)優(yōu)化一般會(huì)首選優(yōu)化DNS，而接下來(lái)的HTTP協(xié)議成為優(yōu)化的重點(diǎn)，一般優(yōu)化者會(huì)選擇協(xié)議切換，合并請(qǐng)求，精簡(jiǎn)數(shù)據(jù)包大小等手段來(lái)對(duì)HTTP協(xié)議進(jìn)行優(yōu)化，嚴(yán)謹(jǐn)?shù)恼f(shuō)這都不屬于網(wǎng)絡(luò)優(yōu)化的范疇。
HTTP協(xié)議的基礎(chǔ)是連接，所以我們的《百度APP移動(dòng)端網(wǎng)絡(luò)深度優(yōu)化實(shí)踐分享(二)：網(wǎng)絡(luò)連接優(yōu)化篇》應(yīng)運(yùn)而生，希望對(duì)大家在網(wǎng)絡(luò)方向的學(xué)習(xí)和實(shí)踐有所幫助。
本系列文章目錄如下：
（本文同步發(fā)布于：http://www.52im.net/thread-2479-1-1.html）
二、相關(guān)文章
《TCP/IP詳解 - 第17章·TCP：傳輸控制協(xié)議》
《TCP/IP詳解 - 第18章·TCP連接的建立與終止》
《TCP/IP詳解 - 第21章·TCP的超時(shí)與重傳》
《通俗易懂-深入理解TCP協(xié)議（上）：理論基礎(chǔ)》
《通俗易懂-深入理解TCP協(xié)議（下）：RTT、滑動(dòng)窗口、擁塞處理》
《理論經(jīng)典：TCP協(xié)議的3次握手與4次揮手過(guò)程詳解》
《現(xiàn)代移動(dòng)端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請(qǐng)求速度、弱網(wǎng)適應(yīng)、安全保障》
《移動(dòng)端IM開(kāi)發(fā)者必讀(一)：通俗易懂，理解移動(dòng)網(wǎng)絡(luò)的“弱”和“慢”》
《移動(dòng)端IM開(kāi)發(fā)者必讀(二)：史上最全移動(dòng)弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》
三、技術(shù)背景
連接優(yōu)化需要解決兩個(gè)核心問(wèn)題：
1）連接建立耗時(shí)較長(zhǎng)，導(dǎo)致請(qǐng)求的總時(shí)長(zhǎng)變長(zhǎng)，進(jìn)而影響用戶體驗(yàn)；
2）在多變的網(wǎng)絡(luò)環(huán)境下，連接建立的過(guò)程可能會(huì)失敗，導(dǎo)致成功率下降，進(jìn)而影響用戶體驗(yàn)。
百度App承載著億級(jí)流量，對(duì)于每一個(gè)請(qǐng)求都需要追求耗時(shí)短，成功率高的體驗(yàn)。從協(xié)議角度出發(fā)，如何才能做到這一點(diǎn)呢？首先我們來(lái)看下建立連接耗時(shí)的原理。
▲ 建立連接耗時(shí)的原理
從上圖我們能清晰的看出：
1）DNS Query需要1個(gè)RTT（Round-Trip Time，即往返時(shí)間），百度App都是基于HTTPDNS服務(wù)的，所以大部分會(huì)命中緩存，如果降級(jí)走了系統(tǒng)DNS，也會(huì)命中緩存，命中不了的由于是基于UDP協(xié)議，所以在連接耗時(shí)上沒(méi)有太大的影響，線上的數(shù)據(jù)也能說(shuō)明這點(diǎn)；
2）TCP要經(jīng)歷SYN，SYN/ACK，ACK三次握手的1.5個(gè)RTT，不過(guò)ACK和ClientHello合并了，所以就是1個(gè)RTT；
3）TLS（Transport Layer Security，即傳輸層安全性協(xié)議）需要經(jīng)過(guò)握手和密鑰交換2個(gè)RTT。
綜上所述：DNS、TLS、TCP握手階段用了4個(gè)RTT才到了ApplicationData階段，也就是數(shù)據(jù)開(kāi)始傳輸階段。
通過(guò)上面的分析可以總結(jié)出，如果我們能盡量的將TLS和TCP的RTT減少，將會(huì)大大降低連接耗時(shí)的時(shí)間。
四、連接優(yōu)化我們都能做什么？
百度App的優(yōu)化目標(biāo)分為兩類，一類是TLS的連接優(yōu)化，一類是TCP的連接優(yōu)化。
下面，我們將分別介紹基于這兩種優(yōu)化的思路和實(shí)踐總結(jié)。
五、連接優(yōu)化之“TLS的連接優(yōu)化”
TLS的連接優(yōu)化，需要服務(wù)端和客戶端都需要支持，共同完成優(yōu)化手段，包括Session Resumption和False Start。
5.1 Session Resumption
Session Resumption中文意思是會(huì)話復(fù)用，下圖講解了Session Resumption的協(xié)議原理。
▲ Session Resumption的協(xié)議原理
通過(guò)上圖可以看出TLS密鑰協(xié)商交換的過(guò)程沒(méi)有了，但具體是如何實(shí)現(xiàn)的呢？包含兩種方式，一種是Sesssion Identifier，一種是Session Ticket。
1）Session Identifier：
Session Identifier中文為會(huì)話標(biāo)識(shí)符，更像我們熟知的session的概念。是 TLS 握手中生成的 Session ID。服務(wù)端會(huì)將Session ID保存起來(lái)，客戶端也會(huì)存儲(chǔ)Session ID，在后續(xù)的ClientHello中帶上它，服務(wù)端如果能找到匹配的信息，就可以完成一次快速握手。
2）Session Ticket：
Session Identifier存在一些弊端，比如客戶端多次請(qǐng)求如果沒(méi)有落在同一臺(tái)機(jī)器上就無(wú)法找到匹配的信息，但Session Ticket可以。Session Ticket更像我們熟知的cookie的概念，Session Ticket用只有服務(wù)端知道的安全密鑰加密過(guò)的會(huì)話信息，保存在客戶端上。客戶端在ClientHello時(shí)帶上了Session Ticket，服務(wù)器如果能成功解密就可以完成快速握手。
不管是Session Identifier還是Session Ticket都存在時(shí)效性問(wèn)題，不是永久生效，對(duì)于這兩種方式大家可以查看參考資料【4】。百度App的網(wǎng)絡(luò)協(xié)議層對(duì)這兩種方式都是支持的，省去了TLS握手過(guò)程中證書下載，密鑰協(xié)商交換的環(huán)節(jié)，節(jié)省了1個(gè)RTT的時(shí)間。
5.2 False Start
False Start的中文意思是搶跑，下圖講解了False Start的協(xié)議原理。
▲ False Start的協(xié)議原理
上圖很清晰的說(shuō)明在TLS第一步握手成功后，客戶端在發(fā)送Change Cipher Spec Finished的同時(shí)開(kāi)始數(shù)據(jù)傳輸，服務(wù)端在TLS握手完成時(shí)直接返回應(yīng)用數(shù)據(jù)。應(yīng)用數(shù)據(jù)的發(fā)送實(shí)際上并未等到握手全部完成，所以稱之為搶跑。
從結(jié)果看省去了1個(gè)RTT的時(shí)間。False Start有兩個(gè)前提條件：
一是要通過(guò)應(yīng)用層協(xié)議協(xié)商ALPN（Application Layer Protocol Negotiation）握手；
二是要支持前向安全的加密算法。
False Start在未完成握手的情況下就發(fā)送了數(shù)據(jù)，前向安全可以提高安全性，具體協(xié)議實(shí)現(xiàn)，大家可以查看參考資料【3】。百度App的網(wǎng)絡(luò)協(xié)議層對(duì)False Start是支持的。
這里說(shuō)句題外話，其實(shí)TCP層有個(gè)類似的連接優(yōu)化手段叫Fast Open，感興趣的同學(xué)，可以查看參考資料【5】。
5.3 Session Resumption和False Start的區(qū)別
兩者對(duì)于TLS來(lái)說(shuō)都是節(jié)省一個(gè)RTT，Session Resumption在第一次握手時(shí)還是需要2個(gè)RTT，在第二次握手時(shí)才能復(fù)用減少到1個(gè)RTT。False Start是端上的行為，故每次都會(huì)減少到1個(gè)RTT。
六、連接優(yōu)化之“TCP的連接優(yōu)化”
TCP的連接優(yōu)化，我們先從連接池說(shuō)起，首先讓我們來(lái)認(rèn)識(shí)下連接池都有哪些類型。
6.1 連接池
▲ 連接池的類型
上圖展示了連接池的不同類型，都是大家耳熟能詳?shù)膮f(xié)議連接池，有低級(jí)連接池，包含TCP連接池（管理HTTP請(qǐng)求的連接）和WebSocket連接池（管理WebSocket連接）。
有高級(jí)連接池，包括HTTP代理連接池（管理HTTP代理請(qǐng)求的連接），SpdySession連接池（管理SPDY和HTTP/2請(qǐng)求的連接），SOCKS連接池（管理SOCKS和SOCKS5代理的連接），SSL連接池（管理HTTPS請(qǐng)求的連接）。
不同類型的連接池以組合的形式互相復(fù)用能力：
1）SSL連接池管理的是SSLSocket，但SSLSocket又依賴于TCP連接池提供的TCPSocket；
2）HTTP代理連接池如果走HTTP協(xié)議，那么就需要TCP連接池提供TCPSocket，如果走HTTPS協(xié)議，那么就需要SSL連接池提供SSLSocket；
3）SpdySession連接池依賴SSL連接池提供SSLSocket，這里需要說(shuō)明下，雖然HTTP/2協(xié)議沒(méi)有強(qiáng)制綁定HTTPS，但是在實(shí)際開(kāi)發(fā)中確實(shí)都是綁定HTTPS，百度App使用ALPN來(lái)協(xié)商HTTP/2；
4）SOCKS連接池管理的SOCKSSocket和SOCKS5Socket都需要依賴TCP連接池提供的TCPSocket，雖然SOCKS5支持UDP，但cronet網(wǎng)絡(luò)庫(kù)暫時(shí)沒(méi)有實(shí)現(xiàn)；
5）WebSocket連接池依賴TCP連接池提供的TCPSocket，聲明下這里沒(méi)有說(shuō)明WSS（Web Socket Secure）的情況。
TCP連接優(yōu)化是一個(gè)比較復(fù)雜的內(nèi)容，百度App做了針對(duì)性場(chǎng)景優(yōu)化，包括預(yù)連接，連接重建，備用連接，復(fù)合連接。
6.2 預(yù)連接
▲ 預(yù)連接和連接重建
預(yù)連接：預(yù)先創(chuàng)建好的連接。它解決的場(chǎng)景是在App使用階段可以無(wú)耗時(shí)的獲取連接。下面用四個(gè)問(wèn)答來(lái)解釋預(yù)連接。
問(wèn)題一：預(yù)連接是否能解決所有網(wǎng)絡(luò)請(qǐng)求的提前連接建立？
答：答案是否定的，預(yù)連接需要業(yè)務(wù)方進(jìn)行核心業(yè)務(wù)的評(píng)估，針對(duì)核心的域名進(jìn)行預(yù)連接的建立。
問(wèn)題二：預(yù)連接既然針對(duì)的是特定的域名，那么是如何配置的呢？
答：采用域名+連接數(shù)的方式進(jìn)行配置，比如https://a.baidu.com|2，表示給a.baidu.com這個(gè)域名配置兩條預(yù)連接，這里要說(shuō)明下，在HTTP/1.x協(xié)議下，網(wǎng)絡(luò)庫(kù)的實(shí)現(xiàn)都會(huì)對(duì)于單域名有最大連接數(shù)的限制，不同網(wǎng)絡(luò)庫(kù)的個(gè)數(shù)限制不一樣，有5個(gè)也有6個(gè)，但對(duì)于HTTP/2協(xié)議，這個(gè)連接數(shù)就只能是1個(gè)。
問(wèn)題三：預(yù)連接是如何建立的？
答：在網(wǎng)絡(luò)庫(kù)初始化的時(shí)候，會(huì)根據(jù)使用者的配置延遲5s進(jìn)行預(yù)連接的建立，主要是考慮網(wǎng)絡(luò)庫(kù)在冷啟動(dòng)下對(duì)于啟動(dòng)性能的影響，為了保證網(wǎng)絡(luò)庫(kù)的整體性能，預(yù)連接的總個(gè)數(shù)限制在20個(gè)。
問(wèn)題四：預(yù)連接是如何保持的？
答：在網(wǎng)絡(luò)庫(kù)初始化的時(shí)候，除了進(jìn)行預(yù)連接的建立，還會(huì)創(chuàng)建一個(gè)預(yù)連接的定時(shí)器，這個(gè)定時(shí)器會(huì)每隔31s，這個(gè)值的設(shè)定取決于BFE（Baidu Front End，是七層流量的統(tǒng)一接入系統(tǒng)）和BGW（Baidu Gate Way，百度自主研發(fā)的四層負(fù)載均衡平臺(tái)）對(duì)超時(shí)的最小值設(shè)定，根據(jù)使用者的配置重新建立連接。
6.3 連接重建
連接重建，將連接重新建立。它解決的場(chǎng)景是App網(wǎng)絡(luò)狀態(tài)發(fā)生變化，IP地址變化，導(dǎo)致連接不可用。下面用三個(gè)問(wèn)答來(lái)解釋連接重建。
問(wèn)題一：連接重建是否針對(duì)連接池里的所有連接？
答：答案是肯定的。
問(wèn)題二：連接重建的過(guò)程是什么樣的？
答：在網(wǎng)絡(luò)狀態(tài)變化的時(shí)候，第一步會(huì)清除掉連接池里的idle socket，何為idle socket？即空閑socket，對(duì)于從未使用過(guò)的空閑socket超過(guò)60秒清除，對(duì)于使用過(guò)的空閑socket超過(guò)90秒清除。第二步重建連接需要等待200ms，目的是等待DNS先重建完成。
問(wèn)題三：連接重建對(duì)于性能有影響嗎？
答：出于性能考慮，連接重建的連接個(gè)數(shù)限制是100個(gè)。
6.4 備用連接
▲ 備用連接和復(fù)合連接
備用連接，預(yù)備的連接。它解決的場(chǎng)景是正常發(fā)送一個(gè)請(qǐng)求當(dāng)group內(nèi)無(wú)連接可用的時(shí)候（何為group？group是管理socket的最小單元，內(nèi)部包含活躍socket，空閑socket，連接任務(wù)，等待請(qǐng)求）。下面用三個(gè)問(wèn)答來(lái)解釋備用連接。
問(wèn)題一：備用連接是否針對(duì)所有請(qǐng)求？
答：答案是肯定的。
問(wèn)題二：備用連接的過(guò)程是什么樣的？
答：當(dāng)有請(qǐng)求來(lái)臨時(shí)，連接池內(nèi)無(wú)連接可用，會(huì)啟動(dòng)一個(gè)定時(shí)器開(kāi)啟備用連接，定時(shí)器的間隔時(shí)間是250ms，與主連接進(jìn)行競(jìng)爭(zhēng)，如果主連接因?yàn)榫W(wǎng)絡(luò)抖動(dòng)或者網(wǎng)絡(luò)狀態(tài)不好，導(dǎo)致連接失敗，那么備用連接就直接發(fā)送請(qǐng)求。如果主連接成功，那么備用連接就被取消掉。
問(wèn)題三：備用連接的目的是什么？
答：在連接池?zé)o連接的情況下，務(wù)必是要?jiǎng)?chuàng)建連接的，在主連接之外加一個(gè)備用連接，會(huì)大大提升創(chuàng)建連接的成功率，從而提升用戶體驗(yàn)。
6.5 復(fù)合連接
復(fù)合連接，即多條連接。它解決的場(chǎng)景是為了多個(gè)IP地址的連接選取問(wèn)題。下面用三個(gè)問(wèn)答來(lái)解釋復(fù)合連接。
問(wèn)題一：復(fù)合連接是否針對(duì)所有請(qǐng)求？
答：答案是肯定的。復(fù)合連接可以全局開(kāi)關(guān)，百度App現(xiàn)階段暫時(shí)沒(méi)有開(kāi)啟復(fù)合連接。
問(wèn)題二：復(fù)合連接的過(guò)程是什么樣的？
答：眾所周知域名DNS查詢一般情況下會(huì)返回多個(gè)IP，我們以域名查詢返回兩個(gè)IP為例
1）如果結(jié)果中存在IPv6的地址，那么會(huì)優(yōu)先選用IPv6的地址，這個(gè)規(guī)則follow HappyEyeBall機(jī)制（可參考系列一對(duì)于HappyEyeBall的介紹）。
2） 接下來(lái)這兩個(gè)IP會(huì)按照順序嘗試建立連接，如果第一個(gè)IP返回失敗，將立即開(kāi)始連接第二個(gè)IP。
3）如果第一個(gè)IP率先成功返回，那么第二個(gè)IP將被加入連接嘗試列表并停止所有嘗試連接。
4）如果第一個(gè)IP失敗，會(huì)立刻開(kāi)始第二個(gè)IP的連接。
5）如果第一個(gè)IP處于pending狀態(tài)，那么會(huì)啟動(dòng)一個(gè)定時(shí)器，默認(rèn)延遲2s會(huì)發(fā)起第二個(gè)IP的連接，如果是多個(gè)IP將會(huì)遞歸連接，需要特別說(shuō)明下，不同的網(wǎng)絡(luò)制式延遲時(shí)間會(huì)不一樣，這樣體驗(yàn)也會(huì)更好。
問(wèn)題三：復(fù)合連接的目的是什么？
答：復(fù)合連接的好處是提供最優(yōu)的IP選取機(jī)制，但也會(huì)帶來(lái)服務(wù)端的高負(fù)載，所以使用的時(shí)候需要進(jìn)行綜合評(píng)估。
七、連接優(yōu)化的最佳實(shí)踐
百度App目前客戶端網(wǎng)絡(luò)架構(gòu)由于歷史原因還未統(tǒng)一，不過(guò)我們正朝著這個(gè)目標(biāo)努力。
我們的中心思想是以系統(tǒng)網(wǎng)絡(luò)庫(kù)的API調(diào)用接口為中心，上層建立網(wǎng)絡(luò)門面，供外部便捷調(diào)用，底層通過(guò)系統(tǒng)機(jī)制以AOP的方式將cronet（chromium的net模塊）注入進(jìn)系統(tǒng)網(wǎng)路庫(kù)，達(dá)到雙端網(wǎng)絡(luò)架構(gòu)統(tǒng)一，能力復(fù)用。
下面著重介紹下連接優(yōu)化在Android和iOS網(wǎng)絡(luò)架構(gòu)中的位置及實(shí)踐。
7.1 連接優(yōu)化在Android網(wǎng)絡(luò)架構(gòu)的位置及實(shí)踐
▲ 連接優(yōu)化在Android網(wǎng)絡(luò)架構(gòu)的位置
百度App的Android網(wǎng)絡(luò)流量目前都在okhttp之上，上層進(jìn)行了網(wǎng)絡(luò)門面的封裝，封裝內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)和對(duì)外友好的API，目前我們正在進(jìn)行重構(gòu)，默認(rèn)采用Android標(biāo)準(zhǔn)的網(wǎng)絡(luò)接口HttpURLConnection，它的底層由系統(tǒng)提供的okhttp的實(shí)現(xiàn)。
訂制方面利用URL Stream Protocol機(jī)制將HttpURLConnection底層網(wǎng)絡(luò)協(xié)議棧接管為cronet，供各個(gè)業(yè)務(wù)和基礎(chǔ)模塊使用，連接優(yōu)化的所有內(nèi)容在cronet網(wǎng)絡(luò)庫(kù)內(nèi)部實(shí)現(xiàn)。
7.2 連接優(yōu)化在iOS網(wǎng)絡(luò)架構(gòu)的位置及實(shí)踐
▲ 連接優(yōu)化在iOS網(wǎng)絡(luò)架構(gòu)的位置
百度App的iOS網(wǎng)絡(luò)流量目前都在cronet之上，上層我們使用iOS的URL Loading System機(jī)制將cronet stack注入進(jìn)URLSession里，這樣我們就可以直接使用URLSession的API進(jìn)行網(wǎng)絡(luò)的操作而且更易于系統(tǒng)維護(hù)，在上層封裝了網(wǎng)絡(luò)門面，供各個(gè)業(yè)務(wù)和基礎(chǔ)模塊使用。
在cronet內(nèi)部實(shí)現(xiàn)了預(yù)連接（主要針對(duì)百度App的幾個(gè)核心域名進(jìn)行預(yù)連和保活），連接重建（針對(duì)所有請(qǐng)求），備用連接（針對(duì)所有請(qǐng)求），復(fù)合連接（iOS上暫時(shí)沒(méi)有開(kāi)啟），Session Resumption（針對(duì)所有請(qǐng)求），F(xiàn)alse Start（針對(duì)所有請(qǐng)求）。
八、實(shí)際收益
連接優(yōu)化的收益主要體現(xiàn)在網(wǎng)絡(luò)時(shí)延和網(wǎng)絡(luò)成功率上，這兩點(diǎn)收益需要結(jié)合業(yè)務(wù)來(lái)說(shuō)，以百度App Feed刷新這個(gè)典型業(yè)務(wù)場(chǎng)景為例。
Feed刷新文本請(qǐng)求網(wǎng)絡(luò)時(shí)延降低16%，F(xiàn)eed刷新圖片請(qǐng)求網(wǎng)絡(luò)時(shí)延降低12%，可謂收益相當(dāng)明顯。
成功率方面，F(xiàn)eed刷新文本請(qǐng)求成功率提升0.29%，F(xiàn)eed刷新圖片請(qǐng)求成功率提升0.23%，也是非常不錯(cuò)的收益。
九、本文結(jié)語(yǔ)
連接優(yōu)化是個(gè)持續(xù)性的話題，沒(méi)有最優(yōu)只有更優(yōu)。上面介紹的百度App的一些經(jīng)驗(yàn)和做法并不見(jiàn)得完美，但我們會(huì)繼續(xù)深入的優(yōu)化下去，持續(xù)提升百度App的網(wǎng)絡(luò)性能。
以上優(yōu)化由百度App團(tuán)隊(duì)，內(nèi)核團(tuán)隊(duì)，OP團(tuán)隊(duì)共建完成。最后感謝大家的辛苦閱讀，希望對(duì)你有所幫助，后面會(huì)繼續(xù)推出-百度App網(wǎng)絡(luò)深度優(yōu)化系列《三》弱網(wǎng)優(yōu)化，敬請(qǐng)期待。
十、參考資料
[1]https://chromium.googlesource.co ... ild_instructions.md
[2] https://chromium.googlesource.co ... ild_instructions.md
[3] False Start：https://tools.ietf.org/html/rfc7918
[4] Session Resumption：https://tools.ietf.org/html/rfc5077
[5] TCP Fast Open：https://tools.ietf.org/html/rfc7413
（原文鏈接：點(diǎn)此進(jìn)入）
附錄：更多網(wǎng)絡(luò)通信方面的精華文章
《TCP/IP詳解 - 第11章·UDP：用戶數(shù)據(jù)報(bào)協(xié)議》
《TCP/IP詳解 - 第17章·TCP：傳輸控制協(xié)議》
《TCP/IP詳解 - 第18章·TCP連接的建立與終止》
《TCP/IP詳解 - 第21章·TCP的超時(shí)與重傳》
《技術(shù)往事：改變世界的TCP/IP協(xié)議（珍貴多圖、手機(jī)慎點(diǎn)）》
《通俗易懂-深入理解TCP協(xié)議（上）：理論基礎(chǔ)》
《通俗易懂-深入理解TCP協(xié)議（下）：RTT、滑動(dòng)窗口、擁塞處理》
《理論經(jīng)典：TCP協(xié)議的3次握手與4次揮手過(guò)程詳解》
《理論聯(lián)系實(shí)際：Wireshark抓包分析TCP 3次握手、4次揮手過(guò)程》
《計(jì)算機(jī)網(wǎng)絡(luò)通訊協(xié)議關(guān)系圖（中文珍藏版）》
《UDP中一個(gè)包的大小最大能多大？》
《P2P技術(shù)詳解(一)：NAT詳解——詳細(xì)原理、P2P簡(jiǎn)介》
《P2P技術(shù)詳解(二)：P2P中的NAT穿越(打洞)方案詳解》
《P2P技術(shù)詳解(三)：P2P技術(shù)之STUN、TURN、ICE詳解》
《通俗易懂：快速理解P2P技術(shù)中的NAT穿透原理》
《高性能網(wǎng)絡(luò)編程(一)：?jiǎn)闻_(tái)服務(wù)器并發(fā)TCP連接數(shù)到底可以有多少》
《高性能網(wǎng)絡(luò)編程(二)：上一個(gè)10年，著名的C10K并發(fā)連接問(wèn)題》
《高性能網(wǎng)絡(luò)編程(三)：下一個(gè)10年，是時(shí)候考慮C10M并發(fā)問(wèn)題了》
《高性能網(wǎng)絡(luò)編程(四)：從C10K到C10M高性能網(wǎng)絡(luò)應(yīng)用的理論探索》
《高性能網(wǎng)絡(luò)編程(五)：一文讀懂高性能網(wǎng)絡(luò)編程中的I/O模型》
《高性能網(wǎng)絡(luò)編程(六)：一文讀懂高性能網(wǎng)絡(luò)編程中的線程模型》
《不為人知的網(wǎng)絡(luò)編程(一)：淺析TCP協(xié)議中的疑難雜癥(上篇)》
《不為人知的網(wǎng)絡(luò)編程(二)：淺析TCP協(xié)議中的疑難雜癥(下篇)》
《不為人知的網(wǎng)絡(luò)編程(三)：關(guān)閉TCP連接時(shí)為什么會(huì)TIME_WAIT、CLOSE_WAIT》
《不為人知的網(wǎng)絡(luò)編程(四)：深入研究分析TCP的異常關(guān)閉》
《不為人知的網(wǎng)絡(luò)編程(五)：UDP的連接性和負(fù)載均衡》
《不為人知的網(wǎng)絡(luò)編程(六)：深入地理解UDP協(xié)議并用好它》
《不為人知的網(wǎng)絡(luò)編程(七)：如何讓不可靠的UDP變的可靠？》
《不為人知的網(wǎng)絡(luò)編程(八)：從數(shù)據(jù)傳輸層深度解密HTTP》
《網(wǎng)絡(luò)編程懶人入門(一)：快速理解網(wǎng)絡(luò)通信協(xié)議（上篇）》
《網(wǎng)絡(luò)編程懶人入門(二)：快速理解網(wǎng)絡(luò)通信協(xié)議（下篇）》
《網(wǎng)絡(luò)編程懶人入門(三)：快速理解TCP協(xié)議一篇就夠》
《網(wǎng)絡(luò)編程懶人入門(四)：快速理解TCP和UDP的差異》
《網(wǎng)絡(luò)編程懶人入門(五)：快速理解為什么說(shuō)UDP有時(shí)比TCP更有優(yōu)勢(shì)》
《網(wǎng)絡(luò)編程懶人入門(六)：史上最通俗的集線器、交換機(jī)、路由器功能原理入門》
《網(wǎng)絡(luò)編程懶人入門(七)：深入淺出，全面理解HTTP協(xié)議》
《網(wǎng)絡(luò)編程懶人入門(八)：手把手教你寫基于TCP的Socket長(zhǎng)連接》
《網(wǎng)絡(luò)編程懶人入門(九)：通俗講解，有了IP地址，為何還要用MAC地址？》
《技術(shù)掃盲：新一代基于UDP的低延時(shí)網(wǎng)絡(luò)傳輸層協(xié)議——QUIC詳解》
《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術(shù)實(shí)踐分享》
《現(xiàn)代移動(dòng)端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請(qǐng)求速度、弱網(wǎng)適應(yīng)、安全保障》
《聊聊iOS中網(wǎng)絡(luò)編程長(zhǎng)連接的那些事》
《移動(dòng)端IM開(kāi)發(fā)者必讀(一)：通俗易懂，理解移動(dòng)網(wǎng)絡(luò)的“弱”和“慢”》
《移動(dòng)端IM開(kāi)發(fā)者必讀(二)：史上最全移動(dòng)弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》
《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（上篇）》
《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（下篇）》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設(shè)計(jì)思路》
《腦殘式網(wǎng)絡(luò)編程入門(一)：跟著動(dòng)畫來(lái)學(xué)TCP三次握手和四次揮手》
《腦殘式網(wǎng)絡(luò)編程入門(二)：我們?cè)谧x寫Socket時(shí)，究竟在讀寫什么？》
《腦殘式網(wǎng)絡(luò)編程入門(三)：HTTP協(xié)議必知必會(huì)的一些知識(shí)》
《腦殘式網(wǎng)絡(luò)編程入門(四)：快速理解HTTP/2的服務(wù)器推送(Server Push)》
《腦殘式網(wǎng)絡(luò)編程入門(五)：每天都在用的Ping命令，它到底是什么？》
《腦殘式網(wǎng)絡(luò)編程入門(六)：什么是公網(wǎng)IP和內(nèi)網(wǎng)IP？NAT轉(zhuǎn)換又是什么鬼？》
《以網(wǎng)游服務(wù)端的網(wǎng)絡(luò)接入層設(shè)計(jì)為例，理解實(shí)時(shí)通信的技術(shù)挑戰(zhàn)》
《邁向高階：優(yōu)秀Android程序員必知必會(huì)的網(wǎng)絡(luò)基礎(chǔ)》
《全面了解移動(dòng)端DNS域名劫持等雜癥：技術(shù)原理、問(wèn)題根源、解決方案等》
《美圖App的移動(dòng)端DNS優(yōu)化實(shí)踐：HTTPS請(qǐng)求耗時(shí)減小近半》
《Android程序員必知必會(huì)的網(wǎng)絡(luò)通信傳輸層協(xié)議——UDP和TCP》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(一)：通信交換技術(shù)的百年發(fā)展史(上)》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(二)：通信交換技術(shù)的百年發(fā)展史(下)》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(三)：國(guó)人通信方式的百年變遷》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(四)：手機(jī)的演進(jìn)，史上最全移動(dòng)終端發(fā)展史》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(五)：1G到5G，30年移動(dòng)通信技術(shù)演進(jìn)史》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(六)：移動(dòng)終端的接頭人——“基站”技術(shù)》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(七)：移動(dòng)終端的千里馬——“電磁波”》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(八)：零基礎(chǔ)，史上最強(qiáng)“天線”原理掃盲》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(九)：無(wú)線通信網(wǎng)絡(luò)的中樞——“核心網(wǎng)”》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(十)：零基礎(chǔ)，史上最強(qiáng)5G技術(shù)掃盲》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(十一)：為什么WiFi信號(hào)差？一文即懂！》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(十二)：上網(wǎng)卡頓？網(wǎng)絡(luò)掉線？一文即懂！》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(十三)：為什么手機(jī)信號(hào)差？一文即懂！》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(十四)：高鐵上無(wú)線上網(wǎng)有多難？一文即懂！》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(十五)：理解定位技術(shù)，一篇就夠》
《百度APP移動(dòng)端網(wǎng)絡(luò)深度優(yōu)化實(shí)踐分享(一)：DNS優(yōu)化篇》
《百度APP移動(dòng)端網(wǎng)絡(luò)深度優(yōu)化實(shí)踐分享(二)：網(wǎng)絡(luò)連接優(yōu)化篇》
>> 更多同類文章 ……
（本文同步發(fā)布于：http://www.52im.net/thread-2479-1-1.html）