После долгих копаний я, кажется, нашел решение проблемы.
Microsoft предоставила исправление для Windows Server 2012, позволяющее обойти базовый механизм фильтрации для входящих многоадресных потоков: https://support.microsoft.com/en-us/help/2808584/datagram-loss-when-you-run-a- многоадресной приемо-приложения-в-окна
Тем не менее исправление недоступно для Windows Server 2012 R2. Но потом я нашел этот пост: https://personalnexus.wordpress.com/2017/02/06/the-case-of-multicast-message-loss-on-windows-server-2012-r2/
Итак, к настоящему времени у меня есть полный контрольный список вещей, которые нужно настроить на наших серверах, и убедиться, что в наших приложениях используются многоадресные сообщения, чтобы убедиться, что все работает гладко и потеря сообщений поддерживается на приемлемом уровне. Тем не менее, на наших последних машинах с Windows Server 2012 R2 у меня были приложения с серьезной потерей дейтаграмм, так как объем сетевого трафика (в общем, не только многоадресной) на машине увеличился.
Я исследовал проблему в Интернете и получил советы, которые вы ожидали: получить последние драйверы NIC, увеличить размеры приемного буфера NIC, включить разгрузку, включить масштабирование на стороне приема, точно настроить масштабирование на стороне приема, увеличить размеры буфера сокетов и т. Д. Конечно, я уже попробовал все эти вещи, и ни одна из них не сработала
Решение по сообщению в блоге:
К сожалению, в документе описана проблема в Windows Server 2012, и доступное там исправление не может быть установлено в Windows Server 2012 R2. К счастью, это не должно быть. Вы можете просто установить ключ реестра, и базовый механизм фильтрации поддерживает его из коробки.
New-ItemProperty HKLM:\System\CurrentControlSet\services\Tcpip\Parameters\ -Name UdpExemptPortRange -Value "XXXX-YYYY" -PropertyType MultiString -Force До сих пор потоки снова работают нормально. Очевидно, что BFE не может обрабатывать огромное количество входящего UDP-трафика, когда также имеется достаточное количество исходящего UDP-трафика.