Фрагментация

Изначальный размер ядра кометы Шумейкеров–Леви 9 оценивается в 5 км. В середине 19-го века перигелий её рассматриваемой орбиты находился недалеко от орбиты Юпитера. В афелии комета приближалась к орбите Сатурна. Её орбита имела небольшой эксцентриситет, то есть была слабо вытянутой. Также она имела небольшой угол наклона к плоскости эклиптики и плоскости орбит Юпитера и Сатурна.

При выбранных параметрах встреча кометы с Юпитером могла произойти ещё в самом начале 20-го века. Эта встреча привела к гравитационному захвату кометы Юпитером, и она стала вращаться вокруг него. Комета попала в сферу Хилла, то есть область пространства, в которой планета может удерживать спутник, несмотря на гравитацию Солнца. Однако видео наглядно показывает, что траектория кометы не является замкнутой.

Комета выполняла серию нескольких вытянутых витков вокруг Юпитера. Затем делала несколько оборотов вокруг него по почти круговой орбите. Комета не могла выйти на замкнутую орбиту вокруг Юпитера из-за сильных гравитационных возмущений со стороны Солнца. Чередование вытянутых и круговых витков происходило по мере движения Юпитера вокруг Солнца. Полный цикл чередования занимал примерно то же самое время, за которое газовый гигант делал два оборота вокруг центрального светила. За это время непрерывно менялась ориентация орбиты кометы по отношению к Солнцу. Она то поворачивалась к звезде ребром, то оказывалась развёрнутой к ней плашмя. В некоторые моменты времени комета оказывалась несколько ближе к Солнцу, которое с большей силой притягивало её к себе. Это сильно дестабилизировало орбиту кометы и приводило к довольно резкой смене её ориентации в пространстве.

Во время выполнения вытянутых витков вокруг газового гиганта, комета иногда проходила всего в нескольких миллионах км от него. В такие моменты очень сильно возрастает неопределённость в расчётном положении кометы. Дело в том, что координаты любого небесного объекта известны с некоторой погрешностью. Каждое тесное сближение объекта с планетой увеличивает неопределённость в координатах на один или даже на два порядка. Из-за этого невозможно точно сказать, когда именно комета Шумейкеров–Леви 9 вышла на орбиту вокруг Юпитера. Существуют оценки, что она могла быть захвачена им лишь в середине 60-х или даже в начале 70-х годов прошлого века. Однако сценарий, показанный в этом видео (что комета пробыла на орбите Юпитера почти сотню лет), также вполне возможен.

Достоверно известно, что 7 июля 1992 года произошло особо тесное сближение кометы Шумейкеров–Леви 9 с Юпитером. Она прошла всего в 40 тыс км от атмосферы планеты. Это сближение было настолько тесным, что мощные приливные силы Юпитера разорвали ядро кометы на множество фрагментов. Комета была открыта Юджином и Каролиной Шумейкерами и Дэвидом Леви 24 марта 1993 года. В тот момент она уже представляла собой множество обломков. Был обнаружен по меньшей мере 21 фрагмент, растянувшийся вдоль траектории движения в виде цепочки. После открытия кометы и вычисления её траектории стало ясно, что дальнейшее движение фрагментов приведёт к их столкновению с Юпитером. Все расчёты подтвердились. Падение фрагментов происходило в течение недели: с 16 по 22 июля 1994 года. Осколки падали на Юпитер со скоростью свыше 60 км/с. Это приводило к колоссальным взрывам в атмосфере газового гиганта. Мощность каждого из взрывов многократно превышала мощность совокупного ядерного потенциала, накопленного на Земле.

Сами моменты падения не наблюдались с Земли, так как столкновение каждого объекта происходило на обратной стороне Юпитера. Однако хорошо были видны последствия столкновений. Облако раскалённого газа, образующееся при взрыве в момент входа обломков в атмосферу Юпитера, поднималось на огромную высоту. В результате, это облако можно было наблюдать с Земли. Также с Земли хорошо были видны тёмные следы от взрывов в атмосфере Юпитера, которые по размеру превышали нашу планету. Эти следы можно было заметить в течение многих недель после взрывов. Моменты падения фрагментов наблюдались космическим аппаратом Галилео, который в это время как раз направлялся к Юпитеру.

Это грандиозное событие, произошедшее 30 лет назад, стало первым наблюдаемым столкновением двух небесных тел. Оно дало понимание, какую важную роль играет Юпитер в защите Земли. Самая большая планета Солнечной системы принимает на себя значительную часть ударов астероидов и комет.

Моделирование и визуализация выполнены автором этой публикации с помощью программного обеспечения собственной разработки. При расчётах учитывалось взаимное влияние друг на друга Солнца, всех планет Солнечной системы, Луны и кометы. Также при расчёте учитывались релятивистские эффекты. Негравитационные эффекты, связанные с испарением вещества ядра кометы и возможным столкновением фрагментов друг с другом, не учитывались. На протяжении большей части этого видео размеры небесных тел показаны сильно преувеличенными по сравнению с расстояниями между ними.

Что такое фрагментация?

Из разговора про MTU мы помним четыре момента:

1. Минимальный размер кадра 64 байт.

2. MTU по умолчанию в Ethernet сетях 1500 байт.

3. Кадры могут быть гораздо больше чем 1500 байт.

4. MTU параметр настраиваемый и не факт, что на всех линка будет настроен MTU, который будет пропускать пакеты, генерируемые отправителем.

Это некие вводные ограничения, которые нам дает Ethernet. IPv4 к этим ограничением добавляет то, что узел получатель должен гарантировать всем своим соседям, что он может принять IP-пакет размером 576 байт, а узел в IPv6 должен уметь обрабатывать пакеты размером 1280 байт.

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

1. Хосты согласовали обмен пакетами 1500 байт (на самом деле они согласовали TCP или SCTP MSS), но на сети есть линк или линки, где MTU меньше 1500 байт.

2. Хосты генерируют пакеты размером более 1500 байт, а на транзитных узлах MTU равен 1500 байт.

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

1. Транзитное устройство может уведомить отправителя о том, что тот генерирует слишком большие пакеты и, если отправителю не запрещено, то он может начать генерировать пакеты меньшего размера.

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

3. Слишком большие пакеты могут просто уничтожаться, но нам этот вариант не очень интересен.

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

Минусов у фрагментации много, вот три основных на мой взгляд:

1. При потере одного из фрагментов можно считать, что теряется весь исходный пакет.

2. Фрагментация повышает нагрузку на устройства сети.

3. В некоторых случаях при сборке фрагментированного пакет может быть нарушена целостность передаваемых данных.

Вот несколько ссылок, где вы можно больше узнать о проблемах, фрагментации, все на ин-язе: RFC 4963, Fragmentation Considered Harmful, RFC 8900.

Поля IP заголовка для управление фрагментацией

В IP заголовке имеется четыре поля, которые так или иначе используются при фрагментации.

1. Размер пакет (Total Lenght). В этом поле хранится полный размер пакета в байтах, т.е. заголовка плюс поля данных.

2. Идентификатор (Identification). Это поле помогает принимающей стороне собрать исходный пакет из полученных фрагментов, у фрагментов, которые являются частями одного исходного пакета, значение этого поля будет одинаковым.

3. Флаги (Flags). Под каждый флаг выделен один бит, нумерация начинается с нуля. Нулевой бит(нулевой флаг) нам не интересен, первый бит называется DF или do not fragment, если значение этого бита равно единицы, то пакет фрагментировать запрещено, если возникает ситуация когда у пакета DF = 1 и размер больше допустимого MTU, такой пакет уничтожается(некоторые устройства игнорируют бит DF и всё равно выполняют фрагментацию). Второй флаг называется MF или more fragments, он используется для того, чтобы обозначить конец последовательности фрагментированных пакетов, пока MF = 1 узел получатель будет ожидать новые фрагменты, как только придет пакет с MF = 0, получатель поймет, что последовательность фрагментированных пакетов закончилась.

4. Смещение фрагмента (Fragment Offset). IP не гарантирует того, что получатель будет получать пакеты в той же последовательности, в которой их генерировал отправитель. В случаях, когда фрагментации нет, проблема собрать всё в нужной последовательности это проблема вышестоящего процесса или протокола, но если получатель принял фрагментированную последовательность, задача собрать исходных пакет из фрагментов ложится на IP процесс, поле смещение помогает понять в какой последовательности надо собирать исходный пакет. Данное поле хранит численное значение, одна единица этого числа равна восьми байтам.

Вот так эти поля выглядят в дампе Wireshark.

Цвета на двух картинках выше соответствуют.

Смещение фрагмента в IP

Стоит отдельно остановиться на поле Fragment Offset, его размер 13 бит, то есть максимальное значение этого поля 8191, но весь вопрос в том, какие единицы измерения используются для смещения фрагмента, если в этом поле стоит значение 1, то это означает, что сдвиг надо делать на 8 байт, то есть максимально возможное смещение 65528 байт.

Проще всего разобраться с вопросом смещения можно будет на примере, допустим, у нас есть два хоста, соединенных каналом с MTU 1500 байт, но хосты хотят обмениваться пакетами размером 5940 байт, в этом случае будет включаться механизм фрагментации, и каждый исходный пакет будет разделен на четыре пакета по 1500 байт, чтобы они гарантированно прошли через канал, смещение первого фрагментированного пакета будет равно нулю, у второго пакета оно уже будет 1480 байт, третий пакет будет иметь смещение 2960 и последний пакет будет со смещением 4440 байт, все описанное выше представлено на рисунке.

Для удобства я пересчитывал единицы измерения смещения в байты.

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

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

Интересные столбцы выделены цветами:

голубой = размер пакета

зеленый = наличие флага MF

красный = смещение

оранжевый = идентификатор

Строки выделять не стал, поскольку розовая строка здесь означает конец фрагментированной последовательности. Плюс важно учитывать, что на этом скрине в столбце Offset значение смещения не в байтах.

Установка iPerf3 на Linux и в Windows

Перейдем к практике, тренироваться будем на той же лабе, которая использовалась в посте про MTU. Вот топология сети:

Далее будет краткий гайд по установке и использованию iPerf в Linux и Windows, кому этот момент очевиден, можно смело пропускать.

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

Iperf это утилита командной строки в Windows, установка его здесь довольная простая, скачиваете архив по этой ссылке, выбирайте самую свежую версию, она внизу. Внутри полученного архива будет папка с именем iperf+номер_версии_разрядность_ОС:

Если хотите, можете скинуть эту папку в любое удобное вам место и на этом установка будет завершена. Я же создам в корне диска C папку с именем iperf3 и скопирую в него содержимое папки "iperf3.17_64.", так будет проще:

При желании можете добавить путь к файлу iperf3.exe в переменную PATH, тогда для запуска программы не придется каждый раз в командной строке переходить по пути C:\iperf3 чтобы запустить программу.

Установку в Linux буду показывать на примере Debian 10, пишем две команды:

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

Примечание

В репозитории дистрибутива, который вы используете, может находиться пакет не с самой последней версией iPerf, в моем случае вопрос версии не принципиален, нам просто надо посмотреть на работу фрагментации, но если вы планируете использовать его для тестов своих каналов, учитывайте два момента: тесты, выполненные на iperf разных версий, могут не показать реальной картины (обычно результаты хуже чем есть на самом деле), в разных версиях есть разные баги, влияющие на результаты тестирования. Microsoft же вообще не рекомендует использовать iPerf для тестов в Windows.

Как запустить тест скорости iPerf

Запустить тест скорости в iPerf дело не хитрое, начнем с сервера. Запуск сервера делается так:

Сервер ожидает запросы от клиента на порт 5201 любого из транспортных протоколов: TCP, UDP, SCTP. Если у вас используется firewall, убедитесь что порт открыт.

Клиента iperf будем запускать в Windows, для этого нужно запустить командую строку желательно от имени администратора, перейти в папку, где лежит exe файл (переходить никуда не надо будет, если добавить путь к iperf3.exe в переменную PATH):

Опции для разных ОС одинаковые, пользователи Linux могут получить справку при помощи утилиты man, в Windows можно написать iperf3.exe -h, но лучше обратиться к документации. Опции iperf делятся на серверные, клиентские и универсальные.

Теперь по поводу команды в Windows: -c говорит о том, что iperf запускается в режиме клиента, при этом данной опции надо передать IP-адрес сервера. Опция -f k говорит iperf о том, что скорость должна быть отображена в kbps, а -M 1300 задает размер TCP MSS 1300 байт.

Учитывайте, что какой бы протокол вы не использовали, iperf выставить df-bit = 1 и это никак не изменить, насколько мне известно, и это нужно учитывать при дальнейших тестах, плюс по умолчанию iperf генерирует пакеты только в одну сторону: от клиента к серверу. На сервере статистика тоже отображается, вот статистика для соединения, которое мы инициировали командой, выполненной выше в Windows:

Более детальную информацию о тесте можно получать, если использовать опцию -V на клиенте и сервере.

Как убрать df-bit у транзитного IP-пакета на роутере Cisco

Пожалуй, самый плохой сценарий для маршрутизатора в вопросах фрагментации, это когда маршрутизатор выполняет эту самую фрагментацию. Выше я не случайно написал про df-bit, который iPerf всегда выставляет на генерируемые им пакеты. С выставленным df-bit мы фрагментацию никогда не увидим, значит, его надо обнулить, как это сделать средствами Windows я не знаю и тратить время на то, чтобы с этим разобраться я не захотел, а вот на роутерах Cisco можно написать route-map и навешать этот route-map на интерфейс, в который будут входить пакеты с установленным df-bit, который мы хотим обнулять.

Примечание

Для тех, кто читал пост про MTU. В той лабе на интерфейсе CSR в сторону коммутатора был создан саб-интерфейс Gi2.200, на нем и был настроен IP-адрес, сейчас же саб-интерфейс Gi2.200 удален, IP-адрес перенесен на Gi2, а на линке CSR/SW кадры ходят без вланов.

Создать route-map можно, например, такой:

Строка set ip df 0 как раз и заставляет обнулять df-bit, а RM_DEL-DF-BIT это просто имя route-map, которое я ей придумал. Роут-мапу нам надо повешать на интерфейс Gi2, поскольку пакеты с df-bit, который мы хотим обнулять, будут входить именно в интерфейс (если бы остался саб-интерфейс Gi2.200, то тогда вешать надо было бы на него). Делается это так:

И давайте зададим IP MTU 1300 байт на интерфейс Gi1:

Всё, лабу подготовили.

Как работает фрагментация IP пакетов на роутере

Наконец-то мы добрались до самой фрагментации. Запустим iperf на Винде(команда iperf3.exe -c 10.0.0.2 -f k -M 1370) и снимем дампы:

1. Первый с линка между SW/Win, здесь будут идти не фрагментированные пакеты с TCP MSS 1370 байт, это уже больше чем MTU интерфейса Gi1, но к значению MSS нужно будет добавить еще размеры заголовков TCP и IP.

2. Второй дамп будем делать с линка Host_1/CSR. Здесь мы сможем увидеть фрагментированные пакеты, видя два дампа, мы сможем сделать вывод о том, что фрагментацию выполняет именно роутер.

Важно найти один и тот же пакет как в первом, так и во втором дампе, проще всего это сделать по идентификатору пакета. Вот пакет с номером 2e8b на линке SW/Win:

Размер пакета 1410 байт, df-bit = 1. А вот этот же пакет на линке Host_1/CSR:

Во-первых, пакетов два: 1300 байт и 130 байт, а это больше изначальных 1410, уже неприятно, особенно, если счёт будем вести на миллионы. Во-вторых, видим, что пакеты, которые идут в сторону Debian, имеют df-bit = 0, из увиденного делаем выводы:

1. Route-map работает, CSR снимает df-bit и делает фрагментацию.

2. Фрагментацию выполняет роутер.

Не вижу сейчас особого смысла смотреть внутрь пакета, т.к. все интересующие нас поля я вывел в дамп, но если что, вот пакет, который генерировала Винда:

Вот первый фрагмент на выходе из CSR Gi1:

А вот второй фрагмент:

Мы посмотрели пример фрагментации пакетов, понятно, что делать это на роутерах не очень правильно, но иногда приходится.

В следующий раз поговорим про Path MTU Discovery, для этого нужно отвязать route-map от интерфейса Gi2, чтобы роутер перестал обнулять df-bit:

IP MTU 1300 байт на линке Gi1 оставляем.

Вопросы для ваших ответов

Может ли фрагментированный IP пакет быть меньше 68 байт и почему?

Напомню топологию

Представим ситуации: на интерфейсе Gi2 роутера CSR настроен IP MTU 1400 байт, на всех остальных линках IP MTU 1500 байт, хост Windows генерирует в сторону Linux пакеты размером 1450 байт, что с этими пакетами будет?

Имеется линк с IP MTU 700 байт: на сколько фрагментов и какого разрмера будет разбит пакет1400 байт?

Имеется линк с IP MTU 725 байт: на сколько фрагментов и какого разрмера будет разбит пакет1430 байт?

Видео версия

Для тех, кому проще смотреть и слушать есть видео версия