本篇內容參考自：《計算機網路 自頂向下方法》原書第六版

前言

• 序號欄位和確認號欄位是TCP報文段首部中兩個最重要的欄位，這兩個欄位是TCP可靠傳輸服務的關鍵部分。
• TCP把資料看成一個無結構的、有序的位元組流。序號是建立在傳送的字元流之上的，而不是建立在傳送的報文段的序列之上

序號

一個報文段的序號是該報文段首位元組的位元組流編號，舉個栗子~

假設主機A的一個程序想通過一條TCP連線向主機B上的一個程序傳送一個數據流，主機A中的TCP將隱式地對資料流中的每一個位元組編號。假定資料流由一個包含500 000位元組的檔案組成，其MSS（最大報文段長度）為1000位元組，資料流的首位元組編號是0，如下圖所示：

該TCP將為該資料流構建500個報文段，給第一個報文段分配序號0，第二個報文段分配序號1000，以此類推，每一個序號被填入到相應TCP報文段首部的序號欄位中。

確認號

TCP是全雙工的，即主機A在向主機B傳送資料的同時，也許也在接收來自主機B的資料。從主機B到達的每個報文段中都有一個序號用於從B流向A的資料。主機A填充進報文段的確認號是主機A期望從主機B收到的下一位元組的序號，舉栗子說明：

假設主機A已經收到了來自主機B的編號為0-535的所有位元組，同時假設它打算髮送一個報文段給主機B，主機A等待主機B的資料流中位元組536及其後的所有位元組，所以主機A會在它發往主機B的報文段的確認號欄位中填上536。

再舉一個栗子~

假設主機A已收到主機B的包含位元組0-535位元組的報文段，以及另一個包含位元組900-1000的報文段。由於某種原因，主機A還沒有收到位元組536-899的報文段。在這個例子裡，主機A為了重新構建主機B的資料流，仍在等待位元組536（和其後的位元組）。因此，A到B的下一個報文段將在確認號欄位中包含536

主機A雖然收到了位元組900-1000的報文段，但是並不會在下一個發往主機B的報文段的確認號欄位中填1001，因為535後面的位元組還沒有得到確認，而收到的900-1000位元組的報文段屬於失序到達，對於失序到達的報文段的處理方法由TCP程式設計人員去具體實現，有兩個基本選擇：一是丟棄失序報文段，二是保留失序位元組並等待缺少的位元組以填補該間隔（這是實踐中採用的方法）