本文由百度技術(shù)團(tuán)隊(duì)“蔡銳”原創(chuàng)發(fā)表于“百度App技術(shù)”公眾號(hào)，原題為《百度App網(wǎng)絡(luò)深度優(yōu)化系列《一》DNS優(yōu)化》，感謝原作者的無(wú)私分享。

本系列文章目錄如下：

《百度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)化篇》

《百度APP移動(dòng)端網(wǎng)絡(luò)深度優(yōu)化實(shí)踐分享(三)：移動(dòng)端弱網(wǎng)優(yōu)化篇》

希望對(duì)大家在網(wǎng)絡(luò)方向的學(xué)習(xí)和實(shí)踐有所幫助。

百度起家于搜索，整個(gè)公司的網(wǎng)絡(luò)架構(gòu)和部署都是基于標(biāo)準(zhǔn)的internet協(xié)議，目前已經(jīng)是全棧HTTPS，來(lái)到移動(dòng)互聯(lián)網(wǎng)時(shí)代后，總的基礎(chǔ)架構(gòu)不變，但在客戶端上需要做很多優(yōu)化工作。

DNS（Domain Name System），它的作用是根據(jù)域名查出IP地址，它是HTTP協(xié)議的前提，只有將域名正確的解析成IP地址后，后面的HTTP流程才能進(jìn)行，所以一般做網(wǎng)絡(luò)優(yōu)化會(huì)選優(yōu)化DNS。

（本文同步發(fā)布于：http://www.52im.net/thread-2472-1-1.html）

域名

系統(tǒng)》

《全面了解移動(dòng)端DNS域名劫持等雜癥：技術(shù)原理、問(wèn)題根源、解決方案等》

《美圖App的移動(dòng)端DNS優(yōu)化實(shí)踐：HTTPS請(qǐng)求耗時(shí)減小近半》

《現(xiàn)代移動(dòng)端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請(qǐng)求速度、弱網(wǎng)適應(yīng)、安全保障》

《移動(dòng)端IM開發(fā)者必讀(一)：通俗易懂，理解移動(dòng)網(wǎng)絡(luò)的“弱”和“慢”》

《移動(dòng)端IM開發(fā)者必讀(二)：史上最全移動(dòng)弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》

DNS優(yōu)化核心需要解決的問(wèn)題有兩點(diǎn)：

1）由于DNS劫持或故障造成的服務(wù)不可用，進(jìn)而影響用戶體驗(yàn)，影響公司的收入；

2）由于DNS調(diào)度不準(zhǔn)確導(dǎo)致的性能退化，進(jìn)而影響用戶體驗(yàn)。

百度App承載著億級(jí)流量，每年都會(huì)遇到運(yùn)營(yíng)商DNS劫持或運(yùn)營(yíng)商DNS故障，整體影響非常不好，所以DNS優(yōu)化刻不容緩，通過(guò)下圖會(huì)更直觀的了解運(yùn)營(yíng)商劫持或故障的原理。

▲ 運(yùn)營(yíng)商劫持或故障的原理

有關(guān)移動(dòng)端DNS劫持等各種疑難雜癥，詳見(jiàn)文章《全面了解移動(dòng)端DNS域名劫持等雜癥：技術(shù)原理、問(wèn)題根源、解決方案等》。

4.1 概述

既然我們面臨這么嚴(yán)峻的問(wèn)題，那么我們?nèi)绾蝺?yōu)化DNS呢？答案就是HTTPDNS。

大部分標(biāo)準(zhǔn)DNS都是基于UDP與DNS服務(wù)器交互的，HTTPDNS則是利用HTTP協(xié)議與DNS服務(wù)器交互，繞開了運(yùn)營(yíng)商的Local DNS服務(wù)，有效防止了域名劫持，提高域名解析效率，下圖是HTTPDNS的原理。

▲ HTTPDNS原理

百度App HTTPDNS端上的實(shí)現(xiàn)是基于百度SYS團(tuán)隊(duì)的HTTPDNS服務(wù)，下圖介紹了HTTPDNS的服務(wù)端部署結(jié)構(gòu)。

▲ HTTPDNS部署結(jié)構(gòu)

HTTPDNS服務(wù)是基于BGP接入的，BGP英文Border Gateway Protocol，即邊界網(wǎng)關(guān)協(xié)議，是一種在自治系統(tǒng)之間動(dòng)態(tài)的交換路由信息的路由協(xié)議，BGP可以根據(jù)當(dāng)前用戶的運(yùn)營(yíng)商路由到百度服務(wù)點(diǎn)的對(duì)應(yīng)集群上，對(duì)于第三方域名，服務(wù)點(diǎn)會(huì)通過(guò)百度部署在運(yùn)營(yíng)商的CDN節(jié)點(diǎn)向其他域名權(quán)威DNS發(fā)起查詢，查詢這個(gè)運(yùn)營(yíng)商下域名的最優(yōu)IP。

百度App獨(dú)立實(shí)現(xiàn)了端的HTTPDNS SDK，下圖介紹了端HTTPDNS的整體架構(gòu)。

▲ 端HTTPDNS的整體架構(gòu)

更多HTTPDNS的資料，請(qǐng)見(jiàn)：《全面了解移動(dòng)端DNS域名劫持等雜癥：技術(shù)原理、問(wèn)題根源、解決方案等》、《美圖App的移動(dòng)端DNS優(yōu)化實(shí)踐：HTTPS請(qǐng)求耗時(shí)減小近半》。

4.2 DNS接口層

DNS接口層解決的問(wèn)題是屏蔽底層的細(xì)節(jié)，對(duì)外提供簡(jiǎn)單整潔的API，降低使用者的上手成本，提高開發(fā)效率。

4.3 DNS策略層

DNS策略層通過(guò)多種策略的組合，使HTTPDNS服務(wù)在性能，穩(wěn)定性，可用性上均保持較高的水準(zhǔn)，下面講解下每個(gè)策略設(shè)計(jì)的初衷和具體實(shí)現(xiàn)。

【4.3.1 容災(zāi)策略】：

這是一個(gè)非常關(guān)鍵的策略，主要解決HTTPDNS服務(wù)可用性的問(wèn)題，實(shí)踐證明，這個(gè)策略幫助百度App在異常情況下挽救回很多流量。

（1）當(dāng)HTTPDNS服務(wù)不可用并且本地也沒(méi)有緩存或者緩存失效的時(shí)候，會(huì)觸發(fā)降級(jí)策略，降級(jí)成運(yùn)營(yíng)商的localDNS方案，雖然存在運(yùn)營(yíng)商事故或者劫持的風(fēng)險(xiǎn)，但保障了DNS服務(wù)的可用性。

（2）當(dāng)HTTPDNS服務(wù)和localDNS服務(wù)雙雙不可用的情況下，會(huì)觸發(fā)backup策略，使用端上的backup IP。

什么是backup IP？backup IP是多組根據(jù)域名分類的IP列表，可云端動(dòng)態(tài)更新，方便后續(xù)運(yùn)維同學(xué)調(diào)整服務(wù)端的節(jié)點(diǎn)IP，不是所有域名都有對(duì)應(yīng)的backup IP列表，目前百度App只能保證核心域名的可用性。

既然是一組IP，便有選取問(wèn)題，backup IP選取機(jī)制是怎樣的呢？我們的中心思想就是要在端上利用最小的代價(jià)，并且考慮服務(wù)端的負(fù)載均衡，得到相對(duì)正確或者合理的選取結(jié)果。通過(guò)運(yùn)營(yíng)商和地理信息，可以選擇一個(gè)相對(duì)較優(yōu)的IP，但獲取地理信息需要很大耗時(shí)，外加頻次很高，代價(jià)很大，所以我們選擇了RR算法來(lái)代替上面的方法（RR算法是Round-Robin，輪詢調(diào)度），這樣客戶端的代價(jià)降低到最小，服務(wù)端也實(shí)現(xiàn)了負(fù)載均衡。

【4.3.2 安全策略】：

（1）HTTPDNS解決的核心問(wèn)題就是安全，標(biāo)準(zhǔn)的DNS查詢大部分是基于UDP的，但也有基于TCP的，如果UDP被封禁，就需要使用TCP。不管是UDP還是TCP，安全性都是沒(méi)有保障的，HTTPDNS查詢是基于標(biāo)準(zhǔn)的HTTP協(xié)議，為了保證安全我們會(huì)在HTTP上加一層TLS（安全傳輸層協(xié)議），這便是HTTPS；

（2）解決了傳輸層協(xié)議的安全性后，我們要解決下域名解析的問(wèn)題，上面我們提到HTTPDNS服務(wù)是基于BGP接入的，在端上采用VIP方式請(qǐng)求HTTPDNS數(shù)據(jù)（VIP即Virtual IP，VIP并沒(méi)有與某設(shè)備存在必定的綁定關(guān)系，會(huì)跟隨主備切換之類的情況發(fā)生而變換，VIP提供的服務(wù)是對(duì)應(yīng)到某一臺(tái)或若干臺(tái)服務(wù)器的），既然請(qǐng)求原始數(shù)據(jù)需要使用IP直連的方式，那么就擺脫了運(yùn)營(yíng)商localDNS的解析限制，這樣即使運(yùn)營(yíng)商出現(xiàn)了故障或者被劫持，都不會(huì)影響百度App的可用性。

【4.3.3 任務(wù)調(diào)度策略】：

HTTPDNS服務(wù)提供了兩類HTTP接口，用于請(qǐng)求最優(yōu)域名結(jié)果。第一種是多域名接口，針對(duì)不同的產(chǎn)品線，下發(fā)產(chǎn)品線配置的域名，第二種是單域名接口，只返回你要查詢的那個(gè)域名結(jié)果，這樣的設(shè)計(jì)和標(biāo)準(zhǔn)的DNS查詢基本是一樣的，只不過(guò)是從UDP協(xié)議變成了HTTP協(xié)議。

（1）多域名接口會(huì)在App冷啟動(dòng)和網(wǎng)絡(luò)切換的時(shí)候請(qǐng)求一次，目的是在App的網(wǎng)絡(luò)環(huán)境初始化或者變化的時(shí)候預(yù)先獲取域名結(jié)果，這樣也會(huì)減少單域名接口的請(qǐng)求次數(shù)。

（2）單域名接口會(huì)在本地cache過(guò)期后，由用戶的操作觸發(fā)網(wǎng)絡(luò)請(qǐng)求，進(jìn)而做一次單域名請(qǐng)求，用戶這次操作的DNS結(jié)果會(huì)降級(jí)成localDNS的結(jié)果，但在沒(méi)有過(guò)期的情況下，下次會(huì)返回HTTPDNS的結(jié)果。

【4.3.4 IP選取策略】：

IP選取策略解決的核心問(wèn)題是最優(yōu)IP的選取，避免因?yàn)榻尤朦c(diǎn)的選取錯(cuò)誤造成的跨運(yùn)營(yíng)商耗時(shí)。HTTPDNS服務(wù)會(huì)將最優(yōu)IP按照順序下發(fā)，客戶端默認(rèn)選取第一個(gè)，這里沒(méi)有做客戶端的連通性校驗(yàn)的原因，主要還是擔(dān)心端上的性能問(wèn)題，不過(guò)有容災(zāi)策略兜底，綜合評(píng)估還是可以接受的。

【4.3.5 緩存策略】：

大家對(duì)于DNS緩存并不陌生，它主要是為了提升訪問(wèn)效率，操作系統(tǒng)，網(wǎng)絡(luò)庫(kù)等都會(huì)做DNS緩存。

DNS緩存中一個(gè)重要的概念就是TTL（Time-To-Live），在localDNS中針對(duì)不同的域名，TTL的時(shí)間是不一樣的，在HTTPDNS中這個(gè)值由服務(wù)端動(dòng)態(tài)下發(fā)，百度App目前所有的域名TTL的配置是5分鐘，過(guò)期后如果沒(méi)有新的IP將繼續(xù)沿用老的IP，當(dāng)然也可以選擇不沿用老的IP，而降級(jí)成localDNS的IP，那么這就取決于localDNS對(duì)于過(guò)期IP的處理。

【4.3.6 命中率策略】：

如果HTTPDNS的命中率是100%，在保證HTTPDNS服務(wù)穩(wěn)定高效的前提下，我們就可以做到防劫持，提升精準(zhǔn)調(diào)度的能力。

（1）為了提升HTTPDNS的命中率，我們選擇使用多域名接口，在冷啟動(dòng)和網(wǎng)絡(luò)切換的時(shí)候，批量拉取域名結(jié)果并緩存在本地，便于接下來(lái)的請(qǐng)求使用。

（2）為了再一次提升HTTPDNS的命中率，當(dāng)用戶操作觸發(fā)網(wǎng)絡(luò)請(qǐng)求，獲取域名對(duì)應(yīng)的IP時(shí)，會(huì)提前進(jìn)行本地過(guò)期時(shí)間判斷，時(shí)間是60s，如果過(guò)期，會(huì)發(fā)起單域名的請(qǐng)求并緩存起來(lái)，這樣會(huì)持續(xù)延長(zhǎng)域名結(jié)果的過(guò)期時(shí)間。本地過(guò)期時(shí)間與上面提到的TTL是客戶端和服務(wù)端的雙重過(guò)期時(shí)間，目的是在異常情況下可以雙重保證過(guò)期時(shí)間的準(zhǔn)確性。

4.4 基礎(chǔ)能力層

基礎(chǔ)能力層主要提供給DNS策略層所需要的基礎(chǔ)能力，包括IPv4/IPv6協(xié)議棧探測(cè)的能力，數(shù)據(jù)傳輸?shù)哪芰Γ彺鎸?shí)現(xiàn)的能力，下面將講解每種能力的具體實(shí)現(xiàn)。

【4.4.1 IPv4/IPv6協(xié)議棧探測(cè)】：

百度App的IPv6改造正在如火如荼的進(jìn)行中，端上在HTTPDNS的IP選取上如何知道目前屬于哪個(gè)協(xié)議棧成為關(guān)鍵性問(wèn)題，并且這種判斷要求性能極高，因?yàn)镮P選取的頻次實(shí)在是太高了。

我們選取的方案是UDP Connect，那么何為UDP Connect？

大家都知道TCP是面向連接的，傳輸數(shù)據(jù)前客戶端都要調(diào)用connect方法通過(guò)三次握手建立連接，UDP是面向無(wú)連接的，無(wú)需建立連接便能收發(fā)數(shù)據(jù)，但是如果我們調(diào)用了UDP的connect方法會(huì)發(fā)生什么呢？當(dāng)我們調(diào)用UDP的connect方法時(shí)，系統(tǒng)會(huì)檢測(cè)其端口是否可用，地址是否正確，然后記錄對(duì)端的IP地址和端口號(hào)，返回給調(diào)用者，所以UDP Connect不會(huì)像TCP Connect發(fā)起三次握手，發(fā)生網(wǎng)絡(luò)真實(shí)損耗，UDP客戶端只有調(diào)用send或者sendto方法后才會(huì)真正發(fā)起真實(shí)網(wǎng)絡(luò)損耗。

▲ UDP Connect原理

有了UDP Connect的基礎(chǔ)保障，我們?cè)谏蠈幼隽司彺鏅C(jī)制，用來(lái)減少系統(tǒng)調(diào)用的損耗，時(shí)機(jī)上目前僅在冷啟動(dòng)和網(wǎng)絡(luò)切換會(huì)觸發(fā)探測(cè)，在同一種網(wǎng)絡(luò)制式下探測(cè)一次基本可以確保當(dāng)前網(wǎng)絡(luò)是IPv4棧還是IPv6棧。

目前百度App客戶端對(duì)于IPv4/IPv6雙棧的策略是保守的，僅在IPv6-only的情況下使用v6的IP，其余使用的都是v4的IP，雙棧下的方案后續(xù)需要優(yōu)化，業(yè)內(nèi)目前標(biāo)準(zhǔn)的做法是happy eyeball算法。

什么叫happy eyeball呢？

就是不會(huì)因?yàn)镮Pv4或IPv6的故障問(wèn)題，導(dǎo)致用戶的眼球一直在等待加載或者出錯(cuò)，這就是happy eyeball名字的由來(lái)。happy eyeball有v1版本RFC6555和v2版本RFC8305，前者是Cisco提出來(lái)的，后者是蘋果提出來(lái)的。happy eyeball解決的核心問(wèn)題是，復(fù)雜環(huán)境下v4和v6 IP選取的問(wèn)題，它是一套整體解決方案，對(duì)于域名查詢的處理，地址的排序，連接的嘗試等方面均做出了規(guī)定，感興趣的同學(xué)可以查看參考資料里的【5】和【6】。

【4.4.2 數(shù)據(jù)傳輸】：

數(shù)據(jù)傳輸主要提供網(wǎng)絡(luò)請(qǐng)求的能力和數(shù)據(jù)解析的能力。

（1）網(wǎng)絡(luò)請(qǐng)求失敗重試的機(jī)制，獲取HTTPDNS結(jié)果的成功率會(huì)大大影響HTTPDNS的命中率，所以客戶端會(huì)有一個(gè)三次重試的機(jī)制，保障成功率。

（2）數(shù)據(jù)解析異常的機(jī)制，如果獲取的HTTPDNS的結(jié)果存在異常，將不會(huì)覆蓋端上的緩存。

【4.4.3 緩存實(shí)現(xiàn)】：

緩存的實(shí)現(xiàn)基本可以分為磁盤緩存和內(nèi)存緩存，對(duì)于HTTPDNS的緩存場(chǎng)景，我們是選其一還是都選擇呢？

百度App選擇的是內(nèi)存緩存，目的是防止我們自己的服務(wù)出現(xiàn)問(wèn)題，運(yùn)維同學(xué)在緊急情況下切換流量，如果做了磁盤緩存，會(huì)導(dǎo)致百度App在重啟后也可能不可用，但這種問(wèn)題會(huì)導(dǎo)致APP在冷啟動(dòng)期間，HTTPDNS結(jié)果未返回前，還是存在故障或者劫持的風(fēng)險(xiǎn)，綜合評(píng)估來(lái)看可以接受，如果出現(xiàn)這種極端情況，影響的是冷啟動(dòng)階段的一些請(qǐng)求，但只要HTTPDNS結(jié)果返回后便會(huì)恢復(fù)正常。

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ù)沒(méi)有使用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的劫持（在出問(wèn)題時(shí)顯得尤為重要）；

2）降低網(wǎng)絡(luò)時(shí)延（在調(diào)度不準(zhǔn)確的情況下，會(huì)增大網(wǎng)絡(luò)的時(shí)延，降低用戶的體驗(yàn)）。

這兩點(diǎn)收益需要結(jié)合業(yè)務(wù)來(lái)說(shuō)，以百度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ì)差很多。

1）基礎(chǔ)知識(shí)要了解學(xué)習(xí)，要夯實(shí)：網(wǎng)絡(luò)相關(guān)的內(nèi)容很多，很雜，不易學(xué)習(xí)，啃過(guò)IETF發(fā)布的RFC的同學(xué)應(yīng)該深有感觸。

2）學(xué)會(huì)將看不見(jiàn)的網(wǎng)絡(luò)變成看得見(jiàn)的：很多自認(rèn)為對(duì)于網(wǎng)絡(luò)很了解的同學(xué)，動(dòng)不動(dòng)就背誦tcp協(xié)議原理，擁塞控制算法，滑動(dòng)窗口大小等，但真正遇到線上問(wèn)題，無(wú)從下手。對(duì)于客戶端同學(xué)，我們?cè)赑C上要學(xué)會(huì)使用tcpdump和Wireshark等工具，適當(dāng)使用Fiddler和Charles等工具，很多時(shí)候電腦和手機(jī)的網(wǎng)絡(luò)環(huán)境不見(jià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ā)揮了作用，你要能看懂握手過(guò)程，傳輸過(guò)程，異常斷開過(guò)程等。

3）有了以上兩點(diǎn)的準(zhǔn)備，接下來(lái)需要一個(gè)會(huì)出現(xiàn)各種網(wǎng)絡(luò)問(wèn)題的平臺(tái)，給你積累經(jīng)驗(yàn)，讓一個(gè)個(gè)高壓下的線上問(wèn)題錘煉你，折磨你。

4）網(wǎng)絡(luò)優(yōu)化是需要數(shù)據(jù)支撐的：但數(shù)據(jù)的采集和分析是需要經(jīng)驗(yàn)的，有些數(shù)據(jù)一眼看下去就是不靠譜的，有些數(shù)據(jù)怎么分析都是負(fù)向收益的，一般來(lái)說(shuō)是有三重奏來(lái)對(duì)數(shù)據(jù)進(jìn)行分析的，一，線下數(shù)據(jù)的采集和分析，得出正向收益，二，灰度數(shù)據(jù)的采集和分析，得出正向收益，三，線上數(shù)據(jù)的采集和分析，得出正向收益。

5）數(shù)據(jù)的正向收益，不能完全證明提升了用戶的體驗(yàn)，所以很多時(shí)候需要針對(duì)特定場(chǎng)景，特定case來(lái)分析和優(yōu)化，就算是大家公認(rèn)做的很好的微信，也不是在所有場(chǎng)景下都能保證體驗(yàn)上的好。

[1] https://chromium.googlesource.com/chromium/src/+/HEAD/docs/android_build_instructions.md

[2] https://chromium.googlesource.com/chromium/src/+/HEAD/docs/ios/build_instructions.md

[3] https://github.com/Tencent/mars

[4] https://tools.ietf.org/html/rfc7858

[5] https://tools.ietf.org/html/rfc6555

[6] https://tools.ietf.org/html/rfc8305

（原文鏈接：點(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次揮手過(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開發(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)畫來(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開發(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ú)線通信網(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ú)線上網(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ā)布于：http://www.52im.net/thread-2472-1-1.html）

網(wǎng)頁(yè)標(biāo)題：DNS如何優(yōu)化-百度APP移動(dòng)端網(wǎng)絡(luò)深度優(yōu)化分享
文章網(wǎng)址：http://www.rwnh.cn/news4/101554.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)建站、網(wǎng)站建設(shè)、網(wǎng)站收錄、網(wǎng)站排名、云服務(wù)器、電子商務(wù)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)