一個頁面從輸入 URL 到頁面載入完的過程中都發生了什麼事情？

過程概述

1. 瀏覽器查找功能變數名稱對應的 IP 地址；

2. 瀏覽器根據 IP 地址與伺服器建立 socket 連接；

3. 瀏覽器與伺服器通信： 瀏覽器請求，伺服器處理請求；

4. 瀏覽器與伺服器斷開連接。

以下為詳細解析:

根據功能變數名稱查找 IP 地址

概念解釋

• IP 地址：IP 協議為互聯網上的每一個網路和每一臺主機分配的一個邏輯地址。IP 地址如同門牌號碼，通過 IP 地址才能確定一臺主機位置。伺服器本質也是一臺主機，想要訪問某個伺服器，必須先知道它的 IP 地址；

• 功能變數名稱（ DN ）：IP 地址由四個數字組成，中間用點號連接，在使用過程中難記憶且易輸入錯誤，所以用我們熟悉的字母和數字組合來代替純數字的 IP 地址，比如我們只會記住 www.baidu.com（百度功能變數名稱） 而不是 220.181.112.244（百度的其中一個 IP 地址）；

• DNS： 每個功能變數名稱都對應一個或多個提供相同服務伺服器的 IP 地址，只有知道伺服器 IP 地址才能建立連接，所以需要通過 DNS 把功能變數名稱解析成一個 IP 地址。

知道了上面的概念，大概就知道了想要獲得伺服器的門牌號碼，需要先將功能變數名稱轉換成 IP 地址。轉換過程如下（以查詢 www.baidu.com 的 IP 地址為例，其中2、3、4步均在上一步未查詢成功的情況下進行）：

查找過程

1. 瀏覽器搜索自己的 DNS 緩存（維護一張功能變數名稱與 IP 地址的對應表）；

2. 搜索操作系統中的 DNS 緩存（維護一張功能變數名稱與 IP 地址的對應表）；

3. 搜索操作系統的 hosts 文件（ Windows 環境下，維護一張功能變數名稱與 IP 地址的對應表）；

4. 操作系統將功能變數名稱發送至 LDNS（本地區功能變數名稱伺服器，如果你在學校接入互聯網，則 LDNS 伺服器就在學校，如果通過電信接入互聯網，則 LDNS 伺服器就在你當地的電信那裡。）LDNS 查詢自己的 DNS 緩存（一般查找成功率在 80% 左右），查找成功則返回結果，失敗則發起一個迭代 DNS 解析請求；

   1. LDNS 向 Root Name Server （根功能變數名稱伺服器，其雖然沒有每個功能變數名稱的的具體信息，但存儲了負責每個域，如 com、net、org等的解析的頂級功能變數名稱伺服器的地址）發起請求，此處，Root Name Server 返回 com 域的頂級功能變數名稱伺服器的地址；

   2. LDNS 向 com 域的頂級功能變數名稱伺服器發起請求，返回 baidu.com 功能變數名稱伺服器地址；

   3. LDNS 向 baidu.com 功能變數名稱伺服器發起請求，得到 www.baidu.com 的 IP 地址；

5. LDNS 將得到的 IP 地址返回給操作系統，同時自己也將 IP 地址緩存起來；

6. 操作系統將 IP 地址返回給瀏覽器，同時自己也將 IP 地址緩存起來；

7. 至此，瀏覽器已經得到了功能變數名稱對應的 IP 地址。

補充說明

• 功能變數名稱與 URL 是兩個概念：功能變數名稱是一臺或一組伺服器的名稱，用來確定伺服器在 Internet 上的位置；URL 是統一資源定位符，用來確定某一個文件的具體位置，例如，zhihu.com 是 知乎的功能變數名稱，根據這個功能變數名稱可以找到知乎的伺服器，zhihu.com/people/CompileYouth 是 URL ，可以根據這個 URL 定位我的知乎主頁；

• IP 地址與功能變數名稱不是一一對應的關係：可以把多個提供相同服務的伺服器 IP 設置為同一個功能變數名稱，但在同一時刻一個功能變數名稱只能解析出一個 IP地址；同時，一個 IP 地址可以綁定多個功能變數名稱，數量不限；

建立連接--三次握手

知道了伺服器的 IP 地址，下麵便開始與伺服器建立連接了。

通俗地講，通信連接的建立需要經歷以下三個過程：

1. 主機向伺服器發送一個建立連接的請求（您好，我想認識您）；

2. 伺服器接到請求後發送同意連接的信號（好的，很高興認識您）；

3. 主機接到同意連接的信號後，再次向伺服器發送了確認信號（我也很高興認識您），自此，主機與伺服器兩者建立了連接。

補充說明

• TCP 協議：三次握手的過程採用 TCP 協議，其可以保證信息傳輸的可靠性，三次握手過程中，若一方收不到確認信號，協議會要求重新發送信號。

網頁請求與顯示

當伺服器與主機建立了連接之後，下麵主機便與伺服器進行通信。網頁請求是一個單向請求的過程，即是一個主機向伺服器請求數據，伺服器返回相應的數據的過程。

1. 瀏覽器根據 URL 內容生成 HTTP 請求，請求中包含請求文件的位置、請求文件的方式等等；

2. 伺服器接到請求後，會根據 HTTP 請求中的內容來決定如何獲取相應的 HTML 文件；

3. 伺服器將得到的 HTML 文件發送給瀏覽器；

4. 在瀏覽器還沒有完全接收 HTML 文件時便開始渲染、顯示網頁；

5. 在執行 HTML 中代碼時，根據需要，瀏覽器會繼續請求圖片、CSS、JavsScript等文件，過程同請求 HTML ；

斷開連接--四次揮手

1. 主機向伺服器發送一個斷開連接的請求（不早了，我該走了）；

2. 伺服器接到請求後發送確認收到請求的信號（知道了）；

3. 伺服器向主機發送斷開通知（我也該走了）；

4. 主機接到斷開通知後斷開連接並反饋一個確認信號（嗯，好的），伺服器收到確認信號後斷開連接；

補充說明

• 為什麼伺服器在接到斷開請求時不立即同意斷開：當伺服器收到斷開連接的請求時，可能仍然有數據未發送完畢，所有伺服器先發送確認信號，等所有數據發送完畢後再同意斷開。

• 第四次握手後，主機發送確認信號後並沒有立即斷開連接，而是等待了 2 個報文傳送周期，原因是：如果第四次握手的確認信息丟失，伺服器將會重新發送第三次握手的斷開連接的信號，而伺服器發覺丟包與重新發送的斷開連接到達主機的時間正好為 2 個報文傳輸周期。