為了驗證理論知識，我透過實際抓取 ADSL 寬帶環境下 Outlook 發送郵件的 TCP/IP 封包，對照《TCP/IP學習筆記》進行補充驗證。本文記錄了真實網絡環境下的封包特徵、三次握手/四次揮手的序列號變化規律，以及自寫抓包程式的功能架構，旨在幫助讀者建立從理論到實戰的直觀認知。
一、 實驗環境與數據來源
- 網絡環境：ADSL 寬帶接入。
- 觸發動作：Outlook 發送郵件（帳號
xiaojin8039@163.com → xiaoj@njb.swirebev.com）。
- 協議過濾：僅捕獲 TCP 協議的 IP 封包。
二、 關鍵封包特徵觀察
1. IP 分片現象
所有捕獲的 IP 封包均未發生分片，均保持原始大小傳輸。這可能得益於 ADSL 環境良好的 MTU 設置及較小的應用層數據量，避免了分片重組的開銷。
2. 首部長度變化
- IP 首部：固定 20 位元組，未出現選項字段。
- TCP 首部：長度動態變化（24~44 位元組）。連接建立階段（SYN 包）必攜選項（如 MSS、Window Scale、SACK Permitted、Timestamps），首部通常為 28 位元組；數據傳輸階段首部多為 20 位元組（無選項）。
3. TCP 連接建立與斷開的完整時序
觀察到的流程比教科書標準「三次握手、四次揮手」更豐富，包含應用層數據交互：
- Client 發送 SYN（Seq=X）
- Server 回覆 SYN+ACK（Seq=Y, Ack=X+1）
- Client 發送 ACK（Seq=X+1, Ack=Y+1）—— 連接建立完成
- Server 發送服務端歡迎信息/應用層數據（PSH+ACK）
- Client 發送郵件命令/數據（PSH+ACK）
- 雙方進行多輪數據交換（DATA 命令、郵件內容、響應碼）
- Client 發送 FIN（Seq=U, Ack=V）
- Server 回覆 ACK（Seq=V, Ack=U+1）
- Server 發送 FIN（Seq=V, Ack=U+1）
- Client 發送最後 ACK（Seq=U+1, Ack=V+1）—— 連接完全關閉
4. 實測序列號與確認號演變規律（節選關鍵幀）
| 幀號 | 方向 | 數據長度 | IP ID | Seq 號 | Ack 號 | 標誌位/備註 |
|---|
| 1 | C→S | 0 | 273 | 2098660028 | 0 | SYN |
| 2 | S→C | 0 | 54707 | 3904671124 | 2098660029 | SYN+ACK |
| 3 | C→S | 0 | 274 | 2098660029 | 3904671125 | ACK |
| 4 | S→C | 56 | 54708 | 3904671125 | 2098660029 | PSH+ACK (Server Info) |
| 5 | C→S | 14 | 275 | 2098660029 | 3904671181 | PSH+ACK (Client Cmd) |
| ... | ... | ... | ... | ... | ... | 數據傳輸階段 |
| 30 | S→C | 0 | 54721 | 3904671452 | 2098662576 | FIN+ACK |
| 31 | C→S | 0 | 288 | 2098662576 | 3904671462 | ACK (連接關閉) |
核心規律總結：
- Seq 遞增邏輯：除 SYN 佔用 1 個序列號外，後續每個封包的 Seq = 前一個 Seq + 數據長度（不含首部）。
- ACK 確認機制：Ack 號永遠等於期望收到的下一個位元組序號（即對方 Seq + 對方數據長度）。
- IP ID：客戶端與服務端各自獨立遞增，可用於區分發送方。
三、 自製抓包分析工具說明
- 核心功能：掛鉤本機網卡，全量捕獲 TCP 協議 IP 封包。
- 應用層解析：對明文協議（如 SMTP、HTTP、POP3）支援郵件首部字段提取與顯示。
- 數據持久化：支援將捕獲的原始封包序列化保存為
scan.bin，並支援導入離線分析（格式見源碼）。
- 擴展性：源碼預留了更多協議解析接口，歡迎有興趣的開發者共同完善。
四、 結語
實戰抓包讓枯燥的 RFC 文檔變得可見、可摸。通過觀察真實的 Seq/Ack 變化、首部選項協商、應用層命令流，能更深刻理解 TCP 可靠傳輸、流量控制、連接管理的精髓。由於水平有限，文中分析難免疏漏，歡迎同好指正交流。
