码迷,mamicode.com
首页 > 其他好文 > 详细

FIN_WAIT1 能持续多久?你知道吗

时间:2016-01-12 18:09:41      阅读:234      评论:0      收藏:0      [点我收藏+]

标签:

FIN_WAIT1 能持续多久?你知道吗

2016-01-12 运维帮

原文:http://blogread.cn/it/article/7215?f=wb&luicode=10000359

作者:火丁笔记

 

前些天,一堆人在 TCPCopy (https://github.com/session-replay-tools/tcpcopy) 社区里闲扯蛋,有人提了一个问题:FIN_WAIT1 能持续多久?引发了一场讨论,期间我得到@wangbin579和多位朋友的点化,受益良多。

 

 

让我们热热身,通过一张旧图来回忆一下 TCP 关闭连接时的情况:

 

技术分享

TCP Close

 

看图可知,主动关闭的一方发出 FIN,同时进入 FIN_WAIT1 状态,被动关闭的一方响应 ACK,从而使主动关闭的一方迁移至 FIN_WAIT2 状态,接着被动关闭的一方同样会发出 FIN,主动关闭的一方响应 ACK,同时迁移至 TIME_WAIT 状态。

 

回到开头的问题:FIN_WAIT1 能持续多久?一般情况下,服务器间的 ACK 确认是非常快的,以至于我们凭肉眼往往观察不到 FIN_WAIT1 的存在,不过网上也有很多案例表明在某些情况下 FIN_WAIT1 会持续很长时间,从而诱发问题。

最常见的误解是认为 tcp_fin_timeout 控制 FIN_WAIT1 的过期,从名字上看也很像,但实际上它控制的是 FIN_WAIT2 的过期时间,官方文档(https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt)是这样说的:

 

The length of time an orphaned (no longer referenced by any application) connection will remain in the FIN_WAIT_2 state before it is aborted at the local end. While a perfectly valid “receive only” state for an un-orphaned connection, an orphaned connection in FIN_WAIT_2 state could otherwise wait forever for the remote to close its end of the connection.
Cf. tcp_max_orphans
Default: 60 seconds

 

让我们通过一个实验来说明问题(服务端:10.16.15.107;客户端:10.16.15.109):

  1. 在服务端监听 1234 端口:「nc -l 1234」

  2. 在客户端连接服务端:「nc 10.16.15.107 1234」
    此时客户端连接进入 ESTABLISHED 状态

  3. 在服务端拦截响应:「iptables -A OUTPUT -d 10.16.15.109 -j DROP」

  4. 在客户端开启抓包:「tcpdump -nn -i any port 1234」

  5. 在客户端通过「ctrl + c」断开连接
    此时客户端连接进入 FIN_WAIT1 状态

 

随时可以通过「netstat -ant | grep :1234」来观察状态,最终抓包结果如下:

 

技术分享

TCP Fin

 

第一个 FIN 是我们按「ctrl + c」断开连接时触发的,因为我们在服务端通过 iptables 拦截了发送给客户端的响应,所以对应的 ACK 被丢弃,随后执行了若干次重试。

 

此外,通过观察时间我们还能发现,第一次重试在 200ms 左右;第二次是在 400ms 左右;第三次是在 800ms 左右;以此类推,每次的时间翻倍。

实际上,控制这一行为的关键参数是 tcp_orphan_retries,官方文档(https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt)是这样说的:

 

This value influences the timeout of a locally closed TCP connection, when RTO retransmissions remain unacknowledged. See tcp_retries2 for more details.
The default value is 8. If your machine is a loaded WEB server, you should think about lowering this value, such sockets may consume significant resources. Cf. tcp_max_orphans.

 

如果你用 sysctl 查询 tcp_orphan_retries 是 0,那么实际等同于 8,看代码:

 

技术分享

于是乎我们可以得出结论,如果你的系统负载较重,有很多 FIN_WAIT1,那么可以考虑通过降低 tcp_orphan_retries 来解决问题,具体设置多少视网络条件而定。

 

问题分析到这里原本可以完美谢幕,但是因为 TCP 有缺陷,导致 FIN_WAIT1 可能被用来发起DoS 攻击,所以我们就再唠十块钱儿的,看看到底是怎么回事儿:

 

假设服务端上有一个大文件,攻击者连接服务端发起请求,但是却不接收数据,于是乎就造成一种现象:客户端接收队列满,导致服务端不得不通过「zero window probes」来循环检测客户端是否有可用空间,以至于 tcp_orphan_retries 也没有用,因为服务端活活被憋死了,发不出 FIN 来,从而永远卡在 FIN_WAIT1。演示代码如下:

 

技术分享

说明:通常文件大小以 100K 为佳,具体取决于 tcp_rmem / tcp_wmem 的大小。

 

怎么办?病急乱投医,重启服务!可惜没用,因为 FIN_WAIT1 已经脱离的服务的管辖范围,所以重启服务是没有用的,如果一定要重启,你只能重启服务器!

 

好在内核已经考虑到了此类问题,它提供了 tcp_max_orphans 参数,用来控制 orphans 的最大值,需要注意的是,和用来控制 TIME_WAIT 的最大值的 tcp_max_tw_buckets 参数一样,除非你遇到了 DoS 攻击,否则最好不要降低它。

 

花絮:我曾经试图寻找一些工具来杀掉 FIN_WAIT1 连接,如果你要杀掉一个 TCP 连接,那么需要知道相应的 ACK 和 SEQ,然后才可以 RESET 连接。为了获取 ACK 和 SEQ,一些工具采用的是被动机制,它通过监听匹配的数据包来获取需要的数据,代表是tcpkill;另一些工具采用的是主动机制,它通过伪造请求来获取需要的数据,代表是killcx,如果有兴趣的话不妨试试它们。

最后,再次感谢 TCPCopy 社区!如果你从本文学到些许知识,那么这份荣幸属于 TCPCopy社区,如果你在本文发现谬误之处,那么全因本人笨拙,还望不吝赐教。

FIN_WAIT1 能持续多久?你知道吗

标签:

原文地址:http://www.cnblogs.com/archoncap/p/5125171.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!