Как уменьшить задержки, вызванные ложной повторной передачей TCP сервера и последующей повторной передачей TCP клиента?

Question

У меня есть приложение Dotnet (работающее на ПК с Windows), которое взаимодействует с Linux-системой через OPC UA. Вариант использования здесь - сделать ~40 запросов на чтение к серверу последовательно. После завершения этих 40 вызовов чтения начинается следующий цикл из 40 вызовов чтения. Каждый вызов чтения возвращает ответ от сервера, содержащий полезную нагрузку размером ~16 КБ, которая фрагментируется и доставляется клиенту. Для большинства запросов сервер завершает доставку полного ответа в течение 5 мс. Однако для некоторых запросов требуется ~300 мс.

В сценариях, где существует эта задержка, я вижу следующую схему повторных передач.

1. [71612] На сервер отправлен новый запрос на чтение.
2. [71613-71630] Ответ доставлен клиенту.
3. [71631] На сервер отправлен новый запрос на чтение.
4. [71632] Произошла ложная повторная передача TCP с сервера для пакета [71844] с порядковым номером 61624844.
5. [71633] Клиент отправляет DUP ACK для пакета.
6. [71634] Клиент выполняет повторную передачу TCP для запроса на чтение в [71846] через 288 мс.

Эта задержка суммируется и вызывает 5-6-секундную задержку для завершения полного цикла из 40 запросов. Я хочу выяснить, что вызывает эти повторные передачи (следовательно, задержки) и что можно сделать, чтобы...

1. Уменьшите частоту повторных передач.
2. Уменьшите задержку на 300 мс со стороны клиента, чтобы быстро повторно передать заблокированный запрос на чтение.

Я попытался отключить алгоритм Nagle на сервере, чтобы повысить производительность, но это не дало никакого эффекта. Кроме того, при уменьшении размера ответа наполовину (8 КБ) повторные передачи редки, и, следовательно, задержка также незначительна. Но уменьшение ответа не является допустимым решением в нашем случае использования.

Соединение с ящиком Linux осуществляется через коммутатор, однако при прямом подключении к нему точка-точка задержка незначительно снижается.

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