TCP归零窗口后的TCP重置

多年来，我们的定制软件使用打印机命令语言（PCL）在不同的打印机上打印

现在我们有一个新的，leightweight打印机，我们正在努力支持。一个简单的打印是完美的工作。但是，如果打印作业增大，我们会遇到打印作业中断

环境：

• 中间没有活动的网络硬件（如包检查防火墙）
• 工作站（这是我们的软件运行的地方）位于Linux内核版本3.0.101上。这里发生了下面描述的TCP重置

使用Wireshark，我们发现了以下情况：

• 我们看到打印机的TCP接收窗口大小每2-3秒变为零。这表明打印机硬件速度太慢，无法实时处理传入数据
• 此零窗口超时通常需要1-2秒
• 打印机向工作站发送“零窗口”确认数据包后，工作站尝试通过定期发送TCP保持活动数据包来保持与打印机的连接
• 打印机正在应答这个保持活动状态的数据包
• 打印机准备再次处理数据时，会向工作站发送一个“TCP窗口更新”数据包。此数据包包含打印机的新接收窗口大小。一旦工作站收到此数据包，它就开始再次向打印机发送数据

下面是刚刚解释的通信跟踪片段：

我对“TCP零窗口”机制的理解是，只要打印机应答工作站的保留数据包，通信的停止和重新启动就可以一直持续下去

然而，在我们的案例中，通信在一段时间后中断：

一段时间后（通常在1-3分钟后），工作站不再发送新的keepalive，而是重置通信。对于我们来说，这是无法解释的，因为之前的所有保持活动的数据包都会被打印机直接确认

我试图复制这个场景也没有成功。我编写了一个简单的TCP客户端和服务器。要强制出现TCP zero窗口，TCP服务器在一定时间内处于休眠状态，然后继续接收数据。 但是，无论服务器等待（睡眠）或中断传输多长时间，我都无法让这两个服务器中的任何一个重置通信。相反，上面描述的TCP keepalive/acknowledge算法是在空闲时间运行的，以保持连接处于活动状态

你有什么想法让我们的工作站在一个有效的TCP连接中间发送这个重置？