Определить размер исходной датаграммы можно только тогда, когда получен последний фрагмент. Значение смещения последнего фрагмента (555) дает смещение, равное 4440 байтам, относительно исходной IP-датаграммы. Если к этом значению добавить байты данных из последнего фрагмента (680 = 700 - 20), то мы получим 5120 байт, это длина исходной IP- датаграммы. В этом случае при добавлении 20 байтов к заголовку IP получается IP-датаграмма исходного размера (4440 + 680 + 20 = 5140). Проблемы фрагментации IP Существует ряд проблем, которые делают нежелательным использование IP-фрагментации. При разбивке IP-датаграммы нагрузка на ЦП и память несколько возрастает.
Это верно как для отправителя, так и для маршрутизатора, находящегося на пути между отправителем и получателем. Процесс фрагментации фактически состоит из создания заголовков для фрагментов и копирования данных исходной датаграммы в эти фрагменты. Этот относительно эффективный процесс, поскольку информация, необходимая для создания фрагментов, уже имеется в готовом виде. Однако при сборке фрагментов нагрузка на получателя значительно увеличивается, поскольку получатель должен выделить память для поступающих фрагментов и, после того как все фрагменты получены, объединить их в исходную датаграмму.
Сборка фрагментов на узле не представляет никаких трудностей, поскольку узел обладает достаточными ресурсами (время и память) для выполнения этого задания. Однако сборка фрагментов на маршрутизаторе, первоочередной задачей которого является переадресация пакетов с максимально возможной скоростью, представляется малоэффективной. Маршрутизатор не предназначен для «удержания» пакетов в течение какого- либо периода времени. Кроме того, маршрутизатор, выполняющий сборку фрагментов, должен выделять под этот процесс самый большой буфер обмена (18 Кбайт), поскольку размер исходного IP-пакета остается для него неизвестным до тех пор, пока не получен последний фрагмент.
Другая проблема, связанная с фрагментацией, относится к обработке «выпавших» фрагментов. При выпадении (утрате) одного из фрагментов IP-датаграммы требуется повторная отправка всей датаграммы, которая также должна пройти фрагментирование. Рассмотрим эту проблему на примере сетевой операционной системы NFS (Network File System). По умолчанию размер блока чтения и записи данных в NFS равен 8192 байт. Таким образом, в NFS размер IP/UDP-датаграммы приблизительно составит 8500 байт, включая NFS-, UDP- и IP-заголовки.
Отправляющая станция, которая подключена к сети Ethernet (MTU = 1500 байт), должна будет разбить датаграмму размером в 8500 байт на шесть частей (пять фрагментов по 1500 байт и один фрагмент – 1100 байт). Если из-за перегрузки канала данных какой-либо фрагмент будет утерян, то отправитель будет вынужден повторно отправить всю исходную датаграмму, а это означает, что потребуется повторная разбивка этой датаграммы на шесть частей. Если из шести пакетов канал сбрасывает один, то вероятность того, что по этому каналу можно передать какие-либо NFS-данные, очень мала, поскольку по крайней мере один IP- фрагмент будет сбрасываться из каждой исходной 8500-байтововой IP-датаграммы.
У брандмауэров, которые фильтруют пакеты или манипулируют ими, используя для этого данные с 4 по 7 уровень (L4 – L7) модели OSI, могут возникнуть проблемы с корректной обработкой IP-фрагментов. При наличии повреждений в IP-фрагментах брандмауэр может заблокировать непервоначальные фрагменты, поскольку в них не содержится информация, которая соответствует установкам пакетного фильтра. Это означает, что принимающий узел не сможет собрать исходную IP-датаграмму. Если брандмауэр настроен таким образом, что он позволяет неначальным фрагментам, имеющим достаточное количество информации, должным образом проходить через фильтр, тогда создается угроза атаки, использующей неначальные пакеты.
Кроме того, некоторые сетевые устройства