Question

我一直在尝试找出HTTP客户端和HTTP服务器之间的TCP连接保持ESTABLISHED状态并持续存在的情况。对于1000多个连接中的1或2个连接，会发生这种情况。目前尚不清楚客户端/服务器是否有故障。

我写了一个python脚本（使用scapy）捕获所有TCP数据包以找出根本原因，我遇到了这种特殊情况，其中TCP SEQ和ACK似乎不匹配，这使我感到困惑。

这是来自scapy脚本的日志中有趣的部分：（在同一端口53332上有很多数据包之后）

2019-12-21 15:54:43 10.0.1.2:8080 -> 10.0.1.3:53332 [ A] seq:769374665 ack:844297577 len:0
2019-12-21 15:54:43 10.0.1.2:8080 -> 10.0.1.3:53332 [PA] seq:769374665 ack:844297577 len:90
HTTP/1.1 200 OK
content-type: application/json; charset=UTF-8
content-length: 389255
2019-12-21 15:54:43 10.0.1.2:8080 -> 10.0.1.3:53332 [ A] seq:769374755 ack:844297577 len:8949
2019-12-21 15:54:43 10.0.1.2:8080 -> 10.0.1.3:53332 [PA] seq:769383704 ack:844297577 len:8949
2019-12-21 15:54:43 10.0.1.2:8080 -> 10.0.1.3:53332 [ A] seq:769392653 ack:844297577 len:8949
2019-12-21 15:54:43 10.0.1.3:53332 -> 10.0.1.2:8080 [ A] seq:844297577 ack:769383704 len:0
2019-12-21 15:54:43 10.0.1.2:8080 -> 10.0.1.3:53332 [PA] seq:769401602 ack:844297577 len:8949
2019-12-21 15:54:43 10.0.1.2:8080 -> 10.0.1.3:53332 [ A] seq:769410551 ack:844297577 len:8949
2019-12-21 15:54:43 10.0.1.2:8080 -> 10.0.1.3:53332 [PA] seq:769419500 ack:844297577 len:8949
2019-12-21 15:54:43 10.0.1.3:53332 -> 10.0.1.2:8080 [ A] seq:844297577 ack:769401602 len:0
2019-12-21 15:54:43 10.0.1.2:8080 -> 10.0.1.3:53332 [ A] seq:769428449 ack:844297577 len:8949
2019-12-21 15:54:43 10.0.1.2:8080 -> 10.0.1.3:53332 [PA] seq:769437398 ack:844297577 len:8949
2019-12-21 15:54:43 10.0.1.2:8080 -> 10.0.1.3:53332 [ A] seq:769446347 ack:844297577 len:8949
2019-12-21 15:54:43 10.0.1.2:8080 -> 10.0.1.3:53332 [PA] seq:769455296 ack:844297577 len:8949
2019-12-21 15:54:43 10.0.1.2:8080 -> 10.0.1.3:53332 [ A] seq:769464245 ack:844297577 len:8949
2019-12-21 15:54:43 10.0.1.2:8080 -> 10.0.1.3:53332 [PA] seq:769473194 ack:844297577 len:8949
2019-12-21 15:54:43 10.0.1.3:53332 -> 10.0.1.2:8080 [ A] seq:844297577 ack:769446347 len:0
2019-12-21 15:54:43 10.0.1.2:8080 -> 10.0.1.3:53332 [ A] seq:769482143 ack:844297577 len:8949
2019-12-21 15:54:43 10.0.1.2:8080 -> 10.0.1.3:53332 [PA] seq:769491092 ack:844297577 len:8949

... scapy脚本在这里肯定错过了几个数据包...

2019-12-21 15:54:43 10.0.1.3:53332 -> 10.0.1.2:8080 [ A] seq:844297577 ack:769750613 len:0
2019-12-21 15:54:43 10.0.1.3:53332 -> 10.0.1.2:8080 [ A] seq:844297577 ack:769764010 len:0

几个小时后：

2019-12-21 17:54:45 10.0.1.2:8080 -> 10.0.1.3:53332 [ A] seq:769764009 ack:844297577 len:0
2019-12-21 17:54:45 10.0.1.3:53332 -> 10.0.1.2:8080 [ A] seq:844297577 ack:769764010 len:0

在15:54:43，客户端已响应769764010的ACK，表明它已接收到高达769764010的数据。2小时后，服务器正在发送769764009的SEQ，比ACK小1。并且客户端继续发送769764010的ACK。

我感到困惑，因为SEQ如何小于ACK（或者ACK如何大于SEQ）。我已经验证了在两个系统上，连接仍处于ESTABLISHED状态，因此两个都未发送FIN，从而导致seq编号增加。

我想念什么？

Answer 1

这实际上是@ user207421的答案，但是用户选择发表评论，所以我正在写此答案。

首先没有问题。这是TCP Keepalive数据包，所有TCP keep-alive数据包都只是一个ACK，其序列号设置为比当前连接的序列号小一个。

因此，实际上没有任何不匹配。

TCP中的SEQ和ACK不匹配

1 个答案: