Э. Таненбаум - Компьютерные сети. (4-е издание) (DJVU) (1130092), страница 145
Текст из файла (страница 145)
Первые два бита этого поля сообщают, что делать с пакетом, маршрутизаторам, не знающим, как обрабатывать данный параметр Возможны четыре следующих варианта: пропустить параметр, игнорировать пакет, игнорировать пакет и отослать обратно 1СМР-пакет, а также то же самое, что и предыдущий вариант, но не отсылать обратно 1СМР-пакет в случае многоадресной рассылки (чтобы один неверный многоадресный пакет не породил миллионы 1СМР-донесений). Поле Длина также имеет размер 1 байт. Оно сообщает, насколько велико значение (от О до 255 байт). Поле Значение содержит необходимую информацию, размером до 255 байт.
Заголовок параметров маршрутизации содержит информацию, которую должны исследовать маршрутизаторы на протяжении всего пути следования пакета. Пока что был определен один вариант использования этого параметра: поддержка дейтаграмм, превышающих 64 Кбайт. Формат заголовка показан на рис. 5.59. Рио. В.эв. дополнительный заголовок для больших дейтаграмм Как и все дополнительные заголовки, он начинается с байта, означающего тип следующего заголовка.
Следующий байт содержит длину дополнительного заголовка в байтах, не считая первых 8 байт, являющихся обязательными. С этого начинаются все расширения. Следующие два байта указывают, что данный параметр содержит размер дейтаграммы (код 194) в виде 4-байтового числа Размеры меньше 65 536 не допускаются, так как могут привести к тому, что первый же маршрутизатор проигнорирует данный пакет и отошлет обратно 1СМР-сообщение об ошибке.
Дейтаграммы, использующие подобные расширения заголовка, называются джамбограммами (от слова фипЬоь, означающего нечто большое и неуклюжее). Использование джамбограмм важно для суперкомпьютерных приложений, которым необходимо эффективно передавать по Интернету гигабайты данных. Маршрутный заголовок содержит информацию об одном или нескольких маршрутизаторах, которые следует посетить по пути к получателю.
Это очень Сетевой уровень в Интернете 539 сильно напоминает свободную маршрутизацию стандарта 1Рч4 тем, что указанные в списке маршрутизаторы должны быть пройдены строго по порядку, тогда как не указанные проходятся между ними. Формат маршрутного заголовка показан на рис. 5.60. Рис. В.60. дополнительный заголовок для маршрутизации Первые четыре байта дополнительного маршрутного заголовка содержат четыре однобайтовых целых числа. Поля Следующий заголовок и Длина дополнительного заголовка были описаны ранее, В поле Тип маршрутизации описывается формат оставшейся части заголовка. Если он равен О, это означает, что далее следует зарезервированное 32-разрядное слово, а за ним — некоторое число адресов 1Рчб.
В будущем, возможно, будут по мере необходимости изобретаться какие-то новые поля. Наконец, в поле Число оставшихся сегментов указывается, сколько адресов из списка еще осталось посетить. Его значение уменьшается при прохождении каждого адреса. Когда оно достигает нуля, пакет оставляется на произвол судьбы — никаких указаний относительно его дальнейшего маршрута не дается. Обычно в этот момент пакет уже находится достаточно близко к месту назначения, и оптимальный маршрут очевиден.
Заголовок фрагментации определяет фрагментацию способом, схожим с протоколом 1Рч4. Заголовок содержит идентификатор дейтаграммы, номер фрагмента и бит, информирующий о том, является ли этот фрагмент последним. В отличие от 1Рч4, в протоколе 1Рчб фрагментировать пакет может только хост-источник. Маршрутизаторы фрагментировать пересылаемые пакеты не могут. Это порывающее с философией прошлого изменение в протоколе упрощает и ускоряет работу маршрутизаторов.
Как уже было сказано, маршрутизатор отвергает слишком большие пакеты, посылая в ответ 1СМР-пакет, указывающий хосту-источнику на необходимость заново передать пакет, выполнив его фрагментацию на меньшие части. Заголовок аутентификации предоставляет механизм подтверждения подлинности отправителя пакета.
Шифрование данных, содержащихся в поле полезной нагрузки, обеспечивает конфиденциальность: прочесть содержимое пакета сможет только тот, для кого предназначен пакет. Для выполнения этой задачи в заголовках используются криптографические методы. Полемика При той открытости, с которой происходил процесс разработки протокола 1Рч6, и при убежденности многочисленных разработчиков в собственной правоте не- 640 Глава 5.
Сетевой уровень удивительно, что многие решения принимались в условиях весьма жарких дискуссий. О некоторых из них будет рассказано далее. Все кровавые подроб|юсти описаны в соответствующих ВЕС. О спорах по поводу длины поля адреса уже упоминалось. В результате было принято компромиссное решение: 16-байтовые адреса фиксированной длины Другое сражение разгорелось из-за размера поля Максимальное количество транзитных участков. Один из противостоящих друг другу лагерей считал, что ограничение количества транзитных участков числом 255 (это явно следует из использования 8-битного поля) является большой ошибкой.
В самом деле, маршруты из 32 транзитных участков уже стали обычными, а через 10 лет могут стать обычными более длинные маршруты. Сторонники этого лагеря заявляли, что использование полей адресов огромного размера было решением дальновидным, а применение крохотных счетчиков транзитных участков — недальновидным. Самый страшный грех, который, по их мнению, могут совершить специалисты по вычислительной технике, — это выделить для чего-нибудь недостаточное количество разрядов. В ответ им было заявлено, что подобные аргументы можно привести для увеличения любого поля, что приведет к разбуханию заголовка.
Кроме того, назначение поля Максимальное количество транзитных участков состоит в том, чтобы не допустить слишком долгого странствования пакетов, и 65 535 транзитных участков — это очень много. К тому же по мере роста Интернета будет создаваться все большее количество междугородных линий, что позволит передавать пакеты из любой страны в любую страну максимум за шесть транзитных пересылок. Если от получателя или отправителя до соответствующего международного шлюза окажется более 125 транзитных участков, то, видимо, что-то не в порядке с магистралями этого государства.
В итоге эту битву выиграли сторонники 8-битового счетчика. Еще одним предметом спора оказался максимальный размер пакета. Обладатели суперкомпьютеров настаивали на размере пакетов, превышающем 64 Кбайт. Когда суперкомпьютер начинает передачу, он занимается серьезным делом и не хочет, чтобы его прерывали через каждые 64 Кбайта.
Аргумент против больших пакетов заключается в том, что если пакет размером в 1 Мбайт будет передаваться по линии Т1 со скоростью 1,5 Мбит/с, то он займет линию на целых 5 секунд, что вызовет слишком большую задержку, заметную для интерактивных пользователей. В данном вопросе удалось достичь компромисса: нормальные пакеты ограничены размером 64 Кбайт, но с помощью дополнительного заголовка можно пересылать дейтаграммы огромного размера. Еще одним спорным вопросом оказалось удаление контрольной суммы 1рч4.
Кое-кто сравнивал этот ход с удалением тормозов из автомобиля. При этом автомобиль становится легче и может двигаться быстрее, но если случится что-нибудь неожиданное, то могут быть проблемы. Аргумент против контрольных сумм состоял в том, что каждое приложение, действительно заботящееся о целостности своих данных, все равно считает контрольную сумму на транспортном уровне, поэтому наличие еще одной на сетевом уровне является излишним (кроме того, контрольная сумма подсчитывается Сетевой уровень в Интернете 541 еШе и на уровне передачи данных). Более того, эксперименты показали, что вычисление контрольной суммы составляло основные затраты протокола 1Рч4. Это сражение было выиграно лагерем противников контрольной суммы, поэтому в протоколе 1Рчб, как мы знаем, контрольной суммы нет.
Вокруг мобильных хостов также разгорелся спор. Если мобильный компьютер окажется на другом конце Земли, сможет ли он продолжать использовать прежний 1рчб-адрес или должен будет использовать схему с внутренним и внешним агентами? Мобильные хосты также вносят асимметрию в систему маршрутизации. Вполне реальна ситуация, когда маленький мобильный компьютер хорошо слышит мощный сигнал большого стационарного маршрутизатора, но стационарный маршрутизатор не слышит слабого сигнала, передаваемого мобильным хостом.
Поэтому появилось много желающих создать в протоколе 1Р«6 явную поддержку мобильных хостов. Эти попытки потерпели поражение, поскольку ни по одному конкретному предложению не удалось достичь консенсуса. Вероятно, самые жаркие баталии разгорелись вокруг вопроса безопасности. Все были согласны, что это необходимо. Спорным было то, где и как следует реализовывать безопасность. Во-первых, где.
Аргументом за размещение системы безопасности на сетевом уровне было то, что при этом она становится стандартной службой, которой могут пользоваться все приложения безо всякого предварительного планирования. Контраргумент заключался в том, что по-настоящему защищенным приложениям подходит лишь сквозное шифрование, когда шифрование осуществляется самим источником, а дешифровка — непосредственным получателем.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
