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

Для каких целей используются эти службы? Существует множество приложений, построенных совершенно естественным способом поверх UDP. Так можно, например, реализовать простую систему просмотра базы данных. Кроме того, мы уже упоминали о системе DNS, сформированной на основе UDP (см. рис. 9.1).

Рис. 9.1. Вопрос и ответ DNS

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

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

Иногда это приводит к дублированию запросов на сервере. Если приложение включит в свое сообщение идентификатор транзакции, сервер сможет распознать дублирование и исключить дополнительную копию сообщения. За эти действия ответственно само приложение, а не UDP.

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

Что происходит после прибытия данных в хост назначения? Как выполняется их доставка в нужное приложение (процесс)?

На рис. 9.2 видно, что для каждого уровня существует идентификатор протокола, указывающий операции, выполняемые над данными. На втором уровне тип Ethernet X'08-00 в заголовке кадра показывает, что кадр нужно передать в IP. На третьем уровне поле протокола в заголовке IP указывает протокол четвертого уровня, куда нужно переслать данные (например, 6 для TCP или 17 для UDP).

Рис. 9.2. Пересылка данных до уровня приложений

Хост может участвовать одновременно в нескольких коммуникациях. Так как же из общего потока выделяется датаграмма UDP и доставляется на нужный уровень приложения? Такой процесс пересылки данных в требуемый процесс часто называют демультиплексированием. Ответ состоит в том, что каждой конечной коммуникационной точке UDP присвоен 16-разрядный идентификатор, называемый номером порта. Термин "порт" не очень удачен для данного идентификатора. Порт для клиентской и серверной частей приложения не имеет никакого отношения к портам оборудования и физическому пути пересылки данных).

Порты с номерами от 0 до 1023 зарезервированы для стандартных служб. Такие порты называются общеизвестными (well-known). Их использование позволяет клиенту идентифицировать службу, к которой он хочет получить доступ. Например, доступ к DNS (которая основана на UDP) производится через общеизвестный порт 53.

Кто назначает общеизвестные порты? Как не трудно догадаться, этим занимается IANA. Номера портов для определенных приложений регистрируются этой организацией и публикуются в документе RFC Assigned Numbers (присвоенные номера). Сокращенный список портов UDP из текущего документа RFC Assigned Numbers показан в таблице 9.1.

Таблица 9.1 Примеры общеизвестных портов UDP

Несколько общеизвестных служб обеспечивает модули для тестирования, отладки и измерений. Например, echo (эхо) с портом 7, соответствуя своему имени, возвращает любую посланную на этот порт датаграмму. Служба Discard (отмена) порта 9, наоборот, удаляет из сети любую посланную на этот порт датаграмму. Character generator (генератор символов) отвечает на любое сообщение датаграммой, содержащей от 0 до 512 байт. Количество байт выбирается случайным образом.

Служба quote of the day (цитата дня) отвечает на любую датаграмму определенным сообщением, например, в некоторых системах программа fortune выводит при регистрации "мудрые" советы (в данном примере приведена фраза Уинстона Черчилля: "Человек может случайно споткнуться об истину, но в большинстве случаев не замечает ее и сосредоточенно продолжает дальнейший поиск".):

> fortune

Churchill's Commentary on Man:

 Man will occasionally stumble over the truth, but most of the

 time he will pick himself up and continue on.

Служба daytime (время дня) отвечает на любые датаграммы сообщением, содержащим текущую дату и время в формате ASCII. Такой формат можно прочитать на экране без дополнительных преобразований. Иначе ведет себя служба Network Time Protocol (NTP), обеспечивающая надежный метод синхронизации компьютеров сети.

Сервер BOOTP и клиент этой службы используются для неконфигурируемых устройств. Рабочая станция может получить для себя IP-адрес, свою маску адреса, узнать местоположение маршрутизатора по умолчанию, адреса наиболее важных серверов сети и, при необходимости, имя и местоположение на сервере boot загружаемого программного файла конфигурации. Программное обеспечение в рабочую станцию поступает через протокол Trivial File Transfer Protocol (см. главу 14).

Мы уже знаем, что сервер имен доступен через порт 53 и команду nslookup. Порты 161 и 162 используются протоколом Simple Network Management Protocol.

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

Оставшиеся номера портов (выше 1023) предоставляются клиентам от программного обеспечения хоста по мере необходимости. Выделение предусматривает следующие шаги:

1. Пользователь запускает клиентскую программу (например, nslookup).

2. Клиентский процесс исполняет системную подпрограмму, имеющую смысл: "Я хочу выполнить коммуникацию UDP. Предоставьте мне порт".

3. Системная подпрограмма выбирает неиспользованный порт из пула доступных портов и предоставляет его клиентскому процессу.

Можно видеть, что TCP также идентифицирует источник и назначение своим 16-разрядным идентификатором порта. Например, порт 21 применяется для доступа к службе пересылки файлов, а порт 23 — для службы регистрации telnet.

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

Используемая для коммуникации комбинация IP-адреса и порта называется адресом socket (дословно — гнездо, разъем). Отметим, что адрес socket обеспечивает для сервера или клиента всю информацию, необходимую для идентификации партнера по коммуникации.

Заголовок IP содержит IP-адреса источника и назначения. Заголовки UDP и TCP содержат номера портов источника и назначения. Следовательно, каждое сообщение UDP или TCP несет в себе адрес socket для источника и назначения.

Ниже приведен результат выполнения команды netstat -па, выводящей локальные и удаленные адреса socket для текущих активных коммуникаций с системой tigger. Адреса socket записаны в форме IP-адрес.номер_порта.

> netstat -na

Active Internet connections (including servers)

Proto Recv-Q Send-Q Local Address       Foreign Address     (state)

Tcp      0      0   127.0.0.1.1340      127.0.0.1.111       TIME_WAIT

Tcp      0      0   128.121.50.145.25   128.252.223.5.1526  SYN_RCVD

Tcp      0      0   128.121.50.145.25   148.7.9.160.65.3368 ESTABLISHED

Tcp      0    438   128.121.50.145.23   130.132.57.246.2219 ESTABLISHED

Tcp      0      0   128.121.50.145.25   192.5.5.1.4022      TIME_WAIT

Tcp      0      0   128.121.50.145.25   141.218.1.100.3968  TIME_WAIT

Tcp      0      0   128.121.50.145.25   35.8.2.2.3722       TIME_WAIT

Tcp      0      0   128.121.50.145.1338 165.247.48.4.25     ESTABLISHED

Tcp      0      0   128.121.50.145.25   128.173.4.8.3626    ESTABLISHED

Tcp      0      0   128.121.50.145.25   192.48.96.14.3270   ESTABLISHED

. . .

Udp      0      0   *.7                 *.*

Udp      0      0   *.9                 *.*

Udp      0      0   *.37                *.*

Udp      0      0   *.19                *.*

Udp      0      0   *.111               *.*

. . .

Например, выделенный рамкой элемент показывает сеанс регистрации TCP из порта клиента 2219 с IP-адресом 130.132.57.246 на стандартный порт telnet с номером 23 и адресом 128.121.50.145. Строки, подобные *.7 и *.9, представляют службы UDP на tigger, ожидающие запросов от клиентов.

Какой механизм необходим для запуска протокола User Datagram Protocol? Прежде всего, UDP должен быть присвоен уникальный идентификатор протокола (17). Это значение будет помещаться в поле протокола IP с названием Protocol во всех исходящих сообщениях UDP. Входящие сообщения со значением 17 в поле протокола IP доставляются в UDP. Протокол UDP формирует сообщение, добавляя простой заголовок к данным от приложения. В этом заголовке указываются номера портов источника и назначения.

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

Рис. 9.3. Заголовок UDP

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

В UDP контрольная сумма вычисляется как комбинация специально сформированного псевдозаголовка (pseudo header), содержащего некоторую информацию IP, заголовка UDP и данных из сообщения.

Формат псевдозаголовка и его участие в вычислении контрольной суммы показаны на рис. 9.4. Отметим, что адрес источника, адрес назначения и поле протокола заимствуются из заголовка IP.

Рис. 9.4. Поля псевдозаголовка для контрольной суммы UDP

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

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

Рис. 9.5 содержит совмещенный вывод IP и UDP частей запроса и соответствующих им ответов. Этот результат получен в мониторе локальной сети Sniffer компании Network General. Запрос содержал требование вывода статуса информации и был послан хостом на сетевую станцию управления. Часть для данных в сообщениях запроса и ответа не приведена.

Рис. 9.5. Заголовки IP и UDP для запроса и ответа

Запрос был послан из IP-адреса 128.1.1.1 и порта UDP с номером 1227 на IP-адрес назначения 128.1.1.10 и 161-й порт UDP (запросы сетевого обслуживания всегда направляются на порт UDP с номером 161).

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

Анализатор Sniffer распознает, что порт 161 назначен для сетевого обслуживания.

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

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

> netstat -s

. . .

udp:

 0 incomplete headers

 0 bad data length fields

 0 bad checksums

 17 socket overflows

Протокол User Datagram Protocol определен в RFC 768. RFC от 862 до 865 обсуждают UDP-службы, echo, discard, character generator и quote of the day. RFC 867 описывает утилиту daytime, a RFC 1119 представляет вторую версию службы network time. Протокол BOOTP рассматривается в главе 11, а о дополнительных службах UDP будет упомянуто в следующих главах.