【发布时间】：2016-02-22 07:55:08
【问题描述】：
假设主机 H1 正在寻找与 H2 建立 TCP 连接并为 3 次握手的第一步发送一个 SYN。然后 H1 在超时时没有收到回音，并且正在向 H2 发送第二个 SYN。
然后，H1 会收到这两个 SYN 的回复。在这种情况下，H1 做了什么——这两个中的哪一个作为握手的第三步确认，来自 H2 的第一个 SYN+ACK 还是第二个？两个 SYN+ACK 有 2 个不同的 H2 初始序列号 (ISN)。它们也有不同的 ACK——H1 在其两个 SYN 中发送了 2 个不同的 ISN。
从另一个角度来看——在这种情况下，H2 会做什么？所以 - H2 收到一个 SYN 并发送 SYN+ACK 作为响应。过了一会儿，H2 又收到了来自 H1 的 SYN+ACK。在这种情况下 H2 做了什么：
- 是否也向第二个 SYN 发送 SYN+ACK？在这种情况下，H2 怎么知道哪个 SYN（H1 的 ISN）是这个连接的？
或
- 忽略第二个 SYN。但是，H2 也超时了——它没有收到任何回音，因为它发送了之前的 SYN+ACK。
这在 TCP 中是如何处理的？
TIA
注意：我见过What if a TCP handshake segment is lost?、TCP: SYN request receives SYN response instead of SYN-ACK、tcpip 3-way handshake 和TCP handshake reliability 以及其他一些有用的讨论。
//--------------------------------------------- ---
编辑：
答案似乎在于RST 标志——只要对序列#s 有疑问，就会重置。请参阅RFC793 的图 9。
但是，Q 仍然存在于下面的评论中：H1 何时出现（图 9 中的“TCP A”） 使用新的 ISN 重试连接 - 多长时间后以及在什么情况下？
【问题讨论】：
-
我投票结束这个问题，因为它与编程无关
-
重新提交的 SYN 的序列号与原始 SYN 中的序列号相同。是什么让您认为情况并非如此？
-
@SteffenUllrich - 如果我没记错的话，ISN 是从每“4 毫秒”一次的计数器中读取的。我假设在第二次尝试中按那个时钟走。你有这方面的参考吗？
-
@Roam：丢失的数据包（包括 SYN）被重新传输，这意味着再次发送完全相同的数据包。相关标准是 RFC 793。
-
@SteffenUllrich - 那么 RFC793 图 9 中的情况如何呢？在行注释下方的 Q-- 部分中查看我的编辑。
标签： networking tcp