Comments 54
Короче говоря, 1500, потому что это и не слишком много и не слишком мало. Яснопонятно.
В tcp@ipv6 есть обязательный pmtu. После того, как весь существенный трафик перейдёт на ipv6, можно будет безопасно пробовать поднимать размер MTU на интерфейсе, а tcp само разберётся какой размер ей хорош.
1500 Б (около 12000 бит)потому, что байт — это примерно 8 бит. Понятно.
Странно то, что 1500 байт — это ровно 12 000 бит
Сейчас — уже да…
В попытке натянуть сову на глобус, извлечь смысл из ошибки перевода, путают термины «слово», «ширина шины» и «байт». Определение по ссылке, кстати, неправильное. Одномоментно обрабатывается как раз слово.
Я ссылку дал на то, что вообще-то в те времена размер байта не обязательно был 8 бит… Поэтому речь о примерном равенстве вполне оправдана. Где-то 7, где-то 9-10 — и вот уже 1500 байт совсем не обязательно значат 12000 бит. Про слова вы это сами что-то додумали. Размер char в C вы думаете, отчего по стандарту так плавает?
впечатление такое, будто у нас форум домохозяек, по-быстрому гуглящих ради спасения макияжа. MTU 1500 и не-восьмибитные байты жили в несколько разные временные интервалы.
Размер char в C вы думаете, отчего по стандарту так плаваетПросветите отсталого. Когда плавал, как.
ru.wikipedia.org/wiki/Limits.h
github.com/exsilium/pxbee-blink-led/blob/master/hc08c/include/limits.h#L16
gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
www.geeksforgeeks.org/char_bit-in-c
Есть кстати ещё одно слово, которое сегодня стало синонимом байта — октет. Но так было не всегда.
github.com/exsilium/pxbee-blink-led/blob/master/hc08c/include/limits.h#L16
gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
www.geeksforgeeks.org/char_bit-in-c
Есть кстати ещё одно слово, которое сегодня стало синонимом байта — октет. Но так было не всегда.
ru.wikipedia.org/wiki/Limits.h...не-не, то, что в стандарте С размер целочисленных задаётся, известно ещё из K&R (даже лично мне известно уже около 40 лет). Но — когда и где в сколько-нибудь массовых применениях он «плавал»?
Кстати, во второй ссылке не очень точно, а Вы и ухватились. Char был, действительно 7-битным во время оно, а вот байт, как его хранилище, именно потому был 8-битным, с битом чётности. В то время подобные наследия телетайпной связи, аппаратные подробности, были видны сверху. Потом, когда символов потребовалось больше, перешли на 8-битный символ при прежнем 8-битном байте. Это позволяло обойтись без переделок железа, ведь бит чётности из явного в байте ушёл в аппаратную глубину.
Есть кстати ещё одно слово, которое сегодня стало синонимом байта — октет. Но так было не всегда.ойой, зачем очередной раз цитировать нагугленное без хотя бы небольшого изучения вопроса? Почти ровно наоборот. «Октет» жил недолго, в самом начале, когда архитектуры ещё не устоялись, и ещё живо было даже телеграфное представление символов. То есть во времена, когда само слово байт ещё не заняло нынешнего универсального состояния. У компьютерщиков были свои единички, байты, у связистов — свои, в телеметрии, опять же свои. По большей части они совпадали, но были свои. Потом из «совпадали» выросло и единство.
Но с сетями и MTU=1500 это по времени разведено.
И сейчас не так уж и сложно найти какой-нибудь микроконтроллер, где char=int=16/32bit
char — это вообще другая логика, а int — ну, слово, понятно и без слов :-). Размер байта это не изменяет.
Конечно, я не думаю, что байт — такое вечное понятие. Со временем он исчезнет. Был обозначением для хранилища char'а, уже нет, сейчас это скорее уже только единица измерения (в словах считать неудобно как раз потому, что они разные бывают), чем что-то практически важное.
Конечно, я не думаю, что байт — такое вечное понятие. Со временем он исчезнет. Был обозначением для хранилища char'а, уже нет, сейчас это скорее уже только единица измерения (в словах считать неудобно как раз потому, что они разные бывают), чем что-то практически важное.
Возможно, автор говорил про полезную нагрузку, но ему было лень считать.
Там фишка в том, что 1500 — это тоже округлённо, что прямым текстом следует из статьи.
Что значит «округлённо»? 1499.7, что ли? Понятно-понятно…
В статье приводятся картинки вроде вот этой:
Обратите внимание, что на них везде одинаковый лимит чуть больше 1500 байт.
Кроме того, в общем случае на 1 передаваемый байт данных могут идти дополнительные управляющие биты. В том же горячо любимом многими последовательном порте можно выключить или включить бит чётности, а про стартовые и стоповые биты я вообще молчу.
Обратите внимание, что на них везде одинаковый лимит чуть больше 1500 байт.
Кроме того, в общем случае на 1 передаваемый байт данных могут идти дополнительные управляющие биты. В том же горячо любимом многими последовательном порте можно выключить или включить бит чётности, а про стартовые и стоповые биты я вообще молчу.
Если бы изначально MTU был высок, то действительно ethernet возможно не взлетел бы. А если бы и взлетел, то кризис "больших файлов" настиг бы нас ещё раньше. Зачем изобретать новые кодеки? Зачем сжимать видео, если канала на 25% больше.
По бокам космического корабля «Кеннеди» размещаются два двигателя по 5 футов шириной. Конструкторы корабля хотели бы сделать эти двигатели еще шире, но не смогли. Почему? Дело в том, что двигатели эти доставлялись по железной дороге, которая проходит по узкому туннелю. Расстояние между рельсами стандартное: 4 фута 8.5 дюйма, поэтому конструкторы могли сделать двигатели только шириной 5 футов. Возникает вопрос: почему расстояние между рельсами 4 фута 8.5 дюйма? Откуда взялась эта цифра? Оказывается, что железную дорогу в Штатах делали такую же, как и в Англии, а в Англии делали железнодорожные вагоны по тому же принципу, что и трамвайные, а первые трамваи производились в Англии по образу и подобию конки. А длина оси конки составляла как раз 4 фута 8.5 дюйма! Но почему? Потому что конки делали с тем расчетом, чтобы их оси попадали в колеи на английских дорогах, чтобы колеса меньше изнашивались, а расстояние между колеями в Англии как раз 4 фута 8.5 дюйма! Отчего так? Да просто дороги в Великобритании стали делать римляне, подводя их под размер своих боевых колесниц, и длина оси стандартной римской колесницы равнялась… правильно, 4 футам 8.5 дюймам! Ну вот теперь мы докопались, откуда взялся этот размер, но все же почему римлянам вздумалось делать свои колесницы с осями именно такой длины? А вот почему: в такую колесницу запрягали обычно двух лошадей. А 4 фута 8.5 дюйма — это был как раз размер двух лошадиных задниц! Делать ось колесницы длиннее было неудобно, так как это нарушало бы равновесие колесницы. Следовательно, вот и ответ на самый первый вопрос: даже теперь, когда человек вышел в космос, его наивысшие технические достижения напрямую зависят от РАЗМЕРА ЛОШАДИНОЙ ЗАДНИЦЫ.
А не маловато 140 см для двух лошадей?
Или римляне на пони катались?
Или римляне на пони катались?
Не путайте лошадей и коров :)
Я не специалист по римской лошадиной сбруе, но по беглому гуглежу картинок римской колесницы видно, что ширина колеи тележки имеет собственный размер, сами лошади имеют гибкое крепление и бегут самостоятельно. Поэтому принципиально, ширина колеи тележки никак не связана с шириной лошадиной задницы.
Тем не менее, с практической точки зрения, путем проб и ошибок была найдена оптимальная ширина колеи тележки, которая и была зафиксирована в стандартах того времени.
Тем не менее, с практической точки зрения, путем проб и ошибок была найдена оптимальная ширина колеи тележки, которая и была зафиксирована в стандартах того времени.
Лошади раньше были действительно меньше, да и люди тоже...
Это, к сожалению, байка, хотя и забавная.
Римляне не использовали колесницы как транспорт — они технологически устарели ещё до появления Республики.
SRB подвозят на мыс Канаверал не по железной дороге, а по морю на барже.
Ну и так далее…
NASA даже специальный пресс-релиз на эту тему выпускала
Римляне не использовали колесницы как транспорт — они технологически устарели ещё до появления Республики.
SRB подвозят на мыс Канаверал не по железной дороге, а по морю на барже.
Ну и так далее…
NASA даже специальный пресс-релиз на эту тему выпускала
Это, к сожалению, городская легенда: www.snopes.com/fact-check/railroad-gauge-chariots
даже теперь, когда человек вышел в космос, его наивысшие технические достижения напрямую зависят от РАЗМЕРА ЛОШАДИНОЙ ЗАДНИЦЫ.
А Илон нашел выход.
Арендовал украинскую Мрию, и доставил габаритные запчасти Falcom9 по воздуху.
Скорее всего компромисс выбирался, исходя из:
Из (2) мы получаем минимальное время фрейма для коллизионного домена. Теперь представим коллизионный домен, в котором нас интересуют два компьютера — один очень активно передаёт много фреймов максимального размера, а второй хочет вклиниться в поток и передавать фреймы минимального размера. Чем меньше MTU, тем меньше в худшем случае ему придётся ждать.
Но при этом слишком маленькие значения MTU будут делать обработку данных слишком дорогой из-за (1), а также увеличивать (3), снижая долю полезной информации.
Если мы потребуем от узлов в 10Мбит/с-сети интерактивности в 1мс, то получим MTU=1212. Однако, в сетевых адаптерах тех времён присутствует специальный предохранитель между MAC и PHY, не позволяющий захватить коллизионный домен на слишком долгое время в случае залипания MAC в состоянии бесконечной отправки. Возможно, использование максимального времени фрейма в 1.2304мс вместо 1мс можно объяснить несовершенством настройки этого предохранителя.
- способностей старых компьютеров обрабатывать прерывания от сетевой карты
- ограничений на длину кабеля и излучаемую мощность
- доля служебной информации
- пропускной способности
Из (2) мы получаем минимальное время фрейма для коллизионного домена. Теперь представим коллизионный домен, в котором нас интересуют два компьютера — один очень активно передаёт много фреймов максимального размера, а второй хочет вклиниться в поток и передавать фреймы минимального размера. Чем меньше MTU, тем меньше в худшем случае ему придётся ждать.
Но при этом слишком маленькие значения MTU будут делать обработку данных слишком дорогой из-за (1), а также увеличивать (3), снижая долю полезной информации.
Если мы потребуем от узлов в 10Мбит/с-сети интерактивности в 1мс, то получим MTU=1212. Однако, в сетевых адаптерах тех времён присутствует специальный предохранитель между MAC и PHY, не позволяющий захватить коллизионный домен на слишком долгое время в случае залипания MAC в состоянии бесконечной отправки. Возможно, использование максимального времени фрейма в 1.2304мс вместо 1мс можно объяснить несовершенством настройки этого предохранителя.
Мне тоже казалось, что-то когда что читал более детальное обоснование
«специальный предохранитель» — скорее всего, вы имеете ввиду «jabber control» — он нужен был для отключения от общей шины только неисправных адаптеров (неисправность определялась превышением предельно допустимого времени на передачу кадра максимальной длины с запасом). То есть, этот «предохранитель» не мог повлиять на выбор максимального размера кадра, его время срабатывания выбиралось уже после.
И да, 1500 — это рудиментарное наследие полудуплексного Ethernet, если бы выбрали больше, пострадала бы интерактивность и эффективность сети (пока передает один узел, другие не могут получить доступ к среде передачи), а влияние на стоимость NIC вторично. Хотя в то время могло быть и наоборот (как написано в статье).
И да, 1500 — это рудиментарное наследие полудуплексного Ethernet, если бы выбрали больше, пострадала бы интерактивность и эффективность сети (пока передает один узел, другие не могут получить доступ к среде передачи), а влияние на стоимость NIC вторично. Хотя в то время могло быть и наоборот (как написано в статье).
Ben Cox'у надо было почитать хабр
Напомнило старую-древнюю байку о том, как программисты дом строили. IT-шников на стройку пускать нельзя.
Можно провести обновления по увеличению MTU на самых крупных участках сети. А для роутеров и ОС выпустить обновления, добавляющие механизм определения максимального MTU у вышестоящего устройства. Так мы получим максимальный MTU, который можно использовать для предотвращения фрагментации пакетов. Таким образом, MTU у конечных пользователей по мере обновления оборудования начнет зависеть лишь от MTU провайдера.
Задержка (по идее) не особо большая. А в новые устройства можно добавить, скажем, особый пакет. Отправляем его выше устройству, а оно возвращает нам максимальный MTU. Если что-то меняется — новый пакет с новыми настройками. Если же вышестоящее устройство не поддерживает этот механизм — то подбором вычисляем максимальный. По поводу «поздно менять»: если реализовать описанный мною плавный алгоритм постепенного перехода, то даже не придется пользователей насильно заставлять менять: они сами будут переходить на новое оборудование, потому что оно быстрее.
На самом деле всё ещё сложнее и запутаннее. Например, в реальности очень часто MTU меньше 1500 байт. Причина: VPN, PPPoE, IPSec, т.е. любой туннель откуда-то должен брать информацию о самом себе и тем самым уменьшать полезную нагрузку. Спрашивается, как же всё работает так, что нет постоянной фрагментации. А работает оно следующим подлым образом (есть другие способы, но этот самый надёжный): При установлении TCP соединения каждый из хостов указывает свой максимальный размер пакета (MSS), выбирается минимальный и дальше всё работает с таким размером. Т.е. это уже 4-ый уровень (а Ethernet — второй). Так вот, маршрутизаторы просто ловят данные пакеты и уменьшают MSS на своей стороне. Таким образом получается, что виртуальный MTU — 1500, а реальный — может быть гораздо меньше.
И если мы попытаемся увеличить где-то MTU, то скорее всего один из узлов всё равно подрежет его до своего значения и смысла в увеличенном размере не будет никакого.
И если мы попытаемся увеличить где-то MTU, то скорее всего один из узлов всё равно подрежет его до своего значения и смысла в увеличенном размере не будет никакого.
Особенность состоит в постепенном переходе. Параллельно провайдеры поднимут MTU, а производители роутеров выпустят новые модели. Пользователи сами будут переходить на новые роутеры, если у них видеосвязь станет плавнее, а в играх упадет пинг (к примеру). До пользователя то не так уж и много узлов (хотя хз). При плановой замене оборудования поставят новое, которое уже будет совместимо с новым MTU, а пользователи так и так будут роутеры менять. И постепенно, не спеша у всех ускорится интернет
Ага. Так IPv6 постепенно вводят, а там с этим гораздо лучше. Никак ввести не могут. Всё очень сложно. Например, весь интернет живёт на L3 и иногда L4, т.е. ему аппаратные ограничения вроде бы не нужны. А дома уже L2 вылезает в полной красе, и там стандарты прибиты и просто так их не изменить. Есть Ethernet, есть Wifi, у всех свои правила. И в локальной сети всё идёт мимо маршрутизатора. Так что, надо MTU увеличивать у всех устройств, иначе будут проблемы (пакет не пролезет). И какой-нибудь умный холодильник всё испортит.
Получается, что надо:
1. Обновить абсолютно все устройства дома (компьютеры, ноутбуки, телефоны, телевизоры, роутеры и т.д.)
2. Обновить операционные системы на компьютерах
3. Обновить всё оборудование у провайдера
4. Обновить все магистрали
И всё ради того, чтобы увеличить MTU, и чуть-чуть выиграть в скорости. Куча работы, любой баг может привести к частичной неработоспособности сети и прочее.
Но есть всеми ненавистный IPv6, у которого эти проблемы постарались решить (там встроенный MTU Discovery, нормально с номерами и размерами пакетов). Можно просто выпустить оборудование с поддержкой IPv6 и будет всё проще. Но только как-то с 1996-ого года прогресс не очень.
Получается, что надо:
1. Обновить абсолютно все устройства дома (компьютеры, ноутбуки, телефоны, телевизоры, роутеры и т.д.)
2. Обновить операционные системы на компьютерах
3. Обновить всё оборудование у провайдера
4. Обновить все магистрали
И всё ради того, чтобы увеличить MTU, и чуть-чуть выиграть в скорости. Куча работы, любой баг может привести к частичной неработоспособности сети и прочее.
Но есть всеми ненавистный IPv6, у которого эти проблемы постарались решить (там встроенный MTU Discovery, нормально с номерами и размерами пакетов). Можно просто выпустить оборудование с поддержкой IPv6 и будет всё проще. Но только как-то с 1996-ого года прогресс не очень.
Двух провайдеров. На этом и на том конце. Не все же ходят исключительно на CDN, стоящие рядом с точками обмена трафиком.
По сравнению с ATM cell размером 53 байта, кадр Ethernet далеко не самый маленький)))
Ну, если уж говорить совсем честно, то _многие_ магистральные операторы давно перешли на джумбо-фреймы. Так, для примера, я со своего оборудования в Канаде до хостинга в Италии добираюсь большими пакетами без их фрагментации. Другое дело, что _многие_ — это не _все_. Поэтому ставить на конечном оборудовании отличное от 1500 значение mtu — рисковать неудачными/длительными коннектами(если pmtu discovery не сломано по пути) с _некоторыми_ клиентами, если только вы не знаете _точно_, что пути до всех ваших клиентов поддерживают jumbo frames.
Sign up to leave a comment.
Как максимальной единицей передачи информации в интернете стали 1500 байт