Повышение надежности UDP

Question

Я строю небольшой сервер на основе UDP.Сервер основан на .Net и использует класс Socket самостоятельно.Я использую порты завершения через ReceiveMessageFromAsync и асинхронную отправку.

Моя проблема в том, что я теряю около 5-10% своего трафика.Теперь я понимаю, что это нормально, но есть ли способ улучшить эту статистику?

Answer 1

Возможно, вы захотите взглянуть на ответы на этот вопрос, прежде чем накатывать свой собственный уровень надежности поверх UDP ... Что вы используете, когда вам нужен надежный UDP?

В качестве альтернативы вы можете попытаться увеличить объем передаваемых данных, сделав буферы отправки и записи сокета как можно большего размера, установив соответствующие параметры сокета перед началом восстановления.

Answer 2

Убедитесь, что вы не отправляете дейтаграммы UDP больше, чем MTU пути (который обычно не превышает ~ 1400 байт, а иногда и меньше).Такие пакеты будут фрагментированы на несколько IP-пакетов и повторно собраны в месте назначения - и если какой-либо один из этих фрагментов будет потерян, то вся дейтаграмма UDP будет отброшена.

Это имеет усилениевлияние на скорость потери пакетов - эта таблица показывает, как интенсивность потерь дейтаграммы UDP резко возрастает с увеличением количества фрагментов, используемых для ее передачи:

Underlying Fragment Loss Rate: 1.00%

Fragments   UDP Datagram Loss Rate
--------------------------------------
1           1.00%
2           1.99%
3           2.97%
4           3.94%
5           4.90%
6           5.85%
7           6.79%
8           7.73%
9           8.65%
10          9.56%
15          13.99%
20          18.21%
30          26.03%
40          33.10%

Answer 3

Архитектура Windows для сокетов, кажется, препятствует хорошей производительности UDP из-за многократного копирования буферов пакетов из ядра через обработчики протоколов в приложение. MSDN, похоже, предпочитает указывать разработчикам ядро ​​Winsock (WSK), заменяя прежний интерфейс драйвера транспорта (TDI), если они хотят разумной производительности дейтаграмм, такой как реализация надежного протокола UDP.

Однако это могут быть не звездные драйверы Windows для вашего сетевого адаптера, поскольку я вижу отличную производительность в Linux с оборудованием Broadcom, но менее 25% производительности в Windows. Отчасти это я вижу из-за отсутствия объединения прерываний передачи, мониторинг производительности Windows всегда сообщает 0 объединений для передач, но переменный диапазон для приема. В Linux я могу настроить объединение и увидеть четкие изменения производительности. По-видимому, программное обеспечение драйвера от Broadcom поддерживает объединение передачи в более поздних выпусках оборудования.

Объединение означает, что пакеты отправляются пакетами в сетевую карту и из нее, пакетные пакеты обычно означают более низкую загрузку ЦП и меньшую вероятность сброса из-за полных буферов или другой системной активности.

Таким образом, хотя менять операционную систему нецелесообразно, вы можете попробовать другое оборудование, чтобы минимизировать влияние ограниченных драйверов.

Answer 4

Другим аспектом снижения потерь пакетов является обеспечение скорости, с которой вы отправляете пакеты. Если вы отправляете данные быстрее, чем может обработать точка узкого места на пути, это станет очевидным в виде отброшенных пакетов. Даже если ваша средняя скорость передачи данных довольно низкая, вы все равно можете отправлять пакеты пакетов в быстрой последовательности.

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

Answer 5

Все, что вы можете сделать, - это что-то в том же общем порядке, что и протокол TCP - отслеживать, какие пакеты были получены, и отправлять что-то обратно в пакеты ACK / NAK, чтобы получить те, которые не были отправлены повторно.