TCP 连接中服务端长时间处于 FIN_WAIT1 状态, 客户端是否无法收到 Close 事件?

• 資深大佬 : wish198

  按你这个说法,你客户端得自己判断出来主动关闭呀,TCP 四次挥手看下

• 主 資深大佬 : Mohanson

  @wish198 我看过 TCP 挥手过程, FIN_WAIT1 是等待对方 ACK. 我目前发现存在题目描述的现象, 但是无法在互联网上找到确切的文字资料来证明这种现象, 因此来问一下看看是否有大佬能提供下文字资料 /Spec 等等的东西证明我的猜测是正确的还是错误的…

• 資深大佬 : lhx2008

  如果客户端没收到 ，就不会确认相关的信息，服务端那边就超时，会重发 Close

• 資深大佬 : alcarl

  有可能对面的防火墙把你发过去的 fin 包过滤了，对面应用没有收到你的 fin，网络上没有其他东西的话，finwait1 阶段是内核控制的对面也是内核控制，应该会自己过度到 finwait2，对面过度到 closewait，然后才是对面应用处理。没进 closewait 客户端当然读不到 eof

• 資深大佬 : alcarl

  @Mohanson 搜索 tcp 四次挥手？

• 資深大佬 : unixeno

  查了一下这个问题，你可以看看这个 https://blog.huoding.com/2014/11/06/383，还有这个 https://blog.csdn.net/dog250/article/details/81697403

  在你服务端 close 之后，连接会立即进入 FIN_WAIT1 状态，如果客户端的接收缓冲区里还有数据，FIN 是不会影响客户端读取的。
  而且如果客户端一直不接收数据，以至于客户端接收队列满了，服务端的 FIN 是发不出去的，这个链接会一直处于 FIN_WAIT1 状态，只有重启系统或者等待零窗口探测包超过 tcp_orphan_retries 参数限制时触发销毁连接

• 主 資深大佬 : Mohanson

  @unixeno 谢谢，有个问题哈，如果 fin 包被拦截，那 tcp 对端是否永远也不知道这个链接被关闭了呢？

• 資深大佬 : bitcross

  @Mohanson 对，所以才有的 keepalive 的设计，及时检测出已经”不可达”的 session

  建议你用 wireshark 之类的抓包工具在客户端抓一下包，看看 fin 包到底有没送过来
  没有的话十有八九就是路由器，防火墙之类的给拦截了，这就要在这些网络设备里检查数据包日志了

• 主 資深大佬 : Mohanson

  @bitcross 好的, 谢谢!

• 資深大佬 : unixeno

  @Mohanson 也可以，需要你向对方发送数据，连接不存在的时候会直接 reset

  不通信的情况下，那肯定是没办法知道对方是不是还在线的

• 資深大佬 : Buges

  关键词：close()与 shutdown()的区别，自己去搜吧。

• 資深大佬 : wish198

  @Mohanson TCP 是有半关闭的,你找个 Wireshark 抓一下包就明白了,不是服务器发来 Fin,你的客户端就要自己关闭