Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Мир TCP/IP. Традиционные приложения (часть 2)

С. Д. Рябко

В этой статье цикла1 мы продолжим разговор о традиционных приложениях TCP/IP. Рассмотрев приложения, выполняющие функции удаленного доступа, управления удаленными процессами и передачи файлов2, мы переходим к приложениям, реализующим обмен сообщениями между пользователями. Точнее, к электронной почте.

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

Основополагающими документами, специфицирующими службу электронной почты в Internet, являются RFC 821, определяющий протокол Simple Mail Transfer Protocol, и RFC 822, определяющий формат почтового сообщения.

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

Почта: конверт, письмо, адрес...

Аналогия с обычной почтой явно прослеживается в структурах данных, с которыми работает электронная почта. Сообщение электронной почты (message) состоит из стандартного заголовка (часто именуемого конвертом, envelope) и собственно письма, или тела (body) сообщения.

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

· From (От кого) — почтовый адрес отправителя;

· To (Кому) — список почтовых адресов получателей;

· Subject (Тема) — тема письма (строка в произвольном формате);

· Cc (Копия) — список почтовых адресов получателей копии письма.

Тело письма, в соответствии с RFC 822, включает текст письма в кодировке ASCII.

Адрес в электронной почте обычно состоит из двух основных частей: локального имени и имени домена, разделяемых при помощи символа “@” — локальное_имя@имя_домена.

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

Имя домена не эквивалентно имени конкретного компьютера, пусть даже это имя почтового сервера, ведущего локальную обработку почты. Например, имя домена в моем почтовом адресе — rsd@elvis.ru. В нашей организации существует сервер с именем “elvis”, но обработку почты может вести и не он (или не только он), а почту с именем домена elvis.ru будет получать все множество наших сотрудников, пусть даже зарегистрированных как пользователи других серверов.

Локальное имя rsd для удобства выбрано кратким, хотя при желании и его можно было бы сделать структурированным, например, таким: sergei.ryabko.

Говоря о локальных именах, следует упомянуть об одной интересной возможности — использовании подстановочных имен (я бы применил именно этот термин для перевода английского слова alias — псевдоним). Подстановочные имена применяются для установления множественных соответствий типа “один пользователь — много имен” или “одно имя — много пользователей”.

Множественное именование одного человека может отражать различные аспекты его деятельности. Например, к нашему системному администратору можно обратиться по его “нормальному” имени, а также по ряду “специальных” имен: root, postmaster и т. д. Но главной функцией подстановочных имен является, пожалуй, организация рабочих групп для коллективного обмена почтой. Например, по адресу info@elvis.ru можно обратиться одновременно ко всем сотрудникам нашего предприятия, отвечающим за ключевые направления его деятельности.

Внутренняя организация сервиса электронной почты

Классическая схема почтовой системы показана на рис. 1. Пользователь общается с интерфейсной программой, называемой пользовательским агентом (user agent, UA). Эта программа обычно не занимается пересылкой почтовых сообщений. Ее задачи — сформировать почтовое сообщение для отправки, дать доступ к списку принятых сообщений, обеспечить их чтение, перенаправление, экспорт в файл и т. п. Передачей сообщений занимается так называемый агент передачи сообщений (message transfer agent, MTA). MTA может представлять собой распределенную систему, включающую локальный MTA на компьютерах отправителя и получателя, а также произвольное число промежуточных устройств, почтовых серверов (mail relay, или relay MTA) или шлюзов (mail gateway), обеспечивающих промежуточную ретрансляцию почты. Необходимость введения промежуточных MTA объясняется несколькими причинами. Во-первых, локальный MTA может не обладать необходимыми ресурсами для хранения и маршрутизации почтовой информации. Во-вторых, специализированную систему, которой все локальные системы “перепоручали” бы определенные функции, легче настраивать, чем множество локальных систем. Наконец, в-третьих, промежуточные MTA выполняют роль шлюзов между различными почтовыми системами.

Механизм распространения почты таков. Сообщение формируется при помощи агента UA отправителя. После того как пользователь отдает команду на отправку почты, почтовая система при необходимости обращается к локальной (в пределах домена) базе данных подстановочных имен и обрабатывает списки получателей почты, заменяя подстановочные на полные имена получателей. Затем сообщение помещается в так называемую очередь отправляемой почты (spool). Локальный агент MTA, периодически (или в зависимости от реализации по вызову агента UA) просматривая очередь на отправку, “берет” почту из этой очереди и передает ее прямо или при помощи некоторого множества промежуточных почтовых серверов локальному агенту MTA получателя.

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

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

SMTP как коммуникационный протокол

SMTP, как и всякий коммуникационный протокол, реализует некоторый диалог распределенных систем. Не имея возможности обсудить все детально, для понимания общей логики протокола приведем только “слова” такого диалога.

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

HELO — определяет начало диалога (от hello).

MAIL — определяет отправителя почты.

RCPT — определяет получателя почты

(от recipient).

DATA — показывает, что за ней следует тело

сообщения.

QUIT — определяет завершение диалога.

Диалог ведется через соединение Telnet на порт 25. Приведем пример диалога для передачи почты:

Клиент: telnet <имя_почтового_сервера_домена> 25

Сервер: 220 <имя_почтового_сервера_домена> Sendmail ready.

Клиент: HELO <имя_хоста-отправителя>

Сервер: 250 <имя_почтового_сервера_домена> pleased to meet you.

Клиент: MAIL From: <адрес_отправителя>

Сервер: 250 <адрес_отправителя>

Клиент: RCPT To: <адрес_получателя>

Сервер: 250 <адрес_получателя>

Клиент: DATA

Сервер: 354 Enter mail.

Клиент: <передача данных тела сообщения>

Сервер: 250 Mail accepted

Клиент: QUIT

Сервер: 221 <имя_почтового_сервера_домена> delivering mail

Иерархия доменов и маршрутизация электронной почты

Для обеспечения маршрутизации на уровне устройств сети в Internet существует служба DNS (Domain Name System, система имен доменов). Эта служба актуальна не только для электронной почты, но и для других приложений.

DNS организована как ориентированная на пользователя система именования, которая может использоваться в ряде прикладных систем наряду с системой адресов протокола IP. В рамках этой системы каждому хосту может быть присвоено иерархическое, интерпретируемое справа налево имя, легко понимаемое и запоминаемое пользователем. Каждая секция имени домена называется меткой (label), каждый суффикс имени также является именем домена. В примере, приведенном выше, имя домена elvis.ru состояло из двух меток — elvis и ru. Домен elvis.ru определяет, условно говоря, сеть нашего предприятия (вовсе не обязательно — локальную); ru, в свою очередь, также есть имя домена, в состав которого входят все российские хосты, имена которых завершает эта метка.

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

Домены, поименованные по организационному признаку, кодируются обычно трехбуквенными именами:

com — коммерческие организации;

edu — учебные заведения;

gov — правительственные организации;

mil — военные организации;

net — крупные центры поддержания сети;

int — международные организации;

org — прочие организации;

arpa — временное (устаревшее) имя домена

сети ARPA.

Географические имена доменов кодируются двухбуквенным кодом страны, например, ru — географическое имя российского домена, us — домена США, uk — домена Великобритании и т. д.

Необходимо понимать, что дерево доменов DNS, показанное на рис. 2, содержит “под собой” связанную систему серверов DNS, отражающую структуру этого дерева.

Маршрутизация электронной почты и других приложений, основанная на DNS, обеспечивается следующим образом. Хост- (или процесс-) отправитель, которому известно имя домена- (или хоста-) получателя, но не известен, например, адрес IP получателя, обращается к ближайшему (в смысле организационной иерархии) серверу DNS. Этот сервер распознает имя домена и возвращает требуемую информацию (в нашем примере адрес IP получателя) или, не найдя такого имени у себя, обращается к вышестоящему серверу, или (в терминах математического описания древовидных иерархических структур) к серверу-родителю. Вышестоящий сервер может выяснить, что искомый домен находится в его ведении или в ведении его потомков и обратиться к ним за искомой информацией. Если же ни у этого сервера, ни у его потомков требуемой информации нет, то сервер опять-таки обращается к своему родителю — и так до тех пор, пока информация не будет найдена или DNS не убедится, что искомый домен в сети отсутствует. Обращение к DNS эффективно обслуживается уже в силу древовидной структуры информации, однако для DNS, как огромной распределенной базы данных, принимается ряд программно-аппаратных мер оптимизации (индексирование, кэширование информации и проч.). Поэтому, хотя и понимаешь, как это делается, но всякий раз поражаешься тому, как буквально через 2-3 мин после (например, ошибочного) ввода имени хоста, Internet отвечает, что такого хоста нет. Ведь чтобы убедиться в этом, нужно, условно говоря, “просмотреть список” более чем из 30 млн компьютеров!

Поскольку DNS — неспециализированная система, работающая в интересах множества различных приложений, она может возвращать им различную информацию. Это оправдано хотя бы потому, что в рамках домена elvis.ru сервис файлового доступа (FTP) и сервис, например, электронной почты могут предоставлять существенно различные устройства. Запросы к DNS выполняются под управлением своего протокола. Мы опишем только информацию, предоставляемую службой DNS (табл. 1).

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

Нужно отметить, что служба DNS организована достаточно сложно. Например, в ней имеют место множественные отношения, когда один хост, предоставляя различные сервисы, может иметь различные имена. Другой пример использования множественности имен — поддержание исторической традиции именования доменов, в силу которой к нашему домену можно обратиться и по имени elvis.msk.su, хотя суффикс “su” утратил смысл определения административного региона.

Развитие систем электронной почты

Нужно сказать, что электронная почта подвергалась боўльшему, по сравнению с прочими традиционными приложениями TCP/IP, технологическому прессингу со стороны пользователей, желающих расширить возможности почтовых систем. Это привело к более интенсивным доработкам почтовых стандартов.

Изменения конверта

Часть команд SMTP прямо транслирует отдельные строки заголовка сообщения (конверта). Расширение таких команд и соответствующее изменение заголовка описаны в так называемом extended SMTP (ESMTP), который совместим со старым протоколом SMTP.

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

Клиент: telnet <имя_почтового_сервера_домена> 25

Сервер: 220-<имя_почтового_сервера_домена> Sendmail ready.

250 ESMTP spoken here

В ESMTP запрос почтового сервиса HELO заменен на запрос расширенного сервиса EHLO, в ответ на который почтовая система ESMTP выдаст набор поддерживаемых сервисов. Например:

Клиент: EHLO <имя_хоста-отправителя>

Сервер: 250-<имя_почтового_сервера_домена>

250-8BITMIME

250-EXPN

250-HELP

250 SIZE

Приведенный ответ следует интерпретировать следующим образом. Сервер говорит, что поддерживает команды EXPN (expand, расширение списка адресов) и HELP (помощь), являющиеся факультативными командами протокола SMTP (RFC 821). Прочие ответы содержат список сервисов, поддерживаемых сервером. Например, SIZE разрешает указывать для контроля размер тела сообщения в байтах в строке Mail from.

Изменения форматов данных в теле сообщения: MIME

Стандарт Multipurpose Internet Mail Extensions (MIME), предложенный в RFC 1521, определяет расширения форматов данных тела сообщения по сравнению с RFC 822, допускавшим только строки ASCII. MIME реализуется только на пользовательских частях системы (UA), оставаясь полностью прозрачным для всех существующих агентов MTA. В табл. 2 перечислены типы данных, поддерживаемые MIME.

Альтернативные кодировки в заголовке сообщения

Последним новшеством, о котором хотелось бы упомянуть в связи с развитием почтовых систем, является возможность использования различных кодировок в заголовках сообщения. Она призвана, прежде всего, устранить недоразумения, связанные с национальными наборами символов. Документ RFC 1152 предлагает для включения таких символов использовать символьную строку следующей семантики: =?набор_символов?кодировка?кодированный_текст

Параметр “набор_символов” принимает два значения: us-ascii и iso-8859-x, где x — цифра. Параметр “кодировка” принимает значения “Q” (quoted-printable) — кодировка восьмибитовых символов при помощи шестнадцатеричной записи их числового значения, и “B” — кодировка base-64, отводящая на символ 6 битов и позволяющая в последовательности из 3 байт передать четыре символа.

SMTP и X.400

Решением, представляющим альтернативу SMTP, является рекомендация МККТТ X.400 (стандарт ISO IS 10021-1), для краткости повсеместно называемая X.400.

В конце 80-х — начале 90-х годов много копий было сломано в спорах о том, на какой из стандартов — SMTP или X.400 — следует ориентироваться при выборе почтовой системы. Сторонники X.400 указывали на более широкие возможности, с чувством описанные в этой спецификации. Правда, (в то время) им тут же приходилось оговариваться, что сколько-нибудь полных реализаций этой спецификации нет. Сейчас, сравнивая почтовые системы, развивающиеся по линии SMTP, и системы X.400, следует сказать, что возможности тех и других систем в части многоформатности (мультимедийности) практически сравниваются. При этом X.400 (точнее, серия связанных рекомендаций X.400 — X.430) сохраняет преимущество в области возможностей административного характера, таких, как доставка в заданные сроки, индикация разрешающих пользователей, замена устаревших сообщений и т. д. Эти возможности не всегда присутствуют в продуктах линии X.400 и не предусматриваются в продуктах линии SMTP. Вообще же это вопрос философский — нужны ли эти возможности в почтовой системе или они должны быть отнесены в веўдение других приложений, например систем управления документами?


распечатать статью




  
5 '1996
СОДЕРЖАНИЕ

колонка редактора

• Телефония через Internet: новое поле битвы?

локальные сети

• Беспроводные ЛВС: вчера, сегодня и завтра

• Недорогие коммутаторы Ethernet

• Мультимедиа и ЛВС

• Оптические дисковые автоматы

корпоративные сети

• Watchdog кусается

• "Плоды" большого дерева NDS

• Необычные, но невыдуманные истории

услуги сетей связи

• Категории служб в сетях АТМ

• Будущее карманных устройств связи

• Передача данных по сетям сотовой связи

• Обзор аппаратуры SDH

• Связные заметки с выставки CeBIT

интернет и интрасети

• Мир TCP/IP. Традиционные приложения (часть 2)

• Почтовый пакет компании Демос

• Списки рассылки: артерии информации

• Таблицы на Web

• Ваш след в Web

приложения клиент-сервер

• Связующее ПО. "Вождение" приложений по сети

• Связующее ПО. Смена веры

защита данных

• Управляемые ИБП: защита предприятия

• Системы firewall: можете спать спокойно

новые продукты

• Сетевые принтеры: новинки на Comtek’96, Многофункциональность System 5000, Накопители TRAVAN TR-4 фирмы Seagate



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх