Будет отправлять партии небольшими пакетами UDP, чтобы получить больше ресурсов (процессор, сжатие zlib и т.д.). Я прочитал здесь, что отправка одного большого пакета ~ 65kBYTE по UDP, вероятно, завершится неудачно, поэтому мне кажется, что отправка множества меньших пакетов будет выполняться чаще, но потом вычислительные накладные расходы на использование большей вычислительной мощности (или, по крайней мере, то, что я предполагаю). Вопрос в основном таков; каков наилучший сценарий для отправки максимальных успешных пакетов и сведение к минимуму вычислений? Есть ли определенный размер, который работает большую часть времени? Я использую Erlang для сервера и Enet для клиента (написанный на С++). Использование сжатия Zlib также и я отправляю одни и те же пакеты каждому клиенту (трансляция - это термин, который я предполагаю).
Самый надежный и эффективный размер пакета udp?
Ответ 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, который может установить хост, равен 576, а IP header max size может быть 60 bytes (508 = 576 MTU - 60 IP - 8 UDP)
Кстати, я бы попытался пойти с байтами 1472, потому что 1500 является стандартным значением.
Используйте 1492 вместо 1500 для вычисления, если вы проходите через PPPoE соединение.
Ответ 2
Будет ли отправлять партии небольшими пакетами UDP, чтобы получить больше ресурсов?
Да, это определенно! Я просто экспериментировал с потоковым приложением. Приложение отправляет 2000 кадров данных каждую секунду, точно рассчитанную. Полезная нагрузка данных для каждого кадра составляет 24 байта. Я использовал UDP с sendto() для отправки этих данных в приложение-слушатель на другом node.
То, что я нашел, было интересно. Этот уровень активности заставил мой процессор переместиться на колени! У меня было около 64% свободного времени процессора, до 5%! Это было катастрофой для моего приложения, поэтому я должен был это исправить. Я решил экспериментировать с вариациями.
Во-первых, я просто прокомментировал вызов sendto(), чтобы увидеть, как выглядели потоки сборки пакетов. Около 1% ударов по процессорному времени. Неплохо. OK... должен быть вызов sendto()!
Затем я сделал быстрый тест fakeout... Я вызвал API sendto() только один раз в каждые 10 итераций, но я заполнил запись данных в 10 раз по сравнению с предыдущей длиной, чтобы имитировать эффект сборки коллекции меньшие записи в более крупные, отправленные реже. Результаты были вполне удовлетворительными: 7% процессор попал, по сравнению с 59% ранее. Казалось бы, по крайней мере, в моей * NIX-подобной системе операция отправки пакета дорого стоит только накладных расходов на выполнение вызова.
На всякий случай, если кто-то сомневается в правильности работы теста, я проверил все результаты с наблюдением Wireshark о действительных передачах UDP, чтобы подтвердить, что все работает так, как должно быть.
Заключение: он использует MUCH меньше процессорного времени, чтобы отправлять более крупные пакеты реже, а затем столько же данных в виде более мелких пакетов, отправляемых чаще. По общему признанию, я не знаю, что произойдет, если UDP начинает фрагментировать вашу слишком большую UDP-дейтаграмму... Я имею в виду, я не знаю, сколько добавочных ресурсов процессора это добавляет. Я постараюсь узнать (я хотел бы узнать себя) и обновить этот ответ.
Ответ 3
534 байта. Это необходимо передать без фрагментации. Конечно, он все равно может быть потерян. Накладные расходы, связанные с ретрансляцией потерянных пакетов и самих сетевых накладных расходов, на несколько порядков превосходят стоимость центрального процессора.
Ответ 4
У меня есть полезная нагрузка TCP 663. Я думаю, что это не приведет к фрагментации, поскольку она меньше 1472 (намного меньше). Но в Wireshark я вижу, что он отправляется дважды (без задержки 200 мс во время ожидания ACK). Возможно, это не фрагментация вообще? Есть ли какое-либо поле в пакете TCP, которое определенно сообщило бы мне, что эта передача фрагментирована?
Ответ 5
Вероятно, вы используете неправильный протокол. UDP почти всегда является плохим выбором для данных, которые вам интересны при передаче. Вы завершаете последовательность упорядочения, повторите попытку и логику целостности, а затем у вас есть TCP.