一文講透從輸入URL到浏覽器顯示頁面發生了什麼

這是一個老生常談的話題，今天我們再來詳細想分析一波。

步驟如下：

1.浏覽器對使用者輸入的網址(域名)做初步的格式化檢查

2.浏覽器對使用者輸入的網址預設進行http/https補全。

3.浏覽器将網址通過DNS協定解析成具體的IP位址

PS：DNS(Domain Name System)，域名系統，是一個聯機分布式資料庫系統，并采用客戶伺服器方式，DNS大多數名字都在本地解析，少量解析需要在網絡上，是以它的效率很高。IP位址的解析是由許多的域名伺服器程式共同完成的。

在這個步驟中，又細分以下幾個步驟：

1).查詢浏覽器的DNS緩存，可以使用 chrome://net-internals/#dns 來檢視，如果沒有對應IP，則進入下一步

2).查詢作業系統的DNS緩存,以Windows系統為例，可以在指令行下使用 ipconfig /displaydns 來進行檢視，如果沒有對應IP，則進入下一步

3).讀取hosts檔案（位于C:\Windows\System32\drivers\etc），檢視有沒有該域名對應的IP位址，如果沒有，則進入下一步

此時已經確定了你的本機的DNS裡沒有對應IP了，接下來就要通過網絡去查找了。

4).聯網向浏覽器發起一個DNS的系統調用，向本地配置的ISP(Internet Service Provide，即網際網路服務提供者，可以了解為營運商)發起域名解析請求，通過UDP協定向DNS伺服器的53端口發起請求，這個請求是遞歸的請求，也就是的DNS伺服器必須得提供給我們該域名的IP位址，ISP的DNS伺服器首先查找自身的緩存，找到對應的條目，且沒有過期，則解析成功。如果沒有找到對應的條目，則ISP的DNS代我們的浏覽器發起疊代DNS解析請求，它首先是會找根域的DNS的IP位址，這個DNS伺服器都内置13台根域的DNS的IP位址(這裡的13台根域名伺服器其實并不真是13台，而是13個ip位址，采用任播技術，我們可以在全球設立這些ip的鏡像站點，你通路到的ip并不是唯一的那台主機)，找到根域的DNS位址後，就會向其發起請求，例如www.cnblogs.com這個域名(www是三級域名，cnblog是二級，com是頂級)，根域發現這是一個頂級域com域的一個域名，于是就告訴ISP的DNS我不知道這個域名的IP位址，但是我知道com域的IP位址，你去找它，于是ISP的DNS就得到了com域的IP位址，又向com域的IP位址發起了請求，請問www.cnblogs.com這個域名的IP位址是多少?com域這台伺服器告訴營運商的DNS我不知道www.cnblogs.com這個域名的IP位址，但是我知道www.cnblogs.com這個域的DNS位址，你去找它去，于是ISP的DNS又向www.cnblogs.com這個域名的DNS位址（這個一般就是由域名注冊商提供的，像萬網，新網等）發起請求（請問www.cnblogs.com這個域名的IP位址是多少？），這個時候cnblogs.com域的DNS伺服器一查，果真在我這裡，于是就把找到的結果發送給ISP的DNS伺服器，這個時候營運商的DNS伺服器就拿到了www.cnblogs.com這個域名對應的IP位址，并傳回給Windows系統核心，核心又把結果傳回給浏覽器，終于浏覽器拿到了www.cnblogs.com對應的IP位址，該進行一步的動作了。

4.發起TCP的3次握手

大概的過程就是：

• 第一次握手： A給B打電話說，你可以聽到我說話嗎？
• 第二次握手： B收到了A的資訊，然後對A說： 我可以聽得到你說話啊，你能聽得到我說話嗎？
• 第三次握手： A收到了B的資訊，然後說可以的，我要給你發資訊啦！

在三次握手之後，A和B都能确定這麼一件事： 我說的話，你能聽到； 你說的話，我也能聽到。 這樣，就可以開始正常通信了。

5.發送Http請求

Http請求封包攜帶各種頭部資訊，大緻分為三個部分：請求行、請求頭、請求體。

請求行一般包括：伺服器協定版本，狀态碼：

狀态碼是由3位數組成，第一個數字定義了響應的類别，且有五種可能取值:

1xx：訓示資訊–表示請求已接收，繼續處理。

2xx：成功–表示請求已被成功接收、了解、接受。

3xx：重定向–要完成請求必須進行更進一步的操作。

4xx：用戶端錯誤–請求有文法錯誤或請求無法實作。

5xx：伺服器端錯誤–伺服器未能實作合法的請求。

請求頭一般包括：此次響應的時間、此次響應傳回的檔案長度、檔案類型等等

請求體一般包括：伺服器傳回給用戶端的檔案、資料等（當請求時POST的時候才會有請求體）

6.伺服器處理後響應給用戶端HTML檔案

7.浏覽器解析HTML代碼。

浏覽器拿到html檔案後，就開始解析其中的html代碼，遇到js/css/image等靜态資源時，就向伺服器端去請求下載下傳（會使用多線程下載下傳，每個浏覽器的線程數不一樣），這個時候就用上keep-alive特性了，建立一次HTTP連接配接，可以請求多個資源(HTTP的版本要為1.1)，下載下傳資源的順序就是按照代碼裡的順序，但是由于每個資源大小不一樣，而浏覽器又多線程請求請求資源，是以顯示的順序并不一定是代碼裡面的順序。

如果浏覽器在請求靜态資源時（在未過期的情況下），向伺服器端發起一個http請求（詢問自從上一次修改時間到現在有沒有對資源進行修改），如果伺服器端傳回304狀态碼（告訴浏覽器伺服器端沒有修改），那麼浏覽器會直接讀取本地的該資源的緩存檔案。

8.浏覽器渲染頁面

渲染的過程大緻分為：

1. 轉換： 浏覽器從磁盤或網絡讀取 HTML 的原始位元組，并根據檔案的指定編碼（如 UTF-8）将它們轉換成各個字元。
2. Tokenizing： 浏覽器将字元串轉換成 W3C HTML5 标準規定的各種tokens，例如，“”、“”，以及其他尖括号内的字元串。每個token都具有特殊含義和一組規則。
3. 詞法分析： 發出的标記轉換成定義其屬性和規則的“對象”。
4. DOM 建構： 最後，由于 HTML 标記定義不同标記之間的關系（一些标記包含在其他标記内），建立的對象連結在一個樹資料結構内，此結構也會捕獲原始标記中定義的父項-子項關系：HTML 對象是 body 對象的父項，body是paragraph對象的父項，依此類推。

整個流程最終輸出是頁面的文檔對象模型 (DOM)，浏覽器對頁面進行的所有進一步處理都會用到它。

總結：

1. DNS解析
2. TCP連接配接
3. 發送HTTP請求
4. 伺服器處理請求并傳回HTTP封包
5. 浏覽器解析渲染頁面
6. 連接配接結束

用到的協定：

這部分的知識完全可以寫成一本書的厚度，無論從前端，後端，網絡，協定各方面都有龐大的知識體系，是以隻能對其中最核心的地方做闡釋，具體請參見《網絡是怎麼連接配接的》這本書。

本文部分參考了

https://www.cnblogs.com/wupeixuan/p/8747918.html

https://www.cnblogs.com/kevin2chen/p/6938021.html

https://segmentfault.com/a/1190000006879700

《圖解HTTP》

《計算機網絡》教材