【面試必備】探究！一個數據包在網絡中的心路歷程

每日一句英語學習，天天進步一點點：

---

前言

想必很多小夥伴面試過程當中，會遇到「當鍵入網址後，到網頁顯示，其間發生了什麼」的面試題。

還別說，這真是挺常問的這題，前幾天坐在我旁邊的主管電話面試應聘者的時候，也問了這個問題。

此次，小林我帶你們一塊兒探究下，一個數據包在網絡中的心路歷程。

每一個階段都有數據包的「心路歷程」，咱們一塊兒看看它說了什麼？

---

正文

接下來如下圖較簡單的網絡拓撲模型做爲例子，探究探究其間發生了什麼？

01 孤單小弟 —— HTTP

瀏覽器作的第一步工做是解析 URL

首先瀏覽器作的第一步工做就是要對 URL 進行解析，從而生髮送給 Web 服務器的請求信息。

讓咱們看看一條長長的 URL 裏的各個元素的表明什麼，見下圖：

因此圖中的長長的 URL 其實是請求服務器裏的文件資源。

要是上圖中的藍色部分 URL 元素都省略了，哪應該是請求哪一個文件呢？

當沒有路徑名時，就表明訪問根目錄下事先設置的默認文件，也就是 /index.html 或者 /default.html 這些文件，這樣就不會發生混亂了。

生產 HTTP 請求信息

對 URL 進行解析以後，瀏覽器肯定了 Web 服務器和文件名，接下來就是根據這些信息來生成 HTTP 請求消息了。

一個孤單 HTTP 數據包表示：「我這麼一個小小的數據包，沒親沒友，直接發到浩瀚的網絡，誰會知道我呢？誰能載我一層呢？誰能保護我呢？個人目的地在哪呢？」。充滿各類疑問的它，沒有停滯不前，依然踏上了征途！

---

02 真實地址查詢 —— DNS

經過瀏覽器解析 URL 並生成 HTTP 消息後，須要委託操做系統將消息發送給 Web 服務器。

但在發送以前，還有一項工做須要完成，那就是查詢服務器域名對於的 IP 地址，由於委託操做系統發送消息時，必須提供通訊對象的 IP 地址。

好比咱們打電話的時候，必需要知道對方的電話號碼，但因爲電話號碼難以記憶，因此一般咱們會將對方電話號 + 姓名保存在通信錄裏。

因此，有一種服務器就專門保存了 Web 服務器域名與 IP 的對應關係，它就是 DNS 服務器。

域名的層級關係

DNS 中的域名都是用句點來分隔的，好比 www.server.com，這裏的句點表明了不一樣層次之間的界限。

在域名中，越靠右的位置表示其層級越高。

畢竟域名是外國人發明，因此思惟和中國人相反，好比說一個城市地點的時候，外國喜歡從小到大的方式順序提及（如 XX 街道 XX 區 XX 市 XX 省），而中國則喜歡從大到小的順序（如 XX 省 XX 市 XX 區 XX 街道）。

根域是在最頂層，它的下一層就是 com 頂級域，再下面是 server.com。

因此域名的層級關係相似一個樹狀結構：

• 根 DNS 服務器
• 頂級域 DNS 服務器（com）
• 權威 DNS 服務器（server.com）

根域的 DNS 服務器信息保存在互聯網中全部的 DNS 服務器中。

這樣一來，任何 DNS 服務器就均可以找到並訪問根域 DNS 服務器了。

所以，客戶端只要可以找到任意一臺 DNS 服務器，就能夠經過它找到根域 DNS 服務器，而後再一路順藤摸瓜找到位於下層的某臺目標 DNS 服務器。

域名解析的工做流程

1. 客戶端首先會發出一個 DNS 請求，問 www.server.com 的 IP 是啥，併發給本地 DNS 服務器（也就是客戶端的 TCP/IP 設置中填寫的 DNS 服務器地址）。
2. 本地域名服務器收到客戶端的請求後，若是緩存裏的表格能找到 www.server.com，則它直接返回 IP 地址。若是沒有，本地 DNS 會去問它的根域名服務器：「老大， 能告訴我 www.server.com 的 IP 地址嗎？」 根域名服務器是最高層次的，它不直接用於域名解析，但能指明一條道路。
3. 根 DNS 收到來自本地 DNS 的請求後，發現後置是 .com，說：「www.server.com 這個域名歸 .com 區域管理」，我給你 .com 頂級域名服務器地址給你，你去問問它吧。」
4. 本地 DNS 收到頂級域名服務器的地址後，發起請求問「老二， 你能告訴我 www.server.com 的 IP 地址嗎？」
5. 頂級域名服務器說：「我給你負責 www.server.com 區域的權威 DNS 服務器的地址，你去問它應該能問到」。
6. 本地 DNS 因而轉向問權威 DNS 服務器：「老三，www.server.com對應的IP是啥呀？」 server.com 的權威 DNS 服務器，它是域名解析結果的原出處。爲啥叫權威呢？就是個人域名我作主。
7. 權威 DNS 服務器查詢後將對應的 IP 地址 X.X.X.X 告訴本地 DNS。
8. 本地 DNS 再將 IP 地址返回客戶端，客戶端和目標創建鏈接。

至此，咱們完成了 DNS 的解析過程。如今總結一下，整個過程我畫成了一個圖。

DNS 域名解析的過程蠻有意思的，整個過程就和咱們平常生活中找人問路的過程相似，只指路不帶路。

數據包表示：「DNS 老大哥厲害呀，找到了目的地了！我仍是很迷茫呀，我要發出去，接下來我須要誰的幫助呢?」

---

03 指南好幫手 —— 協議棧

經過 DNS 獲取到 IP 後，就能夠把 HTTP 的傳輸工做交給操做系統中的協議棧。

協議棧的內部分爲幾個部分，分別承擔不一樣的工做。上下關係是有必定的規則的，上面的部分會向下面的部分委託工做，下面的部分收到委託的工做並執行。

應用程序（瀏覽器）經過調用 Socket 庫，來委託協議棧工做。協議棧的上半部分有兩塊，分別是負責收發數據的 TCP 和 UDP 協議，它們兩會接受應用層的委託執行收發數據的操做。

協議棧的下面一半是用 IP 協議控制網絡包收發操做，在互聯網上傳數據時，數據劊被切分紅一塊塊的網絡包，而將網絡包發送給對方的操做就是由 IP 負責的。

此外 IP 中還包括 ICMP 協議和 ARP 協議。

• ICMP 用於告知網絡包傳送過程當中產生的錯誤以及各類控制信息。
• ARP 用於根據 IP 地址查詢相應的以太網 MAC 地址。

IP 下面的網卡驅動程序負責控制網卡硬件，而最下面的網卡則負責完成實際的收發操做，也就是對網線中的信號執行發送和接收操做。

數據包看了這份指南表示：「原來我須要那麼多大佬的協助啊，那我先去找找 TCP 大佬！」

---

04 可靠傳輸 —— TCP

HTTP 是基於 TCP 協議傳輸的，因此在這咱們先了解下 TCP 協議。

TCP 包頭格式

咱們先看看 TCP 報文頭部的格式：

首先，源端口號和目標端口號是不可少的，若是沒有這兩個端口號，數據就不知道應該發給哪一個應用。

接下來有包的序號，這個是爲了解決包亂序的問題。

還有應該有的是確認號，目的是確認發出去對方是否有收到。若是沒有收到就應該從新發送，直到送達，這個是爲了解決不丟包的問題。

接下來還有一些狀態位。例如 SYN 是發起一個鏈接，ACK 是回覆，RST 是從新鏈接，FIN 是結束鏈接等。TCP 是面向鏈接的，於是雙方要維護鏈接的狀態，這些帶狀態位的包的發送，會引發雙方的狀態變動。

還有一個重要的就是窗口大小。TCP 要作流量控制，通訊雙方各聲明一個窗口（緩存大小），標識本身當前可以的處理能力，別發送的太快，撐死我，也別發的太慢，餓死我。

除了作流量控制之外，TCP還會作擁塞控制，對於真正的通路堵車不堵車，它無能爲力，惟一能作的就是控制本身，也即控制發送的速度。不能改變世界，就改變本身嘛。

TCP 傳輸數據以前，要先三次握手創建鏈接

在 HTTP 傳輸數據以前，首先須要 TCP 創建鏈接，TCP 鏈接的創建，一般稱爲三次握手。

這個所謂的「鏈接」，只是雙方計算機裏維護一個狀態機，在鏈接創建的過程當中，雙方的狀態變化時序圖就像這樣。

• 一開始，客戶端和服務端都處於 CLOSED 狀態。先是服務端主動監聽某個端口，處於 LISTEN 狀態。
• 而後客戶端主動發起鏈接 SYN，以後處於 SYN-SENT 狀態。
• 服務端收到發起的鏈接，返回 SYN，而且 ACK 客戶端的 SYN，以後處於 SYN-RCVD 狀態。
• 客戶端收到服務端發送的 SYN 和 ACK 以後，發送 ACK 的 ACK，以後處於 ESTABLISHED 狀態，由於它一發一收成功了。
• 服務端收到 ACK 的 ACK 以後，處於 ESTABLISHED 狀態，由於它也一發一收了。

因此三次握手目的是保證雙方都有發送和接收的能力。

如何查看 TCP 的鏈接狀態？

TCP 的鏈接狀態查看，在 Linux 能夠經過 netstat -napt 命令查看。

TCP 分割數據

若是 HTTP 請求消息比較長，超過了 MSS 的長度，這時 TCP 就須要把 HTTP 的數據拆解一塊塊的數據發送，而不是一次性發送全部數據。

• MTU：一個網絡包的最大長度，以太網中通常爲 1500 字節。
• MSS：除去 IP 和 TCP 頭部以後，一個網絡包所能容納的 TCP 數據的最大長度。

數據會被以 MSS 的長度爲單位進行拆分，拆分出來的每一塊數據都會被放進單獨的網絡包中。也就是在每一個被拆分的數據加上 TCP 頭信息，而後交給 IP 模塊來發送數據。

TCP 報文生成

TCP 協議裏面會有兩個端口，一個是瀏覽器監聽的端口（一般是隨機生成的），一個是 Web 服務器監聽的端口（HTTP 默認端口號是 80， HTTPS 默認端口號是 443）。

在雙方創建了鏈接後，TCP 報文中的數據部分就是存放 HTTP 頭部 + 數據，組裝好 TCP 報文以後，就需交給下面的網絡層處理。

至此，網絡包的報文以下圖。

此時，趕上了 TCP 的 數據包激動表示：「太好了，碰到了可靠傳輸的 TCP 傳輸，它給我加上 TCP 頭部，我不在孤單了，安全感十足啊！有大佬能夠保護個人可靠送達！但我應該往哪走呢？」

---

05 遠程定位 —— IP

TCP 模塊在執行鏈接、收發、斷開等各階段操做時，都須要委託 IP 模塊將數據封裝成網絡包發送給通訊對象。

IP 包頭格式

咱們先看看 IP 報文頭部的格式：

在 IP 協議裏面須要有源地址 IP 和 目標地址 IP：

• 源地址IP，便是客戶端輸出的 IP 地址；
• 目標地址，即經過 DNS 域名解析獲得的 Web 服務器 IP。

由於 HTTP 是通過 TCP 傳輸的，因此在 IP 包頭的協議號，要填寫爲 06（十六進制），表示協議爲 TCP。

假設客戶端有多個網卡，就會有多個 IP 地址，那 IP 頭部的源地址應該選擇哪一個 IP 呢？

當存在多個網卡時，在填寫源地址 IP 時，就須要判斷到底應該填寫哪一個地址。這個判斷至關於在多塊網卡中判斷應該使用哪一個一塊網卡來發送包。

這個時候就須要根據路由表規則，來判斷哪個網卡做爲源地址 IP。

在 Linux 操做系統，咱們可使用 route -n 命令查看當前系統的路由表。

舉個例子，根據上面的路由表，咱們假設 Web 服務器的目標地址是 192.168.10.200。

1. 首先先和第一條條目的子網掩碼（Genmask）進行 與運算，獲得結果爲 192.168.10.0，可是第一個條目的 Destination 是 192.168.3.0，二者不一致因此匹配失敗。
2. 再與第二條目的子網掩碼進行 與運算，獲得的結果爲 192.168.10.0，與第二條目的 Destination 192.168.10.0 匹配成功，因此將使用 eth1 網卡的 IP 地址做爲 IP 包頭的源地址。

那麼假設 Web 服務器的目標地址是 10.100.20.100，那麼依然依照上面的路由表規則判斷，判斷後的結果是和第三條目匹配。

第三條目比較特殊，它目標地址和子網掩碼都是 0.0.0.0，這表示默認網關，若是其餘全部條目都沒法匹配，就會自動匹配這一行。而且後續就把包發給路由器，Gateway 便是路由器的 IP 地址。

IP 報文生成

至此，網絡包的報文以下圖。

此時，加上了 IP 頭部的數據包表示 ：「有 IP 大佬給我指路了，感謝 IP 層給我加上了 IP 包頭，讓我有了遠程定位的能力！不會懼怕在浩瀚的互聯網迷茫了！但是目的地好遠啊，我下一站應該去哪呢？」

---

06 兩點傳輸 —— MAC

生成了 IP 頭部以後，接下來網絡包還須要在 IP 頭部的前面加上 MAC 頭部。

MAC 包頭格式

MAC 頭部是以太網使用的頭部，它包含了接收方和發送方的 MAC 地址等信息。

在 MAC 包頭裏須要發送方 MAC 地址和接收方目標 MAC 地址，用於兩點之間的傳輸。

通常在 TCP/IP 通訊裏，MAC 包頭的協議類型只使用：

• 0800 ： IP 協議
• 0806 ： ARP 協議

MAC 發送方和接收方如何確認?

發送方的 MAC 地址獲取就比較簡單了，MAC 地址是在網卡生產時寫入到 ROM 裏的，只要將這個值讀取出來寫入到 MAC 頭部就能夠了。

接收方的 MAC 地址就有點複雜了，只要告訴以太網對方的 MAC 的地址，以太網就會幫咱們把包發送過去，那麼很顯然這裏應該填寫對方的 MAC 地址。

因此先得搞清楚應該把包發給誰，這個只要查一下路由表就知道了。在路由表中找到相匹配的條目，而後把包發給 Gateway 列中的 IP 地址就能夠了。

既然知道要發給誰，按如何獲取對方的 MAC 地址呢？

不知道對方 MAC 地址？不知道就喊唄。

此時就須要 ARP 協議幫咱們找到路由器的 MAC 地址。

ARP 協議會在以太網中以廣播的形式，對以太網全部的設備喊出：「這個 IP 地址是誰的？請把你的 MAC 地址告訴我」。

而後就會有人回答：「這個 IP 地址是個人，個人 MAC 地址是 XXXX」。

若是對方和本身處於同一個子網中，那麼經過上面的操做就能夠獲得對方的 MAC 地址。而後，咱們將這個 MAC 地址寫入 MAC 頭部，MAC 頭部就完成了。

好像每次都要廣播獲取，這不是很麻煩嗎？

放心，在後續操做系統會把本次查詢結果放到一塊叫作 ARP 緩存的內存空間留着之後用，不過緩存的時間就幾分鐘。

也就是說，在發包時：

• 先查詢 ARP 緩存，若是其中已經保存了對方的 MAC 地址，就不須要發送 ARP 查詢，直接使用 ARP 緩存中的地址。
• 而當 ARP 緩存中不存在對方 MAC 地址時，則發送 ARP 廣播查詢。

查看 ARP 緩存內容

在 Linux 系統中，咱們可使用 arp -a 命令來查看 ARP 緩存的內容。

MAC 報文生成

至此，網絡包的報文以下圖。

此時，加上了 MAC 頭部的數據包萬分感謝，說道 ：「感謝 MAC 大佬，我知道我下一步要去了哪了！我如今有不少頭部兄弟，相信我能夠到達最終的目的地！」。
帶着衆多頭部兄弟的數據包，終於準備要出門了。

---

07 出口 —— 網卡

IP 生成的網絡包只是存放在內存中的一串二進制數字信息，沒有辦法直接發送給對方。所以，咱們須要將數字信息轉換爲電信號，才能在網線上傳輸，也就是說，這纔是真正的數據發送過程。

負責執行這一操做的是網卡，要控制網卡還須要靠網卡驅動程序。

網卡驅動從 IP 模塊獲取到包以後，會將其複製到網卡內的緩存區中，接着會其開頭加上報頭和起始幀分界符，在末尾加上用於檢測錯誤的幀校驗序列。

• 起始幀分界符是一個用來表示包起始位置的標記
• 末尾的 FCS（幀校驗序列）用來檢查包傳輸過程是否有損壞

最後網卡會將包轉爲電信號，經過網線發送出去。

唉，真是不容易，發一個包，真是歷經歷經千辛萬苦。致此，一個帶有許多頭部的數據終於踏上尋找目的地的征途了！

---

08 送別者 —— 交換機

下面來看一下包是如何經過交換機的。交換機的設計是將網絡包原樣轉發到目的地。交換機工做在 MAC 層，也稱爲二層網絡設備。

交換機的包接收操做

首先，電信號到達網線接口，交換機裏的模塊進行接收，接下來交換機裏的模塊將電信號轉換爲數字信號。

而後經過包末尾的 FCS 校驗錯誤，若是沒問題則放到緩衝區。這部分操做基本和計算機的網卡相同，但交換機的工做方式和網卡不一樣。

計算機的網卡自己具備 MAC 地址，並經過覈對收到的包的接收方 MAC 地址判斷是否是發給本身的，若是不是發給本身的則丟棄；相對地，交換機的端口不覈對接收方 MAC 地址，而是直接接收全部的包並存放到緩衝區中。所以，和網卡不一樣，交換機的端口不具備 MAC 地址。

將包存入緩衝區後，接下來須要查詢一下這個包的接收方 MAC 地址是否已經在 MAC 地址表中有記錄了。

交換機的 MAC 地址表主要包含兩個信息：

• 一個是設備的 MAC 地址，
• 另外一個是該設備鏈接在交換機的哪一個端口上。

舉個例子，若是收到的包的接收方 MAC 地址爲 00-02-B3-1C-9C-F9，則與圖中表中的第 3 行匹配，根據端口列的信息，可知這個地址位於 3 號端口上，而後就能夠經過交換電路將包發送到相應的端口了。

因此，交換機根據 MAC 地址表查找 MAC 地址，而後將信號發送到相應的端口。

當 MAC 地址表找不到指定的 MAC 地址會怎麼樣？

地址表中找不到指定的 MAC 地址。這多是由於具備該地址的設備尚未向交換機發送過包，或者這個設備一段時間沒有工做致使地址被從地址表中刪除了。

這種狀況下，交換機沒法判斷應該把包轉發到哪一個端口，只能將包轉發到除了源端口以外的全部端口上，不管該設備鏈接在哪一個端口上都能收到這個包。

這樣作不會產生什麼問題，由於以太網的設計原本就是將包發送到整個網絡的，而後只有相應的接收者才接收包，而其餘設備則會忽略這個包。

有人會說：「這樣作會發送多餘的包，會不會形成網絡擁塞呢？」

其實徹底不用過於擔憂，由於發送了包以後目標設備會做出響應，只要返回了響應包，交換機就能夠將它的地址寫入 MAC 地址表，下次也就不須要把包發到全部端口了。

局域網中每秒能夠傳輸上千個包，多出一兩個包並沒有大礙。

此外，若是接收方 MAC 地址是一個廣播地址，那麼交換機會將包發送到除源端口以外的全部端口。

如下兩個屬於廣播地址：

• MAC 地址中的 FF:FF:FF:FF:FF:FF
• IP 地址中的 255.255.255.255

數據包經過交換機轉發抵達了路由器，準備要離開土生土長的子網了。此時，數據包和交換機離別時說道：「感謝交換機兄弟，幫我轉發到出境的大門，我要出遠門啦！」

---

09 出境大門 —— 路由器

路由器與交換機的區別

網絡包通過交換機以後，如今到達了路由器，並在此被轉發到下一個路由器或目標設備。

這一步轉發的工做原理和交換機相似，也是經過查表判斷包轉發的目標。

不過在具體的操做過程上，路由器和交換機是有區別的。

• 由於路由器是基於 IP 設計的，俗稱三層網絡設備，路由器的各個端口都具備 MAC 地址和 IP 地址；
• 而交換機是基於以太網設計的，俗稱二層網絡設備，交換機的端口不具備 MAC 地址。

路由器基本原理

路由器的端口具備 MAC 地址，所以它就可以成爲以太網的發送方和接收方；同時還具備 IP 地址，從這個意義上來講，它和計算機的網卡是同樣的。

當轉發包時，首先路由器端口會接收發給本身的以太網包，而後路由表查詢轉發目標，再由相應的端口做爲發送方將以太網包發送出去。

路由器的包接收操做

首先，電信號到達網線接口部分，路由器中的模塊會將電信號轉成數字信號，而後經過包末尾的 FCS 進行錯誤校驗。

若是沒問題則檢查 MAC 頭部中的接收方 MAC 地址，看看是否是發給本身的包，若是是就放到接收緩衝區中，不然就丟棄這個包。

總的來講，路由器的端口都具備 MAC 地址，只接收與自身地址匹配的包，遇到不匹配的包則直接丟棄。

查詢路由表肯定輸出端口

完成包接收操做以後，路由器就會去掉包開頭的 MAC 頭部。

MAC 頭部的做用就是將包送達路由器，其中的接收方 MAC 地址就是路由器端口的 MAC 地址。所以，當包到達路由器以後，MAC 頭部的任務就完成了，因而 MAC 頭部就會被丟棄。

接下來，路由器會根據 MAC 頭部後方的 IP 頭部中的內容進行包的轉發操做。

轉發操做分爲幾個階段，首先是查詢路由表判斷轉發目標。

具體的工做流程根據上圖，舉個例子。

假設地址爲 10.10.1.101 的計算機要向地址爲 192.168.1.100 的服務器發送一個包，這個包先到達圖中的路由器。

判斷轉發目標的第一步，就是根據包的接收方 IP 地址查詢路由表中的目標地址欄，以找到相匹配的記錄。

路由匹配和前面講的同樣，每一個條目的子網掩碼和 192.168.1.100 IP 作 & 與運算後，獲得的結果與對應條目的目標地址進行匹配，若是匹配就會做爲候選轉發目標，若是不匹配就繼續與下個條目進行路由匹配。

如第二條目的子網掩碼 255.255.255.0 與 192.168.1.100 IP 作 & 與運算後，獲得結果是 192.168.1.0 ，這與第二條目的目標地址 192.168.1.0 匹配，該第二條目記錄就會被做爲轉發目標。

實在找不到匹配路由時，就會選擇默認路由，路由表中子網掩碼爲 0.0.0.0 的記錄表示「默認路由」。

路由器的發送操做

接下來就會進入包的發送操做。

首先，咱們須要根據路由表的網關列判斷對方的地址。

• 若是網關是一個 IP 地址，則這個IP 地址就是咱們要轉發到的目標地址，還未抵達終點，還需繼續須要路由器轉發。
• 若是網關爲空，則 IP 頭部中的接收方 IP 地址就是要轉發到的目標地址，也是就終於找到 IP 包頭裏的目標地址了，說明已抵達終點。

知道對方的 IP 地址以後，接下來須要經過 ARP 協議根據 IP 地址查詢 MAC 地址，並將查詢的結果做爲接收方 MAC 地址。

路由器也有 ARP 緩存，所以首先會在 ARP 緩存中查詢，若是找不到則發送 ARP 查詢請求。

接下來是發送方 MAC 地址字段，這裏填寫輸出端口的 MAC 地址。還有一個以太類型字段，填寫 0080 （十六進制）表示 IP 協議。

網絡包完成後，接下來會將其轉換成電信號並經過端口發送出去。這一步的工做過程和計算機也是相同的。

發送出去的網絡包會經過交換機到達下一個路由器。因爲接收方 MAC 地址就是下一個路由器的地址，因此交換機會根據這一地址將包傳輸到下一個路由器。

接下來，下一個路由器會將包轉發給再下一個路由器，通過層層轉發以後，網絡包就到達了最終的目的地。

不知你發現了沒有，在網絡包傳輸的過程當中，源 IP 和目標 IP 始終是不會變的，一直變化的是 MAC 地址，由於須要 MAC 地址在以太網內進行兩個設備之間的包傳輸。

數據包經過多個路由器道友的幫助，在網絡世界途徑了不少路程，最終抵達了目的地的城門！城門值守的路由器，發現了這個小兄弟數據包原來是找城內的人，因而它就將數據包送進了城內，再經由城內的交換機幫助下，最終轉發到了目的地了。數據包感慨萬千的說道：「多謝這一路上，各路大俠的相助！」

---

10 互相扒皮 —— 服務器 與 客戶端

數據包抵達了服務器，服務器確定高興呀，正所謂有朋自遠方來，不亦樂乎？

服務器高興的不得了，因而開始扒數據包的皮！就好像你收到快遞，能不興奮嗎？

數據包抵達服務器後，服務器會先扒開數據包的 MAC 頭部，查看是否和服務器本身的 MAC 地址符合，符合就將包收起來。

接着繼續扒開數據包的 IP 頭，發現 IP 地址符合，根據 IP 頭中協議項，知道本身上層是 TCP 協議。

因而，扒開 TCP 的頭，裏面有序列號，須要看一看這個序列包是否是我想要的，若是是就放入緩存中而後返回一個 ACK，若是不是就丟棄。TCP頭部裏面還有端口號， HTTP 的服務器正在監聽這個端口號。

因而，服務器天然就知道是 HTTP 進程想要這個包，因而就將包發給 HTTP 進程。

服務器的 HTTP 進程看到，原來這個請求是要訪問一個頁面，因而就把這個網頁封裝在 HTTP 響應報文裏。

HTTP 響應報文也須要穿上 TCP、IP、MAC 頭部，不過此次是源地址是服務器 IP 地址，目的地址是客戶端 IP 地址。

穿好頭部衣服後，從網卡出去，交由交換機轉發到出城的路由器，路由器就把響應數據包發到了下一個路由器，就這樣跳啊跳。

最後跳到了客戶端的城門把手的路由器，路由器扒開 IP 頭部發現是要找城內的人，與是又把包發給了城內的交換機，再由交換機轉發到客戶端。

客戶端收到了服務器的響應數據包後，一樣也很是的高興，客戶能拆快遞了！

因而，客戶端開始扒皮，把收到的數據包的皮扒剩 HTTP 響應報文後，交給瀏覽器去渲染頁面，一份特別的數據包快遞，就這樣顯示出來了！

最後，客戶端要離開了，向服務器發起了 TCP 四次揮手，至此雙方的鏈接就斷開了。

---

一個數據包臭不要臉的感覺

下面內容的 「我」，表明「臭美的數據包角色」。
（括號的內容）表明個人吐槽，三連呸！

我一開始我雖然孤單、不知所措，但沒有停滯不前。我依然滿懷信心和勇氣開始了征途。（你固然有勇氣，你是應用層數據，後面有底層兄弟當靠山，我呸！）

我很慶幸遇到了各路神通廣大的大佬，有可靠傳輸的 TCP、有遠程定位功能的 IP、有指明下一站位置的 MAC 等（你固然會遇到，由於都被計算機安排好的，我呸！）。

這些大佬都給我前面加上了頭部，使得我能在交換機和路由器的轉發下，抵達到了目的地！（哎，你也不容易，不吐槽了，放過你！）

這一路上的經歷，讓我認識到了網絡世界中各路大俠協做的重要性，是他們維護了網絡世界的秩序，感謝他們！（我呸，你應該感謝衆多計算機科學家！）

---

參考文獻:

[1] 戶根勤.網絡是怎麼鏈接的.人民郵電出版社.

[2] 劉超.趣談網絡協議.極客時間.

---

END

最後若是你以爲「本文不錯，「關注+收藏+點贊」，一條龍走起，我就當你打賞了 66.6 元了。

Goodbye，咱們下次見！