瀏覽器輸入「xxxxhub」的背後.....

點擊藍色“程序員cxuan ”關注我喲

加個“星標”，及時接收最新文章

Hey guys 各位讀者姥爺們大家好，這裏是程序員 cxuan 計算機網絡連載系列的第 13 篇文章。

到現在爲止，我們算是把應用層、運輸層、網絡層和數據鏈路層都介紹完了，那麼現在是時候把這些內容都串起來，做一個全面的回顧了。那麼我這就以 Web 頁面的請求歷程爲例，來和你聊聊計算機網絡中這些協議是怎樣工作的、數據包是怎麼收發的，從輸入 URL 、敲擊回車到最終完成頁面呈現在你面前的這個過程。

首先，我打開了 Web Browser ，然後在 Google 瀏覽器 URL 地址欄中輸入了 maps.google.com。

然後 ……

查找 DNS 緩存

瀏覽器在這個階段會檢查四個地方是否存在緩存，第一個地方是瀏覽器緩存，這個緩存就是 DNS 記錄。

瀏覽器會爲你訪問過的網站在固定期限內維護 DNS 記錄。因此，它是第一個運行 DNS 查詢的地方。瀏覽器首先會檢查這個網址在瀏覽器中是否有一條對應的 DNS 記錄，用來找到目標網址的 IP 地址。

我是 chrome 瀏覽器，所以在 mac 中，無法使用 chrome://net-internals/#dns 找到對應的 IP 地址，在 windows 中是可以找到的。

那麼 mac 怎麼查詢 DNS 記錄呢？你可以使用 nslookup 命令來查找，但這不是我們討論的重點。

DNS(Domain Name System) 是一個分佈式的數據庫，它用於維護網址 URL 到其 IP 地址的映射關係。在互聯網中，IP 地址是計算機所能夠理解的一種地址，而 DNS 的這種別名地址是我們人類能夠理解和記憶的地址，DNS 就負責把人類記憶的地址映射成計算機能夠理解的地址，每個 URL 都有唯一的 IP 地址進行對應。

舉個例子，google 的官網是 www.google.com ，而 google 的 ip 地址是 216.58.200.228 ，這兩個地址你在 URL 上輸入哪個都能訪問，但是 IP 地址不好記憶，而 google.com 簡單明瞭。DNS 就相當於是我們幾年前使用的家庭電話薄，比如你想給 cxuan 打電話，你有可能記不住 cxuan 的電話號碼，此時你需要查詢電話薄來找到 cxuan 的電話號碼。

瀏覽器第二個需要檢查的地方就是操作系統緩存。如果 DNS 記錄不在瀏覽器緩存中，那麼瀏覽器將對操作系統發起系統調用，Windows 下就是 getHostName。

在 Linux 和大部分 UNIX 系統上，除非安裝了 nscd，否則操作系統可能沒有 DNS 緩存。

nscd 是 Linux 系統上的一種名稱服務緩存程序。

瀏覽器第三個需要檢查的地方是路由器緩存，如果 DNS 記錄不在自己電腦上的話，瀏覽器就會和與之相連的路由器共同維護 DNS 記錄。

如果與之相連的路由器也沒有 DNS 記錄的話，瀏覽器就會檢查 ISP 中是否有緩存。ISP 緩存就是你本地通信服務商的緩存，因爲 ISP 維護着自己的 DNS 服務器，它緩存 DNS 記錄的本質也是爲了降低請求時間，達到快速響應的效果。一旦你訪問過某些網站，你的 ISP 可能就會緩存這些頁面，以便下次快速訪問。對於經常看小電影的你是否感到震驚呢？如果家裏還安裝了一個可以聯網的攝像頭的話，那就有點嗨皮了。

你肯定比較困惑爲什麼第一步瀏覽器需要檢查這麼多緩存，你可能會感到不舒服，因爲緩存可能會透露我們的隱私，但是這些緩存在調節網絡流量和縮短數據傳輸時間等方面至關重要。

所以，上面涉及到 DNS 緩存的查詢過程如下。

如果上面四個步驟中都不存在 DNS 記錄，那麼就表示不存在 DNS 緩存，這個時候就需要發起 DNS 查詢，以查找目標網址（本示例中是 maps.google.com）的 IP 地址。

發起 DNS 查詢

如上所述，如果想要使我的計算機和 maps.google.com 建立連接並進行通信的話，我需要知道 maps.google.com 的 IP 地址，由於 DNS 的設計原因，本地 DNS 可能無法給我提供正確的 IP 地址，那麼它就需要在互聯網上搜索多個 DNS 服務器，來找到網站的正確 IP 地址。

這裏有個疑問，爲什麼我需要搜索多個 DNS 服務器的來找到網站的 IP 地址呢？一臺服務器不行嗎？

因爲 DNS 是分佈式域名服務器，每臺服務器只維護一部分 IP 地址到網絡地址的映射，沒有任何一臺服務器能夠維持全部的映射關係。

在 DNS 的早期設計中只有一臺 DNS 服務器。這臺服務器會包含所有的 DNS 映射。這是一種集中式的設計，這種設計並不適用於當今的互聯網，因爲互聯網有着數量巨大並且持續增長的主機，這種集中式的設計會存在以下幾個問題

單點故障(a single point of failure)，如果 DNS 服務器崩潰，那麼整個網絡隨之癱瘓。
通信容量(traaffic volume)，單個 DNS 服務器不得不處理所有的 DNS 查詢，這種查詢級別可能是上百萬上千萬級，一臺服務器很難滿足。
遠距離集中式數據庫(distant centralized database)，單個 DNS 服務器不可能 鄰近 所有的用戶，假設在美國的 DNS 服務器不可能臨近讓澳大利亞的查詢使用，其中查詢請求勢必會經過低速和擁堵的鏈路，造成嚴重的時延。
維護(maintenance)，維護成本巨大，而且還需要頻繁更新。

所以在當今網絡情況下 DNS 不可能集中式設計，因爲它完全沒有可擴展能力，所以採用分佈式設計，這種設計的特點如下

分佈式、層次數據庫。

首先分佈式設計首先解決的問題就是 DNS 服務器的擴展性問題，因此 DNS 使用了大量的 DNS 服務器，它們的組織模式一般是層次方式，並且分佈在全世界範圍內。沒有一臺 DNS 服務器能夠擁有因特網上所有主機的映射。相反，這些映射分佈在所有的 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 服務器，在因特網上具有公共可訪問的主機，如 Web 服務器和郵件服務器，這些主機的組織機構必須提供可供訪問的 DNS 記錄，這些記錄將這些主機的名字映射爲 IP 地址。一個組織機構的權威 DNS 服務器收藏了這些 DNS 記錄。

在瞭解了 DNS 服務器的設計理念之後，我們回到 DNS 查找的步驟上來，DNS 的查詢方式主要分爲三種

DNS 查找中會出現三種類型的查詢。通過組合使用這些查詢，優化的 DNS 解析過程可縮短傳輸距離。在理想情況下，可以使用緩存的記錄數據，從而使 DNS 域名服務器能夠直接使用非遞歸查詢。

遞歸查詢：在遞歸查詢中，DNS 客戶端要求 DNS 服務器（一般爲 DNS 遞歸解析器）將使用所請求的資源記錄響應客戶端，或者如果解析器無法找到該記錄，則返回錯誤消息。

迭代查詢：在迭代查詢中，如果所查詢的 DNS 服務器與查詢名稱不匹配，則其將返回對較低級別域名空間具有權威性的 DNS 服務器的引用。然後，DNS 客戶端將對引用地址進行查詢。此過程繼續使用查詢鏈中的其他 DNS 服務器，直至發生錯誤或超時爲止。

非遞歸查詢：當 DNS 解析器客戶端查詢 DNS 服務器以獲取其有權訪問的記錄時通常會進行此查詢，因爲其對該記錄具有權威性，或者該記錄存在於其緩存內。DNS 服務器通常會緩存 DNS 記錄，查詢到來後能夠直接返回緩存結果，以防止更多帶寬消耗和上游服務器上的負載。

上面負責開始 DNS 查找的介質就是 DNS 解析器，它一般是 ISP 維護的 DNS 服務器，它的主要職責就是通過向網絡中其他 DNS 服務器詢問正確的 IP 地址。

如果想要了解更多關於 DNS 的消息，請查閱萬字長文爆肝 DNS 協議！

所以對於 maps.google.com 這個域名來說，如果 ISP 維護的服務器沒有 DNS 緩存記錄，它就會向 DNS 根服務器地址發起查詢，根名稱服務器會將其重定向到 .com 頂級域名服務器。.com 頂級域名服務器會將其重定向到google.com 權威服務器。google.com 名稱服務器將在其 DNS 記錄中找到 maps.google.com 匹配的 IP 地址，並將其返回給您的 DNS 解析器，然後將其發送回你的瀏覽器。

這裏值得注意的是，DNS 查詢報文會經過許多路由器和設備纔會達到根域名等服務器，每經過一個設備或者路由器都會使用路由表 來確定哪種路徑是數據包達到目的地最快的選擇。這裏面涉及到路由選擇算法，如果小夥伴們想要了解路由選擇算法，可以看看這篇文章 https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html#anc3

ARP 請求

我看了很多篇文章都沒有提到這一點，那就是 ARP 請求的這個過程。

什麼時候需要發送 ARP 請求呢？

這裏其實有個前提條件

如果 DNS 服務器和我們的主機在同一個子網內，系統會按照下面的 ARP 過程對 DNS 服務器進行 ARP 查詢
如果 DNS 服務器和我們的主機在不同的子網，系統會按照下面的 ARP 過程對默認網關進行查詢

ARP 協議的全稱是 Address Resolution Protocol(地址解析協議)，它是一個通過用於實現從 IP 地址到 MAC 地址的映射，即詢問目標 IP 對應的 MAC 地址 的一種協議。

簡而言之，ARP 就是一種解決地址問題的協議，它以 IP 地址爲線索，定位下一個應該接收數據分包的主機 MAC 地址。如果目標主機不在同一個鏈路上，那麼會查找下一跳路由器的 MAC 地址。

關於爲什麼有了 IP 地址，還要有 MAC 地址概述可以參看知乎這個回答 https://www.zhihu.com/question/21546408

ARP 的大致工作流程如下

假設 A 和 B 位於同一鏈路，不需要經過路由器的轉換，主機 A 向主機 B 發送一個 IP 分組，主機 A 的地址是 192.168.1.2 ，主機 B 的地址是 192.168.1.3，它們都不知道對方的 MAC 地址是啥，主機 C 和主機 D 是同一鏈路的其他主機。

主機 A 想要獲取主機 B 的 MAC 地址，通過主機 A 會通過廣播 的方式向以太網上的所有主機發送一個 ARP 請求包，這個 ARP 請求包中包含了主機 A 想要知道的主機 B 的 IP 地址的 MAC 地址。

主機 A 發送的 ARP 請求包會被同一鏈路上的所有主機/路由器接收並進行解析。每個主機/路由器都會檢查 ARP 請求包中的信息，如果 ARP 請求包中的目標 IP 地址 和自己的相同，就會將自己主機的 MAC 地址寫入響應包返回主機 A

由此，可以通過 ARP 從 IP 地址獲取 MAC 地址，實現同一鏈路內的通信。

所以，要想發送 ARP 廣播，我們需要有一個目標 IP 地址，同時還需要知道用於發送 ARP 廣播的接口的 MAC 地址。

這裏會涉及到 ARP 緩存的概念。

現在你知道了發送一次 IP 分組前通過發送一次 ARP 請求就能夠確定 MAC 地址。那麼是不是每發送一次都得經過廣播 -> 封裝 ARP 響應 -> 返回給主機這一系列流程呢？

想想看，瀏覽器是如何做的？瀏覽器內置了緩存能夠緩存你最近經常使用的地址，那麼 ARP 也是一樣的。ARP 高效運行的關鍵就是維護每個主機和路由器上的 ARP 緩存(或表)。這個緩存維護着每個 IP 到 MAC 地址的映射關係。通過把第一次 ARP 獲取到的 MAC 地址作爲 IP 對 MAC 的映射關係到一個 ARP 緩存表中，下一次再向這個地址發送數據報時就不再需要重新發送 ARP 請求了，而是直接使用這個緩存表中的 MAC 地址進行數據報的發送。每發送一次 ARP 請求，緩存表中對應的映射關係都會被清除。

通過 ARP 緩存，降低了網絡流量的使用，在一定程度上防止了 ARP 的大量廣播。

一般來說，發送過一次 ARP 請求後，再次發送相同請求的機率比較大，因此使用 ARP 緩存能夠減少 ARP 包的發送，除此之外，不僅僅 ARP 請求的發送方能夠緩存 ARP 接收方的 MAC 地址，接收方也能夠緩存 ARP 請求方的 IP 和 MAC 地址，如下所示

不過，MAC 地址的緩存有一定期限，超過這個期限後，緩存的內容會被清除。

深入理解 ARP 協議的話，可以參考 cxuan 的這篇文章。

ARP，這個隱匿在計網背後的男人

所以，瀏覽器會首先查詢 ARP 緩存，如果緩存命中，我們返回結果：目標 IP = MAC。

如果緩存沒有命中：

查看路由表，看看目標 IP 地址是不是在本地路由表中的某個子網內。是的話，使用跟那個子網相連的接口，否則使用與默認網關相連的接口。
查詢選擇的網絡接口的 MAC 地址
我們發送一個數據鏈路層的 ARP 請求：

根據連接主機和路由器的硬件類型不同，可以分爲以下幾種情況：

直連：

如果我們和路由器是直接連接的，路由器會返回一個 ARP Reply （見下面）。

集線器：

如果我們連接到一個集線器，集線器會把 ARP 請求向所有其它端口廣播，如果路由器也連接在其中，它會返回一個 ARP Reply 。

交換機：

如果我們連接到了一個交換機，交換機會檢查本地 CAM/MAC 表，看看哪個端口有我們要找的那個 MAC 地址，如果沒有找到，交換機會向所有其它端口廣播這個 ARP 請求。
如果交換機的 MAC/CAM 表中有對應的條目，交換機會向有我們想要查詢的 MAC 地址的那個端口發送 ARP 請求
如果路由器也連接在其中，它會返回一個 ARP Reply

ARP Reply:

現在我們有了 DNS 服務器或者默認網關的 IP 地址，我們可以繼續 DNS 請求了：

使用 53 端口向 DNS 服務器發送 UDP 請求包，如果響應包太大，會使用 TCP 協議
如果本地/ISP DNS 服務器沒有找到結果，它會發送一個遞歸查詢請求，一層一層向高層 DNS 服務器做查詢，直到查詢到起始授權機構，如果找到會把結果返回。

（上述均來自：https://github.com/skyline75489/what-happens-when-zh_CN#dns）

封裝 TCP 數據包

瀏覽器得到目標服務器的 IP 地址後，根據 URL 中的端口可以知道端口號（http 協議默認端口號是 80， https 默認端口號是 443），會準備 TCP 數據包。數據包的封裝會經過下面的層層處理，數據到達目標主機後，目標主機會解析數據包，完整的請求和解析過程如下。

這裏就不再詳細介紹了，讀者朋友們可以閱讀 cxuan 的這篇文章 TCP/IP 基礎知識詳解詳細瞭解。

瀏覽器與目標服務器建立 TCP 連接

在經過上述 DNS 和 ARP 查找流程後，瀏覽器就會收到一個目標服務器的 IP 和 MAC地址，然後瀏覽器將會和目標服務器建立連接來傳輸信息。這裏可以使用很多種 Internet 協議，但是 HTTP 協議建立連接所使用的運輸層協議是 TCP 協議。所以這一步驟是瀏覽器與目標服務器建立 TCP 連接的過程。

TCP 的連接建立需要經過 TCP/IP 的三次握手，三次握手的過程其實就是瀏覽器和服務器交換 SYN 同步和 ACK 確認消息的過程。

假設圖中左端是客戶端主機，右端是服務端主機，一開始，兩端都處於CLOSED（關閉）狀態。

服務端進程準備好接收來自外部的 TCP 連接。然後服務端進程處於 LISTEN 狀態，等待客戶端連接請求。
客戶端向服務器發出連接請求，請求中首部同步位 SYN = 1，同時選擇一個初始序號 sequence ，簡寫 seq = x。SYN 報文段不允許攜帶數據，只消耗一個序號。此時，客戶端進入 SYN-SEND 狀態。
服務器收到客戶端連接後，，需要確認客戶端的報文段。在確認報文段中，把 SYN 和 ACK 位都置爲 1 。確認號是 ack = x + 1，同時也爲自己選擇一個初始序號 seq = y。請注意，這個報文段也不能攜帶數據，但同樣要消耗掉一個序號。此時，TCP 服務器進入 SYN-RECEIVED(同步收到) 狀態。
客戶端在收到服務器發出的響應後，還需要給出確認連接。確認連接中的 ACK 置爲 1 ，序號爲 seq = x + 1，確認號爲 ack = y + 1。TCP 規定，這個報文段可以攜帶數據也可以不攜帶數據，如果不攜帶數據，那麼下一個數據報文段的序號仍是 seq = x + 1。這時，客戶端進入 ESTABLISHED (已連接) 狀態
服務器收到客戶的確認後，也進入 ESTABLISHED 狀態。

這樣三次握手建立連接的階段就完成了，雙方可以直接通信了。

瀏覽器發送 HTTP 請求到 web 服務器

一旦 TCP 連接建立完成後，就開始直接傳輸數據辦正事了！此時瀏覽器會發送 GET 請求，要求目標服務器提供 maps.google.com 的網頁，如果你填寫的是表單，則發起的是 POST 請求，在 HTTP 中，GET 請求和 POST 請求是最常見的兩種請求，基本上佔據了所有 HTTP 請求的九成以上。

除了請求類型外，HTTP 請求還包含很多很多信息，最常見的有 Host、Connection 、User-agent、Accept-language 等

首先 Host 表示的是對象所在的主機。Connection: close 表示的是瀏覽器需要告訴服務器使用的是非持久連接。它要求服務器在發送完響應的對象後就關閉連接。User-agent: 這是請求頭用來告訴 Web 服務器，瀏覽器使用的類型是 Mozilla/5.0，即 Firefox 瀏覽器。Accept-language 告訴 Web 服務器，瀏覽器想要得到對象的法語版本，前提是服務器需要支持法語類型，否則將會發送服務器的默認版本。下面我們針對主要的實體字段進行介紹（具體的可以參考 https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers MDN 官網學習）

HTTP 的請求標頭分爲四種： 通用標頭、請求標頭、響應標頭 和 實體標頭。

這四種標頭又分別有很多內容，如果你想要深入理解一下關於 HTTP 請求頭的相關內容，可以參考 cxuan 的這篇文章

深入理解 HTTP 標頭

服務器處理請求併發回一個響應

這個服務器包含一個 Web 服務器，也就是 Apache 服務器，服務器會從瀏覽器接收請求並將其傳遞給請求處理程序並生成響應。

請求處理程序也是一個程序，它一般是用 .net 、php、ruby 等語言編寫，用於讀取請求，檢查請求內容，cookie，必要時更新服務器上的信息的這麼一個程序。它會以特定的格式比如 JSON、XML、HTML 組合響應。

服務器發送回一個 HTTP 響應

服務器響應包含你請求的網頁以及狀態代碼，壓縮類型（Content-Encoding），如何緩存頁面（Cache-Control），要設置的 cookie，隱私信息等。

比如下面就是一個響應體

關於深入理解 HTTP 請求和響應，可以參考這篇文章

看完這篇HTTP，跟面試官扯皮就沒問題了

瀏覽器顯示 HTML 的相關內容

瀏覽器會分階段顯示 HTML 內容。首先，它將渲染裸露的 HTML 骨架。然後它將檢查 HTML 標記併發送 GET 請求以獲取網頁上的其他元素，例如圖像，CSS 樣式表，JavaScript 文件等。這些靜態文件由瀏覽器緩存，因此你再次訪問該頁面時，不用重新再請求一次。最後，您會看到 maps.google.com 顯示的內容出現在你的瀏覽器中。