☰

在 ip_conntrack 中，已建立但“卡住”的 TCP 连接，生存时间很长

tag-icon • tag-icon tcp
在 ip_conntrack 中，已建立但“卡住”的 TCP 连接，生存时间很长

我正在尝试了解我在我的（虚拟）服务器上的 /proc/net/ip_conntrack 中看到的一些奇怪条目的原因/如何处理。似乎有许多这样的连接与我的 Web 服务器建立/来自，处于 ESTABLISHED 状态，但显然生存时间很长，相当于几天（W = 我的服务器 IP，X = 另一方的 IP）：

tcp      6 431997 ESTABLISHED src=X dst=W sport=52177 dport=80 packets=2 bytes=92 src=W dst=X sport=80 dport=52177 packets=1 bytes=48 [ASSURED] mark=0 secmark=0 use=1
tcp      6 22299 ESTABLISHED src=X dst=W sport=10975 dport=80 packets=2 bytes=92 src=W dst=X sport=80 dport=10975 packets=1 bytes=48 [ASSURED] mark=0 secmark=0 use=1

tcp      6 330236 ESTABLISHED src=W dst=X sport=80 dport=4555 packets=1 bytes=1420 [UNREPLIED] src=X dst=X sport=W dport=80 packets=0 bytes=0 mark=0 secmark=0 use=1
tcp      6 374668 ESTABLISHED src=W dst=X sport=80 dport=55957 packets=1 bytes=1420 [UNREPLIED] src=X dst=W sport=55957 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=1

我不认为这是恶意的，可能只是 ip_conntrack 的一些怪癖，因为 (a) 随机抽样，这些连接似乎没有显示在 netstat 中，并且 (b) 我可以从自己的客户端 IP 中看到一些类似的条目。所以这看起来更像是 ip_conntrack 工作方式的一些怪异之处。

但我担心这些连接可能会占用资源，而且它们的存在似乎使 ip_conntrack 变得不可靠。有人能解释一下吗？

答案1

这与 conntrack 代码中的默认值有关。来源如下：

linux-source-2.6.38/net/netfilter/nf_conntrack_proto_tcp.c:
  73 static unsigned int tcp_timeouts[TCP_CONNTRACK_MAX] __read_mostly = {
  74         [TCP_CONNTRACK_SYN_SENT]        = 2 MINS,
  75         [TCP_CONNTRACK_SYN_RECV]        = 60 SECS,
  76         [TCP_CONNTRACK_ESTABLISHED]     = 5 DAYS,
  77         [TCP_CONNTRACK_FIN_WAIT]        = 2 MINS,
  78         [TCP_CONNTRACK_CLOSE_WAIT]      = 60 SECS,
  79         [TCP_CONNTRACK_LAST_ACK]        = 30 SECS,
  80         [TCP_CONNTRACK_TIME_WAIT]       = 2 MINS,
  81         [TCP_CONNTRACK_CLOSE]           = 10 SECS,
  82         [TCP_CONNTRACK_SYN_SENT2]       = 2 MINS,
  83 };

注意 ESTABLISHED 默认为 5 天。由于它们是 ESTABLISHED，我不会担心 conntrack 数据库中的资源利用率，它们可能在其他地方使用了更多的资源。从您的输出来看，它们看起来像是网络流量，在这种情况下，如果您遇到资源问题，您可能需要考虑降低 keepalive 设置。

相关内容