在瀏覽器裏，從輸入 URL 到頁面展示，這中間發生了什麼？
此處以chrome瀏覽器爲例進行說明。
首先先介紹幾個多進程瀏覽器裏的基本概念。
- 瀏覽器進程：主要負責用戶交互、子進程管理和文件儲存等功能
- 網絡進程：面向渲染進程和瀏覽器進程等提供網絡下載功能
- 渲染進程：渲染進程的主要職責是把從網絡下載的 HTML、JavaScript、CSS、圖片等資源解析爲可以顯示和交互的頁面。因爲渲染進程所有的內容都是通過網絡獲取的，會存在一些惡意代碼利用瀏覽器漏洞對系統進行攻擊，所以運行在渲染進程裏面的代碼是不被信任的。這也是爲什麼 Chrome 會讓渲染進程運行在安全沙箱裏，就是爲了保證系統的安全
從輸入 URL 到頁面展示
1. 用戶輸入
當用戶在地址欄中輸入一個查詢關鍵字時，地址欄會判斷輸入的關鍵字是搜索內容，還是請求的 URL。
- 如果是搜索內容，地址欄會使用瀏覽器默認的搜索引擎，來合成新的帶搜索關鍵字的 URL。
- 如果判斷輸入內容符合 URL 規則，那麼地址欄會根據規則，把這段內容加上協議，合成爲完整的 URL。
當用戶輸入關鍵字並鍵入回車之後，這意味着當前頁面即將要被替換成新的頁面，不過在這個流程繼續之前，瀏覽器還給了當前頁面一次執行 beforeunload 事件的機會，beforeunload 事件允許頁面在退出之前執行一些數據清理操作，還可以詢問用戶是否要離開當前頁面，比如當前頁面可能有未提交完成的表單等情況，因此用戶可以通過 beforeunload 事件來取消導航，讓瀏覽器不再執行任何後續工作。
2. URL 請求過程
瀏覽器進程會通過進程間通信（IPC）把 URL 請求發送至網絡進程，網絡進程接收到 URL 請求後，會在這裏發起真正的 URL 請求流程。
首先，網絡進程會查找本地緩存是否緩存了該資源。如果有緩存資源，那麼直接返回資源給瀏覽器進程；如果在緩存中沒有查找到資源，那麼直接進入網絡請求流程。
這請求前的第一步是要進行 DNS 解析，以獲取請求域名的服務器 IP 地址。如果請求協議是 HTTPS，那麼還需要建立 TLS 連接。接下來就是利用 IP 地址和服務器建立 TCP 連接。連接建立之後，瀏覽器端會構建請求行、請求頭等信息，並把和該域名相關的 Cookie 等數據附加到請求頭中，然後向服務器發送構建的請求信息。
服務器接收到請求信息後，會根據請求信息生成響應數據（包括響應行、響應頭和響應體等信息），併發給網絡進程。等網絡進程接收了響應行和響應頭之後，就開始解析響應頭的內容了。
（1）重定向
在接收到服務器返回的響應頭後，網絡進程開始解析響應頭，如果發現返回的狀態碼是 301 或者 302，那麼說明服務器需要瀏覽器重定向到其他 URL。這時網絡進程會從響應頭的 Location 字段裏面讀取重定向的地址，然後再發起新的 HTTP 或者 HTTPS 請求，一切又重頭開始了。
（2）響應數據類型處理
Content-Type 是 HTTP 頭中一個非常重要的字段， 它告訴瀏覽器服務器返回的響應體數據是什麼類型，然後瀏覽器會根據 Content-Type 的值來決定如何顯示響應體的內容。
不同 Content-Type 的後續處理流程也截然不同。如果 Content-Type 字段的值被瀏覽器判斷爲下載類型，那麼該請求會被提交給瀏覽器的下載管理器，同時該 URL 請求的導航流程就此結束。但如果是 HTML，那麼瀏覽器則會繼續進行導航流程。由於 Chrome 的頁面渲染是運行在渲染進程中的，所以接下來就需要準備渲染進程了。
3. 準備渲染進程
默認情況下，Chrome 會爲每個頁面分配一個渲染進程，也就是說，每打開一個新頁面就會配套創建一個新的渲染進程。但是，也有一些例外，如果從一個頁面打開了另一個新頁面，而新頁面和當前頁面屬於同一站點的話，那麼新頁面會複用父頁面的渲染進程。
渲染進程準備好之後，還不能立即進入文檔解析狀態，因爲此時的文檔數據還在網絡進程中，並沒有提交給渲染進程，所以下一步就進入了提交文檔階段。
4. 提交文檔
所謂提交文檔，就是指瀏覽器進程將網絡進程接收到的 HTML 數據提交給渲染進程，具體流程是這樣的：
- 首先當瀏覽器進程接收到網絡進程的響應頭數據之後，便向渲染進程發起“提交文檔”的消息；
- 渲染進程接收到“提交文檔”的消息後，會和網絡進程建立傳輸數據的“管道”；
- 等文檔數據傳輸完成之後，渲染進程會返回“確認提交”的消息給瀏覽器進程；
- 瀏覽器進程在收到“確認提交”的消息後，會更新瀏覽器界面狀態，包括了安全狀態、地址欄的 URL、前進後退的歷史狀態，並更新 Web 頁面。
5. 渲染階段
一旦文檔被提交，渲染進程便開始頁面解析和子資源加載了，渲染進程會發送一個消息給瀏覽器進程，瀏覽器接收到消息後，會停止標籤圖標上的加載動畫。