附录B. 早期连接实例的重复段

附录B: 早期连接实例的重复段 (Duplicates from Earlier Connection Incarnations)

需要考虑两种情况：(1) 系统崩溃（并丢失连接状态）和重启，以及 (2) 在不丢失主机状态的情况下关闭和重新打开同一连接。这些将在以下两节中描述。

B.1 系统崩溃导致状态丢失 (System Crash with Loss of State)

TCP在系统启动时的一个MSL的静默时间处理了系统崩溃/重启中的连接状态丢失。有关解释，请参见TCP协议规范中的"何时保持安静" (When to Keep Quiet)。这里所需的MSL不依赖于传输速度。当前TCP的2分钟MSL作为运营妥协似乎是可以接受的，因为许多主机系统在崩溃后需要这么长时间才能启动。

但是，时间戳选项可用于缓解MSL要求（或提供针对数据损坏的额外安全性）。如果正在使用时间戳，并且如果可以保证时间戳时钟在系统崩溃/重启期间单调，即如果可以保证崩溃/重启后发送方时间戳时钟的第一个值大于重启前的最后一个值，则不需要静默时间。

要完全放弃静默时间，需要主机时钟与在崩溃/重启期间稳定的时间源同步，精度为一个时间戳时钟滴答或更好。我们可以从这个严格的要求退一步，利用近似的时钟同步。假设时钟总是重新同步到N个时间戳时钟滴答内，并且启动（如有必要，延长静默时间）需要超过N个滴答。这将保证时间戳的单调性，然后可用于拒绝旧重复，即使没有强制执行MSL。

B.2 关闭和重新打开连接 (Closing and Reopening a Connection)

当TCP连接关闭时，TIME-WAIT状态下2*MSL的延迟会将套接字对捆绑4分钟（参见[Postel81]的第3.5节）。基于TCP构建的应用程序，如果关闭一个连接并打开一个新连接（例如，使用流模式的FTP数据传输连接），每次都必须选择一个新的套接字对。TIME-WAIT延迟有两个不同的目的：

(a) 实现TCP的全双工可靠关闭握手

延迟最终关闭步骤的适当时间实际上与MSL无关；它取决于FIN段的RTO，因此取决于路径的RTT。（可以认为，发送FIN的一方知道它需要什么程度的可靠性，因此它应该能够确定FIN接收方的TIME-WAIT延迟长度。这可以通过FIN段中的适当TCP选项来完成。）

虽然RTT没有正式的上限，但常见的网络工程实践使得RTT大于1分钟的情况非常不可能。因此，TIME-WAIT状态下的4分钟延迟能够令人满意地提供可靠的全双工TCP关闭。再次注意，这与MSL执行和网络速度无关。

如果应用程序需要以非常高的频率重复关闭一个连接并打开另一个连接，TIME-WAIT状态可能会导致间接的性能问题，因为主机上可用的TCP端口数量少于2**16。但是，高网络速度并不是这个问题的主要贡献者；RTT是限制连接打开和关闭速度的因素。因此，这个问题在高传输速度下不会更糟。

(b) 允许旧的重复段过期

要替换TIME-WAIT状态的这个功能，机制必须跨连接运行。PAWS严格定义在单个连接内；最后的时间戳TS.Recent保存在连接控制块中，并在连接关闭时丢弃。

可以向TCP添加额外的机制，即从任何连接接收到的最后时间戳的每主机缓存。然后，如果可以保证时间戳时钟自旧连接打开以来至少滴答了一次，则可以在PAWS机制中使用此值来拒绝来自连接早期实例的旧重复段。这将需要TIME-WAIT延迟加RTT一起必须至少是发送方时间戳时钟的一个滴答。这样的扩展不是本RFC提案的一部分。

请注意，这是Garlick、Rom和Postel提出的机制的一个变体，该机制要求每个主机维护包含每个连接上最高序列号的连接记录。使用时间戳代替，只需要为每个远程主机保留一个数量，无论与该主机的同时连接数量如何。