如何减少 MODBUS TCP 的 ARP 刷新导致的 TCP 延迟
我们有一个应用程序以定义的速率定期发送 TCP 消息（使用 MODBUS TCP）。如果在设定的时间内未收到消息，则会发出警报。然而，每隔一段时间，消息接收就会出现延迟。调查表明，这与刷新 ARP 缓存导致重新发送 TCP 消息有关。
IP 堆栈提供商告诉我们这是 TCP 的预期行为。问题是， 这是 IP 堆栈的预期行为吗？如果不是，其他堆栈如何在 IP/MAC 地址转换不可用期间工作 如果这是预期的行为，我们如何减少在此期间 TCP 消息的延迟？（已尝试过永久 ARP 条目，但不是最佳解决方案）
We have an application which is periodically sending TCP messages at a defined rate(Using MODBUS TCP). If a message is not received within a set period an alarm is raised. However every once in a while there appears to be a delay in messages being received. Investigation has shown that this is associated with the ARP cache being refreshed causing a resend of the TCP message.
The IP stack provider have told us that this is the expected behaviour for TCP. The questions are,
Is this expected behaviour for an IP stack? If not how do other stacks work around the period when IP/MAC address translation is not available
If this is the expected behaviour how can we reduce the delay in TCP messages during this period?(Permanent ARP entries have been tried, but are not the best solution)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在我的上一份工作中，我在一家制造路由器和交换机的公司工作。我们的实现将对等待 ARP 回复的数据包进行排队，并在收到 ARP 回复时发送它们。因此，不需要 TCP 重传。
当在给定时间内未收到 ACK 时，TCP 中就会发生重传。如果 ARP 回复需要很长时间，或者本身丢失，则即使等待 ARP 回复的设备正在对数据包进行排队，您也可能会收到重传。
从你的问题来看，TCP消息的周期比ARP刷新时间短。这意味着 ARP 的重用不会导致它保持刷新，这可能是对您的情况有帮助的行为。
对发生的情况进行数据包跟踪可能会有所帮助 - 您是否真的丢失了第一个数据包？ ARP回复需要多长时间？
为了阻止 ARP 缓存超时，您可能需要尝试找到可以刷新它的东西，例如对同一地址的另一个 ARP 请求，或免费 ARP。
我找到了 MODBUS TCP 的规范，但没有帮助。您可以发布一些有关您的网络的详细信息 - 媒体、设备、速度吗？
In my last job I worked with a company building routers and switches. Our implementation would queue packets waiting for ARP replies and send them when the ARP reply was received. Therefore, no TCP retransmit required.
Retransmission in TCP occurs when an ACK is not received within a given time. If the ARP reply takes a long time, or is itself lost, you might be getting a retransmission even though the device waiting for the ARP reply is queuing the packet.
It would appear from your question that the period of the TCP message is shorter than the ARP refresh time. This implies that reuse of the ARP is not causing it to stay refreshed, which is possible behaviour that would be helpful in your situation.
A packet trace of the situation occurring could be helpful - are you actually losing the first packet? How long does the ARP reply take?
In order to stop the ARP cache timing out, you might want to try to find something that will refresh it, such as another ARP request for the same address, or a gratuitous ARP.
I found a specification for MODBUS TCP but it didn't help. Can you post some details of your network - media, devices, speeds?
您的描述表明对等 ARP 条目在 TCP 段之间过期，并导致某些后续段由于缺少当前 MAC 目标而失败。
如果 MODBUS 设备位于单独的子网上，那么目标路由器可能会善意地将网段排队，直到收到有效的 MAC。如果您无法使用单独的子网，您可以尝试强制会话激活保持活动状态 - 这将导致定期发送空消息，从而使 ARP 计时器保持重置。如果保持活动的开销太高并且您完全控制系统中的应用程序，则可以尝试强制将零长度消息传递到对等点。
Your description suggests that the peer ARP entries expire between TCP segments and cause some subsequent segments to fail due to the lack of a current MAC destination.
If you have the MODBUS devices on a separate subnet, then perhaps the destination router will be kind enough to queue the segment until it receives a valid MAC. If you cannot use a separate subnet, you could try to force the session to have keep-alives activated - this would cause a periodic empty message to be sent that would keep the ARP timers resetting. If the overhead of the keep-alive is too high and you completely control the application in your system, you could try to force zero-length messages through to the peer.