在调查一些瞬态网络问题时,我注意到似乎收到了大量 RST 数据包:
Tcp:
40091950 个主动连接打开
44754733 个被动连接打开
2840116 次失败的连接尝试
已收到 49571981 次连接重置
已发送 30748407 份重置
有人能评论一下这是否表明存在问题吗?这个数字似乎非常高,但我可能只是误解了结果。据我所知,当 TCP 连接未收到其正在发送的数据的 ACK 时,就会发送 RST。
我们正在运行几台 Centos 6.5 服务器,Web 应用程序在 tomcat 中运行,在 httpd 后面保持平衡。每个 tomcat 都会相互建立许多短暂的连接,所以这可能是由此导致的?
我做了一些分析,RST 数据包不是来自路由器或来自 1 个特定主机,而是似乎来自所有主机。
答案1
TCP 是一个状态机。对话双方都存在 TCP 连接,并且双方必须就连接的当前状态达成一致。
当系统收到与其连接视图不一致的数据时,通常会发生 TCP 重置。
维基百科有一个很棒的TCP 状态图解释所有可能的状态以及这些状态之间的有效转换。
至于您的问题,如果没有看到流量就很难判断,但是当一端关闭了连接但另一端仍有缓冲数据或正在发送的数据时,在拆除时看到重置是很常见的。
想象一下以下情况
HostA HostB
ESTABLISHED
Data ------------> 1. here is some data
<------------ ACK 2. i have received your data
Data ------------> 3. here is some data
<------------ ACK 4. i have received your data
Data ------> 5. (data hasn't reached HostB yet)
<------------ FIN 6. we're done here, close this connection
Data -----> 7. (data reaches HostB)
<------------ RST 8. i didn't expect this!
在 时6
,HostB 发送了一个FIN
,因此 HostB 的套接字进入FIN_WAIT1
并期待ACK
来自 HostA 的一个。
然而,HostB 收到的数据比预期的ACK
要多。向套接字发送数据FIN_WAIT1
是无效的,它与 HostB 的状态机所说的下一步有效步骤不一致。出了问题,因此发送了 Reset 以完全结束 TCP 对话。