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