對于互聯網，域名是訪問的第一跳，而這一跳很多時候會“失足”（尤其是移動端網絡），導致訪問錯誤內容、失敗連接等，讓用戶在互聯網上暢游的爽快瞬間消失。
而對于這關鍵的第一跳，包括鵝廠在內的國內互聯網大廠，都在持續深入地研究和思考對策，本文將就鵝廠團隊在這一塊的技術實踐，做一個深度的總結和技術分享，希望給大家帶來些許啟發。
學習交流：
- 即時通訊/推送技術開發交流4群：101279154[推薦]- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
- 即時通訊/推送技術開發交流4群：101279154[推薦]
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
（本文同步發布于：http://www.52im.net/thread-2121-1-1.html）
《網絡編程懶人入門(一)：快速理解網絡通信協議（上篇）》《網絡編程懶人入門(二)：快速理解網絡通信協議（下篇）》《網絡編程懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》《網絡編程懶人入門(七)：深入淺出，全面理解HTTP協議》《網絡編程懶人入門(九)：通俗講解，有了IP地址，為何還要用MAC地址？》《技術掃盲：新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解》《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》《腦殘式網絡編程入門(五)：每天都在用的Ping命令，它到底是什么？》《腦殘式網絡編程入門(六)：什么是公網IP和內網IP？NAT轉換又是什么鬼？》
《網絡編程懶人入門(一)：快速理解網絡通信協議（上篇）》
《網絡編程懶人入門(二)：快速理解網絡通信協議（下篇）》
《網絡編程懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》
《網絡編程懶人入門(七)：深入淺出，全面理解HTTP協議》
《網絡編程懶人入門(九)：通俗講解，有了IP地址，為何還要用MAC地址？》
《技術掃盲：新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解》
《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
《腦殘式網絡編程入門(五)：每天都在用的Ping命令，它到底是什么？》
《腦殘式網絡編程入門(六)：什么是公網IP和內網IP？NAT轉換又是什么鬼？》
但凡使用域名來給用戶提供服務的互聯網企業，都或多或少地無法避免在有中國特色的互聯網環境中遭遇到各種域名被緩存、用戶跨網訪問緩慢等問題。那么對于騰訊這樣的域名數量在10萬級別的互聯網公司來講，域名解析異常的情況到底有多嚴重呢？
每天騰訊的分布式域名解析監測系統在不停地對全國所有的重點LocalDNS（指運營商的DNS服務）進行探測，騰訊域名在全國各地的日解析異常量是已經超過了80萬條（這方面，來自移動端的異常尤為突出）。這給騰訊的業務帶來了巨大的損失。為此騰訊建立了專業的團隊與各個運營商進行了深度溝通，但是由于各種原因，處理效率及效果均不能達到騰訊各業務部門的需求。
除了和運營商進行溝通，有沒有一種技術上的方案，能從根源上解決域名解析異常及用戶訪問跨網的問題呢？這是包括騰訊在內的很多國內互聯網大廠技術團隊一直在思考的問題。
要想理解本文將要討論的DNS各種問題，我們需要首先來復習一下DNS的基本原理和相關知識。
DNS（Domain Name System，域名系統），DNS 服務用于在網絡請求時，將域名轉為 IP 地址。能夠使用戶更方便的訪問互聯網，而不用去記住能夠被機器直接讀取的 IP 數串。
DNS的基一原理如下圖所示：
傳統的基于 UDP 協議的公共 DNS 服務極易發生 DNS 劫持，從而造成安全問題。
如上圖所示，典型DNS域名系統的結構如下：
1）Root 域名：DNS 域名使用時，規定由尾部句號來指定名稱位于根或更高級別的域層次結構；
2）Top Level 頂級域名：用來指示某個國家、地區或組織使用的名稱的類型名稱。如 .net；
3）Second Level 域名：個人或組織在 Internet 上使用的注冊名稱。如 52im.net；
4）Third Level 域名：已注冊的二級域名派生的域名。如 docs.52im.net。
如上圖所示，這是一個典型的域名解析過程：
1）瀏覽器中輸入 www.52im.net，發出解析請求；
2）本機的域名解析器 resolver 程序查詢本地緩存和 host 文件中是否為域名的映射關系，如果有則調用這個 IP 地址映射，完成解析；
3）如果 hosts 與本地解析器緩存都沒有相應的網址映射關系，則本地解析器會向 TCP/IP 參數中設置的首選 DNS 服務器（我們叫它 Local DNS 服務器）發起一個遞歸的查詢請求；
4）服務器收到查詢時，如果要查詢的域名由本機負責解析，則返回解析結果給客戶機，完成域名解析，此解析具有權威性。如果要查詢的域名，不由 Local DNS 服務器解析，但該服務器已緩存了此網址映射關系，則調用這個 IP 地址映射，完成域名解析，此解析不具有權威性；
5）如果 Local DNS 服務器本地區域文件與緩存解析都失效，則根據 Local DNS 服務器的設置（是否遞歸）進行查詢，如果未用開啟模式，Local DNS 就把請求發至13臺 Root DNS。如果用的是遞歸模式，此 DNS 服務器就會把請求轉發至上一級 DNS 服務器，由上一級服務器進行解析，上一級服務器如果不能解析，或找根 DNS 或把轉請求轉至上上級，以此循環；
6）Root DNS 服務器收到請求后會判斷這個域名是誰來授權管理，并會返回一個負責該頂級域名服務器的一個 IP；
7）Local DNS 服務器收到 IP 信息后，將會聯系負責 .net 域的這臺服務器；
8）負責 .com 域的服務器收到請求后，如果自己無法解析，它就會找一個管理 .net 域的下一級 DNS 服務器地址給本地 DNS 服務器；
9）當 Local DNS 服務器收到這個地址后，就會找 52im.net 域服務器，10、11重復上面的動作，進行查詢；
10）最后 www.52im.net 返回需要解析的域名的 IP 地址給 Local DNS 服務器；
11）Local DNS 服務器緩存這個解析結果（同時也會緩存，6、8、10返回的結果）；
12）Local DNS 服務器同時將結果返回給本機域名解析器；
13）本機緩存解析結果；
14）本機解析器將結果返回給瀏覽器；
15）瀏覽器通過返回的 IP 地址發起請求。
遞歸查詢：如果主機所詢問的本地域名服務器不知道被查詢域名的 IP 地址，那么本地域名服務器就以 DNS 客戶的身份，向其他根域名服務器繼續發出查詢請求報文，而不是讓該主機自己進行下一步的查詢。
迭代查詢：當根域名服務器收到本地域名服務器發出的迭代查詢請求報文時，要么給出所要查詢的 IP 地址，要么告訴本地域名服務器：你下一步應當向哪一個域名服務器進行查詢。然后讓本地域名服務器進行后續的查詢，而不是替本地域名服務器進行后續的查詢。
由此可見，客戶端到 Local DNS 服務器，Local DNS 與上級 DNS 服務器之間屬于遞歸查詢；DNS 服務器與根 DNS 服務器之前屬于迭代查詢。
實際環境中，因為采用遞歸模式會導致 DNS 服務器流量很大，所以現在大多數的 DNS 都是迭代模式。
總結下來，DNS的這些咋整主要的帶來了三類問題：
1）LocalDNS劫持；
2）平均訪問延遲下降；
3）用戶連接失敗率下降。
LocalDNS劫持: 由于HttpDNS是通過ip直接請求http獲取服務器A記錄地址，不存在向本地運營商詢問domain解析過程，所以從根本避免了劫持問題。 （對于http內容tcp/ip層劫持，可以使用驗證因子或者數據加密等方式來保證傳輸數據的可信度）
平均訪問延遲下降: 由于是ip直接訪問省掉了一次domain解析過程，（即使系統有緩存速度也會稍快一些‘毫秒級’）通過智能算法排序后找到最快節點進行訪問。
用戶連接失敗率下降: 通過算法降低以往失敗率過高的服務器排序，通過時間近期訪問過的數據提高服務器排序，通過歷史訪問成功記錄提高服務器排序。如果ip(a)訪問錯誤，在下一次返回ip(b)或者ip(c) 排序后的記錄。
那么，追根溯源，到底為什么會存在這些問題？這就是下一節要討論的問題。
我們得先得了解下現在國內各ISP運營商的LocalDNS的基本情況。
國內運營商LocalDNS造成的這些問題，可以歸為下以下3種原因：
1）域名緩存；2）解析轉發；3）LocalDNS遞歸出口NAT。
1）域名緩存；
2）解析轉發；
3）LocalDNS遞歸出口NAT。
下面，我們來逐一分析。
域名緩存很好理解，就是LocalDNS緩存了騰訊的域名的解析結果，不向騰訊權威DNS發起遞歸。
示意圖如下：
為何LocalDNS要把域名解析結果進行緩存呢？原因有以下幾個：
1）保證用戶訪問流量在本網內消化：國內的各互聯網接入運營商的帶寬資源、網間結算費用、IDC機房分布、網內ICP資源分布等存在較大差異。為了保證網內用戶的訪問質量，同時減少跨網結算，運營商在網內搭建了內容緩存服務器，通過把域名強行指向內容緩存服務器的IP地址，就實現了把本地本網流量完全留在了本地的目的；
2）推送廣告：有部分LocalDNS會把部分域名解析結果的所指向的內容緩存，并替換成第三方廣告聯盟的廣告。
以上類型的行為就是我們常說的域名緩存，域名緩存會導致用戶產生以下的訪問異常：
A、僅對80端口的http服務做了緩存，如果域名是通過https協議或其它端口提供服務的，用戶訪問就會出現失敗。比如支付服務、游戲通過指定端口連接connect server服務等；
B、緩存服務器的運維水平參差不齊，時有出現緩存服務器故障導致用戶訪問異常的問題。
除了域名緩存以外，運營商的LocalDNS還存在解析轉發的現象。解析轉發是指運營商自身不進行域名遞歸解析，而是把域名解析請求轉發到其它運營商的遞歸DNS上的行為。
正常的LocalDNS遞歸解析過程是這樣的：
而部分小運營商為了節省資源，就直接將解析請求轉發到了其它運營的遞歸LocalDNS上去了：
這樣的直接后果就是騰訊權威DNS收到的域名解析請求的來源IP就成了其它運營商的IP，最終導致用戶流量被導向了錯誤的IDC，用戶訪問變慢。
LocalDNS遞歸出口NAT指的是運營商的LocalDNS按照標準的DNS協議進行遞歸，但是因為在網絡上存在多出口且配置了目標路由NAT，結果導致LocalDNS最終進行遞歸解析的時候的出口IP就有概率不為本網的IP地址。
如下圖所示：
這樣的直接后果就是GSLB DNS收到的域名解析請求的來源IP還是成了其它運營商的IP，最終導致用戶流量被導向了錯誤的IDC，用戶訪問變慢。
運營商的LocalDNS解析域名異常，給對用戶訪問騰訊互聯網業務的體驗造成了非常大的損害。
那么以前，我們是如何處理這些域名解析異常的問題的呢？
1）實時監控+商務推動：
這種方案是目前騰訊的運營團隊一直在使用的方案。這種方案就是周期比較長，畢竟通過行政手段來推動運營商來解決這個問題是比較耗時的。另外我們通過大數據分析，得出的結論是Top 3的問題用戶均為移動互聯網用戶。對于這部分用戶，我們有什么技術手段可以解決以上的問題呢？
2）繞過自動分配DNS，使用114dns或Google public DNS：
這個方案看上去很美好，114dns是國內最大的中立緩存DNS，而Google又是秉承不作惡理念的互聯網工程帝國巨鱷，而且騰訊的權威DNS又支持edns-client-subnet功能，能直接識別使用Google publicDNS解析騰訊域名的用戶的IP地址，不會出現流量調度失效。
但是問題來了：
a. 如何在用戶側構造域名請求：對于PC端的客戶端來說，構造一個標準的DNS請求包并不算什么難事。但在移動端要向一個指定的LocalDNS上發送標準的DNS請求包，而且要兼容各種iOS和android的版本的話，技術上是可行的，只是兼容的成本會很高；b. 推動用戶修改配置極高：如果要推動用戶手動修改PC的DNS配置的話，在PC端和手機客戶端的WiFI下面還算勉強可行。但是要用戶修改在移動互聯網環境下的DNS配置，其難度不言而喻。
a. 如何在用戶側構造域名請求：對于PC端的客戶端來說，構造一個標準的DNS請求包并不算什么難事。但在移動端要向一個指定的LocalDNS上發送標準的DNS請求包，而且要兼容各種iOS和android的版本的話，技術上是可行的，只是兼容的成本會很高；
b. 推動用戶修改配置極高：如果要推動用戶手動修改PC的DNS配置的話，在PC端和手機客戶端的WiFI下面還算勉強可行。但是要用戶修改在移動互聯網環境下的DNS配置，其難度不言而喻。
3）完全拋棄域名，自建connectcenter進行流量調度：
如果要采用這種這種方案的話，首先你就得要拿到一份準確的IP地址庫來判斷用戶的歸屬，然后再制定個協議搭個connect center來做調度，然后再對接入層做調度改造。這種方案和2種方案一樣，不是不能做，只是成本會比較高，尤其對于騰訊這種業務規模如此龐大的公司而言。
既然上面的這些傳統方案都存在那么多的問題，那有沒有一種調度精準、成本低廉、配置方便的基于域名的流量調度系統呢？答案是肯定的，我們在下一步繼續分享。
HTTPDNS 利用 HTTP 協議與 DNS 服務器交互，代替了傳統的基于 UDP 協議的 DNS 交互，繞開了運營商的 Local DNS，有效防止了域名劫持，提高域名解析效率。另外，由于 DNS 服務器端獲取的是真實客戶端 IP 而非 Local DNS 的 IP，能夠精確定位客戶端地理位置、運營商信息，從而有效改進調度精確性。
HTTPDNS的原理如下圖所示：
Local DNS 劫持：由于 HttpDns 是通過 IP 直接請求 HTTP 獲取服務器 A 記錄地址，不存在向本地運營商詢問 domain 解析過程，所以從根本避免了劫持問題。
平均訪問延遲下降：由于是 IP 直接訪問省掉了一次 domain 解析過程，通過智能算法排序后找到最快節點進行訪問。
用戶連接失敗率下降：通過算法降低以往失敗率過高的服務器排序，通過時間近期訪問過的數據提高服務器排序，通過歷史訪問成功記錄提高服務器排序。
經過努力，騰訊公司的GSLB 團隊推出的HttpDNS是為移動客戶端量身定做的基于Http協議和域名解析的流量調度解決方案，專治LocalDNS解析異常以及流量調度不準。
詳細介紹如下。
騰訊的HttpDNS基本原理：
HttpDNS的原理非常簡單，主要有兩步：
A、客戶端直接訪問HttpDNS接口，獲取業務在域名配置管理系統上配置的訪問延遲最優的IP。（基于容災考慮，還是保留次選使用運營商LocalDNS解析域名的方式）；
B、客戶端向獲取到的IP后就向直接往此IP發送業務協議請求。以Http請求為例，通過在header中指定host字段，向HttpDNS返回的IP發送標準的Http請求即可。
HttpDNS帶來的優勢：
從原理上來講，HttpDNS只是將域名解析的協議由DNS協議換成了Http協議，并不復雜。
但是這一微小的轉換，卻帶來了無數的收益：
A、根治域名解析異常：由于繞過了運營商的LocalDNS，用戶解析域名的請求通過Http協議直接透傳到了騰訊的HttpDNS服務器IP上，用戶在客戶端的域名解析請求將不會遭受到域名解析異常的困擾；
B、調度精準：HttpDNS能直接獲取到用戶IP，通過結合騰訊自有專利技術生成的IP地址庫以及測速系統，可以保證將用戶引導的訪問最快的IDC節點上；
C、實現成本低廉：接入HttpDNS的業務僅需要對客戶端接入層做少量改造，無需用戶手機進行root或越獄；而且由于Http協議請求構造非常簡單，兼容各版本的移動操作系統更不成問題；另外HttpDNS的后端配置完全復用現有權威DNS配置，管理成本也非常低。總而言之，就是以最小的改造成本，解決了業務遭受域名解析異常的問題，并滿足業務精確流量調度的需求；
D、擴展性強：HttpDNS提供可靠的域名解析服務，業務可將自有調度邏輯與HttpDNS返回結果結合，實現更精細化的流量調度。比如指定版本的客戶端連接請求的IP地址，指定網絡類型的用戶連接指定的IP地址等。
當然各位可能會問：用戶將首選的域名解析方式切換到了HttpDNS，那么HttpDNS的高可用又是如何保證的呢？另外不同運營商的用戶訪問到同一個HttpDNS的服務IP，用戶的訪問延遲如何保證？
為了保證高可用及提升用戶體驗，HttpDNS通過接入了騰訊公網交換平臺的BGP Anycast網絡，與全國多個主流運營商建立了BGP互聯，保證了這些運營商的用戶能夠快速地訪問到HttpDNS服務；另外HttpDNS在多個數據中心進行了部署，任意一個節點發生故障時均能無縫切換到備份節點，保證用戶解析正常。
接入效果及未來展望：
當前騰訊的HttpDNS方案已在騰訊內部接入了多個業務，覆蓋數億用戶，并已持續穩定運行超過一年時間。而接入了HttpDNS的業務在用戶訪問體驗方面都有了非常大的提升。
以某個接入HttpDNS的業務為例，該業務僅通過接入HttpDNS，在未做任何其它優化的情況下，用戶平均訪問延遲下降超過10%，訪問失敗率下降了超過五分之一，用戶訪問體驗的效果提升非常顯著。另外騰訊的HttpDNS服務除了在騰訊內部被廣泛使用以外，也受到了業務同行的肯定。國內最大的publicDNS服務商114dns在受到騰訊DNS的啟發下，也推出了HttpDNS服務。
在未來的日子里，騰訊GSLB團隊將會在騰訊內部進一步推廣HttpDNS服務，并將在實際業務的需求下對HttpDNS服務進行升級，如提供更為通用、安全、簡單的接入協議，進一步提升接入用戶的網絡訪問體驗等等。希望HttpDNS能為各位在解決域名解析異常及全局流量調度失效方面提供一個簡單、可行的思路。
作為創業團隊，人力、財力、技術力量可能都無暇顧及這一塊，但是移動端APP卻實實在在面臨文中提到的各種DNS問題，我們該怎么辦呢？
目前，國內有一部分廠商已經提供了這個解析服務，可以直接使用第三方服務。
目前，提供 HttpDns 解析服務的第3方服務商越來多，比如：阿里云HttpDNS、騰訊云HttpDNS、華為云HttpDNS等。
以阿里云的 HttpDNS為便，它的API 比較標準，直接發一個 Get 請求，帶上請求參數，返回結果以 json 返回：
http://203.107.1.1/d?host=www.52im.net
請求成功時，返回結果如下：
{ "host": "www.linkedkeeper.com", "ips": [ "115.238.23.241", "115.238.23.251" ], "ttl": 57}
{
"host": "www.linkedkeeper.com",
"ips": [
"115.238.23.241",
"115.238.23.251"
],
"ttl": 57
}
在移動端，將由 HttpDns 獲得的 IP 地址在原有 URL 的基礎上，將域名替換為 IP，然后用新的 URL 發起 HTTP 請求。
HTTPDNSLib的Github地址：https://github.com/CNSRE/HTTPDNSLib
HTTPDNSLib中實現的HttpDNS交互流程原理：
從上圖中可以看出來 整個業務的交互流程，用戶向查詢模塊傳入一個URL地址，然后查詢模塊會檢查緩存是否存在，不存在從httpdnsapi接口查詢， 然后經過評估模塊返回。在用戶請求URL過程完畢時，需要將這次請求的結果反饋給 lib庫的評估模塊由評估模塊入庫記錄本次質量數據。
HttpDns Lib庫交互詳細流程：
上圖這張詳細流程圖就更深入的說了下 lib的工作原理。有兩條豎線講圖片分為了三個區域，分別是左部分、中間部分 和 右部分。
左部分是app主線程操作的事情，中間部分是app調用者線程中處理lib庫事件邏輯的事情，右面部分是新線程獨立處理事件的邏輯。
開始是里客戶端調用方，傳入一個 url，獲取domain信息后由查詢模塊查詢domain記錄，查詢模塊會從內存緩存層查詢，內存緩存層沒有數據會，查詢數據庫，如果數據庫也沒有數據會請求本地 LocalDNS。從三個環節中任何一個環節拿到數據后， 都會進入下一個環節，如果沒有拿到數據返回null結束。進入評估模塊，根據五個插件進行排序， 排序后返回數據給客戶端。
lib模塊設定定時器，根據ttl過期時間來檢查domain是否需要更新。 定時器是獨立線程， 不會影響app主線程。 httpdns api請求數據， 先從自己配置的 httpdns api接口獲取數據，如果獲取不到會從 dnspod api接口獲取如果也獲取不到 直接從本地 localDNS獲取數據，（從本地localDNS獲取數據后期會改為發送UDP包封裝dns協議從公共dns服務器直接獲取，比如114dns等。dns服務器地址可自行設定。 ）獲取到數據后進入測速模塊。 測速模塊最新版本可以配置兩種方式，一種是http空請求。 兩個http頭的交互，類似tcp首保耗時時間原理 ，用來測試鏈路最快。 另一種是ping命令，（icmp協議）來盡量最小化流量的消耗，考慮倒可能有的服務器禁ping就使用空http測速即可。 測速后將數據插入本地 cache 即可。
下面是測試Demo的截圖：
有關HttpDns Lib庫的詳細介紹，請見：《App域名劫持之DNS高可用 - 開源版HttpDNS方案詳解》。
《TCP/IP詳解 - 第11章·UDP：用戶數據報協議》《TCP/IP詳解 - 第17章·TCP：傳輸控制協議》《TCP/IP詳解 - 第18章·TCP連接的建立與終止》《TCP/IP詳解 - 第21章·TCP的超時與重傳》《技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點）》《通俗易懂-深入理解TCP協議（上）：理論基礎》《通俗易懂-深入理解TCP協議（下）：RTT、滑動窗口、擁塞處理》《理論經典：TCP協議的3次握手與4次揮手過程詳解》《理論聯系實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》《計算機網絡通訊協議關系圖（中文珍藏版）》《UDP中一個包的大小最大能多大？》《P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介》《P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解》《P2P技術詳解(三)：P2P技術之STUN、TURN、ICE詳解》《通俗易懂：快速理解P2P技術中的NAT穿透原理》《高性能網絡編程(一)：單臺服務器并發TCP連接數到底可以有多少》《高性能網絡編程(二)：上一個10年，著名的C10K并發連接問題》《高性能網絡編程(三)：下一個10年，是時候考慮C10M并發問題了》《高性能網絡編程(四)：從C10K到C10M高性能網絡應用的理論探索》《高性能網絡編程(五)：一文讀懂高性能網絡編程中的I/O模型》《高性能網絡編程(六)：一文讀懂高性能網絡編程中的線程模型》《不為人知的網絡編程(一)：淺析TCP協議中的疑難雜癥(上篇)》《不為人知的網絡編程(二)：淺析TCP協議中的疑難雜癥(下篇)》《不為人知的網絡編程(三)：關閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》《不為人知的網絡編程(四)：深入研究分析TCP的異常關閉》《不為人知的網絡編程(五)：UDP的連接性和負載均衡》《不為人知的網絡編程(六)：深入地理解UDP協議并用好它》《不為人知的網絡編程(七)：如何讓不可靠的UDP變的可靠？》《網絡編程懶人入門(一)：快速理解網絡通信協議（上篇）》《網絡編程懶人入門(二)：快速理解網絡通信協議（下篇）》《網絡編程懶人入門(三)：快速理解TCP協議一篇就夠》《網絡編程懶人入門(四)：快速理解TCP和UDP的差異》《網絡編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優勢》《網絡編程懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》《網絡編程懶人入門(七)：深入淺出，全面理解HTTP協議》《網絡編程懶人入門(八)：手把手教你寫基于TCP的Socket長連接》《網絡編程懶人入門(九)：通俗講解，有了IP地址，為何還要用MAC地址？》《技術掃盲：新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解》《讓互聯網更快：新一代QUIC協議在騰訊的技術實踐分享》《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》《聊聊iOS中網絡編程長連接的那些事》《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》《IPv6技術詳解：基本概念、應用現狀、技術實踐（上篇）》《IPv6技術詳解：基本概念、應用現狀、技術實踐（下篇）》《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》《腦殘式網絡編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》《腦殘式網絡編程入門(二)：我們在讀寫Socket時，究竟在讀寫什么？》《腦殘式網絡編程入門(三)：HTTP協議必知必會的一些知識》《腦殘式網絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)》《腦殘式網絡編程入門(五)：每天都在用的Ping命令，它到底是什么？》《腦殘式網絡編程入門(六)：什么是公網IP和內網IP？NAT轉換又是什么鬼？》《以網游服務端的網絡接入層設計為例，理解實時通信的技術挑戰》《邁向高階：優秀Android程序員必知必會的網絡基礎》《全面了解移動端DNS域名劫持等雜癥：技術原理、問題根源、解決方案等》>> 更多同類文章 ……
《TCP/IP詳解 - 第11章·UDP：用戶數據報協議》
《TCP/IP詳解 - 第17章·TCP：傳輸控制協議》
《TCP/IP詳解 - 第18章·TCP連接的建立與終止》
《TCP/IP詳解 - 第21章·TCP的超時與重傳》
《技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點）》
《通俗易懂-深入理解TCP協議（上）：理論基礎》
《通俗易懂-深入理解TCP協議（下）：RTT、滑動窗口、擁塞處理》
《理論經典：TCP協議的3次握手與4次揮手過程詳解》
《理論聯系實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》
《計算機網絡通訊協議關系圖（中文珍藏版）》
《UDP中一個包的大小最大能多大？》
《P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介》
《P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解》
《P2P技術詳解(三)：P2P技術之STUN、TURN、ICE詳解》
《通俗易懂：快速理解P2P技術中的NAT穿透原理》
《高性能網絡編程(一)：單臺服務器并發TCP連接數到底可以有多少》
《高性能網絡編程(二)：上一個10年，著名的C10K并發連接問題》
《高性能網絡編程(三)：下一個10年，是時候考慮C10M并發問題了》
《高性能網絡編程(四)：從C10K到C10M高性能網絡應用的理論探索》
《高性能網絡編程(五)：一文讀懂高性能網絡編程中的I/O模型》
《高性能網絡編程(六)：一文讀懂高性能網絡編程中的線程模型》
《不為人知的網絡編程(一)：淺析TCP協議中的疑難雜癥(上篇)》
《不為人知的網絡編程(二)：淺析TCP協議中的疑難雜癥(下篇)》
《不為人知的網絡編程(三)：關閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》
《不為人知的網絡編程(四)：深入研究分析TCP的異常關閉》
《不為人知的網絡編程(五)：UDP的連接性和負載均衡》
《不為人知的網絡編程(六)：深入地理解UDP協議并用好它》
《不為人知的網絡編程(七)：如何讓不可靠的UDP變的可靠？》
《網絡編程懶人入門(三)：快速理解TCP協議一篇就夠》
《網絡編程懶人入門(四)：快速理解TCP和UDP的差異》
《網絡編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優勢》
《網絡編程懶人入門(八)：手把手教你寫基于TCP的Socket長連接》
《讓互聯網更快：新一代QUIC協議在騰訊的技術實踐分享》
《聊聊iOS中網絡編程長連接的那些事》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（上篇）》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（下篇）》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》
《腦殘式網絡編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》
《腦殘式網絡編程入門(二)：我們在讀寫Socket時，究竟在讀寫什么？》
《腦殘式網絡編程入門(三)：HTTP協議必知必會的一些知識》
《腦殘式網絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)》
《以網游服務端的網絡接入層設計為例，理解實時通信的技術挑戰》
《邁向高階：優秀Android程序員必知必會的網絡基礎》
《全面了解移動端DNS域名劫持等雜癥：技術原理、問題根源、解決方案等》
>> 更多同類文章 ……
作者：Jack Jiang (點擊作者姓名進入Github) 出處：http://www.52im.net/space-uid-1.html 交流：歡迎加入即時通訊開發交流群 215891622 討論：http://www.52im.net/ Jack Jiang同時是【原創Java Swing外觀工程BeautyEye】和【輕量級移動端即時通訊框架MobileIMSDK】的作者，可前往下載交流。 本博文 歡迎轉載，轉載請注明出處（也可前往 我的52im.net 找到我）。
Powered by: BlogJava Copyright © Jack Jiang