Appendix B. Duplicates from Earlier Connection Incarnations (以前の接続の実体からの重複)

Appendix B: Duplicates from Earlier Connection Incarnations (以前の接続の実体からの重複)

考慮すべき2つのケースがあります: (1) システムがクラッシュ（および接続状態の喪失）して再起動する場合、および (2) ホスト状態の喪失なしに同じ接続が閉じられて再び開かれる場合。これらについては、以下の2つのセクションで説明します。

B.1 System Crash with Loss of State (状態喪失を伴うシステムクラッシュ)

TCPのシステム起動時の1 MSLの静止時間は、システムクラッシュ/再起動における接続状態の喪失を処理します。説明については、たとえば、TCPプロトコル仕様 [Postel81] の「いつ静かにすべきか」を参照してください。ここで必要なMSLは転送速度に依存しません。現在のTCP MSLの2分は、多くのホストシステムがクラッシュ後にブートするのにこれだけの時間がかかるため、運用上の妥協として許容できるようです。

ただし、タイムスタンプオプションを使用して、MSL要件を緩和する（またはデータ破損に対する追加のセキュリティを提供する）ことができます。タイムスタンプが使用されており、タイムスタンプクロックがシステムクラッシュ/再起動にわたって単調であることが保証できる場合、つまり、クラッシュ/再起動後の送信者のタイムスタンプクロックの最初の値が再起動前の最後の値よりも大きいことが保証できる場合、静止時間は不要になります。

静止時間を完全に省略するには、ホストクロックがクラッシュ/再起動期間にわたって安定しているタイムソースに同期されている必要があり、精度は1タイムスタンプクロックティック以上である必要があります。この厳密な要件から後退して、近似的なクロック同期を利用することができます。クロックが常にNタイムスタンプクロックティック以内に再同期され、ブート（必要に応じて静止時間で拡張）がNティック以上かかると仮定します。これにより、タイムスタンプの単調性が保証され、強制されたMSLがなくても古い重複を拒否するために使用できます。

B.2 Closing and Reopening a Connection (接続の閉鎖と再開)

TCP接続が閉じられると、TIME-WAIT状態での2*MSLの遅延により、ソケットペアが4分間拘束されます（[Postel81]のセクション3.5を参照）。TCP上に構築されたアプリケーションが1つの接続を閉じて新しい接続を開く（たとえば、ストリームモードを使用するFTPデータ転送接続）場合、毎回新しいソケットペアを選択する必要があります。TIME-WAIT遅延は2つの異なる目的を果たします:

(a) Implement the full-duplex reliable close handshake of TCP. (TCPの全二重信頼性のあるクローズハンドシェイクを実装)

最終クローズステップを遅延させる適切な時間は、実際にはMSLに関連していません。代わりに、FINセグメントのRTOに、したがってパスのRTTに依存します。（FINを送信している側は、必要な信頼性の程度を知っているため、FINの受信者のTIME-WAIT遅延の長さを決定できるはずだと主張できます。これは、FINセグメントの適切なTCPオプションで実現できます。）

RTTに正式な上限はありませんが、一般的なネットワークエンジニアリングの実践では、RTTが1分を超えることは非常にまれです。したがって、TIME-WAIT状態の4分の遅延は、信頼性の高い全二重TCP閉鎖を提供するために満足に機能します。これは、MSLの強制とネットワーク速度とは無関係であることに再度注意してください。

アプリケーションが非常に高い頻度で繰り返し1つの接続を閉じて別の接続を開く必要がある場合、ホスト上の使用可能なTCPポートの数が2**16未満であるため、TIME-WAIT状態は間接的なパフォーマンス問題を引き起こす可能性があります。ただし、高いネットワーク速度はこの問題の主な原因ではありません。RTTが、接続を開閉できる速度の制限要因です。したがって、この問題は高転送速度でも悪化しません。

(b) Allow old duplicate segments to expire. (古い重複セグメントの期限切れを許可)

TIME-WAIT状態のこの機能を置き換えるには、メカニズムが接続間で動作する必要があります。PAWSは単一の接続内で厳密に定義されています。最後のタイムスタンプTS.Recentは接続制御ブロックに保持され、接続が閉じられると破棄されます。

追加のメカニズムをTCPに追加できます。これは、任意の接続から受信した最後のタイムスタンプのホストごとのキャッシュです。この値は、古い接続が開いてから少なくとも1回タイムスタンプクロックがティックしたことが保証できる場合、PAWSメカニズムで使用して、接続の以前の実体からの古い重複セグメントを拒否できます。これには、TIME-WAIT遅延とRTTを合わせて、送信者のタイムスタンプクロックの少なくとも1ティックである必要があります。このような拡張は、このRFCの提案の一部ではありません。

これは、Garlick、Rom、およびPostel [Garlick77]によって提案されたメカニズムのバリアントであり、各ホストがすべての接続で最高のシーケンス番号を含む接続レコードを維持することを要求していました。代わりにタイムスタンプを使用すると、そのホストへの同時接続の数に関係なく、リモートホストごとに1つの量を保持するだけで済みます。