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