Как уменьшить задержки TCP, вызванные сбросами ARP для MODBUS TCP

Question

У нас есть приложение, которое периодически отправляет TCP-сообщения с определенной скоростью (с использованием MODBUS TCP). Если сообщение не получено в течение установленного периода, сигнал тревоги поднимается. Однако время от времени происходит задержка при получении сообщений. Исследование показало, что это связано с обновлением кэша ARP, вызвав повторную отправку сообщения TCP.

Поставщик пакета IP сказал нам, что это ожидаемое поведение для TCP. Вопросы: Является ли это ожидаемым поведением для IP-стека? Если нет, как другие стеки работают в течение периода, когда трансляция IP/MAC-адресов недоступна Если это ожидаемое поведение, как мы можем уменьшить задержку в сообщениях TCP за этот период? (Постоянные записи ARP были опробованы, но не были лучшее решение)

Answer 1

В моей последней работе я работал с ротаторами и коммутаторами компании. Наша реализация будет представлять очередь пакетов, ожидающих ответы ARP, и отправлять их при получении ответа ARP. Поэтому не требуется повторная передача TCP.

Повторная передача в TCP происходит, когда ACK не принимается в течение заданного времени. Если ответ ARP занимает много времени или сам потерян, вы можете получить повторную передачу, даже если устройство, ожидающее ответа ARP, представляет очередь в очереди.

По вашему вопросу, что период сообщения TCP короче, чем время обновления ARP. Это означает, что повторное использование ARP не заставляет его оставаться обновленным, что является возможным поведением, которое было бы полезно в вашей ситуации.

Пакетная трассировка ситуации может быть полезна - вы фактически теряете первый пакет? Как долго ответ ARP?

Чтобы остановить тайм-аут кэша ARP, вы можете попытаться найти что-то, что обновит его, например, другой запрос ARP для того же адреса или бесплатный ARP. Я нашел спецификацию для MODBUS TCP, но это не помогло. Можете ли вы опубликовать некоторые сведения о своей сети - носители, устройства, скорости?

Answer 2

Ваше описание предполагает, что записи ARP одноранговой сети истекают между сегментами TCP и приводят к сбою некоторых последующих сегментов из-за отсутствия текущего адресата MAC.

Если у вас есть устройства MODBUS в отдельной подсети, возможно, маршрутизатор назначения будет достаточно любезен для очереди в сегменте, пока он не получит действительный MAC-адрес. Если вы не можете использовать отдельную подсеть, вы можете попытаться заставить сеанс активировать keep-alives - это приведет к отправке периодического пустого сообщения, которое позволит сбросить таймеры ARP-таймеров. Если накладные расходы на keep-alive слишком высоки, и вы полностью контролируете приложение в своей системе, вы можете попытаться принудительно передать сообщения с нулевой длиной в точку доступа.