Длина указанная в полезных данных сетевого пакета не

Длина указанная в полезных данных сетевого пакета не thumbnail

В компьютерных сетях пакет — это определённым образом оформленный блок данных, передаваемый по сети в пакетном режиме. Компьютерные линии связи, которые не поддерживают пакетного режима, как, например, традиционная телекоммуникационная связь точка-точка, передают данные просто в виде последовательности байтов, символов или битов поодиночке. Если данные сформированы в пакеты, битрейт коммуникационной среды можно более эффективно распределить между пользователями, чем в сети с коммутацией каналов. При использовании сетей с коммутацией пакетов можно надёжно гарантировать пороговый битрейт, ниже которого он опускаться не будет.

Сетевой пакет может состоять из служебной информации, включающей стартовые биты (преамбулу), заголовки (headers) и прицеп (trailer), и полезную нагрузку (payload). Между пакетами, посылаемыми в сеть, обычно соблюдается межкадровый интервал (англ. Interframe gap). Максимальная длина нагрузки называется maximum transmission unit (MTU).

Существует возможность фрагментации пакета — генерация двух сетевых пакетов из одного. Происходит при превышении длины кадра MTU интерфейса, через который он в данный момент проходит. Фрагментация (и её запрещение) поддерживается протоколом IP и не предусмотрена в большинстве других протоколов. Если сетевой адаптер обнаруживает кадр длиннее его media MTU, то этот кадр обычно отбрасывается. Такое случается, если на одном хосте разрешены jumbo-кадры, а на другом — нет. Фрагментация IP-пакета увеличивает нагрузку на центральный процессор и снижает скорость передачи полезных данных этого пакета (на 2÷50 % в Ethernet-сети в зависимости от длины кадра), поэтому её стараются избегать. При потере любого фрагмента повторно должна быть передана вся последовательность, что является дополнительным риском снижения скорости. Сборка всех частей в исходный пакет производится только адресатом, даже если на каком-то участке сети MTU больше требуемого. Фрагментация пакетов может быть использована в сетевых атаках и зондировании сетей.

Разметка пакета[править | править код]

Пакет состоит из двух типов данных: управляющей информации и данных пользователя (называемых также полезной нагрузкой). Управляющая информация содержит данные, необходимые для доставки данных пользователя: адреса отправителя и получателя, коды обнаружения ошибок (типа контрольных сумм) и информацию об очерёдности. Как правило, управляющая информация содержится в заголовке и хвосте пакета, а между ними размещаются пользовательские данные.

Различные коммуникационные протоколы используют разные соглашения для разделения элементов и для форматирования данных. В протоколе «двоичной синхронной передачи» пакет отформатирован в 8-битных байтах, а для разделения элементов используются специальные символы. В других протоколах, таких как Ethernet, зафиксировано начало заголовка и элементов данных, их расположение относительно начала пакета. Некоторые протоколы форматируют информацию на уровне битов, а не байтов.

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

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

Обнаружение ошибок[править | править код]

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

Хвостовая часть пакета часто содержит данные проверки ошибок, возникших во время передачи пакета по сети.

Адрес хоста[править | править код]

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

Сравнение пакетов и дейтаграмм[править | править код]

Термин пакет распространяется на любое сообщение, форматированное как пакет, тогда как термин дейтаграмма
обычно используется для пакетов «ненадёжных» служб.[1] «Надёжной» является служба, которая уведомляет пользователя, если доставка не удалась, тогда как «ненадёжная» такого уведомления пользователя не делает. Например, IP не обеспечивает надёжного сервиса, а TCP и IP вместе его обеспечивают, тогда как UDP с IP надёжного сервиса не обеспечивают. Все эти протоколы используют пакеты, но UDP-пакеты, как правило, называют дейтаграммами.[1]

Когда сеть ARPANET впервые выступила с коммутацией пакетов, она обеспечивала надёжную процедуру доставки пакетов к серверам через свой интерфейс 1822. Сервер сети организует данные в пакет нужного формата, вставляет туда адрес компьютера назначения и посылает сообщение через интерфейс процессору передачи сообщений. Как только сообщение доставлено к серверу назначения, на посылающий сервер доставляется подтверждение. Если сеть не может доставить сообщение, на посылающий сервер будет послано извещение об ошибке.

Разработчики CYCLADES и ALOHAnet продемонстрировали, что можно построить эффективную компьютерную сеть, не обеспечивая надёжной передачи пакетов. Этот опыт позже был использован конструкторами Ethernet.

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

Пример: IP-пакет[править | править код]

IP-пакеты состоят из заголовка и полезной нагрузки. Заголовок пакета IPv4 состоит из:

  1. 4 бита содержат версию пакета: IPv4 или IPv6.
  2. 4 бита содержат длину интернет-заголовка, которая измеряется отрезками по 4 байта (например, 5 означает 20 байт).
  3. 8 бит содержат тип обслуживания, известный также как качество обслуживания (QoS), описывающее приоритеты пакета.
  4. 16 бит содержат длину пакета в байтах.
  5. 16 бит содержат тег идентификации, помогающий восстановить пакет из нескольких фрагментов.
  6. 3 бита содержат нуль, флаг разрешения фрагментации пакета (DF: не фрагментировать), а также флаг разрешения дальнейшей фрагментации (MF: фрагментировать дальше).
  7. 13 бит содержат смещение фрагмента, поле для идентификации положение фрагмента в исходном пакете.
  8. 8 бит содержат время жизни (TTL), которое определяет количество переходов (через маршрутизаторы, компьютеры и сетевые устройства), разрешённых сделать пакету, прежде чем он исчезнет (например, пакету с TTL 16 разрешено пройти не более 16 маршрутизаторов, чтобы добраться до места назначения).
  9. 8 бит содержат протокол (TCP, UDP, ICMP и т. д.).
  10. 16 бит содержат контрольную сумму заголовка, используемую при обнаружении ошибок.
  11. 32 бит содержат IP-адрес источника.
  12. 32 бит содержат адрес назначения.

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

Доставка не гарантируется[править | править код]

Многие сети не гарантируют доставку, отсутствие дубликатов пакетов и порядок их доставки, как например, протокол UDP в сети Интернет. Тем не менее, это можно сделать в верхней части пакета услуг транспортного уровня, который может обеспечить такую защиту. TCP и UDP являются лучшими примерами 4-го транспортного уровня, одного из семи уровней сетевой модели OSI.

Заголовок пакета определяет тип данных, номер пакета, общее количество пакетов и IP-адреса отправителя и получателя.

Иногда используется термин «кадр» для обозначения пакетов в точности так, как он используется при передаче сигнала по проводам или радио.

См. также[править | править код]

  • Анализатор трафика
  • TCP
  • TCP/IP
  • DHCP
  • Моделирование трафика
  • Tail drop

Примечания[править | править код]

  1. 1 2 Kurose, James F. & Ross, Keith W. (2007), «Computer Networking: A Top-Down Approach» ISBN 0-321-49770-8

Ссылки[править | править код]

  • Dean, Tamara (2006). Network+ Guide to Networks. Boston, Massachusetts: Thomson Course Technology.

Источник

IP (internet protocol — протокол) — маршрутизируемый сетевой протокол, протокол сетевого уровня семейства («стека») TCP/IP. IPv4 описан в RFC 791 (сентябрь 1981 года).

Основные положения:

  1. IP – основной протокол стека TCP/IP, он решает вопросы доставки сообщений между узлами составной сети.

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

  3. IP относится к протоколам без установки соединений. IP используется для негарантированной доставки данных, разделяемых на так называемые пакеты от одного узла сети к другому. Это означает, что на уровне этого протокола (третий уровень сетевой модели OSI) не даётся гарантий надёжной доставки пакета до адресата. В частности, пакеты могут прийти не в том порядке, в котором были отправлены, продублироваться (когда приходят две копии одного пакета; в реальности это бывает крайне редко), оказаться повреждёнными (обычно повреждённые пакеты уничтожаются) или не прибыть вовсе. Гарантию безошибочной доставки пакетов дают протоколы более высокого (транспортного уровня) сетевой модели OSI — например, Порты TCP — которые используют IP в качестве транспорта.

  4. Протокол IP использует принцип маршрутизации. Вид таблицы IP- маршрутизации зависит от конкретной реализации маршрутизатора, но в таблицах всех типов маршрутизаторов есть все ключевые поля, необходимые для выполнения маршрутизации. Существует несколько источников, поставляющих записи в таблицу маршрутизации:

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

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

Рассмотрим поля структуру IP- пакета на конкретном примере.
Длина указанная в полезных данных сетевого пакета не

  1. Поле Номер версии (Version) занимает 4 бита, указывает версию протокола IP (IPv4 или IPv6).

  2. Поле Длина заголовка (IHL) IP- пакета занимает 4 бит и указывает значение длины заголовка, измеренное в 32-битовых словах. Обычно заголовок IP-пакета имеет длину в 20 байт (пять 32-битовых слов), но при увеличении объема служебной информации эта длина может быть увеличена. Наибольший заголовок занимает 60 октетов.

  3. Поле Тип сервиса (Type of Service) занимает один байт и задает приоритетность пакета и вид критерия выбора маршрута. Первые три бита этого поля образуют подполе приоритета пакета (Precedence) . Приоритет может иметь значения от самого низкого – 0 (нормальный пакет) до самого высокого – 7 (пакет управляющей информации) . Маршрутизаторы и компьютеры могут принимать во внимание приоритет пакета и обрабатывать более важные пакеты в первую очередь. Поле Type of Service содержит также три бита, определяющие критерий выбора маршрута. Реально выбор осуществляется между тремя альтернативами: малой задержкой, высокой достоверностью и высокой пропускной способностью. Во многих сетях улучшение одного из этих параметров связано с ухудшением другого, кроме того, обработка каждого из них требует дополнительных вычислительных затрат. Поэтому редко, когда имеет смысл устанавливать одновременно хотя бы два из этих трех критериев выбора маршрута. Зарезервированные биты имеют нулевое значение. Установленный

    * бит D (delay) говорит о том, что маршрут должен выбираться для минимизации задержки доставки данного пакета
    * бит Т – для максимизации пропускной способности
    * бит R – для максимизации надежности доставки.

  4. Поле Общая длина (Total Length) занимает 2 байта и означает общую длину пакета с учетом заголовка и поля данных. Максимальная длина пакета ограничена разрядностью поля, определяющего эту величину, и составляет 65 535 байт, однако в большинстве компьютеров и сетей такие большие пакеты не используются. При передаче по сетям различного типа длина пакета выбирается с учетом максимальной длины пакета протокола нижнего уровня, несущего IP- пакеты. Если это кадры Ethernet, то выбираются пакеты с максимальной длиной в 1500 байт, умещающиеся в поле данных кадра Ethernet. В стандарте предусматривается, что все хосты должны быть готовы принимать пакеты вплоть до 576 байт длиной (приходят ли они целиком или по фрагментам). Существует такое правило: хостам рекомендуется отправлять пакеты размером более чем 576 байт, только если они уверены, что принимающий хост или промежуточная сеть готовы обслуживать пакеты такого размера.

  5. Поле Идентификатор пакета (Identification) занимает 2 байта и используется для распознавания пакетов, образовавшихся путем фрагментации исходного пакета. Все фрагменты должны иметь одинаковое значение этого поля.

  6. Поле Флаги (Flags) занимает 3 бита и содержит признаки, связанные с фрагментацией: установленный бит DF (Do not Fragment) запрещает маршрутизатору фрагментировать данный пакет, а установленный бит MF (More Fragments) говорит о том, что данный пакет является промежуточным (не последним) фрагментом. Оставшийся бит зарезервирован.

  7. Поле Смещение фрагмента (Fragment Offset) занимает 13 бит и задает смещение в байтах поля данных этого пакета от начала общего поля данных исходного пакета, подвергнутого фрагментации. Используется при сборке/разборке фрагментов пакетов при передачах их между сетями с различными величинами MTU. Смещение должно быть кратно 8 байт.

  8. Поле Время жизни (Time to Live) занимает 1 байт и означает предельный срок, в течение которого пакет может перемещаться по сети. Время жизни данного пакета измеряется в секундах и задается источником передачи. На маршрутизаторах и в других узлах сети по истечении каждой секунды из текущего времени жизни вычитается единица; единица вычитается и в том случае, когда время задержки меньше секунды. Поскольку современные маршрутизаторы редко обрабатывают пакет дольше, чем за одну секунду, то время жизни можно считать равным максимальному числу узлов, которые разрешено пройти данному пакету до того, как он достигнет места назначения. Если параметр времени жизни станет нулевым до того, как пакет достигнет получателя, этот пакет будет уничтожен. Время жизни можно рассматривать как часовой механизм самоуничтожения. Значение этого поля изменяется при обработке заголовка IP-пакета.

  9. Идентификатор Протокол верхнего уровня (Protocol) занимает 1 байт и указывает, какому протоколу верхнего уровня принадлежит информация, размещенная в поле данных пакета (например, это могут быть сегменты протоколов верхних уровней или протоколов маршрутизации). Значения идентификаторов для различных протоколов приводятся в документе RFC 3232 – Assigned Numbers.

  10. Контрольная сумма (Header Checksum) занимает 2 байта и рассчитывается только по заголовку. Поскольку некоторые поля заголовка меняют свое значение в процессе передачи пакета по сети (например, время жизни), контрольная сумма проверяется и повторно рассчитывается при каждой обработке IP- заголовка. Контрольная сумма – 16 бит – подсчитывается как дополнение к сумме всех 16-битовых слов заголовка. При вычислении контрольной суммы значение самого поля “контрольная сумма” устанавливается в нуль. Если контрольная сумма неверна, то пакет будет отброшен, как только ошибка будет обнаружена.

  11. Поля IP-адрес источника (Source IP Address) и

  12. IP-адрес назначения (Destination IP Address) имеют одинаковую длину – 32 бита – и одинаковую структуру.

  13. Поле Опции (IP Options) является необязательным и используется обычно только при отладке сети. Механизм опций предоставляет функции управления, которые необходимы или просто полезны при определенных ситуациях, однако он не нужен при обычных коммуникациях. Это поле состоит из нескольких подполей, каждое из которых может быть одного из восьми предопределенных типов. В этих подполях можно указывать точный маршрут прохождения маршрутизаторов, регистрировать проходимые пакетом маршрутизаторы, помещать данные системы безопасности, а также временные отметки. Так как число подполей может быть произвольным, то в конце поля Опции должно быть добавлено несколько байт для выравнивания заголовка пакета по 32-битной границе.

  14. Поле Выравнивание (Padding) используется для того, чтобы убедиться в том, что IP- заголовок заканчивается на 32-битной границе. Выравнивание осуществляется нулями.

Фрагментация IP пакетов: MTU, MSS, и PMTUD. PMTUD (Path MTU Discovery) и проблема фрагментации пакетов (network mtu ping packet)

Почему же работают пинг при проблемах с MTU? Пакеты ICMP Request и Relpy имеют размер от 32 до 64 байтов, пингуемый сервер возвращает очень мало информации, которая вполне укладывается в допустимый размер вместе со всеми заголовками.

Протокол Порты TCP позволяет согласовать значение максимального размера сегмента (MSS) обоим участникам соединения. Каждая сторона указывает предлагаемый размер MSS в поле ОПЦИИ заголовка пакета TCP. Будет принято наименьшее из двух значений. Такое согласование позволяет избежать фрагментации пакетов при прохождении через маршрутизаторы и шлюзы, и их последующей сборки на целевом хосте, что приводит к задержкам и снижению скорости передачи.

Фрагментация подразумевает разбиение блока данных (пакета) на равные части. Соответственно после фрагментации следующим этапом следует сборка фрагментов. Протокол IP позволяет выполнять фрагментацию только тех пакетов, которые поступают на входные порты маршрутизаторов. Следует различать фрагментацию сообщений в узле-отправителе, и динамическую фрагментацию сообщений в маршрутизаторах. Дело в том, что практически во всех стеках протоколов есть протоколы, которые осуществляют фрагментацию сообщений прикладного уровня на такие части, которые укладываются в кадры канального уровня. В стеке TCP/IP, например, эту задачу решает протокол транспортного уровня TCP. Этот протокол может разбивать поток байтов, передаваемый ему с прикладного уровня на сообщения нужного размера (например, на 1460 байт для протокола Ethernet).

Поэтому протокол IP в узле-отправителе не использует свои возможности по фрагментации пакетов.

А вот при необходимости передать пакет в следующую сеть, для которой размер пакета является слишком большим, IP-фрагментация становится необходимой.

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

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

Сети Ethernet имеют значение MTU, равное 1500 байт, сети FDDI – 4096 байт, а сети Х.25 чаще всего работают с MTU в 128 байт.

Итак, необходимость фрагментации пакетов на уровне IP мы пояснили. Теперь перейдем к самому процессу фрагментации пакетов IP.

Как мы уже выяснили из предыдущего раздела нашего урока, в поле Flags заголовка IP-пакет может быть помечен как не фрагментируемый. Любой пакет, помеченный таким образом, не может быть фрагментирован модулем IP ни при каких условиях.

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

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

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

Для того, чтобы не перепутать фрагмент различных типов, в заголовке IP-пакетов используется поле Identification.

Модуль протокола IP, отправляющий пакет, устанавливает в поле Identification значение, которое должно быть уникальным для данной пары отправитель – получатель. Кроме этого отправитель в заголовке пакета устанавливает время, в течение которого пакет может быть активным в сети.

Поле смещения фрагмента (Fragment Offset) сообщает получателю положение фрагмента в исходном пакете. Смещение фрагмента и длина определяют часть исходного пакета, принесенную этим фрагментом. Флаг “more fragments” показывает появление последнего фрагмента. Модуль протокола IP, отправляющий неразбитый на фрагменты пакет, устанавливает в нуль флаг “more fragments” и смещение во фрагменте.

Все эти поля дают достаточное количество информации для сборки пакета.

Итак, чтобы разделить на фрагменты большой пакет, модуль протокола IP, установленный, например, на маршрутизаторе, создает несколько новых пакетов и копирует содержимое полей IP-заголовка из большого пакета в IP-заголовки всех новых пакетов. Данные из старого пакета делятся на соответствующее число частей, размер каждой из которых, кроме самой последней, обязательно должен быть кратным 8 байт.

Размер последней части данных равен полученному остатку.

Каждая из полученных частей данных помещается в новый пакет.

Когда происходит фрагментация, то некоторые параметры IP-заголовка копируются в заголовки всех фрагментов, а другие остаются лишь в заголовке первого фрагмента.

Процесс фрагментации может изменить значения данных, расположенных в поле параметров, и значение контрольной суммы заголовка, изменить значение флага “more fragments” и смещение фрагмента, изменить длину IP-заголовка и общую длину пакета.

В заголовок каждого пакета заносятся соответствующие значения в поле смещения “fragment offset”, а в поле общей длины пакета помещается длина каждого пакета.

Таким образом, первый фрагмент будет иметь в поле “fragment offset” нулевое значение. Во всех пакетах, кроме последнего, флаг “more fragments” устанавливается в единицу, а в последнем фрагменте – в нуль.

Теперь давайте рассмотрим процесс сборки фрагментов пакетов.

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

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

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

Однако, поскольку поле идентификатора допускает 65 536 различных значений, некоторые хосты могут использовать просто уникальные идентификаторы, не зависящие от адреса получателя.

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

Процедура объединения заключается в помещении данных из каждого фрагмента в позицию, указанную в заголовке пакета в поле “fragment offset”.

Каждый модуль IP должен быть способен передать пакет из 68 байт без дальнейшей фрагментации. Это связано с тем, что IP-заголовок может включать до 60 байт, а минимальный фрагмент данных – 8 байт. Каждый получатель должен быть в состоянии принять пакет из 576 байт в качестве единого куска либо в виде фрагментов, подлежащих сборке. Если бит флага запрета фрагментации (Don’t Fragment, DF) установлен, то фрагментация данного пакета запрещена, даже если в этом случае он будет потерян.

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

Итак, после длительных объяснений давайте закрепим на примере все, что мы сейчас узнали о фрагментации IP-пакетов.

Рассмотрим процесс фрагментации IP-пакетов при передаче между сетями с разным размером пакетов на примере, который показан на этом рисунке.
Длина указанная в полезных данных сетевого пакета не

Канальный и физический уровни обозначены, как К1, Ф1, К2, Ф2 соответственно.

Пусть компьютер 1 связан с сетью, имеющей значение MTU в 4096 байт, например с сетью FDDI.

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

В первом пакете величина поля смещения равна 0, а во втором – 2800.

Признак фрагментации во втором пакете равен нулю, что показывает, что это последний фрагмент пакета.

Общая величина IP-пакета составляет 2800 плюс 20 (размер IP-заголовка), то есть 2820 байт, что умещается в поле данных кадра FDDI.

Далее модуль IP компьютера 1 передает эти пакеты своему сетевому интерфейсу (образуемому протоколами канального уровня К1 и физического уровня Ф1)

Сетевой интерфейс отправляет кадры следующему маршрутизатору.

После того, как кадры пройдут уровень сетевого интерфейса маршрутизатора (К1 и Ф1) и освободятся от заголовков FDDI, модуль IP по сетевому адресу определяет, что прибывшие два пакета нужно передать в сеть 2, которая является сетью Ethernet и имеет значение MTU, равное 1500.

Следовательно, прибывшие IP-пакеты необходимо фрагментировать.

Маршрутизатор извлекает поле данных из каждого пакета и делит его еще пополам, чтобы каждая часть уместилась в поле данных кадра Ethernet.

Затем он формирует новые IP-пакеты, каждый из которых имеет длину 1400 + 20 = 1420 байт, что меньше 1500 байт, поэтому они нормально помещаются в поле данных кадров Ethernet.

В результате в компьютер 2 по сети Ethernet приходят четыре IP-пакета с общим идентификатором 486.

Протокол IP, работающий в компьютере 2, должен правильно собрать исходное сообщение.

Если пакеты пришли не в том порядке, в котором были посланы, то смещение укажет правильный порядок их объединения.

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

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

Таймер устанавливается на максимальное из двух значений: первоначальное установочное время ожидания и время жизни, указанное в принятом фрагменте.

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

Источник