TCP序列編號機制的例外情況？

Question

在客戶端和服務器設置各自的序列號爲0的情況下，我閱讀了以下情況：

C-->S: SYN=1, SEQ=0 (No data bytes) 
C<--S: SYN=1, SEQ=0, ACK=1 (No data bytes) 
C-->S: SEQ=1, ACK=1 (Data bytes optional) 

在第三部分中，我瞭解服務器期待的下一個序列號是1，但不是序號應該設置爲initial_seq_num + sent_data_bytes_num？由於在握手的第一部分中沒有發送數據字節，因此不應將seq＃設置爲0？

這只是在握手過程中發生異常，或者發送到沒有數據字節的段如果它們可以發送，應該將序號遞增1？

（有一個類似的Q &答案，但答案並不能解釋，如果這是一個例外，在握手階段，或者如果這發生在TCP連接建立後，我甚至不知道如果段沒有數據字節甚至可以發送，我假設你不能）

ADDED似乎TCP保持活動數據包也沒有有效載荷。 RFC 1122表示在這些包中，SEG.SEQ = SND.NXT-1，並且因爲這個序列號將是一個已經被確認的號碼，並且將發送一個重複的ACK，以便保持服務器的序號相同。

否則，當序號正確但沒有有效載荷時，我找不到需要做什麼的任何跡象。我可能是錯誤的，因爲我只是簡單地掃描了文檔，但除了示例之外，在握手過程中也沒有序列編號規則的聲明。

在RFC 1122，它說

不幸的是，一些行爲不端TCP實現未能與SEG.SEQ = SND.NXT-1，除非該段包含數據段做出響應。

所以我假設它取決於每個實現，但如果有任何語句a）在握手過程中的序列編號和b）如何在序列號正確但沒有有效載荷時行爲，如果有人能指出我的意思，我會很感激。

謝謝！

Answer 1

第一個ACK（作爲Handshake的一部分出現）確認從另一端接收到SYN。 SYN段不攜帶任何數據。但爲了允許提供確認SYN的接收，第一個ACK增加，儘管沒有有效載荷存在。