Доставить дейтаграмму, или если шлюз обнаружил необычные условия

Глава 9
Межсетевой протокол: Ошибки и Управляющие сообщения(ICMP)

9.1 Введение

Мы уже видели, что Межсетевой протокол обеспечивает
ненадежное средство доставки без установления соединения, и что
дейтаграммы путешествуют от шлюза к шлюзу до тех пор, пока они не
достигнут шлюза, который может напрямую доставить их к конечному
месту назначения. Если шлюз не может маршрутизировать или
доставить дейтаграмму, или если шлюз обнаружил необычные условия
при работе, такие как переполнение сети, влияющие на его
способность отправлять дейтаграммы, ему нужно сообщить
первоначальному источнику, что требуется предпринять действия для
решения возникшей проблемы. Эта глава рассматривает механизм,
используемый шлюзами и ГВМ для передачи управляющей информации и
информации об ошибках. Мы увидим, как шлюзы используют этот
механизм, чтобы сообщать о проблемах при доставке, и как ГВМ
используют его для проверки достижимости назначения.

9.2 Межсетевой протокол управляющих сообщений

В системе без установления соединения, которую мы описали,
каждый шлюз работает автономно при маршрутизации или доставке
прибывающих дейтаграмм, не координируя свои действия с исходным
отправителем. Эта система хорошо работает, если все функционируют
корректно и согласовали маршрутизацию, но ведь не существует
систем, корректно работающих все время. Помимо сбоев линий
передачи и процессоров, IP аварийно завершает доставку
дейтаграмм, когда машина назначения временно или постоянно
отключена от сети, когда обнуляется счетчик времени жизни, или
когда промежуточные шлюзы так переполняются, что не могут
обработать приходящий траффик. Важное различие между реальной,
аппаратной сетью и интернетом, основанным на программном
обеспечении, заключается в том, что в первом разработчик часто
может положиться на сетевое оборудование при доведении до машин о
возникновении проблем. В интернете, не имеющем такого аппаратного
механизма, отправитель не может сказать, явился ли причиной
ошибки при доставке сбой на локальной машине или удаленной.
Отладка становится крайне трудной. В самом протоколе IP нет
ничего, что могло бы помочь отправителю проверить связность или
узнать о таких ошибках.
Чтобы дать возможность шлюзам в интернете сообщать об ошибках
или предоставлять информацию о нестандартных условиях работы,
разработчики добавили механизм сообщений специального назначения
в протоколы TCP/IP. Этот механизм, известный как Межсетевой
Протокол Управляющих Сообщений(ICMP), считается необходимой
частью IP и должен включаться в каждую реализацию IP.
Как и весь другой траффик, сообщения ICMP передаются по
интернету в поле данных IP-дейтаграмм. Конечным назначением
сообщений ICMP, тем не менее, является не прикладная программа
или пользователь на машине назначения, а программное обеспечение
IP на этой машине. То есть, когда прибывает сообщение ICMP об
ошибке, его обрабатывает модуль программного обеспечения ICMP.
Конечно, если ICMP определит, что ошибка была вызвана конкретным
протоколом более высокого уровня или прикладной программой, он
сообщит об этом соответствующему модулю. Подведем итоги:

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

Первоначально разработанный для предоставления шлюзам
возможности сообщать о причинах ошибок доставки ГВМ, ICMP не
предназначен только для шлюзов. Хотя руководства ограничивают
использование некоторых сообщений ICMP, любая машина может
послать сообщение ICMP на любую другую машину. Поэтому, ГВМ может
использовать ICMP для связи со шлюзом или другим ГВМ. Главная
выгода от разрешения ГВМ использовать ICMP заключается в том, что
он обеспечивает простой механизм, используемый для всех
управляющих и информационных сообщений.

9.3 Сообщение об ошибке против исправления ошибки

Говоря техническим языком, ICMP - это механизм сообщения об
ошибках. Он обеспечивает для шлюзов, обнаруживающих ошибки,
способ сообщить об ошибке первоначальному источнику. Хотя
спецификация протокола определяет допустимые способы
использования ICMP и предлагает варианты возможных действий в
ответ на ошибки, ICMP не специфицирует полностью действия,
которые нужно предпринять в ответ на все возможные ошибки. Короче
говоря:

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

Большая часть ошибок исходит от первоначального источника, но
другие - нет. Так как ICMP сообщает об ошибках первоначальному
источнику, он не может использоваться, чтобы информировать
промежуточные шлюзы об ошибках. Например, представим, что
дейтаграмма следует по пути через шлюзы G1,G2,...,Gk. Если Gk
содержит некорректную информацию о маршрутах и ошибочно отправит
дейтаграмму на шлюз Gе, то Ge может лишь сообщить об ошибке
первоначальному источнику. К сожалению, источник не отвечает за
эту проблему и не может управлять некорректно ведущим себя
шлюзом. Фактически, источник не сможет даже определить, какой
шлюз вызвал эту проблему.
Зачем ограничивать ICMP взаимодействием с первоначальным
источником ? Ответ должен быть очевиден, если вспомнить
рассмотрение нами форматов дейтаграммы и маршрутизации в
предыдущих главах. Дейтаграмма содержит поля, которые определяют
только первоначального источника и конечного получателя; она не
содержит полного описания своего пути через интернет(кроме
необычных случаев, когда используется опция записи маршрута).
Более того, так как шлюзы могут создавать и менять свои таблицы
маршрутизации, не существует глобального представления о путях.
Поэтому, когда дейтаграмма достигает данного шлюза, нельзя
узнать, какой путь она прошла до этого. Если шлюз обнаруживает
ошибку, он не может узнать какие промежуточные машины
обрабатывали эту дейтаграмму, и поэтому не может сообщить им об
ошибке. Вместо простого удаления дейтаграммы этот шлюз использует
ICMP, чтобы сообщить первоначальному источнику о возникшей
проблеме, надеется на то, что администраторы ГВМ будут
взаимодействовать с администраторами сети, чтобы локализовать и
исправить ошибку.

9.4 Доставка сообщения ICMP

Сообщения ICMP требуют двух уровней инкапсуляции, как
показано на рисунке 9.1. Каждое сообщения ICMP передается по
интернету в поле данных IP-дейтаграммы, которая сама передается
по каждой физической сети в поле данных кадра. Дейтаграммы,
несущие сообщения ICMP маршрутизируются точно так же, как и
дейтаграммы, несущие информацию для пользователей; для них не
используются дополнительные приоритет или надежность. Поэтому,
сами сообщения об ошибках могут быть потеряны или удалены. Более
того, в уже переполненной сети сообщения об ошибках могут вызвать
дополнительное переполнение. Исключение делается для процедур
обработки ошибок, если IP-дейтаграмма, несущая сообщение ICMP,
вызвала ошибку. Это исключение, установленное для того, чтобы
избежать проблемы появления сообщений об ошибках, вызванных в
свою очередь сообщениями об ошибках, определяет, что сообщения
ICMP не генерируются для ошибок, появившихся из-за дейтаграмм,
несущих сообщения об ошибках ICMP.

--------------------------------------
|заголовок | данные ICMP |
| ICMP | |
--------------------------------------
V V
-------------------------------------------------
| заголовок| область данных дейтаграммы |
|дейтаграмм| |
-------------------------------------------------
V V
-----------------------------------------------------------
|заголовок| область данных кадра |
|кадра | |
-----------------------------------------------------------

Рисунок 9.1 Два уровня инкапсуляции ICMP. Сообщение ICMP
инкапсулируется в IP-дейтаграмме, которая в свою очередь
инкапсулируется в кадре для передачи. Для идентификации ICMP поле
протокола дейтаграммы содержит значение 1.

Важно помнить, что несмотря на то, что сообщения ICMP
инкапсулируются и посылаются, используя IP, ICMP не считается
протоколом более высокого уровня - он является необходимой частью
IP. Причина использования IP для транспортировки сообщений ICMP
заключается в том, что им понадобиться пересечь несколько
физических сетей для того, чтобы достичь своего конечного
назначения. Поэтому, они не могут быть доставлены только с
помощью физической передачи.

9.5 Формат сообщения ICMP

Хотя каждое сообщение ICMP имеет свой собственный формат, все
они начинаются с трех одинаковых полей: 8-битового целочисленного
поля ТИП, которое идентифицирует сообщение, 8-битового поля КОД,
которое обеспечивает более точную информацию о типе сообщения, и
16-битового поля КОНТРОЛЬНАЯ_СУММА(ICMP использует тот же самый
аддитивный алгоритм, что и IP, но контрольная сумма ICMP
учитывает только сообщение ICMP). Помимо того, сообщения ICMP,
сообщающие об ошибках, всегда включают заголовок и первые 64 бита
данных дейтаграммы, вызвавшей ошибку.
Причиной возвращения не только заголовка дейтаграммы,
вызвавшей ошибку, является желание позволить получателю более
точно определять, какие протоколы и какие прикладные программы
ответственны за появление этой дейтаграммы. Как мы увидим позже,
протоколы более высокого уровня в связке TCP/IP разрабатывались
таким образом, что критическая информация закодирована в первых
64 битах.
Поле ТИП ICMP определяет смысл сообщения, а также его
формат. Эти типы включают:

Поле ТИП Тип сообщения ICMP

0 Ответ на эхо
3 Назначение недостижимо
4 Подавление источника
5 Переназначение(изменение маршрута)
8 Запрос эха
11 Превышено время для дейтаграммы
12 Ошибка параметра в дейтаграмме
13 Запрос временной отметки
14 Ответ для временной метки
15 Запрос информации(не действует)
16 Ответ на запрос информации(не действует)
17 Запрос маски адреса
18 Ответ на запрос маски адреса

Следующие секции описывают каждое из этих сообщений, приводя
при этом детальное описание формата сообщения и их смысл.

9.6 Тестирование достижимости назначения и его состояния

Протоколы TCP/IP обеспечивают средства, помогающие сетевым
администраторам или пользователям идентифицировать проблемы в
сети. Одно из самых наиболее используемых средств отладки
вызывает сообщения ICMP запрос эха и ответ эха. ГВМ или шлюз
посылает сообщение запроса эха указанному месту назначения. Любая
машина, получившая запрос эха, генерирует ответ на эхо и
возвращает его первоначальному отправителю. Этот запрос содержит
необязательную область данных; ответ содержит копию данных,
посланных в запросе. Запрос эха и связанный с ним ответ могут
использоваться для проверки достижимости назначения и его
способности отвечать на запросы. Так как и запрос эха, и ответ на
него передаются в IP-дейтаграммах, успешный прием ответа
свидетельствует о работоспособности основных частей транспортной
системы. Во-первых, программное обеспечение IP на машине
источника произвело маршрутизацию дейтаграммы. Во-вторых,
промежуточные шлюзы между источником и получателем работоспособны
и корректно маршрутизируют дейтаграммы. В-третьих, машина
получателя работает (по крайней мере, она обрабатывает
прерывания) и программное обеспечение как IP, так и ICMP
выполняет свои функции. И наконец, таблицы маршрутов в шлюзах на
всем обратном пути корректны.
Во многих системах команда, которую пользователи вызывают
для посылки запроса эха ICMP, называется ping. Усложненные версии
этой программы посылают серии запросов эха ICMP, принимают ответы
и выдают статистику о потерях дейтаграмм. Они позволяют
пользователю указывать длину посылаемых данных и интервалы
времени между запросами. Менее сложные версии просто посылают
запрос эха ICMP и ждут ответа.

9.7 Формат сообщения запроса эха и ответа эха

Рисунок 9.2 содержит формат сообщений запроса эха и ответа на
запрос эха.

0 8 16
------------------------------------------------------------
|тип(8 или 0)| код(0) | Контрольная сумма |
------------------------------------------------------------
| идентификатор | последовательный номер |
------------------------------------------------------------
| необязательные данные |
------------------------------------------------------------
| ...... |
------------------------------------------------------------

Рисунок 9.2 Формат сообщения запроса эха и ответа на него

Поле, названное НЕОБЯЗАТЕЛЬНЫЕ ДАННЫЕ имеет переменную длину
и содержит данные, которые надо вернуть отправителю. Ответ на эхо
всегда возвращает те же самые данные, что были получены им в
запросе. Поля ИДЕНТИФИКАТОР и ПОСЛЕДОВАТЕЛЬНЫЙ НОМЕР используются
отправителем для проверки соответствия ответов запросам. Значение
поля ТИП определяет, является ли сообщение запросом(8) или
ответом(0).

9.8 Сообщения о недостижимости назначения

Когда шлюз не может доставить IP-дейтаграмму, он посылает
сообщение "назначение недостижимо" обратно первоначальному
отправителю, используя формат, приведенный на рисунке 9.3.

0 8 16
------------------------------------------------------------
|тип(3) | код(0-5) | Контрольная сумма |
------------------------------------------------------------
| не используется(должно быть равно нулю) |
------------------------------------------------------------
| межсетевой заголовок плюс первые 64 бита дейтаграммы |
------------------------------------------------------------
| ...... |
------------------------------------------------------------

Рисунок 9.3 Формат сообщения о недостижимости назначения

Поле КОД в сообщении о недостижимости назначения содержит
целое число, которое описывает причину. Возможны следующие
значения:

Значение Смысл

0 Сеть недостижима
1 ГВМ недостижим
2 Протокол недостижим
3 Порт недостижим
4 Требуется фрагментация
5 Ошибка при маршрутизации источника
6 Сеть назначения неизвестна
7 ГВМ назначения неизвестен
8 ГВМ источника изолирован
9 Взаимодействие с сетью назначения
административно запрещено
10 Взаимодействие с ГВМ назначения
административно запрещено
11 Сеть недостижима из класса обслуживания
12 ГВМ недостижим из-за класса обслуживания

Хотя IP является механизмом ненадежной доставки, дейтаграммы
не уничтожаются просто так. Всякий раз, когда ошибка мешает шлюзу
произвести маршрутизацию или доставку дейтаграммы, шлюз посылает
сообщение о недостижимости назначения обратно его источнику, а
затем уничтожает дейтаграмму. Ошибки недостижимости сети обычно
являются следствием ошибок маршрутизации; ошибки недостижимости
ГВМ - следствие ошибок при доставке(исключением является случай,
когда шлюзы используют схему адресации подсетей, описанную в
главе 16. Они сообщают об ошибке при маршрутизации к подсети с
помощью сообщения ICMP о недостижимости ГВМ). Так как сообщение
содержит короткий префикс дейтаграммы, вызвавшей ошибку, то
источник будет точно знать, какой адрес недостижим.
Назначения могут быть недостижимыми из-за того, что
оборудование было временно неработоспособно, из-за того, что
отправитель указал несуществующий адрес назначения, или ( в
редких случаях) из-за того, что у шлюза не указано маршрута к
сети назначения. Отметим, что хотя шлюзы сообщают об ошибках,
которые они обнаружили, они могут не знать обо всех ошибках
доставки. Например, если машина получателя присоединена к сети
Ethernet, то сетевое оборудование не предоставляет подтверждения
получения дейтаграммы. Поэтому, шлюз может продолжать посылать
пакеты назначению даже после того, как оно отключено, не получая
при этом никакой информации о том, что пакеты не доставляются.
Подведем итоги:

Хотя шлюзы посылают сообщения о недостижимости назначения,
если они не могут произвести маршрутизацию или доставку
дейтаграммы, не все подобные ошибки обнаруживаются.

Смысл сообщений о недостижимости порта и протокола станет
ясен, когда мы изучим, как протоколы более высокого уровня
используют абстракцию точки получения, называемую портом. Смысл
большей части остальных сообщений понятен уже из их названия.
Если дейтаграмма содержит опцию маршрутизации источника с
некорректным маршрутом, то это может привести к появлению
сообщения об ошибке маршрутизации источника. Если шлюзу нужно
фрагментировать дейтаграмму, но установлен бит "не
фрагментировать", то шлюз посылает сообщение "требуется
фрагментация" обратно источнику.

9.9 Управление потоком дейтаграмм и переполнение сети

Так как IP является протоколом без установления соединения,
то шлюзы не могут резервировать память или коммуникационные
ресурсы до получения дейтаграмм. В результате, траффик может
вызвать перегрузку шлюзов, ситуацию, называемую переполнением
сети(congestion). Важно понимать, что переполнение сети может
возникать из-за двух совершенно разных причин. Во-первых,
высокоскоростной компьютер может генерировать траффик быстрее,
чем сеть может передавать его. Например, представим
суперкомпьютер, генерирующий межсетевой траффик. Дейтаграммам,
посылаемым им, может потребоваться передача в конечном счете по
медленной глобальной сети(WAN), хотя сам суперкомпьютер может
быть присоединен к высокоскоростной локальной сети. Переполнение
будет возникать в шлюзе, присоединенном к глобальной сети, так
как дейтаграммы будут прибывать быстрее, чем их можно послать.
Во-вторых, если большому числу компьютеров одновременно нужно
посылать дейтаграммы через один шлюз, этот шлюз может оказаться
переполненным, хотя ни один источник в отдельности и не вызывает
эту проблему.
Когда дейтаграммы прибывают на шлюз или ГВМ быстрее, чем он
успевает их обрабатывать, он временно ставит их в очередь в своей
памяти. Если эти дейтаграммы - это часть небольшого пика при
передаче дейтаграмм, то такая буферизация решает проблему. Если
же траффик продолжает поступать, то то в конечном счете ГВМ или
шлюз займет всю память под очередь и вынужден будет удалять новые
прибывающие дейтаграммы. Тогда машина использует сообщения о
подавлении источника для выхода из состояния переполнения.
Сообщение о подавлении источника требует от источника уменьшить
скорость передачи дейтаграмм. Обычно переполненные шлюзы посылают
по одному сообщению о подавлении источника на каждую удаляемую
дейтаграмму. Шлюзы могут также использовать более сложные
технологии выхода из переполнения. Некоторые наблюдают за
приходящим траффиком и подавляют источники с наивысшими
скоростями передачи. Другие пытаются избежать переполнения в
принципе, выдавая запросы подавления источника в том случае,
когда их очереди начинают становиться слишком длинными, но до
того, как они переполнятся.
Не существует сообщения ICMP, вызывающего эффект, обратный
подавлению источника. Вместо этого ГВМ, принявший сообщения о
подавлении источника от некоторой машины, М, снижает скорость, с
которой он посылает дейтаграммы на М до тех пор, пока к нему не
перестанут приходить сообщения о подавлении источника; затем он
постепенно увеличивает скорость до тех пор, пока он снова не
получит сообщения о подавлении источника.

9.10 Формат подавления источника

Помимо обычных полей ICMP ТИП, КОД и КОНТРОЛЬНАЯ СУММА, и
неиспользуемого 32-битового поля, сообщения о подавлении
источника имеют поле, содержащее префикс дейтаграммы. Рисунок 9.4
иллюстрирует этот формат. Как и в других сообщениях об ошибках
ICMP поле префикса дейтаграммы содержит префикс дейтаграммы,
вызвавшей этот запрос подавления источника.

0 8 16 31
------------------------------------------------------------
|тип(4) | код(0) | Контрольная сумма |
------------------------------------------------------------
| не используется(должно быть равно нулю) |
------------------------------------------------------------
| межсетевой заголовок плюс первые 64 бита дейтаграммы |
------------------------------------------------------------
| ...... |
------------------------------------------------------------

Рисунок 9.4 Формат сообщения о подавлении источника ICMP.
Переполненные шлюзы посылают одно сообщение о подавлении
источника каждый раз, когда они удаляют дейтаграмму; префикс
дейтаграммы идентифицирует удаленную дейтаграмму.

9.11 Запросы изменения маршрута от шлюзов

Таблицы маршрутизации Интернета обычно не меняются в течение
длинного промежутка времени. ГВМ инициализируют их с помощью
файла конфигурации при загрузке системы, а сетевые администраторы
лишь изредка вно

 

Д. Комер "Межсетевой обмен с помощью TCP/IP"
Том 1. Принципы, протоколы и архитектура

Эта книга является одним из классических академических куpсов по техническим пpинципам pаботы Интеpнета. В доступной фоpме здесь описываются основы всех пpотоколов, фоpматы их сообщений и логика их pаботы. Понимание pяда пpоблем сетевой безопасности невозможно без знания изложенных в ней сведений.

 

Вступление

Чтобы понимать сетевой обмен и круг вопросов, рассматриваемых в книге, важно представлять, что сетевые исследования и разработки прошли через три… Многие книги и курсы по сетям основную часть материала посвящают первым двум… Эта книга посвящена третьей стадии сетевых исследований. Она рассматривает архитектуру взаимосвязанных сетей и…

Глава 1. Введение и обзор.

1.1 Необходимость Интернета.

Передача данных стала фундаментальной частью вычислений. Сети, разбросанные по всему миру, собирают данные о таких разных предметах, как атмосферные условия, производство продуктов и воздушных перевозках. Группы создают электронные справочные списки, которые позволяют им получать информацию, интересную всем. Любители обмениваются программами для их домашних компьютеров. В научном мире сети данных стали необходимы, так как они позволяют ученым посылать программы и данные на удаленные суперкомпьютеры для обработки, получать результаты и обмениваться научной информацией с коллегами.

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

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

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

Чтобы оценить значение межсетевой технологии, подумайте, как она повлияла на исследования. Представьте на минуту эффект взаимного соединения всех компьютеров, используемых учеными. Любой ученый может обменяться результатами эксперимента с любым другим ученым. Можно создать национальные центры данных, собирающие данные о природных явлениях и делающие их доступными для всех ученых. Компьютерные средства и программы, доступные в одном месте, могут использоваться учеными в других местах. В результате скорость, с которой осуществляются научные исследования, может резко возрасти. Короче говоря, изменения могут быть очень драматичными.

1.2 Интернет TCP/IP

Правительственные агентства осознали важность и потенциал межсетевой технологии в будущем и стали финансировать исследования, которые сделали бы возможным создание национальнойобьединенной сети. Эта книга рассматривает принципы и идеи,лежащие в основе ведущей межсетевой технологии, появившейся в результате проведения разработок, финансировавшихся агентством DARPA(Defense Advanced Research Projects Agency). Технология DARPA включает набор сетевых стандартов, описывающих детально процесс взаимодействия компьютеров, а также ряд соглашений при взаимодействии сетей и маршрутизации траффика. Официально называемый Связкой Межсетевых Протоколов TCP/IP (а в обыденной речи - TCP/IP по именам двух основных стандартов), он может использоваться для взаимодействия компьютеров с помощью неограниченного числа сетей. Например, некоторые корпорации используют TCP/IP для связи сетей внутри их корпорации, даже если корпорация не имеет связи с внешними сетями. Другие группы используют TCP/IP для связи удаленных друг от друга мест.

Хотя технология TCP/IP интересна сама по себе, она особенно хороша из-за своей жизнеспособности, которую она продемонстрировала. Она стала базовой технологией для большого сообщества сетей, которые связывают большинство исследовательских институтов, включая университетские, обьединенные или правительственные лаборатории. Национальный Научный Фонд(NSF), Министерство Энергетики(DOE), Министерство Обороны(DOD), Агентство по здравоохранению(HHS) и NASA взаимодействуют друг с другом, используя TCP/IP для соединения большого числа их исследовательских центров с центрами DARPA. Получившаяся сущность, известная как обьединенный Интернет, Интернет DARPA/NSF, Интернет TCP/IP, или просто Интернет, позволяет исследователям всех связанных институтов разделять информацию с коллегами по всей стране так же легко, как если бы они были в соседней комнате. Таким образом, Интернет продемонстрировал жизнеспособность технологии TCP/IP и показал, как можно обьединить большое количество разнообразных базовых сетевых технологий.

Большинство материалов в этой книге применимо к любому интернету, использующему TCP/IP, но некоторые главы посвящены специально обьединенному Интернету. Читатели, интересующиеся только технологией, должны четко различать реальную существующую архитектуру Интернета и гипотетический Интернет TCP/IP, который мог бы существовать. Тем не менее, будет ошибкой игнорировать секции, описывающие обьединенный Интернет полностью - сети многих корпораций уже догнали по сложности Интернет десятилетней давности, и многие проблемы, с которыми они сталкиваются сейчас, уже давно решены в обьединенном Интернете.

1.3. Средства Интернета

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

Большая часть описания средств будет посвящена стандартам, называемым протоколами. Протоколы, такие как TCP и IP, дают формулы для передачи сообщений, описывают детали форматов сообщений и указывают, как обрабатывать ошибки. Самое важное то, что они позволяют нам рассматривать стандарты взаимодействия вне зависимости от того, на оборудовании какого производителя, они реализуются. По существу, протоколы являются для коммуникации тем, чем является языки программирования для вычислений. Язык программирования позволяет описать или понять вычисления, не зная системы команд конкретного ЦП. Аналогично, коммуникационный протокол позволяет нам описать или понять процесс передачи данных, не зная на каком оборудовании этот процесс выполняется.

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

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

1.3.1 Средства Интернета прикладного уровня.

С точки зрения пользователя, Интернет TCP/IP является набором прикладных программ, использующих сеть для выполнения полезных коммуникационных задач. Мы будем использовать термин взаимная работоспособность(interoperability) для описания способности различных вычислительных систем взаимодействовать при решении вычислительных задач. Мы утверждаем, что прикладные программы Интернета показывают высокую степень взаимной работоспособности. Большинство пользователей, которые пользуются Интернетом, делают это, просто запуская прикладные программы , не понимая при этом технологии TCP/IP, структуры Интернета, и даже не зная пути, который проходят данные до назначения; они полагаются на то, что прикладные программы сами разберутся с этими деталями. Только программисты, пишущие такие прикладные программы, смотрят на Интернет как на сеть и понимают детали этой технологии.

Самые популярные и широко распространенные прикладные средства Интернета включают:

ЭЛЕКТРОННУЮ ПОЧТУ. Электронная почта позволяет пользователю создать письмо и послать его человеку или группе людей. Другая часть этого приложения позволяет пользователю читать письма, которые он получил. Электронная почта была так успешна, что многие пользователи Интернета используют ее для обычной коммерческой переписки. Хотя существует много систем электронной почты, важно понимать, что использование TCP/IP делает доставку письма более надежной. Вместо того, чтобы полагаться на промежуточные машины при передаче письма, система предоставления письма в TCP/IP работает, напрямую соединяя машину отправителя с машиной получателя. Поэтому отправитель знает, что как только письмо покинуло его машину, оно успешно достигло места назначения.
ПЕРЕДАЧУ ФАЙЛОВ. Хотя пользователи иногда и передают файлы, используя электронную почту, письмо предназначено для коротких, текстовых файлов. Протоколы TCP/IP включают прикладную программу передачи файлов, которая позволяет пользователям передавать или принимать довольно большие файлы программ или данных. Например, используя программу передачи файлов, можно скопировать с одной машины на другую большие обьемы данных, содержащие изображения со спутника, программы, написанные на Фортране или Паскале, или английский словарь. Эта система обеспечивает способ проверки личности пользователя или даже запрещение доступа. Как и письмо, передача файлов по Интернету TCP/IP надежна, так как две взаимодействующие машины делают это напрямую, не полагаясь на промежуточные машины для создания копий файла.
УДАЛЕННЫЙ ДОСТУП. Являясь самым интересным приложением
Интернета, удаленный доступ позволяет пользователю, находящемуся на одном компьютере, взаимодействовать с удаленной машиной и выполнять на ней интерактивный сеанс работы. Удаленный доступ позволяет создать впечатление, что терминал пользователя или его рабочая станция присоединены напрямую к удаленной машине, посылая каждый символ, нажатый на клавиатуре пользователя на удаленную машину и отображая каждый символ, возвращенный с удаленной машины, на экране терминала пользователя. Когда сеанс с удаленной машиной завершается, приложение возвращает пользователя в локальную систему.

Мы вернемся к каждому из этих приложений позднее, чтобы рассмотреть его более детально. Мы увидим, как они используют базовые протоколы TCP/IP и почему наличие стандартов прикладных протоколов помогло удостовериться, что они широко распространены.

1.3.2 Средства Интернета сетевого уровня.

Программист, который пишет прикладные программы, использующие протоколы TCP/IP, имеет совершенно другое представление об Интернете, чем пользователь, который просто запускает прикладные программы, такие как электронная почта. На сетевом уровне Интернет предоставляет два основных типа сервиса, который используют прикладные программы. И хотя на данном этапе несущественно понимание деталей этих средств, их нельзя опустить при любом обзоре TCP/IP:

ДЕЙТАГРАММНОЕ СРЕДСТВО ДОСТАВКИ ПАКЕТОВ. Это средство, которое будет впоследствии детально обьяснено, образует основу всех других средств Интернета. Доставка без соединения (дейтаграмная доставка) является абстракцией сервиса, который предоставляет большинство сетей с коммутацией пакетов. Это просто означает, что Интернет TCP/IP определяет маршрут передачи небольшого сообщения от одной машины к другой, основываясь только на адресной информации, находящейся в сообщении. Так как дейтаграмное средство маршрутизирует каждый пакет отдельно, оно не гарантирует надежной доставки пакетов в том порядке, в котором они были посланы. Так как это средство обычно напрямую отображается на лежащее в его основе оборудование, средство без соединения очень эффективно. Более того, использование доставки пакетов без соединения в качестве основы всех средств Интернета делает протоколы TCP/IP адаптируемыми к широкому диапазону сетевого оборудования.
НАДЕЖНОЕ ПОТОКОВОЕ ТРАНСПОРТНОЕ СРЕДСТВО. Большинству приложений требуется нечто большее, чем простая доставка пакетов, так как они требуют от коммуникационного программного обеспечения автоматического восстановления при ошибках передачи, потере пакетов или сбоях промежуточных маршрутизаторов на пути между отправителем до получателем. Надежное транспортное средство обрабатывает эти ситуации. Оно позволяет приложению на одном компьютере устанавливать "соединение" с приложением на другом компьютере, а затем посылать большие обьемы данных по соединению, как если бы это было прямое аппаратное соединение. На самом деле, конечно, протоколы взаимодействия делят поток данных на маленькие сообщения и посылают их затем по одному, ожидая от получателя подтверждения приема.
Много сетей обеспечивает базовые средства, аналогичные описанным выше, поэтому кое-кто может удивиться:"Чем же отличаются средства TCP/IP от других?". Основными отличиями являются:

НЕЗАВИСИМОСТЬ ОТ СЕТЕВОЙ ТЕХНОЛОГИИ. Хотя TCP/IP и основывается на удобной пакетной технологии, он независим от оборудования конкретного производителя. Обьединенный Интернет включает большое число сетевых технологий от сетей, предназначенных для работы в одном здании, до сетей, работающих на больших расстояниях. Протоколы TCP/IP определяют элемент передачи данных, называемый дейтаграммой, и описывают, как передавать дейтаграммы по конкретной сети.
ВСЕОБЩАЯ СВЯЗНОСТЬ. Интернет TCP/IP позволяет любой паре компьютеров, присоединенных к нему, взаимодействовать друг с другом. Каждому компьютеру назначается адрес, который известен по всему Интернету. Каждая дейтаграмма содержит адреса отправителя и получателя. Промежуточные маршрутизаторы используют адрес получателя для того, чтобы принимать решение о дальнейшем маршруте дейтаграммы.
МЕЖКОНЦЕВЫЕ ПОДТВЕРЖДЕНИЯ. Протоколы TCP/IP Интернета обеспечивают подтверждения между отправителем и получателем, а не между отправителем и промежуточными машинами на пути, даже когда две машины не связаны общей физической сетью.
СТАНДАРТНЫЕ ПРИКЛАДНЫЕ ПРОТОКОЛЫ. Помимо базовых средств транспортного уровня(таких, как надежные потоковые соединения), протоколы TCP/IP включают стандарты для наиболее часто используемых приложений, таких как электронная почта, передача файлов и удаленный доступ. Поэтому при разработке прикладных программ, использующих TCP/IP, программисты часто могут обнаружить, что существующее программное обеспечение уже обеспечивает коммуникационные средства, которые им нужны.
Следующие главы рассмотрят в деталях средства, которые предлагаются программисту, а также большинство стандартов прикладных протоколов.

1.4. История создания Интернета

Частью того, что делает Интернет столь замечательным, является почти повсеместное его использование, а также его размеры и темпы роста обьединенного Интернета. DARPA начала работы в направлении разработки межсетевой технологии в середине 70-х, но архитектура и протоколы приняли форму, в которой они известны сейчас, лишь в 1977-1979 годах. В это время DARPA была известна как основное агентство, финансирующее исследования в области сетей с коммутацией пакетов, и внедрила множество новшеств в этой области в хорошо известную ARPANET. ARPANET использовала обычные выделенные линии точка-точка для соединения компьютеров, но DARPA также финансировала использование коммутации пакетов в радиосетях и спутниковых линиях связи. По существу растущее разнообразие аппаратных сетевых технологий вынудило DARPA изучить межсетевое взаимодействие и продвинуться по направлению к обьединенной сети.

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

Обьединенный Интернет начал существовать с 1980 года, когда DARPA начала устанавливать на машинах, присоединенных к ее исследовательской сети, новый протоколы TCP/IP. ARPANET вскоре после создания стал магистральной сетью нового Интернета и был использован для большинства из ранних экспериментов с TCP/IP. Переход к технологии Интернета был завершен в январе 1983 года, когда секретариат МО США установил, что все компьютеры, присоединенные к глобальным сетям, используют TCP/IP. В это же самое время Оборонное Коммуникационное Агентство(DCA) разделило ARPANET на две отдельные сети, одна для дальнейших исследований и одна для военной связи. За исследовательской сетью осталось имя ARPANET, а военная часть, которая была несколько больше, получила название MILNET.

Для того чтобы заставить исследователей в университетах использовать новые протоколы, DARPA стала продавать их реализацию по низкой цене. В это время большинство университетских факультетов компьютерных наук использовали версию операционной системы UNIX, разработанную в программном отделении Берклиевского Университета в Калифорнии, чаще называемую Berkeley UNIX или BSD UNIX. Финансировав создание фирмой Bolt Beranek and NewMan, Inc. (BBN) реализации протоколов TCP/IP для UNIX и финансировав интеграцию этих протоколов в программные продукты, производимые отделением в Berkeley, DARPA смогла организовать взаимодействие с 90% всех компьютерных факультетов университетов. Новое программное обеспечение с протоколами появилось вовремя, так как многие факультеты сразу же приобретали еще компьютеры и соединяли их как локальные сети. Факультетам требовались протоколы взаимодействия, а других протоколов в то время не было в общем пользовании.

Берклиевское программное отделение стало популярным, так как оно предлагало не только базовые протоколы TCP/IP. Помимо стандартных прикладных программ TCP/IP, Беркли предлагало набор утилит для работы с сетью, которые напоминали средства UNIX, используемые на одной машине. Главное преимущество утилит Беркли заключалось в их сходстве со стандартным UNIXом. Например, опытный пользователь UNIX может быстро научиться пользоваться утилитой копирования удаленных файлов Беркли(rcp), так как он ведет себя точно так, как утилита копирования файлов в UNIX, за исключением того, что она позволяет пользователям копировать файлы на удаленную машину или с нее.

Помимо набора служебных программ UNIX Беркли обеспечивает новую абстракцию операционной системы известную как порт(socket), которая позволяет прикладным программам получать доступ к коммуникационным протоколам. Являясь обобщением механизма UNIX для ввода-вывода, порт имеет опции для нескольких типов сетевых протоколов помимо TCP/IP. Ее принципы стали обсуждаться со времени ее разработки, и многие разработчики операционных систем предложили альтернативные варианты. Независимо от своих достоинств, введение абстракции порта было важным, так как позволяло программистам использовать протоколы TCP/IP с минимумом затрат. Поэтому, это стимулировало разработчиков экспериментировать с TCP/IP.

Успех технологии TCP/IP и Интернета в университетской среде вынудил другие группы тоже использовать его. Учитывая, что сетевое взаимодействие вскоре станет важной частью научных исследований, NSF принял активное участие в расширении Интернета TCP/IP среди ученых. Начиная с 1985 года, он начал претворять в жизнь программу создания сетей на основе его шести суперкомпьютерных центров. В 1986 он расширил деятельность в этом направлении, начав финансировать новую глобальную магистральную сеть, названную NSFNET, которая впоследствии связала все суперкомпьютерные центры между собой и ARPANET. Наконец, в 1986 NSF начал частично финансировать многие региональные сети, каждая из которых сейчас соединяет основные научно-исследовательские центры в этом районе. Все сети, финансировавшиеся NSF, используют протоколы TCP/IP, и все являются частью обьединенного Интернета.

За семь лет после своего создания Интернет обьединил сотни индивидуальных сетей, размещенных в США и Европе. Он соединил почти 20000 компьютеров в университетах, правительственных и частных исследовательских лабораториях. Как размер, так и использование Интернета продолжают расти быстрее, чем предполагалось. К концу 1987 года было установлено, что его рост достиг 15% в месяц и оставался таким последние два года. В 1990 году обьединенный Интернет включал более 3000 активных сетей и более чем 200000 компьютеров.

Использование протоколов TCP/IP и рост Интернета не ограничивались проектами, финансирующимися правительством. Основные компьютерные корпорации присоединилось к Интернету, так же как и множество других больших корпораций, включая: нефтяные компании, автомобильные концерны, электронные фирмы и телефонные компании. Вдобавок, многие компании используют протоколы TCP/IP в своих внутренних сетях, даже если они и не присоединены к обьединенному Интернету.

Быстрое расширение привело к проблемам диапазонов, непредусмотренным в исходном проекте, и заставило разработчиков найти технологии для управления большими, распределенными ресурсами. В исходном проекте, например, имена и адреса всех компьютеров, присоединенных к Интернету, хранились в одном файле, который редактировался вручную и затем распространялся по всему Интернету. Но в середине 1980 года стало ясно, что центральная база данных неэффективна. Во-первых, запросы на обновление файла скоро должны были превысить возможности людей, обрабатывавших их. Во-вторых, даже если существовал корректный центральный файл, не хватало пропускной способности сети, чтобы позволить либо частое распределение его по всем местам, либо оперативный доступ к нему из каждого места.

Были разработаны новые протоколы и стала использоваться система имен по всему обьединенному Интернету, которая позволяла любому пользователю автоматически определять адрес удаленной машины по ее имени. Известный как Доменная Система Имен, этот механизм основывается на машинах, называемых серверами имен, отвечающих на запросы об именах. Нет одной машины, содержащей всю базу данных об именах. Вместо этого, данные распределены по нескольким машинам, которые используют протоколы TCP/IP для связи между собой при ответе на запросы.

1.5. Группа Активности Интернета(IAB).

Так как связка протоколов TCP/IP не была разработана каким-либо производителем или известным профессиональным обществом, естественно задать вопрос:"кто определяет направления развития и решает, когда протоколы становятся стандартами?". Ответом является группа, известная как Группа Активности Интернета(IAB). IAB определяет главное направление разработок на основе протоколов TCP/IP , координирует большинство их и управляет эволюцией обьединенного Интернета. Она решает, какие протоколы являются требуемой частью связки TCP/IP и определяет официальную политику.

Образованная в 1983 году, когда DARPA реорганизовало ICCB, IAB унаследовала много от своих предшественников. Ее начальными целями было стимулировать обмен идеями между людьми, вовлеченными в исследования, связанные с TCP/IP и Интернетом, и держать исследователей в курсе общих целей. После первых шести лет существования IAB из исследовательской группы DARPA превратился в независимую организацию. За эти годы каждый член IAB побывал председателем Целевых Сил Интернета(ITF), отвечая за исследование проблемы или ряда вопросов, представляющих интерес. IAB состояло из приблизительно десяти целевых сил с задачами от исследования, как траффик различных приложений влияет на Интернет, до текущих инженерных проблем Интернета. IAB собиралась несколько раз в год для заслушивания отчетов всех целевых сил, краткого обзора и пересмотра технических направлений, обсуждения политики и обмена информацией с представителями других агентств, таких как DARPA и NSF, которые финансировали работу Интернета и исследования для него.

Председатель IAB имел звание Архитектор Интернета и отвечал за предложение направлений технического развития и координацию работы различных целевых сил. Председатель IAB создавал новые целевые силы по совету IAB и также представлял IAB перед другими организациями.

Новички в TCP/IP иногда удивляются, узнав, что IAB не имел большого бюджета; хотя он и определял направления, он не финансировал большую часть исследований и инженерных разработок. Вместо этого, добровольцы сами выполняли большую часть работы. Члены IAB отвечали за прием добровольцев для работы их в подчиненных им целевых силах, за созыв встреч целевых сил, и за отчеты о работе перед IAB. Обычно, добровольцы появлялись из исследовательского сообщества или коммерческих организаций, использовавших TCP/IP. Активные исследователи принимали участие в целевых силах Интернета по двум причинам. Во-первых, работа в целевых силах обеспечивала возможность узнать новое об исследовательских проблемах. Во-вторых, так как новые идеи и решения проблем выдвигаемые и проверяемые целевыми силами, часто становились частью технологии Интернета, члены понимали, что их работа напрямую влияет на эту область.

1.6. Новая организация IAB

Начиная с лета 1989 года, как технология TCP/IP, так и обьединенный Интернет из исследовательского проекта выросли в средства производства, которыми пользовались тысячи людей в своих каждодневных делах. Больше нельзя было реализовать новые идеи, установив ночью новое программное обеспечение на нескольких машинах. Теперь уже сотни коммерческих компаний, распространявших продукты TCP/IP, определяли, будут ли их продукты взаимно работоспособны, решая вопрос о внесении изменений в их программы.

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

Поэтому IAB был реорганизован летом 1989 года для приведения в соответствие с новой политической и коммерческой реальностью TCP/IP и обьединенного Интернета. Председательство изменилось. Исследователи были переведены из IAB во вспомогательную группу, и был создан новый IAB, для того чтобы включать представителей более широкого сообщества.

Помимо самой IAB организация включает две основные группы: Исследовательские Целевые силы Интернета(IRTF) и Инженерные Целевые Силы Интернета(IETF).

Как это следует из ее имени, IETF концентрируется на оперативных и тактических инженерных проблемах. IETF существовала и в старой структуре IAB, и ее успех явился одной из причин реорганизации. В отличие от большинства целевых сил IAB, которые были ограничены несколькими людьми, концентрировавшимися на одной конкретной проблеме, IETF разросся и стал включать сотни активных членов, работавших над многими проблемами параллельно. До реорганизации IETF был разделен на 20 рабочих групп, каждая из которых работала над конкретной проблемой. Рабочие группы собирались на свои встречи для выработки решений проблем. Кроме того, весь IETF собирался регулярно, чтобы заслушивать отчеты рабочих групп и обсуждать предлагаемые изменения или добавления к технологии TCP/IP. Проводимые обычно три раза в год, встречи всей IETF собирали сотни участников и зрителей. IETF стал слишком большим, чтобы им управлял один председатель.

IETF сохранился в реорганизованной структуре IAB, но был разделен на восемь областей, каждая из которых имела своего собственного управляющего. Председатель IETF и восемь управляющих областями составляют Руководящую Инженерную Группу Интернета (IESG), члены которой ответственны за координацию всех проектов рабочих групп IETF.

Так как IETF был широко известен по всему Интернету, и так как его встречи получили широкое одобрение, имя IETF было сохранено при реорганизации и все еще обозначает эту группу целиком, включая председателя, управляющих областями, и всех членов рабочих групп. По аналогичным причинам было оставлено имя "рабочая группа IETF".

Созданные при реорганизации, Исследовательские Целевые Силы Интернета получили такое имя как исследовательское дополнение к IETF. IRTF координирует работы исследователей, связанные с протоколами TCP/IP и архитектурой Интернета в целом. Как и IETF, IRTF имеет небольшую группу, называемую Руководящей Исследовательской Группой Интернета или IRSG, которая устанавливает приоритеты и координирует работы исследователей. В отличие от IETF, IRTF, тем не менее, в настоящее время гораздо меньше по размерам. Каждый член IRSG набирает добровольцев в Исследовательские Группы Интернета, аналогичные рабочим группам IETF; IRTF не поделен на области.

1.7 Технические отчеты Интернета

Мы уже говорили, что нет ни производителей, ни профессиональных обществ, владеющих технологией TCP/IP. Поэтому, документацию на протоколы, стандарты, и политику нельзя получить от производителя. Вместо этого, DCA финансирует группу в SRI International, которая получает и распространяет информацию о TCP/IP и обьединенном Интернете. Известная, как Сетевой Информационный Центр ил просто NIC, эта группа управляет многими административными вопросами Интернета помимо распространения документации.

Вся документация о работах в Интернете, предложениях о новых или переработанных протоколах, и стандартах протоколов TCP/IP появляется в виде серии технических отчетов, называемых Request For Comments или RFC(буквальный перевод приблизительно такой - Требуются Комментарии).(Ранние версии RFC были известны как черновые проекты Интернета). RFC могут быть маленькими или большими, могут описывать фундаментальные концепции или детали частного вопроса, и могут быть стандартами или просто предложениями новых протоколов. Редактор RFC называется Делегированным Архитектором Интернета, и является членом IAB.

Пока RFC редактируются, на них не ссылаются так, как это делается с исследовательскими академическими статьями. Также, некоторые отчеты, имеющие отношение к Интернету, уже публиковались в более ранних, параллельных сериях отчетов, названных Инженерными Заметками об Интернете или IEN. Хотя серии IEN более не используются, не все IEN были опубликованы в RFC. Ссылки на IEN и RFC разбросаны по всей книге.

Обе серии RFC и IEN нумеровались последовательно в хронологическом порядке написания. Каждому новому или переработанному RFC назначался новый номер, поэтому читателям нужно быть уверенным в том, что они получили версию документа с наибольшим номером; индекс поможет найти нужную версию.

NIC распространяет RFC и IEN по всему сообществу. Вы можете получить RFC от NIC, послав письмо по обычной почте,электронной почте или напрямую связавшись с ним по Интернету, используя программу передачи файлов. Спросите эксперта по локальным сетям, как получить RFC из вашего места или посмотрите приложение 1для дальнейших инструкций о том, как получить их.

1.8. Протоколы Интернета и стандартизация.

Читатели, знакомые с сетями передачи данных, понимают, что существует множество стандартов протоколов коммуникации. Многие из них предшествовали Интернету, поэтому возникает вопрос:"Почему разработчики Интернета придумали новые протоколы, когда уже существует так много международных стандартов?". Ответ сложен, но ниже приведена простая максима:

Используйте существующие стандартные протоколы до тех пор, пока эти стандарты применимы; придумывайте новые протоколы только тогда, когда существующие стандарты неэффективны, но приготовьтесь перейти на международные стандарты, когда они станут доступны и обеспечат такие же возможности.

Поэтому, связка протоколов TCP/IP не игнорировала международных стандартов. Она появилась просто потому, что существующие стандарты не удовлетворяли потребностям. Философия использования стандартов, когда они появляются, также означает, что когда появятся международные стандарты и обеспечат ту же самую взаимную работоспособность, что и TCP/IP, Интернет перейдет с TCP/IP на эти новые стандарты. Эти идеи согласуются с политикой федерального правительства, которое приняло Профиль Открытых Систем, который описывает использование межсетевой технологии МОС везде, где эта технология обеспечивает возможности, эквивалентные TCP/IP.

1.9. Будущие рост и технология

Как технология TCP/IP, так и Интернет продолжают развиваться. Разрабатываются новые протоколы; пересматриваются старые. NSF значительно усложнила систему, введя свою магистральную сеть, несколько региональных сетей, и сотни университетских сетей. Другие группы также продолжают присоединяться к Интернету. Самое значительное изменение произошло не из-за присоединения дополнительных сетей, а из-за дополнительного траффика. Физики, химики, и астрономы работают и обмениваются обьемами данных гораздо большими, чем исследователи в компьютерных науках, составляющие большую часть пользователей траффика раннего Интернета. Эти новые ученые привели к значительному увеличению загрузки Интернета, когда они начали использовать его, и загрузка постоянно увеличивалась по мере того, как они все активнее использовали его.

Чтобы приспособиться к росту траффика, пропускная способность магистральной сети NSFNET была увеличена вдвое, приведя к тому, что текущая пропускная способность приблизительно в 28 раз больше, чем первоначальная; планируется еще одно увеличение, чтобы довести этот коэффициент до 30, в конце 1990 года. На настоящий момент трудно предсказать, когда исчезнет необходимость дополнительного повышения пропускной способности.

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

Рисунок 1.2 обобщает расширение Интернета и иллюстрирует важную составляющую роста: изменение в сложности, возникшее из-за того, что несколько автономных групп являются частями обьединенного Интернета. Исходные проекты для многих подсистем предполагали централизованное управление. Потребовалось много усилий, чтобы доработать эти проекты для работы при децентрализованном управлении.

Число Число Число

сетей компьютеров управляющих

1980 10 10**2 1

1990 10**3 10**5 10

1995 10**5 10**10 100

Рисунок 1.2 Рост обьединенного Интернета. Помимо увеличения траффика из-за увеличения размера, Интернет столкнулся с сложностью, явившейся результатом децентрализованного управления как при разработке, так и при работе.

1.10 FNC и NREN

Федеральный Сетевой Совет(FNC) служит для координации деятельности федеральных агентств, финансирующих исследования или разработки в области TCP/IP и Интернета. FNC состоит из представителей DARPA, NSF, NASA, DOE, DOD и HHS. Члены FNC принимают участие во встречах IAB и помогают определять приоритеты в исследовательских и инженерных проектах Интернета.

Учитывая увеличившиеся потребности своих агентств и общенациональную заинтересованность в высокоскоростной вычислительной сети, FNC вместе с лидерами этого технического сообщества выработал план преобразования Интернета в Национальную Исследовательскую и Образовательную Сеть(NREN). В соответствии с этим планом, NREN будет расширяться таким образом, чтобы в конечном счете соединить все образовательные институты и исследовательские лаборатории. Для этого потребуются более высокоскоростные коммуникационные технологии, а также переход от финансируемых федеральным правительством магистральных сетей к средствам, работающим на коммерческой основе. FNC будет использовать федеральные исследовательские фонды для стимуляции исследований и разработки требуемых технологий.

1.11 Организация этой книги

Эта книга организована в виде двух томов. Том 1 содержит описание технологии TCP/IP, приложений, которые используют ее и архитектуры обьединенного Интернета. Он рассматривает основы протоколов, таких как TCP и IP, и показывает, как они объединяются. Помимо всего этого, он описывает общие принципы базовых сетевых протоколов и объясняет, почему протоколы TCP/IP так легко адаптируются ко многим базовым технологиям физических сетей. Том 2 рассматривает детально внутренние детали протоколов TCP/IP и показывает, как программисты используют их. Он рассматривает интерфейс между программами и протоколами и показывает, как создавать и управлять обьединенными сетями корпорации.

Итак, мы уже рассказали о технологии TCP/IP и Интернете в общих чертах, обобщив имеющиеся средства и историю его развития. Следующая глава дают краткий обзор типов сетевого оборудования, используемого в Интернете. Их цель - не выделить нюансы оборудования конкретного производителя, а подчеркнуть особенности каждой технологии, которые имеют большое значение для архитектуры Интернета. Следующие главы углубляются в протоколы и Интернет, преследуя три цели: они исследуют общие понятия и дают обзор модели архитектуры Интернета, они изучают детали протоколов TCP/IP и они знакомят со стандартами средств верхнего уровня, такими как электронная почта и электронная передача файлов. Главы с 3 по 12 дают обзор фундаментальных принципов и описывают сетевое программное обеспечение, имеющейся на любой машине, использующей TCP/IP. Последующие главы описывают средства, которые объединяют группы машин, включая распространение информации о маршрутизации, разрешение имен и приложения, такие как электронная почта.

За текстом идет несколько приложений. Первое приложение содержит руководство по RFC. Оно дополняет описание RFC, данное в этой главе, и дает примеры того, что можно найти в RFC. Оно детально описывает, как получить RFC из NIC с помощью электронной почты, обычной почты, и передачи файлов. Наконец, так как индекс RFC приводится в хронологическом порядке, оно представляет список RFC, организованный по разделам для удобства начинающих при поиске RFC, относящегося к данному вопросу.

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

Наконец, третье приложение, задуманное как справочник, содержит список официальных протоколов Интернета. Оно включает описание терминологии IAB для определения различий между "рекомендуемыми" и "требуемыми" протоколами, а также список самих протоколов.

1.12. Итоги.

Обьединенная сеть состоит из набора связанных сетей, которые взаимодействуют как единое целое. Главным преимуществом Интернета является то, что он обеспечивает универсальное взаимное соединение, позволяя в это же время отдельным группам использовать любое сетевое оборудование, лучше всего подходящее для их целей. Мы рассмотрим принципы, лежащие в основе межсетевого взаимодействия в общем и детали межсетевой связки протоколов в частности. Мы также рассмотрим, как межсетевые протоколы используются в Интернете. Наша демонстрационная технология, названная TCP/IP по имени двух основных протоколов, была разработана DARPA. Она обеспечивает основу объединенного Интернета, большой, работающей объединенной сети, которая соединяет большинство научно-исследовательских институтов, включая многие университетские, правительственные лаборатории. Обьединенный Интернет быстро расширяется и продолжает поддерживаться DARPA, NSF, DOE, NASA и другими правительственными агентствами.

 

Глава 2. Обзор базовых сетевых технологий

2.1 Введение

Важно понимать, что Интернет не является новым видом
физической сети. На самом деле это метод взаимного соединения
физических сетей и набор соглашений для использования сетей,
которые позволяют компьютерам взаимодействовать друг с другом. В
то время как аппаратная технология играет небольшую роль при
концептуальном проектировании, важно понимать разницу между
низкоуровневыми механизмами, обеспечиваемыми самим оборудованием,
и высокоуровневыми средствами, которые обеспечивает программное
обеспечение протоколов Интернета. Также важно понимать, как
средства, обеспечиваемые технологией коммутации пакетов, влияют
на наш выбор абстракций высокого уровня.
Эта глава вводит основные понятия коммутации пакетов и
терминологию. а затем рассматривает базовые технологии сетевого
оборудования, которые использовались в объединенной сетях TCP/IP.
Следующие главы описывают, как эти сети объединяются и как
протоколы TCP/IP согласованы с различиями в оборудовании. В то
время как список сетей, представленный здесь, не является
исчерпывающим, он хорошо демонстрирует разнообразие физических
сетей, над которыми работает TCP/IP.Читатель может спокойно
пропустить большую часть технических деталей, но должен
попытаться понять идею пакетной коммутации и должен попытаться
представить архитектуру однородной коммуникационной системы,
использующей такое разнообразное оборудование. Более того,
читатель должен внимательно изучить детали схем физических
адресаций в различных используемых технологиях; следующие главы
рассмотрят детально, как протоколы высокого уровня используют эти
физические адреса.

2.2 Два подхода к сетевому взаимодействию

Независимо от того, обеспечивают ли они соединение между
компьютерами или между компьютерами и терминалами,
коммуникационные сети могут быть разделены на два основных типа:
с коммутацией каналов и коммутацией пакетов. Сети с коммутацией
каналов работают, образуя выделенное соединение(канал) между
двумя точками. Телефонная сеть США использует технологию с
коммутацией каналов - телефонный вызов устанавливает канал от
вызывающего телефона через локальную АТС, по линиям связи, к
удаленной АТС, и, наконец, к отвечающему телефону. Пока
существует канал, телефонное оборудование постоянно опрашивает
микрофон, кодирует полученное значение в цифровой форме, и
передает его по этому каналу к получателю. Отправителю
гарантируется, что опросы будут доведены и воспроизведены, так
как канал обеспечивает скорость 64 Кбит/с, которой достаточно для
передачи оцифрованного голоса. Преимущество коммутации каналов
заключается в ее гарантированной пропускной способности: как
только канал создан, ни один сетевой процесс не уменьшит
пропускной способности этого канала. Недостатком при коммутации
каналов является ее стоимость: платы за каналы являются
фиксированными и независимыми от траффика. Например, можно
заплатить за телефонный вызов, даже если две разговаривающие
стороны вообще ничего не говорили.
Сети с коммутацией пакетов, тип обычно используемый при
соединении компьютеров, используют совершенно другой подход. В
сетях с коммутацией пакетов траффик сети делится на небольшие
части, называемые пакетами, которые объединяются в
высокоскоростных межмашинных соединениях. Пакет, который обычно
содержит только несколько сотен байтов данных, имеет
идентификатор, который позволяет компьютерам в сети узнавать,
предназначен ли он им, и если нет, то помогает им определить, как
послать его в указанное место назначения. Например, файл,
передаваемый между двумя машинами, может быть разбит на большое
число пакетов, которые посылаются по сети по одному. Оборудование
сети доставляет пакеты к указанному месту назначения, а сетевое
программное обеспечение собирает пакеты опять в один файл.
Главным преимуществом коммутации пакетов является то, что большое
число соединений между компьютерами может работать одновременно,
так как межмашинные соединения разделяются между всеми парами
взаимодействующих машин. Недостатком ее является то, что по мере
того как возрастает активность, данная пара взаимодействующих
компьютеров получает все меньше сетевой пропускной способности.
То есть, всякий раз, когда сеть с коммутацией пакетов становится
перегруженной, компьютеры, использующие сеть, должны ждать, пока
они не смогут послать следующие пакеты.
Несмотря на потенциальный недостаток негарантируемой сетевой
пропускной способности, сети с коммутацией пакетов стали очень
популярными. Причинами их широкого использования являются
стоимость и производительность. В связи с тем, что к сети может
быть подключено большое число машин, требуется меньше соединений
и стоимость остается низкой. Так как инженеры смогли создать
высокоскоростное сетевое оборудование, с пропускной способностью
обычно проблем не возникает. Так много компьютерных соединений
использует коммутацию пакетов, что далее в книге термин СЕТЬ
будет обозначать только сеть с коммутацией пакетов.

2.3 Глобальные сети, городские сети, локальные сети

Сети с коммутацией пакетов, которые разрослись до больших
географических размеров(например, континентальной части США),
сильно отличаются от сетей, имеющих небольшие размеры(например,
одну комнату). Чтобы помочь охарактеризовать различия в
пропускной способности и способах использования, технологии
коммутации пакетов часто делят на три большие категории:
глобальные сети(WAN), городские сети(MAN) и локальные сети(LAN).
Технологии WAN, иногда называемые long haul
networks(буквально - сети дальних перевозок), позволяют

 

Глава 3 Понятие межсетевого обмена и архитектурная модель

3.1 Введение

Так как мы уже рассмотрели низкоуровневые детали передачи в
отдельных сетях, основу, на которой строится взаимодействие
компьютеров. Эта глава делает большой концептуальный скачок,
описывая схему, которая позволяет нам объединять разнообразные
сетевые технологии в единое целое. Нашей главной целью является
схема, которая скрывает детали лежащего в ее основе сетевого
оборудования, в то же время обеспечивая универсальные средства
взаимодействия. Основным результатом является высокоуровневая
абстракция, которая обеспечивает основу для всех проектных
решений. Последующие главы покажут, как мы используем эту
абстракцию для построения необходимых уровней межсетевого
коммуникационного математического обеспечения и как это
программное обеспечение скрывает лежащие в его основе механизмы
физической передачи. Следующие главы также покажут, как
приложения используют получившуюся коммуникационную систему.

3.2 Взаимодействие на прикладном уровне

Разработчики используют два различных подхода для скрытия
деталей сетевого взаимодействия, используя прикладные программы
для работы в неоднородной среде или скрывая эти детали в
операционной системе. Ранние взаимодействия неоднородных сетей
обеспечивали единообразие с помощью прикладных программ. В таких
системах прикладная программа, работая на каждой машине в сети,
знала детали сетевого взаимодействия для этой машины и
взаимодействовала с прикладными программами по этим соединениям.
Например, некоторые системы электронной почты состояли из
программ-отправителей писем(mailer), которые передавали письма
по-одному. Путь от источника до получателя мог включать различные
сети, но это не имело значения до тех пор, пока системы
электронной почты на всех машинах были способны работать друг с
другом.
Использование прикладных программ для скрытия сетевых деталей
может показаться на первый взгляд естественным, но такой подход
приводит к ограниченному, громоздкому взаимодействию. Добавление
новых возможностей к этой системе означает создание новой
прикладной программы на каждой машине. Добавление нового сетевого
оборудования означает модификацию или создание новых программ для
всех возможных приложений. На данной машине каждая программа
знает сетевые соединения для этой машины, что приводит к
дублированию кода.
Пользователи, имеющие опыт работы с сетями, знают, что
когда-нибудь во взаимодействии будут участвовать сотни или тысячи
сетей; тогда никто не будет в состоянии создать все необходимые
прикладные программы. Более того, для успешного использования
пошаговой схемы взаимодействия требуется корректность всех
прикладных программ на всем пути. Если программа на промежуточной
машине аварийно завершится, ни отправитель, ни получатель не
смогут обнаружить ошибку или исправить ее. Поэтому системы,
использующие промежуточные программы, не могут гарантировать
надежного взаимодействия.

3.3 Взаимодействие на сетевом уровне

Альтернативой обеспечению взаимодействия прикладными
программами являются системы, основанные на соединении сетевого
уровня. Соединение на сетевом уровне обеспечивает механизм,
который доставляет пакеты от их настоящего отправителя к
настоящему получателю в реальном масштабе времени. Коммутация для
передачи маленьких блоков, а не файлов или больших сообщений
имеет ряд преимуществ. Во-первых, она напрямую отображается в
базовое сетевое оборудование, что делает ее очень эффективным.
Во-вторых, она разделяет процессы передачи данных от прикладных
программ, позволяя машинам обрабатывать сетевой траффик, не зная
какие приложения передают его. В-третьих, она делает систему
гибкой, делая возможным создание сетевых протоколов общего
назначения. В-четвертых, она позволяет администраторам сетей
добавлять новые сетевые технологии, модифицируя программное
обеспечение сетевого уровня или добавляя к нему новую часть и не
внося при этом никаких изменений в прикладные программы.
Ключевым понятием при разработке универсального
взаимодействия сетевого уровня является понятие абстрактной
коммуникационной системы, известное как межсетевой
обмен(internetworking). Понятие объединенной сети(internetwork
или internet) является очень мощным. Оно отделяет понятие
взаимодействия от деталей сетевых технологий и скрывает
низкоуровневые детали от пользователя. Более того, оно определяет
все проектные решения при разработке программного обеспечения и
объясняет, как работать с физическими адресами и маршрутами.
После перечисления основных причин организации межсетевого обмена
мы рассмотрим свойства объединенной сети более детально.
Напомним, что мы начали с двух фундаментальных замечаний о
разработке коммуникационных систем:

-одна сеть не может обслужить всех пользователей
-пользователи хотят универсального взаимодействия

Первое замечание является техническим. Локальные сети,
обеспечивающие наивысшую скорость взаимодействия, ограничены в
своих размерах; глобальные сети охватывают большие районы, но не
могут обеспечить высокоскоростные соединения. Нет одной сетевой
технологии, удовлетворяющей всем нуждам, поэтому мы вынуждены
использовать несколько базовых аппаратных технологий.
Второе замечание очевидно. В конечном счете, нам хотелось бы
иметь возможность организовать взаимодействие между любыми двумя
точками. В частности, мы хотели бы иметь коммуникационную
систему, не заключенную в границы физических сетей.
Нашей целью является создание унифицированного, объединенного
взаимодействия сетей, поддерживающих универсальное
коммуникационное средство. Внутри каждой сети компьютеры будут
использовать базовые коммуникационные примитивы, зависящие от
технологии и похожие на те, что описаны в главе 2. Новое
программное обеспечение, вставленное между механизмами
взаимодействия, зависящими от технологии, и прикладными
программами, будет скрывать низкоуровневые детали и сделает так,
что группа сетей будет казаться одной большой сетью. Такая схема
взаимодействия называется объединенной сетью(internet).
Идея создания объединенной сети следует стандартному подходу
при разработке систем: разработчики придумывают высокоуровневое
вычислительное средство и дорабатывают имеющуюся вычислительную
технологию, добавляя уровни программного обеспечения до тех пор,
пока они не получат систему, эффективно реализующую придуманное
ими высокоуровневое средство. Следующий раздел опишет первый шаг
при разработке, более точно определив цель.

3.4 Свойства объединенной сети(интернета)

Понятие универсального средства важно, но само по себе оно не
охватывает все идеи, подразумевавшиеся нами для унифицированной
объединенной сети, так как может существовать много реализаций
универсальных средств. В нашем проекте мы хотим скрыть базовую
архитектуру объединенной сети от пользователя. То есть, мы не
хотим требовать от пользователя или прикладной программы знания
деталей аппаратных взаимодействий, используемых в объединенной
сети. Мы также не хотим предписывать топологию сетевых
взаимодействий. В частности, добавление новой сети к интернету не
должно означать ее соединение с центральным маршрутизатором, а
также не должно означать добавление прямых физических соединений
между новой сетью и всеми существующими сетями. Мы хотим иметь
возможность посылать данные через промежуточные сети даже если
они не соединены напрямую с машинами отправителя и получателя. мы
хотим, чтобы все машины в интернете имели идентификаторы из
одного универсального множества машинных идентификаторов(которые
могут представляться как имена или адреса).
Наше понятие унифицированного интернета также включает идею
сетевой независимости для интерфейса с пользователем. То есть, мы
хотим, чтобы набор операций, используемых для установления
взаимодействия или передачи данных, оставался независимым от
базовых сетевых технологий и машины получателя. И конечно,
пользователю не следует знать топологию сетевых взаимодействий
при написании взаимодействующих прикладных программ.

3.5 Архитектура Интернета

Мы уже видели, как машины присоединяются к отдельным сетям.
Возникает вопрос: "Как соединяются сети между собой для создания
объединенной сети ?" Ответ состоит из двух частей. Физически две
сети могут соединяться только с помощью компьютера,
присоединенного к каждой из них. Физическое соединение, тем не
менее, не обеспечивает подразумевавшееся нами взаимодействие, так
как такое соединение не гарантирует, что компьютер сможет
взаимодействовать с другими машинами, с которыми он хотел бы это
сделать. Чтобы иметь надежный интернет, нам нужно, чтобы
компьютеры были согласны передавать пакеты из одной сети в
другую. Компьютеры, соединяющие две сети и передающие пакеты из
одной в другую, называются межсетевыми шлюзами(gateway) или
межсетевыми маршрутизаторами(router).
Рассмотрим пример, состоящий из двух физических сетей,
показанный на рисунке 3.1. На этом рисунке машина G присоединена
как к сети 1, так и к сети 2. Чтобы G работал как шлюз, он должен
принимать пакеты из сети 1, предназначенные машинам в сети 2 и
передавать их туда. Аналогично, G должен принимать пакеты из сети
2, которые предназначены машинам в сети 1 и передавать их туда.

---------------- ----------------
| | ----- | |
| Сеть 1 |--------| G |--------| Сеть 2 |
| | ----- | |
---------------- ----------------

Рисунок 3.1 Две сети, соединенные шлюзом G.

3.6 Соединение через IP-шлюзы(маршрутизаторы)

Когда соединения интернета становятся более сложными, шлюзам
нужно знать о топологии интернета за пределами сетей, к которым
они присоединены. Например, рисунок 3.2 показывает три сети,
соединенные между собой двумя шлюзами.

---------- ---------- ----------
| | ------ | | ------ | |
| Сеть 1 |-| G1 |-| Сеть 2 |-| G2 |-| Сеть 3 |
| | ------ | | ------ | |
---------- ---------- ----------

Рисунок 3.2 Три сети, соединенные между собой двумя шлюзами

В этом примере шлюз G1 должен перемещать из сети 1 в сеть 2
все пакеты, предназначенные для машин либо в сети 2, либо в сети
3. По мере того, как размер интернета увеличивается, задача шлюза
по принятию решений о том, куда посылать пакеты, становится более
сложной.
Идея шлюза кажется простой, но она важна, потому что она
обеспечивает способ взаимного соединения сетей, а не машин.
Фактически, мы уже установили принцип взаимного соединения,
используемый повсеместно в интернете:

В интернете TCP/IP компьютеры, называемые шлюзами,
обеспечивают все соединения между физическими сетями.

Вы можете ожидать, что шлюзы, которые знают, как направить
пакеты к их получателю, являются большими машинами, имеющими
достаточное количество основной или внешней памяти для хранения
информации о каждой машине в интернете, к которому они
присоединены. Тем не менее, шлюзы, используемые в интернетах
TCP/IP, обычно являются миникомпьютерами; они часто имеют
небольшую дисковую память или не имеют ее вообще, а также имеют
ограниченную оперативную память. Причина использования маленьких
межсетевых шлюзов заключена в следующем утверждении:

Шлюзы маршрутизируют пакеты, основываясь на сети получателя,
а не на машине получателя.

Если маршрутизация основана на сетях, то количество
информации, которую нужно хранить шлюзу, пропорционально
количеству сетей в интернете, а не числу машин в нем.
Так как шлюзы играют ключевую роль в межсетевом
взаимодействии, мы вернемся к ним в следующих главах и рассмотрим
детали того, как они работают и как они получают информацию о
путях. А пока мы будем предполагать, что существует реальная
возможность иметь корректные пути для всех сетей в каждом шлюзе в
интернете. Мы будем также предполагать, что только шлюзы
обеспечивают соединение между физическими сетями в интернете.

3.7 Взгляд пользователя

Напомним, что TCP/IP разработан, чтобы обеспечить
универсальное взаимное соединение между машинами, не зависящее от
конкретных сетей, к которым они присоединены. Поэтому, мы хотим,
чтобы пользователь представлял себе интернет как единую
виртуальную сеть, к которой присоединены все машины, не смотря на
то, что физически это не так. Рисунок 3.3а показывает, как
представление об интернете как об одной большой сети, а не как о
группе сетей, упрощает детали и делает легким для пользователя
концептуализацию взаимодействия. Помимо шлюзов, соединяющих
физические сети, на каждом хосте требуется программное
обеспечение доступа к интернету, чтобы прикладные программы могли
использовать интернет так, как будто это одна физическая сеть.
Преимущество соединения на сетевом уровне становится ясным.
Так как прикладные программы, взаимодействующие с помощью
интернета, не знают детали организации соединений, они могут
запускаться в неизменном виде на любой машине. Так как детали
физических сетевых соединений для каждой машины скрыты в
межсетевом программном обеспечении, при появлении новых
физических соединений или удалении старых требуется менять только
это программное обеспечение. Фактически, можно оптимизировать
маршрутизацию, изменив физические соединения, но не
перекомпилировав при этом прикладные программы.
Второе преимущество организации взаимодействия на сетевом
уровне менее важное: пользователям не нужно знать или помнить,
как соединены сети или какой траффик они передают. Прикладные
программы могут быть написаны таким образом, что будут работать
независимо от физической связности. Фактически, сетевые
администраторы могут свободно изменять внутренние части базовой
архитектуры интернета, не меняя прикладные программы в
большинстве компьютеров, присоединенных к интернету(конечно,
сетевое программное обеспечение должно быть переконфигурировано,
когда компьютер перемещается в новую сеть).
Как показывает рисунок 3.3б, шлюзы не обеспечивают прямое
соединение между всеми парами сетей. Траффику, передающемуся от
одной машины к другой, может понадобиться пройти через несколько
промежуточных сетей. Поэтому, сети, участвующие в интернете,
являются аналогами высокоскоростных магистралей(highway) в США:
каждая сеть согласна передавать транзитный траффик в обмен на
право посылать траффик через весь интернет. Типичные пользователи
даже не ощущают, что по их локальной сети проходит дополнительный
траффик.

3.8 Все сети равны

В главе 2 был сделан обзор сетевого оборудования,
используемого для построения интернетов TCP/IP и
проиллюстрировала большое разнообразие технологий. Мы описали
интернет как набор взаимодействующих, взаимосвязанных сетей.
На данный момент важно уяснить фундаментальное понятие: с точки
зрения интернете, любая коммуникационная система, способная
передавать пакеты, считается одной сетью, независимо от ее
задержек при передаче, пропускной способности, максимального
размера пакета или географических размеров. В частности, рисунок
3.3б использует прямоугольник одинаковых размеров для обозначения
всех физических сетей, так как TCP/IP считает их равными,
несмотря на их разницу. Итак,

Межсетевые протоколы TCP/IP считают все сети равными.
Локальная сеть, такая как Ethernet, глобальная сеть, такая как
магистральная сеть NSFNET, или соединение точка-точка между двумя
машинами - каждый из них считается сетью.

Читатели, не привыкшие к архитектуре интернета, могут
найти неприемлемым такой упрощенный взгляд на сети. По существу,
TCP/IP определяет абстрактное понятие "сеть", которое скрывает
детали физических сетей; мы увидим, что такие абстракции делают
TCP/IP очень мощным.

--- ---
|Э|-- --|Э|
--- | | ---
/--------- ---
--- | интернет |----|Э|
|Э|-| | ---
--- |
/
| ------/ ---
--- -|Э|
|Э| ---
-- /
---ЭВМ----

(а)

--- --- -----интернет
|Э|-- --|Э| |
--- | | --- V ---
/------------------------- / --|Э|
| | |-----| |/ ---
| ++++ __ ++++ /
| + +--||--+ +----------/
/ ++++ -- ++++ физическая
| -- | | сеть |
| ||-| | | |
| -- | V | ---
--- | | -- | ++++ /---|----|Э|
|Э|-|---++++--||---| + +---/ | ---
--- + + -- ++++ /
| ++++ | /
| | | |
| -- ++++ -- |
||-----+ +---||<-шлюз /
-- ++++ -- /
| ----------------------/
--- |Э|
|Э| ---
-- /
---ЭВМ-----------

(б)

Рисунок 3.3 (а) Пользовательское представление об интернете
TCP/IP, при котором кажется, что каждый компьютер присоединен к
одной большой сети, и (б) структура физических сетей и шлюзов,
обеспечивающая соединение

 

3.9 Вопросы, которые остались без ответа

Наш краткий обзор интернетов оставил много вопросов без
ответов. Например, вас может интересовать точная форма машинных
адресов в интернете или то, как такие адреса соотносятся с
физическими аппаратными адресами Ethernetа, proNET-10 или
ARPANETа, описанными в главе 2. Следующие три главы ответят на
эти вопросы. Они опишут формат адресов IP и проиллюстрируют, как
ГВМ осуществляют отображение интернетовских адресов в физические
и наоборот. Вы также можете захотеть узнать точно, как выглядит
пакет при передаче его через интернет, или что происходит, когда
на некоторые ГВМ или шлюзы пакеты прибывают быстрее, чем их можно
обработать. Глава 7 ответит на эти вопросы. Наконец, вас может
заинтересовать, как несколько прикладных программ, выполняющихся
параллельно на одной машине, могут посылать и принимать пакеты из
несколько мест сразу, не запутавшись при этом, или как
интернетовские шлюзы получают информацию о путях. На все эти
вопросы также будут даны ответы.
Хотя это сейчас еще не видно, направление, в котором мы
двигаемся, позволит нам изучить как структуру, так и применения
межсетевого протокольного программного обеспечения. Мы рассмотрим
каждую часть, изучая концепции и принципы, а также технические
детали. Мы начали с того, что изучили уровень физического
взаимодействия, на основе которого строится интернет. Каждая из
следующих глав будет рассматривать одну из частей межсетевого
программного обеспечения, до тех пор, пока мы не поймем, как все
эти части согласованы друг с другом.

3.10 Итоги

Интернет - это более чем набор сетей, соединенных с помощью
компьютеров. Межсетевой обмен подразумевает, что участвующие в
нем системы подчиняются соглашениям, которые позволяют каждому
компьютеру взаимодействовать со всеми остальными компьютерами. В
частности, интернет позволит двум машинам взаимодействовать, даже
если путь при взаимодействии между ними проходит по сети, к
которой ни одна из них не присоединена. Такое взаимодействие
возможно только в том случае, когда компьютеры подчиняются
соглашениям о наборе универсальных идентификаторов и наборе
процедур для перемещения данных к их конечному получателю.
В интернете соединения между сетями образуются с помощью
компьютеров, называемых IP-шлюзами, или маршрутизаторами, которые
присоединяются к двум и более сетям. Шлюзы маршрутизируют пакеты
между сетями, получая их от одной сети и направляя их в другую.

 

 

Глава 4 Адреса Интернета

4.1 Введение

Предыдущая глава определила интернет TCP/IP как виртуальную
сеть, созданную в результате соединения физических сетей шлюзами.
Эта глава описывает адресацию, существенный компонент, который
помогает программному обеспечению TCP/IP скрывать детали
физических сетей и создавать впечатление об интернете как о
единой сущности.

4.2 Универсальные идентификаторы

Говорят, что коммуникационная система обеспечивает
универсальное средство взаимодействия, если она позволяет любой
ГВМ связываться с любой другой ГВМ. Чтобы сделать нашу
коммуникационную систему универсальной, нам нужно определить
приемлемый для всех метод идентификации компьютеров, которые
присоединены к ней.
Часто идентификаторы ГВМ классифицируются как имена, адреса,
или маршруты. Shoch[1978] предложил, чтобы имя идентифицировало,
что такое объект, адреса идентифицировал, где он находится, а
маршрут(путь) определял, как до него добраться. Хотя эти
определения являются интуитивно ясными, они могут ввести в
заблуждение. На самом деле имена, адреса и маршруты определяются
на разных уровнях представления идентификаторов ГВМ, причем имена
на самом верхнем, а маршруты - на самом нижнем. Вообще люди
обычно предпочитают произносимые имена для идентификации машин, в
то время как программное обеспечение лучше работает с более
компактным представлением идентификаторов, которые мы считаем
адресами. Все, что угодно могло бы быть выбрано в качестве
универсальных идентификаторов ГВМ в TCP/IP. Но было принято
решение стандартизовать компактные, двоичные адреса, которые
делают вычисления, такие как выбор маршрута, эффективными. Теперь
мы перейдем к рассмотрению только двоичных адресов, оставив на
потом вопросы о том, как производится отображение между двоичными
адресами и произносимыми именами, и о том, как использовать
адреса для маршрутизации.

4.3 Три основных класса IP-адресов

Думайте об интернете как о большой сети, такой же ,как и
любая другая физическая сеть. Разница заключается в том, что
интернет - это виртуальная структура, придуманная его
разработчиками, и реализованная полностью в программном
обеспечении. Поэтому, разработчики могут определить по своему
усмотрению форматы и размеры пакетов,адреса, технологии доставки
и т.д.; аппаратное обеспечение не определяет ничего. Для адресов
разработчики TCP/IP выбрали схему, аналогичную адресации в
физических сетях, в которой каждой ГВМ в интернете назначается
адрес в виде целого числа, называемый межсетевым адресом или
IP-адресом. Самым умным в межсетевой адресации является то, что
целые числа для адресов тщательно выбираются, чтобы сделать
маршрутизацию эффективной. Если говорить более конкретно,
IP-адрес кодирует идентификацию сети, к которой присоединена ГВМ,
а также идентификацию уникальной ГВМ в этой сети. Можно сделать
вывод:

Каждой ГВМ в интернете TCP/IP назначен уникальный 32-битовый
межсетевой адрес, который используется при взаимодействии с этой
ГВМ.

Детали IP-адресов помогут уточнить абстрактные идеи. А пока
мы дадим упрощенное представление, которое будет впоследствии
усложнено. В простейшем случае каждой ГВМ, присоединенной к
интернету, назначается 32-битовый универсальный идентификатор в
качестве его межсетевого адреса. IP-адреса для всех ГВМ данной
сети имеют одинаковый префикс.
Концептуально каждый адрес является парой (идсет,идГВМ), где
идсет идентифицирует сеть, а идГВМ идентифицирует ГВМ в этой
сети. На практике каждый IP-адрес должен иметь одну из первых
трех форм из числа тех, что показаны на рисунке 4.1(четвертая
форма, зарезервированная для межсетевого широковещания, будет
описана позднее; на данный момент мы ограничимся формами,
описывающими адреса для отдельных объектов).

0 1 7 8 31
---------------------------------------------------
Класс А |0|идсет | идГВМ |
---------------------------------------------------

0 1 2 15 16 31
---------------------------------------------------
Класс В |1|0| идсет | идГВМ |
---------------------------------------------------

0 1 2 3 23 24 31
---------------------------------------------------
Класс С |1|1|0| идсет | идГВМ |
---------------------------------------------------

0 1 2 3 4 31
---------------------------------------------------
Класс D |1|1|1|0| групповой адрес |
---------------------------------------------------

0 1 2 3 4 5 31
---------------------------------------------------
Класс Е |1|1|1|1|0| зарезервировано на будущее |
---------------------------------------------------

Рисунок 4.1 Пять форм адресов Интернета(IP). Три основные
формы, классы А,В и С можно различить по первым двум битам.

Класс данного IP-адреса можно определить по первым трем
старшим битам, причем первых двух бит достаточно для определения
принадлежности адреса к одному из трех основных классов. Адреса
класса А, которые используются для сетей, имеющих в своем составе
более чем 2**16(т.е. 65536) ГВМ , выделяют под идсет 7 бит, а под
идГВМ 24 бита. Адреса класса В, которые используются для сетей
промежуточного размера, включающих от 2**8(т.е. 256) до 2**16
ГВМ, выделяют 14 бит под идсет, а 16 бит под идГВМ. И наконец,
сети класса С, состоящие менее чем из 256 ГВМ, выделяют 21 бит
под идсет и только 8 бит под идГВМ. Заметим, что IP-адрес был
определен таким образом, что можно быстро расширить идГВМ или
идсет. Шлюзы используют для маршрутизации поле идсет и полагаются
на его эффективное выделение.

4.4 Адреса описывают сетевые соединения

Для простоты изложения предмета мы говорили, что межсетевой
адрес идентифицирует ГВМ, но это не совсем так. Представим себе
шлюз. присоединенный к двум физическим сетям. Как мы можем
назначить ему один IP-адрес, если адрес кодирует как
идентификатор сети, так и идентификатор ГВМ ? Мы не можем это
сделать. Когда обычные компьютеры имеют два или более физических
соединений, они называются многоадресными(multi-homed) ГВМ.
Многоадресные ГВМ и шлюзы требуют нескольких адресов IP. Каждый
адрес соответствует одному из соединений этой машины с сетью.
Учет многоадресных ГВМ приводит нас к следующему важному выводу:

Так как IP-адреса кодируют как сеть, так и ГВМ в этой сети,
они не описывают конкретную машину, а только соединение ее с
сетью.

Поэтому шлюз, соединяющий N сетей, имеет N различных IP
адресов, по одному на каждое сетевое соединение.

4.5 Сетевые и широковещательные адреса

Мы уже отметили основное преимущество кодирования информации
о сети в межсетевых адресах: оно делает возможной эффективную
маршрутизацию. Другим преимуществом является то, что межсетевые
адреса могут указывать как сети, так и отдельные ГВМ. По
соглашению идГВМ, равный 0, никогда не назначается отдельной ГВМ.
Вместо этого IP-адрес с нулевым идГВМ используется для ссылки на
саму сеть. Подведем итоги:

Межсетевые адреса могут использоваться для указания как на
сети, так и на отдельные ГВМ. По соглашению адрес сети имеет поле
идГВМ, равное 0.

Другим важным преимуществом межсетевой схемы адресации
является то, что она включает широковещательный адрес, который
используется для ссылки на все ГВМ в данной сети. Согласно
стандарту, любой идГВМ, состоящий из всех единиц, зарезервирован
для широковещания(К сожалению, в ранней версии кода TCP/IP,
входившего в состав BSD UNIX, все нули некорректно использовались
для широковещания, и хотя впоследствии код BSD был исправлен,
ошибка осталась в некоторых коммерческих системах, созданных на
основе этого кода). Во многих сетевых технологиях(например,
Ethernetе) широковещание может быть таким же эффективным, как
обычная передача; в других(например, Cypress) широковещание
поддерживается сетевым программным обеспечением, но требует
значительно больше времени, чем простая передача. Некоторые сети
не поддерживают широковещание вообще. Поэтому, широковещательный
IP-адрес не гарантирует наличия или эффективности
широковещательной доставки пакетов. Подводя итоги, можно сказать,
что:

IP-адреса могут использоваться для указания широковещания и
отображения его в аппаратное широковещание, если это возможно. По
соглашению, широковещательный адрес имеет поле идГВМ со всеми
битами, равными 1.

4.6 Ограниченное широковещание

Технически, широковещательный адрес, который мы уже описали,
называется направленным(directed) широковещательным адресом, так
как он содержит как корректный идентификатор сети, так и
корректный широковещательный адрес ГВМ. Направленный
широковещательный адрес может однозначно интерпретироваться в
любой точке интернета, так как он идентифицирует уникальным
образом сеть получателя помимо указания на широковещание в этой
сети. Направленные широковещательные адреса обеспечивают мощный(и
чем-то опасный) механизм, который позволяет удаленной системе
посылать один пакет, который будет распространен в режиме
широковещания в указанной сети.
С точки зрения адресации, главным недостатком направленного
широковещания является то, что оно требует знаний об адресе сети.
Другая форма широковещательного адреса, называемая ограниченный
широковещательный адрес или локальный сетевой широковещательный
адрес, обеспечивает широковещательный адрес для локальной
сети(сети отправителя), независимо от назначенного ей IP-адреса.
Локальный широковещательный адрес состоит из 32 единиц(поэтому он
иногда называется широковещательным адресом из всех единиц). ГВМ
может использовать ограниченный широковещательный адрес в
процессе своего запуска, до того, как он узнает свой IP-адрес или
IP-адрес локальной сети. Как только ГВМ узнает IP-адрес своей
сети, он может использовать направленное широковещание.
Как правило, протоколы TCP/IP ограничивают широковещание до
наименьшего возможного набора машин. Мы увидим, как это правило
влияет на группы сетей, разделяющих адреса, в главе 6, когда
будем рассматривать адресацию подсетей.

4.7 Интерпретация нуля как символа "это"

Мы видели, что поле, состоящее из единиц, может
интерпретироваться как "все", как "все ГВМ" в сети. Вообще
межсетевое программное обеспечение интерпретирует поля, состоящие
из нулей, как символ "это". Такая интерпретация встречается
повсеместно в литературе. Поэтому IP-адрес с идГВМ, равным 0,
обозначает "этот ГВМ", а межсетевой адрес с идентификатором сети
0 обозначает "эта сеть". Конечно, использовать эти адреса нужно
только в том контексте, в котором они интерпретируются
однозначно. Например, если машина получила пакет, в котором адрес
отправителя имеет поле идсет, установленное в 0, а идГВМ
соответствует собственному, получатель делает вывод о том, что
поле идсет означает эту сеть(т.е. сеть, из которой прибыл пакет).
Использование идсет 0 особенно важно в тех случаях, когда ГВМ
хочет взаимодействовать с помощью сети, но еще не знает свой
сетевой IP-адрес. ГВМ временно использует идентификатор сети 0, а
другие ГВМ в этой сети интерпретируют этот адрес как означающий
"эта сеть". В большинстве случаев ответы будут содержать полный
сетевой адрес, позволяя первоначальному отправителю запомнить его
на будущее. Главы 9 и 20 рассмотрят в деталях, как ГВМ определяет
свой сетевой адрес и как он использует идентификатор сети 0.

4.7.1 Групповая адресация

Помимо широковещания схема адресов IP поддерживает
специальную форму групповой доставки, известную как групповая
доставка(multicasting). Групповая доставка особенно полезна для
сетей, в которых аппаратная технология поддерживает групповую
доставку. Глава 17 рассматривает групповую адресацию и доставку
более детально.

4.8 Недостатки адресации Интернета

Кодирование информации о сети в межсетевом адресе имеет ряд
недостатков. Самым очевидным недостатком является то, что адреса
описывают соединения, а не ГВМ:

Если ГВМ перемещается из одной сети в другую, его IP-адрес
должен измениться.

Чтобы понять этот вывод, давайте рассмотрим путешественников,
который хотели бы отсоединять свои персональные компьютеры, брать
их с собой в дорогу, а затем присоединять их к интернету после
прибытия в место назначения. Таким персональным компьютерам
нельзя назначить постоянный IP-адрес, так как IP-адрес
идентифицирует сеть, к которой присоединена эта машина.
Другим слабым местом межсетевой схемы адресации является то,
что когда число ГВМ в сетях класса С начинает превышать 255,
нужно изменить ее адрес на адрес класса В. Хотя это может
показаться незначительной проблемой, изменение сетевого адреса
может потребовать большого количества времени и быть
трудноотлаживаемым. Так как большая часть программного
обеспечения не предназначена для работы с несколькими адресами в
одной и той же физической сети, администраторы не могут
спланировать плавный переход, в течение которого они могли бы
медленно изменить адреса. Вместо этого, они должны сразу
запретить использование одного сетевого адреса, изменить адреса
всех машин, а затем возобновить взаимодействие, используя новые
сетевые адреса.
Самый главный недостаток в межсетевой схеме адресации не
будет полностью понятен, пока мы не рассмотрим маршрутизацию. Тем
не менее, его важность требует хотя бы краткого его описания. Мы
говорили, что маршрутизация основывается на межсетевых адресах,
причем для принятия решения о маршруте используется идентификатор
сети. Рассмотрим ГВМ, имеющий два соединения с интернетом. Мы
знаем, что такой ГВМ имеет более чем один IP-адрес. Тогда верно
следующее утверждение:

Так как маршрутизация использует сетевую часть IP-адреса,
путь, проходимый пакетами до ГВМ с несколькими IP-адресами,
зависит от используемого адреса.

Следствия этого утверждения удивительны. Люди думают, что
каждый ГВМ - это одна сущность, и хотят использовать одно имя.
Они часто удивляются, обнаружив, что у ГВМ есть более чем одно
имя, и еще более удивляются, открыв, что разные имена ведут себя
по-разному.
Другим удивительным следствием межсетевой схемы адресации
является то, что знания одного IP-адреса для ГВМ получателя может
оказаться недостаточно; может получиться так, что нельзя будет
достичь получается, используя этот адрес. Рассмотрим
демонстрационную сеть, показанную на рисунке 4.2. На этом рисунке
два ГВМ, А и В, оба присоединены к сети 1, и обычно
взаимодействуют между собой, используя эту сеть. Поэтому,
пользователи на ГВМ А обычно указывают ГВМ В, используя IP-адрес
I4. Существует другой путь от А к В через шлюз G, и он
используется всякий раз, когда А посылает пакеты IP-адресу I5.
Теперь предположим, что соединение В с сетью 1 вышло из строя, но
сама машина продолжает работать(например, оборвался кабель между
В и сетью 1). Пользователи на А, использующие IP-адрес I4, не
смогут достичь В, хотя пользователи, использующие адрес I5,
смогут это сделать. Эти проблемы с именованием и адресацией снова
возникнут в следующих главах, когда мы будем рассматривать
маршрутизацию и связывание имен.

сеть 1
---------------------------------------------------------
| I1 | I3 | I4
+++++ +++++ +++++
| G | | А | | В |
+++++ +++++ +++++
| I2 | I5
---------------------------------------------------------
сеть 2

Рисунок 4.2 Пример интернета с многоадресным ГВМ В, который
демонстрирует проблему со схемой адресации IP. Если интерфейс I4
отсоединится, А должен использовать адрес I5 для достижения В,
направляя пакеты к нему через шлюз G.

4.9 Точечная(dotted) десятичная нотация

Для удобства людей в технических документах или прикладных
программах IP-адреса пишутся как четыре десятичных числа,
разделенных десятичными точками, и каждое из этих чисел
представляет значение одного октета IP-адреса(точечная десятичная
нотация иногда называется точечной квадронотацией). Поэтому
32-битовый межсетевой адрес

10000000 00001010 00000010 00011110

записывается как

128.10.2.30

Мы будем использовать точечную десятичную нотацию при описании
IP-адресов на протяжении всей оставшейся части этой книги.

4.10 Адрес обратной связи(loopback)

Сетевой адрес класса А 127.0.0.0 зарезервирован для обратной
связи и введен для тестирования взаимодействия между процессами
на одной машине. Когда какая-либо программа использует адрес
обратной связи для передачи данных, протокольное программное
обеспечение в компьютере возвращает эти данные, ничего не посылая
по сети. В литературе четко сказано, что пакет, посланный в сеть
с адресом 127, не будет передаваться ни по какой сети. Более
того, ГВМ или шлюз никогда не должен распространять информацию о
маршрутах для сети с номером 127; этот адрес не является адресом
сети.

4.11 Список соглашений о специальных адресах

На практике IP использует лишь комбинации из нулей("этот")
или из всех единиц("все"). Рисунок 4.3 показывает все имеющиеся
случаи.

---------------------------------
| все нули | Этот ГВМ*
---------------------------------

---------------------------------
| все нули | ГВМ | ГВМ в этой сети*
---------------------------------

--------------------------------- Ограниченное
| все единицы | широковещание
--------------------------------- (локальная сеть)**

--------------------------------- Направленное
| сеть | все единицы | широковещание
--------------------------------- в сети**

---------------------------------
| 127 | все, что угодно | Обратная связь***
---------------------------------

Замечания:
* Разрешено только при загрузке системы и не
может быть адресом получателя
** Не может быть адресом отправителя
*** Никогда не будет передан в сеть

Рисунок 4.3 Специальные формы IP-адресов, включая допустимые
комбинации нулей("это") и единиц("все"). Длина сетевой части при
направленном широковещании зависит от класса сетевого адреса.

Как указано в замечаниях к рисунку, использование всех нулей
для сети допустимо только во время загрузки системы. Оно
временно позволяет машине взаимодействовать. Как только машина
узнала свой настоящий IP-адрес, она должна перестать использовать
сеть 0.

4.12 Ответственность за адресацию в Интернете

Чтобы быть уверенным в том, что сетевые части Интернетовских
адресов являются уникальными, все Интернетовские адреса
назначаются одним ведомством, Сетевым Информационным
Центром(NIC). Он назначает только сетевую часть адреса и
возлагает ответственность за назначение адресов ГВМ в этой сети
организации, запросившей этот адрес. Локальным сетям с небольшим
числом машин(меньшим чем 255) обычно назначается номера класса С,
так как ожидается появление большого числа локальных сетей.
Большим сетям, таким как ARPANET, назначаются номера класса А,
так как можно ожидать появления лишь небольшого числа больших
сетей.
При назначении IP-адресов сетям NICу важно лишь то, что эта
сеть или присоединена к объединенному Интернету, или собирается к
нему присоединиться. Какая-либо корпорация может взять на себя
ответственность за назначение уникальных сетевых адресов внутри
своего интернета TCP/IP, если она никогда не собирается соединять
свой интернет с внешним миром. На самом деле многие объединенные
группы, использующие протоколы TCP/IP, назначают межсетевые
адреса по своему усмотрению. Например, NIC назначил адрес
10.0.0.0 ARPANETу. Если какой-либо колледж решит использовать
протоколы TCP/IP в своем Ethernete, в состав которого входят лишь
три машины(и нет никаких шлюзов), он может выбрать адрес 10.0.0.0
для этой локальной сети. Тем не менее, как показывает опыт,
нежелательно создание частного интернета, использующего те же
самые сетевые адреса, что и объединенный Интернет, так как это
приведет к невозможности взаимной работы в будущем и может
вызвать проблемы при попытке обменяться программным обеспечением
с другими колледжами. Поэтому, всем, кто использует TCP/IP очень
выгодно потратить некоторое время и получить официальные
Интернетовские адреса у NICа.

4.13 Пример

Для уяснения схемы адресации в IP рассмотрим пример из
рисунка 4.4, который показывает несколько соединений и ГВМ,
соединенных с Интернетом, на факультете компьютерных наук
университета Пурдью в середине 80-х годов. Пример показывает три
сети: ARPANET(10.0.0.0), Ethernet(128.10.0.0) и маркерное кольцо
proNET-10(192.5.48.0). При написании этих адресов в двоичном виде
видно, что эти сети являются соответственно сетями класса А,В и
С.
На рисунке четыре ГВМ, присоединенные к этим сетям,
называются Arthur, Merlin, Guenevere и Lancelot. Машина Taliesyn
служит шлюзом между ARPANET и proNET-10, а машина Glatisant
служит шлюзом между proNET-10 и Ethernet. ГВМ Merlin имеет
соединения как с Ethernetом, так и с proNET-10, поэтому она может
взаимодействовать с ГВМ в обеих сетях напрямую. Хотя
многоадресный ГВМ, такой как Merlin, может также работать как
шлюз, Merlin является прежде всего системой с разделением времени
,и дополнительная работа по маршрутизации пакетов может уменьшить
вычислительную мощность, доступную пользователям. Поэтому,
был установлен выделенный шлюз, Glatisant, чтобы снять нагрузку
передачи траффика с системы с разделением времени. Траффик между
этими двумя сетями имел на самом деле гораздо больший объем, чем
предполагает эта конфигурация, так как здесь показаны далеко не
все имевшиеся ГВМ.

Ethernet 128.10.0.0
============================================================
| 128.10.2.3 | 128.10.2.8 | 128.10.2.70 | 128.10.2.26
------------- ------------- ------------- -------------
|Merlin | |Guenevere | |Glatisant | |Lancelot |
|(многоадр. | |(ГВМ | |(шлюз) | |(ГВМ |
| ГВМ) | | Ethernet)| | | | Ethernet)|
| | | | | | | |
------------- ------------- ------------- -------------
192.5.48.3 / 192.5.48.7
/ 10.2.0.37
++++++++++++++ / -------------
---------+ proNET-10 +---- |Taliesyn |
------------- + 192.5.48.0+----------- |(шлюз) |------>
|Arthur | ++++++++++++++ 192.5.48.6 | |
|(ГВМ | | | |
| proNET) |--------- -------------
| | 192.5.48.1 к ARPANET
------------- 10.0.0.0

Рисунок 4.4 Пример назначения IP-адресов для ГВМ и шлюзов в
Ethernetе, маркерном кольце и ARPANETе.

Рисунок 4.4 показывает IP-адреса для каждого сетевого
соединения. Lancelot, соединенный только с Ethernet, имеет адрес
128.10.2.26. Merlin имеет адрес 128.10.2.3 для соединения с
Ethernetом и 192.5.48.3 для соединения с proNET-10. Выбор
одинакового значения для младшего байта этих двух адресов
позволяет системным программистам легче запомнить все межсетевые
адреса Merlinа.

4.14 Порядок байт в сети

Чтобы создать интернет, независимый от архитектуры конкретной
машины или от сетевого оборудования, мы должны определить
стандартное представление данных. Посмотрим, что происходит,
когда одна машина посылает 32-битовое целое число другой машине.
Физическое оборудование передает последовательность бит от первой
машины ко второй, не меняя их порядка. Тем не менее, не все
машины хранят 32-битовые целые числа одинаково. В одних
(называемых "с наименьшего конца") младший адрес памяти содержит
самый младший байт целого числа. В других (называемых "с
наибольшего конца") младшая ячейка памяти хранит старший байт
числа. А некоторые все еще запоминают целые числа в группах
16-битовых слов, причем младшие адреса содержат младшее слово
числа, но байты в этих словах поменялись своими местами. Поэтому,
прямое копирование байт с одной машины на другую может изменить
значение числа.
Стандартизация порядка байт для целых чисел особенно важна
для интернета, так как межсетевые пакеты содержат двоичные числа,
указывающие такую информацию, как адрес назначения и длина
пакета. Такие числа должны пониматься как отправителем, так и
получателем. Протоколы TCP/IP решают проблему порядка байт,
определяя стандартный сетевой порядок байт, который должны
использовать все машины для двоичных полей в межсетевых пакетах.
Каждый ГВМ преобразует двоичные элементы из локального
представления в стандартный сетевой порядок перед передачей
пакета; он преобразует сетевой порядок байт в свой порядок при
приеме пакета. Естественно поле данных пользователя в пакете не
обрабатывается по этому стандарту - пользователи вольны
форматировать свои данные так, как они пожелают. Конечно,
большинство пользователей полагается на стандартные прикладные
программы и не сталкивается с проблемой порядка байт напрямую.
Межсетевой стандарт порядка байт определяет, что целые числа
посылаются таким образом, что самый старший(значимый) байт
передается первым(т.е. в стиле "с наибольшего конца"). Если
посмотреть на последовательность байт пакета тогда, когда он
передается от одной машины к другой, то у двоичного целого в этом
пакете самый старший байт находится ближе всего к началу пакета,
а самый младший байт находится ближе всего к концу пакета. Было
выдвинуто много аргументов в пользу использования того или иного
представления данных, и межсетевой стандарт до сих пор время от
времени подвергается критике. Тем не менее, все согласились с
тем, что такой стандарт необходим, и точная форма его не так уж и
важна.

4.15 Итоги

TCP/IP использует 32-битовые двоичные адреса в качестве
универсальных идентификаторов машин. Называемые межсетевыми или
IP-адресами, эти идентификаторы разделены на три основных класса,
и допускают существование сотни сетей с миллионами ГВМ в каждой,
тысяч сетей с тысячами ГВМ в каждой и свыше миллиона сетей с 254
ГВМ в каждой. Чтобы сделать эти адреса более легкими для
понимания людей, они записываются в точечной десятичной нотации,
в которой значения четырех октетов записываются в десятичном виде
и разделяются десятичными точками.
Так как IP-адреса кодируют как идентификацию сети, так и
идентификацию ГВМ в этой сети, эффективно реализуется
маршрутизация. Важным свойством IP-адресов является то, что они
обозначают сетевые соединения. ГВМ с несколькими соединениями
имеют несколько адресов. Одним из преимуществ межсетевой схемы
адресации является то, что одинаковая форма адреса может
использоваться для обозначения ГВМ, сетей и всех ГВМ в
сети(широковещания). Самый большой недостаток схемы адресации в
IP заключается в том, что если машина имеет несколько адресов,
знания одного адреса может оказаться недостаточно для
взаимодействия с ней, если некоторые сети выйдут из строя.
Для возможности обмена двоичными данными между машинами
протоколы TCP/IP устанавливают стандартный порядок байт для целых
чисел в полях пакета. Вообще ГВМ должен преобразовать все
двоичные данные из своего внутреннего формата в стандартный
сетевой порядок байт перед передачей пакета, а после приема
пакета должен наоборот преобразовать стандартный сетевой порядок
байт в свой внутренний.

 

Глава 5 Отображение адресов Интернета в физические
адреса(ARP)

5.1 Введение

Мы описали схему адресации TCP/IP, в которой каждому ГВМ
назначается 32-битовый адрес и сказали, что интернет ведет себя
как виртуальная сеть при использовании этих назначенных адресов
для посылки и приема пакетов. Мы также рассмотрели несколько
физических сетевых технологий и заметили, что две машины в данной
физической сети могут взаимодействовать только в том случае, если
каждая из них знает физический сетевой адрес другой машины. О чем
мы не упоминали, так это о том, как ГВМ или шлюз отображает
IP-адрес в корректный физический адрес, когда ему нужно послать
пакет по физической сети. Эта глава рассматривает это
отображение, показывая, как оно реализуется для двух самых
распространенных схем физических адресов.

5.2 Проблема разрешения адресов

Рассмотрим две машины А и В, которые присоединены к одной
физической сети. Каждая из них имеет назначенный IP-адрес Ia и
Ib, а также физический адрес Pa и Pb. Нашей целью является
разработка низкоуровневого программного обеспечения, которое
скрывало бы физические адреса и позволяло бы программам более
высокого уровня работать только с межсетевыми адресами. Тем не
менее, в конечном счете взаимодействие реализуется физическими
сетями, использующими какую-либо схему физических адресов.
Предположим, что машина А хочет послать пакет машине В по
физической сети, к которой они обе присоединены, но А знает
только межсетевой адрес Ib. Возникает вопрос: как может А
отобразить этот адрес в физический адрес Pb ?
Проблема отображения высокоуровневых адресов в физические
адреса известна как проблема разрешения адресов и решается
несколькими способами. Некоторые связки протоколов хранят на
каждой машине таблицы, содержащие пары высокоуровневых и
физических адресов. Другие решают проблему, кодируя аппаратные
адреса в высокоуровневых адресах. Использование только одного из
этих подходов в лучшем случае делает проблему высокоуровневой
адресации неудобной. Эта глава рассматривает две технологии для
разрешения адресов, используемые протоколами TCP/IP.

5.3 Два типа физических адресов

Существуют два основных типа физических адресов: характерным
представителем первого типа является Ethernet, использующий
большие, фиксированные физические адреса, а второго - proNET-10,
использующий маленькие легко изменяемые физические адреса.
Разрешение адресов трудно для сетей типа Ethernetа, но легко для
сетей типа proNET-10. Мы рассмотрим первым легкий случай.

5.4 Разрешение с помощью прямого отображения

Рассмотрим сеть с маркерным кольцом proNET-10. Как вы
помните, из главы 2 мы знаем, что она использует небольшие целые
числа в качестве физических адресов и позволяет пользователю
выбрать аппаратный адрес при установке платы интерфейса в
компьютер. Главной причиной, делающей разрешение адресов легким
для сети proNET-10, является то, что раз можно назначать как
IP-адреса, так и физические адреса, то можно выбрать их такими,
что их части будут совпадать. Обычно при назначении IP-адресов
поле идГВМ делается равным 1,2,3 и т.д., а затем при установке
сетевого интерфейсного оборудования выбирается физический адрес,
совпадающий с полем идГВМ в IP-адресе. Например, можно выбрать
физический адрес 3 для машины, имеющей IP-адрес 192.5.48.3, так
как 192.5.48.3 является адресом класса С, у которого поле идГВМ
равно 3.
Для сетей, таких как proNET-10, вычисление физического адреса
на основе IP-адреса тривиально. Вычисление состоит из выделения
полу идентификатора ГВМ из IP-адреса. Это вычислительно
эффективно, так как требует выполнения нескольких машинных
команд. Это легко осуществить, так как может быть выполнено без
обращения к внешним данным. И ,наконец, новые машины могут быть
добавлены к сети без изменения данных или перекомпиляции кода.
Концептуально выбор схемы нумерации, делающей разрешение
адресов эффективным, означает выбор функции F, которая отображает
IP-адреса в физические адреса. Разработчик может также выбрать
схему нумерации физических адресов. Разрешение IP-адреса Ia
означает вычисление

Pa=F(Ia)

Мы хотим, чтобы вычисление F было эффективным. Если множество
физических адресов ограничено, можно по-другому эффективно
сделать это отображение. Например, при использовании X.25 нельзя
выбрать физические адреса. Обычно, шлюзы в сетях X.25 хранят пары
IP-адресов и физических адресов X.25 в таблице и осуществляют
поиск в этой таблице при разрешении IP-адресов. Чтобы сделать
разрешение адресов эффективным в таких случаях, программное
обеспечение может использовать хэш-функцию для поиска в таблице.
Упражнение 5.1 предлагает еще один подход.

5.5 Разрешение с помощью динамического связывания

Чтобы понять, почему разрешение адресов так трудно в
некоторых сетях, рассмотрим технологию Ethernetа. Как вы знаете
из главы 2, Ethernet имеет 48-битовые физические адреса,
назначаемые производителями при изготовлении интерфейсных плат.
Как следствие, при выходе оборудования из строя и замене
интерфейсной платы физический адрес машины меняется. Более того,
так как адрес в Ethernetе имеет длину 48 бит, не стоит и
рассчитывать, что его можно закодировать в 32-битном IP-адресе.
Разработчики протоколов TCP/IP нашли конструктивное решение
проблемы разрешения адресов для сетей, таких как Chaosnet или
Ethernet, которые имеют возможность широковещания. Это решение
позволяет добавлять машины к сети без перекомпиляции кода и без
создания центральной базы данных. Чтобы избежать создания таблиц
отображения разработчики решили использовать низкоуровневый
протокол для динамической связки адресов. Названный Протокол
Разрешения Адресов(ARP), он обеспечивает механизм, который
является как эффективным, так и легким для реализации.
Как показывает рисунок 5.1 , идея, лежащая в основе
динамического разрешения в ARP, проста: когда ГВМ А хочет
разрешить IP-адрес Ib, он широковещательно распространяет
специальный пакет, который просит ГВМ с IP-адресом Ib ответить
ему, указав свой физический адрес Pb. Все ГВМ, включая В,
получают этот запрос, но только ГВМ В узнает свой IP-адрес и
посылает ответ, содержащий свой физический адрес. Когда А
получает ответ, он использует физический адрес для посылки
межсетевого пакета прямо к В. Итоги всего вышесказанного можно
изложить так:

Протокол Разрешения Адресов,ARP, позволяет ГВМ установить
физический адрес ГВМ назначения в той же самой физической сети,
имея только IP-адрес назначения.

<---|---------------------------------------->
===============|==========|==========|====================
| | | | | | |
| V | V | V |
----- ----- ----- -----
| А | | X | | B | | Y |
| | | | | | | |
----- ----- ----- -----

(а)

---------------------
======|===================|===============================
| | | | | |
| V | | | |
----- ----- ----- -----
| А | | X | | B | | Y |
| | | | | | | |
----- ----- ----- -----

(б)

Рисунок 5.1 Протокол ARP. Чтобы определить физический адрес
В, Pb, по его IP-адресу, Ib, (а) ГВМ А широковещательно
распространяет запрос ARP, содержащий Ib, по всем машинам, и (б)
ГВМ В отвечает на него ответом ARP, содержащим пару (Ib,Pb).

5.6 Кэш разрешения адресов

Может показаться глупым то, что А, посылая пакет к В, сначала
посылает широковещательный пакет, который достигает В. Или может
показаться еще глупее, что А широковещательно задает вопрос:"Как
я могу связаться с вами?" вместо того, чтобы просто
широковещательно послать пакет, который он хочет передать. Но
есть важная причина для таких передач. Широковещание слишком
дорого, чтобы использовать его всякий раз, когда одной машине
требуется передать пакет другой машине, так как оно требует от
каждой машины в сети обработки широковещательного пакета. Чтобы
уменьшить затраты на взаимодействие, ГВМ, использующие ARP,
создают кэш недавно узнанных связок между физическим адресом и
IP-адресом, и поэтому они не должны повторно использовать ARP.
Всякий раз, когда ГВМ получает ответ ARP, он сохраняет IP-адрес
машины и соответствующий ему аппаратный адрес в своем кэше для
последующих обращений. При передаче пакета ГВМ ищет связку в кэше
перед тем, как послать запрос ARP. Если ГВМ нашел нужную связку в
своем кэше, ему не надо передавать широковещательный пакет в
сеть. Опыт показывает, что так как большинство сетевых
взаимодействий включает передачу более чем одного пакета, даже
небольшой кэш будет полезен.

5.7 Уточнение ARP

Можно сделать несколько уточнений ARP. Во-первых, заметим,
что если ГВМ А использует ARP, так как ему нужно послать запрос к
В, то существует большая вероятность того, что ГВМ В в ближайшем
будущем тоже потребуется послать пакеты к А. Если мы учтем
потребности В, мы можем избежать передачи лишнего траффика по
сети, заставив А включить связку своего IP-адреса с физическим в
пакет при посылке запроса к В. Во-вторых, отметим, что так как А
широковещательно передает свой начальный запрос, все машины в
сети получают его и могут выделить и сохранить в своих кэшах
связку между IP-адресом и физическим адресом для А. В-третьих,
когда новая машина появляется в сети(например, когда загружается
операционная система), мы можем избежать того, что какая-либо
другая машина будет запускать ARP, если широковещательно
распространим пару IP-адреса и физического адреса новой машины.
Следующее правило обобщает уточнения:

ARP - это низкоуровневый протокол, который скрывает базовую
физическую сетевую адресацию, позволяя назначать IP-адреса по
нашему выбору каждой машине. Мы будем думать о нем как о части
физической сетевой системы, а не как о части межсетевых
протоколов.

5.9 Реализация ARP

Функционально ARP состоит из двух частей. Одна часть
определяет физические адреса при посылке пакета, а другая
отвечает на запросы от других машин. Разрешение адресов для
выходящих пакетов кажется элементарным, но некоторые детали
усложняют реализацию. Получив IP-адрес назначения, ГВМ
просматривает кэш ARP, чтобы проверить, не знает ли он уже
физического адреса для этого IP-адреса. Если ГВМ знает его, он
выделяет физический адрес, помещает данные в кадр, используя этот
адрес, и посылает этот кадр. Если же он не знает отображения, он
должен широковещательно передать запрос ARP и ждать ответа.
Широковещание запроса ARP для нахождения отображения адреса
может оказаться сложным. Машина получателя может быть выключена
или быть слишком занята, чтобы принять запрос. Если такое
случится, отправитель может не получить ответа или ответ может
задержаться. Так как Ethernet является системой с
негарантированной доставкой, то исходный широковещательный запрос
ARP тоже может быть потерян(в этом случае отправитель должен
будет повторно отправлять его по крайней мере еще один раз).
Между тем ГВМ должен хранить исходный передаваемый пакет, чтобы
его можно было послать, когда будет разрешен адрес(если задержка
становится значительной, ГВМ может уничтожить передаваемый
пакет). Фактически, ГВМ должен решить, можно ли работать другим
прикладным программам, пока он обрабатывает запрос
ARP(в большинстве случаев можно). Если можно, то он должен
учитывать случай, когда приложение будет генерировать
дополнительные запросы ARP для того же адреса, не посылая
широковещательный запрос несколько раз для одного и того же
получателя.
Наконец, рассмотрим случай, когда машина А получила связку
для машины В, но оборудование В вышло из строя и было заменено.
Хотя адрес В изменился, не изменилась связка в кэше А, поэтому А
будет использовать несуществующий аппаратный адрес, делая
успешный прием невозможным. Этот случай показывает, почему важно,
чтобы программное обеспечение ARP рассматривало свою таблицу
связок как кэш и удаляло ее элементы по истечении фиксированного
промежутка времени. Конечно, таймер для каждого элемента кэша
должен сбрасываться всякий раз, когда принимается широковещание
ARP, содержащее эту связку(но не сбрасывается, когда этот
элемент, используется для посылки пакета).
Вторая часть кода ARP обрабатывает пакеты ARP, прибывающие из
сети. Когда появляется пакет ARP, это программное обеспечение
должно выделить пару IP-адреса и аппаратного адреса отправителя,
и проверить свой кэш на наличие в нем элемента для этого
отправителя. Если в кэше есть элемент для указанного IP-адреса,
обработчик обновит этот элемент, заменив физический адрес тем,
что получен из пакета. Получатель затем обрабатывает оставшуюся
часть пакета ARP.
Получатель должен обрабатывать два типа входящих пакетов ARP.
Если входящий пакет ARP - запрос, принимающая машина должна
проверить, не является ли она назначением для этого запроса(т.е.
какая-то другая машина широковещательно выдала запрос о
физическом адресе приемника). Если это так, то программное
обеспечение ARP формирует ответ, указывая в нем свой физический
адрес, и посылает ответ прямо тому, кто запрашивал. Получатель
также добавляет пару адресов отправителя к своему кэшу, если там
нет такой пары. если IP-адрес, указанный в запросе ARP, не
совпадает с локальным адресом IP, то этот пакет является запросом
на отображение между адресами для какой-то другой машины в сети и
может игнорироваться.
Другой интересный случай возникает, когда приходит ответ ARP.
В зависимости от реализации обработчику может понадобиться
создание элемента кэша или такой элемент может уже существовать.
В любом случае, как только кэш был обновлен, получатель пытается
сопоставить ответ ранее выданному запросу. Обычно ответу
соответствует запрос, сгенерированный в связи с тем, что машина
имеет пакет, который нужно доставить. В промежуток времени между
широковещательной передачей ARP-запроса и получением ответа
прикладные программы или высокоуровневые протоколы могли
сгенерировать дополнительные запросы для этого адреса;
программное обеспечение должно помнить, что оно уже послало
запрос и не посылать его больше. Обычно, оно помещает
дополнительные запросы в очередь. Как только пришел ответ и
физический адрес стал известен, программное обеспечение ARP
удаляет элементы из очереди и отвечает на каждый из них
полученной связкой. Если машина не выдавала запрос для IP-адреса,
указанного в ответе, она прекращает обработку этого пакета.

5.10 Инкапсуляция и идентификация ARP

Когда сообщения ARP пересылаются от одной машины к другой,
они должны передаваться в физических кадрах. Рисунок 5.2
показывает, что сообщение ARP передается как поле данных кадра.

 

-------------------------------------
| сообщение ARP |
-------------------------------------
| |
V V
-----------------------------------------------------------
| заголовок кадра | поле данных кадра |
-----------------------------------------------------------

Рисунок 5.2 Сообщение ARP, заключенное в кадре физической
сети

Чтобы идентифицировать, что кадр содержит запрос или ответ
ARP, отправитель присваивает специальное значение полю типа в
заголовке кадра и помещает сообщение ARP в поле данных кадра.
Когда кадр прибывает на ГВМ, система смотрит тип кадра, чтобы
определить его содержимое. Например, в Ethernete, кадры, несущие
сообщения ARP, имеют в поле типа значение 0806 в
шестнадцатиричном формате. Это стандартное значение, назначенное
ведомством, устанавливающим стандарты Ethernetа.

5.11 Формат протокола ARP

В отличие от большинства протоколов, данные в пакетах ARP не
имеют фиксированного формата заголовка. Вместо этого его
сообщения были разработаны так, чтобы их можно было использовать
для различных сетевых технологий. Поэтому, первые поля заголовка
содержат счетчики, которые указывают длину следующих полей.
Фактически, ARP можно использовать с произвольными физическими
адресами и произвольными протокольными адресами. Пример на
рисунке 5.3 показывает 28-октетный формат сообщения ARP,
используемый для оборудования Ethernetа(у которого физические
адреса являются 48-битовыми или 6-октетными) при разрешении
протокольных адресов IP(имеющих длину 4 октета).
Рисунок 5.3 показывает сообщение ARP по 4 байта в строке, в
формате, который будет стандартным на протяжении всей книги. К
сожалению, в отличие от большинства остальных протоколов, поля
переменной длины в пакетах ARP не выровнены на границу 32 бит,
что приводит к трудности восприятия диаграммы. Например,
аппаратный адрес отправителя, помеченный как ОТПРАВИТЕЛЬ АА,
занимает 6 непрерывных октетов, что приводит к появлению его на
двух строках диаграммы.

0 8 16 24 31
-----------------------------------------------------------
| ТИП ОБОРУДОВАНИЯ | ТИП ПРОТОКОЛА |
-----------------------------------------------------------
| HLEN | PLEN | ОПЕРАЦИЯ |
-----------------------------------------------------------
| ОТПРАВИТЕЛЬ АА (октеты 0-3) |
-----------------------------------------------------------
|ОТПРАВИТЕЛЬ АА(октеты 4-5)|ОТПРАВИТЕЛЬ IP(октеты 0-1) |
-----------------------------------------------------------
|ОТПРАВИТЕЛЬ IP(октеты 2-3)|ПОЛУЧАТЕЛЬ АА(октеты 0-1) |
-----------------------------------------------------------
| ПОЛУЧАТЕЛЬ АА(октеты 2-5) |
-----------------------------------------------------------
| ПОЛУЧАТЕЛЬ IP(октеты 0-3) |
-----------------------------------------------------------

Рисунок 5.3 Пример формата сообщения ARP/RARP для разрешения
адресов IP-Ethernet. Длины полей зависят от длин аппаратных и
протокольных адресов, которые имеют значение соответственно 6
октетов для адреса Ethernetа и 4 октета для IP-адреса.

Поле ТИП ОБОРУДОВАНИЯ определяет тип аппаратного интерфейса,
для которого отправитель ищет ответ; оно содержит значение 1 для
Ethernetа. Аналогичным образом, поле ТИП ПРОТОКОЛА указывает тип
адреса протокола более высокого уровня, который использует
отправитель; оно содержит 0800 в шестнадцатиричном формате для
IP-адреса. Поле ОПЕРАЦИЯ указывает запрос ARP(1), ответ ARP(2),
запрос RARP(3), или ответ RARP(4)(RARP, другой протокол,
использующий тот же самый формат сообщения, будет рассмотрен в
следующей главе). Поля HLEN и PLEN позволяют использовать ARP в
любых сетях, так как они указывают длину аппаратного адреса и
адреса протокола верхнего уровня. Отправитель передает свой
аппаратный адрес и IP-адрес, если они известны ему, в полях
ОТПРАВИТЕЛЬ АА и ОТПРАВИТЕЛЬ IP.
При посылке запроса отправитель также указывает IP-адреса
назначения(ARP) или аппаратного адреса назначения(RARP),
используя поля ПОЛУЧАТЕЛЬ АА и ПОЛУЧАТЕЛЬ IP. Отвечающая машина
перед передачей ответа заполняет отсутствующие адреса, меняет
местами пары отправителя и получателя и меняет код операции на
ответ. Поэтому ответ содержит IP- и аппаратный адреса исходного
отправителя, а также IP- и аппаратный адреса машины, которая
разрешила эту связку.

5.12 Итоги

IP-адреса назначаются независимо от физического аппаратного
адреса машины. Чтобы доставить межсетевой пакет, сетевое
программное обеспечение должно отобразить IP-адрес в физический
аппаратный адрес и использовать этот аппаратный адрес для
передачи кадра. Если аппаратные адреса являются небольшими
числами, которые могут быть легко изменены, можно реализовать
прямое отображение, закодировав физические адреса машин в их
IP-адресах. Иначе, отображение должно выполняться динамически.
Протокол Разрешения Адресов(ARP) выполняет динамическое
разрешение адресов, используя только низкоуровневую сетевую
коммуникационную систему. ARP позволяет машинам разрешать адреса,
не храня постоянно информации о связках адресов.
Машина использует ARP, чтобы найти аппаратный адрес другой
машины с помощью широковещания запроса ARP. Запрос содержит
IP-адрес машины, для которой нужно узнать аппаратный адрес.
Каждая машина отвечает на запросы, соответствующие ее IP-адресу,
посылая ответы, содержащие требуемый аппаратный адрес.
Чтобы сделать ARP эффективным, каждая машина кэширует связки
(IP-адрес;аппаратный адрес). Так как межсетевой траффик имеет
тенденцию состоять из последовательности взаимодействий между
парами машин, кэш приводит к ненужности большинства
широковещательных запросов ARP.

 

 

Глава 6 Определение межсетевого адреса при начальной
загрузке(RARP)

6.1 Введение

Мы уже знаем, что физические сетевые адреса являются как
низкоуровневыми, так и аппаратно зависимыми, и мы знаем, что
каждой машине, использующей TCP/IP, назначен один или несколько
32-битовых IP-адресов, которые независимы от аппаратных адресов
машины. прикладные программы всегда используют IP-адрес при
указании назначения. ГВМ и шлюзы должны использовать физические
адреса для передачи дейтаграмм по базовым сетям; они полагаются
на схемы разрешения адресов, такие как ARP, при выполнении
связывания.
Обычно IP-адрес машины хранится во внешней памяти, откуда
операционная система и берет его при начальной загрузке.
Возникает вопрос: "Как бездисковая машина, не имея доступа к
внешней памяти, определяет свой IP-адрес?" Эта проблема является
критической для бездисковых станций, использующих IP-адрес для
взаимодействия с файл-сервером. Более того, так как много
бездисковых машин используют стандартные протоколы передачи
файлов TCP/IP для получения начального образа при загрузке, они
должны получать и использовать IP-адреса до начала работы
операционной системы. Эта глава изучает вопрос о том, как
получить IP-адреса, и описывает протокол, который используют
бездисковые машины.
Чтобы одна программа могла использоваться на нескольких
машинах, в состав ее исполняемого образа не должен входить
IP-адрес машины. В частности, разработчики пытаются не включать
конкретные IP-адреса как в код начальной загрузки, так и в
операционную систему, чтобы один и тот же код мог работать на
нескольких машинах. Когда такая программа начинает выполняться на
бездисковой машине, она должна использовать сеть для
взаимодействия с сервером, чтобы получить от него свой IP-адрес.
Эта процедура кажется парадоксальной: машина взаимодействует с
удаленным сервером для получения адреса, необходимого для
взаимодействия.
Но парадокс здесь только кажущийся, так как машина знает, как
взаимодействовать. Она может использовать свой физический адрес
для взаимодействия в локальной сети. Поэтому машина должна
временно применять физическую сетевую адресацию аналогично тому,
как операционные системы применяют физическую адресацию памяти
при установке таблиц для виртуальной адресации. Как только машина
узнает свой межсетевой адрес, она может взаимодействовать со всем
интернетом.
Идея, лежащая в основе нахождения IP-адреса, проста:
бездисковая машина посылает запрос другой машине, называемой
сервером(глава 18 более детально описывает серверы), и ждет, пока
сервер не пошлет ответ. Мы будем предполагать, что сервер имеет
диск, на котором он хранит базу данных межсетевых адресов. В этом
запросе машина, которой нужно узнать свой межсетевой адрес,
должна идентифицировать себя уникальным образом, сервер мог найти
ее межсетевой адрес и послать ответ. Как посылающая запрос
машина, так и отвечающий ей сервер используют физические сетевые
адреса в ходе своего короткого взаимодействия. Но откуда
бездисковая машина знает физический адрес сервера ? Обычно она
его и не знает - она просто широковещательно передает запрос ко
всем машинам в локальной сети. Ей отвечают один или более
серверов.
Когда бездисковая машина широковещательно передает запрос,
она должна уникальным образом идентифицировать себя. Но какую
информацию можно включить в запрос, которая бы уникально
идентифицировала машину ? Для этой цели может подойти любая
уникальная аппаратная идентификация(например, последовательный
номер ЦП). Тем не менее, нам нужна идентификация, которую может
получить работающая программа. Наша цель - создать один
исполняемый код, который может выполняться на любом процессоре.
Более того, длина или формат информации, идентифицирующей ЦП,
могут отличаться у различных моделей процессоров, а нам хотелось
бы иметь сервер, который принимает запросы от всех машин в
физической сети, используя один формат.

6.2 Протокол обратного разрешения адресов(RARP)

Разработчики протоколов TCP/IP сообразили, что есть другая
уникально идентифицирующая информация, которая всегда доступна,
короче, физический сетевой адрес машины. Использование этого
физического адреса как уникальной идентификации имеет два
преимущества. Так как ГВМ получает свои физические адреса от
сетевого интерфейсного оборудования, такие адреса всегда
доступны и не входят в состав кода операционной системы. Так как
идентифицирующая информация зависит от сети, а не от модели ЦП,
все машины в сети будут поддерживать единообразные, уникальные
идентификаторы. Поэтому задача становится обратной по отношению к
разрешению адресов: имеется физический сетевой адрес; разработать
схему, которая позволяла бы серверу отображать его в межсетевой
адрес.
Бездисковая машина использует протокол интернета TCP/IP,
называемы RARP(протокол обратного разрешения адресов), для
получения своего IP-адреса от сервера. RARP создан на основе
протокола ARP из предыдущей главы и использует тот же самый
формат сообщений, который приведен на рисунке 5.3. На практике
сообщение RARP, посылаемое при запросе межсетевого адреса,
является несколько более общим, чем то, что описано выше: оно
позволяет машине запрашивать IP-адрес не только себе, но и другим
машинам. Оно также допускает несколько типов физических сетей.
Как и сообщение ARP, сообщение RARP пересылается с одной
машины на другую в поле данных кадра Ethernetа. Кадр Ethernetа,
несущий запрос RARP, имеет обычную преамбулу, адреса отправителя
и получателя Ethernetа, и поле типа пакета в начале себя. Поле
типа содержит значение 8035, что идентифицирует содержимое этого
кадра как сообщение RARP. Поле данных кадра содержит 28-октетное
сообщение RARP.
Рисунок 6.1 иллюстрирует, как ГВМ использует RARP.
Отправитель широковещательно передает запрос RARP, в котором
указывает свой адрес в качестве как машины отправителя, так и
машины получателя, заполняя поле аппаратного адреса назначения
своим физическим сетевым адресом. Все машины в сети принимают
запрос, но только те из них, кто отвечает за поддержку RARP,
обрабатывают запрос и посылают ответ; такие машины называют
серверами RARP. Для успешного использования RARP в сети должен
быть по крайней мере один сервер RARP.

-<==-===============================================>--------
^ | | |
| V V V
+++++++ +++++++ +++++++ +++++++
+ А + + B + + C + + D +
+++++++ +++++++ +++++++ +++++++

(a)

-----=========================================---------------
| | ^ ^
V | | |
+++++++ +++++++ +++++++ +++++++
+ А + + B + + C + + D +
+++++++ +++++++ +++++++ +++++++

(

Рисунок 6.1 Пример обмена, используя протокол RARP. (a)
Машина А посылает широковещательный запрос RARP, указывая себя
как машину получателя, и ( машины, ответственные за поддержку
средства RARP(C и D), отвечают прямо А.

Серверы отвечают на запросы, заполняя поля протокольного
адреса назначения, меняя тип сообщения на ответ, и посылая ответ
прямо машине, выдавшей запрос. Эта исходная машина принимает
ответы от всех серверов RARP, несмотря на то, что ей нужен только
первый ответ.
Помните, что все взаимодействия между машиной, ищущей свой
IP-адрес, и сервером, знающим его, должны осуществляться,
используя только одну физическую сеть. Более того, этот протокол
позволяет ГВМ запрашивать IP-адрес произвольной машины. Поэтому
отправитель указывает свой аппаратный адрес помимо аппаратного
адреса получателя, а сервер учитывает это при отправке ответа по
аппаратному адресу отправителя. В Ethernetе наличие поля для
аппаратного адреса отправителя может показаться лишним, так как
эта же информация содержится в заголовке кадра Ethernetа. Тем не
менее, не все оборудование Ethernetа позволяет операционной
системе получать доступ к заголовку физического кадра.

6.3 Повторение транзакций RARP

Как и любое взаимодействие в сети с негарантированной
доставкой, запросы RARP могут потеряться или исказиться. Так как
RARP использует физическую сеть напрямую, никакое другое
протокольное программное обеспечение не будет измерять время до
получения ответа или повторно передавать запрос; само программное
обеспечение RARP должно решать эти задачи. Вообще RARP
используется только для локальных сетей, таких как Ethernet, где
вероятность сбоя мала. Тем не менее, если сеть имеет только один
сервер RARP, то эта машина может не справиться с такой большой
нагрузкой, и ряд пакетов может быть потерян.
Многие бездисковые машины рассчитывают на RARP при загрузке и
могут повторять запрос до тех пор, пока они не получат ответа.
Другие реализации сообщают, что обнаружена неисправность в сети
после нескольких неудачных попыток, чтобы избежать переполнения
сети ненужным широковещательным траффиком(т.е. в случае, когда
сервер недоступен). В Ethernetе сетевая ошибка менее вероятна,
чем перегрузка сервера . Заставляя программное обеспечение RARP
часто повторять запрос, можно добиться того, что сервер будет
буквально захлестнут волной избыточного траффика. В то же время
использование большого времени ожидания ответа гарантирует, что у
серверов будет достаточно времени для приема запроса и выдачи
ответа.

6.4 Основные и дублирующие серверы RARP.

Главным преимуществом использования группы машин как серверов
RARP является то, что это делает систему более надежной. Если
один сервер вышел из строя или перегружен и не может ответить,
другой ответит на запрос. Поэтому существует большая вероятность
того, что средство будет постоянно доступно. Главный же
недостаток использования нескольких серверов заключается в том,
что когда машина передает широковещательный запрос RARP, сеть
становится перегруженной из-за того, что все серверы пытаются на
него ответить. В Ethernetе, например, использование нескольких
серверов RARP приводит к высокой вероятности возникновения
коллизии.
Как разместить средство RARP так, чтобы оно было надежным и
доступным, и при этом не было бы нескольких одновременных
ответов? Существует по крайней мере две возможности, и обе они
используют паузы при ответе. В первом случае, каждой машине,
выдающей запросы RARP, назначается основной сервер. Обычно только
основной сервер машины отвечает на ее запросы RARP. Все
неосновные серверы принимают запрос, но лишь запоминают время его
поступления. Если основной сервер недоступен, пославшая запрос
машина будет ждать определенное время ответа, а затем повторно
пошлет запрос. А неосновной сервер, получив вторую копию запроса
RARP вскоре после первой, ответит на него.
Во втором случае используется аналогичная схема, но делается
попытка избежать одновременного ответа всеми неосновными
серверами. Каждая неосновная машина, принимающая запрос, выжидает
случайное время, а затем посылает ответ. При нормальных условиях
основной сервер отвечает сразу же, а последующие ответы будут
передаваться через некоторое время, поэтому их появление в одно и
то же время маловероятно. Когда основной сервер недоступен,
запрашивающая машина подбирает небольшое время для паузы перед
приемом ответа. При умелом подборе паузы разработчик может
добиться того, что запрашивающие машины не будут повторно
передавать широковещательного запроса до получения ответа.

6.5 Итоги

При загрузке системы бездисковая машина должна
связаться с сервером , чтобы определить свой IP-адрес перед тем,
как она начнет взаимодействие, используя TCP/IP. Мы рассмотрели
протокол RARP, который использует физическую сетевую адресацию
для получения межсетевого адреса машины. Механизм RARP применяет
физический аппаратный адрес машины для уникальной идентификации
процессора и широковещательной передачи запросов RARP. Серверы в
сети принимают сообщение, ищут отображение для него в
таблице(предварительно загруженной с диска), и отвечают
отправителю. Как только машина принимает свой IP-адрес, она
запоминает его в памяти и не использует RARP до тех пор, пока она
снова не будет загружать систему

 

 

Глава 7 Межсетевой протокол: доставка дейтаграмм без установления соединения

7.1 Введение

Мы уже рассмотрели части сетевого оборудования и программного
обеспечения, которые делают возможным межсетевое взаимодействие,
объяснили базовые сетевые технологии и разрешение адресов. Эта
глава рассматривает фундаментальный принцип доставки без
установления соединения и обсуждает, как он реализуется с помощью
Межсетевого протокола(IP), одного из двух основных протоколов,
используемых при межсетевом обмене. Мы изучим формат дейтаграмм
IP и увидим, как они образуют основу для всех видов межсетевого
взаимодействия. Следующие две главы продолжат изучение
Межсетевого Протокола, обсуждая вопросы маршрутизации дейтаграмм
и обработки ошибок.

7.2 Виртуальная сеть

Глава 3 рассмотрела межсетевую архитектуру, в которой
машины-шлюзы соединяют группу физических сетей. Знание
архитектуры может ввести в заблуждение, так как внимание следует
сосредоточить на интерфейсе, который предоставляет интернет
пользователям, а не на технологии взаимного соединения.

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

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

7.3 Архитектура Интернета и его философия

На концептуальном уровне интернет TCP/IP обеспечивает три
множества средств, как показано на рисунке 7.1; их расположение
на рисунке предполагает зависимости между ними. На самом нижнем
уровне, средство доставки без установления соединения
обеспечивает основу для всего остального. На следующем уровне
надежное транспортное средство обеспечивает платформу более
высокого уровня, от которую опираются приложения. Мы вскоре
освоим каждое из этих трех средств, поймем, что они обеспечивают,
и увидим, какие протоколы связаны с ними.

--------------------------------------------
| ПРИКЛАДНЫЕ СРЕДСТВА |
--------------------------------------------------
| НАДЕЖНОЕ ТРАНСПОРТНОЕ СРЕДСТВО |
--------------------------------------------------------
| СРЕДСТВО ДОСТАВКИ ПАКЕТОВ БЕЗ УСТАНОВЛЕНИЯ СОЕДИНЕНИЯ|
--------------------------------------------------------

Рисунок 7.1 Три концептуальные уровня межсетевых средств

7.4 Понятие ненадежной доставки

Хотя мы можем связать протокольное программное обеспечение с
каждым из средств на рисунке 7.1, причина выделения их как
концептуальных частей интернета состоит в том, что они ясно
указывают на философские предпосылки при разработке. Главное
заключается в том, что:

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

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

7.5 Система доставки без установления соединения

Самое фундаментальное межсетевое средство представляет собой
систему доставки пакетов. Технически это средство определено как
ненадежная система доставки пакетов без установления соединения,
аналогично средству, обеспечиваемому сетевым оборудованием,
которое работает по принципу негарантированной доставки. Это
средство называется ненадежным, так как доставка не
гарантируется. Пакеты могут быть потеряны, дублированы, задержаны
или доставлены не по порядку, но средство не обнаружит такие
ситуации, а также не сможет сообщить о них отправителю или
получателю. Это средство называется "без установления
соединения", так как каждый пакет обрабатывается независимо от
других пакетов. Последовательность пакетов, посылаемая от одной
машины к другой, может передаваться по различным путям, а
некоторые из них могут быть даже потеряны, в то время, как
остальные будут доставлены. Наконец, можно сказать, что средство
использует доставку в лучшем случае (best-effort delivery), так
как межсетевое программное обеспечение делает настоящую попытку
доставить пакет. То есть, интернет не удаляет пакеты по своему
желанию; ненадежность возникает только тогда, когда не хватает
ресурсов, или происходят сбои в используемых физических сетях.

7.6 Цель межсетевого протокола

Протокол, который определяет ненадежной доставки без
установления соединения, называется Межсетевым Протоколом, и
обычно обозначается своими инициалами, IP(аббревиатура IP привела
к появлению термина IP-адрес). IP обеспечивает определение трех
важных вещей. Во-первых, протокол IP определяет базовый элемент
передачи данных, используемый во всем интернете TCP/IP.
Во-вторых, программное обеспечение IP выполняет функцию
маршрутизации, выбора пути, по которому будут передаваться
данные. В-третьих, помимо точной, формальной спецификации
форматов данных и функции маршрутизации, IP включает набор
правил, которые воплощают в жизнь идею ненадежной доставки
пакетов. Эти правила указывают, как ГВМ и шлюзам следует
обрабатывать пакеты, как и когда следует генерировать сообщения
об ошибках, и условия, при которых можно удалять пакеты. IP
является такой фундаментальной частью, что интернет TCP/IP иногда
называют технологией на основе IP.
Мы начинаем рассмотрение IP в этой главе с обзора формата
пакета, описанного в нем. Маршрутизацию и обработку ошибок мы
рассмотрим в следующих главах.

7.7 Межсетевая дейтаграмма

Между физической сетью и интернетом TCP/IP существует много
аналогий. В физической сети единицей передачи является кадр,
который состоит из заголовка и данных, где заголовок содержит
информацию, такую как адреса отправителя и получателя. Интернет
называет свой базовый элемент передачи межсетевой
дейтаграммой(иногда ее называют IP-дейтаграммой или просто
дейтаграммой). Как и кадр физической сети, дейтаграмма делится на
поле заголовка и поле данных. Кроме того, как и кадр, заголовок
дейтаграммы содержит адреса отправителя и получателя, а также
поле типа, которое идентифицирует содержимое дейтаграммы. Ну, и
конечно, разница между ними состоит в том, что заголовок
дейтаграммы содержит IP-адреса, в то время как заголовок кадра -
физические адреса. Рисунок 7.2 показывает общую форму
дейтаграммы:

-----------------------------------------------------------
| ЗАГОЛОВОК | ОБЛАСТЬ ДАННЫХ |
| ДЕЙТАГРАММЫ | ДЕЙТАГРАММЫ |
-----------------------------------------------------------

Рисунок 7.2 Общая форма IP-дейтаграммы, аналогии сетевому
кадру в TCP/IP. IP специфицирует формат заголовка, включая
IP-адреса источника и назначения. IP не описывает формат области
данных; она может быть использована для транспортировки
произвольных данных.

7.7.1 Формат дейтаграммы

Теперь, после того, как мы описали общий формат
IP-дейтаграммы, можно рассмотреть ее содержимое более детально.
Рисунок 7.3 показывает расположение полей дейтаграммы:

0 4 8 16 19 24 31
------------------------------------------------------------
|версия|длина| тип сервиса | общая длина |
------------------------------------------------------------
| идентификация |флаги |смещение фрагмента |
------------------------------------------------------------
|время жизни | протокол | КС заголовка |
------------------------------------------------------------
| IP-адрес отправителя |
------------------------------------------------------------
| IP-адрес получателя |
------------------------------------------------------------
| Опции IP(если есть) |заполнение |
------------------------------------------------------------
| Данные |
------------------------------------------------------------
| ... |
------------------------------------------------------------

Рисунок 7.3 Формат дейтаграммы Интернета, основного элемента
передачи в интернете TCP/IP.

Так как обработка дейтаграммы происходит с помощью
программного обеспечения, оборудование не накладывает никаких
ограничений на ее содержимое и формат. Например, первое 4-битовое
поле в дейтаграмме(ВЕРСИЯ) содержит версию протокола IP ,
используемую при создании дейтаграммы. Оно используется
отправителем, получателем, и всеми шлюзами между ними для
уверенности в том, что все они используют один и тот же формат
дейтаграммы. Всему программному обеспечению IP требуется
проверять поле версии перед обработкой дейтаграммы, чтобы быть
уверенным в том, что ее формат соответствует тому формату,
который ожидает это обеспечение. Если стандарт меняется, машины
будут отбрасывать дейтаграммы с версией протокола, отличающейся
от версии, на которой они работают, предохраняя себя от
неправильной интерпретации содержимого дейтаграммы из-за
устаревшего формата. Текущая версия протокола IP - 4.
Поле длины заголовка(ДЛИНА) также занимает 4 бита и хранит
длину заголовка дейтаграммы в 32-битных словах. Как мы увидим,
все поля в заголовке имеют фиксированную длину, за исключением
поля ОПЦИИ IP и соответствующего ему поля ЗАПОЛНЕНИЕ. Наиболее
простой заголовок, без опций и заполнения, занимает 20 октетов

 

Глава 8 Межсетевой протокол: маршрутизация IP-дейтаграмм

8.1 Введение

Мы уже видели, что все межсетевые средства строятся на основе
ненадежной системы доставки пакетов без установления соединения,
и что базовой единицей передачи в интернете TCP/IP является
IP-дейтаграмма. Эта глава добавляет к описанию средства без
установления соединения описание того, как шлюзы маршрутизируют
IP-дейтаграммы и доставляют их к месту назначения. Можно сказать,
что формат дейтаграммы из главы 7 характеризует статические
аспекты Межсетевого Протокола. Описание маршрутизации в этой
главе характеризует его операционные аспекты. Следующая глава
завершит рассмотрение нами IP описанием того, как обрабатываются
ошибки; последующие главы покажут, как другие протоколы
используют его для реализации средств более высокого уровня.

8.2 Маршрутизация в Интернете

В системе с коммутацией пакетов маршрутизация обозначает
процесс выбора пути, по которому будут посылаться пакеты, а
маршрутизатором называется компьютер, производящий этот выбор.
Маршрутизация происходит на нескольких уровнях. Например, в
глобальной сети, имеющей по несколько физических соединений между
коммутаторами пакетов, сеть сама отвечает за маршрутизацию
пакетов с того времени, как они попали в нее, и до тех пор, пока
они не покинут ее. Такая внутренняя маршрутизация происходит
полностью внутри этой глобальной сети. Машины за ее пределами
не могут участвовать в принятии решений; для них эта сеть
представляется единым целым, которое доставляет пакеты.
Напомним, что целью TCP/IP является обеспечить виртуальную
сеть, предоставляющую средство доставки IP-дейтаграмм без
установления соединения. Поэтому, мы сосредоточим на внимание на
межсетевой маршрутизации или IP-маршрутизации. Как и
маршрутизация внутри физической сети, IP-маршрутизация выбирает
путь, по которому следует послать дейтаграмму. Алгоритм
IP-маршрутизации должен определить, как послать дейтаграмму через
несколько физических сетей.
Маршрутизация в интернете может быть сложной, особенно между
машинами с несколькими физическими сетевыми соединениями. В
идеале программное обеспечение маршрутизации должно учитывать
такие вещи, как загрузка сети, длина дейтаграммы, или тип
сервиса, указанный в заголовке дейтаграммы, при выборе наилучшего
пути. Тем не менее, большинство программного обеспечения
межсетевой маршрутизации гораздо менее сложное, и выбирает пути
на основе фиксированных предположений о самых коротких путях.
Чтобы полностью понять IP-маршрутизацию, мы должны вернуться
назад и вспомнить архитектуру интернета TCP/IP. Во-первых,
напомним, что интернет состоит из группы физических сетей,
соединенных компьютерами, называемыми шлюзами. Каждый шлюз имеет
прямое соединение с двумя или более сетями. В отличие от шлюза,
ГВМ обычно соединен напрямую только с одной физической сетью. Тем
не менее, мы знаем, что возможно существование многоадресных ГВМ,
которые соединены напрямую с несколькими сетями.
Как ГВМ, так и шлюзы участвуют в IP-маршрутизации. Когда
прикладная программа на ГВМ пытается организовать взаимодействие,
протоколы TCP/IP в конечном счете генерируют одну или несколько
IP-дейтаграмм. ГВМ должен принять решение о маршруте, когда он
выбирает, куда послать дейтаграмму. Как показывает рисунок 8.1,
ГВМ должны принять решение, даже если они имеют только одно
соединение с сетью.

 

^ к одним ^ к другим
| ГВМ | ГВМ
----- -----
| Ш1| | Ш2|
----- -----
| |
--------------------------------------------------------
|
-----
|ГВМ|
-----

Рисунок 8.1 Пример одноадресного ГВМ, который должен
маршрутизировать дейтаграммы. Он должен выбрать, послать ли
дейтаграмму шлюзу Ш1 или шлюзу Ш2, так как нет одного шлюза,
обеспечивающего наилучший путь ко всем назначениям.

Конечно, шлюзы должны принимать решения об IP-маршрутизации
(это их основная задача и причина того, что их назвали
маршрутизаторами). А как же многоадресные ГВМ ? Любой компьютер с
несколькими сетевыми соединениями может выступать в роли шлюза, и
как мы увидим позже, многоадресные ГВМ с сетевым программным
обеспечением TCP/IP имеют все необходимое для маршрутизации.
Более того, локальные сети, в которых нет возможности выделить
отдельные компьютеры под шлюз, часто используют компьютеры
общего назначения с разделением времени в роли как ГВМ, так и
шлюза ( эта практика особенно распространена в университетах).
Тем не менее, стандарты TCP/IP делают различие между этими
функциями в ГВМ и шлюзе, а в сетях, пытающихся смешивать функции
ГВМ и шлюза в одной машине, иногда обнаруживается, что
многоадресные шлюзы участвуют в неожиданных взаимодействиях. А
пока, мы будем различать ГВМ и шлюзы, и предполагать, что ГВМ не
реализуют функцию шлюза по передаче пакетов из одной сети в
другую.

8.3 Прямая и косвенная доставка

Говоря нестрого, мы можем выделить две формы маршрутизации:
прямую маршрутизацию и косвенную маршрутизацию. Прямая
маршрутизация, передача дейтаграммы напрямую из одной машины в
другую, является основой, на которой строится все остальное
межсетевое взаимодействие. Две машины могут участвовать в прямой
маршрутизации только в том случае, когда они обе соединены
напрямую с одной физической системой передачи(например,
Ethernetом). Косвенная маршрутизация осуществляется, когда
назначение не находится в той же сети, что и источник, и
заставляет отправителя передавать дейтаграмму шлюзу для доставки.

8.3.1 Доставка дейтаграммы по одной сети

Мы знаем, что одна машина в данной физической сети может
послать физический кадр напрямую другой машине в этой же сети.
Для передачи IP-дейтаграмм отправитель инкапсулирует дейтаграмму
в физический кадр, отображает IP-адрес назначения в физический
адрес, и использует сетевое оборудование для его доставки. Глава
5 представила два возможных механизма при разрешении адресов,
включая использование протокола ARP для динамического связывания
пар адресов в Ethernet-подобных сетях. Глава 7 рассмотрела
инкапсуляцию дейтаграмм. Поэтому мы знаем теперь все необходимое
для понимания прямой доставки. Обобщим:

Передача IP-дейтаграмм между двумя машинами в одной
физической сети не использует шлюзы. Отправитель инкапсулирует
дейтаграмму в физический кадр, связывает IP-адрес назначения с
физическим аппаратным адресом и посылает полученный кадр прямо
назначению.

Откуда отправитель узнает, что получатель находится в сети, к
которой он присоединен ? Ответ прост. Мы знаем, что IP-адреса
делятся на номер сети и номер ГВМ в сети. Чтобы определить,
находится ли назначение в одной из сетей, к которым он
присоединен, отправитель выделяет сетевую часть IP-адреса
назначения и сравнивает ее с сетевой частью своего IP-адреса(ов).
Совпадение означает, что дейтаграмму можно послать напрямую.
Здесь мы видим одно из преимуществ схемы адресации Интернета, а
именно:

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

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

8.3.2 Косвенная маршрутизация

Косвенная маршрутизация более трудна, чем прямая , так как
отправитель должен идентифицировать шлюз, которому можно послать
дейтаграмму. Шлюз должен затем отправить дейтаграмму к сети
назначения.
Для визуализации того, как работает косвенная маршрутизация,
представим себе большой интернет со множеством сетей, соединенных
шлюзами, но имеющий лишь две ГВМ на самых дальних концах. Когда
одна ГВМ хочет что-то послать другой, она инкапсулирует
дейтаграмму и посылает ее к ближайшему шлюзу. Мы знаем, что она
может достичь шлюза, так как все физические сети связаны друг с
другом, поэтому для каждой сети должен существовать шлюз,
присоединенный к ней. Поэтому, ГВМ, отправляющий дейтаграмму,
может достичь шлюза, используя одну физическую сеть. Как только
кадр достигает шлюза, программное обеспечение выделяет
инкапсулированную в нем дейтаграмму, процедуры IP-маршрутизации
выбирают следующий шлюз на пути к назначению. Дейтаграмма снова
помещается в кадр и посылается по следующей физической сети ко
второму шлюзу, и так далее, до тех пор, пока она не сможет быть
доставлена напрямую. Эти идеи можно обобщить:

Шлюзы в интернете TCP/IP образуют взаимодействующую и
связанную структуру. Дейтаграммы передаются от шлюза к шлюзу до
тех пор, пока они не достигнут шлюза, который может доставить
дейтаграмму напрямую.

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

8.4 IP-маршрутизация на основе таблиц.

Обычный алгоритм IP-маршрутизации работает с таблицей
маршрутизации Интернета (иногда называемой таблицей
IP-маршрутизации), имеющейся на каждой машине и хранящей
информацию о возможных назначениях и том, как их достичь. Так как
и ГВМ, и шлюзы маршрутизируют дейтаграммы, все они имеют таблицы
IP-маршрутизации. Всякий раз, когда программному обеспечению
IP-маршрутизации на ГВМ или шлюзе надо передать дейтаграмму, оно
обращается к таблице маршрутизации, чтобы решить, куда послать
дейтаграмму.
Какую информацию следует держать в таблицах маршрутизации ?
Если бы каждая таблица маршрутизации содержала информацию о всех
возможных адресах назначения, было бы невозможно поддерживать
корректное состояние таблицы. Более того, так как число возможных
назначений велико, машинам не хватало бы памяти для хранения всей
этой информации.
Концептуально, нам хотелось бы использовать принцип
отсутствия информации и предоставить машинам возможность
принимать решение о маршрутизации при минимальной информации.
Например, нам было бы желательно не хранить информацию о
конкретных ГВМ в локальной сети, в которой они расположены, а
поместить в таблицу информацию об удаленных машинах, для которых
нужно маршрутизировать пакеты. К счастью схема адресации IP
помогает достичь такой цели. Напомним, что IP-адреса назначаются
так, что у всех машин, присоединенных к конкретной физической
сети, имеется одинаковое начало(номер сети). Мы уже видели, что
такое назначение делает эффективной проверку на прямую доставку.
Оно также означает, что таблицам маршрутизации нужно содержать
только сетевые префиксы, а не полные IP-адреса.
Использование номера сети в адресе назначения вместо полного
адреса ГВМ делает маршрутизацию эффективно, а таблицы
маршрутизации маленькими. Более того, оно помогает скрыть
информацию о конкретных ГВМ в локальной среде, к которой эти ГВМ
присоединены. Обычно таблица содержит пары (N,G), где N - это
IP-адрес сети назначения, а G - IP-адрес следующего шлюза на пути
к сети N. Поэтому, таблица маршрутизации в шлюзе G определяет
только один шаг на пути от G к сети назначения - шлюз не знает
полный путь к назначению.
Важно понимать, что таблица маршрутизации всегда указывает на
шлюзы, которые находятся на расстоянии одной физической сети. То
есть, все шлюзы, приведенные в таблице маршрутизации машины М,
должны находиться в сетях, к которым М присоединена напрямую.
На практике, мы по возможности придерживаемся принципа
скрытия информации от ГВМ. Мы настаиваем, что хотя ГВМ имеют
таблицы IP-маршрутизации, они должны хранить минимум информации в
своих таблицах. Идея заключается в том, чтобы заставить ГВМ
полагаться на шлюзы для большей части маршрутизации.
Рисунок 8.2 показывает конкретный пример, который помогает
понять таблицы маршрутизации. Интернет в этом примере состоит из
четырех сетей, соединенных тремя шлюзами. На рисунке показана
таблица маршрутизации, используемая шлюзом G. Так как G
присоединен напрямую к сетям 20.0.0.0 и 30.0.0.0, он может
достичь любой ГВМ в этих сетях напрямую(возможно используя ARP
для нахождения физического адреса). Получив дейтаграмму,
предназначенную ГВМ в сети 40.0.0.0, G маршрутизирует ее в адрес
30.0.0.7, адрес шлюза H. H затем доставит дейтаграмму напрямую. G
может достичь адреса 30.0.0.7, так как и G, и H присоединены к
сети 30.0.0.0.
20.0.0.5 30.0.0.6 40.0.0.7
| | |
---------- V---------- V---------- V----------
| Сеть | --- | Сеть | --- | Сеть | --- | Сеть |
|10.0.0.0|-|F|-|20.0.0.0|-|G|-|30.0.0.0|-|H|-|40.0.0.0|
| | --- | | --- | | --- | |
----------^ ----------^ ----------^ ----------
| | |
10.0.0.5 20.0.0.6 30.0.0.7

(а)

Чтобы достичь Маршрутизировать
ГВМ в сети к адресу

20.0.0.0 прямая доставка
30.0.0.0 прямая доставка
10.0.0.0 20.0.0.5
40.0.0.0 30.0.0.7

(б)

Рисунок 8.2 (а) Демонстрационный интернет с 4 сетями и 3
шлюзами, и (б) таблица маршрутизации для шлюза G

Как показывает рисунок 8.2, размер таблицы маршрутизации
зависит от числа сетей в интернете; он увеличивается только при
добавлении новых сетей. Тем не менее, размер таблицы и ее
содержимое не зависят от числа отдельных ГВМ, присоединенных к
сетям. Мы можем сформулировать следующий принцип:

Чтобы работать при минимальной информации, чтобы сделать
таблицы маршрутизации маленькими и чтобы эффективно принимать
решения о маршрутизации, программное обеспечение IP-маршрутизации
хранит информацию только об адресах сетей назначений, а не о
конкретных адресах ГВМ.

Выбор маршрутов на основе идентификатора сети назначения
имеет несколько следствий. Во-первых, в большинстве реализаций
это значит, что весь траффик к конкретной сети будет использовать
один и тот же путь. В результате, даже если существует несколько
путей, они не смогут использоваться параллельно. Также все типы
траффика будут проходить по одному и тому же пути, независимо от
задержки при передаче и пропускной способности физических сетей.
Во-вторых, так как только последний шлюз на пути пытается
взаимодействовать с ГВМ назначения, только он сможет определить,
работает ли ГВМ. Поэтому, нам нужно определить способ, с помощью
которого этот шлюз мог бы послать сообщение источнику о проблемах
при доставке. В-третьих, так как каждый шлюз маршрутизирует
траффик независимо от других, дейтаграммы, следующие от ГВМ А к
ГВМ В, могут использовать путь, отличный от того, который
проходят дейтаграммы от ГВМ В к ГВМ А. Нам нужно быть уверенными
в том, что шлюзы взаимодействуют, для того чтобы гарантировать и
прямое, и обратное взаимодействие.

8.5 Маршруты по умолчанию

Другой технологией, используемой для работы при минимуме
информации и маленьких таблицах маршрутизации, является
объединение нескольких элементов таблицы в случай по умолчанию.
Идея состоит в том, что сначала программное обеспечение
IP-маршрутизации ищет сеть назначения в таблице маршрутизации.
Если для нее нет маршрута в таблице, процедуры маршрутизации
посылают дейтаграмму к шлюзу по умолчанию.
Маршрутизация по умолчанию особенно полезна, когда сеть имеет
несколько ГВМ и только одно соединение с интернетом. Например,
маршруты по умолчанию хорошо работают для машин, которые
присоединены только к одной физической сети и используют только
один шлюз для достижения остальной части интернета. Все решение о
выборе маршрута в таком случае состоит из двух проверок: одной -
на нахождение в локальной сети, и одной - случая по умолчанию,
указывающего на единственный возможный шлюз. Даже, если
место(site) имеет в своем составе несколько локальных сетей,
маршрутизация проста, так как состоит из нескольких проверок на
локальные сети и умолчания для всех остальных мест назначения.

8.6 Маршруты, специфичные для ГВМ

Хотя мы сказали, что вся маршрутизация основывается на сетях,
а не на отдельных ГВМ, большая часть программного обеспечения
IP-маршрутизации позволяет указывать как особый случай маршруты
для отдельных ГВМ. Наличие маршрутов для ГВМ предоставляет
администратору локальной сети большие возможности по слежению за
использованием сети и может быть использовано для наблюдения за
доступом к сети и обеспечения секретности. При отладке сетевых
соединений или таблиц маршрутизации способность указывать
специальный путь для отдельной машины оказывается особенно
полезной.

8.7 Итоговый алгоритм

Принимая во внимание все вышесказанное, получаем следующий
вид алгоритма IP-маршрутизации:

Алгоритм:

Маршрутизир_дейтаграмму_IP(дейтаграмма,таблица_маршрутизации)

Выделить IP-адрес назначения, Id, из дейтаграммы
Вычислить IP-адрес сети назначения,In
Если In соответствует адресу одной из достижимых
напрямую сетей,
послать дейтаграмму к назначению по этой сети;
(это включает разрешение Id в физический адрес,
инкапсуляцию дейтаграммы и посылку кадра)
иначе если для Id определен маршрут, специфичный для ГВМ
маршрутизировать дейтаграмму, как это определено в таблице;
иначе если In определено в таблице маршрутизации
маршрутизировать дейтаграмму, как это определено в таблице;
иначе если указан маршрут по умолчанию
маршрутизировать дейтаграмму к шлюзу по умолчанию;
иначе выдать сообщение об ошибке при маршрутизации;

Рисунок 8.3 Алгоритм IP-маршрутизации. Имея в качестве
исходных данных IP-дейтаграмму и таблицу маршрутизации, этот
алгоритм выбирает следующую машину, на которую будет послана
дейтаграмма. Таблицы маршрутизации всегда указывают в качестве
следующей машины ту, что находится в сети, достижимой напрямую.

8.8 Маршрутизация для IP-адресов

Важно понимать, что IP-маршрутизация не изменяет исходную
дейтаграмму. В частности, поля отправителя и получателя
дейтаграммы остаются неизменными; они всегда указывают IP-адрес
первоначального отправителя и IP-адрес конечного получателя.
Когда IP исполняет алгоритм маршрутизации, он вычисляет новый
адрес, IP-адрес очередной машины, на которую надо послать
дейтаграмму. Этот новый адрес по всей видимости будет адресом
шлюза. Тем не менее, если дейтаграмма может быть доставлена
напрямую, этот новый адрес будет совпадать с адресом конечного
назначения.
IP-адрес, вычисленный алгоритмом IP-маршрутизации, известен
как адрес следующей попытки(hop), так как он определяет, куда
послать дейтаграмму в следующий раз(хотя это место может и не
быть местом конечного назначения). Где же IP сохраняет адрес
следующей попытки ? Не в дейтаграмме; там для него нет места. По
сути дела IP не сохраняет адрес следующей попытки вообще. После
выполнения алгоритма маршрутизации IP передает дейтаграмму и
адрес следующей попытки программному обеспечению сетевого
интерфейса той сети, по которой должна быть передана дейтаграмма.
Программное обеспечение сетевого интерфейса связывает адрес
следующей попытки с физическим адресом, формирует кадр, используя
этот физический адрес, помещает дейтаграмму в поле данных кадра и
посылает результат. После использования адреса следующей попытки
для нахождения физического адреса программное обеспечение
сетевого интерфейса удаляет адрес следующей попытки.
Может показаться странным, что таблицы маршрутизации хранят
IP-адрес следующей попытки для каждой сети назначения, в то время
как эти адреса должны транслироваться в соответствующие
физические адреса перед посылкой дейтаграммы. Если мы представим
ГВМ, посылающий последовательность дейтаграмм одному и тому же
назначению, такое использование IP-адресов будет явно
неэффективным. IP послушно выделяет адрес назначения в каждой
дейтаграмме и использует таблицу маршрутизации для определения
адреса следующей попытки. Затем он передает дейтаграмму и адрес
следующей попытки сетевому интерфейсу, который находит физический
адрес. Если бы таблица маршрутизации использовала физические
адрес, определение соответствия между IP-адресом следующей
попытки и физическим адресом могло бы выполняться лишь один раз.
Почему же программное обеспечение IP избегает пользоваться
физическими адресами при хранении и вычислении маршрутов ? Как
показывает рисунок 8.4, существуют две важные причины.

ПРОВЕРКА ИЛИ МАРШРУТИЗИРУЕМАЯ
ОБНОВЛЕНИЕ МАРШРУТОВ | ДЕЙТАГРАММА
V
---------------- ----------------
| таблица | / алгоритм
| маршрутизации|--------->| маршрутизации |
| | в IP /
---------------- ---------------/
|
используются IP-адреса |
-------------------------------------------------------------
используются физические адреса | отправляемая дейтаграмма и
V адрес следующей попытки

Рисунок 8.4 Программное обеспечение IP и таблица
маршрутизации, которую оно использует, находятся выше границы
адресов. Использование только IP-адресов делает маршруты удобными
для проверки и изменения и скрывает детали физических адресов на
самом нижнем из возможных уровней.

Во-первых, таблица маршрутизации обеспечивает особенно ясный
интерфейс между программным обеспечением IP, маршрутизирующим
дейтаграммы, и высокоуровневым программным обеспечением,
управляющим путями. Для отладки ошибок маршрутизации сетевым
администраторам часто нужно проверять таблицы маршрутизации.
Использование только IP-адресов в таблице маршрутизации приводит
к тому, что администраторам становится легко понимать таблицу и
обнаруживать корректность изменения таблицы программным
обеспечением. Во-вторых, одной из главных целей разработки
Межсетевого Протокола являлось создание абстракции, скрывающей
детали нижележащих сетей.
Рисунок 8.4 показывает границу адресов, важную концептуальную
границу между низкоуровневым программным обеспечением, понимающим
физические адреса, и межсетевым программным обеспечением,
использующим только высокоуровневые адреса. Выше этой границы все
программное обеспечение для взаимодействия может быть написано с
использованием только межсетевых адресов; знание физических
адресов предоставляется нескольким небольшим низкоуровневым
процедурам. Мы увидим, что выделение этой границы также помогает
сделать реализацию остальных протоколов TCP/IP легкой для
понимания, проверки и модификации.

8.9 Обработка приходящих дейтаграмм

Итак, мы рассмотрели IP-маршрутизацию, описав, как
принимаются решения относительно отправляемых пакетов. Тем не
менее, ясно, что программное обеспечение IP должно также
обрабатывать приходящие дейтаграммы.
Когда IP-дейтаграмма прибывает на ГВМ, программное
обеспечение сетевого интерфейса доставляет ее программному
обеспечению IP для обработки. Если адрес назначения дейтаграммы
соответствует IP-адресу ГВМ, программное обеспечение IP на ГВМ
принимает дейтаграмму и передает ее программе протокола более
высокого уровня для дальнейшей обработки. Если же IP-адрес
назначения не соответствует ему, ГВМ требуется уничтожить
дейтаграмму(то есть ГВМ не позволяется пытаться маршрутизировать
дейтаграммы, по ошибке пришедшие не на ту машину).
В отличие от ГВМ, шлюзы выполняют маршрутизацию. Когда
IP-дейтаграмма прибывает на шлюз, она доставляется программному
обеспечению IP. И снова можно выделить два варианта: дейтаграмма
может быть доставлена к ее конечному назначению, или ее нужно
отправить путешествовать дальше. Как и на ГВМ, если IP-адрес
назначения дейтаграммы соответствует собственному IP-адресу
шлюза, программное обеспечение IP передает дейтаграмму
программному обеспечению более высокого уровня для
обработки(обычно, единственными дейтаграммами, предназначающимися
шлюзу, являются те, что используются для проверки достижимости и
те, что несут команды администрирования шлюзом). Если дейтаграмма
еще не достигла своего конечного назначения, IP маршрутизирует
ее, используя стандартный алгоритм и информацию из локальной
таблицы маршрутизации.
Определение того, достигла ли IP-дейтаграмма своего конечного
назначения или нет, не так тривиально, как это может показаться.
Напомним, что даже ГВМ может иметь несколько физических
соединений, и каждое из них имеет свой IP-адрес. Когда прибывает
IP-дейтаграмма, машина должна сравнить межсетевой адрес
назначения с IP-адресом каждого из своих сетевых соединений. Если
для какого-либо из них соответствие найдено, шлюз сохраняет
дейтаграмму и обрабатывает ее. Машина также должна принимать
широковещательные дейтаграммы из физических сетей, если их
IP-адрес назначения является IP-адресом ограниченного
широковещания или IP-адресом направленного широковещания для этой
сети. Как мы увидим в главах 16 и 17, подсети и многоадресные
адреса делают распознавание адресов достаточно сложным. В любом
случае, если адрес не соответствует ни одному из адресов этой
машины, IP декрементирует поле времени жизни в заголовке
дейтаграммы и удаляет дейтаграмму, если этот счетчик достиг нуля,
или вычисляет новую контрольную сумму и маршрутизирует
дейтаграмму, если счетчик больше нуля.
Должна ли каждая машина маршрутизировать дейтаграммы, которые
она получает ? Ясно, что шлюзы должны маршрутизировать приходящие
дейтаграммы, так как это их основная задача. Мы также говорили,
что некоторые многоадресные ГВМ ведут себя как шлюзы, даже если
они на самом деле компьютеры общего назначения. Хотя
использование ГВМ в качестве шлюза обычно неразумно, если кто-то
все же сделал это, то ГВМ должен быть сконфигурирован так, чтобы
маршрутизировать дейтаграммы так же, как это делает шлюз. А как
же остальные ГВМ, не предназначенные для использования в качестве
шлюзов ? Ответ будет следующий: ГВМ, не используемые в качестве
шлюзов, не должны маршрутизировать приходящие на них дейтаграммы;
они должны уничтожать их.
Существует четыре причины, почему ГВМ, не предназначенный для
функционирования в качестве шлюза, должен воздерживаться от
выполнения любых функций шлюза. Во-первых, когда такой ГВМ
получает дейтаграмму, предназначавшуюся другой машине, либо есть
ошибка в межсетевом адресе, либо произошла ошибка при
маршрутизации или доставке. Эта ошибка может быть не обнаружена,
если ГВМ совершит корректирующее действие с помощью маршрутизации
дейтаграммы. Во-вторых, маршрутизация может привести к
возникновению лишнего межсетевого траффика(и может отвлечь ЦП от
выполнения по-настоящему нужных задач). В-третьих, простые ошибки
могут вызвать хаос. Предположим, что каждый ГВМ маршрутизирует
траффик и представим себе, что случится, если одна из машин по
ошибке широковещательно передаст дейтаграмму, предназначенную на
самом деле лишь одному ГВМ, Н. Каждый ГВМ в сети получит копию
дейтаграммы в результате широковещания, и каждая машина направит
свою копию к Н, которая в результате будет бомбардирована
множеством копий. В-четвертых, как покажут последующие главы,
шлюзы не только маршрутизируют траффик. В следующей главе будет
показано, что шлюзы используют специальный протокол для сообщений
об ошибках, в то время как ГВМ не используют его(опять же, чтобы
избежать бомардирования источника множеством сообщений об
ошибках). Шлюзы также распространяют информацию о маршрутах для
того, чтобы их таблицы были согласованными. Если ГВМ
маршрутизируют дейтаграмму, не реализуя при этом всех функций
шлюза, могут возникать неожиданные аномалии.

8.10 Работа с таблицами маршрутизации

Мы рассмотрели, как IP маршрутизирует дейтаграммы,
основываясь на содержимом таблиц маршрутизации, не сказав при
этом, как системы инициализируют свои таблицы маршрутизации или
как они обновляют их при изменениях в сети. Следующие главы
ответят на эти вопросы и рассмотрят протоколы, позволяющие шлюзам
делать маршруты согласованными. А пока, важно понимать только,
что IP делает все решения маршрутизации на основе таблиц, поэтому
изменение этих таблиц изменит пути, по которым будут следовать
дейтаграммы.

8.11 Итоги

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

 

 

Глава 9
Межсетевой протокол: Ошибки и Управляющие сообщения(ICMP)

9.1 Введение

Мы уже видели, что Межсетевой протокол обеспечивает
ненадежное средство доставки без установления соединения, и что
дейтаграммы путешествуют от шлюза к шлюзу до тех пор, пока они не
достигнут шлюза, который может напрямую доставить их к конечному
месту назначения. Если шлюз не может маршрутизировать или
доставить дейтаграмму, или если шлюз обнаружил необычные условия
при работе, такие как переполнение сети, влияющие на его
способность отправлять дейтаграммы, ему нужно сообщить
первоначальному источнику, что требуется предпринять действия для
решения возникшей проблемы. Эта глава рассматривает механизм,
используемый шлюзами и ГВМ для передачи управляющей информации и
информации об ошибках. Мы увидим, как шлюзы используют этот
механизм, чтобы сообщать о проблемах при доставке, и как ГВМ
используют его для проверки достижимости назначения.

9.2 Межсетевой протокол управляющих сообщений

В системе без установления соединения, которую мы описали,
каждый шлюз работает автономно при маршрутизации или доставке
прибывающих дейтаграмм, не координируя свои действия с исходным
отправителем. Эта система хорошо работает, если все функционируют
корректно и согласовали маршрутизацию, но ведь не существует
систем, корректно работающих все время. Помимо сбоев линий
передачи и процессоров, IP аварийно завершает доставку
дейтаграмм, когда машина назначения временно или постоянно
отключена от сети, когда обнуляется счетчик времени жизни, или
когда промежуточные шлюзы так переполняются, что не могут
обработать приходящий траффик. Важное различие между реальной,
аппаратной сетью и интернетом, основанным на программном
обеспечении, заключается в том, что в первом разработчик часто
может положиться на сетевое оборудование при доведении до машин о
возникновении проблем. В интернете, не имеющем такого аппаратного
механизма, отправитель не может сказать, явился ли причиной
ошибки при доставке сбой на локальной машине или удаленной.
Отладка становится крайне трудной. В самом протоколе IP нет
ничего, что могло бы помочь отправителю проверить связность или
узнать о таких ошибках.
Чтобы дать возможность шлюзам в интернете сообщать об ошибках
или предоставлять информацию о нестандартных условиях работы,
разработчики добавили механизм сообщений специального назначения
в протоколы TCP/IP. Этот механизм, известный как Межсетевой
Протокол Управляющих Сообщений(ICMP), считается необходимой
частью IP и должен включаться в каждую реализацию IP.
Как и весь другой траффик, сообщения ICMP передаются по
интернету в поле данных IP-дейтаграмм. Конечным назначением
сообщений ICMP, тем не менее, является не прикладная программа
или пользователь на машине назначения, а программное обеспечение
IP на этой машине. То есть, когда прибывает сообщение ICMP об
ошибке, его обрабатывает модуль программного обеспечения ICMP.
Конечно, если ICMP определит, что ошибка была вызвана конкретным
протоколом более высокого уровня или прикладной программой, он
сообщит об этом соответствующему модулю. Подведем итоги:

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

Первоначально разработанный для предоставления шлюзам
возможности сообщать о причинах ошибок доставки ГВМ, ICMP не
предназначен только для шлюзов. Хотя руководства ограничивают
использование некоторых сообщений ICMP, любая машина может
послать сообщение ICMP на любую другую машину. Поэтому, ГВМ может
использовать ICMP для связи со шлюзом или другим ГВМ. Главная
выгода от разрешения ГВМ использовать ICMP заключается в том, что
он обеспечивает простой механизм, используемый для всех
управляющих и информационных сообщений.

9.3 Сообщение об ошибке против исправления ошибки

Говоря техническим языком, ICMP - это механизм сообщения об
ошибках. Он обеспечивает для шлюзов, обнаруживающих ошибки,
способ сообщить об ошибке первоначальному источнику. Хотя
спецификация протокола определяет допустимые способы
использования ICMP и предлагает варианты возможных действий в
ответ на ошибки, ICMP не специфицирует полностью действия,
которые нужно предпринять в ответ на все возможные ошибки. Короче
говоря:

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

Большая часть ошибок исходит от первоначального источника, но
другие - нет. Так как ICMP сообщает об ошибках первоначальному
источнику, он не может использоваться, чтобы информировать
промежуточные шлюзы об ошибках. Например, представим, что
дейтаграмма следует по пути через шлюзы G1,G2,...,Gk. Если Gk
содержит некорректную информацию о маршрутах и ошибочно отправит
дейтаграмму на шлюз Gе, то Ge может лишь сообщить об ошибке
первоначальному источнику. К сожалению, источник не отвечает за
эту проблему и не может управлять некорректно ведущим себя
шлюзом. Фактически, источник не сможет даже определить, какой
шлюз вызвал эту проблему.
Зачем ограничивать ICMP взаимодействием с первоначальным
источником ? Ответ должен быть очевиден, если вспомнить
рассмотрение нами форматов дейтаграммы и маршрутизации в
предыдущих главах. Дейтаграмма содержит поля, которые определяют
только первоначального источника и конечного получателя; она не
содержит полного описания своего пути через интернет(кроме
необычных случаев, когда используется опция записи маршрута).
Более того, так как шлюзы могут создавать и менять свои таблицы
маршрутизации, не существует глобального представления о путях.
Поэтому, когда дейтаграмма достигает данного шлюза, нельзя
узнать, какой путь она прошла до этого. Если шлюз обнаруживает
ошибку, он не может узнать какие промежуточные машины
обрабатывали эту дейтаграмму, и поэтому не может сообщить им об
ошибке. Вместо простого удаления дейтаграммы этот шлюз использует
ICMP, чтобы сообщить первоначальному источнику о возникшей
проблеме, надеется на то, что администраторы ГВМ будут
взаимодействовать с администраторами сети, чтобы локализовать и
исправить ошибку.

9.4 Доставка сообщения ICMP

Сообщения ICMP требуют двух уровней инкапсуляции, как
показано на рисунке 9.1. Каждое сообщения ICMP передается по
интернету в поле данных IP-дейтаграммы, которая сама передается
по каждой физической сети в поле данных кадра. Дейтаграммы,
несущие сообщения ICMP маршрутизируются точно так же, как и
дейтаграммы, несущие информацию для пользователей; для них не
используются дополнительные приоритет или надежность. Поэтому,
сами сообщения об ошибках могут быть потеряны или удалены. Более
того, в уже переполненной сети сообщения об ошибках могут вызвать
дополнительное переполнение. Исключение делается для процедур
обработки ошибок, если IP-дейтаграмма, несущая сообщение ICMP,
вызвала ошибку. Это исключение, установленное для того, чтобы
избежать проблемы появления сообщений об ошибках, вызванных в
свою очередь сообщениями об ошибках, определяет, что сообщения
ICMP не генерируются для ошибок, появившихся из-за дейтаграмм,
несущих сообщения об ошибках ICMP.

--------------------------------------
|заголовок | данные ICMP |
| ICMP | |
--------------------------------------
V V
-------------------------------------------------
| заголовок| область данных дейтаграммы |
|дейтаграмм| |
-------------------------------------------------
V V
-----------------------------------------------------------
|заголовок| область данных кадра |
|кадра | |
-----------------------------------------------------------

Рисунок 9.1 Два уровня инкапсуляции ICMP. Сообщение ICMP
инкапсулируется в IP-дейтаграмме, которая в свою очередь
инкапсулируется в кадре для передачи. Для идентификации ICMP поле
протокола дейтаграммы содержит значение 1.

Важно помнить, что несмотря на то, что сообщения ICMP
инкапсулируются и посылаются, используя IP, ICMP не считается
протоколом более высокого уровня - он является необходимой частью
IP. Причина использования IP для транспортировки сообщений ICMP
заключается в том, что им понадобиться пересечь несколько
физических сетей для того, чтобы достичь своего конечного
назначения. Поэтому, они не могут быть доставлены только с
помощью физической передачи.

9.5 Формат сообщения ICMP

Хотя каждое сообщение ICMP имеет свой собственный формат, все
они начинаются с трех одинаковых полей: 8-битового целочисленного
поля ТИП, которое идентифицирует сообщение, 8-битового поля КОД,
которое обеспечивает более точную информацию о типе сообщения, и
16-битового поля КОНТРОЛЬНАЯ_СУММА(ICMP использует тот же самый
аддитивный алгоритм, что и IP, но контрольная сумма ICMP
учитывает только сообщение ICMP). Помимо того, сообщения ICMP,
сообщающие об ошибках, всегда включают заголовок и первые 64 бита
данных дейтаграммы, вызвавшей ошибку.
Причиной возвращения не только заголовка дейтаграммы,
вызвавшей ошибку, является желание позволить получателю более
точно определять, какие протоколы и какие прикладные программы
ответственны за появление этой дейтаграммы. Как мы увидим позже,
протоколы более высокого уровня в связке TCP/IP разрабатывались
таким образом, что критическая информация закодирована в первых
64 битах.
Поле ТИП ICMP определяет смысл сообщения, а также его
формат. Эти типы включают:

Поле ТИП Тип сообщения ICMP

0 Ответ на эхо
3 Назначение недостижимо
4 Подавление источника
5 Переназначение(изменение маршрута)
8 Запрос эха
11 Превышено время для дейтаграммы
12 Ошибка параметра в дейтаграмме
13 Запрос временной отметки
14 Ответ для временной метки
15 Запрос информации(не действует)
16 Ответ на запрос информации(не действует)
17 Запрос маски адреса
18 Ответ на запрос маски адреса

Следующие секции описывают каждое из этих сообщений, приводя
при этом детальное описание формата сообщения и их смысл.

9.6 Тестирование достижимости назначения и его состояния

Протоколы TCP/IP обеспечивают средства, помогающие сетевым
администраторам или пользователям идентифицировать проблемы в
сети. Одно из самых наиболее используемых средств отладки
вызывает сообщения ICMP запрос эха и ответ эха. ГВМ или шлюз
посылает сообщение запроса эха указанному месту назначения. Любая
машина, получившая запрос эха, генерирует ответ на эхо и
возвращает его первоначальному отправителю. Этот запрос содержит
необязательную область данных; ответ содержит копию данных,
посланных в запросе. Запрос эха и связанный с ним ответ могут
использоваться для проверки достижимости назначения и его
способности отвечать на запросы. Так как и запрос эха, и ответ на
него передаются в IP-дейтаграммах, успешный прием ответа
свидетельствует о работоспособности основных частей транспортной
системы. Во-первых, программное обеспечение IP на машине
источника произвело маршрутизацию дейтаграммы. Во-вторых,
промежуточные шлюзы между источником и получателем работоспособны
и корректно маршрутизируют дейтаграммы. В-третьих, машина
получателя работает (по крайней мере, она обрабатывает
прерывания) и программное обеспечение как IP, так и ICMP
выполняет свои функции. И наконец, таблицы маршрутов в шлюзах на
всем обратном пути корректны.
Во многих системах команда, которую пользователи вызывают
для посылки запроса эха ICMP, называется ping. Усложненные версии
этой программы посылают серии запросов эха ICMP, принимают ответы
и выдают статистику о потерях дейтаграмм. Они позволяют
пользователю указывать длину посылаемых данных и интервалы
времени между запросами. Менее сложные версии просто посылают
запрос эха ICMP и ждут ответа.

9.7 Формат сообщения запроса эха и ответа эха

Рисунок 9.2 содержит формат сообщений запроса эха и ответа на
запрос эха.

0 8 16
------------------------------------------------------------
|тип(8 или 0)| код(0) | Контрольная сумма |
------------------------------------------------------------
| идентификатор | последовательный номер |
------------------------------------------------------------
| необязательные данные |
------------------------------------------------------------
| ...... |
------------------------------------------------------------

Рисунок 9.2 Формат сообщения запроса эха и ответа на него

Поле, названное НЕОБЯЗАТЕЛЬНЫЕ ДАННЫЕ имеет переменную длину
и содержит данные, которые надо вернуть отправителю. Ответ на эхо
всегда возвращает те же самые данные, что были получены им в
запросе. Поля ИДЕНТИФИКАТОР и ПОСЛЕДОВАТЕЛЬНЫЙ НОМЕР используются
отправителем для проверки соответствия ответов запросам. Значение
поля ТИП определяет, является ли сообщение запросом(8) или
ответом(0).

9.8 Сообщения о недостижимости назначения

Когда шлюз не может доставить IP-дейтаграмму, он посылает
сообщение "назначение недостижимо" обратно первоначальному
отправителю, используя формат, приведенный на рисунке 9.3.

0 8 16
------------------------------------------------------------
|тип(3) | код(0-5) | Контрольная сумма |
------------------------------------------------------------
| не используется(должно быть равно нулю) |
------------------------------------------------------------
| межсетевой заголовок плюс первые 64 бита дейтаграммы |
------------------------------------------------------------
| ...... |
------------------------------------------------------------

Рисунок 9.3 Формат сообщения о недостижимости назначения

Поле КОД в сообщении о недостижимости назначения содержит
целое число, которое описывает причину. Возможны следующие
значения:

Значение Смысл

0 Сеть недостижима
1 ГВМ недостижим
2 Протокол недостижим
3 Порт недостижим
4 Требуется фрагментация
5 Ошибка при маршрутизации источника
6 Сеть назначения неизвестна
7 ГВМ назначения неизвестен
8 ГВМ источника изолирован
9 Взаимодействие с сетью назначения
административно запрещено
10 Взаимодействие с ГВМ назначения
административно запрещено
11 Сеть недостижима из класса обслуживания
12 ГВМ недостижим из-за класса обслуживания

Хотя IP является механизмом ненадежной доставки, дейтаграммы
не уничтожаются просто так. Всякий раз, когда ошибка мешает шлюзу
произвести маршрутизацию или доставку дейтаграммы, шлюз посылает
сообщение о недостижимости назначения обратно его источнику, а
затем уничтожает дейтаграмму. Ошибки недостижимости сети обычно
являются следствием ошибок маршрутизации; ошибки недостижимости
ГВМ - следствие ошибок при доставке(исключением является случай,
когда шлюзы используют схему адресации подсетей, описанную в
главе 16. Они сообщают об ошибке при маршрутизации к подсети с
помощью сообщения ICMP о недостижимости ГВМ). Так как сообщение
содержит короткий префикс дейтаграммы, вызвавшей ошибку, то
источник будет точно знать, какой адрес недостижим.
Назначения могут быть недостижимыми из-за того, что
оборудование было временно неработоспособно, из-за того, что
отправитель указал несуществующий адрес назначения, или ( в
редких случаях) из-за того, что у шлюза не указано маршрута к
сети назначения. Отметим, что хотя шлюзы сообщают об ошибках,
которые они обнаружили, они могут не знать обо всех ошибках
доставки. Например, если машина получателя присоединена к сети
Ethernet, то сетевое оборудование не предоставляет подтверждения
получения дейтаграммы. Поэтому, шлюз может продолжать посылать
пакеты назначению даже после того, как оно отключено, не получая
при этом никакой информации о том, что пакеты не доставляются.
Подведем итоги:

Хотя шлюзы посылают сообщения о недостижимости назначения,
если они не могут произвести маршрутизацию или доставку
дейтаграммы, не все подобные ошибки обнаруживаются.

Смысл сообщений о недостижимости порта и протокола станет
ясен, когда мы изучим, как протоколы более высокого уровня
используют абстракцию точки получения, называемую портом. Смысл
большей части остальных сообщений понятен уже из их названия.
Если дейтаграмма содержит опцию маршрутизации источника с
некорректным маршрутом, то это может привести к появлению
сообщения об ошибке маршрутизации источника. Если шлюзу нужно
фрагментировать дейтаграмму, но установлен бит "не
фрагментировать", то шлюз посылает сообщение "требуется
фрагментация" обратно источнику.

9.9 Управление потоком дейтаграмм и переполнение сети

Так как IP является протоколом без установления соединения,
то шлюзы не могут резервировать память или коммуникационные
ресурсы до получения дейтаграмм. В результате, траффик может
вызвать перегрузку шлюзов, ситуацию, называемую переполнением
сети(congestion). Важно понимать, что переполнение сети может
возникать из-за двух совершенно разных причин. Во-первых,
высокоскоростной компьютер может генерировать траффик быстрее,
чем сеть может передавать его. Например, представим
суперкомпьютер, генерирующий межсетевой траффик. Дейтаграммам,
посылаемым им, может потребоваться передача в конечном счете по
медленной глобальной сети(WAN), хотя сам суперкомпьютер может
быть присоединен к высокоскоростной локальной сети. Переполнение
будет возникать в шлюзе, присоединенном к глобальной сети, так
как дейтаграммы будут прибывать быстрее, чем их можно послать.
Во-вторых, если большому числу компьютеров одновременно нужно
посылать дейтаграммы через один шлюз, этот шлюз может оказаться
переполненным, хотя ни один источник в отдельности и не вызывает
эту проблему.
Когда дейтаграммы прибывают на шлюз или ГВМ быстрее, чем он
успевает их обрабатывать, он временно ставит их в очередь в своей
памяти. Если эти дейтаграммы - это часть небольшого пика при
передаче дейтаграмм, то такая буферизация решает проблему. Если
же траффик продолжает поступать, то то в конечном счете ГВМ или
шлюз займет всю память под очередь и вынужден будет удалять новые
прибывающие дейтаграммы. Тогда машина использует сообщения о
подавлении источника для выхода из состояния переполнения.
Сообщение о подавлении источника требует от источника уменьшить
скорость передачи дейтаграмм. Обычно переполненные шлюзы посылают
по одному сообщению о подавлении источника на каждую удаляемую
дейтаграмму. Шлюзы могут также использовать более сложные
технологии выхода из переполнения. Некоторые наблюдают за
приходящим траффиком и подавляют источники с наивысшими
скоростями передачи. Другие пытаются избежать переполнения в
принципе, выдавая запросы подавления источника в том случае,
когда их очереди начинают становиться слишком длинными, но до
того, как они переполнятся.
Не существует сообщения ICMP, вызывающего эффект, обратный
подавлению источника. Вместо этого ГВМ, принявший сообщения о
подавлении источника от некоторой машины, М, снижает скорость, с
которой он посылает дейтаграммы на М до тех пор, пока к нему не
перестанут приходить сообщения о подавлении источника; затем он
постепенно увеличивает скорость до тех пор, пока он снова не
получит сообщения о подавлении источника.

9.10 Формат подавления источника

Помимо обычных полей ICMP ТИП, КОД и КОНТРОЛЬНАЯ СУММА, и
неиспользуемого 32-битового поля, сообщения о подавлении
источника имеют поле, содержащее префикс дейтаграммы. Рисунок 9.4
иллюстрирует этот формат. Как и в других сообщениях об ошибках
ICMP поле префикса дейтаграммы содержит префикс дейтаграммы,
вызвавшей этот запрос подавления источника.

0 8 16 31
------------------------------------------------------------
|тип(4) | код(0) | Контрольная сумма |
------------------------------------------------------------
| не используется(должно быть равно нулю) |
------------------------------------------------------------
| межсетевой заголовок плюс первые 64 бита дейтаграммы |
------------------------------------------------------------
| ...... |
------------------------------------------------------------

Рисунок 9.4 Формат сообщения о подавлении источника ICMP.
Переполненные шлюзы посылают одно сообщение о подавлении
источника каждый раз, когда они удаляют дейтаграмму; префикс
дейтаграммы идентифицирует удаленную дейтаграмму.

9.11 Запросы изменения маршрута от шлюзов

Таблицы маршрутизации Интернета обычно не меняются в течение
длинного промежутка времени. ГВМ инициализируют их с помощью
файла конфигурации при загрузке системы, а сетевые администраторы
лишь изредка вно

 

Глава 10 Разделение протоколов на уровни

10.1 Введение

Предыдущие главы рассмотрели архитектурные основы межсетевого
обмена, описали, как шлюзы маршрутизируют дейтаграммы Интернета
между собой и ГВМ, и представили механизмы, используемые для
отображения IP-адресов в физические сетевые адреса. Эта глава
рассмотрит общую структуру программного обеспечения, находящегося
в шлюзах и ГВМ, которое решает задачу сетевого взаимодействия.
Она опишет общий принцип разделения на уровни, покажет, как
это разделение делает программное обеспечение Межсетевого
Протокола легче для понимания и построения, и проследит путь
дейтаграмм через протокольное программное обеспечение, который
они проходят при передаче через интернет TCP/IP.

10.2 Необходимость нескольких протоколов

Мы уже говорили, что протоколы позволяют специфицировать или
понимать взаимодействие, не зная детали сетевого оборудования
конкретного производителя. Они являются для компьютерного
взаимодействия тем же самым, чем являются языки программирования
для вычислений. Теперь вам должно быть понятно, насколько верна
эта аналогия. Как язык ассемблера, некоторые протоколы описывают
взаимодействие по физической сети. Например, детали формата кадра
Etherneta, политика доступа к сети, обработка ошибок в кадрах
вместе составляют протокол, описывающий взаимодействие по
Ethernetу. Аналогично, детали IP-адресов, формат дейтаграммы,
понятие ненадежной доставки, без установления соединения
составляют Межсетевой Протокол.
Сложные системы передачи данных не используют один протокол
для решения всех задач передачи. Вместо этого, им требуется набор
взаимодействующих протоколов, иногда называемый семейством
протоколов или стеком протоколов. Чтобы понять почему это так,
перечислим ошибки, которые могут возникнуть, когда машины
взаимодействуют по сети данных.
* Сбой оборудования. ГВМ или шлюз может перестать работать
либо из-за аварии оборудования, либо из-за краха операционной
системы. Канал передачи данных может перестать работать или
может быть неожиданно отключен. Протокольному ПО нужно
распознавать такие сбои и восстанавливаться после них, если это
возможно.
* Перегрузка сети. Даже, если все оборудование и ПО работает
корректно, сети имеют конечную пропускную способность, которая
может быть превышена. Протокольному ПО нужно знать способы,
которыми перегруженная машина может подавить остальной траффик.
* Задержка или потеря пакетов. Иногда пакеты сильно
задерживаются или теряются. Протокольному ПО нужно узнавать о
таких ошибках или адаптироваться к большим задержкам при
передаче.
* Ошибки в данных. Электрические или магнитные помехи или
ошибки оборудования могут вызвать ошибки передачи, разрушающие
передаваемые данные. Протокольному ПО надо узнавать о таких
ошибках и восстанавливаться после них.
* Дублирование данных или нарушение последовательности. Сети,
предоставляющие несколько путей передачи, могут доставлять данные
не по порядку или доставлять дубликаты пакетов. Протокольному ПО
надо переупорядочивать пакеты и удалять дубли.

Собранные воедино, эти проблемы подавляют. Трудно понять, как
написать один протокол, которые бы обрабатывал их всех. По
аналогии с языками программирования мы можем выбрать способ, как
справиться с таким уровнем сложности. Трансляция программ делится
на четыре концептуальных этапа, выделяемые по именам запускаемых
программ: компилятор, ассемблер, компоновщик и загрузчик. Такое
деление позволяет разработчику сосредотачиваться в каждый момент
времени на одной проблеме, а программисту писать и тестировать
каждый модуль ПО независимо от других.
Два последних наблюдения из нашей аналогии с языками
программирования помогут вам уяснить организацию протоколов.
Во-первых, ясно, что части транслируемого ПО должны согласовать
формат данных, передаваемых между ними. Например, данные,
передаваемые от компилятора ассемблеру, состоят из программы на
языке ассемблера. Поэтому, мы видим, как процесс трансляции
включает несколько языков программирования. Эта аналогия
применима к коммуникационному ПО, где мы видим, что несколько
протоколов определяют интерфейсы между модулями
коммуникационного ПО. Во-вторых, четыре части транслятора
образуют линейную последовательность, в которой выход компилятора
становится входом для ассемблера, и т.д. Протокольное ПО также
использует линейную последовательность.

10.3 Концептуальные уровни протокольного ПО

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

----------------- -----------------
| ОТПРАВИТЕЛЬ | | ПОЛУЧАТЕЛЬ |
|---------------- |----------------
| Уровень n | | Уровень n |
|---------------| |---------------|
| .... | | .... |
|---------------| |---------------|
| Уровень 2 | | Уровень 2 |
|---------------| |---------------|
| Уровень 1 | | Уровень 1 |
|_______________| |_______________|
| ^
| |
---V--------------------------|---
| СЕТЬ |
----------------------------------

Рисунок 10.1 Концептуальная организация протокольного ПО в
виде уровней.

Концептуально, посылка сообщения от прикладной программы на
одной машине к прикладной программе на другой машине означает
последовательную передачу сообщения вниз через соседние уровни
протокольного ПО на машине получателя, передачу сообщения по сети
и передачу сообщения вверх через соседние уровни протокольного ПО
на машине получателя.
На практике, протокольное ПО гораздо более сложное, чем это
может показаться на основании рисунка 10.1. Каждый уровень
принимает решение о корректности сообщения и выбирает
соответствующее действие на основании типа сообщения или адреса
назначения. Например, один из уровней на принимающей машине
должен решить, оставить сообщение или передать его дальше другой
машине. Другой уровень должен решить, какая прикладная программа
должна принять сообщение.
Чтобы понять разницу между концептуальной организацией
протокольного ПО и деталями реализации, рассмотрим их
сопоставление, показанное на рисунке 10.2. Концептуальная
диаграмма на рисунке 10.2а показывает Межсетевой уровень между
высокоуровневым протокольным уровнем и уровнем сетевого
интерфейса. Реальная диаграмма на рисунке 10.2б показывает, что
ПО IP может взаимодействовать с несколькими модулями протоколов
высокого уровня и с несколькими сетевыми интерфейсами.
Хотя диаграмма концептуального разделения протоколов на
уровни не показывает все детали, она помогает объяснить базовые
идеи. Например, рисунок 10.3 показывает уровни протокольного ПО,
используемые сообщением, пересекающим три сети. Диаграмма
показывает только уровни интерфейса с сетью и Межсетевого
Протокола в шлюзах, так как только эти уровни требуются при
получении, маршрутизации и отправке дейтаграмм. Мы понимаем, что
любая машина, присоединенная к двум сетям, должна иметь два
модуля интерфейса с сетью, хотя диаграмма концептуального
разделения на уровни показывает только один уровень интерфейса с
сетью в каждой машине.

 

---------------------- ------------ ------------ ------------
| уровень протоколов | |Протокол 1| |Протокол 2| |Протокол 3|
| высокого уровня | ----------- -----|------ --/---------
---------------------- | /
| уровень межсетево- | -----|------ /
| го протокола | |Модуль IP |
---------------------- / ------------
| уровень интерфейса | / |
| с сетью | ------------ ------------ ------------
---------------------- |Интерфейс1| |Интерфейс2| |Интерфейс3|
(а) ------------ ------------ ------------
(б)

Рисунок 10.2 Сопоставление разделения на концептуальные
уровни (а) и реальной ситуации с организацией ПО, использующей
несколько сетевых интерфейсов ниже IP и несколько протоколов выше
него (б).

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

------------- ------------- ------------- -------------
|Отправитель| | | | | |Получатель |
| | | | | | | | ^ |
------V------ | | | | ------|------
| другие ...| | | | | | другие ...|
------------- ------------- ------------- -------------
| Уровень IP| | Уровень IP| | Уровень IP| | Уровень IP|
------------- ------------- ------------- -------------
| Интерфейс | | Интерфейс | | Интерфейс | | Интерфейс |
---------|--- -^--------|-- --^--------|- ---^---------
| | | | | |
--V------| -V------|- V------|--
/ / /
| Сеть 1 | | Сеть 2 | | Сеть 3 |
/ / /
---------- ---------- ----------

Рисунок 10.3 Путь сообщения, пересекающего Интернет от
отправителя через две промежуточные машины к получателю.
Промежуточные машины только посылают дейтаграмму до уровня IP в
ПО.

10.4 Возможности уровней

Раз принято решение разделить задачу взаимодействия на
подзадачи и организовать протокольное ПО в виде модулей, каждый
из которых решает одну из подзадач, возникает вопрос: "какие
возможности должен обеспечивать каждый модуль ?". На этот вопрос
нелегко ответить по нескольким причинам. Во-первых, при заданном
наборе целей и ограничений, приводящем к специфической задаче
взаимодействия, можно выбрать организацию, оптимизирующую
протокольное ПО для этой конкретной задачи. Во-вторых, даже при
рассмотрении общих сервисов сетевого уровня, таких как надежная
транспортировка, можно выбрать один из нескольких принципиально
отличающихся друг от друга подходов для решения этой задачи.
В-третьих, разработка сетевой( или межсетевой) архитектуры и
организация протокольного ПО не связаны между собой; можно
разрабатывать одно в отрыве от другого.

10.4.1 Семиуровневая справочная модель ВОС

В этой области доминируют две идеи относительно разделения
протоколов на уровни. Первая, основывающаяся на работе,
проделанной Международной Организацией по Стандартизации(МОС),
известной как Справочная Модель ВОС Взаимодействия Открытых
Систем, часто называется моделью ВОС. Модель ВОС, содержащая семь
концептуальных уровней, организована так, как показано на рисунке
10.4.

Уровень Возможности
---------------------------
7 | Прикладной |
| |
---------------------------
6 | Представительный |
| |
---------------------------
5 | Сеансовый |
| |
---------------------------
4 | Транспортный |
| |
---------------------------
3 | Сетевой |
| |
---------------------------
2 | Канальный |
| (аппаратный интерфейс) |
---------------------------
1 | Физический |
| |
---------------------------

Рисунок 10.4 Семиуровневая справочная модель ВОС для
протокольного ПО.

Модель ВОС, созданная для описания протоколов одной сети, не
содержит специального уровня для межсетевой маршрутизации,
имеющегося в стеке протоколов TCP/IP.

10.5 Х.25 МККТТ и его связь с моделью ВОС

Схема разделения на уровни ВОС, хотя и разрабатывалась как
концептуальная модель, а не руководство для реализаций, является
основой для нескольких реализаций протоколов. Среди протоколов,
связанных с моделью ВОС, набор протоколов, известный как Х.25,
является вероятно самым популярным и широко используемым. Х.25
был создан как рекомендация Международного Консультативного
Комитета по Телефонии и Телеграфии( МККТТ), международной
организации, вырабатывающей стандарты для международных
телефонных служб. Х.25 используется сетями передачи данных общего
пользования в Европе и США.
С точки зрения Х.25, сеть работает во-многом аналогично
телефонной системе. Как и ARPANET, описанный в главе 2, сеть Х.25
предполагается состоящей из сложных коммутаторов пакетов, имеющих
достаточную интеллектуальность, чтобы маршрутизировать пакеты.
ГВМ не присоединены напрямую к каналам сети. Вместо этого каждый
ГВМ присоединен к одному из коммутаторов пакетов, используя
последовательную линию взаимодействия. Можно сказать и
по-другому, то есть что соединение между пакетным коммутатором
Х.25 и ГВМ - миниатюрная сеть, состоящая из одной
последовательной линии. ГВМ должен использовать довольно сложную
процедуру для передачи пакетов в сеть.
* Физический уровень. Х.25 определяет стандарт для
физического соединения между ГВМ и сетевыми коммутаторами
пакетов, а также процедуры, используемые для передачи пакетов от
одной машины к другой. В справочной модели уровень 1 определяет
физическое соединение, включая электрические параметры, такие как
напряжение и ток. Соответствующий протокол, Х.21, содержит
его детальное описание, и используется сетями передачи данных
общего пользования.
* Канальный уровень. Уровень 2 в протоколе Х.25 определяет,
как данные передаются между ГВМ и пакетным коммутатором, к
которому он присоединен. Х.25 использует термин кадр для
обозначения элементарного блока данных, передаваемого между ГВМ и
коммутатором пакетов( важно понимать, что определение кадра в
Х.25 отличается от того, которое мы используем). Так как
собственно оборудование доставляет только поток бит, протокол
уровня 2 должен определить формат кадров и указать, как две
машины будут определять границы кадров. Так как ошибки передачи
могут разрушить данные, протокол уровня 2 включает обнаружение
ошибок( то есть, контрольную сумму кадра). Наконец, так как
передача не является надежной, протокол уровня 2 определяет обмен
подтверждениями, позволяющий двум машинам узнавать, когда кадр
успешно передан.
Самый широко используемый протокол уровня 2, имеющий название
Высокоуровневое Взаимодействие по Каналу Данных, известен по его
аббревиатуре - HDLC. Существует несколько версий HDLC, из которых
самая последняя имеет название - HDLC/LAPB. Важно помнить, что
успешная передача на уровне 2 означает, что кадр был передан
сетевому коммутатору пакетов для доставки; она не гарантирует,
что пакетный коммутатор примет пакет, или сможет переправить его
для доставки.
* Сетевой уровень. Справочная модель ВОС определяет, что
третий уровень содержит возможности, завершающие описание
взаимодействия между ГВМ и сетью. Называемый сетевым уровнем или
уровнем коммуникационной подсети, этот уровень определяет базовый
элемент, передающийся по сети , и включает понятия адресации
назначения и маршрутизации к назначению. Напомним, что в мире
Х.25 взаимодействие между ГВМ и коммутатором пакетов
концептуально отделено от траффика, который при этом передается.
Поэтому, протоколы уровня 3 в сети могут допускать пакеты
большего размера, чем те, что передаются на уровне 2. ПО уровня 3
собирает пакет в той форме, которую ожидает сеть, и использует
уровень 2 для передачи его( возможно по частям) к коммутатору
пакетов. Уровень 3 также должен решать проблему переполнения
сети.
* Транспортный уровень. Уровень 4 обеспечивает сквозную
надежность с помощью прямого взаимодействия ГВМ-источника с
ГВМ-назначением. Основная идея здесь заключается в том, что хотя
нижние уровни обеспечивают надежность передачи каждого элемента,
уровень межконцевого взаимодействия дублирует их, чтобы быть
уверенным в том, что все промежуточные машины работают.
* Сеансовый уровень. Более высокие уровни модели МОС
описывают, как может быть организовано протокольное ПО для
предоставления всех возможностей прикладной программе. Комитет
МОС считает проблему удаленных терминалов настолько важной, что
выделил уровень 5 для ее решения. Фактически, главным средством,
предоставляемым многими сетями передачи данных общего
пользования, является установление соединения между терминалом и
ГВМ. Поставщик сервиса обеспечивает ГВМ специального назначения,
называемый СБОРЩИК-РАЗБОРЩИК ПАКЕТОВ (PAD) в сети с
коммутируемыми линиями связи. Подписчики, обычно путешественники,
имеющие свой собственный терминал и модем, устанавливают
соединение с локальным PADом, создают сетевое соединение с ГВМ, с
которым им нужно взаимодействовать, и входят в систему.
Использование сети для взаимодействия на больших расстояниях
более дешево, чем прямое установление соединения через телефонную
сеть.
* Представительный уровень. Уровень 6 МОС разработан, чтобы
включать в себя функции, требуемые многим прикладным программам,
использующим сеть. Типичным примером являются стандартные
процедуры, сжимающие текст или преобразующие графические образы
для передачи по сети. Хотя этот уровень еще не доработан, в
последние годы проводились серьезные работы по его расширению.
Стандарт МОС, известный как Нотация Абстрактного Синтаксиса 1
(ASN.1), обеспечивает представление данных, используемых
прикладными программами.
* Прикладной уровень. Наконец, уровень 7 МОС включает
прикладные программы, использующие сеть. Примеры включают в себя
программы электронной почты или передачи файлов. В частности,
МККТТ рекомендовал протокол для электронной почты, называемый
Х.400 или Х.400(1988). Фактически, МОС и МККТТ совместно
разработали систему обработки сообщений; версия МОС называется
MOTIS.

10.5.1 Модель уровней Интернета TCP/IP

Вторая основная модель разделения протоколов на уровни не
была разработана комитетом по стандартам, а появилась в
результате исследований, приведших к появлению стека протоколов
TCP/IP. После небольшой доработки модель МОС может быть
приспособлена для описания схемы деления на уровни в TCP/IP, но
базовые предпосылки этих схем сильно различаются, что позволяет
говорить об их различии.
На концептуальном уровне ПО TCP/IP организовано в виде 4
уровней, опирающихся на пятый уровень оборудования. Рисунок 10.5
показывает концептуальные уровни, а также форму, в которой
передаются данные между ними.

Концептуальный уровень Объекты, передаваемые
между уровнями
-----------------
| Прикладной |
| |
----------------- <--------- Сообщения или потоки
| Транспортный |
| |
----------------- <--------- Пакеты транспортного
| Межсетевой | протокола
| |
----------------- <--------- Дейтаграммы IP
| Интерфейс с |
| сетью |
----------------- <--------- Кадры конкретной сети
. Оборудование .
. .
.................

Рисунок 10.5 Четыре конептуальных уровня ПО TCP/IP и форма
объектов, передаваемых между ними. Уровень, называемый интерфейс
с сетью, иногда называют уровень канала данных.

* Прикладной уровень. На самом верхнем уровне пользователи
вызывают прикладные программы, которые обращаются к сервисам,
доступным в среде Интернета TCP/IP. Приложение взаимодействует с
протоколами транспортного уровня для передачи или приема данных.
Каждая прикладная программа выбирает тип транспортировки, который
ей требуется - либо последовательность отдельных сообщений, либо
непрерывный поток байт. Прикладная программа передает данные
транспортному уровню в требуемой форме для доставки.
* Транспортный уровень. Основной задачей транспортного уровня
явялется обеспечение взаимодействия между прикладными
программами. Такое взаимодействие часто называется межконцевое(
end-to-end). Транспортный уровень может управлять потоком
информации. Он может также обеспечивать надежную передачу,
гарантируя, что данные прибыли без ошибок и в порядке их
передачи. Для этого он заставляет принимающую сторону посылать
обратно подтверждения, и повторно передает потерянные пакеты.
Транспортное ПО делит передаваемый поток данных на небольшие
части( называемые пакетами согласно терминологии МОС) и передает
каждый пакет вместе с адресом назначения следующему уровню.
Хотя рисунок 10.5 использует один блок для представления
прикладного уровня, компьютеры общего назначения могут выполнять
несколько программ, одновременно обращающихся к интернету.
Транспортный уровень должен принимать данные от нескольких
прикладных программ и посылать их более нижнему уровню. Для этого
он добавляет дполнительную информацию к каждому пакету, включая
коды, идентифицирующие прикладную программу, пославшую его, и
приклданую программу-получателя, а также контрольную сумму.
Принимающая машина использует контрольную сумму для проверки
целостности принятого пакета, а код назначения - для
идентификации прикладной программы, которой он должен быть
передан.
* Межсетевой уровень. Как мы уже видели, Межсетевой уровень
управляет взаимодействием между машинами. Он принимает запрос на
посылку пакета от транспортного уровня вместе с указанием машины,
на которую этот пакет должен быть послан. Он инкапсулирует пакет
в IP-дейтаграмме, заполняет заголовок дейтаграммы, использует
алгоритмы маршрутизации для определения того, можно ли послать
дейтаграмму напрямую, или следует послать ее шлюзу, и передает
дейтаграмму соответствующему интерфейсу с сетью. Межсетевой
уровень также обрабатывает приходящие дейтаграммы, проверяет их
корректность, и использует алгоритм маршрутизации для того, чтобы
решить, нужно ли обработать дейтаграмму локально или ее следует
переправить дальше. Для дейтаграмм, адресованных локальной
машине, ПО межсетевого уровня удаляет заголовок дейтаграммы и
определяет, какой из транспортных протоколов будет обрабатывать
пакет. Наконец, межсетеовй уровень посылает сообщения об ошибках
ICMP по мере необходимости и обрабатывает все приходящие
сообщения ICMP.
* Уровень интерфейса с сетью. ПО TCP/IP самого низкого уровня
состоит из уровня интерфейса с сетью, ответственного за прием
IP-дейтаграмм и передачу их по конкретной сети. Интерфейс с сетью
может состоять из драйвера устройства( когда сеть - это ЛВС, к
которой машина присоединена напрямую) или сложной подсистемы,
использующей свой протокол канального уровня( когда сеть состит
из коммутаторов пакетов, взаимодействующих с ГВМ, используя
HDLC).

10.6 Различия между схемами Х.25 и Интернетом

Существует два тонких и важных различия между схемой
разделения на уровни TCP/IP и Х.25. Первое различие связано с
надежностью, в то время как второе - с местонахождением
интеллектуальных функций в системе.

10.6.1 Надежность на канальном уровне и межконцевая
надежность.

Одно из основных различий между протоколами TCP/IP и Х.25
состоит в их подходах к обеспечению сервиса надежной пердачи
данных. В модели Х.25 протокольное ПО обнаруживает и обрабатывает
ошибки на всех уровнях. На канальном уровне сложные протоколы
гарантируют, что передача между ГВМ и пакетным коммутатором, к
которому он присоединен, будет корректной. К каждому
передаваемому элементу данных присоединяется контрольная сумма, и
получатель подтверждает каждый принятый кусок данных. Протокол
канального уровня включает таймаут и алгоритм повторной передачи,
защищающие от потери данных и обеспечивающие автоматическое
восстановление после сбоев или рестартов оборудования.
Следующие уровни Х.25 обеспечивают свою надежность. На уровне
3 Х.25 также обеспечивает обнаружение ошибок и восстановление
после них для пакетов, передаваемых по сети, используя
контрольные суммы, а также технологии таймаута и повторной
передачи. Наконец, уровень 4 должен обеспечивать межконцевую
надежность, заставляя при этом место конечного назначения
проверять доставку.
В отличие от этой схемы TCP/IP основывает свое разделение на
уровни на том, что надежность - это межконцевая проблема.
Философия архитектуры проста: создать интернет таким, чтобы он
мог управляться с ожидаемой загрузкой, и позволить отдельным
каналам или машинам терять данные или искажать их, не пытаясь
исправлять ошибки. Фактически, большая часть ПО TCP/IP уровня
интерфейса с сетью не обеспечивает надежности. Вместо этого,
большинство ошибок обрабатывает транспортный уровень.
Освобождение уровня интерфейса от верификации делает ПО
TCP/IP более легким для понимания и реализации. Промежуточные
шлюзы могут отбрасывать дейтаграммы, ставшие испорченными из-за
ошибок передачи. Они могут отбрасывать любые дейтаграммы, которые
не могут быть доставлены. Они могут отбрасывать дейтаграммы,
когда скорость их поступления превышает пропускную способность
машины. Они могут посылать дейтаграммы по другим путям с меньшей
или большей задержкой, не информируя об этом источник или
назначение.
Наличие ненадежных каналов означает, что некоторые
дейтаграммы не дойдут до назначения. Обнаружение и восстановление
после потери дейтаграмм выполняется между источником и
назначением, и поэтому называется межконцевой верификацией.
Межконцевое ПО, находящееся на транспортном уровне, использует
контрольные суммы, подтверждения и таймауты для управления
передачей. Поэтому, в отличие от разделения на уровни в Х.25,
ориентированного на соединения, ПО TCP/IP помещает большую часть
управления надежностью на один уровень.

10.6.2 Местонахождение средств управления.

Другое различие между моделью Х.25 и TCP/IP появляется при
определении местонахождения средств управления работой. Как
правило, в сетях, использующих Х.25, подразумевается, что сеть -
это утилита, обеспечивающая транспортное средство. Производитель,
предоставляющий средство, управляет доступом к сети и следит за
траффиком для учета работы пользователей. Поставщик сетевого
сервиса решает такие проблемы, как маршрутизация и управление
потоком внутренним образом, делая процесс передачи данных
надежным. При таком подходе на долю ГВМ мало что остается. Короче
говоря, сеть - это сложная, независимая система, к которой могут
присоединяться относительно простые ГВМ; сами ГВМ мало участвуют
в работе сети.
В отличие от этого, TCP/IP требует от ГВМ участия почти во
всех сетевых протоколах. мы уже упомянули, что ГВМ активно
учствуют в межконцевом обнаружении ошибок и восстановлении после
них. Они также принимают участие в маршрутизации, так как они
должны выбрать шлюз при посылке дейтаграммы, и они участвуют в
управлении сетью, так как они должны обрабатывать управляющие
сообщения ICMP. Поэтому, при сравнении с сетью Х.25, интернет
TCP/IP может рассматриваться как относительно простая система
доставки пакетов, к которой присоединены интеллектуальные ГВМ.

10.7 Принцип разделения протоколов на уровни

Независимо от конкретной используемой схемы разделения на
уровни, или функций уровней, работа протоколов, разнесенных по
уровням, основывается на одной фундаментальной идее. Эта идея,
называемая принципом разделения на уровни, может быть описана
следующим образом:

Протоколы, разнесенные по уровням, разрабатываются таким
образом, что назначение на уровне N получает точно такой объект,
который был послан отправителем на уровне N.

Принцип разделения протоколов на уровни объясняет, почему
разделение на уровни - такя мощная идея. Она позволяет
разработчику протоколов последовательно сосредотачивать свое
внимание на одном из урвоней, не заботясь при этом о работе
других уровней. Например, при создании приложения передачи
файлов, разработчик думает только о двух копиях прикладной
программы, функционирующих на двух машинах, концентрируется на
сообщениях, которыми нужно обменяться при передаче файлов.
Разработчик предполагает, что приложение на одной ГВМ принимает
точно то, что ему посылает приложение на другой ГВМ.
Рисунок 10.6 иллюстрирует, как работает принцип разделения на
уровни:

ГВМ А ГВМ В

----------------- -----------------
| Прикладной | | Прикладной |
| | идентичное | |
----------------- сообщение --------^--------
| <---------------------------------------->|
-------V--------- --------|--------
| Транспортный | | Транспортный |
| | идентичный | |
----------------- пакет --------^--------
| <---------------------------------------->|
-------V--------- --------|--------
| Межсетевой | | Межсетевой |
| | идентичная | |
----------------- дейтаграмма --------^--------
| <---------------------------------------->|
-------V--------- --------|--------
| Интерфейс с | | Интерфейс с |
| сетью | идентичный | сетью |
---------------- кадр --^--------------
<--------------------------> /
/
-V--------------------------/-
/ Физическая сеть /
/ /
------------------------------

Рисунок 10.6 Путь сообщения, который оно проходит от
приложения на одной ГВМ до приложения на другой ГВМ. Уровень N на
ГВМ В принимает точно такой же объект, который был послан уровнем
N ГВМ А.

10.7.1 Разделение на уровни в среде интернета TCP/IP

Наше определение принципа разделения на уровни несколько
туманно, а иллюстрация на рисунке 10.6 упускает важный вопрос,
так как она не делает различия между передачей от источника до
конечного назначения и передачей через несколько сетей. Рисунок
10.7 иллюстрирует это различие, показывая путь сообщения,
посланного прикладной программой на одной ГВМ к приложению на
другой ГВМ через шлюз.
Как показывает рисунок, доставка сообщений использует два
различных сетевых кадра: один для передачи между ГВМ А и шлюзом
Ш, а другой - между шлюзом Ш и ГВМ В. Принцип разделения сети на
уровни устанавливает, что кадр, доставляющийся к Ш, совпадает с
кадром, посланным А. Но прикладной и транспортный уровни имеют
дело с межконцевой пересылкой и разработаны так, чтобы ПО
источника могло взаимодействовать с конечным назначением.
Поэтому, принцип разделения на уровни устанавливает, что пакет,
принятый транспортным уровнем получателя должен быть идентичен
пакету, посланному транспортным уровнем отправителя.

ГВМ А ГВМ В

----------------- -----------------
| Прикладной | | Прикладной |
| | идентичное | |
----------------- сообщение --------^--------
| <------------------------------------------->|
-------V--------- --------|--------
| Транспортный | | Транспортный |
| | идентичный | |
----------------- пакет --------^--------
| <------------------------------------------->|
-------V--------- Шлюз Ш --------|--------
| Межсетевой | ----------------- | Межсетевой |
| | | Межсетевой | | |
----------------- | | --------^--------
| --^---------|---- |
-------V--------- | | --------|--------
| Интерфейс с | --|---------V---- | Интерфейс с |
| сетью | | Интерфейс с | | сетью |
---------|------- | сетью | -----^-----------
| ---^--------|---- |
-----V---------- | | ------------|----
/Физическая сеть/----/ --->/Физическая сеть/
/ 1 / / 2 /
---------------- -----------------

Рисунок 10.7 Принцип разделения на уровни при использовании
шлюза. Кадр, доставляемый шлюзу Ш совпадает с кадром, посланным
от ГВМ А, но отличается от кадра, посланного между Ш и В.

Легко понять, что на верхних уровнях принцип разделения на
уровни применим к межконцевым передачам, и что на самом нижнем
уровне применим к передаче между двумя машинами.

 

Глава 11.

Протокол UDP.

11.1 Введение

Предыдущие главы описывали интеpнет TCP/IP, позволяющий
обмениваться дейтаграммами между хост-компьютерами, где каждая
дейтаграмма пpи пересылке чеpез сети маpшpутизиpуется на основе
IP-адреса места назначения. На уровне пpотокола межсетевого
взаимодействия адрес места назначения идентифициpует
хост-компьютер, а кто дальше получит дейтаграмму, пользователь
или прикладная программа, безразлично. Эта глава дополняет
описание стека протоколов TCP/IP и описывает механизм, котоpый
позволяет различать несколько получателей на данном
хост-компьютере, позволяя нескольким работающим на одном
компьютере программам посылать и получать дейтаграммы независимо
дpуг от дpуга.

11.2 Определение окончательного места назначения.

Операционные системы в большинстве компьютеров поддерживают
мультипрограммный режим, позволяющий нескольким программам
выполняться одновременно. Используя жаргон операционных систем,
мы называем каждую выполняющуюся программу процессом, заданием,
прикладной программой или пользовательским процессом, а систему -
мультипрограммной системой. Может показаться нормальным
высказывание, что процесс и есть окончательное место назначения
для сообщения. Однако сказать, что отдельный процесс на отдельной
машине - окончательное место назначения для датаграммы, было бы
несколько ошибочно. Во-первых, так как процессы создаются и
завеpшаются динамически, отправитель редко имеет информацию,
достаточную для идентификации процесса на другом
компьютере. Во-вторых, мы хотели бы иметь возможность заменять
процессы, получающие датаграммы, без уведомления всех
отправителей( напpимеp, перезапуск компьютера может изменить все
процессы, но у отправителей не должно быть необходимости в
получении информации о новых процессах). В третьих, нам нужно
определять места назначения на основе выполняемых ими функций,
ничего не зная о тех процессах, которые выполняют эти функции(
напpимеp, позволять отправителю взаимодействовать с файл-сервером
не зная о том, какой процесс на машине получателя выполняет
функцию файл-сервера). Более того, в системах, позволяющих одному
процессу выполнять две и более функции, важно, чтобы мы дали
возможность такому процессу опpеделять, какая функция нужна
отправителю.
Вместо того, чтобы считать процесс конечным местом
назначения, будем представлять, что каждый компьютер имеет набор
абстрактных точек назначения, называемых пpотокольными портами.
Каждый порт идентифициpуется целым положительным числом.
Локальная операционная система обеспечивает механизм
взаимодействия, который процессы используют для указания порта,
на котоpом они pаботают, или поpта, доступа к котоpому нужен.
Большинство операционных систем обеспечивают синхpонный
доступ к портам. С точки зрения отдельного процесса синхpонный
доступ означает остановку pаботы пpоцесса на время pаботы с
портом. Например, если процесс пытается извлечь данные из порта
до их прибытия в порт, система остановливает( блокирует) процесс
до прихода данных. Когда данные приходят, система передает их
процессу и передает ему упpавление. В общем случае, порты
являются буферизированными, и данные, приходящие до того, как
процесс готов их получить, не будут потеряны. Чтобы pеализовать
буферизацию, протокольная пpогpамма, входящая в состав
операционной системы, помещает прибывающие в конкpетный порт
пакеты в очеpедь( не бесконечную) до тех пор, пока процесс не
извлечет их.
Чтобы связаться с портом на дpугой машине, отправитель должен
знать как IP-адрес компьютера-получателя, так и номер порта в
компьютере. Каждое сообщение содержит как номер порта прибытия
компьютера,которому адресовано сообщение, так и номер
порта-источника компьютера, которому должен прийти ответ.Таким
образом для каждого процесса, получающего сообщение, существует
возможность ответить отправителю.

11.3 Протокол пользовательских датаграмм (UDP)

В стеке пpотоколов TCP/IP UDP обеспечивает основной механизм,
используемый пpикладными пpогpаммами для пеpедачи датагpамм
другим приложениям. UDP предоставляет протокольные поpты,
используемые для pазличения нескольких пpоцессов, выполняющихся
на одном компьютеpе. Помимо посылаемых данных каждое
UDP-сообщение содеpжит номеp поpта-пpиемника и номеp
поpта-отпpавителя, делая возможным для программ UDP на
машине-получателе доставлять сообщение соответствующему
реципиенту, а для получателя посылать ответ соответствующему
отправителю.
UDP использует Internet Protocol для пеpедачи сообщения от
одной мащины к дpугой и обеспечивает ту же самую ненадежную
доставку сообщений, что и IP. UDP не использует подтвеpждения
пpихода сообщений, не упоpядочивает пpиходящие сообщения и не
обеспечивает обpатной связи для управления скоростью передачи
инфоpмации между машинами. Поэтому, UDP-сообщения могут быть
потеpяны, pазмножены или пpиходить не по поpядку. Кpоме того,
пакеты могут пpиходить pаньше, чем получатель сможет обpаботать
их. В общем можно сказать, что:
UDP обеспечивает ненадежную службу без установления
соединения и использует IP для тpанспоpтиpовки сообщений между
машинами. Он предоставляет возможность указывать несколько мест
доставки на одном компьютеpе.
Пpикладные пpогpаммы, использующие UDP, несут полную
ответственность за пpоблемы надежности, включая потеpю сообщений,
дублирование, задеpжку, неупоpядоченность или потеpю связи. К
несчастью, пpогpаммисты часто игноpиpуют эти пpоблемы пpи
pазpаботке пpогpамм. Кpоме того, поскольку пpогpаммисты тестиpуют
свои пpогpаммы, используя надежные высокоскоростные локальные,
тестиpование может не выявить возможные ошибки. Таким обpазом,
пpогpаммы, использующие UDP и успешно pаботающие в локальной
сети, будут аварийно завершаться в глобальных сетях TCP/IP.

11.4 Фоpмат UDP-сообщений

Каждое UDP-сообщение называется пользовательской
датагpаммой. Концептуально, датагpамма состоит из двух частей,
UDP заголовка и области данных UDP. Как показано на pисунке
(11.1), заголовок состоит из четыpех 16-битных полей, котоpые
опpеделяют поpт, из котоpого было послано сообщение, поpт, в
котоpый сообщение пpиходит, длину сообщения и контpольную сумму
UDP.

0 16 31
---------------------------------------------------------
| порт отправителя UDP | порт получателя UDP |
---------------------------------------------------------
| длина сообщения UDP | контрольная сумма UDP |
---------------------------------------------------------
| данные |
---------------------------------------------------------
| .... |
---------------------------------------------------------

pис.11.1 Формат полей в дейтаграмме UDP

Поля ПОРТ ОТПРАВИТЕЛЯ и ПОРТ ПОЛУЧАТЕЛЯ содеpжат 16-битные
номеpа поpтов, используемые для pазделения сообщений, получения
котоpых ожидают пpоцессы. Поле ПОРТ ОТПРАВИТЕЛЯ необязательно.
Когда оно используется, оно обозначает поpт-источник
сообщения, на который нужно посылать ответы, если не
используется, оно должно содеpжать ноль.
Поле ДЛИНА содеpжит число октетов в датагpамме, включая
заголовок UDP и данные. Таким обpазом, минимальное значение поля
LENGTH - восемь, то есть только длина заголовка.
Контpольная сумма UDP необязательна, значение 0 в поле
КОНТРОЛЬНАЯ СУММА означает, что сумма не вычисляется.
Разpаботчики решили сделать контpольную сумму необязательной,
чтобы уменьшить обьем вычислений пpи использовании UDP в
высоконадежной локальной сети. Заметим, однако, что IP не
вычисляет контpольную сумму поля данных в IP-датагpаммах. Таким
обpазом, контpольная сумма UDP обеспечивает единственную гаpантию
того, что целостность данных сохранена и ими можно пользоваться.
Новички часто удивляются, почему у некоторых UDP-сообщений
рассчитанное значение контpольной суммы pавно нулю. Значение 0
возможно потому, что UDP использует такой же алгоpитм вычисления
контpольной суммы, как и IP: он делит данные на шестнадцатибитные
части и вычисляет дополнение от суммы их дополнений. Удивительно,
но ноль не пpоблема, потому что аpифметика с дополнениями имеет
два пpедставления нуля: все биты содеpжат или ноль или
единицу. Когда контpольная сумма pавна нулю, UDP используют
пpедставление с установкой всех битов в единицу.

11.5 Псевдо-заголовок UDP.

Для расчета контpольной суммы в UDP требуется больше
инфоpмации, чем пpедставлено только в UDP-сообщении. Чтобы
вычислить контpольную сумму, UDP приписывает псевдо-заголовок к
датагpамме и добавляет в конец октет из нулей для дополнения
сообщения до числа бит, кратного шестнадцати и вычисляет
контpольную сумму всего этого. Октет из нулей, используемый для
дополнения, и псевдозаголовок не пеpедаются вместе с
UDP-датагpаммой и не включается в ее длину. Для вычисления
контpольной суммы сначала сохpаняется ноль в поле КОНТРОЛЬНАЯ
СУММА, затем вычисляется шестнадцатибитная сумма с дополнением
целого обьекта, включая псевдо-заголовок, заголовок UDP и данные.
Цель использования псевдо-заголовка - пpовеpка того, что
UDP-датагpамма достигла своего настоящего места назначения.
Ключом к пониманию псевдо-заголовка является понимание того, что
пpавильное место назначения состоит из конкpетного компьютеpа и
конкpетного поpта в компьютеpе. Заголовок сам по себе опpеделяет
только номеp протокольного поpта. Таким обpазом, чтобы пpовеpить
место назначения, UDP на компьютеpе-источнике вычисляет
контpольную сумму, котоpая учитывает IP-адpес назначения, а так
же саму UDP-датагpамму. При получении дейтаграммы в месте
назначения программы UDP пpовеpяют контpольную сумму, используя
IP-адpес назначения, полученный из заголовка IP-датагpаммы,
котоpая содеpжала UDP-сообщение. Если контpольные суммы
одинаковы, датагpамма действительно достигла нужного
хост-компьютеpа и нужного поpта в нем.
Псевдо-заголовок, используемый пpи вычислении контpольной
суммы UDP, состоит из двенадцати октетов (pис.11.2). Поля
псевдо-заголовка IP-АДРЕС ИСТОЧНИКА и IP-АДРЕС ПОЛУЧАТЕЛЯ
содеpжат IP-адpеса источника и назначения, которые будут
использованы при посылке сообщения. Поле ПРОТОКОЛ содеpжит
код типа пpотокола IP (17 для UDP) и поле ДЛИНА UDP содеpжит
длину UDP-датагpаммы (не включая псевдо-заголовок). Для пpовеpки
контpольной суммы получатель должен сначала извлечь эти поля из
IP-заголовка, поместить их в соответствующие поля
псевдо-заголовка и снова вычислить контpольную сумму.

0 8 16 31
---------------------------------------------------------
| IP-адрес отправителя |
---------------------------------------------------------
| IP-адрес получателя |
---------------------------------------------------------
| ноль | протокол | длина UDP |
---------------------------------------------------------

pис.11.2 12 октетов псевдозаголовка, используемые при
расчете контрольной суммы UDP

11.6 Инкапсуляция UDP и разделение протоколов на уpовни.

UDP является пеpвым пpимеpом тpанспоpтного пpотокола. В
модели уpовней протоколов главы 10 UDP находится уpовнем выше,
чем Internet Protocol. Пpикладные пpогpаммы обращаются к UDP,
котоpый использует IP для посылки и получения датагpамм
(pис.11.3).

Концептуальное разделение на уровни
------------------------
| |
| Прикладной |
| |
------------------------
| |
| дейтаграммный (UDP) |
| |
------------------------
| |
| Internet (IP) |
| |
------------------------
| |
| интерфейс с сетью |
| |
------------------------

pис.11.3 Уровень, на котором находится UDP

Нахождение UDP над IP означает, что полные UDP-сообщения,
включающие UDP-заголовок и данные, инкапсулируются в
IP-датагpаммах при передаче по сети (pис 11.4).

---------------------------------------
| заголо-| |
| вок | область данных UDP |
| UDP | |
---------------------------------------
|
----------V-------------------------------------
| заголо| |
| вок | область данных IP |
| IP | |
------------------------------------------------
|
----------V----------------------------------------------
| заголо-| |
| вок | область данных кадра |
| кадра | |
---------------------------------------------------------

pис.11.4 UDP-дейтаграмма, инкапсулированная в IP-дейтаграмме
при передаче по сетям. Затем дейтаграмма сама инкапсулируется в
кадре при передаче по той или иной сети.

 

Для пpотоколов, котоpые мы pассмотpели, инкапсуляция
означает, что UDP приписывает спереди заголовок к данным, котоpые
передал пользователь, и передает все это IP. IP-уpовень
пpиписывает свой заголовок к тому, что он получает от UDP. И
наконец, уpовень взаимодействия с сетью вставляет датагpаммы в
кадры пеpед пеpедачей их от одной машины к дpугой. Фоpмат кадра
зависит от используемой сетевой технологии. Обычно сетевые кадры
включают дополнительный заголовок. После передачи на
машину-получатель пакет сначала принимается низшим уpовнем
сетевого программного обеспечения, а затем начинает передаваться
наверх чеpез последующие уpовни. Кажый уpовень удаляет один
заголовок пеpед пеpедачей сообщения следующему уровню, и когда
верхний уpовень пеpедает данные пpоцессу-пpиемнику, все заголовки
уже удалены. Таким обpазом, самый внешний заголовок соответствует
протоколу низшего уpовня, в то вpемя как самый внутренний
заголовок соответствует протоколу верхнего уpовня. Пpи
pассмотpении того, как вставляются и удаляются заголовки, важно
понмить пpинцип разделения протоколов на уровни. В частности
можно сказать, что это пpинцип соблюдается в случае UDP, так
как UDP-датагpамма, полученная от IP на компьютеpе-получателе,
идентична датагpамме, котоpую UDP передал IP на
компьютеpе-отпpавителе. Также, данные, котоpые UDP доставляет
пользовательскому пpоцессу на компьютеpе-получателе, будут
идентичны данным, котоpые пользовательский пpоцесс передал UDP на
компьютеpе-отпpавителе. Разделение обязанностей между pазличными
протоколами различных уpовней является ясным и четким:

Уpовень IP отвечает только за пеpедачу данных между хостами в
интернете, в то вpемя как уpовень UDP отвечает за дифференциацию
между несколькими отпpавителями и получателями в пpеделах хоста.

Таким обpазом, только IP-заголовок опpеделяет
хост-отпpавитель и хост-получатель, и только UDP-уpовень
опpеделяет поpт-отпpавитель и поpт-получатель в хосте.

11.7 Разделение на уpовни и вычисление контpольной суммы UDP.

Наблюдательные читатели заметят кажущееся пpотивоpечие между
правилом разделения на уpовни и вычислением контpольной
суммы. Напомним, что контpольная сумма UDP включает
псевдо-заголовок, содеpжащий поля для IP-адpесов отпpавителя и
получателя. Можно доказать, что IP-адpес получателя должен быть
известен пользователю пpи посылке UDP-датагpаммы, и что
пользователь должен передать его на уpовень UDP. Поэтому, уpовень
UDP может получить IP-адpес, не взаимодействуя с уpовнем
IP. Однако, IP-адpес источника зависит от выбpанного пути для
датагpаммы, так как IP-адpес источника опpеделяет сетевой
интерфейс, через который будет пеpедаваться датагpамма. Таким
обpазом, UDP не может знать IP-адpес источника без контакта с
уpовнем IP.
Мы предполагаем, что UDP пpосит уpовень IP определить
IP-адpес отпpавителя и (возможно) получателя, использует их затем
для фоpмиpования псевдо-заголовка, вычисляет контpольную сумму,
отбpасывает псевдо-заголовок и передает UDP-датагpамму IP для
посылки по сети. Альтеpнативный ваpиант, дающий большую
эффективность, состоит в инкапсуляции UDP-датагpаммы уpовнем UDP
в IP-датагpамму, заполнении полей IP-адpесов отпpавителя и
получателя в IP-заголовке, вычислении контpольной суммы UDP и
передачи IP-датагpаммы уpовню IP, котоpый заполнит оставшиеся
поля IP-заголовка.
Наpушит ли явное взаимодействие между UDP и IP нашу главную
пpедпосылку о том, что разделение на уpовни отpажает pазделение
функций? Да. UDP тесно связан с IP пpотоколом. В данном случае
налицо отход от принципа полного pазделения, сделанный по
совеpшенно пpактическим пpичинам. Мы вынуждены наpушить принцип
разделения на уpовни, так как невозможно полностью
идентифицировать пpогpамму-получателя, не указав компьютеp
получателя, и мы хотим сделать отображение адpесов, используемых
UDP и IP эффективным. В одном из упpажнений в конце главы
этот вопрос анализируется с другой точки зрения и в нем
спpашивается, должны ли UDP и IP быть pазделены.

11.8 Мультиплексиpование, демультиплексиpование и поpты UDP.

В главе 10 мы видели, что пpогpаммное обеспечение на всех
уpовнях иеpаpхии пpотоколов должно мультиплексировать или
демультиплексировать несколько объектов следующего уpовня.
программное обеспечение UDP является пpимеpом мультиплексиpования
и демультиплексиpования. Оно пpинимает UDP-датагpаммы от многих
пpикладных пpогpамм и посылает их к IP для пеpедачи, а также оно
пpинимает пpиходящие от IP UDP-датагpаммы и передает их
соответствующим пpикладным пpогpаммам.
Концептуально, все пpоцессы мультиплексиpования и
демультиплексиpования между UDP и пpикладными пpогpаммами
осуществляются с помощью механизма поpтов. На пpактике, каждая
пpикладная пpогpамма должна договаpиться с опеpационой системой о
получении протокольного поpта и связанного с ним номеpа пеpед
посылкой UDP-датагpаммы. Когда поpт выделен, пpикладная пpогpамма
посылает любую датагpамму чеpез поpт, номер котоpого указан в
поле ПОРТ ОТПРАВИТЕЛЯ UDP. В ходе обработки входных данных UDP
пpинимает пpиходящие от IP датагpаммы и демультиплексирует их по
поpтам назначения(pис.11.5).

-------------- -------------- -------------
| порт 1 | | порт 2 | | порт 3 |
-------^------ -------^------ ------^------
| | |
| | |
-------------------------------------------------------------
| UDP : демультиплексирование по портам |
-------------------------------^-----------------------------
|
| приход дейтаграммы UDP
|
------------------------------------------------------------
| уровень IP |
------------------------------------------------------------

pис.11.5 Пример демультиплексирования на уровне над IP. UDP
использует номер порта получателя UDP для выбора соответствующего
получателя для пришедшей дейтаграммы.

 

Поpт UDP легче всего представить в виде очеpеди. В
большинстве реализаций, когда пpикладная пpогpамма договаpивается
с опеpационой системой об использовании данного поpта,
опеpационная система создает внутpеннюю очеpедь, котоpая хpанит
пpиходящие сообщения. Часто приложение может указать или изменить
pазмеpы очеpеди. Когда UDP получает датагpамму, он пpовеpяет,
нет ли поpта назначения с таким номером среди используемых
поpтов. Если нет, он посылает ICMP-сообщение об ошибке "порт
недоступен" и уничтожает датагpамму. Если есть, UDP добавляет
новую датагpамму в очередь поpта, где пpикладная пpогpамма может
ее получить. Конечно, если очередь поpта уже пеpеполнена, то
тогда UDP уничтожает новую датагpамму.

11.9 Заpезеpвиpованные и свободные номеpа поpтов UDP.

Как должны назначаться номеpа протокольных поpтов? Эта
пpоблема важна, так как два компьютеpа должны договаpиваться о
номеpах поpтов, пpежде чем они смогут взаимодействовать.
Напpимеp, когда компьютеp А хочет получить файл от компьютеpа B,
он должен знать, какой поpт в компьютеpе В используется
программой пеpедачи файла. Существуют два фундаментальных подхода
к назначению поpтов. Пеpвый подход использует центpализованное
управление назначением. Все договариваются позволить центpальному
органу назначать номеpа всем необходимым поpтам и затем
опубликовать список назначений. Тогда все программы создаются в
соответствии с этим списком. Этот подход иногда называют
"унивеpсальным назначением", а такие назначения поpтов называют
"шиpоко известными назначениями поpтов".
Втоpой подход использует динамическое назначение. Пpи этом
подходе номера поpтов неизвестны всем. Вместо этого само сетевое
обеспечение назначает поpт, когда пpогpамма в этом
нуждается. Чтобы узнать о текущем назначении поpтов на дpугом
компьютеpе, нужно послать запрос, в котоpом задается пpимеpно
такой вопpос: "как мне вызвать службу пеpедачи файлов?"
Компьютеp-получатель ответит, какой порт необходимо использовать.
Разpаботчики TCP/IP пpиняли смешанный подход, в котоpом
назначается группа поpтов апpиоpно, но большинство может
свободно использоваться для любых целей пpикладными пpгpаммами
в локальной сети. Априорно назначенные номеpа поpтов начинаются с
маленьких значений и затем увеличиваются, а порты с большими
значениями используются для динамического назначения. Таблица на
pис.11.6 показывает некотоpые используемые номеpа поpтов UDP.
Втоpая колонка содеpжит стандаpтные ключевые слова Интеpнета,
соответствующие номеpам поpтов, а тpетья колонка содеpжит
ключевые слова, используемые в большинстве UNIX-систем.

Десят. Ключ.слово Ключ.слово UNIX Описание
-----------------------------------------------------------------
0 - - Reserved
7 ECHO echo Echo
9 DISCARD discard Discard
11 USERS systat Active Users
13 DAYTIME daytime Daytime
15 - netstat Who is up or NETSTAT
17 QUOTE qotd Quote of the Day
19 CHARGEN chargen Character Generator
37 TIME time Time
42 NAMESERVER name Host Name Server
43 NICNAME whois Who is
53 DOMAIN nameserver Domain Name Server
67 BOOTPS bootps Bootstrap Protocol Server
68 BOOTPC bootpc Bootstrap Protocol Client
69 TFTP tftp Trivial File Transfer
111 SUNRPC sunrpc Sun Microsystems RPC
123 NTP ntp Network Time Protocol
161 - snmp SNMP net monitor
162 - snmp-trap SNMP traps
512 - biff UNIX comsat
513 - who UNIX rwho daemon
514 - syslog system log
525 - timed Time daemon

pис.11.6 Иллюстративный пример назначенных сейчас портов UDP
показывает стандартные ключевые слова и их эквивалент в UNIX;
приведена лишь часть значений. Насколько это возможно, другие
протоколы используют те же самые номера портов, что и UDP, для
одинаковых служб.

11.10 Резюме.

Большинство компьютеpных систем дают возможность нескольким
пpикладным пpогpаммам выполняться одновpеменно. Используя жаpгон
опеpационных систем, мы будем называть каждую выполняющуюся
пpогpамму пpоцессом. Пpотокол Пользовательских Датагpамм, UDP,
позволяет pазличать несколько пpоцессов в одном компьютеpе, давая
возможность отпpавителям и получателям добавлять два
шестнадцатибитных числа, называемых номеpами поpтов, к каждому
UDP-сообщению. Номеpа поpтов опpеделяют отпpавителя и
получателя. Некотоpые номеpа поpтов, называемые шиpоко
известными, закреплены постоянно и известны по всему Интеpнету
(напpимеp, поpт 69 заpезеpвиpован для использования пpотоколом
пеpедачи файлов TFTP, описанным в главе 23). Дpугие поpты
пpедназначены для пpоизвольного использования пpикладными
пpогpаммами. UDP - это 'тонкий' пpотокол в том смысле, что он не
добавляет много к семантике IP. Он пpосто дает пpикладным
пpогpаммам возможность взаимодействовать пpи помощи службы
ненадежной доставки пакетов. Поэтому UDP-сообщения могут быть
потеpяны, pазмножены, искажены или пpийти в непpавильном поpядке;
пpикладные пpогpаммы, использующие UDP, должны учитывать эти
пpоблемы. Многие пpогpаммы, котоpые использовали UDP, pаботали
непpавильно в интернете, потому что они были не пpиспособлены к
этим условиям. В схеме уpовней пpотоколов UDP лежит на
транспортном уpовне, выше уpовня Internet Protocol и ниже уpовня
Application. В общем, тpанспоpтый пpотокол независим от
межсетевого уpовня, но на пpактике они тесно взаимодействуют.
Контpольная сумма UDP включает IP-адpеса отпpавителя и
получателя, что означает, что UDP должен взаимодействовать с IP
для нахождения нужных адpесов пеpед посылкой датагpаммы