Самый надежный и эффективный размер пакета udp?

Question

Будет ли отправлять партии небольшими пакетами UDP, чтобы получить больше ресурсов (процессор, сжатие по zlib и т. Д.). Я прочитал here, что отправка одного большого пакета ~ 65kBYTE по UDP, вероятно, завершится неудачно, поэтому мне кажется, что отправка множества меньших пакетов будет выполняться чаще, но затем наступает вычислительная нагрузка на использование большей вычислительной мощности (или, по крайней мере, то, что я предположим). Вопрос в основном таков; каков наилучший сценарий для отправки максимальных успешных пакетов и сведение к минимуму вычислений? Есть ли определенный размер, который работает большую часть времени? Я использую Erlang для сервера и Enet для клиента (написанный на C++). С помощью сжатия Zlib также я отправляю одни и те же пакеты каждому клиенту (трансляция - это термин, который я предполагаю).

Answer 1

Максимальный размер UDP payload, что большую часть времени, не вызывает фрагментацию IP является

MTU size of the host handling the PDU (most of the case it will be 1500) - 
size of the IP header (20 bytes) - 
size of UDP header (8 bytes) 

1500 MTU - 20 IP hdr - 8 UDP hdr = 1472 bytes 

@EJP говорил о 534 байт, но я бы исправить его 508. Это число байтов, которые точно не вызывают фрагментации, так как минимальный размер MTU, что хост может установить это и IP header max size может быть 60 bytes(508 = 576 MTU - 60 IP-- 8, UDP)

Кстати, я постараюсь пойти с 1472 байтами, потому что 1500 - это стандартное значение.

Используйте 1492 вместо 1500 для расчета, если вы проходите через соединение PPPoE.

Answer 2

534 байт. Это необходимо передать без фрагментации. Конечно, он все равно может быть потерян. Накладные расходы, связанные с повторной передачей потерянных пакетов и самих сетевых накладных расходов, на несколько порядков больше, чем стоимость процессора.

Answer 3

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

Answer 4

Будет ли отправлять партии небольшими пакетами UDP, чтобы получить больше ресурсов?

Да, это было бы, безусловно! Я просто экспериментировал с потоковым приложением. Приложение отправляет 2000 кадров данных каждую секунду, точно рассчитанную. Полезная нагрузка данных для каждого кадра составляет 24 байта. Я использовал UDP с sendto(), чтобы отправить эти данные в приложение-слушатель на другом узле.

Что я нашел, было интересно. Этот уровень активности заставил мой процессор переместиться на колени! У меня было около 64% ​​свободного времени процессора, до 5%! Это было катастрофой для моего приложения, поэтому я должен был это исправить. Я решил поэкспериментировать с вариациями.

Во-первых, я просто прокомментировал вызов sendto(), чтобы посмотреть, как выглядели потоки сборки пакетов. Около 1% ударов по процессорному времени. Неплохо. ОК ... должно быть sendto() звонок!

Затем я сделал быстрый тест на фальшивку ...Я вызвал API sendto() только один раз в каждые 10 итераций, но я заполнил запись данных в 10 раз по сравнению с предыдущей длиной, чтобы имитировать эффект сборки коллекции меньших записей в более крупную, отправляемую реже. Результаты были вполне удовлетворительными: 7% процессор попал, по сравнению с 59% ранее. Казалось бы, по крайней мере, в моей * NIX-подобной системе операция отправки пакета дорого стоит только накладных расходов на выполнение вызова.

На всякий случай, если кто-либо сомневается в правильности работы теста, я проверил все результаты с наблюдением Wireshark о действительных передачах UDP, чтобы подтвердить, что все работает так, как должно.

Заключение: он использует МНОГО меньше процессорного времени, чтобы отправлять более крупные пакеты реже, а затем столько же данных в виде более мелких пакетов, отправляемых более часто. По общему признанию, я не знаю, что произойдет, если UDP начнет фрагментировать вашу слишком большую UDP-дейтаграмму ... Я имею в виду, что я не знаю, сколько добавочных ресурсов процессора это добавляет. Я попытаюсь выяснить (я хотел бы узнать себя) и обновить этот ответ.