![已经确认的数据序列号反复返回为空字节](https://linux22.com/image/645945/%E5%B7%B2%E7%BB%8F%E7%A1%AE%E8%AE%A4%E7%9A%84%E6%95%B0%E6%8D%AE%E5%BA%8F%E5%88%97%E5%8F%B7%E5%8F%8D%E5%A4%8D%E8%BF%94%E5%9B%9E%E4%B8%BA%E7%A9%BA%E5%AD%97%E8%8A%82.png)
我的应用程序(客户端)连接到一个事务处理服务器(TP 服务器)。我们看到一个奇怪的数据包序列,其中 TP 服务器发送一个带有空 (0) 字节数据的 PUSH 数据包,但该数据包的序列号不正确;该序列号是最后收到的字节的序列号。
请查看此处的 TCP 转储数据
http://pastebin.com/5UBXWazy
172.250.10.10.13824 是 TP 服务器。
172.11.105.5.49524 是客户端。
“TP-Server”不在我的控制范围内,不确定它在什么操作系统上运行。“Client”是我在 Debian Squeeze 上运行的支付应用程序。
您可以看到下面的数据包中TP-Server发送了一个空字节数据。
20:52:34.472819 IP (tos 0x0, ttl 59, id 51820, offset 0, flags [DF], proto TCP (6), length 53)
172.250.10.10.13824 > 172.11.105.5.49524: Flags [P.], cksum 0xe36f (correct), seq 1457045850:1457045851, ack 3097912286, win 17680, options [nop,nop,TS val 646012206 ecr 73190886], length 1
0x0000: 4500 0035 ca6c 4000 3b06 a941 acfa 0a0a E..5.l@.;..A....
0x0010: ac0b 6905 3600 c174 56d8 c15a b8a6 63de ..i.6..tV..Z..c.
0x0020: 8018 4510 e36f 0000 0101 080a 2681 5d2e ..E..o......&.].
0x0030: 045c cde6 00 .\...
上述空字节数据的序列号标记为 1457045850。但如下所示,该数据是在更早的时间接收的。
20:50:22.506267 IP (tos 0x0, ttl 59, id 51817, offset 0, flags [DF], proto TCP (6), length 607)
172.250.10.10.13824 > 172.11.105.5.49524: Flags [P.], cksum 0x6460 (correct), seq 1457045296:1457045851, ack 3097912253, win 17680, options [nop,nop,TS val 645999009 ecr 73187775], length 555
对于不正确的序列号,客户端会用一个 sack 标志来响应,表明不正确的序列号。
20:52:34.472864 IP (tos 0x0, ttl 64, id 1172, offset 0, flags [DF], proto TCP (6), length 64)
172.11.105.5.49524 > 172.250.10.10.13824: Flags [.], cksum 0x4501 (correct), seq 3097912286, ack 1457045851, win 2003, options [nop,nop,TS val 73220891 ecr 646012206,nop,nop,sack 1 {1457045850:1457045851}], length 0
TP-Server又重复发送了7次相同的空字节数据,并且序列号也都是错误的。Client也努力用sack回应。
20:58:29.024492 IP (tos 0x0, ttl 59, id 51827, offset 0, flags [DF], proto TCP (6), length 53)
172.250.10.10.13824 > 172.11.105.5.49524: Flags [P.], cksum 0x04bf (correct), seq 1457045850:1457045851, ack 3097912308, win 17680, options [nop,nop,TS val 646047661 ecr 73277952], length 1
0x0000: 4500 0035 ca73 4000 3b06 a93a acfa 0a0a E..5.s@.;..:....
0x0010: ac0b 6905 3600 c174 56d8 c15a b8a6 63f4 ..i.6..tV..Z..c.
0x0020: 8018 4510 04bf 0000 0101 080a 2681 e7ad ..E.........&...
0x0030: 045e 2200 00 .^"..
20:58:29.024553 IP (tos 0x0, ttl 64, id 1179, offset 0, flags [DF], proto TCP (6), length 64)
172.11.105.5.49524 > 172.250.10.10.13824: Flags [.], cksum 0x602c (correct), seq 3097912308, ack 1457045851, win 2003, options [nop,nop,TS val 73309529 ecr 646047661,nop,nop,sack 1 {1457045850:1457045851}], length 0
但是,当第 8 次发生同样的情况时,客户端停止提供确认。TP 服务器继续发送空字节数据 5 次,但客户端均未提供确认。此行为发生在网络堆栈级别,我可怜的客户端应用程序没有收到任何套接字错误,仅在时间“21:18:59”时,它收到了 getsocketopt err:110(我认为是 ETIMED_OUT)。因此,我的客户端应用程序等待了一段时间,并尝试在 21:21:38 重新连接(您可以看到 SYN 数据包)。但是,此后 TP 服务器没有响应。几分钟后重新启动“客户端”PC 后,TP 服务器接受了新连接。但是,相同的空字节数据包又开始重新出现。有时,会发生这样的情况,客户端有一些定期数据包需要以大约 10 秒的间隔发送到 TP 服务器,并且这保持连接处于活动状态,而不管是否仍出现空字节以及客户端是否使用 sack 进行响应。
我的问题:
发送这些带有错误序列号的空数据字节的原因是什么?
我应该对 debian 网络堆栈采取任何措施来处理这种情况以保持连接处于活动状态吗?