學妹問我：當開啟 CSDN，到網頁顯示，其間發生了什麼？
大家好，我是小林。
想必不少小夥伴面試過程中，會遇到「當鍵入網址後，到網頁顯示，其間發生了什麼」的面試題。
還別說，這真是挺常問的這題，前幾天坐在我旁邊的主管電話面試應聘者的時候，也問了這個問題。
這次，小林用 30 張圖 + 擬人手法帶大家一探究竟！
以下圖較簡單的網路拓撲模型作為例子，探究探究其間發生了什麼？
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 伺服器。
域名解析的工作流程
- 使用者端首先會發出一個 DNS 請求，問 www.server.com 的 IP 是啥，並行給本地 DNS 伺服器（也就是使用者端的 TCP/IP 設定中填寫的 DNS 伺服器地址）。
- 本地域名伺服器收到使用者端的請求後，如果快取裡的表格能找到 www.server.com，則它直接返回 IP 地址。如果沒有，本地 DNS 會去問它的根域名伺服器：「老大， 能告訴我 www.server.com 的 IP 地址嗎？」 根域名伺服器是最高層次的，它不直接用於域名解析，但能指明一條道路。
- 根 DNS 收到來自本地 DNS 的請求後，發現後置是 .com，說：「www.server.com 這個域名歸 .com 區域管理」，我給你 .com 頂級域名伺服器地址給你，你去問問它吧。」
- 本地 DNS 收到頂級域名伺服器的地址後，發起請求問「老二， 你能告訴我 www.server.com 的 IP 地址嗎？」
- 頂級域名伺服器說：「我給你負責 www.server.com 區域的權威 DNS 伺服器的地址，你去問它應該能問到」。
- 本地 DNS 於是轉向問權威 DNS 伺服器：「老三，www.server.com對應的IP是啥呀？」 server.com 的權威 DNS 伺服器，它是域名解析結果的原出處。為啥叫權威呢？就是我的域名我做主。
- 權威 DNS 伺服器查詢後將對應的 IP 地址 X.X.X.X 告訴本地 DNS。
- 本地 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。
- 首先先和第一條條目的子網掩碼（
Genmask）進行 與運算，得到結果為192.168.10.0，但是第一個條目的Destination是192.168.3.0，兩者不一致所以匹配失敗。 - 再與第二條目的子網掩碼進行 與運算，得到的結果為
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] 劉超.趣談網路協定.極客時間.
作者簡介：大家好，我是小林，一個專為大家圖解的工具人，微信搜尋「小林coding」，關注回覆「圖解」，獲取小林原創的圖解網路和圖解系統 PDF。