TCPシーケンス番号と確認応答番号
私はここで関連するトピックを含む他の質問を調べましたが、これについてはまだはっきりしていません。
私はちょうど読んでいます this TCPシーケンスと確認応答番号の説明。約半分下にこの図があります：
ページの終わり近くに、最後のステップであるステップ4の説明に次のテキストが含まれています。
ACKはシーケンス番号スペースを占有しないため、4行目のセグメントのシーケンス番号は3行目と同じであることに注意してください。
したがって、生成されたパケットは、以前に受信したパケットに対する単なる確認応答（つまり、ACKフラグのみが設定され、データは含まれていません）であり、シーケンス番号をインクリメントしないことに注意してください。
私は現在これを理解するのに苦労しています：
- ステップ4で送信されたパケットのシーケンス番号が同じシーケンス番号ステップ3で送信されたパケットとして。
- 確認番号もこれらの手順で同じであることも明らかです。
- 基本的に、作者はstep 4パケットはstep 3パケット。ただし、step 4パケットにはデータ/ペイロードが含まれます。
私の最初の2つのポイントに関して、これは正しいですか？（著者がそれを正しく理解したように？）私の3番目のポイントに関して、これは正しいですか？そして最後に、最初の2つの質問に対する答えが基本的に 'yes'であると仮定すると、介在するものがないため、これらの番号が両方のパケットで同じである理由です。 ゲートウェイサーバーから受信したパケット？
私はこれについて一般的な説明を求めています。
- はい、パケット3と4のシーケンス番号と確認応答番号は実際に同じです。
- いいえ、パケットが完全に同一であるとは限りません。表示される可能性のある違いは次のとおりです。
- パケット4には、
PSHフラグが設定されている場合もあります。 - タイムスタンプが使用されている場合、3と4の間で異なる可能性があります。
- チェックサムはおそらく異なるでしょう。
- パケット4には、
- パケット3と4でシーケンス番号が同じである理由は、パケット3にペイロードデータが含まれていなかったためです。
- パケット3と4で確認応答番号が同じである理由は、その間にサーバーからデータが受信されなかったためです。
パケット3は一種の冗長です。 TCPレイヤーは、アプリケーションがそれらのマイクロ秒の間にソケットに何かを書き込んだ場合、それを送信する前に数マイクロ秒待機し、パケット4に直接進むことを決定できます。
Wiresharkを使用して、コンピューター上の実際のトラフィックを検査することをお勧めします。これは、何が起こっているのかを理解するのに役立つ場合があります。