建立TCP连接时，如果TCP使用固定的初始序列号会发生什么？

Question

我正在阅读Douglas Comer的《TCP/IP协议》一书，当谈到创建TCP连接时，存在一个问题：

假设TCP的实现在创建连接时使用初始序列号1，那么系统崩溃和重启会如何混淆远程系统，使其认为旧连接仍然保持打开状态。

我无法理解其中的原因，请帮忙解释，谢谢。

- DiveInto

Answer 1

考虑为什么连接通常会收到重复的序列号。

然后考虑一下，接收系统如何处理带有“重复”序列号的数据包（因为发送系统在使用数据包尝试重新建立连接时开始重用序列号）。

但是数据包会丢失、延迟和乱序到达。不能简单地说在带有SYN标志的数据包之后到达的所有内容都是新的。假设一些旧的数据包被延迟并在建立新连接后到达。如何区分序列号为＃10的数据包是来自旧连接还是新连接？最糟糕的情况是它来自旧连接，并且接收系统将其接受为来自新连接。当真正的新连接数据包＃10到达时，它被忽略为不必要的重传。流被损坏，没有任何指示。

http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentSequenceNumberSynchroniz.htm

“每次连接都以序列号1开始的问题在于，它会引入不同连接的分段混淆的可能性。假设我们建立了一个TCP连接并发送了一个包含1到30字节的数据段。然而，因为互联网出现了问题，导致这个数据段被延迟，最终TCP连接本身也被终止了。接着我们启动了一个新的连接，并再次使用起始序列号1。然而，一旦这个新连接被启动，旧的带有标记为1到30字节的数据段就出现了。另一台设备会错误地认为这些字节是新连接的一部分。... 这只是几个类似问题中的一个。”

---

另一个问题是初始序列号可预测，例如每次从1开始，这会导致可预测性漏洞：

恶意人员可以编写代码分析ISN，然后根据先前使用的ISN预测后续TCP连接的ISN。这代表着一个安全风险，过去已经被利用（例如著名的Mitnick攻击）。为了解决这个问题，现在的实现在其ISN选择过程中使用随机数。

Mitnick攻击 - http://www.cas.mcmaster.ca/wiki/index.php/The_Mitnick_attack

- Bert F

---

但是当重新建立连接时，传输系统将发送一个带有SYN代码位设置的段（当然，序列号将被设置为1），这样做（设置SYN代码位）不会通知接收系统正在尝试建立新连接吗？请参阅Transmission_Control_Protocol的维基百科，它说：“每个端点发送的第一个数据包应该设置此标志（SYN）。” - DiveInto

非常感谢您的高质量回答，但很抱歉我还是有些固执。您提供的场景表明接收系统可能会错误地将旧连接的数据包视为新连接的数据包，因此系统崩溃和重启可能会让远程系统混淆旧数据包来自新连接。但这仍然无法解释如何让远程系统混淆旧连接仍然保持打开状态。实际上，在您提供的场景中，我认为接收系统清楚地知道旧连接已经关闭。再次感谢您的回答，非常感谢 ^_^。 - DiveInto

@Diveinto - 我一直在考虑这个问题，唯一能想到的是重新连接的初始 SYN 数据包可能会被视为重复。然而，我找不到支持这一点的文档。我找到的最接近的是 http://www.faqs.org/rfcs/rfc793.html 的图10：“当 SYN 到达第3行时，TCP B 处于同步状态，并且传入的数据段在窗口之外，响应一个确认，指示它下一个期望听到的序列（ACK 100）。”没有说明如果数据段在窗口内会发生什么。 - Bert F

Answer 2

然而，情况比那更糟糕——使用序列号进行预测使欺骗和注入变得更加容易。

- Flexo

---

实际上，我知道更糟糕的一面，只是不知道为什么这会让接收系统认为旧连接仍然打开。 - DiveInto

Answer 3

重启后，如果第一个TCP连接是向同一远程系统的，则由于序列号再次为1，考虑那会引起什么问题。

- sinelaw