完整高頻題庫(kù)倉(cāng)庫(kù)地址：https://github.com/hzfe/awesome-interview

完整高頻題庫(kù)閱讀地址：https://febook.hzfe.org/

回答關(guān)鍵點(diǎn)

URL DNS TCP 渲染

瀏覽器從輸入網(wǎng)址到渲染頁(yè)面主要分為以下幾個(gè)過(guò)程

• URL 輸入
• DNS 解析
• 建立 TCP 連接
• 發(fā)送 HTTP / HTTPS 請(qǐng)求（建立 TLS 連接）
• 服務(wù)器響應(yīng)請(qǐng)求
• 瀏覽器解析渲染頁(yè)面
• HTTP 請(qǐng)求結(jié)束砸西，斷開(kāi) TCP 連接

知識(shí)點(diǎn)深入

1. URL 輸入

URL（統(tǒng)一資源定位符糯耍，Uniform Resource Locator）用于定位互聯(lián)網(wǎng)上資源硅确，俗稱(chēng)網(wǎng)址。

我們?cè)诘刂窓谳斎?HZFE 官方網(wǎng)址 hzfe.org 后敲下回車(chē)盾计，瀏覽器會(huì)對(duì)輸入的信息進(jìn)行以下判斷：

1. 檢查輸入的內(nèi)容是否是一個(gè)合法的 URL 鏈接催束。
2. 是澎现，則判斷輸入的 URL 是否完整。如果不完整押赊，瀏覽器可能會(huì)對(duì)域進(jìn)行猜測(cè)饺藤，補(bǔ)全前綴或者后綴。
3. 否，將輸入內(nèi)容作為搜索條件涕俗，使用用戶設(shè)置的默認(rèn)搜索引擎來(lái)進(jìn)行搜索罗丰。

大部分瀏覽器會(huì)從歷史記錄、書(shū)簽等地方開(kāi)始查找我們輸入的網(wǎng)址再姑，并給出智能提示萌抵。

2. DNS（Domain Name System）解析

因?yàn)闉g覽器不能直接通過(guò)域名找到對(duì)應(yīng)的服務(wù)器 IP 地址，所以需要進(jìn)行 DNS 解析元镀，查找到對(duì)應(yīng)的 IP 地址進(jìn)行訪問(wèn)绍填。

DNS 解析流程如下：

1. 在瀏覽器中輸入 hzfe.org 域名，操作系統(tǒng)檢查瀏覽器緩存和本地的 hosts 文件中栖疑，是否有這個(gè)網(wǎng)址記錄讨永，有則從記錄里面找到對(duì)應(yīng)的 IP 地址，完成域名解析遇革。
2. 查找本地 DNS 解析器緩存中住闯，是否有這個(gè)網(wǎng)址記錄，有則從記錄里面找到對(duì)應(yīng)的 IP 地址澳淑，完成域名解析比原。
3. 使用 TCP/IP 參數(shù)中設(shè)置的 DNS 服務(wù)器進(jìn)行查詢(xún)。如果要查詢(xún)的域名包含在本地配置區(qū)域資源中杠巡，則返回解析結(jié)果量窘，完成域名解析。
4. 檢查本地 DNS 服務(wù)器是否緩存該網(wǎng)址記錄氢拥，有則返回解析結(jié)果蚌铜，完成域名解析。
5. 本地 DNS 服務(wù)器發(fā)送查詢(xún)報(bào)文至根 DNS 服務(wù)器嫩海，根 DNS 服務(wù)器收到請(qǐng)求后冬殃，用頂級(jí)域 DNS 服務(wù)器地址進(jìn)行響應(yīng)。
6. 本地 DNS 服務(wù)器發(fā)送查詢(xún)報(bào)文至頂級(jí)域 DNS 服務(wù)器叁怪。頂級(jí)域 DNS 服務(wù)器收到請(qǐng)求后审葬，用權(quán)威 DNS 服務(wù)器地址進(jìn)行響應(yīng)。
7. 本地 DNS 服務(wù)器發(fā)送查詢(xún)報(bào)文至權(quán)威 DNS 服務(wù)器奕谭，權(quán)威 DNS 服務(wù)器收到請(qǐng)求后涣觉，用 hzfe.org 的 IP 地址進(jìn)行響應(yīng)，完成域名解析血柳。

查詢(xún)通常遵循以上流程官册，從請(qǐng)求主機(jī)到本地 DNS 服務(wù)器的查詢(xún)是遞歸查詢(xún)，DNS 服務(wù)器獲取到所需映射的查詢(xún)過(guò)程是迭代查詢(xún)难捌。

3. 建立 TCP 連接

世界上幾乎所有的 HTTP 通信都是由 TCP/IP 承載的膝宁，TCP/IP 是全球計(jì)算機(jī)及網(wǎng)絡(luò)設(shè)備都在使用的一種常用的分組交換網(wǎng)絡(luò)分層鸦难。HTTP 的連接實(shí)際上就是 TCP 連接以及其使用規(guī)則。–《HTTP 權(quán)威指南》

當(dāng)瀏覽器獲取到服務(wù)器的 IP 地址后员淫，瀏覽器會(huì)用一個(gè)隨機(jī)的端口（1024 < 端口 < 65535）向服務(wù)器 80 端口發(fā)起 TCP 連接請(qǐng)求（注：HTTP 默認(rèn)約定 80 端口明刷，HTTPS 為 443 端口）。這個(gè)連接請(qǐng)求到達(dá)服務(wù)端后满粗，通過(guò) TCP 三次握手，建立 TCP 的連接愚争。

3.1 分層模型

????----------------------------------
??7|???應(yīng)用層???|???????????|???HTTP??|

??6|???表示層???|???應(yīng)用層???|

??5|???會(huì)話層???|???????????|?????????|
????---------------------------------
??4|???傳輸層???|???傳輸層???|?TCP?TLS?|
????---------------------------------
??3|???網(wǎng)絡(luò)層???|???網(wǎng)絡(luò)層???|???IP????|
????---------------------------------
??2|??數(shù)據(jù)鏈路層
???????????????|???鏈路層
??1|???物理層
????--------------------------------
???????[OSI]???|???[TCP/IP]

3.2 TCP 三次握手

#?SYN?是建立連接時(shí)的握手信號(hào)映皆，TCP?中發(fā)送第一個(gè)?SYN?包的為客戶端，接收的為服務(wù)端
# TCP 中轰枝，當(dāng)發(fā)送端數(shù)據(jù)到達(dá)接收端時(shí)捅彻，接收端返回一個(gè)已收到消息的通知。這個(gè)消息叫做確認(rèn)應(yīng)答 ACK

??假設(shè)有客戶端A鞍陨，服務(wù)端B步淹。我們要建立可靠的數(shù)據(jù)傳輸。
??????SYN(=j)???????//?SYN:?A?請(qǐng)求建立連接
??A?---------->?B
????????????????|
?????ACK(=j+1)??|???//?ACK:?B?確認(rèn)應(yīng)答?A?的?SYN
?????SYN(=k)????|???//?SYN:?B?發(fā)送一個(gè)?SYN
??A?<-----------
??|
??|??ACK(=k+1)
???----------->?B???//?ACK:?A?確認(rèn)應(yīng)答?B?的包

1. 客戶端發(fā)送 SYN 包（seq = j）到服務(wù)器诚撵，并進(jìn)入 SYN_SEND 狀態(tài)缭裆，等待服務(wù)器確認(rèn)。
2. 服務(wù)器收到 SYN 包寿烟，必須確認(rèn)客戶的 SYN（ACK = k + 1）澈驼，同時(shí)自己也發(fā)送一個(gè) SYN 包（seq = k），即 SYN+ACK 包筛武，此時(shí)服務(wù)器進(jìn)入 SYN_RECV 狀態(tài)缝其。
3. 客戶端收到服務(wù)器的 SYN+ACK 包，向服務(wù)器發(fā)送確認(rèn)包 ACK（ACK = k + 1）徘六，此包發(fā)送完畢内边，客戶端和服務(wù)器進(jìn)入 ESTABLISHED 狀態(tài)，完成三次握手待锈。

4. TLS 協(xié)商

建立連接后就可以通過(guò) HTTP 進(jìn)行數(shù)據(jù)傳輸漠其。如果使用 HTTPS，會(huì)在 TCP 與 HTTP 之間多添加一層協(xié)議做加密及認(rèn)證的服務(wù)竿音。HTTPS 使用 SSL（Secure Socket Layer） 和 TLS（Transport Layer Security） 協(xié)議辉懒，保障了信息的安全。

• SSL

• 認(rèn)證用戶和服務(wù)器谍失，確保數(shù)據(jù)發(fā)送到正確的客戶端和服務(wù)器眶俩。
• 加密數(shù)據(jù)防止數(shù)據(jù)中途被竊取。
• 維護(hù)數(shù)據(jù)的完整性快鱼，確保數(shù)據(jù)在傳輸過(guò)程中不被改變颠印。

• TLS

• 用于在兩個(gè)通信應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性纲岭。該協(xié)議由兩層組成：TLS 記錄協(xié)議（TLS Record）和 TLS 握手協(xié)議（TLS Handshake）。較低的層為 TLS 記錄協(xié)議线罕，位于某個(gè)可靠的傳輸協(xié)議（例如 TCP）上面止潮。

4.1 TLS 握手協(xié)議

1. 客戶端發(fā)出一個(gè) client hello 消息，攜帶的信息包括：所支持的 SSL/TLS 版本列表钞楼；支持的與加密算法喇闸；所支持的數(shù)據(jù)壓縮方法；隨機(jī)數(shù) A询件。
2. 服務(wù)端響應(yīng)一個(gè) server hello 消息燃乍，攜帶的信息包括：協(xié)商采用的 SSL/TLS 版本號(hào)；會(huì)話 ID宛琅；隨機(jī)數(shù) B刻蟹；服務(wù)端數(shù)字證書(shū) serverCA；由于雙向認(rèn)證需求嘿辟，服務(wù)端需要對(duì)客戶端進(jìn)行認(rèn)證舆瘪，會(huì)同時(shí)發(fā)送一個(gè) client certificate request，表示請(qǐng)求客戶端的證書(shū)红伦。
3. 客戶端校驗(yàn)服務(wù)端的數(shù)字證書(shū)英古；校驗(yàn)通過(guò)之后發(fā)送隨機(jī)數(shù) C，該隨機(jī)數(shù)稱(chēng)為 pre-master-key昙读，使用數(shù)字證書(shū)中的公鑰加密后發(fā)出哺呜；由于服務(wù)端發(fā)起了 client certificate request，客戶端使用私鑰加密一個(gè)隨機(jī)數(shù) clientRandom 隨客戶端的證書(shū) clientCA 一并發(fā)出箕戳。
4. 服務(wù)端校驗(yàn)客戶端的證書(shū)某残，并成功將客戶端加密的隨機(jī)數(shù) clientRandom 解密；根據(jù)隨機(jī)數(shù) A/隨機(jī)數(shù) B/隨機(jī)數(shù) C（pre-master-key） 產(chǎn)生動(dòng)態(tài)密鑰 master-key陵吸，加密一個(gè) finish 消息發(fā)至客戶端玻墅。
5. 客戶端根據(jù)同樣的隨機(jī)數(shù)和算法生成 master-key，加密一個(gè) finish 消息發(fā)送至服務(wù)端壮虫。
6. 服務(wù)端和客戶端分別解密成功澳厢，至此握手完成，之后的數(shù)據(jù)包均采用 master-key 進(jìn)行加密傳輸囚似。

5. 服務(wù)器響應(yīng)

當(dāng)瀏覽器到 web 服務(wù)器的連接建立后剩拢，瀏覽器會(huì)發(fā)送一個(gè)初始的 HTTP GET 請(qǐng)求，請(qǐng)求目標(biāo)通常是一個(gè) HTML 文件饶唤。服務(wù)器收到請(qǐng)求后徐伐，將發(fā)回一個(gè) HTTP 響應(yīng)報(bào)文，內(nèi)容包括相關(guān)響應(yīng)頭和 HTML 正文募狂。

<html>
?<head>
??<meta?charset="UTF-8"/>
??<title>我的博客</title>
??<link?rel="stylesheet"?src="styles.css"/>
??<scrIPt?src="index.js"></scrIPt>
</head>
<body>
??<h1?class="heading">首頁(yè)</h1>
??<p>A?paragraph?with?a?<a?></scrIPt>
</body>
</html>

5.1 狀態(tài)碼

狀態(tài)碼是由 3 位數(shù)組成办素，第一個(gè)數(shù)字定義了響應(yīng)的類(lèi)別角雷，且有五類(lèi)可能取值

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

5.2 常見(jiàn)的請(qǐng)求頭和字段

• Cache-Control：must-revalidate、no-cache需曾、private（是否需要緩存資源）
• Connection：keep-alive（保持連接）
• Content-Encoding：gzip（web 服務(wù)器支持的返回內(nèi)容壓縮編碼類(lèi)型）
• Content-Type：text/html吗坚；charset=UTF-8（文件類(lèi)型和字符編碼格式）
• Date：Sun， 21 Sep 2021 06:18:21 GMT（服務(wù)器消息發(fā)出的時(shí)間）
• Transfer-Encoding：chunked（服務(wù)器發(fā)送的資源的方式是分塊發(fā)送）

5.3 HTTP 響應(yīng)報(bào)文

響應(yīng)報(bào)文由四部分組成（響應(yīng)行 + 響應(yīng)頭 + 空行 + 響應(yīng)體）

• 狀態(tài)行：HTTP 版本 + 空格 + 狀態(tài)碼 + 空格 + 狀態(tài)碼描述 + 回車(chē)符（CR） + 換行符（LF）
• 響應(yīng)頭：字段名 + 冒號(hào) + 值 + 回車(chē)符 + 換行符
• 空行：回車(chē)符 + 換行符
• 響應(yīng)體：由用戶自定義添加呆万，如 post 的 body 等

6. 瀏覽器解析并繪制

不同的瀏覽器引擎渲染過(guò)程都不太一樣商源，這里以 Chrome 瀏覽器渲染方式為例。

1. 處理 HTML 標(biāo)記并構(gòu)建 DOM 樹(shù)桑嘶。
2. 處理 CSS 標(biāo)記并構(gòu)建 CSSOM 樹(shù)。
3. 將 DOM 與 CSSOM 合并成一個(gè)渲染樹(shù)躬充。
4. 根據(jù)渲染樹(shù)來(lái)布局逃顶，以計(jì)算每個(gè)節(jié)點(diǎn)的幾何信息。
5. 將各個(gè)節(jié)點(diǎn)繪制到屏幕上充甚。

7. TCP 斷開(kāi)連接

現(xiàn)在的頁(yè)面為了優(yōu)化請(qǐng)求的耗時(shí)以政，默認(rèn)都會(huì)開(kāi)啟持久連接（keep-alive），那么一個(gè) TCP 連接確切關(guān)閉的時(shí)機(jī)伴找，是這個(gè) tab 標(biāo)簽頁(yè)關(guān)閉的時(shí)候盈蛮。這個(gè)關(guān)閉的過(guò)程就是四次揮手。關(guān)閉是一個(gè)全雙工的過(guò)程技矮，發(fā)包的順序是不一定的抖誉。一般來(lái)說(shuō)是客戶端主動(dòng)發(fā)起的關(guān)閉，過(guò)程如下圖所示：

1. 主動(dòng)關(guān)閉方發(fā)送一個(gè) FIN衰倦，用來(lái)關(guān)閉主動(dòng)方到被動(dòng)關(guān)閉方的數(shù)據(jù)傳送袒炉，也就是主動(dòng)關(guān)閉方告訴被動(dòng)關(guān)閉方：我已經(jīng)不會(huì)再給你發(fā)數(shù)據(jù)了（在 FIN 包之前發(fā)送出去的數(shù)據(jù)，如果沒(méi)有收到對(duì)應(yīng)的 ACK 確認(rèn)報(bào)文樊零，主動(dòng)關(guān)閉方依然會(huì)重發(fā)這些數(shù)據(jù)）我磁，但此時(shí)主動(dòng)關(guān)閉方還可以接受數(shù)據(jù)。
2. 被動(dòng)關(guān)閉方收到 FIN 包后驻襟，發(fā)送一個(gè) ACK 給對(duì)方夺艰，確認(rèn)序號(hào)為收到序號(hào)+1（與 SYN 相同，一個(gè) FIN 占用一個(gè)序號(hào)）沉衣。
3. 被動(dòng)關(guān)閉方發(fā)送一個(gè) FIN郁副，用來(lái)關(guān)閉被動(dòng)關(guān)閉方到主動(dòng)關(guān)閉方的數(shù)據(jù)傳送，也就是告訴主動(dòng)關(guān)閉方豌习，我的數(shù)據(jù)也發(fā)送完了霞势，不會(huì)再給你發(fā)數(shù)據(jù)了烹植。
4. 主動(dòng)關(guān)閉方收到 FIN 后，發(fā)送一個(gè) ACK 給被動(dòng)關(guān)閉方愕贡，確認(rèn)序號(hào)為收到序號(hào)+1草雕，至此，完成四次揮手固以。

參考資料

1. How_browsers_work
2. DOMTokenList
3. 圖解 SSL/TLS 協(xié)議
4. DNS 域名系統(tǒng)