在linux里面 FIN-WAIT-1 停留多久？

Question

如果在主动关闭端发送一个FIN给另外一端，而此时这对TCP连接之间的网络已经不通
（此时可以让TCP另外一端的机器down掉），TCP连接的两端还没有超时，也没有感
知到TCP连接已经失效，那么主动关闭端的TCP会在FIN-WAIT-1停留多久呢？

Answer 1

如果对端无法发送ack M+1和 FIN N，可能永远停留在这个状态，被动端处于CLOSE_WAIT状态

Answer 2

这个FIN-WAIT-1持续时间的问题正好也困扰着我！
查了RFC和各种文档，一直没找到FIN-WAIT-1的超时约定，都是只提到FIN-WAIT-2和TIME-WAIT超时。。。
我是在Windows平台下遇到的FIN_WAIT_1，有时会终止，有时会持续数小时。。。不解啊。。。

Answer 3

如果出现这种情况，基本就在那里等了，因为FIN-WAIT-1的状态等待是没有超时的，主要原因是不明确Server端应用的情况，不能够设置超时，在这个层面上就只能傻等。

Answer 4

如果出现这种情况，基本就在那里等了，因为FIN-WAIT-1的状态等待是没有超时的，主要原因是不明确Server端应 ...
沉寂 发表于 2011-08-23 11:37

按照我理解，FIN-WAIT-1等的是对端的ACK（对方回应我方发的FIN），而不是等对方关闭另个方向的连接（对方ACK后再发的FIN）。

这个等ACK照常理应该有TimeOut啊？不然这设计不就有缺陷了吗？

Answer 5

按照我理解，FIN-WAIT-1等的是对端的ACK（对方回应我方发的FIN），而不是等对方关闭另个方向的连接（ ...
CloudF_N 发表于 2011-08-25 11:51

    正相反，这个不是设计缺陷，因为ACK是由Server端的应用发出的，应用的情况是非常复杂的，强制设置超时，反而是设计缺陷。这个是信令层面层面的设计，和数据应用本身就应该是可分离的。设计本身是没有错，要防止出现这种情况，可以通过应用层面的心跳之类的来加以辅助判断，是可以避免。

Answer 6

本帖最后由 CloudF_N 于 2011-09-06 11:54 编辑

正相反，这个不是设计缺陷，因为ACK是由Server端的应用发出的，应用的情况是非常复杂的，强制设置 ...
沉寂 发表于 2011-08-25 23:49

你这个理论是哪来的？有文档吗？

我都是个人想法：我觉得这个Ack不该是应用层决定发不发的（因为只是Ack，而不是在Ack后再发FIN去关闭另半个方向的连接以形成半关闭，我觉得所有Ack都应该是tcpip驱动层面控制的）

我这里讨论的Ack是4次握手中的第2个哦，被动关闭端该应答的那个，整个TCP正常关闭过程我总结如下（这里谁主动关闭，是由应用层决定的）：

1    主动关闭端A：发FIN，进入FIN-WAIT-1状态，并等待......
2-1 被动关闭端P：收到FIN后必须立即发ACK，进入CLOSE_WAIT状态，并等待......
2-2 主动关闭端A：收到ACK后进入FIN-WAIT-2状态，并等待......
3    被动关闭端P：发FIN，进入LAST_ACK状态，并等待......
4-1 主动关闭端A：收到FIN后必须立即发ACK，进入TIME_WAIT状态，等待2MSL后结束Socket
4-2 被动关闭端P：收到ACK后结束Socket

这里一共有5个等待：

FIN-WAIT-2、LAST_ACK、TIME_WAIT是明文规定了必须有Time Out
CLOSE_WAIT是规定了可以永久下去（也就是正常的半关闭）
为什么偏偏就FIN-WAIT-1是没有规定的？就算没规定，我也不觉得它该死等啊，因为我不认同ACK是该由应用层发的。再退一步，就算应用层ACK了，但包在传输中丢了，你说怎么办吧？。。。

Answer 7

顶一下，求解。。。