Как клиент взаимодействует с сервером
Что такое взаимодействие Клиент-Сервер?
Сегодня речь пойдет о так называемом взаимодействии Клиент-Сервер, так как практически все программное обеспечение построено на данном принципе. А как Вы помните, что у нас сайт для начинающих программистов и понимание данного взаимодействия обязательно для новичка в программирование. Поэтому в данном материале мы рассмотрим, что это такое и для чего это нужно.
Как я уже сказал, если Вы хотите стать программистом то Вы должны понимать принцип данного взаимодействия, потому что хотите Вы или нет, Вам придется столкнуться с этим, так как это встречается практически везде, например все сайты в Интернете построены на этом, все программы которые используют базу данных, сюда также можно и отнести и автоматическое обновление программ, и многое другое.
Теперь поговорим подробней. Что такое взаимодействие Клиент-сервер? Это взаимодействие двух программных продуктов между собой, один из которых выступает в качестве сервера, а другой соответственно в качестве клиента. Клиент посылает запрос, а сервер отвечает ему. А что такое клиент и что такое сервер? Спросите Вы. Клиент это программная оболочка, с которой взаимодействует пользователь. А сервер это та часть программного обеспечения, которая выполняет все основные функции (хранит данные, выполняет расчеты). Другими словами, пользователь видит программу, которая, допустим, работает с какими-то данными, которые хранятся в базе данных, тем самым он видит всего лишь интерфейс этой программы, а все самое основное выполняет сервер, и процесс когда пользователь оперирует данными через интерфейс программы, при котором клиентская часть взаимодействует с серверной, и называется Клиент-Сервер. В качестве клиента не обязательно должен выступать интерфейс, который видит пользователь, в некоторых случаях в качестве клиента может выступать и просто программа или скрипт, например, данные на сайте хранятся в базе данных, соответственно скрипты, которые будут обращаться к базе данных и будут являться клиентом в данном случае, хотя и сами эти скрипты являются сервером для клиентской часть сайта (интерфейса).
А для чего это нужно?
Это лучше объяснить на примере.
Допустим, Вы написали программу, которая умеет работать с некими данными и установили ее пользователю, все замечательно работает, пока другой пользователь не скажет, а я хочу такую же программу, но чтобы данные у нас были одни, и при редактировании одним пользователем другой мог увидеть это изменение. И для этого Вам необходимо сделать какую-то базу данных доступ, к которой можно получить через интерфейс Вашей программы, причем данная база должна располагаться на отдельном сервере, для того чтобы все пользователи могли получить к ней доступ, конечно, которым Вы разрешите.
И тем самым всем пользователям, которым нужна эта программа, Вы устанавливаете только клиентскую часть и настраиваете взаимодействие с сервером. В данном случае подразумевается, что Вы на сервере установите СУБД (Система управления базами данных).
Где под клиентом понимается клиентская часть приложения, которая взаимодействует с серверной частью приложения по средствам сети.
Все сайты в Интернете располагаются где-то на серверах (хостинге), а Вы соответственно хотите получить доступ к ним и для этого используете браузер и в данном случае браузер и есть клиент, а файлы на хостинге сервер. Если разбирать отдельно взятый сайт, то здесь также присутствует данное взаимодействие, к примеру, в браузере Вы видите всего лишь интерфейс приложения и при любых Ваших действиях на этом сайте данный интерфейс будет отправлять запрос серверу который выполнит все что Вы запросили и пришлет ответ, а клиент в свою очередь отобразит этот ответ, для того чтобы пользователь смог увидеть его.
Другими словами принцип клиент-сервер основан на том, что клиент отправляет запрос серверу, а сервер отвечает ему. И данные запрос-ответы могут выглядеть по-разному, могут использоваться разные протоколы, такие как tcp/ip, http, rdp и много других.
Теперь надеюсь, стало понятно, что такое Клиент-сервер, теперь давайте немного поговорим о том, как лучше реализовывать данное взаимодействие.
Как уже говорилось выше, если Вы захотели хранить данные в базе данных то лучше всего использовать СУБД, такие как MSSql, MySQL, Oracle, PostgreSQL так как данные СУБД предоставляют огромные возможности для серверной разработки. Так как, когда Вы будете разрабатывать программное обеспечение по такому принципу, Вам лучше всего четко разграничить клиент и сервер, т.е. клиент выполняет только роль интерфейса, из которого можно будет посылать запросы серверу на запуск процедур или функций, а соответственно сервер будет выполнять эти процедуры и функции и посылать результат их выполнения клиенту, предварительно, конечно же, Вы должны будете написать эти самые процедуры и функции, что и позволяют делать данные СУБД. Этим Вы упростите разработку и увеличите производительность Вашего программного обеспечения. Поэтому запомните клиент, во всех случаях, при взаимодействии Клиент-Сервер должен выполнять только лишь функцию интерфейса, и не нужно на него возлагать какие-то там другие задачи (обработка данных и другое), все, что можно перенести на сервер переносите, а пользователю предоставьте всего лишь интерфейс.
В связи с этим пришло время поговорить о преимуществах данной технологии:
Есть также пару недостатков :
Или на примере сайта в Интернете, существуют как серверные языки программирования, например PHP так и клиентские, например JavaScript, поэтому, если Вы решили сами создать нормальный сайт в Интернете, то учтите, что Вам придется с этим столкнуться и проще говоря, Вы должны будете стать Web-мастером который должен знать ой как много:).
Как Вы уже поняли, что взаимодействие Клиент-Сервер используется практически везде, и можно сказать, сеть построена, для того чтобы пользователь, по средствам программного обеспечения, мог взаимодействовать с другими пользователями или удаленными ресурсами, так как все что Вы запрашиваете или отправляете по сети основано на взаимодействие запрос-ответ. Поэтому начинающий программист должен понимать данное взаимодействие и в последствие реализовывать его.
Пьеса «Разработка многопользовательской сетевой игры.» Часть 3: Клиент-серверное взаимодействие
С третьей частью я немного задержался. Но как говорится лучше поздно чем никогда…
Итак, продолжаем разговор.
В третьей части нашей постановки мы реализуем протокол, напишем сервер и клиент которые будут взаимодействрвать по сети. И (ОМГ!) танки будут ездить!
Под катом то, что вы давно хотели, но боялись спросить…
Для особо придиристых напомню, что весь код в статье не претендует на звание «СуперПуперМегаОфигительноеОхрененноЗашибательское решение всех проблем». Код призван показать основные моменты и только. Он местами некрасив, неоптимален, но надесь основную суть передает.
Со времени последнй статьи произошло много событий. Одно из них это то, что я перешел на разработку для Scala под IDEA. Причина банальна — плагин для NetBeans совсем отстойный… Следовательно проект в bitbucket изменен с NetBeans на IDEA, так что не пугайтесь. И хоть первые впечатления от IDEA не очень положительные, попробую прожевать это кактус.
Вспомним что там с архитетурой…
Она хорошо ложится на Акторы в скале. Получается, что будет один процесс (GameServer) который принимает коннекты и после установки соединения передает канал Актору (ClientHandler) для обработки. Таким образом для каждого клиента будет создан свой актор и он будет отвечать за связь с клиентом. Для отправки сообщения клиенту мы просто отправляем его актору и забываем, актор сам отправит его клиенту и примет ответ. Вообще акторы в скале очень интересная вещь. Их можно создавать десятками тысяч, практически на каждый чих. Есть еще одна реализация акторов на скале, проект Akka. Он гораздо более навороченный. И для реальных проектов имеет смысл присмотреться нему.
Часть третья. Действие второе: Протокол передачи данных.
Для начала создадим класс игрока Player. Он будет хранить id игрока и его координаты.
Протокол у нас самый простой Для его реализации надо создать 2 класса. Класс Packet в котором и бут храниться сообщение.
и Класс кодирующий и декодирующий сообщения
Реализация протокола готова. Как видно, в простейших случаях ничего страшного. Но в реальных проектах для изобретения своего велосипеда должны быть весские основания. Лучше использовать готовые проверенные временем решения.
Часть третья. Действие третье: Сервер, как много в этом слове.
Пока мы создаем каркас игры. Поэтому сервер будет выполнять чисто номинальную работу. Обрабатывать подключение клиентов и обеспечивать связь между клиентами. В дальнейшем мы его будем дорабатывать.
Cоздаем класс GameServer
Сервер получился простой как перпендикуляр. Запускается он в отдельном треде. Хлеба не просит. Здесь показана только сама работа с клиентами. Нет частей обрабатывающих корректное подключение/отключение клиентов. Нет управления сессиями. Но это уже каждый может доработать как ему нравится.
Часть третья. Действие четвертое: Актор еще Актор.
Теперь создадим Actor который будет обрабатывать клиентское соединение.
Актор получился простой как палка. Он только принимает сообщения и отсылает их.
Для нагрузочного тестирования я запустил сервер у себя на довольно слабеньком ноутбуке (1.3 Ггц, AMD, WiFi 56Mbit). А в качестве клиента создал консольное java приложение которое запускает указанное количество потоков и в каждом непрерывно, без паузы, отсылает пакеты на сервер. Клиент запускался на десктопе (3.6 Ггц, 4 ядра) в 100 потоков.
В итоге сервер переваривал порядка 6000 сообщений в секнду. Что в общем-то неплохо. В зависимости от вычислительной нагрузки, на реальном серверном железе, он сможет держать несколько тысяч клиентов.
Клиент с прошлой части практически не изменился. Добавилось только граическое отображение игрока в виде танка и реализация протокола.
Добавим класс описывающий игрока
А также допишем методы реализующие протокол.
Вот и готово базовое взаимодействие между клиентом и сервером.
Не решены вопросы корректного подключения/отключения клиентов, синхронизация клиентов (из-за чего танки при движении дергаются). Это все нас ждет в следующих частях…
P.S. Многовато кода… может убрать часть и оставить только описание методов?
Как всегда все исходники можно посмотреть на Github
Архитектура клиент-сервер
Веб-приложение – это клиент-серверное приложение, в котором клиентом выступает браузер, а сервером – веб-сервер (в широком смысле).
Основная часть приложения, как правило, находится на стороне веб-сервера, который обрабатывает полученные запросы в соответствии с бизнес-логикой продукта и формирует ответ, отправляемый пользователю. На этом этапе в работу включается браузер, именно он преобразовывает полученный ответ от сервера в графический интерфейс, понятный пользователю.
Архитектура «клиент-сервер» определяет общие принципы организации взаимодействия в сети, где имеются серверы, узлы-поставщики некоторых специфичных функций (сервисов) и клиенты (потребители этих функций).
Практические реализации такой архитектуры называются клиент-серверными технологиями.
Расположение компонентов на стороне клиента или сервера определяет следующие основные модели их взаимодействия в рамках двухзвенной архитектуры:
Клиент – это браузер, но встречаются и исключения (в тех случаях, когда один веб-сервер (ВС1) выполняет запрос к другому (ВС2), роль клиента играет веб-сервер ВС1). В классической ситуации (когда роль клиента выполняет браузер) для того, чтобы пользователь увидел графический интерфейс приложения в окне браузера, последний должен обработать полученный ответ веб-сервера, в котором будет содержаться информация, реализованная с применением HTML, CSS, JS (самые используемые технологии). Именно эти технологии «дают понять» браузеру, как именно необходимо «отрисовать» все, что он получил в ответе.
Веб-сервер – это сервер, принимающий HTTP-запросы от клиентов и выдающий им HTTP-ответы. Веб-сервером называют как программное обеспечение, выполняющее функции веб-сервера, так и непосредственно компьютер, на котором это программное обеспечение работает. Наиболее распространенными видами ПО веб-серверов являются Apache, IIS и NGINX. На веб-сервере функционирует тестируемое приложение, которое может быть реализовано с применением самых разнообразных языков программирования: PHP, Python, Ruby, Java, Perl и пр.
База данных фактически не является частью веб-сервера, но большинство приложений просто не могут выполнять все возложенные на них функции без нее, так как именно в базе данных хранится вся динамическая информация приложения (учетные, пользовательские данные и пр).
Третьим звеном в трехзвенной архитектуре становится сервер приложений, т.е. компоненты распределяются следующим образом:
Трехзвенная архитектура может быть расширена до многозвенной (N-tier, Multi-tier) путем выделения дополнительных серверов, каждый из которых будет представлять собственные сервисы и пользоваться услугами прочих серверов разного уровня.
Двухзвенная архитектура проще, так как все запросы обслуживаются одним сервером, но именно из-за этого она менее надежна и предъявляет повышенные требования к производительности сервера.
Трехзвенная архитектура сложнее, но, благодаря тому, что функции распределены между серверами второго и третьего уровня, эта архитектура предоставляет:
Клиент-серверные технологии
Архитектура клиент-сервер применяется в большом числе сетевых технологий, используемых для доступа к различным сетевым сервисам.
Типы сервисов:
Изначально предоставляли доступ к гипертекстовым документам по протоколу HTTP (Hyper Text Transfer Protocol). Сейчас поддерживают расширенные возможности, в частности, работу с бинарными файлами (изображения, мультимедиа и т.п.).
Предназначены для централизованного решения прикладных задач в некоторой предметной области. Для этого пользователи имеют право запускать серверные программы на исполнение. Использование серверов приложений позволяет снизить требования к конфигурации клиентов и упрощает общее управление сетью.
Серверы баз данных используются для обработки пользовательских запросов на языке SQL. При этом, СУБД находится на сервере, к которому и подключаются клиентские приложения.
Файл-сервер хранит информацию в виде файлов и предоставляет пользователям доступ к ней. Как правило, файл-сервер обеспечивает и определенный уровень защиты от несанкционированного доступа
Во-первых, действует как посредник, помогая пользователям получить информацию из Интернета и, при этом, обеспечивая защиту сети.
Во-вторых, сохраняет часто запрашиваемую информацию в кэш-памяти на локальном диске, быстро доставляя ее пользователям, без повторного обращения к Интернету.
Межсетевые экраны, анализирующие и фильтрующие проходящий сетевой трафик, с целью обеспечения безопасности сети.
Предоставляют услуги по отправке и получению электронных почтовых сообщений.
Эти системы обеспечивают связь с сетью по коммутируемым линиям. Удаленный сотрудник может использовать ресурсы корпоративной ЛВС, подключившись к ней с помощью обычного модема.
Для доступа к тем или иным сетевым сервисам используются клиенты, возможности которых характеризуются понятием «толщины». Оно определяет конфигурацию оборудования и программное обеспечение, имеющиеся у клиента. Рассмотрим возможные граничные значения:
«Тонкий» клиент
Этот термин определяет клиента, вычислительных ресурсов которого достаточно лишь для запуска необходимого сетевого приложения через web-интерфейс. Пользовательский интерфейс такого приложения формируется средствами статического HTML (выполнение JavaScript не предусматривается), вся прикладная логика выполняется на сервере. Для работы тонкого клиента достаточно лишь обеспечить возможность запуска web-браузера, в окне которого и осуществляются все действия. По этой причине web-браузер часто называют «универсальным клиентом».
«Толстый» клиент
Таковым является рабочая станция или персональный компьютер, работающие под управлением собственной дисковой операционной системы и имеющие необходимый набор программного обеспечения. К сетевым серверам «толстые» клиенты обращаются, в основном, за дополнительными услугами (например, доступ к web-серверу или корпоративной базе данных).
Так же под «толстым» клиентом подразумевается и клиентское сетевое приложение, запущенное под управлением локальной ОС. Такое приложение совмещает компонент представления данных (графический пользовательский интерфейс ОС) и прикладной компонент (вычислительные мощности клиентского компьютера).
Прикладная логика «rich»-клиента также реализована на сервере. Данные отправляются в стандартном формате обмена, на основе того же XML (протоколы SOAP, XML-RPC) и интерпретируются клиентом.
Некоторые основные протоколы «rich»-клиентов на базе XML приведены ниже:
Протокол передачи данных — набор соглашений интерфейса логического уровня, которые определяют обмен данными между различными программами. Эти соглашения задают единообразный способ передачи сообщений и обработки ошибок при взаимодействии ПО.
Сетевой протокол — набор правил и действий (очерёдности действий), позволяющий осуществлять соединение и обмен данными между двумя и более включёнными в сеть устройствами.
Сетевые протоколы:
TCP/IP — набор протоколов передачи данных, получивший название от двух принадлежащих ему протоколов: TCP (англ. Transmission Control Protocol) и IP (англ. Internet Protocol).
Наиболее известные протоколы, используемые в сети Интернет:
HTTP (Hyper Text Transfer Protocol) — это протокол передачи гипертекста.
SSL ( Secure Sockets Layer — уровень защищённых cокетов) — криптографический протокол, который подразумевает более безопасную связь.
FTP (File Transfer Protocol) — это протокол передачи файлов со специального файлового сервера на компьютер пользователя.
POP3 (Post Office Protocol) — это стандартный протокол почтового соединения.
SMTP (Simple Mail Transfer Protocol) — протокол, который задает набор правил для передачи почты.
TELNET — это протокол удаленного доступа.
DTN — протокол, предназначенный для сетей дальней космической связи IPN, которые используются NASA.
Всё ПО для работы с протоколом HTTP разделяется на три большие категории:
Как видно из названия, главные «действующие лица»:
· клиент – компьютерное устройство, которое отсылает запросы серверу, касающиеся выполнения определенных задач или предоставления конкретной информации.
· сервер – компьютерное устройство, гораздо мощнее обычного ПК.
Система работает по следующему принципу:
1. Клиент отправляет запрос серверной машине.
2. Сервер принимает обращение с требованием выполнить определенное действие и выполняет поставленную задачу.
3. Программно-аппаратный комплекс отправляет клиенту результат выполненной работы, обработанного запроса.
Модель клиент-сервер предоставляет возможность разграничить поставленные задачи и работу над вычислениями между теми, кто заказывает услуги и теми, кто их поставляет.
Основные компоненты системы:
· клиент. Рабочая станция считается входной точкой конечного пользователя в данной системе. Отправляет запросы, получает ответы;
· сервер. Взаимодействует с многочисленными клиентами и решает поставленные ими задачи;
· сеть. Здесь происходит передача данных. Посредством сети можно соединить рабочие машины общими ресурсами;
· приложения. Могут обрабатывать информацию, организовывать физическое распределение данных между сервером и клиентом. Программным обеспечением оснащают серверные устройства для сбора данных, работы с ними и хранения. А также ПО устанавливают на компьютерной станции-клиенте.
О технологии клиент-сервер
Серверное устройство поддерживает многопользовательский режим и обеспечивает одновременно работу с несколькими клиентами. Конечно, машина не может решать в прямом смысле слова одновременно несколько поставленных задач, она выстраивает запросы в очередь по мере поступления, обрабатывает обращения и отправляет результаты работы. Запросы можно выстраивать в списке по приоритетности. Чем важнее запрос, тем быстрей его обрабатывают, даже, если он поступил позже.
Рядовые пользователи сети интернет даже не догадываются о том, как их запросы моментально обслуживаются, чтобы они читали новости, книги, тематические статьи, смотрели интересные видео и фильмы, ходили по форумам, «зависали» в социальных сетях, оплачивали счета, общались с друзьями, оформляли заказы на покупку товаров и т.д. Главное, что ответная реакция быстрая.
Именно технология клиент сервер предоставляет возможность реализовать вышеуказанные многочисленные поставленные задачи. Обычно клиент – это браузер конкретного пользователя. А серверами зачастую выступают:
· любые серверы http;
· наборы серверных машин (например, Denwer);
Обмен информацией между клиентом и сервером происходит благодаря сетевым протоколам в интернете. Каждой услуге соответствует определенный протокол, их предостаточно. Запросы, отсылаемые клиентом, классифицируют как http сообщения. Здесь четко указано, какие сведения нужно предоставить, в каком оформлении. Серверное устройство после анализа и обработки запроса, обычно отвечает html документом – дает свой http ответ.
Сообщение от клиента поступает с дополнительными данными, чтобы серверу было понятно, как с ним работать. Ответ машины также отправляется с кодами помимо полезных запрашиваемых данных, чтобы браузер оценил понятливость аппаратно-программного комплекса при обработке его запроса.
Смотря на каком уровне осуществляется взаимосвязь клиента с сервером, отсылаемые сообщения браузером упаковываются по-разному. Как будто они оборачиваются клиентом в несколько слоем обертки. После того, как послание поступило серверной станции, она приступает к разворачиванию всех этих слоев, проводит анализ информации и сбор данных.
Говоря больше о технологии клиент-сервер, следует уточнить, что браузер первый выходит на контакт и делает запрос серверной машине, которая лишь предоставляет услуги в ответ на сообщения и указывает, какие условия нужно при этом соблюдать. Разные компьютерные устройства используют, чтобы установить программное обеспечение клиента и серверного оборудования. Но есть случаи, когда они работали на одном ПК.
Когда на одном сайте одновременно находятся несколько посетителей, к серверу в один момент обращается много клиентов. Однако одномоментное поступление запросов ограничено мощностью и возможностями серверных устройств, а также характером отправляемых сообщений.
Архитектура клиент-сервер
Благодаря архитектуре клиент и сервер определены позиции взаимной связи между компьютерными машинами лишь в целом. Что же касается нюансов взаимодействия, они определены протоколами. Технология вполне прозрачно намекает на разделение в сети рабочих машин: серверы и клиенты. Рабочий контакт всегда инициирован клиентской машиной. Протокол же описывает, по каким правилам этот контакт установлен и действует.
Архитектура взаимодействия между клиентом и сервером подразделяется на два вида:
· двухзвенная. Сторонние ресурсы не задействованы. Одна машина обрабатывает поступившие сообщения. В этом случае сервер должен быть высокопроизводительным. Несмотря на эти жесткие требования, архитектура очень надежная. Первый уровень – клиент отправляет запрос. Второй уровень – сервером принимается сообщение, обрабатывается и отправляется ответ.
· многоуровневая. Речь идет о любой современной архитектуре СУБД. Принципиальное отличие и особенность: запросом клиента занимаются одновременно несколько серверных устройств. Операции перераспределяются, нагрузка на серверную машину снижена и оптимальная. Единственный минус: низкая надежность по сравнению с предыдущим вариантом.
Многоуровневая клиент-серверная архитектура
Обработкой данных занимаются несколько разных серверов. Благодаря такому подходу возможности серверов и клиентов используются более эффективно за счет разделения функций:
К тому же, систему можно точнее разделить на функциональные блоки для выполнения конкретной роли. Для этого между собой взаимодействуют разнообразные серверы приложений. К примеру, реально выделить сервер, необходимый для выполнения всего функционала по управлению персоналом. При этом реально сделать такую настройку, что пользователи смогут пользоваться только его общедоступным функционалом, а детали реализации серверной машины будут недоступны, так как с ней свяжут отдельную базу данных. Подобные системы легко адаптируются под веб, ведь легче организовать доступ пользователей к конкретному функционалу БД посредством html форм, чем ко всей БД.
На веб-технологию очень просто перевести многоуровневую систему. Заменяют клиентскую часть браузером спецтипа или универсального назначения. При этом дополняют веб-сервером и компактными программными модулями сервер приложений. Многоуровневая архитектура также использует менеджеры транзакций. Обмен информацией одновременно происходит между одной серверной машиной приложений и несколькими серверами БД.
· информация защищена и безопасно хранится. Так как серверная машина БД ведет базы данных, можно независимо от программ пользователя обрабатывать информацию в базе;
· повышенная стойкость к сбоям. Сохранена целостность информационных запросов, они доступны другим пользователям, если во время работы клиента случился сбой;
· масштабируемость. Архитектура адаптируется к увеличению количества пользователей. База данных также расширяется в объеме. Однако при этом не поставлена задача менять ПО. Система наращивает аппаратные средства, так происходит подстройка под меняющиеся факторы;
· повышенная защита данных от взлома и опасных атак;
· один пользователь меньше нагружает сеть, поэтому увеличивается ее пропускная способность. Можно удовлетворить запросы большего количества пользователей;
Преимущества и недостатки архитектуры клиент-сервер
Разделен код программы клиентского и серверного приложения. Это главное преимущество архитектуры. Выбрана локальная сеть. Поэтому плюсы следующие:
· к клиентским рабочим станциям выдвигают низкие запросы;
· преимущественно все вычислительные операции выполняются на серверах;
· реально повысить защиту локальной сети.
Но не все так гладко с клиент-серверной архитектурой, есть и недостатки:
· серверные машины стоят в разы дороже, чем клиентские рабочие станции;
· обслуживание серверов доверяют только квалифицированным и профессионально подготовленным специалистам;
· работа клиентских компьютерных устройств остановлена, если в локальной сети «полетело» серверное оборудование.
Важно понимать, что нет четкого разделения оборудования на клиентское и серверное. Просто архитектура к/с дает возможность перераспределить и оптимизировать загруженность и распределить функциональность между этими рабочими станциями.