瀏覽器輸入「xxxxhub」的背后.....
作者/cxuan
源自/程序員cxuan
那么我這就以 Web 頁面的請求歷程為例，來和你聊聊計算機網(wǎng)絡中這些協(xié)議是怎樣工作的、數(shù)據(jù)包是怎么收發(fā)的，從輸入 URL 、敲擊回車到最終完成頁面呈現(xiàn)在你面前的這個過程。
首先，我打開了 Web Browser ，然后在 Google 瀏覽器 URL 地址欄中輸入了 maps.google.com。
然后 ……
查找 DNS 緩存
瀏覽器在這個階段會檢查四個地方是否存在緩存，第一個地方是瀏覽器緩存，這個緩存就是 DNS 記錄。
瀏覽器會為你訪問過的網(wǎng)站在固定期限內(nèi)維護 DNS 記錄。因此，它是第一個運行 DNS 查詢的地方。瀏覽器首先會檢查這個網(wǎng)址在瀏覽器中是否有一條對應的 DNS 記錄，用來找到目標網(wǎng)址的 IP 地址。
我是 chrome 瀏覽器，所以在 mac 中，無法使用 chrome://net-internals/#dns 找到對應的 IP 地址，在 windows 中是可以找到的。
那么 mac 怎么查詢 DNS 記錄呢？你可以使用
nslookup命令來查找，但這不是我們討論的重點。
DNS(Domain Name System) 是一個分布式的數(shù)據(jù)庫，它用于維護網(wǎng)址 URL 到其 IP 地址的映射關系。在互聯(lián)網(wǎng)中，IP 地址是計算機所能夠理解的一種地址，而 DNS 的這種別名地址是我們?nèi)祟惸軌蚶斫夂陀洃浀牡刂罚珼NS 就負責把人類記憶的地址映射成計算機能夠理解的地址，每個 URL 都有唯一的 IP 地址進行對應。
舉個例子，google 的官網(wǎng)是 www.google.com ，而 google 的 ip 地址是 216.58.200.228 ，這兩個地址你在 URL 上輸入哪個都能訪問，但是 IP 地址不好記憶，而 google.com 簡單明了。DNS 就相當于是我們幾年前使用的家庭電話薄，比如你想給 cxuan 打電話，你有可能記不住 cxuan 的電話號碼，此時你需要查詢電話薄來找到 cxuan 的電話號碼。
瀏覽器第二個需要檢查的地方就是操作系統(tǒng)緩存。如果 DNS 記錄不在瀏覽器緩存中，那么瀏覽器將對操作系統(tǒng)發(fā)起系統(tǒng)調(diào)用，Windows 下就是 getHostName。
在 Linux 和大部分 UNIX 系統(tǒng)上，除非安裝了
nscd，否則操作系統(tǒng)可能沒有 DNS 緩存。nscd 是 Linux 系統(tǒng)上的一種名稱服務緩存程序。
瀏覽器第三個需要檢查的地方是路由器緩存，如果 DNS 記錄不在自己電腦上的話，瀏覽器就會和與之相連的路由器共同維護 DNS 記錄。
如果與之相連的路由器也沒有 DNS 記錄的話，瀏覽器就會檢查 ISP 中是否有緩存。ISP 緩存就是你本地通信服務商的緩存，因為 ISP 維護著自己的 DNS 服務器，它緩存 DNS 記錄的本質也是為了降低請求時間，達到快速響應的效果。一旦你訪問過某些網(wǎng)站，你的 ISP 可能就會緩存這些頁面，以便下次快速訪問。對于經(jīng)常看小電影的你是否感到震驚呢？如果家里還安裝了一個可以聯(lián)網(wǎng)的攝像頭的話，那就有點嗨皮了。
你肯定比較困惑為什么第一步瀏覽器需要檢查這么多緩存，你可能會感到不舒服，因為緩存可能會透露我們的隱私，但是這些緩存在調(diào)節(jié)網(wǎng)絡流量和縮短數(shù)據(jù)傳輸時間等方面至關重要。
所以，上面涉及到 DNS 緩存的查詢過程如下。
如果上面四個步驟中都不存在 DNS 記錄，那么就表示不存在 DNS 緩存，這個時候就需要發(fā)起 DNS 查詢，以查找目標網(wǎng)址（本示例中是 maps.google.com）的 IP 地址。
發(fā)起 DNS 查詢
如上所述，如果想要使我的計算機和 maps.google.com 建立連接并進行通信的話，我需要知道 maps.google.com 的 IP 地址，由于 DNS 的設計原因，本地 DNS 可能無法給我提供正確的 IP 地址，那么它就需要在互聯(lián)網(wǎng)上搜索多個 DNS 服務器，來找到網(wǎng)站的正確 IP 地址。
這里有個疑問，為什么我需要搜索多個 DNS 服務器的來找到網(wǎng)站的 IP 地址呢？一臺服務器不行嗎？
因為 DNS 是分布式域名服務器，每臺服務器只維護一部分 IP 地址到網(wǎng)絡地址的映射，沒有任何一臺服務器能夠維持全部的映射關系。
在 DNS 的早期設計中只有一臺 DNS 服務器。這臺服務器會包含所有的 DNS 映射。這是一種集中式的設計，這種設計并不適用于當今的互聯(lián)網(wǎng)，因為互聯(lián)網(wǎng)有著數(shù)量巨大并且持續(xù)增長的主機，這種集中式的設計會存在以下幾個問題
單點故障(a single point of failure)，如果 DNS 服務器崩潰，那么整個網(wǎng)絡隨之癱瘓。通信容量(traaffic volume)，單個 DNS 服務器不得不處理所有的 DNS 查詢，這種查詢級別可能是上百萬上千萬級，一臺服務器很難滿足。遠距離集中式數(shù)據(jù)庫(distant centralized database)，單個 DNS 服務器不可能鄰近所有的用戶，假設在美國的 DNS 服務器不可能臨近讓澳大利亞的查詢使用，其中查詢請求勢必會經(jīng)過低速和擁堵的鏈路，造成嚴重的時延。維護(maintenance)，維護成本巨大，而且還需要頻繁更新。
所以在當今網(wǎng)絡情況下 DNS 不可能集中式設計，因為它完全沒有可擴展能力，所以采用分布式設計，這種設計的特點如下
分布式、層次數(shù)據(jù)庫。
首先分布式設計首先解決的問題就是 DNS 服務器的擴展性問題，因此 DNS 使用了大量的 DNS 服務器，它們的組織模式一般是層次方式，并且分布在全世界范圍內(nèi)。沒有一臺 DNS 服務器能夠擁有因特網(wǎng)上所有主機的映射。相反，這些映射分布在所有的 DNS 服務器上。
大致來說有三種 DNS 服務器：根 DNS 服務器、 頂級域(Top-Level Domain, TLD) DNS 服務器 和 權威 DNS 服務器 。這些服務器的層次模型如下圖所示
根 DNS 服務器，有 400 多個根域名服務器遍及全世界，這些根域名服務器由 13 個不同的組織管理。根域名服務器的清單和組織機構可以在 https://root-servers.org/ 中找到，根域名服務器提供 TLD 服務器的 IP 地址。頂級域 DNS 服務器，對于每個頂級域名比如 com、org、net、edu 和 gov 和所有的國家級域名 uk、fr、ca 和 jp 都有 TLD 服務器或服務器集群。所有的頂級域列表參見 https://tld-list.com/ 。TDL 服務器提供了權威 DNS 服務器的 IP 地址。權威 DNS 服務器，在因特網(wǎng)上具有公共可訪問的主機，如 Web 服務器和郵件服務器，這些主機的組織機構必須提供可供訪問的 DNS 記錄，這些記錄將這些主機的名字映射為 IP 地址。一個組織機構的權威 DNS 服務器收藏了這些 DNS 記錄。
在了解了 DNS 服務器的設計理念之后，我們回到 DNS 查找的步驟上來，DNS 的查詢方式主要分為三種
DNS 查找中會出現(xiàn)三種類型的查詢。通過組合使用這些查詢，優(yōu)化的 DNS 解析過程可縮短傳輸距離。在理想情況下，可以使用緩存的記錄數(shù)據(jù)，從而使 DNS 域名服務器能夠直接使用非遞歸查詢。
遞歸查詢：在遞歸查詢中，DNS 客戶端要求 DNS 服務器（一般為 DNS 遞歸解析器）將使用所請求的資源記錄響應客戶端，或者如果解析器無法找到該記錄，則返回錯誤消息。
迭代查詢：在迭代查詢中，如果所查詢的 DNS 服務器與查詢名稱不匹配，則其將返回對較低級別域名空間具有權威性的 DNS 服務器的引用。然后，DNS 客戶端將對引用地址進行查詢。此過程繼續(xù)使用查詢鏈中的其他 DNS 服務器，直至發(fā)生錯誤或超時為止。
非遞歸查詢：當 DNS 解析器客戶端查詢 DNS 服務器以獲取其有權訪問的記錄時通常會進行此查詢，因為其對該記錄具有權威性，或者該記錄存在于其緩存內(nèi)。DNS 服務器通常會緩存 DNS 記錄，查詢到來后能夠直接返回緩存結果，以防止更多帶寬消耗和上游服務器上的負載。
上面負責開始 DNS 查找的介質就是 DNS 解析器，它一般是 ISP 維護的 DNS 服務器，它的主要職責就是通過向網(wǎng)絡中其他 DNS 服務器詢問正確的 IP 地址。
如果想要了解更多關于 DNS 的消息，請查閱 萬字長文爆肝 DNS 協(xié)議！
所以對于 maps.google.com 這個域名來說，如果 ISP 維護的服務器沒有 DNS 緩存記錄，它就會向 DNS 根服務器地址發(fā)起查詢，根名稱服務器會將其重定向到 .com 頂級域名服務器。.com 頂級域名服務器會將其重定向到google.com 權威服務器。google.com 名稱服務器將在其 DNS 記錄中找到 maps.google.com 匹配的 IP 地址，并將其返回給您的 DNS 解析器，然后將其發(fā)送回你的瀏覽器。
這里值得注意的是，DNS 查詢報文會經(jīng)過許多路由器和設備才會達到根域名等服務器，每經(jīng)過一個設備或者路由器都會使用路由表 來確定哪種路徑是數(shù)據(jù)包達到目的地最快的選擇。這里面涉及到路由選擇算法，如果小伙伴們想要了解路由選擇算法，可以看看這篇文章 https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html#anc3
ARP 請求
我看了很多篇文章都沒有提到這一點，那就是 ARP 請求的這個過程。
什么時候需要發(fā)送 ARP 請求呢？
這里其實有個前提條件
如果 DNS 服務器和我們的主機在同一個子網(wǎng)內(nèi)，系統(tǒng)會按照下面的 ARP 過程對 DNS 服務器進行 ARP 查詢
如果 DNS 服務器和我們的主機在不同的子網(wǎng)，系統(tǒng)會按照下面的 ARP 過程對默認網(wǎng)關進行查詢
ARP 協(xié)議的全稱是 Address Resolution Protocol(地址解析協(xié)議)，它是一個通過用于實現(xiàn)從 IP 地址到 MAC 地址的映射，即詢問目標 IP 對應的 MAC 地址 的一種協(xié)議。
簡而言之，ARP 就是一種解決地址問題的協(xié)議，它以 IP 地址為線索，定位下一個應該接收數(shù)據(jù)分包的主機 MAC 地址。如果目標主機不在同一個鏈路上，那么會查找下一跳路由器的 MAC 地址。
關于為什么有了 IP 地址，還要有 MAC 地址概述可以參看知乎這個回答 https://www.zhihu.com/question/21546408
ARP 的大致工作流程如下
假設 A 和 B 位于同一鏈路，不需要經(jīng)過路由器的轉換，主機 A 向主機 B 發(fā)送一個 IP 分組，主機 A 的地址是 192.168.1.2 ，主機 B 的地址是 192.168.1.3，它們都不知道對方的 MAC 地址是啥，主機 C 和 主機 D 是同一鏈路的其他主機。
主機 A 想要獲取主機 B 的 MAC 地址，通過主機 A 會通過廣播 的方式向以太網(wǎng)上的所有主機發(fā)送一個 ARP 請求包，這個 ARP 請求包中包含了主機 A 想要知道的主機 B 的 IP 地址的 MAC 地址。
主機 A 發(fā)送的 ARP 請求包會被同一鏈路上的所有主機/路由器接收并進行解析。每個主機/路由器都會檢查 ARP 請求包中的信息，如果 ARP 請求包中的目標 IP 地址 和自己的相同，就會將自己主機的 MAC 地址寫入響應包返回主機 A
由此，可以通過 ARP 從 IP 地址獲取 MAC 地址，實現(xiàn)同一鏈路內(nèi)的通信。
所以，要想發(fā)送 ARP 廣播，我們需要有一個目標 IP 地址，同時還需要知道用于發(fā)送 ARP 廣播的接口的 MAC 地址。
這里會涉及到 ARP 緩存的概念。
現(xiàn)在你知道了發(fā)送一次 IP 分組前通過發(fā)送一次 ARP 請求就能夠確定 MAC 地址。那么是不是每發(fā)送一次都得經(jīng)過廣播 -> 封裝 ARP 響應 -> 返回給主機這一系列流程呢？
想想看，瀏覽器是如何做的？瀏覽器內(nèi)置了緩存能夠緩存你最近經(jīng)常使用的地址，那么 ARP 也是一樣的。ARP 高效運行的關鍵就是維護每個主機和路由器上的 ARP 緩存(或表)。這個緩存維護著每個 IP 到 MAC 地址的映射關系。通過把第一次 ARP 獲取到的 MAC 地址作為 IP 對 MAC 的映射關系到一個 ARP 緩存表中，下一次再向這個地址發(fā)送數(shù)據(jù)報時就不再需要重新發(fā)送 ARP 請求了，而是直接使用這個緩存表中的 MAC 地址進行數(shù)據(jù)報的發(fā)送。每發(fā)送一次 ARP 請求，緩存表中對應的映射關系都會被清除。
通過 ARP 緩存，降低了網(wǎng)絡流量的使用，在一定程度上防止了 ARP 的大量廣播。
一般來說，發(fā)送過一次 ARP 請求后，再次發(fā)送相同請求的幾率比較大，因此使用 ARP 緩存能夠減少 ARP 包的發(fā)送，除此之外，不僅僅 ARP 請求的發(fā)送方能夠緩存 ARP 接收方的 MAC 地址，接收方也能夠緩存 ARP 請求方的 IP 和 MAC 地址，如下所示
不過，MAC 地址的緩存有一定期限，超過這個期限后，緩存的內(nèi)容會被清除。
深入理解 ARP 協(xié)議的話，可以參考 cxuan 的這篇文章。
所以，瀏覽器會首先查詢 ARP 緩存，如果緩存命中，我們返回結果：目標 IP = MAC。
如果緩存沒有命中：
查看路由表，看看目標 IP 地址是不是在本地路由表中的某個子網(wǎng)內(nèi)。是的話，使用跟那個子網(wǎng)相連的接口，否則使用與默認網(wǎng)關相連的接口。
查詢選擇的網(wǎng)絡接口的 MAC 地址
我們發(fā)送一個數(shù)據(jù)鏈路層的 ARP 請求：
根據(jù)連接主機和路由器的硬件類型不同，可以分為以下幾種情況：
直連：
如果我們和路由器是直接連接的，路由器會返回一個
ARP Reply（見下面）。
集線器：
如果我們連接到一個集線器，集線器會把 ARP 請求向所有其它端口廣播，如果路由器也連接在其中，它會返回一個
ARP Reply。
交換機：
如果我們連接到了一個交換機，交換機會檢查本地 CAM/MAC 表，看看哪個端口有我們要找的那個 MAC 地址，如果沒有找到，交換機會向所有其它端口廣播這個 ARP 請求。
如果交換機的 MAC/CAM 表中有對應的條目，交換機會向有我們想要查詢的 MAC 地址的那個端口發(fā)送 ARP 請求
如果路由器也
連接在其中，它會返回一個ARP Reply
ARP Reply:
現(xiàn)在我們有了 DNS 服務器或者默認網(wǎng)關的 IP 地址，我們可以繼續(xù) DNS 請求了：
使用 53 端口向 DNS 服務器發(fā)送 UDP 請求包，如果響應包太大，會使用 TCP 協(xié)議
如果本地/ISP DNS 服務器沒有找到結果，它會發(fā)送一個遞歸查詢請求，一層一層向高層 DNS 服務器做查詢，直到查詢到起始授權機構，如果找到會把結果返回。
（上述均來自：https://github.com/skyline75489/what-happens-when-zh_CN#dns）
封裝 TCP 數(shù)據(jù)包
瀏覽器得到目標服務器的 IP 地址后，根據(jù) URL 中的端口可以知道端口號 （http 協(xié)議默認端口號是 80， https 默認端口號是 443），會準備 TCP 數(shù)據(jù)包。數(shù)據(jù)包的封裝會經(jīng)過下面的層層處理，數(shù)據(jù)到達目標主機后，目標主機會解析數(shù)據(jù)包，完整的請求和解析過程如下。
這里就不再詳細介紹了，讀者朋友們可以閱讀 cxuan 的這篇文章 TCP/IP 基礎知識詳解詳細了解。
瀏覽器與目標服務器建立 TCP 連接
在經(jīng)過上述 DNS 和 ARP 查找流程后，瀏覽器就會收到一個目標服務器的 IP 和 MAC地址，然后瀏覽器將會和目標服務器建立連接來傳輸信息。這里可以使用很多種 Internet 協(xié)議，但是 HTTP 協(xié)議建立連接所使用的運輸層協(xié)議是 TCP 協(xié)議。所以這一步驟是瀏覽器與目標服務器建立 TCP 連接的過程。
TCP 的連接建立需要經(jīng)過 TCP/IP 的三次握手，三次握手的過程其實就是瀏覽器和服務器交換 SYN 同步和 ACK 確認消息的過程。
假設圖中左端是客戶端主機，右端是服務端主機，一開始，兩端都處于CLOSED（關閉）狀態(tài)。
服務端進程準備好接收來自外部的 TCP 連接。然后服務端進程處于
LISTEN狀態(tài)，等待客戶端連接請求。客戶端向服務器發(fā)出連接請求，請求中首部同步位 SYN = 1，同時選擇一個初始序號 sequence ，簡寫 seq = x。SYN 報文段不允許攜帶數(shù)據(jù)，只消耗一個序號。此時，客戶端進入
SYN-SEND狀態(tài)。服務器收到客戶端連接后，，需要確認客戶端的報文段。在確認報文段中，把 SYN 和 ACK 位都置為 1 。確認號是 ack = x + 1，同時也為自己選擇一個初始序號 seq = y。請注意，這個報文段也不能攜帶數(shù)據(jù)，但同樣要消耗掉一個序號。此時，TCP 服務器進入
SYN-RECEIVED(同步收到)狀態(tài)。客戶端在收到服務器發(fā)出的響應后，還需要給出確認連接。確認連接中的 ACK 置為 1 ，序號為 seq = x + 1，確認號為 ack = y + 1。TCP 規(guī)定，這個報文段可以攜帶數(shù)據(jù)也可以不攜帶數(shù)據(jù)，如果不攜帶數(shù)據(jù)，那么下一個數(shù)據(jù)報文段的序號仍是 seq = x + 1。這時，客戶端進入
ESTABLISHED (已連接)狀態(tài)服務器收到客戶的確認后，也進入
ESTABLISHED狀態(tài)。
這樣三次握手建立連接的階段就完成了，雙方可以直接通信了。
瀏覽器發(fā)送 HTTP 請求到 web 服務器
一旦 TCP 連接建立完成后，就開始直接傳輸數(shù)據(jù)辦正事了！此時瀏覽器會發(fā)送 GET 請求，要求目標服務器提供 maps.google.com 的網(wǎng)頁，如果你填寫的是表單，則發(fā)起的是 POST 請求，在 HTTP 中，GET 請求和 POST 請求是最常見的兩種請求，基本上占據(jù)了所有 HTTP 請求的九成以上。
除了請求類型外，HTTP 請求還包含很多很多信息，最常見的有 Host、Connection 、User-agent、Accept-language 等
首先 Host 表示的是對象所在的主機。Connection: close 表示的是瀏覽器需要告訴服務器使用的是非持久連接。它要求服務器在發(fā)送完響應的對象后就關閉連接。User-agent: 這是請求頭用來告訴 Web 服務器，瀏覽器使用的類型是 Mozilla/5.0，即 Firefox 瀏覽器。Accept-language 告訴 Web 服務器，瀏覽器想要得到對象的法語版本，前提是服務器需要支持法語類型，否則將會發(fā)送服務器的默認版本。下面我們針對主要的實體字段進行介紹（具體的可以參考 https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers MDN 官網(wǎng)學習）
HTTP 的請求標頭分為四種： 通用標頭、請求標頭、響應標頭 和 實體標頭。
這四種標頭又分別有很多內(nèi)容，如果你想要深入理解一下關于 HTTP 請求頭的相關內(nèi)容，可以參考 cxuan 的這篇文章
服務器處理請求并發(fā)回一個響應
這個服務器包含一個 Web 服務器，也就是 Apache 服務器，服務器會從瀏覽器接收請求并將其傳遞給請求處理程序并生成響應。
請求處理程序也是一個程序，它一般是用 .net 、php、ruby 等語言編寫，用于讀取請求，檢查請求內(nèi)容，cookie，必要時更新服務器上的信息的這么一個程序。它會以特定的格式比如 JSON、XML、HTML 組合響應。
服務器發(fā)送回一個 HTTP 響應
服務器響應包含你請求的網(wǎng)頁以及狀態(tài)代碼，壓縮類型（Content-Encoding），如何緩存頁面（Cache-Control），要設置的 cookie，隱私信息等。
比如下面就是一個響應體
關于深入理解 HTTP 請求和響應，可以參考這篇文章
瀏覽器顯示 HTML 的相關內(nèi)容
瀏覽器會分階段顯示 HTML 內(nèi)容。首先，它將渲染裸露的 HTML 骨架。然后它將檢查 HTML 標記并發(fā)送 GET 請求以獲取網(wǎng)頁上的其他元素，例如圖像，CSS 樣式表，JavaScript 文件等。這些靜態(tài)文件由瀏覽器緩存，因此你再次訪問該頁面時，不用重新再請求一次。最后，您會看到 maps.google.com 顯示的內(nèi)容出現(xiàn)在你的瀏覽器中。