引言

常見的網絡拓撲結構如下圖所示：

在此拓撲中，終端設備通過 WiFi 連接到路由器，路由器再連接到光貓（或終端設備通過移動網絡 4G/5G 連接到基站），之後 ISP 網絡服務提供商接管網絡通信，將請求最終轉發至應用服務器。

從用户設備發出的 HTTP 請求是如何穿越網絡的？我們將深入探討這一過程。

HTTP 請求的網絡旅途

OSI 網絡體系結構

先從計算機網絡的基礎架構開始：

上圖展示了五層簡化版 OSI 網絡模型。每層都對網絡通信至關重要，特別是在 HTTP 請求的傳遞過程中。關鍵點包括：

• 傳輸層：TCP 頭部包含的源端口和目標端口。
• 網絡層：IP 頭部包含的源 IP 地址和目標 IP 地址。
• 數據鏈路層：MAC 頭部包含的源 MAC 地址和目標 MAC 地址。

接下來我們來看看，在網絡設備的轉發過程中，這些信息如何發生變化。

HTTP 網絡之旅

下圖展示了完整的網絡路徑：

一、用户終端設備 --> 路由器

1. HTTP 請求基於 TCP 連接。用户通常會請求一個域名地址，首先必須通過 DNS 解析獲取服務器的 IP 地址。DNS 的查詢過程如下：

   • 瀏覽器 DNS 緩存（如果訪問的是 web 網頁）。
   • 本地操作系統 DNS 緩存。
   • 本地 /etc/hosts 文件是否有配置域名到 IP 的直接映射。

   • DNS 查詢：

     • 向域名服務器（地址配置在 /etc/resolv.conf 文件）發起查詢：

       • 域名服務器地址可以是：ISP 域名服務器或公共 DNS 服務器（如 Google 8.8.8.8 或 Cloudflare 1.1.1.1）。
       • 通常，終端設備通過路由器連接網絡，這時 /etc/resolv.conf 的 nameserver 指向的就是路由器的 WAN IP（如 192.168.3.1），路由器將繼續轉發 DNS 查詢。
     • 遞歸查詢：根域名服務器 -> 頂級域名服務器 -> 權威域名服務器（存儲真實的 DNS 記錄）。

2. DNS 解析完畢後，數據開始從應用層向下傳遞並封裝：

   • 傳輸層：封裝 TCP 頭，包含源端口（一般隨機生成）和目標端口（HTTP 默認 80）。
   • 網絡層：封裝 IP 頭，包含源 IP（用户設備的內網 IP）和目標 IP（遠程服務器公網 IP）地址。
3. 用户設備通過 ARP 協議查找目標 MAC 地址（此時得到路由器的 MAC 地址）。在數據鏈路層則封裝了 MAC 頭部，其中包含了源 MAC（用户設備 MAC）地址和目標 MAC（路由器 MAC）地址。
4. 最後，數據在物理層通過無線電波（WiFi）傳遞二進制數據到路由器（如果是雙絞線則是電信號，光纖則是光信號）。路由器接收到數據後，進入下一階段處理。

二、路由器 --> 光貓

路由器在物理層接收到二進制數據後，將數據解析成上一層的數據鏈路層格式，隨後改寫源 MAC 和目標 MAC 地址，將數據發送到下一跳設備（光貓）。

由於路由器沒有公網 IP 地址，此時不會進行 NAT（網絡地址轉換），IP 頭部中的源 IP 仍為用户設備的內網 IP。

三、光貓 --> ISP NAT 設備

光貓負責將數據通過一系列中間網絡設備，最終傳遞到 ISP 的 NAT 設備。

四、ISP NAT 設備 --> 服務器

由於公網 IPv4 地址的數量有限，ISP 通常會為同一區域的多個用户共享一個公網 IP。

此時，ISP 的 NAT 設備會將源 IP 地址轉換為共享的公網 IP 地址。至此，數據才進入公網傳輸，並最終達到應用服務器。

服務器在接受到數據後，從下層往上依次解析數據，最終還原出來應用層的 HTTP 請求。

總結

本文介紹了 HTTP 請求從用户終端設備到應用服務器的全過程，並通過圖示説明了請求如何在 OSI 模型的不同層次間傳遞和轉化。