TCP零窗口后TCP重置

Question

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

现在我们正在尝试支持一种新的轻量级打印机。简单的印刷工作完美无瑕。但是，如果打印作业的大小增加，我们会遇到打印作业的中断。

环境：

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

使用Wireshark，我们发现了以下内容：

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

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

我对“TCP零窗口”机制的理解是，只要打印机正在回答工作站的keepalive数据包，就可以停止和重新启动通信。

但是，在我们的案例中，通信会在一段时间后中断：

一段时间后（通常在1-3分钟后）工作站不再发送新的保持活动状态，但正在重置通信。对于我们来说，这是不可解释的，因为所有以前的保持活动包直接由打印机确认。

我也没有成功尝试复制场景。我写了一个简单的TCP客户端和服务器。为了强制TCP零窗口发生，TCP服务器正在休眠一段时间，而不是继续接收数据。 但是，无论服务器等待多长时间（睡眠）或中断传输，我都无法让两者中的任何一个重置通信。相反，上述TCP keepalive / acknowledge算法在空闲时间运行，保持连接存活。

您是否有任何想法使我们的工作站在有效的TCP连接中发送此重置？