TCP 中的Sequence Number

介紹

咱們關注的就是序號和確認號

這兩者也是 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）是一個隨機值

參考TCP 的那些事兒（上）

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的數據整合起來了。