Основное преимущество непрозрачной фрагментации состоит в том, что маршрутизаторы выполняют меньше работы. Так работает IP. При этом фрагменты пакета должны нумероваться таким образом, чтобы можно было восстановить исходный поток данных. В случае IP каждому фрагменту сообщается номер пакета (который есть у каждого пакета), абсолютное смещение внутри пакета (в байтах) и флажок, показывающий, является ли этот фрагмент последним в пакете. Пример такой фрагментации показан на рис. 5.38. Хотя схема очень проста, она обладает рядом важных преимуществ. По прибытии в место назначения фрагменты можно помещать в буфер в любом порядке. Кроме того, при пересечении сети с меньшим значением MTU фрагменты могут быть разделены на более мелкие фрагменты. Такая ситуация показана на рис. 5.38, в. При повторной передаче (если все фрагменты не дошли до адресата) пакет может быть разбит на фрагменты по-другому. И наконец, размер фрагментов может быть произвольным, вплоть до одного байта плюс заголовок. В любом случае пакет будет восстановлен: номер пакета и смещение помогут расположить данные в правильном прядке, а флажок укажет на конец пакета.

Рис. 5.38.Фрагментация при элементарном размере 1 байт: а — исходный пакет, содержащий 10 байт данных; б — фрагменты после прохождения через сеть с максимальным размером 8 байт; в — фрагменты после прохождения через шлюз размера 5
К сожалению, у этой схемы есть некоторые недостатки. Во-первых, это может быть более затратным, чем прозрачная фрагментация, так как заголовки фрагментов иногда передаются по связям, где без них можно обойтись. Однако настоящая проблема заключается в самом существовании фрагментов. Kent и Mogul (1987) считают, что фрагментация работает в ущерб производительности, так как при утере одного фрагмента теряется весь пакет (не говоря уже затратах на заголовки). Для хостов фрагментация оказалась тяжелым бременем, чем предполагалось вначале.
Таким образом, следует вернуться к первоначальной идее и полностью избавиться от фрагментации в сети — стратегия, использующаяся в современном Интернете. Этот процесс называется Path MTU discovery (поиск путевого значения MTU) (Mogul и Deering, 1990). Он работает так. При отправке каждого IP-пакета в его заголовок помещается информация о том, что фрагментация не разрешена. Если маршрутизатор получает слишком большой пакет, он отправляет источнику сообщение об ошибке и удаляет его (рис. 5.39). Используя информацию, содержащуюся в сообщении об ошибке, источник перераспределяет данные так, чтобы пакеты смогли пройти через маршрутизатор. Если такая же проблема возникнет на каком-то из следующих маршрутизаторов, ситуация повторится.

Рис. 5.39. Поиск путевого значения MTU
Преимущество Path MTU discovery состоит в том, что в результате источник знает необходимый размер пакета. При изменении маршрута новое путевое значение MTU станет известно источнику из новых сообщений об ошибке. Однако фрагментация между отправителем и получателем будет все равно необходима, если только путевое значение MTU не будет вычислено на более высоком уровне и передано IP. Чтобы это было возможно, TCP и IP обычно используются вместе (в виде TCP/IP). И хотя для некоторых протоколов это пока не реализовано, фрагментация все же была перенесена из сети на хосты.
Недостатком технологии Path MTU discovery является то, что отправка пакета может вызвать дополнительную задержку. Эта задержка может увеличиться в несколько раз в зависимости от того, сколько раз отправителю придется повторять отправку (меняя размер пакета), прежде чем пакет достигнет места назначения. Следовательно, возникает вопрос: существуют ли более эффективные схемы? Вероятно, да. Рассмотрим, к примеру, вариант, при котором слишком большие пакеты просто обрезаются. В таком случае получатель узнает путевое значение MTU настолько быстро, насколько это вообще возможно (по размеру полученного пакета), а также получает некоторую часть данных.
5.6. Сетевой уровень в Интернете
Теперь самое время подробно поговорить о сетевом уровне в Интернете. Но прежде чем перейти к деталям, неплохо было бы познакомиться с принципами, которые были основополагающими в прошлом, при его разработке, и которые обеспечили сегодняшний успех. В наше время люди все чаще пренебрегают ими. Между тем, эти принципы пронумерованы и включены в документ RFC 1958, с которым полезно ознакомиться (а для разработчиков протоколов он должен быть просто обязательным для прочтения, с экзаменом в конце). Этот документ использует идеи, которые были изложены в книгах (Clark, 1988; Saltzer и др., 1984). Ниже мы приведем 10 основных принципов, начиная с самых главных.
Читать дальше
Конец ознакомительного отрывка
Купить книгу