Файл: Технология «клиент-сервер».pdf

Введение

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

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

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

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

Глава 1. Модель «клиент-сервер»

Глава 1.1. Описание модели клиент-сервер

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

В базовой модели клиент-сервер все процессы в распределенных системах делятся на две возможно перекрывающиеся группы. Процессы, реализующие некоторую службу, называются серверами (servers). Процессы, запрашивающие службы у серверов путем посылки запроса и последующего ожидания ответа от сервера, называются клиентами (clients). Такое взаимодействие клиента и сервера, известно также под названием режим работы запрос-ответ (request-reply behavior).^[1]

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

Сама клиент-серверная архитектура зародилась ещё во времена терминалов доступа к мейнфреймам в 1960-1970х годах. И Описана в одном из ранних документов RFC 5^[2] В этой ранней документации используется терминология server-host и user-host вместо привычной клиент-сервер.

Глава 1.2. Разделение клиент-серверного программного обеспечения по уровням

Концепция слоев или уровней (layers) – одна из общеупотребительных моделей, используемых разработчиками программного обеспечения для разделения сложных систем на более простые части. В архитектурах компьютерных систем, например, различают слои кода на языке программирования, функций операционной системы, драйверов устройств, наборов инструкций центрального процессора и внутренней логики чипов. В среде сетевого взаимодействия протокол FTP работает на основе протокола TCP, который, в свою очередь, функционирует "поверх" протокола IP, расположенного "над" протоколом Ethernet.^[3]

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

Расчленение системы на слои предоставляет целый ряд преимуществ.

- Отдельный слой можно воспринимать как единое самодостаточное целое, не особенно заботясь о наличии других слоев (скажем, для создания службы FTP необходимо знать протокол TCP, но не тонкости Ethernet).

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

- Зависимость между слоями можно свести к минимуму. Так, при смене среды передачи информации (при условии сохранения функциональности слоя IP) Служба FTP будет продолжать работать как ни в чем не бывало.

- Каждый слой является удачным кандидатом на стандартизацию (например, TCP и IP — стандарты, определяющие особенности функционирования соответствующих слоев системы сетевых коммуникаций).

- Созданный слой может служить основой для нескольких различных слоев более высокого уровня (протоколы TCP/IP используются приложениями FTP, telnet, SSH и HTTP). В противном случае для каждого протокола высокого уровня пришлось бы изобретать собственный протокол низкого уровня.^[4]

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

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

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

Четкого разделения между клиентом и сервером обычно нет. Например, сервер распределенной базы данных может выступать клиентом, передающим запросы на различные файловые серверы, отвечающие за реализацию таблиц этой базы данных. В этом случае сервер баз данных сам по себе не делает ничего, кроме обработки запросов. ^[6]

Тем не менее принято разделение на следующие уровни:

- уровень пользовательского интерфейса

- уровень обработки

- уровень данных

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

Уровень пользовательского интерфейса обычно реализуется на клиентах. Этот уровень содержит программы, посредством которых пользователь может взаимодействовать с приложением. Современные пользовательские интерфейсы поддерживают совместную работу приложений через единственное графическое окно и в ходе действий пользователя обеспечивают через это окно обмен данными.^[7]

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

Уровень данных в модели клиент-сервер содержит программы, которые предоставляют данные обрабатывающим их приложениям. Специфическим свойством этого уровня является требование сохранности – когда приложение не работает, данные должны сохраняться в определенном месте в расчете на дальнейшее использование. В простейшем случае уровень данных реализуется файловой системой. В модели клиент-сервер уровень данных обычно находится на стороне сервера.^[8]

Глава 1.3. Варианты архитектуры «клиент-сервер»

В простейшем варианте организации будет существовать всего два типа машин:

- Клиенты, выполняющие только пользовательский интерфейс.

- Серверы, реализующие всё остальное, уровень обработки и уровень данных.

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

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

Рисунок 1. Различные формы организации архитектуры клиент-сервер(Источник: Распределенные системы. Принципы и парадигмы/Э. Таненбаум, М. ван Стеен. – СПб.: Питер, 2003. – С 76)

Рассмотренные выше архитектуры относятся к физически двухзвенным архитектурам.

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

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

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

Более популярным в настоящее время и более интересным является горизонтальное распределение. При таком типе распределения клиент и сервер могут содержать физически разделенные части логически однородного модуля, причем работа с каждой из частей может происходить независимо. Это позволяет выравнивать нагрузку.^[10]

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