這哥問題是一個常被用作面試題的問題下面我們來細說一下這個流程和相關(guān)概念

URL 解析

URL，統(tǒng)一資源定位符，是用來表示從互聯(lián)網(wǎng)上得到的資源位置和訪問這些資源的方法，俗稱網(wǎng)址！互聯(lián)網(wǎng)上的所有資源，都有一個唯一確定的URL。URL的一般形式由一下四個部分組成：

<協(xié)議>://<主機>:<端口>/<路徑>

URL的第一部分是最左邊的<協(xié)議>。這里的<協(xié)議>就是指出使用什么協(xié)議來獲取萬維網(wǎng)文檔。現(xiàn)在最常用的協(xié)議就是http（超文本傳輸協(xié)議HTTP），其次就是ftp（文件傳輸協(xié)議FTP）。在協(xié)議后面的:// 是規(guī)定的格式。它的右邊是第二部分<主機>，它指出這個萬維網(wǎng)文檔是在哪一臺主機上。這里的<主機>就是指該主機在互聯(lián)網(wǎng)上的域名 。在后面是第三部分和第四部分<端口>和<路徑>,有時可以省略。如果是采用http協(xié)議訪問萬維網(wǎng)文檔，如果省略端口，走會訪問默認端口80，如果省略路徑，則URL就指到互聯(lián)網(wǎng)上的某個主頁（home page）。而URL解析，就是當(dāng)用戶輸入URL并回車后，瀏覽器對拿到的URL進行識別，抽取出域名字段，比如https://www.baidu.com,它的域名就是www.baidu.com,拿到域名后，就會順利進行第二步了，就是DNS域名解析!

圖片

DNS 域名解析

域名系統(tǒng)DNS（Domain Name System）是互聯(lián)網(wǎng)使用的命名系統(tǒng)，用來把便于人們使用的機器名轉(zhuǎn)換為IP地址。用戶與互聯(lián)網(wǎng)上的某臺主機通信時，必須要知道對方的IP地址。然而用戶很難記住長達32位的二進制主機地址。及時是點分十進制IP地址也并不容易記憶。但是在應(yīng)用層為了方便用戶記憶各種網(wǎng)絡(luò)應(yīng)用，連接在互聯(lián)網(wǎng)上的主機不僅有IP地址，而且還有便于用戶記憶的主機名字（域名）。域名系統(tǒng)DNS能夠把互聯(lián)網(wǎng)上的主機名字轉(zhuǎn)換為IP地址。既然互聯(lián)網(wǎng)上的每一臺主機都有主機名字，那么為什么機器在處理IP數(shù)據(jù)報的時候要使用IP地址而不是用域名呢？簡單來說，這是因為IP地址的長度是固定的32位（如果是IPv6地址，那就是固定的128位，也是定長的），而域名的長度并不是固定的，機器處理起來比較困難。注意，可以在瀏覽器中輸入域名得出網(wǎng)頁內(nèi)容，也可以輸入對應(yīng)的IP地址得到網(wǎng)頁內(nèi)容。雖然得出的內(nèi)容是一樣的，但調(diào)用的過程不一樣，輸入IP地址是直接從主機上調(diào)用內(nèi)容，輸入域名是通過對應(yīng)的域名解析服務(wù)器指向?qū)?yīng)的主機IP地址，在從主機中調(diào)用網(wǎng)址的內(nèi)容。

圖片

建立 TCP 連接

第一次握手：客戶端向服務(wù)器端發(fā)送請求（SYN=1） 等待服務(wù)器響應(yīng)；第二次握手：服務(wù)器收到請求并確認，回復(fù)一個指令（SYN=1，ACK=1）；第三次握手：客戶端收到服務(wù)器的回復(fù)指令并返回確認（ACK=1）。

圖片

這里我又有一個問題來了，為什么A最后還要發(fā)送一次確認呢？請讀者稍加思考一下！

這主要是為了防止已失效的連接請求報文段突然又傳送到了B，因而產(chǎn)生錯誤！所謂的已失效的請求報文段是這樣產(chǎn)生的?？紤]一種正常情況，A發(fā)出連接請求，但因連接請求報文丟失而未收到確認。于是A在重傳一次連接請求。后來收到了來自服務(wù)器的連接請求確認，建立了連接。數(shù)據(jù)傳輸完畢后，就通過四次揮手釋放了連接。在該過程中，A共發(fā)出了兩個連接請求報文段，其中第一個丟失，第二個達到了B，沒有已失效的連接請求報文段。

現(xiàn)假定出現(xiàn)一種異常情況，即A發(fā)出的第一個連接請求報文段并沒有丟失，而是在某些網(wǎng)絡(luò)結(jié)點長時間滯留了，以致延誤到連接釋放以后的某個時間才達到B。本來這是一個早已失效的報文段，但B收到此失效的連接請求報文段后，就誤認為是A又發(fā)出了一次新的連接請求。于是就想A發(fā)出確認連接報文段，同意建立連接。假定不采用三次握手，那么只要B發(fā)出確認，新的連接就建立了。由于現(xiàn)在A并沒有發(fā)出建立連接的請求，因此不會理睬B的確認，也不會向B發(fā)送數(shù)據(jù)。但B卻認為新的運輸連接已經(jīng)建立了，并一直等待A發(fā)送數(shù)據(jù)。于是B的資源就這樣白白浪費了。

發(fā)送 HTTP 請求

HTTP協(xié)議定義了瀏覽器怎樣向萬維網(wǎng)服務(wù)器請求萬維網(wǎng)文檔，以及服務(wù)器怎樣把文檔傳送給瀏覽器。從層次的角度看，HTTP是面向事務(wù)的應(yīng)用層協(xié)議。HTTP有兩類報文：

（1）請求報文——從客戶端向服務(wù)器發(fā)送請求報文。如下圖所示。

（2）響應(yīng)報文——從服務(wù)器到客戶端的回答。

圖片

HTTP請求報文有三部分組成，即請求行，首部行和實體主體三部分組成。請求報文的第一行，請求行只有三個內(nèi)容，即方法，請求資源的URL以及HTTP的版本。這里的方法就是對所請求的對象進行操作這些方法實際上也就是一些命令。

常見請求報文的方法

例如下面是一個HTTP的請求報文的開始行的格式,由方法，域名以及HTTP的版本構(gòu)成。注意（方法與域名之間含空格，域名與HTTP版本之間也含空格）。

GET http://www.lovsh.com/dir/index.html HTTP/1.1

服務(wù)器處理相關(guān)的請求

接受HTTP報文后，會對連接進行處理，對HTTP協(xié)議進行解析（請求方法、域名、路徑等），并且進行一些驗證：

驗證是否配置虛擬主機驗證虛擬主機是否接受此方法驗證該用戶可以使用該方法（根據(jù) IP 地址、身份信息等）重定向假如服務(wù)器配置了 HTTP 重定向，就會返回一個 301永久重定向響應(yīng)，瀏覽器就會根據(jù)響應(yīng)，重新發(fā)送 HTTP 請求（重新執(zhí)行上面的過程）。URL 重寫然后會查看 URL 重寫規(guī)則，如果請求的文件是真實存在的，比如圖片、html、css、js文件等，則會直接把這個文件返回。否則服務(wù)器會按照規(guī)則把請求重寫到 一個 REST 風(fēng)格的 URL 上。然后根據(jù)動態(tài)語言的腳本，來決定調(diào)用什么類型的動態(tài)文件解釋器來處理這個請求。

圖片

返回響應(yīng)的結(jié)果

服務(wù)器每收到一個請求報文后，對應(yīng)的都會回復(fù)一個響應(yīng)報文。HTTP的響應(yīng)報文由狀態(tài)行，首部行以及實體主體組成，一般用開始行是請求行還是狀態(tài)行來區(qū)分是請求報文還是響應(yīng)報文！

響應(yīng)報文的第一行就是狀態(tài)行，狀態(tài)行包括版本，狀態(tài)碼以及短語組成。狀態(tài)碼都是三位數(shù)字構(gòu)成的，分為5大類，原先有33種，后來又增加了幾種。這5大類的狀態(tài)碼都是以不同的數(shù)字開頭的。

斷開 TCP 連接

第一次揮手：客戶端向服務(wù)器發(fā)送連接釋放報文段（FIN=1），等待服務(wù)器響應(yīng)；

第二次揮手：服務(wù)器收到連接釋放報文段并發(fā)出確認（ACK=1），客戶端到服務(wù)器的連接關(guān)閉，此時TCP處理半關(guān)閉狀態(tài)，需要等到服務(wù)器向客戶端發(fā)送數(shù)據(jù)結(jié)束；

第三次揮手：服務(wù)器向客戶端發(fā)送連接釋放報文段（FIN=1，ACK=1），并等待客戶端的確認；

第四次揮手：客戶端收到服務(wù)器的連接釋放報文段并給出確認（ACK=1），連接釋放。

圖片

瀏覽器解析渲染頁面

HTMl解析與頁面渲染的過程如下所示：

1. 瀏覽器獲取到 html 資源后開始解析 html (dom tree)
2. 解析到 css 后根據(jù) css 生成 css 規(guī)則樹 (style rules).
3. 在 dom 樹和 css 規(guī)則樹都生成完后，通過 dom 樹和 css 規(guī)則樹生成渲染樹( render tree )
4. 渲染樹構(gòu)建完成后，瀏覽器開始計算元素的大小和位置( layout )
5. 根據(jù)計算好的節(jié)點信息將內(nèi)容繪制到屏幕上( painting )

圖片

注意：

瀏覽器為了提升性能，在 URL 解析之后，實際會先查詢是否有緩存，如果緩存命中，則直接返回緩存資源。

如果是 HTTPS 協(xié)議，在建立 TCP 連接之后，還需要進行 SSL/TLS 握手過程，以協(xié)商出一個會話密鑰，用于消息加密，提升安全性。