Основные подходы к реализации взаимодействия сетей

Основные проблемы при организации взаимодействия различных сетей связаны с тем, что эти сети используют различные стеки коммуникационных протоколов. В каждом конкретном стеке протоколов, будь то стек DoD или Novell NetWare, средства, реализующие какой-либо уровень, обеспечивают интерфейс для вышележащего уровня своей системы и пользуются услугами интерфейсных функций нижележащего уровня. Например, средства реализации протокола Novell IPX в сервере предоставляют интерфейсные услуги протоколу NCP для приема запросов от рабочих станций и пересылки им ответов. В свою очередь протокол IPX пользуется интерфейсными функциями драйвера сетевого адаптера Ethernet, чтобы передать пакет для отправки в сеть.

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

К сожалению, в реальном мире компьютерных сетей существует несколько стеков протоколов, уже завоевавших свое место под солнцем и не собирающихся его уступать. Например, если на предприятии используются мейнфреймы IBM, то они скорее всего используют протоколы сетевой архитектуры SNA и аппаратуру Token Ring. Использование компьютеров DEC с операционной системой VAX означает, что используются протоколы DECnet и Ethernet. Сети локальных компьютеров используют чаще всего протоколы Novell NetWare, Banyan VINES, IBM LAN Server или Microsoft LAN Manager с аппаратурой Ethernet, Token Ring или ARCnet.

Существование многих стеков протоколов не вносит никаких проблем до тех пор, пока не появляется потребность в их взаимодействии, то есть потребность в доступе пользователей сети NetWare к мейнфрейму IBM или пользователей графических рабочих станций UNIX к компьютеру VAX. В этих случаях проявляется несовместимость близких по назначению, но различных по форматам данных и алгоритмам протоколов.

Общность различных стеков протоколов проявляется только на нижних уровнях - физическом и канальном. Здесь в настоящее время почти нет проблем для взаимодействия, так как большинство стеков могут использовать общие протоколы Ethernet, Token Ring, FDDI. Исключение составляют только мейнфреймы IBM, которые на нижнем уровне в основном используют протоколы типа ведущий-ведомый с синхронной передачей данных, ориентированные на иерархическую соподчиненную структуру мейнфрейм - групповой контроллер - терминалы. Да и соединение двух компьютеров, использующих на нижнем уровне различные протоколы, а на верхних - одинаковые не составляет проблемы - эта задача решается аппаратно с помощью транслирующего моста или маршрутизатора.

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

Если рассмотреть наиболее часто используемый в сетях сервис, а именно, файловый сервис, то различия в протоколах файлового сервиса в первую очередь связаны с различиями структур файловых систем. Например, пользователю MS-DOS непривычны приемы монтирования файловой системы UNIX в одно дерево, он хочет работать с разрозненными файловыми системами отдельных носителей, отображенными на буквы английского алфавита. Команды, используемые при работе с различными файловыми системами, также различны как по названию, так и по содержанию. Кроме того, даже для одной файловой системы в различных операционных системах предусмотрены различные удаленные сервисы. В ОС UNIX можно работать с удаленной файловой системой с помощью символьных команд протокола прикладного уровня FTP, переписывая файлы с удаленной машины на локальную по одному, а можно работать с протоколом NFS, который обеспечивает монтирование удаленной системы в локальную и требует других команд и приемов. Поэтому проблемы, возникающие на верхних уровнях, гораздо сложнее, чем проблемы замены заголовка пакета на канальном уровне.

Рис. 3.13. Два основных варианта согласования протоколов
а - трансляция протоколов; б - мультиплексирование стеков протоколов

Для организации взаимодействия различных сетей в настоящее время используется два подхода.

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

Второй подход заключается в том, что в операционные системы серверов и рабочих станций встраиваются несколько мирно сосуществующих наиболее популярных стеков протоколов. Такая технология получила название мультиплексирования стеков протоколов. За счет ее использования либо клиентские запросы используют стек протоколов той сети, к которой относятся нужные серверы, либо серверы подключают стек протоколов, соответствующий поступившему клиентскому запросу (рисунок 3.13,б).

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

Шлюзы

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

Рисунок 3.14 иллюстрирует принцип функционирования шлюза. В показанном примере шлюз, размещенный на компьютере 2, согласовывает протоколы клиентского компьютера 1 сети А с протоколами серверного компьютера 3 сети В. Допустим, что две сети используют полностью отличающиеся стеки протоколов. Как видно из рисунка, в шлюзе реализованы оба стека протоколов.

Рис. 3.14. Принципы функционирования шлюза

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

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

Date: 2016-05-25; view: 559; Нарушение авторских прав