如果一台机器死机，TCP连接如何终止？

如果在两台主机（A & B）之间建立了TCP连接，并假设主机A向主机B发送了5个八比特组，然后主机B发生了故障（由于原因不明）。主机A将等待确认，但没有得到它们，将重新发送八位组，并且还会减小发送方窗口大小。这会重复几次，直到窗口大小由于数据包丢失而缩小为零。我的问题是，接下来会发生什么？如果一台机器死机，TCP连接如何终止？

来源

2012-02-25 Jake

是不是这是syn flooding？ – 2012-06-16 00:44:30

在这种情况下，TCP最终超时等待确认并向应用程序返回错误。应用程序必须从TCP套接字读取/ recv以了解该错误，随后的写入/发送调用也将失败。直到TCP确定连接已经结束，写/发送调用不会失败，如果套接字缓冲区已满，它们将从应用程序或块中看到成功。

如果主机B在发送ACK后消失，主机A将不会了解该情况，直到它向B发送某些内容为止，否则最终会超时或导致ICMP错误。（通常，第一次写入/发送呼叫不会失败，因为TCP不会立即使连接失败，并且请记住，写入/发送呼叫在完成之前不会等待ACK）。

还要注意，重传不会减小窗口大小。

来源

2012-02-25 23:59:17 nos

现在请点击此link

一个很简单的回答你的问题在我的看法是，该连接将超时，将被关闭。存在的另一种可能性是，由于未响应的机器可能会生成一些ICMP错误。另外，如果坠毁的机器再次联机，则会观察到我上面粘贴的链接中描述的过程。

来源

2012-02-26 00:03:52

取决于操作系统的实施。简而言之，它将等待ACK并重新发送数据包，直到超时。那么你的连接将被拆除。准确地查看Linux中发生的情况here其他操作系统遵循类似的算法。

来源

2012-02-26 00:20:01 Vlad

在你的情况下，将生成一个FIN（由幸存的节点）并且连接最终会迁移到CLOSED状态。如果你持续在目标IP地址上输入netstat输出，你会看到从ESTABLISHED状态迁移到TIMED_WAIT，然后最终消失。

在你的情况，这将发生，因为TCP保持一个计时器来获得它发送的数据包的ACK。这个计时器不够长，所以检测会很快发生。然而，如果机器B在A获得ACK之后死亡，并且之后A不发送任何东西，那么上述定时器不能检测到相同的事件，然而另一个定时器（呼叫空闲超时）将检测到该条件并且连接将关闭。这个超时时间默认为高。但通常情况并非如此，机器A会尝试发送内容并检测发送路径中的错误状态。

简而言之，除了一种情况（空闲超时：默认情况下非常高），TCP本身足以智能地关闭连接（并让应用程序知道它）。

cforfun

来源

2012-02-26 06:39:30 cforfun

死亡机器如果死亡会怎样产生FIN？ – EJP 2012-02-27 09:34:05

@EJP：TCP FIN可以由两端生成：幸存端的错误处理可以在其实现中执行主动关闭，并且您可以在存活节点中的此连接的netstat输出中观察FIN_WAIT_1状态。 – cforfun 2012-02-27 16:31:12

但是如果它在生成FIN之前死亡呢？ – EJP 2012-02-27 23:49:04

在正常情况下，每一侧通过发送特殊消息具有FIN（光洁度）终止其连通的端位设置。接收到该FIN的设备回应FIN的确认以表明它已被接收。连接作为一个整体不会被视为终止，直到两个设备通过发送FIN并接收确认完成关闭过程。

来源

2014-07-03 17:21:01 user3802714

如果一台机器死机，TCP连接如何终止？

回答

相关问题