原文：http://packetlife.net/blog/2010/jun/7/understanding-tcp-sequence-acknowledgment-numbers/
翻譯：https://blog.csdn.net/a19881029/article/details/38091243
一點總結
SYN - 創建一個連接
FIN - 終結一個連接
ACK - 確認接收到的數據
TCP會話的每一端都包含一個32位（bit）的序列號，該序列號被用來跟蹤該端發送的數據量。每一個包中都包含序列號，在接收端則通過確認號用來通知發送端數據成功接收
當某個主機開啟一個TCP會話時，他的初始序列號是隨機的，可能是0和4,294,967,295之間的任意值，而不是都從0開始，這樣主要是出於網絡安全的因素着想。 如果不是隨機產生初始序列號，黑客將會以很容易的方式獲取到你與其他主機之間通信的初始化序列號，並且偽造序列號進行攻擊，這已經成為一種很常見的網絡攻擊手段。同時可以避免不必要的沖突。初始序列號隨機生成，一般是基於時間，利用散列函數（這個函數一定時間也會輪換）計算而成的，目的是防止被猜測序列號從而被偽造攻擊。同時因為是基於時間的，所以幾乎不會與最近斷開的或正在等待中的序列號相同
接收端接受到發送端的報文號回送的序列號是在接受端的初始序列號開始累加（第一次傳送有效數據的序列號為初始序列號，后續序列號(比如第一次發送端傳送數據序列號為1，發送數據725byte，則下一次發送端的序列號為726))
確認號取決於發送過來數據的大小 比如初始發送了42byte，此時回送的ACK為43（表示<43的數據已全部確認(累積確認)期望收到序號為43的包)
如果客戶端沒有再向服務端發送數據，客戶端序列號保持不變，服務端的序列號，由於服務端不斷地發送HTTP響應，故其序列號一直在增長
序列號為當前端成功發送的數據字節數，確認號為當前端成功接收的數據位數，SYN標志位和FIN標志位也要占1位
TCP是以流水線發出的，比如發送端順序的發出 Seq=1、Seq=2、Seq=3。
那么如果ACK確認的序號和收到的包的序號一致的話，那么需要發回 ACK=1、ACK=2、ACK=3 共三個包。
但是TCP協議對此進行了優化，即累積確認只需要發送一個ACK包就能代表說自己已經收到了前面三個包，
那就是發送ACK=4 （期望收到Seq為4的包）。這樣節省了ACK確認的數量
另外TCP是的序號是根據數據流編碼的， 假設最開始Seq=0 Len=3， 那么 ACK=4的時候：
第一個意思是想表明期待收到下一個Seq為4的包。
第二個意思實際上是說，想收到的包開始的那個比特位於數據流中的第四個比特。
--部分總結摘自評論/原文