tanenbaum_seti_all.pages (525408), страница 143
Текст из файла (страница 143)
Возможность изменения положения хоста без необходимости изменять его адрес. 8. Возможность дальнейшего развития протокола в булущем. 9. Возможность сосуществования старого и нового протоколов в течение нескольких лет. Сетевой уровень в Интернете 633 Чтобы найти протокол, удовлетворяющий всем этим требованиям, !БТ1 издал в ВГС 1550 приглашение к дискуссиям и предложениям. Был получен двадцать один ответ.
Далеко не все варианты содержали предложсния, полностью удовлетворяющие этим требованиям. В декабре 1992 года были рассмотрены семь серьезных предложений. Их содержание варьировалось от небольших изменений в протоколе 1Р до полного отказа от него н замены совершенно другим протоколом. Одно из предложсний состояло в использовании вместо 1Р протокола С1 Л!1Л который с его 160-разрядным адресом обсспсчивал бы достаточное адресное пространство на веки вечные. Кроме того, это реше~ис объединило бы два основных сетевых протокола, Однако все же сочли, что при подобном выборе придется признать, что кое-что в мире 051 было сделано правильно, что было бы политически некорректным в интернет-кругах.
Протокол С).ХР, на самом деле, очень мало отличается от протокола 1Р. Окончательный выбор был сделан в пользу протокола, отличающегося от 1Р значительно сильнее, нежели С1.ХР. Вше одним аргументом против С!.Л!Р была его слабая поддержка типа сервиса, требовавшегося для эффектиЬной передачи мультимедиа. Три лучших предложения были опубликованы в журнале ГЕЕЕ Легюогл Майаале (Эсег!пя, 1993; Ггапс!з, 1993; Кагг и Гоп), 1993). После долгих обсуждений, переработок и борьбы за первое место была выбрана модифицированная комбинированная версия Диринга (Реет!пя) и Фрэнсиса (Ггапс!з), называемая в настоящий момент протоколом 51РР (5!шр!е 1птсгпег Ргососо! Р!па — простой интернет-протокол Плюс). Новому протоколу было дано обозначение 1Рчб (протокол 1Ру5 уже использовался в качестве экспериментального протокола потоков реального времени).
Протокол 1рч6 прекрасно справляется с поставленными задачами. Он обладает достоинствами протокола! Р и лишен некоторых его недостатков (либо они проявляются в меньшей степени), к тому же наделсн некоторыми новыми особенностями. В общем случае протокол 1Руб несовместим с протоколом 1Рч4, но зато совместим со всеми остальными протоколами Интернета, включая ТСР, Н1)1', 1СМР, 1СМР, 05РГ, ВОР и Е)Л!5, для чего гн1огда требуются небольшие изменения (в основном чтобы работать с более длшщыми адресами).
Основные особенности протокола 1Руб обсуждаются далее. Дополнительные сведения о нем можно найти в ВГС с 2460 по 2466. Прежде всего, у протокола 1Руб поля адресов длиннес, чем у 1Ру4. Они имеют длину 16 байт, что решает основную проблему, поставленную прн разработке протокола, — обеспечить практически неограниченный запас интернет-адресов. Мы еще кратко упомянем об адресах чуть позднее. Второе заметное улучшение протокола 1рчб по сравнению с !Ру4 состоит в более простом заголовке пакета.
Он состоит вссго из 7 нолей (вместо 13 у протокола 1Рч4). Таким образом, маршрутизаторы могут быстрее обрабатывать пакеты, что повышает производительность. Краткое описание заголовков будет приведено далее. Третье усовершенствование заключается в улучшенной поддержке нсобязательных параметров. Подобное изменение действительно было существенным, 534 Глава 6. Сетевой уровень так как в новом заголовке требуемые прежде поля стали необязательными. Кроме того, изменился способ представления необязательных параметров, что упростило для маршрутизаторов пропуск не относящихся к ним параметров и ускорило обработку пакетов.
В-четвертых, протокол 1Рчб демонстрирует большой шаг вперед в области безопасности. У проблемной группы проектирования Интернета 1ЕТР была полная папка вырезок из газет с сообщениями о том, как 12-летние мальчишки с помощью своего персонального компьютера по Интернету вломились в банк или военную базу. Выло ясно, что надо как-то улучшить систему безопасности.
Аутентификация и конфиденциальность являются ключевыми чертами нового 1Р- протокола. Наконец, в новом протоколе было уделено больше внимания типу предоставляемых услуг. Для этой цели в заголовке пакета 1Рч4 было отведено 8-разрядное поле (на практике не используемое), но при ожидаемом росте мультимедийного графика в будущем требовалось значительно больше разрядов. Основной заголовок! Рчб Заголовок 1Рчб показан на рис. 5.58. Поле Версия содержит число 6 для 1рчб (н 4 для 1рч4). На период перехода с 1Рч4 на 1Рчб, который, вероятно, займет около десяти лет, маршрутизаторы по значению этого поля смогут различать пакеты нового и старого стандарта. Подобная проверка потребует нескольких тактов процессора, что может оказаться нежелательным в некоторых ситуациях, поэтому многие реализации, вероятно, попытаются избежать этих накладных расходов и будут отличать пакеты 1Рт4 от пакетов 1Рчб с помощью некоторого поля в заголовке уровня передачи данных.
При этом пакеты будут передаваться напрямую нужному сетевому уровню. Однако знакомство уровня передачи данных с типами пакетов сетевого уровня полностью нарушает принцип разделения протоколов на уровни, при котором каждый уровень не должен знать назначения битов из пакетов более высокого уровня. Дискуссия между лагерями, руководствующимнся принципами «Делай правильно» и «Делай быстро», несомненно, будет долгой и энергичной.
Поле Класс трафиха используется для того, чтобы различать пакеты с разными требованиями к доставке в реальном времени. Такое поле присутствовало в стандарте 1Р с самого начала, однако оно реально обрабатывалось маршрутизаторами лишь в единичных случаях Сейчас проводятся эксперименты, направленные на то, чтобы определить, как лучше всего использовать это поле для передачи данных в реальном времени. Поле Мешка патпока также пока является экспериментальным, но будет применяться для установки между отправителем и получателем псевдосоединения с определенными свойствами и требованиями.
Например, поток пакетов между двумя процессами на разных хостах может обладать строгими требованиями к задержкам, что потребует резервирования пропускной способности. Поток устанавливается заранее и получает идентификатор. Когда прибывает пакет с отличным от нуля содержимым поля Метка потока, все маршрутизаторы смотрят в свои таблицы, чтобы определить, какого рода особая обработка ему требуется.
Сетевой уровень в Интернете 635 Таким образом, новый протокол пытается соединить достоинства подсетей различных типов: гибкость дейтаграмм и гарантии виртуальных каналов. 32 бита Рис. В.бп. Фиксированный заголовок 1Реб (обязательные поля) Каждый поток описывается адресом источника, адресом назначения и номером потока, так что для каждой пары 1Р-адресов можно создать много активных потоков. Два потока с одинаковыми номерами, но различными адресами отправителя или получателя считаются разными потокаии и различаются маршрутизаторами по адресам.
Ожидается, что номера каналов будут выбираться случайным образом, а не назначаться подряд начиная с 1, что облегчит маршрутизаторам их распознавание. Поле Длина полезной нагрузки сообщает, сколько байт следует за 40-байтовым заголовком, показанным на рис. 5.58. В заголовке 1Рч4 аналогичное поле называлось Полная длина и определяло весь размер пакета. В новом протоколе 40 байт заголовка учитываются отдельно. Поле Следующий заголовок раскрывает секрет возможности использования упрощенного заголовка.
Дело в том, что после обычного 40-байтового заголовка могут идти дополнительные (необязательные) расширенные заголовки. Это поле сообшает, какой из шести дополнительных заголовков (на текуший момент) следует за основным. В последнем 1Р-заголовке поле Слвфющий заголовок сообпает, какой обрабатывающей программе протокола транспортного уровня (то есть ТСР или ()РР) передать пакет. Поле Максимальное число транзитных участков не дает пакетам вечно блуждать по сети.
Оно имеет практически то же назначение, что и поле Время жизни в заголовке протокола 1рч4. Это поле уменьшается на единицу на каждом тран- 536 Глава 6. Сетевой уровень зитном участке. Теоретически, в протоколе 1Рч4 это поле должно было содержать секунды времени жизни пакета, однако ни однц маршрутизатор не использовал сго подобным образом, поэтому имя поля было приведено в соответствие способу его применения. Следом идут поля Адрес опп>)>авителя н Адрес получателя. В исходном предложении Диринга (протоколе 51РР) использовались 8-байтовые адреса, но прн рассмотрении проекта было решено, что 8-байтовых адресов хватит лишь на несколько десятилетий, в то время как 16-байтовых адресов должно хватить навечно.
Другие возражали, что 16 байтов для адресов слишком много, тогда как третьи настаивали на 20-байтных адресах для совместимости с дейтаграммным протоколом 081. Еще одна фракция ратовала за алрсса переменной длины. После продолжительных споров было решено, что наилучшим компромиссным решением являются 16-байтовыс адреса фиксированной длины. Для написания 16-байтовых адресов была выработана новая нотация.
Лдреса в 1Рчб записываются в виде восьми групп по четыре шестнадцатеричных цифры, разделенных двоеточиями, например: 8000:0000;0000:0000:0123:4567:89ЛВ;С1)ЕГ Поскольку многие адреса будут содержать большое количество нулей, были разрешены три метода сокращенной записи адресов. Во-первых, могут быть опущены ведущие нули в каждой группе, например, 0123 можно записывать как 123, Во-вторых, одна или более групп, полностью состоящих из нулей, могут заменяться парой лвоеточий. Таким образом, приведенный выше адрес принимает вид 8000з123:4567:89ЛВ;СБЕГ Наконец, адреса 1Рч4 могут записываться как нара двоеточий, после которой пишется адрес в старом десятичном формате, например: з192.31.2046 Возможно, нет необходимости говорить об атом столь подробно, но количество всех возможных 16-байтовых адрссов очень велико — 2"", что приблизительно равно 3 10>".
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
