最近部門組織了一次前端性能優(yōu)化交流會，大家從輸入頁面 URL 到最終頁面展示內(nèi)容這個過程提出了許多優(yōu)化點。但同時發(fā)現(xiàn)很多同學(xué)對 HTTP 協(xié)議層的知識不能串聯(lián)起來，于是整理了這篇文章，希望可以給大家?guī)硪唤z靈感。

當(dāng)我們在頁面上發(fā)起一個 AJAX 請求的時候，在網(wǎng)絡(luò)協(xié)議層面都經(jīng)歷了哪些內(nèi)容？

如上述代碼所示，我們對?baidu.com?發(fā)起了一個網(wǎng)絡(luò)請求，最終在 then 方法中得到了具體的響應(yīng)內(nèi)容。

使用 Wireshark 抓包結(jié)果如下：

?

圖中可以看到，請求 baidu.com 時，首先通過TCP 3次握手建立連接，然后通過 HTTP 傳輸內(nèi)容，最后通過 TCP 4 次揮手?jǐn)嚅_連接。

真實的過程更加復(fù)雜，我們主要分析以下幾點：

一、建立連接階段

要獲取baidu.com的網(wǎng)頁內(nèi)容，就需要和baidu服務(wù)器建立連接，怎樣建立這個連接呢？

1、DNS 域名解析

通過 DNS 解析，我們就能找到 baidu 服務(wù)器對應(yīng)的 IP 地址。如圖：

?

經(jīng)過 DNS 解析后，我們就能得到 baidu.com 的 IP 地址了：39.156.69.79 和 220.181.38.148，通常客戶端會隨機選中一個 IP 地址進行通信。

其實 IP 不一定要通過 DNS 解析才能獲取，它通常會被客戶端緩存，只有在 DNS 緩存都沒有命中的時候才會請求 DNS 服務(wù)器。

判斷步驟如下：

• 判斷瀏覽器是否有緩存 IP 地址。
• 判斷本機是否有緩存該 IP 地址，如：檢查 Host 文件。
• 判斷本地域名解析服務(wù)器是否有緩存 IP 地址，如：電信，聯(lián)通等運營商。
• 向 DNS 根域名解析服務(wù)器，解析域名 IP 地址。
• 向 DNS 二根域名解析服務(wù)器，解析域名 IP 地址。
• 以此類推，最終獲得 IP 地址。

2、建立 TCP 連接

有了 IP 地址之后，客戶端和服務(wù)器端就能建立連接了，首先是建立 TCP 連接。TCP 是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。

在這一層，我們傳輸?shù)臄?shù)據(jù)會按照一個個的字節(jié)裝入報文中，當(dāng)報文的長度達到最大分段（MSS）時，就會發(fā)送這個報文。如果傳輸?shù)膱笪暮荛L，可能會被拆分成多個 TCP 報文進行傳輸。TCP 報文頭如下：

?

我們主要看以下幾點：

• 源端口、目的端口。
• 序列號：seq，報文的唯一標(biāo)識。
• 確認(rèn)號：ack，報文的確認(rèn)標(biāo)識，便于確認(rèn) seq 是否已經(jīng)收到。
• TCP 標(biāo)記：SYN 、ACK、FIN
• 窗口：表示發(fā)送方可以接收的字節(jié)數(shù)，即接收窗口大小，用于流量控制。

接下來，我們看一下 TCP 是怎樣建立連接的？

?

如圖所示，建立 TCP 連接需要 3 個步驟，俗稱三次握手。

• 第一次握手：客戶端向服務(wù)器端發(fā)送序列號 seq=x 的標(biāo)識，表示開始建立連接。
• 第二次握手：服務(wù)器端回發(fā)一個 ack=x+1 的標(biāo)識，表示確認(rèn)收到第一次握手，同時發(fā)送自己的標(biāo)識 seq=y。
• 第三次握手：客戶端發(fā)送 ack=y+1 的標(biāo)識，標(biāo)識確認(rèn)收到第二次握手。

經(jīng)過了 3 次握手，即保證了客戶端和服務(wù)器端都能正常發(fā)送和接收數(shù)據(jù)，TCP 連接也就建立成功了。

二、TCP 可靠傳輸原理

上文中說到，TCP 是可靠的傳輸，這是為什么呢？這是因為 TCP 內(nèi)部使用了停止等待協(xié)議 ARQ?，它通過確認(rèn)和重傳機制，實現(xiàn)了信息的可靠傳輸。例如：

?

• 客戶端發(fā)送數(shù)據(jù) M1
• 服務(wù)器端確認(rèn)數(shù)據(jù) M1 收到
• 客戶端發(fā)送數(shù)據(jù) M2
• 服務(wù)器端確認(rèn)數(shù)據(jù) M2 收到
• 依次類推 …

在這期間，如果某一條數(shù)據(jù)很久都沒有得到確認(rèn)，客戶端就會重傳這條數(shù)據(jù)。這樣一來，對于與每一次發(fā)送的數(shù)據(jù)，服務(wù)器端都得到了確認(rèn)，即保證了數(shù)據(jù)的可靠性。

雖然 ARQ 可以滿足數(shù)據(jù)可靠性，但每次只能發(fā)送和確認(rèn)一個請求，效率太低了，于是就產(chǎn)生了連續(xù) ARQ 協(xié)議。

連續(xù) ARQ 協(xié)議會連續(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ù)都收到了。

在這個流程中，服務(wù)器端不需要對每一個數(shù)據(jù)都返回確認(rèn)信息，而是接收到多個數(shù)據(jù)時一并確認(rèn)，這個方式叫做?累計確認(rèn)。

1、根據(jù) IP 協(xié)議找到目標(biāo)服務(wù)器

這里有個疑問，TCP 的每一次握手，是怎么找到目的服務(wù)器的呢？

答：通過 IP 協(xié)議。

IP 協(xié)議的目的是實現(xiàn)網(wǎng)絡(luò)層的數(shù)據(jù)轉(zhuǎn)發(fā)，它通過路由器不斷跳轉(zhuǎn)，最終把數(shù)據(jù)成功送達目的地。上文中的每一次 TCP 握手以及數(shù)據(jù)交互，都是通過 IP 協(xié)議去傳輸?shù)摹?/p>

IP 報文頭如下：

?

2、IP 尋址算法

我們可以把網(wǎng)絡(luò)中的所有計算機都看做是一個點，計算機之間的連接看做是一條線，這些點和線就組合成了一個圖。例如：

?

通過上圖，我們就把復(fù)雜的網(wǎng)絡(luò)轉(zhuǎn)化成了數(shù)學(xué)問題。IP 尋址算法，其實就是圖論中的最短路徑的算法。

最短路徑算法在 IP 協(xié)議中有 2 種實現(xiàn)：

• RIP 協(xié)議：使用距離矢量算法，確保 IP 路由跳轉(zhuǎn)的次數(shù)最小。
• OSPF 協(xié)議：使用迪杰斯特拉算法，確保 IP 路由跳轉(zhuǎn)的速度最快。

通過以上兩個協(xié)議，我們就能找到通往目的地的路徑了。

3、以太網(wǎng)協(xié)議

這里拋出一個問題：IP 數(shù)據(jù)是怎樣從一個路由器跳到另一個路由器呢？

答：通過以太網(wǎng)協(xié)議。

IP 協(xié)議主要是用來尋找最優(yōu)路徑的，具體的傳輸是由以太網(wǎng)協(xié)議來做的。

以太網(wǎng)屬于數(shù)據(jù)鏈路層，它主要負(fù)責(zé)相鄰設(shè)備的通信。原理是通過查詢交換機 Mac 表，找到通信雙方的物理接口，進而開始通信。

以太網(wǎng)報文頭如下：

?

我們只用關(guān)心以下 3 個點：

• 源 Mac 地址
• 目的 Mac 地址
• 校驗碼 CRC：校驗當(dāng)前幀是否有效。

4、通過網(wǎng)線向服務(wù)器硬件接口傳輸比特信息

通過以太網(wǎng)協(xié)議，我們找到了目標(biāo)機器的硬件接口，接下來要怎么發(fā)送信息呢？

答：通過物理層。

在沒有 WiFi 的年代，我們只能通過插網(wǎng)線來進行上網(wǎng)，網(wǎng)線其實就是物理層的設(shè)備之一。網(wǎng)線可以由多種材料組成，最常見的就是光纖和電纜。

光纖和電纜的傳輸原理類似，都是通過兩個信號來模擬二進制數(shù)據(jù)的，一個信號即為一個比特。

• 電纜中：高電位表示 1 ，低點位表示 0。
• 光纖中：光亮表示 1，光熄滅表示 0。

如：在光纖中，我們通過觀察光的閃動，即可得知傳輸?shù)亩M制數(shù)據(jù)。

有了這些物理設(shè)備，我們就能把復(fù)雜的數(shù)據(jù)轉(zhuǎn)換成光信號或者電信號進行傳輸了。

二、發(fā)送數(shù)據(jù)階段

1、建立安全層 SSL

本文的案例是發(fā)送一個 HTTPS 的請求，所以在發(fā)送數(shù)據(jù)之前，會創(chuàng)建一個 SSL 安全層，用于數(shù)據(jù)加密，通常的加密方法有兩種：

（1）非對稱加密

• A 有鑰匙，B 沒有鑰匙，且他們都有一個公共的鎖，B 給 A 發(fā)送數(shù)據(jù)時，都會先把數(shù)據(jù)鎖起來再發(fā)送。
  • 接收數(shù)據(jù)時，A 用鑰匙解開鎖，即可得到數(shù)據(jù)。除 A 以外，其他人沒有鑰匙，也就獲取不到數(shù)據(jù)。
  • 實現(xiàn)了單向通信加密。

（2）對稱加密

• • A、B 雙方都有一把相同的鑰匙和一個公共的鎖，每次發(fā)送數(shù)據(jù)時，都把數(shù)據(jù)放在鎖里進行發(fā)送。
  • 接收數(shù)據(jù)時，A、B 雙方就用各自的鑰匙來解鎖。其他人沒有鑰匙，也就獲取不到數(shù)據(jù)。
  • 實現(xiàn)了雙向通信加密。

到這里為止，所有的準(zhǔn)備工作都就緒了，接下來才是發(fā)送 HTTP 請求。

2、發(fā)送 HTTP 請求

HTTP 協(xié)議其實就是制定了一個通信規(guī)則，規(guī)定了客戶端和服務(wù)器之間的通信格式。以請求 baidu 首頁為例：

?

如上圖所示，發(fā)起 HTTP 請求時，必須遵守以下規(guī)則：

• 請求方法（必填）?GET
• 請求地址（必填）?/
• HTTP 協(xié)議版本（必填）?1.1
• 其他 HTTP 頭部字段（可選）?Host、User-Agent、Accept
• 請求參數(shù)，放在空行后面（可選）

服務(wù)器響應(yīng)請求時，同樣遵守了 HTTP 響應(yīng)規(guī)則：

• HTTP 協(xié)議版本（必填）?1.1
• 響應(yīng)狀態(tài)碼（必填）?200
• 狀態(tài)碼描述（必填）?OK
• 其他 HTTP 頭部字段（可選）?Date、Server、ETag、Last-Modified?等
• 請求參數(shù)，放在空行后面（可選）

只要我們遵守這個規(guī)則，就能進行 HTTP 通信了。到目前為止，我們已經(jīng)分析完成了數(shù)據(jù)請求的所有過程，你是否都理解了呢？

總結(jié)

以上是生活随笔為你收集整理的一文搞懂IT基础知识，讲通HTTP、TCP、IP、以太网的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。