识别IIS中CLOSE_WAIT过多的原因

Question

我有一个windows服务器运行一个为android应用提供服务的web，今天我开始收到警报，说我的服务器正在超时。

此服务器运行在Cloud之后。

当我通过RDC连接到服务器时，我注意到它使用了0%的CPU，但是有3200多个连接，如下所示：连接。

连接的“正常”数量将接近300。所以它多了10倍。

我以为它被攻击了，然后我从cloudflare激活了“我在攻击模式”，但是它根本没有工作。

我通过运行iisreset重新启动IIS，几分钟后它恢复正常，然后连接的数量又开始增加！

我跳进云照明支持聊天，支持代理说，他没有看到任何异常，他们没有什么可以做的。

我的服务器只允许来自CF服务器的连接。

我决定检查这些连接是什么，当我运行netstat时，我得到了以下内容：

Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    xxx:80       CF_IP_ADDRESS.157:13824  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.157:17952  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.173:21754  ESTABLISHED
  TCP    xxx:80       CF_IP_ADDRESS.173:22890  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.173:24456  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.173:55678  ESTABLISHED
  TCP    xxx:80       CF_IP_ADDRESS.173:63352  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.195:31634  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.195:56504  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.195:62466  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.205:14264  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.205:37858  ESTABLISHED
  TCP    xxx:80       CF_IP_ADDRESS.205:47142  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.205:50318  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.205:57534  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.205:63570  ESTABLISHED
  TCP    xxx:80       CF_IP_ADDRESS.211:35054  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.217:26940  ESTABLISHED
  TCP    xxx:80       CF_IP_ADDRESS.217:29042  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.217:37898  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.217:39096  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.217:46002  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.217:63860  CLOSE_WAIT

这只是3622行中的几行。

有趣的是，在这3622行中，2992将这个CLOSE_WAIT作为状态。

正如我说的，如果我运行iisreset，所有的东西都会正常工作几分钟，然后才开始超时给真正的用户。

CF支持说，他们看不到任何异常，所以我不确定这是否是一次攻击或什么。

服务器正在运行IIS，会不会是个bug？是否有任何攻击遵循这种模式，并会留下大量的CLOSE_WAIT连接？

任何帮助都会很感激的。

服务器正在运行Windows server 2016和IIS 10。

Answer 1

好的，我会在这里发布我的发现，以防万一有人需要。

在这个问题开始发生的前10个小时，我已经运行了windows更新并安装了KB5005698。此更新安装在支持android应用程序的2台服务器上。

奇怪的是，这个问题同时发生在两个服务器上，这就是我最初怀疑这是一次攻击的原因。

当服务器不再处于高负载状态时，问题就停止了，我决定将web从.net 5迁移到.net 6，我安装了服务器包并进行了部署。

由于问题在迁移.net版本之前就停止了，所以没有什么改变，所以我就把它留在了那里。

大约4个小时前，我又开始收到警报，但这次是因为web返回过多的http 500，但连接的数量是正常的。因此，我决定将应用程序恢复为.net 5版本。

当我这么做的时候，连接的数量开始增加，在一分钟内达到了5k，超时也是免费的！我继续运行iisreset，同样的模式再次发生。

所以我又把它换成了.net 6，没有增加更多的连接，但是过了一段时间，HTTP500s。

原来，http 500是一个简单的代码修复程序，所以我修复了它，并重新部署了它，目标是.net 6。

因此，没有更高的联系，一切似乎都很顺利。

因此，我得出的结论是，问题在于KB5005698和.net 5。

针对.net 6部署相同的应用程序解决了问题。

在经历了数千次糟糕的评论和收入损失之后，一切又回来了.

吸取教训..。如果不需要的话，我再也不会更新服务器了。

希望它能帮到别人。