这是完全可行的，但需要注意的是您需要知道目标 tcp 堆栈所需的正确序列号。（因此，为了能够对与服务器的所有连接执行此操作，您必须在服务器本身或到该服务器的网关上）。

注意：你离目标堆栈越远，你就越有可能在注入时遇到时间问题。（假设它是一个数据包注入，而不是一个完整的中间人）

我还从经验中知道，通过对目标堆栈进行小的安全更新，这种拦截很快就会被打破:(

Rst 和 fin 将受到相对严密的保护，是否值得将 tcp 窗口大小设置为零而不是？（只是一个想法，自从我玩这个东西以来已经很长时间了[十年！]）

..但我想知道通信方如何知道连接被不当终止以及为什么它只是被中断。

tcp 的全部意义在于提供可靠的连接，如果你终止连接，那么每一端的堆栈都知道。它只是被中断，因为当连接断开时，大多数系统会重试连接，通常甚至不告诉用户。

我最初的回复在块引用中的下方（“否......”），但我需要更正这个，因为我认为我的回复是错误的。TCP 本身并不能确保免受重放和/或中间人攻击。事实上，这种中断通常被称为TCP 重置攻击。问题在于 TCP 没有内置的消息身份验证，裸 TCP 无法保证数据包的真实性或真实性——要实现这一点，需要依赖HTTPS 中的传输层安全性 (TLS)。如果应用程序能够检测到乱序数据包或非法 FIN，则这是辅助服务，TCP 标准未指定。下面是我最初的错误评估：

不，攻击者无法通过注入“FIN”数据包成功终止 TCP 连接，因为 TCP 是一个相互偶然的协议，需要双方同意（即，一方通过发送意图声明来启动状态更改，然后等待接收对该意图的确认，然后它将处理状态更改）到要执行的事务的事务。这对应于 Brent Baccala（编辑）*Connected: An Internet Encyclopedia,* 第三版中给出的答案，我们在其中找到以下内容：

情况 2：TCP 从网络接收到一个 FIN 如果一个未经请求的 FIN 从网络到达，接收 TCP 可以 ACK 并告诉用户连接正在关闭。用户将以 CLOSE 响应，TCP 可以在发送任何剩余数据后向另一个 TCP 发送 FIN。然后 TCP 等待直到它自己的 FIN 被确认，然后它删除连接。如果没有收到 ACK，则在用户超时后，连接将中止并告知用户。

[Connected: An Internet Encyclopedia TCP Connection Close][5] 所以即使数据包序号是正确的，一个意外的`FIN`并不仅仅根据TCP协议描述结束两台计算机之间的通信。让我们不要忘记：接收方不仅会向发送方发出确认“FIN”的响应，而且实际上会收到两个具有相同序列号的冲突数据包——除非接收方处于预期“FIN”的地步，否则它将被丢弃，通信将继续或在两个终端同意的最后一个状态重新开始。