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

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

Когда IP датаграмма фрагментирована, она не собирается вновь до тех пор, пока не достигнет конечного пункта назначения. (Для некоторых других сетевых протоколов процесс повторной сборки отличается от описанного выше, при этом повторная сборка осуществляется на маршрутизаторе следующей пересылки, а не в конечном пункте назначения.) На уровне IP сборка осуществляется в конечном пункте назначения. Это сделано для того, чтобы сделать фрагментацию и повторную сборку прозрачной для транспортных уровней (TCP и UDP), хотя это может вести к некоторой потере производительности. Существует вероятность, что фрагмент датаграммы будет снова фрагментирован (возможно даже несколько раз). Информации, которая содержится в IP заголовке вполне достаточно для фрагментации и повторной сборки.

Вернемся снова к IP заголовку (см. рисунок 3.1) и рассмотрим, какие поля используются в процессе фрагментации. Поле идентификации содержит значение уникальное для каждой отправленной IP датаграммы. Это значение копируется в каждый фрагмент конкретной датаграммы. В поле флагов один бит означает, что "дальше следуют еще фрагменты" (more fragments). Этот бит устанавливается в единицу для каждого фрагмента, кроме последнего. Поле смещения фрагмента (fragment offset) содержит смещение этого фрагмента от начала исходной датаграммы. Когда датаграмма фрагментируется, поле полной длины каждого фрагмента изменяется, так чтобы соответствовать размеру фрагмента.

И в заключение, один из битов в поле флагов называется "не фрагментировать" (don't fragment). Если этот бит установлен в единицу, IP не будет фрагментировать датаграмму. Вместо этого датаграмма уничтожается, а отправителю посылается ICMP ошибка "фрагментация необходима, однако установлен бит не фрагментировать" (fragmentation needed but don't fragment bit set). Мы рассмотрим эту ошибку более подробно в следующем разделе.

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

Несмотря на то, что процесс фрагментации IP выглядит довольно прозрачным, существует одна особенность, которая делает его не всегда желательным: если один фрагмент потерялся, датаграмма должна быть целиком повторно передана. Это объясняется тем, что IP не имеет тайм-аутов и не осуществляет повторной передачи - за это несут ответственность верхние уровни. (TCP осуществляет тайм-аут и повторную передачу, UDP - нет. Некоторые UDP приложения осуществляют тайм-аут и повторную передачу самостоятельно.) Когда потерялся фрагмент из TCP сегмента, TCP отработает тайм-аут и повторно передаст TCP сегмент целиком (IP датаграмма). Не существует способа повторно передать только один фрагмент датаграммы. И действительно, если фрагментация была осуществлена промежуточным маршрутизатором, а не отправляющей системой, отправляющая система не сможет знать как датаграмма была фрагментирована в процессе передачи. Именно по этой причине (всего одной) фрагментации стараются избежать. [Kent and Mogul 1987] приводят аргументы, которые доказывают необходимость избегать фрагментации.

С использованием UDP довольно легко добиться IP фрагментации. (Позже мы увидим, что TCP старается избежать фрагментации, и для приложения практически невозможно заставить TCP отправлять сегменты, которые нуждаются в фрагментации. То есть, другими словами, отправить сегмент такого размера, для которого потребуется фрагментация, практически невозможно.) Мы воспользуемся программой sock, чтобы увеличить размер датаграммы, с таким расчетом, чтобы была осуществлена фрагментация. Максимальный размер данных во фрейме Ethernet составляет 1500 байт (рисунок 2.1), при этом 1472 байта предназначены для пользовательских данных, 20 байт отводится под IP заголовок и 8 байт под UDP заголовок. Запустим программу sock с размером данных 1471, 1472, 1473 и 1474 байта. Мы ожидаем, что в двух последних случаях произойдет фрагментация:

bsdi % sock -u -i -n1 -w1471 svr4 discard
bsdi % sock -u -i -n1 -w1472 svr4 discard
bsdi % sock -u -i -n1 -w1473 svr4 discard
bsdi % sock -u -i -n1 -w1474 svr4 discard

На рисунке 11.7 показан соответствующий вывод команды tcpdump.

1 0.0 bsdi.1112 > svr4.discard: udp 1471
2 21.008303 (21.0083) bsdi.1114 > svr4.discard: udp 1472

3 50.449704 (29.4414) bsdi.1116 > svr4.discard: udp 1473 (frag 26304:1480@0+)
4 50.450040 ( 0.0003) bsdi > svr4: (frag 26304:1@1480)

5 75.328650 (24.8786) bsdi.1118 > svr4.discard: udp 1474 (frag 26313:1480@0+)
6 75.328982 ( 0.0003) bsdi > svr4: (frag 26313:2@1480)

Содержание раздела