我试图了解我在（虚拟）服务器上/ proc / net / ip_conntrack中看到的一些奇怪条目的原因。 在ESTABLISHED状态下，似乎有很多来自/从我的Web服务器的连接，但显然有相当多的时间等于几天（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不可靠。 任何人都可以摆脱任何光？
这与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数据库中的资源利用率，他们可能在其他地方使用更多的资源。 从你的输出看，他们看起来像networkingstream量，在这种情况下，如果你遇到资源问题，你可能会考虑降低keepalive设置。