TCPシーケンス番号付けメカニズムの例外？私は、次が真であることを読んで、クライアントとサーバーの両方が0に、それぞれのシーケンス番号を設定し、状況に

Question

、：

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 & Aがありますが、これはハンドシェイクフェーズの間に例外であるか、TCP接続が確立された後に起こるかどうかの答えは説明しません。私はあなたができないと仮定している）

ADDEDこれは、TCPキープアライブパケットにもペイロードがないようです。 RFC 1122はこれらのパケットの中でSEG.SEQ = SND.NXT-1と言います。このシーケンス番号は既にACKされた番号になり、サーバのシーケンス番号を同じに保つために、重複ACKが送信されるためです。

そうでなければ、シーケンス番号が正しいがペイロードがないときに何をする必要があるかの兆候を見つけることができませんでした。私は文書を短時間スキャンしただけなので間違っているかもしれませんが、例以外のハンドシェイク中のシーケンス番号の規則に関する記述もありません。 RFC 1122で

は、それが

言う残念ながら、いくつかは、TCP実装がセグメントにデータが含まれている場合を除きSEG.SEQ = SND.NXT-1とセグメントへの応答に失敗しmisbehaved。

私はそれが各実装に依存すると仮定していますが、a）ハンドシェイク中のシーケンス番号付けと、b）シーケンス＃が正しいがペイロードがないときの動作方法誰かが私にその部分を指摘できたら、本当に感謝します。

ありがとうございます！

Answer 1

最初のACK（ハンドシェイクの一部として発生）は、相手側からSYNの受信を確認します。 SYNセグメントにはデータはありません。しかし、SYNの受信を確認するための準備を可能にするために、ペイロードは存在しないが、最初のACKはインクリメントされる。