文章目錄
- 實際應用
- 第一步:用戶在瀏覽器輸入 `www.baidu.com` 并按下回車
- 1. 瀏覽器觸發域名解析(DNS查詢)
- 第二步:DNS請求的逐層封裝與傳輸
- 1. 應用層(DNS協議)
- 2. 傳輸層(UDP協議)
- 3. 網絡層(IP協議)
- 4. 數據鏈路層(以太網/Wi-Fi協議)
- 5. 物理層(比特流傳輸)
- 第三步:數據包如何找到DNS服務器?
- 1. 局域網內傳輸(數據鏈路層)
- 2. 跨網絡傳輸(網絡層)
- 3. 最終抵達DNS服務器
- 第四步:瀏覽器發起HTTP請求
- 1. 建立TCP連接(傳輸層)
- 2. 封裝HTTP請求(應用層)
- 3. 逐層封裝
- 第五步:數據包穿越互聯網到達百度服務器
- 1. 路由器的逐跳轉發(網絡層)
- 2. 服務器接收請求
- 第六步:響應數據返回客戶端
- 1. 反向封裝與傳輸
- 2. 瀏覽器渲染頁面
- 關鍵協作點總結
- 補充技術細節
上一篇文章對計算機網絡的五層結構做了簡單的介紹,需要的可以看這里
計算機網絡的五層結構(物理層、數據鏈路層、網絡層、傳輸層、應用層)到底是什么?
實際應用
看到這里的時候我相信大家會有和我一樣的疑惑,這五層結構到底是干嘛用的,到底有什么用,我平時有用到這東西的機會嗎?
那么下面我給大家準備了一個實際的例子來讓大家對這五層機構可以更好的了解。
我下面的例子是用訪問瀏覽器中的某一個網址來舉例,在我訪問一個網址,比如www.baidu.com的時候,讓我們看看這五層結構都是怎么發揮作用的?
第一步:用戶在瀏覽器輸入 www.baidu.com
并按下回車
1. 瀏覽器觸發域名解析(DNS查詢)
-
為什么需要DNS?
計算機無法直接通過域名www.baidu.com
通信,必須將其轉換為 IP 地址(如14.215.177.38
)。這一過程稱為 DNS解析。 -
具體流程:
- Step 1:檢查本地緩存
瀏覽器緩存 → 系統緩存(如Windows的hosts文件) → 路由器緩存 → 若命中,直接使用緩存的IP地址。 - Step 2:未命中緩存 → 發起遞歸查詢
若本地無緩存,瀏覽器調用操作系統的 DNS解析器(應用層組件),生成一個 DNS請求報文,內容為:查詢域名:www.baidu.com 查詢類型:A記錄(IPv4地址)
- Step 1:檢查本地緩存
第二步:DNS請求的逐層封裝與傳輸
1. 應用層(DNS協議)
- DNS協議使用 UDP(傳輸層協議),目標端口為
53
,源端口隨機(如50001
)。 - 封裝后的 DNS報文 交給傳輸層處理。
2. 傳輸層(UDP協議)
- 添加 UDP頭部:包含源端口(
50001
)、目標端口(53
)、長度和校驗和。 - 此時數據變為:
[UDP頭部 | DNS請求報文]
3. 網絡層(IP協議)
- 添加 IP頭部:包含源IP(你的設備私有IP,如
192.168.1.100
)、目標IP(默認DNS服務器IP,如8.8.8.8
)。 - 此時數據變為:
[IP頭部 | UDP頭部 | DNS請求報文]
4. 數據鏈路層(以太網/Wi-Fi協議)
- 添加 幀頭部:包含源MAC地址(你的網卡MAC,如
AA:BB:CC:DD:EE:FF
)和目標MAC地址(默認網關的MAC地址,如路由器的11:22:33:44:55:66
)。 - 此時數據變為:
[幀頭 | IP頭部 | UDP頭部 | DNS請求報文 | 幀尾]
5. 物理層(比特流傳輸)
- 將幀轉換為 電信號(網線) 或 無線電波(Wi-Fi),通過物理媒介發送到路由器(默認網關)。
第三步:數據包如何找到DNS服務器?
1. 局域網內傳輸(數據鏈路層)
- 目標MAC地址是路由器:你的設備通過ARP協議(地址解析協議)提前獲取了默認網關(路由器)的MAC地址。
- 交換機的作用:如果設備通過網線連接到交換機,交換機會根據MAC地址表將幀轉發到路由器對應的端口。
2. 跨網絡傳輸(網絡層)
- 路由器收到數據包后,剝離幀頭部,檢查IP頭部:
- 目標IP是
8.8.8.8
(DNS服務器),不屬于本地局域網。 - 路由器通過 NAT(網絡地址轉換) 將源IP(
192.168.1.100
)替換為路由器的公網IP(如120.230.10.20
)。 - 路由器根據 路由表 選擇下一跳(如ISP的核心路由器),重新封裝幀頭部(目標MAC變為下一跳設備的MAC),轉發數據包。
- 目標IP是
3. 最終抵達DNS服務器
- 數據包經過多個路由器的接力轉發(每經過一個路由器,源/目標MAC地址會變化,但IP地址不變),最終到達DNS服務器
8.8.8.8
。 - DNS服務器解析請求,查詢
www.baidu.com
的IP地址,生成 DNS響應報文(包含14.215.177.38
),按原路返回給你的設備。
第四步:瀏覽器發起HTTP請求
1. 建立TCP連接(傳輸層)
- 獲取到百度服務器的IP地址后,瀏覽器通過 TCP協議 與目標IP(
14.215.177.38
)的80
端口(HTTP)或443
端口(HTTPS)建立連接。 - TCP三次握手:
- 客戶端發送
SYN
報文(序列號x)。 - 服務器回復
SYN-ACK
報文(序列號y,確認號x+1)。 - 客戶端發送
ACK
報文(確認號y+1)。
- 客戶端發送
- 此時TCP連接建立完成,雙方確認通信能力。
2. 封裝HTTP請求(應用層)
- 瀏覽器生成 HTTP請求報文,例如:
GET / HTTP/1.1 Host: www.baidu.com User-Agent: Chrome/120.0
- 如果是HTTPS,還需進行 TLS握手(交換密鑰、驗證證書等)。
3. 逐層封裝
- 傳輸層:將HTTP報文拆分為多個 TCP段,添加TCP頭部(源端口、目標端口、序列號、確認號)。
- 網絡層:添加IP頭部(源IP為公網IP
120.230.10.20
,目標IP14.215.177.38
)。 - 數據鏈路層:添加幀頭部(源MAC為路由器出口MAC,目標MAC為下一跳設備MAC)。
- 物理層:轉換為比特流傳輸。
第五步:數據包穿越互聯網到達百度服務器
1. 路由器的逐跳轉發(網絡層)
- 每個路由器根據目標IP
14.215.177.38
查詢路由表,選擇最優路徑(如通過BGP協議判斷)。 - 數據包可能經過:
- 家庭路由器 → ISP骨干網路由器 → 百度數據中心邊緣路由器 → 百度內部核心路由器。
2. 服務器接收請求
- 百度服務器接收到數據包后,反向解封裝:
- 物理層 → 數據鏈路層(剝離幀頭) → 網絡層(檢查IP地址) → 傳輸層(重組TCP段) → 應用層(處理HTTP請求)。
- 服務器生成 HTTP響應報文(狀態碼200,包含HTML、CSS、JS等資源)。
第六步:響應數據返回客戶端
1. 反向封裝與傳輸
- 服務器將HTTP響應按相同流程封裝(IP頭部源/目標地址調換,TCP端口調換),通過互聯網返回。
- 客戶端路由器接收后,通過NAT將目標IP從公網IP
120.230.10.20
轉換為內網IP192.168.1.100
,再轉發給你的設備。
2. 瀏覽器渲染頁面
- 瀏覽器接收HTTP響應后,解析HTML/CSS/JS,加載圖片等資源(可能觸發多次HTTP請求)。
- 最終渲染出完整的百度首頁。
關鍵協作點總結
- DNS解析:
- 應用層協議(DNS) → 傳輸層(UDP) → 網絡層(IP路由) → 數據鏈路層(MAC尋址) → 物理層傳輸。
- HTTP請求:
- 應用層(HTTP) → 傳輸層(TCP連接) → 網絡層(IP跨網) → 數據鏈路層(幀轉發) → 物理層傳輸。
- 數據封裝與解封裝:
- 每經過一層設備(如路由器、交換機),數據包的外層封裝會被修改(如MAC地址、IP NAT),但核心內容(如HTTP報文)保持不變。
補充技術細節
- NAT(網絡地址轉換):
家庭路由器將內網設備的私有IP(如192.168.1.100
)轉換為公網IP(如120.230.10.20
),解決IPv4地址不足問題。 - MTU與分片:
若數據包超過鏈路層最大傳輸單元(如1500字節),網絡層會將其分片,目標端重組。 - ARP協議:
設備通過ARP廣播查詢IP地址對應的MAC地址(如“誰是192.168.1.1
?請告訴我你的MAC!”)。
通過以上流程,你可以清晰看到:五層模型并非獨立運作,而是像流水線一樣協同工作,最終實現“輸入網址 → 看到網頁”的復雜過程。