本文引用了顏向群發(fā)表于高可用架構(gòu)公眾號(hào)上的文章《聊聊HTTPS環(huán)境DNS優(yōu)化：美圖App請(qǐng)求耗時(shí)節(jié)約近半案例》的部分內(nèi)容，感謝原作者。
1、引言
移動(dòng)互聯(lián)網(wǎng)時(shí)代，APP 廠商之間的競(jìng)爭(zhēng)非常激烈，而良好的用戶體驗(yàn)是必須優(yōu)先考慮的，美圖產(chǎn)品以高顏值著稱，對(duì)產(chǎn)品的用戶體驗(yàn)非常重視。從技術(shù)的角度來(lái)看，客戶端的體驗(yàn)優(yōu)化當(dāng)中 DNS 優(yōu)化是非常關(guān)鍵的一環(huán)，怎么降低 DNS 的耗時(shí)、怎么減少域名劫持等問(wèn)題，都是大家需要重點(diǎn)解決的研發(fā)問(wèn)題。
本文介紹美圖APP在移動(dòng)端DNS優(yōu)化的實(shí)踐（主要針對(duì)HTTPS協(xié)議），文章內(nèi)容從DNS問(wèn)題、原理到最終優(yōu)化效果，講解的較全面，值得學(xué)習(xí)和借鑒。
另外：如您想詳細(xì)了解移動(dòng)端DNS的各種雜癥及主流解決方案，推薦詳讀《全面了解移動(dòng)端DNS域名劫持等雜癥：原理、根源、HttpDNS解決方案等》。
（原文鏈接：http://www.52im.net/thread-2172-1-1.html）
2、相關(guān)文章
《TCP/IP詳解 卷1：協(xié)議 - 第14章 DNS:域名系統(tǒng)》
《網(wǎng)絡(luò)編程懶人入門(mén)(七)：深入淺出，全面理解HTTP協(xié)議》
《現(xiàn)代移動(dòng)端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請(qǐng)求速度、弱網(wǎng)適應(yī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é)》
《全面了解移動(dòng)端DNS域名劫持等雜癥：原理、根源、HttpDNS解決方案等》
3、內(nèi)容概述
DNS 服務(wù)作用于網(wǎng)絡(luò)連接之前，將域名解析為 IP 地址供后續(xù)流程進(jìn)行連接（原理詳見(jiàn)：《TCP/IP詳解 卷1：協(xié)議 - 第14章 DNS:域名系統(tǒng)》）。
DNS 查詢時(shí)，會(huì)先在本地緩存中嘗試查找，如果不存在或是記錄過(guò)期，就繼續(xù)向 DNS 服務(wù)器發(fā)起遞歸查詢,這里的 DNS 服務(wù)器一般就是運(yùn)營(yíng)商的 DNS 服務(wù)器。
在這過(guò)程中，會(huì)產(chǎn)生一些不可控的問(wèn)題。
美圖的移動(dòng)端產(chǎn)品在實(shí)際用戶環(huán)境下會(huì)面臨 DNS 劫持、耗時(shí)波動(dòng)等問(wèn)題（詳見(jiàn)：《全面了解移動(dòng)端DNS域名劫持等雜癥：原理、根源、HttpDNS解決方案等》），這些 DNS 環(huán)節(jié)的不穩(wěn)定因素，導(dǎo)致后續(xù)網(wǎng)絡(luò)請(qǐng)求被劫持或是直接失敗, 對(duì)產(chǎn)品的用戶體驗(yàn)產(chǎn)生不好的影響。
為此，我們對(duì)移動(dòng)端產(chǎn)品的 DNS 解析進(jìn)行了優(yōu)化探索，產(chǎn)生了相應(yīng)的 SDK。在這過(guò)程中，我們參考借鑒了業(yè)內(nèi)的主流方案，也進(jìn)行了一些實(shí)踐上的思考。
下面的內(nèi)容會(huì)主要以 Android 平臺(tái)來(lái)進(jìn)行說(shuō)明。
4、LocalDNS VS HTTP DNS
在長(zhǎng)期的實(shí)踐中，互聯(lián)網(wǎng)公司發(fā)現(xiàn) LocalDNS 會(huì)存在如下幾個(gè)問(wèn)題：
1）域名緩存：運(yùn)營(yíng)商 DNS 緩存域名解析結(jié)果，將用戶導(dǎo)向網(wǎng)內(nèi)緩存服務(wù)器；
2）解析轉(zhuǎn)發(fā) & 出口 NAT：運(yùn)營(yíng)商 DNS 轉(zhuǎn)發(fā)查詢請(qǐng)求或是出口 NAT 導(dǎo)致流量調(diào)度策略失效。
什么是LocalDNS？一般來(lái)說(shuō)，LocalDNS就是指本地ISP運(yùn)營(yíng)商的DNS：
▲ 圖中“局部DNS服務(wù)器”即是LocalDNS
為了解決 LocalDNS 的這些問(wèn)題，業(yè)內(nèi)也催生了 HTTP DNS 的概念（注：如您對(duì)LocalDNS、HTTP DNS這些概念還不了解，請(qǐng)務(wù)必先閱讀《全面了解移動(dòng)端DNS域名劫持等雜癥：原理、根源、HttpDNS解決方案等》）。
HTTP DNS的基本原理如下:
原本用戶進(jìn)行 DNS 解析是向運(yùn)營(yíng)商的 DNS 服務(wù)器發(fā)起 UDP 報(bào)文進(jìn)行查詢，而在 HTTP DNS 下，我們修改為用戶帶上待查詢的域名和本機(jī) IP 地址直接向 HTTP WEB 服務(wù)器發(fā)起 HTTP 請(qǐng)求，這個(gè) HTTP WEB 將返回域名解析后的 IP 地址。
比如 DNSPod 的實(shí)現(xiàn)原理如下:
相比 LocalDNS，HTTP DNS 會(huì)具備如下優(yōu)勢(shì):
1）根治域名解析異常：繞過(guò)運(yùn)營(yíng)商的 DNS，向具備 DNS 解析功能的 HTTP WEB 服務(wù)器發(fā)起查詢；
2）調(diào)度精準(zhǔn)：HTTP DNS 能夠直接獲取到用戶的 IP 地址，從而實(shí)現(xiàn)準(zhǔn)確導(dǎo)流；
3）擴(kuò)展性強(qiáng)：本身基于 HTTP 協(xié)議，可以實(shí)現(xiàn)更強(qiáng)大的功能擴(kuò)展。
那么，是否直接全部走 HTTP DNS 呢?
5、美圖APP的DNS 優(yōu)化策略探索
HTTP DNS 相比 LocalDNS 存在一些優(yōu)勢(shì), 然而 HTTP DNS 本身也是存在一定的成本問(wèn)題。
美圖的產(chǎn)品線豐富，涉及的域名也較為廣泛，為了適應(yīng)各產(chǎn)品的實(shí)際場(chǎng)景，在實(shí)踐中我們?cè)O(shè)計(jì)了較為靈活的策略控制。
首先，在策略上我們并未完全放棄 LocalDNS。
一個(gè) App 涉及的域名眾多，在策略上我們能夠配置其核心 API 域名走 HTTP DNS，而對(duì)于非核心請(qǐng)求我們?nèi)韵Ｍ葒L試走 LocalDNS, 在異常情況下才升級(jí)走 HTTP DNS。
那么如何判斷 LocalDNS 的異常情況呢?
我們選擇了幾個(gè)指標(biāo)來(lái)衡量一個(gè) DNS 服務(wù)器的質(zhì)量情況:
1）IP 記錄的 TTL 時(shí)間：在 DNS 劫持發(fā)生的情況下，返回的 TTL 可能會(huì)有非常大的值；
2）解析耗時(shí)：如果一個(gè) DNS 服務(wù)器解析耗時(shí)不理想，那么它也不是我們希望的；
3）返回的 IP 的可連接性：對(duì)返回的 IP 進(jìn)行質(zhì)量測(cè)試，如果連接狀況不佳，那么這個(gè) DNS 服務(wù)器有劫持的可疑。
在 Android 平臺(tái)上，通過(guò)系統(tǒng)方法獲得的解析結(jié)果信息是非常有限的，上面的指標(biāo)有的將無(wú)法獲取，因此在實(shí)踐中我們會(huì)自己去構(gòu)造 DNS 查詢報(bào)文，向運(yùn)營(yíng)商的多個(gè) DNS 服務(wù)器發(fā)起查詢。
通過(guò)上面幾個(gè)指標(biāo)的綜合評(píng)定，當(dāng) LocalDNS 表現(xiàn)不佳的時(shí)候，策略上我們將升級(jí)走 HTTP DNS，嘗試讓用戶獲取更好的 DNS 解析效果。
在 DNS 解析環(huán)節(jié)，還有一個(gè)我們比較關(guān)心的指標(biāo)，那就是 DNS 解析的耗時(shí)：
1）LocalDNS 在過(guò)期的情況下，會(huì)發(fā)起遞歸查詢，這個(gè)時(shí)間是不可控的，在部分情況下甚至能達(dá)到數(shù)秒級(jí)別；
2）HTTP DNS 相對(duì)會(huì)好一些，但正常來(lái)看，也會(huì)有200ms 左右的耗時(shí)。
這個(gè)時(shí)間能否再優(yōu)化一些呢？
我們 SDK 在本地構(gòu)建了自己的記錄緩存池，每次通過(guò) LocalDNS 或是 HTTP DNS 解析得到記錄都存在緩沖池中。
當(dāng)然，這個(gè)是普遍的做法，系統(tǒng)底層的 netdb 庫(kù)也是這樣實(shí)現(xiàn)。
區(qū)別在于我們做了一個(gè)小改動(dòng)：對(duì)于過(guò)期的記錄我們采用懶更新的策略，當(dāng)查到過(guò)期的緩存記錄時(shí)，先返回過(guò)期記錄給用戶，同時(shí)再異步重新發(fā)起 DNS 查詢更新緩存記錄。
這個(gè)小改動(dòng)能夠保證我們二次解析時(shí)都能命中本地緩存，極大地降低 DNS 解析耗時(shí)，不過(guò)它也帶來(lái)了一定的風(fēng)險(xiǎn)性。
因此實(shí)踐中：我們也會(huì)添加異步定期的 DNS 記錄緩存池掃描功能，及時(shí)發(fā)現(xiàn)緩存中的過(guò)期記錄并進(jìn)行更新，也降低 App 命中過(guò)期記錄的情況。
5、美圖APP無(wú)侵入的 SDK 接入方式探索
在 DNS 優(yōu)化的實(shí)踐中，我們遇到最大的問(wèn)題，倒不是策略層面設(shè)計(jì)問(wèn)題，而是我們的 DNS SDK 運(yùn)用到實(shí)際 App 產(chǎn)品業(yè)務(wù)上的姿勢(shì)問(wèn)題。
5.1 IP直連方案及各種坑
業(yè)內(nèi)對(duì) HTTP DNS 在實(shí)際業(yè)務(wù)中的接入方式多采用 IP 直連的形式，即原本直接請(qǐng)求 http://www.meitu.com，現(xiàn)在我們先調(diào)用 SDK 進(jìn)行域名解析，拿到 IP 地址比如 1.1.1.1，然后替換域名為: http://1.1.1.1/。
這樣操作之后， 由于 URL 中 HOST 已經(jīng)是 IP 地址，網(wǎng)絡(luò)請(qǐng)求庫(kù)將跳過(guò)域名解析環(huán)節(jié)，直接向 1.1.1.1 服務(wù)器發(fā)起 HTTP 請(qǐng)求。
在實(shí)際操作中，對(duì)于 IP 直連的方案我們踩了不少的坑。
首先，對(duì)于 HTTP 請(qǐng)求，采用 IP 直連的方案后，我們還是需要進(jìn)行的一個(gè)操作是手動(dòng)配置 Header 中的 HOST :
URL htmlUrl = new URL("http://1.1.1.1/");
HttpURLConnection connection = (HttpURLConnection) htmlUrl.openConnection();
connection.setRequestProperty("Host","www.meitu.com");
HTTP 協(xié)議相對(duì)比較容易，只需要處理 HOST，那么 HTTPS 呢？
發(fā)起HTTPS請(qǐng)求首先需要進(jìn)行 SSL/TLS 握手，其流程如下:
1）客戶端發(fā)送 Client Hello，攜帶隨機(jī)數(shù)、支持的加密算法等信息；
2）服務(wù)端收到請(qǐng)求后，選擇合適的加密算法，連同公鑰證書(shū)、隨機(jī)數(shù)等信息返回給客戶端；
3）客戶端檢驗(yàn)服務(wù)端證書(shū)的合法性，計(jì)算產(chǎn)生隨機(jī)數(shù)并用證書(shū)公鑰加密發(fā)送給服務(wù)端；
4）服務(wù)端通過(guò)私鑰獲取隨機(jī)數(shù)信息，基于之前的交互信息計(jì)算得到協(xié)商密鑰并通知給客戶端；
5）客戶端驗(yàn)證服務(wù)端發(fā)送的數(shù)據(jù)和密鑰，通過(guò)后雙方握手完成，開(kāi)始進(jìn)行加密通信。
在我們采用 IP 直連的形式后，上述 HTTPS 的第三步會(huì)發(fā)生問(wèn)題,。
客戶端檢驗(yàn)服務(wù)端下發(fā)的證書(shū)這動(dòng)作包含兩個(gè)步驟:
1）客戶端用本地保存的根證書(shū)解開(kāi)證書(shū)鏈，確認(rèn)服務(wù)端的證書(shū)是由可信任的機(jī)構(gòu)頒發(fā)的；
2）客戶端需要檢查證書(shū)的 Domain 域和擴(kuò)展域是否包含本次請(qǐng)求的 HOST。
證書(shū)的驗(yàn)證需要這兩個(gè)步驟都檢驗(yàn)通過(guò)才能夠進(jìn)行后續(xù)流程，否則 SSL/TLS 握手將在這里失敗結(jié)束。
由于在 IP 直連下，我們給網(wǎng)絡(luò)請(qǐng)求庫(kù)的 URL 中 host 部分已經(jīng)被替換成了 IP 地址，
因此證書(shū)驗(yàn)證的第二步中，默認(rèn)配置下 “本次請(qǐng)求的 HOST” 會(huì)是一個(gè) IP 地址，這將導(dǎo)致 domain 檢查不匹配，最終 SSL/TLS 握手失敗。
那么該如何解決這個(gè)問(wèn)題？
解決 SSL/TLS 握手中域名校驗(yàn)問(wèn)題的方法在于我們重新配置 HostnameVerifier, 讓請(qǐng)求庫(kù)用實(shí)際的域名去做域名校驗(yàn)。
代碼示例如下:
finalURL htmlUrl = newURL("https://1.1.1.1/");
HttpsURLConnection connection = (HttpsURLConnection) htmlUrl.openConnection();
connection.setRequestProperty("Host","www.meipai.com");
connection.setHostnameVerifier(newHostnameVerifier() {
@Override
publicbooleanverify(String hostname, SSLSession session) {
returnHttpsURLConnection.getDefaultHostnameVerifier()
.verify("www.meipai.com",session);
}
});
我們又解決了一個(gè)問(wèn)題，那么 IP 直連下， HTTPS 的問(wèn)題都搞定了嗎？
沒(méi)有，HTTPS 還有 SNI 的場(chǎng)景要特殊處理。
SNI（Server Name Indication）是為了解決一個(gè)服務(wù)器使用多個(gè)域名和證書(shū)的SSL/TLS擴(kuò)展。
它的基本工作原理如下：
1）服務(wù)端配置有多個(gè)域名和對(duì)應(yīng)的證書(shū)。客戶端在與服務(wù)器建立SSL鏈接之時(shí),先發(fā)送自己要訪問(wèn)站點(diǎn)的域名；
2）服務(wù)器根據(jù)這個(gè)域名返回一個(gè)合適的證書(shū)。
跟上面 Domain 校驗(yàn)的情況類似，這里的網(wǎng)絡(luò)請(qǐng)求庫(kù)默認(rèn)發(fā)送給服務(wù)端的 "要訪問(wèn)站點(diǎn)的域名" 就是我們替換后的 IP 地址。
服務(wù)端在收到這樣一個(gè) IP 地址形式的域名后將是一臉懵逼，找不到對(duì)應(yīng)的證書(shū)，最后只好下發(fā)一個(gè)默認(rèn)的域名證書(shū)回來(lái)。
接下來(lái)發(fā)生的是，客戶端在檢驗(yàn)證書(shū)的 Domain 域時(shí)，怎么也檢查不通過(guò)，因?yàn)榉?wù)端下發(fā)的證書(shū)本來(lái)就不是對(duì)應(yīng)該域名的。
最后 SSL/TLS 握手失敗告終。
上述這個(gè) SNI 場(chǎng)景下的問(wèn)題，我們是否有辦法解決呢？
可以解決，需用客戶端重新定制 SSLSocketFactory , 不過(guò)修改的代碼相對(duì)較多，這里就不列舉了。
如果我們 SDK 要接入到 App 實(shí)際業(yè)務(wù)中，到 HTTPS SNI 場(chǎng)景處理這里，相信很多同學(xué)都崩潰了，接入的工作量其實(shí)也不低。
很多情況下可能就做了妥協(xié)，只有 Okhttp 場(chǎng)景才使用這個(gè) SDK，因?yàn)?Okhttp 本身支持 DNS 替換，沒(méi)有上面那些問(wèn)題。
在美圖的實(shí)踐中，我們不僅僅希望 Okhttp 的請(qǐng)求才進(jìn)行這個(gè) DNS 優(yōu)化，我們希望在 App H5 頁(yè)面加載、播放器播放等場(chǎng)景也能應(yīng)用相應(yīng)的優(yōu)化。
在這樣的需求下，IP 直連的接入方案帶來(lái)的接入工作量其實(shí)不低，甚至需要改動(dòng)到部分輪子。
在最初的實(shí)踐中，我們也的確嘗試了落實(shí) IP 直連 到各個(gè)模塊，然而即使克服了改造的工作量問(wèn)題，實(shí)際運(yùn)行上還是會(huì)有不少坑。
5.2 美圖最終使用的無(wú)侵入式 DNS SDK 集成方案
那么，有沒(méi)有更合適的一種技術(shù)方案，能夠降低 我們 DNS SDK 的接入工作量，也能兼顧各種使用場(chǎng)景，比如 HTTPS、RTMP 協(xié)議等？
基于這樣的目標(biāo)，我們?cè)趯?shí)踐中嘗試探索了一種對(duì)業(yè)務(wù)集成友好的無(wú)侵入式 DNS SDK 集成方案。下面我們以 Android 平臺(tái)進(jìn)行說(shuō)明。
我們知道在 Java 層面上進(jìn)行 DNS 解析的基本方式是調(diào)用如下方法:
InetAddress.getAllByName("www.meipai.com");
Android 平臺(tái)上常用的 Okhttp、HttpUrlConnection 等網(wǎng)絡(luò)請(qǐng)求庫(kù)都會(huì)依賴這個(gè)形式的 DNS 解析。
我們深入分析 InetAddress 的運(yùn)行流程，其大致如下:
在上述流程中我們可以知道，InetAddress 會(huì)有到 AddressCache 嘗試獲取已緩存記錄的動(dòng)作，而這里 AddessCache 是一個(gè) static 的 map 結(jié)構(gòu)變量。
因此，在這里我們來(lái)對(duì)它做點(diǎn)小手腳 :
1）模仿系統(tǒng)的 AddressCache 構(gòu)造一個(gè)我們自己的 AddressCahce 結(jié)構(gòu)，不過(guò)它的 get 方法被替換為從我們 SDK 獲取解析記錄；
2）通過(guò)反射的形式用我們修改后的 AddressCache 替換掉系統(tǒng)的 AddressCache 變量。
這個(gè)偷天換日的操作之后，HttpsUrlConnection 等 Java 層網(wǎng)絡(luò)請(qǐng)求在進(jìn)行 DNS 解析時(shí)就會(huì)是這樣一個(gè)流程:
通過(guò)這個(gè)形式，我們能夠完美解決 Java 層的 DNS SDK 接入問(wèn)題，對(duì)于業(yè)務(wù)方來(lái)說(shuō)，他們并不需要做任何 URL 替換操作，對(duì)應(yīng)的 HTTPS 場(chǎng)景下的問(wèn)題也不復(fù)存在。
Java 層的接入解決了， 那么 Native 層呢？
我們知道在 Android 平臺(tái)上，像 WebView、播放器等模塊他們進(jìn)行網(wǎng)絡(luò)連接的操作都是在 native 層進(jìn)行的，并不會(huì)調(diào)用到 Java 層的 InetAddress 方法。
首先在 C/C++ 層，我們知道進(jìn)行 DNS 解析會(huì)使用 getaddrinfo 或是 gethostbyname2 這兩個(gè)函數(shù)。
另外我們還知道，在 Android 等 Linux 系統(tǒng)下，對(duì)于 .so 這類可共享對(duì)象文件會(huì)是 ELF 的文件格式。
因此從這些已知信息，我們可以得到下列一些情況：我們的 App 中 a.so 中直接使用到了系統(tǒng) libc.so 中的 getaddrinfo 函數(shù)，那么根據(jù) ELF 文件規(guī)范，在 a.so 的 .rel.plt 表中會(huì)有如下關(guān)系定義: getaddrinfo ==> 0xFFFFFF 。
.rel.plt 表中的映射關(guān)系為 a.so 的運(yùn)行指出了 getaddrinfo 這個(gè)外部符號(hào)在當(dāng)前內(nèi)存空間中的絕對(duì)地址。
正常情況下，a.so 中執(zhí)行到 getaddrinfo 的函數(shù)流程是這樣的：
那么在這里，我們是否可以手動(dòng)修改這個(gè)映射表內(nèi)容，把 getaddrinfo 的內(nèi)存地址替換成我們的 my_getaddrinfo 地址呢？
這樣，a.so 在實(shí)際運(yùn)行時(shí)會(huì)被拐到我們的 my_getaddrinfo 中？
實(shí)際上，確實(shí)是可行的。 我們嘗試在 SDK 啟動(dòng)后，對(duì) a.so 的 .rel.plt 表進(jìn)行修改，達(dá)到接管 a.so DNS 的目的。
修改后的 a.so 運(yùn)行流程如下：
通過(guò)上面的方式，我們能夠比較完美地接管 App 在 Java 層 和 Native 層 DNS 過(guò)程，實(shí)現(xiàn)業(yè)務(wù)方無(wú)任何額外改動(dòng)的情況下運(yùn)用我們的 DNS SDK 優(yōu)化效果。
6、SDK 上線后的效果表現(xiàn)
在實(shí)際運(yùn)用中，我們?nèi)〉昧吮容^好的效果。得益于 DNS SDK 在命中本地緩存率上的策略優(yōu)化，我們的移動(dòng)端產(chǎn)品在網(wǎng)絡(luò)請(qǐng)求中 DNS 解析環(huán)節(jié)耗時(shí)得到降低。
從實(shí)際監(jiān)控?cái)?shù)據(jù)來(lái)看，完整網(wǎng)絡(luò)請(qǐng)求的耗時(shí)也能夠降低 100ms 左右：
通過(guò) HTTP DNS 的引入和 LocalDNS 優(yōu)化升級(jí)策略，我們的網(wǎng)絡(luò)請(qǐng)求成功率有提升，在未知主機(jī)等具體錯(cuò)誤率表現(xiàn)出下降的趨勢(shì)。
由于 SDK 層面本身做好了靈活的策略配置，我們通過(guò)線上監(jiān)控和配置也讓各產(chǎn)品在效益和成本之間取得一個(gè)最佳的平衡點(diǎn)。
附錄：更多網(wǎng)絡(luò)通信方面的精華文章
《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ò)編程懶人入門(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)(六)：史上最通俗的集線器、交換機(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í)減小近半》
>> 更多同類文章 ……
（原文鏈接：http://www.52im.net/thread-2172-1-1.html）