摘要： 經典面試題。
- 原文： 從 URL 輸入到頁面展現到底發生什麼？
- 作者： 浪裡行舟
經授權轉載，版權歸原作者所有。
前言
打開浏覽器從輸入網址到網頁呈現在大家面前，背後到底發生了什麼？經曆怎麼樣的一個過程？先給大家來張總體流程圖，具體步驟請看下文分解！
本文首發位址為
GitHub 部落格，寫文章不易，請多多支援與關注！
總體來說分為以下幾個過程:
- DNS 解析:将域名解析成 IP 位址
- TCP 連接配接：TCP 三次握手
- 發送 HTTP 請求
- 伺服器處理請求并傳回 HTTP 封包
- 浏覽器解析渲染頁面
- 斷開連接配接：TCP 四次揮手
一、URL 到底是啥
URL（Uniform Resource Locator），統一資源定位符，用于定位網際網路上資源，俗稱網址。比如
http://www.w3school.com.cn/ht...，遵守以下的文法規則：
scheme://host.domain:port/path/filename 各部分解釋如下：
- scheme - 定義網際網路服務的類型。常見的協定有 http、https、ftp、file，其中最常見的類型是 http，而 https 則是進行加密的網絡傳輸。
- host - 定義域主機（http 的預設主機是 www）
- domain - 定義網際網路域名，比如 w3school.com.cn
- port - 定義主機上的端口号（http 的預設端口号是 80）
- path - 定義伺服器上的路徑（如果省略，則文檔必須位于網站的根目錄中）。
- filename - 定義文檔/資源的名稱
二、域名解析（DNS）
在浏覽器輸入網址後，首先要經過域名解析，因為浏覽器并不能直接通過域名找到對應的伺服器，而是要通過 IP 位址。大家這裡或許會有個疑問----計算機既可以被賦予 IP 位址，也可以被賦予主機名和域名。比如
www.hackr.jp
。那怎麼不一開始就賦予個 IP 位址？這樣就可以省去解析麻煩。我們先來了解下什麼是 IP 位址
1. IP 位址
IP 位址是指網際網路協定位址，是 IP Address 的縮寫。IP 位址是 IP 協定提供的一種統一的位址格式，它為網際網路上的每一個網絡和每一台主機配置設定一個邏輯位址，以此來屏蔽實體位址的差異。IP 位址是一個 32 位的二進制數，比如 127.0.0.1 為本機 IP。
域名就相當于 IP 位址喬裝打扮的僞裝者，帶着一副面具。它的作用就是便于記憶和溝通的一組伺服器的位址。使用者通常使用主機名或域名來通路對方的計算機，而不是直接通過 IP 位址通路。因為與 IP 位址的一組純數字相比，用字母配合數字的表示形式來指定計算機名更符合人類的記憶習慣。但要讓計算機去了解名稱，相對而言就變得困難了。因為計算機更擅長處理一長串數字。為了解決上述的問題，DNS 服務應運而生。
2. 什麼是域名解析
DNS 協定提供通過域名查找 IP 位址，或逆向從 IP 位址反查域名的服務。DNS 是一個網絡伺服器，我們的域名解析簡單來說就是在 DNS 上記錄一條資訊記錄。
例如 baidu.com 220.114.23.56（伺服器外網IP位址）80（伺服器端口号） 3. 浏覽器如何通過域名去查詢 URL 對應的 IP 呢
- 浏覽器緩存：浏覽器會按照一定的頻率緩存 DNS 記錄。
- 作業系統緩存：如果浏覽器緩存中找不到需要的 DNS 記錄，那就去作業系統中找。
- 路由緩存：路由器也有 DNS 緩存。
- ISP 的 DNS 伺服器：ISP 是網際網路服務提供商(Internet Service Provider)的簡稱，ISP 有專門的 DNS 伺服器應對 DNS 查詢請求。
- 根伺服器：ISP 的 DNS 伺服器還找不到的話，它就會向根伺服器送出請求，進行遞歸查詢（DNS 伺服器先問根域名伺服器.com 域名伺服器的 IP 位址，然後再問.baidu 域名伺服器，依次類推）
4. 小結
浏覽器通過向 DNS 伺服器發送域名，DNS 伺服器查詢到與域名相對應的 IP 位址，然後傳回給浏覽器，浏覽器再将 IP 位址打在協定上，同時請求參數也會在協定搭載，然後一并發送給對應的伺服器。接下來介紹向伺服器發送 HTTP 請求階段，HTTP 請求分為三個部分：TCP 三次握手、http 請求響應資訊、關閉 TCP 連接配接。
三、TCP 三次握手
在用戶端發送資料之前會發起 TCP 三次握手用以同步用戶端和服務端的序列号和确認号，并交換 TCP 視窗大小資訊。
1. TCP 三次握手的過程如下：
- 用戶端發送一個帶 SYN=1，Seq=X 的資料包到伺服器端口（第一次握手，由浏覽器發起，告訴伺服器我要發送請求了）
- 伺服器發回一個帶 SYN=1， ACK=X+1， Seq=Y 的響應包以示傳達确認資訊（第二次握手，由伺服器發起，告訴浏覽器我準備接受了，你趕緊發送吧）
- 用戶端再回傳一個帶 ACK=Y+1， Seq=Z 的資料包，代表“握手結束”（第三次握手，由浏覽器發送，告訴伺服器，我馬上就發了，準備接受吧）
2. 為啥需要三次握手
謝希仁著《計算機網絡》中講“三次握手”的目的是“為了防止已失效的連接配接請求封包段突然又傳送到了服務端，因而産生錯誤”。
四、發送 HTTP 請求
TCP 三次握手結束後，開始發送 HTTP 請求封包。
請求封包由請求行（request line）、請求頭（header）、請求體四個部分組成,如下圖所示：
1. 請求行包含請求方法、URL、協定版本
- 請求方法包含 8 種：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。
- URL 即請求位址，由 <協定>：//<主機>：<端口>/<路徑>?<參數> 組成
- 協定版本即 http 版本号
POST /chapter17/user.html HTTP/1.1 以上代碼中“POST”代表請求方法，“/chapter17/user.html”表示 URL，“HTTP/1.1”代表協定和協定的版本。現在比較流行的是 Http1.1 版本
2. 請求頭包含請求的附加資訊，由關鍵字/值對組成，每行一對，關鍵字和值用英文冒号“:”分隔。
請求頭部通知伺服器有關于用戶端請求的資訊。它包含許多有關的用戶端環境和請求正文的有用資訊。其中比如：Host，表示主機名，虛拟主機；Connection,HTTP/1.1 增加的，使用 keepalive，即持久連接配接，一個連接配接可以發多個請求；User-Agent，請求發出者，相容性以及定制化需求。
3. 請求體，可以承載多個請求參數的資料，包含回車符、換行符和請求資料，并不是所有請求都具有請求資料。
name=tom&password=1234&realName=tomson 上面代碼，承載着 name、password、realName 三個請求參數。
給大家推薦一個好用的 BUG 監控工具
，歡迎免費試用！
五、伺服器處理請求并傳回 HTTP 封包
1. 伺服器
伺服器是網絡環境中的高性能計算機，它偵聽網絡上的其他計算機（客戶機）送出的服務請求，并提供相應的服務，比如網頁服務、檔案下載下傳服務、郵件服務、視訊服務。而用戶端主要的功能是浏覽網頁、看視訊、聽音樂等等，兩者截然不同。 每台伺服器上都會安裝處理請求的應用——web server。常見的 web server 産品有 apache、nginx、IIS 或 Lighttpd 等。
web server 擔任管控的角色，對于不同使用者發送的請求，會結合配置檔案，把不同請求委托給伺服器上處理相應請求的程式進行處理（例如 CGI 腳本，JSP 腳本，servlets，ASP 腳本，伺服器端 JavaScript，或者一些其它的伺服器端技術等），然後傳回背景程式處理産生的結果作為響應。
2. MVC 背景處理階段
背景開發現在有很多架構，但大部分都還是按照 MVC 設計模式進行搭建的。
MVC 是一個設計模式，将應用程式分成三個核心部件：模型（model）-- 視圖（view）--控制器（controller），它們各自處理自己的任務，實作輸入、處理和輸出的分離。
1、視圖（view）
它是提供給使用者的操作界面，是程式的外殼。
2、模型（model）
模型主要負責資料互動。在 MVC 的三個部件中，模型擁有最多的處理任務。一個模型能為多個視圖提供資料。
3、控制器（controller）
它負責根據使用者從"視圖層"輸入的指令，選取"模型層"中的資料，然後對其進行相應的操作，産生最終結果。控制器屬于管理者角色，從視圖接收請求并決定調用哪個模型構件去處理請求，然後再确定用哪個視圖來顯示模型處理傳回的資料。
這三層是緊密聯系在一起的，但又是互相獨立的，每一層内部的變化不影響其他層。每一層都對外提供接口（Interface），供上面一層調用。
至于這一階段發生什麼？簡而言之，首先浏覽器發送過來的請求先經過控制器，控制器進行邏輯處理和請求分發，接着會調用模型，這一階段模型會擷取 redis db 以及 MySQL 的資料，擷取資料後将渲染好的頁面，響應資訊會以響應封包的形式傳回給用戶端，最後浏覽器通過渲染引擎将網頁呈現在使用者面前。
3. http 響應封包
響應封包由響應行（request line）、響應頭部（header）、響應主體三個部分組成。如下圖所示：
(1) 響應行包含：協定版本，狀态碼，狀态碼描述
狀态碼規則如下：
- 1xx：訓示資訊--表示請求已接收，繼續處理。
- 2xx：成功--表示請求已被成功接收、了解、接受。
- 3xx：重定向--要完成請求必須進行更進一步的操作。
- 4xx：用戶端錯誤--請求有文法錯誤或請求無法實作。
- 5xx：伺服器端錯誤--伺服器未能實作合法的請求。
(2) 響應頭部包含響應封包的附加資訊，由 名/值 對組成
(3) 響應主體包含回車符、換行符和響應傳回資料，并不是所有響應封包都有響應資料
六、浏覽器解析渲染頁面
浏覽器拿到響應文本 HTML 後，接下來介紹下浏覽器渲染機制
浏覽器解析渲染頁面分為一下五個步驟：
- 根據 HTML 解析出 DOM 樹
- 根據 CSS 解析生成 CSS 規則樹
- 結合 DOM 樹和 CSS 規則樹，生成渲染樹
- 根據渲染樹計算每一個節點的資訊
- 根據計算好的資訊繪制頁面
1. 根據 HTML 解析 DOM 樹
- 根據 HTML 的内容，将标簽按照結構解析成為 DOM 樹，DOM 樹解析的過程是一個深度優先周遊。即先建構目前節點的所有子節點，再建構下一個兄弟節點。
- 在讀取 HTML 文檔，建構 DOM 樹的過程中，若遇到 script 标簽，則 DOM 樹的建構會暫停，直至腳本執行完畢。
2. 根據 CSS 解析生成 CSS 規則樹
- 解析 CSS 規則樹時 js 執行将暫停，直至 CSS 規則樹就緒。
- 浏覽器在 CSS 規則樹生成之前不會進行渲染。
3. 結合 DOM 樹和 CSS 規則樹，生成渲染樹
- DOM 樹和 CSS 規則樹全部準備好了以後，浏覽器才會開始建構渲染樹。
- 精簡 CSS 并可以加快 CSS 規則樹的建構，進而加快頁面相應速度。
4. 根據渲染樹計算每一個節點的資訊（布局）
- 布局：通過渲染樹中渲染對象的資訊，計算出每一個渲染對象的位置和尺寸
- 回流：在布局完成後，發現了某個部分發生了變化影響了布局，那就需要倒回去重新渲染。
5. 根據計算好的資訊繪制頁面
- 繪制階段，系統會周遊呈現樹，并調用呈現器的“paint”方法，将呈現器的内容顯示在螢幕上。
- 重繪：某個元素的背景顔色，文字顔色等，不影響元素周圍或内部布局的屬性，将隻會引起浏覽器的重繪。
- 回流：某個元素的尺寸發生了變化，則需重新計算渲染樹，重新渲染。
七、斷開連接配接
當資料傳送完畢，需要斷開 tcp 連接配接，此時發起 tcp 四次揮手。
- 發起方向被動方發送封包，Fin、Ack、Seq，表示已經沒有資料傳輸了。并進入 FIN_WAIT_1 狀态。(第一次揮手：由浏覽器發起的，發送給伺服器，我請求封包發送完了，你準備關閉吧)
- 被動方發送封包，Ack、Seq，表示同意關閉請求。此時主機發起方進入 FIN_WAIT_2 狀态。(第二次揮手：由伺服器發起的，告訴浏覽器，我請求封包接受完了，我準備關閉了，你也準備吧)
- 被動方向發起方發送封包段，Fin、Ack、Seq，請求關閉連接配接。并進入 LAST_ACK 狀态。(第三次揮手：由伺服器發起，告訴浏覽器，我響應封包發送完了，你準備關閉吧)
- 發起方向被動方發送封包段，Ack、Seq。然後進入等待 TIME_WAIT 狀态。被動方收到發起方的封包段以後關閉連接配接。發起方等待一定時間未收到回複，則正常關閉。(第四次揮手：由浏覽器發起，告訴伺服器，我響應封包接受完了，我準備關閉了，你也準備吧)
參考文章
- 從輸入頁面位址到展示頁面資訊都發生了些什麼？
- 前端經典面試題: 從輸入 URL 到頁面加載發生了什麼？
- TCP 的三次握手四次揮手
- 通路 Web，tcp 傳輸全過程（三次握手、請求、資料傳輸、四次揮手）
- 浏覽器發送 http 請求過程分析
- 謝希仁著《計算機網絡》第四版
- 圖解 http
關于Fundebug
！