Основное преимущество непрозрачной фрагментации состоит в том, что маршрутизаторы выполняют меньше работы. Так работает 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 основных принципов, начиная с самых главных.

1.    Убедитесь в работоспособности. Нельзя считать разработку (или стандарт) законченной, пока не проведен ряд успешных соединений между прототипами. Очень часто разработчики сначала пишут тысячестраничное описание стандарта, утверждают его, а потом обнаруживается, что он еще очень сырой или вообще неработоспособен. Тогда пишется версия 1.1 стандарта. Так бывает, но так быть не должно.

2.    Упрощайте. Если есть сомнения, всегда самый простой выбор является самым лучшим. Уильям Оккам (William Occam) декларировал этот принцип еще в XIV веке («Бритва Оккама»). Его можно выразить следующим образом: Борись с излишествами. Если какое-то свойство не является абсолютно необходимым, забудьте про него, особенно если такого же эффекта можно добиться комбинированием уже имеющихся свойств.

3.    Всегда делайте четкий выбор. Если есть несколько способов реализации одного и того же, необходимо выбрать один из них. Увеличение количества способов — это порочный путь. В стандартах часто можно встретить несколько опций, режимов или параметров. Почему так получается? Лишь потому, что при разработке было несколько авторитетных мнений на тему того, что является наилучшим. Разработчики должны избегать этого и сопротивляться подобным тенденциям. Надо просто уметь говорить «Нет».

4.    Используйте модульный принцип. Этот принцип напрямую приводит к идее стеков протоколов, каждый из которых работает на одном из независимых уровней. Таким образом, если обстоятельства складываются так, что необходимо изменить один из модулей или уровней, то это не затрагивает других частей системы.

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

6.    Избегайте статичности свойств и параметров. Если есть какие-то обязательные параметры (например, максимальный размер пакета), то лучше заставить отправителя и получателя договариваться об их конкретных значениях, чем жестко закреплять их.

7.    Проект должен быть хорошим, но он не может быть идеальным. Очень часто разработчики создают хорошие проекты, но не могут предусмотреть какие-нибудь

причудливые частные случаи. Не стоит портить то, что сделано хорошо и работает в большинстве случаев. Вместо этого имеет смысл переложить все бремя ответственности за «улучшения» проекта на тех, кто предъявляет свои странные требования.

8.    Тщательно продумывайте отправку данных, но будьте снисходительны при приеме данных. Другими словами, посылайте только те пакеты, которые полностью соответствуют всем требованиям стандартов. При этом надо иметь в виду, что приходящие пакеты не всегда столь идеальны и их тоже нужно обрабатывать.

9.    Продумайте масштабируемость. Если в системе работают миллионы хостов и миллиарды пользователей, о централизации можно забыть. Нагрузка должна быть распределена максимально равномерно между имеющимися ресурсами.