UDP IP Fragmentation и MTU

Я пытаюсь понять какое-то поведение, которое я вижу в контексте отправки пакетов UDP.UDP IP Fragmentation и MTU

У меня есть две небольшие программы Java: одна, которая передает UDP-пакеты, а другая, которая их получает. Я запускаю их локально в своей сети между двумя компьютерами, подключенными через один коммутатор.

Настройка MTU (сообщенная/sbin/ifconfig) равна 1500 на обоих сетевых адаптерах.

Если я отправляю пакеты с размером < 1500, я их принимаю. Ожидаемое.
Если я отправляю пакеты с 1500 < размер < 24258 Я принимаю их. Ожидаемое. Я подтвердил через wirehark, что IP-уровень фрагментирует их.
Если я отправляю пакеты размером> 24258, они теряются. Не ожидается. Когда я запускаю wirehark на принимающей стороне, я не вижу ни одного из этих пакетов.

Мне удалось увидеть подобное поведение с помощью ping-s.

ping -s 24258 hostA работает, но

ping -s 24259 hostA терпит неудачу.

Кто-нибудь понимает, что может произойти, или есть идеи о том, что я должен искать?

Оба компьютера работают CentOS 5 64-бит. Я использую 1,6 JDK, но я действительно не думаю, что это проблема программирования, это проблема с сетью или, может быть, с ОС.

источник

2010-09-14 wolfcastle

Возможно, вам больше повезло с просьбой об этом на serverfault.com. –

Что делает wirehark на отправляющей стороне соединения для пакетов с 'size> 24258'? –

@Kaleb Я не эксперт в проводнике, но захват на отправляющей стороне выглядит одинаково, если размер пакета равен> или <24258. Я вижу фрагментированные IP-пакеты, но я вижу только UDP-пакеты для небольших пакетов (у меня есть сочетание очень маленьких и очень больших пакетов). Данные, которые я отправляю, являются двоичными, поэтому трудно понять, какой IP-пакет принадлежит тому, что UDP-пакет. Я мог бы попробовать провести более простой тест с более предсказуемыми данными и посмотреть, что показывает wirehark. Я, возможно, не доберусь до этого до завтра. @ire_and_curses, спасибо, что я не был уверен, что именно серверное шифрование точно охвачено. Я могу попробовать. – wolfcastle

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

Похоже, что реализация вашего хоста поддерживает максимальный размер, намного превышающий 576, но все же значительно меньший, чем максимальный теоретический размер 65 535. (Я не думаю, что переключатель должен быть проблемой, потому что ему не нужно делать дефрагментацию - он даже не работает на уровне IP).

В стандарте IP далее рекомендуется, чтобы хосты не отправляли пакеты более 576 байт, если только они не уверены, что принимающий хост может обрабатывать больший размер пакета. Возможно, вам стоит подумать, будет ли лучше, если ваша программа будет отправлять меньший размер пакета. 24,529 кажется ужасно большим для меня. Я думаю, что может быть вероятность, что многие хосты не будут обрабатывать пакеты, большие.

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

источник

2010-09-14 20:52:58

Я не знал, что реализация может иметь меньший максимальный размер пакета. Вы знаете, как определить, что это за значение? Согласен, 24k - очень большой размер, и я, вероятно, не буду отправлять большие пакеты в развернутой системе, я просто столкнулся с этим во время тестирования. Я имею полный контроль над сетью в развернутой системе (все компьютеры/коммутаторы/маршрутизаторы). Мы используем Gigabit ethernet, поэтому, если мы также используем jumbo-фреймы, я собираю I * должен * иметь возможность использовать размер пакета 9000 (UDP-заголовки + полезная нагрузка) без фрагментации IP-слоя. – wolfcastle

я нашел следующее, которые могут представлять интерес:

Determine the maximum size of a UDP datagram packet on Linux
Установите бит DF в заголовке IP и отправлять непрерывно более крупные пакеты, чтобы определить, в какой момент пакет фрагментирован согласно Path MTU Discovery. Затем фрагментация пакетов должна привести к пакету ICMP типа 3 с code 4, указывающим, что пакет был слишком большим для отправки без фрагментации.

Ответ Дэна полезен, но обратите внимание, что после заголовков вы действительно ограничены 65507 байтами.

источник

2010-09-14 22:14:38

UDP IP Fragmentation и MTU

ответ

Смежные вопросы