有一个事务处理服务器（TP-Server），我的应用程序（客户端）连接到这个服务器。 我们看到一个奇怪的数据包序列，在TP-Server正在发送一个零（0）字节数据的PUSH数据包，但是这个数据包的序列号是不正确的; 序号是最后收到的字节的序号。
请看这里的TCP转储数据
http://pastebin.com/5UBXWazy
TP-Server是172.250.10.10.13824。
客户端是172.11.105.5.49524。
“TP-Server”不在我的控制之下，不知道它在运行什么操作系统。 “客户端”是我在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
对于不正确的序列号，客户用一个表示不正确序列号的麻袋标志作出响应。
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次，错误的序号相同。 客户狡猾地用麻袋回应。
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
但是，第八次发生同样的情况，客户停止付款。 TP-Server继续发送空白字节数据5次，因为没有一个客户端用ack响应。 这种行为发生在networking堆栈级别，而我的可怜的客户端应用程序没有得到任何套接字错误，只有在“21:18:59”，它收到getsocketopt错误：110（我认为是ETIMED_OUT）。 所以，我的客户端应用程序，等待了更多的时间，并试图在21:21:38重新连接（你可以看到SYN数据包）。 但是，之后TP-Server没有响应。 几分钟后重新启动“客户端”PC后，TP-Server接受新的连接。 但是，相同的空字节分组又开始重新出现。 有时，事实上，客户端有一些周期性的数据包要以大约10秒的时间间隔发送到TP-服务器，这使得连接保持活动状态，不pipe仍然发生空字节，客户端响应麻袋。
我的问题：
这些空数据字节以不正确的序列号发送的原因是什么？
我应该做任何关于debiannetworking堆栈来处理这种情况，以保持连接活着？