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