一文串聯(lián) HTTP、TCP、IP、以太網(wǎng)
本文轉(zhuǎn)載自微信公眾號(hào)「前端日志」，作者孟思行 。轉(zhuǎn)載本文請(qǐng)聯(lián)系前端日志公眾號(hào)。
最近部門(mén)組織了一次前端性能優(yōu)化交流會(huì)，大家從輸入頁(yè)面 URL 到最終頁(yè)面展示內(nèi)容這個(gè)過(guò)程提出了許多優(yōu)化點(diǎn)。但同時(shí)發(fā)現(xiàn)很多同學(xué)對(duì) HTTP 協(xié)議層的知識(shí)不能串聯(lián)起來(lái)，于是整理了這篇文章，希望可以給大家?guī)?lái)一絲靈感。
當(dāng)我們?cè)陧?yè)面上發(fā)起一個(gè) AJAX 請(qǐng)求的時(shí)候，在網(wǎng)絡(luò)協(xié)議層面都經(jīng)歷了哪些內(nèi)容?
- // 發(fā)起請(qǐng)求
- fetch('https://baidu.com')
- // 協(xié)議層1...
- // 協(xié)議層2...
- // 協(xié)議層3...
- .then(res=>
- // 得到結(jié)果
- console.log(res)
- })
如上述代碼所示，我們對(duì) baidu.com 發(fā)起了一個(gè)網(wǎng)絡(luò)請(qǐng)求，最終在 then 方法中得到了具體的響應(yīng)內(nèi)容。
使用 Wireshark 抓包結(jié)果如下：
圖中可以看到，請(qǐng)求 baidu.com 時(shí)，首先通過(guò) TCP 3 次握手建立連接，然后通過(guò) HTTP 傳輸內(nèi)容，最后通過(guò) TCP 4 次揮手?jǐn)嚅_(kāi)連接。
真實(shí)的過(guò)程更加復(fù)雜，我們主要分析以下幾點(diǎn)：
- 建立連接階段
- 通過(guò) IP 尋址找到目標(biāo)服務(wù)器(網(wǎng)絡(luò)層)
- 通過(guò) Mac 尋址找到服務(wù)器硬件接口(數(shù)據(jù)鏈路層)
- 通過(guò)網(wǎng)線向服務(wù)器硬件接口傳輸比特信息(物理層)
- DNS 域名解析(應(yīng)用層)
- 建立 TCP 連接(傳輸層)
- 發(fā)送數(shù)據(jù)階段
- 建立 SSL 安全連接(應(yīng)用層)
- 發(fā)送 HTTP 請(qǐng)求(應(yīng)用層)
建立連接階段
要獲取 baidu.com 的網(wǎng)頁(yè)內(nèi)容，就需要和 baidu 服務(wù)器建立連接，怎樣建立這個(gè)連接呢?
- 通過(guò) DNS 獲取 baidu 的 IP 地址。
- 建立 TCP 連接。
DNS 域名解析
通過(guò) DNS 解析，我們就能找到 baidu 服務(wù)器對(duì)應(yīng)的 IP 地址。
如圖：
經(jīng)過(guò) DNS 解析后，我們就能得到 baidu.com 的 IP 地址了：39.156.69.79 和 220.181.38.148，通?？蛻舳藭?huì)隨機(jī)選中一個(gè) IP 地址進(jìn)行通信。
域名的解析步驟
其實(shí) IP 不一定要通過(guò) DNS 解析才能獲取，它通常會(huì)被客戶端緩存，只有在 DNS 緩存都沒(méi)有命中的時(shí)候才會(huì)請(qǐng)求 DNS 服務(wù)器。
判斷步驟如下：
- 判斷瀏覽器是否有緩存 IP 地址。
- 判斷本機(jī)是否有緩存該 IP 地址，如：檢查 Host 文件。
- 判斷本地域名解析服務(wù)器是否有緩存 IP 地址，如：電信，聯(lián)通等運(yùn)營(yíng)商。
- 向 DNS 根域名解析服務(wù)器，解析域名 IP 地址。
- 向 DNS 二根域名解析服務(wù)器，解析域名 IP 地址。
- 以此類推，最終獲得 IP 地址。
建立 TCP 連接
有了 IP 地址之后，客戶端和服務(wù)器端就能建立連接了，首先是建立 TCP 連接。
TCP 是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。
在這一層，我們傳輸?shù)臄?shù)據(jù)會(huì)按照一個(gè)個(gè)的字節(jié)裝入報(bào)文中，當(dāng)報(bào)文的長(zhǎng)度達(dá)到最大分段(MSS)時(shí)，就會(huì)發(fā)送這個(gè)報(bào)文。如果傳輸?shù)膱?bào)文很長(zhǎng)，可能會(huì)被拆分成多個(gè) TCP 報(bào)文進(jìn)行傳輸。
TCP 報(bào)文頭如下：
我們主要看以下幾點(diǎn)：
- 源端口、目的端口。
- 序列號(hào)：seq，報(bào)文的唯一標(biāo)識(shí)。
- 確認(rèn)號(hào)：ack，報(bào)文的確認(rèn)標(biāo)識(shí)，便于確認(rèn) seq 是否已經(jīng)收到。
- TCP 標(biāo)記：
- SYN 為 1 表示這是連接請(qǐng)求或是連接接受請(qǐng)求。用于創(chuàng)建連接和同步序列號(hào)。
- ACK 為 1 表示確認(rèn)號(hào)字段有效。注意這里大寫(xiě)的 ACK 只是一個(gè)標(biāo)記，和確認(rèn)號(hào) ack 并不相同。
- FIN 為 1 表示要求釋放連接。
- 窗口：表示發(fā)送方可以接收的字節(jié)數(shù)，即接收窗口大小，用于流量控制。
接下來(lái)，我們看一下 TCP 是怎樣建立連接的?
如圖所示，建立 TCP 連接需要 3 個(gè)步驟，俗稱三次握手。
- 第一次握手：客戶端向服務(wù)器端發(fā)送序列號(hào) seq=x 的標(biāo)識(shí)，表示開(kāi)始建立連接。
- 第二次握手：服務(wù)器端回發(fā)一個(gè) ack=x+1 的標(biāo)識(shí)，表示確認(rèn)收到第一次握手，同時(shí)發(fā)送自己的標(biāo)識(shí) seq=y。
- 客戶端確認(rèn)自己發(fā)出的數(shù)據(jù)能夠被服務(wù)器端收到。
- 第三次握手：客戶端發(fā)送 ack=y+1 的標(biāo)識(shí)，標(biāo)識(shí)確認(rèn)收到第二次握手。
- 服務(wù)器端確認(rèn)自己發(fā)出的數(shù)據(jù)能夠被客戶端收到。
經(jīng)過(guò)了 3 次握手，即保證了客戶端和服務(wù)器端都能正常發(fā)送和接收數(shù)據(jù)，TCP 連接也就建立成功了。
TCP 可靠傳輸原理
上文中說(shuō)到，TCP 是可靠的傳輸，這是為什么呢?
這是因?yàn)?TCP 內(nèi)部使用了 停止等待協(xié)議 ARQ ，它通過(guò) 確認(rèn) 和 重傳 機(jī)制，實(shí)現(xiàn)了信息的可靠傳輸。
例如：
- 客戶端發(fā)送數(shù)據(jù) M1
- 服務(wù)器端確認(rèn)數(shù)據(jù) M1 收到
- 客戶端發(fā)送數(shù)據(jù) M2
- 服務(wù)器端確認(rèn)數(shù)據(jù) M2 收到
- 依次類推 ...
在這期間，如果某一條數(shù)據(jù)很久都沒(méi)有得到確認(rèn)，客戶端就會(huì)重傳這條數(shù)據(jù)。這樣一來(lái)，對(duì)于與每一次發(fā)送的數(shù)據(jù)，服務(wù)器端都得到了確認(rèn)，即保證了數(shù)據(jù)的可靠性。
雖然 ARQ 可以滿足數(shù)據(jù)可靠性，但每次只能發(fā)送和確認(rèn)一個(gè)請(qǐng)求，效率太低了，于是就產(chǎn)生了連續(xù) ARQ 協(xié)議。
連續(xù) ARQ 協(xié)議 會(huì)連續(xù)發(fā)送一組數(shù)據(jù)，然后再批量等待這一組數(shù)據(jù)的確認(rèn)信息，好比把單線程 ARQ 變成了多線程，大大提高了資源的利用效率。
如：
- 客戶端發(fā)送數(shù)據(jù) M1、M2、M3、M4。
- 服務(wù)器端確認(rèn)數(shù)據(jù) M4 收到，表示 M4 及之前的數(shù)據(jù)都收到了。
- 客戶端發(fā)送數(shù)據(jù) M5、M6、M7、M8。
- 服務(wù)器端確認(rèn)數(shù)據(jù) M8 收到，表示 M8 及之前的數(shù)據(jù)都收到了。
在這個(gè)流程中，服務(wù)器端不需要對(duì)每一個(gè)數(shù)據(jù)都返回確認(rèn)信息，而是接收到多個(gè)數(shù)據(jù)時(shí)一并確認(rèn)，這個(gè)方式叫做 累計(jì)確認(rèn)。
這里有個(gè)疑問(wèn)，TCP 的每一次握手，是怎么找到目的服務(wù)器呢?
答：通過(guò) IP 協(xié)議。
根據(jù) IP 協(xié)議找到目標(biāo)服務(wù)器
IP 協(xié)議的目的是實(shí)現(xiàn)網(wǎng)絡(luò)層的數(shù)據(jù)轉(zhuǎn)發(fā)，它通過(guò)路由器不斷跳轉(zhuǎn)，最終把數(shù)據(jù)成功送達(dá)目的地。
上文中的每一次 TCP 握手以及數(shù)據(jù)交互，都是通過(guò) IP 協(xié)議去傳輸?shù)摹?/p>
IP 報(bào)文頭如下：
我們關(guān)注以下兩點(diǎn)就可以了：
- 源 IP 地址
- 目的 IP 地址
發(fā)起一個(gè) IP 請(qǐng)求執(zhí)行流程如下：
- 構(gòu)建 IP 請(qǐng)求頭(源 IP、目標(biāo) IP)。
- IP 協(xié)議通過(guò)算法，計(jì)算出一條通往服務(wù)器端的路徑。
- 發(fā)送端查詢路由表，找出下一跳的 IP 地址(通常是路由器)，并發(fā)送數(shù)據(jù)。
- 路由器查詢路由表，找出下一跳的 IP 地址，并發(fā)送數(shù)據(jù)。
- 不斷重復(fù)步驟 4，直到找到目的局域網(wǎng)。
- 發(fā)送數(shù)據(jù)。
路由表存在于計(jì)算機(jī)或路由器中，由目的 IP 地址、子網(wǎng)掩碼、下一跳地址、發(fā)送接口四部分組成。通過(guò)目的 IP 地址，即可找到下一跳的地址，進(jìn)行轉(zhuǎn)發(fā)。
例如：A 要向 G 發(fā)送 IP 數(shù)據(jù)。
具體流程如下：
- A 生成 IP 頭部(源 IP：A ，目的 IP：G)
A 查詢路由表，發(fā)現(xiàn)下一跳為 B，于是把數(shù)據(jù)傳給 B。
- B 生成 IP 頭部(源 IP：A ，目的 IP：G)
B 查詢路由表，發(fā)現(xiàn)下一跳為 E，于是把數(shù)據(jù)傳給 E。
- E 生成 IP 頭部(源 IP：A ，目的 IP：G)
E 查詢路由表，發(fā)現(xiàn)下一跳為 G，于是把數(shù)據(jù)傳給 G。
- 到達(dá)目的地 G。
你是否有疑惑，為什么 IP 會(huì)按照這條路徑向 G 傳輸數(shù)據(jù)呢?
其實(shí)，上圖中的路徑并非只有一條，我們通過(guò) ABEG 到達(dá)了目的地 G，同樣也可以通過(guò) ABCFHG 到達(dá) G，這兩種路徑都能完成任務(wù)，為什么 IP 不選擇 ABCFHG 這條路徑呢?
這就涉及到了 IP 尋址的算法。
IP 尋址算法
我們可以把網(wǎng)絡(luò)中的所有計(jì)算機(jī)都看做是一個(gè)點(diǎn)，計(jì)算機(jī)之間的連接看做是一條線，這些點(diǎn)和線就組合成了一個(gè)圖。
例如：
通過(guò)上圖，我們就把復(fù)雜的網(wǎng)絡(luò)轉(zhuǎn)化成了數(shù)學(xué)問(wèn)題。IP 尋址算法，其實(shí)就是圖論中的最短路徑的算法。
最短路徑算法在 IP 協(xié)議中有 2 種實(shí)現(xiàn)：
- RIP 協(xié)議
- 每個(gè)節(jié)點(diǎn)中都保存有其他節(jié)點(diǎn)的位置信息(跳數(shù)和下一跳的 IP)。
- 通過(guò)和鄰居節(jié)點(diǎn)進(jìn)行數(shù)據(jù)交換，更新自己到目的地的最短距離，不斷重復(fù)，即可得到起點(diǎn)到終點(diǎn)的最短路徑。
- 實(shí)現(xiàn)簡(jiǎn)單，開(kāi)銷很小，適用于小型網(wǎng)絡(luò)。
- 使用距離矢量算法，確保 IP 路由跳轉(zhuǎn)的次數(shù)最小。
- 原理
- OSPF 協(xié)議
- 從起始點(diǎn)開(kāi)始，采用貪心算法的策略，每次遍歷到始點(diǎn)距離最近且未訪問(wèn)過(guò)的頂點(diǎn)的鄰接節(jié)點(diǎn)，直到擴(kuò)展到終點(diǎn)為止。
- 適用于大型網(wǎng)絡(luò)。
- 使用迪杰斯特拉算法，確保 IP 路由跳轉(zhuǎn)的速度最快。
- 原理
通過(guò)以上兩個(gè)協(xié)議，我們就能找到通往目的地的路徑了。
這里拋出一個(gè)問(wèn)題：IP 數(shù)據(jù)是怎樣從一個(gè)路由器跳到另一個(gè)路由器呢?
答：通過(guò)以太網(wǎng)協(xié)議。
通過(guò) Mac 尋址找到服務(wù)器硬件接口
IP 協(xié)議主要是用來(lái)尋找最優(yōu)路徑的，具體的傳輸是由以太網(wǎng)協(xié)議來(lái)做的。
以太網(wǎng)屬于數(shù)據(jù)鏈路層，它主要負(fù)責(zé)相鄰設(shè)備的通信。原理是通過(guò)查詢交換機(jī) Mac 表，找到通信雙方的物理接口，進(jìn)而開(kāi)始通信。
以太網(wǎng)報(bào)文頭如下：
我們只用關(guān)心以下 3 個(gè)點(diǎn)：
- 源 Mac 地址
- 目的 Mac 地址
- 校驗(yàn)碼 CRC：校驗(yàn)當(dāng)前幀是否有效。
可以看到，以太網(wǎng)層都是通過(guò) Mac 地址進(jìn)行通信的，這里的 Mac 地址是哪里來(lái)的呢?
答：通過(guò) ARP 協(xié)議。
ARP 協(xié)議 是一個(gè)通過(guò)解析 IP 地址來(lái)找尋 Mac 地址的協(xié)議。IP 地址轉(zhuǎn)換成 Mac 地址后，就能進(jìn)行以太網(wǎng)數(shù)據(jù)傳輸了。
例如：
當(dāng)機(jī)器 A 向機(jī)器 C 發(fā)送數(shù)據(jù)時(shí)：
- A 構(gòu)建以太網(wǎng)報(bào)文(源地址：A，目的地址：C)，并通過(guò)網(wǎng)卡發(fā)出數(shù)據(jù)幀。
- 數(shù)據(jù)幀到達(dá)交換機(jī) B，交換機(jī)取出目的地址 C 的 Mac 地址。
- B 查詢 Mac 表，根據(jù)目的地 Mac 地址，匹配 C 的硬件接口。
- 如果找到 C 的硬件接口，發(fā)送數(shù)據(jù)。
- 如果未找到 C 的硬件接口，向 B 直連的所有機(jī)器發(fā)送廣播信息找 C，找到后會(huì)把 C 記錄到 Mac 表中。
經(jīng)過(guò)上述的流程，我們就找到了目的機(jī)器的硬件接口。
通過(guò)以太網(wǎng)協(xié)議，我們找到了目標(biāo)機(jī)器的硬件接口，接下來(lái)要怎么發(fā)送信息呢?
答：通過(guò)物理層。
通過(guò)網(wǎng)線向服務(wù)器硬件接口傳輸比特信息
在沒(méi)有 WiFi 的年代，我們只能通過(guò)插網(wǎng)線來(lái)進(jìn)行上網(wǎng)，網(wǎng)線其實(shí)就是物理層的設(shè)備之一。
網(wǎng)線可以由多種材料組成，最常見(jiàn)的就是光纖和電纜。
光纖和電纜的傳輸原理類似，都是通過(guò)兩個(gè)信號(hào)來(lái)模擬二進(jìn)制數(shù)據(jù)的，一個(gè)信號(hào)即為一個(gè)比特。
- 電纜中：高電位表示 1 ，低點(diǎn)位表示 0。
- 光纖中：光亮表示 1，光熄滅表示 0。
如：在光纖中，我們通過(guò)觀察光的閃動(dòng)，即可得知傳輸?shù)亩M(jìn)制數(shù)據(jù)。
有了這些物理設(shè)備，我們就能把復(fù)雜的數(shù)據(jù)轉(zhuǎn)換成光信號(hào)或者電信號(hào)進(jìn)行傳輸了。
發(fā)送數(shù)據(jù)階段
發(fā)送數(shù)據(jù)可以分為兩個(gè)步驟：
- 建立安全層 SSL
- 發(fā)送 HTTP 請(qǐng)求
建立安全層 SSL
本文的案例是發(fā)送一個(gè) HTTPS 的請(qǐng)求，所以在發(fā)送數(shù)據(jù)之前，會(huì)創(chuàng)建一個(gè) SSL 安全層，用于數(shù)據(jù)加密。
通常的加密方法有兩種：
- 非對(duì)稱加密
- A 有鑰匙，B 沒(méi)有鑰匙，且他們都有一個(gè)公共的鎖，B 給 A 發(fā)送數(shù)據(jù)時(shí)，都會(huì)先把數(shù)據(jù)鎖起來(lái)再發(fā)送。
- 接收數(shù)據(jù)時(shí)，A 用鑰匙解開(kāi)鎖，即可得到數(shù)據(jù)。除 A 以外，其他人沒(méi)有鑰匙，也就獲取不到數(shù)據(jù)。
- 實(shí)現(xiàn)了單向通信加密。
- 對(duì)稱加密
- A、B 雙方都有一把相同的鑰匙和一個(gè)公共的鎖，每次發(fā)送數(shù)據(jù)時(shí)，都把數(shù)據(jù)放在鎖里進(jìn)行發(fā)送。
- 接收數(shù)據(jù)時(shí)，A、B 雙方就用各自的鑰匙來(lái)解鎖。其他人沒(méi)有鑰匙，也就獲取不到數(shù)據(jù)。
- 實(shí)現(xiàn)了雙向通信加密。
互聯(lián)網(wǎng)通信是雙向的，所以我們需要使用對(duì)稱加密，可是，怎樣才能保證通信雙方都有一把相同的鑰匙呢?
目前的解決方案：
- 先使用非對(duì)稱加密，進(jìn)行秘鑰協(xié)商，讓通信雙方拿到相同的鑰匙。
- 然后使用對(duì)稱加密，進(jìn)行加密傳輸。
秘鑰協(xié)商過(guò)程如圖：
圖中劃重點(diǎn)：
- 客戶端發(fā)送自身支持的加密算法。
- 服務(wù)器端選擇一種加密算法，同時(shí)返回?cái)?shù)字證書(shū)。
- 客戶端確認(rèn)證書(shū)有效。
- 客戶端生成隨機(jī)數(shù)，并使用證書(shū)中的服務(wù)器公鑰加密，然后發(fā)送給服務(wù)器。
- 服務(wù)器端使用私鑰解密，獲得隨機(jī)數(shù)。
- 雙方使用第 2 步確定的加密算法，把隨機(jī)數(shù)進(jìn)行加密，即可獲得相同的對(duì)稱加密秘鑰。
Ok，秘鑰協(xié)商之后，我們的 SSL 安全層也就建好了。
秘鑰協(xié)商時(shí)存在一個(gè)問(wèn)題：
秘鑰協(xié)商時(shí)，怎么保證是和真正的服務(wù)器在協(xié)商，而不是一個(gè)中間人呢?
答：數(shù)字證書(shū)。
數(shù)字證書(shū)重點(diǎn)關(guān)注 2 個(gè)部分：
- 服務(wù)器公鑰
- 數(shù)字簽名
其中，數(shù)字簽名又是由服務(wù)器公鑰和證書(shū)私鑰加密生成的，目的是為了防止服務(wù)器公鑰被篡改。
有了數(shù)字證書(shū)，客戶端就能通過(guò)驗(yàn)證證書(shū)，來(lái)判斷服務(wù)器是否是真正的服務(wù)器了。
驗(yàn)證邏輯如下：
可以看到，數(shù)字證書(shū)通過(guò)同樣的算法進(jìn)行解密，如果得到相同的信息摘要，就能保證數(shù)據(jù)是有效的，如果不一致，則會(huì)驗(yàn)證失敗，拒絕后續(xù)的請(qǐng)求。
到這里為止，所有的準(zhǔn)備工作都就緒了，接下來(lái)才是發(fā)送 HTTP 請(qǐng)求。
發(fā)送 HTTP 請(qǐng)求
HTTP 協(xié)議其實(shí)就是制定了一個(gè)通信規(guī)則，規(guī)定了客戶端和服務(wù)器之間的通信格式。
以請(qǐng)求 baidu 首頁(yè)為例：
如上圖所示，發(fā)起 HTTP 請(qǐng)求時(shí)，必須遵守以下規(guī)則：
- 請(qǐng)求方法(必填) GET
- 請(qǐng)求地址(必填) /
- HTTP 協(xié)議版本(必填) 1.1
- 其他 HTTP 頭部字段(可選) Host、User-Agent、Accept
- 請(qǐng)求參數(shù)，放在空行后面(可選)
服務(wù)器響應(yīng)請(qǐng)求時(shí)，同樣遵守了 HTTP 響應(yīng)規(guī)則：
- HTTP 協(xié)議版本(必填) 1.1
- 響應(yīng)狀態(tài)碼(必填) 200
- 狀態(tài)碼描述(必填) OK
- 其他 HTTP 頭部字段(可選) Date、Server、ETag、Last-Modified 等
- 請(qǐng)求參數(shù)，放在空行后面(可選)
只要我們遵守這個(gè)規(guī)則，就能進(jìn)行 HTTP 通信了。
到目前為止，我們已經(jīng)分析完成了數(shù)據(jù)請(qǐng)求的所有過(guò)程，你是否都理解了呢?
思考與總結(jié)
本文通過(guò)一個(gè)網(wǎng)絡(luò)請(qǐng)求，對(duì)整個(gè) HTTP、TCP、IP、以太網(wǎng)等協(xié)議進(jìn)行了流程化分析，最后再梳理一下：
- 請(qǐng)求 baidu.com。
- DNS 解析 baidu.com，得到 IP 地址。
- 建立 TCP 連接。
- IP 協(xié)議通過(guò)算法，計(jì)算出一條通往服務(wù)器最優(yōu)路徑。
- IP 沿著路徑跳轉(zhuǎn)時(shí)，會(huì)通過(guò) ARP 協(xié)議把 IP 地址轉(zhuǎn)換成 Mac 地址。
- 以太網(wǎng)通過(guò) Mac 地址，找到通信雙方的硬件接口。
- 物理層通過(guò)網(wǎng)線作為載體，在兩個(gè)硬件接口之間傳輸比特信號(hào)。
- TCP 連接建立完畢。
- 建立 SSL 安全層。
- 發(fā)送 HTTP 請(qǐng)求。
