ОСиС_2008

–MX (сокращение от Mail eXchanger) — возвращаемое значение представляет собой IP-адрес, соответствующий заданному DNS-имени и используемый для приема электронной почты. Применение данного типа позволяет использовать для приема электронной почты и для других приложений (в том числе и Web) два разных хоста, имеющих одинаковое DNS-имя, но разные IP-адреса;

–CNAME — переданное в запросе DNS-имя представляет собой псевдоним настоящего (канонического) имени хоста. Возвращаемое значение представляет собой IP-адрес, соответствующий каноническому имени. Например, если хост kcup.fet.tusur.ru используется в качестве Web-сервера, то в качестве псевдонима для этого хоста может использоваться www.kcup.fet.tusur.ru. Естественно, что для задания хоста пользователь может использовать не только псевдоним, но и каноническое имя.

Получив запрос от клиента, DNS-сервер выполняет поиск в своей базе данных, в которой хранится информация о каждом DNS- имени из того поддерева имен DNS, за которое отвечает данный сервер. Каждая запись в базе данных сервера содержит: 1) DNS- имя; 2) тип записи; 3) значение. При этом поля «DNS-имя» и «тип записи» используются в качестве исходной информации для поиска требуемого содержимого третьего поля.

Заметим, что пользователь сетевого приложения часто может использовать не только полные DNS-имена, но и сокращения от этих имен. Например, сокращениями имени хоста kcup.fet.tusur.ru

являются kcup.fet.tusur, kcup.fet и kcup. Так как DNS-серверы имеют дело исключительно с полными DNS-именами, то всю работу по преобразованию сокращенного DNS-имени в полное имя выполняет DNS-клиент (более точно — процедура gethostbyname). Например, пусть пользователь использовал в диалоге с сетевым приложением DNS-имя kcup. Тогда, обратившись к DNS-серверу, DNS-клиент получит значение NULL. После этого DNS-клиент последовательно увеличивает длину DNS-имени за счет подсоединения к сокращенному DNS-имени суффиксов fet.tusur.ru, tusur.ru, ru до тех пор, пока не получит от своего локального сервера искомый IP-адрес. Естественно, что перечисленные суффиксы должны быть заранее введены в качестве констант, доступных процедуре gethostbyname. Заметим, что в приведенном примере первое же присоединение суффикса fet.tusur.ru приведет к получению полного DNS-имени.

Для повышения эффективности использования системы DNS используются два приема — тиражирование корневого DNS- сервера и кэширование имен. Рассмотрим эти приемы.

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

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

8.5. Приложения для передачи файлов

8.5.1. Приложения на основе протокола FTP

Очень распространены сетевые приложения для передачи файлов, которые используют прикладной протокол FTP (File Transfer Protocol — протокол передачи файлов). В отличие от рассмотренного выше приложения DNS, такое приложение обслуживает не только программы, но и пользователей. Поэтому оно предоставляет для такого обслуживания не только программный, но и пользовательский интерфейсы. Ранее была рассмотрена общая структура подобных сетевых приложений.

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

влокальную файловую структуру, или, наоборот, копирование локального файла в файловую структуру на удаленном хосте. Для выполнения любой из этих операций требуется, чтобы права доступа данного пользователя к файлу на удаленном хосте соответствовали типу этой операции. Естественно, что для получения каких-то особых прав доступа пользователь должен, во первых, заранее быть зарегистрирован на удаленном хосте (получить символьное имя и пароль), а во вторых, в начале работы с FTP- клиентом пользователь должен пройти процедуру аутентификации — правильно назвать свое имя и пароль. В том случае если пользователь не зарегистрирован на удаленном хосте, он может получить минимальные права доступа к файлам этого хоста, используя стандартное имя — anonymous, а в качестве пароля — quest.

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

1)open — подготовиться к пересылке файла (файлов) между локальным и удаленным хостами. При выполнении данной команды FTP-клиент запрашивает у пользователя DNS-имя удаленного хоста (если при вводе команды shell – ftp пользователь не задал

вкачестве параметра IP-адрес этого хоста). Кроме того, FTP-кли- ент выполняет аутентификацию пользователя, запрашивая у него имя и пароль;

2)close — команда, обратная open. Она уничтожает транспортные каналы между локальным и удаленным хостами. Применение данной команды не означает завершение работы FTP-

клиента, так как пользователь может выдать новую команду open для этого же или для другого удаленного хоста;

3) get — передать копию файла с удаленного хоста на локальный хост. В качестве первого параметра команды пользователь может задать имя требуемого файла на удаленном хосте, а в качестве второго параметра — имя файла-копии на локальном хосте. Если второй параметр отсутствует, то имя файла-копии будет таким же, как и у исходного файла. Если отсутствует и первый параметр, то FTP-клиент сам запросит у пользователя имя копируемого файла;

4)mget — передать с удаленного хоста на локальный хост копии нескольких файлов;

5)put — передать копию файла с локального хоста на удаленный хост. В качестве первого параметра задается имя файла на локальном хосте, а в качестве второго параметра — имя файлакопии на удаленном хосте;

6)mput — передать с локального на удаленный хост копии нескольких файлов;

7)pwd — определить имя-путь текущего каталога на удаленном хосте. Текущий каталог на удаленном хосте используется точно так же, как и текущий каталог на локальном хосте — для сокращения задаваемых имен файлов;

8)cd — сделать переход в другой текущий каталог на удаленном хосте;

9)ls — вывести на экран содержимое требуемого каталога на удаленном хосте;

10)quit — завершить работу FTP-клиента.

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

1) при получении команды пользователя open клиент посылает серверу следующие команды:

а) USER имя_пользователя — передает серверу имя пользователя;

б) PASS пароль — передает серверу пароль пользователя;

2)при получении команды пользователя ls клиент посылает серверу команду LIST — запрос на пересылку содержимого текущего каталога;

3)при получении команды пользователя get клиент посылает серверу команду RETR имя_файла — запрос на пересылку копии заданного файла с удаленного хоста на локальный хост. При получении от пользователя команды mget клиент посылает серверу несколько команд RETR — по одной на каждый копируемый файл;

4)при получении команды пользователя put клиент посылает серверу команду STOR имя_файла — запрос на пересылку копии заданного файла с локального на удаленный хост. При получении от пользователя команды mput клиент посылает серверу несколько команд STOR — по одной на каждый копируемый файл.

Прежде чем обмениваться FTP-командами и ответами на них, клиент и сервер создают управляющее TCP-соединение. Инициатором создания такого соединения является клиент, а точнее — главный клиентский процесс. Запрос на создание управляющего соединения этот процесс посылает в TCP-порт с номером 21, принадлежащий хосту с требуемым FTP-сервером. При этом IP- адрес требуемого хоста сервера известен или из команды пользователя, запускающей FTP-клиент, или в результате преобразования DNS-сервером того DNS-имени, которое сообщил пользователь.

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

Для передачи данных какого-то файла (по команде RETR или STOR), а также для передачи содержимого какого-то каталога (по команде LIST) между дочерним процессом сервера и главным процессом клиента создается дополнительное TCP-соединение передачи данных. Инициатором создания такого виртуального соединения является сервер, в котором для передачи данных используется TCP-порт с номером 20. Так как инициатор создания TCP-соединения должен заранее знать не только IP-адрес, но и

номер TCP-порта удаленного партнера, то этот номер, полученный ранее клиентом динамически от своей локальной ОС, передается им серверу (при передаче команд RETR, STOR, LIST).

Кроме того, для выполнения приема и передачи данных по этому TCP-соединению и главный процесс клиента, и дочерний процесс сервера порождают свои дочерние процессы. Таким образом, в отличие от обычной модели клиент-сервер (см. п. 4.6.3), в которой клиент есть один процесс, а сервер — 2-уровневое дерево процессов, в FTP-приложении клиент имеет 2-х, а сервер — 3-уровневую структуру. Несмотря на подобное усложнение структур обеих частей приложения, использование отдельных TCP-сое- динений для передачи команд и для передачи данных приносит существенную пользу, так как позволяет существенно упростить алгоритмы программ процессов. Кроме того, управляющее соединение и соединение передачи данных могут использоваться параллельно, что предоставляет пользователю дополнительные возможности. Например, пользователь может прервать своей командой передачу файла.

Полезно сравнить FTP-приложение с рассмотренной в подразд. 6.3 сетевой операционной системой NFS. В отличие от FTP- приложения, каждая часть (клиент или сервер) системы NFS реализована не вне ядра своей ОС, а внутри него. Несмотря на это, система NFS также является сетевым приложением, так как не занимается транспортировкой информации по сети. В отличие от FTP-приложения, система NFS «прозрачна» для пользователя. То есть для того чтобы работать с удаленным файлом, ни от пользователя, ни от программиста, разрабатывающего программу, не требуется выдачи никаких дополнительных команд или системных вызовов. После того как выполнено монтирование удаленной файловой системы, работа с ней выполняется точно так же, как и с локальной ФС.

Кроме того, система NFS отличается от FTP-приложения по своим функциям. В то время как FTP-приложение выполняет «перекачку» файлов целиком, система NFS позволяет пользователям и программам работать с удаленными файлами точно так же, как и с локальными файлами. При этом может быть считан или скорректирован любой фрагмент файла без «перекачки» всего файла.

Так как программная реализация протокола FTP достаточно сложна, то для сокращения длины программы иногда используют

другой, простейший протокол передачи файлов TFTP (Trivial File Transfer Protocol). В отличие от FTP-приложения, TFTP-приложе- ние использует для связи между своими клиентской и серверной частями не несколько параллельных TCP-соединений, а единственный UDP-канал (номер порта сервера — 69). Инициатором передачи файла, как всегда, является клиентская часть приложения. Получив запрос от какой-то программы на своем хосте, клиент посылает серверу сообщение-команду на чтение или запись указанного в команде файла.

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

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

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

К достоинствам подобной загрузки небольших ЭВМ, подключенных к сети, во-первых, относится небольшой объем ПЗУ:

кроме TFTP-клиента оно содержит лишь небольшую программу, реализующую протокол UDP. Во вторых, существенно повышается гибкость всей ВС, элементами которой являются бездисковые хосты, так как для замены программного обеспечения на этих хостах достаточно заменить лишь файл (или файлы) на одном хосте, содержащем TFTP-сервер. Никакие изменения в ПЗУ клиентов при этом не требуются.

8.5.2. Электронная почта

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

Допустим, что Вова, являющийся пользователем хоста kcup.fet.tusur.ru, решил отправить электронное письмо Пете, являющемуся пользователем хоста sapr.fet.tusur.ru. Для того чтобы подобное информационное взаимодействие было возможно, и Вова, и Петя должны иметь каждый свой собственный электронный почтовый ящик — область на носителе ВП, предназначенную для приема почтовых сообщений, присылаемых данному пользователю. Каждый почтовый ящик имеет символьное имя, уникальное для всей сети Internet. Это имя состоит из двух частей, разделенных символом «@» (коммерческое at): справа — DNS-имя того узла сети, на котором находится почтовый ящик, а слева — локальное имя почтового ящика в этом узле.

Внашем примере почтовые ящики имеют имена: vova@mail.ru

иpetja@tusur.ru. Нетрудно заметить, что DNS-имена, входящие в состав указанных имен почтовых ящиков, отличаются от DNS- имен тех хостов, на которых работают пользователи Вова и Петя. Возможны две причины такого несоответствия.

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

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

Во-вторых, даже если почтовый сервер и выполняется на хосте пользователя, DNS-имена самого хоста и почтового сервера могут быть разные. Это обусловлено тем, что делая DNS-запрос, DNS- клиент сопровождает его указанием типа A или MX. Первый тип задается всеми приложениями, за исключением электронной почты, которая использует второй тип (см. подразд. 8.4). Поэтому одному и тому же IP-адресу хоста могут соответствовать два разных DNS-имени.

Вернемся к примеру. На рис. 66 сплошными стрелками показан путь, который проходит сообщение от Вовы до Пети, а пунктирными стрелками показан путь ответного сообщения — от Пети до Вовы. Отправку своего письма Вова начинает с того, что запускает на своем хосте программу — почтовый агент, который является одновременно клиентом двух (не считая DNS) сетевых приложений. Из этих клиентов при отправке письма используется

SMTP-клиент. SMTP (Simple Mail Transfer Protocol) — простой протокол передачи электронной почты. Получив от Вовы через интерфейсную часть сообщение-письмо, а также адрес назначения petja@tusur.ru SMTP-клиент посылает это сообщение SMTP-сер- веру, входящему в состав почтового сервера, имеющего DNS-имя — mail.ru. Естественно, что перед отправкой сообщения SMTP-клиент временно становится DNS-клиентом для того, чтобы получить IP-адрес почтового сервера.

Получив сообщение-письмо, SMTP-сервер передает его SMTP- клиенту, расположенному в этом же почтовом сервере. Далее SMTP-клиент посылает это письмо тому SMTP-серверу, который входит в состав почтового сервера с требуемым DNS-именем — tusur.ru. Получив письмо, SMTP-сервер определяет из него имя

одного из своих почтовых ящиков (petja) и помещает в него письмо. Далее письмо лежит без движения в почтовом ящике до тех пор, пока Петя не захочет его прочитать.

Рис. 66. Пересылка почтовых сообщений между хостами

Для чтения письма Петя запускает почтовый агент на своем хосте, а затем через интерфейсную часть он инициирует клиент

POP3. POP3 (Post Office Protocol) — почтовый протокол версии 3.

В отличие от протокола SMTP, который является протоколом отправки сообщений (от клиента к серверу), протокол POP3 является протоколом приема сообщений (от сервера к клиенту).