Модель клиент-сервер (Понятие прикладных протоколов)

Содержание:

ВВЕДЕНИЕ

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

В архитектуру клиент-сервер входят следующие основные компоненты:

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

Использование такой архитектуры помогает оптимизировать распределение вычислительных ресурсов и обеспечивает защиту данных.

1 ОСОБЕННОСТИ ФУНКЦИОНИРОВАНИЯ МОДЕЛИ «КЛИЕНТ - СЕРВЕР»

1.1 Характерные принципы функционирования модели «Клиент - Сервер»

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

- программа, установленная на компьютере пользователя, которая может осуществлять сетевой запрос с целью получения объекта, и предназначенная для его обработки (например, просмотра, изменения или печати документа);

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

- правила (протокол) взаимодействия между этими программами.

Технология взаимодействия, в которой одна программа запрашивает выполнение какой-либо совокупности действий («запрашивает услугу»), а другая ее выполняет, называется технологией «клиент-сервер». Участники такого взаимодействия называются соответственно клиентом (client) и сервером (server). Достаточно часто клиентом (или сервером) называют компьютеры, на которых функционирует то или иное клиентское (или серверное) программное обеспечение.

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

1.2 Определение сервера и клиента

При большом числе компьютеров (десятки, сотни и даже тысячи) предприятия чаще всего полагаются на сети модели «клиент-сервер». Упрощенно можно считать, что в такой сети отдельный компьютер подключается к одному или нескольким мощным компьютерам, которые называются серверами.

Сервер – это компьютер, или выполняющаяся на нём программа, которая предоставляет клиентам доступ к общим ресурсам и управляет этими ресурсами.

Клиент – пользователь (получатель) услуг и/или ресурсов, которые предоставляет сервер.

СЕРВЕР

Рисунок 1.1. - Модель клиент-сервер.

В серверных сетях серверы оснащены процессорами типа Intel Pentium 4 и сетевой операционной системой.

1.3 Роль сервера и клиента в архитектуре клиент-сервер

Роль серверов состоит в обеспечение централизованной защиты и управлении трафиком, а так же в предоставление клиентам ресурсов: информации, приложений и доступа к устройствам совместного пользования (например, к принтерам). В клиент – серверной среде в роли клиентов выступают настольные ПК (именно ПК, а не неинтеллектуальные терминалы) под управлением операционной системы типа Windows 95 или Windows NT Workstation. Как правило, клиент использует собственные вычислительные мощности для обработки информации, полученной от сервера, но полагается на сервер в части предоставления необходимых данных и приложений. Такое распределение ролей в обработке информации носит название клиентской (front - end) и серверной (back - end) обработки.

Наряду с успешным функционированием в собственной «родной» среде, сети модели клиент – сервер могут работать с микрокомпьютерами и мэйнфреймами. Именно эта гибкость в сочетании достаточно низкой (по сравнению с традиционными решениями) стоимостью и составляет привлекательность клиент – серверных сетей. Работая в такой среде на компьютере – клиенте, можно «вкушать плоды» трех разных методов обработки информации: автономной работы, взаимодействия с другими ПК сети и подключения к серверу или мэйнфрейму для доступа к хранящейся там информации.

1.4 Понятие прикладных протоколов

Необходимо различать понятия сетевых приложений и протоколов прикладного уровня. Протоколы прикладного уровня являются частью (хотя и весьма большой) сетевых приложений. Рассмотрим два примера. Web является сетевым приложением, позволяющим пользователям получать web-документы по запросу и состоящим из множества компонентов, включая стандарт формата документов (HTML), браузеры (Netscape Navigator, Microsoft Internet Explorer и др.), web-серверы (например, Apache, Microsoft или Netscape), протоколы прикладного уровня. Протокол прикладного уровня для web носит название протокола передачи гипертекста (HyperText Transfer Protocol, HTTP) и описывает формат и порядок обмена сообщениями между клиентом и сервером (RFC 2646). Таким образом, HTTP является лишь частью web-приложения.

В качестве второго примера рассмотрим приложение электронной почты. Электронная почта Интернета также состоит из множества компонентов: почтовых серверов, содержащих почтовые ящики пользователей, программ для просмотра и создания электронных писем, стандартов, описывающих структуру электронных писем, протоколов прикладного уровня, регламентирующих порядок обмена сообщениями серверов между собой и с оконечными системами пользователей, а также интерпретацию полей, из которых состоят электронные письма. Основным протоколом прикладного уровня для электронной почты является протокол простой передачи сообщений (Simple Mail Transfer Protocol, SMTP). Как мы видим, SMTP (RFC 2821) — лишь часть (хотя и достаточно большая) структуры приложений электронной почты.

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

□ типы используемых сообщений, например запросы и ответы;

□ синтаксис каждого из типов сообщений, описывающий поля сообщения и их разделители;

□ семантику полей, то есть смысл информации, содержащейся в каждом из полей сообщения;

□ правила, описывающие события, которые вызывают генерацию сообщений.

Некоторые из протоколов прикладного доступа (HTTP, SMTP и др.) являются официально документированными в RFC. Это означает, что если разработчик нового браузера будет следовать стандарту, то браузер сможет получать документы с любого web-сервера, построенного по этому же стандарту. Тем не менее существует множество протоколов прикладного уровня, которые не стандартизированы и при этом используются для поддержки коммерческих продуктов. В частности, это характерно для Интернет-телефонии.

1.5 Представление данных в системах обработки данных

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

На сегодняшний день существует ряд веб-приложений, к которым выдвигается требование постоянного обеспечения актуальности информации. К таким приложениям можно отнести веб-приложения мониторинга состояния какой-либо системы или процесса, приложения для совместной работы, системы мгновенного обмена сообщениями, многопользовательские браузерные онлайн игры и другие. Иногда подобного рода приложения называют веб-приложениями с применением коммуникаций реального времени, или веб-приложениями реального времени [1, c. 222].

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

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

В связи с описанным ограничением протокола HTTP для организации интенсивного обмена информацией применяются несколько способов, использующих технологии AJAX и Comet, которые позволяют его обойти. Рассмотрим основные из этих методов в хронологическом порядке их появления.

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

Рисунок 1. Опрос (polling)

К очевидным недостаткам такого подхода следует отнести следующие:

• очень много лишних запросов, посылаемых клиентом, когда на сервере еще нет новых данных;
• серверу приходится хранить информацию о произошедших событиях до тех пор, пока клиент не запросит их или пока они не устареют;
• события всегда приходят с опозданием, ввиду заданного интервала и времени, требуемого на открытие соединения.

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

Более совершенными транспортными технологиями являются технологии под общим термином Comet. Comet – это коллекция техник, которые при постоянном (или длительном) HTTP-соединении позволяют веб-серверу отправлять данные браузеру без дополнительного запроса с его стороны. Общая черта таких моделей состоит в том, что все они основаны на технологиях, непосредственно поддерживаемых браузером.

К таким техникам относится другой способ обмена сообщениями, называемый длительный опросом (англ. long polling). После загрузки веб-страницы, клиентский код выполняет запрос, но сервер не отвечает и не закрывает соединение, пока не появятся новые данные или пока клиент не отключится самостоятельно. Как только данные появились – отправляется ответ и соединение закрывается. После чего клиент сразу же отправляет следующий запрос, снова запуская процесс ожидания (рисунок 2).

Рисунок 2. Длинный опрос (long-polling)

Достоинства этого метода по сравнению с классическим опросом (polling):

• минимальное количество запросов;
• высокая временная точность событий;
• отсутствие необходимости длительного хранения событий сервером.

Общим недостатком для всех методов, работающих по средствам протокола HTTP, является избыточный размер сообщений, обусловленный передачей служебных HTTP-заголовков вместе с полезной информацией. Каждое подключение к серверу требует передачи полного набора НТТР-заголовков, и при необходимости обеспечения малого интервала времени между запросами это становится настоящей проблемой.

Для получения информации со стороны сервера также возможно использовать и дополнительные модули для браузеров, такие как Adobe Flash и Java. Они допускают простые TCP-соединения с сервером, которые могут использоваться для принудительной отправки клиентам оперативной информации. К проблемам применения сторонних модулей относится то, что нет никакой гарантии их установки в клиентском браузере, а также частые конфликты этих модулей с брандмауэрами, особенно в корпоративных сетях. Кроме того, технологии Comet не были приведены к стандарту и поэтому имеют проблему несовместимости кода в различных браузерах [2, с. 127].

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

Одна из таких технологий – Server-Sent Events (SSE) [4]. Эта технология позволяет клиентскому JavaScript коду в браузере создавать специальный объект EventSource, который сам обеспечивает соединение с сервером, делает пересоединение в случае обрыва и генерирует события при поступлении данных или возникновении ошибок.

После создания объекта EventSource с указанием адреса подключения браузер отправит запрос на установление соединения серверу. Чтобы соединение успешно открылось, сервер должен ответить с HTTP-заголовком "Content-Type: text/event-stream" и не закрывать соединение. После этого сервер может отправлять в открытое соединение сообщения, когда появляется новая информация (рисунок 3).

Рисунок 3. Server-Sent Events

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

Технология Server-Sent Events значительно уменьшает количество передаваемых по сети лишних данных, HTTP-заголовки передаются только при установлении соединения. Сообщения от сервера не сопровождаются HTTP-заголовками, что в значительной степени минимизирует накладные расходы на передачу. Однако передача данных таким способом возможна только в одностороннем порядке: от сервера к клиенту.

Альтернативным решением в виде части спецификации HTML5 является технология WebSocket. WebSocket – это протокол, предоставляющий двунаправленную полнодуплексную связь, работа которой обеспечивается поверх протокола TCP [6, с. 1]. Стандартизация программного интерфейса (WebSocket API) для доступа к протоколу из веб-браузера осуществляется организацией W3C [5], а сам протокол WebSocket определяется стандартом RFC 6455 [3]. Переключение с HTTP на WebSocketпротокол происходит с помощью обмена специальными заголовками между клиентом и сервером. Если сервер в ответных заголовках подтверждает этот переход, то дальше общение идёт на специальном протоколе WebSocket, который уже не имеет с HTTP ничего общего.

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

Рисунок 4. WebSocket

Протокол WebSocket подробно описан в RFC 6455 [3]. Здесь лишь отметим, что формат пакета (фрейма) данных имеет компактную структуру, обеспечивая минимум накладных расходов на передачу и повышая тем самым производительность. Кроме того, фреймы делятся на два больших типа: фреймы с данными и управляющие фреймы, предназначенные для проверки связи (ping) и закрытия соединения. Помимо передачи текстовой информации, фреймы с данными могут содержать и бинарные данные.

Для обеспечения безопасного соединения, WebSocket также может работать через TLS (TransportLayer Security). В таком случае, при создании экземпляра WebSocket с помощью HTML5 WebSocketAPI, указывается URL-схема “wss://” вместо “ws://” для незащищенного соединения. Этот метод является наиболее предпочтительным, обеспечивающим не только шифрование соединения, но и предотвращение разбора такого подключения прокси-серверами, некоторые версии которых могут изменять заголовки «обновления» протокола, приводя их в негодность.

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

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

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

• Использование современных подходов стандартизованных HTML5 (Server-Sent Events и WebSocket) позволяет существенно повысить производительность интерактивных веб-приложений с интенсивным обменом данными между клиентом и сервером. По возможности стоит придерживаться именно этих технологий коммуникации и прибегать к использованию более примитивных средств транспортировки данных, таких как Comet или опрос, лишь в случае отсутствия их поддержки используемыми браузерами.
• Server-Sent Events отправляются по традиционному протоколу HTTP. Это означает, что они не требуют специальной реализации протокола или сервера. Кроме того, SSE-cобытия имеют ряд особенностей, которые не имеют WebSocket по умолчанию, такие как автоматическое переподключение и идентификаторы событий. Использование SSE в веб-приложениях, в которых осуществляется однонаправленная передача данных от сервера клиенту, может ускорить время разработки.
• Для повышения надежности и отказоустойчивости в случае использования WebSocket можно применять балансировщик TCP-загруженности.
• Рекомендуется использовать безопасные WebSocket-подключения (wss). Прокси-серверы не станут заниматься закодированными подключениями, что обеспечит поддержу протокола старыми версиями серверов, а также добавится преимущество защищенности данных от подслушивания.

При использовании SSE и WebSocket удобно использовать веб-сервер, реализующий цикл событий (англ. event loop) для поддержания асинхронности.
 

2 ОСНОВНЫЕ ПРИНЦИПЫ ПОСТРОЕНИЯ РАСПРЕДЕЛЁННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

2.1 Основные принципы структурного подхода

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

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

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

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

2.2 Неоднородность ресурсов в распределенных системах

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

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

2.3 Концепции и принципы объектного подхода

Основные понятия объектно-ориентированного подхода - объект, класс и экземпляр.

Объект - это абстракция множества предметов реального мира, обладающих одинаковыми характеристиками и законами поведения. Объект представляет собой типичный неопределенный элемент такого множества. Экземпляр объекта - это конкретный определенный элемент множества. Например, в банковском деле объектом является некоторый лицевой счет, а экземпляром этого объекта - лицевой счет #123.

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

Таким образом, объект - это типичный представитель класса, а термины «экземпляр объекта» и «элемент класса» равнозначны.

С точки зрения объектного моделирования понятия «описание класса» и «описание объекта» эквивалентны, так как для определения множества схожих элементов, образующих класс, достаточно описать его типичного представителя, то есть объект.

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

Объектный подход предполагает, что собственные ресурсы, которыми могут манипулировать только методы самого объекта, скрыты от внешних компонентов. Сокрытие данных и методов в качестве собственных ресурсов объекта получило название инкапсуляции.

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

Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов.

2.4 Особенности применения объектного подхода

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

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

Класс объектов, кроме структур данных, определяет функции (методы), применимые к этим структурам.

В примере с объектом «Покупатель» класс может содержать такие функции (методы), как проверить кредитоспособность, выставить счет и т. д. Класс - это ключевой элемент, обеспечивающий модульность в проектных спецификациях ИС и программных решениях.

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

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

Третьим важным качеством объектного подхода является согласованность моделей системы от стадии анализа до программных модулей.

Требование согласованности моделей выполняется благодаря возможности применения абстрагирования, модульности, полиморфизма на всех стадиях разработки.

Модели анализа могут быть непосредственно подвергнуты сравнению с моделями реализации.

По объектным моделям может быть прослежено отображение реальных сущностей моделируемой предметной области в объекты и классы информационной системы.

сервер клиент данные объектный

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Биячуев, Т. А. Безопасность корпоративных систем: учеб. пособие / Т. А. Биячуев. – СПб.: СПб ГУ ИТМО, 2014. – 161 с.
2. Браун, С. Виртуальные частные сети : учеб. пособие / С. Браун. – М: Лори, 2015. – 481 с.
3. Романец, Ю. В. Защита информации в компьютерных системах и сетях: Учебное пособие / Ю.В.Романец, П.А.Тимофеев, В.Ф.Шаньгин. – М. : Ифра-М, 2015. – 304 с.
4. Дворский, М. Н. Техническая безопасность объектов предпринимательства : Учебное пособие / М. Н. Дворский, С. Н. Палатченко. – М. : А-депт, 2016. – 304 с.
5. ViPNet Администратор: Руководство администратора
6. ViPNet Координатор: Руководство администратора
7. http://www.infotecs.ru
8. http://expo-infosecurity.ru
9. http://ru.wikipedia.org/wiki/VPN