いくつかのHTTPトラフィックをキャプチャしていて、FINフラグが設定され、ペイロードデータも含まれているパケットを観察しました。
このトピックを検索したところ、同様の質問がいくつか見つかりましたが、この状況の次のシーケンス番号とRFCリファレンスについて話しているものはありませんでした。
私の質問は、ペイロードを含むFINフラグが設定されたパケットの次のシーケンス番号はどうあるべきかということです。
言い換えると、アクティブなオープナーのFINパケットの応答であるパケットのACK番号は何である必要がありますか? FINパケットの送信者にもペイロードがありますが、応答パケットにはどの確認番号が必要ですか?
--> <SEQ=100><ACK=300><CTL=FIN,ACK> : payload length = 20 bytes
<-- <SEQ=300><ACK=X><CTL=FIN,ACK>
--> <SEQ=X><ACK=301><CTL=ACK>
X
101
、120
、または121
ですか?
RFCはこのシナリオについて明確に説明していますか?
RFC 793でもそれを検索しましたが、質問に対する明確な説明が見つかりませんでした。
RFC 793は、SYNおよびFIN制御フラグが1つのシーケンス番号を占めることを示しています。
用語集には、FIN制御フラグについて次のように書かれています。
フィン
1つのシーケンス番号を占有する制御ビット(finis)。これは、送信者がこれ以上データを送信しないこと、またはシーケンススペースを占有する制御を送信しないことを示します。
したがって、2番目のパケットが最初のパケットを確認している場合、X
の値は121
である必要があることがわかります。
私は100%確信していませんが、これが私がそれを理解する方法です:
2番目のパケットでは、SEQ = 300およびACK = 120であるため、ペイロードを確認します。
3番目のパケットSEQ = 121では、ACKの送信は1バイトのペイロードと見なされるため、接続を開くときに3ウェイハンドシェイクで発生するのと同様です。