Обычно DNS используется другими протоколами прикладного уровня: HTTP, SMTP и FTP для получения IP-адресов вместо вводимых пользователями имен хостов. Рассмотрим, к примеру, ситуацию, когда пользователь вводит в адресной строке браузера адрес web-страницы _www.someschool.edu/index.html. Для того чтобы сформировать запрос, пользовательский хост должен сначала получить IP-адрес удаленного хоста, на котором находится ресурс, то есть _www.someschool.edu. При работе протокола DNS пользовательский хост играет роль клиента. Браузер выделяет из URL-адреса страницы имя хоста и передает его клиентской стороне DNS-приложения, которая формирует и отправляет запрос DNS-серверу. DNS-сервер обрабатывает запрос и отсылает клиенту ответ, содержащий IP-адрес хоста. Затем браузер открывает TCP-соединение с HTTP-сервером, выполняющимся на хосте с полученным IP-адресом. Очевидно, что процесс получения IP-адреса не является мгновенным и вносит дополнительную задержку в суммарное время установления соединения с HTTP-сервером, которая иногда может быть весьма значительной. Как мы увидим позже, среднее время получения IP-адреса (а также объем DNS-трафика) может быть уменьшено путем кэширования IP-адреса на «ближайшем» DNS-сервере.
Помимо преобразования имен хостов в IP-адреса, DNS выполняет еще несколько важных функций, перечисленных ниже.

□ Поддержка псевдонимов серверов. Хосты с длинными именами могут иметь один или несколько псевдонимов; например, хосту _relayl.west-coast.enterprise.com можно присвоить два псевдонима — _enterprise.com и _www.enterprise.com. В этом случае говорят, что _relayl.west-coast.enterprise.com является каноническим именем хоста. Обычно введение псевдонимов вызывается недостаточной мнемо-ничностью канонического имени. Получение канонического имени хоста по заданному псевдониму, как и IP-адреса, выполняется с помощью протокола DNS.

□ Поддержка псевдонимов почтовых серверов. Очевидно, что мнемоничность особенно важна для адресов электронных почтовых ящиков. Например, если Боб использует почтовый ящик компании Hotmail, то его адрес будет иметь вид _bob@hotmail.com, что нетрудно запомнить. На самом деле _hotmail.com является лишь псевдонимом почтового сервера Боба, в то время как каноническое имя имеет гораздо более сложную структуру, например _relayl.west-coast.hotmail.com. Приложение электронной почты с помощью протокола DNS по заданному псевдониму получает каноническое имя и IP-адрес сервера. Фактически запись типа MX (см. ниже) позволяет почтовому серверу компании и ее web-серверу иметь одинаковые псевдонимы, например _enterprise.com.

□ Распределение загрузки. В последнее время DNS все больше используется для распределения загрузки между дублирующими серверами. Популярные сайты, например cnn.com, зачастую имеют несколько копий (или реплик, или зеркал), расположенных на различных серверах с различными IP-адресами. Таким образом, в случае дублирующих серверов с одним именем хоста связывается множество IP-адресов, которые хранятся в базе данных DNS. Когда производится DNS-запрос для имени, которому сопоставлено несколько IP-адресов, в ответ включаются все IP-адреса, однако сервер может изменять порядок их перечисления. Поскольку обычно HTTP-клиент сначала формирует запрос с использованием IP-адреса, который был указан в списке первым, это позволяет распределять загрузку между дублирующими серверами. Подобный механизм применим как для web-серверов, так и для почтовых серверов, то есть несколько почтовых серверов могут иметь один и тот же псевдоним. В последнее время некоторые компании, такие как Akamai, стали применять DNS для «изощренных» методов распределения web-ресурсов (см. раздел «Распределение ресурсов» этой главы).

ПРИНЦИПЫ И ПРАКТИКА -
DNS, подобно протоколам HTTP, FTP и SMTP, является протоколом прикладного уровня. Он выполняется на оконечных системах, опираясь на парадигму клиент/сервер и службы протокола транспортного уровня, передающие DNS-сообщения между оконечными системами. Тем не менее роль DNS в значительной степени отличается от роли web-протоколов, а также протоколов электронной почты и обмена файлами. Пользователь не взаимодействует с DNS напрямую: DNS осуществляет в Интернете «закулисную» функцию преобразования имен хостов в IP-адреса. Эта функция используется либо пользовательскими приложениями, либо другим сетевым программным обеспечением. В разделе «Ядро компьютерных сетей» главы 1 мы рассказали о том, что наиболее сложные проблемы Интернета сосредоточены на его «периферии». Служба DNS, выполняющая трансляцию адресов с помощью клиентов и серверов, находящихся на разбросанных по Интернету оконечных системах, только подтверждает эту философию разработчиков.

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

Идентификация процесса внутри хоста производится с помощью уникального для каждого процесса хоста номера порта. Популярные Интернет-протоколы прикладного уровня имеют стандартизированные (говорят: хорошо известные) значения номеров портов. Так, процесс, использующий протокол HTTP, получает порт номер 80, а процесс, использующий протокол SMTP, — порт номер 25. Хорошо известные номера портов можно найти в документе RFC 1700 (который в настоящее время является несколько устаревшим) и на сайте _http://www.iana.org (RFC 3232). Когда разработчик создает новое сетевое приложение, он должен назначить приложению собственный номер порта.

На рис, 2.3 изображено взаимодействие двух процессов через Интернет посред-ством.сокетов (хотя в представленной ситуации используется протокол TCP, с тем же успехом это мог бы быть протокол UDP). Как можно видеть, сокет представляет собой интерфейс между прикладным и транспортным уровнями хоста. Сокет также часто называют прикладным программным интерфейсом (API), осуществляющим связь приложения и компьютерной сети. Под контролем разработчика приложения практически целиком находится часть сокета, относящаяся к прикладному уровню, чего нельзя сказать о его «транспортной» части. Здесь в компетенции разработчика лишь выбор протокола транспортного уровня и установка значений нескольких параметров транспортного уровня (максимальный размер буфера, максимальный размер сегмента и др.). Приложение всегда строится с использованием единственного транспортного протокола. Мы вернемся к обсуждению сокетов в разделах «Программирование ТСР-сокетов» и «Программирование UDP-сокетов» этой главы.

Во многих приложениях хост может играть роль как клиента, так и сервера. Представим себе сеанс Telnet, установленный между хостами А и В (как вы помните, Telnet представляет собой когда-то популярное приложение для организации удаленного доступа). Если сеанс был инициирован хостом А, то хост А будет играть роль клиента, а хост В — роль сервера. Если же инициатором сеанса был хост В, то хосты А и В поменяются ролями. В качестве другого примера представьте себе обмен файлов между двумя хостами по протоколу FTP (File Transfer Protocol — протокол передачи файлов). Во время FTP-сеанса клиент и сервер могут неоднократно меняться местами, при этом клиентом считается та сторона, которая осуществляет прием файла. Тем не менее чаще всего пользуются следующим правилом: клиентом является хост, инициирующий обмен.

В качестве второго примера рассмотрим приложение электронной почты. Электронная почта Интернета также состоит из множества компонентов: почтовых серверов, содержащих почтовые ящики пользователей, программ для просмотра и создания электронных писем, стандартов, описывающих структуру электронных писем, протоколов прикладного уровня, регламентирующих порядок обмена сообщениями серверов между собой и с оконечными системами пользователей, а также интерпретацию полей, из которых состоят электронные письма. Основным протоколом прикладного уровня для электронной почты является протокол простой передачи сообщений (Simple Mail Transfer Protocol, SMTP). Как мы видим, SMTP (RFC 2821) — лишь часть (хотя и достаточно большая) структуры приложений электронной почты.

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

Некоторые из протоколов прикладного доступа (HTTP, SMTP и др.) являются официально документированными в RFC. Это означает, что если разработчик нового браузера будет следовать стандарту, то браузер сможет получать документы с любого web-сервера, построенного по этому же стандарту. Тем не менее существует множество протоколов прикладного уровня, которые не стандартизированы и при этом используются для поддержки коммерческих продуктов. В частности, это характерно для Интернет-телефонии.