IP-фрагментация и сборка

Question

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

Я понимаю, как это работает, а именно, как дейтаграммы разделены на более мелкие куски, так как сетевые соединения имеют MTU. Однако пример на картине меня смущает.

Итак, первые два раздела показывают длину 1500, потому что это MSU, но разве это не значит, что последний должен иметь 1000 (всего 4000 байтов), а не 1040? Откуда взялись эти дополнительные 40 байт? Я предполагаю, что из-за того, что предыдущие два фрагмента имели заголовок 20 байтов, эти дополнительные 40 байтов данных должны были куда-то перемещаться, поэтому он будет поступать в последний фрагмент?

Fragflag по существу означает, что есть еще один фрагмент, поэтому все они будут иметь Fragflag из 1, за исключением последнего фрагмента, который будет в нуле. Однако я не понимаю, что такое смещение или как оно рассчитывается. Почему первое смещение на ноль? Почему мы разделили байты в поле данных (1480) на 8, чтобы получить второе смещение? Откуда это произошло? Кроме того, я предполагаю, что каждое смещение фрагментов будет только увеличиваться на это значение?

Например, первый фрагмент будет иметь смещение 0, второе 185, третье 370 и четвертое 555? (370 + 185)

Спасибо за помощь!

Answer 1

В каждом пакете имеется 20-байтовый заголовок. Таким образом, исходный пакет содержит 3980 байт данных. Эти фрагменты содержат 1480, 1480 и 1020 байтов данных. 1480 + 1480 + 1020 = 3980

Каждый бит в заголовке является ценным. Разделение смещения на 8 позволяет ему поместиться в 13 бит вместо 16. Это означает, что каждый пакет, кроме последнего, должен содержать несколько байтов данных, которое кратно 8, что не является проблемой.

Answer 2

Размер смещения составляет 13 бит в заголовке IP, но нам нужны 16 бит, как в худшем случае. Поэтому мы используем коэффициент масштабирования 8, т. Е. (2^16/2^13).

Answer 3

Фрагментация и сборка были описаны исключительно в RFC 791. Пройдите через Internet Protocol Specification RFC. RFC имеет различные разделы, объясняющие фрагментацию и повторную сборку. Все ваши сомнения и вопросы хорошо удовлетворяются в нем.

Ans 1: Что касается длин пакета: Исходный пакет содержит 4000 байт. Этот пакет является полностью IP-пакетом и, следовательно, также содержит заголовок IP. Таким образом, длина полезной нагрузки на самом деле равна 4000 - (длина заголовка IP i. E. 20).

Фактическая полезная нагрузка Длина = 4000 - 20 = 3980

Теперь пакет фрагментирован из-за того, что длина больше, чем MTU (1500 байт).

Таким образом, первый пакет содержит 1500 байтов, который включает в себя заголовок IP + полезную нагрузку.

1500 = 20 (IP-заголовка) + 1480 (полезная нагрузка данных)

Аналогично для другого пакета.

Третий пакет должен содержать оставшиеся данные, оставшиеся (3980 - 1480 -1480) = 1020

Таким образом, длина пакета составляет 20 (IP-заголовок) + 1020 (полезная нагрузка) = 1040

Ans 2 : Смещение - это адрес или локатор, откуда данные начинаются со ссылкой на исходную полезную нагрузку данных. Для IP полезная нагрузка данных включает в себя все данные, которые после заголовка IP и заголовок Options. Таким образом, система/маршрутизатор принимает полезную нагрузку и делит ее на более мелкие части и сохраняет следы смещения со ссылкой на исходный пакет, чтобы можно было выполнить сборку.

, как указано на странице 12. RFC

"Поля смещения фрагмента сообщает приемник позиции фрагмента в исходной дейтаграмме. Фрагмент смещения и длины определяют часть исходной дейтаграммы охватываемой этот фрагмент. Флаг более-фрагментов указывает (путем сброса) последний фрагмент. Эти поля предоставляют достаточную информацию для повторной сборки дейтаграмм. «

Смещение фрагмента измеряется в единицах по 8 байт каждый. Он имеет 13-битное поле в заголовке IP. Как было сказано на странице 17 RFC

«Это поле указывает, где в дейтаграмму этот фрагмент belongs.The смещение фрагмента измеряется в единицах 8 октетов (64 бит). Первый фрагмент имеет нулевое смещение.»

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

Страница 28 из RFC пишет: * Фрагменты учитываются в единицах 8 октетов. Стратегия фрагментации сконструирована так, что нефрагментированная датаграмма имеет всю нулевую информацию фрагментации (MF = 0, смещение фрагмента = 0). Если интернет-датаграмма фрагментирована, ее часть данных должна быть , разбитой на восьми октетных границах. Этот формат позволяет 2 ** 13 = 8192 фрагментов по 8 октетов для всего 65536 октетов. Обратите внимание, что это согласуется с полем общей длиной дейтаграммы (конечно, заголовок учитывается в общей длине , а не во фрагментах). *

Answer 4

те не дополнительные биты, но общая длина последнего фрагмента , , поскольку 1500 - это MTU, это означает, что может быть 1500 байт данных в одном фрагменте, включая заголовок. Заголовок добавляется с каждым фрагментом. это означает, что в фрагменте мы можем отправить 1500-20 = 1480 байт данных. Данаграмма 4000. датаграмма - это не что иное, как инкапсуляция данных на сетевом уровне. Так что все данные, которые мы должны отправить, составляют 4000-20 = 3980. затем он фрагментируется на 3 части (ceil (3980/1480)), каждый из которых имеет длину 1480, 1480, 1020 соответственно. поэтому, когда заголовок 20B добавляется к последнему фрагменту, его длина становится равной 1020 + 20 = 1040.