在學習前端的過程中經常看到這樣一個問題：當你在瀏覽器中輸入url后發生了什么？下面是個人學習過程中的總結，供個人復習使用，如有理解不正確或不足的地方希望大家指出。
先上一張腦圖：
我將該過程分為了以下六步：
1. DNS域名解析
- 在瀏覽器DNS緩存中搜索
- 在操作系統DNS緩存中搜索
- 讀取系統hosts文件，查找其中是否有對應的ip
- 向本地配置的首選DNS服務器發起域名解析請求
2. 建立TCP連接
為了準確地傳輸數據，TCP協議采用了三次握手策略。發送端首先發送一個帶SYN（synchronize）標志的數據包給接收方，接收方收到后，回傳一個帶有SYN/ACK(acknowledegment)標志的數據包以示傳達確認信息。最后發送方再回傳一個帶ACK標志的數據包，代表握手結束。在這過程中若出現問題中斷，TCP會再次發送相同的數據包。
TCP是一個端到端的可靠的面向連接的協議，所以HTTP基于傳輸層TCP協議不用擔心數據的傳輸的各種問題。
3. 發起HTTP請求
請求方法：
- GET:獲取資源
- POST:傳輸實體主體
- HEAD:獲取報文首部
- PUT:傳輸文件
- DELETE:刪除文件
- OPTIONS:詢問支持的方法
- TRACE:追蹤路徑
請求報文：
4. 接受響應結果
狀態碼：
- 1**：信息性狀態碼
- 2**：成功狀態碼
200：OK 請求正常處理
204：No Content請求處理成功，但沒有資源可返回
206：Partial Content對資源的某一部分的請求 - 3**：重定向狀態碼
301：Moved Permanently 永久重定向
302：Found 臨時性重定向
304：Not Modified 緩存中讀取 - 4**：客戶端錯誤狀態碼
400：Bad Request 請求報文中存在語法錯誤
401：Unauthorized需要有通過Http認證的認證信息
403：Forbidden訪問被拒絕
404：Not Found無法找到請求資源 - 5**：服務器錯誤狀態碼
500：Internal Server Error 服務器端在執行時發生錯誤
503：Service Unavailable 服務器處于超負載或者正在進行停機維護
響應報文：
5. 瀏覽器解析html
瀏覽器按順序解析html文件，構建DOM樹，在解析到外部的css和js文件時，向服務器發起請求下載資源，若是下載css文件，則解析器會在下載的同時繼續解析后面的html來構建DOM樹，則在下載js文件和執行它時，解析器會停止對html的解析。這便出現了js阻塞問題。
預加載器：
當瀏覽器被腳本文件阻塞時，預加載器（一個輕量級的解析器）會繼續解析后面的html，尋找需要下載的資源。如果發現有需要下載的資源，預加載器在開始接收這些資源。預加載器只能檢索HTML標簽中的URL，無法檢測到使用腳本添加的URL，這些資源要等腳本代碼執行時才會獲取。
注: 預解析并不改變Dom樹，它將這個工作留給主解析過程
瀏覽器解析css，形成CSSOM樹，當DOM樹構建完成后，瀏覽器引擎通過DOM樹和CSSOM樹構造出渲染樹。渲染樹中包含可視節點的樣式信息（不可見節點將不會被添加到渲染樹中，如：head元素和display值為none的元素）
值得注意的是，這個過程是逐步完成的，為了更好的用戶體驗，渲染引擎將會盡可能早的將內容呈現到屏幕上，并不會等到所有的html都解析完成之后再去構建和布局render樹。它是解析完一部分內容就顯示一部分內容，同時，可能還在通過網絡下載其余內容。
6. 瀏覽器布局渲染
- 布局：通過計算得到每個渲染對象在可視區域中的具體位置信息（大小和位置），這是一個遞歸的過程。
- 繪制：將計算好的每個像素點信息繪制在屏幕上
在頁面顯示的過程中會多次進行Reflow和Repaint操作，而Reflow的成本比Repaint的成本高得多的多。因為Repaint只是將某個部分進行重新繪制而不用改變頁面的布局，如：改變了某個元素的背景顏色。而如果將元素的display屬性由block改為none則需要Reflow。
參考鏈接：
一次完整的HTTP事務是怎樣一個過程？
瀏覽器內部工作原理
瀏覽器的渲染原理簡介
渲染樹構建、布局及繪制
如何通過預加載器提升網頁加載速度
了解html頁面的渲染過程
