從Ethernet到TCP，講不清楚算我輸

以太網幀格式

" 以太網是一種計算機局域網技術。IEEE組織的IEEE 802.3標準制定了以太網的技術標準，它規定了包括物理層的連線、電子信號和介質訪問層協議的內容。以太網是目前應用最廣泛的局域網技術，取代了其餘局域網技術如令牌環、FDDI和ARCNET。" -- Wiki百科

從 Xerox 公佈的 Ethernet I 發展到如今，有過6種以太幀格式：

• Ethernet I
• Ethernet II
• Ethernet 802.3 raw
• Ethernet 802.3 SAP
• 802.3/802.2 LLC
• 802.3/802.2 SNAP

其中主流應用的是 Ethernet II、802.3/802.2 LLC、802.3/802.2 SNAP 這三種，最經常使用的是 RFC894 定義，也就是 Ethernet II 的幀格式。

Ethernet II

• 目標 MAC 地址：6個字節（48位），發送時會先檢查目標 MAC 的地址，與當前適配器的物理地址是否一致，不一致就丟棄；
• 源 MAC 地址：6個字段（48位），發送幀的網絡適配器物理地址
• 類型：上層協議的類型，常見的有，0x0800 表示是 IPV4 協議，0x0806 表示是 ARP 協議，0x86DD 表示是 IPV6 協議，更多詳見
• 數據報文：最小 46 字節，最大 1500 字節（MTU）

802.3/802.2 LLC

• DASP：1個字節，目的服務訪問點
• SSAP：1個字節，源服務訪問點

將 Ethernet II 幀頭的類型字段替換爲幀長度，而且由於新增長了 DASP, SSAP，Control這三個各佔1字節的字段，報文的長度也調整爲：43~1497，它們三個字段做爲 LLC 的頭

802.3/802.2 SNAP

• 類型：2個字節，不一樣於 Ethernet II 的類型字段
• OUI ID：3個字節，一般都爲 0

數據報文變爲：38~1492字節

Ethernet 幀，從最上層（應用層）發送的數據單元（PDU），每通過一層，都會把上層整個的 PDU 做爲下層 PDU 的 data 域，而後加上
本身的協議頭；接受端，同下而上的層層拆掉每層的頭部。瞭解了這些，咱們嘗試抓包具體分析每一個字段

Tcp 報文

$ tcpdump -i eth1 port 9527 -s 0 -w ./target9527.cap
用 wireshark 打開抓到的二進制報文，如圖所示：

創建鏈接

Frame 1，表示第1幀，源ip和目的ip分別是：172.24.31.67 和 10.96.77.128，都是內網ip。

• type：0x0800 表示 IPV4
• 源 MAC 地址：04:25:c5:83:f5:64
• 目標設備mac地址：5e:38:57:10:84:d9
• Flags：0x4000，沒有拆包，若是請求報文大於 MTU，會拆屢次發送
• Times to live：ttl，存活時間，數據包每通過一個三層路由器設備時，ttl域的值減1，當其存活次數爲0時，便會取消數據包的轉發。ttl，默認值是64，以下圖，通過 14 次到達目標ip，全部64-13=51

• SYN：1，表示 請求及創建鏈接，包括剩下的兩次握手請求包

發送數據包

從 Frame 4 至 Frame 7 是創建鏈接後，發送具體請求的數據包。首先，發送了 HTTP 協議的 GET 請求，收到請求後回覆了ACK。具體看下：

• 在 GET 請求時，設置了標誌位 ACK 和 PSH，PSH 是告訴接收端，當即交由應用層處理而沒必要等到Recv socket buffer寫滿
• 接收端回覆 ACK 和 Seq number，接收端和發送端一樣會再回復一個PSH標記的包，要求當即處理
• 最後，應用層經過 HTTP 協議回覆報文，在回覆報文時，這裏要注意還有個標誌位，在報文中，FIN=1，表示在返回的同時請求關閉鏈接

斷開鏈接

tcp 鏈接是雙工的，因此任何創建鏈接的雙方均可以發起關閉鏈接的請求。本身以前面試也總喜歡問這些問題，看看候選人到底理解的是否透徹，
但是大多數都不怎麼清楚。言歸正傳，剩下的 Frame 8 至 Frame 11 是回覆詳情的 ACK 和 端開鏈接的 tcp 包。

• Frame 8 和 Frame 9，分別回覆的是，Frame 6 PSH標誌位的請求和 Frame 7 的 HTTP 請求
• Frame 10 是鏈接另外一邊發起了關閉鏈接的請求，標誌位 FIN=1
• Frame 11 是發起關閉請求方，回覆上一個 FIN=1 的 ACK 請求包

四次揮手所有結束。有同窗能夠會比較疑惑，不是應該是4次請求嗎，這裏只有三次。解釋下這個問題：由於服務端在響應HTTP請求時，由於知道本身已經發送徹底部數據，因此在響應包里加上了四次揮手中的第一次 FIN=1 的請求。