Понятие протокола, и связанные с ним понятия
| Вид материала | Документы |
- Программа курса лекций, 33.31kb.
- А, а также связанные с этим сервисы, частично или полностью через пакетные сети, 211.32kb.
- Тема Основные понятия о правовых явлениях, 165.32kb.
- Контрольная работа по предмету «Логика», 57.32kb.
- Понятия налоги и налогообложение. Налоговая система понятие налога и сбора. Принципы, 2182.16kb.
- Задачи: Продолжить формирование понятия о внутренней среде и ее компонентах. Раскрыть, 161.91kb.
- Естественные науки 14 апреля с 10. 00 до 17., 82.95kb.
- Словари профессий, 47.56kb.
- Программа форума «служба протокола» день первый (02. 06. 2011г., четверг), 114.5kb.
- Программа форума «служба протокола» день первый (02. 06. 2011г., четверг), 107.69kb.
Протоколы, обслуживающие стек TCP/IP.
Состав и структура системы протоколов межсетевого (Internet) уровня стека TCP/IP.
Рассмотрение протокола IP будет неполным, если мы оставим без внимания на другие протоколы уровня межсетевого взаимодействия, непосредственно обслуживающие его. Мы уже вскользь упоминали их, когда рассматривали общую структуру стека TCP/IP.
Между большим разнообразием протоколов уровня приложений процессов (которое все пополняется по мере создания новых сетевых сервисов), и не меньшим разнообразием протоколов уровня сетевого интерфейса (также постоянно пополняющимся), находится сравнительно небольшая группа протоколов транспортного и сетевого уровня, которые собственно и делают Internet Internetом.
Протоколы транспортного уровня TCP (Transmission Control Protocol) и UDP (User Datagram Protocol) обеспечивают доставку между процессами на различных узлах сети Internet.
Оба они предполагают, что доставку пакетов данных между соответствующими узлами обеспечивается протоколом IP.
Но функционирование протокола IP поддерживается рядом других протоколов того же уровня.
Всякая сложная система для правильного функционирования нуждается в своей системе управления, а система управления – в системе связи. В случае Internet – «сети сетей» – устройства, осуществляющие соединение различных сетей, называемые маршрутизаторами (router), или шлюзами (gateway), для обеспечения управления общаются друг с другом посредством ряда протоколов, древнейшим из них является протокол Gateway to Gateway Protocol (GGP), сейчас уже почти вымерший. Эти протоколы мы рассмотрим позднее, когда подробно будим разбирать IP-маршрутизацию.
Иногда шлюз или компьютер, получающий данные, обменивается информацией управления с компьютером, отправляющим эти данные. Именно для таких целей используется протокол контрольных сообщений Internet ICMP (Internet Control Message Protocol).
Оригинальная версия спецификации ICMP-протокола – документ RFC-792 размещается на сервере ISI (Information Sciences Institute):
URL = ссылка скрыта
Для преобразования адресов, используемых IP-протоколом в адреса конкретных сетей (физические адреса) и обратно используются протоколы ARP (Address Resolution Protocol) и RARP (Reverse Address Resolution Protocol).
Оригинальная версия спецификации ARP-протокола – документ RFC-826 размещается на сервере ISI (Information Sciences Institute):
URL = ссылка скрыта
Оригинальная версия спецификации RARP-протокола – документ RFC-903 размещается на сервере ISI (Information Sciences Institute):
URL = ссылка скрыта
Протокол контрольных сообщений Internet ICMP.
ICMP использует своих сообщений пакеты протокола Internet (IP), как если бы ICMP являлся протоколом более высокого уровня. Однако фактически ICMP является составной частью протокола Internet и должен являться составной частью каждого модуля IP. Заметим, что и номер RFC-792, описывающего протокол ICMP, идет сразу за номером RFC-791, описывающего протокол IP.
Сообщения ICMP должны отправляться в некоторых затруднительных ситуациях. Например, когда пакет не может достичь своего адресата, когда шлюз не имеет достаточно места в своем буфере для передачи какого-либо пакета, или когда шлюз приказывает хост-компьютеру отправлять информацию по более короткому маршруту.
Протокол IP не обеспечивает абсолютную надежность передачи информации. Целью контрольных сообщений является обеспечение обратной связи, оповещение отправителя данных о проблемах, возникающих в коммуникационном оборудовании. Их целью не является придание надежности протоколу IP. Протокол не дает гарантий, что пакет достигает своего адресата или что контрольное сообщение будет возвращено компьютеру, отправившему данные. Некоторые из пакетов могут исчезнуть в сети, не вызвав при этом ни каких оповещений (хотя бы потому, что за их потерю могут быть ответственны физический и канальный уровни OSI). Кроме того, сами сообщения могут быть потеряны. И даже в случае, когда сообщение информирует IP модуль узла о потере пакета, IP модуль не организует его повторную передачу. Протоколы более высокого уровня, использующие протокол IP, должны применять свои собственные процедуры для обеспечения надежности передачи данных, если таковая требуется.
Сообщения ICMP протокола, как правило, оповещают об ошибках, возникающих при обработке пакетов. Чтобы проблемы с передачей сообщений не вызывали появление новых сообщений, чтобы это в свою очередь не привело к лавинообразному росту количества сообщений, циркулирующих в сети, установлено, что нельзя посылать сообщения о сообщениях8. Также констатируется, что ICMP сообщения можно посылать только о проблемах, возникающих при обработке нулевого фрагмента в сегментированном пакете (нулевой фрагмент имеет нуль в поле смещения фрагмента). Кроме того, ICMP сообщения не посылаются, если проблема возникла с пакетом, имеющим групповой (multicast) или широковещательный (broadcast) адрес получателя. То же относится к пакетам, имеющим адрес отправителя, не указывающий конкретный узел (loopback, групповой, широковещательный, нулевой), либо отправленных на широковещательный локальный адрес.
Форматы сообщений
ICMP сообщения посылаются с помощью стандартного IP пакета. Первый байт в поле данных пакета – это поле типа ICMP сообщения. Значение этого поля определяет формат всех остальных данных в пакете. Любое поле, которое помечено "unused", зарегистрировано для последующих разработок, и должно при отправлении содержать нули. Если обратное особо не оговорено при описании отдельных форматов, IP заголовок должен иметь в своих полях следующие значения:
Версия=4
Тип сервиса=0
Время жизни Поскольку значение этого поля уменьшается на единицу в каждой IP-системе, на которой обрабатывается данный пакет, то значение этого поля должно, по крайней мере, превышать количество шлюзов, через которые будет проходить пакет.
Протокол: ICMP=1
Адрес отправления=Адрес шлюза или хост-компьютера, который составил данное ICMP сообщение. Если не оговорено обратное, в этом поле может находиться любой из адресов шлюза.
С
ообщение о недостижимости адресатаПоля ICMP протокола:
Тип=3
Код
0 – невозможно передать пакет локальной сети, где находится адресат
1 – невозможно передать пакет узлу, являющийся адресатом
2 – нельзя воспользоваться указанным протоколом
3 – нельзя передать данные на указанный порт
4 – для передачи пакета по сети требуется фрагментация, но установлен флаг DF. В этом случае в поле, помеченное как unused, может быть записано значение MTU (Maximum Transportation Unit) на следующем шаге.
5 – сбой в маршрутизации при отправлении (это означает, что в пакете присутствуют опции маршрутизации от источника, либо записи маршрута, но они не поддерживаются маршрутизаторами на маршруте). На этом кончаются коды, определенные RFC-792. впоследствии были определенны дополнительные коды:
6 – неизвестна сеть назначения – destination network unknown.
7 – неизвестен хост назначения – destination host unknown.
8 – хост источник изолирован – source host isolated.
9 – сеть назначения закрыта администратором – destination network administrativrly prohibited.
10 – хост назначения закрыт администратором – destination host administrativrly prohibited.
11 – сеть недоступна для TOS – network unreachable for TOS.
12 – хост недоступен для TOS – host unreachable for TOS.
13 – связь административно закрыта путем фильтрации – communication administratively prohibited by filtering.
14 – нарушено старшинство для хоста – host precedence violation.
15 – старшинство разъединено – precedence cutoff in effect.
Контрольная сумма является 16-битным дополнением до единицы суммы дополнений 16-битных слов во всех полях ICMP сообщения, начиная с поля типа ICMP. Для вычисления контрольной суммы первоначально значение этого поля обнуляется. В отличии от протокола IP, контрольная сумма ICMP охватывает все сообщение, а не только заголовок. Аналогичным образом поступают протоколы IGMP, TCP, UDP. Но процедура расчета контрольной суммы осталась прежней.
Internet заголовок + 64 бита данных из исходного пакета – если протокол более высокого уровня использует номера портов, то предполагается, что эти номера находятся в первых 64 битах поля данных9. Транспортные протоколы Internet – TCP и UDP – этому условию удовлетворяют. Таким образом, получатель сообщения может идентифицировать пакет, вызвавший проблему.
Если, согласно информации в таблицах маршрутизации шлюза, локальная сеть, указанная в заголовке IP пакета в поле адресата, является недостижимой, например, из-за ее чрезмерной удаленности, то шлюз может послать хост-компьютеру, отправившему пакет, сообщение о недостижимости адресата.
Кроме этого, в некоторых сетях шлюз может иметь возможность определять доступность отдельного хост-компьютера. Шлюз в такой сети может послать данное сообщение, если хост-компьютер, являющийся адресатом, недоступен.
Когда для достижения адресата пакет должен быть разбит шлюзом на отдельные фрагменты, но установлен флаг запрета фрагментации, шлюз обязан ликвидировать пакет и может при этом послать сообщение о недостижимости адресата.
Наконец, на узле-адресате может отсутствовать требуемый протокол, либо не быть открыт порт протокола транспортного уровня.
Таким образом, шлюз может послать сообщения с кодами 0, 1, 4 и 5. Хост – с кодами 2 и 3.
Сообщение о превышении контрольного времени
Формат тот же, поля:
Тип=11
Код:
0 – при передаче превышено время жизни.
1 – превышено контрольное время при сборке фрагментов пакета.
Если фрагмент нулевого размера превысил контрольное время, то сообщение в этом не посылается вовсе.
Шлюз может послать сообщение с кодом 0, а хост - с кодом 1.
Сообщение о проблемах с параметром
Формат
Поля:
Тип=12
Код: 0 - указатель показывает ошибку, 1 – требуемая опция не установлена.
Если шлюз или хост-компьютер, обрабатывающий пакет, обнаруживает проблему с обработкой параметров заголовка, и это не позволяет завершить его обработку, то он должен ликвидировать пакет. Поскольку в случае проблем с адресом или протоколом генерируется сообщение о недостижимости адресата, а при обнулении времени жизни – сообщение о превышении контрольного времени, причиной такой ситуации обычно являются неправильные аргументы в опции. Сообщения такого типа посылаются только в том случае, если ошибка приводит к ликвидации пакета.
Код 1 чаще всего относится к отсутствию опции безопасности.
Сообщение для приостановки отправителя
Формат стандартный, поля:
Тип=4
Код=0
Это сообщение обеспечивает примитивную форму управления потоком на сетевом уровне. Шлюз может ликвидировать IP-пакеты, если у него нет места в буфере для постановки их в очередь на отправление в очередную сеть по маршруту следования к адресату. В этом случае он должен послать сообщение для приостановки хост-компьютеру, отправившему пакет. Сообщение о приостановке может послать также сам адресат, если пакеты приходят слишком быстро, чтобы успеть их обработать. Сообщение о приостановке является запросом для хост-компьютера уменьшить скорость посылки данных на этот конкретный адрес. Шлюз может посылать сообщение для приостановки отправителя в каждом случае ликвидации. При получении такого сообщения хост-компьютер, отправивший данные, должен уменьшить скорость посылки данных по этому адресу до тех пор, пока не перестанут приходить запросы на приостановку с данного шлюза. После этого хост-компьютер, отправляющий данные, может постепенно увеличивать скорость посылки данных по этому адресу, пока вновь не станут приходить сообщения о приостановке.
Шлюз или хост-компьютер может посылать сообщение о приостановке еще до достижения предельной пропускной способности, и не ждать, пока этот предел будет пройден. Это означает, что пакет с данными, вызвавший появление сообщения о приостановке, все же может достичь своего адресата. И шлюз и хост-компьютер могут отправить сообщение с кодом 0.
Сообщение о переадресации
Ф
ормат Поля:
Тип=5
Код:
0 - переадресация пакетов для сети.
1 - переадресация пакетов для хост-компьютера.
2 - переадресация пакетов для типа услуг и сети.
3 - переадресация пакетов для типа услуг и хост-компьютера.
Internet адрес шлюза – Адрес шлюза, на который должен быть проложен маршрут к сети, указанной в поле адреса в исходном пакете с данными.
Шлюз посылает сообщение на хост-компьютер о переадресации в следующей ситуации: Шлюз G1 получает IP пакет от хост-компьютера. Шлюз G1 проверяет таблицу маршрутизации и находит адрес следующего шлюза G2 в маршрута для пакета по пути в сеть X, где расположен ее адресат. Если G2 и исходный хост-компьютер идентифицируются IP адресом как находящиеся в одной и той же сети, то хосту-отправителю следует послать сообщение о переадресации. Сообщение о переадресации заставляет хост-компьютер впредь посылать пакеты для сети X прямо на шлюз G2, поскольку это более короткий путь, чем через шлюз G1. Шлюз G1 передает исходный пакет адресату.
Для пакетов с опциями IP маршрутизации отправления и адресом шлюза в поле получателя сообщение не посылается, даже если существует более оптимальный маршрут к конечному адресату, чем следующий адрес, указанный в такой опции маршрута.
Э
хо-сообщение и сообщение в ответ на эхоФормат
Поля
Тип
8- эхо-сообщение
0- сообщение в ответ на эхо
Код=0
Идентификатор
Если код = 0, то идентификатор для соотнесения эхо-сообщений и ответов на них, должен быть обнулен.
Номер очереди
Если код = 0, то номер очереди, служащий для соотнесения эхо-сообщений и ответов на них, должен быть обнулен.
Данные из эхо-сообщения должны быть переданы в ответе на это сообщение.
Идентификатор и номер очереди может использоваться отправителем эхо-сообщения с целью идентификации приходящих пакетов. Например, идентификатор может использоваться в качестве порта подобно протоколам TCP и UDP для идентификации сеанса. Номер очереди может увеличиваться на единицу при посылке каждого эхо сообщения (запроса). Компьютер, отозвавшийся на это сообщение, возвращает в своем ответе те же значения для идентификатора и номера очереди, что были в исходном эхо-сообщении.
Как шлюз, так и хост-компьютер могут возвращать сообщение с кодом 0.
Примером применения такого сообщения может служить команда ping, позволяющая определить доступность определенного узла.
Сообщение со штампом времени и ответ на штамп времени
Формат
Поля:
Тип:
13 для сообщения со штампом времени
14 для ответа на сообщение со штампом времени
Код=0
Идентификатор
Если код = 0, то идентификатор, служащий для соотнесения сообщений со штампом времени и ответов на них, должен быть обнулен.
Номер очереди
Если код = 0, то номер очереди, служащий для соотнесения сообщений со штампом времени и ответов на них, должен быть обнулен.
Данные из сообщения (штамп времени) возвращаются вместе с ответом, при этом в них добавляется еще один штамп времени. Штамп времени – это 32 бита, где записано время в миллисекундах, прошедшее после полуночи по единому времени (UT).
Штамп времени отправления – это время, которое отправитель фиксировал последний раз перед посылкой сообщения.
Штамп времени получения – это время, когда исходное сообщение впервые увидел получатель первоначального сообщения.
Штамп времени передачи – это время, которое фиксировал в последний раз компьютер, отправляющий ответное сообщение.
Если нет возможности измерять время в миллисекундах или нельзя определить единое время (UT), то в штамп все же можно занести имеющееся время, снабдив его единицей в старшем бите. Последнее также указывает на запись нестандартного значения в этом поле.
Запрос информации и ответное сообщение с информацией
Формат:
Поля:
Тип
15 - сообщение с запросом информации
16 - ответное сообщение с информацией
Код=0
Идентификатор
Если код = 0, то идентификатор, служащий для соотнесения запросов и ответов, может быть обнулен.
Номер очереди
Если код = 0, то номер очереди, служащий для соотнесения запросов и ответов, может быть обнулен.
Данное сообщение может быть послано, когда в IP заголовке в полях отправителя и получателя записаны нули (этот хост–этой сети). В ответ должен быть послан IP–пакет с полностью заданными адресами. Данное сообщение является способом, с помощью которого хост-компьютер сможет определить номер сети, куда он подключен. Сейчас считается устаревшим.
Список сообщений неполон, соответствует спецификации RFC-792. В лекции по адресации мы уже познакомились с еще одной парой сообщений:
A
ddress Mask Request (код 17) и Address Mask Reply (код 18). Данные типы сообщений описаны в документе RFC-950 "Internet Standard Subnetting Procedure".В документе RFC-1256 описаны еще два типа ICMP сообщений. Они используются маршрутизаторами для информирования узлов сети об имеющихся маршрутах, рассылаются по адресу 224.0.0.1 (всем узлам), либо широковещательно, периодически (раз в 450-600 сек) либо по запросу.
Router Advertisement:
Здесь число адресов – число объявленных маршрутов,
длина адреса – длина описания маршрута в 32-битных словах, всегда равна 2 (адрес+приоритет).
Адрес и приоритет – описание маршрута, повторяются для «число адресов» маршрутов. Приоритетность маршрута тем выше, чем выше приоритет. Маршрут по умолчанию имеет приоритет 0.
Поле время жизни предназначено для записи продолжительности жизни объявленных маршрутов (адресов) в секундах (по умолчанию 30 мин).
Д
ля запроса маршрутной информации (Router Advertisement Request) узлы используется сообщение типа 10:Протоколы ARP/RARP.
Протоколы ARP и RARP осуществляют отображение физических адресов на IP-адреса.
В протоколе IP-адрес узла, то есть адрес компьютера или порта маршрутизатора, назначается произвольно администратором сети и прямо не связан с его локальным адресом. Подход, используемый в IP, удобно использовать в крупных сетях и по причине его независимости от формата локального адреса, и по причине стабильности, так как в противном случае, при смене на компьютере сетевого адаптера это изменение должны бы были учитывать все адресаты всемирной сети Internet (в том случае, конечно, если сеть подключена к Internet'у).
Для определения локального адреса по IP-адресу используется протокол разрешения адреса Address Resolution Protocol, ARP. Протокол ARP работает различным образом в зависимости от того, какой протокол канального уровня работает в данной сети - протокол локальной сети (Ethernet, Token Ring, FDDI) с возможностью широковещательного доступа одновременно ко всем узлам сети, или же протокол глобальной сети (X.25, Frame Relay), как правило, не поддерживающий широковещательный доступ. Существует также протокол, решающий обратную задачу – нахождение IP-адреса по известному локальному адресу. Он называется реверсивный ARP – RARP (Reverse Address Resolution Protocol) и используется при старте станций, не знающих в начальный момент своего IP-адреса, но знающих адрес своего сетевого адаптера.
Узел, которому нужно выполнить отображение IP-адреса на локальный адрес, формирует ARP запрос, вкладывает его в кадр протокола канального уровня, указывая в нем известный IP-адрес, и рассылает запрос широковещательно. Все узлы локальной сети получают ARP запрос и сравнивают указанный там IP-адрес с собственным. В случае их совпадения узел формирует ARP-ответ, в котором указывает свой IP-адрес и свой локальный адрес и отправляет его уже направленно, так как в ARP запросе отправитель указывает свой локальный адрес. ARP-запросы и ответы используют один и тот же формат пакета. Так как локальные адреса могут в различных типах сетей иметь различную длину, то формат пакета протокола ARP зависит от типа сети.
Формат ARP пакета для локальной сети
Тип локальной сети 2 байта (Тип ЛС)
Тип сетевого протокола 2 байта (не только IP=080016)
Длина локального адреса 1 байт
Длина сетевого адреса 1 байт
Тип операции 2 байта (1 – ARP запрос, 2 – ARP ответ.)
Локальный адрес отправителя
Сетевой адрес отправителя
Искомый локальный адрес
Искомый сетевой адрес
Узел, отправляющий ARP-запрос, заполняет в пакете все поля, кроме поля искомого локального адреса (для RARP-запроса не указывается искомый IP-адрес). Значение этого поля заполняется узлом, опознавшим свой IP-адрес.
В общем случае ARP-ответ может отправляться не обязательно искомым узлом, вместо него это может сделать другой узел. Например, узел подключен через модем к серверу удаленного доступа. Сервер выделяет подключенному узлу IP-адрес из адресного пространства сети, в которой он сам находится, поэтому остальные узлы той же сети полагают, что могут отправить пакет этому узлу непосредственно. В этом случае на запрос об MAC-адресе подключенного узла отвечает сервер удаленного доступа, сообщая свой MAC-адрес. Приняв пакет для удаленного узла, сервер удаленного доступа доставляет пакет по назначению по коммутируемому каналу. Такой механизм называется proxy ARP.
Другим вариантом является установка маски сети на узлах в 0, в результате узлы считают все адреса локальными. На ARP-запрос о физическом адресе удаленного узла при этом отвечает маршрутизатор, который берет на себя доставку пакета.
В глобальных сетях администратору сети обычно приходится вручную формировать ARP-таблицы, в которых он задает, например, соответствие IP-адреса адресу узла сети X.25, который имеет смысл локального адреса. Спецификации RFC-1356 и RFC-1490, определяющие передачу IP-трафика поверх сетей X.25 и Frame Relay не определяют никакого динамического протокола, который позволял бы автоматизировать этот процесс. Работа протокола ARP поверх ATM-сетей описана в RFC-1577. Особенностью сетей Frame Relay является преимущественное формирование виртуальных каналов вручную администратором, вследствие чего ARP-таблицы в этих сетях устанавливают соответствие IP-адресов не адресам узлов как таковым, а номерам заранее сформированных виртуальных каналов. В последнее время наметилась тенденция автоматизации работы протокола ARP и в глобальных сетях. Для этой цели среди всех маршрутизаторов, подключенных к какой-либо глобальной сети, выделяется специальный маршрутизатор, который ведет ARP-таблицу для всех остальных узлов и маршрутизаторов этой сети. При таком централизованном подходе для всех узлов и маршрутизаторов вручную нужно задать только IP-адрес и локальный адрес выделенного маршрутизатора. Затем каждый узел и маршрутизатор регистрирует свои адреса в выделенном маршрутизаторе, а при необходимости установления соответствия между IP-адресом и локальным адресом узел обращается к выделенному маршрутизатору с запросом и автоматически получает ответ без участия администратора.
Протокол RARP решает обратную задачу – получение сетевого адреса по известному локальному. Основное назначение этого протокола – обеспечение IP адресами бездисковых станций. Такая станция в момент запуска знает свой аппаратный адрес, но не знает сетевого (запись IP-адреса в ПЗУ не всегда удобна – ведь станция может быть перемещена в другую сеть). Протокол RARP позволяет такой станции узнать свой IP адрес. Формат запросов/ответов протокола RARP аналогичен формату ARP, даже коды операций – 3 для запроса, 4 для ответа – как бы продолжают перечень команд ARP, и создают впечатление, что речь идет об одном и том же протоколе. Но механизм реализации RARP существенно отличается от ARP.
ARP запрос обрабатывался узлом, опознавшим свой адрес, а в случае RARP узел этого адреса не знает, поэтому даже в локальной сети RARP требует наличия сервера, который хранит таблицу соответствия локальных и сетевых адресов. Поскольку стартующая бездисковая станция не знает адреса этого сервера, запрос RARP, как и запрос ARP, посылается широковещательно. При этом ARP и RARP имеют разные поля типа протокола (например, для Ethernet ARP=800616, RARP=803516), так что принимают запрос все узлы, но обрабатывает его и отвечает только RARP-сервер. RARP-серверов в локальной сети может быть несколько, чтобы обеспечить старт бездисковых станций и в том случае, когда один из них неисправен или просто выключен.
Заметим, что формат RARP-запроса позволяет получать информацию об IP-адресе не только своего, а любого узла, если это почему-то необходимо. В то же время для динамического конфигурирования бездисковых станций он недостаточно функционален – он сообщает только IP-адрес. Маску сети и информацию о маршрутах узел должен получать отдельно, например, посредством ICMP сообщений Address Mask Request/Replay, Router Advertisement и т.д. В настоящее время существуют протоколы, предоставляющие узлу более полную конфигурационную информацию – BOOTP, DHCP, а для коммутируемых соединений такую функцию выполняет протокол NCP – составная часть протокола PPP.