如何减少MODBUS TCP的ARP刷新导致的TCP延迟

我们有一个应用程序，它以定义的速率定期发送TCP消息（使用MODBUS TCP）。如果在设定的时间段内未收到消息，则会发出警报。然而，每隔一段时间，接收到的消息就会出现延迟。调查表明，这与刷新ARP缓存导致TCP消息重新发送有关

IP堆栈提供商告诉我们，这是TCP的预期行为。问题是,， 这是IP堆栈的预期行为吗？如果没有，在IP/MAC地址转换不可用的时期，其他堆栈如何工作

---

如果这是预期的行为，我们如何在这段时间内减少TCP消息的延迟？（已经尝试了永久ARP条目，但不是最佳解决方案）

在我的上一份工作中，我与一家制造路由器和交换机的公司一起工作。我们的实现将对等待ARP回复的数据包进行排队，并在收到ARP回复时发送它们。因此，不需要TCP重新传输

TCP中的重传发生在给定时间内未收到ACK时。如果ARP应答需要很长时间，或者自身丢失，则即使等待ARP应答的设备正在排队等待数据包，您也可能会获得重新传输

从您的问题看来，TCP消息的周期比ARP刷新时间短。这意味着ARP的重用并不会导致它保持刷新状态，这可能对您的情况有所帮助

对发生的情况进行数据包跟踪可能会有所帮助-您是否确实丢失了第一个数据包？ARP回复需要多长时间

为了停止ARP缓存超时，您可能需要尝试查找一些可以刷新它的内容，例如对同一地址的另一个ARP请求，或者免费的ARP。

---

我找到了MODBUS TCP的规范，但没有帮助。您能否发布一些网络的详细信息-媒体、设备、速度？

您的描述表明对等ARP条目在TCP段之间过期，并由于缺少当前MAC目的地而导致某些后续段失败

如果MODBUS设备位于一个单独的子网中，那么目标路由器可能会对段进行排队，直到收到有效的MAC。如果无法使用单独的子网，可以尝试强制会话激活keep alives-这将导致定期发送空消息，从而保持ARP计时器重置。如果keep-alive的开销太高，并且您完全控制了系统中的应用程序，那么您可以尝试强制将零长度消息传递给对等方