Преподаватель который помогает студентам и школьникам в учёбе.

Описание функционирования приложения

Содержание:

Введение

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

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

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

Предметом исследования являются архитектуры системы «клиент-сервер».

Целью курсовой работы является исследование архитектуры «Клиент-сервер».

Поставленная цель определила решение следующих задач, таких как:

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

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

Глава 1. Теоретические аспекты архитектуры «клиент-сервер»

1.1. Особенности и принципы архитектуры «клиент-сервер»

Архитектура «клиент-сервер» является наиболее распространенной архитектурой распределенной системы, которая разбивает систему на две основные подсистемы или логические процессы –

Клиент – это первый процесс, который отправляет запрос второму процессу, то есть серверу.

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

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

Рисунок 1 – Архитектура «клиент-сервер»

Типичные варианты разделения функций между клиентом и сервером (рисунок 2):

- распределенная база данных;

- распределенное представление;

- сервер базы данных (удаленное представление);

- распределенная функция;

- удаленный доступ к данным.

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

Сервер выполняет следующие функции:

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

Функции, которые реализуются клиентской частью:

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

Рисунок 2 – Варианты разделения функций между клиентом и сервером

Наиболее распространенными является модель удаленного доступа к данным и модель сервера базы данных (удаленного представления).

Моделью удаленного доступа к данным (RDA) реализуются функции представления информации и логика прикладной обработки с помощью совмещенных программ, которые выполняются на клиенте. Функция управления данными реализуется через среду передачи при помощи операторов языка SQL или вызова функций специальной библиотеки API (интерфейс прикладного программирования).

Основным достоинством RDA-модели является большое количество готовых СУБД с SQL-интерфейсами и инструментальных средств, которые обеспечивают быстрое создание клиентских программ.

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

В модели сервера БД (DBS) функции клиента ограничены функциями представления информации, а прикладные функции обеспечивает приложение, которое находится на сервере. Такая модель более технологична, чем модель RDA, и реализуется в СУБД Oracle, Sybase и Ingress. Приложения при этом реализуются как хранимые процедуры.

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

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

Модель распределенного представления представлена мощным сервером, а клиенты практически отсутствуют. К функциям клиента относится простое отображение информации на мониторе и связь с сервером с помощью локальной сети. Модель распределенного представления реализуется в СУБД, которые поддерживают работу X-терминалов. Хост-машина (основной компьютер) должна быть достаточно мощной для возможности обслуживания нескольких Х-терминалов. У X-терминала должен быть достаточно быстрый процессор и большой объем оперативной памяти вследствие отсутствия дисковых накопителей.

Достоинством данной модели является простота управления доступом к системе и обслуживания, а также невысокая стоимость.

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

1.2. Модели «тонкого» и «толстого» клиента

Клиент-серверная архитектура может быть классифицирована на две модели на основе функциональности клиента –

Модель «тонкого» клиента.

В модели «тонкого» клиента вся обработка приложений и управление данными осуществляется сервером. Клиент просто отвечает за запуск программного обеспечения для презентации.

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

Используется, когда устаревшие системы переносятся на архитектуры клиент-сервер, в которых устаревшая система действует как сервер сама по себе с графическим интерфейсом, реализованным на клиенте

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

Модель «толстого» клиента.

В модели «толстого» клиента сервер отвечает только за управление данными. Программное обеспечение на клиенте реализует логику приложения и взаимодействия с пользователем системы.

Наиболее подходит для новых систем C / S, где возможности клиентской системы известны заранее
Более сложная, чем модель «тонкого» клиента, особенно для управления. Новые версии приложения должны быть установлены на всех клиентах.

Наиболее подходит для новых систем C/S, где возможности клиентской системы известны заранее

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

Рисунок 3 – Модели «клиент-серверной» архитектуры

1.3. Многоуровневая архитектура «клиент-сервер»

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

Рисунок 4 – Трехуровневая архитектура «клиент-сервер»

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

Рисунок 5 – Состав трехуровневой архитектуры

Уровень презентации.

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

Уровень приложения (бизнес-логика, уровень логики или средний уровень).

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

Уровень данных.

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

Преимущества:

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

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

Улучшает возможность повторного использования и масштабируемости – по мере увеличения требований могут быть добавлены дополнительные серверы.

Обеспечивает многопоточную поддержку, а также уменьшает сетевой трафик.

Обеспечивает ремонтопригодность и гибкость

Недостатки:

Неудовлетворительная тестируемость из-за отсутствия инструментов тестирования.
Более критичная надежность и доступность сервера.
Неудовлетворительная тестируемость из-за отсутствия инструментов тестирования.
Более критичная надежность и доступность сервера.

Глава 2. Клиент-серверное приложение для защищенной передачи сообщений

2.1 Концепция приложения

Клиент-серверная архитектура приложения подразумевает наличие у предприятия собственного сервера. Такое решение имеет ряд преимуществ:

1) все передаваемые данные не покидают пределов предприятия;

2) приложение будет работать даже при отсутствии подключения к сети Интернет;

3) «прозрачность» - можно быть уверенным, что удаляемые данные действительно удалены, чего нельзя ожидать в случае, если разработчик предоставляет только клиентскую часть, а серверная остается подведомственной разработчику и/или другим сторонним лицам.

Обмен сообщениями производится с использованием протокола SSL (Secure Sockets Layer – уровень защищенных сокетов), кроме того, каждое сообщение дополнительно шифруется на основе криптосистемы с открытым ключом RSA. Такое двойное шифрование обезопасит данные в случае успешной атаки злоумышленника на протокол SSL, или взлома сервера (на сервере история сообщений хранится в зашифрованном виде).

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

2.2 Описание инструментов разработки и базы данных

Приложение было разработано на языке C++ с использованием библиотеки Qt в среде разработки MS Visual Studio 2013 for Windows Desktop Express Edition.

Для реализации криптографических алгоритмов и TLS использовалась библиотека OpenSS. OpenSSL не использует функции, специфичные для конкретной ОС, поэтому не нарушает кроссплатформенность. Функции для работы с TLS, основанные на OpenSSL, реализованы в библиотеке Qt в классе QSslSocket.

ER-модель базы приведена на рисунке 6.

Рисунок 6 – ER-модель

Сущность “Clients” – основная в базе. В ней хранятся данные пользователей:

- ID – уникальный идентификатор пользователя;

- login – имя пользователя, указанное при реистрации;

- hash – хэш-образ пароля;

- statofreg – статус регистрации пользователя:

«1» – пользователь одобрен,

«0» - одобрение не пройдено;

- status – статус присутствия пользователя в сети:

«1» - пользователь в сети,

«0» - пользователь не в сети.

Сущность «ClientList» - таблица для хранения списка контактов для каждого пользователя. Содержит поля:

- ownerID – ID пользователя, для которого задается список контактов. Повторяется в таблице столько раз, сколько пользователей содержится в списке контактов для него;

- clientID – ID пользователя, который содержится в списке контактов для пользователя ownerID.

Сущность «Message» содержит все пересылаемы сообщения. Для нее заданы следующие поля:

- ID – уникальный идентификатор сообщения;

- message – сообщение в зашифрованном виде;

- fromID – ID отправителя сообщения;

- toID – ID получателя сообщения;

- status – статус доставки сообщения.

«1» - сообщение было доставлено получателю,

«0» - сообщение не было доставлено получателю.

2.3 Описание функционирования приложения

Рассмотрим алгоритм функционирования клиентской и серверной частей приложения, а также их взаимодействие.

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

Кроме доступа к СУБД сервер должен обладать SSL-сертификатом и ключом стандарта X.509. Требуется указать путь к сертификату и ключу для загрузки их в программу.

При запуске сервера осуществляется соединение с базой данных и запуск режима прослушивания порта. Сервер находится в состоянии ожидания входящих соединений. Описание функции запуска сервера startServer() приведено в следующем пункте.

При первом запуске клиентской части приложения требуется указать адрес сервера.

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

Таблица 2 – Таблица соответствия сообщений сервера их предназначению

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

Рисунок 7 – Алгоритм регистрации нового пользователя

Рассмотрим подробнее приведенную схему.

Для регистрации требуется ввести уникальное имя нового пользователя и дважды пароль во избежание случайной ошибки при вводе пароля. После ввода данных и нажатия на кнопку «Зарегистрироваться» вычисляется хэш пароля по алгоритму SHA256, генерируется сообщение в XML-формате, содержащее имя пользователя и хэш. Открывается временное SSL-соединение с сервером, на который направляется сгенерированное сообщение.

Далее клиент переходит в режим ожидания ответа от сервера. Если в указанный интервал времени ответ от сервера не был получен, выводится сообщение об ошибке соединения, временное SSL-соединение закрывается. Сервер, получив сообщение, по тегу <registrate> определяет, что это сообщение является запросом на регистрацию, вычленяет из него значения имени пользователя и хэша пароля. Производит поиск по базе пользователей на предмет существования пользователя с таким именем. Если пользователь с таким именем найден в базе, генерируется и отправляется XML-сообщение с оповещением. В случае получения такого сообщения, клиент определяет, что пользователь с таким именем существует и выводит сообщение об этом в окне регистрации, временное SSL-соединение закрывается.

В случае, если пользователь с заданным именем не найден в базе, осуществляется генерация уникального идентификатора формата UUID (Universally Unique Identifier). Алгоритм UUID позволяет генерировать гарантированно уникальную последовательность символов, так что, даже в двух разных таблицах не найдется совпадающих идентификаторов. Такое решение будет удобно, если возникнет необходимость объединения двух, или более, таблиц.

Далее рассмотрим процесс аутентификации пользователя.

Рисунок 8 – Алгоритм аутентификации пользователя

При нажатии на кнопку «Log In» открывается окно ввода логина и пароля. После нажатия кнопки «ОК» считываются введенные данные, вычисляется хэш пароля, генерируется сообщение XML-формата, содержащее логин и хэш пароля, открывается временное SSL-соединение, после чего, сообщение отправляется серверу.

Сервер получает сообщение, по тегу <loginquery> определяет, что сообщение является запросом аутентификации, вычленяет имя пользователя и хэш пароля. Затем, выполняется поиск по таблице пользователей. Если пользователь с заданным именем не найден, или значения хэшей не совпадают, генерируется XML-сообщение с отклонением запроса аутентификации. Клиент, получив сообщение, и определив, что запрос аутентификации отклонен, выводит сообщение о том, что имя пользователя или пароль введены неверно, временное SSL-соединение закрывается. Если пользователь найден и хэши пароля совпадают, но проставлен статус «неодобрен», генерируется XML-сообщение о необходимости дождаться одобрения. В случае получения клиентом сообщения о необходимости дождаться одобрения, выводится сообщение «Дождитесь одобрения», временное SSL-соединение закрывается.

Если пользователь найден, пароль введен верно, и пользователь «одобрен», генерируется сообщение об удовлетворении запроса аутентификации, содержащее также ID пользователя. Если клиентом получено сообщение об удачной аутентификации, временное SSL-соединение переходит в статус постоянного, сохраняется значение собственного ID пользователя.

Рассмотрим процесс выхода пользователя из сети.

Рисунок 9 – Алгоритм выхода пользователя из сети

По нажатию на кнопку “Выйти из сети” клиентом генерируется XMLсообщение, информирующее сервер о выходе клиента из сети, содержащее ID. SSL-соединение закрывается. Сервер, получив сообщение с тегом <logoff>, обновляет статус пользователя в таблице на «0».

Заключение

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

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

Список литературы

Агальцов В. П. Базы данных. В 2-х т., т. 2. Распределенные и удаленные базы данных. 1-e изд. – Форум Инфра-М, 2009. – 272 с.
Васильев А. А., Избачков Ю. С., Петров В. Н., Телина И. С. Информационные системы. – Питер, 2011. – 544 с.
Волкова В. Н., Кузин Б. И., Барабанова И. М. Информационные системы: Учебное пособие для вузов (под ред. Волковой В. Н., Кузина Б. И.) Изд. 2-е, перераб., доп. – СПбГПУ, 2005 г. – 224 с.
Голицына О. Л., Партыка Т. Л., Попов И. И. Системы управления базами данных. М., Форум, Инфра-М, 2011 г. – 432 с.
Дейт К. Дж. Введение в системы баз данных. 8-е издание. – М.: Издательский дом «Вильяме», 2006. – 1328 с.
Диго С. М. Базы данных: проектирование и использование: учебник. – М.: Финансы и статистика, 2005. – 592 с.
Душин В. К. Теоретические основы информационных процессов и систем. Учебник. 4-е изд. – Дашков и К, 2011 г. – 348 с.
Карпова, Т. С. Базы данных: Модели, разработка, реализация. – СПб.: Питер, 2002. – 303 c.
Кириллов В. В., Громов Г. Ю. Введение в реляционные базы данных (+CD). – СПб.: БХВ-Петербург, 2009. – С. 464.
Коржов В.В. Многоуровневые системы клиент-сервер. – М.: Издательство Открытые системы, 2007.
Кузин А. В., Левонисова С. В. Базы данных: учеб. пособие для студ. вузов. 2-е изд., стер. – М. Издательский цент «Академия», 2008. – 320 с.
Кузнецов С. Д. Основы баз данных: учебное пособие. 2-е изд., испр. – М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. – 484 с.
Кузовкин А. В., Цыганов А. А., Щукин Б. А. Управление данными. – М.: Академия, 2010 г. – 256 с.
Малыхина М. П. Базы данных: основы, проектирование, использование: учеб. пособие для студ. Вузов. 2-е изд. – СПб.: БХВПетербург, 2007. – 528 с. Марков А. С., Лисовский К. Ю. Базы данных. Введение в теорию и методологию: учебник. – М.: Финансы и статистика, 2006. – 512 с.
Мельников В. Защита информации в компьютерных системах. – М.: Финансы и статистика, Электронинформ, 2007
Пирогов В. Ю. Информационные системы и базы данных. Организация и проектирование. – БХВ-Петербург, 2009 г. – 528 с.
Попов И., Максимов Н., Голицына О. Информационные системы. – М.: Форум, Инфра-М, 2007 г. – 496 с.
Титоренко Г.А. Информационные технологии управления. – М.: Юнити: 2012.
Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: учебник для высших учебных заведений. 6-е издание. – М.: КОРОНА-Век, 2010. –736 c.