打開流覽器從輸入網址到網頁呈現在大家面前， 背後到底發生了什麼？經歷怎麼樣的一個過程？
先給大家來張總體流程圖，
從URL輸入到頁面展現
一、URL到底是啥URL（Uniform Resource Locator）， 統一資源定位符， 用於定位互聯網上資源， 俗稱網址。 比如： http://www.w3school.com.cn/html/index.asp， 遵守以下的語法規則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地址？這樣可以省去解析麻煩。
我們先來瞭解下什麼是IP地址？
1. IP位址IP位址是指互聯網協定位址， 是IP Address的縮寫。 IP位址是IP協議提供的一種統一的位址格式， 它為互聯網上的每一個網路和每一台主機分配一個邏輯位址， 以此來遮罩物理位址的差異。 IP位址是一個32位的二進位數字， 比如：127.0.0.1為本機IP， 如果每個網址都是一串數字， 那就不便於記憶!
功能變數名稱就相當於IP位址喬裝打扮的偽裝者， 帶著一副面具， 它的作用就是便於記憶和溝通的一組伺服器的地址。
但這樣有時候會帶來一種風險——DNS劫持， 就是使功能變數名稱對應的不再是原本對應的IP， 其效果就是對特定的網路不能訪問或訪問的是假網址，
DNS是一個網路服務器， 我們的功能變數名稱解析簡單來說就是在DNS上記錄一條資訊記錄。 例如：baidu.com 220.114.23.56（伺服器外網IP位址）80（伺服器埠號）。
流覽器通過向DNS伺服器發送功能變數名稱， DNS伺服器查詢到與功能變數名稱相對應的IP地址， 然後返回給流覽器， 流覽器再將IP位址打在協議上， 同時請求參數也會在協定搭載， 然後一併發送給對應的伺服器， 下一步就到了伺服器處理階段的工作。
3. 功能變數名稱解析流程 流覽器緩存：如果在之前對該url指定的主機進行過訪問， 流覽器會緩存該主機的IP一段時間（該時間流覽器指定），伺服器是網路環境中的高性能電腦， 它偵聽網路上的其他電腦（客戶機）提交的服務請求， 並提供相應的服務。 比如：網頁服務、檔下載服務、郵件服務、視頻服務。
而用戶端主要的功能是流覽網頁、看視頻、聽音樂等等， 兩者截然不同。 每台伺服器上都會安裝處理請求的應用——web server， 常見的web server產品有apache、nginx、IIS或Lighttpd等。
web server 擔任管控的角色， 對於不同用戶發送的請求， 會結合設定檔， 把不同請求委託給伺服器上處理相應請求的程式進行處理（例如：CGI腳本， JSP腳本， servlets， ASP腳本， 伺服器端JavaScript， 或者一些其它的伺服器端技術等）， 然後返回幕後程式處理產生的結果作為回應。
伺服器和用戶端區別
2. MVC幕後處理階段後臺開發現在有很多框架，但大部分都還是按照MVC設計模式進行搭建的。
MVC是一個設計模式，將應用程式分成三個核心部件：模型（model）——視圖（view）——控制器（controller），它們各自處理自己的任務，實現輸入、處理和輸出的分離。
MVC架構
（1）視圖（view）
它是提供給使用者的操作介面，是程式的外殼。
（2）模型（model）
模型主要負責資料交互，在MVC的三個部件中，模型擁有最多的處理任務，一個模型能為多個視圖提供資料。
（3）控制器（controller）
它負責根據使用者從”視圖層”輸入的指令，選取”模型層”中的資料，然後對其進行相應的操作，產生最終結果。控制器屬於管理者角色，從視圖接收請求並決定調用哪個模型構件去處理請求，然後再確定用哪個視圖來顯示模型處理返回的資料。
這三層是緊密聯繫在一起的，但又是互相獨立的，每一層內部的變化不影響其他層，每一層都對外提供介面（Interface），供上面一層調用。
至於這一階段發生什麼？
簡而言之，首先流覽器發送過來的請求先經過控制器，控制器進行邏輯處理和請求分發，接著會調用模型。這一階段模型會獲取redis db以及MySQL的資料，獲取資料後將渲染好的頁面，通過視圖返回給流覽器，最後流覽器通過渲染引擎將網頁呈現在用戶面前。因此，下一步就來到流覽器處理階段
四、流覽器的處理流覽器拿到回應文本HTML後，以chrome流覽器為例，介紹下流覽器渲染機制
chrome流覽器渲染機制：
處理 HTML 標記並構建 DOM 樹。處理 CSS 標記並構建 CSSOM 樹。將 DOM 與 CSSOM 合併成一個渲染樹（render 樹）。根據渲染樹來佈局，以計算每個節點（也就是每個Element）的幾何位置，這又叫layout和reflow過程。最後通過調用作業系統Native GUI的API繪製，將各個節點繪製到螢幕上。於是就來到了繪製網頁的最後階段。五、繪製網頁流覽器根據html和css計算得到渲染樹之後，將渲染好的頁面圖像顯示出來，即繪製網頁，並開始回應用戶的操作。
六、後記隨著學習的深入，對於頁面載入這個主題認識更加深刻，之前一些困惑點現在都迎刃而解。
作者：浪裡行舟
原文連結：https://www.jianshu.com/p/40d76ebb94e2
本文由 @浪裡行舟 授權發佈于人人都是產品經理，未經作者許可，禁止轉載
題圖來自Unsplash，基於CCO協定
伺服器和用戶端區別
2. MVC幕後處理階段後臺開發現在有很多框架，但大部分都還是按照MVC設計模式進行搭建的。
MVC是一個設計模式，將應用程式分成三個核心部件：模型（model）——視圖（view）——控制器（controller），它們各自處理自己的任務，實現輸入、處理和輸出的分離。
MVC架構
（1）視圖（view）
它是提供給使用者的操作介面，是程式的外殼。
（2）模型（model）
模型主要負責資料交互，在MVC的三個部件中，模型擁有最多的處理任務，一個模型能為多個視圖提供資料。
（3）控制器（controller）
它負責根據使用者從”視圖層”輸入的指令，選取”模型層”中的資料，然後對其進行相應的操作，產生最終結果。控制器屬於管理者角色，從視圖接收請求並決定調用哪個模型構件去處理請求，然後再確定用哪個視圖來顯示模型處理返回的資料。
這三層是緊密聯繫在一起的，但又是互相獨立的，每一層內部的變化不影響其他層，每一層都對外提供介面（Interface），供上面一層調用。
至於這一階段發生什麼？
簡而言之，首先流覽器發送過來的請求先經過控制器，控制器進行邏輯處理和請求分發，接著會調用模型。這一階段模型會獲取redis db以及MySQL的資料，獲取資料後將渲染好的頁面，通過視圖返回給流覽器，最後流覽器通過渲染引擎將網頁呈現在用戶面前。因此，下一步就來到流覽器處理階段
四、流覽器的處理流覽器拿到回應文本HTML後，以chrome流覽器為例，介紹下流覽器渲染機制
chrome流覽器渲染機制：
處理 HTML 標記並構建 DOM 樹。處理 CSS 標記並構建 CSSOM 樹。將 DOM 與 CSSOM 合併成一個渲染樹（render 樹）。根據渲染樹來佈局，以計算每個節點（也就是每個Element）的幾何位置，這又叫layout和reflow過程。最後通過調用作業系統Native GUI的API繪製，將各個節點繪製到螢幕上。於是就來到了繪製網頁的最後階段。五、繪製網頁流覽器根據html和css計算得到渲染樹之後，將渲染好的頁面圖像顯示出來，即繪製網頁，並開始回應用戶的操作。
六、後記隨著學習的深入，對於頁面載入這個主題認識更加深刻，之前一些困惑點現在都迎刃而解。
作者：浪裡行舟
原文連結：https://www.jianshu.com/p/40d76ebb94e2
本文由 @浪裡行舟 授權發佈于人人都是產品經理，未經作者許可，禁止轉載
題圖來自Unsplash，基於CCO協定