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

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

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

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

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


Rambler's Top100

  

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

С.Д. Рябко

В этой и следующей статьях цикла 1 мы поговорим о традиционных приложениях TCP/IP. Достаточно трудно строго определить круг этих приложений. Например, о WWW уже, наверное, можно говорить, как о традиционном приложении TCP/IP. Поэтому искусственно ограничим круг традиционных приложений теми, которые подготовлены в "ранних" (выпущенных до середины 80-х годов) документах RFC и выполняют базовые функции: удаленный доступ и управление удаленными процессами, передачу файлов, обмен сообщениями между пользователями 2.

Почти каждый вузовский лектор, рассказывая о коммуникационных протоколах, в той или иной форме употребит фразу о том, что минимальная функциональность, необходимая для передачи информации по сети, обеспечивается тремя нижними уровнями модели ISO. Это, вероятно, так. Однако далее мы увидим, что даже над транспортным уровнем для функционирования приложения приходится надстраивать очень замысловатые конструкции.

Удаленный доступ

***

Протокол Telnet

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

Telnet, как протокол, предоставляет механизмы для решения трех основных задач. Во-первых, он определяет интерфейс, называемый виртуальным сетевым терминалом (network virtual terminal, NVT), который абстрагирует аппаратную реализацию сервера и клиента. И клиент, и сервер "отвязываются" от собственных аппаратных особенностей, договариваясь о свободном формате данных. Во-вторых, Telnet предусматривает механизм конфигурирования ряда параметров (опций). Примером опции может быть 7- или 8-битовая кодировка данных. И, наконец, в-третьих, Telnet устанавливает и поддерживает симметричное терминальное соединение. Это означает, что как клиент Telnet, так и сервер Telnet имеют одинаковые права по инициации передачи данных, согласованию опций и т. д.

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

Архитектурное решение о размещении сервиса Telnet именно на прикладном уровне (а, скажем, не в ядре ОС) имеет свои преимущества и недостатки. Главное преимущество - реализационная взаимонезависимость ОС и сервиса Telnet, а недостаток - некоторая потеря в эффективности, которая, впрочем, для преимущественно интерактивных текстовых приложений Telnet неощутима.

Отметим, что системы "Локальный терминал" и "Локальный сервер", показанные на рис.1, в современной практике часто могут быть единой аппаратно-программной системой. Однако даже в этом случае рассмотрение терминала, как отдельного устройства стандартного ввода/вывода, достаточно удобно для понимания работы протокола Telnet в целом.

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

При попытке организации терминальных соединений в реальных сетях, где в качестве оконечного оборудования на различных концах соединения могут применяться существенно различные аппаратные платформы, возникают конфликты, связанные с интерпретацией символьных кодов. Например, одни текстовые терминалы в качестве символа, переводящего строку, используют специальный код CR (carriage return - возврат каретки), другие - код LF (line feed - перевод строки), третьи - пару CR-LF.

Решением проблемы служит упомянутый выше интерфейс NVT, являющийся "прослойкой" между локальным терминалом и локальным сервером (рис. 2), которая преобразует управляющие символы в приемлемый для удаленного оконечного оборудования вид.

Интерфейс NVT обеспечивает интерпретацию указанных в табл. 1 символов управления. Кроме того в качестве кода перевода строки он формирует последовательность CR-LF вне зависимости от кода, который был сформирован клавиатурой конкретного терминала.

Управление удаленными процессами

Другой функцией NVT является управление удаленным процессом. Эта задача также может конфликтовать с аппаратно-программными системами клиентов и серверов. Вообразите, что вам необходимо прервать процесс на сервере, не прерывая терминального сеанса с ним. Для этого вы используете стандартный код прерывания процесса Ctrl-C. Однако ваша локальная терминальная система сама воспринимает этот код как код прерывания выполнения задачи. Что же произойдет? Вы прервете локальную задачу, т. е. оборвете сеанс работы с сервером, а процесс на сервере будет продолжать работать!

Во избежание подобных конфликтов NVT назначает следующие команды управления: IP, AO, AYT, EC, EL, SYNCH, BRK (табл. 2) Для передачи таких команд Telnet использует так называемые составные последовательности (escape sequences), состоящие из двух кодов. Первым идет символ с десятичным кодом 255, который обычно при нажатии клавишей клавиатурами не генерируется. Этот код называют IAC (Interpret As Command). Вторым следует код команды.

Часть команд, перечисленных в табл. 2, используется для управления удаленным процессом, часть - для согласования опций Telnet.

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

Чтобы выйти из подобных тупиковых ситуаций, команда управления процессом всегда сопровождается командой SYNCH, очищающей буфер от обычных (не срочных) данных и доводящей команду управления до сервера Telnet, который может прекратить существование "зациклившегося" процесса.

Опции Telnet

Мы говорили выше о том, что расположение Telnet на прикладном уровне позволяет "развязать" реализации Telnet и ОС и, тем самым, обеспечивает дополнительную гибкость в модификациях и наращивании функциональности этого протокола. В первую очередь это касается опций Telnet, представляющих собой достаточно интересную и сложную конструкцию, которая позволяет клиенту и серверу "на ходу" реконфигурировать параметры соединения. Набор регулируемых параметров достаточно широк и включает кодировку данных (7- или 8-битовая), режим передачи (дуплексный или полудуплексный), тип терминала и т. д. Некоторые из опций перечислены в табл. 3.

Процедура согласования опций выполнена в "неограничительной" манере, очень характерной для протоколов TCP/IP. Прежде всего нужно отметить следующее: хотя в Telnet инициатива по организации соединения принадлежит клиенту, протокол согласования опций симметричен в том смысле, что сервер, как и клиент, может обладать инициативой в установлении определенных опций. Кроме того, механизм согласования опций допускает работу на разных концах соединения версий протокола Telnet, снабженных различными наборами опций (вплоть до того, что один из партнеров не владеет никакими опциями и базируется только на NVT).

Сервис удаленного доступа Rlogin

Развитием терминального доступа в ряде систем UNIX является удаленный доступ Rlogin (remote login). Rlogin отличается от Telnet более тесной связью с ОС. В частности, для Rlogin характерно распознавание прав доступа пользователей (он не требует повторного ввода пароля при последовательном доступе с одного хоста к другому, если пользователь корректно выполнил операцию входа на первый из доступных ему хостов). Кроме того, Rlogin может использовать стандартный ввод/вывод ОС удаленных хостов; интерпретировать стандартные ошибки ОС; распознавать параметры настройки оболочки (environment) как на локальном, так и на удаленном хосте; экспортировать часть этих параметров с локального на удаленный хост и т. д.

Сильные и слабые стороны удаленного доступа

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

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

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

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

Файловый доступ

***

Протокол FTP

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

Не так все просто

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

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

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

Протокол FTP (File Transfer Protocol) обеспечивает:

* программный доступ к удаленным файлам: для работы программ предоставляется командный интерфейс;

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

* преобразование данных: FTP позволяет клиенту описать формат хранимых данных (например, специфицировать кодировку символов для текстов);

* аутентификацию и авторизацию: FTP проверяет имя пользователя, его пароль и права доступа.

FTP изнутри

Сервис протокола FTP, основывающийся на транспорте TCP, поддерживает множество конкурентных FTP-соединений c различными клиентами. В свою очередь, всякое FTP-соединение "внутри" состоит из двух соединений (рис. 3): управляющего (control connection) и передачи данных (data transfer connection). Управляющее соединение поддерживается от начала до конца сеанса связи с клиентом. Соединение передачи данных динамически устанавливается на время передачи каждого файла. Обычно оба соединения поддерживаются двумя различными процессами ОС (так происходит в UNIX-системах; на ПК все может быть реализовано проще).

Для поддержания управляющего соединения FTP не "изобретает велосипед": для его организации используется протокол Telnet в рамках NVT. Механизм приписания (связывания) портов 3 различен для клиента и сервера. FTP-сервер работает на известных (well-known) портах 21 (управляющее соединение) и 20 (соединение передачи данных). FTP-клиент может выбрать и согласовать на локальной клиентской машине номера портов, что позволяет клиенту поддерживать несколько FTP-соединений с одним сервером. (Этот механизм работает для UNIX-систем и не всегда поддерживается, например, на ПК.)

Команды протокола FTP

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

Ответы сервера - это текстовые строки, для удобства использования в программах начинающиеся с трехцифрового кода ответа, вслед за которым идет текст, раскрывающий значение кода. Трехцифровой код ответа интерпретируется поразрядно. Первая цифра ответственна за общий тип ответа: положительный (1-3) или отрицательный (4-5), промежуточный (1,2,4) или окончательный (3,5); вторая - указывает на причину ошибки; третья - конкретизирует событие.

Интерактивный FTP

Для пользователя интерактивный FTP выглядит как отдельная командная оболочка. При вызове протокола FTP с командной строки появляется приглашение FTP>, после которого могут вводиться различные команды. В этой статье нет места для описания полного набора команд интерактивного FTP (наиболее употребительные команды представлены в табл. 5), мы ограничимся рассказом о важнейших из них.

Для получения информации о всех (или одной) команде FTP необходимо ввести команду help <имя_команды>. Если help вызвана без параметров, то выводится список команд FTP; если указано имя команды, то следует очень краткое пояснение о ее назначении.

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

Анонимный FTP

В Internet существует весьма демократичный и распространенный сервис, называемый анонимным FTP (Anonymous FTP). Как правило, он обеспечивает файловый доступ к серверам с бесплатной (freeware), публично-доступной (public domain) или условно-продаваемой (shareware) информацией. Вы не можете быть зарегистрированы на таком сервере как пользователь (слишком много пользователей пришлось бы регистрировать), поэтому вам предлагают войти под условным именем Anonymous и ввести в качестве пароля адрес вашей электронной почты (подлинность которого не всегда контролируется), после чего с этим сервером можно беспрепятственно обмениваться информацией.

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

Протокол TFTP

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

Соответствующий сервис в семействе TCP/IP поставляет другой, более простой протокол - TFTP (Trivial File Transfer Protocol - тривиальный протокол передачи файлов).

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

В качестве транспортного протокола TFTP используется UDP.

Сетевая файловая система

***

Протокол NFS

Развитием файловых служб в TCP/IP является сетевая файловая система NFS (Network File System) - протокол, разработанный фирмой Sun Microsystems. Он обеспечивает прозрачный разделяемый доступ к файлам по сети, доступ в режиме on-line. В клиентской системе NFS реализуется таким образом, что пользователь (приложение) практически не различает локальные и удаленные файлы. Когда клиентское приложение обращается к файлу (рис. 5), ОС определяет к локальному или сетевому файлу обращается клиент, и переадресует управление соответственно локальной или сетевой файловой системе.

Удаленный вызов процедур и преобразование данных

Сетевая файловая система NFS реализуется одновременно с двумя другими протоколами - удаленного вызова процедур (Remote Procedure Call, RPC) и внешнего представления данных (eXternal Data Representation, XDR). Такое функциональное деление позволяет разработчику приложений независимо обращаться к каждому из протоколов и использовать только необходимую функциональность. В сумме же разработчик получает чрезвычайно мощный инструментарий для создания распределенных систем.

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

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


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




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

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

• Всемирная либеральная революция в электросвязи

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

• Система сигнализации № 7

• CTI: TAPI или TSAPI?

• Стандарт DECT: новые возможности для операторов сетей связи

• Широковещательные системы передачи данных домашним ПК

• Эволюция GSM

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

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

• Какой вариант HTML "реальнее"?

• Южная Московская Опорная Сеть

• ПК для всего мира

• Как украсить страницу Web

• Планирование узла Web

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

• Тестирование модемов V.34

• Многопротокольная маршрутизация в сетях АТМ

• Маршрутизация в сетях АТМ. Кто победит?

• Удаленный доступ по TCP/IP

• Средства удаленного доступа

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

• Сетевые принтеры

• Стековые концентраторы

• Законы энтропии и сеть

• Системная политика - ключ к эффективному управлению

• Применение профилей пользователей в Windows 95

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

• Размышления об электронных платежах

• Чувство безопасности

• "Скорпион" защищает сеть

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

• Недорогой маршрутизатор Vgate фирмы RND, Lotus Notes версии 4.0, Компьютеры UltraSPARC, Коммутаторы IGX фирмы StrataCom, Bay Networks всерьез берется за АТМ, Вперед по дороге АТМ



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