文中由百度搜索技術(shù)性精英團(tuán)隊(duì)“蔡銳”原創(chuàng)發(fā)布于“百度搜索App技術(shù)性”微信公眾號(hào)，原名為《百度搜索App互聯(lián)網(wǎng)深層優(yōu)化系列產(chǎn)品《二》連接優(yōu)化》，謝謝創(chuàng)作者的不求回報(bào)共享。
在《百度搜索APP手機(jī)端互聯(lián)網(wǎng)深層優(yōu)化實(shí)踐活動(dòng)共享(一)：DNS優(yōu)化篇》里大伙兒掌握到互聯(lián)網(wǎng)優(yōu)化一般會(huì)優(yōu)選優(yōu)化DNS，而下面的HTTP協(xié)議變成優(yōu)化的關(guān)鍵，一般優(yōu)化者會(huì)挑選協(xié)議轉(zhuǎn)換，合拼請(qǐng)求，精減數(shù)據(jù)文件尺寸等方式來(lái)對(duì)HTTP協(xié)議開(kāi)展優(yōu)化，認(rèn)真細(xì)致的說(shuō)這都不屬于互聯(lián)網(wǎng)優(yōu)化的范圍。
HTTP協(xié)議的基本是連接，因此大家的《百度搜索APP手機(jī)端互聯(lián)網(wǎng)深層優(yōu)化實(shí)踐活動(dòng)共享(二)：互聯(lián)網(wǎng)連接優(yōu)化篇》應(yīng)時(shí)而生，期待對(duì)大伙兒在互聯(lián)網(wǎng)方位的學(xué)習(xí)培訓(xùn)和實(shí)踐活動(dòng)有一定的協(xié)助。
本系列產(chǎn)品文章內(nèi)容文件目錄以下：
（文中同歩公布于：.1.html）
《TCP/IP詳細(xì)說(shuō)明-第17章·TCP：傳送操縱協(xié)議》
《TCP/IP詳細(xì)說(shuō)明-第18章·TCP連接的創(chuàng)建與停止》
《TCP/IP詳解-第21章·TCP的超時(shí)與重傳》
《淺顯易懂-深層次了解TCP協(xié)議（上）：理論基礎(chǔ)》
《淺顯易懂-深層次了解TCP協(xié)議（下）：RTT、滑動(dòng)窗口、時(shí)延解決》
《基礎(chǔ)理論經(jīng)典：TCP協(xié)議的3次握手與4次招手全過(guò)程詳細(xì)說(shuō)明》
《當(dāng)代手機(jī)端互聯(lián)網(wǎng)短連接的優(yōu)化方式小結(jié)：請(qǐng)求速率、弱網(wǎng)融入、安全防范措施》
《移動(dòng)端IM開(kāi)發(fā)者必讀(一)：通俗易懂，理解移動(dòng)網(wǎng)絡(luò)的“弱”和“慢”》
《手機(jī)端IM開(kāi)發(fā)人員必看(二)：史上*牛全挪動(dòng)弱互聯(lián)網(wǎng)優(yōu)化方式 小結(jié)》
連接優(yōu)化必須處理兩個(gè)核心難題：
1）連接創(chuàng)建用時(shí)較長(zhǎng)，造成 請(qǐng)求的總時(shí)間拉長(zhǎng)，從而危害客戶(hù)體驗(yàn)；
2）在變化多端的網(wǎng)絡(luò)空間下，連接創(chuàng)建的全過(guò)程很有可能會(huì)不成功，造成 通過(guò)率降低，從而危害客戶(hù)體驗(yàn)。
百度搜索App安裝著億級(jí)總流量，針對(duì)每一個(gè)請(qǐng)求都必須追求完美用時(shí)短，成功率較高的感受。從協(xié)議視角考慮，怎樣才可以保證這一點(diǎn)呢？*先大家看來(lái)下創(chuàng)建連接用時(shí)的基本原理。
▲ 創(chuàng)建連接用時(shí)的基本原理
從圖中大家能清楚的看得出：
1）DNS Query必須一個(gè)RTT（Round-Trip Time，即來(lái)回時(shí)間），百度搜索App全是根據(jù)HTTPDNS服務(wù)項(xiàng)目的，因此絕大多數(shù)會(huì)擊中緩存文件，假如退級(jí)離開(kāi)了系統(tǒng)軟件DNS，也會(huì)擊中緩存文件，擊中不上的因?yàn)槭歉鶕?jù)UDP協(xié)議，因此在連接用時(shí)上沒(méi)有很大的危害，網(wǎng)上的數(shù)據(jù)信息也可以表明這一點(diǎn)；
2）TCP要?dú)v經(jīng)SYN，SYN/ACK，ACK三次握手的1.五個(gè)RTT，但是ACK和ClientHello合拼了，因此便是一個(gè)RTT；
3）TLS（Transport Layer Security，即網(wǎng)絡(luò)層安全系數(shù)協(xié)議）必須歷經(jīng)握手和密匙互換兩個(gè)RTT。
總的來(lái)說(shuō)：DNS、TLS、TCP握手環(huán)節(jié)用了4個(gè)RTT才到ApplicationData環(huán)節(jié)，也就是數(shù)據(jù)信息逐漸傳送環(huán)節(jié)。
根據(jù)上邊的剖析能夠小結(jié)出，如果我們能盡可能的將TLS和TCP的RTT降低，可能大幅度降低連接用時(shí)的時(shí)間。
百度搜索App的優(yōu)化總體目標(biāo)分成兩大類(lèi)，一類(lèi)是TLS的連接優(yōu)化，一類(lèi)是TCP的連接優(yōu)化。
下邊，大家將各自詳細(xì)介紹根據(jù)這二種優(yōu)化的構(gòu)思和實(shí)踐心得。
TLS的連接優(yōu)化，必須服務(wù)器端和手機(jī)客戶(hù)端都必須適用，互相配合優(yōu)化方式，包含Session Resumption和False Start。
Session Resumption中文翻譯是對(duì)話(huà)多路復(fù)用，下面的圖解讀了Session Resumption的協(xié)議基本原理。
▲ Session Resumption的協(xié)議基本原理
根據(jù)圖中能夠看得出TLS密匙商議互換的全過(guò)程沒(méi)了，但實(shí)際是怎樣完成的呢？包括二種方法，一種是Sesssion Identifier，一種是Session Ticket。
1）Session Identifier：
Session Identifier漢語(yǔ)為對(duì)話(huà)標(biāo)志符，更像大家熟識(shí)的session的定義。是 TLS 握手中形成的 Session ID。服務(wù)器端會(huì)將Session ID保存，手機(jī)客戶(hù)端也會(huì)儲(chǔ)存Session ID，在事后的ClientHello中攜帶它，服務(wù)器端假如能尋找配對(duì)的信息內(nèi)容，就可以進(jìn)行一次迅速握手。
2）Session Ticket：
Session Identifier存有一些缺點(diǎn)，例如手機(jī)客戶(hù)端數(shù)次請(qǐng)求要是沒(méi)有落在同一臺(tái)設(shè)備上就無(wú)法找到配對(duì)的信息內(nèi)容，但Session Ticket能夠。Session Ticket更像大家熟識(shí)的cookie的定義，Session Ticket用僅有服務(wù)器端了解的安全密鑰數(shù)據(jù)加密過(guò)的對(duì)話(huà)信息內(nèi)容，儲(chǔ)存在手機(jī)客戶(hù)端上。手機(jī)客戶(hù)端在ClientHello時(shí)攜帶了Session Ticket，網(wǎng)絡(luò)服務(wù)器假如能取得成功破譯就可以進(jìn)行迅速握手。
無(wú)論是Session Identifier還是Session Ticket都存有及時(shí)性難題，并不是永久性起效，針對(duì)這二種方法大伙兒能夠查詢(xún)參考文獻(xiàn)【4】。百度搜索App的互聯(lián)網(wǎng)協(xié)議層對(duì)這二種方法全是適用的，省掉了TLS握手全過(guò)程中證書(shū)下載，密匙商議互換的階段，節(jié)約了一個(gè)RTT的時(shí)間。
False Start的中文翻譯是彎道超車(chē)，下面的圖解讀了False Start的協(xié)議基本原理。
▲ False Start的協(xié)議基本原理
圖中很清楚的表明在TLS第一步握手取得成功后，手機(jī)客戶(hù)端在推送Change Cipher Spec Finished的另外逐漸傳輸數(shù)據(jù)，服務(wù)器端在TLS握手過(guò)去進(jìn)行時(shí)立即回到運(yùn)用數(shù)據(jù)信息。運(yùn)用數(shù)據(jù)信息的推送事實(shí)上仍未直到握手所有進(jìn)行，因此稱(chēng)作彎道超車(chē)。
從結(jié)果看省掉了一個(gè)RTT的時(shí)間。False Start有兩個(gè)必要條件：
一是要根據(jù)網(wǎng)絡(luò)層協(xié)議商議ALPN（Application Layer Protocol Negotiation）握手；
二是要適用前向安全性的加密技術(shù)。
False Start在沒(méi)完成握手的狀況下就推送了數(shù)據(jù)信息，前向安全性能夠提升安全系數(shù)，實(shí)際協(xié)議完成，大伙兒能夠查詢(xún)參考文獻(xiàn)【3】。百度搜索App的互聯(lián)網(wǎng)協(xié)議層對(duì)False Start是適用的。
這兒說(shuō)句題外話(huà)，實(shí)際上TCP層有一個(gè)相近的連接優(yōu)化方式叫Fast Open，很感興趣的同學(xué)們，能夠查詢(xún)參考文獻(xiàn)【5】。
二者針對(duì)TLS而言全是節(jié)約一個(gè)RTT，Session Resumption在第一次握手時(shí)還是必須兩個(gè)RTT，在第二次握手時(shí)才可以多路復(fù)用降低到一個(gè)RTT。False Start是端上的個(gè)人行為，故每一次都是會(huì)降低到一個(gè)RTT。
TCP的連接優(yōu)化，大家先從連接池談起，*先使我們來(lái)了解下連接池都有哪些種類(lèi)。
▲ 連接池的種類(lèi)
圖中展現(xiàn)了連接池的不一樣種類(lèi)，全是大伙兒廣為人知的協(xié)議連接池，有低等連接池，包括TCP連接池（管理方法HTTP請(qǐng)求的連接）和WebSocket連接池（管理方法WebSocket連接）。
有高級(jí)連接池，包含HTTP代理商連接池（管理方法HTTP代理商請(qǐng)求的連接），SpdySession連接池（管理方法SPDY和HTTP/2請(qǐng)求的連接），SOCKS連接池（管理方法SOCKS和SOCKS5代理商的連接），SSL連接池（管理方法HTTPS請(qǐng)求的連接）。
不一樣種類(lèi)的連接池以組成的方式相互之間多路復(fù)用工作能力：
1）SSL連接池管理方法的是SSLSocket，但SSLSocket又取決于TCP連接池出示的TCPSocket；
2）HTTP代理商連接池假如走HTTP協(xié)議，那麼就必須TCP連接池出示TCPSocket，假如走HTTPS協(xié)議，那麼就必須SSL連接池出示SSLSocket；
3）SpdySession連接池依靠SSL連接池出示SSLSocket，這兒必須表明下，盡管HTTP/2協(xié)議沒(méi)有強(qiáng)制性關(guān)聯(lián)HTTPS，可是在具體開(kāi)發(fā)設(shè)計(jì)中的確全是關(guān)聯(lián)HTTPS，百度搜索App應(yīng)用ALPN來(lái)商議HTTP/2；
4）SOCKS連接池管理方法的SOCKSSocket和SOCKS5Socket都必須依靠TCP連接池出示的TCPSocket，盡管SOCKS5適用UDP，但cronet互聯(lián)網(wǎng)庫(kù)暫時(shí)沒(méi)有完成；
5）WebSocket連接池依靠TCP連接池出示的TCPSocket，申明下這兒沒(méi)有表明WSS（Web Socket Secure）的狀況。
TCP連接優(yōu)化是一個(gè)非常復(fù)雜的內(nèi)容，百度搜索App干了目的性情景優(yōu)化，包含預(yù)連接，連接復(fù)建，預(yù)留連接，復(fù)合型連接。
▲ 預(yù)連接和連接復(fù)建
預(yù)連接：事先建立好的連接。它處理的情景是在App應(yīng)用環(huán)節(jié)能夠無(wú)用時(shí)的獲得連接。下邊用四個(gè)話(huà)題討論來(lái)表述預(yù)連接。
難題一：預(yù)連接是不是能處理全部互聯(lián)網(wǎng)請(qǐng)求的提早連接創(chuàng)建？
答：回答是否認(rèn)的，預(yù)連接必須業(yè)務(wù)流程方開(kāi)展關(guān)鍵業(yè)務(wù)流程的評(píng)定，對(duì)于關(guān)鍵的網(wǎng)站域名開(kāi)展預(yù)連接的創(chuàng)建。
難題二：預(yù)連接即然對(duì)于的是特殊的網(wǎng)站域名，那麼是如何配置的呢？
答：選用網(wǎng)站域名 連接數(shù)的方法開(kāi)展配備，例如 連接數(shù)的限定，不一樣互聯(lián)網(wǎng)庫(kù)的數(shù)量限定不一樣，有五個(gè)也是有6個(gè)，但針對(duì)HTTP/2協(xié)議，這一連接數(shù)就只有是一個(gè)。
難題三：預(yù)連接是怎樣創(chuàng)建的？
答：在互聯(lián)網(wǎng)庫(kù)復(fù)位的情況下，會(huì)依據(jù)使用人的配備延遲時(shí)間5s開(kāi)展預(yù)連接的創(chuàng)建，主要是考慮到互聯(lián)網(wǎng)庫(kù)在冷啟下針對(duì)運(yùn)行特性的危害，為了更好地確?；ヂ?lián)網(wǎng)庫(kù)的總體特性，預(yù)連接的總數(shù)量限定在20個(gè)。
難題四：預(yù)連接是怎樣維持的？
答：在互聯(lián)網(wǎng)庫(kù)復(fù)位的情況下，除開(kāi)開(kāi)展預(yù)連接的創(chuàng)建，還會(huì)繼續(xù)建立一個(gè)預(yù)連接的計(jì)時(shí)器，這一計(jì)時(shí)器會(huì)每過(guò)31s，這一值的設(shè)置在于BFE（Baidu Front End，是七層總流量的統(tǒng)一連接系統(tǒng)軟件）和BGW（Baidu Gate Way，百度搜索自主研發(fā)的四層負(fù)載均衡服務(wù)平臺(tái)）對(duì)請(qǐng)求超時(shí)的極小值設(shè)置，依據(jù)使用人的配備再次創(chuàng)建連接。
連接復(fù)建，將連接再次創(chuàng)建。它處理的情景是App網(wǎng)絡(luò)狀態(tài)產(chǎn)生變化，IP地址轉(zhuǎn)變，造成 連接不能用。下邊用三個(gè)話(huà)題討論來(lái)表述連接復(fù)建。
難題一：連接復(fù)建是不是對(duì)于連接池中的全部連接？
答：回答是毫無(wú)疑問(wèn)的。
難題二：連接復(fù)建的全過(guò)程是哪些的？
答：在網(wǎng)絡(luò)狀態(tài)轉(zhuǎn)變的情況下，第一步會(huì)消除掉連接池中的idle socket，什么是idle socket？即空余socket，針對(duì)從沒(méi)應(yīng)用過(guò)的空余socket超出60秒消除，針對(duì)應(yīng)用過(guò)的空余socket超出90秒消除。第二步復(fù)建連接必須等候200ms，目地是等候DNS先復(fù)建進(jìn)行。
難題三：連接復(fù)建針對(duì)特性有影響嗎？
答：出自于特性考慮到，連接復(fù)建的連接數(shù)量限定是一百個(gè)。
▲ 預(yù)留連接和復(fù)合型連接
預(yù)留連接，準(zhǔn)備的連接。它處理的情景是一切正常推送一個(gè)請(qǐng)求當(dāng)group內(nèi)無(wú)連接能用的情況下（什么是group？group是管理方法socket的*少模塊，內(nèi)部包括活躍性socket，空余socket，連接每日任務(wù)，等候請(qǐng)求）。下邊用三個(gè)話(huà)題討論來(lái)表述預(yù)留連接。
難題一：預(yù)留連接是不是對(duì)于全部請(qǐng)求？
答：回答是毫無(wú)疑問(wèn)的。
難題二：預(yù)留連接的全過(guò)程是哪些的？
答：當(dāng)有請(qǐng)求來(lái)臨時(shí)性，連接池中無(wú)連接能用，會(huì)運(yùn)行一個(gè)計(jì)時(shí)器打開(kāi)預(yù)留連接，計(jì)時(shí)器的時(shí)間間隔是250Ms，與主連接開(kāi)展市場(chǎng)競(jìng)爭(zhēng)，假如主連接由于網(wǎng)絡(luò)抖動(dòng)或是網(wǎng)絡(luò)狀態(tài)不太好，造成 連接不成功，那麼預(yù)留連接就立即推送請(qǐng)求。假如主連接取得成功，那麼預(yù)留連接就被撤消掉。
難題三：預(yù)留連接的目地是啥？
答：在連接池?zé)o連接的狀況下，盡量是要建立連接的，在主連接以外加一個(gè)預(yù)留連接，會(huì)大大的提高建立連接的通過(guò)率，進(jìn)而提高客戶(hù)體驗(yàn)。
復(fù)合型連接，即好幾條連接。它處理的情景是為了更好地好幾個(gè)IP地址的連接選擇難題。下邊用三個(gè)話(huà)題討論來(lái)表述復(fù)合型連接。
難題一：復(fù)合型連接是不是對(duì)于全部請(qǐng)求？
答：回答是毫無(wú)疑問(wèn)的。復(fù)合型連接能夠全局性電源開(kāi)關(guān)，百度搜索App目前暫時(shí)沒(méi)有打開(kāi)復(fù)合型連接。
難題二：復(fù)合型連接的全過(guò)程是哪些的？
答：大家都知道網(wǎng)站域名DNS查看一般狀況下能回到好幾個(gè)IP，大家以域名注冊(cè)查詢(xún)回到2個(gè)IP為例子
1）假如結(jié)果中存有IPv6的詳細(xì)地址，那麼會(huì)優(yōu)先選擇采用IPv6的詳細(xì)地址，這一標(biāo)準(zhǔn)follow HappyEyeBall體制（可參照系列產(chǎn)品一針對(duì)HappyEyeBall的詳細(xì)介紹）。
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)估。
百度App目前客戶(hù)端網(wǎng)絡(luò)架構(gòu)由于歷史原因還未統(tǒng)一，不過(guò)我們正朝著這個(gè)目標(biāo)努力。
我們的中心思想是以系統(tǒng)網(wǎng)絡(luò)庫(kù)的API調(diào)用接口為中心，上層建立網(wǎng)絡(luò)門(mén)面，供外部便捷調(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í)踐。
▲ 連接優(yōu)化在Android網(wǎng)絡(luò)架構(gòu)的位置
百度App的Android網(wǎng)絡(luò)流量目前都在okhttp之上，上層進(jìn)行了網(wǎng)絡(luò)門(mén)面的封裝，封裝內(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)。
▲ 連接優(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ò)門(mén)面，供各個(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)求）。
連接優(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ò)的收益。
連接優(yōu)化是個(gè)持續(xù)性的話(huà)題，沒(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] ... ild_instructions.md
[2] ... ild_instructions.md
[3] False Start：
[4] Session Resumption：
[5] TCP Fast Open：
（原文鏈接：點(diǎn)此進(jìn)入）
《TCP/IP詳解-第11章·UDP：用戶(hù)數(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ò)編程中的線(xiàn)程模型》
《不為人知的網(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ò)編程懶人入門(mén)(一)：快速理解網(wǎng)絡(luò)通信協(xié)議（上篇）》
《網(wǎng)絡(luò)編程懶人入門(mén)(二)：快速理解網(wǎng)絡(luò)通信協(xié)議（下篇）》
《網(wǎng)絡(luò)編程懶人入門(mén)(三)：快速理解TCP協(xié)議一篇就夠》
《網(wǎng)絡(luò)編程懶人入門(mén)(四)：快速理解TCP和UDP的差異》
《網(wǎng)絡(luò)編程懶人入門(mén)(五)：快速理解為什么說(shuō)UDP有時(shí)比TCP更有優(yōu)勢(shì)》
《網(wǎng)絡(luò)編程懶人入門(mén)(六)：史上*通俗的集線(xiàn)器、交換機(jī)、路由器功能原理入門(mén)》
《網(wǎng)絡(luò)編程懶人入門(mén)(七)：深入淺出，全面理解HTTP協(xié)議》
《網(wǎng)絡(luò)編程懶人入門(mén)(八)：手把手教你寫(xiě)基于TCP的Socket長(zhǎng)連接》
《網(wǎng)絡(luò)編程懶人入門(mén)(九)：通俗講解，有了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ò)編程入門(mén)(一)：跟著動(dòng)畫(huà)來(lái)學(xué)TCP三次握手和四次揮手》
《腦殘式網(wǎng)絡(luò)編程入門(mén)(二)：我們?cè)谧x寫(xiě)Socket時(shí)，究竟在讀寫(xiě)什么？》
《腦殘式網(wǎng)絡(luò)編程入門(mén)(三)：HTTP協(xié)議必知必會(huì)的一些知識(shí)》
《腦殘式網(wǎng)絡(luò)編程入門(mén)(四)：快速理解HTTP/2的服務(wù)器推送(Server Push)》
《腦殘式網(wǎng)絡(luò)編程入門(mén)(五)：每天都在用的Ping命令，它到底是什么？》
《腦殘式網(wǎng)絡(luò)編程入門(mén)(六)：什么是公網(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ù)入門(mén)(一)：通信交換技術(shù)的百年發(fā)展史(上)》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(二)：通信交換技術(shù)的百年發(fā)展史(下)》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(三)：國(guó)人通信方式的百年變遷》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(四)：手機(jī)的演進(jìn)，史上*全移動(dòng)終端發(fā)展史》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(五)：1G到5G，30年移動(dòng)通信技術(shù)演進(jìn)史》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(六)：移動(dòng)終端的接頭人——“基站”技術(shù)》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(七)：移動(dòng)終端的千里馬——“電磁波”》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(八)：零基礎(chǔ)，史上*強(qiáng)“天線(xiàn)”原理掃盲》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(九)：無(wú)線(xiàn)通信網(wǎng)絡(luò)的中樞——“核心網(wǎng)”》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(十)：零基礎(chǔ)，史上*強(qiáng)5G技術(shù)掃盲》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(十一)：為什么WiFi信號(hào)差？一文即懂！》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(十二)：上網(wǎng)卡頓？網(wǎng)絡(luò)掉線(xiàn)？一文即懂！》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(十三)：為什么手機(jī)信號(hào)差？一文即懂！》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(十四)：高鐵上無(wú)線(xiàn)上網(wǎng)有多難？一文即懂！》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(十五)：理解定位技術(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)化篇》
>>更多同類(lèi)文章 ……
（本文同步發(fā)布于：.1.html）
