我也认为这是非常不可能的，并且在我所知道的任何网络中都不会造成真正的问题。因此，针对它的“常用方法”的答案是没有。

但是，您可以构建一个恶意路由器来执行此操作：捕获（在某处飞行中）几个数据包，等待序列号循环，然后重播它们，我们就会触发这种情况。会发生什么取决于楼上的协议，在现实生活中，这些协议必须是 scp 或 rsync（复制大文件）或某些流媒体服务（cctv 永远运行？）。还有什么可以使 TCP 保持打开 4GByte？（所以也许答案是：“这种情况通常被阻止，因为流从不包装其序列号，因为它太短了。”

对于协议问题，我注意到 RFC 7323“高性能 TCP 扩展”涵盖了“PAWS”（防止包装序列）的确切问题。 https://www.rfc-editor.org/rfc/rfc7323#section-5

快速搜索显示在 haiku-os 和 Linux 内核中有一些提到这一点，但我不知道实际实现了多少。

亲切的问候，

乔纳森。

你的数字 6：

Receiver 错误地认为它们属于当前窗口“循环”并处理它们，而不应该这样做，因为它们是重复的。

那不是发生的事情。例如，TCP 在 TCP 段头中有一个 Sequence Number 字段。如果已经接收到该段，则忽略重复的段。

来自RFC 793，传输控制协议：

可靠性：

TCP 必须从互联网通信系统损坏、丢失、复制或乱序传送的数据中恢复。这是通过为每个传输的八位字节分配一个序列号来实现的，并且需要来自接收 TCP 的肯定确认 (ACK)。如果在超时间隔内没有收到 ACK，则重新传输数据。在接收方，序列号用于对可能无序接收的片段进行正确排序并消除重复。通过向每个传输的段添加校验和、在接收器处对其进行检查并丢弃损坏的段来处理损坏。

只要 TCP 继续正常运行并且 Internet 系统没有完全分区，传输错误就不会影响数据的正确传递。TCP 从 Internet 通信系统错误中恢复。

流量控制：

TCP 为接收方提供了一种方法来管理发送方发送的数据量。这是通过返回一个带有每个 ACK​​ 的“窗口”来实现的，该窗口指示除了成功接收的最后一个段之外的可接受序列号的范围。该窗口指示发送方在接收进一步许可之前可以传输的允许的八位字节数。

-和-

2.6. 可靠的通讯

在 TCP 连接上发送的数据流在目的地按顺序可靠地传送。

通过使用序列号和确认，传输变得可靠。从概念上讲，数据的每个八位字节都分配有一个序列号。段中数据的第一个八位字节的序列号与该段一起传输，称为段序列号。段还携带一个确认号，它是反向传输的下一个预期数据八位字节的序列号。当 TCP 传输一个包含数据的段时，它会在重传队列中放置一个副本并启动一个计时器；当收到对该数据的确认时，该段将从队列中删除。如果在定时器用完之前没有收到确认，则重新传输该段。

TCP 的确认并不能保证数据已交付给最终用户，而只能保证接收方 TCP 已对此负责。

为了管理 TCP 之间的数据流，采用了流控制机制。接收 TCP 向发送 TCP 报告一个“窗口”。此窗口指定接收 TCP 当前准备接收的八位字节数，从确认号开始。

另请参阅第3.3节。序列号。

编辑：

根据评论和讨论，您似乎忘记了您在询问滑动窗口，其中调整窗口的大小以满足网络条件。如果网络条件太差（你写“极端”），窗口大小会非常小。当它小到只用于单个段时，就没有问题，因为任何重复的段都将用于不同的窗口，并且它们将被删除。