文中由百度技術(shù)性精英團隊“蔡銳”原創(chuàng)發(fā)布于“百度App技術(shù)性”微信公眾號，原名為《百度App互聯(lián)網(wǎng)深層優(yōu)化系列產(chǎn)品《一》DNS優(yōu)化》，謝謝創(chuàng)作者的不求回報共享。
互聯(lián)網(wǎng)優(yōu)化是手機客戶端幾大技術(shù)性方位中認可的一個深層行業(yè)，因此 百度App給大伙兒產(chǎn)生互聯(lián)網(wǎng)深層優(yōu)化系列產(chǎn)品文章內(nèi)容。
本系列產(chǎn)品文章內(nèi)容文件目錄以下：
期待對大伙兒在互聯(lián)網(wǎng)方位的學(xué)習(xí)培訓(xùn)和實踐活動有一定的協(xié)助。
百度發(fā)家于檢索，全部企業(yè)的網(wǎng)絡(luò)結(jié)構(gòu)和布署全是根據(jù)規(guī)范的internet協(xié)議書，現(xiàn)階段早已是全棧開發(fā)HTTPS，趕到移動互聯(lián)時期后，總的系統(tǒng)架構(gòu)不會改變，但在手機客戶端上必須做許多優(yōu)化工作中。
DNS（Domain Name System），它的功效是依據(jù)域名查出來IP地址，它是HTTP協(xié)議書的前提條件，僅有將域名恰當?shù)姆治龀蒊P地址后，后邊的HTTP步驟才可以開展，因此 一般做互聯(lián)網(wǎng)優(yōu)化會優(yōu)選優(yōu)化DNS。
（文中同歩公布于：
《TCP/IP詳細說明 卷1：協(xié)議書-第14章 DNS:域名系統(tǒng)軟件》
《全方位掌握手機端DNS域名被劫持等雜癥：技術(shù)性原理、難題根本原因、解決方法等》
《美圖照片App的手機端DNS優(yōu)化實踐活動：HTTPS要求用時減少近半》
《當代手機端互聯(lián)網(wǎng)短連接的優(yōu)化方式小結(jié)：要求速率、弱網(wǎng)融入、安全防范措施》
《移動端IM開發(fā)者必讀(一)：通俗易懂，理解移動網(wǎng)絡(luò)的“弱”和“慢”》
《手機端IM開發(fā)人員必看(二)：史上*牛全挪動弱互聯(lián)網(wǎng)優(yōu)化方式 小結(jié)》
DNS優(yōu)化關(guān)鍵必須處理的難題有二點：
1）因為DNS被劫持或常見故障導(dǎo)致的服務(wù)項目不能用，從而危害客戶體驗，危害企業(yè)的收益；
2）因為DNS生產(chǎn)調(diào)度不精確造成 的特性衰退，從而危害客戶體驗。
百度App安裝著億級總流量，每一年都是會碰到營運商DNS被劫持或營運商DNS常見故障，總體危害十分不太好，因此 DNS優(yōu)化勢在必行，根據(jù)下面的圖會更形象化的掌握運營商劫持或常見故障的原理。
▲ 運營商劫持或常見故障的原理
相關(guān)手機端DNS被劫持等各種各樣疑難病癥，詳細文章內(nèi)容《全方位掌握手機端DNS域名被劫持等雜癥：技術(shù)性原理、難題根本原因、解決方法等》。
即然大家遭遇那么不容樂觀的難題，那麼大家怎樣優(yōu)化DNS呢？回答便是HTTPDNS。
絕大多數(shù)規(guī)范DNS全是根據(jù)UDP與DNS網(wǎng)絡(luò)服務(wù)器互動的，HTTPDNS則是運用HTTP協(xié)議書與DNS網(wǎng)絡(luò)服務(wù)器互動，避開了營運商的Local DNS服務(wù)項目，合理避免了域名被劫持，提升域名分析高效率，下面的圖是HTTPDNS的原理。
▲ HTTPDNS原理
百度App HTTPDNS端上的完成是根據(jù)百度SYS精英團隊的HTTPDNS服務(wù)項目，下面的圖詳細介紹了HTTPDNS的服務(wù)器端布署構(gòu)造。
▲ HTTPDNS布署構(gòu)造
HTTPDNS服務(wù)項目是根據(jù)BGP連接的，BGP英語Border Gateway Protocol，即界限網(wǎng)關(guān)ip協(xié)議書，是一種在自治系統(tǒng)中間動態(tài)性的互換路由器信息內(nèi)容的ospf協(xié)議，BGP能夠依據(jù)當今客戶的營運商路由器到百度服務(wù)項目點的相匹配群集上，針對第三方域名，服務(wù)項目點會根據(jù)百度布署在營運商的CDN連接點向別的域名權(quán)威性DNS進行查看，查看這一營運商下域名的*優(yōu)化IP。
百度App單獨完成了端HTTPDNS SDK，下面的圖詳細介紹了端HTTPDNS的總體構(gòu)架。
▲ 端HTTPDNS的總體構(gòu)架
大量HTTPDNS的材料，請見：《全方位掌握手機端DNS域名被劫持等雜癥：技術(shù)性原理、難題根本原因、解決方法等》、《美圖照片App的手機端DNS優(yōu)化實踐活動：HTTPS要求用時減少近半》。
DNS插口層處理的難題是屏蔽掉*底層的關(guān)鍵點，對外開放出示簡易干凈整潔的API，減少使用人的入門成本費，提升開發(fā)設(shè)計高效率。
DNS對策層根據(jù)多種多樣對策的組成，使HTTPDNS服務(wù)項目在特性，可靠性，易用性上均維持較高的水平，下邊解讀下每一個對策設(shè)計方案的初心和實際完成。
【4.3.1 容災(zāi)備份對策】：
這是一個十分重要的對策，關(guān)鍵處理HTTPDNS服務(wù)項目易用性的難題，實踐經(jīng)驗證明，這一對策協(xié)助百度App在異?，F(xiàn)象下拯救回許多總流量。
（1）當HTTPDNS服務(wù)項目不能用而且當?shù)囟紱]有緩存或是緩存無效的情況下，會開啟退級對策，退級成營運商的localDNS計劃方案，盡管存有營運商安全事故或是被劫持的風(fēng)險性，但確保了DNS服務(wù)項目的易用性。
（2）當HTTPDNS服務(wù)項目和localDNS服務(wù)項目同時不能用的狀況下，會開啟backup對策，應(yīng)用端上的backup IP。
什么叫backup IP？backup IP是多個依據(jù)域名歸類的IP目錄，可云空間動態(tài)更新，便捷事后運維管理同學(xué)們調(diào)節(jié)服務(wù)器端的連接點IP，非是全部域名都是有相匹配的backup IP目錄，現(xiàn)階段百度App只有確保關(guān)鍵域名的易用性。
即然是一組IP，便有選擇難題，backup IP選擇體制是如何的呢？大家的主題思想便是要在端出運用*少的成本，而且考慮到服務(wù)器端的web服務(wù)，獲得相對性恰當或是有效的選擇結(jié)果。根據(jù)營運商和空間信息，能夠挑選一個相對性較好的IP，但獲得空間信息必須非常大用時，另加次數(shù)很高，成本非常大，因此 大家挑選了RR優(yōu)化算法來替代上邊的方式 （RR優(yōu)化算法是Round-Robin，輪詢生產(chǎn)調(diào)度），那樣手機客戶端的成本減少到*少，服務(wù)器端也完成了web服務(wù)。
【4.3.2 安全設(shè)置】：
（1）HTTPDNS處理的關(guān)鍵難題便是安全性，規(guī)范的DNS查看絕大多數(shù)是根據(jù)UDP的，但也是有根據(jù)TCP的，假如UDP被禁封，就必須應(yīng)用TCP。無論是UDP還是TCP，安全系數(shù)全是沒有確保的，HTTPDNS查看是根據(jù)規(guī)范的HTTP協(xié)議書，為了更好地確保安全性大家會在HTTP上添一層TLS（安全性網(wǎng)絡(luò)層協(xié)議書），這就是HTTPS；
（2）解決了網(wǎng)絡(luò)層協(xié)議書的安全系數(shù)后，我們要處理下域名分析的難題，上邊大家提及HTTPDNS服務(wù)項目是根據(jù)BGP連接的，在端出選用VIP方法要求HTTPDNS數(shù)據(jù)信息（VIP即Virtual IP，VIP并沒有與某機器設(shè)備存有必然的關(guān)聯(lián)關(guān)聯(lián)，會追隨主備轉(zhuǎn)換這類的狀況產(chǎn)生而轉(zhuǎn)換，VIP出示的服務(wù)項目是相匹配到某一臺或多個臺網(wǎng)絡(luò)服務(wù)器的），即然要求原始記錄必須應(yīng)用IP傳送數(shù)據(jù)的方法，那麼就解決了營運商localDNS的分析限定，那樣即便營運商發(fā)生了常見故障或是遭劫持，都不容易危害百度App的易用性。
【4.3.3 線程同步對策】：
HTTPDNS服務(wù)項目出示了兩大類HTTP插口，用以要求*優(yōu)化域名結(jié)果。第一種是多域名插口，對于不一樣的產(chǎn)品系列，下達產(chǎn)品系列配備的域名，第二種是單域名插口，只回到你需要查看的那一個域名結(jié)果，那樣的設(shè)計方案和規(guī)范的DNS查看基礎(chǔ)是一樣的，只不過是是以UDP協(xié)議書變成了HTTP協(xié)議書。
（1）多域名插口會在App冷啟和互聯(lián)網(wǎng)轉(zhuǎn)換的情況下要求一次，目地是在App的網(wǎng)絡(luò)空間復(fù)位或是轉(zhuǎn)變的情況下事先獲得域名結(jié)果，那樣也會降低單域名插口的要求頻次。
（2）單域名插口會在當?shù)豤ache到期后，由客戶的實際操作開啟互聯(lián)網(wǎng)要求，從而做一次單域名要求，客戶此次實際操作的DNS結(jié)果會退級成localDNS的結(jié)果，但在沒有到期的狀況下，下一次會回到HTTPDNS的結(jié)果。
【4.3.4 IP選擇對策】：
IP選擇對策處理的關(guān)鍵難題是*優(yōu)化IP的選擇，防止由于連接點的選擇不正確導(dǎo)致的跨營運商用時。HTTPDNS服務(wù)項目會將*優(yōu)化IP依照次序下達，手機客戶端默認設(shè)置選擇第一個，這兒沒有做手機客戶端的連接性校檢的緣故，關(guān)鍵還是擔憂端上的特性難題，但是有容災(zāi)備份對策兜底，綜合性評定還是能夠接納的。
【4.3.5 緩存對策】：
大伙兒針對DNS緩存并不生疏，它主要是為了更好地提高瀏覽高效率，電腦操作系統(tǒng)，互聯(lián)網(wǎng)庫等都是會做DNS緩存。
DNS緩存中一個關(guān)鍵的定義便是TTL（Time-To-Live），在localDNS中對于不一樣的域名，TTL的時間不一樣的，在HTTPDNS中這一值由服務(wù)器端動態(tài)性下達，百度App現(xiàn)階段全部的域名TTL的配備是五分鐘，到期后要是沒有新的IP將再次延用老的IP，自然還可以挑選不延用老的IP，而退級成localDNS的IP，那麼這就在于localDNS針對到期IP的解決。
【4.3.6 準確率對策】：
假如HTTPDNS的準確率是100%，在確保HTTPDNS服務(wù)項目平穩(wěn)高效率的前提條件下，大家就可以保證防劫持，提高精確生產(chǎn)調(diào)度的能力。
（1）為了更好地提高HTTPDNS的準確率，大家挑選應(yīng)用多域名插口，在冷啟和互聯(lián)網(wǎng)轉(zhuǎn)換的情況下，大批量獲取域名結(jié)果并緩存在當?shù)兀阌谙旅娴囊髴?yīng)用。
（2）為了更好地再一次提高HTTPDNS的準確率，當客戶實際操作開啟互聯(lián)網(wǎng)要求，獲得域名相匹配的IP時，會提早開展當?shù)氐狡跁r間分辨，時間60s，假如到期，會進行單域名的要求并緩存起來，那樣會不斷增加域名結(jié)果的到期時間。當?shù)氐狡跁r間與上邊提及的TTL是手機客戶端和服務(wù)器端的雙向到期時間，目地是在異常現(xiàn)象下能夠雙向確保到期時間的精確性。
基本能力層關(guān)鍵出示給DNS對策層所必須的基本能力，包含IPv4/IPv6tcp協(xié)議檢測的能力，傳輸數(shù)據(jù)的能力，緩存完成的能力，下邊將解讀每個能力的實際完成。
【4.4.1 IPv4/IPv6tcp協(xié)議檢測】：
百度App的IPv6更新改造已經(jīng)熱火朝天的進行中，端出在HTTPDNS的IP選擇上如何知道現(xiàn)階段歸屬于哪一個tcp協(xié)議變成至關(guān)重要難題，而且這類分辨規(guī)定特性極高，由于IP選擇的次數(shù)確實是太高了。
大家選擇的計劃方案是UDP Connect，那麼什么是UDP Connect？
大家都了解TCP是朝向聯(lián)接的，傳送數(shù)據(jù)前手機客戶端都需要啟用connect方式 根據(jù)三次握手創(chuàng)建聯(lián)接，UDP是朝向無聯(lián)接的，不用創(chuàng)建聯(lián)接便能收取和發(fā)送數(shù)據(jù)信息，可是如果我們啟用了UDP的connect方式 會產(chǎn)生什么？在我們啟用UDP的connect方式 時，系統(tǒng)軟件會檢驗其端口號是不是能用，詳細地址是不是恰當，隨后紀錄對端IP地址和服務(wù)器端口，回到給調(diào)用者，因此 UDP Connect不容易像TCP Connect進行三次握手，產(chǎn)生互聯(lián)網(wǎng)真正耗損，UDP手機客戶端僅有啟用send或是sendto方式 后才會真實進行真正互聯(lián)網(wǎng)耗損。
▲ UDP Connect原理
擁有UDP Connect的基本確保，我們在頂層干了緩存體制，用于降低系統(tǒng)進程的耗損，機會上現(xiàn)階段僅在冷啟和互聯(lián)網(wǎng)轉(zhuǎn)換會開啟檢測，在同一種網(wǎng)絡(luò)頻段下檢測一次基礎(chǔ)能夠保證當今互聯(lián)網(wǎng)是IPv4棧還是IPv6棧。
現(xiàn)階段百度App手機客戶端針對IPv4/IPv6雙棧的對策是傳統(tǒng)的，僅在IPv6-only的狀況下應(yīng)用v6的IP，其他應(yīng)用的全是v4的IP，雙棧下的計劃方案事后必須優(yōu)化，業(yè)界現(xiàn)階段規(guī)范的作法是happy eyeball優(yōu)化算法。
什么是happy eyeball呢？
便是不容易由于IPv4或IPv6的常見故障難題，導(dǎo)致用戶的目光一直等待載入或是打錯，這就是happy eyeball名字的來歷。happy eyeball有v1版本號RFC6555和v2版本號RFC8305，前面一種是Cisco明確提出來的，后面一種是iPhone明確提出來的。happy eyeball處理的關(guān)鍵難題是，繁雜自然環(huán)境下v4和v6 IP選擇的難題，它是一套總體解決方法，針對域名查看的解決，詳細地址的排列，聯(lián)接的試著等層面均作出了要求，很感興趣的同學(xué)們能夠查詢參考文獻里的【5】和【6】。
【4.4.2 傳輸數(shù)據(jù)】：
傳輸數(shù)據(jù)關(guān)鍵出示互聯(lián)網(wǎng)要求的能力和數(shù)據(jù)信息分析的能力。
（1）互聯(lián)網(wǎng)要求不成功再試的體制，獲得HTTPDNS結(jié)果的通過率會大大的危害HTTPDNS的準確率，因此 手機客戶端會有一個三次再試的體制，確保通過率。
（2）數(shù)據(jù)信息分析出現(xiàn)異常的體制，假如獲得的HTTPDNS的結(jié)果存有出現(xiàn)異常，將不容易遮蓋端上的緩存。
【4.4.3 緩存完成】：
緩存的完成基礎(chǔ)能夠分成硬盤緩存和運行內(nèi)存緩存，針對HTTPDNS的緩存情景，我們都是選其一還是都挑選呢？
百度App挑選的是運行內(nèi)存緩存，目地是避免我們自己的服務(wù)項目發(fā)生難題，運維管理同學(xué)們在緊急狀況下轉(zhuǎn)換總流量，假如干了硬盤緩存，會造成 百度App在重新啟動后也很有可能不能用，但這類難題會造成 APP在冷啟期內(nèi)，HTTPDNS結(jié)果未回到前，還是存有常見故障或是被劫持的風(fēng)險性，綜合性評定看來能夠接納，假如發(fā)生這類極端化狀況，危害的是冷啟環(huán)節(jié)的一些要求，但只需HTTPDNS結(jié)果回到后便會恢復(fù)過來。
百度App現(xiàn)階段手機客戶端網(wǎng)絡(luò)結(jié)構(gòu)因為歷史時間緣故還未統(tǒng)一，但是大家正向著這一總體目標勤奮，下面著重介紹下HTTPDNS在Android和iOS網(wǎng)絡(luò)架構(gòu)中的位置及實踐。
HTTPDNS在Android網(wǎng)絡(luò)架構(gòu)的位置及實踐：
百度App的Android網(wǎng)絡(luò)流量都在okhttp之上，上層進行了網(wǎng)絡(luò)門面的封裝，封裝內(nèi)部的實現(xiàn)細節(jié)和對外友好的API，供各個業(yè)務(wù)和基礎(chǔ)模塊使用，在okhttp上我們擴展了DNS模塊，使用HTTPDNS替換了原有的系統(tǒng)DNS。
▲ HTTPDNS在Android網(wǎng)絡(luò)架構(gòu)的位置
HTTPDNS在iOS網(wǎng)絡(luò)架構(gòu)的位置及實踐：
百度App的iOS網(wǎng)絡(luò)流量都在cronet（chromium的net模塊）之上，上層我們使用AOP的方式將cronet stack注入進URLSession里，這樣我們就可以直接使用URLSession的API進行網(wǎng)絡(luò)的操作而且更易于系統(tǒng)維護。
在上層封裝了網(wǎng)絡(luò)門面，供各個業(yè)務(wù)和基礎(chǔ)模塊使用，在cronet內(nèi)部我們修改了DNS模塊，除了原有的系統(tǒng)DNS邏輯外，還添加了HTTPDNS的邏輯。
iOS上還有一部分流量是在原生URLSession上，主要是有些第三方業(yè)務(wù)沒有使用cronet但還想單獨使用HTTPDNS的能力，所以就有了下面的HTTPDNS封裝層，方法是在上層直接將域名替換成IP，域名對于底層很多機制是至關(guān)重要的，比如https校驗，cookie，重定向，SNI（Server Name Indication）等，所以將域名修改成了IP直連后，我們又處理了以上三種情況，保證請求的可用性。
▲ HTTPDNS在iOS網(wǎng)絡(luò)架構(gòu)的位置
DNS優(yōu)化的收益主要有兩點：
1）防止DNS的劫持（在出問題時顯得尤為重要）；
2）降低網(wǎng)絡(luò)時延（在調(diào)度不準確的情況下，會增大網(wǎng)絡(luò)的時延，降低用戶的體驗）。
這兩點收益需要結(jié)合業(yè)務(wù)來說，以百度App Feed業(yè)務(wù)為例：
1）第一點上我們?nèi)〉昧吮容^大的效果，iOS劫持率由0.12%降低到0.0002%，Android劫持率由0.25%降低到0.05%；
2）第二點的收益不明顯，原因在于Feed業(yè)務(wù)主要目標群體在國內(nèi)，百度在國內(nèi)節(jié)點布局相對豐富，服務(wù)整體質(zhì)量也較高，即使出現(xiàn)調(diào)度不準確的情況，差值也不會太大，但如果在國外情況可能會差很多。
DNS優(yōu)化是個持續(xù)性的話題，上面介紹的百度App的一些經(jīng)驗和做法并不見得完美，但我們會持續(xù)深入的優(yōu)化下去，為百度App的DNS能力保駕護航。*后感謝大家的辛苦閱讀，希望對你有所幫助，后面會繼續(xù)推出《百度APP移動端網(wǎng)絡(luò)深度優(yōu)化實踐分享(二)：網(wǎng)絡(luò)連接優(yōu)化篇》，敬請期待。
做為一個工程師，如何才能做好網(wǎng)絡(luò)優(yōu)化這件事情，是個值得我們交流探討的話題，個人認為應(yīng)該從以下五方面入手。
1）基礎(chǔ)知識要了解學(xué)習(xí)，要夯實：網(wǎng)絡(luò)相關(guān)的內(nèi)容很多，很雜，不易學(xué)習(xí)，啃過IETF發(fā)布的RFC的同學(xué)應(yīng)該深有感觸。
2）學(xué)會將看不見的網(wǎng)絡(luò)變成看得見的：很多自認為對于網(wǎng)絡(luò)很了解的同學(xué)，動不動就背誦tcp協(xié)議原理，擁塞控制算法，滑動窗口大小等，但真正遇到線上問題，無從下手。對于客戶端同學(xué)，我們在PC上要學(xué)會使用tcpdump和Wireshark等工具，適當使用Fiddler和Charles等工具，很多時候電腦和手機的網(wǎng)絡(luò)環(huán)境不見得一致，所以要在手機上使用iNetTools，Ping&DNS或終端工具。學(xué)會使用工具后，要學(xué)著創(chuàng)造不同的網(wǎng)絡(luò)環(huán)境，有很多工具能幫助你完成這點，比如蘋果的Network Link Conditioner，F(xiàn)aceBook的ATC（Augmented Traffic Control）等。具備以上兩個場景后，你的第一條儲備就發(fā)揮了作用，你要能看懂握手過程，傳輸過程，異常斷開過程等。
3）有了以上兩點的準備，接下來需要一個會出現(xiàn)各種網(wǎng)絡(luò)問題的平臺，給你積累經(jīng)驗，讓一個個高壓下的線上問題錘煉你，折磨你。
4）網(wǎng)絡(luò)優(yōu)化是需要數(shù)據(jù)支撐的：但數(shù)據(jù)的采集和分析是需要經(jīng)驗的，有些數(shù)據(jù)一眼看下去就是不靠譜的，有些數(shù)據(jù)怎么分析都是負向收益的，一般來說是有三重奏來對數(shù)據(jù)進行分析的，一，線下數(shù)據(jù)的采集和分析，得出正向收益，二，灰度數(shù)據(jù)的采集和分析，得出正向收益，三，線上數(shù)據(jù)的采集和分析，得出正向收益。
5）數(shù)據(jù)的正向收益，不能完全證明提升了用戶的體驗，所以很多時候需要針對特定場景，特定case來分析和優(yōu)化，就算是大家公認做的很好的微信，也不是在所有場景下都能保證體驗上的*佳。
[1]
[2]
[3]
[4]
[5]
[6]
（原文鏈接：點此進入）
《TCP/IP詳解-第11章·UDP：用戶數(shù)據(jù)報協(xié)議》
《TCP/IP詳解-第17章·TCP：傳輸控制協(xié)議》
《TCP/IP詳解-第18章·TCP連接的建立與終止》
《TCP/IP詳解-第21章·TCP的超時與重傳》
《技術(shù)往事：改變世界的TCP/IP協(xié)議（珍貴多圖、手機慎點）》
《通俗易懂-深入理解TCP協(xié)議（上）：理論基礎(chǔ)》
《通俗易懂-深入理解TCP協(xié)議（下）：RTT、滑動窗口、擁塞處理》
《理論經(jīng)典：TCP協(xié)議的3次握手與4次揮手過程詳解》
《理論聯(lián)系實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》
《計算機網(wǎng)絡(luò)通訊協(xié)議關(guān)系圖（中文珍藏版）》
《UDP中一個包的大小*大能多大？》
《P2P技術(shù)詳解(一)：NAT詳解——詳細原理、P2P簡介》
《P2P技術(shù)詳解(二)：P2P中的NAT穿越(打洞)方案詳解》
《P2P技術(shù)詳解(三)：P2P技術(shù)之STUN、TURN、ICE詳解》
《通俗易懂：快速理解P2P技術(shù)中的NAT穿透原理》
《高性能網(wǎng)絡(luò)編程(一)：單臺服務(wù)器并發(fā)TCP連接數(shù)到底可以有多少》
《高性能網(wǎng)絡(luò)編程(二)：上一個10年，著名的C10K并發(fā)連接問題》
《高性能網(wǎng)絡(luò)編程(三)：下一個10年，是時候考慮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連接時為什么會TIME_WAIT、CLOSE_WAIT》
《不為人知的網(wǎng)絡(luò)編程(四)：深入研究分析TCP的異常關(guān)閉》
《不為人知的網(wǎng)絡(luò)編程(五)：UDP的連接性和負載均衡》
《不為人知的網(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有時比TCP更有優(yōu)勢》
《網(wǎng)絡(luò)編程懶人入門(六)：史上*通俗的集線器、交換機、路由器功能原理入門》
《網(wǎng)絡(luò)編程懶人入門(七)：深入淺出，全面理解HTTP協(xié)議》
《網(wǎng)絡(luò)編程懶人入門(八)：手把手教你寫基于TCP的Socket長連接》
《網(wǎng)絡(luò)編程懶人入門(九)：通俗講解，有了IP地址，為何還要用MAC地址？》
《技術(shù)掃盲：新一代基于UDP的低延時網(wǎng)絡(luò)傳輸層協(xié)議——QUIC詳解》
《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術(shù)實踐分享》
《現(xiàn)代移動端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請求速度、弱網(wǎng)適應(yīng)、安全保障》
《聊聊iOS中網(wǎng)絡(luò)編程長連接的那些事》
《移動端IM開發(fā)者必讀(一)：通俗易懂，理解移動網(wǎng)絡(luò)的“弱”和“慢”》
《移動端IM開發(fā)者必讀(二)：史上*全移動弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》
《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實踐（上篇）》
《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實踐（下篇）》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設(shè)計思路》
《腦殘式網(wǎng)絡(luò)編程入門(一)：跟著動畫來學(xué)TCP三次握手和四次揮手》
《腦殘式網(wǎng)絡(luò)編程入門(二)：我們在讀寫Socket時，究竟在讀寫什么？》
《腦殘式網(wǎng)絡(luò)編程入門(三)：HTTP協(xié)議必知必會的一些知識》
《腦殘式網(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è)計為例，理解實時通信的技術(shù)挑戰(zhàn)》
《邁向高階：優(yōu)秀Android程序員必知必會的網(wǎng)絡(luò)基礎(chǔ)》
《全面了解移動端DNS域名劫持等雜癥：技術(shù)原理、問題根源、解決方案等》
《美圖App的移動端DNS優(yōu)化實踐：HTTPS請求耗時減小近半》
《Android程序員必知必會的網(wǎng)絡(luò)通信傳輸層協(xié)議——UDP和TCP》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(一)：通信交換技術(shù)的百年發(fā)展史(上)》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(二)：通信交換技術(shù)的百年發(fā)展史(下)》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(三)：國人通信方式的百年變遷》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(四)：手機的演進，史上*全移動終端發(fā)展史》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(五)：1G到5G，30年移動通信技術(shù)演進史》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(六)：移動終端的接頭人——“基站”技術(shù)》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(七)：移動終端的千里馬——“電磁波”》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(八)：零基礎(chǔ)，史上*強“天線”原理掃盲》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(九)：無線通信網(wǎng)絡(luò)的中樞——“核心網(wǎng)”》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十)：零基礎(chǔ)，史上*強5G技術(shù)掃盲》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十一)：為什么WiFi信號差？一文即懂！》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十二)：上網(wǎng)卡頓？網(wǎng)絡(luò)掉線？一文即懂！》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十三)：為什么手機信號差？一文即懂！》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十四)：高鐵上無線上網(wǎng)有多難？一文即懂！》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十五)：理解定位技術(shù)，一篇就夠》
《百度APP移動端網(wǎng)絡(luò)深度優(yōu)化實踐分享(一)：DNS優(yōu)化篇》
《百度APP移動端網(wǎng)絡(luò)深度優(yōu)化實踐分享(二)：網(wǎng)絡(luò)連接優(yōu)化篇》
>>更多同類文章 ……
（本文同步發(fā)布于：
