感覺這題還挺容易考到的，屬于八股文里的一股，而且在回答過程中還會(huì)觸及到其他幾個(gè)面試題。。

1. DNS解析

DNS解析的過程就是尋找哪臺(tái)機(jī)器上有你需要資源的過程。當(dāng)你在瀏覽器中輸入一個(gè)地址時(shí)，例如http://www.baidu.com，其實(shí)不是百度網(wǎng)站真正意義上的地址?；ヂ?lián)網(wǎng)上每一臺(tái)計(jì)算機(jī)的唯一標(biāo)識(shí)是它的IP地址，但是IP地址并不方便記憶。用戶更喜歡用方便記憶的網(wǎng)址去尋找互聯(lián)網(wǎng)上的其它計(jì)算機(jī)，也就是上面提到的百度的網(wǎng)址。所以互聯(lián)網(wǎng)設(shè)計(jì)者需要在用戶的方便性與可用性方面做一個(gè)權(quán)衡，這個(gè)權(quán)衡就是一個(gè)網(wǎng)址到IP地址的轉(zhuǎn)換，這個(gè)過程就是DNS解析。它實(shí)際上充當(dāng)了一個(gè)翻譯的角色，實(shí)現(xiàn)了網(wǎng)址到IP地址的轉(zhuǎn)換。
當(dāng)然如果你直接輸入的是另一臺(tái)電腦的IP地址來訪問它，那么則不存在這一步。

考點(diǎn)：DNS是如何查詢的

答：

1) 瀏覽器首先搜索瀏覽器自身緩存的DNS記錄。

2) 如果瀏覽器緩存中沒有找到需要的記錄或記錄已經(jīng)過期，則搜索hosts文件和操作系統(tǒng)緩存。

3) 如果在hosts文件和操作系統(tǒng)緩存中沒有找到需要的記錄或記錄已經(jīng)過期，則向域名解析服務(wù)器發(fā)送解析請(qǐng)求。

4) 如果域名解析服務(wù)器也沒有該域名的記錄，則開始遞歸+迭代解析。

5) 獲取域名對(duì)應(yīng)的IP后，一步步向上返回，直到返回給瀏覽器。

2. TCP連接

知道了服務(wù)器的 IP 地址，下面便開始與服務(wù)器建立連接了。

考點(diǎn)：TCP三次握手

答：

主機(jī)向服務(wù)器發(fā)送一個(gè)建立連接的請(qǐng)求（您好，我想認(rèn)識(shí)您）；
服務(wù)器接到請(qǐng)求后發(fā)送同意連接的信號(hào)（好的，很高興認(rèn)識(shí)您）；
主機(jī)接到同意連接的信號(hào)后，再次向服務(wù)器發(fā)送了確認(rèn)信號(hào)（我也很高興認(rèn)識(shí)您），自此，主機(jī)與服務(wù)器兩者建立了連接。（三次握手的過程采用 TCP 協(xié)議，其可以保證信息傳輸?shù)目煽啃?，三次握手過程中，若一方收不到確認(rèn)信號(hào)，協(xié)議會(huì)要求重新發(fā)送信號(hào)）

圖：

引發(fā)的考點(diǎn)：為什么是三次握手？

答：“已失效的連接請(qǐng)求報(bào)文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒有丟失，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間的滯留了，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)server。本來這是一個(gè)早已失效的報(bào)文段。但server收到此失效的連接請(qǐng)求報(bào)文段后，就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請(qǐng)求。于是就向client發(fā)出確認(rèn)報(bào)文段，同意建立連接。假設(shè)不采用“三次握手”，那么只要server發(fā)出確認(rèn)，新的連接就建立了。由于現(xiàn)在client并沒有發(fā)出建立連接的請(qǐng)求，因此不會(huì)理睬server的確認(rèn)，也不會(huì)向server發(fā)送數(shù)據(jù)。但server卻以為新的運(yùn)輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)。這樣，server的很多資源就白白浪費(fèi)掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況，client不會(huì)向server的確認(rèn)發(fā)出確認(rèn)。server由于收不到確認(rèn)，就知道client并沒有要求建立連接?！?--?謝希仁版《計(jì)算機(jī)網(wǎng)絡(luò)》。

3. 發(fā)起HTTP請(qǐng)求

當(dāng)服務(wù)器與主機(jī)建立了連接之后，下面主機(jī)便與服務(wù)器進(jìn)行通信。網(wǎng)頁請(qǐng)求是一個(gè)單向請(qǐng)求的過程，即是一個(gè)主機(jī)向服務(wù)器請(qǐng)求數(shù)據(jù)，服務(wù)器返回相應(yīng)的數(shù)據(jù)的過程。
瀏覽器根據(jù) URL 內(nèi)容生成 HTTP 請(qǐng)求，HTTP請(qǐng)求報(bào)文是由三部分組成: 請(qǐng)求行, 請(qǐng)求報(bào)頭和請(qǐng)求正文；

這一塊的考點(diǎn)過多，比如強(qiáng)緩存和協(xié)商緩存等。

4.?服務(wù)器處理請(qǐng)求并返回HTTP報(bào)文

服務(wù)器接到請(qǐng)求后，會(huì)根據(jù) HTTP 請(qǐng)求中的內(nèi)容來決定如何獲取相應(yīng)的 HTML 文件；
服務(wù)器將得到的 HTML 文件發(fā)送給瀏覽器；
HTTP響應(yīng)報(bào)文也是由三部分組成: 狀態(tài)碼, 響應(yīng)報(bào)頭和響應(yīng)報(bào)文

考點(diǎn)：HTTP狀態(tài)碼

答：

1xx：指示信息–表示請(qǐng)求已接收，繼續(xù)處理。
2xx：成功–表示請(qǐng)求已被成功接收、理解、接受。
3xx：重定向–要完成請(qǐng)求必須進(jìn)行更進(jìn)一步的操作。
4xx：客戶端錯(cuò)誤–請(qǐng)求有語法錯(cuò)誤或請(qǐng)求無法實(shí)現(xiàn)。
5xx：服務(wù)器端錯(cuò)誤–服務(wù)器未能實(shí)現(xiàn)合法的請(qǐng)求。

5.?瀏覽器解析渲染頁面

在瀏覽器還沒有完全接收 HTML 文件時(shí)便開始渲染、顯示網(wǎng)頁；
在執(zhí)行 HTML 中代碼時(shí)，根據(jù)需要，瀏覽器會(huì)繼續(xù)請(qǐng)求圖片、CSS、JavsScript等文件，過程同請(qǐng)求 HTML ；

這一部分都是考點(diǎn)：瀏覽器加載頁面渲染流程，大致如下

1. 解析HTML文件生成DOM Tree

2. 解析CSS文件生成CSSOM（CSS對(duì)象模型）

3. 整合DOM Tree和CSSOM，生成Render Tree

4. layout布局（重排在這一步，確定大小位置等，可以想象成將頁面切成一塊一塊的）

5. 渲染每一個(gè)節(jié)點(diǎn)（重繪在這一步，這也是為什么重排一定重繪，重繪不一定重排）

6. 結(jié)束連接

主機(jī)向服務(wù)器發(fā)送一個(gè)斷開連接的請(qǐng)求（不早了，我該走了）；
服務(wù)器接到請(qǐng)求后發(fā)送確認(rèn)收到請(qǐng)求的信號(hào)（知道了）；
服務(wù)器向主機(jī)發(fā)送斷開通知（我也該走了）；
主機(jī)接到斷開通知后斷開連接并反饋一個(gè)確認(rèn)信號(hào)（嗯，好的），服務(wù)器收到確認(rèn)信號(hào)后斷開連接；

考點(diǎn)：TCP四次揮手

圖：

文章大部分內(nèi)容整理來至知乎大佬“高程”：

《前端面試題---一個(gè)頁面從輸入 URL 到頁面加載顯示完成，這個(gè)過程中都發(fā)生了什么？》

鏈接：https://zhuanlan.zhihu.com/p/53351608