Коммуникационная cеть — система, состоящая из объектов, осуществляющих функции генерации, преобразования, хранения и потребления продукта, называемых пунктами (узлами) сети, и линий передачи (связей, коммуникаций, соединений), осуществляющих передачу продукта между пунктами.
Отличительная особенность коммуникационной сети — большие расстояния между пунктами по сравнению с геометрическими размерами участков пространства, занимаемых пунктами. В качестве продукта могут фигурировать информация, энергия, масса, и соответственно различают группы сетей информационных, энергетических, вещественных. В группах сетей возможно разделение на подгруппы. Так, среди вещественных сетей могут быть выделены сети транспортные, водопроводные, производственные и др. При функциональном проектировании сетей решаются задачи синтеза топологии, распределения продукта по узлам сети, а при конструкторском проектировании выполняются размещение пунктов в пространстве и проведение (трассировка) соединений.
Информационная сеть — коммуникационная сеть, в которой продуктом генерирования, переработки, хранения и использования является информация.
Вычислительная (компьютерная) сеть — информационная сеть, в состав которой входит вычислительное оборудование. Компонентами вычислительной сети могут быть ЭВМ и периферийные устройства, являющиеся источниками и приемниками данных, передаваемых по сети. Эти компоненты составляют оконечное оборудование данных (ООД или DTE — Data Terminal Equipment). В качестве ООД могут выступать ЭВМ, принтеры, плоттеры и другое вычислительное, измерительное и исполнительное оборудование автоматических и автоматизированных систем. Собственно пересылка данных происходит с помощью сред и средств, объединяемых под названием среда передачи данных.
Глобальная вычислительная сеть объединяет множество локальных сетей и сотни тысяч — миллионы разнотипных ЭВМ по всему миру, физическая линия связи — оптокабель или космическая радиолиния связи.
Локальная вычислительная сеть (ЛВС) — система связи отдельно расположенных ЭВМ на относительно небольшом расстоянии (обычно в пределах помещении и/или этажа здания); обычно объединяет до нескольких десятков (чаще однотипных) компьютеров, физическая линия связи — «витая пара» или коаксиальный кабель. В последее время для связи между узлами все чаще используютсябеспроводные технологии стандартов 802.11.
Корпоративная вычислительная сеть — локальная вычислительная сеть (крупной) организации, работающая на протоколах Интернет (стек TCP/IP) и использующая сервисы Интернет. При непосредственном подключении к глобальной сети — еще и телекоммуникационную среду Интернета.
Рабочая группа (workgroup) — набор компьютеров, объединенных одним именем для работы с общими сетевыми ресурсами (директории и файлы, принтеры и т.п.).
Домен (domain) — определенная администратором сети совокупность компьютеров, использующихединую базу данных и систему защиты; каждый домен имеет уникальное имя (см. также DNS).
Узел (host) — подключенное к сети устройство (обычно компьютер), идентифицируемое собственнымадресом (например, ip-адрес - это уникальное в пределах сети 32-разрядное двоичное число)
Трафик (traffic) — поток сообщений в разделяемой среде передачи данных, часто используется для грубой оценки уровня использования передающей среды (тяжелый, средний, легкий трафик).
Топология (topology) сети — физическая конфигурация машин в сети.
Маршрутизация — процесс определения (оптимального) пути доступа к объектам (компьютерам) сети.
Пакет, кадр, сообщение, датаграмма — единица передаваемой по сети информации, определенное количество байт, сгруппированное вместе и посылаемое одновременно. То или иное наименование применяется в контексте описания различных сетевых уровней.
Сетевая архитектура — концепция, представляющая логическую, функциональную и физическую организацию технических и программных средств сети и определяющая основные элементы информационной сети, характер и топологию взаимодействия этих элементов.
Протокол — это набор семантических и синтаксических правил, определяющий поведение функциональных блоков сети при передаче данных. Другими словами, протокол — это совокупность соглашений относительно способа представления данных, обеспечивающего их передачу в нужных направлениях и правильную интерпретацию данных всеми участниками процесса информационного обмена.
Программное обеспечение компьютерных сетей — комплекс программ, поддерживающий функции обмена информацией между отдельно расположенными ЭВМ. В настоящее время программное обеспечение компьютерных сетей обычно является (иногда опционально устанавливаемой) составной часть операционных систем.
Понятие открытой системы. Модель OSI. Стеки протоколов
Информационный обмен — процесс многофункциональный. Родственные функции группируются по назначению и эти группы называют "уровнями взаимодействия". Унификация уровней позволяет создавать гетерогенные сети со сложной топологией. В основе унификации — понятие эталонной сетевой модели. Модель как таковая лишь описывает порядок сетевого взаимодействия, который реализуется в виде стека протоколов.
Модель OSI
Стеки протоколов
Модель OSI
Обмен информацией между компьютерами, объединенными в сеть, очень сложная задача. Это связано с тем, что существует много производителей аппаратных и программных средств вычислительных систем. Единственный выход — унифицировать средства сопряжения систем, а именно использовать открытые системы. Открытая система взаимодействует с другими системами на основе единых общедоступных стандартов и спецификаций.
В 1984г. Международная Организация по Стандартизации (ISO) представила индустриальный стандарт — модель взаимодействия открытых систем (Open System Interconnection Reference Model — OSI/RM, в советской литературе — ЭМВОС), чтобы помочь поставщикам создавать совместимые сетевые аппаратные и программные средства. В соответствии с этой моделью выделяются следующие уровни (рис.1):
Рис. 1. Эталонная модель OSI
физический (Physical);
канальный (Data Link);
сетевой (Network);
транспортный (Transport);
сеансовый (Session);
представительский (Presentation) ;
прикладной (Application).
В соответствии с эталонной моделью OSI эти уровни взаимодействуют так, как показано на рис. 2. Таким образом, сложная задача обмена информацией между компьютерами в сети разбивается на ряд относительно независимых и менее сложных подзадач взаимодействия между смежными уровнями.
Рис. 2. Взаимодействие между уровнями OSI
Связь между уровнями двух сетевых узлов (горизонтальное взаимодействие) выполняется в соответствии с унифицированными правилами — протоколами взаимодействия
В автономной системе передача данных между уровнями (вертикальное взимодействие) реализуется через интерфейсы API
Границу между сеансовым и транспортным уровнями можно рассматривать как границу между протоколами прикладного уровня и протоколами низших уровней. Если прикладной, представительный и сеансовый уровни обеспечивают прикладные процессы сеанса взаимодействия, то четыре низших уровня решают проблемы транспортировки данных.
Два самых низших уровня — физический и канальный — реализуются аппаратными и программными средствами, остальные пять более высоких уровней реализуются, как правило, программными средствами.
При передаче информации от прикладного процесса в сеть на физический уровень происходит ее обработка, которая заключается в разбиении передаваемых данных на отдельные блоки, преобразовании формы представления или кодировки данных в блоке и добавлении к каждому блокузаголовка (header) соответствующего уровня (см. пример). Каждый заголовок характеризует используемый протокол обработки данных, причем каждый уровень воспринимает в качестве данных весь блок, полученный от предыдущего уровня, включая присоединенный заголовок. Такое построение эталонной модели позволяет заложить (инкапсулировать) в каждый передаваемый по физической среде информационный блок сведения, необходимые для выбора последовательности протоколов для осуществления обратных преобразований на принимающей информацию стороне.
Физический уровень
Этот уровень определяет механические, электрические, процедурные и функциональные характеристики установления, поддержания и размыкания физического соединения между конечными системами. Физический уровень определяет такие характеристики соединения, как уровни напряжений, синхронизацию и физическую скорость передачи данных, максимальные расстояния передачи, конструктивные параметры разъемов и другие аналогичные характеристики. Известные стандарты RS-232-C, V.24 и IEEE 802.3 (Ethernet).
Канальный уровень
Канальный уровень (уровень звена данных, информационно-канальный уровень) отвечает за надежную передачу данных через физический канал, а именно:
обеспечивает физическую адресацию (в отличие от сетевой или логической адресации);
обеспечивает обнаружение ошибок в передаче и восстановление данных;
отслеживает топологию сети и обеспечивает дисциплину использования сетевого канала конечной системой;
обеспечивает уведомление о неисправностях;
обеспечивает упорядоченную доставку блоков данных и управление потоком информации.
Для ЛВС канальный уровень разбивается на два подуровня:
LLC (Logical Link Control) — обеспечивает управление логическим звеном, т.е. собственно функции канального уровня;
MAC (Media Access Control) — обеспечивает специальные методы доступа к среде распространения.
Сетевой уровень
Этот уровень обеспечивает возможность соединения и выбор маршрута между двумя конечными системами, подключенными к разным подсетям (сегментам), которые могут быть разделены множеством подсетей и могут находиться в разных географических пунктах. Протоколы маршрутизации позволяют сети из маршрутизаторов выбирать оптимальные маршруты через связанные между собой подсети.
Транспортный уровень
Транспортный уровень обеспечивает высшим уровням услуги по транспортировке данных, а именно:
обеспечивает надежную транспортировку данных через объединенную сеть;
обеспечивает механизмы для установки, поддержания и упорядоченного завершения действия виртуальных каналов;
обеспечивает обнаружение и устранение неисправностей транспортировки;
следит за тем, чтобы конечная система не была перегружена слишком большим количеством данных.
Другими словами, транспортный уровень обеспечивает интерфейс между процессами и сетью, устанавливает логические каналы между процессами и обеспечивает передачу по этим каналам информационных блоков. Эти логические каналы называются транспортными.
Сеансовый уровень
Сеансовый уровень реализует установление, поддержку и завершение сеанса взаимодействия между прикладными процессами абонентов. Сеансовый уровень синхронизирует диалог между объектами представительного уровня , определяет точки синхронизации для промежуточного контроля и восстановления при передаче файлов. Этот уровень также позволяет производить обмен данными в режиме, заданном прикладной программой, или предоставляет возможность выбора режима обмена.
Кроме основной функции управления диалогом сеансовый уровень предоставляет средства для выбора класса услуг и уведомления об исключительных ситуациях (проблемах сеансового, представительного и прикладного уровней).
Представительный уровень
Представительный уровень (уровень представления данных) определяет синтаксис, форматы и структуры представления передаваемых данных (но не затрагивает семантику, значение данных). Для того, чтобы информация, посылаемая из прикладного уровня одной системы, была читаемой на прикладном уровне другой системы, представительный уровень осуществляет трансляцию между известными форматами представления информации за счет использования унифицированного формата представления информации.
Таким образом, этот уровень обеспечивает служебные операции, выбираемые на прикладном уровне, для интерпретации передаваемых и получаемых данных: управление информационным обменом, отображение данных и управление структурированными данными. Эти служебные данные позволяют связывать воедино терминалы и вычислительные средства различных типов. Примером протокола этого уровня является XDR.
Прикладной уровень
В отличие от других уровней прикладной уровень — самый близкий к пользователю уровень OSI — не предоставляет услуги другим уровням OSI, однако он обеспечивает прикладные процессы, лежащие за пределами масштаба модели OSI.
Прикладной уровень обеспечивает непосредственную поддержку прикладных процессов и программ конечного пользователя (СУБД, текстовых процессоров, программ банковских терминалов и т.д. ) и управление взаимодействием этих программ с сетью передачи данных:
идентифицирует и устанавливает наличие предполагаемых партнеров для связи;
синхронизирует совместно работающие прикладные программы;
устанавливает соглашение по процедурам устранения ошибок и управления целостностью информации;
определяет достаточность наличных ресурсов для предполагаемой связи.
Модель OSI не является реализацией, она лишь предлагает порядок организации взаимодействия между компонентами системы. Реализациями этих правил являются стеки протоколов.
Стеки протоколов
Стек OSI
Протоколы стека OSI и их распределение по уровням сетевой модели приведены на рис. 3.
Рис. 3. Протоколы стека OSI ISO
Стек NetBIOS/SMB
Фирмы Microsoft и IBM совместно работали над сетевыми средствами для персональных компьютеров, поэтому стек протоколов NetBIOS/SMB является их совместным детищем. Средства NetBIOS появились в 1984 году как сетевое расширение стандартных функций базовой системы ввода/вывода (BIOS) IBM PC для сетевой программы PC Network фирмы IBM, которая на прикладном уровне (рис. 4) использовала для реализации сетевых сервисов протокол SMB.
Рис. 4. Стек NetBIOS/SMB
Протокол NetBIOS работает на трех уровнях модели взаимодействия открытых систем: сетевом, транспортном и сеансовом. NetBIOS может обеспечить сервис более высокого уровня, чем протоколы IPX и SPX, однако не обладает способностью к маршрутизации. Таким образом, NetBIOS не является сетевым протоколом в строгом смысле этого слова. NetBIOS содержит много полезных сетевых функций, которые можно отнести к сетевому, транспортному и сеансовому уровням, однако с его помощью невозможна маршрутизация пакетов, так как в протоколе обмена кадрами NetBIOS не вводится такое понятие как сеть. Это ограничивает применение протокола NetBIOS локальными сетями, не разделенными на подсети. NetBIOS поддерживает как дейтаграммный обмен, так и обмен с установлением соединений.
Протокол SMB, соответствующий прикладному и представительному уровням модели OSI, регламентирует взаимодействие рабочей станции с сервером. В функции SMB входят следующие операции:
Управление сессиями. Создание и разрыв логического канала между рабочей станцией и сетевыми ресурсами файлового сервера.
Файловый доступ. Рабочая станция может обратиться к файл-серверу с запросами на создание и удаление каталогов, создание, открытие и закрытие файлов, чтение и запись в файлы, переименование и удаление файлов, поиск файлов, получение и установку файловых атрибутов, блокирование записей.
Сервис печати. Рабочая станция может ставить файлы в очередь для печати на сервере и получать информацию об очереди печати.
Сервис сообщений. SMB поддерживает простую передачу сообщений со следующими функциями: послать простое сообщение; послать широковещательное сообщение; послать начало блока сообщений; послать текст блока сообщений; послать конец блока сообщений; переслать имя пользователя; отменить пересылку; получить имя машины.
Из-за большого количества приложений, которые используют функции API, предоставляемые NetBIOS, во многих сетевых ОС эти функции реализованы в виде интерфейса к своим транспортным протоколам. В NetWare имеется программа, которая эмулирует функции NetBIOS на основе протокола IPX, существуют программные эмуляторы NetBIOS для Windows NT и стека TCP/IP.
Стек TCP/IP
Стек TCP/IP, называемый также стеком DoD и стеком Internet, является одним из наиболее популярных стеков коммуникационных протоколов. Стек был разработан по инициативе Министерства обороны США (Department of Defence, DoD) для связи экспериментальной сети ARPAnet с другими сателлитными сетями как набор общих протоколов для разнородной вычислительной среды. Сеть ARPA поддерживала разработчиков и исследователей в военных областях. В сети ARPA связь между двумя компьютерами осуществлялась с использованием протокола Internet Protocol (IP), который и по сей день является основным в стеке TCP/IP и фигурирует в названии стека.
Большой вклад в развитие стека TCP/IP внес университет Беркли, реализовав протоколы стека в своей версии ОС UNIX. Широкое распространение ОС UNIX привело и к широкому распространению протокола IP и других протоколов стека. На этом же стеке работает всемирная информационная сеть Internet, чье подразделение Internet Engineering Task Force (IETF) вносит основной вклад в совершенствование стандартов стека, публикуемых в форме спецификаций RFC.
Так как стек TCP/IP был разработан до появления модели взаимодействия открытых систем ISO/OSI, то, хотя он также имеет многоуровневую структуру, соответствие уровней стека TCP/IP уровням модели OSI достаточно условно.
Структура протоколов TCP/IP приведена на рис. 5. Протоколы TCP/IP делятся на 4 уровня.
Рис. 5. Стек TCP/IP
Самый нижний (уровень IV) — уровень межсетевых интерфейсов — соответствует физическому и канальному уровням модели OSI. Этот уровень в протоколах TCP/IP не регламентируется, но поддерживает все популярные стандарты физического и канального уровня: для локальных каналов это Ethernet, Token Ring, FDDI, для глобальных каналов — собственные протоколы работы на аналоговых коммутируемых и выделенных линиях SLIP/PPP, которые устанавливают соединения типа "точка — точка" через последовательные каналы глобальных сетей, и протоколы территориальных сетей X.25 и ISDN. Разработана также специальная спецификация, определяющая использование технологии ATM в качестве транспорта канального уровня.
Следующий уровень (уровень III) — это уровень межсетевого взаимодействия, который занимается передачей дейтаграмм с использованием различных локальных сетей, территориальных сетей X.25, линий специальной связи и т. п. В качестве основного протокола сетевого уровня (в терминах модели OSI) в стеке используется протокол IP, который изначально проектировался как протокол передачи пакетов в составных сетях, состоящих из большого количества локальных сетей, объединенных как локальными, так и глобальными связями. Поэтому протокол IP хорошо работает в сетях со сложной топологией, рационально используя наличие в них подсистем и экономно расходуя пропускную способность низкоскоростных линий связи. Протокол IP является дейтаграммным протоколом.
К уровню межсетевого взаимодействия относятся и все протоколы, связанные с составлением и модификацией таблиц маршрутизации, такие как протоколы сбора маршрутной информации RIP(Routing Internet Protocol) и OSPF (Open Shortest Path First), а также протокол межсетевых управляющих сообщений ICMP (Internet Control Message Protocol). Последний протокол предназначен для обмена информацией об ошибках между маршрутизатором и шлюзом, системой-источником и системой-приемником, то есть для организации обратной связи. С помощью специальных пакетов ICMP сообщается о невозможности доставки пакета, о превышении времени жизни или продолжительности сборки пакета из фрагментов, об аномальных величинах параметров, об изменении маршрута пересылки и типа обслуживания, о состоянии системы и т.п.
Следующий уровень (уровень II) называется основным. На этом уровне функционируют протокол управления передачей TCP (Transmission Control Protocol) и протокол дейтаграмм пользователя UDP(User Datagram Protocol). Протокол TCP обеспечивает устойчивое виртуальное соединение между удаленными прикладными процессами. Протокол UDP обеспечивает передачу прикладных пакетов дейтаграммным методом, то есть без установления виртуального соединения, и поэтому требует меньших накладных расходов, чем TCP.
Верхний уровень (уровень I) называется прикладным. За долгие годы использования в сетях различных стран и организаций стек TCP/IP накопил большое количество протоколов и сервисов прикладного уровня: протокол копирования файлов FTP, протоколы удаленного управления telnet и ssh, почтовый протокол SMTP, гипертекстовые сервисы доступа к удаленной информации, такие как WWW и многие другие. Кратко остановимся на некоторых из протоколов стека, наиболее тесно связанных с тематикой данного курса.
Протокол SNMP (Simple Network Management Protocol) используется для организации сетевого управления. Проблема управления разделяется здесь на две задачи. Первая задача связана с передачей информации. Протоколы передачи управляющей информации определяют процедуру взаимодействия сервера с программой-клиентом, работающей на хосте администратора. Они определяют форматы сообщений, которыми обмениваются клиенты и серверы, а также форматы имен и адресов. Вторая задача связана с контролируемыми данными. Стандарты регламентируют, какие данные должны сохраняться и накапливаться в шлюзах, имена этих данных и синтаксис этих имен. В стандарте SNMP определена спецификация информационной базы данных управления сетью. Эта спецификация, известная как база данных MIB (Management Information Base), определяет те элементы данных, которые хост или шлюз должен сохранять, и допустимые операции над ними.
Протокол пересылки файлов FTP (File Transfer Protocol) реализует удаленный доступ к файлу. Для того, чтобы обеспечить надежную передачу, FTP использует в качестве транспорта протокол с установлением соединений — TCP. Кроме пересылки файлов протокол, FTP предлагает и другие услуги. Так пользователю предоставляется возможность интерактивной работы с удаленной машиной, например, он может распечатать содержимое ее каталогов, FTP позволяет пользователю указывать тип и формат запоминаемых данных. Наконец, FTP выполняет аутентификацию пользователей. Прежде, чем получить доступ к файлу, в соответствии с протоколом пользователи должны сообщить свое имя и пароль.
В стеке TCP/IP протокол FTP предлагает наиболее широкий набор услуг для работы с файлами, однако он является и самым сложным для программирования. Приложения, которым не требуются все возможности FTP, могут использовать другой, более экономичный протокол — простейший протокол пересылки файлов TFTP (Trivial File Transfer Protocol). Этот протокол реализует только передачу файлов, причем в качестве транспорта используется более простой, чем TCP, протокол без установления соединения — UDP.
Протокол telnet обеспечивает передачу потока байтов между процессами, а также между процессом и терминалом. Наиболее часто этот протокол используется для эмуляции терминала удаленной ЭВМ.
Высокоуровневое взаимодействие. Клиент-серверные, одноранговые и гибридные сети
Основное назначение компьютерных сетей — осуществление интерактивной связи между узлами для совместного использования ресурсов. Сетевые ресурсы — это данные, приложения и периферийные устройства. Доступ к сетевым ресурсам может быть централизованным (клиент-серверная модель), децентрализованным (одноранговая модель) и гибридным (частично централизованным).
Сети на основе сервера
Сеть на основе сервера (серверов) представляет собой распределенную систему, компонентами которой являются клиенты, запрашивающие некоторые ресурсы или сервисы, и серверы, их представляющие (рис. 1).
Рис. 1. Структура сети на основе выделенного сервера
Здесь, сервер — это высокопроизводительный компьютер, обслуживающий клиентсткие подключения. Такое определение является не полным и не отражает всего смысла клиент-серверной архитектуры, но широко используется при проектировании и реализации компьютерных сетей.
Выделенный сервер (dedicated server) выполняет специальные, серверные, приложения (в Windows — службы, в UNIX — демоны), которые представляют определенные услуги: доступ к данным, обмен сообщениями, удаленный запуск приложений и т.п.
Сетевые ресурсы в такой сети концентрируются на сервере, он же представляет услугицентрализованного управления этими ресурсами.
Клиентами сети на основе сервера являются компьютеры пользователей, которые обращаются к серверу за услугами по решению прикладных задач, таких как работа с общими файлами, отправка и получение электронной почты, ресурсоемкие вычисления, доступ в Интернет и т.п.
В зависимости от задач и принятой модели клиент-серверного взаимодействия, требования к вычислительной мощности клиентов и серверов могут изменяться в очень широком диапазоне.
Общим недостатком сетей на основе сервера, как и всех централизованных систем, является то, что неполадки на сервере ставят под угрозу работоспособность всей сети. Так, например, слишком большое число клиентских подключений может привести к неправильному функционированию или полному отключению сервера. Киберпреступники используют такую тактику в сетевых атаках типа DDoS (Distributed Deny of Service, — анг., распределенный отказ в обслуживании).
Типы серверов
В качестве примера, перечислим некоторые виды серверов, используемых в глобальной и локальных сетях:
Файловый сервер — предназначен для хранения и совместного использования файлов, доступ к которым осуществляется по сети.
Сервер печати (принт-сервер) — обеспечивает пользователей возможностью распечатки документов на сетевом принтере.
Почтовый сервер — обслуживает процессы передачи электронных сообщений между пользователями сети.
Коммуникационный сервер — управляет трафиком между узлами локальной сети и удаленными узлами.
В корпоративных сетях обычно одновременно используется несколько серверов разного назначения. Поэтому необходимо учитывать все возможные нюансы, которые могут проявиться при расширении сети, с тем чтобы изменение роли определенного сервера в дальнейшем не отразилось на работе всех пользователей.
Одноранговые сети
Одноранговая сеть представляет собой распределенную среду, в которой все узлы равноправны. Компьютеры такой сети могут функционировать как в качестве клиентов, так и серверов (рис. 2).
Пользователи одноранговой сети самостоятельно решают, какие ресурсы (в первую очередь файловые) на своем компьютере сделать общедоступными по сети. Децентрализованное управление ресурсами требует от пользователей повышенного уровня компьютерной грамотности, чтобы работать и как пользователю, и как администратору своего компьютера.
Рис. 2. Структура одноранговой сети
В 90-е годы XX века под одноранговой сетью понималась небольшая локальная сеть на 10-30 компьютеров с децентрализованным управлением — рабочая группа. Развитие Интернет привело к появлению протоколов одноранговых сетей глобального масштаба («пиринговых» сетей, от анг. peer — равный, см. peer-to-peer).
Гибридные сети
Полная децентрализация в одноранговых сетях, насчитывающих сотни и тысячи компьютеров, приводит к сложностям в управлении ими. Эта проблема отчасти решается добавлением координационного сервера в структуру сети (рис. 3). На сервер возлагаются задачи контроля за состоянием сети, представления списка доступных ресурсов и общего управления. Например, клиенты могут обращаться к такому серверу для авторизации, после чего способны взаимодействовать друг с другом непосредственно.
Рис. 3. Комбинированная (гибридная) сеть
Комбинированные, или гибридные сети — получили наибольшее распространение, поскольку сочетают преимущества одноранговых и клиент-серверных сетей и, во-многом, лишены их недостатков. Однако, для правильной реализации гибридных сетей и поддержания их в работоспособном состоянии от системных администраторов требуются глубокие знания и навыки планирования.
Компоненты сетевого приложения. Клиент-серверное взаимодействие и роли серверов.
Как правило компьютеры и программы, входящие в состав информационной системы, не являются равноправными. Некоторые из них владеют ресурсами (файловая система, процессор, принтер, база данных и т.д.), другие имеют возможность обращаться к этим ресурсам. Компьютер (или программу), управляющий ресурсом, называют сервером этого ресурса (файл-сервер, сервер базы данных, вычислительный сервер...). Клиент и сервер какого-либо ресурса могут находится как на одном компьютере, так и на различных компьютерах, связанных сетью.
В рамках многоуровневого представления вычислительных систем можно выделить три группы функций, ориентированных на решение различных подзадач:
функции ввода и отображения данных (обеспечивают взаимодействие с пользователем);
прикладные функции, характерные для данной предметной области;
функции управления ресурсами (файловой системой, базой даных и т.д.)
Рис.1. Компоненты сетевого приложения
Выполнение этих функций в основном обеспечивается программными средствами, которые можно представить в виде взаимосвязанных компонентов (рис. 1), где:
компонент представления отвечает за пользовательский интерфейс;
прикладной компонент реализует алгоритм решения конкретной задачи;
компонент управления ресурсом обеспечивает доступ к необходимым ресурсам.
Автономная система (компьютер, не подключенный к сети) представляет все эти компоненты как на различных уровнях (ОС, служебное ПО и утилиты, прикладное ПО), так и на уровне приложений (не характерно для современных программ). Так же и сеть — она представляет все эти компоненты, но, в общем случае, распределенные между узлами. Задача сводится к обеспечению сетевого взаимодействия между этими компонентами.
Архитектура «клиент-сервер» определяет общие принципы организации взаимодействия в сети, где имеются серверы, узлы-поставщики некоторых специфичных функций (сервисов) и клиенты, потребители этих функций.
Практические реализации такой архитектуры называются клиент-серверными технологиями. Каждая технология определяет собственные или использует имеющиеся правила взаимодейстия между клиентом и сервером, которые называются протоколом обмена (протоколом взаимодействия).
Двухзвенная архитектура
В любой сети (даже одноранговой), построенной на современных сетевых технологиях, присутствуют элементы клиент-серверного взаимодействия, чаще всего на основе двухзвенной архитектуры. Двухзвенной (two-tier, 2-tier) она называется из-за необходимости распределения трех базовыхкомпонентов между двумя узлами (клиентом и сервером).
Рис.2. Двухзвенная клиент-серверная архитектура
Двухзвенная архитектура используется в клиент-серверных системах, где сервер отвечает на клиентские запросы напрямую и в полном объеме, при этом используя только собственные ресурсы. Т.е. сервер не вызывает сторонние сетевые приложения и не обращается к сторонним ресурсам для выполнения какой-либо части запроса (рис. 2)
Расположение компонентов на стороне клиента или сервера определяет следующие основные модели их взаимодействия в рамках двухзвенной архитектуры:
сервер терминалов — распределенное представление данных;
файл-сервер — доступ к удаленной базе данных и файловым ресурсам;
сервер БД — удаленное представление данных;
сервер приложений — удаленное приложение.
Перечисленные модели с вариациями представлены на рис. 3.
Рис.3. Модели клиент-серверного взаимодействия
Исторически первой появилась модель распределенного представления данных (модель сервер терминалов). Она реализовывалась на универсальной ЭВМ (мэйнфрейме), выступавшей в роли сервера, с подключенными к ней алфавитно-цифровыми терминалами. Пользователи выполняли ввод данных с клавиатуры терминала, которые затем передавались на мэйнфрейм и там выполнялась их обработка, включая формирование «картинки» с результатами. Эта «картинка» и возвращалась пользователю на экран терминала.
С появлением персональных компьютеров и локальных сетей, была реализована модель файлового сервера, представлявшего доступ файловым ресурсам, в т.ч и к удаленной базе данных. В этом случае выделенный узел сети является файловым сервером, на котором размещены файлы базы данных. На клиентах выполняются приложения, в которых совмещены компонент представления и прикладной компонент (СУБД и прикладная программма), использующие подключенную удаленную базу как локальный файл. Протоколы обмена при этом представляют набор низкоуровневых вызовов операций файловой системы.
Такая модель показала свою неэффективность ввиду того, что при активной работе с таблицами БД возникает большая нагрузка на сеть. Частичным решением является поддержка тиражирования (репликации) таблиц и запросов. В этом случае, например при изменении данных, обновляется не вся таблица, а только модифицированная ее часть.
С появлением специализированных СУБД появилась возможность реализации другой модели доступа к удаленной базе данных — модели сервера баз данных. В этом случае ядро СУБД функционирует на сервере, прикладная программа на клиенте, а протокол обмена обеспечивается с помощью языка SQL. Такой подход по сравнению с файловым сервером ведет к уменьшению загрузки сети и унификации интерфейса «клиент-сервер». Однако, сетевой трафик остается достаточно высоким, кроме того, по прежнему невозможно удовлетворительное администрирование приложений, поскольку в одной программе совмещаются различные функции.
С разработкой и внедрением на уровне серверов баз данных механизма хранимых процедур появилась концепция активного сервера БД. В этом случае часть функций прикладного компонента реализованы в виде хранимых процедур, выполняемых на стороне сервера. Остальная прикладная логика выполняется на клиентской стороне. Протокол взаимодействия — соответствующий диалект языка SQL.
Преимущества такого подхода очевидны:
возможно централизованное администрирование прикладных функций;
снижение стоимости владения системой (TOC, total cost of ownership) за счет аренды сервера, а не его покупки;
значительное снижение сетевого трафика (т.к. передаются не SQL-запросы, а вызовы хранимых процедур).
Основной недостаток — ограниченность средств разработки хранимых процедур по сравнению с языками высокого уровня.
Реализация прикладного компонента на стороне сервера представляет следующую модель — сервер приложений. Перенос функций прикладного компонента на сервер снижает требования к конфигурации клиентов и упрощает администрирование, но представляет повышенные требования к производительности, безопасности и надежности сервера.
В настоящее время намечается тенденция возврата к тому, с чего начиналась клиент-серверная архитектура — к централизации вычислений на основе модели терминал-сервера. В современной реинкарнации терминалы отличаются от своих алфавитно-цифровых предков тем, что имея минимум программных и аппаратных средств, представляют мультимедийные возможности (в т.ч. графический пользовательский интерфейс). Работу терминалов обеспечивает высокопроизводительный сервер, куда вынесено все, вплоть до виртуальных драйверов устройств, включая драйверы видеоподсистемы.
Трехзвенная архитектура
Рис.4. Трехзвенная клиент-серверная архитектура
Еще одна тенденция в клиент-серверных технологиях связана со все большим использованием распределенных вычислений. Они реализуются на основе модели сервера приложений, где сетевое приложение разделено на две и более частей, каждая из которых может выполняться на отдельном компьютере. Выделенные части приложения взаимодействуют друг с другом, обмениваясь сообщениями в заранее согласованном формате. В этом случае двухзвенная клиент-серверная архитектура становитсятрехзвенной (three-tier, 3-tier).
Как правило, третьим звеном в трехзвенной архитектуре становится сервер приложений, т.е. компоненты распределяются следующим образом (рис. 4):
Представление данных — на стороне клиента.
Прикладной компонент — на выделенном сервере приложений (как вариант, выполняющем функции промежуточного ПО).
Управление ресурсами — на сервере БД, который и представляет запрашиваемые данные.
Рис.5. Многозвенная (N-tier) клиент-серверная архитектура
Трехзвенная архитектура может быть расширена до многозвенной (N-tier, Multi-tier) путем выделения дополнительных серверов, каждый из которых будет представлять собственные сервисы и пользоваться услугами прочих серверов разного уровня. Абстрактный пример многозвенной модели приведен нарис. 5.
Сравнение архитектур
Двухзвенная архитектура проще, так как все запросы обслуживаются одним сервером, но именно из-за этого она менее надежна и предъявляет повышенные требования к производительности сервера.
Трехзвенная архитектура сложнее, но благодаря тому, что функции распределены между серверами второго и третьего уровня, эта архитектура представляет:
Высокую степень гибкости и масштабируемости.
Высокую безопасность (т.к. защиту можно определить для каждого сервиса или уровня).
Высокую производительность (т.к. задачи распределены между серверами).
Клиент-серверные технологии
Архитектура клиент-сервер применяется в большом числе сетевых технологий, используемых для доступа к различным сетевым сервисам. Кратко рассмотрим некоторые типы таких сервисов (и серверов).
Web-серверы
Изначально представляли доступ к гипертекстовым документам по протоколу HTTP (Huper Text Transfer Protocol). Сейчас поддерживают расширенные возможности, в частности работу с бинарными файлами (изображения, мультимедиа и т.п.).
Серверы приложений
Предназначены для централизованного решения прикладных задач в некоторой предметной области. Для этого пользователи имеют право запускать серверные программы на исполнение. Использование серверов приложений позволяет снизить требования к конфигурации клиентов и упрощает общее управление сетью.
Серверы баз данных
Серверы баз данных используются для обработки пользовательских запросов на языке SQL. При этом СУБД находится на сервере, к которому и подключаются клиентские приложения.
Файл-серверы
Файл-сервер хранит информацию в виде файлов и представляет пользователям доступ к ней. Как правило файл-сервер обеспечивает и определенный уровень защиты от несакционированного доступа.
Прокси-сервер
Во-первых, действует как посредник, помогая пользователям получить информацию из Интернета и при этом обеспечивая защиту сети.
Во-вторых, сохраняет часто запрашиваемую информацию в кэш-памяти на локальном диске, быстро доставляя ее пользователям без повторного обращения к Интернету.
Файрволы (брандмауэры)
Межсетевые экраны, анализирующие и фильтрующие проходящий сетевой трафик, с целью обеспечения безопасности сети.
Почтовые серверы
Представляют услуги по отправке и получению электронных почтовых сообщений.
Серверы удаленного доступа (RAS)
Эти системы обеспечивают связь с сетью по коммутируемым линиям. Удаленный сотрудник может использовать ресурсы корпоративной ЛВС, подключившись к ней с помощью обычного модема.
Это лишь несколько типов из всего многообразия клиент-серверных технологий, используемых как в локальных, так и в глобальных сетях.
Для доступа к тем или иным сетевам сервисам используются клиенты, возможности которых характеризуются понятием «толщины». Оно определяет конфигурацию оборудования и программное обеспечение, имеющиеся у клиента. Рассмотрим возможные граничные значения:
«Тонкий» клиент
Этот термин определяет клиента, вычислительных ресурсов которого достаточно лишь для запуска необходимого сетевого приложения через web-интерфейс. Пользовательский интерфейс такого приложения формируется средствами статического HTML (выполнение JavaScript не предусматривается), вся прикладная логика выполняется на сервере. Для работы тонкого клиента достаточно лишь обеспечить возможность запуска web-браузера, в окне которого и осуществляются все действия. По этой причине web-браузер часто называют "универсальным клиентом".
«Толстый» клиент
Таковым является рабочая станция или персональный компьютер, работающие под управлением собственной дисковой операционной системы и имеющие необходимый набор программного обеспечения. К сетевым серверам «толстые» клиенты обращаются в основном за дополнительными услугами (например, доступ к web-серверу или корпоративной базе данных). Так же под «толстым» клиентом подразумевается и клиентское сетевое приложение, запущенное под управлением локальной ОС. Такое приложение совмещает компонент представления данных (графический пользовательский интерфейс ОС) и прикладной компонент (вычислительные мощности клиентского компьютера).
В последнее время все чаще используется еще один термин: «rich»-client. «Rich«-клиент своего рода компромисс между «толстым» и «тонким» клиентом. Как и «тонкий» клиент, «rich»-клиент также представляет графический интерфейс, описываемый уже средствами XML и включающий некоторую функциональность толстых клиентов (например интерфейс drag-and-drop, вкладки, множественные окна, выпадающие меню и т.п.)
Прикладная логика «rich»-клиента также реализована на сервере. Данные отправляются в стандартном формате обмена, на основе того же XML (протоколы SOAP, XML-RPC) и интерпретируются клиентом.
Некоторые основные протоколы «rich»-клиентов на базе XML приведены ниже:
XAML (eXtensible Application Markup Language) — разработан Microsoft, используется в приложениях на платформе .NET;
XUL (XML User Interface Language) — стандарт, разработанный в рамках проекта Mozilla, используется, например, в почтовом клиенте Mozilla Thunderbird или браузере Mozilla Firefox;
Flex — мультимедийная технология на основе XML, разработанная Macromedia/Adobe.
Заключение
Итак, основная идея архитектуры «клиент-сервер» состоит в разделении сетевого приложения на несколько компонентов, каждый из которых реализует специфический набор сервисов. Компоненты такого приложения могут выполняться на разных компьютерах, выполняя серверные и/или клиентские функции. Это позволяет повысить надежность, безопасность и производительность сетевых приложений и сети в целом.
Одноранговые (пиринговые) сети
Одноранговая сетевая архитектура — стабильно набирающий популярность способ организации высокоуровнего сетевого взаимодействия, где все узлы сети обладают равными правами и выступают поставщиками и потребителями сетевых сервисов одновременно.
Это тезисы леции
Одноранговая сеть — это децентрализованная системная архитектура
Узлы представляют симметричные функции
Разделение ресурсов (полоса пропускания, CPU, дисковое пространство) между узлами
Гетерогенная среда из множества (ненадежных) узлов
Способность к самоорганизации, отказоустойчивость (на уровне сети)
Динамичность (частое подключение и отключение узлов)
Одноранговая сеть — это уже давно не «рабочая группа» на 20-30 компьютеров
Пиру — пир!
Одноранговая = пиринговая
Peer-to-peer (англ.) — равный к равному
ALSO: per-2-peer, P2P
Пир (peer) — «соучастник», узел одноранговой сети (рис. 1)
Рис. 1. Обобщенная схема однорангового взаимодействия
Характеристики пиринговых сетей
Основные
Децентрализация (полная или частичная)
Масштабируемость
Нет «горячих точек» (hotspots) и «узких мест» (bottlenecks)
Динамическое подключение
Ad-hoc connectivity
Самоорганизация
Отказоустойчивость
ALSO: анонимность, безопасность, доверие, репликация, кэширование, координация…
Что не является P2P?
Централизованные решения
Клиент-серверная архитектура
Модель master / slave
«тупые» терминалы / активные трансляторы
Проблемы:
Масштабируемость
Ограниченные возможности центрального узла
Стоимость
Предыстория p2p
ARPANET, 1969
Клиент-серверные приложения (ftp, telnet...)
USENET, 1979
Децентрализованное управление, позволяющее избежать сетевого флуда, трассировки заголовков …
UUCP, NNTP
DNS, 1983
Масштабируемость!!!
Иерархический дизайн
Распределенная нагрузка, кэширование, делегирование запросов...
APPN, 1984
Advanced Peer to Peer Networking (см. SNA и z/OS), IBM
Взрыв Интернет (1994-1999 гг)
Клиент-серверные службы
HTTP, Chat, Mail, IM
«Конец» сотрудничества
Спам, превалирование TCP трафика и, как следствие, перегрузка сети
см. RFC 5348 — TCP Friendly Rate Control (TFRC)
«Лекарства»: файрволлы, динамическая адресация (DHCP), NATs, асимметричная пропускная способность
Решение
Задействовать вычислительные ресурсы пользователей, возложив на них серверные функции
Одноранговая сеть
Каждый узел сети (пир) — является как потребителем сервисов (клиентом), так и поставщиком (сервером)
Каждый пир может инициировать сеанс
Пиры взаимодействуют между собой напрямую
Инфраструктура P2P
Оверлейная сеть — сеть «поверх» сети
В случае P2P: Маршрутизаторы прикладного уровня используют инфраструктуру IP-сети
Избыточность? Ну-у-у, есть чуток...
Почему оверлей?
Представляет услуги, которых нет на нижележащих уровнях
Приложения «один-ко-многим» и «многие-ко-многим»: multicast не поддерживается многими ip-маршрутизаторами
Кстати: IP-сеть — тоже оверлей...
Архитектурные модели
Централизованная одноранговая модель
Есть сервер, координирующий работу пиров
Пиры получают от сервера список файлов (Napster) или френд-лист (Skype)
Рис. 2. Централизованная модель
Децентрализованная одноранговая модель
Нет выделенного сервера
Каждый узел может взаимодействовать со множеством других узлов
Все узлы равноправны
Может быть (рис. 3)
структурированная (HyperCub, DHT)
неструктурированная (Gnutella)
Рис. 3. Структурированные и неструктурированные пиринговые сети
Pure P2P (рис. 1) (например Gnutella) и/или...
Иерархическая одноранговая модель
...Суперпир — узел с широким каналом, к которому подключаются другие пиры (GoalBit — футбол онлайн)
Многоуровневый структурированный оверлей (рис. 4) - гибридная архитектура
Первое звено — пиры подключаются к Суперпирам
Второе звено — Суперпиры соединяются между собой
Снижение числа прямых подключений
Реализация «пограничных» вычислений (edge computing)
Рис. 4. Двухуровневая модель одноранговой сети
Сферы применения P2P
Файлообменные сети
BitTorrent, Gnutella, KaZaA, eDonkey, Ст. 146 УК РФ...
Распределенные вычисления
SETI@Home, Find-A-Drug, GIMPS (числа Мерсенна) & etc...
Финансы
Криптовалюты: Bitcoin, Litecoin, PPCoin...
Медийный трафик
Актуальность P2P
По данным Интернет-провайдеров, на пиринговые сети приходится 50-75% глобального трафика
Это сдвиг парадигмы от координации к сотрудничеству, от централизации к децентрализации, от контроля к стимулу
Для специалистов
Пиры - «то-о-о-лстые» клиенты!
Вычислительные ресурсы
Распределенные хранилища данных
Пропускная способность каналов связи постоянно растет
Edge computing: «пограничные вычисления» - перемещение нагрузки на конечных пользователей
Децентрализованные вычисления лучше масштабируются
Миллионы пользователей
Нирвана: Дешевые многопользовательские приложения с бесконечными ресурсами
Для пользователей
Организационный сдвиг от иерархической (централизованной) модели к сетевой (децентрализованной) -> анонимность
P2P позволяет создавать всемирные сообщества
Напримеры
1. Обучение: классическая (лекции/экзамены) модель VS совместное (коллаборативное) обучение
2. СМИ: несколько крупных издателей (TV, радио, газеты) VS «народные» новости (блоги, Интернет-TV, сетевые радиостанции)
Ложка дегтя
Судебное преследование
Идея P2P дискредитирована пиратским контентом
Психология пользователей
«зажатая» раздача
Разнородность
Сложность поиска информации
Название одно — содержание другое
Содержание одно — названия разные
Решение - хэш-коды
Анонимность - Беспокоит тех, кому есть что скрывать
Промежуточное ПО. Назначение, функции и виды middleware.
Промежуточное программное обеспечение используется в многозвенных клиент-серверных приложениях для интеграции распределенных компонентов в единую информационную систему.
Эволюция архитектуры «клиент-сервер»
Классическая двухзвенная клиент-серверная модель вполне подходит для небольших корпоративных подразделений с ограниченным числом пользователей и невысокой нагрузкой на сервер. Однако, по мере внедрения клиент-серверных технологий в сферу высококритичных корпоративных приложений, обслуживающих сотни пользователей и обрабатывающих существенные массивы данных, стали очевидны недостатки двухзвенных решений:
ограниченные возможности масштабирования;
необходимость изменения клиентских приложений при изменении работы серверной логики.
Решить эти проблемы позволяет переход на трех- и многозвенные модели, в которых прикладная логика вынесена в отдельный уровень (на сервер приложений). Это позволяет эффективно распределять нагрузку и обеспечить прозрачное наращивание как функциональности сервера (серверов) приложений, так и числа обслуживаемых пользователей.
Но, для перехода на трехзвенную архитектуру зачастую приходится решить другую проблему: как обеспечить взаимодействие имеющихся компонентов, от которых нельзя отказаться по тем или иным причинам, с компонентами новой системы. Т.е. возникает вопрос интеграции приложений. Ответом на этот вопрос является использование специализированного, т.н. промежуточного, программного обеспечения — middleware.
Определение и назначение промежуточного ПО
Промежуточное программное обеспечение (middleware) — это класс программного обеспечения, предназначенного для объединения компонентов распределенного клиент-серверного приложения или целых сетевых приложений в единую информационную систему. Промежуточное ПО представляет набор сервисов, обращение к которым позволяет различным приложениям, в общем случае выполняющимся на разных платформах, взаимодействовать между собой (рис. 1). Общие прикладные интерфейсы (API) промежуточного ПО позволяют реализовать взаимодействие между приложениями, не углубляясь в инфраструктуру и детали реализации гетерогенной сети, а последующие изменения в структуре и составе такой сети не потребуют изменений в приложениях (при условии, что эти изменения не затрагивают API middleware).
Рис. 1. Промежуточное программное обеспечение
Термин middleware впервые был использован в 1968 г., но как технология интеграции корпоративных приложений, этот тип программного обеспечения стал использоваться с 80-х годов XX в. для решения проблем совместимости и взаимодействия новых приложений с устаревшими наследованными системами.
Место промежуточного ПО — в условной «середине» между сетевыми приложениями или их компонентами. Этим оно напоминает среднее звено в трехзвенных клиент-серверных архитектурах, за исключением того, что функциональные части middleware распределены между приложениями и/или их компонентами в корпоративной сетевой среде.
Функции middleware
Сервисы middleware представляют приложениям разнобразные функции API, которые, в сравнении с функциями операционных систем и сетевых служб, обеспечивают:
прозрачный доступ к другим сетевым сервисам и приложениям;
независимость от других сетевых сервисов;
высокую надежность и постоянную готовность.
Следует отметить, что зачастую различия в функциональности операционной системы и промежуточного ПО являются условными. В частности, некоторые возможности, ранее представляемые исключительно средствами middleware, теперь реализуются на уровне ядра операционных систем. Типичным примером является стек TCP/IP, поддержка которого включена практически во все ОС.
Виды промежуточного ПО
Востребованность промежуточного ПО при разработке и внедрении сложных систем привела к появлению различных типов middleware, которые отличаются масштабируемостью, надежностью и самой идеей организации взаимодействия. При этом весь существующий на сегодняшний день спектр промежуточного ПО можно условно разделить на две основных категории (по специализации):
Программное обеспечение для межпрограммного взаимодействия (см. также IPC - Inter-Process Communication).
Программное обеспечение доступа к базам данных.
Промежуточное ПО межпрограммного взаимодействия
Протоколы и продукты этой категории облегчают межпроцессные взаимодействия (IPC - InterProcess Communications) и распределение объектов в инфраструктуре корпоративной информационной системы. Они выполняют роль клея, позволяющего соединить многозвенные приложения. Основными технологиями являются следующие: RPC, MOM, TPM и ORB. В готовых решениях, как правило, используется один или несколько таких протоколов.
Концепция вызова удаленных процедур (remote procedure call — RPC) была разработана и реализована в компанией XEROX еще начале 80-х годов XX века. Общий смысл RPC можно представить так: программа может выполнять не только собственные (скомпилированные) процедуры и функции, но и обращаться к процедурам удаленного сервера (рис. 2).
Рис. 2. Вызов удаленных процедур
Для установки связи, передачи вызова и возврата результата клиентский и серверный процессы обращаются к специальным компонентам – «заглушкам», соответственно клиентской и серверной (client stub и server stub). Эти stub'ы не реализуют никакой прикладной логики и предназначены только для организации взаимодействия удаленных (в общем случае) приложений. Все RPC-обращения клиента (имена функций и списки параметров) упаковываются клиентской заглушкой в сетевые сообщения (этот процесс называется marshaling) и ей же передаются серверной заглушке. Та, в свою очередь, распаковывает полученные данные (unmarshaling), передает их реальной функции сервера, а полученные результаты упаковывает в обратном порядке. Клиентская заглушка принимает ответ, распаковывает его и возвращает в приложение. Таким образом, процедуры-заглушки изолируют прикладные модули клиента и сервера от уровня сетевых коммуникаций.
Для определения правил, задающих отношения между клиентом и сервером RPC, используется язык описания интерфейсов IDL. Интерфейс содержит определение имени функции и полное описание передаваемых параметров и результатов выполнения. Правила IDL обеспечивают независимость механизма RPC от языков программирования: обращаясь к удаленной процедуре, клиент использует свои языковые конструкции, а IDL-компилятор преобразует их в унифицированные описания, понятные серверу. На сервере IDL-описания преобразуются в конструкции языка программирования, на котором реализован серверный процесс.
У RPC как средства организации сетевого взаимодействия есть ряд минусов, кроющихся в самой парадигме структурного программирования:
Синхронные запросы — RPC приостанавливает выполнение приложения до тех пор, пока сервер не вернет требуемые данные.
Статические отношения между компонентами — привязка клиентского процесса к серверным заглушкам происходит на этапе компиляции и не может быть изменена во время выполнения.
Для устранения этих недостатков были разработаны более совершенные механизмы реализации RPC:
асинхронные RPC, позволяющие избежать приостановки выполнения клиентского приложения посредством функций обратного вызова (call-back functions);
код заглушек вынесен в динамически подключаемые библиотеки.
Протокол взаимодействия RPC также может повлиять на работу системы. Рассмотрим гипотетический фрагмент кода:
for (i = 0, i < 1000, i++)
for (j = 0, j < 1000, j++)
RPC_call();
В этом случае вызов удаленной процедуры будет выполняться миллион раз. На каждой итерации будут выполняться действия не только по передаче данных и результатов, но и по управлению соединением. Это приведет не только к повышению нагрузки на сеть, но и снижению производительности системы в целом. В данном случае правильным решением является вынос функций установления и разрыва соединения за тело циклов, что противоречит самой идее RPC.
См. также: RFC 1057 Remote Procedure Call Protocol Specification Version 2 (Sun Microsystems), C706 DCE 1.1: Remote Procedure Call (The OpenGroup Distributed Computing Environment (DCE))
Сервисы обработки сообщений (MOM — message-oriented middleware) —это системы, как правило асинхронные, в которых взаимодействие между клиентом и сервером основано на обмене сообщениями. Сообщения — это текстовые блоки, состоящие из управляющих команд и передаваемых данных. Для передачи сообщений используются байт-ориентированные протоколы, такие как HTTP, POP/SMTP и т.п.
Обмен сообщениями реализуется через API системы MOM. Запросы сервисов ставятся в очередь сообщений и обрабатываются в соответствии с приоритетами и доступностью ресурсов (рис. 3). Приоритеты сообщений позволяют обеспечить первоочередную доставку важных сообщений, аотложенная доставка осуществляется либо по расписанию, либо при появлении адресата в сети. Ответы сервера содержат информацию об успешном или неуспешном выполнении операции.
Рис. 3. Промежуточное обеспечение, ориентированное на обработку сообщений (MOM)
Сервисы MOM хорошо зарекомендовали себя в сильно распределенных приложениях, используемых в гетерогенной сети с медленными и ненадежными соединениями. Это, во-многом, достигается благодаря поддержке уровней «качества обслуживания»:
надежная доставка сообщений (reliable message delivery) — система MOM гарантирует, что в процессе обмена ни одно сообщение не будет утеряно;
гарантированная доставка сообщений (guaranteed message delivery) — сообщение доставляется адресату немедленно или через заданный промежуток времени, не превышающий определенного значения (в случае, если сеть в данный момент не доступна);
застрахованная доставка сообщений (assured message delivery) — каждое сообщение доставляется только один раз.
Очереди сообщений представляют собой мощный, гибкий и в то же время простой механизм межпрограммного взаимодействия.
Помимо приведенной, можно сказать классической, схемы с очередями, разработаны и используются сервисы MOM с непосредственной передачей сообщений и на основе подписки.
Системы с непосредственной передачей сообщений (message passing) используют логическое сетевое соединение для обмена сообщениями между взаимодействующими приложениями. Эта схема удобна в тех случаях, когда клиенты и серверы сообщений используются в сильно связанной сетевой инфраструктуре и синхронизированы по времени.
Сервисы MOM, обслуживающие клиентов по подписке/публикации (publish&subscribe) работают по принципу, напоминающему почтовую рассылку: одно приложение публикует информацию в сети, а другие подписываются на эту публикацию для получения необходимых данных. Взаимодействующие таким способом приложения полностью независимы друг от друга, что представляет возможности динамической реконфигурации всей распределенной системы.
Мониторы обработки транзакций (Transaction Processing monitors, TP-monitors) — это промежуточное программное обеспечение, обеспечивающее контроль передачи данных от клиента при работе с распределенными базами данных. Монитор транзакций обеспечивает целостность данных, следя за тем, чтобы не было потерянных или незавершенных транзакций. Транзакция – это законченный блок обращений к базе данных, для которого гарантируется выполнение четырех условий ACID:
Атомарность (Atomicity) – операции транзакции образуют неделимый, атомарный блок, который либо выполняется от начала до конца, либо не выполняется вообще. При невозможности выполнения транзакции происходит откат к исходному состоянию;
Согласованность (Consistency) – по завершении транзакции все задействованные ресурсы находятся в предопределенном и согласованном состоянии;
Изолированность (Isolation) – одновременный доступ транзакций различных приложений к разделяемым ресурсам координируется таким образом, чтобы исключить их влияние друг на друга;
Долговременность (Durability) – все модификации ресурсов в процессе выполнения транзакции будут долговременными.
Монитор транзакций обеспечивает контроль над выполнением этих условий, выполняя функции концентрации и преренаправления запросов к БД в распределенной среде с множеством баз данных от различных поставщиков (рис. 4).
Рис. 4. Монитор транзакций
Подробное описание открытой спецификации Distributed TP доступно на сайте OpenGroup.
Распределенные объектные системы (Distributed object systems) — это промежуточное программное обеспечение, реализованное в виде взаимодействующих друг с другом программных объектов. Каждый такой объект уникальным образом идентифицируется в сети и обеспечивает доступ к представляемым им сервисам через публичные свойства и методы. Реализация объекта и платформа, на которой он выполняется, полностью прозрачны для клиента.
С точки зрения разработки, использование распределенных объектов оправданно при создании масштабных объектно-ориентированных систем. Фактически же, объектная «обертка» таких решений скрывает за собой ранее рассмотренные RPC, MOM и средства управления транзакциями. По-этому, в первом приближении общий принцип взаимодействия распределенных объектов очень похож на RPC (рис. 5). Это сходство заметно и в средствах описания интерфейсов — объекты используют все тот же IDL. Однако, в сравнении с RPC, распределенные объекты могут компоноваться динамически, т.е. не на этапе компиляции, а во время выполнения приложений.
Рис. 5. Распределенные объектные системы (stub и skeleton - клиентская и серверная заглушки)
Архитектура распределенных объектных систем стандартизована и наиболее распространены спецификации CORBA, COM/DCOM и EJB.
CORBA (Common Object Request Broker Architecture, типовая архитектура брокера объектных запросов) — открытый стандарт, разработанный группой Object Management Group (OMG), который определяет интерфейсы между сетевыми объектами, позволяющие им работать совместно. Брокеры объектных запросов (object request brokers, ORB), созданные в соответствии с CORBA, представляют интерфейсы для разработки объектно-ориентированных систем «клиент-сервер».
Microsoft COM (Component Object Model, компонентная объектная модель) — это семейство технологий, предназначенных для организации взаимодействия Windows-приложений (см. MSDN: The Component Object Model). В это семейство входят COM+, DCOM (Distributed COM) и ActiveX Controls. Microsoft позиционирует COM как платформу для разработки повторно используемых (re-usable) компонентов приложений. В случае DCOM — компонентов распределенных клиент-серверных систем.
EJB (Enterprise JavaBeans) — технология, разработанная Sun Microsystems для корпоративных решений на платформе Java (Java EE/EJB). Спецификация EJB описывает архитектуру серверных компонентов и порядок их использования в клиент-серверных приложениях. Эта технология упрощает разработку распределенных систем на основе Java и обеспечивает наибольшую переносимость Java-приложений.
Промежуточное ПО доступа к базам данных
Рассмотрим два основных типа промежуточного обеспечения, ориентированного на работу с распределенными данными — это собственное промежуточное обеспечение СУБД и основное промежуточное обеспечение баз данных.
Собственное промежуточное ПО СУБД — это встроенные механизмы доступа для конкретного сервера баз данных.
Основное промежуточное ПО баз данных — к этому типу относится, например, интерфейс Open Database Connectivity (ODBC), который позволяет программам «общаться» на разных диалектах SQL через общие интерфейсы.
Собственное промежуточное ПО СУБД. К этому виду относится, в первую очередь, поддержка стандартов языка SQL. Несмотря на то, что SQL является международным стандартом, разработчики СУБД самостоятельно определяют, какие из возможностей SQL они будут поддерживать в своих системах. В результате, конкретная СУБД может, с одной стороны, не поддерживать или поддерживать частично некоторые команды SQL, а с другой — представлять разработчикам приложений нестандартные языковые расширения.
Другим видом собственного middleware являются встроенные средства СУБД, позволяющие выполнять импорт данных из внешних источников (например, из других СУБД или текстовых файлов) и экспортировать данные в сторонние форматы (например, CSV или XML).
Основное промежуточное ПО доступа к БД. К этой категории относятся внешние (по отношению к СУБД) средства middleware, специально разработанные для обращения к базам данных. Сюда относятся как технологические решения (например, ODBC и JDBC), так и концептуальные, представляющие обобщенную архитектуру информационной системы с распределенными БД (например, EDA или DQB).
ODBC (Open DataBase Connectivity, открытое соединение с БД) — это интерфейс доступа к базам данных, разработанный Microsoft. ODBC представляет возможность обращения к реляционным и нереляционным СУБД в гетерогенной среде через унифицированные вызовы API (рис. 6). Обращения к функциям ODBC транслируются в естественные диалекты многих СУБД с помощью специальных ODBC-драйверов либо напрямую, либо через указание имени источника данных (рис. 7).
Рис. 6. а) Доступ к БД через ODBC; б) Интерфейс ODBC.
JDBC (Java DataBase Connectivity) — это прикладной программный интерфейс для обращения к базам данных из Java-приложений. Средства JDBC являются платформонезависимыми и выполняются в любой среде под управлением виртуальной машины Java. По сравнению с ODBC этот тип промежуточного ПО баз данных предлагает больше возможностей по интеграции приложений и расширяет сферу использования БД (например, в сторону мобильных приложений). Больше того, спецификация JDBC предусматривает возможность доступа Java-приложений к БД через ODBC с помощью специального средства, т.н. «моста» (ODBC/JDBC-bridge).
EDA (Event-Driven Architecture, событийно-управляемая архитектура) — это концепция управления корпоративной информационной системой на основе событий, возникающих в бизнес-процессе. Доступ к БД в EDA базируется на использовании централизованного способа обращения к распределенным базам данных. Все запросы клиентов поступают на вход SQL-шлюза, который транслирует SQL-запросы в унифицированный формат и перенаправляет их к серверам БД. Взаимодействие с ними возможно как через набор общих API, так и через ODBC-интерфейс (рис. 8). Использование SQL-шлюза обеспечивает доступ к данным в разнородных многозвенных системах, где множество приложений параллельно обращаются к источникам данных различного формата.
Рис. 8. Принцип доступа к БД в EDA
DQB (Distributed Query Broker, брокер распределенных запросов) — децентрализованное (в отличие от EDA) решение для доступа к БД на основе ORB. Заглушки-брокеры, размещенные на серверах БД, принимают унифицированные SQL-запросы и транслируют их в диалекты конкретных СУБД (рис. 9).
Рис. 9. Брокер распределенных запросов (DQB)
Middleware: Что выбрать?
Стек протоколов TCP/IP давно уже поддерживается на уровне операционных систем, средства RPC также доступны в сетевых ОС едва ли не "по умолчанию". Этот механизм практически не требует от разработчиков и интеграторов каких-либо новых знаний и навыков. Не требуется изучать специфические middleware API: вызов удаленной процедуры ничем не отличается от обращения к локальной подпрограмме, а все процессы преобразования данных и передачи их по сети выполняются клиентской и серверной заглушками. Использование RPC может быть наиболее подходящим решением для систем, где возможные проблемы, связанные с синхронностью протокола RPC, не являются критичными.
Промежуточное ПО обмена сообщениями предлагает бОльшую, по сравнению с RPC, гибкость, так как ни одно из взаимодействующих приложений не блокируется в процессе обмена сообщениями. Такое решение лучше подойдет для автоматизированных систем, компоненты которых слабо связаны, работают в независимом временном режиме и используют разнородную сетевую среду. Однако, системы на основе MOM как правило не поддерживают автоматическое преобразование форматов (marshalling/unmarshalling), что требует от разработчика решения задач по преобразованию форматов данных.
Взаимодействие компонентов корпоративных приложений в объектно-ориентированной среде удобнее всего реализовывать с помощью объектных-же средств промежуточного ПО. В этом случае, разработчик использует объектную модель, четко описывающую бизнес-процессы. Высокий уровень абстракции объектов (будь то ORB или EJB) полностью скрывает от пользователя детали реализации взаимодействия между ними. Использование объектов позволяет строить корпоративные приложения словно лего город, из унифицированных «кирпичиков»объектов. Это справедливо, если вся система является объектно-ориентированной. Затруднения с использованием распределенных объектов появляются, когда компонентами автоматированной системы являются унаследованные приложения.
Мониторы транзакций ориентированы на сложные и высококритичные корпоративные системы. Они обеспечивают необходимый уровень сервиса для таких систем, включая управление процессами, балансировку нагрузки на серверы, средства резервирования восстановления данных. Для задач автоматизации небольшого предприятия возможности, представляемые TP-мониторами могут быть избыточны. К тому же, продукты этой категории имеют высокую стоимость, что может быть экономически не выгодно.
Рассмотренные категории промежуточного ПО все реже и реже используются в «чистом» виде. Напротив, как и в большинстве сетевых технологий, развитие middleware идет в сторону объединения возможностей разных его категорий и для разного рода задач всегда можно подобрать наиболее подходящее решение.
Основы сетевой безопасности. Сеть как объект защиты
Преступность в сфере информационных технологий (киберпреступность) — явление, получившее глобальное распространение буквально в течение нескольких лет. Эффективная борьба с киберпреступлениями требует международного сотрудничества на государственном уровне.
Первые вирусы для IBM PC-совместимых компьютеров появились в 90-х годах XX века. С тех пор характер угроз стал принципиально другим, отразив изменения в технологии, внедрение компьютеров во все новые сферы жизни и рост числа пользователей. В любой сфере человеческой деятельности каждое новое поколение принимает эстафету у предыдущего, учась на его достижениях. Это относится и к создателям вредоносного кода: несколько поколений вирусописателей полностью изменили ситуацию с угрозами информационной безопасности.
Чуть более десятка лет назад вирусы и другие вредоносные программы использовались для осуществления одиночных актов компьютерного вандализма и антисоциального самовыражения с применением сложных технических средств. Большинство вирусов ограничивались заражением компьютерных дисков и программ. А ущерб в основном сводился к потере данных, поскольку вирусы стирали или портили данные на диске.