有多种机制可以检测重复。

• 在 TCP 级别，每个 TCP 数据包中发送的序列号允许检测一个数据包是否被接收两次，或者更一般地说，它是否与已经接收的数据重叠。这实际上不是一个安全功能，而是检测数据包重新排序、重复和丢失，并且这种方式在不可靠的网络层之上提供了一个可靠的传输层。如果检测到这样的重复，它将被简单地丢弃。
• 在 TLS 级别，没有明确地在线发送序列号，但序列号仍保留在每个对等方的 TLS 状态内，并包含在有效负载保护的计算中。因此 TLS 在设计上具有重放保护 - 有关更多信息，请参阅TLS 序列号。由于成功重放的数据包本质上意味着攻击者能够积极地摆弄底层可靠的 TCP 连接，因此该连接通常会被视为受损和放弃。
• 此外，每个新的 TLS 会话都会产生不同的加密密钥，即服务器首先无法解密从不同 TLS 会话嗅探到的 HTTP 请求。感谢 user253751在评论中指出这一点。

一般来说，不 - TLS 协议防止重放攻击，因此如果数据被复制并重新发送，它将被丢弃。

有一个例外，TLS 1.3 协议中的一项新功能 - 0-RTT。这是一种性能增强，其代价是协议在某些情况下无法防止重放攻击。理论上，允许 0-RTT 的系统将具有针对重放攻击的应用层防御。但是，这会产生应用程序可能允许 0-RTT 但防御不足的风险。我不知道我们是否会在野外看到 0-RTT 漏洞，但这是一个潜在有趣的研究领域。更多信息

不，这行不通。通过“数据包”，我假设您只是在描述通过 TLS 的请求中的一些数据，这些数据可以拆分为发送到服务器的多个 TCP 数据包。这可能只是通过已加密的劫持 TCP 连接发送您收到的内容，或者通过重播您从 TCP 连接开始到结束记录的整个会话。

在第一种情况下，服务器的加密状态将与第一次接收数据时不同。如果您在数据流中的某一时刻加密“Hello”，则与稍后加密“Hello”不同。您也可以发送随机位。

如果您正在重播整个连接，则由于握手发生的方式，这将不起作用。每个新连接都有由客户端和服务器生成的随机字节集。这些随机字节用于生成用于后面数据实际加密的密钥。您必须很幸运，并且在服务器上为您的新连接生成与您尝试重播的前一个连接相同的随机字节。