一：前情概述
應用層數據報文到傳輸層時，若採用TCP協議則會在其報文頭部添加TCP報文頭，同理當服務端接收到數據報文解析到傳輸層時也會根據TCP報文頭進行相應的邏輯處理。TCP首部蘊藏大量協議數據信息，學習TCP必須抽絲剝繭將其喫透
二：端口Port
Wireshark抓包顯示在TCP首部前兩個字段就是源端口與目的端口，端口號爲什麼要在傳輸層協議中攜帶？真相只有一個，定位！！網絡數據包如何確定歸屬，服務器部署N個應用，依靠的就是端口號。開發部署過程中都知道應用需要暴露監聽端口，且該端口必須唯一不能複用，不然就是Address Already used！
2.1 端口常識
一臺主機最多可以有65535個端口，一般也不會用到這麼多。其中部分端口由IANA機構統一管理，這類端口稱之爲熟知端口，範圍是0 ~ 1023。比如HTTP默認的80、HTTPS默認的443、SSH默認的22等等。
當然，除去0~1023範圍的熟知端口，還有部分不受IANA控制，但是會由IANA登記使用情況的端口，這類端口稱之爲已登記端口，範圍是1024 ~ 65535 * 0.75 - 1 = 49151。比如Redis的6379、MySQL的3306、ZK的2181等等
除了上述兩類端口之外剩餘的端口都是臨時端口號，這些端口供本地應用臨時分配端口使用。當然這個範圍也是可以控制的，控制變量爲
/proc/sys/net/ipv4/ip_local_port_range
2.2 Linux端口操作
通過netstat、lsof等命令加上端口可以查看對應的應用程序PID，當然也可以使用nc、telnet檢查遠程主機端口使用情況等信息
三：序列號Sequence Number
上一篇文章中就已經接觸到序列號的概念，一個完整的應用層報文會因爲諸多限制(後續講解)切割劃分爲多個數據包進行傳輸，傳輸過程中因爲網絡延遲波動等因素導致數據包順序會出現混亂。數據接收方怎麼按照順序重組數據包？答案就是依靠序列號！總結起來序列號作用如下：
根據序列號確定數據包順序,解決數據分包後因爲網絡波動延遲導致的數據包亂序問題
四：確認號ACK
定時重傳也是保證TCP安全可靠的一個重要手段，上一章節講到網絡分包，既然一個完整的數據應用包可能會因爲限制切分爲多個數據包，那麼有些數據包就有可能丟失。一千個包丟了一個需要將一千個包重傳？顯然是愚蠢的設計！針對上述情況提出確認號概念，ACK在上一篇文章中也已經涉及。其具體作用含義如下：
比確認號小的包都已經接收到了，下次傳輸請使用確認號作爲序列號傳輸
五：標記Flags
| 標籤 | 作用 |
|---|---|
| ACK | 標識爲確認包 |
| PSH | 標識立即交給應用層，不能進行緩存 |
| RST | 標識強制斷開連接，包不合法、連接已經斷開、無法處理的包 |
| SYN | 標識連接建立 |
| FIN | 標識連接斷開 |
六：校驗和Checksum
數據包經歷千辛萬苦總算到達數據接收方，必須經過靈魂兩問：是否還完整？有被篡改麼？機器語言就是數據的交流，出發的時候發送端就給這個數據包標記好，有N數量的數據，當接收端收到數據包後就會校驗計算