【面試】Web 頁面請求歷程

這個問題應該是網絡知識最綜合的一個考察，由於涉及到的知識實在太多了，若是面試官對每個細節都問的話，應該能夠把網絡知識問的差很少

我查閱資料總結大概有兩種表述

簡單過程

說簡單也不是簡單，就是從表面看是主要發生了哪幾步

• DNS 解析
• TCP 鏈接
• 發送 HTTP 請求
• 服務器處理請求並返回 HTTP 報文
• 瀏覽器解析渲染頁面
• 鏈接結束

具體過程以下：

DNS 解析

通俗來將，就是尋找哪臺服務器上有你想要請求的資源。好比當你在瀏覽器中輸入 www.google.com 時，這其實不是真正意義上谷歌的地址。互聯網上每一臺機器的惟一標識是它的IP 地址，可是 IP 地址不方便記憶，因此用戶更喜歡使用上面提到的網址來和互聯網中其餘計算機進行信息交互，那麼將網址轉化爲實際 IP 地址的過程就是 DNS 解析。實際上充當一個翻譯的角色，實現網址到 IP 地址的轉換

解析過程

DNS 解析是一個遞歸查詢的過程，經過下圖來直觀理解：

這就是一個查找 www.google.com 的 IP 地址的過程。首先在本地域名中查找 IP 地址，若是沒有找到，本地域名會向根域名發送一個請求，若是根域名服務器也不存在該域名時，本地域名會向 com 頂級域名服務器發送一個請求，依次類推下去。直到最後本地域名服務器獲得 google 的 IP 地址並把它緩存到本地，供下次使用。從上述過程當中能夠看出網址解析的過程是一個從左到右的過程：com-google.com-www.google.com，可是這樣的話根域名服務器的解析呢？實際上真正的網址是 www.google.com.，這裏並非多打了個 . 而是這表明根域名服務器，實際上全部的網址後面都會有這個，由於都有，因此就默認爲了方便將這個省去，可是瀏覽器在請求 DNS 時候會自動加上

DNS 優化

圖中在 DNS 的請求過程當中大概經歷了 8 個步驟，這個過程當中存在多個請求，若是每次請求都是經歷這麼多步驟，是否太耗時間，計算機經過 DNS 緩存來減小該過程的步驟

DNS 存在多級緩存，從離瀏覽器的距離來講，有如下幾種：瀏覽器緩存、系統緩存、路由器緩存、IPS 服務器緩存、根域名緩存、頂級域名服務器緩存、主域名服務器緩存

DNS 負載均衡

實際上 DNS 每次返回的 IP 地址不是固定的，DNS 會返回一個合適機器的 IP 給用戶，例如能夠根據每臺機器的負載量、該機器離用戶地理位置的距離等等，這就涉及到 DNS 的負載均衡，又叫 DNS 重定向。

TCP 鏈接

這個過程也是面試常考的過程，具體能夠查看我上一篇文章【面試】完全理解 TCP 及面試常問

瀏覽器發送 HTTP 請求

一個http請求報文由請求行 request-line 、請求頭部 headers、空行 blank-line 和請求數據 request-body 4個部分組成

後面的過程就是涉及到前端的知識，這裏不詳細討論，主要關注點仍是下面的後臺涉及到的協議細節。

詳細過程

1. DHCP 配置主機信息

• 假設主機最開始沒有 IP 地址以及其餘信息，那麼就須要先使用 DHCP 來獲取
• 主機生成一個 DHCP 請求報文，並將這個報文放入具備目的端口 67 和源端口 68 的 UDP 報文段中
• 該報文段則被放入一個具備廣播 IP 目的地址(255.255.255.255) 和源 IP 地址（0.0.0.0）的 IP 數據報中，由於這個時候主機還不具備一個 IP 地址
• 該請求報文的 IP 數據報會被放置在以太網幀中，該以太網幀具備目的 MAC 地址 FF:FF:FF:FF:FF:FF，該幀將廣播到與交換機鏈接的全部設備
• 鏈接在交換機的 DHCP 服務器收到廣播幀以後，不斷地向上分解獲得 IP 數據報、UDP 報文段、DHCP 請求報文，以後生成 DHCP ACK 報文，該報文包含如下信息：IP 地址、DNS 服務器的 IP 地址、默認網關路由器的 IP 地址和子網掩碼。該報文被放入 UDP 報文段中，UDP 報文段有被放入 IP 數據報中，最後放入 MAC 幀中
• 該幀的目的地址是請求主機的 MAC 地址，由於交換機具備自學習能力，以前主機發送了廣播幀以後就記錄了 MAC 地址到其轉發接口的交換表項，所以如今交換機就能夠直接知道應該向哪一個接口發送該幀
• 主機收到該幀後，不斷分解獲得 DHCP 報文。以後就配置它的 IP 地址、子網掩碼和 DNS 服務器的 IP 地址，並在其 IP 轉發表中安裝默認網關

2. ARP 解析 MAC 地址

• 主機經過瀏覽器生成一個 TCP 套接字，套接字向 HTTP 服務器發送 HTTP 請求。爲了生成該套接字，主機須要知道網站的域名對應的 IP 地址。
• 主機生成一個 DNS 查詢報文，該報文具備 53 號端口，由於 DNS 服務器的端口號是 53。
• 該 DNS 查詢報文被放入目的地址爲 DNS 服務器 IP 地址的 IP 數據報中。
• 該 IP 數據報被放入一個以太網幀中，該幀將發送到網關路由器。
• DHCP 過程只知道網關路由器的 IP 地址，爲了獲取網關路由器的 MAC 地址，須要使用 ARP 協議。
• 主機生成一個包含目的地址爲網關路由器 IP 地址的 ARP 查詢報文，將該 ARP 查詢報文放入一個具備廣播目的地址（FF:FF:FF:FF:FF:FF）的以太網幀中，並向交換機發送該以太網幀，交換機將該幀轉發給全部的鏈接設備，包括網關路由器。
• 網關路由器接收到該幀後，不斷向上分解獲得 ARP 報文，發現其中的 IP 地址與其接口的 IP 地址匹配，所以就發送一個 ARP 回答報文，包含了它的 MAC 地址，發回給主機

3. DNS 解析域名

• 知道了網關路由器的 MAC 地址以後，就能夠繼續 DNS 的解析過程了。
• 網關路由器接收到包含 DNS 查詢報文的以太網幀後，抽取出 IP 數據報，並根據轉發表決定該 IP 數據報應該轉發的路由器。
• 由於路由器具備內部網關協議（RIP、OSPF）和外部網關協議（BGP）這兩種路由選擇協議，所以路由表中已經配置了網關路由器到達 DNS 服務器的路由表項。
• 到達 DNS 服務器以後，DNS 服務器抽取出 DNS 查詢報文，並在 DNS 數據庫中查找待解析的域名。
• 找到 DNS 記錄以後，發送 DNS 回答報文，將該回答報文放入 UDP 報文段中，而後放入 IP 數據報中，經過路由器反向轉發回網關路由器，並通過以太網交換機到達主機。

4. HTTP 請求頁面

• 有了 HTTP 服務器的 IP 地址以後，主機就可以生成 TCP 套接字，該套接字將用於向 Web 服務器發送 HTTP GET 報文。
• 在生成 TCP 套接字以前，必須先與 HTTP 服務器進行三次握手來創建鏈接。生成一個具備目的端口 80 的 TCP SYN 報文段，並向 HTTP 服務器發送該報文段。
• HTTP 服務器收到該報文段以後，生成 TCP SYN ACK 報文段，發回給主機。
• 鏈接創建以後，瀏覽器生成 HTTP GET 報文，並交付給 HTTP 服務器。
• HTTP 服務器從 TCP 套接字讀取 HTTP GET 報文，生成一個 HTTP 響應報文，將 Web 頁面內容放入報文主體中，發回給主機。
• 瀏覽器收到 HTTP 響應報文後，抽取出 Web 頁面內容，以後進行渲染，顯示 Web 頁面。

參考

前端經典面試題：從輸入 URL 到頁面加載發生了什麼？

web-頁面請求過程

計算機網絡-自頂向下方法