Пишу прогу с использованием UDP. Тесты показали что чем больше размер пакета - тем лучше (до определенного предела), в т.ч. потерь меньше и полезная скорость выше. Например при передаче между двумя проводными провайдерами при пакете 512 байт скорость 80-100 кбайт/сек, при 1372 - 400-500 кб/сек. Нелинейно, непонятно, но факт. Потерь при пакете 1372 байта значительно меньше. Самое главное тоже самое наблюдаю на тормозных каналах (EDGE, через телефон в режиме GSM) дает стабильно 3500 - 4000 байт/сек. при 1372, и падает до 1500-2500 при пакете 512.

Изучение основ привели к тому что максимальный размер упирается в минимальное MTU (максимальный размер IP пакета) между двумя точками, при превышении которого начинается разбиение пакета на несколько, в результате резкое увеличение потерь. Теория (RFC) гласит что должно быть не меньше 576 байт, только 576 байт это стандарт для канала X.25, от которого все отказываются уже лет 10 и негласным стандартом становится 1500 байт у Ethernet`а.
В инете не у всех 1500, т.к. оборачивается в пакет туннельного протокола (L2TP, PPPoE и т.п.) у которого есть свой заголовок.

В общем в итоге все упирается в размер MTU-28 (28 размер заголовка IP+UDP) , а померить элементарно:


1472 это 1500-28

Все кому не лень сделайте такой пинг и посмотрите что получилось. У меня на одном провайдере работает


на другом не проходит


проходит только


1373 уже не проходит.

Интересно у кого какое максимальное значение при котором пинги проходят?

miksoftНасколько я понимаю, в MTU обычно самое узкое место на последней миле. Так что примерять какие-либо конкретные цифры ко всему рунету бессмысленно.
Как раз смысл есть и результат интересен, народ тут со всей страны и у каждого своя последняя миля.
Пусть конкретного размера не выведем, но будет общее понимание к чему готовиться.

Просто есть цифра 576 байт - это наименьшее MTU которое должно поддерживать все сетевое оборудование в инете (так в RFC написано). Но эта цифра рождена давным-давно, поэтому интересно реально есть ли вообще где-то оборудование с таким MTU?
Для Ethernet`а стандарт 1500, для оптики 4000+.

Интересен минимальный порог этого замера. У меня на одном провайдере MTU 1400, отсюда максимум пинга 1372. Есть у кого-нибудь меньше 1372?
Также интересны конкретные величины. Хочу написать программное определение (если это не сложно окажется), чтобы оптимизировать поиск проще сначала проверить конкретные значения, для этого они и нужны.

Basil A. SidorovDima TВ общем в итоге все упирается в размер MTU-28 (28 размер заголовка IP+UDP)Э-хе-хе ... Про инкапсуляцию, значит не подумали, хотя и упомянули.
При данной постановке вопроса нет смысла углубляться в эту сторону. Интересен максимальный размер пакета, который пройдет без фрагментации от моего приложения до сервера в инете. Тут ping.exe выполняет роль приложения, а sql.ru - сервера.
Как выше упомянуто уменьшение размера MTU вопрос последней мили, поэтому можно предположить что при прямом обмене между пользователями А и Б пройдет пакет с наименьшим из двух MTU измеренным таким способом.

Basil A. SidorovСлучилось так, что именно сегодня я запустил тест скорости по UDP между двумя провайдерами.
Предел - между четырьмя и восемью килобайтами. Но только в одну сторону и с огромными потерями
Тоже занимался такими тестами в начале изучения UDP. Кое-где проходили пакеты по 65507 байт (максимальный размер данных в пакете). Число 1372 тогда и вычислил на своем провайдере, тогда еще не знал чем оно обусловлено. Он рубит все что за пределами его MTU. Другой провайдер нормально пропускает даже 65507 туда и обратно.

Basil A. SidorovЕсли же говорить о скоростях, за которые вы так боритесь, то стабильное преимущество - у TCP
Уже расписывал зачем мне UDP, и чем он больше мне подходит чем TCP, не смысла снова это обсуждение повторять.
Скорость мне не критична, но если ее можно увеличить, то почему бы не исследовать этот вопрос?

Тут было высказано интересное мнение
Anatoly Moskovsky... одно дело 100Мбпс при пакете 1500 и другое дело при пакете 60 байтов
Оно натолкнуло на мысль что оборудование заточено на обработку пакетов, и уменьшение размера только создает проблемы, т.к. количество пакетов возрастает. Тесты подтверждают, именно по этой причине возрастает скорость передачи при увеличении размера пакета. Соотношение полезных и служебных данных не так сильно меняется. Заголовки ~10% при размере 512 байт и 3,5% при 1372, т.е. ожидаемое ускорение 6,5%, а у меня 100% и больше. Если предположить что скорость в пакетах в секунду, то 1372/512 дает +150%.

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

В общем я в раздумье: остановится на гарантированной в RFC константе 548 байт (576 - 28), попытаться подобрать свою (без гарантий что она везде сработает) или мерить предел по месту и слать с максимальным КПД (этот вариант идеальный, вопрос только в трудоемкости его реализации)

miksoftDima T Path MTU discovery
Читал уже, именно эта ссылка и натолкнула на мысль замерами заняться, только это за рамками данного топика, т.к. это уже вопросы конкретной реализации. По этому поводу будет другой топик. Пока я только в общих чертах понимаю что к чему.

miksoftОднако, это все плохо согласуется с вашим же:Dima TГиморно это. Согласен что интересно, но как-то надо разумно ограничивать свои творческие изыскания, а то я вместо написания собственного простенького протокола передачи файла стану спецом по низкоуровневому устройству интернета ))
Вполне согласуется, там была проблема, причину которой я бы мог найти, но устранить проблему все-равно бы не смог.
Тут ситуация обратная: поняв устройство - я решу свою проблему.

MasterZivЯ подозреваю, что для linux должна быть другая комманда.
Наверно на тут мало кто на линуксе, возможно ты один.

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


Дальше посылка пакета тестового размера своему серверу, который обратно шлет пакет того же размера. Ответ пришел - размер подтвержден, и далее по алгоритму двоичного поиска между 458 и 1472. Еще оказалось если ограничение со стороны отправителя (даже на роутере), то sendto() возвращает ошибку при отправке.

Все отлично работало пока по GPRS не попробовал. Там таймауты по несколько секунд нужны для ожидания ответа. В общем устанешь ждать пока отработает. Поэтому надо какой-то другой алгоритм изобретать. Отправить сразу несколько пакетов разных размеров и смотреть какой наибольший вернется. Т.к. скорости грустные 2000-3000 байт в секунду, то тоже много не пошлешь. Вот тут выручат реальные данные, хоть как-то минимизировал бы трафик. Хотя наверно самый идеальный вариант хранить предыдущее значение и тесты начинать с него.

miksoftDima TОтправить сразу несколько пакетов разных размеров и смотреть какой наибольший вернется. Т.к. скорости грустные 2000-3000 байт в секунду, то тоже много не пошлешь. Вот тут выручат реальные данные, хоть как-то минимизировал бы трафик. Хотя наверно самый идеальный вариант хранить предыдущее значение и тесты начинать с него.Ну да, тестируйте сразу пакетами с настоящим данными. Анализируете по каким квитки не пришли, вычисляете порог и выше него уже не шлете. Но контроль в сторону уменьшения нужно продолжать до конца передачи, т.к. MTU трассы может измениться в процессе.
спасибо за шутку, оценил.

maytonDima T, у меня друг делал сетевые игры для интернета. В режиме реального времени.
Пробовал UDP-протоколы. Забил. Говорит - ненадёжно. Очень многие поставщики
услуг интернета режут этот протокол на разных уровнях.

TCP надёжнее.
Поздно разворачиваться, все спроектировано и на 80% уже написано. Даже если бы ты на старте это сказал, все-равно бы сделал, слишком уж много плюсов у UDP чтобы отказываться не попробовав. Будут проблемы в реальном использовании - перепишу/добавлю TCP. Это версия 2.0 давно работающей системы (по HTTP).

PS Отрицательный результат - тоже результат, не взлетит - не расстроюсь.

miksoftШутки не было. В чем вы ее увидели?
Без обид. Все стебаются что я свой TCP пишу. А тут почти цитата из RFC. Тем более противоречит этому
miksoftНасколько я понимаю, в MTU обычно самое узкое место на последней миле.
С этим полностью согласен, поэтому хочу ограничится расчетом MTU между клиентом и сервером в инете. А при прямом обмене между клиентами брать меньшее. Т.е. делаю предположение что тонкое место на выходе от клиента. Есть маленькая вероятность что это не так, на это случай - уменьшение используемого MTU клиента, разрыв всего и перелогин на сервере.

PS Не хочу TCP повторять, он уже есть и лучше я точно не напишу. Мир.

miksoftВ посте выше предложил для тестирования использовать реальные данные с целью уменьшить общий объем передаваемых данных и количество раундтрипов.
Передача уже написана, стормозил что тут я это не упоминал. И замеры MTU во время передачи туда никак не вписываются. Может я бы их туда и вписал, но в начале разработки мне никто не подсказал, а я тогда просто не знал что такое MTU и зачем оно мне. Там было два вопроса как слать и по сколько. Т.к. оба одновременно не смог решить, то начал с "как", закончил, работает, в этом топике поднял вопрос "по сколько", в принципе сейчас тоже все понятно. Можно подъитожить что все вопросы решены, дальше дело техники: причесать и тестить на живых людях.

Антон АксёновDima T,

Дмитрий, как практика показала, решение рабочее? Ну, вычислить MTU, фрагментировать пакеты под него, или, оглядываясь назад, вы бы не стали морочаться?
Практика показала самые часто встречающиеся MTU это 1500, 1492 и самое меньшее 1400. Это размер с заголовками, если надо полезный размер вычитай заголовки, для UDP 28 байт.

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

Тесты на живых клиентах показали что решение рабочее, если провайдеры жестоко UDP не рубят (как сотовые), то все доходит. Хотя есть любители порубить по сигнатуре. Тестил отправками размером ~1 мб, т.е. клиент бъет 1 мб на куски согласно MTU и шлет на мой эхо-сервер, тот обратно тем же способом. После я логи изучал, по проводным сетям все нормально, потери незначительные. Может и по сотовым что-то поменялось, тогда 3G было мэнстримом, сегодня 4G.