Иван Громов

Exchange естественно

Программа называется Google Chrome.
Ставить Google Chrome.
Устанавливаете в него приложение Google Keep из стора
Делаете иконку на приложение на рабочем столе
...
PROFIT

Предлагаете угадать где именно он пропадает и что значит "пропадает"?

Рассмотрим 10-мегабитный ethernet. Реальная величина фрейма с заголовками и полезной нагрузкой 1526 байт. Прибавив сюда 12 байт промежутка между фреймами , получим 1538 байт.

10 мегабит / 1538 байт = 812 фреймов в секунду
812 фреймов в секунду * 1500 байт полезной нагрузки * 8 бит = 9752925 бит в секунду

9752925 ~ 97,5% эффективность использования полосы пропускания 10М ethernet.

Уменьшая MTU мы увеличим количество фреймов в секунду и тем самым уменьшим эффективность полосы пропускания за счет лишних заголовков.

Увеличив MTU мы уменьшим количество фреймов в секунду, улучшим количественные показатели эффективности использования полосы пропускания.

Почему же остановились на 97.5% эффективности? Потому что именно такое число обычно за границей считают и пишут со словами "very high effectiveness". Впрочем, возможно 97.5% закреплено в каком-то стандарте классификации США.

ИМХО, определено методом научного тыка. Подробнее читать в гугле по запросу
"why mtu 1500"
e.g.

А вот откуда взялись эти пресловутые 1500 байт, вопрос сложнее. Я нашел следующее объяснение — предпосылок на введение верхнего ограничения размера фрейма было несколько:
Задержка при передаче – чем больше фрейм, тем дольше длится передача. Для ранних сетей, где Collision домен не ограничивался портом, и все станции должны были ждать завершения передачи, это было серьёзной проблемой.
Чем больше фрейм, тем больше вероятность того что фрейм при передаче будет поврежден, что приведет к необходимости повторной передачи, и все устройства в collision домене будут вынуждены опять ожидать.
Ограничения, накладываемые памятью используемой под интерфейс буферы – на тот момент (1979г) увеличение буферов значительно удорожало стоимость интерфейса.
Ограничение, вносимое полем Length/Type – в стандарте закреплено, что все значения выше 1536 (от 05-DD до 05-FF.) указывают на EtherType, соответственно длина должна быть меньше 05-DC. (У меня правда есть подозрение, что это скорее следствие, чем предпосылка, но вроде инфа от разработчиков стандарта 802.3)

habrahabr.ru/post/226807

Потому что так гласит стандарт IEEE802.3

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

Предположим что мы хотим послать IP датаграмму в 1500 байт. Это мы еще находимся на третьем уровне модели OSI. Теперь идем на второй, запаковываем датаграмму в ethernet-фрейм, то есть добавляем еще 26 байт, итого имеем фрейм размером в 1526 байт. Так же между всеми фреймами есть еще 12-ти байтный зазор, что бы различать где кончается один фрейм и начинается другой. То есть на каждую датаграмму в 1500 байт мы передаем фрейм в 1538 байт.

Давайте пока не будем отвлекаться на всякие Fast Ethernet и примим что скорость нашего Ethernet - 10mbps. Посчитаем сколько фреймов может передаваться в секунду:

10 Mbps / 1538 байт = 812.74 фреймов / секунду.

Имея количество фреймов в секунду мы можем прикинуть, при каком размере сколько будет идти наша датаграмма и какова будет полезная нагрузка на канал:

812.74 * 1500 = 9 765 625 bps или ~9.7Mbps что есть ~97% заполнения канала. Логично что если повысить MTU то и полезная нагрузка будет больше, но тут стоит просто иметь в виду еще и потери пакетов и прочее. В этом плане маленькие пакеты лучше, в итоге приходим к компромису.

Конечно с тех пор много чего поменялось, но суть остается та же. Выбираем размер пакета по оверхэду и вероятности потерь.

Рекомендую почитать: en.wikipedia.org/wiki/Jumbo_frame