介紹
我們關注的就是序號和確認號
這二者也是 TCP 實現可靠傳輸的方式。下圖是一次隨便抓包的截圖（相對序列號）
意義
在TCP傳輸中，每一個字節都是有序號的，從0開始。通過序號的方式保存數據的順序，接收端接受到之后進行重新排列成為需要的數據。
因此，我對於SEQ和ACK的了解就是：
SEQ 代表：發送的這個包中第一個字節（如果有payload的話）的序號
ACK 代表：已成功接受序列號到 ack-1 的數據，期望接收的下一個字節的序號為 ack
舉例說明：
我已經發送了前100字節的數據，那么我下一個發送的包（如果發送窗口還有空間）的SEQ就是101，比如要發送10字節的數據，那么下一個包中的數據的字節編號就是 101 - 110. 之后如果繼續發送的話，序號就是從111開始。
如果接收端接到了這個10字節的包的話，便會返回一個 ACK 為 111 的包，表示前面110個字節已經成功接收。
為什么SYN和FIN會消耗一個序列號
細心的同學可能會發現，為什么在建立連接的時候，發送的 SYN 包大小（payload）明明是0字節，但是接收端卻返回 ACK = 1 ，還有斷開連接的時候 FIN 包也被視為含有1字節的數據。
原因是 SYN 和 FIN 信號都是需要 acknowledgement 的，也就是你必須回復這個信號，如果它不占有一個字節的話，要如何判斷你是回復這個信號還是回復這個信號之前的包呢？
例如：如果 FIN 信號不占用一個字節，回復 FIN 的 ack 包就可能被誤認為是回復之前的數據包被重新發送了一次，第二次揮手無法完成，連接也就無法正常關閉了。
為什么SYN和ACK的初始值（ISN initialization sequence number）是一個隨機值
ISN是不能hard code的，不然會出問題的——比如：如果連接建好后始終用1來做ISN，如果client發了30個segment過去，但是網絡斷了，於是 client重連，又用了1做ISN，但是之前連接的那些包到了，於是就被當成了新連接的包，此時，client的Sequence Number 可能是3，而Server端認為client端的這個號是30了。全亂了。RFC793中說，ISN會和一個假的時鍾綁在一起，這個時鍾會在每4微秒對ISN做加一操作，直到超過2^32，又從0開始。這樣，一個ISN的周期大約是4.55個小時。因為，我們假設我們的TCP Segment在網絡上的存活時間不會超過Maximum Segment Lifetime（縮寫為MSL – Wikipedia語條），所以，只要MSL的值小於4.55小時，那么，我們就不會重用到ISN。
什么是TCP segment of a reassembled PDU
如圖所示，在抓包的時候，經常會看到[TCP segment of a reassembled PDU ] 字樣的包，這個代表數據在傳輸層被分包了。也就是代表包大小大於MTU，此處放一下MTU與MSS區別：
MTU（Maximum Transmission Unit）最大傳輸單元，在TCP/IP協議族中，指的是IP數據報能經過一個物理網絡的最大報文長度，其中包括了IP首部(從20個字節到60個字節不等)，一般以太網的MTU設為1500字節，加上以太幀首部的長度14字節，也就是一個以太幀不會超過1500+14 = 1514字節。
MSS（Maximum Segment Size，最大報文段大小，指的是TCP報文（一種IP協議的上層協議）的最大數據報長度，其中不包括TCP首部長度。MSS由TCP鏈接的過程中由雙方協商得出，其中SYN字段中的選項部分包括了這個信息。如果MSS+TCP首部+IP首部大於MTU，那么IP報文就會存在分片，如果小於，那么就可以不需要分片正常發送。
因此，出現這種現象的原因就是你調用一次send的時候，send的數據比 MSS 還要打，因此就被協議棧進行了分包。
順便說一下，IP數據包的分片是通過flag字段和offset字段共同完成的。
從圖中可以看到，第6個和第5個包是同一個TCP報文被分成了兩個包。如果我們點開看的話，可以看到兩個報文的ACK序號都一樣，並且這些報文的Sequence Number都不一樣，並且后一個Sequence Number為前一個Sequence Number加上前一個報文大小再加上1 。這也是判斷reassembled 的方式。
點開第6個包，可以看到它將5和6的數據整合起來了。