Адресация Internet

Адресация Internet

Каждый интерфейс в объединенной сети должен иметь уникальный IP адрес. Эти адреса представляют из себя тридцатидвухбитовые числа. Cуществует определенная структура адреса Internet. На рисунке 1.5 показано 5 классов адресов Internet.
Эти 32-битные адреса обычно записываются как 4 десятичных числа, по одному на каждый байт адреса. Такая форма записи называется "десятичной записью с точками" (dotted-decimal). Например, адрес сети класса B может быть записан как 140.252.13.33.
Определить класс адреса, или класс сети, можно по первому числу в адресе. На рисунке 1.6 показаны различные классы, причем первое число выделено.


Рисунок 1.5 Пять классов адресов Internet.

Класс	Диапазон
A	0.0.0.0 - 127.255.255.255
B	128.0.0.0 - 191.255.255.255
C	192.0.0.0 - 223.255.255.255
D	224.0.0.0 - 239.255.255.255
E	240.0.0.0 - 247.255.255.255

Рисунок 1.6 Диапазоны IP адресов в разных классах сетей.





Здесь хотелось бы отметить, что хосты с несколькими интерфейсами имеют несколько IP адресов: по одному на каждый интерфейс.
Так как каждый интерфейс, подключенный к сети, должен иметь уникальный адрес, встает вопрос распределения IP адресов в глобальной сети Internet. Этим занимается сетевой информационный центр (Internet Network Information Center или InterNIC). InterNIC назначает только сетевые идентификаторы (ID). Назначением идентификаторов хостов в сети занимаются системные администраторы.


Регистрация сервисов Internet (IP адреса и имена доменов DNS) осуществляется в NIC, nic.ddn.mil. InterNIC была создана 1 апреля 1993 года. В настоящее время NIC регистрирует сервисы только для сети министерства обороны (DDN - Defence Data Network). Все другие пользователи Internet в настоящее время используют регистрационный сервис InterNIC в rs.internic.net.
Реально существует три части InterNIC: регистрационный сервис (rs.internic.net), сервис баз данных (ds.internic.net) и информационный сервис (is.internic.net). См. Упражнение 8 главы 1.


Существует три типа IP адресов: персональный адрес (unicast) - указывает на один хост, широковещательный адрес (broadcast) - указывает на все хосты в указанной сети, и групповой адрес (multicast) - указывает на группу хостов, принадлежащей к группе адресации. В главе 12 и главе 13 мы рассмотрим широковещательные и групповые запросы более подробно.
В разделе "Адресация подсетей" главы 3 мы продолжим описание IP адресации, включая подсети, после того как опишем IP маршрутизацию. На рисунке 3.9 показаны особые случаи IP адресов: идентификатор хоста и идентификатор сети, установленные во все нули или во все единицы.

Демультиплексирование (Demultiplexing)

Демультиплексирование (Demultiplexing)

Когда фрейм Ethernet принимается компьютером приемником, он начинает свой путь вверх по стеку протоколов, при этом все заголовки удаляются в соответствующих уровнях. Каждый протокол просматривает определенные идентификаторы в заголовке, чтобы определить, какой следующий верхний уровень должен получить данные. Этот процесс называется демультиплексированием (demultiplexing), он проиллюстрирован на рисунке 1.8.


Рисунок 1.8 Демультиплексирование полученного Ethernet фрейма.





Местоположение квадратиков, помеченных именами протоколов "ICMP" и "IGMP", всегда различно. На рисунке 1.4 мы показали их на том же уровне, что и IP, потому что в действительности они являются дополнением к протоколу IP. Однако здесь мы показали их выше чем IP, чтобы подчеркнуть то, что сообщения ICMP и IGMP инкапсулируются в IP датаграммы.
Тот же самый подход был использован с квадратиками, помеченными "ARP" и "RARP". Здесь мы показали их выше чем драйвер устройства Ethernet, потому что оба они имеют свой собственный тип фреймов Ethernet, как IP датаграммы. Однако на рисунке 2.4 мы покажем ARP как часть драйвера устройства Ethernet, что будет более логично.
Естественно, что рисунки, иллюстрирующие протоколы и их взаимодействия, всегда несовершенны.


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

Инкапсуляция

Инкапсуляция

Когда приложение посылает данные с использованием TCP, данные опускаются вниз по стеку протоколов, проходя через каждый уровень, до тех пор пока они не будут отправлены в виде потока битов по сети. Каждый уровень добавляет свою информацию к данным путем пристыковки заголовков (а иногда завершителей). На рисунке 1.7 показан этот процесс. Блок данных, который TCP посылает в IP, называется TCP сегментом. Блок данных, который IP посылает в сетевой интерфейс, называется IP датаграммой. Поток битов, который передается по Ethernet, называется фреймом (frame).
Числа, стоящие под заголовком и завершителем Ethernet фрейма на рисунке 1.7, показывают стандартный размер заголовков в байтах. В следующих разделах мы расскажем о заголовках более подробно.
Одной из физических характеристик фрейма Ethernet является та, что размер данных должен быть в диапазоне между 46 и 1500 байт. Минимальный размер мы обсудим в разделе "Примеры ARP" главы 4, а максимальный в разделе "MTU" главы 2.


Все стандарты Internet и большинство книг про TCP/IP используют термин октет (octet) вместо слова байт. Такая терминология сложилась исторически, однако мы будем использовать именно слово байт (byte).
Чтобы быть максимально точными, рассматривая рисунок 1.7, мы должны сказать, что блок данных, передаваемый между IP и сетевым интерфейсом, называется пакетом (packet). Этот пакет может быть как IP датаграммой, так и фрагментом IP датаграммы. Мы рассмотрим фрагментацию более подробно в разделе "Фрагментация IP" главы 11.


Что касается UDP данных, то картина там практически идентичная. Единственное различие заключается в том, что блок информации, который UDP передает в IP, называется UDP датаграммой, а размер UDP заголовка составляет 8 байт.


Рисунок 1.7 Инкапсуляция данных, осуществляемая по мере того, как они проходят по стеку протоколов.





Снова обратимся к рисунку 1.4, на котором показано как TCP, UDP, ICMP и IGMP посылают данные в IP. IP должен добавить какой-либо идентификатор к IP заголовку, который он генерирует, чтобы указать какому уровню принадлежат данные. IP делает это путем сохранения восьмибитного значения в своем заголовке, которое называется полем протокола. Это значение равно 1 для ICMP, 2 для IGMP, 6 для TCP и 17 для UDP.
Точно так же различные приложения могут использовать TCP или UDP в одно и то же время. Протоколы транспортного уровня сохраняют в заголовке идентификатор приложения, которое их использует. TCP и UDP оба используют шестнадцатибитный номер порта (port number), чтобы указать на приложения. TCP и UDP сохраняют номер порта источника и номер порта назначения в своих заголовках.
Сетевой интерфейс посылает и принимает фреймы, принадлежащие IP, ARP и RARP. Должна существовать форма идентификации в заголовке Ethernet, которая бы указывала, какой сетевой уровень сгенерировал данные. Для этого существует шестнадцатибитное поле типа фрейма в заголовке Ethernet.

Интерфейсы прикладного программирования

Интерфейсы прикладного программирования

Два популярных интерфейса прикладного программирования (API - application programming interface) для приложений, использующих протоколы TCP/IP, называются сокетами (sockets) и интерфейсом транспортного уровня (TLI - Transport Layer Interface) . Первый иногда называется "Berkeley sockets", что указывает на то где он был разработан. Последний, исходно разработанный в AT&T, иногда называется XTI (X/Open Transport Interface), это работа, произведенная X/Open, международной группой поставщиков компьютеров, которые создали свой собственный набор стандартов. XTI в действительности является расширением TLI.
При написании этой книги мы не задавались целью подробно рассматривать низкий уровень программирования, однако, где это возможно, будем ссылаться на отдельные характеристики TCP/IP, в частности на большинство популярных API. Все детали программирования, как для сокет так и для TLI, можно найти в [Stevens 1990].

Internet

Internet

На рисунке 1.3 показано соединение двух сетей - Ethernet и Token ring. В разделах "Адресация Internet" и "Номера портов" главы 1 мы говорили о глобальной сети Internet и о необходимости централизованного распределения IP адресов (InterNIC), а также о заранее известных номерах портов (IANA) . Само слово internet имеет различный смысл, в зависимости от того, начинается ли оно с большой буквы или с маленькой.
Слово internet означает несколько сетей, соединенных вместе, использующих общее семейство протоколов. Слово Internet, начинающееся с большой буквы, обозначает определенное количество компьютеров (более миллиона), находящихся по всему миру, которые могут общаться друг с другом с использованием TCP/IP. Поэтому Internet это internet, а не наоборот.

Краткие выводы

Краткие выводы

В этой главе мы совершили короткое путешествие в огромный мир семейства протоколов TCP/IP, представили большинство терминов и протоколов, которые будут обсуждены более подробно в следующих главах.
Существует четыре уровня семейства протоколов TCP/IP - канальный уровень (link layer), сетевой уровень (network layer), транспортный уровень (transport layer) и прикладной уровень (application layer). Мы показали, за что отвечает каждый из этих уровней. В TCP/IP существуют серьезные различия между сетевым и транспортным уровнями: сетевой уровень (IP) предоставляет сервис, не ориентированный на соединение (пересылка за пересылкой - hop-by-hop), тогда как транспортный уровень предоставляет сервис с соединением (точка в точку - end-to-end) (TCP и UDP).
"internet" это несколько сетей. Основное средство, используемое для объединения сетей (internet) это маршрутизатор, который соединяет сети на IP уровне. Заглавная "I" в слове "Internet" обозначает сеть, которая охватывает весь земной шар.
В сети каждый интерфейс имеет уникальный IP адрес, однако пользователи могут использовать имена хостов вместо IP адресов. Система имен доменов (DNS) позволяет установить динамическое соответствие между именами хостов и IP адресами. Номера портов используются для идентификации приложений, общающихся друг с другом. При этом мы сказали, что сервера используют заранее-известные порты (well-known), тогда как клиенты используют динамически назначаемые порты (ephemeral port).

Модель Клиент-Сервер

Модель Клиент-Сервер

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


Рисунок 1.8.1 Алгоритм работы последоватеьного сервера

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


Рисунок 1.8.2 Алгоритм работы конкурентного сервера

Запуск нового сервера на шаге К2 для обработки запроса клиента может выглядеть как создание нового процесса, задачи, в зависимости от того какая операционная система лежит в основе этого сервера. Новый сервер обрабатывает поступивший запрос клиента целиком. По завершении сервер уничтожается.
Преимущество конкурентного сервера заключается в том, что он просто запускает другие сервера для обработки запросов от клиентов. В подобном случае каждый клиент имеет собственный сервер. Предполагается, что операционная система поддерживает многозадачность и обслуживание нескольких клиентов одновременно.
Мы подразделили именно сервера, а не клиентов, специально, потому что в обычных условиях клиент не может сказать, с каким сервером, последовательным или конкурирующим, он общается.
В общем случае, серверы TCP - конкурентные, а серверы UDP - последовательные. Однако из этого правила могут быть исключения. Более подробно мы рассмотрим UDP серверы в разделе "Сервер UDP" главы 11, а TCP серверы - в разделе "Реализация TCP сервера" главы 18.

Номера портов

Номера портов

Как мы уже сказали, TCP и UDP идентифицируют приложения с использованием 16-битных номеров порта. Рассмотрим, как выбираются эти номера портов.
Обычно серверы знают свои заранее известные (well-known) номера портов. Например, каждая реализация TCP/IP, предоставляющая FTP сервер, знает, что сервисный порт TCP номер 21 зарезервирован для FTP сервиса. Каждый Telnet сервер имеет порт номер 23. Каждая реализация TFTP (Trivial File Transfer Protocol) использует UDP порт 69. Подобные сервисы, предоставляемые в любой реализации TCP/IP, имеют заранее известные номера портов в диапазоне от 1 до 1023. Заранее известные порты обслуживаются Internet Assigned Numbers Authority (IANA).


До 1992 года номера заранее известных портов находились в диапазоне от 1 до 255. Порты между 256 и 1023 обычно использовались UNIX системами для специальных сервисов. Эти сервисы присутствовали в UNIX системах, однако могли не присутствовать в других операционных системах. В настоящее время IANA обслуживает порты в диапазоне от 1 до 1023.
В качестве примера различия между Internet сервисом и специализированным UNIX сервисом можно показать различие между Telnet и Rlogin. Оба позволяют осуществить терминальный заход по сети на удаленный компьютер. Telnet это стандарт TCP/IP с номером заранее известного порта 23. Он поддерживается практически во всех операционных системах. Rlogin, с другой стороны, исходно был разработан в UNIX системах (однако многие не UNIX системы в настоящее время также предоставляют этот сервис). Однако заранее известный порт был выбран в начале 80-годов и установлен в значение 513.


Клиент обычно не заботится о том, какой порт используется с его стороны. Все что ему необходимо, это быть уверенным, что данный номер порта уникален на его компьютере. Номер порта клиента называется динамически назначаемым портом (ephemeral port), то есть портом с коротким временем жизни. Это объясняется тем, что клиент обычно существует ровно столько времени, сколько пользователь нуждается в клиентском сервисе, тогда как сервера функционируют все время, пока запущен компьютер.
Большинство реализаций TCP/IP располагают номера динамически назначаемых портов в диапазоне значений между 1024 и 5000. Номера портов свыше 5000 предназначены для других серверов (не зарезервированных в сети Internet) . Далее по тексту мы встретим множество примеров того, как располагаются или назначаются динамически назначаемые порты.


Solaris 2.2 является исключением. По умолчанию, динамически назначаемые порты TCP и UDP начинаются с 32768. В разделе "Solaris 2.2" приложения E подробно рассматриваются опции конфигурирования, которые могут быть модифицированы системным администратором, чтобы изменить установки по умолчанию.


В большинстве UNIX систем номера заранее известных портов находятся в файле /etc/services. Чтобы найти номер порта для сервера Telnet и Domain Name System, можно исполнить следующую команду:


sun % grep telnet /etc/services
telnet 23/tcp используется порт TCP 23
sun % grep domain /etc/services
domain 53/udp используются порты UDP 53
domain 53/tcp и TCP порт 53

Процесс стандартизации

Процесс стандартизации

Кто контролирует семейство протоколов TCP/IP, добавляет новые стандарты и так далее? Существует 4 группы, которые несут ответственность за технологию Internet.

Internet Society (ISOC) это сообщество профессионалов, которое отвечает за настройку и поддержку роста Internet как мировой исследовательской коммуникационной инфраструктуры.

Internet Architecture Board (IAB) занимается технической координацией. Состоит примерно из 15 добровольцев по всему миру, которые отвечают за различные дисциплины и являются последней инстанцией при принятии и оценке качества стандартов Internet. IAB находится под управлением ISOC.

Internet Engineering Task Force (IETF) - группа, занимающаяся стандартами. Поделена на 9 зон (приложения, маршрутизация и адресация, безопасность, и так далее). IETF разрабатывает спецификации, которые становятся стандартами Internet. В помощь IETF была сформирована группа Internet Engineering Steering Group (IESG).

Internet Research Task Force (IRTF) занимается долговременными проектами.

IRTF и IETF находятся под управлением IAB. [Crocker 1993] предоставляет дополнительную информацию о процессе стандартизации в рамках Internet.

Реализации

Реализации

Де факто стандарт для реализаций TCP/IP появился в группе компьютерных исследований Калифорнийского университета в Berkeley. Исторически он распространялся с 4.x BSD system (Berkeley Software Distribution), и с BSD Networking Releases. Исходные тексты этой реализации явились отправной точкой для множества последующих.
На рисунке 1.10 показана хронология появления различных релизов BSD и указаны важнейшие характеристики TCP/IP. BSD Networking Releases, показанный слева, свободно распространяемый исходный код, который содержит все исходные сетевые коды: как самих протоколов, так и большинства приложений и утилит (таких как Telnet и FTP).


Надо сказать, что довольно сложно вычислить, когда и как появился релиз Net/3.


По тексту мы используем термин "реализации, произошедшие от Berkeley" или "Berkeley реализации", чтобы указать на следующие реализации: SunOS 4.x, SVR4, и AIX 3.2, которые были разработаны с использованием исходных текстов Berkeley.


Рисунок 1.10 Различные релизы BSD и их важнейшие функции.





Эти реализации имеют очень много общего, включая одни и те же ошибки!
Большинство исследований в Internet до сих пор осуществляется с использованием системы Berkeley - новые алгоритмы предотвращения переполнения (глава 21, раздел "Быстрая повторная передача и алгоритм быстрого восстановления"), групповые запросы (глава 12, раздел "Рассылка групповых сообщений"), работа с каналами с повышенной пропускной способностью (глава 24, раздел "Каналы с повышенной пропускной способностью (Long Fat Pipes)") и так далее.

RFC

RFC

Все официальные стандарты сообщества internet публикуются в Request for Comment, или в RFC. В дополнение, существует множество RFC, которые не являются официальными стандартами, однако они публикуются с информационными целями. Диапазон размеров RFC колеблется от 1 до почти 200 страниц. Каждый из них имеет собственный номер.
Все RFC доступны бесплатно по электронной почте или с использованием FTP через Internet. Послать электронную почту можно следующим образом:


To: rfc-info@ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs


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

Assigned Numbers RFC содержит в себе все числа и константы, которые используются в протоколах Internet. В настоящее время самая последняя версия этого RFC имеет номер 1340 [Reynolds and Postel 1992]. Также здесь описаны все заранее известные порты глобальной сети Internet.

Когда RFC обновляется (обычно это происходит ежегодно), список индексов для 1340 указывает, какой RFC заменил его.

Официальные стандарты протоколов Internet (Internet Official Protocol Standards), в настоящее время RFC 1600 [Postel 1994]. Этот RFC содержит информацию о состоянии стандартизации различных протоколов Internet. Каждый протокол имеет одно из следующих состояний стандартизации: стандарт, необязательный стандарт, рекомендованный стандарт, экспериментальный, информационный, или исторический. В дополнение, каждый протокол имеет уровень необходимости: необходим, рекомендуется, на выбор, с ограниченным использованием, или не рекомендуется.

Как и Assigned Numbers RFC, этот RFC регулярно переиздается. При чтении этого RFC убедитесь, что Вы используете последнюю копию.

Требования к хостам Host Requirements RFC, 1122 и 1123 [Braden 1989a, 1989b]. RFC 1122 описывает канальный уровень, сетевой уровень и транспортный уровень, тогда как RFC 1123 описывает прикладной уровень. Эти два RFC корректируют и интерпретируют различные важные RFC, вышедшие раньше, и часто являются исходной точкой при изучении деталей того или иного протокола. Список характеристик и конкретных подробностей протоколов следующий: "должен", "следует", "может", "не следует" или "не должен".

[Borman 1993b] приводит практический взгляд на эти два RFC, а RFC 1127 [Braden 1989c] содержит краткий информационный справочник дискуссий и выводов в рабочих группах, которые разрабатывали Host Requirements RFC.

Требования к маршрутизаторам Router Requirements RFC. Официальная версия этого RFC - RFC 1009 [Braden and Postel 1987], однако новая версия близка к завершению [Almquist 1993]. Это RFC напоминает RFC требования к компьютерам, однако содержит уникальные требования к маршрутизаторам.

Система имен доменов (DNS - Domain Name System)

Система имен доменов (DNS - Domain Name System)

Несмотря на то что каждый сетевой интерфейс компьютера имеет свой собственный IP адрес, пользователи привыкли работать с именами хостов. Существует распределенная мировая база данных TCP/IP, называемая системой имен доменов (DNS - Domain Name System), которая позволяет установить соответствие между IP адресами и именами хостов. В главе 14 мы рассмотрим DNS более подробно.
А теперь мы должны быть уверены, что любое приложение может вызвать функцию из стандартной библиотеки, для того чтобы определить IP адрес (или адреса, соответствующие данному имени хоста). Точно так же эта функция предоставляет возможность осуществить и обратную процедуру, то есть по заданному IP адресу определить соответствующее имя хоста.
Большинство приложений, которые воспринимают имя хоста в качестве аргумента, также воспринимают и IP адреса. Когда мы используем Telnet, в главе 4, например, в одном случае мы указываем имя хоста, а в другом случае - IP адрес.

Стандартные простые сервисы

Стандартные простые сервисы

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


Если повнимательнее посмотреть на номера портов этих и других стандартных сервисов TCP/IP (Telnet, FTP, SMTP, и так далее), то можно заметить, что большинство из них имеют нечетные номера. Так сложилось исторически, так как номера портов были заимствованы от номеров портов NCP. Протокол управления сетью (NCP - Network Control Protocol) предшествовал TCP в качестве транспортного уровня для ARPANET. NCP был симплексный, не полнодуплексный, каждое приложение требовало двух соединений, поэтому пара четных-нечетных чисел в качестве номеров портов, была зарезервирована для каждого приложения. Когда TCP и UDP стали стандартными транспортными уровнями, на каждое приложение потребовался один номер порта, поэтому в качестве номеров порта были использованы нечетные номера портов NCP.

Имя	порт TCP	порт UDP	RFC	Описание
echo	7	7	862	Сервер возвращает все посланное клиентом
discard	9	9	863	Сервер игнорирует все посланное клиентом
daytime	13	13	867	Сервер выдает время и дату в читаемом формате
chargen	19	19	864	TCP сервер посылает продолжающийся поток символов, до тех пор пока соединение не будет разорвано клиентом. UDP сервер посылает датаграммы с произвольным количеством каждый раз когда пользователь посылает датаграмму
time	37	37	868	Сервер выдает время как 32-х битовое бинарное число. Это число означает количество секунд с полуночи 1- го Января 1900, UTC.

Рисунок 1.9 Стандартные сервисы, предоставляемые большинством реализаций.

Тестируемая сеть

Тестируемая сеть

На рисунке 1.11 показана тестируемая сеть, которая используется для всех примеров в тексте этой книги.


Рисунок 1.11 Сеть, используемая для всех примеров в тексте. Все IP адреса начинаются с 140.252.





Большинство примеров запускаются на четырех системах, которые показаны в нижней части рисунка. Все IP адреса на этом рисунке принадлежат сети класса B 140.252. Все имена хостов принадлежат домену .tuc.noao.edu (noao это "National Optical Astronomy Observatories", а tuc это Tuscon). Например, нижняя правая система имеет полное имя хоста svr4.tuc.noao.edu с IP адресом 140.252.13.34. Над каждым квадратиком указана операционная система, под управлением которой работает данный компьютер. Подобный набор систем и сетей, компьютеров и маршрутизаторов позволяет подробно рассмотреть различные реализации TCP/IP.
Необходимо отметить, что в действительности, в домене noao.edu значительно больше сетей и хостов, нежели тех, что показаны на рисунке 1.11. Однако здесь показаны те системы, которые использовались в качестве примеров в книге.
В разделе "Адресация подсетей" главы 3 мы опишем способ деления этой сети на подсети, а в разделе "Уполномоченный агент ARP" главы 4 подробно рассмотрим dialup SLIP (IP по последовательной линии с дозвоном) соединения между sun и netb. В разделе "SLIP: IP по последовательной линии" главы 2 SLIP описан более подробно.

Упражнения

Упражнения

Вычислите максимально возможное количество компьютеров в сетях класса A, B и C.

Воспользовавшись анонимным FTP (глава 27, раздел "Примеры FTP"), получите файл nfsnet/statistics/history.netcount с хоста ftp://nic.merit.edu. В этом файле содержится количество местных и иностранных сетей, объявленных в инфраструктуре NFSNET. Распределите полное количество сетей по годам (по оси ОХ - годы, по OY - количество сетей). Максимальное значение по оси OY должно совпадать со значением, рассчитанным в предыдущем упражнении. Если данные примерно совпадут, экстраполируйте значения, чтобы оценить, когда текущая схема адресации переполнится сетевыми идентификаторами (раздел "Будущее IP" главы 3 рассказывает о том, как можно решить подобную проблему).

Достаньте копию Host Requirements RFC [Braden 1989a] и рассмотрите принцип непотопляемости (robustness principle) , который применяется к каждому уровню семейства протоколов TCP/IP. Какое применение можно найти для этого принципа?

Получите копию последнего Assigned Numbers RFC. Каков зарезервированный порт протокола "quote of the day"? Какой RFC определяет этот протокол?

Имеете ли Вы компьютер, который подключен к сети TCP/IP, какой его основной IP адрес? Подключен ли этот компьютер к мировой сети Internet? Имеет ли он несколько интерфейсов?

Получите копию RFC 1000, чтобы понять, откуда появился термин RFC.

Установите контакт с сообществом Internet, isoc@isoc.org или + 1 703 648 9888, чтобы получить информацию о вступлении.

Получите файл about-internic/information-about-the-internic, используя анонимный FTP с хоста ftp://is.internic.net.

Назад
Компания | Услуги | Для клиентов | Библиотека | Галерея | Cофт | Линки
На главную

Уровни TCP/IP

Уровни TCP/IP

В действительности, семейство протоколов TCP/IP объединяет значительно больше протоколов. На рисунке 1.4 показаны некоторые дополнительные протоколы, которые мы рассмотрим в книге.


Рисунок 1.4 Различные протоколы на разных уровнях семейства протоколов TCP/IP.





TCP и UDP - два основных протокола транспортного уровня. Оба используют IP в качестве сетевого уровня.
TCP предоставляет надежный транспортный уровень, даже несмотря на то что он использует ненадежный сервис IP. В главах 17, 18, 19, 20, 21 и 22 мы подробно рассмотрим функционирование TCP. Затем мы рассмотрим некоторые приложения TCP: Telnet и Rlogin в главе 26, FTP в главе 27 и SMTP в главе 28. Приложения - это, как правило, пользовательские процессы.
UDP отправляет и принимает датаграммы (datagram). Датаграмма это блок информации (определенное количество байт информации, которое указывается отправителем), который отправляется от отправителя к приемнику. В отличие от TCP, UDP является ненадежным протоколом. Не существует гарантий, что датаграмма достигнет конечной точки назначения. В главе 11 мы рассмотрим UDP, а затем в главе 14 - систему имен доменов (Domain Name System), в главе 15 - простой протокол передачи файлов (Trivial File Transfer Protocol) и в главе 16 - протокол загрузки (Bootstrap Protocol). Это приложения, которые используют UDP. SNMP (Простой протокол управления сетью - Simple Network Management Protocol) также использует UDP, однако он работает с некоторыми другими протоколами, которые мы будем рассматривать вплоть до главы 25.
IP это основной протокол сетевого уровня. Он используется как TCP, так и UDP. Каждый блок информации TCP и UDP, который передается по объединенным сетям, проходит через IP уровень в каждой конечной системе и в каждом промежуточном маршрутизаторе. На рисунке 1.4 показаны приложения, которые имеют прямой доступ к IP. Такой доступ используется довольно редко, но существует возможность его осуществить (некоторые ранние протоколы маршрутизации были разработаны именно подобным образом). Также в процессе экспериментов при создании новых транспортных уровней используется возможность доступа к протоколу IP. В главе 3 рассматривается протокол IP, более подробно IP рассматривается в последующих главах. В главе 9 и главе 10 рассказывают о том как осуществляется IP маршрутизация.
ICMP является дополнением к протоколу IP. Он используется IP уровнем для обмена сообщениями об ошибках и другой жизненно важной информацией уровня IP. Глава 6 рассказывает об ICMP более подробно. Несмотря на то, что ICMP используется в основном IP уровнем, приложения также могут получить доступ к ICMP. Мы рассмотрим два наиболее популярных диагностических средства, Ping и Traceroute (глава 7 и глава 8), использующих ICMP.
Протокол управления группами Internet (IGMP - Internet Groupe Management Protocol), используется при групповой адресации: при этом UDP датаграммы рассылаются нескольким получателям. Мы опишем основные особенности широковещательной адресации (рассылка UDP датаграмм каждому компьютеру в указанной сети) и групповой адресации в главе 12, а затем опишем сам IGMP в главе 13.
Протокол определения адреса (ARP - Address Resolution Protocol) и обратный протокол определения адреса (RARP - Reverse Address Resolution Protocol) это специализированные протоколы, используемые только с определенным типом сетевых интерфейсов (такие как Ethernet и Token ring). Они применяются для преобразования формата адресов, используемого IP уровнем в формат адресов, используемый сетевым интерфейсом. Мы рассмотрим эти протоколы в главе 4 и главе 5 соответственно.

Уровни

Уровни

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

Прикладной	Telnet, FTP, e-mail и т.д.
Транспортный	TCP,UDP
Сетевой	IP, ICMP, IGMP
Канальный	драйвер устройства и интерфейсная плата

Рисунок 1.1 Четыре уровня протоколов TCP/IP.


Каждый уровень несет собственную функциональную нагрузку.

Канальный уровень (link layer). Еще его называют уровнем сетевого интефейса. Обычно включает в себя драйвер устройства в операционной системе и соответствующую сетевую интерфейсную плату в компьютере. Вместе они обеспечивают аппаратную поддержку физического соединения с сетью (с кабелем или с другой используемой средой передачи).

Сетевой уровень (network layer), иногда называемый уровнем межсетевого взаимодействия, отвечает за передачу пакетов по сети. Маршрутизация пакетов осуществляется именно на этом уровне. IP (Internet Protocol - протокол Internet), ICMP (Internet Control Message Protocol - протокол управления сообщениями Internet) и IGMP (Internet Group Management Protocol - протокол управления группами Internet) обеспечивают сетевой уровень в семействе протоколов TCP/IP.

Транспортный уровень (transport layer) отвечает за передачу потока данных между двумя компьютерами и обеспечивает работу прикладного уровня, который находится выше. В семействе протоколов TCP/IP существует два транспортных протокола: TCP (Transmission Control Protocol) и UDP (User Datagram Protocol). TCP осуществляет надежную передачу данных между двумя компьютерами. Он обеспечивает деление данных, передающихся от одного приложения к другому, на пакеты подходящего для сетевого уровня размера, подтверждение принятых пакетов, установку тайм-аутов, в течение которых должно прийти подтверждение на пакет, и так далее. Так как надежность передачи данных гарантируется на транспортном уровне, на прикладном уровне эти детали игнорируются. UDP предоставляет более простой сервис для прикладного уровня. Он просто отсылает пакеты, которые называются датаграммами (datagram) от одного компьютера к другому. При этом нет никакой гарантии, что датаграмма дойдет до пункта назначения. За надежность передачи данных, при использовании датаграмм отвечает прикладной уровень. Для каждого транспортного протокола существуют различные приложения, которые их используют.

Прикладной уровень (application layer) определяет детали каждого конкретного приложения. Существует несколько распространенных приложений TCP/IP, которые присутствуют практически в каждой реализации:

Telnet - удаленный терминал

FTP, File Transfer Protocol - протокол передачи файлов

SMTP, Simple Mail Transfer Protocol - простой протокол передачи электронной почты

SNMP, Simple Network Management Protocol - простой протокол управления сетью.

Если у нас есть два компьютера в локальной сети, (например, Ethernet) и на обоих запущен FTP, то данные протоколы будут работать так, как показано на рисунке 1.2.


Рисунок 1.2 Два хоста в локальной сети с работающим FTP.





Мы пометили один квадратик на прикладном уровне как FTP клиент, а другой как FTP сервер. Большинство сетевых приложений работают именно таким образом, то есть, на одном конце клиент, а на другом сервер. Сервер предоставляет некоторые типы сервиса клиентам. В данном случае это доступ к файлам на сервере. Telnet предоставляет сервис, позволяющий клиенту зайти на сервер удаленным терминалом.
Каждый уровень имеет один или несколько протоколов, который позволяет общаться с удаленным узлом на том же уровне. Один протокол, например, позволяет общаться двум TCP уровням, а другой протокол обеспечивает коммуникации между двумя IP уровнями.
С правой стороны на рисунке 1.2 мы видим, что прикладной уровень обеспечивается пользовательским процессом, тогда как три нижних уровня обычно встроены в ядро операционной системы. Несмотря на то, что возможны и другие способы реализации, во всех UNIX системах все построено именно по такому принципу.
Существует еще одно отличие между верхним уровнем и тремя нижними уровнями, приведенными на рисунке 1.2. Прикладной уровень обычно является приложением и взаимодействует с пользователем, а не занимается передачей данных по сети. Три нижних уровня ничего не знают о работающих над ними приложениях, однако отвечают за все детали коммуникаций.
На рисунке 1.2 мы показали четыре протокола, каждый на своем уровне. FTP это протокол прикладного уровня, TCP - протокол транспортного уровня, IP - протокол сетевого уровня, а протоколы Ethernet обеспечивают канальный уровень. Семейство протоколов TCP/IP объединяет в себе множество протоколов, однако наиболее часто используемые названия для данного семейства это TCP/IP, TCP и IP (иногда семейство называют Семейство Протоколов Internet).
Цели, решаемые сетевым и прикладным уровнями, различны - первый обеспечивает взаимодействие с различными средами передачи (Ethernet, Token ring, и т.д.), второй работает с конкретными пользовательскими приложениями (FTP, Telnet, и т.д.). На первый взгляд, разница между сетевым и транспортным уровнями достаточно туманна. На основании чего между ними проводится разграничение? Чтобы понять это, мы рассмотрим не одну отдельно взятую сеть, а несколько сетей.
Одной из причин феноменального роста сетевых технологий в течение 80-х годов явилось понимание того, что отдельно стоящий компьютер практически бесполезен. Несколько отдельных систем были объединены вместе в сеть. Однако, как выяснилось позже, а именно в 90-х годах, отдельно стоящая сеть также практически бесполезна. Поэтому люди начали объединять сети вместе. Именно результат такого объединения получил название internet (межсетевое взаимодействие). internet это несколько объединенных сетей, которые используют одно и то же семейство протоколов.
Наиболее простой путь осуществить межсетевое взаимодействие - это объединить две или более сетей с помощью маршрутизатора. Как правило, маршрутизатор представляет из себя аппаратное устройство. Огромное достоинство маршрутизаторов заключается в том, что они могут объединить сети, построенные на различных физических принципах: Ethernet, Token ring, point-to-point, FDDI (Fiber Distributed Data Interface), и так далее.
Эти устройства также иногда называются IP маршрутизаторами (IP router), однако мы будем использовать термин маршрутизатор (router).
Исторически эти устройства назывались шлюзами (gateway), и этот термин до сих пор широко используется в литературе о TCP/IP. Сегодня чаще всего термин шлюз используется для обозначения шлюза между приложениями: процесс, который объединяет два различных семейства протоколов (скажем, TCP/IP и IBM SNA) в одном конкретном приложении (чаще всего это электронная почта или передача файлов).
На рисунке 1.3 показано объединение двух сетей: Ethernet и Token ring с помощью маршрутизатора. Несмотря на то что мы показали связь только между двумя компьютерами, подсоединенными к маршрутизатору из разных сетей, любой компьютер в Ethernet может общаться с любым компьютером в Token ring.
На рисунке 1.3 мы также можем проследить разницу между конечной системой (end system), в данном случае это два компьютера на каждой стороне, и промежуточной системой (intermediate system), в данном случае это маршрутизатор в середине. Прикладной и транспортный уровни используют протоколы, ориентированные на соединение (end-to-end). На рисунке эти два уровня используются только конечными системами. Сетевой уровень, однако, использует протокол, не требующий соединения (пересылка-за-пересылкой - hop-by-hop), он используется в данном случае двумя конечными системами и каждой промежуточной системой.


Рисунок 1.3 Две сети, соединенные через маршрутизатор.





В семействе протоколов TCP/IP сетевой уровень - IP. Он предоставляет ненадежный сервис. Это означает, что в процессе своей работы протокол передает пакет от источника к пункту назначения, однако не предоставляет никаких гарантий того, что пакет дойдет по назначению. TCP, с другой стороны, предоставляет надежный транспортный уровень, который пользуется ненадежным сервисом IP. Чтобы обеспечить подобный сервис, TCP выставляет тайм-ауты и осуществляет повторные передачи, отсылает и принимает подтверждения и так далее. Транспортный уровень и сетевой уровень несут различную ответственность за передачу данных.
Маршрутизатор, по определению, имеет два или несколько интерфейсов сетевого уровня (если он объединяет две или более сетей). Любая система с несколькими интерфейсами называется многоинтерфейсной (multihomed). Компьютер, имеющий несколько интерфейсов, но не перенаправляющий пакеты с одного интерфейса на другой, не может называться маршрутизатором. Большинство реализаций TCP/IP позволяют компьютерам с несколькими интерфейсами функционировать в качестве маршрутизаторов. Однако компьютеры должны быть специально сконфигурированы, чтобы решать задачи маршрутизации. Таким образом, мы можем называть систему хостом, когда на нем работают такие приложения как FTP или Telnet, или маршрутизатором, когда он осуществляет передачу пакетов из одной сети в другую. В зависимости от того какие функции выполняются компьютером, мы будем использовать тот или иной термин.
Одна из основных задач объединения сетей заключается в том, чтобы скрыть все детали физического процесса передачи информации между приложениями, находящимися в разных сетях. Поэтому нет ничего удивительного в том, что в объединенных сетях, как, например, на рисунке 1.3, прикладные уровни не заботятся (и не должны заботиться) о том, что один компьютер находится в сети Ethernet, а другой в сети Token ring с маршрутизатором между ними. Даже если бы между сетями было 20 маршрутизаторов и различные типы физического соединения, приложения работали бы точно так же. Подобная концепция, при которой детали физического объединения сетей скрыты от приложений, определяет мощность и гибкость такой технологии объединения сетей.
Существует еще один метод объединения сетей - с помощью мостов (bridge). В этом случае сети объединяются на канальном уровне, тогда как маршрутизаторы объединяют сети на сетевом уровне.
Стоит отметить, что объединение TCP/IP сетей осуществляется в основном с помощью маршрутизаторов, а не с помощью мостов. Поэтому мы более подробно рассмотрим маршрутизаторы. В главе 12 [Perlman 1992] сравниваются маршрутизаторы и мосты.

Зарезервированные порты

Зарезервированные порты

В Unix системах реализуется концепция зарезервированных портов. Только процесс с привилегиями суперпользователя может назначить себе зарезервированный порт.
Эти номера портов находятся в диапазоне от 1 до 1023 и используются некоторыми приложениями (например, Rlogin, глава 26, раздел "Протокол Rlogin") для разграничения прав доступа при общении клиент-сервер.

TCP-IP крупным планом

Ethernet и IEEE 802 инкапсуляция

Ethernet и IEEE 802 инкапсуляция

Термин Ethernet обычно означает стандарт, опубликованный в 1982 году компаниями Digital Equipment Corp., Intel Corp., и Xerox Corp. В настоящее время это основная технология применяемая в локальных сетях использующих TCP/IP. В Ethernet используется метод доступа, называемый CSMA/CD, что обозначает наличие несущей (Carrier Sense), множественный доступ (Multiple Access) с определением коллизий (Collision Detection). Обмен осуществляется со скоростью 10 Мбит/сек, с использованием 48-битных адресов.
Несколько лет спустя Комитет 802 Института инженеров по электротехнике и радиоэлектронике (IEEE - Institute of Electrical and Electronics Engineers) опубликовал отличающийся набор стандартов. 802.3 описывает полный набор сетей CSMA/CD, 802.4 описывает сети с передачей маркера и 802.5 описывает сети Token ring. Общим для всех них является стандарт 802.2, который определяет управление логическим каналом (LLC - Logical link control) и который является общим для большинства сетей 802. К сожалению, комбинация 802.2 и 802.3 определяет форматы фрейма отличные от Ethernet ([Stallings 1987] описывает все детали стандартов IEEE 802).
В мире TCP/IP инкапсуляция IP датаграмм определена в RFC 894 [Hornig 1984] для сетей Ethernet и в RFC 1042 [Postel and Reynolds 1988] для сетей IEEE 802. В Host Requirements RFC к каждому компьютеру, подключенному к Internet через кабель Ethernet 10 Мбит/сек, предъявляются следующие требования:

Компьютер должен иметь возможность посылать и получать пакеты, инкапсулированные с использованием RFC 894 (Ethernet).

У компьютера должна быть возможность получать пакеты RFC 1042 (IEEE 802), перемешанные с пакетами RFC 894.

Компьютер должен иметь возможность посылать пакеты с использованием инкапсуляции RFC 1042. Если компьютер может посылать оба типа пакетов, то тип пакета должен быть конфигурируемым, а конфигурация по умолчанию должна быть настроена на пакеты RFC 894.

Наиболее широко используется инкапсуляция RFC 894. На рисунке 2.1 показаны два различных метода инкапсуляции. Цифры под каждым квадратиком на рисунке это размер в байтах.
В обоих форматах фрейма используется 48-битовый (6-байтовый) формат представления адресов источника и назначения (802.3 позволяет использование 16-битных адресов, однако обычно используются 48-битные). Это как раз то, что мы называем по тексту аппаратными адресами (hardware addresses). Протоколы ARP и RARP (см. главу 4 и главу 5) устанавливают соответствие между 32-битными IP адресами и 48-битными аппаратными адресами.
Следующие 2 байта в этих форматах фрейма различаются. Поле длины (length) 802 содержит количество следующих за ним байтов, однако не содержит в конце контрольной суммы. Поле тип (type) в Ethernet определяет тип данных, которые следуют за ним. Во фрейме 802 то же поле типа (type) появляется позже в заголовке протокола доступа к подсети (SNAP - Sub-Network Access Protocol). К счастью, величины, находящиеся в поле длины (length) 802, никогда не совпадают с величинами, находящимися в поле типа (type) Ethernet, поэтому эти два формата фрейма легко различимы.
Во фрейме Ethernet данные следуют сразу после поля тип (type), тогда как во фрейме 802 за ним следуют 3 байта LLC 802.2 и 5 байт SNAP 802.2. Поля DSAP (точка доступа к сервису назначения - Destination Service Access Point) и SSAP (точка доступа к сервису источника - Source Service Access Point) оба установлены в 0xAA. Поле ctrl установлено в 3. Следующие 3 байта, org code установлены в 0. Затем идет 2-байтовое поле тип (type), такое же, как мы видели в формате фрейма Ethernet (дополнительные значения, которые могут появиться в поле типа, описаны в RFC 1340 [Reynolds and Postel 1992]).
Поле контрольной суммы (CRC) определяет ошибки, возникшие при транспортировке фрейма (также оно иногда называется FCS или последовательность контроля фрейма - frame check sequence).
Минимальный размер фреймов 802.3 и Ethernet требует, чтобы размер данных был хотя бы 38 байт для 802.3 или 46 байт для Ethernet. Чтобы удовлетворить этому требованию, иногда вставляются байты заполнения, для того чтобы фрейм был соответствующей длины.
Мы еще столкнемся с минимальным размером, когда будем рассматривать движение пакетов по кабелям. Также мы еще не раз обратимся к инкапсуляции Ethernet, потому что это, пожалуй, самая широко распространенная форма инкапсуляции.

Инкапсуляция IEEE 802.2/802.3

Рисунок 2.1 Инкапсуляция IEEE 802.2/802.3 (RFC 1042) и инкапсуляция Ethernet (RFC 894).

Инкапсуляция завершителей

Инкапсуляция завершителей

RFC 893 [Leffler and Karels 1984] описывает другую форму инкапсуляции, которая используется в Ethernet и называется инкапсуляция завершителей (trailer encapsulation). С ранними версиями системы BSD на DEC VAX проводился эксперимент, который должен был увеличить производительность путем изменения порядка полей в IP датаграмме. Поля с переменной длиной, которые находились в начале данных фрейма Ethernet (IP заголовок и TCP заголовок), переносились в конец, сразу после контрольной суммы. Это позволяет данным, находящимся во фрейме, быть спланированными в аппаратную страницу с сохранением копии в памяти, когда данные копируются в ядро. Данные TCP, которые кратны 512 байтам, могут быть перемещены путем манипулирования страницами таблиц ядра. Два компьютера договариваются об использовании инкапсуляции завершителей, пользуясь расширением ARP. Для этих фреймов определены различные значения типа фрейма Ethernet.
В настоящее время инкапсуляция завершителей не применяется, поэтому мы не будем приводить примеров. Читатели, которые интересуются этой темой, могут обратиться к RFC 893 или разделу 11.8 [Leffler et al. 1989] за более подробной информацией.

Интерфейс Loopback

Интерфейс Loopback


Большинство реализаций поддерживают интерфейс loopback, который позволяет клиенту и серверу на одном и том же компьютере общаться друг с другом используя TCP/IP. Для интерфейса loopback зарезервирована сеть класса А с идентификатором 127. По договоренности большинство систем добавляют IP адрес 127.0.0.1 для этого интерфейса и дают ему имя localhost. IP датаграмма, посылаемая в интерфейс loopback, не попадает в сеть.
Мы можем решить, что транспортный уровень распознает, что удаленный адрес - это адрес loopback и каким-либо образом сокращает процесс обработки датаграммы. Однако этого не происходит. Осуществляется полная обработка данных на транспортном и сетевом уровнях, после чего IP датаграмма направляется по петле назад, когда выходит вниз из сетевого уровня. На рисунке 2.4 показана упрощенная диаграмма того, как loopback интерфейс обрабатывает IP датаграммы.

MTU

MTU

Как мы видели на рисунке 2.1, существуют ограничения, накладываемые на размер фрейма для Ethernet инкапсуляции и инкапсуляции 802.3. Ограничение накладывается на количество байтов данных в 1500 и 1492 соответственно. Эта характеристика канального уровня называется максимальный блок передачи (MTU - maximum transmission unit). Большинство типов сетей определяют верхний предел.
Если IP хочет отослать датаграмму, которая больше чем MTU канального уровня, осуществляется фрагментация (fragmentation), при этом датаграмма разбивается на меньшие части (фрагменты). Каждый фрагмент должен быть меньше чем MTU. Мы обсудим IP фрагментацию в разделе "Фрагментация IP" главы 11.
На рисунке 2.5 приведен список некоторых типичных значений MTU, взятых из RFC 1191 [Mogul and Deering 1990]. Здесь приведены MTU для каналов точка-точка (таких как SLIP или PPP), однако они не являются физической характеристикой среды передачи. Это логическое ограничение, при соблюдении которого обеспечивается адекватное время отклика при диалоговом использовании. В разделе "Вычисление загруженности последовательной линии" главы 2 мы рассмотрим, откуда берется это ограничение.
В разделе "Команда netstat" главы 3 мы воспользуемся командой netstat, чтобы определить MTU для определенного интерфейса.

Network	MTU (байты)
Hyperchannel	65535
16 Мбит/сек Token ring (IBM)	17914
4 Мбит/сек Token ring (IEEE 802.5)	4464
FDDI	4352
Ethernet	1500
IEEE 802.3/802.2	1492
X.25	576
Точка-точка (с маленькой задержкой)	296

Обработка IP датаграмм интерфейсом loopback.

Рисунок 2.4 Обработка IP датаграмм интерфейсом loopback.


На этом рисунке необходимо обратить внимание на следующее:

Все что отправляется на адрес loopback (обычно 127.0.0.1), попадает на вход IP.

Датаграммы, отправляемые на широковещательный или групповой адреса, копируются в интерфейс loopback и отправляются в Ethernet. Это осуществляется исходя из определения широковещательной или групповой рассылки (глава 12), которая включает в себя посылающий хост.

Все что отправляется на любой из собственных IP адресов хоста, посылается на интерфейс loopback.

Может показаться неэффективным то что транспортный и IP уровни обрабатывают данные, которые посылаются по петле. Однако это упрощает разработку, потому что интерфейс loopback для сетевого уровня выглядит просто как еще один канальный уровень. Сетевой уровень направляет датаграммы в интерфейс loopback как в любой другой канальный уровень, а затем интерфейс loopback помещает датаграммы обратно во входную очередь IP.
Другой интересный момент, который можно увидеть на рисунке 2.4, заключается в том, что IP датаграммы, посланные на один из собственных адресов хоста, обычно не попадают в соответствующую сеть. В комментариях к некоторым BSD драйверам Ethernet устройств указывается, что большинство интерфейсных плат Ethernet не способны читать свою собственную передачу. Так как хост должен обрабатывать IP датаграммы, которые он посылает самому себе, такая обработка пакетов, как показано на рисунке 2.4, это простейший путь добиться этого.
4.4BSD имеет переменную useloopback (по умолчанию устанавливается ее в 1). Если эта переменная установлена в 0, драйвера Ethernet посылают локальные пакеты в сеть, вместо того чтобы посылать их в драйвер loopback. Это может работать, а может и не работать, в зависимости от того, какая установлена интерфейсная плата Ethernet и какой драйвер.

PPP: протокол точка-точка (Point-to-Point)

PPP: протокол точка-точка (Point-to-Point)

PPP, протокол точка-точка, устраняет все недостатки SLIP. PPP состоит из трех компонентов.

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

Протокол управления каналом (LCP - link control protocol) используется для установления конфигурации и тестирования соединения. С его помощью оконечные системы договариваются об использовании различных опций.

Семейство протоколов управления сетью (NCP - network control protocol) указывает на различные протоколы сетевого уровня. В настоящее время существует RFC для IP, сетевого уровня OSI, DECnet и Apple Talk. Например, IP NCP позволяет каждой оконечной системе указать, будет ли он использовать сжатие заголовков, такое же как в CSLIP.

RFC 1548 [Simpson 1993] описывает метод инкапсуляции, который будет использоваться в протоколе управления каналом. RFC 1332 [McGregor 1992] описывает протокол управления сетью для IP.
Формат PPP фреймов был выбран таким образом, чтобы напоминать стандарт ISO HDLC (high-level data link control) . На рисунке 2.3 показан формат фреймов PPP.

SLIP: IP по последовательной линии

SLIP: IP по последовательной линии

SLIP - это простая форма инкапсуляции IP датаграмм для последовательной линии, которая описана в RFC 1055 [Romkey 1988]. SLIP стал широко использоваться для подключения домашних систем к Internet с того момента, когда практически на каждом компьютере появился последовательный порт RS-232, а также появились высокоскоростные модемы.
Формирование фреймов с использованием SLIP подчиняется следующим правилам.

IP датаграмма завершается специальным символом, который называется END (0xc0). Для того чтобы предотвратить шум в линии, перед тем как датаграмма будет интерпретирована как часть датаграммы, большинство реализаций передают символ END также и в начале датаграммы. (Если на линии есть шум, этот END прекращает передачу ошибочной датаграммы и позволяет текущей датаграмме быть переданной. Ошибочная датаграмма будет отброшена верхним уровнем, когда он определит, что ее содержимое повреждено.)

Если байт, находящийся в IP датаграмме, эквивалентен символу END, вместо него передается 2-байтовая последовательность 0xdb, 0xdc. Специальный символ 0xdb называется SLIP ESC символ, однако его значение отличается от символа ASCII ESC (0xlb).

Если байт IP датаграммы равен символу SLIP ESC, вместо него передается 2-байтовая последовательность 0xdb, 0xdd.

На рисунке 2.2 показан пример создания подобных фреймов, при этом в исходной IP датаграмме появляются один END символ и один ESC символ. В этом примере количество байт, переданных по последовательной линии, равно длине IP датаграммы плюс 4. SLIP использует довольно простой метод организации фрейма.
Существуют несколько правил, соблюдая которые можно работать со SLIP.

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

Не существует поля типа (напоминающего поля типа фрейма в Ethernet). Если последовательная линия используется для SLIP, она не может быть одновременно использована для какого-либо другого протокола.

SLIP не добавляет контрольную сумму (как, например, поле контрольной суммы - CRC во фреймах Ethernet). Если из-за шума в телефонной линии датаграмма будет повреждена, это повреждение определяется верхним уровнем. (Однако новые модели модемов могут определять и исправлять испорченные фреймы). Это аналогично тому, как если бы верхние уровни предоставляли некоторую форму контрольной суммы. В главе 3 и главе 17 мы увидим, что контрольная сумма всегда присутствует в IP заголовке, в TCP заголовке и в TCP данных. А в главе 11 мы увидим, что контрольная сумма для заголовка UDP и для данных UDP необязательна.

SLIP с компрессией (CSLIP)

SLIP с компрессией (CSLIP)


Так как линии SLIP как правило медленные (19200 бит/сек или меньше) и часто используют для диалогового трафика (как, например, Telnet и Rlogin, оба из которых используют TCP), возникает необходимость уменьшить TCP пакеты, проходящие по SLIP каналу. Для того чтобы перенести один байт данных, требуется 20 байт IP заголовков и 20 байт TCP заголовков, то есть вместе 40 байт (в разделе "Интерактивный ввод" главы 19 показывается поток этих маленьких пакетов при вводе простых команд в течение сессии Rlogin).
После того как было определено, что с меньшими пакетами достигается большая производительность, новые версии SLIP стали называться CSLIP, что означает сжатый SLIP, который описан в RFC 1044 [Jacobson 1990a]. CSLIP обычно уменьшает 40-байтовый заголовок до 3-5 байт. CSLIP поддерживает до 16 TCP соединений на каждом конце канала и знает, что каждое поле в двух заголовках для данного соединения обычно не изменяется. Для тех полей, которые все же изменяются, изменения заключаются в небольшом увеличении. Подобные уменьшенные заголовки значительно улучшают время отклика при диалоговой работе.
Большинство разработок SLIP в настоящее время поддерживают CSLIP. Оба SLIP канала в подсети, приведенной на рисунке 1.11, являются каналами CSLIP.

Типичные значения максимальных блоков передачи (MTU).

Рисунок 2.5 Типичные значения максимальных блоков передачи (MTU).

Транспортный MTU

Транспортный MTU

Когда общаются два компьютера в одной и той же сети, важным является MTU для этой сети. Однако, когда общаются два компьютера в разных сетях, каждый промежуточный канал может иметь различные MTU. В данном случае важным является не MTU двух сетей, к которым подключены компьютеры, а наименьший MTU любого канала данных, находящегося между двумя компьютерами. Он называется транспортным MTU (path MTU).
Транспортный MTU между любыми двумя хостами может быть не постоянным. MTU зависит от загруженности канала на настоящий момент. Также он зависит от маршрута. Маршрут может быть несимметричным (маршрут от A до B может быть совсем не тем, что маршрут от B к A), поэтому MTU может быть неодинаков для этих двух направлений.
RFC 1191 [Mogul and Deering 1990] описывает механизм определения транспортного MTU (path MTU discovery mechanism). Мы рассмотрим как функционирует этот механизм после того, как опишем фрагментацию ICMP и IP. В разделе "ICMP ошибки о недоступности" главы 11 мы подробно рассмотрим ошибку недоступности ICMP, которая используется в этом механизме, а в разделе "Определение транспортного MTU с использованием Traceroute" главы 11 мы покажем версию программы traceroute, которая использует механизм определения транспортного MTU до пункта назначения. В разделах "Определение транспортного MTU при использовании UDP" главы 11 и "Определение транспортного MTU" главы 24 показано, как функционируют UDP и TCP, когда реализация поддерживает определение MTU.

Упражнения

Упражнения

Если Ваша система поддерживает команду netstat(1) (см. главу 3, раздел "Команда netstat"), используйте ее, чтобы определить интерфейсы в Вашей системе и их MTU.

Назад
Компания | Услуги | Для клиентов | Библиотека | Галерея | Cофт | Линки
На главную

Вычисление загруженности последовательной линии

Вычисление загруженности последовательной линии

Если скорость в линии составляет 9600 бит/сек, при этом 1 байт составляет 8 бит плюс 1 старт-бит и 1 стоп-бит, скорость линии будет 960 байт/сек. Передача пакета размером 1024 байта с этой скоростью займет 1066 мс. Если мы используем SLIP канал для диалогового приложения и одновременно с ним работает такое приложение как FTP, которое посылает или принимает пакеты по 1024 байт, мы должны ждать, так как среднее время задержки нашего интерактивного пакета составит 533 мс.
Это означает, что наш диалоговый пакет будет послан по каналу перед любым другим "большим" пакетом. Большинство SLIP приложений предоставляют разделение пакетов по типу сервиса, отправляя диалоговый трафик перед трафиком передачи данных. Диалоговый трафик это, как правило, Telnet, Rlogin и управляющая часть (пользовательские команды, но не данные) FTP.
Естественно, что такое разделение по сервисам несовершенно. Оно не оказывает никакого воздействия на неинтерактивный трафик, который уже поставлен в очередь на передачу (например, последовательным драйвером). Новые модели модемов, которые имеют большие буферы и позволяют сбуферизировать неинтерактивный трафик в буфере модема, что также сказывается на задержке диалогового трафика.
Ожидание в 533 мс неприемлемо для диалогового ответа. С точки зрения человеческого фактора мы знаем, что неприемлемой является задержка дольше чем 100-200 мс [Jacobson 1990a]. Под задержкой подразумевается время между отправкой пакета и возвращением отклика (как правило, эхо символа).
Уменьшение MTU в канале SLIP до 256 означает, что максимальное время, в течение которого канал может быть занят одним фреймом, составляет 266 мс, и половина от этого (наше среднее время ожидания) составляет 133 мс. Это лучше, однако до сих пор не идеально. Причина, по которой мы выбрали это значение (как сравниваются 64 и 128), заключается в том, чтобы обеспечить лучшее использование канала для передачи данных (как, например, при передаче большого файла). В случае CSLIP фрейма размером 261 байт с заголовком размером в 5 байт (256 байт данных), 98,1% линии используются для передачи данных и 1,9% на заголовки. Уменьшение MTU меньше чем 256 уменьшает максимальное значение пропускной способности линии, которую мы можем получить при передаче данных.
Значение MTU равное 296 для канала точка-точка (рисунок 2.5), подразумевает 256 байт данных и 40 байт TCP и IP заголовков. Так как MTU это величина, о которой IP узнает от канального уровня, это значение должно включать в себя стандартные заголовки TCP и IP. Именно таким образом IP принимает решение о фрагментации. IP ничего не знает о сжатии заголовков, которое осуществляются CSLIP.
Наш расчет средней задержки (половина того времени, которое требуется на передачу фрейма максимального размера) имеет отношение только к каналу SLIP (или каналу PPP), который используется для передачи интерактивного трафика и трафика данных. Когда идет обмен только интерактивным трафиком, время передачи одного байта данных в каждом направлении (в случае сжатого 5-байтового заголовка) составляет примерно 12,5 мс, при скорости 9600 бит/сек. Это хорошо укладывается в диапазон 100-200 мс, о котором мы упоминали ранее. Также заметьте, что сжатие заголовков с 40 до 5 байт уменьшает время задержки для одного байта с 85 до 12,5 мс.
К сожалению, эти расчеты становятся не совсем верными, когда используется коррекция ошибок и сжатие в модемах. Сжатие в модемах уменьшает количество байт, которые посылаются по линии, однако исправление ошибок может увеличить время передачи этих байт. Однако эти расчеты дают нам исходную точку, для того чтобы принять разумное решение.
В следующих главах мы будем использовать эти расчеты для последовательных линий, чтобы определить некоторые величины таймеров, которые используются при передаче пакетов по последовательным линиям.

TCP-IP крупным планом

Адресация подсетей

Адресация подсетей

В настоящее время существует требование, чтобы все хосты поддерживали адресацию подсетей (RFC 950 [Mogul and Postel 1985]). Теперь IP адрес не делится просто на идентификатор сети и идентификатор хоста: идентификатор хоста делится на идентификатор подсети и идентификатор хоста.
В сетях класса A и в сетях класса B адреса отводится слишком много бит на идентификатор хоста: 224 - 2 и 216 - 2 соответственно. Как правило, такое количество хостов не подключается к одной сети. (На рисунке 1.5 показан формат IP адресов сетей различных классов сетей.) В данном случае вычитается 2, потому что идентификатор хоста из всех нулевых битов или всех единичных битов не используется.
После получения от InterNIC идентификатора сети определенного класса, системный администратор решает, делить ли сеть на подсети или нет, а если делить, то сколько бит будет отведено на идентификатор подсети и сколько на идентификатор хоста. Например, сети, описываемые в этом тексте, имеют адреса класса В (140.252), а из оставшихся 16 бит 8 отводятся под идентификатор подсети, а 8 на идентификатор хоста. Это показано на рисунке 3.5.

Будущее IP

Будущее IP

У IP существуют три проблемы. Все они явились результатом феноменального роста сети Internet за последние несколько лет. (Обратитесь к упражнению 2 главы 1.)

Почти половина всех адресов класса В уже распределена. Если адреса класса В будут распространяться с такой же скоростью как сейчас, то их запас будет исчерпан где-то в 1995 году.

32-битные адреса в общем случае непригодны для долговременного роста Internet.

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

Бесклассовая маршрутизация между доменами (CIDR - Classless Interdomain Routing) призвана разрешить третью проблему, при этом к текущей версии IP будут добавлены некоторые расширения (IP версия 4). Мы обсудим это более подробно в разделе "CIDR: бесклассовая маршрутизация между доменами" главы 10.
Что касается новой версии IP, которую часто называют IPng, было сделано четыре предложения для следующих поколений IP. В майском выпуске IEEE Network (vol.7, no.3) за 1993 год содержится обзор первых трех предложений вместе с CIDR. RFC 1454 [Dixon 1993] также сравнивает первые три предложения.

Простой протокол Internet (SIP - Simple Internet Protocol) . Предлагается минимальный набор изменений к IP, после чего IP будет использовать 64-битные адреса и другой формат заголовка. (Первые 4 бита заголовка также содержат номер версии, которые устанавливается в 4.)

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

TUBA, что означает TCP и UDP с увеличенными адресами (TCP and UDP with bigger Addresses), основан на OSI CLNP (сетевой протокол без соединения - Connectionless Network Protocol), протокол OSI похожий на IP. Он предлагает еще большие адреса: переменной длины, до 20 байт. Однако, СLNP это существующий протокол, тогда как SIP и PIP это всего лишь предложения, более того, CLNP уже документирован. RFC 1347 [Callon 1992] описывает детали TUBA. Глава 7 [Perlman 1992] содержит сравнение IPv4 и CLNP. Множество маршрутизаторов уже поддерживают CLNP, однако большинство хостов не поддерживают.

TP/IX, который описан в RFC 1475 [Ullmann 1993]. Как и в случае с SIP, он использует 64-битные IP адреса, также изменяя TCP и UDP заголовки: 32-битный номер порта для обоих протоколов, 64-битный номер последовательности, 64-битный номер подтверждения и 32-битные окна для TCP.

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

Доставка IP датаграммы от bsdi к sun.

Рисунок 3.3 Доставка IP датаграммы от bsdi к sun.


Рассмотрим еще один пример: bsdi имеет IP датаграмму, которую необходимо послать на хост ftp.uu.net, IP адрес которого 192.48.96.9. На рисунке 3.4 показан путь датаграммы через первые три маршрутизатора. bsdi просматривает свою таблицу маршрутизации, однако не находит совпадающий хост или совпадающую сеть. Он использует пункт таблицы маршрутизации по умолчанию, в соответствии с которым необходимо послать датаграмму на sun, который является маршрутизатором следующей пересылки. Когда датаграмма передается от bsdi к sun, IP адрес для нее это конечный адрес назначения (192.48.96.9), однако адрес канального уровня - это 48-битный Ethernet адрес интерфейса Ethernet машины sun. Сравните эту датаграмму с одной из показанных на рисунке 3.3, где IP адрес назначения и адрес назначения канального уровня указывают на один и тот же хост (sun).
Когда sun получает датаграмму, он понимает, что IP адрес назначения этой датаграммы не его собственный, и если sun сконфигурирован для того чтобы выполнять функции маршрутизатора, он перенаправляет датаграмму. Происходит просмотр его таблицы маршрутизации, в результате чего выбирается пункт по умолчанию. Из этого пункта следует, что sun должен перенаправить датаграмму на маршрутизатор следующей пересылки - netb, IP адрес которого 140.252.1.183. Датаграмма пересылается по SLIP каналу точка-точка с использованием минимальной инкапсуляции, показанной на рисунке 2.2. Мы не показываем заголовок канального уровня, как в случае с Ethernet, потому что его нет в случае SLIP канала.
Когда netb получает датаграмму, он осуществляет те же самые шаги, которые только что осуществил sun: датаграмма не предназначается какому-либо из его IP адресов, а так как netb сконфигурирован так, чтобы выполнять функции маршрутизатора, он перенаправляет датаграмму. В данном случае также используется пункт таблицы маршрутизации по умолчанию, при этом датаграмма посылается на маршрутизатор следующей пересылки gateway (140.252.1.4). С использованием ARP в сети Ethernet 140.252.1, netb получает 48-битный Ethernet адрес соответствующий адресу 140.252.1.4. Именно этот Ethernet адрес становится адресом назначения в заголовке канального уровня.
gateway осуществляет те же шаги, как и два предыдущих маршрутизатора, в его таблице маршрутизации пункт по умолчанию указывает на адрес 140.252.104.2 как на адрес маршрутизатора следующей пересылки (мы убедимся, что этот маршрутизатор является маршрутизатором следующей пересылки для gateway с использованием Traceroute на рисунке 8.4).
Из приведенного примера можно сделать несколько важных выводов.

Все хосты и маршрутизаторы в данном примере используют маршрут по умолчанию.

IP адрес назначения датаграммы никогда не меняется. (В разделе "Опция IP маршрутизации от источника" главы 8 мы увидим, что это не всегда верно, если используется маршрутизация от источника, что бывает довольно редко.) Все решения о маршрутизации основываются на этом адресе назначения.

Для каждого канала могут быть использованы различные заголовки канального уровня, а адрес назначения канального уровня (если присутствует) всегда содержит адрес маршрутизатора следующей пересылки. В нашем примере датаграммы, инкапсулированные во фреймы канального уровня, содержали Ethernet адрес следующей пересылки, однако SLIP не содержал. Адреса Ethernet обычно получаются с использованием ARP.

IP адреса описываемой подсети.

Рисунок 3.12 IP адреса описываемой подсети.

Первая колонка помечена как "хост" ("Host"), однако и sun и bsdi также функционируют как маршрутизаторы, так как они имеют несколько интерфейсов и перенаправляют пакеты с одного интерфейса на другой.
В последней строке таблицы показано, что широковещательный адрес сети Ethernet на рисунке 3.10 установлен 140.252.13.63: он формируется из идентификатора подсети Ethernet (140.252.13.32) и младших 5 бит на рисунке 3.11, установленных в единицу (16+8+4+2+1=31). (В главе 12 мы увидим, что этот адрес называется широковещательным адресом подсети.)

IP маршрутизация

IP маршрутизация

IP маршрутизация это довольно простой процесс, особенно с точки зрения хоста. Если пункт назначения напрямую подключен к хосту (например канал точка-точка) или хост включен между несколькими сетями (Ethernet или Token ring), IP датаграмма направляется непосредственно в пункт назначения, иначе хост посылает датаграмму на маршрутизатор по умолчанию, тем самым предоставляя маршрутизатору решать как доставить датаграмму в пункт назначения. Эту простую схему реализуют практически все хосты.
В этом разделе и в главе 9 мы рассмотрим наиболее общие случаи, когда IP уровень может быть сконфигурирован таким образом, чтобы выполнять функции маршрутизации, в дополнение к тому, что он работает в качестве сетевого интерфейса. Большинство многопользовательских систем в настоящее время, включая практически каждую UNIX систему, могут быть сконфигурированы таким образом, чтобы выступать в роли маршрутизатора. Существует возможность указать простой алгоритм маршрутизации, который будет использоваться как хостом, так и маршрутизатором. Основная и фундаментальная разница между хостом и маршрутизатором заключается в том, что хост никогда не перенаправляет датаграммы с одного своего интерфейса на другой, тогда как маршрутизатор перенаправляет. Мы рассмотрим более подробно опции конфигурирования в разделе "Перенаправлять или не перенаправлять" главы 9.
В соответствии с общей схемой, IP может получать датаграммы от собственных уровней TCP, UDP, ICMP и IGMP (это датаграммы, формирующиеся здесь же), которые необходимо отправить, однако датаграммы могут быть приняты с какого-либо сетевого интерфейса (эти датаграммы должны быть перенаправлены). IP уровень имеет в памяти таблицу маршрутизации, которую он просматривает каждый раз при получении датаграммы, которую необходимо перенаправить. Когда датаграмма принята с сетевого интерфейса, IP, во-первых, проверяет, не принадлежит ли ему указанный IP адрес назначения или не является ли этот IP адрес широковещательным. Если это так, то датаграмма доставляется в модуль протокола, указанный в поле протокола в IP заголовке. Если датаграмма не предназначается для этого IP уровня (1), если IP уровень был сконфигурирован для того чтобы работать как маршрутизатор, пакет перенаправляется (в этом случае датаграмма обрабатывается как исходящая, что будет описано ниже), иначе (2) датаграмма молча уничтожается.
Каждый пункт таблицы маршрутизации содержит следующую информацию:

IP адрес назначения. Это может быть как полный адрес хоста (host address) или адрес сети (network address), что указывается в поле флагов (описывается ниже). Адрес хоста имеет ненулевое значение идентификатора хоста (рисунок 1.5) и указывает на один конкретный хост, тогда как адрес сети имеет идентификатор хоста, установленный в 0, и указывает на все хосты, включенные в определенную сеть (Ethernet, Token ring).

IP адрес маршрутизатора следующей пересылки (next-hop router), или, иначе говоря, IP адрес непосредственно подключенной сети. Маршрутизатор следующей пересылки принадлежит одной из непосредственно подключенных сетей, в которую мы можем отправить датаграммы для их доставки. Маршрутизатор следующей пересылки это не конечный пункт назначения, однако он принимает датаграммы, которые мы посылаем, и перенаправляет их в направлении конечного пункта.

Флаги. Один флаг указывает, является ли IP адрес пункта назначения, адресом сети или адресом хоста. Другой флаг указывает на то, является ли маршрутизатор следующей пересылки действительно маршрутизатором или это непосредственно подключенный интерфейс (мы опишем эти флаги в разделе "Принципы маршрутизации" главы 9).

Указание на то, на какой сетевой интерфейс должны быть переданы датаграммы для передачи.

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

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

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

В таблице маршрутизации ищется пункт, помеченный "по умолчанию" (default). Если пункт найден, пакет отсылается на указанный маршрутизатор по умолчанию.

Если ни один из шагов не дал положительного результата, датаграмма считается недоставленной. Если недоставленная датаграмма была сгенерирована данным хостом, то обычно возвращается ошибка "хост недоступен" (host unreachable) или "сеть недоступна" (network unreachable). Этот код ошибки возвращается приложению, которое сгенерировало датаграмму.
В начале всегда осуществляется сравнение на совпадение полного адреса хоста, после чего осуществляется сравнение идентификатора сети. Только в том случае, если результат обеих сравнений отрицательный, используется маршрут по умолчанию. Маршруты по умолчанию и сообщения ICMP о перенаправлении, отправляемые на маршрутизатор следующей пересылки (если для датаграммы выбрано неверное направление по умолчанию), являются довольно мощными характеристиками IP маршрутизации, к которым мы еще вернемся в главе 9.
Еще одна фундаментальная характеристика IP маршрутизации заключается в возможности указать маршрут к сети, вместо того, чтобы указывать маршрут к каждому отдельно взятому хосту. Именно поэтому хосты включенные в Internet, например, имеют в своих таблицах маршрутизации тысячи пунктов, вместо того чтобы содержать в них не более чем миллион пунктов.

IP заголовок

IP заголовок

На рисунке 3.1 показан формат IP датаграммы. Стандартный размер IP заголовка составляет 20 байт, если не присутствуют опции.

Использование подсетей переменной длины.

Рисунок 3.11 Использование подсетей переменной длины.


Маска подсети с переменной длиной не создаст проблем для других хостов и маршрутизаторов в сети 140.252, так как все датаграммы, направляемые в подсеть 140.252.13, приходят на маршрутизатор sun (IP адрес 140.252.1.29. Рисунок 3.10) и если sun знает об 11-битном идентификаторе подсети для хостов в подсети 13, все будет нормально.
Маска подсети для всех интерфейсов в подсети 140.252.13 установлена в 255.255.255.224 или 0xffffffe0. Это означает, что крайние правые 5 битов отводятся на идентификатор хоста, а 27 бит слева оставлены на идентификатор сети и идентификатор подсети.
На рисунке 3.12 показано распределение IP адресов и масок подсетей для интерфейсов, приведенных на рисунке 3.10.

Хост	IP адрес	Маска подсети	ID сети/ ID подсети	ID хоста	Комментарии
sun	140.252.1.29	255.255.255.0	140.252.1.	29	в подсети 1
	140.252.13.33	255.255.255.244	140.252.13.32	1	Ethernet, который рассматривается в качестве примера
svr4	140.252.13.34	255.255.255.244	140.252.13.32	2
bsdi	140.252.13.35	255.255.255.244	140.252.13.32	3	Ethernet
	140.252.13.66	255.255.255.244	140.252.13.64	2	точка-точка
slip	140.252.13.65	255.255.255.244	140.252.13.64	1	точка-точка
	140.252.13.63	255.255.255.224	140.252.13.32	31	широковещательный адрес в Ethernet

Команда ifconfig

Команда ifconfig

Сейчас, когда мы описали канальный уровень и IP уровень, мы можем показать команду, которая используется для конфигурирования сетевого интерфейса который используется TCP/IP. Команда ifconfig(8) обычно запускается в момент загрузки хоста при конфигурации каждого интерфейса.
Для интерфейсов с дозвоном (dialup), которые могут включаться и выключаться (такие как SLIP каналы), ifconfig должна быть запущена каждый раз когда канал включается или выключается.
В следующем примере показаны значения для подсети, описываемой в книге. Сравните эти значения с теми, что приведены на рисунке 3.12.
sun % /usr/etc/ifconfig -a опция -a в SunOS означает "все интерфейсы" le0: flags=63 inet 140.252.13.33 netmask ffffffe0 broadcast 140.252.13.63 sl0: flags=1051 inet 140.252.1.29 --> 140.252.1.183 netmask ffffff00 lo0: flags=49 inet 127.0.0.1 netmask ff000000
Интерфейс loopback (глава 2, раздел "Интерфейс Loopback") воспринимается как сетевой интерфейс. Он использует адрес класса A и не позволяет разбивать себя на подсети.
Обратите внимание на то, что в Ethernet не используется инкапсуляция завершителей (глава 2, раздел "Инкапсуляция завершителей") и что Ethernet поддерживает широковещательные запросы, тогда как SLIP канал это канал точка-точка.
Флаг LINK0 для SLIP интерфейса это опция конфигурирования, которая позволяет осуществлять сжатие slip (CSLIP, глава 2, раздел "SLIP с компрессией (CSLIP)"). Еще одна возможная опция это LINK1, которая включает CSLIP, если принят сжатый пакет с удаленного конца, и LINK2, которая позволяет отбрасывать все исходящие пакеты ICMP. Мы рассмотрим адрес назначения этого SLIP канала в разделе "Уполномоченный агент ARP" главы 4.
Комментарии, приведенные в инструкции по инсталляции, объясняют причину, по которой была введена последняя опция: "Она не должна быть установлена, однако некоторые кретины, посылающие pingи на Вас, могут свести производительность канала к нулю".
Еще один маршрутизатор - bsdi. Так как опция -a это характеристика SunOS, (BSD релизы не имеют подобной опции) мы должны исполнить ifconfig несколько раз, указывая имя интерфейса в качестве аргумента:
bsdi % /sbin/ifconfig we0 we0: flags=863 inet 140.252.13.35 netmask ffffff00 broadcast 140.252.13.63 bsdi % /sbin/ifconfig sl0 sl0: flags=1011 inet 140.252.13.66 --> 140.252.13.65 netmask ffffff00
Здесь у интерфейса Ethernet мы видим новую опцию (we0): SIMPLEX. Эта опция из 4.4BSD, которая указывает на то, что интерфейс не может слушать свою собственную передачу. Она устанавливается в BSD/386 для всех интерфейсов Ethernet. Если опция установлена, интерфейс, посылающий фрейм с широковещательным адресом, посылает копию на локальный хост и посылает копию на loopback. (Мы покажем пример данной характеристики в разделе "ICMP запрос и отклик маски адреса" главы 6.)
На хосте slip конфигурация интерфейса SLIP примерно такая же, как показано выше для bsdi, за исключением того, что IP адреса на двух концах переставлены местами:
slip % /sbin/ifconfig sl0 sl0: flags=1011 inet 140.252.13.65 --> 140.252.13.66 netmask ffffffe0
Последний интерфейс - это Ethernet на хосте svr4. Он аналогичен интерфейсу Ethernet, показанному ранее, за исключением того, что версия команды ifconfig в SVR4 не печатает флаг RUNNING:
svr4 % /usr/sbin/ifconfig emd0 emd0: flags=23 inet 140.252.13.34 netmask ffffffe0 broadcast 140.252.13.63
Команда ifconfig обычно поддерживает и другие семейства протоколов (не TCP/IP), а также имеет несколько дополнительных опций. Обратитесь к руководству по вашей системе, для того чтобы изучить эту команду более подробно.

Команда netstat

Команда netstat

Команда netstat(1) также предоставляет информацию об интерфейсах системы. Флаг -i выдает информацию об интерфейсах, а флаг -n выдает IP адреса вместо имен хостов.
sun % netstat -in Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue le0 1500 140.252.13.32 140.252.13.33 67719 0 92133 0 1 0 sl0 552 140.252.1.183 140.252.1.29 48035 0 54963 0 0 0 lo0 1536 127.0.0.1 127.0.0.1 15548 0 15548 0 0 0
Эта команда печатает MTU для каждого интерфейса, количество входящих пакетов, ошибки ввода, количество исходящих пакетов, ошибки вывода, коллизии (столкновения) и текущий размер исходящей очереди.
Мы вернемся к команде netstat в главе 9, где будем использовать ее для рассмотрения таблиц маршрутизации, и в главе 13, когда будем использовать модифицированную версию команды, чтобы рассмотреть активные группы при групповой адресации.

Маска подсети

Маска подсети

В процессе конфигурации, которая происходит в момент загрузки хоста, осуществляется установка IP адреса хоста. Большинство систем хранят его в дисковом файле, который читается во время загрузки. В главе 5 мы рассмотрим, как бездисковые системы определяют свой IP адрес при загрузке.
В дополнение к IP адресу, хосту также необходимо знать, сколько бит будет использовано в качестве идентификатора подсети и сколько бит будет использовано в качестве идентификатора хоста. Это также определяется во время загрузки с использованием маски подсети. Маска это 32-битное значение, которое содержит биты, установленные в единицу для идентификатора сети и идентификатора подсети, и биты, установленные в 0 для идентификатора хоста. На рисунке 3.7 показано формирование маски подсети для двух различных разделений адреса класса В. В верхнем примере происходит разделение на хосте noao.edu, как показано на рисунке 3.5, где идентификатор подсети и идентификатор хоста занимают 8 бит. В нижнем примере показано разделение адреса класса В, при этом идентификатор подсети занимает 10 бит, а идентификатор хоста - 6 бит.

Настройки большинства подсетей noao.edu 140.252.

Рисунок 3.6 Настройки большинства подсетей noao.edu 140.252.


Для того чтобы получить доступ к хосту, IP адрес которого начинается с 140.252, внешний маршрутизатор должен всего лишь знать путь к IP адресу 140.252.104.1. Это означает, что для доступа ко всем сетям 140.252 необходим только один пункт в таблице маршрутизации, вместо 30-ти пунктов в случае использования 30 адресов класса С. Таким образом, деление на подсети уменьшает размер таблиц маршрутизации (в разделе "CIDR: бесклассовая маршрутизация между доменами" главы 10 мы рассмотрим новую технологию, которая помогает уменьшить размер таблиц маршрутизации даже если используются адреса класса С).
Для того чтобы показать что подсети непрозрачны для маршрутизаторов внутри подсети, обратимся к рисунку 3.6 и представим, что датаграмма прибывает в gateway из Internet с адресом назначения 140.252.57.1. Маршрутизатор gateway должен знать где находится подсеть 57 и что датаграммы для этой подсети надо посылать в kpno. В свою очередь, kpno должен посылать датаграммы в R55, который пошлет их в R57.

Настройки хостов и сетей в описываемой подсети.

Рисунок 3.10 Настройки хостов и сетей в описываемой подсети.


Если Вы сравните этот рисунок с одним из тех, что показаны на внутренней стороне обложки, то заметите, что мы опустили некоторые детали, которые описывают подсоединение маршрутизатора sun к верхнему Ethernet. (посредством SLIP соединения). Это не влияют на наше описание деления на подсети в данном разделе. Мы вернемся к подобному SLIP соединению в разделе "Уполномоченный агент ARP" главы 4, когда будем описывать уполномоченного агента ARP.
Проблема заключается в том, что мы имеем две раздельные сети внутри подсети 13: Ethernet и канал точка-точка (выделенный канал SLIP). (Каналы точка-точка всегда привносят некоторые проблемы, так как каждый конец требует собственный IP адрес.) В будущем здесь может появиться больше хостов и сетей, однако недостаточно для того, чтобы выделять другой номер подсети. Мы принимаем решение расширить идентификатор подсети с 8 до 11 бит, и уменьшить идентификатор хоста с 8 до 5 бит. Это называется подсетями с переменной длиной, так как большинство сетей внутри сети 140.252 используют маску подсети длиной 8 бит, тогда как наша сеть использует маску подсети длиной 11 бит.
RFC 1009 [Braden and Postel 1987] позволяет использовать в сетях с подсетями несколько масок подсетей. Новые требования к маршрутизаторам Router Requirements RFC [Almquist 1993] определяют все требования. Проблема, однако, заключается в том, что не все протоколы маршрутизации обмениваются масками подсети вместе с идентификатором сети назначения. Мы увидим в главе 10, что RIP не поддерживает подсети переменной длины, однако RIP версии 2 и OSPF поддерживают. У нас не было подобных проблем, так как RIP не используется в подсетях, описываемых в тексте.
На рисунке 3.11 показана структура IP адреса, используемая в подсети, описываемой в книге. Первые 8 бит в 11-битном идентификаторе подсети всегда равны 13 в данной подсети. Для оставшихся трех бит идентификатора подсети мы используем двоичное 001 для Ethernet и 010 для SLIP канала точка-точка.

Пример масок подсетей для двух различных подсетей класса B.

Рисунок 3.7 Пример масок подсетей для двух различных подсетей класса B.


Несмотря на то, что IP адреса обычно пишутся в десятичном виде с точками, маски подсети, как правило, пишутся в шестнадцатиричном виде, особенно если разделение происходит не побайтно, а побитно.
После того как хост получил свой IP адрес и маску подсети, он может определить, предназначена ли IP датаграмма для (1) хоста в его собственной подсети, (2) хосту в другой подсети его собственной сети, или (3) хосту в другой сети. Зная собственный IP адрес, можно определить, к какому классу он относится: А, В или С (по старшим битам), также можно определить, где проведена граница между идентификатором сети и идентификатором подсети. По маске подсети можно определить где проведена граница между идентификатором подсети и идентификатором хоста.

Пример подсети

Пример подсети

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

Пример

Пример

Представьте себе адрес хоста 140.252.1.1 (адрес класса В), и маску подсети - 255.255.255.0 (8 бит на идентификатор подсети и 8 бит на идентификатор хоста).

Если IP адрес назначения 140.252.4.5, мы знаем, что идентификатор сети класса В тот же самый (140.252), однако идентификатор подсети другой (1 и 4). На рисунке 3.8 показано, как происходит сравнение двух IP адресов с использованием маски подсети.

Если IP адрес назначения 140.252.1.22, то идентификатор сети класса В тот же самый (140.252), и идентификатор подсети также тот же самый (1). Однако идентификатор хоста другой.

Если IP адрес назначения 192.43.235.6 (адрес класса С), идентификатор сети другой. С этим адресом не может быть произведено дальнейшее сравнение.

Примеры

Примеры

Для начала представим себе простой пример: хост bsdi имеет IP датаграмму, которую необходимо послать на хост sun. Оба хоста находятся в одной и той же сети Ethernet (рисунок находится на внутренней стороне обложки). На рисунке 3.3 показан процесс доставки датаграммы.
Когда IP принимает датаграмму от одного из верхних уровней, он просматривает свою таблицу маршрутизации и определяет, что IP адрес назначения (140.252.13.33) непосредственно подключен к сети (Ethernet 140.252.13.0). В таблице маршрутизации найден совпадающий адрес сети (в следующем разделе мы увидим, что благодаря разбиению на подсети сетевой адрес этого Ethernet в действительности 140.252.13.32, однако это не влияет на маршрутизацию).
Датаграмма передается в драйвер устройства Ethernet и посылается на sun в виде Ethernet фрейма (рисунок 2.1). Адрес назначения в IP датаграмме это IP адрес Sun (140.252.13.33), а адрес назначения в заголовке канального уровня это 48-битовый Ethernet адрес интерфейса Ethernet машины sun. 48-битный Ethernet адрес получается с использованием ARP, как это делается - мы увидим в следующей главе.

Путь датаграммы от bsdi к ftp.uu.net (192.48.96.9).

Рисунок 3.4 Путь датаграммы от bsdi к ftp.uu.net (192.48.96.9).


В главе 9 мы снова вернемся к IP маршрутизации, после того как расскажем об ICMP. Также мы рассмотрим некоторые примеры таблиц маршрутизации и примеры того, как они используются при принятии решений о маршрутизации.

Разделение на подсети адреса класса B.

Рисунок 3.5 Разделение на подсети адреса класса B.


Подобное разделение позволяет создать 254 подсети по 254 хоста в каждой.
Большинство администраторов использует 8 из 16-ти бит идентификатора хоста в сети класса В, для выделения подсетей. Это позволяет легко выделить идентификатор подсети из десятичного сетевого адреса, при этом для сетей класса А или класса В можно выделить различное количество битов для организации подсетей.
В большинстве примеров разделение на подсети осуществляется с адресами класса В. Поделить на подсети можно и адреса класса С, однако в этом случае на идентификатор подсети выделяется очень мало битов. Разделение на подсети очень редко применяется по отношению адресов класса А, потому что адресов класса А очень мало (однако, большинство адресов класса А поделено на подсети).
Разделение на подсети скрывает детали внутренней организации сети от внешних маршрутизаторов. В нашем примере, все IP адреса имеют идентификатор сети класса В - 140.252, однако в ней существует более чем 30 подсетей и более чем 400 хостов, распределенных по этим подсетям. Один маршрутизатор обеспечивает подключение к Internet, как показано на рисунке 3.6.
На этом рисунке мы пометили большинство маршрутизаторов как Rn, где n это номер подсети. Мы показали маршрутизаторы, которые соединяют эти подсети вместе с девятью системами, которые показаны на рисунке, находящимся на внутренней стороне обложки. Сети Ethernet показаны жирными линиями, а каналы точка-точка показаны пунктиром. Мы показали не все хосты, находящиеся в различных подсетях. Например, более 50 хостов находятся в подсети 140.252.3 и более 100 в подсети 140.252.1.
Преимущество использования подсети заключается в том, что используется один адрес класса В с 30 подсетями, а не 30 адресов класса С. При этом разделение на подсети уменьшает размер таблиц маршрутизации Internet. Факт того что адрес сети класса В 140.252 поделен на подсети говорит о том, что они прозрачны для всех маршрутизаторов Internet, кроме тех, которые находятся в подсети 140.252.

Рекомендованные значения поля типа сервиса (TOS).

Рисунок 3.2 Рекомендованные значения поля типа сервиса (TOS).


Диалоговые приложения, Telnet и Rlogin, требуют свести к минимуму задержку, так как они используются человеком интерактивно и осуществляют небольшую передачу данных. Передача файлов с использованием FTP, с другой стороны, требует максимальной пропускной способности. Максимальная надежность необходима для сетевого управления (SNMP) и для протоколов маршрутизации. Новости Usenet (NNTP) это единственное приложение, которое требует минимизации стоимости.
Характеристика TOS, в настоящее время, большинством реализаций TCP/IP не поддерживается, однако она включена в новые системы, начиная с 4.3BSD Reno. Некоторые протоколы маршрутизации, такие как OSPF и IS-IS, имеют возможность принимать решение о маршрутизации на основе этого поля.
В разделе "Вычисление загруженности последовательной линии" главы 2 мы упомянули, что драйверы SLIP обычно осуществляют построение очереди на основе типа сервиса, что позволяет диалоговому траффику обрабатываться перед передачей данных. Так как большинство реализаций не используют поле TOS, это построение очереди делается с помощью драйвера SLIP, который смотрит в поле протокола (для того чтобы определить, является ли данный сегмент TCP сегментом или нет) и затем проверяет номера портов TCP источника и назначения, чтобы определить, принадлежит ли этот номер диалоговому сервису.
Поле полной длины (total length) содержит полную длину IP датаграммы в байтах. Благодаря этому полю и полю длины заголовка, мы знаем, с какого места начинаются данные в IP датаграмме и их длину. Так как это поле состоит из 16 бит, максимальный размер IP датаграммы составляет 65535 байт. (Обратитесь к рисунку 2.5 и обратите внимание, что Hyperchannel имеет MTU, равный 65535. В действительности это не MTU - здесь используется максимально возможный размер IP датаграммы). Это поле изменяется в момент фрагментации и повторной сборки датаграммы, что будет описано в разделе "Фрагментация IP" главы 11.
Несмотря на то что существует возможность отправить датаграмму размером 65535 байт, большинство канальных уровней поделят подобную датаграмму на фрагменты. Более того, от хоста не требуется принимать датаграмму размером больше чем 576 байт. TCP делит пользовательские данные на части, поэтому это ограничение обычно не оказывает влияния на TCP. Что касается UDP, услугами которого пользуются многие приложения (RIP, TFTP, BOOTP, DNS, SNMP), то он ограничивает себя 512 байтами пользовательских данных, что даже меньше ограничения в 576 байт. Большинство приложений в настоящее время (особенно те, которые поддерживают NFS - Network File System) позволяют использовать IP датаграмму размером 8192 байта.
Однако, поле полной длины требуется в IP заголовке для некоторых каналов (как например, Ethernet), который дополняет маленькие фреймы до минимальной длины. Несмотря на то что минимальный размер фрейма Ethernet составляет 46 байт (рисунок 2.1), IP датаграмма может быть еще меньше. Если поле полной длины не было представлено, IP уровень не будет знать, сколько 46-байтных фреймов Ethernet получится из IP датаграммы.
Поле идентификации (identification) уникально идентифицирует каждую датаграмму, отправленную хостом. Значение, хранящееся в поле, обычно увеличивается на единицу с посылкой каждой датаграммы. Мы обратимся к этому полю, когда будем рассматривать фрагментацию и обратную сборку в разделе "Фрагментация IP" главы 11. Там же мы рассмотрим поле флагов (flags) и поле смещения фрагментации (fragmentation offset).
RFC 791 [Postel 1981a] сообщает, что поле идентификации должно быть выбрано верхним уровнем, который отправляет IP датаграммы, а это означает, что две последовательно отправленные IP датаграммы, одна из которых сгенерирована TCP, а другая - UDP, должны иметь одно и то же поле идентификации. Подобный подход работает (алгоритм сборки может обработать такую ситуацию). Однако, большинство реализаций, произошедших от Berkeley, увеличивают соответствующую переменную в ядре IP уровня каждый раз, когда отправляется IP датаграмма, вне зависимости от того какой уровень отправляет данные через IP. Переменная ядра инициируется каждый раз в момент загрузки системы.
Поле времени жизни (TTL - time-to-live) содержит максимальное количество пересылок (маршутизаторов), через которые может пройти датаграмма. Это поле ограничивает время жизни датаграммы. Значение устанавливается отправителем (как правило 32 или 64) и уменьшается на единицу каждым маршрутизатором, который обрабатывает датаграмму. Когда значение в поле достигает 0, датаграмма удаляется, а отправитель уведомляется об этом с помощью ICMP сообщения. Подобный алгоритм предотвращает зацикливание пакетов в петлях маршрутизации. Мы вернемся к этому полю в главе 8, когда будем рассматривать программу Traceroute.
Мы говорили о поле протокола (protocol) в главе 1 и показали на рисунке 1.8 как оно используется в IP для демультиплексирования входящих датаграмм. Это поле указывает, какой протокол отправил данные через IP.
Контрольная сумма заголовка (header checksum) рассчитывается только для IP заголовка. Она не включает в себя данные, которые следуют за заголовком. ICMP, IGMP, UDP и TCP имеют контрольные суммы в своих собственных заголовках, которые охватывают их заголовки и данные.
Чтобы рассчитать контрольную сумму IP для исходящей датаграммы, поле контрольной суммы сначала устанавливается в 0. Затем рассчитывается 16-битная сумма с поразрядным дополнением (One's complement - поразрядное дополнение к двоичной системе.) (заголовок целиком воспринимается как последовательность 16-битных слов). 16-битное поразрядное дополнение этой суммы сохраняется в поле контрольной суммы. Когда IP датаграмма принимается, вычисляется 16-битная сумма с поразрядным дополнением. Так как контрольная сумма, рассчитанная приемником, содержит в себе контрольную сумму, сохраненную отправителем, контрольная сумма приемника состоит из битов равных 1, если в заголовке ничего не было изменено при передаче. Если в результате не получились все единичные биты (ошибка контрольной суммы), IP отбрасывает принятую датаграмму. Сообщение об ошибке не генерируется. Теперь задача верхних уровней каким-либо образом определить, что датаграмма отсутствует, и обеспечить повторную передачу.
ICMP, IGMP, UDP и TCP используют такой же алгоритм расчета контрольной суммы. Также TCP и UDP включают в себя различные поля из IP заголовка, в дополнение к своим собственным заголовкам и данным. RFC 1071 [Braden, Borman, and Partridge 1988] описывает технику и реализацию расчета контрольной суммы Internet. Так как маршрутизаторы обычно изменяют только поле TTL (уменьшают его значение на единицу), маршрутизатор может просто увеличить на единицу контрольную сумму, когда он перенаправляет полученную датаграмму, вместо того чтобы рассчитывать контрольную сумму заново для IP заголовка в целом. RFC 1141 [Mallory and Kullberg 1990] описывает как этого можно добиться.
Стандартные реализации BSD, однако, не используют метод обновления контрольной суммы на единицу при перенаправлении датаграммы.
Каждая IP датаграмма содержит IP адрес источника (source IP address) и IP адрес назначения (destination IP address). Это 32-битные значения, которые мы описали в разделе "Адресация Internet" главы 1.
И последнее поле - поле опций (options), это список дополнительной информации переменной длины. В настоящее время опции определены следующим образом:

безопасность и обработка ограничений (для военных приложений, описано в RFC 1108 [Kent 1991]),

запись маршрута (запись каждого маршрута и его IP адрес, глава 7, раздел "Опция записи IP маршрута"),

временная марка (запись каждого маршрута, его IP адрес и время, глава 7, раздел "IP опция временной марки"),

свободная маршрутизация от источника (указывает список IP адресов, через которые должна пройти датаграмма, глава 8, раздел "Опция IP маршрутизации от источника"), и

жесткая маршрутизация от источника (то же самое, что и в предыдущем пункте, однако IP датаграмма должна пройти только через указанные в списке адреса, глава 8, раздел "Опция IP маршрутизации от источника").

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

Специальные IP адреса.

Рисунок 3.9 Специальные IP адреса.

Мы разделили эту таблицу на три секции. Первые две записи содержат специальные адреса источников, затем адрес интерфейса loopback, и последние четыре записи - это широковещательные адреса.
Первые два пункта в таблице с идентификатором сети, равным 0, могут существовать только как адрес источника во время процедуры инициализации, когда хост определяет свой собственный IP адрес, например, с использованием протокола BOOTP (глава 16).
В разделе "Широковещательные запросы" главы 12 мы рассмотрим четыре типа широковещательных адресов более подробно.

Специальные IP адреса

Специальные IP адреса

В процессе описания подсетей может встретится семь специальных IP адресов (см. рисунок 3.9). На этом рисунке 0 означает поле, состоящее из всех бит, установленных в ноль, -1 означает поле из бит, установленных в единицы, а netid (идентификатор сети), subnetid (идентификатор подсети) и hostid (идентификатор хоста) обозначает соответствующие поля, которые установлены не в единицы и не в нули. Пустая колонка идентификатора подсети означает, что адреса не могут быть разбиты на подсети.

IP адрес	Может появляться как	Описание
ID сети	ID подсети	ID хоста	источник?	назначение?
0		0	OK	никогда	этот хост в этой сети (см. ограничения ниже)
0		hostid	OK	никогда	указывает хост в этой сети (см. ограничения ниже)
127		любой	OK	OK	адрес loopback (см. раздел "Интерфейс Loopback" главы 2)
-1		-1	никогда	OK	ограниченный широковещательный запрос (никогда не перенаправляется)
netid		-1	никогда	OK	широковещательный запрос, направляемый в сеть на netid
netid	subnetid	-1	никогда	OK	широковещательный запрос, направляемый в подсеть на netid, subnetid
netid	-1	-1	никогда	OK	широковещательный запрос, направляемый во все подсети на netid

Сравнение двух подсетей класса

Рисунок 3.8 Сравнение двух подсетей класса В, использующих маски подсети.


В процессе IP маршрутизации, сравнения, подобные этому, делаются все время с использованием двух IP адресов и маски подсети.

Упражнения

Упражнения

Должен ли быть адрес интерфейса loopback всегда 127.0.0.1?

На рисунке 3.6 определите маршрутизаторы, которые имеют больше двух интерфейсов.

В чем отличие маски подсети для адреса класса А с 16 битами для идентификатора подсети и адреса класса В с 8 битами для адреса подсети?

Прочитайте RFC 1219 [Tsuchiya 1991], для того чтобы познакомиться с рекомендуемой технологией назначения идентификаторов подсетей и идентификаторов хостов.

Можно ли использовать маску подсети 255.255.0.255 для адресов класса А?

Почему MTU для интерфейса loopback, показанного в разделе "Команда netstat", установлен в 1536?

Семейство протоколов TCP/IP построено на основе уровня IP, который определяет технологию передачи датаграмм по сети. Существуют семейства протоколов, которые основаны на применении сетевых технологий, ориентированных на соединения. Прочитайте [Clark 1988], чтобы найти три преимущества сетей с передачей датаграмм.

Назад
Компания | Услуги | Для клиентов | Библиотека | Галерея | Cофт | Линки
На главную

TCP-IP крупным планом

ARP Кэш

ARP Кэш

Эффективность функционирования ARP во многом зависит от ARP кэша (ARP cache), который присутствует на каждом хосте. В кэше содержатся Internet адреса и соответствующие им аппаратные адреса. Стандартное время жизни каждой записи в кэше составляет 20 минут с момента создания записи.
Содержимое ARP кэша можно увидеть с использованием команды arp(8). Опция -a показывает все записи, содержащиеся в кэше:
bsdi % arp -a
sun (140.252.13.33) at 8:0:20:3:f6:42
svr4 (140.252.13.34) at 0:0:c0:c2:9b:26
48-битные Ethernet адреса приведены в виде шести шестнадцатиричных чисел, разделенных двоеточиями. Дополнительные функции команды arp обсуждаются в разделе "Команда arp" главы 4.

ARP запрос и ARP отклик, сгенерированные

Рисунок 4.4 ARP запрос и ARP отклик, сгенерированные при запросе на Telnet соединение.

На рисунке А.3 в приложении А показан реальный вывод команды tcpdump, которую мы запустили на рисунке 4.4. Так как это первый пример вывода tcpdump в тексте, Вам стоит посмотреть приложение, чтобы увидеть как мы преобразовали вывод, чтобы он стал более красивым и читаемым.
Мы удалили 4 заключительные строки из вывода tcpdump, которые соответствуют разрыву соединения (более подробно рассматривается в главе 18), так как они не имеют отношения к нашему обсуждению.
В строке 1 приводится аппаратный адрес источника (bsdi), в данном случае - 0:0:c0:6f:2d:40. Аппаратный адрес назначения ff:ff:ff:ff:ff:ff, являющийся широковещательным адресом Ethernet. Каждый Ethernet интерфейс на кабеле получит фрейм и обработает его, как показано на рисунке 4.2.
Следующее поле вывода в строке 1, arp, означает, что тип фрейма (frame type) установлен в 0x0806, что означает либо ARP запрос, либо ARP отклик.
Значение 60, напечатанное после слов arp и ip, в каждой из 5 строк означает длину фрейма Ethernet. Так как размер ARP запроса и ARP отклика составляет 42 байта (28 байт - ARP сообщение, 14 байт - Ethernet заголовок), каждый фрейм дополняется до минимума Ethernet: 60 байт.
Если обратиться к рисунку 1.7, то можно увидеть, что минимальный размер (60 байт) включает в себя 14-байтный Ethernet заголовок, однако не включает 4-байтный Ethernet завершитель. В некоторых книгах минимум приводится как 64 байта, что включает в себя и Ethernet завершитель. Мы целенаправленно не включили 14 байт заголовка Ethernet в минимум из 46 байт, показанных на рисунке 1.7. Максимальный размер составляет 1500 байт. Обычно эта величина называется максимальный блок передачи (MTU - maximum transmission unit) (См. рисунок 2.5). Мы часто используем понятие MTU, потому что оно ограничивает размер IP датаграммы, однако оно никак не связано с минимальным размером. Большинство драйверов устройств или интерфейсных плат автоматически дополняют Ethernet фреймы до минимального размера. IP датаграммы в строках 3, 4 и 5 (содержащие TCP сегменты) меньше чем минимум и также будут дополнены до 60 байт.
Следующее поле в строке 1, "arp кто имеет" (arp who-has), идентифицирует фрейм как ARP запрос с IP адресом svr4 в качестве адреса назначения и IP адресом bsdi в качестве адреса отправителя. tcpdump по умолчанию приводит имена хостов соответствующие IP адресам. (В разделе "Беспричинный ARP" мы воспользуемся опцией -n, чтобы посмотреть реальные IP адреса в ARP запросе.)
В строке 2 мы видим, что ARP запрос распространяется как широковещательный, тогда как адрес назначения ARP отклика это адрес bsdi (0:0:c0:6f:2d:40). ARP отклик посылается непосредственно запрашивающему хосту; он не является широковещательным.
tcpdump печатает для этого фрейма arp reply вместе с именем хоста и аппаратным адресом отвечающего.
В строке 3 отправляется первый TCP сегмент, содержащий требование об установлении соединения. Аппаратный адрес назначения это адрес хоста назначения (svr4). Мы рассмотрим этот сегмент более подробно в главе 18.
Число, которое печатается в каждой строке, после номера строки - это время (в секундах) когда пакет был принят программой tcpdump. В каждой строке после первой содержится разница во времени (в секундах) с предыдущей строкой. Это значение приводится в скобках. Как видно из рисунка, время между отправкой ARP запроса и получением ARP отклика составляет 2,2 мс. Первый TCP сегмент послан через 0,7 мс после этого. Таким образом, для динамического определения адреса с использованием ARP, в данном примере, потребовалось менее чем 3 мс.
И последнее на что следует обратить внимание в выводе tcpdump: мы не увидим ARP запрос от svr4, когда он посылает свой первый TCP сегмент (строка 4). Дело в том, что svr4 уже имеет данные о bsdi в своем ARP кэше, так как, когда система получает ARP запрос, помимо того что она посылает ARP отклик, она также сохраняет аппаратный адрес и IP адрес запросившего в своем ARP кэше. Это логично, так как если запросивший собирается послать IP датаграмму, то получившему скорее всего придется отправить ответ на эту датаграмму.

ARP запрос на несуществующий хост.

Рисунок 4.5 ARP запрос на несуществующий хост.

Сейчас мы не указываем опцию -e, так как мы уже знаем, что ARP запрос широковещательный.
Здесь интересно посмотреть, с какой частотой рассылаются ARP запросы: 5,5 секунд после первого запроса и снова через 24 секунды. (Мы рассмотрим тайм-ауты TCP и алгоритм повторных передач более подробно в главе 21.) Полное время, показанное в выводе tcpdump, составляет 29,5 секунды. Однако вывод от команды date перед и после команды telnet показывает, что запрос на соединение от Telnet клиента длился в течении 75 секунд. И действительно, мы увидим позже, что большинство BSD реализаций устанавливают ограничение в 75 секунд для завершения запроса на установление TCP соединения.
В главе 18, при рассмотрении последовательности TCP сегментов, которые посылаются в процессе установления соединения, мы увидим, что моменты отправки ARP запросов полностью совпадают с отправкой сегментов TCP SYN.
Обратите внимание на то, что в кабеле мы никогда не увидим TCP сегменты. Все что мы можем увидеть это ARP запросы. Пока не получен ARP отклик, TCP сегменты не могут быть отправлены, так как неизвестен аппаратный адрес назначения. Если запустить tcpdump в фильтрующем режиме, чтобы увидеть только данные TCP, вывода не будет вообще.

ARP запрос на несуществующий хост

ARP запрос на несуществующий хост

Что произойдет, если запрашиваемый хост выключен или не существует вообще? Попробуем указать несуществующий Internet адрес - идентификатор сети и идентификатор подсети будет от нашего локального Ethernet, однако указанного идентификатора хоста не существует. На рисунке 3.10 мы видели, что идентификаторов хостов с 36-го по 62-ой не существуют (идентификатор хоста 63 - широковещательный адрес). В данном примере мы будем использовать идентификатор хоста 36.
в этот раз telnet на IP адрес, а не на имя хоста (hostname)
bsdi % date ; telnet 140.252.13.36 ; date
Sat Jan 30 06:46:33 MST 1993
Trying 140.252.13.36 ...
telnet: Unable to connect to remote host : Connection timed out
Sat Jan 30 06:47:49 MST 1993 прошло 76 секунд

bsdi % arp -a проверяем ARP кэш
? (140.252.13.36) at (incomplete)

На рисунке 4.5 мы видим вывод tcpdump.
1 0.0 arp who-has 140.252.13.36 tell bsdi
2 5.509069 ( 5.5091) arp who-has 140.252.13.36 tell bsdi
3 29.509745 (24.0007) arp who-has 140.252.13.36 tell bsdi

"Беспричинный" ARP

"Беспричинный" ARP

Другая характеристика ARP, которую стоит рассмотреть - "беспричинный" ARP (gratuitous ARP). Он проявляется, когда хост посылает ARP запрос, основываясь на собственном IP адресе. Обычно это делается, когда интерфейс конфигурируется во время загрузки.
Если мы запустим tcpdump на хосте sun при загрузке хоста bsdi, то увидим пакет, показанный на рисунке 4.7.
1 0.0 0:0:c0:6f:2d:40 ff:ff:ff:ff:ff:ff arp 60:
arp who-has 140.252.13.35 tell 140.252.13.35

Формат ARP запроса или отклика при работе с Ethernet.

Рисунок 4.3 Формат ARP запроса или отклика при работе с Ethernet.


Два первых поля в Ethernet заголовке - поля источника и назначения Ethernet. Специальный адрес назначения Ethernet, состоящий из всех единиц, означает широковещательный адрес. Фреймы с таким адресом будут получены всеми Ethernet интерфейсами на кабеле.
Двухбайтовый тип фрейма (frame type) Ethernet указывает, данные какого типа, пойдут следом. Для ARP запроса или ARP отклика это поле содержит 0x0806.
Выражения аппаратный (hardware) и протокол (protocol) используются для описания полей в пакетах ARP. Например, ARP запрос запрашивает аппаратный адрес (в данном случае Ethernet адрес) соответствующий адресу протокола (в данном случае IP адрес).
Поле hard type указывает на тип аппаратного адреса. Для Ethernet это значение равно единице. Prot type указывает тип адреса протокола, к которому будет приведено соответствие. Для IP адресов используется значение 0x0800. По своему целевому назначению это значение соответствует полю типа во фрейме Ethernet, который содержит IP датаграмму. (См. рисунок 2.1.)
Два следующих однобайтных поля, hard size и prot size, указывают на размеры в байтах аппаратного адреса и адреса протокола. В ARP запросах и откликах они составляют 6 для Ethernet и 4 для IP адреса.
Поле op указывает на тип операции: ARP запрос (значение устанавливается в 1), ARP отклик (2), RARP запрос (3) и RARP отклик (4). (Мы поговорим о RARP в главе 5.) Это поле необходимо, так как поля типа фрейма (frame type) одинаковы для ARP запроса и ARP отклика.
Следующие четыре поля: аппаратный адрес отправителя (Ethernet адрес в данном примере), адрес протокола (IP адрес), аппаратный адрес назначения и адрес протокола назначения. Обратите внимание, что в данном случае происходит некоторое дублирование информации: аппаратный адрес отправителя может быть получен как из Ethernet заголовка, так и из ARP запроса.
Для ARP запроса все поля заполнены, за исключением аппаратного адреса назначения. Когда система получает ARP запрос, который предназначается ей, она вставляет свой аппаратный адрес, меняет местами адреса источника и назначения, устанавливает поле op в значение 2 и отправляет отклик.

Формат пакета ARP

Формат пакета ARP

На рисунке 4.3 показан формат ARP запроса и формат ARP отклика, в случае использования Ethernet и IP адресов. (ARP можно использовать в других сетей, при этом он способен устанавливать соответствие не только для IP адресов. Первые четыре поля, следующие за полем типа фрейма, указывают на типы и размеры заключительных четырех полей.)

Команда arp

Команда arp

Мы использовали эту команду с флагом -a, чтобы отобразить все записи ARP кэша. Существуют и другие опции.
Суперпользователь может использовать опцию -d, чтобы удалить запись из ARP кэша. (Это было сделано перед запуском некоторых примеров, чтобы показать изменения ARP.)
Записи могут быть добавлены с использованием опции -s. При использовании этой опции необходимо указать имя хоста и Ethernet адрес, IP адрес, соответствующий имени хоста, и Ethernet адрес добавляются в кэш. Подобная запись делается на постоянной основе (она не будет удалена из кэша по тайм-ауту), если только в конце командной строки не будет использовано ключевое слово temp.
Ключевое слово pub в конце командной строки с опцией -s приведет к тому, что система будет функционировать как ARP агент для этого хоста. Система будет отвечать на ARP запросы для IP адресов, соответствующих имени хоста, при этом ответ будет содержать указанный Ethernet адрес. Если объявленный адрес это адрес самой отвечающей системы, это означает, что система работает как уполномоченный агент ARP для указанного имени хоста.

Пример

Пример

Если мы введем команду
% ftp bsdi
будет выполнена следующая последовательность действий. (См. рисунок 4.2.)

Приложение, FTP клиент, вызывает функцию gethostbyname(3), чтобы конвертировать имя хоста (bsdi) в 32-битный IP адрес. Эта функция в DNS (Domain Name System) называется разборщиком (resolver) , мы опишем это подробно в главе 14. Подобное преобразование осуществляется с использованием DNS или, если существует маленькая сеть, то с помощью статического файла хостов (/etc/hosts).

FTP клиент требует установить TCP соединение с указанным IP адресом.

TCP посылает запрос на установление соединения удаленному хосту, посылая IP датаграммы по указанному IP адресу. (Мы рассмотрим как это делается более подробно в главе 18.)

Если хост назначения подключен к сети (Ethernet, Token ring, или к другому концу канала точка-точка), IP датаграмма может быть послана непосредственно хосту. Если хост назначения находится в удаленной сети, IP маршрутизатор определяет Internet адрес непосредственно подключенного маршрутизатора следующей пересылки, чтобы послать туда IP датаграмму. В обоих случаях IP датаграмма посылается либо хосту, либо маршрутизатору, подключенные непосредственно к данной сети.

Если используется Ethernet, посылающий хост должен конвертировать 32-битный адрес в 48-битный Ethernet адрес. Или другими словами, осуществить преобразование из логического Internet адреса в соответствующий физический аппаратный адрес. Этим занимается ARP. ARP работает в широковещательных сетях, где много хостов или маршрутизаторов подключено к одной и той же сети.

ARP посылает фрейм Ethernet, который называется ARP запрос (ARP request), каждому хосту в сети. Подобный метод рассылки называется широковещательным запросом (broadcast). На рисунке 4.2 широковещательный запрос показан пунктирными линиями. ARP запрос содержит IP адрес хоста назначения (имя которого bsdi) и запрос "если Вы владелец этого IP адреса, пожалуйста сообщите мне Ваш аппаратный адрес".

Пример "беспричинного" ARP.

Рисунок 4.7 Пример "беспричинного" ARP.

(Мы использовали флаг -n программы tcpdump, чтобы напечатать адреса в цифровом десятичном виде вместо имен хостов.) В терминах полей ARP запроса, адрес протокола отправителя и адрес протокола назначения идентичны: 140.252.13.35 (что соответствует хосту bsdi). Адрес источника в заголовке Ethernet, 0:0:c0:6f:2d:40 как показано программой tcpdump, эквивалентен аппаратному адресу отправителя (из рисунка 4.4).
"Беспричинный" ARP предоставляет две характеристики.

Он позволяет хосту определить, существует ли другой хост с тем же самым IP адресом. Хост bsdi не ожидает отклика на свой запрос, однако если отклик принят, на консоли возникает сообщение об ошибке "обнаружен дублирующий IP адрес с Ethernet адресом: a:b:c:d:e:f". Это предупреждение системному администратору о том, что одна из систем неправильно сконфигурирована.

Если хост, посылающий "беспричинный" ARP, только что изменил свой аппаратный адрес (может быть потому, что хост был выключен, удалена интерфейсная плата и затем хост был перезагружен), этот пакет заставляет другой хост на кабеле, который имеет запись в своем кэше для старого аппаратного адреса, обновить ARP кэш соответствующим образом. Малоизвестный факт о протоколе ARP [Plummer 1982] заключается в том, что если хост получает ARP запрос для IP адреса, который он уже имеет в кэше, содержимое кэша обновляется аппаратным адресом отправителя (Ethernet адресом) из запроса ARP. Это делается для любого запроса ARP, полученного хостом. (Повторим, что ARP запросы широковещательные, поэтому такие действия осуществляются всеми хостами в сети каждый раз при появлении ARP запроса.) [Bhide, Elnozahy, and Morgan 1991] описывает приложения, которые используют эту характеристику ARP. Она позволяет запасному (backup) файл-серверу занять место вышедшего из строя сервера с использованием "беспричинного" ARP запроса с запасным аппаратным адресом, однако с тем же IP адресом, который имел вышедший из строя хост. При этом все пакеты, направляемые серверу, вышедшему из строя, будут посланы на запасной сервер, а пользовательские приложения не будут знать о том, что основной сервер вышел из строя.

К сожалению, авторы затем отказались от этого подхода, так как он зависит от корректности реализации ARP на всех типах клиентов. Существуют различные типы ARP, которые не поддерживают эту спецификацию.
Наблюдения за всеми системами в подсети, используемой в этой книге, показывает, что SunOS 4.1.3 и 4.4BSD используют "беспричинный" ARP при загрузке, а SVR4 не поддерживает эту характеристику.

Пример уполномоченного ARP.

Рисунок 4.6 Пример уполномоченного ARP.


Когда какой-либо другой хост в подсети 140.252.1 (скажем, gemini) хочет послать IP датаграмму хосту sun на адрес 140.252.1.29, gemini сравнивает идентификатор сети (140.252) и идентификатор подсети (1), и если они идентичны, отправляет ARP запрос в верхний Ethernet (на рисунке 4.6) на IP адрес 140.252.1.29. Маршрутизатор netb распознает этот IP адрес как принадлежащий одному из dialup хостов и отвечает, отправив аппаратный адрес этого Ethernet интерфейса в кабель 140.252.1. Хост gemini посылает IP датаграмму в netb по Ethernet, а netb направляет датаграмму в sun по SLIP каналам с дозвоном (dialup). Это делает его прозрачным для всех хостов подсети 140.252.1, так как хост sun действительно находится "позади" маршрутизатора netb.
Если мы запустим команду arp на хосте gemini после общения с хостом sun, то увидим, что оба эти адреса принадлежат подсети 140.252.1 (netb и sun) и что им соответствует один аппаратный адрес. Как правило, это основная причина, по которой используется уполномоченный агент ARP.
gemini % arp -a
появится много строк про хосты из подсети 140.252.1
netb (140.252.1.183) at 0:80:ad:3:6a:80
sun (140.252.1.29) at 0:80:ad:3:6a:80

Еще одна деталь на рисунке 4.6, которую необходимо объяснить, это отсутствие IP адреса под квадратиком, который обозначает маршрутизатор netb (SLIP канал). Почему на обоих концах SLIP канала нет IP адреса, как между bsdi и slip? В разделе "Команда ifconfig" главы 3, из вывода команды ifconfig, мы заметили, что адрес назначения SLIP канала 140.252.1.183. NetBlazer не требует наличия IP адресов на каждом конце SLIP канала. (Это позволяет сэкономить несколько столь ценных в настоящее время IP адресов.) Он определяет какой хост посылает пакет в зависимости от того по какому последовательному интерфейсу прибыл пакет, поэтому нет необходимости каждому хосту на SLIP канале использовать уникальный IP адрес для своего канала с маршрутизатором. Все dialup хосты используют адрес 140.252.1.183 в качестве адреса назначения для своих SLIP каналов.
Уполномоченный агент ARP обеспечивает доставку датаграмм к маршрутизатору sun, однако как это делают другие хосты из подсети 140.252.13? Для направления датаграмм в другие хосты должна использоваться маршрутизация. Где-либо в сети 140.252 должны быть сделаны записи в таблице маршрутизации, поэтому все датаграммы, направляющиеся в подсеть 140.252.13 или в указанные хосты этой подсети, будут направляться на маршрутизатор netb. Этот маршрутизатор знает, как доставить датаграммы в их конечный пункт назначения, отправляя их через маршрутизатор sun.
Уполномоченный агент ARP также называется смешанным (promiscuous ARP) или расщепленным (ARP hack). Эти имена появились благодаря другому использованию уполномоченных агентов ARP: они применялись для того, чтобы спрятать друг от друга две физические сети между которыми находился маршрутизатор. В этом случае обе физические сети использовали один и тот же идентификатор сети, так как маршрутизатор, находящийся между ними, был сконфигурирован как уполномоченный ARP агент, чтобы отвечать на ARP запросы из одной сети к хостам в другой сети. Эта техника использовалась в прошлом, чтобы спрятать группу хостов с более старой версией TCP/IP на отдельном физическом кабеле. Две причины, по которым приходилось отделять эти "устаревшие" хосты, заключались в том, что, во-первых, они не могли поддерживать разделение на подсети и, во-вторых, использовали старые широковещательные адреса (идентификатор хоста состоял из всех нулевых бит вместо современного стандарта, при котором идентификатор хоста состоит из единичных битов).

Примеры ARP

Примеры ARP

В этом разделе мы воспользуемся командой tcpdump, чтобы посмотреть, как в действительности работает ARP при запуске обычного TCP приложения, например, Telnet. В приложении А содержится дополнительная информация о работе программы tcpdump.

Протоколы определения адреса: ARP и RARP.

Рисунок 4.1 Протоколы определения адреса: ARP и RARP.


ARP предоставляет динамическое сопоставление IP адресов и соответствующих аппаратных адресов. Мы используем термин динамическое, так как это происходит автоматически и обычно не зависит от используемых прикладных программ или воли системного администратора.
RARP, в основном, используется системами без жестких дисков (бездисковые рабочие станции или X терминалы), однако здесь требуется ручная конфигурация с участием системного администратора. Мы рассмотрим RARP в главе 5.

Реакция ARP на ввод пользователя: ftp hostname.

Рисунок 4.2 Реакция ARP на ввод пользователя: ftp hostname.

Хост назначения на ARP уровне получает этот широковещательный запрос, определяет, что отправитель спрашивает именно его IP адрес, и отвечает на него ARP откликом (ARP reply). Этот отклик содержит IP адрес и соответствующий аппаратный адрес.

ARP отклик принимается, и IP датаграмма, из-за которой начался обмен ARP запрос - ARP отклик, может быть послана.

IP датаграмма отправляется на хост назначения.

Фундаментальная концепция, заложенная в ARP, заключается в следующем. Сетевой интерфейс имеет аппаратный адрес (48-битное значение для Ethernet или Token ring). Фреймы, которыми обмениваются на аппаратном уровне, должны адресоваться к корректному интерфейсу. Однако TCP/IP испоьзует собственную схему адрессации: 32-битные IP адреса. Знание IP адреса хоста не позволяет ядру послать датаграмму этому хосту. Драйвер Ethernet должен знать аппаратный адрес пункта назначения, чтобы послать туда данные. В задачу ARP входит обеспечение динамического соответствия между 32-битными IP адресами и аппаратными адресами, используемыми различными сетевыми технологиями.
Каналы точка-точка не используют ARP. Когда эти каналы конфигурируются (обычно во время загрузки), ядру необходимо сказать IP адрес для каждого конца канала. Аппаратные адреса, такие как Ethernet адреса, в данном случае не используются.

Тайм-аут ARP кэша

Тайм-аут ARP кэша

Для записей, вводимых в ARP кэш, обычно устанавливается тайм-аут. (В разделе "Команда arp" мы увидим, что команда arp позволяет системному администратору поместить в кэш определенную запись, и на нее тайм-аут распространяться не будет.) Реализации, произошедшие от Berkeley, обычно установливают тайм-аут, в 20 минут для завершенной записи и 3 минуты для незавершенной записи. (Мы видели незавершенную запись в предыдущем примере, когда заставили отправить ARP запрос на несуществующий хост.) Эти реализации обычно перестартовывают 20-минутный тайм-аут для записи каждый раз, когда эта запись используется.
Требования к хостам Host Requirements RFC говорит, что запись должна удаляться по тайм-ауту, даже если данная запись используется, однако большинство реализаций, произошедших от Berkeley, не делают этого - они перестартовывают тайм-аут каждый раз, когда происходит обращение к записи.

Типичный пример

Типичный пример

Чтобы посмотреть как функционирует ARP, мы запустим команду telnet, чтобы подсоединиться к discard (discard server - сервер, не предоставляющий пользователю никаких услуг) серверу.
bsdi% arp -a проверяем, что ARP кэш пуст
bsdi% telnet svr4 discard подсоединяемся к серверу
Trying 140.252.13.34 ...
Connected to svr4.
Escape character is '^]' .
^] нажимаем Control и правую квадратную скобку,
telnet> quit чтобы получить приглашение Telnet и закрыть сессию
Connection closed.

Пока осуществляются эти действия, мы запускаем команду tcpdump с опцией -e на другом хосте (sun). Это позволит нам посмотреть аппаратные адреса (48-битные адреса Ethernet).
1 0.0 0:0:c0:6f:2d:40 ff:ff:ff:ff:ff:ff arp 60:
arp who-has svr4 tell bsdi
2 0.002174 (0.0022) 0:0:c0:c2:9b:26 0:0:c0:6f:2d:40 arp 60:
arp reply svr4 is-at 0:0:c0:c2:9b:26
3 0.002831 (0.0007) 0:0:c0:6f:2d:40 0:0:c0:c2:9b:26 ip 60:
bsdi.1030>svr4.discard: S 596459521:596459521 (0)
win 4096 [tos 0x10]
4 0.007834 (0.0050) 0:0:c0:c2:9b:26 0:0:c0:6f:2d:40 ip 60:
svr4.discard>bsdi.1030: S 3562228252:3562228252 (0)
ack 596459522 win 4096
5 0.009615 (0.0018) 0:0:c0:6f:2d:40 0:0:c0:c2:9b:26 ip 60:
bsdi.1030>svr4.discard: . ack 1 win 4096 [tos 0x10]

Уполномоченный агент ARP

Уполномоченный агент ARP

Уполномоченный агент ARP позволяет маршрутизатору отвечать на ARP запросы в одну сеть, в то время как запрашиваемый хост находится в другой сети. С помощью этого средства происходит обман отправителя, который отправил ARP запрос, после чего он думает, что маршрутизатор является хостом назначения, тогда как в действительности хост назначения находится "на другой стороне" маршрутизатора. Маршрутизатор выступает в роли уполномоченного агента хоста назначения, перекладывая пакеты от другого хоста.
Для того чтобы лучше описать работу уполномоченных агентов ARP, мы рассмотрим пример. Из рисунка 3.10 видно, что система sun подключена к двум сетям Ethernet. Однако в действительности это не так, в чем можно убедиться, если сравнить этот рисунок с рисунком, который приведен на внутренней стороне обложки. Между sun и подсетью 140.252.1 находится маршрутизатор, который выступает в роли уполномоченного агента ARP, при этом все выглядело так, как будто sun находится в подсети 140.252.1. На рисунке 4.6 показано, что Telebit NetBlazer, названный netb, находится между подсетью и хостом sun.

Упражнения Вернемся к команде

Упражнения

Вернемся к команде, которую мы исполнили, чтобы получить вывод, показанный на рисунке 4.4. Что произойдет, если после того как мы проверили локальный ARP кэш и он оказался пустым, мы введем команду bsdi % rsh svr4 arp -a


чтобы проверить, что ARP кэш также пуст на хосте назначения? (Эта команда исполнит команду arp -a на хосте svr4.)

Опишите тест, который позволит определить, корректно ли обрабатывает определенный хост "беспричинные" ARP запросы.

Шаг номер 7 в разделе "Пример" может занять определенное время (миллисекунды), потому что пакет отправлен и ARP ожидает ответа. Как Вы думаете, обработает ли ARP несколько датаграмм, которые прибыли от IP на тот же адрес назначения в течение этого периода времени?

В конце раздела "Примеры ARP" мы упомянули, что RFC Host Requirements и Berkeley реализации отличаются с точки зрения обработки тайм-аутов для активных записей ARP. Что произойдет, если клиент Berkeley постарается установить контакт с сервером, который был выключен и из него была удалена плата Ethernet? Изменится ли что-нибудь, если сервер выдаст "беспричинный" ARP запрос при загрузке?

Назад
Компания | Услуги | Для клиентов | Библиотека | Галерея | Cофт | Линки
На главную

TCP-IP крупным планом

Формат пакета RARP

Формат пакета RARP

Формат пакета RARP практически идентичен пакету ARP (см. рисунок 4.3). Единственное отличие заключается в том, что поле тип фрейма (frame type) для запроса или отклика RARP установлено в 0x8035, а поле op имеет значение 3 для RARP запроса и значение 4 для RARP отклика.
RARP запрос является широковещательным, а RARP отклик обычно персональный.

Несколько RARP серверов в сети

Несколько RARP серверов в сети

Еще одна особенность заключается в том, что RARP запросы посылаются в виде широковещательных запросов аппаратного уровня, как показано на рисунке 5.2. Это означает, что они не перенаправляются маршрутизаторами. Чтобы позволить бездисковым системам загружаться, даже если RARP сервер выключен, в сети обычно существуют несколько RARP серверов (на одном и том же кабеле).
По мере того как количество серверов растет (чтобы повысить надежность), увеличивается сетевой траффик, так как каждый сервер посылает RARP отклик на каждый RARP запрос. Бездисковые системы, которые посылают RARP запросы, обычно используют первый полученный ими RARP отклик. (Мы никогда не имели подобных проблем с ARP, потому что только один хост посылает ARP отклик.) Более того, существует вероятность, что несколько RARP серверов отправят отклики одновременно, увеличивая тем самым количество коллизий в Ethernet.

Примеры RARP

Примеры RARP

В нашей сети мы можем заставить хост sun загружаться из сети, вместо того чтобы загружаться с локального диска. Если мы запустили RARP сервер и tcpdump на хосте bsdi, то получим вывод, показанный на рисунке 5.1. Мы используем флаг -e, чтобы команда tcpdump показывала аппаратные адреса:
1 0.0 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
2 0.13 (0.13) 0:0:c0:6f:2d:40 8:0:20:3:f6:42 rarp 42:
rarp reply 8:0:20:3:f6:42 at sun
3 0.14 (0.01) 8:0:20:3:f6:42 0:0:c0:6f:2d:40 ip 65:
sun.26999>bsdi.tftp: 23 RRQ "8CFC0D21.SUN4C"

RARP серверы как пользовательские процессы

RARP серверы как пользовательские процессы

Основная задача RARP сервера заключается в том, чтобы предоставить соответствие между аппаратными адресами и IP адресами для множества хостов (все бездисковые системы в сети). Необходимая информация содержится в дисковом файле (обычно /etc/ethers в UNIX системах). Так как ядро обычно не читает дисковые файлы, функция RARP сервера реализуется с использованием пользовательского процесса, который не является частью ядра TCP/IP.
Далее, можно отметить, что RARP запросы передаются в качестве Ethernet фреймов со специфическим полем типа фрейма Ethernet (0x8035 на рисунке 2.1). Это означает, что RARP сервер должен обладать способностью отправлять и принимать Ethernet фреймы подобного типа. В приложении А мы опишем как для приема подобных фреймов используются BSD Packet Filter, Sun Network Interface Tap и SVR4 Data Link Provider Interface. Так как посылка и прием подобных фреймов зависит от системы, реализация RARP сервера также зависит от системы.

RARP запрос при отсутствии в сети RARP сервера.

Рисунок 5.2 RARP запрос при отсутствии в сети RARP сервера.

Когда тайм-аут достигает определенного предела (больше чем 42,80 секунды), он сбрасывается вновь в 5,34 секунды.
Подобное увеличение значения тайм-аута - это наилучший подход, так как каждый раз используется одно и то же значение. На рисунке 6.8 мы увидим неверный подход, с помощью которого осуществляются тайм-ауты и повторные передачи, а в главе 21 мы рассмотрим метод используемый в TCP.

Реализация RARP сервера

Реализация RARP сервера

Тогда как концепция RARP довольно проста, реализация RARP сервера сильно зависит от системы и довольно сложна. Напротив, реализация ARP сервера проста и является, как правило, частью реализации ядра TCP/IP. Так как ядро знает собственные IP адреса и аппаратные адреса, при получении ARP запроса для одного из IP адресов оно просто формирует отклик с соответствующим аппаратным адресом.

Упражнения

Упражнения

Требуется ли для RARP отдельное поле типа фрейма (frame type)? Может ли быть использовано одно и то же значение 0x0806 для ARP и RARP?

Если в сети находится несколько RARP серверов, как они могут сделать так, чтобы предотвратить коллизии своих ответов?

Назад
Компания | Услуги | Для клиентов | Библиотека | Галерея | Cофт | Линки
На главную

Запрос и отклик RARP.

Рисунок 5.1 Запрос и отклик RARP.

Запрос RARP широковещательный (строка 1), а отклик RARP (строка 2) персональный. Вывод в строке 2, at sun, означает, что RARP отклик содержит IP адрес хоста sun (140.252.13.33).
В строке 3 мы видим, что как только sun получил свой IP адрес, он выдал TFTP запрос на чтение (RRQ) файла 8CFC0D21.SUN4C. (TFTP это простой протокол передачи файлов - Trivial File Transfer Protocol. Мы рассмотрим его более подробно в главе 15.) Восемь шестнадцатиричных цифр в имени файла это шестнадцатиричное представление IP адреса 140.252.13.33 хоста sun. Это IP адрес, который мы получили в отклике RARP. Оставшаяся часть имени файла, SUN4C, указывает на тип системы, которая загружается.
В строке 3 tcpdump сообщает, что это IP датаграмма длиной 65, а не UDP датаграмма (которая в действительности является ей), так как мы запустили tcpdump с флаго -e, чтобы получить в выводе аппаратные адреса. Еще один момент на, который необходимо обратить внимание на рисунке 5.1, заключается в том, что длина Ethernet фрейма в строке 2 меньше чем установленный минимум (который, как мы упоминали в разделе "Примеры ARP" главы 4, должен быть равен 60 байтам). Причина этого заключается в том, что мы запустили tcpdump на системе, которая посылает этот Ethernet фрейм (bsdi). Приложение, rarpd, пишет 42 байта в устройство пакетного фильтра BSD (BSD Packet Filter) (14 байт - Ethernet заголовок и 28 байт - отклик RARP), именно это и видит tcpdump. Однако драйвер устройства Ethernet дополняет этот короткий фрейм до минимального размера, необходимого для передачи (60 байт). Если бы мы запустили tcpdump на другом компьютере, длина составила бы 60 байт.
Также мы видим, что когда бездисковая система получает свой IP адрес в отклике RARP, она осуществляет TFTP запрос, чтобы прочитать загрузочный имидж. Сейчас мы не будем подробно рассматривать, как загружаются бездисковые системы. (В главе 16 описывается последовательность загрузки бездисковых X терминалов с использованием RARP, BOOTP и TFTP.)
На рисунке 5.2 показаны пакеты, которые появляются в том случае, если в сети нет RARP сервера. Адрес назначения каждого пакета - широковещательный адрес Ethernet. Адрес Ethernet, следующий за who-is, это аппаратный адрес хоста которому требуется информация, а адрес Ethernet, следующий за tell, это аппаратный адрес отправителя.
Обратите внимание на частоту повторных передач. Первая повторная передача происходит через 6,55 секунд, затем интервал увеличивается до 42,80 секунд, затем через 5,34 секунды, затем через 6,55 секунд и снова через 42,79 секунды. Если мы рассчитаем разницу между каждым тайм-аутом, мы заметим эффект удвоения: между 5,34 и 6,55 - 1,21 секунды, между 6,55 и 8,97 - 2,42 секунды, между 8,97 и 13,80 - 4,83 секунды и так далее.
1 0.0 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
2 6.55 ( 6.55) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
3 15.52 ( 8.97) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
4 29.32 (13.80) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
5 52.78 (23.46) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
6 95.58 (42.80) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
7 100.92 ( 5.34) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
8 107.47 ( 6.55) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
9 116.44 ( 8.97) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
10 130.24 (13.80) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
11 153.70 (23.46) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
12 196.49 (42.79) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42

TCP-IP крупным планом

Другие возможные варианты

Другие возможные варианты

Существуют другие способы получить время и дату.

Мы описали сервис дневного времени и сервис времени в разделе "Стандартные простые сервисы" главы 1. Первый возвращает текущую дату и время в формате, понятном для человека - в виде строк ACSII символов. Мы можем проверить работу этого сервиса с использованием команды telnet:

sun % telnet bsdi daytime
Trying 140.252.13.35 ...
Connected to bsdi.
Escape character is '^]'. первые три строки - вывод Telnet клиента
Wed Feb 3 16:38:33 1993 это вывод сервиса дневного времени
Connection closed by foreign host. это опять вывод Telnet клиента

Сервер времени возвращает 32-битное двоичное значение, содержащее количество секунд после полуночи 1 января 1900 года, UTC. (Команда rdate, которую мы упоминали ранее, использует сервис времени TCP.)

Для получения более точного времени используется протокол сетевого времени (NTP - Network Time Protocol), который описан в RFC 1305 [Mills 1992]. Этот протокол использует определенную технику поддержания точности часов для группы систем в локальной или глобальной сети с точностью до миллисекунды. Для более подробного изучения функционирования этого протокола, необходимо обратиться к RFC.

Open Software Foundation (OSF) Distributed Computing Environment (DCE) определяет сервис распределенного времени (DTS - Distributed Time Service), который также осуществляет синхронизацию часов между хостами. [Rosenberg, Kenney, and Fisher 1992] более подробно описывает этот сервис.

В Unix системах Berkeley существует демон timed(8) , который используется для синхронизации часов систем, находящихся в локальной сети. В отличие от NTP и DTS, timed не работает в глобальных сетях.

Генерация ICMP ошибки о недоступности

Рисунок 6.8 Генерация ICMP ошибки о недоступности порта в ответ на TFTP запрос.

ICMP ошибка о недоступности порта возвращается немедленно (строка 4). Однако TFTP клиент игнорирует ICMP сообщение и посылает следующую UDP датаграмму примерно через 5 секунд (строка 5). Это повторяется трижды, перед тем как клиент прекращает свои попытки.
Обратите внимание на то, что ICMP сообщения передаются между хостами без номера порта назначения, тогда как каждая 20-байтовая UDP датаграмма выходит из указанного порта (2924) в указанный порт (8888).
Число 20 в конце каждой UDP строки это длина данных в UDP датаграмме. В данном примере 20 - это сумма двухбайтного кода операции (opcode) TFTP, 9-байтного имени (temp.foo) и 9-байтной строки netascii. (На рисунке 15.1 подробно описано содержимое пакета TFTP.)
Если мы запустим тот же пример с опцией -e команды tcpdump, то увидим точную длину каждого ICMP сообщения о недоступности порта, которое возвращается отправителю. Длина составляет 70 байт. (см. рисунок 6.9).

ICMP ошибка недоступности порта

ICMP ошибка недоступности порта (ICMP Port Unreachable Error)

В двух последних разделах описаны запросы ICMP - маски адреса, и запросы и отклики временной марки. Сейчас мы рассмотрим ICMP сообщения об ошибках, а именно: сообщение о недоступности порта, подкод сообщения ICMP о недоступности пункта назначения. Также рассмотрим дополнительную информацию, которая возвращается в ICMP сообщении об ошибке. Для этого воспользуемся UDP (глава 11).
Если UDP принимает датаграмму, порт назначения которой не соответствует порту, который обслуживается каким-либо процессом, UDP выдает ICMP сообщение о недоступности порта. Попробуем получить ошибку недоступности порта с использованием TFTP клиента. (TFTP подробно описан в главе 15.)
TFTP сервер использует заранее-известный UDP порт 69. Однако большинство программ TFTP клиента позволяют указать другой порт с помощью команды connect. В данном случае мы указали порт 8888:
bsdi % tftp
tftp> connect svr4 8888 указываем имя сервера и номер порта
tftp> get temp.foo пробуем получить файл
Transfer timed out. 25 секунд спустя истекает время таймера
tftp> quit

Команда connect сохраняет имя хоста, с которым необходимо установить соединение, и номер порта на этом хосте для дальнейшего использования командой get. После того как введена команда get, UDP датаграмма посылается на порт 8888 хоста svr4. На рисунке 6.8 показан вывод команды tcpdump, иллюстрирующий обмен пакетами.
Перед тем как послать UDP датаграмму на svr4, отправляется ARP запрос, для того чтобы определить аппаратный адрес (строка 1). Возвращается ARP отклик (строка 2), после чего отправляются UDP датаграммы (строка 3). (Мы оставили ARP запрос-отклик в выводе команды tcpdump, чтобы напомнить Вам, что этот обмен необходим перед отправкой первой IP датаграммы с одного хоста на другой. В следующих примерах мы не будем приводить ARP обмен.)
1 0.0 arp who-has svr4 tell bsdi
2 0.002050 (0.0020) arp reply svr4 is-at 0:0:c0:c2:9b:26

3 0.002723 (0.0007) bsdi.2924 > svr4.8888: udp 20
4 0.006399 (0.0037) svr4 > bsdi: icmp: svr4 udp port 8888 unreachable

5 5.000776 (4.9944) bsdi.2924 > svr4.8888: udp 20
6 5.004304 (0.0035) svr4 > bsdi: icmp: svr4 udp port 8888 unreachable

7 10.000887 (4.9966) bsdi.2924 > svr4.8888: udp 20
8 10.004416 (0.0035) svr4 > bsdi: icmp: svr4 udp port 8888 unreachable

9 15.001014 (4.9966) bsdi.2924 > svr4.8888: udp 20
10 15.004574 (0.0036) svr4 > bsdi: icmp: svr4 udp port 8888 unreachable

11 20.001177 (4.9966) bsdi.2924 > svr4.8888: udp 20
12 20.004759 (0.0036) svr4 > bsdi: icmp: svr4 udp port 8888 unreachable

ICMP сообщение, вернувшееся в

Рисунок 6.9 ICMP сообщение, вернувшееся в нашем примере "порт UDP недоступен".


Одно из правил, которому подчиняется ICMP, заключается в том, что ICMP сообщение об ошибке (см. последнюю колонку на рисунке 6.3) должно включать IP заголовок (включая все опции) датаграммы, на которую сгенерирована ошибка. Также ICMP сообщение об ошибке содержит, по крайней мере, первые 8 байт из IP датаграммы, которые следуют за IP заголовком. В нашем примере первые 8 байт, следующие за IP заголовком, содержат UDP заголовок (рисунок 11.2).
Очень важный факт заключается в том, что UDP заголовок содержит номера портов источника и назначения. В данном случае это порт назначения (8888), из-за которого было сгенерировано ICMP сообщение о недоступности порта. Номер порта источника (2924) может быть использован системой, получившей ICMP сообщение об ошибке, чтобы установить соответствие между принятой ошибкой и конкретным пользовательским процессом (в данном случае TFTP клиент).
Одна из причин, по которой IP заголовок датаграммы, которая вызвала сообщение об ошибке, посылается обратно, заключается в том, что этот IP заголовок содержит поле протокола, которое позволяет ICMP модулю понять, как необходимо интерпретировать следующие 8 байт (в данном примере - UDP заголовок). Если обратиться к TCP заголовку (см. рисунок 17.2), то мы увидим, что номера портов источника и назначения содержатся в первых 8 байтах TCP заголовка. Общий формат ICMP сообщений о недоступности показан на рисунке 6.10.

ICMP сообщение.

Рисунок 6.2 ICMP сообщение.


В этой главе мы рассмотрим ICMP сообщения в целом, некоторые из них подробно: запрос и отклик маски адреса, запрос и отклик временной марки и сообщение о недоступности порта. В главе 7 мы обсудим, с использованием программы Ping, эхо запрос и эхо отклик, а в главе 9 рассмотрим ICMP сообщения, связанные с IP маршрутизацией.

ICMP запрос и отклик маски адреса.

Рисунок 6.4 ICMP запрос и отклик маски адреса.


Поля идентификатора и номера последовательности в ICMP сообщении могут быть установлены по выбору отправителя, эти же значения будут возвращены в отклике. Именно таким образом отправитель идентифицирует отклик на свой запрос.
Мы можем написать простую программу (которая называется icmpaddrmask), которая выдает ICMP запрос маски адреса и печатает все отклики. Обычно, запрос отправляется на широковещательный адрес, мы поступим точно так же. Адрес назначения (140.252.13.63) это широковещательный адрес для подсети 140.252.13.32 (см. рисунок 3.12).
sun % icmpaddrmask 140.252.13.63
received mask = ffffffe0, from 140.252.13.33 от самого себя
received mask = ffffffe0, from 140.252.13.35 от bsdi
received mask = ffff0000, from 140.252.13.34 от svr4

Первое, на что стоит обратить внимание в выводе программы, это то, что значение, возвращенное от svr4, неверно. Это произошло из-за того, что SVR4 возвращает общую маску подсети класса В, подразумевающую, что деление на подсети не осуществлено, даже несмотря на то что интерфейс svr4 сконфигурирован с правильной маской подсети:
svr4 % ifconfig emd0
emd0: flags=23inet 140.252.13.34 netmask ffffffe0 broadcast 140.252.13.63

Это одна из известных ошибок SVR4 возникающая при обработке ICMP запросов маски адреса.
Мы рассмотрим обмен пакетами для хоста bsdi, используя tcpdump. Вывод показан на рисунке 6.5. Была использована опция -e, которая позволяет посмотреть аппаратные адреса.
1 0.0 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff ip 60:
sun > 140.252.13.63: icmp: address mask request
2 0.00 (0.00) 0:0:c0:6f:2d:40 ff:ff:ff:ff:ff:ff ip 46:
bsdi > sun: icmp: address mask is 0xffffffe0
3 0.01 (0.01) 0:0:c0:6f:2d:40 8:0:20:3:f6:42 ip 60:
svr4 > sun: icmp: address mask is 0xffff0000

ICMP запрос и отклик маски адреса

ICMP запрос и отклик маски адреса

ICMP запрос маски адреса используется бездисковыми системами, чтобы получить маску подсети (глава 3, раздел "Маска подсети") во время загрузки. Система посылает широковещательный ICMP запрос. (Это напоминает то, как бездисковые системы с использованием RARP получают свои IP адреса во время загрузки.) Альтернативный метод для бездисковых систем получить маски своих подсетей - протокол BOOTP, о котором рассказано в главе 16. На рисунке 6.4 показан формат ICMP запроса и отклика маски адреса.

ICMP запрос и отклик временной марки.

Рисунок 6.6 ICMP запрос и отклик временной марки.


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

ICMP запрос и отклик временной марки

ICMP запрос и отклик временной марки

ICMP запрос временной марки позволяет системе запросить другую систему о текущем времени. Рекомендуемое значение, которое должно быть возвращено, это количество миллисекунд, которые прошли с полуночи в формате UTC, (Универсальное согласованное время - Coordinated Universal Time). (В старых руководствах UTC называется Среднее время по Гринвичу - Greenwich Mean Time.) Одна из основных особенностей ICMP сообщения заключается в том, что оно предоставляет время в с точностью до миллисекунд, тогда как другие методы используемые для получения времени от удаленных систем (например, команда rdate, существующая в некоторых UNIX системах) предоставляют время с точностью до секунд. Недостаток заключается в том, что сообщается только время, прошедшее с полуночи, - запрашивающая система должена знать текущую дату. На рисунке 6.6 показан формат ICMP запроса и формат ICMP отклика временной марки.

ICMP запрос маски адреса, отправленный

Рисунок 6.5 ICMP запрос маски адреса, отправленный на широковещательный адрес.

Обратите внимание на то, что посылающий хост, sun, принимает ICMP отклик (строка вывода с комментарием "от самого себя", которая была показана ранее), даже если "в кабеле" ничего не было. Это основная характеристика широковещательных запросов: посылающий хост принимает копию широковещательного пакета через внутренний механизм loopback. Так как по определению термин "широковещательный запрос" означает все хосты в локальной сети, сюда же включается и посылающий хост. (Если обратиться к рисунку 2.4, можно увидить, что драйвер Ethernet, определив, что адрес назначения является широковещательным, посылает пакет в сеть и копирует его в интерфейс loopback.)
Затем bsdi отправляет широковещательным запросом отклик, тогда как svr4 посылает отклик только тому, кто отправил запрос. Обычно отклик должен быть персональным, если только IP адрес источника в запросе не установлен в 0.0.0.0, отправка откликов на широковещательный адрес это ошибка, допущенная в BSD/386.
Требования к хостам Host Requirements RFC гласят, что система не должна отправлять отклик о маске адреса, если она не является полномочным агентом для рассылки масок адресов. (Чтобы являтьься полномочным агентом и рассылать подобные отклики, система должна быть специально сконфигурирована. (См. приложение Е.) Однако, как мы видим из этого примера, большинство реализаций посылают отклик в ответ на полученный запрос. Иногда хосты даже посылают неверные отклики!
Обратимся к следующему примеру. Мы посылаем запрос о маске адреса на свой собственный IP адрес и на loopback адрес:
sun % icmpaddrmask sun
received mask = ff000000, from 140.252.13.33

sun % icmpaddrmask localhost
received mask = ff000000, from 127.0.0.1
В обоих случаях возвращенная маска адреса соответствует адресу loopback, адресу 127.0.0.1 сети класса А. Снова обратившись к рисунку 2.4 мы увидим, что IP датаграммы, посланные на собственный IP адрес хоста (140.252.13.33 в данном примере), в действительности посылаются на loopback интерфейс. ICMP отклик о маске адреса должен соответствовать маске подсети интерфейса, на которой был принят запрос (при этом хост с несколькими интерфейсами может иметь различные маски подсети для каждого интерфейса), а в нашем случае оба запроса получены с интерфейса loopback.

Инкапсуляция ICMP сообщений в IP датаграммы.

Рисунок 6.1 Инкапсуляция ICMP сообщений в IP датаграммы.


Официальная спецификация ICMP находится в RFC 792 [Postel 1981b].
На рисунке 6.2 показан формат ICMP сообщения. Первые 4 байта одинаковы для всех сообщений, однако остальные отличаются в зависимости от типа сообщения. Мы будем показывать точный формат каждого сообщения, по мере того как будем их описывать.
Существует 15 различных значений для поля типа (type), которые указывают на конкретныей тип ICMP сообщения. Для некоторых ICMP сообщений используются различные значения в поле кода (code), подобным образом осуществляется дальнейшее подразделение ICMP сообщений.
Поле контрольной суммы (checksum) охватывает ICMP сообщения целиком. Алгоритм, используемый при этом, такой же как тот, что был описан в разделе "IP заголовок" главы 3 при расчете контрольной суммы IP заголовка. Контрольная сумма ICMP присутствует всегда.

Обработка ICMP сообщений в 4.4BSD.

Рисунок 6.12 Обработка ICMP сообщений в 4.4BSD.

Обработка ICMP сообщений в 4.4BSD

Обработка ICMP сообщений в 4.4BSD

Так как ICMP охватывает очень широкий диапазон различных условий, начиная от фатальных ошибок и заканчивая информационными сообщениями, каждое ICMP сообщение обрабатывается по-своему даже в рамках одной реализации. Рисунок 6.12 это повтор рисунка 6.3, который показывает обработку возможных ICMP сообщений системой 4.4BSD.
Если в последней колонке указано "ядро", ICMP сообщение обрабатывается ядром, если - "пользовательский процесс", это означает, что сообщение передается всем пользовательским процессам, которые зарегистрированы в ядре так, что могут читать принятые ICMP сообщения. Если подобных пользовательских процессов нет, сообщение молча удаляется. (Эти пользовательские процессы также получают копии всех других ICMP сообщений, даже если те обрабатываются ядром, однако только после того, как ядро обработало сообщение.) Некоторые сообщения полностью игнорируются. И в заключение, если в последней колонке находится строка в кавычках, то эта строка является сообщением об ошибке Unix, соответствующее создавшемуся условию. Некоторые из ошибок мы рассмотрим в следующих главах.

тип	код	Описание	Кем обрабатывается
0	0	эхо отклик	пользовательский процесс
3		назначение недоступно - destination unreachable:
	0	сеть недоступна - network unreachable	"No route to host"
	1	хост недоступен - host unreachable	"No route to host"
	2	протокол недоступен - protocol unreachable	"Connection refused"
	3	порт недоступен - port unreachable	"Connection refused"
	4	необходима фрагментация, но установлен бит DF - fragmentation needed but DF bit set	"Message too long"
	5	сбой маршрутизация от источника - source route failed	"No route to host"
	6	сеть назначения неизвестна - destination network unknown	"No route to host"
	7	хост назначения неизвестен - destination host unknown	"No route to host"
	8	хост назначения изолирован - source host isolated (obsolete)	"No route to host"
	9	сеть назначения административно закрыта - destination network administratively prohibited	"No route to host"
	10	хост назначения административно закрыт - destination host administratively prohibited	"No route to host"
	11	сеть недоступна для TOS - network unreachable for TOS	"No route to host"
	12	хост недоступен для TOS - host unreachable for TOS	"No route to host"
	13	связь административно закрыта - communication administratively prohibited	(игнорируется)
	14	нарушено старшинство для хоста - host precedence violation	(игнорируется)
	15	старшинство разъединено - precedence cutoff in effect	(игнорируется)
4	0	подавление источника - source quench	ядром TCP, игнорируется UDP
5		перенаправление - redirect:
	0	перенаправление в сеть - redirect for network	ядро обновляет таблицу маршрутизации
	1	перенаправление в хост - redirect for host	ядро обновляет таблицу маршрутизации
	2	перенаправление для типа сервиса и сети - redirect for type-of-service and network	ядро обновляет таблицу маршрутизации
	3	перенаправление для типа сервиса и хоста - redirect for type-of-service and host	ядро обновляет таблицу маршрутизации
8	0	эхо запрос - echo request	ядро генерирует отклик
9	0	объявление маршрутизатора - router advertisement	пользовательский процесс
10	0	запрос к маршрутизатору - router solicitation	пользовательский процесс
11		время истекло - time exceeded:
	0	время жизни стало равным 0 в процессе передачи - time-to-live equals 0 during transit	пользовательский процесс
	1	время жизни стало равным 0 в процессе повторной сборки - time-to-live equals 0 during reassembly	пользовательский процесс
12		проблемы с параметрами - parameter problem:
	0	неверный IP заголовок - IP header bad	"Protocol not available"
	1	отсутствует необходимая опция - required option missing	"Protocol not available"
13	0	запрос временной марки - timestamp request	ядро генерирует отклик
14	0	отклик с временной маркой - timestamp reply	пользовательский процесс
15	0	информационный запрос - information request	(игнорируется)
16	0	информационный отклик - information reply	пользовательский процесс
17	0	запрос маски адреса - address mask request	ядро генерирует отклик
18	0	отклик с маской адреса - address mask reply	пользовательский процесс

Примеры

Примеры

Воспользуемся простой программой (которая называется icmptime), которая посылает ICMP запрос временной марки и печатает полученный отклик. Запустим эту программу в нашей маленькой сети:
sun % icmptime bsdi
orig = 83573336, recv = 83573330, xmit = 83573330, rtt = 2 ms
difference = -6 ms

sun % icmptime bsdi
orig = 83577987, recv = 83577980, xmit = 83577980, rtt = 2 ms
difference = -7 ms
Программа выдала три временные марки из ICMP сообщения: исходную (orig), приема (recv) и передачи (xmit). Из этого и следующих примеров видно, что все хосты установили временные марки приема и передачи в одно и то же значение.
Также мы рассчитали время возврата (rtt) , которое рассчитывается как время, когда был принят отклик, минус время, когда был отправлен запрос. difference - это временная марка приема минус исходная временная марка. На рисунке 6.7 показана взаимосвязь между этими значениями.

Сообщение о недоступности ICMP.

Рисунок 6.10 Сообщение о недоступности ICMP.


На рисунке 6.3 мы видели, что существует 16 различных ICMP сообщений о недоступности с кодами от 0 до 15. ICMP сообщение о недоступности порта имеет код 3. На рисунке 6.10 показано, что второе 32-битное слово в ICMP сообщении должно быть установлено в 0. Механизм определения транспортного MTU (глава 2, раздел "Транспортный MTU") позволяет маршрутизатору поместить MTU исходящего интерфейса в младшие 16 бит этого 32-битного значения, когда код равен 4 ("необходима фрагментация, однако установлен бит не фрагментировать "). Мы покажем пример подобной ошибки в разделе "ICMP ошибки о недоступности (требуется фрагментация)" главы 11.
Правила, по которым действует ICMP, позволяют системе вернуть больше чем первые 8 байт раздела данных IP датаграммы, которая вызвала ICMP ошибку, однако большинство Berkeley реализаций возвращают ровно 8 байт. В Solaris 2.2, с использованием опции ip_icmp_return_data_bytes, может быть указано, сколько байт необходимо возвращать, однако по умолчанию возвращаются первые 64 байта данных (приложение E, раздел "Solaris 2.2").

Типы сообщений ICMP.

Рисунок 6.3 Типы сообщений ICMP.

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

Типы сообщений ICMP

Типы сообщений ICMP

На рисунке 6.3 приведены возможные типы ICMP сообщений, как они определяются полями типа (type) и кода (code).
Последние две колонки на рисунке указывают, является ли ICMP сообщение запросом (query) или сообщением об ошибке (error). Подобное разделение необходимо, потому что сообщения об ошибках ICMP иногда обрабатываются специальным образом. Например, ICMP сообщение об ошибке никогда не генерируется в ответ на ICMP сообщение об ошибке. (Если не придерживаться этого правила, то ошибка будет генерироваться на ошибку до бесконечности.)
Когда посылается ICMP сообщение об ошибке, оно всегда содержит IP заголовок и первые 8 байт IP датаграммы, которая вызвала генерацию ICMP ошибки. Это позволяет принимающему ICMP модулю установить соответствие между полученным сообщением, одним из конкретных протоколов (TCP или UDP из поля протоколов в IP заголовке) и с одним из конкретных пользовательских процессов (с помощью номера порта TCP или UDP, который содержится в TCP или UDP заголовке в первых 8 байтах IP датаграммы). В разделе "ICMP ошибка недоступности порта (ICMP Port Unreachable Error)" главы 6 мы рассмотрим это более подробно.
Сообщение об ошибке ICMP никогда не генерируется в ответ на:

ICMP сообщение об ошибке. (ICMP сообщение об ошибке, однако, может быть сгенерировано в ответ на ICMP запрос.)

Датаграмму, направляющуюся на широковещательный IP адрес (рисунок 3.9) или групповой адрес IP (адрес класса D, рисунок 1.5).

Датаграмму, которая посылается широковещательным запросом на канальном уровне.

Фрагмент, который не является первым. (Мы опишем фрагментацию в разделе "Фрагментация IP" главы 11.)

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

тип	код	Описание	запрос	ошибка
0	0	эхо-отклик (отклик-Ping, глава 7)	·
3		назначение недоступно:
	0	сеть недоступна - network unreachable (раздел "ICMP ошибки о недоступности хоста и сети" главы 9)		·
	1	хост недоступен - host unreachable (раздел "ICMP ошибки о недоступности хоста и сети" главы 9)		·
	2	протокол недоступен - protocol unreachable		·
	3	порт недоступен - port unreachable (раздел "ICMP ошибка недоступности порта (ICMP Port Unreachable Error)" главы 6)		·
	4	необходима фрагментация, однако установлен бит “не фрагментировать”- fragmentation needed but don’t-fragment bit set (раздел "ICMP ошибки о недоступности" главы 11)		·
	5	не работает маршрутизация от источника - source route failed (глава 8, раздел "Опция IP маршрутизации от источника")		·
	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 (глава 9, раздел "ICMP ошибки о недоступности хоста и сети")		·
	12	хост недоступен для TOS - host unreachable for TOS (глава 9, раздел "ICMP ошибки о недоступности хоста и сети")		·
	13	связь административно закрыта путем фильтрации - communication administratively prohibited by filtering		·
	14	нарушено старшинство для хоста - host precedence violation		·
	15	старшинство разъединено - precedence cutoff in effect		·
4	0	подавление источника (элементарное управление потоком данных) - source quench (глава 11, раздел "ICMP ошибка подавления источника")		·
5		перенаправление - redirect (глава 11, раздел "ICMP ошибка подавления источника"):
	0	перенаправление в сеть - redirect for network		·
	1	перенаправление в хост - redirect for host		·
	2	перенаправление для типа сервиса и сети - redirect for type-of-service and network		·
	3	перенаправление для типа сервиса и хоста - redirect for type-of-service and host		·
8	0	эхо запрос - echo request (Ping запрос, глава 7)	·
9	0	объявление маршрутизатора - router advertisement (глава 9, раздел "ICMP сообщения поиска маршрутизатора")	·
10	0	запрос к маршрутизатору - router solicitation (глава 9, раздел "ICMP сообщения поиска маршрутизатора")	·
11		время истекло - time exceeded:
	0	время жизни стало равным 0 в процессе передачи - time-to-live equals 0 during transit (Traceroute, глава 8)		·
	1	время жизни стало равным 0 в процессе повторной сборки - time-to-live equals 0 during reassembly (глава 11, раздел "Фрагментация IP")		·
12		проблемы с параметрами - parameter problem:
	0	неверный IP заголовок - IP header bad		·
	1	отсутствует необходимая опция - required option missing		·
13	0	запрос временной марки - timestamp request (глава 6, раздел "ICMP запрос и отклик временной марки")	·
14	0	отклик с временной маркой - timestamp reply (глава 6, раздел "ICMP запрос и отклик временной марки")	·
15	0	информационный запрос - information request	·
16	0	информационный отклик - information reply	·
17	0	запрос маски адреса - address mask request (глава 6, раздел "ICMP запрос и отклик маски адреса")	·
18	0	отклик с маской адреса - address mask reply (глава 6, раздел "ICMP запрос и отклик маски адреса")	·

Упражнения

Упражнения

В конце раздела "Типы сообщений ICMP" мы привели 5 специальных условий, при которых сообщение об ошибке ICMP не посылается. Что произойдет, если эти 5 условий не соблюдены, а мы послали широковещательную UDP датаграмму на несоответствующий порт в локальном кабеле?

Прочитайте Host Requirements RFC [Braden 1989a], чтобы посмотреть, попадает ли генерация ICMP ошибки о недоступности порта под разделы "должен", "следует" или "может". В каком разделе и на какой странице это можно найти?

Прочитайте RFC 1349 [Almquist 1992], чтобы посмотреть, как поле типа сервиса IP (см. рисунок 3.2) должно быть установлено для ICMP.

Если Ваша система имеет команду netstat, используйте ее, чтобы посмотреть, какой тип ICMP сообщений принимается и посылается.

Назад
Компания | Услуги | Для клиентов | Библиотека | Галерея | Cофт | Линки
На главную

Временная диаграмма работы команды tcpdump

Временная диаграмма работы команды tcpdump

Здесь мы приводим временную диаграмму, соответствующую выводу команды tcpdump, приведенному на рисунке 6.11.

Временная диаграмма запроса TFTP на неверный порт.

Рисунок 6.11 Временная диаграмма запроса TFTP на неверный порт.


Время на рисунке увеличивается по направлению вниз, а метки, стоящие крайними слева на рисунке, соответствуют величинам времени в выводе команды tcpdump, приведенном на рисунке 6.8. Метки вверху - это имена хостов и номера портов каждой конечной системы. Однако, вертикальное представление времени на рисунке не точно соответствует реальному времени. При передаче данных UDP или TCP мы показываем пакет с помощью жирной линии.
Почему TFTP клиент осуществляет повторную передачу своего запроса после прихода сообщения ICMP? Особенность сетевого программирования, присутствующая в системах BSD, заключается в том, что пользовательский процесс, использующий UDP, не предупреждается о приеме ICMP сообщения на этот сокет, если только процесс не установил соединение (connect) к этому сокету. Стандартный TFTP клиент системы BSD не выдает connect, поэтому он никогда не получит уведомления о приходе ICMP ошибки.
Также необходимо обратить внимание на то, что при работе TFTP клиента используется алгоритм тайм-аутов и повторных передач. TFTP клиент просто осуществляет повторную передачу каждые 5 секунд, всего в течение 25 секунд. Позже мы увидим, что подобный алгоритм протокола TCP значительно лучше.
Устаревший алгоритм тайм-аутов и повторных передач, используемый TFTP клиентом, в настоящее время запрещен Host Requirements RFC. Тем не менее, все три системы в описываемой подсети и Solaris 2.2 до сих пор его используют. AIX 3.2.2 использует экспотенциальный рост тайм-аута, посылая пакеты с интервалом 0, 5, 15 и 35 секунд. В настоящее время рекомендуется именно такой способ расчета тайм-аутов. Более подробно мы обсудим тайм-ауты в главе 21.
И в заключение, обратите внимание на то, что ICMP сообщения вернулись примерно через 3,5 миллисекунды после отправки UDP датаграммы. В главе 7 мы увидим, что это примерно соответствует времени возврата для отклика Ping.

Взаимосвязь между значениями

Рисунок 6.7 Взаимосвязь между значениями, напечатанными программой icmptime.


Если принять за истину то, что одна половина RTT отводится под запрос, а другая половина под отклик, тогда часы отправителя должны быть настроены как difference минус половина RTT, чтобы иметь то же самое время, как у хоста к которому отправляется запрос. В предыдущем примере часы bsdi отставали на 7 и 8 миллисекунд от часов sun.
Так как временная марка является количеством миллисекунд после полуночи, UTC должны быть всегда меньше чем 86400000 (24х60х60х1000). Эти примеры были исполнены сразу после 16:00 во временной зоне имеющей отставание на 7 часов от UTC, таким образом, приемлемыми являются значения больше чем 82800000 (2300 часов).
Если мы запустим эту программу несколько раз на хост bsdi, то увидим, что последние цифры во временной марке передачи и приема всегда равны нулю. Это происходит из-за того, что программный релиз (Version 0.9.4) имеет часы с точностью 10 миллисекунд. (Мы опишем это в приложении В.)
Если мы запустим программу дважды на хост svr4, то увидим что уже три младшие цифры во временной марке SVR4 равны нулю:
sun % icmptime svr4
orig = 83588210, recv = 83588000, xmit = 83588000, rtt = 4 ms
difference = -210 ms

sun % icmptime svr4
orig = 83591547, recv = 83591000, xmit = 83591000, rtt = 4 ms
difference = -547 ms
По каким-то причинам SVR4 не предоставляет разрешение времени с точностью до миллисекунд при использовании временной марки ICMP. Подобная неточность делает расчет разницы во времени бесполезным, если разговор идет о миллисекундах.
Если мы обратимся к двум другим хостам в подсети 140.252.1, то увидим, что установка одних часов отличается от установки часов sun на 3,7 секунды, а других на 75 секунд:
sun % icmptime gemini
orig = 83601883, recv = 83598140, xmit = 83598140, rtt = 247 ms
difference = -3743 ms

sun % icmptime aix
orig = 83606768, recv = 83532183, xmit = 83532183, rtt = 253 ms
difference = -74585 ms
Другой интересный пример может быть получен при обращении к маршрутизатору gateway (маршрутизатор Cisco). Из примера видно, что если система возвращает нестандартное значение временной марки (отличающееся от количества миллисекунд после полуночи, UTC), старшие биты в 32-битной временной марке устанавливаются в единицу. Наша программа определяет это и печатает временные марки приема и передачи в треугольных скобках (после установки старших битов в ноль). Мы можем рассчитать разницу между исходной временной маркой и временной маркой приема.
sun % icmptime gateway
orig = 83620811, recv = <4871036>, xmit = <4871036>, rtt = 220 ms

sun % icmptime gateway
orig = 83641007, recv = <4891232>, xmit = <4891232>, rtt = 213 ms
Если запустить нашу программу на этот хост несколько раз, то можно заметить, что полученные значения имеют точность до миллисекунд и содержит количество миллисекунд с какой-то начальной точки, однако начальная точка не полночь, UTC. (Это может быть, например, счетчик, который увеличивается на единицу каждую миллисекунду с момента загрузки маршрутизатора.)
И в качестве последнего примера сравним часы sun с часами системы, которые считаются абсолютно точными - сервер NTP. (Мы расскажем о протоколе сетевого времени NTP - Network Time Protocol, ниже.)
sun % icmptime clock.llnl.gov
orig = 83662791, recv = 83662919, xmit = 83662919, rtt = 359 ms
difference = 128 ms

sun % icmptime clock.llnl.gov
orig = 83670425, recv = 83670559, xmit = 83670559, rtt = 345 ms
difference = 134 ms
Если вычесть из разницы (difference) половину RTT, то можно будет сказать, что часы sun торопятся на величину в диапазоне 51,5 - 38,5 миллисекунды.

TCP-IP крупным планом

Формат ICMP сообщения для эхо запроса и эхо отклика.

Рисунок 7.1 Формат ICMP сообщения для эхо запроса и эхо отклика.


Так же, как в случае других ICMP запросов, в отклике сервера должены содержаться поля идентификатора (identifier) и номера последовательности (sequence number). Кроме того, любые дополнительные данные, посланные клиентам, должны быть отражены эхом.
Реализации ping, присутствующие в Unix, устанавливают в поле идентификатора ICMP сообщения идентификатор процесса, отправляющего запрос. Это позволяет программе ping идентифицировать вернувшийся ответ, если на одном и том же хосте в одно и то же время запущено несколько программ ping.
Номер последовательности начинается с 0 и увеличивается на единицу каждый раз когда посылается следующий эхо запрос. ping печатает номер последовательности каждого возвращенного пакета, позволяя нам увидеть, потерялся ли пакет, поменялась ли последовательность движения пакетов и был ли пакет продублирован. Так как IP является ненадежным сервисом доставки датаграмм, любое из трех вышеперечисленных условий может появиться при работе программы ping.
Исторически сложилось так, что программа ping посылает эхо запрос один раз в секунду, печатая каждый эхо отклик в момент его возвращения. Однако новые разработки требуют указания опции -s, чтобы программа работала подобным образом. По умолчанию новые реализации посылают только один эхо запрос и выдают сообщение "host is alive" (хост доступен), если эхо отклик получен, или "no answer" (не отвечает), если отклик не получен в течение 20 секунд.

IP опция временной марки

IP опция временной марки

Опция IP временной марки во многом напоминает опцию записи маршрута. На рисунке 7.7 показан формат IP опции временной марки (сравните с рисунком 7.3).

Ненормальный вывод

Ненормальный вывод

Следующий пример был рассмотрен автором и является исходной точкой для дальнейшего описания ICMP сообщений о перенаправлении в главе 9. Мы посылаем ping на хост aix, находящийся в подсети 140.252.1, с хоста slip (доступ осуществляется через SLIP соединение с дозвоном на компьютере sun) с опцией записи маршрута. При этом получаем следующий вывод:
slip % ping -R aix
PING aix (140.252.1.92): 56 data bytes
64 bytes from 140.252.1.92: icmp_seq=0 ttl=251 time=650 ms
RR: bsdi (140.252.13.35)
sun (140.252.1.29)
netb (140.252.1.183)
aix (140.252.1.92)
gateway (140.252.1.4) почему используется этот маршрутизатор?
netb (140.252.1.183)
sun (140.252.13.33)
bsdi (140.252.13.66)
slip (140.252.13.65)
64 bytes from aix: icmp_seq=1 ttl=251 time=610 ms (same route)
64 bytes from aix: icmp_seq=2 ttl=251 time=600 ms (same route)
^?
--- aix ping statistics ---
4 packets transmitted, 3 packets recieved, 25% packet loss
round-trip min/avg/max = 600/620/650 ms

Мы могли бы запустить этот пример с хоста bsdi, но выбрали хост slip, чтобы увидеть все 9 IP адресов, которые появятся в списке RR.
Странность этого вывода заключается в том, что исходящая датаграмма (ICMP эхо запрос) направляется непосредственно от netb к aix, а возвращается (ICMP эхо отклик) от aix через маршрутизатор gateway, перед тем как попасть в netb. То что мы видим здесь, является характеристикой IP маршрутизации, которую мы опишем ниже. На рисунке 7.6 показан путь датаграммы.

Общий формат опции маршрута в IP заголовке.

Рисунок 7.3 Общий формат опции маршрута в IP заголовке.


Код (code) - однобайтовое поле, содержащее тип IP опции. Для опции RR установлено значение 7. Длина (len) - это полный размер в байтах опции RR, в данном случае 39. (Несмотря на то, что существует возможность указать опцию RR с размером меньше максимального, ping всегда предоставляет поле опции размером 39 байт, что позволяет записать до 9 IP адресов. Несмотря на то, что существует ограничение в размере опций в IP заголовке, оно, тем не менее, позволяет указать размер меньше максимального.)
Указатель (ptr) - это индекс в 39-байтной опции, который указывает на то, где хранится следующий IP адрес. Его минимальное значение 4, что указывает на первый IP адрес. Когда следующий IP адрес записывается в список, значение ptr меняется следующим образом: 8, 12, 16 и так до 36. После того как записан девятый адрес, ptr устанавливается в значение 40, указывая на то, что список полон. А теперь давайте зададим себе такой вопрос.
Когда маршрутизатор (который по определению имеет несколько интерфейсов) записывает свой IP адрес в список, какой IP адрес он записывает? Это должен быть адрес либо входящего интерфейса, либо исходящего. RFC 791 [Postel 1981a] указывает, что маршрутизатор записывает IP адрес исходящего интерфейса. Однако, мы увидим, что когда исходный хост (хост, запустивший ping) получает ICMP эхо отклик с включенной опцией RR, он вносит в список IP адрес своего входящего интерфейса.

Общий формат опции временной марки в IP заголовке.

Рисунок 7.7 Общий формат опции временной марки в IP заголовке.


Для опции временной марки поле кода (code) устанавливается в 0x44. Два поля длина (len) и указатель (ptr) такие же как в опции записи маршрута: полная длина опции (обычно 36 или 40) и указатель на следующий доступный пункт (5, 9, 13 и так далее).
Размер двух следующих полей составляет 4 бита: OF - поле переполнения (overflow) и FL - поле флагов (flags). Функционирование опции временной марки определяется полем флагов (flags), как показано на рисунке 7.8.

флаги (flags)	Описание
0	Запись только временных марок. Это как раз то, что мы показали на рисунке 7.7.
1	Каждый маршрутизатор записывает свой IP адрес и временную марку. Места в списке опций хватает только на четыре такие пары.
3	Отправитель устанавливает список опций, который должен состоять из 4-х пар IP адресов 0 (ноль) временных марок. Маршрутизатор записывает свою временную марку только в том случае, если следующий IP адрес из списка совпадает с IP адресом маршрутизатора.

Обычный пример

Обычный пример

Давайте попробуем запустить программу ping с опцией RR. Мы запустили ping с хоста svr4 на хост slip. Промежуточный роутер (bsdi) обрабатывает датаграмму, следующий вывод будет получен от svr4:
svr4 % ping -R slip
PING slip (140.252.13.65): 56 data bytes
64 bytes from 140.252.13.65: icmp_seq=0 ttl=254 time=280 ms
RR: bsdi (140.252.13.66)
slip (140.252.13.65)
bsdi (140.252.13.35)
svr4 (140.252.13.34)
64 bytes from 140.252.13.65: icmp_seq=1 ttl=254 time=280 ms (same route)
64 bytes from 140.252.13.65: icmp_seq=2 ttl=254 time=280 ms (same route)
^?
--- slip ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 270/276/280 ms

На рисунке 7.4 показаны 4 пересылки, через которые проходит пакет (по две в каждом направлении), а также IP адреса добавляемые к списку RR при каждой пересылке.

Опция записи IP маршрута

Опция записи IP маршрута

Программа ping предоставляет возможность просмотреть IP опцию записи маршрута (RR). В большинстве версий программы ping присутствует опция -R, которая включает характеристику записи маршрута. При использовании этой опции ping устанавливает опцию IP записи маршрута (RR) в исходящих датаграммах (которые содержат ICMP эхо запрос). При этом каждый маршрутизатор, который обрабатывает датаграмму, добавляет свой IP адрес в список, находящийся в дополнительном поле. Когда датаграмма достигает конечного пункта назначения, список IP адресов копируется в исходящий ICMP эхо отклик, а все маршрутизаторы на обратном пути также добавляют свои IP адреса в список. Когда ping принимает эхо отклик, печатает список IP адресов.
Как бы просто это не звучало, в действительности, запись маршрута - достаточно сложный процесс. Генерация IP опции RR хостом источником, обработка опции RR промежуточными маршрутизаторами и отражение входящего списка RR из ICMP эхо запроса в исходящий ICMP эхо отклик все это дополнительные и необязательные характеристики. Большинство систем в настоящее время поддерживают эти дополнительные характеристики, однако некоторые системы не отображают список IP адресов.
Самая большая проблема, однако, заключается в ограниченном размере IP заголовка, в который должен поместиться список IP адресов. Из рисунка 3.1 видно, что поле длины заголовка (header length) в IP заголовке составляет 4 бита, что ограничивает размер IP заголовка в пределах пятнадцати 32-битных слов (60 байт). Так как фиксированный размер IP заголовка составляет 20 байт, а RR опция использует 3 байта для своей установки (что мы опишем ниже), то остается 37 байт (60-20-3) на список адресов, а это, в свою очередь, позволяет поместить туда до 9 IP адресов. На заре развития ARPANET 9 IP адресов - было очень много, однако, в настоящее время, подобный размер существенно ограничивает работу команды ping с опцией -R. (В главе 8 мы рассмотрим программу Traceroute, которая используется для отслеживания маршрута, по которому двигается датаграмма.) Несмотря на все ограничения, опция записи маршрута работает и предоставляет возможность пронаблюдать, как обрабатываются опции IP. На рисунке 7.3 показан общий формат опции записи маршрута в IP датаграмме.

Программа ping с опцией записи маршрутизации.

Рисунок 7.4 Программа ping с опцией записи маршрутизации.


Маршрутизатор bsdi добавляет в список разные IP адреса в зависимости от направления движения датаграммы. Он всегда добавляет IP адрес исходящего интерфейса. Однако, когда ICMP эхо отклик достигает системы, которая инициировала запрос (svr4), она добавляет в список IP адрес входящего интерфейса.
Мы можем наблюдать за обменом пакетами с хоста sun, на котором запущена программа tcpdump с опцией -v (просмотр IP опций). На рисунке 7.5 показан вывод.
1 0.0 svr4>slip: icmp: echo request (ttl 32, id 35835,
optlen=40 RR{39}=RR{#0.0.0.0/0.0.0.0/0.0.0.0/
0.0.0.0/0.0.0.0/0.0.0.0/0.0.0.0/0.0.0.0/0.0.0.0} EOL)

2 0.267746 (0.2677) slip>svr4: icmp: echo reply (ttl 254, id 1976,
optlen=40 RR{39}=RR{140.252.13.66/140.252.13.65/
140.252.13.35/#0.0.0.0/0.0.0.0/0.0.0.0/0.0.0.0/ 0.0.0.0/0.0.0.0} EOL)

Программа Ping

Программа Ping

Мы будем называть программу ping, которая посылает эхо запросы - клиент, а хост, на который посылаются эхо запросы - сервер. Большинство реализаций TCP/IP поддерживают Ping сервер непосредственно в ядре - сервер не является пользовательским процессом. (Два сервиса, работающие с ICMP запросами, которые мы описали в главе 6, маска адреса и запросы временной марки, также обрабатываются непосредственно в ядре.) На рисунке 7.1 показаны ICMP эхо запрос и эхо отклик.

Работа программы ping с записью

Рисунок 7.6 Работа программы ping с записью маршрута, показывающая характеристику IP маршрутизации.


Проблема заключается в том, что aix не знает как послать IP датаграмму, направляющуюся в подсеть 140.252.13 к netb. Однако, aix имеет в своей таблице маршрутизации пункт по умолчанию, который сообщает о необходимости посылать все датаграммы на маршрутизатор gateway, если не существует конкретного маршрута к пункту назначения. Маршрутизатор gateway знает значительно больше о существующих маршрутах, чем любой другой хост в подсети 140.252.1. (В этой сети Ethernet присутствует более чем 150 хостов, и вместо того чтобы каждому иметь запущенный демон маршрутизации, они используют пункт "по умолчанию" (default), который указывает на маршрутизатор gateway.)
Вопрос, на который пока нет ответа, заключается в том, почему gateway не послал сообщение ICMP о перенаправлении (глава 9, раздел "ICMP ошибки перенаправления") на aix, чтобы обновить его таблицу маршрутизации? По некоторым причинам (возможно потому, что датаграмма, генерирующая перенаправление, является ICMP эхо запросом) перенаправление не произошло. Однако, если мы используем Telnet и подключимся к серверу дневного времени на aix, ICMP перенаправление произойдет, и таблица маршрутизации aix будет обновлена. Если мы затем запустим ping со включенной опцией записи маршрута, маршрут покажет, что датаграммы идут от netb к aix и назад к netb без дополнительной пересылки через маршрутизатор gateway. Мы рассмотрим сообщения ICMP о перенаправлении более подробно в разделе "ICMP ошибки перенаправления" главы 9.

Работа программы в глобальных сетях

Работа программы в глобальных сетях

При работе в глобальных сетях результат может значительно отличаться. Следующий пример был получен в рабочий день после полудня, время, когда Internet обычно довольно загружен:
gemini % ping vangogh.cs.berkeley.edu
PING vangogh.cs.berkeley.edu: 56 data bytes
64 bytes from (128.32.130.2): icmp_seq=0. time=660. ms
64 bytes from (128.32.130.2): icmp_seq=5. time=1780. ms
64 bytes from (128.32.130.2): icmp_seq=7. time=380. ms
64 bytes from (128.32.130.2): icmp_seq=8. time=420. ms
64 bytes from (128.32.130.2): icmp_seq=9. time=390. ms
64 bytes from (128.32.130.2): icmp_seq=14. time=110. ms
64 bytes from (128.32.130.2): icmp_seq=15. time=170. ms
64 bytes from (128.32.130.2): icmp_seq=16. time=100. ms
^? вводим символ прерывания
---- vangogh.CS.Berkeley.EDU PING Statistics ----
17 packets transmitted, 8 packets received, 52% packet loss
round-trip (ms) min/avg/max = 100/501/1780

Эхо запросы и эхо отклики с номерами последовательности 1, 2, 3, 4, 6, 10, 11, 12 и 13 были потеряны. Также обратите внимание на значительную разницу между величинами времен возврата. (Количество потерянных пакетов, а именно 52%, является ненормальным. Это неприемлимо для Internet даже в рабочие дни после полудня.)
При работе в глобальных сетях можно встретиться с дублированием пакетов (один и тот же номер последовательности появляется дважды или несколько раз), также может возникнуть перемешивание номеров последовательности (номер последовательности N+1 появляется перед номером последовательности N).

Работа программы в локальных сетях

Работа программы в локальных сетях

Вывод программы ping при работе в локальных сетях обычно выглядит следующим образом:
bsdi % ping svr4
PING svr4 (140.252.13.34): 56 data bytes
64 bytes from 140.252.13.34: icmp_seq=0 ttl=255 time=0 ms
64 bytes from 140.252.13.34: icmp_seq=1 ttl=255 time=0 ms
64 bytes from 140.252.13.34: icmp_seq=2 ttl=255 time=0 ms
64 bytes from 140.252.13.34: icmp_seq=3 ttl=255 time=0 ms
64 bytes from 140.252.13.34: icmp_seq=4 ttl=255 time=0 ms
64 bytes from 140.252.13.34: icmp_seq=5 ttl=255 time=0 ms
64 bytes from 140.252.13.34: icmp_seq=6 ttl=255 time=0 ms
64 bytes from 140.252.13.34: icmp_seq=7 ttl=255 time=0 ms
^? чтобы остановить ping, вводим символ прерывания
--- svr4 ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max = 0/0/0 ms

Когда принимается ICMP эхо отклик, печатается номер последовательности, затем параметр время жизни (TTL) и рассчитанное время возврата. (TTL это поле времени жизни в IP заголовке. В настоящее время программа ping в BSD печатает полученное TTL каждый раз, когда принимается эхо отклик - некоторые реализации этого не делают. Мы рассмотрим использование TTL в главе 8 с программой traceroute.)
Как видно из примера, приведенного выше, эхо отклики возвращаются в том же порядке, в котором были отправлены (0, 1, 2 и так далее).
ping может рассчитать время возврата, так как он сохраняет время, когда был отправлен эхо запрос, в разделе данных ICMP сообщения. Когда отклик возвращается, эти данные извлекаются и сравниваются с текущим временем. Обратите внимание на то, что посылающая система, bsdi, во всех случаях рассчитала время возврата равное 0 мс. Это объясняется тем, что программе доступен таймер с низким разрешением. Система BSD/386 может использовать только таймер с дискретом 10 мс. (Мы обсудим это более подробно в приложении В.) Позже, с использованием вывода команды tcpdump, мы увидим, что в системах с часами с более высоким разрешением (Sun) разница во времени между ICMP эхо запросом и эхо откликом составляет примерно 4 мс.
Первая строка вывода содержит IP адрес хоста назначения, даже если было указано имя (svr4). Это означает, что имя было преобразовано в IP адрес. Мы рассмотрим процедуру преобразования и DNS в главе 14. После запуска программы ping проходит несколько секунд, перед тем как появляется первая строка вывода с напечатанным IP адресом, это время необходимо DNS, чтобы определить IP адрес, соответствующий имени хоста.
На рисунке 7.2 показан вывод tcpdump для этого примера.
1 0.0 bsdi > svr4: icmp: echo request
2 0.003733 (0.0037) svr4 > bsdi: icmp: echo reply

3 0.998045 (0.9943) bsdi > svr4: icmp: echo request
4 1.001747 (0.0037) svr4 > bsdi: icmp: echo reply

5 1.997818 (0.9961) bsdi > svr4: icmp: echo request
6 2.001542 (0.0037) svr4 > bsdi: icmp: echo reply

7 2.997610 (0.9961) bsdi > svr4: icmp: echo request
8 3.001311 (0.0037) svr4 > bsdi: icmp: echo reply

9 3.997390 (0.9961) bsdi > svr4: icmp: echo request
10 4.001115 (0.0037) svr4 > bsdi: icmp: echo reply

11 4.997201 (0.9961) bsdi > svr4: icmp: echo request
12 5.000904 (0.0037) svr4 > bsdi: icmp: echo reply

13 5.996977 (0.9961) bsdi > svr4: icmp: echo request
14 6.000708 (0.0037) svr4 > bsdi: icmp: echo reply

15 6.996764 (0.9961) bsdi > svr4: icmp: echo request
16 7.000479 (0.0037) svr4 > bsdi: icmp: echo reply

SLIP каналы с дозвоном (Dialup)

SLIP каналы с дозвоном (Dialup)

При использовании SLIP каналов с дозвоном существуют некоторые отличия, так как на каждом конце канала присутствуют модемы. Модемы, которые используются между системами netb и sun, предоставляют то, что называется модуляцией V.32 (9600 бит/сек), контроль ошибок V.42 (также иногда называемый LAP-M) и сжатие данных V.42bis. Это означает, что наши простые вычисления, которые были достаточно точны для выделенного канала, где известны все параметры, в таких условиях практически неверны.
В данном случае играют роль несколько фактов. Модемы вносят некоторую задержку. Размер пакета может быть уменьшен благодаря сжатию данных, однако размер может быть и увеличен, так как используется протокол контроля ошибок. В дополнение, принимающий модем не может выдать полученные байты данных до тех пор, пока не будет проверена контрольная сумма. И в завершение, на каждом конце используется последовательный асинхронный интерфейс компьютера, а большинство операционных систем читают эти интерфейсы через определенный интервал времени или после того, как было получено определенное количество символов.
В следующем примере мы послали ping на хост gemini с хоста sun.
sun % ping gemini
PING gemini: 56 data bytes
64 bytes from gemini (140.252.1.11): icmp_seq=0. time=373. ms
64 bytes from gemini (140.252.1.11): icmp_seq=1. time=360. ms
64 bytes from gemini (140.252.1.11): icmp_seq=2. time=340. ms
64 bytes from gemini (140.252.1.11): icmp_seq=3. time=320. ms
64 bytes from gemini (140.252.1.11): icmp_seq=4. time=330. ms
64 bytes from gemini (140.252.1.11): icmp_seq=5. time=310. ms
64 bytes from gemini (140.252.1.11): icmp_seq=6. time=290. ms
64 bytes from gemini (140.252.1.11): icmp_seq=7. time=300. ms
64 bytes from gemini (140.252.1.11): icmp_seq=8. time=280. ms
64 bytes from gemini (140.252.1.11): icmp_seq=9. time=290. ms
64 bytes from gemini (140.252.1.11): icmp_seq=10. time=300. ms
64 bytes from gemini (140.252.1.11): icmp_seq=11. time=280. ms
----gemini PING Statistics----
12 packets transmitted, 12 packets received, 0% packet loss
round-trip (ms) min/avg/max = 280/314/373

Обратите внимание на то, что в первой строке RTT не кратен 10 миллисекундам, однако в остальных строках значение RTT кратно 10 миллисекундам. Если запустить этот пример несколько раз, то можно заметить, что подобное поведение сохранится. (Это вызвано точностью часов хоста sun - они предоставляют разрешение в одну миллисекунду. Это было проверено тестами, которые приведены в приложении В.)
Также обратите внимание на то, что первый RTT больше чем следующие, а остальные уменьшаются в процессе работы команды и их диапазон находится между 280 и 300 мс. Если не останавливать программу примерно минуту или две, RTT останутся в этом диапазоне, никогда не уменьшаясь меньше чем 260 мс. Если рассчитать ожидаемый RTT для скорости 9600 бит/сек (упражнение 2 главы 7), величина составит 180 миллисекунд, таким образом мы ошиблись в расчете примерно в 1,5 раза от реального значения.
Если программа ping будет работать в течение 60 секунд, то среднее RTT при использовании V.42 и V.42bis составит 277 миллисекунд. (Это лучше, чем значение, полученное в предыдущем примере, так как программа работала долше, при этом значение RTT застабилизировались в определенном диапазоне.) Если выключить сжатие данных V.42bis, то среднее значение составит 330 миллисекунд. Если выключить контроль ошибок V.42 (который также выключается при выключении сжатия данных V.42bis), среднее значение составит 300 миллисекунд. Эти параметры модемов влияют на RTT, однако все же лучше использовать контроль ошибкок и сжатие данных.

Выделенные SLIP каналы

Выделенные SLIP каналы

Давайте рассмотрим время возврата при работе по SLIP каналам, так как они обычно работают в асинхронном режиме с низкими скоростями, например 9600 бит/сек или меньше. Обратимся к расчету пропускной способности последовательной линии, приведенному в разделе "Вычисление загруженности последовательной линии" главы 2. Предположим, скорость SLIP канала между хостами bsdi и slip составляет 1200 бит/сек.
Оценить время возврата можно следующим образом. Во-первых, обратимся к примеру вывода Ping, показанному ранее. По умолчанию, ICMP сообщение содержит 56 байт данных. А также, 20 байт IP заголовка и 8 байт ICMP заголовка, что в сумме дает размер IP датаграммы - 84 байта. (Мы можем проверить это, запустив tcpdump -e, с помощью этой опции можно посмотреть размеры Ethernet фреймов.) Из раздела "SLIP: IP по последовательной линии" главы 2 мы знаем, что в начало и в конец датаграммы добавляется по меньшей мере два дополнительных байта, а именно - байт END. Не исключено, что при создании фреймов SLIP будут добавлены дополнительные байты, однако это зависит от величины каждого байта в датаграмме. Предположим, что скорость составляет 1200 бит/сек, в байте 8 бит, один старт-бит и один стоп-бит, при этом скорость будет 120 байт/сек или 8,33 мс на один байт. Время возврата составит (86 x 8,33 x 2) или 1433 мс. (Здесь умножается на 2 потому, что мы рассчитываем время возврата - то есть время, за которое пакет ушел и вернулся.)
Следующий вывод должен подтвердить правильность наших вычислений:
svr4 % ping -s slip
PING slip: 56 data bytes
64 bytes from (192.42.62.1): icmp_seq=0. time=1480. ms
64 bytes from (192.42.62.1): icmp_seq=1. time=1480. ms
64 bytes from (192.42.62.1): icmp_seq=2. time=1480. ms
64 bytes from (192.42.62.1): icmp_seq=3. time=1480. ms
^?
---- slip PING Statistics ----
5 packets transmitted, 4 packets received, 20% packet loss
round-trip (ms) min/avg/max = 1480/1480/1480

(Опция -s необходима для SVR4, чтобы посылать один запрос каждую секунду.) Время возврата составляет почти 1,5 секунды, однако программа все еще посылает ICMP эхо запросы с интервалом в 1 секунду. Это означает, что будет выдано два эхо запроса (в момент времени 0 и в момент времени 1), перед тем как вернется первый отклик (момент времени 1,480). Именно поэтому программа считает, что один пакет потерян. В действительности он не был потерян, скорее всего он еще просто не вернулся.
Мы снова обратимся к медленному SLIP каналу в главе 8, когда будем рассматривать работу программы traceroute.

Вывод ping при работе в локальной сети.

Рисунок 7.2 Вывод ping при работе в локальной сети.

Время между отправкой эхо запроса и приемом эхо отклика составляет 3,7 мс. Также мы видим, что эхо запросы посылаются с интервалом примерно в 1 секунду.
Часто бывает, что первое время возврата больше чем все остальные. Это происходит в том случае, если аппаратный адрес назначения отсутствует в ARP кэше отправителя. Как мы помним из главы 4, отправка ARP запроса и получение ARP отклика может занять несколько миллисекунд, только после этого отправляется первый эхо запрос. Это проиллюстрировано в следующем примере:
sun % arp -a убедимся, что ARP кэш пуст

sun % ping svr4
PING svr4: 56 data bytes
64 bytes from svr4 (140.252.13.34): icmp_seq=0. time=7. ms
64 bytes from svr4 (140.252.13.34): icmp_seq=1. time=4. ms
64 bytes from svr4 (140.252.13.34): icmp_seq=2. time=4. ms
64 bytes from svr4 (140.252.13.34): icmp_seq=3. time=4. ms
^? вводим символ прерывания
---- svr4 PING Statistics ----
4 packet transmitted, 4 packets received, 0% packets loss
round-trip (ms) min/avg/max = 4/4/7

Дополнительные 3 миллисекунды в первом RTT скорее всего потрачены на отправку ARP запроса и получение отклика.
Этот пример был запущен на хосте sun, который имеет таймер с разрешением в одну микросекунду, но не смотря на это, программа ping печатает время возврата только с разрешением в одну миллисекунду. В предыдущем примере, запущенном под BSD/386 Version 0.9.4, время возврата равно 0 миллисекунд, так как таймер имеет разрешение в 10 миллисекунд. Следующий вывод получен с использованием BSD/386 Version 1.0, где есть таймер с разрешением в одну микросекунду. Существует версия программы ping, которая имеет более высокое временное разрешение.
bsdi % ping svr4
PING svr4 (140.252.13.34): 56 data bytes
64 bytes from 140.252.13.34: icmp_seq=0 ttl=255 time=9.304 ms
64 bytes from 140.252.13.34: icmp_seq=1 ttl=255 time=6.089 ms
64 bytes from 140.252.13.34: icmp_seq=2 ttl=255 time=6.079 ms
64 bytes from 140.252.13.34: icmp_seq=3 ttl=255 time=6.096 ms
^? вводим символ прерывания
--- svr4 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 6.079/6.880/9.304 ms

Вывод программы tcpdump c записью опций маршрутизации.

Рисунок 7.5 Вывод программы tcpdump c записью опций маршрутизации.

Вывод optlen=40 указывает на то, что пространство опций в IP заголовке, используемое в данном случае, равно 40 байтам. (Обратите внимание, длина IP заголовка должна быть кратна 4 байтам.) RR {39} означает, что включена опция записи маршрута, а длина ее поля составляет 39. Затем приводится список из 9 IP адресов, знак (#) показывает на который из IP адресов указывает поле ptr в заголовке опции RR. Так как мы наблюдали за пакетами с хоста sun (см. рисунок 7.4), то видели только ICMP эхо запросы с пустым списком и ICMP эхо отклики, в списке которых содержится 3 адреса. Мы удалили оставшиеся строки в выводе tcpdump, так как они практически идентичны тем, которые показаны на рисунке 7.5.
Комбинация EOL в конце записи маршрута указывает на IP опцию "конец списка" (end of list). Опция EOL имеет значение 0. В поле опций IP заголовка, состоящего из 40 байт присутствует 39 байт данных RR. Так как пространство опций устанавливается в 0, перед тем как датаграмма отсылается, последний байт 0 следующий за 39-ю байтами данных RR интерпретируется как EOL. Если в поле опций IP заголовка присутствует несколько опций и появляется необходимость использовать байты заполнения перед началом следующей опции, используется специальный символ "нет операции" (NOP - no operation), значение которого равно единице.
На рисунке 7.5 SVR4 устанавливает в поле TTL в эхо запросе значение 32, а BSD/386 устанавливает значение 255. (Это значение печатается как 254, потому что маршрутизатор bsdi уже успел уменьшить это значение на единицу.) Все новые системы устанавливают TTL ICMP сообщений по максимуму (255).
Необходимо отметить, что две системы, BSD/386 и SVR4, из трех TCP/IP реализаций, описываемых в качестве примера в этой книге, поддерживают опцию записи маршрута. Таким образом, они корректно обновляют RR список при перенаправлении датаграммы. Также они корректно отражают RR список из входящих ICMP эхо запросов в исходящий ICMP эхо отклик. SunOS 4.1.3, однако, обновляет RR список, когда перенаправляет датаграмму, но не отображает RR список. Solaris 2.x исправляет эту проблему.

Значение флагов в опции временной марки.

Рисунок 7.8 Значение флагов в опции временной марки.

В случае если маршрутизатор не может добавить временную марку, из-за того что не хватает места, он увеличивает на единицу поле переполнения (overflow).
Обычное значение для временной марки это количество миллисекунд после полуночи, UTC, что напоминает запрос и отклик временной марки ICMP (глава 6, раздел "ICMP запрос и отклик временной марки"). Если маршрутизатор не поддерживает подобный стандарт, он может вставить то представление времени, которое он использует, однако затем он должен установить в единицу старшие биты временной марки, чтобы указать на нестандартный формат.
Заданные ограничения, которые мы рассматривали с опцией записи маршрута, с опцией временной марки становятся еще более жесткими. Если осуществляется запись и IP адресов и временных марок (флаги установлены в единицу), то можно сохранить только 4 подобные пары. Сохранение только временной марки практически бесполезно, потому что мы не имеем представления, какому маршрутизатору соответствует определенная временная марка (если только мы не имеет фиксированную топологию, которая никогда не изменяется). Если установить флаги в значение 3, то появится возможность выбрать, каким маршрутизаторам необходимо вставлять их временные марки. Более глобальная проблема заключается в том, что мы не можем контролировать то, насколько точно маршрутизаторы устанавливают временные марки. Поэтому довольно сложно оценить время пересылки между маршрутизаторами с использованием этой IP опции. Вскоре мы увидим, что программа traceroute (см. главу 8) предоставляет более совершенный способ оценки времени пересылки между маршрутизаторами.

TCP-IP крупным планом

Функционирование программы Traceroute

Функционирование программы Traceroute

В разделе "Опция записи IP маршрута" главы 7 мы описали IP опцию записи маршрута (RR). Возникает вопрос, зачем писать новое приложение, когда данная опция уже реализована? Существует три причины. Во-первых, исторически не все маршрутизаторы поддерживают опцию записи маршрута, из чего следует, что некоторые маршруты становятся неиспользуемыми. (Traceroute не требует каких-либо специальных характеристик на промежуточных маршрутизаторах.)
Во-вторых, запись маршрута обычно осуществляется в одном направлении. Отправитель включает опцию, а получатель должен вставить все значения из принятого IP заголовка и каким-либо образом вернуть их отправителю. В разделе "Опция записи IP маршрута" главы 7 мы видели, что большинство реализаций сервера Ping (функция ICMP эхо отклика, встроенная в ядро) отображают входящий RR список, однако при этом удваивается количество записанных IP адресов (путь туда и обратно), помимо этого существует еще несколько ограничений, которые будут рассмотрены в следующем параграфе. (Traceroute требует только того, чтобы на пункте назначения присутствовал работающий UDP модуль - никаких специальных серверных приложений не требуется.)
Третья и основная причина заключается в том, что размер, предоставляемый для опций в IP заголовке, недостаточен для того, чтобы обработать большинство маршрутов. В поле опций IP заголовка входит всего 9 IP адресов. Если во времена ARPANET этого хватало, на сегодняшний день этого слишком мало.
Traceroute использует ICMP и поле TTL в IP заголовке. Поле TTL (время жизни) это 8-битное поле, которое отправитель устанавливает в какое-либо значение. Рекомендуемое исходное значение указано в Assigned Numbers RFC и в настоящее время равно 64. Более старые системы устанавливают это значение в 15 или 32. Мы видели в некоторых примерах работы программы Ping (глава 7), что ICMP эхо отклики часто отправляются с TTL, установленным в максимальное значение - 255.
Каждый маршрутизатор, который обрабатывает датаграмму, уменьшает значение TTL на единицу или на количество секунд, в течение которых маршрутизатор обрабатывал датаграмму. Так как большинство маршрутизаторов задерживает датаграмму меньше чем секунду, поле TTL, как правило, уменьшается на единицу и довольно точно соответствует количеству пересылок.
RFC 1009 [Braden and Postel 1987] требует, чтобы маршрутизатор, задерживающий датаграмму на время большее чем 1 секунда, уменьшал TTL на количество секунд. Совсем немногие маршрутизаторы удовлетворяют этому требованию. Современные требования к маршрутизаторам, Router Requirements RFC [Almquist 1993], делают это требование необязательным, позволяя маршрутизаторам использовать поле TTL в качестве счетчика пересылок.
С помощью поля TTL предотвращается зацикливание датаграммы в петлях маршрутизации. Например, если маршрутизатор вышел из строя или соединение между двумя маршрутизаторами потеряно, может потребоваться некоторое время (от нескольких секунд до нескольких минут), для того чтобы определить, что маршрут потерян и что его необходимо обойти. В это время существует вероятность, что датаграмма будет уничтожена в петле маршрутизации. Чтобы предотвратить потерю датаграммы, поле TTL устанавливается в максимальную величину.
Когда маршрутизатор получает IP датаграмму с TTL равным либо 0, либо 1, он не должен отправлять эту датаграмму дальше. (Хост приемник должен доставить подобную датаграмму в приложение, так как датаграмма не может быть смаршрутизировна. Как правило, системы не должны получать датаграммы с TTL равным 0.) Если такую датаграмму получает маршрутизатор, он уничтожает ее и посылает хосту, который ее отправил ICMP сообщение "время истекло" (time exceeded). Принцип работы Traceroute заключается в том, что IP датаграмма, содержащая это ICMP сообщение, имеет в качестве адреса источника IP адрес маршрутизатора.
Теперь мы можем понять, как работает Traceroute. На хост назначения отправляется IP датаграмма с TTL, установленным в единицу. Первый маршрутизатор, который должен обработать датаграмму, уничтожает ее (так как TTL равно 1) и отправляет ICMP сообщение об истечении времени (time exceeded). Таким образом, определяется первый маршрутизатор в маршруте. Затем Traceroute отправляет датаграмму с TTL равным 2, что позволяет получить IP адрес второго маршрутизатора. Это продолжается до тех пор, пока датаграмма не достигнет хоста назначения. Однако, если датаграмма прибыла именно на хост назначения, он не уничтожит ее и не сгенерирует ICMP сообщение об истечении времени, так как датаграмма достигла своего конечного назначения. Как можно определить, что датаграмма достигла конечного пункта назначения?
В UDP датаграммах, которые посылает Traceroute, устанавливается несуществующий номер UDP порта (больше чем 30000), что делает невозможным обработку этой датаграммы каким-либо приложением. Поэтому когда прибывает подобная датаграмма, UDP модуль хоста назначения генерирует ICMP сообщение "порт недоступен" (port unreachable) (см. раздел "ICMP ошибка недоступности порта" главы 6). Все что необходимо в этом случае, Traceroute это определить тип принятого ICMP сообщения - либо об истечении времени, либо о недоступности порта - именно таким образом мы узнаем, доставлена ли датаграмма в пункт назначения.
Программа Traceroute должна уметь устанавливать поле TTL в исходящих датаграммах. Не все интерфейсы TCP/IP поддерживают это, и не все реализации предоставляют эту возможность, однако большинство современных систем предоставляют. А это означает, что Traceroute может быть запущена. Однако обычно требуется, чтобы эту программу запускал суперпользователь.

ICMP сообщение об истечении времени

Рисунок 8.2 ICMP сообщение об истечении времени ("time exceeded").


В сообщении, которое генерируется, когда TTL достигает нуля, поле code равно нулю.
Существует возможность, что хост пошлет ICMP сообщение "время истекло в течении повторной сборки" (time exceeded during reassembly) в том случае, если время истекло в течении повторной сборки фрагментированной датаграммы. (Мы подробно рассмотрим фрагментацию и повторную сборку в разделе "Фрагментация IP" главы 11.) В этом случае поле code устанавливается в единицу.
Строки с 9-ой по 14-ую на рисунке 8.1 соответствуют трем датаграммам, которые посылаются с TTL равным 2. Они достигают конечного пункта назначения, при этом генерируется ICMP сообщение о недоступности порта.
Попробуем рассчитать время возврата, которое соответствует SLIP каналу, как это было сделано в разделе "Программа Ping" главы 7, когда при работе программы Ping была установлена скорость канала - 1200 бит/сек. Исходящая UDP датаграмма содержит 12 байт данных, 8 байт UDP заголовка, 20 байт IP заголовка и 2 байта (минимум) для создания SLIP фреймов (см. раздел "SLIP: IP по последовательной линии" главы 2), что в целом составляет 42 байта. В отличие от Ping, размер возвращающихся датаграмм изменяется. На рисунке 6.9, мы видели, что возвращаемое ICMP сообщение содержит IP заголовок датаграммы, которая вызвала ошибку и первые 8 байт данных, которые следуют за IP заголовком (содержащие UDP заголовок, в данном случае traceroute). При этом мы получаем 20+8+20+8+2 или 58 байт. При скорости передачи в 960 байт/сек, ожидаемое RTT составляет (42+58/960) или 104 миллисекунды. Это сопоставимо со значением, рассчитанным для svr4 и равным 110 миллисекундам.
Номер порта источника на рисунке 8.1 достаточно большой (42804). traceroute устанавливает номер порта источника IP датаграмм, которые она посылает в логическое ИЛИ (logical OR), со своим идентификатором процесса (32768). В этом случае, если traceroute запущена несколько раз на одном и том же хосте, каждый процесс просматривает номер порта источника в UDP заголовке, который возвращается в ICMP сообщении, и обрабатывает только те сообщения, которые были отправлены в качестве отклика на его запрос.
Необходимо отметить некоторые особенности traceroute. Во-первых, не существует гарантии, что маршрут, который используется сегодня, будет использоваться и завтра, даже если две последовательные датаграммы были отправлены к одному и тому же пункту назначения. Если маршрут изменится в процессе работы программы, Вы увидите это, потому что traceroute напечатает новые IP адреса для определенных TTL.
Во-вторых, не существует гарантии того, что путь, по которому вернется ICMP сообщение, совпадет с путем, по которому traceroute отправила UDP датаграмму. Это означает, что время возврата, которое печатает программа, может не совпадать со временем, потребовавшимся на передачу исходящей датаграммы и возвращенного сообщения. (Возможен вариант, что UDP датаграмма дойдет от источника до маршрутизатора за 1 секунду, однако ICMP сообщение проделает обратный путь за 3 секунды, при этом время возврата будет напечатано как 4 секунды.)
В-третьих, IP адрес, который возвращается в сообщение ICMP, это IP адрес интерфейса, на который маршрутизатор принял UDP датаграмму. Тогда как при использовании опции записи маршрута (см. раздел "Опция записи IP маршрута" главы 7) записывается IP адрес исходящего интерфейса. Так как каждый маршрутизатор по умолчанию имеет 2 или более интерфейсов, запуск traceroute от хоста А к хосту В может отличаться от того, который запущен с хоста В на хост А. Действительно, если мы запустим traceroute от хоста slip к svr4, вывод будет следующим:
slip % traceroute svr4
traceroute to svr4 (140.252.13.34), 30 hops max, 40 byte packets
1 bsdi (140.252.13.66) 110 ms 110 ms 110 ms
2 slip (140.252.13.34) 110 ms 120 ms 110 ms

В этом случае IP адрес, напечатанный для хоста bsdi, это адрес SLIP интерфейса (140.252.13.66), тогда как до этого адрес был 140.252.13.35, что соответствовало интерфейсу Ethernet. Так как traceroute пытается определить имя, связанное с IP адресом, имена будут различны. (В нашем примере оба интерфейса bsdi имеют одно и то же имя.)
Обратимся к рисунку 8.3. На нем показаны две локальные сети, соединенные через маршрутизаторы. Два маршрутизатора соединены по каналу точка-точка. Если мы запустим traceroute с хоста в левой локальной сети на хост в правой локальной сети, IP адреса для маршрутизатора будут if1 и if3. При использовании другого пути, будут получены адреса if4 и if2. Два интерфейса if2 и if3 имеют один и тот же идентификатор сети, тогда как два других интерфейса имеют разные идентификаторы сетей.

Идентификация интерфейсов программой traceroute.

Рисунок 8.3 Идентификация интерфейсов программой traceroute.


И в заключение отметим, что при работе с глобальными сетями вывод traceroute значительно легче читать, если вместо IP адресов печатаются читаемые имена доменов. Однако, так как в ICMP сообщении, принимаемом при работе traceroute, содержится IP адрес, он и будет выдан, если преобразовать IP адрес в имя домена не удалось. В этом случае администратор должен позаботиться о том, чтобы принятый IP адрес мог быть корректно трансформирован в имя домена. Мы опишем, как IP адреса конвертируются в имена с использованием DNS, в разделе "Запросы указателя" главы 14.

Общий формат опции маршрутизации

Рисунок 8.6 Общий формат опции маршрутизации от источника в IP заголовке.


Формат практически идентичен формату опции записи маршрута, которую мы рассмотрели на рисунке 7.3. Однако, в случае маршрутизации от источника мы должны заполнить список IP адресов, перед тем как будет отправлена IP датаграмма, тогда как в опции записи маршрута мы выделяли пространство и устанавливали в 0 список IP адресов, позволяя маршрутизаторам заполнить их в процессе передачи датаграммы. В случае с маршрутизацией от источника мы выделяем область для заполнения и инициализируем определенное количество требуемых IP адресов, обычно их количество меньше чем 9. В случае опции записи маршрута мы старались выделить как можно больше места, для того чтобы использовать более чем 9 адресов.
Поле code устанавливается в 0x83 для свободной маршрутизации от источника, и в 0x89 для жесткой маршрутизации от источника. Поля len и ptr идентичны тем, что мы описали в разделе "Опция записи IP маршрута" главы 7.
Опции маршрутизации от источника обычно называются "маршрутизацией от источника с записью" (source and record route) (LSRR - свободная и SSRR - жесткая), так как список IP адресов обновляется в процессе того, как датаграмма проходит по маршруту. Происходит следующее:

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

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

Если маршрутизатор является пунктом назначения и указатель не больше чем длина, в этом случае (1) следующий адрес в списке (куда указывает ptr) становится адресом назначения датаграммы, (2) IP адрес, соответствующий исходящему интерфейсу, замещает собой только что использованный адрес источника, и (3) указатель увеличивается на 4.

Все это лучше показать на примере. На рисунке 8.7 мы предположили, что посылающее приложение на хосте S отправляет датаграмму к D, указав маршрут от источника как R1, R2 и R3.

Опция IP маршрутизации от источника

Опция IP маршрутизации от источника

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

Жесткая (strict) маршрутизация от источника. Отправитель указывает точный путь, по которому должна пройти IP датаграмма. Если маршрутизатор обнаруживает, что следующая пересылка, указанная в маршрутизации от источника, не является непосредственно подключенной сетью, возвращается ICMP ошибка "маршрутизация от источника невозможна" (source route failed).

Свободная (loose) маршрутизация от источника. Отправитель указывает список IP адресов, через который должна пройти IP датаграмма, однако датаграмма может также пройти через другие маршрутизаторы между любыми двумя адресами, указанными в списке.

Traceroute позволяет использовать маршрутизацию от источника.
Некоторые свободно распространяемые исходные тексты программы Traceroute содержат дополнения, которые позволяют установить свободную маршрутизацию от источника. Однако стандартные версии обычно не включают эту опцию. Комментарии к дополнениям гласят: "исходные тексты программы Traceroute, написанные Van Jacobson (весна 1988 года), поддерживали эту характеристику, однако она была удалена по требованию людей, которые вывели из строя свои шлюзы". Для того чтобы показать пример, приведенный в этом разделе, автор установил эти дополнения и модифицировал их таким образом, чтобы можно было использовать оба типа маршрутизации от источника.
На рисунке 8.6 показан формат опции маршрутизации от источника.

Пример IP маршрутизации от источника.

Рисунок 8.7 Пример IP маршрутизации от источника.


На этом рисунке символ (#) означает поле указателя, которое может принимать значение 4, 8, 12 и 16. Поле длины всегда будет 15 (3 IP адреса + 3 байта). Обратите внимание на то, как меняется IP адрес назначения в IP датаграмме при каждой пересылке.
Когда приложение получает данные, которые маршрутизировались от источника, оно должно выделить значение принятого маршрута и использовать обратный маршрут для отправки отклика.
Требования к хостам Host Requirements RFC указывает, что TCP клиент должен иметь возможность указать маршрутизацию от источника, и что TCP сервер должен иметь возможность принять маршрутизацию от источника, а также использовать обратный маршрут для всех сегментов TCP соединения. Если TCP сервер позже принял другой маршрут от источника, более новый маршрут перезаписывает собой ранний маршрут.

Пример traceroute, показывающий несимметричные маршруты.

Рисунок 8.11 Пример traceroute, показывающий несимметричные маршруты.

Исходящий маршрут (TTL 1-11) отличается от обратного маршрута (TTL 11-21), это является хорошей иллюстрацией того, что маршрутизация в Internet может быть несимметричной.
Этот вывод также иллюстрирует проблему, которую мы обнаружили при рассмотрении рисунка 8.3. Сравните вывод для TTL 2 и 19: оба относятся к маршрутизатору gateway.tuc.noao.edu, однако IP адреса различны. Так как traceroute идентифицирует входящий интерфейс, это означает, что мы прошли через маршрутизатор с разных сторон, в тот момент, когда использовали исходящий маршрут (TTL 2) и когда использовали обратный маршрут (TTL 19). Точно так же можно сравнить TTL 3 и 18, TTL 4 и 17.

Примеры traceroute при использовании

Примеры traceroute при использовании жесткой маршрутизации от источника

Опция -G в нашей версии traceroute идентична опции -g, описанной ранее, однако она определяет жесткую маршрутизацию от источника вместо свободной. Посмотрим что произойдет, если указан неверный жесткий маршрут от источника. Обратимся к рисунку 8.5, на котором показана нормальная последовательность маршрутизаторов для датаграмм, двигающихся из нашей подсети к NSFNET через netb, gateway, butch и gabby. (Мы отбросили суффиксы доменов, .tuc.noao.edu и .telcom.arizona.edu, во всех строках вывода, показанных ниже, чтобы сделать их более читаемыми.) Мы указали жесткий маршрут от источника, который не использует butch, а пытается пройти непосредственно от gateway к gabby. Это не должно сработать, что показано на рисунке 8.9.
sun % traceroute -G netb -G gateway -G gabby westgate
traceroute to westgate (192.80.43.2), 30 hops max, 40 byte packets
1 netb (140.252.1.183) 272 ms 257 ms 261 ms
2 gateway (140.252.1.4) 263 ms 259 ms 234 ms
3 gateway (140.252.1.4) 263 ms !S * 235 ms !S

Примеры traceroute с использованием

Примеры traceroute с использованием свободной маршрутизации от источника

Опция -g программы traceroute позволяет нам указать промежуточные маршрутизаторы, которые должны быть использованы при свободной маршрутизации от источника. Эта опция может быть указана до 8 раз. (Причина того, что указывается именно 8, а не 9 раз, заключается в том, что программный интерфейс, который будет использоваться, потребует, чтобы последний пункт являлся конечным пунктом назначения.)
Повторно обратимся к рисунку 8.4, из которого видно, что маршрутизация к NIC, nic.ddn.mil, была осуществлена через сеть NASA. На рисунке 8.8 мы заставим датаграммы пройти через NSFNET, вместо того чтобы использовать маршрутизатор enss142.UT.westnet.net (192.31.39.21) в качестве промежуточного маршрутизатора:
sun % traceroute -g 192.31.39.21 nic.ddn.mil
traceroute to nic.ddn.mil (192.112.36.5), 30 hops max, 40 byte packets
1 netb.tuc.noao.edu (140.252.1.183) 256 ms 256 ms 235 ms

2 butch.telcom.arizona.edu (140.252.104.2) 234 ms 228 ms 234 ms
3 Gabby.Telcom.Arizona.EDU (128.196.128.1) 234 ms 257 ms 233 ms

4 enss142.UT.westnet.net (192.31.39.21) 294 ms 288 ms 295 ms

5 t3-2.Denver-cnss97.t3.ans.net (140.222.97.3) 294 ms 286 ms 293 ms
6 t3-3.Denver-cnss96.t3.ans.net (140.222.96.4) 293 ms 288 ms 294 ms
7 t3-1.St-Louis-cnss80.t3.ans.net (140.222.80.2) 294 ms 318 ms 294 ms
8 * t3-1.Chicago-cnss24.t3.ans.net (140.222.24.2) 318 ms 295 ms
9 t3-2.Cleveland-cnss40.t3.ans.net (140.222.40.3) 319 ms 318 ms 324 ms
10 t3-1.New-York-cnss32.t3.ans.net (140.222.32.2) 324 ms 318 ms 324 ms
11 t3-1.Washington-DC-cnss56.t3.ans.net (140.222.56.2) 353 ms 348 ms 325 ms
12 t3-0.Washington-DC-cnss58.t3.ans.net (140.222.58.1) 348 ms 347 ms 325 ms
13 t3-0.enss145.t3.ans.net (140.222.145.1) 353 ms 348 ms 325 ms

14 nsn-FIX-pe.sura.net (192.80.214.253) 353 ms 348 ms 325 ms
15 GSI.NSN.NASA.GOV (128.161.252.2) 353 ms 348 ms 354 ms
16 NIC.DDN.MIL (192.112.36.5) 354 ms 347 ms 354 ms

Работа в локальной сети

Работа в локальной сети

А сейчас запустим traceroute. Мы будем использовать сети, показанные на рисунке, приведенном на внутренней стороне обложки, и пройдем по маршруту от svr4 к slip через маршрутизатор bsdi. Выделенный SLIP канал между bsdi и slip имеет скорость 9000 бит/сек.
svr4 % traceroute slip
traceroute to slip (140.252.13.65), 30 hops max, 40 byte packets
1 bsdi (140.252.13.35) 20 ms 10 ms 10 ms
2 slip (140.252.13.65) 120 ms 120 ms 120 ms

Первая строка, без номера содержит имя и IP адрес пункта назначения и указывает на то, что величина TTL не может быть больше 30. Размер датаграммы установлен в 40 байт, из которых 20 байт отводится на IP заголовок, 8 байт на UDP заголовок и 12 байт на пользовательские данные. (В 12 байтах пользовательских данных содержится номер последовательности, который увеличивается на единицу при отправке каждой следующей датаграммы, копия исходящего TTL и время, когда датаграмма была отправлена.)
Следующие две строки вывода начинаются с TTL, после чего следует имя хоста или маршрутизатора и их IP адреса. Для каждого значения TTL отправляется 3 датаграммы. Для каждого возвращенного ICMP сообщения рассчитывается и печатается время возврата (round-trip). Если ответ не получен в течении пяти секунд на любую из трех датаграмм, печатается звездочка, после чего отправляется следующая датаграмма. В нашем примере первые три датаграммы имели TTL, установленный в единицу, а ICMP сообщения вернулись через 20, 10 и 10 миллисекунд. Следующие три датаграммы были отправлены с TTL равным 2, а ICMP сообщения вернулись с задержкой 120 миллисекунд. Так как TTL со значением 2 достигло конечного пункта назначения, программа прекратила свою работу.
Времена возврата (round-trip) рассчитывается программой traceroute на хосте отправителе. Они представляют из себя полные времена возврата от программы traceroute к маршрутизатору. Если необходимо расчитать время, затраченное на каждую пересылку, мы должны вычесть значение, полученное как TTL N, из значения, полученного как TTL N+1.
На рисунке 8.1 показан вывод tcpdump для данного исполнения программы traceroute. То что первый пробный пакет к bsdi имел RTT равное 20 миллисекундам, а следующие два имели RTT равное 10 миллисекундам объясняется тем, что был осуществлен ARP обмен.
Значение, которое выбирается как номер UDP порта назначения, начинается с величины 33435 и увеличивается на единицу каждый раз, когда отправляется следующая датаграмма. Номер порта может быть изменен с использованием опции командной строки. UDP датаграмма содержит 12 байт пользовательских данных, как упоминалось ранее, в том случае, если в выводе traceroute мы видим, что отправляются датаграммы размером в 40 байт.
Когда IP датаграмма имеет TTL равное единице, tcpdump печатает комментарий [ttl 1]. Подобное сообщение печатается, когда TTL равно 0 или 1, чтобы предупредить нас о том, что в датаграмме что-то не в порядке. В данном случае мы ожидаем увидеть TTL равное 1, однако некоторые другие приложения получат предупреждение о том, что датаграмма скорее всего не достигла своего конечного пункта назначения. Скорее всего мы никогда не увидим датаграммы с TTL равным 0, если только маршрутизатор, который отправил ее в кабель, не вышел из строя.
1 0.0 arp who-has bsdi tell svr4
2 0.000586 (0.0006) arp reply bsdi is-at 0:0:c0:6f:2d:40

3 0.003067 (0.0025) svr4.42804>slip.33435: udp 12 [ttl 1]
4 0.004325 (0.0013) bsdi>svr4: icmp: time exceeded in-transit

5 0.069810 (0.0655) svr4.42804>slip.33436: udp 12 [ttl 1]
6 0.071149 (0.0013) bsdi>svr4: icmp: time exceeded in-transit

7 0.085162 (0.0140) svr4.42804>slip.33437: udp 12 [ttl 1]
8 0.086375 (0.0012) bsdi>svr4: icmp: time exceeded in-transit

9 0.118608 (0.0322) svr4.42804>slip.33438: udp 12
10 0.226464 (0.1079) slip>svr4: icmp: slip udp port 33438 unreachable

11 0.287296 (0.0608) svr4.42804>slip.33439: udp 12
12 0.395230 (0.1079) slip>svr4: icmp: slip udp port 33439 unreachable

13 0.409504 (0.0143) svr4.42804>slip.33440: udp 12
14 0.517430 (0.1079) slip>svr4: icmp: slip udp port 33440 unreachable

Traceroute на nic.ddn.mil со свободной

Рисунок 8.8 traceroute на nic.ddn.mil со свободной маршрутизацией от источника через NSFNET.

Создается впечатление, что было сделано 16 пересылок со средним RTT около 350 миллисекунд, тогда как обычный маршрут, показанный на рисунке 8.4, состоял только из 13 пересылок, и среднее RTT равнялось примерно 322 миллисекундам. Из этого можно сделать вывод, что маршрут по умолчанию предпочтительнее. (Существуют и другие ограничения, в соответствии с которыми принимаются решения о прокладке маршрута; в том числе организационные или политические.)
Мы сказали "создается впечатление, что было сделано 16 пересылок", так как имели возможность сравнить этот вывод с нашим предыдущим примером через NFSNET (см. рисунок 8.5), который показал 3 отсутствующих маршрута в примере, который использует свободную маршрутизацию от источника. (Это, возможно, было вызвано ошибками в работе маршрутизаторов при генерации ICMP сообщения об истечении времени при получении датаграмм, маршрутизируемых от источника.) Маршрутизатор gateway.tuc.noao.edu отсутствует между netb и butch, а маршрутизаторы Westgate.Telcom.Arizona.edu и uu-ua.AZ.westnet.net отсутствуют между Gabby и enss142.UT.westnet.net. Вполне возможно, что мы не видим эти маршрутизаторы так как они не могут корректно обработать входящие датаграммы со свободной маршрутизации от источника. В действительности, при использовании NSFNET осуществляется 19 пересылок между источником и NIC. В упражнении 5 главы 8 будет продолжено рассмотрение отсутствующих маршрутизаторов.
Из этого примера видна еще одна проблема. В командной строке мы должны указать IP адрес маршрутизатора enss142.UT.westnet.net вместо его имени. Это происходит потому, что процедура определяющая соответствие между именем и адресом (возвращается имя по заданному IP адресу, раздел "Запросы указателя", главы 14), или наоборот, когда задается имя, а возвращается IP адрес, не работает. Функции определения адреса по имени и имени по адресу используют два различных файла в системе DNS (Domain Name System), и не все администраторы синхронизируют эти два файла друг с другом. Нет ничего необычного в том, что в одном направлении DNS работает, но не работает в другом.
Вместо первого RTT для TTL равного 8 мы видим в выводе звездочку (*). Это указывает на то, что был отработан тайм-аут и на первую посылку в течении пяти секунд не был получен отклик.
И последнее, на что необходимо обратить внимание, сравнивая этот рисунок с рисунком 8.4, заключается в том, что маршрутизатор nsn-FIX-pe.sura.net подключен как к NSFNET, так и к сети NASA.

Traceroute от хоста sun.tuc.noao.edu к хосту aw.com.

Рисунок 8.5 traceroute от хоста sun.tuc.noao.edu к хосту aw.com.

После того как датаграмма вышла из сети telcom.arizona.edu она попадает в региональную сеть western.net (TTL 6 и 7). Затем датаграмма попадает на магистраль (backbone) NSFNET, t3.ans.net, которая используется Advanced Network & Services. (T3 это общепринятая аббревиатура для каналов 45 Мбит/сек, которые используются в качестве магистралей.) И последняя сеть это alter.net, точка подсоединения к Internet для aw.com.

Traceroute от sun к nic.ddn.mil.

Рисунок 8.4 traceroute от sun к nic.ddn.mil.

Чтобы включить этот пример в текст, мы запустили его для не-DDN узлов (не военные узлы) от nic.ddn.mil к rs.internic.net, новый "InterNIC".
Когда датаграмма выходит из сети tuc.noao.edu, она попадает в сеть telcom.arizona.edu. Затем она попадает в сеть Национального агентства по аэронавтике США (NASA Science Internet), nsn.nasa.gov. Маршрутизаторы с TTL равным 6 и 7 находятся в лаборатории Jet Propulsion (JPL). Сеть sura.net (в выводе TTL равно 11) это сеть Исследовательской ассоциации университетов (Southeastern Universities Research Association Network). GSI (TTL равно 12) это Government Systems, Inc., оператор для NIC.
Второе RTT для TTL равного 6 (590) почти в два раза больше, чем два другие RTT (234 и 262). Это показывает динамику IP маршрутизации. Подобное может произойти где-нибудь по пути от источника к маршрутизатору если какой-нибудь промежуточный маршрутизатор задержал датаграмму. Однако мы не можем сказать, была ли задержена исходящая датаграмма или возвращающееся ICMP сообщение.
RTT для первой попытки с TTL равным 3 (204) меньше, чем RTT для первой попытки с TTL равной 2 (233). Так как каждое полученное RTT является полным временем прохода от посылающего хоста к маршрутизатору, это вполне объснимо.
В примере на рисунке 8.5 показана работа программы Traceroute от хоста sun на хост нашего издателя.
sun % traceroute aw.com
traceroute to aw.com (192.207.117.2), 30 hops max, 40 byte packets
1 netb.tuc.noao.edu (140.252.1.183) 227 ms 227 ms 234 ms
2 gateway.tuc.noao.edu (140.252.1.4) 233 ms 229 ms 234 ms

3 butch.telcom.arizona.edu (140.252.104.2) 233 ms 229 ms 234 ms
4 Gabby.Telcom.Arizona.EDU (128.196.128.1) 264 ms 228 ms 234 ms
5 Westgate.Telcom.Arizona.EDU (192.80.43.2) 234 ms 228 ms 234 ms

6 uu-ua.AZ.westnet.net (192.31.39.233) 263 ms 258 ms 264 ms
7 enss142.UT.westnet.net (192.31.39.21) 263 ms 258 ms 264 ms

8 t3-2.Denver-cnss97.t3.ans.net (140.222.97.3) 293 ms 288 ms 275 ms
9 t3-3.Denver-cnss96.t3.ans.net (140.222.96.4) 283 ms 263 ms 261 ms
10 t3-1.St-Louis-cnss80.t3.ans.net (140.222.80.2) 282 ms 288 ms 294 ms
11 t3-1.Chicago-cnss24.t3.ans.net (140.222.24.2) 293 ms 288 ms 294 ms
12 t3-2.Cleveland-cnss40.t3.ans.net (140.222.40.3) 294 ms 288 ms 294 ms
13 t3-1.New-York-cnss32.t3.ans.net (140.222.32.2) 323 ms 318 ms 324 ms
14 t3-1.Washington-DC-cnss56.t3.ans.net (140.222.56.2) 323 ms 318 ms 324 ms
15 t3-0.Washington-DC-cnss58.t3.ans.net (140.222.58.1) 324 ms 318 ms 324 ms
16 t3-0.enss136.t3.ans.net (140.222.136.1) 323 ms 318 ms 324 ms

17 Washington.DC.ALTER.NET (192.41.177.248) 323 ms 377 ms 324 ms
18 Boston.MA.ALTER.NET (137.39.12.2) 324 ms 347 ms 324 ms
19 AW-gw.ALTER.NET (137.39.62.2) 353 ms 378 ms 354 ms

20 aw.com (192.207.117.2) 354 ms 349 ms 354 ms

Traceroute с жесткой маршрутизацией

Рисунок 8.9 traceroute с жесткой маршрутизацией от источника, который не работает.

Здесь необходимо обратить внимание на выражение !S, следующее за RTT для TTL равного 3. Это означает, что программа traceroute получила ICMP сообщение "маршрутизация от источника не сработала" (source route failed): type равняется 3 и code равняется 5 на рисунке 6.3. Звездочка во втором RTT для TTL равного 3 указывает на то, что на эту посылку не был получен ответ. Это как раз то что мы ожидали, так как для gateway не существует возможности послать датаграмму непосредственно к gabby.
Причина того, что датаграммы с TTL 2 и 3 пришли именно от gateway, заключается в том, что TTL с номером 2 отправлялась из gateway, когда он получил входящую датаграмму с TTL равным 1. Он определяет, что время жизни (TTL) истекло перед тем, как был обнаружен жесткий маршрут от источника (кстати, неправильный), поэтому и было отправлено ICMP сообщение об истечении времени. Строка с TTL равным 3 получена gateway с входящим TTL равным 2, он просмотрел жесткий маршрут от источника, определил, что он неверен, после чего послал ICMP сообщение о том, что маршрутизация от источника не может быть осуществлена.
На рисунке 8.10 показан вывод tcpdump, соответствующий этому примеру. Этот вывод получен на SLIP канале между sun и netb. Мы указали опцию -v для tcpdump, чтобы получить информацию о маршрутизации от источника. При этом появляется часть вывода, который нам не нужен, как, например, идентификатор датаграммы. Этот вывод был удален. Сокращение SSRR означает "жесткая маршрутизация от источника с записью" (strict source and record route).
1 0.0 sun.33593 > netb.33435: udp 12 [ttl 1]
(optlen=16 SSRR{#gateway gabby westgate} EOL)
2 0.270278 (0.2703) netb > sun: icmp: time exceeded in-transit
3 0.284784 (0.0145) sun.33593 > netb.33436: udp 12 [ttl 1]
(optlen=16 SSRR{#gateway gabby westgate} EOL)
4 0.540338 (0.2556) netb > sun: icmp: time exceeded in-transit
5 0.550062 (0.0097) sun.33593 > netb.33437: udp 12 [ttl 1]
(optlen=16 SSRR{#gateway gabby westgate} EOL)
6 0.810310 (0.2602) netb > sun: icmp: time exceeded in-transit
7 0.818030 (0.0077) sun.33593 > netb.33438: udp 12 (ttl 2,
optlen=16 SSRR{#gateway gabby westgate} EOL)
8 1.080337 (0.2623) gateway > sun: icmp: time exceeded in-transit
9 1.092564 (0.0122) sun.33593 > netb.33439: udp 12 (ttl 2,
optlen=16 SSRR{#gateway gabby westgate} EOL)
10 1.350322 (0.2578) gateway > sun: icmp: time exceeded in-transit
11 1.357382 (0.0071) sun.33593 > netb.33440: udp 12 (ttl 2,
optlen=16 SSRR{#gateway gabby westgate} EOL)
12 1.590586 (0.2332) gateway > sun: icmp: time exceeded in-transit
13 1.598926 (0.0083) sun.33593 > netb.33441: udp 12 (ttl 3,
optlen=16 SSRR{#gateway gabby westgate} EOL)
14 1.860341 (0.2614) gateway > sun:
icmp: gateway unreachable - source route failed
15 1.875230 (0.0149) sun.33593 > netb.33442: udp 12 (ttl 3,
optlen=16 SSRR{#gateway gabby westgate} EOL)
16 6.876579 (5.0013) sun.33593 > netb.33443: udp 12 (ttl 3,
optlen=16 SSRR{#gateway gabby westgate} EOL)
17 7.110518 (0.2339) gateway > sun:
icmp: gateway unreachable - source route failed

Время возврата traceroute при

Время возврата traceroute при использовании свободной маршрутизации от источника

Раньше мы уже упоминали о том, что не существует гарантии того, что маршрут от А до В тот же самый, как и маршрут от В до А. Найти различие между этими двумя маршрутами можно только зайдя терминалами на обе системы и запустив traceroute на каждой из них. Однако, используя свободную маршрутизацию от источника, мы можем определить маршрут в обоих направлениях.
Добиться этого можно, если указать свободную маршрутизацию от источника с назначением по свободному маршруту и указать посылающий хост в качестве конечного пункта назначения. Например, с хоста sun мы можем найти маршрут к и от хоста bruno.cs.colorado.edu (см. рисунок 8.11).
sun % traceroute -g bruno.cs.colorado.edu sun
traceroute to sun (140.252.13.33), 30 hops max, 40 byte packets
1 netb.tuc.noao.edu (140.252.1.183) 230 ms 227 ms 233 ms
2 gateway.tuc.noao.edu (140.252.1.4) 233 ms 229 ms 234 ms

3 butch.telcom.arizona.edu (140.252.104.2) 234 ms 229 ms 234 ms
4 Gabby.Telcom.Arizona.EDU (128.196.128.1) 233 ms 231 ms 234 ms
5 NSIgate.Telcom.Arizona.EDU (192.80.43.3) 294 ms 258 ms 234 ms

6 JPL1.NSN.NASA.GOV (128.161.88.2) 264 ms 258 ms 264 ms
7 JPL2.NSN.NASA.GOV (192.100.15.2) 264 ms 258 ms 264 ms
8 NCAR.NSN.NASA.GOV (128.161.97.2) 324 ms * 295 ms

9 cu-gw.ucar.edu (192.43.244.4) 294 ms 318 ms 294 ms

10 engr-gw.Colorado.EDU (128.138.1.3) 294 ms 288 ms 294 ms
11 bruno.cs.colorado.edu (128.138.243.151) 293 ms 317 ms 294 ms
12 engr-gw-ot.cs.colorado.edu (128.138.204.1) 323 ms 317 ms 384 ms
13 cu-gw.Colorado.EDU (128.138.1.1) 294 ms 318 ms 294 ms

14 enss.ucar.edu (192.43.244.10) 323 ms 318 ms 294 ms

15 t3-1.Denver-cnss97.t3.ans.net (140.222.97.2) 294 ms 288 ms 384 ms
16 t3-0.enss142.t3.ans.net (140.222.142.1) 293 ms 288 ms 294 ms

17 Gabby.Telcom.Arizona.EDU (192.80.43.1) 294 ms 288 ms 294 ms
18 Butch.Telcom.Arizona.EDU (128.196.128.88) 293 ms 317 ms 294 ms

19 gateway.tuc.noao.edu (140.252.104.1) 294 ms 289 ms 294 ms
20 netb.tuc.noao.edu (140.252.1.183) 324 ms 321 ms 294 ms
21 sun.tuc.noao.edu (140.252.13.33) 534 ms 529 ms 564 ms

Вывод при работе в глобальных сетях

Вывод при работе в глобальных сетях

Вывод, показанный ранее для нашей маленькой сети, достаточно реально показывает, как функционируют протоколы. Однако, будет очень интересно посмотреть, как работает traceroute в больших сетях, например, в сети Internet.
На рисунке 8.4 показано как отправляется запрос от sun к Сетевому информационному центру (NIC - Network Information Center).
sun % traceroute nic.ddn.mil
traceroute to nic.ddn.mil (192.112.36.5), 30 hops max, 40 byte packets

1 netb.tuc.noao.edu (140.252.1.183) 218 ms 227 ms 233 ms
2 gateway.tuc.noao.edu (140.252.1.4) 233 ms 229 ms 204 ms

3 butch.telcom.arizona.edu (140.252.104.2) 204 ms 228 ms 234 ms
4 Gabby.Telcom.Arizona.EDU (128.196.128.1) 234 ms 228 ms 204 ms
5 NSIgate.Telcom.Arizona.EDU (192.80.43.3) 233 ms 228 ms 234 ms

6 JPL1.NSN.NASA.GOV (128.161.88.2) 234 ms 590 ms 262 ms
7 JPL3.NSN.NASA.GOV (192.100.15.3) 238 ms 223 ms 234 ms
8 GSFC3.NSN.NASA.GOV (128.161.3.33) 293 ms 318 ms 324 ms
9 GSFC8.NSN.NASA.GOV (192.100.13.8) 294 ms 318 ms 294 ms
10 SURA2.NSN.NASA.GOV (128.161.166.2) 323 ms 319 ms 294 ms
11 nsn-FIX-pe.sura.net (192.80.214.253) 294 ms 318 ms 294 ms
12 GSI.NSN.NASA.GOV (128.161.252.2) 293 ms 318 ms 324 ms

13 NIC.DDN.MIL (192.112.36.5) 324 ms 321 ms 324 ms

Вывод tcpdump для примера traceroute от svr4 к slip.

Рисунок 8.1 Вывод tcpdump для примера traceroute от svr4 к slip.

ICMP cообщение "время истекло при передаче" (time exceeded in transit) это то, что мы ожидаем увидеть от маршрутизатора bsdi, в том случае если он уменьшит на единицу TTL и оно станет равным нулю. ICMP сообщение придет от маршрутизатора даже в том случае, если IP датаграмма, которая была уничтожена, направлялась на slip.
Существуют два различных ICMP сообщения об истечении времени (рисунок 6.3), в каждом из них содержится различное поле code. На рисунке 8.2 показан формат этих ICMP сообщений.

Вывод tcpdump для traceroute с

Рисунок 8.10 Вывод tcpdump для traceroute с неработающей жесткой маршрутизацией от источника.

Обратите внимание на то, что каждая UDP датаграмма, посланная sun, имеет в качестве назначения netb, а не хост назначения (westgate). Мы описали это с помощью примера, показанного на рисунке 8.7. Два других маршрутизатора указаны с опцией -G (gateway и gabby), а конечный пункт назначения (westgate) появляется в списке опций SSRR для первой пересылки.
Также из этого вывода можно заметить, что тайм-аут, используемый traceroute (время между строками 15 и 16), составляет 5 секунд.

TCP-IP крупным планом

Более подробно

Более подробно

На рисунке 9.4 показан формат сообщения ICMP о перенаправлении.

Более сложные таблицы маршрутизации

Более сложные таблицы маршрутизации

Хост sun является маршрутизатором по умолчанию для всех хостов в нашей подсети, так как он имеет SLIP канал с дозвоном, который подключен к Internet (см. рисунок на внутренней стороне обложки).
sun % netstat -rn
Routing tables
Destination Gateway Flags Refcnt Use Interface
140.252.13.65 140.252.13.35 UGH 0 171 le0
127.0.0.1 127.0.0.1 UH 1 766 lo0
140.252.1.183 140.252.1.29 UH 0 0 sl0
default 140.252.1.183 UG 1 2955 sl0
140.252.13.32 140.252.13.33 U 8 99551 le0

Первые два пункта таблицы маршрутизации sun идентичны первым двум пунктам для хоста svr4: маршрут, указывающий на хост slip, через маршрутизатор bsdi и loopback маршрут.
Третья строка отличается. Это прямой маршрут (флаг G не установлен) на хост (флаг H установлен), соответствующий каналу точка-точка, интерфейс SLIP. Если мы посмотрим на вывод команды ifconfig,
sun % ifconfig sl0
sl0: flags=1051
inet 140.252.1.29 --> 140.252.1.183 netmask ffffff00

то увидим, что адрес назначения в таблице маршрутизации на другом конце канала точка-точка (маршрутизатор netb), а адрес маршрутизатора в действительности это локальный IP адрес исходящего интерфейса (140.252.1.29). (Раньше мы говорили, что для прямых маршрутов адрес маршрутизатора печатается командой netstat как локальный IP адрес используемого интерфейса.)
Пункт по умолчанию это непрямой маршрут (флаг G), указывающий на сеть (нет флага H). Адрес маршрутизатора - 140.252.1.183, (адрес на другом конце SLIP канала), а не локальный IP адрес SLIP интерфейса (140.252.1.29) (так как это непрямой маршрут).
Необходимо обратить внимание на то, что третья и четвертая строки в выводе команды netstat (интерфейс sl0) создаются программным обеспечением SLIP при установлении канала SLIP, они удаляются, когда канал SLIP отключается.

Действия, выполняемые IP уровнем.

Рисунок 9.1 Действия, выполняемые IP уровнем.

Формат ICMP сообщения запроса маршрутизатора.

Рисунок 9.6 Формат ICMP сообщения запроса маршрутизатора.

Функционирование хоста

Функционирование хоста

При старте хост обычно посылает три запроса о поиске маршрутизатора с интервалом в 3 секунды. После того как принято объявление от маршрутизатора, запросы прекращаются.
Хост также слушает объявления от маршрутизатора. Эти объявления могут привести к смене маршрутизатора по умолчанию для данного хоста. Если объявление не получено для текущего маршрута по умолчанию, он может быть удален по тайм-ауту.
Пока текущий маршрутизатор по умолчанию функционирует, он отправляет объявления каждые 10 минут с временем жизни в 30 минут. Это означает, что маршрут по умолчанию в таблице маршрутизации хоста не будет удален по тайм-ауту, даже если одно или два объявления будут потеряны.

Функционирование маршрутизатора

Функционирование маршрутизатора


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

ICMP ошибки о недоступности хоста и сети

ICMP ошибки о недоступности хоста и сети

ICMP ошибка о недоступности хоста (host unreachable) отправляется маршрутизатором, когда он получает IP датаграмму, которую невозможно перенаправить. (На рисунке 6.10 мы показали формат ICMP сообщений о недоступности.) Мы сможем пронаблюдать это в нашей сети, если выключим SLIP канал с дозвоном на маршрутизаторе sun и попробуем отправить пакет через SLIP канал с любого другого хоста, указав sun как маршрутизатор по умолчанию.
Ранние реализации TCP/IP в BSD генерировали и ошибки о недоступности хоста, и ошибки о недоступности сети, в зависимости от того, принадлежал ли пункт назначения локальной подсети или нет. 4.4BSD генерирует только ошибку о недоступности хоста.
Обратимся снова к выводу команды netstat запущенной на маршрутизаторе sun, вывод показан в предыдущем разделе. Мы видим, что пункт таблицы маршрутизации, который соответствует SLIP каналу, добавляется, когда SLIP канал включается, и удаляется, когда SLIP канал выключается. Это означает, что когда SLIP канал отключен, маршрута по умолчанию на sun не существует. Однако мы не будем пытаться изменить все таблицы маршрутизации у хостов в нашей маленькой сети, оставив им возможность самим удалить свои маршруты по умолчанию. Вместо этого мы посчитаем ICMP сообщения о недоступности хоста, сгенерированные sun для любых пакетов, которые он не может перенаправить.
Мы можем увидеть это, запустив ping с svr4 на хост, находящийся на другом конце SLIP канала (в настоящее время этот хост выключен):
svr4 % ping gemini
ICMP Host Unreachable from gateway sun (140.252.13.33)
ICMP Host Unreachable from gateway sun (140.252.13.33)
^? символ прерывания

На рисунке 9.2 мы показали вывод команды tcpdump для этого примера. (Команда запущена на хосте bsdi).
1 0.0 svr4 > gemini: icmp: echo request
2 0.00 (0.00) sun > svr4: icmp: host gemini unreachable

3 0.99 (0.99) svr4 > gemini: icmp: echo request
4 0.99 (0.00) sun > svr4: icmp: host gemini unreachable

ICMP ошибки перенаправления

ICMP ошибки перенаправления

ICMP ошибка перенаправления отправляется маршрутизатором на хост, пославший IP датаграмму, когда датаграмма должна быть послана на другой маршрутизатор. Подобная концепция довольно проста. Мы привели три составные части этой концепции на рисунке 9.3. Увидеть ICMP перенаправление можно только когда хост имеет выбор, на какой маршрутизатор послать пакет. (Обратитесь к примерам, которые мы приводили на рисунке 7.6.)

Предположим, что хост посылает IP датаграмму на R1. Подобное решение принято потому, что R1 - это маршрутизатор по умолчанию для этого хоста.

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

R1 посылает ICMP перенаправление на хост, сообщая тем самым, что следующие датаграммы необходимо посылать на R2 вместо R1.

ICMP сообщение о перенаправлении.

Рисунок 9.4 ICMP сообщение о перенаправлении.


Существуют четыре различных типа сообщений о перенаправлении, с различными значениями кода (code), как показано на рисунке 9.5.

код	Описание
0	перенаправление для сети
1	перенаправление для хоста
2	перенаправление для типа сервиса (TOS) и сети
3	перенаправление для типа сервиса (TOS) и хоста

ICMP сообщения поиска маршрутизатора

ICMP сообщения поиска маршрутизатора (ICMP Router Discovery Messages)

Ранее в этой главе мы говорили, что одним из способов инициализации таблицы маршрутизации является создание статических маршрутов, которые заносятся в конфигурационные файлы. Подобный метод часто используется для установки маршрута по умолчанию. Существует способ, заключающийся в использовании ICMP объявлений маршрутизаторов.
Основной принцип заключается в том, что после загрузки хост рассылает широковещательные или групповые запросы с требованием сообщить ему о маршрутизаторе. Один или несколько маршрутизаторов отвечают с использованием сообщения об объявлении маршрутизатора. В дополнение, маршрутизаторы периодически рассылают широковещательные или групповые сообщения с объявлением маршрутизатора, позволяя каждому хосту, который примет эти сообщения, обновить свои таблицы маршрутизации.
RFC 1256 [Deering 1991] содержит формат этих ICMP сообщений. На рисунке 9.6 показан формат ICMP сообщения запроса маршрутизатора. На рисунке 9.7 показан формат ICMP сообщения объявления маршрутизатора, которое рассылается маршрутизаторами.
В одном сообщении маршрутизатор может объявить несколько адресов. Поле количества адресов. Размер записи адреса - количество 32-битных слов для каждого адреса маршрутизатора, оно всегда установлено в 2. Время жизни - количество секунд, в течение которого данное объявление адресов считается действительным.

Инициализация таблицы маршрутизации

Инициализация таблицы маршрутизации

Мы никогда не упоминали о том, как создаются пункты в таблице маршрутизации. Когда инициализируется интерфейс (обычно, когда адрес интерфейса устанавливается командой ifconfig), автоматически создается прямой маршрут для этого интерфейса. Для каналов точка-точка и loopback интерфейса устанавливается маршрут к хосту (то есть устанавливается флаг H). Для широковещательных интерфейсов, таких как Ethernet, маршрутом является сама эта сеть.
Маршруты к хостам или сетям, которые не подключены непосредственно, должны быть помещены в таблицу маршрутизации каким-либо иным образом. Самый распространенный способ создания маршрутов - с помощью команды route, что обычно делается из загрузочных файлов при старте системы. На хосте svr4 были исполнены следующие команды, которые добавляют пункты, показанные ранее:
route add default sun 1
route add slip bsdi 1
Третий аргумент (default и slip) это пункты назначения, четвертый аргумент это маршрутизатор (gateway) и последний аргумент это показатель маршрутизации. Команда route использует показатель маршрутизации следующим образом: она устанавливает флаг G, если показатель больше чем 0, и не устанавливает флаг G, если показатель равен 0.
К сожалению, совсем немногие системы содержат команды route в своих стартовых файлах. В 4.4BSD и BSD/386 это /etc/netstat, в SVR4 - /etc/inet/rc.inet, в Solaris 2.x - /etc/rc2.d/S69inet, в SunOS 4.1.x - /etc/rc.local и в AIX 3.2.2 - /etc/rc.net.
В некоторых системах маршрутизатор по умолчанию содержится в файле, например, /etc/defaultrouter. Этот пункт по умолчанию добавляется в таблицу маршрутизации при каждой перезагрузке.
Существует еще один способ заполнить таблицу маршрутизации с помощью запуска демона маршрутизации (см. главу 10) или с помощью нового протокола определения маршрутов (раздел "ICMP сообщения поиска маршрутизатора").

Нет маршрута к пункту назначения

Нет маршрута к пункту назначения

Во всех наших примерах сделано предположение, что поиск в таблице маршрутизации заканчивается успешно и будет обнаружено соответствие, хотя бы с маршрутором по умолчанию. Что произойдет, если маршрут по умолчанию отсутствует, и не будет найдено совпадение с указанным пунктом назначения?
Ответ зависит от того, какого рода IP датаграмма обрабатывается, то есть была ли она сгенерирована непосредственно этим хостом или она должна быть перенаправлена (в том случае, если хост выступает в роли маршрутизатора). Если датаграмма была сгенерирована этим хостом, приложению, которое отправило датаграмму, возвращается ошибка "хост недоступен" (host unreachable) или "сеть недоступна" (network unreachable). Если датаграмма должна быть перенаправлена, посылающему хосту возвращается ICMP собщение о недоступности хоста. Мы рассмотрим эту ошибку в следующем разделе.

Перенаправлять или не перенаправлять

Перенаправлять или не перенаправлять

Мы уже несколько раз упоминали о том, что хост не сможет перенаправить IP датаграммы, если он специально не сконфигурирован, чтобы выступать в роли маршрутизатора. Как осуществляется подобная конфигурация?
Большинство Berkeley реализаций, имеют переменную ядра, названную ipforwarding (или похоже). (См. приложение Е.) Некоторые системы (BSD/386 и SVR4, например) перенаправляют датаграммы, если эта переменная установлена в ненулевое значение. В SunOS 4.1.x определено три значения для этой переменной: -1 обозначает, что перенаправление никогда не будет осуществляться и что никогда нельзя будет сменить значение этой переменной, 0 обозначает, что перенаправление не осуществляется, однако значение переменной устанавливается в 1, когда два или более интерфейсов активизированы, и 1 обозначает, что перенаправление осуществляется всегда. У Solaris 2.x также существует три значения, а именно 0 (перенаправление не осуществляется), 1 (перенаправление осуществляется всегда) и 2 (перенаправление осуществляется только тогда, когда активизированы два или более интерфейсов).
В более ранних реализациях 4.2BSD датаграммы перенаправляются по умолчанию. При этом, если система сконфигурирована неверно, возникает очень много проблем. Именно поэтому данная опция ядра должна быть всегда по умолчанию установлена в значение "без перенаправления" (never forward), пока системный администратор специально не включит перенаправление.

Пример

Пример

Посмотрим ICMP перенаправления в действии на примере нашей сети (на внутренней стороне обложки). Мы показали всего три хоста (aix, solaris и gemini) и два маршрутизатора (gateway и netb) в верхней части сети, в действительности там более 150 хостов и 10 маршрутизаторов. Большинство хостов считают gateway маршрутизатором по умолчанию, так как он предоставляет доступ к Internet.
Как можно получить доступ из подсети 140.252.1 к нижней подсети (4 нижние хоста на рисунке)? Во-первых, вспомним, что если на конце SLIP канала находится единственный хост, используется уполномоченный агент ARP (глава 4, раздел "Уполномоченный агент ARP"). Это означает, что для хостов в верхней сети 140.252.1 не требуется специальных средств, для того чтобы получить доступ к хосту sun (140.252.1.29). Доступ обеспечит программное обеспечение уполномоченного агента ARP на netb.
Однако, если на удаленном конце SLIP канала присутствует сеть, то необходима маршрутизация. Одно из возможных решений заключается в том, чтобы каждый хост и маршрутизатор знали о том, что маршрутизатор netb является шлюзом в сеть 140.252.13. Этого можно добиться путем внесения статического маршрута в каждую таблицу маршрутизации на каждом хосте или запустив на каждом хосте маршрутизирующий демон. Однако существует более простой способ (метод, который обычно используется) - использовать ICMP перенаправление.
Запустим программу ping с хоста solaris в верхней сети на хост bsdi (140.252.13.35) в нижней сети. Так как идентификаторы подсети различны, уполномоченный агент ARP не может быть использован. Предположим, что статический маршрут не установлен, поэтому при посылке первого пакета будет использован маршрут по умолчанию на маршрутизатор gateway. Ниже мы приводим таблицу маршрутизации, перед тем как запустили ping:
solaris % netstat -rn
Routing Table:
Destination Gateway Flags Ref Use Interface
-------------- --------------- ------- --- ------- --------------
127.0.0.1 127.0.0.1 UH 0 848 lo0
140.252.1.0 140.252.1.32 U 3 15042 le0
224.0.0.0 140.252.1.32 U 3 0 le0
default 140.252.1.4 UG 0 5747

(Пункт 224.0.0.0 используется для групповой адресации IP. Мы опишем это в главе 12.) Если указать опцию -v в командной строке ping, то будут видны все ICMP сообщения принятые хостом. Нам необходимо указать эту опцию, чтобы увидеть сообщения о перенаправлении, которые будут посланы.
solaris % ping -sv bsdi
PING bsdi: 56 data bytes
ICMP Host redirect from gateway gateway (140.252.1.4)
to netb (140.252.1.183) for bsdi (140.252.13.35)
64 bytes from bsdi (140.252.13.35): icmp_seq=0. time=383. ms
64 bytes from bsdi (140.252.13.35): icmp_seq=1. time=364. ms
64 bytes from bsdi (140.252.13.35): icmp_seq=2. time=353. ms
^? символ прерывания
----bsdi PING Statistics----
4 packets transmitted, 3 packets received, 25% packet loss
round-trip (ms) min/avg/max = 353/366/383

Перед тем как мы получим первый ответ на ping, хост примет ICMP перенаправление от маршрутизатора по умолчанию gateway. Если мы затем посмотрим таблицу маршрутизации, то увидим, что появился новый маршрут к хосту bsdi. (Этот пункт выделен жирным шрифтом.)
solaris % netstat -rn
Routing Table:
Destination Gateway Flags Ref Use Interface
--------------- --------------- -------- --- ------- -------------
127.0.0.1 127.0.0.1 UH 0 848 lo0
140.252.13.35 140.252.1.183 UGHD 0 2
140.252.1.0 140.252.1.32 U 3 15045 le0
224.0.0.0 140.252.1.32 U 3 0 le0
default 140.252.1.4 UG 0 5749

Pltcmm мы впервые видиv флаг D, который означает, что маршрут был установлен с использованием ICMP перенаправления. Флаг G обозначает, что это непрямой маршрут к шлюзу (netb), а флаг H обозначает, что это маршрут к хосту (как мы и ожидали), а не маршрут к сети.
Так как это маршрут к хосту, добавленный путем перенаправления, он обслуживает только хост bsdi. Если затем мы попробуем получить доступ к хосту svr4, будет сгенерировано еще одно перенаправление, и будет создан еще один маршрут к хосту. Точно так же, попытка получить доступ к хосту slip создаст еще один маршрут. Каждое перенаправление на конкретный хост приводит к созданию нового маршрута к хосту. Все три хоста в подсети (bsdi, svr4 и slip) будут обслуживаться одним маршрутом к сети, указывающим на маршрутизатор sun. Однако, ICMP перенаправления создают маршруты к хостам, а не маршруты к сетям, так как маршрутизатор, генерирующий перенаправление в данном примере (gateway), не имеет представления о структуре подсетей в сети 140.252.13.

Пример ICMP перенаправления.

Рисунок 9.3 Пример ICMP перенаправления.


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

Принципы маршрутизации

Принципы маршрутизации

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

Поиск совпадающего адреса хоста.

Поиск совпадающего адреса сети.

Поиск пункта по умолчанию. (Пункт по умолчанию обычно указывается в таблице маршрутизации как сеть с идентификатором сети равным нулю.)

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

Простая таблица маршрутизации

Простая таблица маршрутизации

Давайте рассмотрим типичные таблицы маршрутизации. На хосте svr4 мы запустили команду netstat с опцией -r, чтобы просмотреть таблицу маршрутизации, и с опцией -n, которая печатает IP адреса в цифровом формате, а не в виде имен. (Мы сделали это, потому что некоторые пункты таблицы маршрутизации это сети, а не хосты. Без опции -n команда netstat просматривает файл /etc/networks, и берет оттуда имена сетей. При этом может получиться некоторая путаница, потому что в выводе команды помимо имен хостов появятся имена сетей.)
svr4 % netstat -rn
Routing tables
Destination Gateway Flags Refcnt Use Interface
140.252.13.65 140.252.13.35 UGH 0 0 emd0
127.0.0.1 127.0.0.1 UH 1 0 lo0
default 140.252.13.33 UG 0 0 emd0
140.252.13.32 140.252.13.34 U 4 25043 emd0

В первой строке говорится, что для пункта назначения 140.252.13.65 (хост slip) шлюз (маршрутизатор), на который будут посылаться пакеты, это 140.252.13.35 (bsdi). Хост slip подсоединен к bsdi через SLIP канал, а bsdi находится в той же сети Ethernet, что и данный хост.
Для конкретного маршрута может быть показано 5 различных флагов.
U
Маршрут активен. G
Маршрут подключен к шлюзу (маршрутизатору). Если этот флаг не установлен, считается, что пункт назначения подключен непосредственно. H
Маршрут ведет к хосту, что означает, что в качестве пункта назначения используется полный адрес хоста. Если этот флаг не установлен, то маршрут указывает на сеть, что в свою очередь означает, что пунктом назначения является адрес сети: идентификатор сети или комбинация идентификатора сети и идентификатора подсети. D
Маршрут был создан посредством перенаправления ("ICMP ошибки перенаправления"). M
Маршрут был модифицирован посредством перенаправления ("ICMP ошибки перенаправления"). Флаг G очень важен, потому что именно этот флаг определяет различие между непрямым маршрутом (indirect route) и прямым маршрутом (direct route). (Флаг G не устанавливается для прямого маршрута.) Отличие заключается в том, что у пакета, направляющегося по прямому маршруту, IP адрес и адрес канального уровня указывают на конечный пункт назначения (рисунок 3.3). Когда пакет отправляется по непрямому маршруту, IP адрес указывает на конечный пункт назначения, а адрес канального уровня указывает на маршрутизатор следующей пересылки. Мы видели подобный пример этого на рисунке 3.4. В этой таблице маршрутизации мы видим непрямой маршрут (флаг G установлен), при этом IP адрес пакета, который будет передаваться по этому маршруту, будет совпадать с IP адресом конечного пункта назначения (140.252.13.65), а адрес канального уровня будет указывать на соответствующий маршрутизатор, IP адрес которого 140.252.13.35.
Очень важно понимать разницу между флагами G и H. Флаг G определяет различие между прямым и непрямым маршрутом, как описано выше. Флаг H указывает на то, что адрес пункта назначения (первая колонка вывода команды netstat) это полный адрес хоста. Отсутствие флага H означает, что адрес назначения это адрес сети (идентификатор хоста должен быть установлен в 0). При просмотре таблицы маршрутизации используются следующие правила: если маршрут указывает на хост он должен полностью совпадать с IP адресом пункта назначения, если маршрут указывает на сеть - сопасть должны идентификаторы сети и любого идентификатора подсети в адресе пункта назначения. Большинство версий команды netstat сначала печатают все пункты, указывающие на хосты, после чего печатаются пункты, указывающие на сети.
Колонка счетчика обращений (reference count) сообщает о количестве использований каждого маршрута. Протоколы, ориентированные на соединения, такие как TCP, занимают маршрут все время, пока соединение установлено. Если установить Telnet соединение между хостами svr4 и slip, то счетчик обращений будет установлен в 1. Если установить еще одно Telnet соединение, счетчик будет показывать 2, и так далее.
Следующая колонка (use) показывает количество пакетов, прошедших по этому маршруту. Если запустить программу ping, которая отправит 5 пакетов, счетчик установится в значение 5 (Естественно, при условии, что никто больше не использует этот маршрут). Последняя колонка интерфейс (interface) сообщает нам имя локального интерфейса.
Вторая строка в выводе относится к loopback интерфейсу (глава 2, раздел "Интерфейс Loopback"), который всегда имеет имя lo0. Флаг G не установлен, так как маршрут не ведет к маршрутизатору. Флаг H указывает, что адрес назначения (127.0.0.1) это адрес хоста, а не адрес сети. Когда флаг G не установлен, это указывает на прямой маршрут, в колонке gateway указывается IP адрес исходящего интерфейса.
Третья строка вывода описывает маршрут по умолчанию. Каждый хост должен иметь один или несколько маршрутов по умолчанию. Этот пункт указывает на то, что необходимо посылать пакеты на маршрутизатор 140.252.13.33 (sun), если не был найден конкретный маршрут. Это означает, что хост svr4 может получить доступ к другим системам в Internet через маршрутизатор sun (и его SLIP канал) воспользовавшись этим единственным пунктом таблицы маршрутизации. Возможность установить маршрут по умолчанию это одна из наиболее мощных концепций IP маршрутизации. Флаги для этого маршрута (UG) говорят о том, что маршрут указывает на маршрутизатор.
Здесь мы специально назвали sun маршрутизатором, а не хостом, потому что когда он работает как маршрутизатор по умолчанию, используются его функции IP перенаправления, при этом он не выступает в роли хоста.
Требования к хостам Host Requirements RFC указывает, что IP уровень должен поддерживать несколько маршрутов по умолчанию. Большинство реализаций, однако, этого не позволяют. Когда существует несколько маршрутов по умолчанию, общая техника выбора маршрута заключается в последовательном многократном переборе маршрутов. Именно так поступает, например, Solaris 2.2.
И последняя строка указывает на подключенный Ethernet. Флаг H не установлен, это указывает на то, что адрес назначения (140.252.13.32) это адрес сети, при этом идентификатор хоста установлен в 0. И действительно, 5 младших битов установлены в 0 (рисунок 3.11). Это прямой маршрут (флаг G не установлен), поэтому в колонке gateway указывается IP адрес исходящего интерфейса.
Существует еще один немаловажный аспект, оказывающий влияние на маршрутизацию, однако он не отражен в выводе команды netstat. Это маска подсети, связанная с адресом назначения (140.252.13.32). Когда адрес пункта назначения сравнивается с IP адресом 140.252.13.33, адрес перед сравнением, логически суммируется с маской подсети, связанной с этим адресом назначения (0xffffffe0 из раздела "Пример подсети" главы 3). Так как ядро знает каждый интерфейс, связанный с каждым пунктом таблицы маршрутизации, и так как каждый интерфейс имеет маску подсети, каждый пункт таблицы маршрутизации имеет собственную маску подсети.
Сложность таблицы маршрутизации хоста зависит от топологии сетей, к которым хост имеет доступ.

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

Хост подключен к одной локальной сети и имеет возможность получить доступ к хостам только в этой локальной сети. Таблица маршрутизации имеет 2 пункта: один для loopback интерфейса и один для локальной сети (например, Ethernet).

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

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

Давайте проследим за тем, что делает IP когда обращается к таблице маршрутизации, чтобы смаршрутизировать пакеты на хосте svr4.

Предположим, что адрес назначения принадлежит хосту sun, 140.252.13.33. Во-первых, осуществляется поиск совпадающего адреса хоста. Два пункта хостов в таблице (slip и localhost) не совпадают, поэтому поиск в таблице маршрутизации осуществляется снова на предмет совпадающего адреса сети. Совпадение найдено в пункте 140.252.13.32 (идентификатор сети и идентификатор подсети совпали), поэтому используется интерфейс emd0. Это прямой маршрут, поэтому адрес канального уровня будет являться адресом назначения.

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

Теперь мы посылаем датаграмму по Internet на хост aw.com (192.207.117.2). Первый поиск в таблице маршрутизации на предмет совпадающего адреса хоста заканчивается неудачей, поэтому осуществляется поиск на предмет совпадающего адреса сети. Он также завершается неудачно. И последний шаг это поиск пункта по умолчанию, который заканчивается успешно. Маршрут является непрямым через маршрутизатор 140.252.13.33 с использованием интерфейса emd0.

В нашем последнем примере мы послали датаграмму на свой собственный хост. Существует 4 способа сделать это, используя имя хоста, IP адрес хоста, loopback имя или loopback IP адрес:

ftp svr4
ftp 140.252.13.34

ftp localhost
ftp 127.0.0.1
В двух первых случаях второй поиск в таблице маршрутизации приведет к совпадению с сетью 140.252.13.32, и пакет посылается через Ethernet драйвер. Как мы показали на рисунке 2.4, пакет, предназначенный на собственный IP адрес хоста, посылается в loopback драйвер, который ставит пакет во входную очередь IP.
В двух следующих случаях указано имя loopback интерфейса или его IP адрес, поэтому первый поиск в таблице маршрутизации приведет к совпадению адреса хоста, и пакет отсылается в loopback драйвер, который ставит его во входную очередь IP.
Во всех четырех случаях пакет отправляется в loopback драйвер, однако принимаются два разных решения о маршрутизации.

Различные значения code для ICMP перенаправления.

Рисунок 9.5 Различные значения code для ICMP перенаправления.

Существуют три IP адреса, которые должен знать получатель ICMP перенаправления: (1) IP адрес, который вызвал перенаправление (находится в IP заголовке, возвращенном как данные в ICMP сообщении о перенаправлении), (2) IP адрес маршрутизатора, который послал перенаправление (является IP адресом источника IP датаграммы, содержащей перенаправление) и (3) IP адрес маршрутизатора, который должен быть использован (находится в байтах с 4-го по 7-ой в ICMP сообщении).
Существует несколько правил, посвященных ICMP перенаправлениям. Во-первых, перенаправления генерируются только маршрутизаторами, ни в коем случае не хостами. Однако, перенаправления могут быть использованы только хостами, не маршрутизаторами. Считается, что маршрутизаторы используют протоколы маршрутизации и обмениваются таблицами с другими маршрутизаторами, поэтому они не нуждаются в перенаправлениях. (Это означает, что на рисунке 9.1 таблица маршрутизации должна быть обновлена либо с использованием маршрутизирующего демона, либо с использованием перенаправления, однако не с использованием и того и другого.)
Когда 4.4BSD функционирует как маршрутизатор, осуществляются следующие проверки, причем каждая из них должна быть истиной, для того чтобы было сгенерировано ICMP перенаправление.

Исходящий и входящий интерфейс один и тот же.

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

Датаграмма не должна быть смаршрутизирована от источника.

Ядро должно быть сконфигурировано таким образом, чтобы посылать перенаправления.

Переменная ядра с именем ip_sendredirects (или похожим). (См. приложение Е.) Большинство современных систем (4.4BSD, SunOS 4.1.x, Solaris 2.x и AIX 3.2.2, например) включают эту переменную по умолчанию. Другие системы, например, SVR4, имеют эту переменную по умолчанию выключенной.
В дополнение, хост 4.4BSD, который принимает ICMP перенаправления, осуществляет некоторые проверки перед модификацией своей таблицы маршрутизации. Это предотвращает странное поведение маршрутизатора или хоста, вызванное некорректной модификацией таблицы маршрутизации системы.

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

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

Перенаправление не может заставить хост использовать самого себя в качестве маршрутизатора.

Модифицируемый маршрут должен быть непрямым маршрутом.

И в заключение стоит повториться, что маршрутизаторы должны посылать только перенаправления к хостам (codes 1 или 3 на рисунке 9.5), а не перенаправления к сетям. Из-за разделения на подсети не всегда можно однозначно указать, когда должно быть послано перенаправление к сети вместо перенаправления к хосту. Некоторые хосты воспринимают принятое перенаправление к сети как перенаправление к хосту, в том случае если маршрутизатор послал неверный тип (type).

Реализация

Реализация

Сообщения о поиске маршрутизатора обычно генерируются и обрабатываются пользовательскими процессами (демонами). Поэтому добавляется еще один программный способ обновления таблицы маршрутизации к тем, что показаны на рисунке 9.1, несмотря на то, что он может добавить или удалить только пункт по умолчанию. Демон должен быть сконфигурирован так, чтобы выступать либо в роли маршрутизатора, либо в роли хоста.
Эти два ICMP сообщения достаточно новы и поддерживаются не всеми системами. В нашей сети их поддерживает только Solaris 2.x (демон in.rdisc). Несмотря на то, что RFC рекомендует использовать групповую адресацию IP, где это возможно, поиск маршрутизаторов может осуществляться с использованием широковещательных сообщений.

Сообщение ICMP о недоступности хоста в ответ на ping.

Рисунок 9.2 Сообщение ICMP о недоступности хоста в ответ на ping.

Когда маршрутизатор sun обнаруживает, что на хост gemini нет маршрута, он отвечает на эхо запрос сообщением о недоступности хоста.
Если мы включим SLIP канал, подключающий нас к Internet, и попробуем послать ping на несуществующий в Internet IP адрес, то рано или поздно получим сообщение об ошибке. Интересно посмотреть, как далеко уйдет пакет по Internet, перед тем как будет получена ошибка:
sun % ping 192.82.148.1 этот IP адрес не подключен к Internet
PING 192.82.148.1: 56 data bytes
ICMP Host Unreachable from gateway enss142.UT.westnet.net (192.31.39.21)
for icmp from sun (140.252.1.29) to 192.82.148.1

Обратившись к рисунку 8.5, мы увидим, что пакет прошел через шесть маршрутизаторов, перед тем как было определено, что IP адрес не существует. Только когда он дошел до пределов NSFNET магистрали, была выявлена ошибка. Это произошло из-за того, что шесть маршрутизаторов, которые перенаправляли пакет, отправляли его на пункт назначения по умолчанию. И только когда пакет достиг NSFNET магистрали, маршрутизатор, имеющий полное представление о каждой сети, подключенной к Internet, смог определить ошибку. Это иллюстрирует тот факт, что большинство маршрутизаторов функционируют, не представляя себе полной топологии сетей.
[Ford, Rekhter, and Braun 1993] определяет домены маршрутизации верхнего уровня (top-level routing domain) как маршрутизаторы, поддерживающие и обрабатывающие информацию о большинстве узлов Internet и не использующие маршрутов по умолчанию. В Internet существует пять доменов маршрутизации верхнего уровня: NFSNET магистраль, Commercial Internet Exchange (CIX), NASA Science Internet (NSI), SprintLink и European IP Backbone (EBONE).

Упражнения

Упражнения

Как Вы думаете, почему существуют два типа ICMP перенаправлений - на сеть и на хост?

Обратитесь к таблице маршрутизации хоста svr4, показанной в начале раздела "Принципы маршрутизации". Является ли необходимым указание маршрута на хост slip (140.252.13.65)? Что изменится, если этот пункт будет удален из таблицы маршрутизации?

Представьте, что существует кабель между 4.2BSD и 4.3BSD хостами. Также представьте, что идентификатор сети - 140.1. Хост 4.2BSD распознает в качестве широковещательных адресов только адреса с идентификаторами хостов, установленными во все нули (140.1.0.0), тогда как хост 4.3BSD обычно отправляет широковещательные сообщения с идентификаторами хостов, состоящих из всех единичных битов (140.1.255.255). Также, хост 4.2BSD по умолчанию старается перенаправить входящие датаграммы, даже если он имеет только один интерфейс. Опишите, что произойдет, когда хост 4.2BSD получает IP датаграммы с адресом назначения 140.1.255.255.

Продолжим предыдущее упражнение. Представьте себе, что кто-либо исправил эту проблему, добавив запись в ARP кэш на одной из систем в подсети 140.1. (воспользовавшись командой arp), сказав при этом, что IP адрес 140.1.255.255 соответствует Ethernet адресу из всех единичных битов (широковещательный запрос Ethernet). Опишите, что произойдет в этом случае.

Просмотрите таблицу маршрутизации Вашей системы и опишите каждую запись.

Назад
Компания | Услуги | Для клиентов | Библиотека | Галерея | Cофт | Линки
На главную

TCP-IP крупным планом

BGP: протокол граничных маршрутизаторов

BGP: протокол граничных маршрутизаторов (Border Gateway Protocol)

BGP это протокол внешних маршрутизаторов, предназначенный для связи между маршрутизаторами в различных автономных системах. BGP заменяет собой старый EGP, который использовался в ARPANET. BGP Version 3 определен в RFC 1267 [Lougheed and Rekhter 1991].
RFC 1268 [Rekhter and Gross 1991] описывает использование BGP в Internet. Практически все, что приведенного ниже, взято именно из этих двух RFC. В дополнение, необходимо отметить, что в 1993 году BGP Version 4 разрабатывался таким образом (RFC 1467 [Topolcic 1993]), чтобы поддерживать CIDR, который мы опишем в разделе "CIDR: бесклассовая маршрутизация между доменами" этой главы.
Системы, поддерживающие BGP, обмениваются информацией о доступности сети с другими BGP системами. Эта информация включает в себя полный путь по автономным системам, по которым должен пройти траффик (поток данных), чтобы достичь этих сетей. Эта информация адекватна построению графа соединений AS (автономных систем). При этом возникает возможность легко обходить петли маршрутизации, а также упрощается процесс принятия решений о маршрутизации.
Во-первых, необходимо сказать, что IP датаграмма в AS может принадлежать как к локальному траффику, так и к транзитному траффику. Локальный - это траффик у которого источник и пункт назначения находятся в одной AS. При этом IP адреса источника и назначения указывает на хосты, принадлежащие одной автономной системе. Весь остальной траффик называется транзитным. Основное преимущество использования BGP в Internet заключается в уменьшении транзитного траффика.
Автономная система может принадлежать к следующим категориям:

Ограниченная (stub) AS автономная система имеет единственное подключение к одной внешней автономной системе. В такой автономной системе присутствует только локальный траффик.

Многоинтерфейсная (multihomed) AS имеет подсоединение к нескольким удаленным автономным системам, однако по ней запрещено прохождение транзитного траффика.

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

Общая топология Internet состоит из транзитных, многоинтерфейсных и ограниченных автономных систем. Ограниченные и многоинтерфейсные автономные системы не нуждаются в использовании BGP - они могут использовать EGP, чтобы обмениваться информацией о доступности с транзитными автономными системами.
BGP позволяет использовать маршрутизацию, основанную на политических решениях (policy-based routing). Все правила определяются администратором автономной системы и указываются в конфигурационных файлах BGP. "Политические решения" не являются частью протокола, однако позволяют делать выбор между маршрутами, когда существует несколько альтернативных, и позволяют управлять перераспределением информации. Решения принимаются в соответствии с вопросами безопасности или экономической целесообразности.
BGP отличается от RIP или OSPF тем, что BGP использует TCP в качестве транспортного протокола. Две системы, использующие BGP, устанавливают TCP соединения между собой и затем обмениваются полными таблицами маршрутизации BGP. Обновления представляются в виде изменений таблицы маршрутизации (таблица не передается целиком).
BGP это протокол вектора расстояний, однако, в отличие от RIP (который объявляет пересылки к пункту назначения), BGP перечисляет маршруты к каждому пункту назначения (последовательность номеров автономных систем к пункту назначения). При этом исчезают некоторые проблемы, связанные с использованием протоколов вектора расстояний. Каждая автономная система идентифицируется 16-битным номером.
BGP определяет выход из строя канала или хоста на другом конце TCP соединения путем регулярной отправки сообщения "оставайся в живых" (keepalive) своим соседям. Рекомендуемое время между этими сообщениями составляет 30 секунд. Сообщение "оставайся в живых", которое используется на уровне приложений, независимо от TCP опций "оставайся в живых" (глава 23).

CIDR: бесклассовая маршрутизация

CIDR: бесклассовая маршрутизация между доменами (Classless Interdomain Routing)

В главе 3 было сказано, что в настоящее время ощущается нехватка адресов класса В, поэтому узлам с несколькими сетями приходится присваивать несколько идентификаторов сетей класса С вместо одного идентификатора сети класса В. С одной стороны, появление адресов класса С решает одну проблему (переполнение количества адресов класса В). С другой стороны, появляется еще одна проблема: каждая сеть класса С требует записи в таблице маршрутизации. Бесклассовая маршрутизация между доменами (CIDR - Classless Interdomain Routing) это способ, который позволяет свести к минимуму рост таблиц маршрутизации в Internet. Этот способ также называется supernetting и описывается в RFC 1518 [Rekhter and Li 1993] и в RFC 1519 [Fuller et al. 1993], обзор можно найти в [Ford, Rekhter and Braun 1993]. CIDR одобрен Internet Architecture Board [Huitema 1993]. RFC 1467 [Topolcic 1993] кратко описывает состояние и развитие CIDR в Internet.
Основная концепция, заложенная в CIDR, заключается в том, что несколько IP адресов можно расположить определенным образом, что позволит уменьшить количество записей в таблице маршрутизации. Например, если один узел состоит из 16 адресов класса С, все 16 могут быть расположены таким образом, что они будут суммироваться, поэтому ко всем 16-ти можно будет обратиться через одну запись в таблице маршрутизации. Также, если 8 различных узлов подключены к одному и тому же Internetовскому "поставщику сервиса" через одну и ту же точку подключения к Internet, и если все 8 узлов имеют 8 различных IP адресов, они могут быть суммированы, после чего потребуется только одна запись в таблице маршрутизации, которая будет использоваться в Internet для всех 8 узлов.
Для того чтобы использовать подобное суммирование, необходимо, чтобы выполнялось три условия.

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

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

Протоколы маршрутизации, которые будут использоваться, должны быть расширены таким образом, чтобы позволять передачу 32-битных масок и 32-битных адресов. OSPF (раздел "OSPF: открыть первым наикратчайший маршрут") и RIP-2 (раздел "RIP Version 2") способны передавать 32-битные маски, так же как и BGP Version 4.

В качестве примера скажем, что RFC 1466 [Gerich 1993] рекомендует, чтобы новые адреса класса С в Европе находились в диапазоне 194.0.0.0 - 195.255.255.255. В шестнадцатиричном представлении эти адреса лежат в диапазоне 0xc2000000 - 0xc3ffffff. Это позволяет использовать 65536 различных идентификаторов сети класса С, однако все они имеют одинаковые 7 бит старшего порядка. В других (неевропейских) странах может быть использована единственная запись в таблице маршрутизации с IP адресом 0xc2000000 и 32-битной маской 0xfe000000 (254.0.0.0), чтобы организовать маршрут ко всем этим идентификаторам сетей класса С (в количестве 65536) через одну точку. Последовательность битов в адресе класса С (это биты, следующие за 194 или 195) может быть расположена в иерархическом порядке, например, по странам или по поставщикам сервиса, чтобы тем самым позволить дополнительное сложение внутри европейских маршрутизаторов с использованием дополнительных битов, стоящих после 7 бит старшего порядка в 32-битной маске.
CIDR также использует технику, которая определяет, что "лучшее совпадение это всегда наиболее длинное совпадение (longest match)": то есть совпадение максимального количества битов в 32-битной маске. Продолжая пример из предыдущего параграфа, нужно отметить следующее. Предположим, что один поставщик сервиса в Европе нуждается в использовании другого маршрутизатора для входа в Internet, чем вся остальная Европа. Если этот поставщик сервиса находится в диапазоне адресов 194.0.16.0 - 194.0.31.255 (16 идентификаторов сетей класса С), записи в таблице маршрутизации для этих сетей должны иметь IP адрес 194.0.16.0 и маску 255.255.240.0 (0xfffff000). Датаграмма, которая маршрутизируется на адрес 194.0.22.1, будет совпадать с этим пунктом таблицы маршрутизации и с одной из сетей класса С в остальной Европе. Однако, так как маска 255.255.240 "длиннее" чем маска 254.0.0.0, будет использован пункт в таблице маршрутизации, который имеет самую длинную маску.
Термин "бесклассовый" используется потому, что решения о маршрутизации принимаются на основе масок, накладываемых на полный 32-битный IP адрес. При этом не существует различия между адресами класса А, В или С.
Первоначально предполагается использовать CIDR в адресах новых сетей класса С. Благодаря внесению подобного изменения, значительно уменьшится рост таблиц маршрутизации в Internet, при этом не потребуется вносить никаких изменений в существующие маршрутизаторы. Хотя надо отметить, что подобное решение является кратковременной мерой. Более значительное улучшение можно получить, если CIDR будет использоваться для всех IP адресов, и существующие IP адреса будут переназначены (при этом все существующие хосты получат новые адреса!) в соответствии с ограничениями по странам, континентам и поставщикам сервисов [Ford, Rekhter and Braun 1993]. Выигрыш будет заключаться в следующем: современная таблица маршрутизации содержит до 10000 записей, тогда как после применения CIDR количество записей уменьшится до 200.

Демоны маршрутизации в Unix

Демоны маршрутизации в Unix

В Unix системах обычно запускается демон маршрутизации, называемый routed. Он присутствует практически в каждой версии TCP/IP. Этот демон понимает только протокол RIP. (Мы опишем routed в следующем разделе.) routed предназначен для сетей малого или среднего размеров.
Альтернативная программа - gated. Этот демон поддерживает как IGP, так и EGP. [Fedor 1988] описывает раннюю реализацию gated. На рисунке 10.1 приведены протоколы маршрутизации, поддерживаемые демоном routed и двуми версиями демона gated. Большинство систем, которые используют демоны маршрутизации, запускают routed, однако если возникает необходимость поддерживать разные протоколы маршрутизации, используется gated.

Демон	Протоколы внутренних маршрутизаторов	Протоколы внешних маршрутизаторов
HELLO	RIP	OSPF	EGP	BGP
routed		V1
gated, Version 2	·	V1		·	V1
gated, Version 3	·	V1,V2	V2	·	V2,V3

Динамическая маршрутизация

Динамическая маршрутизация

Динамическая маршрутизация используется для общения маршрутизаторов друг с другом. Маршрутизаторы передают друг другу информацию о том, какие сети в настоящее время подключены к каждому из них. Маршрутизаторы общаются, используя протоколы маршрутизации. Пользовательский процесс, посредством которого маршрутизаторы могут общаться с соседними маршрутизаторами, называется демоном маршрутизации (routing daemon). Как видно из рисунка 9.1, демон маршрутизации обновляет таблицу маршрутизации в ядре в соответствии с информацией, которую он получает от соседних маршрутизаторов.
Динамическая маршрутизация не меняет способы, с помощью которых ядро осуществляет маршрутизацию на IP уровне, как описано в разделе "Принципы маршрутизации" главы 9. Мы назвали это механизмом маршрутизации (routing mechanism). Ядро точно так же просматривает свою таблицу маршрутизации, отыскивая маршруты к хостам, маршруты к сетям и маршруты по умолчанию. Меняется только способ помещения информации в таблицу маршрутизации - вместо запуска команды route или использования загрузочных файлов маршруты добавляются и удаляются динамически демоном маршрутизации, который работает постоянно.
Как было отмечено ранее, демон маршрутизации отвечает за политику маршрутизации (routing policy) , выбирая, какие маршруты необходимо поместить в таблицу маршрутизации. Если демон обнаружил несколько маршрутов к пункту назначения, он выбирает (каким-либо образом), какой маршрут лучше, и именно этот маршрут (единственный) добавляет в таблицу маршрутизации. Если демон определил, что канал изчез (возможно по причине выхода из строя маршрутизатора или телефонной линии), он может удалить соответствующие маршруты или добавить альтернативные маршруты, чтобы обойти возникшую неисправность.
В Internet, на сегодняшний день, используется множество различных протоколов маршрутизации. Internet организован как сообщество автономных систем (AS - autonomous systems), каждая из которых обычно администрируется независимо от остальных. Например, сеть, построенная в университетском городке, обычно считается автономной системой. Магистраль (backbone) NSFNET с точки зрения Internet это автономная система, потому что все маршрутизаторы на магистрали находятся под единым административным контролем.
Для каждой автономной системы выбирается собственный протокол маршрутизации, с помощью которого осуществляется взаимодействие между маршрутизаторами в этой автономной системе. Такой протокол называется протоколом внутренних маршрутизаторов (IGP - interior gateway protocol) или протоколом внутридоменной маршрутизации (intradomain routing protocol). Наиболее популярный IGP - это протокол обмена информацией о маршрутизации (RIP - Routing Information Protocol). Более новый IGP это протокол Open Shortest Path First (OSPF). Он был разработан как замена для RIP. Устаревший IGP, который в настоящее время не используется, HELLO - это IGP, который первоначально использовался на магистрали NSFNET вплоть до 1986 года.
Новые требования к маршрутизаторам Router Requirements RFC [Almquist 1993] определяют, что маршрутизатор, который реализует любые динамические протоколы маршрутизации, должен поддерживать OSPF и RIP, а также может поддерживать другие IGP.
Существуют протоколы маршрутизации, которые называются протоколами внешних маршрутизаторов (EGP - exterior gateway protocols) или протоколами междоменной маршрутизации (interdomain routing protocols). Они предназначены для общения между маршрутизаторами, находящихимися в разных автономных системах. Исторически (и к большому сожалению) предшественником всех EGP был протокол с тем же самым именем: EGP. Более новый EGP - протокол пограничных маршрутизаторов (BGP - Border Gateway Protocol) в настоящее время используется между магистралью NSFNET и некоторыми региональными сетями, которые подключены к магистрали. Планируется, что BGP заменит собой EGP.

Два маршрутизатора netb и gateway

Рисунок 10.5 Два маршрутизатора netb и gateway, на которые мы послали запрос об их таблицах маршрутизации.


На рисунке 10.6 показан обмен пакетами, который получен с помощью команды tcpdump. Мы указали SLIP интерфейс с опцией -i sl0.
sun % tcpdump -s600 -i sl0
1 0.0 sun.2879 > netb.route: rip-poll 24
2 5.014702 (5.0147) sun.2879 > netb.route: rip-req 24
3 5.560427 (0.5457) netb.route > sun.2879: rip-resp 25:
4 5.710251 (0.1498) netb.route > sun.2879: rip-resp 12:

Еще один пример

Еще один пример

Сейчас мы рассмотрим все обновления RIP, которые происходят в сети Ethernet без получения запросов, и посмотрим, что RIP регулярно отправляет своим соседям. На рисунке 10.7 показаны сети в noao.edu. Для простоты маршрутизаторы названы как Rn, где n - номер подсети. Каналы точка-точка показаны с помощью пунктирных линий с указанием IP адресов для каждого конца канала.

Формат RIP сообщения.

Рисунок 10.3 Формат RIP сообщения.

Формат сообщения RIP2.

Рисунок 10.10 Формат сообщения RIP2.


В RIP-2 предоставляется простая схема аутентификации. Первые 20 байт в RIP сообщении содержащие семейство адресов, которое установлено в 0xffff, а поле route tag, установлено в значение 2. Оставшиеся 16 байт содержат пароль в открытом виде.
И в заключение, RIP-2 поддерживает групповые запросы в дополнение к широковещательным (глава 12). При этом уменьшается загрузка хостов, которые не принимают RIP-2 сообщения.

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

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

RIP сообщения передаются в UDP датаграммах, как показано на рисунке 10.2. (Мы рассмотрим UDP в главе 11.)

Инкапсуляция RIP сообщения в UDP датаграмму.

Рисунок 10.2 Инкапсуляция RIP сообщения в UDP датаграмму.


На рисунке 10.3 показан формат RIP сообщения, вместе с IP адресами.
Если поле команда равно 1 - это запрос, если 2 - отклик. Существуют еще две значения поля команды (3 и 4), а также два недокументированных значения: опрос (5) и пункт опроса (6). В запросе находится требование к другой системе послать всю или часть ее таблицы маршрутизации. В отклике содержится вся или часть таблицы маршрутизации отправителя.
Поле версия обычно установлено в 1, однако для RIP Version 2 (раздел "RIP Version 2") это значение устанавливается в 2.
Следующие 20 байт сдержат: семейство адресов (которое всегда равно 2 для IP адресов), IP адрес и соответствующий показатель. В следующих разделах мы увидим, что в роли показателя RIP выступает счетчик пересылок.
В RIP сообщении может быть объявлено до 25 маршрутизаторов. Ограничение в 25 определяется полным размером RIP сообщения, 20х25+4=504, меньше чем 512 байт. Из-за ограничения в 25 маршрутизаторов, на один запрос, как правило, требуется послать несколько откликов, чтобы передать всю таблицу маршрутизации.

Обычное функционирование

Обычное функционирование

Давайте посмотрим, как обычно работает routed с использованием RIP. Номер зарезервированного порта для RIP - UDP порт 520.

Инициализация. Когда демон стартует, он определяет все активизированные интерфейсы и посылает пакет с запросом на каждый интерфейс, с требованием к удаленным маршрутизаторам послать полные таблицы маршрутизации. В случае канала точка-точка этот запрос отправляется на другой конец канала. Запрос рассылается широковещательными сообщениями, если сеть их поддерживает. Порт назначения - UDP порт 520 (демон маршрутизации на другом маршрутизаторе). Характеристики подобного запроса следующие: поле команды установлено в 1, поле семейство адресов установлено в 0 и показатель установлен в 16. Подобный формат соответствует специальному запросу, в ответ на который требуется послать полную таблицу маршрутизации.

Запрос принят. В случае специального запроса, который мы только что описали, запрашивающему отправляется полная таблица маршрутизации. Иначе обрабатывается каждый пункт в запросе: если присутствует маршрут на указанный адрес, показатель устанавливается в определенное значение, иначе показатель устанавливается в 16. (Показатель, установленный в 16, это специальное значение, которое означает "бесконечно" (infinity) и сообщает, что маршрута к этому пункту назначения не существует.) Возвращается ответ.

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

Регулярное обновление маршрутизации. Каждые 30 секунд вся или часть таблицы маршрутизации отправляется каждому соседнему маршрутизатору. Таблица маршрутизации распространяется широковещательными сообщениями (в случае Ethernet) или отправляется на другой конец канала точка-точка.

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

С каждым маршрутом связан тайм-аут. Если система, использующая RIP, определила, что маршрут не был обновлен в течение трех минут, показатель маршрута устанавливается в состояние "бесконечно" (16) и помечается для удаления. Это означает, что было пропущено шесть 30-секундных обновлений от маршрутизатора, который объявил маршрут. Однако, удаление маршрута из локальной таблицы маршрутизации откладывается еще на 60 секунд, чтобы убедиться что маршрут действительно исчез.

OSPF: "открыть первым наикратчайший

OSPF: "открыть первым наикратчайший маршрут" (Open Shortest Path First)

OSPF это альтернативный RIP протокол внутренних маршрутизаторов. В OSPF сняты все ограничения, присущие для RIP. OSPF Version 2 описывается в RFC 1247 [Moy 1991].
OSPF - протокол состояния канала (link-state) , тогда как RIP - протокол вектора расстояний (distance-vector) . Термин вектор расстояний означает, что сообщения, посылаемые RIP, содержат вектор расстояний (счетчик пересылок). Каждый маршрутизатор обновляет свою таблицу маршрутизации на основании векторов расстояний, который он получает от своих соседей.
Когда используется протокол состояния канала, маршрутизатор не обменивается информацией о расстояниях со своими соседями. Вместо этого каждый маршрутизатор активно тестирует статус своих каналов к каждому соседнему маршрутизатору и посылает эту информацию другим своим соседям, которые могут направить поток данных в автономную систему. Каждый маршрутизатор принимает информацию о состоянии канала и уже на ее основании строит полную таблицу маршрутизации.
С практической точки зрения основное отличие заключается в том, что протокол состояния канала работает значительно быстрее, чем протокол вектора расстояний. Нужно отметить, что в случае протокола состояния канала значительно быстрее осуществляется сходимость сети. Под понятием сходимости (converge) мы подразумеваем стабилизацию сети после каких-либо изменений, как, например, поломки маршрутизатора или выхода из строя канала. В разделе 9.3 [Perlman 1992] сравниваются между собой два типа протоколов маршрутизации.
OSPF также отличается от RIP (как и многие другие протоколы маршрутизации) тем, что OSPF использует непосредственно IP. Это означает, что он не использует UDP или TCP. OSPF имеет собственную величину, которая устанавливается в поле протокола (protocol) в IP заголовке (рисунок 3.1).
К тому же, так как OSPF это протокол состояния канала, а не протокол вектора расстояний, он имеет и другие характеристики, которые делают его предпочтительным по отношению к RIP.

OSPF может рассчитать отдельный набор маршрутизаторов для каждого типа сервиса IP (type-of-service) (рисунок 3.2). Это означает, что для любого пункта назначения может быть несколько пунктов в таблице маршрутизации, по одному для каждого типа сервиса IP.

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

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

OSPF поддерживает подсети: маска подсети соответствует каждому объявленному маршруту. Это позволяет разбить IP адрес любого класса на несколько подсетей различного размера. (Мы показали это в примере в разделе "Пример подсети" главы 3 и назвали подсетями переменной длины.) Маршруты к хостам объявляются с маской подсети, из всех единичных бит. Маршрут по умолчанию объявляется как IP адрес 0.0.0.0 с маской из всех нулевых битов.

Каналы точка-точка между маршрутизаторами не имеют IP адресов на каждом конце. Это называется сетями без адреса (unnumbered). Такой подход позволяет сэкономить IP адреса - очень ценный ресурс в настоящее время!

Используется простая схема аутентификации. Может быть указан пароль в виде открытого текста, так же как это делается в схеме RIP-2 (раздел "RIP Version 2").

OSPF использует групповую адресацию (глава 12) вместо широковещательной, что уменьшает загруженность систем, которые не распознают OSPF.

Так как большинство поставщиков маршрутизаторов поддерживают OSPF, он начинает постепенно замещать собой RIP в большинстве сетей.

Показатели (metrics)

Показатели (metrics)

В качестве показателя в RIP используются счетчик пересылок. Для всех непосредственно подключенных интерфейсов счетчик пересылок равен 1. Рассмотрим маршрутизаторы и сети, показанные на рисунке 10.4. Четыре пунктирные линии показывают широковещательные сообщения RIP.

Пример

Пример

Мы воспользуемся программой ripquery, чтобы получить таблицы маршрутизации некоторых маршрутизаторов. ripquery отправляет один из недокументированных запросов (названный "опрос" (poll), при этом поле команда установливается в 5, рисунок 10.3) на маршрутизатор, требуя от него послать полную таблицу маршрутизации. Если ответ не получен в течении 5 секунд, посылается стандартный RIP запрос (поле команда установлено в 1). (Ранее мы говорили, что запрос с полем семейства протоколов установленным в 0 и с показателем установленным в 16 запрашивает полную таблицу маршрутизации маршрутизатора.)
На рисунке 10.5 показаны два маршрутизатора, у которых мы потребуем их таблицы маршрутизации на хосте sun. Мы запустим ripquery с sun, и получим информацию о маршрутизации с маршрутизатора следующей пересылки, netb:
sun % ripquery -n netb
504 bytes from netb (140.252.1.183): первое сообщение содержит 504 байта
тут удалено несколько строк
140.252.1.0, metric 1 верхний Ethernet на рисунке 10.5
140.252.13.0, metric 1 нижний Ethernet на рисунке 10.5
244 bytes from netb (140.252.1.183): второе сообщение с оставшимися 244 байтами
несколько строк удалено

Как мы и ожидали, netb объявляет нашу подсеть с показателем 1. Верхний Ethernet, к которому также подключен netb (140.252.1.0), имеет показатель равный 1. (Флаг -n говорит о необходимости выводить IP адреса в цифровом представлении, вместо того чтобы печатать имена хостов.) В этом примере netb сконфигурирован таким образом, чтобы считать все хосты, находящиеся в подсети 140.252.13, подключенными к нему напрямую - таким образом, netb ничего не знает о тех хостах, которые действительно находятся в подсети 140.252.13. Так как существует только одна точка подключения к подсети 140.252.13, объявление различных показателей для каждого хоста не имеет практического смысла.

Пример маршрутизаторов и сетей.

Рисунок 10.4 Пример маршрутизаторов и сетей.


Маршрутизатор R1 объявляет маршрут к N2 со счетчиком пересылок равным 1, послав широковещательное сообщение на N1. (Бессмысленно объявлять маршрут к N1 в широковещательном сообщении, посланном на N1.) Он также объявляет маршрут к N1 со счетчиком пересылок равным 1, послав широковещательное сообщение на N2. Точно так же, R2 объявляет маршрут к N2 с показателем 1 и маршрут к N3 с показателем 1.
Если смежный с нами маршрутизатор объявил маршрут к удаленной сети со счетчиком пересылок равным 1, то для нас показатель к этой сети будет равен 2, так пакет необходимо послать сначала на наш маршрутизатор, чтобы получить доступ к сети. В примере, приведенном выше, показатель к N1 для R2 равен 2, так же как и показатель к N3 для R1.
Так как каждый маршрутизатор посылает свои таблицы маршрутизации соседям, определяется каждая сеть в каждой автономной системе (AS). Если внутри AS существует несколько путей от маршрутизатора к сети, маршрутизатор выбирает путь с наименьшим количеством пересылок и игнорирует другие пути.
Величина счетчика пересылок ограничена значением 15, что означает, что RIP может быть использован только внутри AS, где максимальное количество пересылок между хостами составляет 15. Специальное значение показателя, равное 16, указывает на то, что на данный IP адрес не существует маршрута.

Проблемы

Проблемы

Как бы просто это ни звучало, все равно существуют проблемы. Во-первых, RIP не имеет представления о делении на подсети. Если обычный 16-битный идентификатор хоста в адресе класса В ненулевой, RIP не может определить, принадлежит ли ненулевая часть идентификатору подсети или IP адрес - это целиком адрес хоста. Некоторые реализации используют маску подсети того интерфейса, через который пришла RIP информация, однако такой способ не всегда корректен.
Во-вторых, для RIP требуется очень много времени, чтобы восстановить функционирование сети, после того как вышел из строя маршрутизатор или канал. Время обычно составляет несколько минут. В это время могут возникнуть петли маршрутизации. В современных реализациях RIP существует множество рекомендаций, которые позволяют избавляться от петель маршрутизации и увеличить скорость сходимости сетей. В RFC 1058 [Hedrick 1988a] подробно описано, как должен быть реализован RIP.
Использование количества пересылок в качестве показателя маршрутизации не позволяет использовать другие переменные, которые также должны приниматься во внимание при выборе маршрута. И в заключение, максимальное значение - 15 пересылок ограничивает размер сетей, в которых может быть использован RIP.

Протоколы маршрутизации, поддерживаемые routed и gated.

Рисунок 10.1 Протоколы маршрутизации, поддерживаемые routed и gated.

Мы опишем RIP Version 1 в следующем разделе, а отличия RIP Version 2, OSPF и BGP соответственно в разделах "RIP Version 2", "OSPF: открыть первым наикратчайший маршрут" и "BGP: протокол граничных маршрутизаторов" этой главы.

RIP ответ от gateway.

Рисунок 10.9 RIP ответ от gateway.

Выражение "BROADCAST" в выводе snoop на рисунке 10.8 для RIP пакета, посланного R10, означает, что IP адрес назначения это ограниченный широковещательный адрес 255.255.255.255 (глава 12, раздел "Широковещательные запросы"), а не широковещательный адрес, указывающий на подсеть (140.252.1.255), который используют другие маршрутизаторы.

RIP: протокол обмена информацией о маршрутизации

RIP: протокол обмена информацией о маршрутизации

В этом разделе приводится обзор RIP, так как это наиболее широко используемый протокол маршрутизации. Официальная спецификация протокола RIP находится в RFC 1058 [Hedrick 1988a], однако этот RFC был написан через несколько лет после того, как протокол получил широкое распространение.

RIP широковещательные сообщения

Рисунок 10.8 RIP широковещательные сообщения, пойманные на solaris за 60 секунд.

Благодаря флагу -P пакеты ловятся не перемешиваясь, благодаря -tr печатаются соответствующие временные марки, а благодаря port 520 захватываются только UDP датаграммы у которых в качестве порта источника или порта назначения указан порт 520.
Первые 6 пакетов приходят от R6, R4, R2, R7, R8 и R3, в каждом объявляется только одна сеть. Если мы заглянем внутрь пакетов, то увидим, что R6 объявляет маршрут к сети 140.252.6.0 со счетчиком пересылок равным 1, R4 объявляет маршрут к 140.252.4.0 со счетчиком пересылок равным 1, и так далее.
Маршрутизатор gateway, однако, объявил 15 маршрутизаторов. Мы можем запустить snoop с флагом -v и посмотреть содержимое RIP сообщения. (Этот флаг выдает полное содержимое входящего пакета: Ethernet заголовок, IP заголовок, UDP заголовок и RIP сообщение. Мы удалили всю информацию за исключением информации RIP.) На рисунке 10.9 показан вывод.
Сравните объявленные счетчики пересылок для сети 140.252.1 с топологией, приведенной на рисунке 10.7.
Очень странный факт заключается в том, что в выводе на рисунке 10.8 R10 объявляет четыре сети, тогда как на рисунке 10.7 показано только три. Если мы заглянем в RIP пакет с помощью snoop, то мы увидим следующие объявленные маршруты:
RIP: Address Metric
RIP: 140.251.0.0 16 (not reachable)
RIP: 140.252.9.0 1
RIP: 140.252.10.0 1
RIP: 140.252.11.0 1

Маршрут к сети класса В 140.251 фиктивный и не должен объявляться. Он не принадлежит к noao.edu.
solaris % snoop -P -v -tr udp port 520 host gateway
много строк удалено
RIP: Opcode = 2 (route response)
RIP: Version = 1

RIP: Address Metric

RIP: 140.252.101.0 1
RIP: 140.252.104.0 1

RIP: 140.252.51.0 2
RIP: 140.252.81.0 2
RIP: 140.252.105.0 2
RIP: 140.252.106.0 2

RIP: 140.252.52.0 3
RIP: 140.252.53.0 3
RIP: 140.252.54.0 3
RIP: 140.252.55.0 3
RIP: 140.252.58.0 3
RIP: 140.252.60.0 3
RIP: 140.252.82.0 3
RIP: 192.68.189.0 3

RIP: 140.252.57.0 4

RIP Version 2

RIP Version 2

RFC 1388 [Malkin 1993a] определяет новые расширения RIP, которые в целом обычно называются RIP-2. Эти расширения не изменяют протокол, однако добавляют дополнительную информацию в поля, помеченные как "должны быть равны нулю" (must be zero) на рисунке 10.3. RIP и RIP-2 могут взаимодействовать в том случае, если RIP игнорирует поля, которые должны быть установлены в ноль.
На рисунке 10.10 показан формат сообщения RIP-2. Для RIP-2 поле версии устанавливается в 2.
Домен маршрутизации - это идентификатор маршрутизирующего демона, которому принадлежит этот пакет. В реализациях Unix это должен быть идентификатор процесса демона. Это поле позволяет администратору запустить RIP на одном и том же маршрутизаторе несколько раз, причем каждый будет функционировать с одним доменом маршрутизации.
Поле метки маршрута предназначено для того, чтобы поддерживать протоколы внешних маршрутизаторов. Здесь хранится номер автономной системы для EGP и BGP.
Маска подсети для каждого пункта соответствует своему IP адресу. IP адрес следующей пересылки - это IP адрес пункта назначения, куда должны посылаться пакеты. Значение 0 в этом поле означает, что пакеты должны отправляться в систему, которая послала RIP сообщение.

Сети noao.edu 140.252.

Рисунок 10.7 Сети noao.edu 140.252.


Мы запустили на Solaris 2.x программу snoop, напоминающую программу tcpdump, которую мы запускали на компьютере solaris. Эту программу можно запустить без привилегии суперпользователя, однако только для того, чтобы перехватывать широковещательные пакеты, групповые пакеты или пакеты, посылаемые на хост. На рисунке 10.8 показаны пакеты, пойманные за 60 секунд. Мы заменили большинство официальных имен хостов на наше представление в форме Rn.
solaris % snoop -P -tr udp port 520
0.00000 R6.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
4.49708 R4.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
6.30506 R2.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
11.68317 R7.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
16.19790 R8.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
16.87131 R3.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
17.02187 gateway.tuc.noao.edu -> 140.252.1.255 RIP R (15 destinations)
20.68009 R10.tuc.noao.edu -> BROADCAST RIP R (4 destinations)

29.87848 R6.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
34.50209 R4.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
36.32385 R2.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
41.34565 R7.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
46.19257 R8.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
46.52199 R3.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
47.01870 gateway.tuc.noao.edu -> 140.252.1.255 RIP R (15 destinations)
50.66453 R10.tuc.noao.edu -> BROADCAST RIP R (4 destinations)

Вывод команды tcpdump при запуске программы ripquery.

Рисунок 10.6 Вывод команды tcpdump при запуске программы ripquery.

Первый отправляемый запрос - это команда опроса RIP (poll) (строка 1). В этом месте отрабатывается тайм-аут в 5 секунд, после чего отправляется обычный RIP запрос (строка 2). Число 24 в конце строк 1 и 2 это размер пакетов запроса в байтах: 4 байта RIP заголовок (с командой и версией), после чего следует один 20-байтовый адрес и показатель.
В строке 3 показан первый отклик, причем число 25 в конце строки указывает, что в сообщении находится 25 пар адресов и показателей, что, как мы рассчитали ранее, составляют 504 байта. Именно эту информацию выдает ripquery. Мы указали опцию -s600 для tcpdump, сообщая о необходимости прочитать из сети 600 байт. Это позволяет принять UDP датаграмму целиком (вместо того чтобы принять только ее первую часть) и затем напечатать содержимое RIP ответа.
В строке 4 показано второе ответное сообщение от маршрутизатора, со следующими 12-ю парами адресов и показателей. Мы можем рассчитать размер этого сообщения, который будет составлять 12х20+4=244, что как раз и печатала ripquery ранее.
Если мы обратимся к маршрутизатору, который находится позади netb, к gateway, то скорее всего получим, что показатель до нашей подсети 140.252.13.0 будет равен 2. Давайте проверим это предположение:
sun % ripquery -n gateway
504 bytes from gateway (140.252.1.4):
несколько строк удалено
140.252.1.0, metric 1 верхний Ethernet на рисунке 10.5
140.252.13.0, metric 2 нижний Ethernet на рисунке 10.5

Здесь показатель для верхнего Ethernet на рисунке 10.5 (140.252.1.0) остался равным 1, так как этот Ethernet непосредственно подключен и к gateway, и к netb, однако наша подсеть 140.252.13.0, как мы и ожидали, имеет показатель равный 2.

TCP-IP крупным планом

Фрагментация IP

Фрагментация IP

Как мы указали в разделе "MTU" главы 2, физический сетевой уровень обычно имеет ограничение максимального размера фрейма, который может быть передан. Когда IP уровень получает IP датаграмму, которую необходимо отправить, он определяет, на какой локальнй интерфейс отправляется датаграмма (или маршрутизируется), и запрашивает интерфейс, чтобы тот сообщил размер своего MTU. IP сравнивает MTU с размером датаграммы и, если необходимо, осуществляет фрагментацию. Фрагментация может быть осуществлена как на отправляющем хосте, так и на промежуточном маршрутизаторе.
Когда IP датаграмма фрагментирована, она не собирается вновь до тех пор, пока не достигнет конечного пункта назначения. (Для некоторых других сетевых протоколов процесс повторной сборки отличается от описанного выше, при этом повторная сборка осуществляется на маршрутизаторе следующей пересылки, а не в конечном пункте назначения.) На уровне IP сборка осуществляется в конечном пункте назначения. Это сделано для того, чтобы сделать фрагментацию и повторную сборку прозрачной для транспортных уровней (TCP и UDP), хотя это может вести к некоторой потере производительности. Существует вероятность, что фрагмент датаграммы будет снова фрагментирован (возможно даже несколько раз). Информации, которая содержится в IP заголовке вполне достаточно для фрагментации и повторной сборки.
Вернемся снова к IP заголовку (см. рисунок 3.1) и рассмотрим, какие поля используются в процессе фрагментации. Поле идентификации содержит значение уникальное для каждой отправленной IP датаграммы. Это значение копируется в каждый фрагмент конкретной датаграммы. В поле флагов один бит означает, что "дальше следуют еще фрагменты" (more fragments). Этот бит устанавливается в единицу для каждого фрагмента, кроме последнего. Поле смещения фрагмента (fragment offset) содержит смещение этого фрагмента от начала исходной датаграммы. Когда датаграмма фрагментируется, поле полной длины каждого фрагмента изменяется, так чтобы соответствовать размеру фрагмента.
И в заключение, один из битов в поле флагов называется "не фрагментировать" (don't fragment). Если этот бит установлен в единицу, IP не будет фрагментировать датаграмму. Вместо этого датаграмма уничтожается, а отправителю посылается ICMP ошибка "фрагментация необходима, однако установлен бит не фрагментировать" (fragmentation needed but don't fragment bit set). Мы рассмотрим эту ошибку более подробно в следующем разделе.
Когда IP датаграмма фрагментируется, каждый фрагмент становится пакетом, с собственным IP заголовком, и маршрутизируется независимо от других пакетов. Поэтому становится возможным, что датаграммы прибудет в конечный пункт назначения в другом порядке, нежели они были исходно отправлены и фрагментированы. Однако, в IP заголовке хранится достаточно информации для того, чтобы датаграмма была собрана корректно.
Несмотря на то, что процесс фрагментации IP выглядит довольно прозрачным, существует одна особенность, которая делает его не всегда желательным: если один фрагмент потерялся, датаграмма должна быть целиком повторно передана. Это объясняется тем, что IP не имеет тайм-аутов и не осуществляет повторной передачи - за это несут ответственность верхние уровни. (TCP осуществляет тайм-аут и повторную передачу, UDP - нет. Некоторые UDP приложения осуществляют тайм-аут и повторную передачу самостоятельно.) Когда потерялся фрагмент из TCP сегмента, TCP отработает тайм-аут и повторно передаст TCP сегмент целиком (IP датаграмма). Не существует способа повторно передать только один фрагмент датаграммы. И действительно, если фрагментация была осуществлена промежуточным маршрутизатором, а не отправляющей системой, отправляющая система не сможет знать как датаграмма была фрагментирована в процессе передачи. Именно по этой причине (всего одной) фрагментации стараются избежать. [Kent and Mogul 1987] приводят аргументы, которые доказывают необходимость избегать фрагментации.
С использованием UDP довольно легко добиться IP фрагментации. (Позже мы увидим, что TCP старается избежать фрагментации, и для приложения практически невозможно заставить TCP отправлять сегменты, которые нуждаются в фрагментации. То есть, другими словами, отправить сегмент такого размера, для которого потребуется фрагментация, практически невозможно.) Мы воспользуемся программой sock, чтобы увеличить размер датаграммы, с таким расчетом, чтобы была осуществлена фрагментация. Максимальный размер данных во фрейме Ethernet составляет 1500 байт (рисунок 2.1), при этом 1472 байта предназначены для пользовательских данных, 20 байт отводится под IP заголовок и 8 байт под UDP заголовок. Запустим программу sock с размером данных 1471, 1472, 1473 и 1474 байта. Мы ожидаем, что в двух последних случаях произойдет фрагментация:
bsdi % sock -u -i -n1 -w1471 svr4 discard
bsdi % sock -u -i -n1 -w1472 svr4 discard
bsdi % sock -u -i -n1 -w1473 svr4 discard
bsdi % sock -u -i -n1 -w1474 svr4 discard
На рисунке 11.7 показан соответствующий вывод команды tcpdump.
1 0.0 bsdi.1112 > svr4.discard: udp 1471
2 21.008303 (21.0083) bsdi.1114 > svr4.discard: udp 1472

3 50.449704 (29.4414) bsdi.1116 > svr4.discard: udp 1473 (frag 26304:1480@0+)
4 50.450040 ( 0.0003) bsdi > svr4: (frag 26304:1@1480)

5 75.328650 (24.8786) bsdi.1118 > svr4.discard: udp 1474 (frag 26313:1480@0+)
6 75.328982 ( 0.0003) bsdi > svr4: (frag 26313:2@1480)

ICMP ошибка о недоступности, когда

Рисунок 11.9 ICMP ошибка о недоступности, когда необходима фрагментация, однако установлен бит "не фрагментировать".


Если маршрутизатор не поддерживает этот новый формат ICMP ошибки, MTU следующей пересылки устанавливается в 0.
Новые требования к маршрутизаторам Router Requirements RFC [Almquist 1993] указывают на то, что маршрутизатор должен генерировать эту новую форму, когда выдает ICMP сообщение о недоступности.

ICMP ошибка подавления источника.

Рисунок 11.18 ICMP ошибка подавления источника.


На рисунке 11.19 показан вывод команды tcpdump, соответствующий этой команде.
1 0.0 bsdi.1403 > solaris.discard: udp 1024
26 строк не показано
27 0.10 (0.00) bsdi.1403 > solaris.discard: udp 1024
28 0.11 (0.01) sun > bsdi: icmp: source quench

29 0.11 (0.00) bsdi.1403 > solaris.discard: udp 1024
30 0.11 (0.00) sun > bsdi: icmp: source quench
142 строки не показано
173 0.71 (0.06) bsdi.1403 > solaris.discard: udp 1024
174 0.71 (0.00) sun > bsdi: icmp: source quench

ICMP ошибка подавления источника

ICMP ошибка подавления источника

Воспользовавшись UDP, можно сгенерировать ICMP ошибку "подавление источника" (source quench). Эта ошибка может быть сгенерирована системой (маршрутизатором или хостом), когда она принимает датаграммы быстрее, чем эти датаграммы могут быть обработаны. Обратите внимание на выражение "могут быть". Система не требует послать подавление источника, даже если буферы переполнены и датаграммы отбрасываются.
На рисунке 11.18 показан формат ICMP ошибки подавления источника. Мы имеем идеальную возможность сгенерировать подобную ошибку в нашей тестовой сети. Мы можем посылать датаграммы с bsdi на маршрутизатор sun по Ethernet, причем эти датаграммы должны быть смаршрутизированы через SLIP канал. Так как SLIP канал примерно в тысячу раз медленнее чем Ethernet, мы легко можем переполнить буфер. Следующая команда посылает 100 датаграмм размером 1024 байта с хоста bsdi через маршрутизатор sun на solaris. Мы отправляем датаграммы на стандартный discard сервис, где они будут игнорированы:
bsdi % sock -u -i -w1024 -n100 solaris discard

ICMP ошибки о недоступности (требуется фрагментация)

ICMP ошибки о недоступности (требуется фрагментация)

Необходимо обсудить еще одну ICMP ошибку о недоступности. Она генерируется, когда маршрутизатор принимает датаграмму, которую необходимо фрагментировать, однако в IP заголовке установлен флаг "не фрагментировать" (DF). Эта ошибка может быть использована программой, которой необходимо определить минимальный MTU в маршруте до пункта назначения - что называется механизмом определения транспортного MTU (path MTU discovery) (глава 2, раздел "Транспортный MTU").
На рисунке 11.9 показан формат ICMP ошибки о недоступности для данного случая. Он отличается от формата, приведенного на рисунке 6.10, потому что биты 16-31 во втором 32-битном слове могут содержать MTU следующей пересылки, вместо того чтобы быть установленными в 0.

ICMP подавление источника от маршрутизатора sun.

Рисунок 11.19 ICMP подавление источника от маршрутизатора sun.

Из этого вывода мы удалили множество строк. Первые 26 датаграмм приняты без ошибок: мы показали вывод только для первой. Начиная с 27-й датаграммы, каждый раз, когда отправляется датаграмма, мы получаем ошибку подавление источника. Всего было 26+(74х2)=174 строк вывода.
Из нашего расчета пропускной способности последовательной линии, приведенного в разделе "Вычисление загруженности последовательной линии" главы 2, видно, что на передачу датаграммы размером 1024 байта со скоростью 9600 бит/сек потребуется больше одной секунды. (В нашем примере для этого потребуется больше времени, так как датаграмма размером 20+8+1024 байт будет фрагментирована, потому что MTU SLIP канала от sun к netb составляет 552 байта.) Однако, из показателей времени, приведенных на рисунке 11.19, мы видим, что маршрутизатор sun получил все 100 датаграмм за время меньше чем одна секунда, перед тем как первая была отправлена в SLIP канал. При этом понятно, что мы использовали множество его буферов.
Несмотря на то, что RFC 1009 [Braden and Postel 1987] требует, чтобы маршрутизатор генерировал ошибки подавления источника, когда переполняются его буферы, новые требования к маршрутизаторам Router Requirements RFC [Almquist 1993] меняют это положение и говорят, что маршрутизатор не должен генерировать ошибки подавления источника.
Следующий момент, на который необходимо обратить внимание в примере, заключается в том, что программа sock никогда не получала уведомлений о том, что источник подавлен, или если и получала их, то игнорировала. Это говорит о том, что реализации BSD обычно игнорируют полученные сообщения о подавлении источника в случае использования протокола UDP. (В случае TCP, при получении уведомления передача данных по соединению, для которого сгенерировано подавление источника, замедляется. Мы это обсудим в разделе "ICMP ошибки" главы 21.) Проблема заключается в том, что процесс, который сгенерировал данные, которые, в свою очередь, вызвали подавление источника, может уже завершиться, когда будет принято сообщение о подавлении источника. И действительно, если мы используем программу time в Unix, чтобы оценить, как долго работает программа sock, то узнаем, что она проработала всего лишь около 0,5 секунды. Однако на рисунке 11.19 мы видели, что некоторые сообщения о подавлении источника были получены через 0,71 секунды после отправки первой датаграммы, то есть уже после того, как процесс прекратил работу. Что произойдет, если наша программа выдаст 100 датаграмм и завершится. Не все 100 датаграмм будут посланы - некоторые из них будут стоять в выходной очереди.
Этот пример доказывает, что UDP - ненадежный протокол и показывает важность контроля за потоком данных (flow control). Несмотря на то, что программа sock успешно выдала в сеть 100 датаграмм, только 26 достигли пункта назначения. Остальные 74 скорее всего были отброшены промежуточным маршрутизатором. Если приложение не поддерживает какую-либо форму уведомлений, отправитель не знает, принял ли получатель данные.

IP адрес клиента и номер порта

IP адрес клиента и номер порта

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

IP адрес назначения

IP адрес назначения

Некоторым приложениям необходимо знать, кому предназначена датаграмма, то есть IP адрес назначения. Например, требования к хостам Host Requirements RFC определяют, что TFTP сервер должен игнорировать принятые датаграммы, которые рассылаются на широковещательный адрес. (Мы опишем широковещательную адресацию в главе 12, а TFTP в главе 15.)
Это означает, что операционная система должна передать IP адрес назначения из принятой UDP датаграммы в приложение. К сожалению, не все реализации предоставляют эту возможность.
Сокеты API предоставляют эту возможность с использованием опции IP_RECVDSTADDR. Из систем, которые описываются в тексте, только BSD/386, 4.4BSD и AIX 3.2.2 поддерживают эту опцию. SVR4, SunOS 4.x и Solaris 2.x не поддерживают.

Контрольная сумма UDP

Контрольная сумма UDP

Контрольная сумма UDP охватывает UDP заголовок и UDP данные. Вспомним, что контрольная сумма в IP заголовке охватывает только IP заголовок - она не охватывает данные, находящиеся в IP датаграмме. И UDP, и TCP содержат контрольные суммы в своих заголовках, которые охватывают как заголовок, так и данные. Для UDP контрольная сумма необязательна, но для TCP она обязательна.
Контрольная сумма UDP рассчитывается точно так же, как (глава 3, раздел "IP заголовок") контрольная сумма IP заголовка (сумма 16-битных слов с переполнением), хотя существуют и отличия. Во-первых, UDP датаграмма может состоять из нечетного количества байт, тогда как при расчете контрольной суммы складываются 16-битные слова. При этом в конец датаграммы добавляются нулевые байты заполнения, если это необходимо для расчета контрольной суммы. (Байты заполнения не передаются.)
В UDP и TCP существуют 12-байтовые псевдозаголовки (в UDP датаграммах и TCP сегментах) только для расчета контрольной суммы. Псевдозаголовки содержат в себе определенные поля из IP заголовка. Все это сделано для двойной проверки того, что данные достигли того пункта назначения, которому предназначались (IP не принимает датаграммы, которые не адресованы для данного хоста, и не сможет передать UDP датаграммы, предназначенные для другого верхнего уровня). На рисунке 11.3 показан псевдозаголовок и UDP датаграмма.

Максимальный размер UDP датаграммы

Максимальный размер UDP датаграммы

Теоретически максимальный размер IP датаграммы может составлять 65535 байт, что ограничивается 16-битным полем полной длины в IP заголовке (см. рисунок 3.1). При длине IP заголовка равной 20 байтам и длине UDP заголовка равной 8 байтам в UDP датаграмме для пользовательских данных остается максимум 65507 байт. В большинстве реализаций, однако, используются датаграммы значительно меньшего размера.
Обычно играют роль два ограничения. Во-первых, программа приложение может быть ограничена программным интерфейсом. Сокеты API (глава 1, раздел "Интерфейсы прикладного программирования") предоставляют функцию, которая может быть вызвана приложением, чтобы установить размер буферов ввода и вывода. Для UDP сокета этот размер напрямую связан с максимальным размером UDP датаграммы, которая может быть прочитана и записана UDP. В настоящее время большинство систем предоставляют по умолчанию максимальный размер UDP датаграммы, которая может быть прочитана или записана, равный 8192 байтам. (Эта значение установлено в 8192, потому что именно столько по умолчанию читается и записывается системой NFS.)
Следующее ограничение определяется реализацией ядра TCP/IP. Могут существовать характеристики реализации (или ошибки), которые ограничивают размер UDP датаграммы значением меньшим, чем 65535 байт.
Автор экспериментировал с различными размерами UDP датаграмм, используя программу sock. С использованием loopback интерфейса под SunOS 4.1.3, максимальный размер UDP датаграммы был 32767 байт. Использовать большее значение не удавалось. При передаче по Ethernet от BSD/386 к SunOS 4.1.3, максимальный размер IP датаграммы, которую мог принять Sun, составлял 32786 (при этом пользовательских данных было 32758 байт). С использованием loopback интерфейса в Solaris 2.2 максимальный размер IP датаграммы, которая могла быть отправлена и принята, составлял 65535 байт. При передаче от Solaris 2.2 к AIX 3.2.2 удалось передать IP датаграмму максимального размера в 65535 байт.
В разделе "IP заголовок" главы 3 мы упомянули, что хосту необходимо получать IP датаграммы размером по меньшей мере 576 байт. Большинство приложений UDP разработаны таким образом, чтобы ограничивать свои приложения в размере 512 байт данных или меньше, чтобы уложиться в это ограничение. В разделе "RIP: протокол обмена информацией о маршрутизации" главы 10, например, мы видели, что RIP всегда посылает в датаграмме меньше чем 512 байт. Это же самое ограничение мы найдем и в других UDP приложениях: DNS (глава 14), TFTP (глава 15), BOOTP (глава 16) и SNMP (глава 25).

Мировой Internet

Мировой Internet

Модифицированная версия traceroute была запущена несколько раз на различные хосты по всему миру. С ее помощью было достигнуто 15 стран (включая Антарктику), при этом были использованы различные трансатлантические и транстихоокеанские каналы. Однако, до того как сделать это, мы увеличили MTU SLIP канала с дозвоном между нашей подсетью и маршрутизатором netb (рисунок 11.12) до 1500, как в Ethernet.
Из 18 раз, когда была запущена программа, только в двух случаях траспортный MTU был меньше чем 1500. Один трансатлантический канал имел MTU равный 572 (странное значение, которое даже не приведено в списке в RFC 1191), и маршрутизатор не вернул ICMP ошибку в новом формате. Еще один канал между двумя маршрутизаторами в Японии не обрабатывал фреймы размером 1500 байт, также маршрутизатор не вернул ICMP ошибку в новом формате. После того как MTU было уменьшено до 1006, все заработало.
Вывод, который мы можем сделать из этих экспериментов, заключается в том, что большинство (но не все) глобальных сетей в настоящее время могут обрабатывать пакеты больше чем 512 байт. Использование характеристики поиска транспортного MTU позволяет приложениям работать значительно продуктивнее, пользуясь большими MTU.

Множественный прием на порт

Множественный прием на порт

Несмотря на то, что это не описано в RFC, большинство реализаций позволяют только одному приложению в одно и то же время быть связанным с одним локальным адресом и номером UDP порта. Когда UDP датаграмма прибывает на хост назначения на свой IP адрес и номер порта, одна копия доставляется в единственную конечную точку. IP адрес конечной точки может быть представлен в виде символов подстановки, как было показано ранее.
Например, в SunOS 4.1.3 мы стартовали один сервер на порт 9999 с локальным IP адресом в виде символов подстановки:
sun % sock -u -s 9999
Если затем попробовать стартовать еще один сервер с тем же локальным адресом в виде символов подстановки и с тем же портом, это не сработает, даже если мы укажем опцию -A:
sun % sock -u -s 9999 так получиться не должно
can't bind local address: Address already in use

sun % sock -u -s -A 9999 поэтому мы указали флаг -A
can't bind local address: Address already in use

Для систем, которые поддерживают групповую адресацию (см. главу 12), все обстоит иначе. Несколько конечных точек могут использовать один и тот же локальный адрес и номер UDP порта, однако приложение должно сообщить API, что это допустимо (флаг -A использует опцию сокета SO_REUSEADDR).
4.4BSD, которая поддерживает групповую адресацию, требует, чтобы приложение установило другую опцию сокета (SO_REUSEPORT), чтобы позволить нескольким конечным точкам делить один и тот же порт. Более того, каждая конечная точка должна указать эту опцию, включая первую конечную точку, которая использует этот порт.
Когда UDP датаграмма прибывает на свой IP адрес назначения, который является широковещательным или групповым адресом, при этом с этим IP адресом и номером порта связано несколько конечных точек, копия входящей датаграммы направляется каждой конечной точке. (Локальный IP адрес конечной точки может быть указан в виде символов подстановки, при этом он совпадет с любым IP адресом назначения.) Однако, если у прибывшей IP датаграммы IP адрес назначения - персональный адрес, только одна копия датаграммы доставляется в одну конечную точку. Которая конечная точка получит датаграмму с персональным адресом, зависит от реализации.

Наблюдения за фрагментацией UDP датаграмм.

Рисунок 11.7 Наблюдения за фрагментацией UDP датаграмм.

Первые две UDP датаграммы (строки 1 и 2) помещаются в Ethernet фреймы и не фрагментируются. Однако, длина IP датаграммы, в которую необходимо записать 1473 байта данных, составляет 1501 байт, поэтому она должна быть фрагментирована (строка 3 и 4). Точно так же, длина датаграммы, в которую необходимо записать 1474 байта данных, будет составлять 1502 байта, и она также должна быть фрагментирована (строки 5 и 6).
Когда IP датаграмма фрагментирована, tcpdump выводит дополнительную информацию. Во-первых, выводится флаг frag 26304 (строки 3 и 4) и флаг frag 26313 (строки 5 и 6), который указывает на значение поля идентификации в IP заголовке.
Число 1480 в строке 3 (между двоеточием и символом @), это размер, за исключением IP заголовка. Первые фрагменты обеих датаграмм содержит 1480 байт данных: 8 байт UDP заголовока и 1472 байта пользовательских данных. (Если добавить 20 байт IP заголовка, получится точно размер пакета - 1500 байт.) Второй фрагмент первой датаграммы (строка 4) содержит 1 байт данных - оставшийся байт пользовательских данных. Второй фрагмент второй датаграммы (строка 6) содержит 2 оставшихся байта пользовательских данных.
При фрагментации требуется, чтобы порция данных генерируемых фрагментов (за исключением IP заголовока) была кратна 8 байтам для всех фрагментов за исключением последнего. В этом примере, число 1480 кратно восьми.
Число, следующее за символом @, это смещение данных во фрагменте от начала датаграммы. Первый фрагмент обеих датаграмм начинается с нуля (строки 3 и 5), а второй фрагмент обеих датаграмм начинается со смещения в 1480 байт (строки 4 и 6). Символ плюс, который следует за смещением и напечатан для первых фрагментов обеих датаграмм, означает, что в данной датаграмме присутствуют еще фрагменты. Знак плюс соответствует биту "дальше следуют еще фрагменты" (more fragments) в 3-битовом поле флагов IP заголовка. Назначение этого бита заключается в том, чтобы сообщить принимающему о том, что сборка всех фрагментов датаграммы полностью завершена.
И в завершение, обратите внимание на то, что в строках 4 и 6 (не первые фрагменты) не указан протокол (UDP), а также порты источника и назначения. Протокол должен быть напечатан, так как он находится в IP заголовке, который копируется в каждый фрагмент. А номера портов находятся в UDP заголовке, который присутствует только в первом фрагменте. На рисунке 11.8 показано, что произойдет с третьей датаграммой (которая содержит 1473 байта пользовательских данных). Здесь мы видим подтверждение того, что заголовок любого транспортного уровня присутствует только в первом фрагменте.
Хочется обратить внимание на терминологию: IP датаграмма (IP datagram) это блок, который передается от одного конца IP уровня к другому концу IP уровня (перед фрагментацией и после повторной сборки), тогда как пакет (packet) это блок данных, который передается между IP уровнем и канальным уровнем. Пакет может быть полной IP датаграммой или всего лишь фрагментом IP датаграммы.

Немного статистики

Немного статистики

[Mogul 1992] предоставляет некоторую статистическую информацию о появлении ошибок контрольных сумм на довольно загруженном NFS сервере, который работал в течение 40 дней. На рисунке 11.5 приведены статистические данные.

Уровень	Количество ошибок в контрольных суммах	Приблизительное количество пакетов
Ethernet	446	170.000.000
IP	14	170.000.000
UDP	5	140.000.000
TCP	350	30.000.000

Обмен пакетами для данного примера.

Рисунок 11.12 Обмен пакетами для данного примера.


И в завершение, отметим, что выражение mtu=0 в строках 3 и 6 на рисунке 11.11 указывает на то, что sun не возвращает MTU для исходящего интерфейса в ICMP сообщении о недоступности, как показано на рисунке 11.9. (В разделе "Дополнительные примеры" главы 25 мы решим эту проблему с использованием SNMP и убедимся в том, что MTU SLIP интерфейса netb равен 1500.)

Обмен пакетами при отправке по

Рисунок 11.17 Обмен пакетами при отправке по Ethernet UDP датаграммы размером 8192 байта.

Этот вывод достаточно неожидан. Во-первых, перед тем как получен первый ARP отклик, генерируются шесть ARP запросов. Как можно догадаться, IP быстро генерирует шесть фрагментов, и для каждого отправляется ARP запрос.
Затем, когда получен первый ARP отклик (строка 7), отправляется только последний фрагмент (строка 9)! Это означает, что первые пять фрагментов были отброшены. В действительности, это пример обычного функционирования ARP. Большинство реализаций держат только последний пакет, который должен быть отправлен на хост назначения, пока ожидается ARP отклик.
Требования к хостам Host Requirements RFC требуют от реализаций, чтобы они предотвращали лавинообразную рассылку ARP запросов (повторная отправка ARP запросов для одного и того же IP адреса с большой частотой). Рекомендуемая максимальная частота составляет один раз в секунду. Здесь мы видим шесть ARP запросов в течение 4,3 миллисекунды. Требования к хостам Host Requirements RFC требуют, чтобы ARP сохранил по крайней мере один пакет, и это должен быть самый последний пакет. Это как раз то, что мы видели здесь.
Следующая необъяснимая аномальность заключается в том, что svr4 отправил назад семь ARP откликов, а не шесть.
И последнее, про что хочется сказать, tcpdump работал еще 5 минут после того, как вернулся последний ARP отклик, ожидая увидеть, как svr4 пошлет назад ICMP ошибку "время истекло в течение повторной сборки" (time exceeded during reassembly). ICMP сообщение так и не появилось. (Мы показали формат этого сообщения на рисунке 8.2. Поле код, установленное в 1, указывает на то, что время истекло в течение повторной сборки датаграммы.)
IP уровень должен запустить таймер, когда появляется первый фрагмент датаграммы. Здесь "первый" означает первый из прибывших фрагментов для данной датаграммы, а не просто первый фрагмент (со смещением фрагмента равным 0). Обычное значение тайм-аута находится в диапазоне от 30 до 60 секунд. Если все фрагменты для этой датаграммы не прибыли за время до истечения таймера, все фрагменты отбрасываются. Если этого не сделать, фрагменты, которые уже никогда не прибудут (как мы видели в этом примере), могут вызвать переполнение приемного буфера.
Существуют две причины, по которым мы не увидели ICMP сообщение. Во-первых, большинство реализаций Berkeley никогда не генерируют эту ошибку! Эти реализации устанавливают таймер и отбрасывают все фрагменты, когда таймер истечет, однако ICMP ошибка не генерируется. Во-вторых, первый фрагмент - фрагмент со смещением равным 0, содержащий UDP заголовок, не был принят. (Это был первый из пяти пакетов, отброшенных ARP.) Реализация не требует генерировать ICMP ошибку, если первый фрагмент не был принят. Причина заключается в том, что приемник ICMP ошибки не может сказать, который пользовательский процесс отправил датаграмму, которая была отброшена, потому что недоступен заголовок транспортного уровня. А высший уровень (либо TCP приложение, либо UDP приложение) отработает тайм-аут и повторит передачу.
В этом разделе мы использовали IP фрагментацию, чтобы посмотреть, как осуществляется взаимодействие между UDP и ARP. Это взаимодействие можно увидеть, если отправитель быстро отправит несколько UDP датаграмм. Мы воспользовались фрагментацией, потому что пакеты быстро генерируются с помощью IP, что значительно быстрее, чем генерация нескольких пакетов пользовательским процессом.

Ограничение локального IP адреса

Ограничение локального IP адреса

Большинство UDP серверов используют символы подстановки для своих IP адресов, когда создают конечные точки UDP. Это означает, что входящая UDP датаграмма, направляющаяся на порт сервера, будет принята любым локальным интерфейсом. Например, мы можем стартовать UDP сервер на порте 7777:
sun % sock -u -s 7777
Затем мы воспользуемся командой netstat, чтобы посмотреть состояние этой конечной точки:

sun % netstat -a -n -f inet
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
udp 0 0 *.7777 *.*

В этом выводе мы удалили много строк и оставили только те, которые нам интересны. Флаг -a сообщает о всех конечных точках сети. Флаг -n печатает IP адреса в десятичном представлении, вместо того чтобы использовать DNS и конвертировать адреса в имена, а также печатает номера портов вместо имен сервисов. Опция -f inet сообщает только о точках TCP и UDP.
Локальный адрес напечатан как *.7777, где звездочка означает, что в качестве локального IP адреса может быть подставлен любой адрес.
Когда сервер создает свою конечную точку, он может указать один из локальных IP адресов хоста, включая один из его широковещательных адресов в качестве локального IP адреса конечной точки. При этом входящая UDP датаграмма будет передана на конечную точку только в том случае, если IP адрес назначения совпадет с указанным локальным адресом. С помощью программы sock можно указать IP адрес перед номером порта, и этот IP адрес становится локальным IP адресом для конечной точки. Например,
sun % sock -u -s 140.252.1.29 7777
из датаграмм, прибывающих на SLIP интерфейс, выбирает датаграммы с адресом 140.252.1.29. Вывод команды netstat будет выглядеть следующим образом:

Proto Recv-Q Send-Q Local Address Foreign Address (state)
udp 0 0 140.252.1.29.7777 *.*

Если мы постараемся послать на этот сервер датаграмму с хоста bsdi, адрес которого 140.252.13.35, по Ethernet, вернется ICMP ошибка о недоступности порта. Сервер никогда не увидит эту датаграмму. На рисунке 11.21 это показано более подробно.

1 0.0 bsdi.1723 > sun.7777: udp 13
2 0.000822 (0.0008) sun > bsdi: icmp: sun udp port 7777 unreachable

Ограничение внешних IP адресов

Ограничение внешних IP адресов

Во всех выводах команды netstat, которую мы показывали ранее, удаленные IP адреса и удаленные номера портов показаны как *.*. Это означает, что конечная точка воспримет входящие UDP датаграммы с любого IP адреса и любого номера порта. В большинстве реализаций конечным точкам UDP позволяется ограничивать удаленные адреса.
Другими словами, конечная точка может воспринимать только UDP датаграммы от указанного IP адреса и номера порта. Наша программа sock использует опцию -f, чтобы указать удаленный IP адрес и номер порта:
sun % sock -u -s -f 140.252.13.35.4444 5555
При этом удаленный IP адрес устанавливается в 140.252.13.35 (наш хост bsdi), а удаленный номер порта в 4444. Заранее-известный порт сервера 5555. Если мы запустим netstat, то увидим, что локальный IP адрес также установлен, даже если мы не указывали его непосредственно:

Proto Recv-Q Send-Q Local Address Foreign Address (state)
udp 0 0 140.252.13.33.5555 140.252.13.35.4444

Это побочный эффект указания удаленного IP адреса и удаленного номера порта в системах Berkeley: если локальный IP адрес не был выбран при установке удаленного адреса, локальный адрес выбирается автоматически. В качестве локального IP адреса устанавливается IP адрес интерфейса, который выбирается с помощью IP маршрутизации для достижения указанного удаленного IP адреса. И действительно, в этом примере IP адрес sun для Ethernet, который подключен к удаленному адресу, это 140.252.13.33.
На рисунке 11.22 приведены три типа адресов и портов, которые UDP сервер может установить для самого себя.

Локальный адрес	Удаленный адрес	Описание
localIP.lport	foreignIP.fport	ограничено одним клиентом
localIP.lport	*.*	ограничено датаграммами, прибывающими с одного локального интерфейса: localIP
*.lport	*.*	принимает все датаграммы, посланные на lport

Определение транспортного MTU при использовании UDP

Определение транспортного MTU при использовании UDP

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

Определение транспортного MTU с использованием UDP.

Рисунок 11.16 Определение транспортного MTU с использованием UDP.

И снова мы видим, что две первые датаграммы отправлены с установленным битом DF, на обе получены ICMP ошибки. Сейчас в ICMP ошибке указывается MTU следующей пересылки, который равен 296.
В строках 5, 6 и 7 мы видим, что хост источник осуществляет фрагментацию, как на рисунке 11.14. Если известен MTU следующей пересылки, генерируются только три фрагмента, по сравнению с четырьмя фрагментами, которые генерируются маршрутизатором bsdi на рисунке 11.15.

Определение транспортного MTU с использованием UDP.

Рисунок 11.14 Определение транспортного MTU с использованием UDP.

Так как ICMP сообщение "не могу фрагментировать" не содержит MTU следующей пересылки, это означает, что IP решил что всех устраивает MTU равный 576. Первый фрагмент (строка 5) содержит 544 байта UDP данных, 8 байт UDP заголовка и 20 байт IP заголовка, полный размер IP датаграммы составляет 572 байта. Второй фрагмент (строка 6) содержит оставшиеся 106 байт UDP данных и 20-байтный IP заголовок.
К сожалению, следующая датаграмма, строка 7, имеет установленный бит DF, поэтому она отбрасывается bsdi, после чего возвращается ICMP ошибка. Здесь произошло следующее: истек IP таймер, который сообщил IP о необходимости проверить, не увеличился ли транспортный MTU, путем повторной установки бита DF. Мы увидим, что это произойдет снова в строках 19 и 20. Сравнивая времена в строках 7 и 19, где DF бит устанавливается в единицу, мы видим, что проверка на увеличение транспортного MTU осуществляется каждые 30 секунд.
Этот 30-секундный таймер слишком мал. RFC 1191 рекомендует установить значение таймера в 10 минут. Величину таймера можно изменить с помощью параметра ip_ire_pathmtu_interval (приложение E, раздел "Solaris 2.2"). В Solaris 2.2 не существует способа выключить определение транспортного MTU для одного UDP приложения или для всех UDP приложений. Оно может быть включено или выключено только для всей системы в целом с помощью изменения параметра ip_path_mtu_discovery. Как мы видим из данного примера, включение характеристики определения транспортного MTU, когда UDP приложения отправляют датаграммы, которые, возможно, будут фрагментированы, приведет к тому, что датаграмма может быть отброшена.
Максимальный размер датаграммы, воспринимаемый IP уровнем на solaris (576 байт), неверен. На рисунке 11.13 мы видели, что реальный MTU составляет 296 байт. Это означает, что фрагменты, генерируемые solaris, снова фрагментируются на bsdi. На рисунке 11.15 показан вывод tcpdump, полученный на хосте назначения (slip) для первой прибывшей датаграммы (строки 5 и 6 на рисунке 11.14).
1 0.0 solaris.38196 > slip.discard: udp 650 (frag 47942:272@0+)
2 0.304513 (0.3045) solaris > slip: (frag 47942:272@272+)
3 0.334651 (0.0301) solaris > slip: (frag 47942:8@544+)
4 0.466642 (0.1320) solaris > slip: (frag 47942:106@552)

Определение транспортного MTU с использованием Traceroute

Определение транспортного MTU с использованием Traceroute

Так как большинство систем не поддерживают функцию определения транспортного MTU, мы доработаем программу traceroute (глава 8) так, чтобы она могла определять транспортный MTU. Мы отправим пакет с установленным битом "не фрагментировать" (don't fragment). Размер первого отправляемого пакета будет равен MTU исходящего интерфейса. Когда вернется ICMP ошибка "не могу фрагментировать" (can't fragment), мы уменьшим размер пакета. Если маршрутизатор, отправивший ICMP ошибку, поддерживает новую версию, которая включает MTU исходящего интерфейса в ICMP сообщение, мы используем полученное значение; иначе мы попробуем следующий меньший MTU. Как утверждает RFC 1191 [Mogul and Deering 1990], существует ограниченное количество значений MTU, наша программа имеет таблицу возможных значений и просто перейдет на следующее меньшее значение.
Попробуем подобный алгоритм с хоста sun на хост slip, зная, что SLIP канал имеет MTU равный 296:
sun % traceroute.pmtu slip
traceroute to slip (140.252.13.65), 30 hops max
outgoing MTU = 1500
1 bsdi (140.252.13.35) 15 ms 6 ms 6 ms
2 bsdi (140.252.13.35) 6 ms
fragmentation required and DF set, trying new MTU = 1492
fragmentation required and DF set, trying new MTU = 1006
fragmentation required and DF set, trying new MTU = 576
fragmentation required and DF set, trying new MTU = 552
fragmentation required and DF set, trying new MTU = 544
fragmentation required and DF set, trying new MTU = 512
fragmentation required and DF set, trying new MTU = 508
fragmentation required and DF set, trying new MTU = 296
2 slip (140.252.13.65) 377 ms 377 ms 377 ms

В этом примере маршрутизатор bsdi не вернул MTU исходящего интерфейса в ICMP сообщении, поэтому мы перейдем на следующее меньшее значение MTU. Первая строка вывода для TTL равного 2 сообщает имя хоста bsdi, однако это происходит из-за того, оно было возвращено маршрутизатором в ICMP ошибке. Последняя строка вывода для TTL равного 2 это как раз то, что мы ожидали.
Не составляет труда модифицировать ICMP код на bsdi, чтобы получить MTU исходящего интерфейса. И если мы сделаем это и вернемся к нашей программе, то получим следующий вывод:
sun % traceroute.pmtu slip
traceroute to slip (140.252.13.65), 30 hops max
outgoing MTU = 1500
1 bsdi (140.252.13.35) 53 ms 6 ms 6 ms
2 bsdi (140.252.13.35) 6 ms
fragmentation required and DF set, next hop MTU = 296
2 slip (140.252.13.65) 377 ms 378 ms 377 ms

Здесь нам нет смысла перебирать восемь различных значений MTU, маршрутизатор сообщил нужное значение.

Отказ обработки UDP датаграммы

Рисунок 11.21 Отказ обработки UDP датаграммы, вызванный несовпадением локального адреса сервера.

Существует возможность запустить другие сервера для этого же порта, каждый с собственным локальным IP адресом. Однако, приложение должно разрешить системе повторно использовать тот же самый номер порта.
Должна быть указана опция сокета в API SO_REUSEADDR. Это делается нашей программой sock с помощью опции -A.
На хосте sun мы можем стартовать пять различных серверов на одном и том же UDP порте (8888):

sun % sock -u -s 140.252.1.29 8888 для канала SLIP
sun % sock -u -s -A 140.252.13.33 8888 для Ethernet
sun % sock -u -s -A 127.0.0.1 8888 для loopback интерфейса
sun % sock -u -s -A 140.252.13.63 8888 для широковещательных запросов Ethernet
sun % sock -u -s -A 8888 для всего остального (метасимволы в IP адресе)

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

Proto Recv-Q Send-Q Local Address Foreign Address (state)
udp 0 0 *.8888 *.*
udp 0 0 140.252.13.63.8888 *.*
udp 0 0 127.0.0.1 8888 *.*
udp 0 0 140.252.13.33 8888 *.*
udp 0 0 140.252.1.29 8888 *.*

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

Первая датаграмма, прибывшая на хост slip от solaris.

Рисунок 11.15 Первая датаграмма, прибывшая на хост slip от solaris.

В этом примере хост solaris не должен фрагментировать исходящие датаграммы, однако должен выключить бит DF и позволить маршрутизатору с меньшим MTU осуществить фрагментацию.
Сейчас мы запустим тот же самый пример, однако изменим поведение маршрутизатора bsdi так, чтобы тот возвращал MTU следующей пересылки в ICMP сообщении "не могу фрагментировать". На рисунке 11.16 показаны первые шесть строк вывода tcpdump.
1 0.0 solaris.37974 > slip.discard: udp 650 (DF)
2 0.004199 (0.0042) bsdi > solaris: icmp:
slip unreachable - need to frag, mtu = 296 (DF)

3 4.950193 (4.9460) solaris.37974 > slip.discard: udp 650 (DF)
4 4.954325 (0.0041) bsdi > solaris: icmp:
slip unreachable - need to frag, mtu = 296 (DF)

5 9.779855 (4.8255) solaris.37974 > slip.discard: udp 650 (frag 35278:272@0+)
6 9.930018 (0.1502) solaris > slip: (frag 35278:272@272+)
7 9.990170 (0.0602) solaris > slip: (frag 35278:114@544)

Поля, используемые для расчета контрольной суммы UDP.

Рисунок 11.3 Поля, используемые для расчета контрольной суммы UDP.


На этом рисунке мы специально показали датаграмму с нечетной длиной, в этом случае требуется дополнительный байт для расчета контрольной суммы. Обратите внимание на то, что длина UDP датаграммы, при расчете контрольной суммы, появляется дважды.
Если рассчитанная контрольная сумма равна 0, она хранится как все единичные биты (65535), эти значения эквивалентны в арифметике с поразрядным дополнением (дополнение единицы) (ones-complement). Если переданная контрольная сумма равна 0, это означает, что отправитель не рассчитал контрольную сумму.
Если отправитель все же рассчитал контрольную сумму, а получатель определил наличие ошибки, UDP датаграмма молча уничтожается, сообщение об ошибке не генерируется. (То же самое происходит, если IP уровень обнаружил ошибку в контрольной сумме IP заголовка.)
Контрольная сумма UDP рассчитывается отправителем и проверяется получателем. Она позволяет определить любые изменения в UDP заголовке или данных, которые произошли на пути между отправителем и получателем.
Несмотря на то, что для контрольная сумма UDP - необязательный параметр, она должна рассчитываться всегда. В конце 1980-х годов некоторые производители компьютеров стали по умолчанию отключать расчет контрольной суммы UDP, чтобы увеличить скорость работы сетевой файловой системы (NFS - Network File System), которая использует UDP. Это может быть допустимым в одной локальной сети, где рассчитывается циклический избыточный код для фреймов на канальном уровне (фреймы Ethernet или Token ring), с помощью которого можно определить повреждение фрейма, когда датаграмма проходит через маршрутизаторы. Поверите Вы или нет, но существуют маршрутизаторы, у которых есть ошибки в программном или аппаратном обеспечении и которые изменяют биты в датаграммах, которые они маршрутизируют. Эти ошибки не могут быть выявлены в UDP датаграммах, если отключена опция контрольной суммы. Также необходимо отметить, что некоторые протоколы канального уровня (например, SLIP) не имеют каких-либо форм расчета контрольной суммы для данных в канале.
Требования к хостам Host Requirements RFC требуют, чтобы расчет контрольной суммы UDP был включен по умолчанию. Также они требуют, чтобы принятая контрольная сумма обязательно проверялась, если ее рассчитал отправитель (в том случае, если принятая контрольная сумма не нулевая). Некоторые реализации игнорируют это и проверяют принятую контрольную сумму в том случае, если включена опция расчета исходящей контрольной суммы.

Пример

Пример

Проблема, которую мы обсудим, возникла при получении ICMP ошибки при попытке определить MTU SLIP канала с дозвоном между маршрутизатором netb и хостом sun. Мы знаем MTU этого канала от sun к netb, так как, во-первых, это указывается при конфигурации SLIP на хосте sun, во-вторых, мы видели MTU при запуске команды netstat в разделе "Команда netstat" главы 3. А сейчас мы хотим определить MTU в другом направлении. (В главе 25 рассказывается как определить MTU с использованием SNMP.) Для каналов точка-точка нет необходимости, чтобы MTU был одним и тем же в обоих направлениях.
Для определения использована следующая техника. Мы запустили ping с хоста solaris на хост bsdi, увеличивая размер пакета данных до тех пор, пока к пакетам не была применена фрагментация. Процесс показан на рисунке 11.10.

Пример

Пример

Так как единственная система, которая поддерживает механизм определения транспортного MTU, это Solaris 2.x, мы используем ее как хост источник, чтобы отправить датаграмму размером 650 байт на slip. Так как хост slip находится позади SLIP канала с MTU равным 296, любая UDP датаграмма больше чем 268 байт (296 - 20 - 8) с установленным битом "не фрагментировать" должна вызвать ICMP ошибку "не могу фрагментировать" с маршрутизатора bsdi. На рисунке 11.13 показана топология и MTU каналов.

Пример UDP фрагментации.

Рисунок 11.8 Пример UDP фрагментации.

Простой пример

Простой пример

Мы воспользуемся программой sock, чтобы сгенерировать несколько UDP датаграмм, которые мы просмотрим с использованием tcpdump:
bsdi % sock -v -u -i -n4 svr4 discard
connected on 140.252.13.35.1108 to 140.252.13.34.9

bsdi % sock -v -u -i -n4 -w0 svr4 discard
connected on 140.252.13.35.1110 to 140.252.13.34.9
В первом случае запуска программы установлен отладочный режим (-v), при этом можно просмотреть номера динамически назначаемых портов, указан UDP (-u) вместо TCP по умолчанию и установлен режим источника, опция (-i) , это означает, что мы будем посылать данные, а не будем читать из стандартного ввода или писать в стандартный вывод. Опция -n4 сообщает о необходимости выдать 4 датаграммы (вместо того, чтобы выдавать по умолчанию 1024) на хост назначения svr4. Сервис discard описан в разделе "Стандартные простые сервисы" главы 1. Мы используем размер вывода по умолчанию в 1024 байта на одну запись.
Второй раз мы запустили программу, указав -w0, при этом будут выдаваться датаграммы нулевой длины. На рисунке 11.6 показан вывод команды tcpdump для двух примеров.
1 0.0 bsdi.1108 > svr4.discard: udp 1024
2 0.002424 ( 0.0024) bsdi.1108 > svr4.discard: udp 1024
3 0.006210 ( 0.0038) bsdi.1108 > svr4.discard: udp 1024
4 0.010276 ( 0.0041) bsdi.1108 > svr4.discard: udp 1024

5 41.720114 (41.7098) bsdi.1110 > svr4.discard: udp 0
6 41.721072 ( 0.0010) bsdi.1110 > svr4.discard: udp 0
7 41.722094 ( 0.0010) bsdi.1110 > svr4.discard: udp 0
8 41.723070 ( 0.0010) bsdi.1110 > svr4.discard: udp 0

Сервер UDP

Сервер UDP

Существует несколько особенностей использования UDP, которые отражаются на разработке и реализации сервера. Разработка и реализация клиентов обычно легче, чем реализация серверов. Именно поэтому здесь мы обсудим разработку сервера, а не разработку клиента. Серверы обычно взаимодействуют с операционной системой, и большинство серверов требуют, чтобы существовал какой-либо способ, позволяющий обработать запросы от нескольких клиентов одновременно.
Обычно когда клиент стартует, он сразу же устанавливает соединение с одним сервером. Сервера, с другой стороны, стартуют и затем "засыпают", ожидая прибытия запроса от клиента. В случае UDP, сервер "просыпается", когда прибывает датаграмма от клиента, эта датаграмма может содержать запрос в какой-либо форме.
Мы не будем рассматривать аспекты программирования клиентов и серверов ([Stevens 1990] описывает все более подробно), однако рассмотрим характеристики протокола UDP, которые оказывают влияние на разработку и реализацию сервера, использующего UDP. (Мы обсудим подробности TCP сервера в разделе "Реализация TCP сервера" главы 18.) Некоторые характеристики мы обсудим в зависимости от реализаций UDP, которые будут использоваться, а также рассмотрим характеристики, которые являются общими для большинства реализаций.

Системы, использованные для определения

Рисунок 11.13 Системы, использованные для определения транспортного MTU с использованием UDP.


Следующая команда генерирует десять UDP датаграмм размером 650 байт с интервалом в 5 секунд:
solaris % sock -u -i -n10 -w650 -p5 slip discard
На рисунке 11.14 показан вывод команды tcpdump. Когда этот пример был запущен, маршрутизатор bsdi был сконфигурирован таким образом, чтобы не возвращать MTU следующей пересылки как часть ICMP ошибки "не могу фрагментировать".
Первая посланная датаграмма с установленным битом DF (строка 1) генерирует ожидаемую ошибку от маршрутизатора bsdi (строка 2). Что интересно, следующая датаграмма, также посланная с установленным битом DF (строка 3), генерирует ту же самую ICMP ошибку (строка 4). Мы ожидали, что эта датаграмма будет послана с выключенным битом DF.
В строке 5 IP наконец понял, что датаграммы в этот пункт назначения не должны посылаться с установленным битом DF, после чего стал фрагментировать датаграммы на хосте источнике. Это поведение отличается от того, что было показано в ранних примерах, где IP отправлял датаграммы, которые он получал от UDP, и при этом маршрутизаторам с более маленькими MTU (bsdi в данном случае) позволялось осуществлять фрагментацию.
1 0.0 solaris.38196 > slip.discard: udp 650 (DF)
2 0.004218 (0.0042) bsdi > solaris: icmp:
slip unreachable - need to frag, mtu = 0 (DF)

3 4.980528 (4.9763) solaris.38196 > slip.discard: udp 650 (DF)
4 4.984503 (0.0040) bsdi > solaris: icmp:
slip unreachable - need to frag, mtu = 0 (DF)

5 9.870407 (4.8859) solaris.38196 > slip.discard: udp 650 (frag 47942:552@0+)
6 9.960056 (0.0896) solaris > slip: (frag 47942:106@552)

7 14.940338 (4.9803) solaris.38196 > slip.discard: udp 650 (DF)
8 14.944466 (0.0041) bsdi > solaris: icmp:
slip unreachable - need to frag, mtu = 0 (DF)

9 19.890015 (4.9455) solaris.38196 > slip.discard: udp 650 (frag 47944:552@0+)
10 19.950463 (0.0604) solaris > slip: (frag 47944:106@552)

11 24.870401 (4.9199) solaris.38196 > slip.discard: udp 650 (frag 47945:552@0+)
12 24.960038 (0.0896) solaris > slip: (frag 47945:106@552)

13 29.880182 (4.9201) solaris.38196 > slip.discard: udp 650 (frag 47946:552@0+)
14 29.940498 (0.0603) solaris > slip: (frag 47946:106@552)

15 34.860607 (4.9201) solaris.38196 > slip.discard: udp 650 (frag 47947:552@0+)
16 34.950051 (0.0894) solaris > slip: (frag 47947:106@552)

17 39.870216 (4.9202) solaris.38196 > slip.discard: udp 650 (frag 47948:552@0+)
18 39.930443 (0.0602) solaris > slip: (frag 47948:106@552)

19 44.940485 (5.0100) solaris.38196 > slip.discard: udp 650 (DF)
20 44.944432 (0.0039) bsdi > solaris: icmp:
slip unreachable - need to frag, mtu = 0 (DF)

Системы, которые были использованы

Рисунок 11.10 Системы, которые были использованы для определения MTU SLIP канала между netb и sun.


На хосте sun была запущена программа tcpdump, которая позволила посмотреть, как осуществляется фрагментация в SLIP канале. Фрагментация не появлялась и все было отлично до тех пор, пока размер данных в пакете ping не возрос от 500 байт до 600. Входящие эхо запросы были видны (как будто фрагментации не было), однако эхо отклики исчезли.
Чтобы лучше разобраться в происходящем, программа tcpdump также была запущена на bsdi, после чего стало видно, что отправляется и что принимается. На рисунке 11.11 показан вывод.
1 0.0 solaris > bsdi: icmp: echo request (DF)
2 0.000000 (0.0000) bsdi > solaris: icmp: echo reply (DF)
3 0.000000 (0.0000) sun > bsdi: icmp: solaris unreachable -
need to frag, mtu = 0 (DF)

4 0.738400 (0.7384) solaris > bsdi: icmp: echo request (DF)
5 0.748800 (0.0104) bsdi > solaris: icmp: echo reply (DF)
6 0.748800 (0.0000) sun > bsdi: icmp: solaris unreachable -
need to frag, mtu = 0 (DF)

Статистика поврежденных пакетов

Рисунок 11.5 Статистика поврежденных пакетов, определенных с использованием контрольных сумм.

В последней колонке приведено приблизительное количество пакетов, так как и другие протоколы используют Ethernet и IP уровень. Например, не все Ethernet фреймы используются IP датаграммами, ARP также использует Ethernet. Не все IP датаграммы используются UDP или TCP, так как ICMP также использует IP.
Обратите внимание на то, что выявлено значительно больше ошибок контрольных сумм TCP, чем UDP. Это скорее всего вызвано тем, что с помощью TCP обычно устанавливаются "дальние" соединения (которые проходят через много маршрутизаторов, мостов и так далее), тогда как UDP траффик обычно локальный.
Поэтому ошибки, приведенные в нижней строке, не всегда имеют отношение к канальному уровню (Ethernet, Token ring). При передаче данных следует всегда включать опцию контрольную сумму в оконечных точках. Однако, если передаваемые данные представляют определенную ценность, не стоит полностью доверять контрольным суммам UDP или TCP, так как это простые контрольные суммы, и они не гарантируют, что защитят данные от всех возможных ошибок.

UDP инкапсуляция.

Рисунок 11.1 UDP инкапсуляция.


Официальная спецификация UDP приведена в RFC 768 [Postel 1980].
UDP является ненадежным протоколом: он отправляет датаграммы, которые приложение пишет в IP уровень, однако не существует гарантии того, что они достигнут конечного пункта назначения. С точки зрения надежности может возникнуть предположение, что стоит избегать использовать UDP и всегда пользоваться надежными протоколами, такими как TCP. После того как TCP будет описан в главе 17, мы вернемся к этой теме и посмотрим, какие типы приложений могут использовать UDP.
Приложениям нет необходимости беспокоиться о размере получившейся в результате IP датаграммы. Если она по размеру больше, чем MTU для данной сети (см. главу 2, раздел "MTU"), IP датаграмма будет фрагментирована. Это применимо к каждой сети, через которую пройдет датаграмма по пути от источника до пункта назначения, кроме первой сети, к которой подключен посылающий хост. (Мы определили понятие транспортного MTU в разделе "Транспортный MTU" главы 2.) Более подробно IP фрагментация будет рассмотрена в разделе "Фрагментация IP" этой главы.

UDP заголовок.

Рисунок 11.2 UDP заголовок.


Номера портов (port numbers) указывают на отправляющий и принимающий процессы. На рисунке 1.8 показано, что TCP и UDP используют номер порта назначения для демультиплексирования данных, поступающих от IP. Так как IP осуществляет демультиплексирование входящих IP датаграмм для TCP и UDP (с использованием значения протокола в IP заголовке), TCP просматривает номера портов TCP, а UDP - номера портов UDP. Номера портов TCP независимы от номеров портов UDP.
Несмотря на подобную независимость, если зарезервированный сервис предоставляется обоими TCP и UDP, обычно выбирается один и тот же номер порта для обоих транспортных уровней. Это сделано для удобства, а не по требованию протоколов.
Поле длины UDP содержит длину в байтах UDP заголовка и UDP данных. Минимальное значение для этого поля составляет 8 байт. (Не произойдет ничего страшного, если будет отправлена UDP датаграмма с нулевой длиной данных.) Параметр UDP длины - избыточный. IP датаграмма содержит свою полную длину в байтах, поэтому длина UDP датаграммы это полная длина минус длина IP заголовка (которая указана в поле длины заголовка на рисунке 3.1).

UDP заголовок

UDP заголовок

На рисунке 11.2 показаны поля, присутствующие в UDP заголовке.

Указание локального и удаленного

Рисунок 11.22 Указание локального и удаленного IP адресов и номера порта для UDP сервера.

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

Усечение датаграмм

Усечение датаграмм

Из того что IP может отправлять и принимать датаграммы определенного размера, не следует, что принимающее приложение готово прочитать датаграммы этого размера. Программный интерфейс UDP позволяет приложениям указывать максимальное количество байт, которые будут обработаны за один раз. Что произойдет, если принятая датаграмма по размеру больше, чем датаграмма, которую готово принять приложение?
К сожалению, ответ зависит от программного интерфейса и реализации.
Традиционные версии Berkeley сокет API обрезают датаграммы, отбрасывая любые непоместившиеся данные. Будет ли приложение поставлено в известность, зависит от версии. (4.3 BSD Reno и более поздние версии могут уведомить приложение о том, что датаграмма была обрезана.) API сокеты под SVR4 (включая Solaris 2.x) не обрезают датаграммы. Любые непоместившиеся данные последовательно считываются. Приложение не уведомляется о нескольких циклах считывания и ему будет передана одна UDP датаграмма. TLI API не отбрасывают данные. Вместо этого возвращается флаг, указывающий на то, что данных больше, чем можно считать за один раз, поэтому приложение начинает последовательно считывать оставшуюся датаграмму.
Когда мы будем обсуждать TCP, то увидим, что этот протокол предоставляет последовательные потоки байт, направляемые в приложение, без каких-либо ограничений. TCP передает в приложение данные любого размера, которые требуются для приложения - причем данные на этом интерфейсе никогда не теряются.

Входная очередь UDP

Входная очередь UDP

В разделе "Модель клиент-сервер" главы 1 мы говорили, что большинство UDP серверов могут обслуживать все запросы к клиентам с использованием одного UDP порта (заранее известные порты серверов).
Обычно размер входной очереди, связанный с каждым UDP портом, который используется приложением, ограничен. Это означает, что запросы, которые прибывают в одно и то же время от различных клиентов, автоматически ставятся в очередь UDP. Принятые UDP датаграммы передаются приложению (когда оно требует следующую датаграмму) в том порядке, в каком они были приняты.
Однако существует вероятность, в случае если очередь переполнена, что модуль UDP в ядре отбросит входящие датаграммы. Мы можем пронаблюдать это с помощью следующего эксперимента. Стартуем нашу программу sock на хосте bsdi, запустив таким образом UDP сервер:
bsdi % sock -s -u -v -E -R256 -r256 -P30 6666
from 140.252.13.33, to 140.252.13.63: 1111111111 от sun на широковещательный адрес
from 140.252.13.34, to 140.252.13.35: 4444444444444 от svr4 на персональный адрес

Мы использовали следующие флаги : -s, запускает программу в роли сервера, -u для UDP, -v, печатает IP адрес клиента, и -E печатает IP адрес назначения (в данном случае система это позволяет). В дополнение, мы установили приемный буфер UDP для этого порта в 256 байт (-R), вместе с размером, который может быть прочитан каждым приложением (-r). Флаг -P30 сообщает о необходимости подождать 30 секунд после очистки UDP порта, перед считыванием первой датаграммы. Это дает нам время стартовать клиентов на двух других хостах, послать некоторые датаграммы и посмотреть, как работает очередь приема.
После того как сервер стартован и прошла 30-секундная пауза, мы стартуем одного клиента на хосте sun и посылаем три датаграммы:
sun % sock -u -v 140.252.13.63 6666 на широковещательный адрес Ethernet
connected on 140.252.13.33.1252 to 140.252.13.63.6666
1111111111 11 байт данных (с символом новой строки)
222222222 10 байт данных (с символом новой строки)
33333333333 12 байт данных (с символом новой строки)

Адрес назначения это широковещательный адрес (140.252.13.63). Затем мы стартовали еще одного клиента на хосте svr4 и послали еще три датаграммы:

svr4 % sock -u -v bsdi 6666
connected on 0.0.0.0.1042 to 140.252.13.35.6666
4444444444444 14 байт данных (с символом новой строки)
555555555555555 16 байт данных (с символом новой строки)
66666666 9 байт данных (с символом новой строки)

Первое, на что необходимо обратить внимание в интерактивном выводе, показанном ранее на bsdi, что только две датаграммы были приняты приложением: первая от sun, состоящая из всех единиц, и первая от svr4, состоящая из всех четверок. Остальные четыре датаграммы были отброшены.
Вывод команды tcpdump на рисунке 11.20 показывает, что все шесть датаграмм были доставлены к хосту назначения. Датаграммы прибыли от двух клиентов в обратном порядке: первая от sun, затем от svr4 и так далее. Также мы можем заметить, что все шесть были доставлены примерно за 12 секунд, в течение 30-секундного периода пока сервер "спал".

1 0.0 sun.1252 > 140.252.13.63.6666: udp 11
2 2.499184 (2.4992) svr4.1042 > bsdi.6666: udp 14
3 4.959166 (2.4600) sun.1252 > 140.252.13.63.6666: udp 10
4 7.607149 (2.6480) svr4.1042 > bsdi.6666: udp 16
5 10.079059 (2.4719) sun.1252 > 140.252.13.63.6666: udp 12
6 12.415943 (2.3369) svr4.1042 > bsdi.6666: udp 9

Вывод команды tcpdump для случая

Рисунок 11.6 Вывод команды tcpdump для случая, когда UDP датаграммы посылаются в одном направлении.

В выводе показаны четыре датаграммы размером 1024 байта, за которыми следуют четыре датаграммы нулевой длинны. Каждая датаграмма следует за предыдущей с интервалом в несколько миллисекунд. (Для того чтобы ввести вторую команду, потребовалась 41 секунда.)
До того как была отправлена первая датаграмма, соединения между отправителем и получателем не существовало. (В главе 17, где рассказывается о TCP, мы покажем, что перед тем как будет отправлен первый байт данных, должно быть установлено соединение.) Необходимо отметить, что получатель не выдает подтверждение, когда получает данные. Отправитель, в этом примере, не имеет представления о том, получены ли данные на удаленном конце.
И в завершение, обратите внимание, что номер порта источника UDP меняется каждый раз при запуске программы. Сначала порт был 1108, затем 1110. В разделе "Номера портов" главы 1 мы показали, что номера динамически назначаемых портов, используемых клиентами, обычно находятся в диапазоне от 1024 до 5000.

Вывод команды tcpdump

Вывод команды tcpdump

Довольно сложно определить, включена ли опция расчета контрольной суммы UDP на конкретной системе. Обычно приложение не имеет доступа к полю контрольной суммы принятого UDP заголовка. Чтобы решить эту проблему, автор добавил еще одну опцию к программе tcpdump, после чего та стала выдавать полученные контрольные суммы UDP. Если полученное значение равно 0, это означает, что отправитель не рассчитал контрольную сумму.
На рисунке 11.4 показан вывод к трем системам и от тех же трех различных систем в нашей сети. Мы запустили программу sock (приложение С), послав единственную UDP датаграмму с 9 байтами данных на стандартный эхо сервер.
1 0.0 sun.1900 > gemini.echo: udp 9 (UDP cksum=6e90)
2 0.303755 ( 0.3038) gemini.echo > sun.1900: udp 9 (UDP cksum=0)

3 17.392480 (17.0887) sun.1904 > aix.echo: udp 9 (UDP cksum=6e3b)
4 17.614371 ( 0.2219) aix.echo > sun.1904: udp 9 (UDP cksum=6e3b)

5 32.092454 (14.4781) sun.1907 > solaris.echo: udp 9 (UDP cksum=6e74)
6 32.314378 ( 0.2219) solaris.echo > sun.1907: udp 9 (UDP cksum=6e74)

Вывод программы tcpdump от ping

Рисунок 11.11 Вывод программы tcpdump от ping на bsdi от solaris с IP датаграммой размером в 600 байт.

Во-первых, выражение (DF) в каждой строке означает, что в единицу установлен бит "не фрагментировать" в IP заголовке. Это означает, что Solaris 2.2 нормально устанавливает этот бит в единицу, что является частью механизма определения транспортного MTU.
Строка 1 указывает, что эхо запрос проходит через маршрутизатор netb к sun без фрагментации и с установленным битом DF, поэтому можно сделать вывод, что критичный размер MTU для SLIP хоста netb еще не достигнут.
Также, заметьте из строки номер 2, что DF флаг копируется в каждый эхо отклик. Как раз это и вызвало проблему. Эхо отклик того же размера, что и эхо запрос (чуть больше 600 байт), однако MTU исходящего SLIP интерфейса хоста sun равен 552. Эхо отклик должен быть фрагментирован, однако установлен флаг DF. Это заставляет sun генерировать ICMP ошибку о недоступности и отправлять ее к bsdi (где она уничтожается).
Именно поэтому мы не видели эхо отклики от solaris. Отклики не проходили через sun. На рисунке 11.12 показан путь прохождения пакетов.

Вывод tcpdump для UDP датаграмм, посланных двумя клиентами.

Рисунок 11.20 Вывод tcpdump для UDP датаграмм, посланных двумя клиентами.

Также необходимо отметить, что c опцией -E сервер может узнать IP адрес назначения каждой датаграммы. Сервер может выбирать, что сделать с первой принятой датаграммой, которая была отправлена на широковещательный адрес.
В этом примере необходимо обратить внимание еще на некоторые особенности. Во-первых, приложение не сообщило, когда была переполнена входная очередь. Лишние датаграммы UDP просто отбросил. Также в выводе tcpdump мы видим, что ничего не было отправлено клиенту обратно, чтобы сообщить ему о том, что датаграммы были отброшены. Не было послано ничего похожего на ICMP сообщение подавления источника, абсолютно ничего. И в заключение, хочется отметить, что входная очередь UDP функционирует по принципу FIFO (первый вошел, первый вышел), тогда как, что мы видели в разделе "Взаимодействие между UDP и ARP" этой главы, входная очередь ARP - LIFO (последний зашел, первый вышел).

Вывод tcpdump, с помощью которого

Рисунок 11.4 Вывод tcpdump, с помощью которого можно определить, включена ли опция контрольной суммы UDP на конкретном хосте.

Отсюда мы видим, что у двух из трех систем опция контрольной суммы UDP включена.
Также обратите внимание на то, что исходящая датаграмма имеет такую же контрольную сумму, как и входящая датаграмма (строки 3 и 4, 5 и 6). На рисунке 11.3, можно заметить, что два IP адреса поменяны местами, так же, как и два номера порта. Другие поля в псевдозаголовке и заголовке UDP остались те же, так как данные были отражены эхом. Это подтверждает, что контрольная сумма UDP (а в действительности, и все контрольные суммы в семействе протоколов TCP/IP) это простая 16-битовая сумма. С ее помощью невозможно определить ошибку, которая заключается в перемене мест двух 16-битных значений.
Автор также направил DNS запрос на каждый из восьми корневых серверов DNS, описанных в разделе "Основы DNS" главы 14. DNS использует UDP, и только на двух из восьми была включена опция расчета контрольной суммы UDP!

Взаимодействие между UDP и ARP

Взаимодействие между UDP и ARP

Используя UDP, мы можем рассмотреть очень интересное взаимодействие между UDP и типичной реализацией ARP.
Мы используем программу sock, чтобы сгенерировать одну UDP датаграмму с 8192 байтами данных. Мы ожидаем, что в этом случае будет сгенерировано шесть Ethernet фрагментов (см. упражнение 3 главы 11). Также, перед запуском программы, мы убедимся в том, что ARP кэш пуст, поэтому перед тем как будет отправлен первый фрагмент, должен произойти обмен ARP запросом и откликом.
bsdi % arp -a проверяем, что ARP кэш пуст
bsdi % sock -u -i -n1 -w8192 svr4 discard

Мы ожидаем, что первая датаграмма вызовет отправку ARP запроса. Следующие пять фрагментов, которые генерируются IP, ставят перед нами два вопроса, на которые мы можем ответить, только воспользовавшись tcpdump: будут ли готовы к отправке оставшиеся фрагменты, перед тем как будет получен ARP отклик, если так, что будет делать ARP с этими несколькими пакетами направляемыми на конкретный пункт назначения, пока ожидается ARP отклик? На рисунке 11.17 показан вывод программы tcpdump.
1 0.0 arp who-has svr4 tell bsdi
2 0.001234 (0.0012) arp who-has svr4 tell bsdi
3 0.001941 (0.0007) arp who-has svr4 tell bsdi
4 0.002775 (0.0008) arp who-has svr4 tell bsdi
5 0.003495 (0.0007) arp who-has svr4 tell bsdi
6 0.004319 (0.0008) arp who-has svr4 tell bsdi
7 0.008772 (0.0045) arp reply svr4 is-at 0:0:c0:c2:9b:26
8 0.009911 (0.0011) arp reply svr4 is-at 0:0:c0:c2:9b:26
9 0.011127 (0.0012) bsdi > svr4: (frag 10863:800@7400)
10 0.011255 (0.0001) arp reply svr4 is-at 0:0:c0:c2:9b:26
11 0.012562 (0.0013) arp reply svr4 is-at 0:0:c0:c2:9b:26
12 0.013458 (0.0009) arp reply svr4 is-at 0:0:c0:c2:9b:26
13 0.014526 (0.0011) arp reply svr4 is-at 0:0:c0:c2:9b:26
14 0.015583 (0.0011) arp reply svr4 is-at 0:0:c0:c2:9b:26

TCP-IP крупным планом

Адреса групп

Адреса групп

На рисунке 12.2 показан формат IP адреса класса D.

Фильтрация, которая осуществляется

Рисунок 12.1 Фильтрация, которая осуществляется стеком протоколов, когда принимается фрейм.


В настоящее время большинство интерфейсов могут быть сконфигурированы таким образом, чтобы принимать фреймы, IP адрес которых является групповым адресом или групповым адресом какой-либо подгруппы. В групповом адресе Ethernet младший бит старшего байта установлен в единицу. В шестнадцатиричном представлении этот бит выглядит следующим образом: 01:00:00:00:00:00. (Мы можем считать, что широковещательный адрес Ethernet ff:ff:ff:ff:ff:ff это особый случай группового адреса Ethernet.)
Когда сетевая плата получает фрейм, она передает его в драйвер устройства. (Сетевая плата может отбросить фрейм только в том случае, если не сошлась контрольная сумма Ethernet.) Дополнительная фильтрация осуществляется драйвером устройства. Во-первых, тип фрейма должен принадлежать соответствующему протоколу (IP, ARP и так далее). Во-вторых, может быть осуществлена дополнительная групповая фильтрация, чтобы проверить, принадлежит ли хост к адресуемой группе.
Затем драйвер устройства передает фрейм следующему уровню, например, IP, если фрейм является IP датаграммой. IP также осуществляет фильтрацию, основанную на проверке IP адресов источника и назначения, и, в свою очередь, передает датаграмму следующему уровню (например TCP или UDP, если все в порядке).
Каждый раз когда UDP получает датаграмму от IP, он осуществляет фильтрацию, основанную на номере порта назначения, а иногда и на номере порта источника. Если указанный порт не обслуживается в текущий момент каким-либо процессом, датаграмма отбрасывается, и генерируется ICMP сообщение о недоступности порта. (TCP осуществляет подобную фильтрацию, основанную на своих номерах портов.) Если в UDP датаграмме обнаружена ошибка контрольной суммы, UDP молча ее отбрасывает.
Проблема широковещательных запросов заключается в том, что хосты, которые совсем не заинтересованы в получении этих запросов, должны их обрабатывать. Представьте себе приложение, которое должно обрабатывать широковещательные запросы UDP. Если на кабеле находится 50 хостов, но только из них 20 участвуют в работе этого приложения, в каждый момент времени один из 20 посылает широковещательный запрос UDP, при этом остальные 30 хостов должны обработать этот запрос, который проходит весь путь по стеку протоколов до UDP уровня, прежде чем датаграмма будет отброшена. UDP датаграмма отбрасывается этими 30-ю хостами, потому что порта назначения не обслуживается каким-либо процессом.
Основная задача групповых запросов - уменьшить загрузку хостов, не учавствующих в работе определенного приложения. Хост может принадлежать к одной или нескольким группам. Если это возможно, сетевая плата сообщает, к какой группе принадлежит хост, после чего сетевой платой принимаются только фреймы определенной группы.

Формат IP адреса класса D.

Рисунок 12.2 Формат IP адреса класса D.


В отличие от трех других классов IP адресов (A,B и C), форматы которых приведены на рисунке 1.5, 28 бит, отведенные под групповой идентификатор, не подвергаются дальнейшему делению.
Групповой адрес (multicast group address) состоит из четырех старших бит, установленных в 1110, и идентификатора группы. В десятичном виде групповые адреса находятся в диапазоне от 224.0.0.0 до 239.255.255.255.
Некоторое количество хостов, просматривающих определенный групповой IP адрес, называется группой хостов (host group). Группа хостов может объединять хосты в разных сетях. Членство в группе динамическое - хост может вступать в группу и выходить из группы по собственному желанию. Не существует ограничений на количество хостов в группе, и хост не должен принадлежать к группе, чтобы послать сообщение в эту группу.
Некоторые адреса групп назначаются как заранее известные адреса от IANA (Internet Assigned Numbers Authority). В этом случае группа считается постоянной группой хостов (permanent host group). Заранее известные групповые адреса приведены в последних RFC назначенных номеров (Assigned Numbers RFC). Обратите внимание на то, что постоянным в данном случае является групповой адрес, а не членство в группе.
Например, 224.0.0.1 означает "все системы в этой подсети", а 224.0.0.2 означает "все маршрутизаторы в этой подсети". Групповой адрес 224.0.1.1 предназначен для сетевого протокола времени (NTP - Network Time Protocol), 224.0.0.9 для RIP-2 (глава 10, раздел "RIP Version 2") и 224.0.1.2 для SGI (Silicon Graphics) dogfight приложений.

Ограниченный широковещательный запрос

Ограниченный широковещательный запрос

Ограниченный широковещательный адрес (limited broadcast address) - это адрес 255.255.255.255. Он может быть использован в качестве адреса назначения для IP датаграмм в процессе конфигурации хоста, когда хост может не знать собственной маски подсети и даже своего IP адреса.
Датаграмма, направляющаяся на ограниченный широковещательный адрес, никогда (ни при каких условиях) не будет перенаправлена маршрутизатором. Она может существовать только на локальном кабеле.
Но тут возникает вопрос, на который практически невозможно дать ответ: если хост имеет несколько интерфейсов и процесс посылает датаграмму с ограниченным широковещательным адресом, должна ли датаграмма быть отправлена на каждый подсоединенный интерфейс, который поддерживает широковещательную адресацию? Если нет, то приложение, которое хочет разослать широковещательный запрос на все интерфейсы, должно само определить все интерфейсы хоста, которые поддерживают широковещательную адресацию, и послать копию на каждый интерфейс.
Большинство BSD систем воспринимают 255.255.255.255 как адрес широковещательного адреса первого интерфейса, который был сконфигурирован, и не позволяют послать датаграмму на все подключенные интерфейсы, поддерживающие широковещательную адресацию. И действительно, два приложения, которые посылают UDP датаграммы на каждый интерфейс, это routed (глава 10, раздел "Демоны маршрутизации в Unix") и rwhod (сервер BSD клиента rwho). Оба этих приложения проходят через похожую процедуру запуска, чтобы определить все интерфейсы хоста и те, которые поддерживают широковещательную адресацию. Широковещательный адрес сети, соответствующий этому интерфейсу затем используется как адрес назначения для датаграмм, которые посылаются в этот интерфейс.
Требования к хостам Host Requirements RFC не определяют, должен ли хост, имеющий несколько интерфейсов, посылать ограниченный broadcast на все свои интерфейсы.

Преобразование групповых адресов в адреса Ethernet

Преобразование групповых адресов в адреса Ethernet

IANA владеет блоком Ethernet адресов, которые в шестнадцатиричном представлении выглядят как 00:00:5e. Это старшие 24 бита Ethernet адреса, означающие, что блок включает адреса в диапазоне от 00:00:5e:00:00:00 до 00:00:5e:ff:ff:ff. IANA отвела половину этого блока для групповых адресов. Установлено правило, что первый байт Ethernet адреса равный 01 указывает на групповой адрес. Это означает, что Ethernet адреса, соответствующие групповым адресам IP, должны находиться в диапазоне от 01:00:5e:00:00:00 до 01:00:5e:7f:ff:ff.
Приведенные здесь выражения используют стандартную последовательность битов для Internet, для сетей CSMA/CD или Token bus, а именно такую, как биты располагаются в памяти. Это как раз то, с чем сталкивается большинство программистов и системных администраторов. IEEE документация использует порядок бит, который используется при передаче. Assigned Numbers RFC предоставляет дополнительные подробности о различиях между этими представлениями.
Подобное расположение позволяет 23 битам в Ethernet адресе соответствовать идентификатору группы IP. В процессе преобразования адресов 23 младших бита идентификатора группы помещаются в 23 бита Ethernet адреса. (См. рисунок 12.3.)
Старшие 5 бит в идентификаторе группы игнорируются, так как они не уникальны. Каждому Ethernet адресу соответствует 32 различных идентификатора группы. Например, групповой адрес 224.128.64.32 (в шестнадцатиричном представлении e0.80.40.20) и 224.0.64.32 (в шестнадцатиричном представлении e0.00.40.20) оба будут трансформированы в Ethernet адрес 01:00:5e:00:40:20.
Так как подобное сопоставление не уникально, предполагается, что драйвер устройства или IP модуль на рисунке 12.1 должен осуществить фильтрацию, так как сетевая плата может получить групповой фрейм, который хосту не предназначен. Если сетевая плата не осуществляет адекватную фильтрацию групповых фреймов, драйвер устройства, вполне возможно, должен будет получать все групповые фреймы и сам осуществлять фильтрацию.

Примеры широковещательных запросов

Примеры широковещательных запросов

Как рассылаются широковещательные запросы и что делают маршрутизаторы и хосты с этими запросами? К сожалению, на этот вопрос очень сложно ответить, потому что это зависит от типа широковещательного адреса, приложения, реализации TCP/IP и возможной конфигурации.
Во-первых, приложение должно поддерживать широковещательные запросы. Если мы запустим
sun % ping 255.255.255.255
/usr/etc/ping: unknown host 255.255.255.255
то есть постараемся послать запрос на локальный кабель, это не сработает. Однако проблема здесь заключена в самом приложении (ping). Большинство приложений, которые воспринимают как цифровые IP адреса (в десятичном выражении), так и имена хостов, вызывают функцию inet_addr (3), чтобы конвертировать строку чисел в 32-битный двоичный IP адрес, и если это не удалось, воспринимают строку символов как имя хоста. Эта библиотечная функция возвращает код ошибки -1 если в строке обнаружен символ, отличный от цифры или десятичной точки, в случае ограниченного широковещательного адреса (255.255.255.255) также выдается код -1. Большинство программ, которые воспринимают символьную строку как имя хоста, обрабатывают его с использованием DNS (глава 14) и ограничиваются выводом ошибки, такой как "неизвестный хост" (unknown host).
Даже если мы исправим эту ошибку в программе ping, результаты будут все равно не такими как хотелось бы. Из шести протестированных систем, только одна генерировала широковещательные пакеты в локальный кабель. Большинство ищут IP адрес 255.255.255.255 в таблице маршрутизации, в конце концов находят маршрут по умолчанию и посылают персональный пакет на маршрутизатор по умолчанию. Естественно, такой пакет уничтожается.
В подобном случае необходимо использовать широковещательные запросы, направленные в подсеть. И действительно, в разделе "ICMP запрос и отклик маски адреса" главы 6 мы посылали датаграммы на IP адрес 140.252.13.63 для нижнего Ethernet в нашей тестовой сети и получали отклики от всех хостов Ethernet. Широковещательный адрес, направленный в подсеть, соответствует каждому интерфейсу, именно этот адрес используется командой ifconfig (глава 3, раздел "Команда ifconfig"). Если мы пошлем ping на этот адрес, результат будет таким, как мы хотели:
sun % arp -a ARP кэш пуст

sun % ping 140.252.13.63
PING 140.252.13.63: 56 data bytes
64 bytes from sun (140.252.13.33): icmp_seq=0. time=4. ms
64 bytes from bsdi (140.252.13.35): icmp_seq=0. time=172. ms
64 bytes from svr4 (140.252.13.34): icmp_seq=0. time=192. ms

64 bytes from sun (140.252.13.33): icmp_seq=1. time=1. ms
64 bytes from bsdi (140.252.13.35): icmp_seq=1. time=52. ms
64 bytes from svr4 (140.252.13.34): icmp_seq=1. time=90. ms

^? введен символ прерывани
----140.252.13.63 PING Statistics----
2 packets transmitted, 6 packets received, -200% packet loss
round-trip (ms) min/avg/max = 1/85/192

sun % arp -a снова проверяем ARP кэш
svr4 (140.252.13.34) at 0:0:c0:c2:9b:26
bsdi (140.252.13.35) at 0:0:c0:6f:2d:40

IP определяет, что адрес назначения (140.252.13.63) - это широковещательный адрес, направленный в подсеть, и посылает датаграммы на широковещательный адрес канального уровня.
Мы упоминали в разделе "ICMP запрос и отклик маски адреса" главы 6, что этот тип широковещательных запросов означает обращение ко всем хостам локальной сети, включая отправителя. Из примера видно, что мы получили отклик от отправляющего хоста sun и от всех остальных хостов, находящихся на кабеле.
В этом примере показан ARP кэш перед и после того, как был запущен ping на широковещательный адрес. Это сделано для того, чтобы показать взаимосвязь между рассылкой широковещательных запросов и состоянием ARP. ARP кэш пуст перед запуском ping, и заполнен по окончании. (В кэше находится по одной записи на каждый хост, находящийся на кабеле и ответивший на эхо запрос.) Как заполнился кэш, раз мы сказали, что Ethernet фрейм посылается на широковещательный адрес канального уровня 0xffffffff? Отправка этих фреймов хостом sun не требует ARP.
Если мы посмотрим работу ping с использованием tcpdump, то увидим, что получатели широковещательных фреймов генерируют ARP запрос на sun, перед тем как отправить отклик. Причем, надо отметить, что каждый отклик персональный. Мы говорили в разделе "Примеры ARP" главы 4, что получатель ARP запроса (sun в данном примере) обычно добавляет IP адрес и аппаратный адрес запрашивающего в свой ARP кэш, и отправляет ARP отклик. Это делается из предположения, что если запрашивающий послал нам пакет, мы, возможно, в будущем захотим послать что-нибудь и ему.
Использование ping - это особый случай, потому что подобный тип программного интерфейса, (который в большинстве Unix реализаций называется "символьный сокет" (raw socket)), всегда позволяет послать датаграмму на широковещательный адрес. Что если мы воспользуемся приложением, которое не поддерживает широковещательные запросы, как, например, TFTP? (Мы опишем TFTP более подробно в главе 15.)

bsdi % tftp запускаем клиента
tftp> connect 140.252.13.63 указываем IP адрес сервера
tftp> get temp.foo и пытаемся получить файл с сервера
tftp: sendto: Permission denied
tftp> quit прекращение работы клиента

Здесь мы получаем ошибку мгновенно, при этом в кабель ничего не посылается. Это объясняется тем, что сокеты API не позволяют процессу отправлять UDP датаграммы на широковещательный адрес, если процесс специально не заявил, что он планирует использовать широковещательные запросы. Это сделано для того, чтобы предотвратить ошибочное указание широковещательного адреса пользователем (именно так, как поступили мы в данном случае), тогда как приложение не предназначено для рассылки широковещательных запросов.
Для сокет API, приложение должно установить опцию сокет SO_BROADCAST перед отправкой UDP датаграммы на широковещательный адрес. Однако, не все системы применяют это ограничение. Некоторые реализации позволяют любому процессу отправлять UDP датаграммы широковещательным образом, причем не требуют от процесса, чтобы он объявлял об этом. Другие имеют более строгие ограничения и требуют, чтобы процесс имел привилегии суперпользователя, чтобы использовать широковещательную рассылку.
Следующий вопрос заключается в том, перенаправляются ли широковещательные пакеты. Некоторые ядра и маршрутизаторы имеют опцию, которая позволяет включить или выключить эту характеристику. (См. приложение Е.)
Если мы включим характеристику перенаправления широковещательных пакетов на маршрутизаторе bsdi и запустим ping с хоста slip, то увидим, что bsdi перенаправляет широковещательные запросы, направленные в подсеть. Перенаправление направленных широковещательных запросов означает, что маршрутизатор воспринимает входящие датаграммы как персональные, определяет, что адрес назначения это направленный широковещательный адрес одного из его интерфейсов, и затем перенаправляет датаграммы в соответствующую сеть, используя широковещательный адрес канального уровня.

slip % ping 140.252.13.63
PING 140.252.13.63 (140.252.13.63): 56 data bytes
64 bytes from 140.252.13.35: icmp_seq=0 ttl=255 time=190 ms
64 bytes from 140.252.13.33: icmp_seq=0 ttl=254 time=280 ms (DUP!)
64 bytes from 140.252.13.34: icmp_seq=0 ttl=254 time=360 ms (DUP!)

64 bytes from 140.252.13.35: icmp_seq=1 ttl=255 time=190 ms
64 bytes from 140.252.13.33: icmp_seq=1 ttl=254 time=270 ms (DUP!)
64 bytes from 140.252.13.34: icmp_seq=1 ttl=254 time=360 ms (DUP!)

^? введен символ прерывания
--- 140.252.13.63 ping statistics ---
3 packets transmitted, 2 packets received, +4 duplicates, 33% packet loss
round-trip min/avg/max = 180/273/360 ms

Мы видим, что это работает. Также мы видим, что программа ping в BSD проверяет отслеживает повторные номера последовательности и помечает их как DUP!. Это обычно означает, что пакет был каким-либо образом продублирован, однако здесь именно это и должно было произойти, так как запросы были отправлены на широковещательный адрес.
Этот тест можно запустить с более удаленного хоста (от той сети, к которой направляется широковещательный запрос). Мы запустили ping с хоста vangogh.cs.berkeley.edu (который находится на расстоянии 14 пересылок от нашей сети), и это также будет работать, если маршрутизатор sun сконфигурирован таким образом, чтобы перенаправлять направленные широковещательные запросы. В данном случае IP датаграммы (переносящие ICMP эхо запросы) перенаправляются каждым маршрутизатором, встречающимся им на пути, как обычные датаграммы. Никто из них не знает, что в действительности это направленные широковещательные запросы. И последний маршрутизатор, netb, думает, что пакеты предназначены хосту с идентификатором равным 63, и перенаправляет их на sun. В этом месте sun определяет, что IP адрес назначения в действительности это широковещательный адрес подключенного интерфейса, и передает датаграммы в виде широковещательных запросов канального уровня для этой сети.
Рассылка широковещательных запросов это характеристика, которую необходимо использовать с очень большой осторожностью. В большинстве случаев групповая адресация IP предоставляет лучшее решение практически всех проблем.

Рассылка групповых сообщений

Рассылка групповых сообщений

Рассылка групповых сообщений IP предоставляет приложениям два сервиса.

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

Запрос от клиента к серверу. Например, бездисковая рабочая станция старается определить положение сервера загрузки. В настоящее время это осуществляется с использованием широковещательных запросов (как мы увидим в случае с BOOTP в главе 16), однако решение с использованием групповых запросов может уменьшить загруженность хостов, которые не предоставляют этот сервис.

В этом разделе мы рассмотрим групповые адреса, а в следующей главе рассмотрим протоколы, которые используют групповую адресацию хостов и маршрутизаторов (IGMP).

Широковещательные запросы в сетях FDDI и Token Ring

Широковещательные запросы в сетях FDDI и Token Ring

Сети FDDI используют ту же схему преобразования между IP адресами класса D и 48-битными FDDI адресами [Katz 1990]. Сети Token ring обычно используют отличную систему сопоставления из-за ограничений, которые накладываются на большинство управляющих устройств Token ring [Pusateri 1993].

Широковещательные запросы

Широковещательные запросы

На рисунке 3.9 показаны четыре различные формы широковещательных адресов IP. Сейчас мы опишем их более подробно.

Широковещательный запрос, направленный во все подсети

Широковещательный запрос, направленный во все подсети

Широковещательный адрес всех подсетей (all-subnets-directed broadcast address), также требует знания маски подсети в сети назначения. Только в этом случае можно определить различие между широковещательным адресом всех подсетей и широковещательным адресом сети. И идентификатор подсети, и идентификатор хоста, в данном случае, устанавливаются в единицы. Например, если маска подсети назначения 255.255.255.0, то IP адрес 128.1.255.255 это широковещательный запрос, направленный во все подсети. Однако, если сеть не разбита на подсети, это широковещательный запрос, направляемый в сеть.
В настоящее время такой тип широковещательных запросов считается устаревшим [Almquist 1993]. В настоящее время используются групповые запросы, а не широковещательные запросы, направленные во все подсети.
[Almquist 1993] отмечает, что в RFC 922 требуется, чтобы широковещательные запросы, направленные во все подсети, посылались во все подсети, однако не все маршрутизаторы это поддерживают. И это хорошо, так как неверно сконфигурированый хост, без собственной маски подсети, будет посылать эти "локальные" широковещательные запросы во все подсети. Например, если хост с IP адресом 128.1.2.3 не имеет установленной маски подсети, его широковещательный адрес по умолчанию устанавливается в 128.1.255.255. Однако, если маска подсети должна быть определена как 255.255.255.0, то широковещательные запросы от неправильно сконфигурированного хоста появятся во всех подсетях.
Первая широкораспространенная реализация TCP/IP, в системе 4.2BSD (1983 год), использовала для широковещательных адресов идентификатор хоста, установленного во все нули. Один из самых ранних примеров обращения к широковещательным IP адресам это IEN 212 [Gurwitz and Hinden 1982], и именно здесь было определено использовать широковещательные IP адреса с идентификаторами хостов, установленными во все единицы. (IEN это Internet Experiment Notes, непосредственный предшественник RFC.) В RFC 894 [Hornig 1984] говорится, что 4.2BSD использует нестандартный широковещательный адрес, однако в RFC 906 [Finlayson 1984] замечается, что тогда не существовало стандарта Internet для широковещательных адресов. При редакции RFC была сделана сноска на RFC 906, где говорилось об отсутствии стандарта на широковещательные адреса, однако очень рекомендовалось использовать широковещательные адреса с идентификаторами хоста, установленными во все единицы. К тому же, Berkeley начал использовать все единичные биты для широковещательного адреса, начиная с 4.3BSD (1986 год), однако некоторые операционные системы (и что интересно, даже SunOS 4.x) продолжали использовать нестандартные широковещательные адреса до начала 90-х.

Широковещательный запрос в подсеть

Широковещательный запрос в подсеть

Широковещательный адрес подсети (subnet-directed broadcast address) имеет идентификатор хоста, установленный в единицы, однако определенный идентификатор подсети. Для того, чтобы классифицировать адрес как широковещательный адрес подсети, необходимо знать маску подсети. Например, если маршрутизатор получил датаграмму, с адресом назначения 128.1.2.255, можно считать, что это широковещательный запрос, направленный в подсеть, если сеть класса В 128.1 имеет маску подсети 255.255.255.0, однако это не широковещательный запрос, если маска подсети 255.255.254.0 (0xfffffe00).

Широковещательный запрос в сеть

Широковещательный запрос в сеть

В широковещательном адресе сети (net-directed broadcast) идентификатор хоста устанавливается во все единичные биты. Широковещательный адрес для сети класса А, имеет вид netid.255.255.255, где netid это идентификатор сети класса А.
Маршрутизаторы должны перенаправлять широковещательные запросы, направляемые в сеть, однако должна присутствовать опция, позволяющая отключить это перенаправление.

Соответствие между IP адресами

Рисунок 12.3 Соответствие между IP адресами класса D и групповыми адресами Ethernet.


Существует два варианта реализации групповой адресации в сетевых платах, использующиеся в локальных сетях. Одни осуществляют групповую фильтрацию, основанную на значении аппаратного группового адреса, что означает, что некоторые нежелательные фреймы могут пройти. В другом случае имеется небольшое фиксированное количество групповых адресов, принимаемых платой, при этом, если хосту необходимо принять больше групповых адресов, чем поддерживается, интерфейс должен быть помещен в режим "разных групп" (multicast promiscuous). Однако, оба типа интерфейсов все еще требуют, чтобы драйвер устройства осуществлял проверку на предмет того, необходимо ли дальше обрабатывать принятый фрейм. Даже если интерфейс осуществляет идеальную групповую фильтрацию (основанную на 48-битном аппаратном адресе) фильтрация все еще необходима, так как сопоставление IP адресов класса D и 48-битных аппаратных адресов осуществляется не один к одному. Однако, если абстрагироваться от несовершенства преобразования адресов и аппаратной фильтрации, групповая адресация все же лучше, чем широковещательная.
Осуществить групповой запрос в единственную физическую сеть довольно просто. Отправляющий процесс указывает IP адрес назначения, который является групповым адресом, драйвер устройства конвертирует это в соответствующий Ethernet адрес и отправляет. Принимающие процессы должены указать своим IP модулям, что они хочет получать датаграммы, предназначенные определенному групповому адресу, и драйвера устройств должен каким-либо образом получать эти групповые фреймы. Все это называется "вступлением в группу". (Причина, по которой мы использовали выражение "принимающие процессы" во множественном числе, объясняется тем, что обычно существует несколько получателей, которым предназначено групповое сообщение, либо на одном, либо на разных хостах.) Когда групповая датаграмма получена хостом, копия доставляется всем процессам, которые принадлежат к группе. Это отличается от UDP, где единственный процесс получает входящую персональную UDP датаграмму. Несколько процессов на одном хосте могут принадлежать к одной группе.
Однако сложности растут как снежный ком, когда группа распространяется на несколько сетей, и групповые пакеты должны проходить через маршрутизаторы. Маршрутизаторам необходимо знать, принадлежат ли какие-либо хосты в данной физической сети к определенной группе. Для определения этого, существует протокол, называемый протоколом группового управления Internet (IGMP - Internet Group Management Protocol). Этому протоколу полностью посвящена следующая глава.

Упражнения

Упражнения

Увеличивается ли сетевой траффик (загрузка сети) в случае широковещательных запросов?

Представьте 50 хостов в Ethernet: 20 запускают TCP/IP, а 30 используют какое-либо другое семейство протоколов. Как широковещательные запросы от одного семейства протоколов обрабатываются хостами, использующими другое семейство протоколов?

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

Если Вы запустили ping на широковещательный адрес с большим размером пакетов, как в примере: sun % ping 140.252.13.63 1472
PING 140.252.13.63: 1472 data bytes
1480 bytes from sun (140.252.13.33): icmp_seq=0. time=6. ms
1480 bytes from svr4 (140.252.13.34): icmp_seq=0. time=84. ms
1480 bytes from bsdi (140.252.13.35): icmp_seq=0. time=128. ms
это работает, однако увеличение размера пакета на 1 байт приведет к следующей ошибке:
sun % ping 140.252.13.63 1473
PING 140.252.13.63: 1473 data bytes
sendto: Message too long
Что произошло?

Повторите упражнение 6 главы 10, представив себе 8 RIP сообщений, направляемых с помощью групповой адресации вместо широковещательной (представьте, что используется RIP Version 2). Что изменится?

Назад
Компания | Услуги | Для клиентов | Библиотека | Галерея | Cофт | Линки
На главную

TCP-IP крупным планом

Детали реализации

Детали реализации

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

Формат полей IGMP сообщения.

Рисунок 13.2 Формат полей IGMP сообщения.


Поле версии IGMP (IGMP version) установлено в 1. Поле тип IGMP (IGMP type) устанавливается в 1 для запроса, посылаемого групповым маршрутизатором, и в 2 для ответа, отправляемого хостом. Контрольная сумма (checksum) рассчитывается так же, как контрольная сумма ICMP.
Групповой адрес (group address) это IP адрес класса D.. В запросе поле группового адреса устанавливается в 0. В отчете оно содержит групповой адрес. Мы расскажем более подробно об этом в следующих разделах, когда будем говорить о том, как функционирует IGMP.
Протокол IGMP
Вступление в группу
Фундаментальной концепцией для работы группы является то, что процесс вступает в группу с определенным интерфейсом хоста. (Мы используем термин процесс, который обозначает программу, которая запущена операционной системой.) Членство в группе динамическое - со временем процесс может как вступать, так и выходить из группы.
Естественно, процесс должен иметь возможность вступить в группу с указанным интерфейсом. Процесс также может покинуть группу, в которую он до этого вступил. Для вступления в группу и выхода из группы требуется, чтобы какой-либо API на хосте поддерживал групповую рассылку. Мы используем выражение "интерфейс", потому что членство в группе связано с интерфейсом. Процесс может вступить в одну и ту же группу с разных интерфейсов.
Релиз IP, поддерживающий групповую рассылку в Berkeley Unix Стэндфордского университета, детализирует эти изменения сокетов API. Эти изменения также присутствуют в Solaris 2.x и описаны в страницах помощи ip(7).
Поэтому идентификатор хоста в группе это адрес группы и интерфейс. Хост должен помнить таблицу всех групп, к которым принадлежит хотя бы один процесс, и счетчик обращений, то есть количество процессов, принадлежащих к группе.

Группа всех хостов (All-Hosts)

Группа всех хостов (All-Hosts)

На рисунке 13.3 мы видели, что IGMP запрос от маршрутизатора отправляется на IP адрес назначения 224.0.0.1. Этот адрес называется адресом группы всех хостов (all-hosts). Он имеет отношение ко всем хостам и маршрутизаторам подключенным к физической сети и поддерживающим групповую адресацию. Каждый хост автоматически вступает в эту группу со всеми интерфейсами, которые поддерживают групповую адресацию, при инициализации интерфейса. О членстве в этой группе никогда не сообщается (рассылкой отчетов).

IGMP отчеты и запросы.

Рисунок 13.3 IGMP отчеты и запросы.


Мы поговорим о поле TTL позже в этом разделе.

IGMP сообщение

IGMP сообщение

На рисунке 13.2 показан формат 8-байтового IGMP сообщения.

IGMP запросы и отчеты

IGMP запросы и отчеты

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

Хост отправляет первый IGMP отчет, когда первый процесс вступает в группу. Если несколько процессов на данном хосте вступили в одну и ту же группу, отправляется только один отчет, в тот момент, когда процесс первый раз вступил в группу. Отчет посылается на тот же интерфейс, с которым процесс вступил в группу.

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

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

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

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

Инкапсуляция IGMP сообщения в IP датаграмму.

Рисунок 13.1 Инкапсуляция IGMP сообщения в IP датаграмму.


На то, что в IP датаграмме находится IGMP сообщение, указывает величина в поле протокола равная 2.

Поле времени жизни

Поле времени жизни

На рисунке 13.3 мы видели, что поле TTL в отчете и запросе установлено в 1. Это напоминает обычное TTL поле в IP заголовке. Групповая датаграмма с TTL исходно равным 0 не "уйдет" дальше своего хоста. По умолчанию групповые датаграммы рассылаются с TTL равным 1. Это позволяет датаграммам распространяться только в своей подсети. Значение TTL больше единицы может быть установлено групповым маршрутизатором.
Обратитесь к разделу "Типы сообщений ICMP" главы 6, где говорится, что ICMP ошибка никогда не генерируется в ответ на датаграмму, направляемую на групповой адрес. Групповые маршрутизаторы не генерируют ICMP ошибку "время истекло" (time exceeded), когда значение TTL становится равным 0.
Обычно, пользовательский процесс не заботится о значении исходящего TTL. Одно исключение, пожалуй, программа Traceroute (см. главу 8), принцип работы которой основан как раз на изменении значения поля TTL. Однако, приложения, которые работают с групповой адресацией, должны иметь возможность установить исходящее поле TTL. Это означает, что программный интерфейс должен предоставлять эту возможность пользовательским процессам.
Путем увеличения TTL приложение может осуществить расширенный поиск (expanding ring search) конкретного сервера. В этом случае первая групповая датаграмма посылается с TTL равным 1, если ответ не получен, посылается датаграмма с TTL равным 2, затем 3 и так далее. В этом случае приложение определяет положение ближайшего сервера в количествах пересылок.
Специальный диапазон адресов 224.0.0.0 - 224.0.0.255 отводится для приложений, которые не будут рассылать групповые запросы дальше чем на одну пересылку. Групповые маршрутизаторы не должны перенаправлять датаграммы с такими адресами назначения, вне зависимости от TTL.

Пример

Пример

Сейчас, когда мы рассмотрели некоторые особенности групповой адресации IP, давайте посмотрим на то, как рассылаются сообщения. Мы добавили поддержку групповой адресации IP на хосте sun, а также воспользовались некоторыми тестовыми программами, которые присутствуют в программном обеспечении, работающем с групповой адресацией.
Во-первых, мы используем модифицированную версию команды netstat, которая сообщает о членстве в группах для каждого интерфейса. (Стандартный вывод netstat -ni для этого хоста приводится в разделе "Команда netstat" главы 3.) Ниже мы выделили строки, имеющие отношение к группам, жирным шрифтом:

sun % netstat -nia
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
le0 1500 140.252.13. 140.252.13.33 4370 0 4924 0 0
224.0.0.1
08:00:20:03:f6:42
01:00:5e:00:00:01
sl0 552 140.252.1 140.252.1.29 13587 0 15615 0 0
224.0.0.1
lo0 1536 127 127.0.0.1 1351 0 1351 0 0
224.0.0.1

Так как указана опция -n, IP адреса печатает в цифровом формате (а не в виде имен), -i печатает статистику по интерфейсам, и -a предоставляет отчет о всех сконфигурированных интерфейсах.
Вторая строка в выводе для le0 (Ethernet) сообщает о том, что этот интерфейс принадлежит к группе 224.0.0.1 (группа "все хосты"), а через одну строку показан соответствующий Ethernet адрес: 01:00:5e:00:00:01. Это как раз то, что мы и ожидали для Ethernet адреса. Подобное соответствие описано в разделе "Рассылка групповых сообщений" главы 12. Мы видим, что два других интерфейса, которые поддерживают рассылку групповых сообщений, канал SLIP - sl0 и loopback интерфейс lo0, также принадлежат к группе всех хостов.
Для маршрутизации групповых датаграмм используется обычная таблица маршрутизации. Пункты, помеченные жирным шрифтом, показывают все датаграммы для 224.0.0.0, отправлены в Ethernet:

sun % netstat -rn
Routing tables
Destination Gateway Flags Refcnt Use Interface
140.252.13.65 140.252.13.35 UGH 0 32 le0
127.0.0.1 127.0.0.1 UH 1 381 lo0
140.252.1.183 140.252.1.29 UH 0 6 sl0
default 140.252.1.183 UG 0 328 sl0
224.0.0.0 140.252.13.33 U 0 66 le0
140.252.13.32 140.252.13.33 U 8 5581 le0

Если Вы сравните эту таблицу маршрутизации с той, которую мы показали в разделе "Принципы маршрутизации" главы 9 для маршрутизатора sun, то увидите, что единственным отличием является запись для группы.
А сейчас запустим тестовую программу, которая позволит вступить в группу для определенного интерфейса. (Вывод этой тестовой программы не приводится.) Мы вступили в группу 224.1.2.3 с интерфейсом Ethernet (140.252.13.33). Исполнение netstat показывает, что ядро вступило в группу Ethernet адресом, как мы и ожидали. Отличия от предыдущего вывода команды netstat приведены жирным шрифтом:

sun % netstat -nia
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
le0 1500 140.252.13. 140.252.13.33 4374 0 4929 0 0
224.1.2.3
224.0.0.1
08:00:20:03:f6:42
01:00:5e:01:02:03
01:00:5e:00:00:01
sl0 552 140.252.1 140.252.1.29 13862 0 15943 0 0
224.0.0.1
lo0 1536 127 127.0.0.1 1360 0 1360 0 0
224.0.0.1

Здесь снова показан вывод для двух других интерфейсов, sl0 и lo0, из чего видно, что в группу вступил только один интерфейс.
На рисунке 13.4 показан вывод команды tcpdump, соответствующий процессу вступления в группу.

1 0.0 8:0:20:3:f6:42 1:0:5e:1:2:3 ip 60:
sun > 224.1.2.3: igmp report 224.1.2.3 [ttl 1]

2 6.94 (6.94) 8:0:20:3:f6:42 1:0:5e:1:2:3 ip 60:
sun > 224.1.2.3: igmp report 224.1.2.3 [ttl 1]

Пример работы группового маршрутизатора

Пример работы группового маршрутизатора

Давайте продолжим предыдущий пример, однако сейчас запустим демон групповой маршрутизации на хосте sun. В данном случае нас интересуют не детали реализации протоколов групповой маршрутизации, а то, как происходит обмен IGMP запросами и отчетами. Даже несмотря на то, что демон групповой маршрутизации запущен только на одном хосте, и только этот (единственный) хост поддерживает групповую адресацию (sun), групповые запросы и отчеты перемещаются по Ethernet.
Перед стартом демона маршрутизации мы вступили в другую группу: 224.9.9.9. На рисунке 13.5 показан вывод.

1 0.0 sun > 224.0.0.4: igmp report 224.0.0.4

2 0.00 ( 0.00) sun > 224.0.0.1: igmp query
3 5.10 ( 5.10) sun > 224.9.9.9: igmp report 224.9.9.9

4 5.22 ( 0.12) sun > 224.0.0.1: igmp query
5 7.90 ( 2.68) sun > 224.1.2.3: igmp report 224.1.2.3
6 8.50 ( 0.60) sun > 224.0.0.4: igmp report 224.0.0.4
7 11.70 ( 3.20) sun > 224.9.9.9: igmp report 224.9.9.9

8 125.51 (113.81) sun > 224.0.0.1: igmp query
9 125.70 ( 0.19) sun > 224.9.9.9: igmp report 224.9.9.9
10 128.50 ( 2.80) sun > 224.1.2.3: igmp report 224.1.2.3
11 129.10 ( 0.60) sun > 224.0.0.4: igmp report 224.0.0.4

12 247.82 (118.72) sun > 224.0.0.1: igmp query
13 248.09 ( 0.27) sun > 224.1.2.3: igmp report 224.1.2.3
14 248.69 ( 0.60) sun > 224.0.0.4: igmp report 224.0.0.4
15 255.29 ( 6.60) sun > 224.9.9.9: igmp report 224.9.9.9

Упражнения

Упражнения

Мы сказали, что хосты рассылают IGMP отчеты со случайными задержками. Как можно убедиться, что в локальной сети два хоста не генерируют отчет с одинаковой случайной задержкой?

В [Casner and Deering 1992] сказано, что UDP не имеет двух характеристик, необходимых для посылки звуковой информации по MBONE: определение изменения порядка движения пакетов и определение дублированных пакетов. Как Вы можете добавить эти возможности в UDP?

Назад
Компания | Услуги | Для клиентов | Библиотека | Галерея | Cофт | Линки
На главную

Вывод команды tcpdump при вступлении хоста в группу.

Рисунок 13.4 Вывод команды tcpdump при вступлении хоста в группу.

Строка 1 соответствует моменту, когда хост вступает в группу. Следующая строка - это задержанный отчет, который, как мы говорили, отправляется с некоторой случайной задержкой (до 10 секунд).
В этих двух строках показаны аппаратные адреса, чтобы убедиться в том, что адрес назначения Ethernet это корректный групповой адрес. Также стоит убедиться в том, что IP адрес источника это один из соответствующих адресов sun, а IP адрес назначения это групповой адрес. Адрес, сообщенный в отчете, - это тот же групповой адрес.
И в заключение, необходимо отметить, что значение TTL установлено в 1, как было указано ранее. Команда tcpdump печатает TTL в квадратных скобках, когда его значение равно 0 или 1. Это потому, что TTL обычно больше, чем эти значения. В случае групповой адресации мы ожидаем увидеть множество IP датаграмм с TTL равным 1.
Из этого вывода видно, что групповой маршрутизатор должен воспринимать все групповые датаграммы на всех своих интерфейсах. Маршрутизатор не имеет представления, в какую группу должен вступить хост.

Вывод команды tcpdump за время работы демона маршрутизации.

Рисунок 13.5 Вывод команды tcpdump за время работы демона маршрутизации.

Мы не включили Ethernet адреса в этот вывод, потому что уже убедились в том, что они именно такие, какие должны быть. Также мы удалили весь вывод, посвященный TTL равным 1, потому что они также соответствуют ожидаемым.
В строке 1 показан момент старта демона маршрутизации. Он отправляет отчет о том, что вступил в группу 224.0.0.4. Групповой адрес 224.0.0.4 - это заранее известный адрес и используется протоколом групповой маршрутизации вектора расстояний (DVMRP - Distance Vector Multicast Routing Protocol). Это протокол используется в настоящее время для групповой маршрутизации. (DVMRP описан в RFC 1075 [Waitzman, Partridge, and Deering 1988].)
При старте демон посылает запрос (строка 2). IP адрес назначения в запросе 224.0.0.1 (все хосты), как показано на рисунке 13.3.
Первый отчет (строка 3) приходит примерно через 5 секунд, для группы 224.9.9.9. Это единственный отчет, принятый перед тем, как был отправлен следующий запрос (строка 4). Два запроса (строки 2 и 4) отправляются с небольшим промежутком в момент старта демона, так как он пытается построить групповую таблицу маршрутизации.
В строках 5, 6 и 7 мы видим по одному отчету для каждой группы, к которой принадлежит хост sun. Обратите внимание, что принят отчет от группы 224.0.0.4, в дополнение к двум группам, в которые мы вступили, потому что в то время пока работает демон, он принадлежит к этой группе.
Следующий запрос в строке 8 появляется через 2 минуты после предыдущего запроса. В ответ на него также приходит три отчета (строки 9, 10 и 11). В этот раз отчеты приходят в другом порядке, так как время между приходом запроса и отправкой отчета выбирается случайным образом.
И последний запрос, отправляется примерно через 2 минуты после предыдущего запроса, и снова получены ожидаемые отклики.

TCP-IP крупным планом

3-Символьные общие домены.

Рисунок 14.2 3-символьные общие домены.

Иногда считается, что 3-символьные общие домены используются только организациями Соединенных Штатов, а 2-символьные домены стран всеми остальными, однако это не так. Существуют неамериканские организации в основных доменах, и множество организаций в Соединенных Штатах находятся в домене страны .us. (RFC 1480 [Cooper and Postel 1993] описывает домен .us более подробно.) Единственные общие домены, которые закреплены за Соединенными Штатами, это .gov и .mil.
Многие 2-символьные домены стран второго уровня, очень похожи на основные домены: .ac.uk, например, принадлежит академическим институтам, а .co.uk коммерческим организациям Великобритании.
Одна важная характеристика DNS, не показанная на рисунке 14.1, это передача ответственности внутри DNS. Не существует организации, которая бы управляла и обслуживала все дерево в целом и каждую метку в отдельности. Вместо этого, одна организация (NIC) обслуживает только часть дерева (домены верхнего уровня), а ответственность за определенные зоны передает другим организациям.
Зона (zone) это отдельно администрируемая часть дерева DNS. Например, домен второго уровня noao.edu это отдельная зона. Многие домены второго уровня поделены на меньшие зоны. Например, университет может поделить свою зону на подзоны по факультетам, а компания может поделить себя на зоны по принципу деления на филиалы или отделы.
Если Вы знакомы с файловой системой Unix, то обратите внимание, что деление дерева DNS на зоны очень напоминает деление на логические файловые системы физических дисковых разделов. Однако мы не можем сказать, основываясь на рисунке 14.1, под чьим руководством находятся зоны, также как мы не можем по подобному рисунку сказать, какие директории в файловой системе находятся в определенном дисковом разделе.
С того момента, как выбрана организация или персона, которая несет ответственность за управление зоной, эта организация или персона должна организовать несколько серверов DNS (name servers) для этой зоны. Как только в зоне появляется новая система, администратор этой зоны помещает имя и IP адрес нового хоста в базу данных сервера DNS. В небольших университетах, например, один человек может делать это каждый раз при появлении новой системы, однако в больших университетах ответственность должна быть распределена (например, по департаментам), так как один человек не может осуществлять эту работу в целом.
Сервер DNS, скажем, обслуживает одну зону или несколько зон. Человек, который несет ответственность за зону, администрирует основной сервер DNS (primary name server) для этой зоны и один или несколько вторичных серверов DNS (secondary name servers). Первичный и вторичный сервера должны быть независимы и избыточны таким образом, чтобы система DNS не вышла из строя при отказе одного из серверов.
Основное отличие между первичными и вторичными серверами заключается в том, что первичные загружают всю необходимую информацию из дисковых файлов, тогда как вторичные получают информацию от первичного. Процесс передачи информации от первичного сервера вторичному называется передачей зоны (zone transfer). Когда в зоне появляется новый хост, администратор добавляет соответствующую информацию (минимум, имя и IP адрес) в дисковый файл на первичном сервере. После чего первичный сервер DNS уведомляется о необходимости повторно считать свои конфигурационные файлы. Вторичные сервера регулярно опрашивают первичные (обычно каждые 3 часа), и если первичные содержат новую информацию, вторичный получает ее с использованием передачи зоны.
Что произойдет, если сервер DNS не содержит необходимой информации? Он должен установить контакт с другим сервером DNS. (В этом заключается распределенная природа DNS.) Однако не каждый сервер DNS знает, как обратиться к другому серверу. Вместо этого каждый сервер DNS должен знать, как установить контакт с корневыми серверами DNS (root name servers). В апреле 1993 года существовало восемь корневых серверов, все первичные сервера должны знать IP адреса каждого корневого сервера. (Эти IP адреса находятся в конфигурационных файлах первичного сервера. Первичные сервера должны знать именно IP адреса корневых серверов, а не их DNS имена.) Корневой сервер, в свою очередь, знает имена и положения (IP адрес) каждого официального сервера DNS для всех доменов второго уровня. При этом возникает последовательный процесс: запрашивающий сервер должен установить контакт с корневым сервером. Корневой сервер сообщает запрашивающему серверу о необходимости обратиться к другому серверу и так далее. Мы рассмотрим эту процедуру и соответствующие примеры позже в этой главе.
Вы можете получить текущий список корневых серверов, воспользовавшись анонимным (anonymous) FTP. Получите файл netinfo/root-servers.txt с ftp.rs.internic.net или nic.ddn.mil.
Фундаментальная характеристика DNS - это кэширование (caching). Когда DNS сервер получает информацию о соответствии (скажем, IP адресов именам хостов), он кэширует эту информацию таким образом, что в случае следующего запроса может быть использована информация из кэша, дополнительный запрос на другие сервера не делается. В разделе "Кэширование" этой главы мы рассмотрим кэширование более подробно.

Часть записи ресурса в отклике DNS

Часть записи ресурса в отклике DNS

Последние три поля в DNS сообщении это ответы (answers), полномочия (authority) и дополнительная информация (additional information), общий формат называется записью ресурса (RR - resource record). На рисунке 14.8 показан формат записи ресурса.

Еще один пример

Еще один пример

Давайте рассмотрим еще один пример, который описывает несколько функций DNS, о которых мы рассказали раньше. Мы запустили клиента Rlogin, подсоединившись к Rlogin серверу в каком-то удаленном домене. На рисунке 14.16 показан обмен пакетами.

Формат DNS отклика, соответствующий

Рисунок 14.11 Формат DNS отклика, соответствующий строке 2 на рисунке 14.10.


Мы указали только имя хоста (gemini), а не полное имя домена (FQDN) , однако клиент Telnet вывел именно полное имя домена. В данном случае клиент Telnet ищет имя, которое мы ввели, вызвав разборщик (gethostbyname), который возвращает IP адрес и FQDN. Затем Telnet выводит IP адрес, с которым он старается установить TCP соединение, и когда соединение установлено, печатает FQDN.
Пауза между вводом команды Telnet и печатью IP адреса, вызвана тем, что разборщик устанавливает контакт с DNS сервером, чтобы преобразовать имя в IP адрес. Пауза между выводом Trying и Connected to, вызвана установлением TCP соединения между клиентом и сервером, а не DNS.

Формат раздела вопроса (question) в запросе DNS.

Рисунок 14.5 Формат раздела вопроса (question) в запросе DNS.


(Дальше в этом разделе мы увидим, что байт счетчик с двумя старшими битами, установленными в 1, значения от 192 до 255, используется в схеме со сжатием.) В отличие от многих других форматов сообщений, которые мы рассмотрели, этому полю разрешено заканчиваться на ограничителе не равном 32 битам. Заполнение не используется.
На рисунке 14.6 показано, как хранится имя домена gemini.tuc.noao.edu.

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

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

Для DNS запроса и для DNS отклика используется одинаковый формат. На рисунке 14.3 показан общий формат DNS сообщения.

Формат записи ресурса DNS.

Рисунок 14.8 Формат записи ресурса DNS.


Имя домена (domain name) это имя, которому соответствуют следующие данные ресурса. Формат имени домена тот же, что мы описали ранее для поля имени запроса (query name) (рисунок 14.6).
Тип (type) указывает на один из типов кодов RR. Это то же самое, что и значения типа запроса (query type), которые мы описали раньше. Для данных Internet класс (class) обычно установлен в 1.
Поле время жизни (time-to-live) это количество секунд, в течение которых RR может быть кэширована клиентом. Обычно TTL RR равно 2 дням.
Длина записи ресурса (resource data length) указывает на количество данных ресурса (resource data). Формат этих данных зависит от типа (type). Для типа равного 1 (запись A) данные ресурса - это 4-байтный IP адрес. Сейчас мы описали основной формат DNS запросов и откликов.
Теперь посмотрим с использованием tcpdump, как они упаковываются в пакеты и как происходит обмен.

Иерархическая организация DNS.

Рисунок 14.1 Иерархическая организация DNS.


Каждый узел (кружочки на рисунке 14.1) имеет метку длиной до 63 символов. Корень дерева это специальный узел без метки. Метки могут содержать заглавные буквы или маленькие. Имя домена (domain name) для любого узла в дереве - это последовательность меток, которая начинается с узла выступающего в роли корня, при этом метки разделяются точками. (Здесь видно отличие от файловой системы Unix, где полный путь всегда начинается с вершины (корня) и опускается вниз по дереву.) Каждый узел дерева должен иметь уникальное имя домена, однако одинаковые метки могут быть использованы в различных точках дерева.
Имя домена, которое заканчивается точкой, называется абсолютным именем домена (absolute domain name) или полным именем домена (FQDN - fully qualified domain name). Например, sun.tuc.noao.edu.. Если имя домена не заканчивается на точку, подразумевается, что имя должно быть завершено. Как будет закончено имя, зависит от используемого программного обеспечения DNS. Если незаконченное имя состоит из двух или более меток, его можно воспринимать как законченное или полное; иначе справа от имени должен быть добавлен локальный суффикс. Например, имя sun может быть завершено локальным суффиксом .tuc.noao.edu..
Домены верхнего уровня поделены на три зоны:

arpa это специальный домен, используемый для сопоставления адрес - имя (раздел "Запросы указателя" этой главы).

Семь 3-символьных доменов называются общими (generic) доменами. В некоторых публикациях они называются организационными (organizational) доменами.

Все 2-символьные домены, основанные на кодах стран, можно найти в ISO 3166. Они называются доменами стран (country), или географическими (geographical) доменами.

На рисунке 14.2 приведен список обычной классификации семи основных доменов.

Домен	Описание
com	коммерческие организации
edu	учебные организации
gov	правительственные организации США
int	международные организации
mil	военные организации США
net	сети
org	другие организации

Кэширование

Кэширование

Чтобы уменьшить траффик DNS в Internet, все сервера DNS используют кэширование. В стандартных Unix реализациях кэш поддерживается сервером, а не разборщиком. Так как разборщик является частью каждого приложения, а приложения приходят и уходят, оставляя кэш в программах, которые живут все время, пока система работает (сервер DNS), имеет смысл поддерживать кэш именно на сервере. При этом кэш доступен любому приложению, которое использует сервер. Любые другие хосты в узле, которые используют этот сервер DNS, также пользуются кэшем сервера.
В примерах (рисунок 14.9), мы запускали клиентов на хосте sun, и обращались к DNS серверу на хост noao.edu через SLIP канал. Сейчас попробуем запустить DNS сервер на хосте sun. В этом случае, если просмотреть с использованием tcpdump траффик DNS в SLIP канале, мы увидим только запросы, которые не могут быть обработаны сервером в своем собственном кэше.
По умолчанию разборщик ищет сервер DNS на локальном хосте (UDP порт 53 или TCP порт 53). Мы удалили запись nameserver из файла разборщика, оставив только запись domain:
sun % cat /etc/resolv.conf
domain tuc.noao.edu
Отсутствие записи nameserver в этом файле приводит к тому, что разборщик пользуется сервером DNS на локальном хосте.
Затем мы запустили команду host следующим образом:

sun % host ftp.uu.net
ftp.uu.net A 192.48.96.9

На рисунке 14.14 показан вывод команды tcpdump для этого запроса.

1 0.0 sun.tuc.noao.edu.domain > NS.NIC.DDN.MIL.domain:
2 A? ftp.uu.net. (28)
2 0.559285 (0.5593) NS.NIC.DDN.MIL.domain > sun.tuc.noao.edu.domain:
2- 0/5/5 (229)

3 0.564449 (0.0052) sun.tuc.noao.edu.domain > ns.UU.NET.domain:
3+ A? ftp.uu.net. (28)
4 1.009476 (0.4450) ns.UU.NET.domain > sun.tuc.noao.edu.domain:
3* 1/0/0 A ftp.UU.NET (44)

Обмен пакетами при старте Rlogin клиента и сервера.

Рисунок 14.16 Обмен пакетами при старте Rlogin клиента и сервера.


Было осуществлено 11 шагов, при этом заранее никакой информации на клиенте или сервере кэшировано не было:

Клиент стартует и вызывает свою функцию разборщика, чтобы конвертировать имя хоста, которое мы ввели вместо IP адреса. Запрос типа A отправляется на корневой сервер.

Ответ от корневого сервера содержит DNS сервера для домена в котором находится Rlogin сервер.

Разборщик клиента повторно отправляет запрос типа A на DNS сервер. Этот запрос обычно имеет установленный флаг "рекурсия необходима".

Приходит отклик с IP адресом хоста.

Клиент Rlogin устанавливает TCP соединение с сервером Rlogin. (В главе 18 этот процесс описывается более подробно.) TCP модули клиента и сервера обмениваются друг с другом тремя пакетами.

Сервер Rlogin принимает соединение от клиента и вызывает свой разборщик, чтобы получить имя хоста клиента по IP адресу, который сервер получил от своего TCP. Это PTR запрос, выданный на корневой DNS сервер. Может быть, это не тот корневой сервер, к которому обратился клиент в шаге 1.

Отклик корневого сервера содержит имя DNS сервера домена in-addr.arpa клиента.

Разборщик сервера повторно отправляет PTR запрос к DNS серверу клиента.

PTR отклик содержит FQDN хоста клиента.

Разборщик сервера отправляет запрос типа A к DNS серверу клиента, спрашивая IP адрес, соответствующий имени, возвращенному в предыдущем шаге. Это может быть сделано автоматически с использованием функции сервера gethostbyaddr, как мы описали в разделе "Запросы указателя" этой главы, или сервер Rlogin осуществляет этот шаг самостоятельно. Также, DNS сервер клиента часто тот же самый, что и DNS сервер клиента in-addr.arpa, однако это необязательно.

Отклик от DNS сервера клиента содержит запись A для хоста клиента. Сервер Rlogin сравнивает запись A с IP адресом клиента, потребовавшего открыть TCP соединение.

Кэширование может уменьшить количество пакетов, которыми произошел обмен в этом примере.

Общий формат DNS запроса и ответа.

Рисунок 14.3 Общий формат DNS запроса и ответа.


Сообщение содержит фиксированный 12-байтный заголовок, за которым следуют четыре поля переменной длины.
Значение в поле идентификации (identification) устанавливается клиентом и возвращается сервером. Это поле позволяет клиенту определить, на какой запрос пришел отклик.
16-битовое поле флагов (flags) поделено на несколько частей, как показано на рисунке 14.4.

Основы DNS

Основы DNS

Пространство имен DNS имеет иерархическую структуру, которая внешне напоминает файловую систему Unix. На рисунке 14.1 показана иерархическая организация DNS.

Поле флагов (flags) в заголовке DNS.

Рисунок 14.4 Поле флагов (flags) в заголовке DNS.


Описание каждого поля мы начнем с крайне левых битов.

QR (тип сообщения), 1-битовое поле: 0 обозначает - запрос, 1 обозначает - отклик.

opcode (код операции), 4-битовое поле. Обычное значение 0 (стандартный запрос). Другие значения - это 1 (инверсный запрос) и 2 (запрос статуса сервера).

AA - 1-битовый флаг, который означает "авторитетный ответ" (authoritative answer). Сервер DNS имеет полномочия для этого домена в разделе вопросов.

TC - 1-битовое поле, которое означает "обрезано" (truncated). В случае UDP это означает, что полный размер отклика превысил 512 байт, однако были возвращены только первые 512 байт отклика.

RD - 1-битовое поле, которое означает "требуется рекурсия" (recursion desired). Бит может быть установлен в запросе и затем возвращен в отклике. Этот флаг требует от DNS сервера обработать этот запрос самому (т.е. сервер должен сам определить требуемый IP адрес, а не возвращать адрес другого DNS сервера), что называется рекурсивным запросом (recursive query). Если этот бит не установлен и запрашиваемый сервер DNS не имеет авторитетного ответа, запрашиваемый сервер возвратит список других серверов DNS, к которым необходимо обратиться, чтобы получить ответ. Это называется повторяющимся запросом (iterative query) . Мы рассмотрим примеры обоих типов запросов в следующих примерах.

RA - 1-битовое поле, которое означает "рекурсия возможна" (recursion available). Этот бит устанавливается в 1 в отклике, если сервер поддерживает рекурсию. Мы увидим в наших примерах, что большинство серверов DNS поддерживают рекурсию, за исключением нескольких корневых серверов (коневые сервера не в состоянии обрабатывать рекурсивные запросы из-за своей загруженности).

Это 3-битовое поле должно быть равно 0.

rcode это 4-битовое поле кода возврата. Обычные значения: 0 (нет ошибок) и 3 (ошибка имени). Ошибка имени возвращается только от полномочного сервера DNS и означает, что имя домена, указанного в запросе, не существует.

Следующие четыре 16-битных поля указывают на количество пунктов в четырех полях переменной длины, которые завершают запись. В запросе количество вопросов (number of questions) обычно равно 1, а остальные три счетчика равны 0. В отклике количество ответов (number of answers) по меньшей мере равно 1, а оставшиеся два счетчика могут быть как нулевыми, так и ненулевыми.

Представление имени домена gemini.tuc.noao.edu.

Рисунок 14.6 Представление имени домена gemini.tuc.noao.edu.


У каждого вопроса есть тип запроса (query type), а каждый отклик (называемый записью ресурса, о чем мы поговорим ниже) имеет тип (type). Существует около 20 различных значений, некоторые из которых в настоящее время уже устарели. На рисунке 14.7 показаны некоторые из этих значений. Тип запроса это надмножество (множество, подмножеством которого является данное множество) типов: два из показанных значений, могут быть использованы только в вопросах.

Имя	Цифровое значение	Описание	тип (type)?	тип запроса (query type)?
A	1	IP адрес	·	·
NS	2	сервер DNS	·	·
CNAME	5	каноническое имя	·	·
PTR	12	запись указателя	·	·
HINFO	13	информация о хосте	·	·
MX	15	запись об обмене почтой	·	·
AXFR	252	запрос на передачу зоны		·
* или ANY	255	запрос всех записей		·

Пример

Пример

Давайте воспользуемся программой host, чтобы осуществить поиск указателя, и при этом просмотрим с использованием tcpdump как происходит обмен пакетами. Мы используем те же начальные установки как на рисунке 14.9, запустив программу host на хосте sun с тем же самым сервером DNS noao.edu. Мы указали IP адрес нашего хоста svr4:
sun % host 140.252.13.34
Name: svr4.tuc.noao.edu
Address: 140.252.13.34
Так как единственный аргумент в командной строке это IP адрес, программа host автоматически генерирует запрос указателя. На рисунке 14.12 показан вывод команды tcpdump.

1 0.0 140.252.1.29.1610 > 140.252.1.54.53: 1+ PTR?
34.13.252.140.in-addr.arpa. (44)

2 0.332288 (0.3323) 140.252.1.54.53 > 140.252.1.29.1610: 1* 1/0/0 PTR
svr4.tuc.noao.edu. (75)

Простой пример

Простой пример

Давайте посмотрим, как происходит общение между разборщиком и сервером DNS. Мы запустили клиента Telnet с хоста sun на хост gemini, подключившись к серверу времени:

sun % telnet gemini daytime
Trying 140.252.1.11 ... первые три строки вывода от Telnet клиента
Connected to gemini.tuc.noao.edu.
Escape character is '^]'.
Wed Mar 24 10:44:17 1993 вывод от сервера дневного времени
Connection closed by foreign host. вывод от Telnet клиента

В этом примере мы указали разборщику на хосте sun (где запущен клиент Telnet) использовать сервер DNS на хосте noao.edu (140.252.1.54). На рисунке 14.9 показано взаимное расположение этих трех систем.

Проверка неправильного имени хоста

Проверка неправильного имени хоста

Когда IP датаграмма прибывает на хост сервера, будь то UDP датаграмма или TCP сегмент с требованием установить соединение, все что доступно процессу сервера это IP адрес клиента и номер порта (UDP или TCP). Некоторые сервера требуют, чтобы IP адрес клиента имел запись указателя в DNS. В разделе "Примеры FTP" главы 27 мы рассмотрим пример, иллюстрирующий это, используя анонимный FTP с неизвестного IP адреса.
Другие серверы, как, например, сервер Rlogin (глава 26), требуют не только то, чтобы IP адрес клиента имел запись указателя, но и еще спрашивают DNS об IP адресе, соответствующем имени, возвращенном в PTR отклике, и требуют, чтобы один из возвращенных адресов совпадал с IP адресом в принятой датаграмме. Эта проверка осуществляется потому, что пункты в файле .rhosts (глава 26, раздел "Протокол Rlogin") содержат имя хоста, а не IP адрес; таким образом, сервер хочет убедиться, что имя хоста действительно соответствует входящему IP адресу.
Некоторые производители автоматически помещают эту проверку в программы разборщика, конкретно в функцию gethostbyaddr. При этом подобная проверка становится доступной для любой программы, использующей разборщик. Отпадает необходимость помещать эту проверку в каждое приложение.
Мы можем увидеть, как это происходит, с помощью библиотеки разборщика SunOS 4.1.3. Мы написали простую программу, которая осуществляет запрос указателя путем вызова функции gethostbyaddr. Также мы поместили записи в файл /etc/resolv.conf таким образом, чтобы использовать в качестве DNS сервера хост noao.edu, получить доступ к которому можно через SLIP канал с хоста sun. На рисунке 14.13 показан вывод команды tcpdump, полученный от SLIP канала, при вызове функции gethostbyaddr, в случае, когда получается имя, соответствующее IP адресу 140.252.1.29 (хост sun).

1 0.0 sun.1812 > noao.edu.domain: 1+ PTR?
29.1.252.140.in-addr.arpa. (43)
2 0.339091 (0.3391) noao.edu.domain > sun.1812: 1* 1/0/0 PTR
sun.tuc.noao.edu. (73)
3 0.344348 (0.0053) sun.1813 > noao.edu.domain: 2+ A?
sun.tuc.noao.edu. (33)
4 0.669022 (0.3247) noao.edu.domain > sun.1813: 2* 2/0/0 A
140.252.1.29 (69)

Раздел вопросов в DNS запросе

Раздел вопросов в DNS запросе

Формат каждого вопроса в разделе вопросов (question) показан на рисунке 14.5. Обычно присутствует только один вопрос.
Имя запроса (query name) это искомое имя. Оно выглядит как последовательность из одной или нескольких меток. Каждая метка начинается с 1-байтового счетчика, который содержит количество следующих за ним байт. Имя заканчивается байтом равным 0, который является меткой с нулевой длиной. И является, в свою очередь, меткой корня. Каждый счетчик байтов должен быть в диапазоне от 0 до 63, так как длина метки ограничена 63 байтами.

Системы, используемые в примере работы DNS.

Рисунок 14.9 Системы, используемые в примере работы DNS.


Как мы уже упомянули ранее, разборщик является частью клиента. Он устанавливает контакт с сервером DNS, чтобы получить IP адрес, перед тем как будет установлено TCP соединение между Telnet и сервером времени.
На этом рисунке мы опустили подробности, описывающие, как происходит общение между sun и Ethernet сетью 140.252.1, которое в действительности осуществляется по SLIP каналу, потому что это не относится к нашим рассуждениям. Мы запустим tcpdump на SLIP канале, чтобы посмотреть, как происходит обмен пакетами между разборщиком и сервером DNS.
Файл /etc/resolv.conf на хосте sun сообщает разборщику о необходимости сделать следующее:
sun % cat /etc/resolv.conf
nameserver 140.252.1.54
domain tuc.noao.edu
Первая строка сообщает IP адрес DNS сервера - хоста noao.edu. Может быть указано до трех строк nameserver, таким образом, будет обеспечен запасной сервер на случай, если один из них выключен или недоступен. Строка domain содержит домен по умолчанию. Если искомое имя не является полным именем домена (не заканчивается точкой), к имени добавляется имя домена по умолчанию .tuc.noao.edu. Именно поэтому мы можем ввести telnet gemini вместо telnet gemini.tuc.noao.edu.
На рисунке 14.10 показан обмен пакетами между разборщиком и сервером DNS.

1 0.0 140.252.1.29.1447 > 140.252.1.54.53: 1+ A?
gemini.tuc.noao.edu. (37)

2 0.290820 (0.2908) 140.252.1.54.53 > 140.252.1.29.1447: 1* 2/0/0 A
140.252.1.11 (69)

UDP или TCP

UDP или TCP

Мы уже упоминали, что заранее известные номера портов для DNS серверов - UDP порт 53 и TCP порт 53. Это означает, что DNS поддерживает как UDP, так и TCP. Однако все примеры, которые мы просмотрели с использованием tcpdump, использовали UDP. Когда используется тот или иной протокол и почему?
Когда разборщик выдает запрос и возвращается отклик с установленным битом TC (обрезано - truncated), это означает, что размер отклика превысил 512 байт, только первые 512 байт были возвращены серверу. Разборщик обычно отправляет запрос снова, но уже с использованием TCP. При этом возвращается больше, чем 512 байт. (Вспомните описание максимального размера UDP датаграммы в разделе "Максимальный размер UDP датаграммы" главы 11.) Так как TCP делит поток данных на части, которые называются сегментами, он может передать любое количество пользовательских данных с использованием нескольких сегментов.
Также, когда в домене включается вторичный сервер DNS, он осуществляет передачу зоны с первичного сервера домена. Мы также говорили, что вторичный сервер регулярно запрашивает первичный (обычно каждые три часа). При этом определяется, не обновил ли первичный сервер свою таблицу, и если да, то осуществляется передача зоны. Передача зоны осуществляется с использованием TCP, так как в этом случае передается значительно больше данных, чем в случае одного запроса или отклика.
Так как DNS в основном использует UDP, и разборщик, и сервер DNS должны отработать свой собственный тайм-аут и осуществить повторную передачу. В отличие от других приложений Internet, которые используют UDP (TFTP, BOOTP и SNMP) и которые функционируют обычно в локальных сетях, DNS отправляет запросы и получает отклики обычно по глобальным сетям. Процент потерянных пакетов и разница в значениях времен возврата обычно значительно выше в глобальных сетях, нежели в локальных, при этом повышается важность надежной передачи и четкости работы алгоритма расчета тайм-аутов для клиентов DNS.

Упражнения

Упражнения

Классифицируйте DNS разборщик и DNS сервер как с точки зрения модели "клиент-сервер".

Объясните назначение всех 75 байт в отклике на рисунке 14.12.

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

Каждая UDP датаграмма имеет длину. Процессу, который получает UDP датаграмму, сообщается ее длина. Разборщик может выдать запрос с использованием TCP вместо UDP. TCP это поток байтов без каких-либо маркеров записи. Как приложение может узнать, сколько данных возвращено? Обратите внимание, что в DNS заголовке нет поля длины (рисунок 14.3). (Подсказка: обратитесь к RFC 1035.)

Мы говорили, что сервер DNS должен знать IP адреса корневых серверов, и что эта информация доступна через анонимный FTP. К сожалению, не все системные администраторы обновляют свои DNS файлы, если изменяется список корневых серверов. (В списке корневых серверов иногда происходят изменения, однако нечасто.) Как Вы думаете, каким образом DNS обрабатывает подобную ситуацию?

Получите файл, упомянутый в упражнении 8 главы 1, и определите, кто несет ответственность за обслуживание корневых серверов DNS. Как часто обновляется информация на корневых серверах?

В чем заключается проблема обслуживания кэша на сервере DNS и какую роль в этом играет разборщик?

При обсуждении рисунка 14.10 мы сказали, что DNS сервер сортирует записи A таким образом, что адреса, принадлежащие сети, в которой находится запрашивающий хост, становятся первыми. Кто должен сортировать записи A: сервер DNS или разборщик?

Назад
Компания | Услуги | Для клиентов | Библиотека | Галерея | Cофт | Линки
На главную

Вывод команды tcpdump для запроса

Рисунок 14.10 Вывод команды tcpdump для запроса на сервер DNS на хосте gemini.tuc.noao.edu.

Мы проинструктировали tcpdump не печатать имена доменов для IP адресов источника и назначения каждой IP датаграммы. Вместо этого он печатает 140.252.1.29 для клиента (разборщик) и 140.252.1.54 для сервера DNS. Порт 1447, используемый клиентом, это порт, назначаемый динамически, а 53 это заранее известный порт DNS сервера. Если tcpdump постарается напечатать имена вместо IP адресов, ему придется обратиться к тому же DNS серверу (осуществляя запрос указателя), что может привести к нежелательному выводу.
Начиная со строки 1, поле после двоеточия (1+) означает, что поле идентификации равно 1, а знак плюс обозначает, что установлен флаг RD (требуется рекурсия). Мы видим, что по умолчанию разборщик требует рекурсию.
Следующее поле, A?, означает, что тип запроса - A (мы хотим получить IP адрес), а маркировка вопроса обозначает, что это запрос (не ответ). Затем печатается имя запроса: gemini.tuc.noao.edu.. Разборщик добавляет последнюю точку к имени запроса, указывая на то, что это абсолютное имя домена.
Длина пользовательских данных в UDP датаграмме составляет 37 байт: 12 байт - заголовок фиксированного размера (рисунок 14.3), 21 байт - имя запроса (рисунок 14.6) и 4 байта - тип запроса и класс запроса. То что UDP датаграмма имеет нечетную длину напоминает нам, что в DNS сообщениях не используются биты заполнения.
Строка 2 в выводе команды tcpdump это ответ от DNS сервера, где 1* в поле идентификации со звездочкой обозначает, что установлен флаг AA (авторитетный ответ). (Мы ожидали от сервера именно этого, так как первичный сервер для домена noao.edu имеет полное представление об именах внутри этого домена.)
Вывод 2/0/0 показывает количество записей ресурсов в трех последних полях с переменной длиной отклика: 2 ответ RR, 0 полномочия RR и 0 дополнительные RR. Команда tcpdump печатает только первый ответ, который в данном случае имеет тип A (IP адрес) со значением 140.252.1.11.
Почему мы получили два ответа на наш запрос? Потому что хост gemini имеет несколько интерфейсов. Поэтому возвращено два IP адреса. Другое полезное средство, использующее DNS, - это программа host. Она позволяет нам отправить запрос на DNS сервер и посмотреть что вернется. Если мы запустим эту программу, то увидим два IP адреса для хоста gemini:
sun % host gemini
gemini.tuc.noao.edu A 140.252.1.11
gemini.tuc.noao.edu A 140.252.3.54
Первый ответ на рисунке 14.10 и первая строка вывода команды host - IP адрес, принадлежащий той же подсети (140.252.1), что и запрашивающий хост. В этом нет ничего странного. Если сервер DNS и хост, отправляющий запрос, находятся в той же самой сети (или подсети), BIND сортирует результаты таким образом, чтобы адреса, принадлежащие общей сети, появлялись в первую очередь.
Мы также можем получить доступ к хосту gemini с использованием другого адреса, однако это будет не так эффективно. С использованием traceroute в этом примере можно увидеть, что обычный путь от подсети 140.252.1 к 140.252.3 не проходит через хост gemini, а проходит через другой маршрутизатор, который подключен к обеим сетям. В данном случае, если мы получим доступ к gemini через другой IP адрес (140.252.3.54), все пакеты потребуют еще одной дополнительной пересылки. Мы вернемся к этому примеру и рассмотрим более подробно причины, по которым используется альтернативный маршрут, в разделе "Дополнительные примеры" главы 25, где мы сможем использовать SNMP, чтобы посмотреть таблицу маршрутизации маршрутизатора.
Существуют и другие программы, предоставляющие простой интерактивный доступ к DNS. Программа nslookup поставляется с большинством реализаций DNS. Глава 10 [Albitz and Liu 1992] подробно описывает эту программу. Программа dig (Domain Internet Groper) это еще одна общедоступная программа, с помощью которой можно отправить запросы на DNS сервера. Программа doc (Domain Obscenity Control) - shellовский скрипт, который использует dig и диагностирует поведение доменов, отправляя запросы на соответствующие DNS сервера и осуществляя простой анализ откликов. В приложении F подробно рассказано, как можно получить эти программы.
И последняя деталь, на которую необходимо обратить внимание в этом примере, это размер UDP данных в отклике: 69 байт. Чтобы объяснить эту величину, надо знать две вещи.

Вопрос возвращается в отклике.

При отправке отклика с именами доменов может быть использовано множество повторов. Поэтому используется схема сжатия. И действительно, в нашем примере имя домена gemini.tuc.noao.edu появляется трижды. Схема сжатия довольно проста. Везде, где в имени домена появляется метка, используется единственный байт-счетчик (который находится в диапазоне от 0 до 63), у которого два старших бита установлены в 1. Это 16-битный указатель, а не 8-битный байт-счетчик. Следующие 14 байт в указателе определяют смещение следующей метки в DNS сообщении. (Смещение первого байта в поле идентификации равно 0.) Мы специально сказали, что этот указатель может появиться там, где появляется метка, а не только там, где появляется полное имя домена, однако возможно, что указатель будет иметь как форму полного имени домена, так и всего лишь окончательной части имени. (Это потому, что окончательные метки в именах заданных доменов часто бывают идентичны.)

На рисунке 14.11 показан формат DNS отклика, что соответствует строке 2 на рисунке 14.10. Здесь показаны IP и UDP заголовки, чтобы напомнить о том, что DNS сообщения обычно инкапсулируются в UDP датаграммы. Мы специально показали байты счетчики в метках имен доменов в вопросе. Два возвращенных ответа одинаковы, за исключением различных IP адресов. В этом примере каждый указатель в ответе имеет значение 12, что является смещением от начала DNS заголовка полного имени домена.
И последнее, на что необходимо обратить внимание, это вторая строка из вывода команды Telnet, которая повторена здесь:

sun % telnet gemini daytime мы напечатали только gemini
Trying 140.252.1.11 ...
Connected to gemini.tuc.noao.edu. однако в выводе клиента Telnet появился FQDN

Вывод tcpdump для: host ftp.ee.lbl.gov.

Рисунок 14.15 Вывод tcpdump для: host ftp.ee.lbl.gov.

Из строки 1 видно, что теперь наш сервер установил контакт с другим корневым сервером (c.nyser.net). Сервер DNS обычно циклически опрашивает различные серверы для зоны, при этом накапливается информация о времени отклика от того или иного сервера. И, в конце концов, будет использован тот сервер, время возврата от которого минимально.
Так как наш сервер установил контакт с корневым сервером, флаг "рекурсия необходима" не установлен. Корневой сервер не сбросил флаг "рекурсия возможна", как мы видели в строке 2 на рисунке 14.14. (Даже если так, DNS сервер все равно не должен запрашивать корневой сервер с помощью рекурсивного запроса.)
В строке 2 отклик приходит назад без ответа, однако с четырьмя RR полномочий и четырьмя RR дополнительной информации. Как мы можем догадаться, четыре RR полномочий это имена DNS серверов для ftp.ee.lbl.gov, а другие четыре RR содержат IP адреса этих четырех серверов.
Строка 3 - это запрос на сервер ns1.lbl.gov (первый из четырех DNS серверов, полученных в строке 2). Флаг "рекурсия необходима" установлен.
Отклик в строке 4 отличается от предыдущих откликов. Возвращено два RR ответа, и tcpdump сообщает, что первый - это RR CNAME. Каноническое имя для ftp.ee.lbl.gov - это ee.lbl.gov.
Это общепринятое использование записи CNAME. FTP узел для LBL всегда имеет имя, начинающееся с ftp, однако время от времени он может перемещаться с одного хоста на другой. Пользователям достаточно знать только имя ftp.ee.lbl.gov, а DNS сама установит соответствие с тем или иным хостом.
Вспомните, что когда мы запускали host, он печатал и CNAME и IP адрес, соответствующий каноническому имени. Это потому, что отклик (строка 4 на рисунке 14.15) содержит два RR ответа. Первый это CNAME, второй это запись A. Если запись A не была возвращена вместе с CNAME, наш сервер пошлет еще один запрос, спрашивая IP адрес ee.lbl.gov. Это еще одна оптимизация реализации: CNAME и запись A канонического имени возвращается в одном отклике.

Вывод tcpdump для: host ftp.uu.net.

Рисунок 14.14 Вывод tcpdump для: host ftp.uu.net.

Появилась новая опция программы tcpdump. Мы получаем все данные, направляющиеся к или от UDP или TCP портов 53, с помощью опции -w. В этом случае весь символьный вывод сохраняется в файле для дальнейшей обработки. При этом tcpdump не пытается вызвать свой собственный разборщик, чтобы напечатать все имена, соответствующие IP адресам. После того как запущены все запросы, мы перезапустили tcpdump с опцией -r. В этом случае программа читает выходной файл и генерирует обычный вывод (который показан на рисунке 14.14). Это занимает несколько секунд, так как tcpdump вызывает свой разборщик.
Первое на что необходимо обратить внимание в выводе tcpdump, это то, что идентификаторы представляют собой небольшие целые числа (2 и 3). Это потому, что мы выключили сервер DNS и затем перестартовали его, чтобы очистить кэш. Когда сервер DNS стартует, он устанавливает идентификатор в 1.
Затем мы ввели запрос, в котором требуется получить IP адрес для хоста ftp.uu.net, DNS сервер установил соединение с одним из восьми корневых серверов, ns.nic.ddn.mil (строка 1). Это обычный запрос типа A, который мы уже видели ранее, однако обратите внимание, что флаг требования рекурсии не установлен. (Если флаг установлен, после идентификатора 2 должен быть напечатан знак плюс.) В наших предыдущих примерах говорилось, что разборщик устанавливает флаг необходимости рекурсии, однако здесь мы видим, что наш сервер DNS не установил флаг, когда он обратился к одному из корневых серверов. Это произошло потому, что от корневых серверов нельзя требовать рекурсивных ответов - они должны быть использованы только для того, чтобы найти адреса к другим полномочным серверам.
Из строки 2 видно, что отклик пришел назад без записи ресурса (RR) ответа, с пятью RR полномочий и пятью RR дополнительной информации. Знак минус, следующий за идентификатором 2, означает, что флаг "рекурсия возможна" (RA) не установлен - этот корневой сервер не ответит на рекурсивный запрос, даже если мы его об этом попросим.
Несмотря на то, что tcpdump не напечатал 10 записей ресурсов, которые были возвращены, мы можем исполнить команду host, чтобы посмотреть, что находится в кэше:

sun % host -v ftp.uu.net
Query about ftp.uu.net for record types A
Trying ftp.uu.net ...
Query done, 1 answer, status: no error
The following answer is not authoritative:
ftp.uu.net 19109 IN A 192.48.96.9
Authoritative nameservers:
UU.NET 170308 IN NS NS.UU.NET
UU.NET 170308 IN NS UUNET.UU.NET
UU.NET 170308 IN NS UUCP-GW-1.PA.DEC.COM
UU.NET 170308 IN NS UUCP-GW-2.PA.DEC.COM
UU.NET 170308 IN NS NS.EU.NET
Additional information:
NS.UU.NET 170347 IN A 137.39.1.3
UUNET.UU.NET 170347 IN A 192.48.96.2
UUCP-GW-1.PA.DEC.COM 170347 IN A 16.1.0.18
UUCP-GW-2.PA.DEC.COM 170347 IN A 16.1.0.19
NS.EU.NET 170347 IN A 192.16.202.11

В этот раз мы указали опцию -v, чтобы увидеть не только записи A. Вывод показывает, что в домене uu.net присутствует пять полномочных DNS серверов. Пять RR с дополнительной информацией, которые были возвращены корневым серверам, содержат IP адреса этих пяти DNS серверов. Поэтому у нас нет необходимости снова устанавливать контакт с корневым сервером, чтобы найти адрес одного из этих серверов. Это еще одно из расширений реализации, сделанное в DNS.
Команда host определяет, что ответ не авторитетный. Это произошло из-за того, что ответ был получен из кэша нашего DNS сервера, а не в результате контакта с полномочным сервером.
Вернемся к строке 3 на рисунке 14.14; сервер DNS установил контакт с первым полномочным сервером (ns.uu.net) с тем же самым вопросом: какой IP адрес ftp.uu.net? На этот раз наш сервер установил флаг "рекурсия необходима". Ответ, возвращенный в строке 4 - это отклик с одним ответом RR.
Затем мы снова исполнили команду host, спрашивая о том же самом имени:

sun % host ftp.uu.net
ftp.uu.net A 192.48.96.9

Это как раз то, что мы и ожидали, потому что ответ на команду host был получен из кэша сервера.
Мы исполнили команду host снова в поисках адреса для ftp.ee.lbl.gov:

sun % host ftp.ee.lbl.gov
ftp.ee.lbl.gov CNAME ee.lbl.gov
ee.lbl.gov A 128.3.112.20

На рисунке 14.15 показан вывод команды tcpdump.

1 18.664971 (17.6555) sun.tuc.noao.edu.domain > c.nyser.net.domain:
4 A? ftp.ee.lbl.gov. (32)
2 19.429412 ( 0.7644) c.nyser.net.domain > sun.tuc.noao.edu.domain:
4 0/4/4 (188)

3 19.432271 ( 0.0029) sun.tuc.noao.edu.domain > ns1.lbl.gov.domain:
5+ A? ftp.ee.lbl.gov. (32)
4 19.909242 ( 0.4770) ns1.lbl.gov.domain > sun.tuc.noao.edu.domain:
5* 2/0/0 CNAME ee.lbl.gov. (72)

Вывод tcpdump для запроса указателя.

Рисунок 14.12 Вывод tcpdump для запроса указателя.

Из строки 1 видно, что идентификатор равен 1, установлен флаг требования рекурсии (знак плюс), и тип запроса это PTR. (Вспомним, что марка вопроса обозначает, что это запрос, а не отклик.) Размер данных составляет 44 байта, из которых 12 байт - DNS заголовок, 28 байт - 7 меток в имени домена, и 4 байта это тип запроса и класс запроса.
В отклике установлен бит авторитетного ответа (звездочка) и содержится одна запись ресурса (RR) ответа. Тип RR это PTR, а данные ресурса содержат имя домена.
От разборщика к серверу DNS в качестве запроса указателя передается не 32-битный IP адрес, а имя домена 34.13.252.140.in-addr.arpa.

Вызов функции разборщика, которая

Рисунок 14.13 Вызов функции разборщика, которая осуществляет запрос указателя.

В строке 1 запрос указателя, в строке 2 отклик. Однако, функция разборщика автоматически посылает запрос об IP адресе в строке 3 на имя, возвращенное в строке 2. Отклик в строке 4 содержит две записи ответа, так как хост sun имеет два IP адреса. Если ни один из адресов не совпал с аргументом gethostbyaddr, отправляется сообщение системе, которая фиксирует событие, а функция возвращает ошибку приложению.

Записи ресурсов

Записи ресурсов

Мы видели несколько различных типов записей ресурса (RR), а именно: IP адрес имеет тип A, а PTR обозначает запрос указателя. Также мы видели RR, которые возвращает DNS сервер: RR ответа, RR полномочий и RR дополнительной информации. Всего существует около 20 различных типов записей ресурсов, некоторые из которых мы сейчас опишем.
А
Запись А определяет IP адрес. Хранится как 32-битное двоичное значение.
PTR
Запись указателя используется для запросов указателя. IP адрес представляется в виде имени домена (последовательность меток) в домене in-addr.arpa.
CNAME
"Каноническое имя" (canonical name). Представляется как имя домена (последовательность меток). Имя домена, которое имеет каноническое имя, часто называется псевдонимом (alias). Они используются некоторыми FTP узлами, для того чтобы предоставить легкозапоминаемый псевдоним для какой-либо системы. Например, сервер gated (мы упоминали о нем в разделе "Демоны маршрутизации в Unix" главы 10) доступен через анонимное FTP с сервера gated.cornell.edu. Однако, не существует системы, названной gated, это псевдоним для какой-то другой системы. Эта другая система является каноническим именем для gated.cornell.edu:

sun % host -t cname gated.cornell.edu
gated.cornell.edu CNAME COMET.CIT.CORNELL.EDU

Здесь мы использовали опцию -t, чтобы указать на один конкретный тип запроса.

HINFO
Информация о хосте: две символьные строки, указывающие на центральный процессор (CPU) и операционную систему. Не все хосты предоставляют записи HINFO для своих систем, и предоставляемая информация может быть устаревшей.
sun % host -t hinfo sun
sun.tuc.noao.edu HINFO Sun-4/25 Sun4.1.3


MX
Записи, посвященные обмену почтой, которые используются по следующему сценарию: (1) узел, который не подсоединен к Internet, может использовать узел, который подсоединен к Internet, в качестве своего почтового сервера. Два узла работают попеременно, обмениваясь любой прибывшей почтой, в основном с использованием протокола UUCP. (2) запись MX предоставляет возможность доставить почту на альтернативный хост, когда хост назначения недоступен. (3) записи MX позволяют организациям предоставлять виртуальные хосты, на которые можно отправлять почту, как, например, cs.university.edu, даже если хост с таким именем не существует. (4) Организации со шлюзами firewall могут использовать записи MX, чтобы ограничить доступ к внутренним системам. Многие хосты, которые не подключены к Internet, имеют UUCP каналы к хостам, подключеным к Internet, как, например, UUNET. С помощью записи MX обеспечивается передача электронной почты с использованием стандартного обращения user@host (пользователь@хост). Например, фиктивный домен foo.com может иметь следующую MX запись:

sun % host -t mx foo.com
foo.com MX relay1.UU.NET
foo.com MX relay2.UU.NET

MX записи используются программами доставки почты на хостах, подключенных к Internet. В этом примере программа доставки почты говорит "если у тебя есть почта, которую необходимо послать на user@foo.com, пошли почту на relay1.uu.net или на relay2.uu.net".
В каждой записи MX есть 16-битное целое значение, которое называется значением предпочтительности. Если для одного пункта назначения существует несколько MX записей, они будут использованы по порядку, начиная с той записи, у которой наименьшее значение предпочтительности.
Записи MX используются, когда хост выключен или недоступен. В этом случае программа доставки почты использует MX записи только в том случае, если не может подсоединиться к пункту назначения с использованием TCP. Для объединенных сетей, с которыми экспериментировал автор, его основная система подключена к Internet через SLIP канал, и если она не работает, мы получим:

sun % host -tv mx sun
Query about sun for record types MX
Trying sun within tuc.noao.edu ...
Query done, 2 answers,authoritative status: no error
sun.tuc.noao.edu 86400 IN MX 0 sun.tuc.noao.edu
sun.tuc.noao.edu 86400 IN MX 10 noao.edu

Опцию -v позволяет посмотреть значения предпочтительности. (Благодаря этой опции в выводе появятся и все другие поля.) Второе поле, 86400, - это время жизни в секундах. Время жизни равно 24 часам (24х60х60). Третья колонка, IN, это класс (Internet). Мы видим, что непосредственная доставка на хост (первая запись MX) имеет наименьшее значение предпочтительности равное 0. Если это не работает (SLIP канал выключен), используется следующее более высокое значение предпочтительности (10), и делается попытка доставить почту на хост noao.edu. Если и это не сработает, отправитель отработает тайм-аут и повторит попытки позже.
В разделе "Примеры SMTP" главы 28 мы покажем примеры доставки почты SMTP с использованием записей MX.

NS
Запись имени сервера. Указывает на полномочные DNS серверы для домена. Представлена в виде имен доменов (последовательность меток). Мы рассмотрим примеры этих записей в следующем разделе. Это общие типы RR. В следующих примерах мы увидим еще некоторые типы.

Запросы указателя

Запросы указателя

Для понимания работы DNS важно знать, как обрабатываются запросы указателя - задан IP адрес, возвращается имя (или имена), соответствующее этому адресу.
Во-первых, вернемся к рисунку 14.1 и рассмотрим домен верхнего уровня arpa, а также домен in-addr, находящийся ниже. Когда организация вступает в Internet и получает часть простраства имен DNS, как, например, noao.edu, она также получает право на часть пространства имен in-addr.arpa, соответствующее ее IP адресам в Internet. В данном случае noao.edu - это сеть класса B с идентификатором 140.252. Уровень дерева DNS ниже in-addr.arpa должен быть первым байтом IP адреса (140 в данном примере), следующий уровень это следующий байт IP адреса (252), и так далее. Однако помните, что имена пишутся, снизу-вверх по дереву DNS. Это означает, что DNS имя хоста sun с IP адресом 140.252.13.33 будет 33.13.252.140.in-addr.arpa.
Мы должны написать 4 байта IP адреса задом наперед, потому что полномочия делегируются на основе идентификаторов сетей: первый байт адрес класса A, первый и второй байты адреса класса B, а первый, второй и третий байты это адреса класса C. Первый байт IP адреса должен быть непосредственно под меткой in-addr, однако полные имена доменов (FQDN) пишутся снизу вверх по дереву. Если бы FQDN писались сверху вниз, DNS имя для IP адреса было бы arpa.in-addr.140.252.13.33, однако в этом случае FQDN для хоста должно быть edu.noao.tuc.sun.
Без отдельных ветвей дерева DNS осуществить преобразования адрес - имя, (обратное преобразование) можно было бы только начиная от корня дерева и просматривая каждый домен верхнего уровня. При сегодняшнем размере Internet это могло бы занять дни или даже недели. Использование же in-addr.arpa приемлемый вариант, несмотря на переставленные местами байты в IP адресе и специальные домены, иногда вносящие определенную путаницу.
Однако встретиться с доменом in-addr.arpa и переставленными байтами в IP адресе можно только тогда, когда мы общаемся с DNS непосредственно, используя, такие программы как host или просматривая пакеты с использованием tcpdump. При работе приложения, разборщик (gethostbyaddr) обычно воспринимает IP адрес и возвращает информацию о хосте. Перестановка байтов и добавление домена in-addr.arpa осуществляется разборщиком автоматически.

Значения type и query type для DNS вопросов и ответов.

Рисунок 14.7 Значения type и query type для DNS вопросов и ответов.

Наиболее распространенный тип запроса - тип A, который обозначает, что необходим IP адрес для запрашиваемого имени (query name). PTR запрос требует имена, соответствующие IP адресу. Это запрос указателя, который мы опишем в разделе "Запросы указателя" этой главы. Другие типы запросов мы опишем в разделе "Записи ресурсов" этой главы.
Класс запроса (query class) обычно равен 1, что указывает на адреса Internet. (В некоторых случаях поддерживаются не-IP значения.)



    Бизнес: Предпринимательство - Малый бизнес - Управление

• Бизнес
  
• Разновидности бизнеса
  
• Планирование бизнеса
  
• Управление бизнесом
  
  
• Предпринимательство
  
• Русское предпринимательство
  
• Управление и предпринимательство
  
  
• Малый бизнес
  
• Виды малого бизнеса
  
• Русский малый бизнес
  
• Управление малым бизнесом
  
• Posix для малого бизнеса
  
  
• Телефония как малый бизнес
  
• Телефония на Java для малого бизнеса