Как найти самый большой UDP-пакет, который я могу отправить без фрагментации?

Question

Мне нужно знать, какой самый большой UDP-пакет я могу отправить на другой компьютер без фрагментации.

Этот размер обычно известен как MTU (Максимальная единица передачи).Предположительно, между двумя компьютерами будет множество маршрутизаторов и модемов, которые могут иметь разные MTU.

Я читал, что реализация TCP в Windows автоматически находит максимальное MTU в пути.

Я также экспериментировал и выяснил, что максимальный MTU от моего компьютера до сервера составлял 57712 байт + заголовок.Все, что было выше этого, было отброшено.Мой компьютер подключен к локальной сети, разве MTU не должен составлять около 1500 байт?

Answer 1

Следующее не дает прямого ответа на ваш вопрос, но может показаться вам интересным;в нем говорится, что IP-пакеты могут быть разобраны / собраны заново и, следовательно, превышать лимит на подчиненных носителях (например1500-байтовый Ethernet): Устраните проблемы с фрагментацией IP, MTU, MSS и PMTUD с помощью GRE и IPSEC

---

Подробнее по этой теме:

• Ре:Фрагментация UDP говорит, что вы должны использовать ICMP вместо UDP для обнаружения MTU
• Обнаружение MTU пути говорит, что TCP-соединение может включать неявное согласование MTU через ICMP

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

Нет, похоже на то, что является реализованный:смотрите, например Примеры часто задаваемых вопросов программиста Winsock:Пинг-понг:Метод Необработанных Сокетов.

Итак, чтобы обнаружить MTU, сгенерируйте ping-пакеты с флагом "не фрагментировать".

Может быть, есть более простой API, чем этот, я не знаю;но я надеюсь, что я дал вам понять лежащий в основе протокол [ы].

Answer 2

В дополнение ко всем предыдущим ответам, цитируя Классический:

IPv4 и IPv6 определяют минимальный размер буфера для повторной сборки, минимальный размер дейтаграммы, который, как нам гарантировано, должна поддерживать любая реализация.Для IPv4 это 576 байт.IPv6 увеличивает это значение до 1280 байт.

Это в значительной степени означает, что вы хотите ограничить размер вашей дейтаграммы менее чем 576, если вы работаете через общедоступный Интернет и контролируете только одну сторону exchange - это то, что делает большинство стандартных протоколов на основе UDP.

Также обратите внимание, что PMTU является динамическим свойством пути.Это одна из тех вещей, с которыми TCP справляется за вас.Если вы не готовы повторно реализовать множество логических схем последовательности, синхронизации и повторной передачи, используйте TCP для любой критически важной сети.Бенчмарк, тест, профиль, т.е. доказать что TCP является вашим узким местом, только тогда рассматривайте UDP.

Answer 3

Это интересная тема для меня.Возможно, некоторые практические результаты могли бы представлять интерес при доставке больших объемов UDP-данных по реальному Интернету через UDP, и при скорости передачи 1 пакета в секунду данные продолжают поступать с минимальной потерей пакетов примерно до 2 тыс.Из-за этого вы начинаете сталкиваться с проблемами, но регулярно мы доставляли пакеты размером более 1600 байт без сбоев - это происходит по мобильным сетям GPRS, а также по глобальной сети по всему миру.При ~ 1K предполагая, что сигнал стабилен (это не так!) вы получаете низкую потерю пакетов.

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

Answer 4

Ваш собственный MTU доступен в реестр, но MTU на практике идет к наименьшему MTU на пути между вашей машиной и пунктом назначения.Оба они изменчивы и могут быть определены только эмпирически.Существует целый ряд RFC - запросы показывая, как это определить.

Локальные сети могут внутренне иметь очень большие значения MTU, поскольку сетевое оборудование обычно однородно или, по крайней мере, управляется централизованно.

Answer 5

Для приложений UDP вы должны обрабатывать сквозной MTU самостоятельно, если хотите избежать фрагментации IP или отброшенных пакетов.Рекомендуемый подход для любого приложения - сделать все возможное, чтобы использовать PMTU для выбора максимальной дейтаграммы или отправки дейтаграмм < минимальный PMTU

https://tools.ietf.org/html/rfc5405#section-3.2

Рекомендации по использованию одноадресного UDP для разработчиков приложений "НЕ СЛЕДУЕТ отправлять дейтаграммы, превышающие PMTU, СЛЕДУЕТ обнаруживать PMTU или отправлять дейтаграммы < минимальный PMTU

В Windows отображаются настройки и доступ к информации PMTU через интерфейс базовых параметров сокета:

Вы можете убедиться, что обнаружение PMTU включено через IP_MTU_DISCOVER, и вы можете прочитать MTU через IP_MTU.

https://docs.microsoft.com/en-us/windows/desktop/winsock/ipproto-ip-socket-options