Архитектура сервера приложений

Лекция 4. Архитектура с сервером приложений

Развитие идей архитектуры клиент-сервер привел к появлению трехзвенной архитектуры доступа к базам данных (в литературе ее также называют многозвенной архитектурой,.

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

Архитектура клиент-сервер — двухзвенная: первым звеном в ней есть программа клиента а второй — сервер БД и сама БД.

В трехзвенной архитектуре создается вспомогательная программа, в которую включаются все компоненты-наборы данных, которые были раньше (в двухзвенной архитектуре) собственностью клиентских применений. Потом эта программа регистрируется в качестве СОМ- МТ- ли СОRВА -сервера, после чего она становится сервером применений. Теперь клиентские программы уже не содержат в себе громоздкие коды компонентов-наборов и многих других вспомогательных компонентов. Выделения прикладного элемента с отдельный изолированный компонент разрешает сосредоточить в нем реализацию основной массы бизнес-правил и сделать клиентские приложения независимыми от изменений бизнеса-логики. В этом случае неправильные данные будут откидываться сервером применений и не будут передаваться на сервер БД (рис.4). Для получения доступа к серверных данных клиентские приложения обращаются к отдаленного серверу применений, которое находится на другой машине и реализует необходимый обмен данными. А функцию формирования запросов к отдаленному серверу БД выполняет сервер применений. На нем же размещаются реальные наборы данных — результаты выполнения запросов SQL-сервером.

Рис. 4. трехзвенная архитектура

В клиентской программе, которая в этой архитектуре называется облегченным или тонким клиентом (thin сlіепt), размещается клиентский набор данных, который представляет собой копию части данных из БД. Все изменения, что пользователь вносит в данные, изменяют эту локальную копию и могут к нужной поре не передаваться в БД (режим отложенной обработки данных). Потом при восстановлении отдаленного набора данных только измененные записи передаются серверу применений. В свою очередь сервер применений пересылает эти изменения SQL-серверу для записи их в отдаленную БД.

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

Заметим, что на рис. 5 по левую сторону показанный вариант размещения сервера применений на машине сервера БД. Такой вариант наиболее популярный, так как снижает загрузка сети и гарантирует одновременную работу обеих серверов.

Сервер применений может располагаться на любой сетевой машине, оснащенной ВDЕ в случае работы с клиентским применением созданным в среде Delphi. Разумеется, в этом случае каталог его размещения должен быть доступным другим сетевым машинам, а самая машина сервера применений должна быть включена в период работы с сервером данных. Больше того, в этой архитектуре можно использовать файл-серверный вариант размещения данных (на рис. 5 — по правую сторону). Таким образом, вместо сервера БД с успехом могут использоваться файлы-серверы с таблицами DЬаsе и Рагаdох. Преимущества облегченного клиента и централизации бизнесов-правил будут в полной мере оказываться и в этом случае. Кроме того, в таких системах существенным образом снижается нагрузка на сеть, так как фильтрация и отбор данных реализуются сервером применений, а клиенту пересылаются лишь результаты запроса.

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

Рис. 5. Разновидности архитектур с сервером приложений

К дополнительным преимуществам можно отнести :

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

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

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

· возможность отложенных восстановлений наборов данных: можно получить необходимую порцию данных, сохранить их в файле, работать с ними автономно (например, в другом городе), а потом снова соединиться с сервером применений и обновить на сервере внесенные в данные изменения.

Связь «тонких клиентов» с сервером применений осуществляется средствами, которые базируются на механизмах OLЕ-автоматизации и объектно-ориентированных вызовов, которые являются стандартами для отдаленных процедур в распределенных системах. На сегодняшний день существуют несколько технологий взаимодействия объектов и программ, которые параллельно развиваются и конкурируют : СОМ (Соmропепt ОЬjесt Моdel — компонентная модель объектов) корпорации Місгоsoft , СОRВА (Common ОЬjесt Require Вгокег Агсhytecture — архитектура с поставщиком необходимых общих объектов) независимой группы ОМС, МТ (Місгоsoft Тгапsасtion Server) и прочие. Эти технологии предназначены для того, чтобы одна программа (клиент) смогла заставить работать объект, который есть частью другой программы (частью сервера), так, будто этот объект был частью клиента. Причем в общем случае обе эти программы могут быть расположены на разных компьютерах (в том числе, которые находятся в разных частях мира), написанные на разных языках и таких, что выполняются под управлением разных операционных систем. Больше того самые компьютеры могут быть разного типа — например, ІВМ- совместный ПК и рабочая станция SUN.

Вопрос для самоконтроля

1. Что такое локальная база данных?

2. Что представляет собой база данных в локальной и распределенной архітектурах?

3. Кем и как выполняется синхронизация данных в архитектуре «сервер^-сервер-файл-сервер»?

4. Назовите недостатки архитектуры сервер^-сервер-файл-сервер?

5. Назовите преимущества архитектуры сервер^-сервер-клиент-сервер?

6. Что такое Промышленная СУБД?

Что такое сервер приложений?

\|	следующая лекция ==>
Лекция 3. Клиент-серверные базы данных	\|	Атаки на уровне систем управления базами данных

Дата добавления: 2014-01-15 ; Просмотров: 758 ; Нарушение авторских прав?

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

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

О модели взаимодействия клиент-сервер простыми словами. Архитектура «клиент-сервер» с примерами

28.07.2016
Сервера и протоколы
Комментариев нет

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

Модель взаимодействия клиент-сервер. Архитектура «клиент-сервер».

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

Концепция взаимодействия клиент-сервер

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

Здесь мы разберемся с концепцией, которая позволяет нам выполнять все эти действия в сети Интернет. Данная концепция получила название «клиент-сервер». Как понятно из названия, в данной концепции участвуют две стороны: клиент и сервер. Здесь всё как в жизни: клиент – это заказчик той или иной услуги, а сервер – поставщик услуг. Клиент и сервер физически представляют собой программы, например, типичным клиентом является браузер. В качестве сервера можно привести следующие примеры: все HTTP сервера (в частности Apache), MySQL сервер, локальный веб-сервер AMPPS или готовая сборка Denwer (последних два примера – это не проста сервера, а целый набор серверов).

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

Читать еще: Основные принципы архитектуры

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

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

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

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

Простая схема взаимодействия клиент-сервер

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

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

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

Давайте теперь ответим на вопрос: «зачем веб-мастеру или веб-разработчику понимать концепцию взаимодействия клиент-сервер?». Ответ, естественно, очевиден. Чтобы что-то делать своими руками нужно понимать, как это работает. Чтобы сделать сайт и, чтобы он правильно работал в сети Интернет или хотя бы просто работал, нам нужно понимать, как работает сеть Интернет.

Мы уже упоминали, что большая часть сетевых протоколов имеют архитектуру клиент-сервер. Например, веб-мастеру или веб-разработчику будут интересны протоколы седьмого и шестого уровня эталонной модели. Сетевым администраторам важно понимать, как происходит взаимодействие на уровнях с пятого по второй. Для инженеров связи наибольший интерес представляют протоколы с четвертого по первый уровень модели OSI.

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

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

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

Существует два вида архитектуры взаимодействия клиент-сервер: первый получил название двухзвенная архитектура клиент-серверного взаимодействия, второй – многоуровневая архитектура клиент-сервер (иногда его называют трехуровневая архитектура или трехзвенная архитектура, но это частный случай).

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

Двухуровневая модель взаимодействия клиент-сервер

Здесь четко видно, что есть клиент (1-ый уровень), который позволяет человеку сделать запрос, и есть сервер, который обрабатывает запрос клиента.

Если говорить про многоуровневую архитектуру взаимодействия клиент-сервер, то в качестве примера можно привести любую современную СУБД (за исключением, наверное, библиотеки SQLite, которая в принципе не использует концепцию клиент-сервер). Суть многоуровневой архитектуры заключается в том, что запрос клиента обрабатывается сразу несколькими серверами. Такой подход позволяет значительно снизить нагрузку на сервер из-за того, что происходит распределение операций, но в то же самое время данный подход не такой надежный, как двухзвенная архитектура. На рисунке ниже вы можете увидеть пример многоуровневой архитектуры клиент-сервер.

Многоуровневая архитектура взаимодействия клиент-сервер

Типичный пример трехуровневой модели клиент-сервер. Если говорить в контексте систем управления базами данных, то первый уровень – это клиент, который позволяет нам писать различные SQL запросы к базе данных. Второй уровень – это движок СУБД, который интерпретирует запросы и реализует взаимодействие между клиентом и файловой системой, а третий уровень – это хранилище данных.

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

Преимущества и недостатки архитектуры клиент-сервер

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

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

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

Краткий обзор 10 популярных архитектурных шаблонов приложений

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

Что такое архитектурный шаблон?

По материалам Википедии,

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

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

1. Многоуровневый шаблон

2. Клиент-серверный шаблон

4. Каналы и фильтры

5. Шаблон посредника

6. Одноранговый шаблон

1. Многоуровневый шаблон

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

Читать еще: Архитектура базы данных

Чаще всего в общих информационных системах встречаются следующие 4 слоя:

· Слой представления (также известен как слой пользовательского интерфейса)

· Слой приложения (также известен как слой сервиса)

· Слой бизнес-логики (также известен как уровень предметной области)

· Слой доступа к данным (также известен как уровень хранения данных)

Использование

· Общие десктопные приложения.

2. Клиент-серверный шаблон

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

Использование

· Онлайн приложения (электронная почта, совместный доступ к документам, банковские услуги).

3. Ведущий-ведомый

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

Использование

· В репликации баз данных. Там главная БД считается авторитетным источником, а подчиненные базы с ней синхронизируются.

· Периферийные устройства, подключенные к шине в компьютере (ведущие и ведомые устройства).

4. Каналы и фильтры

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

Использование

· Компиляторы. Последовательные фильтры выполняют лексический, синтаксический, семантический анализ и создание кода.

· Рабочие процессы в биоинформатике.

5. Шаблон посредника

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

Сервер размещает свои возможности (службы и характеристики) у посредника (брокера). Клиент запрашивает услугу у брокера. Затем брокер перенаправляет клиента к подходящей службе из своего реестра.

Использование

6. Одноранговый шаблон

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

Использование

· Проприетарные мультимедийные приложения (как тот же Spotify).

7. Шина событий

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

Использование

· Разработки на Android

8. Модель-представление-контроллер

Этот шаблон также известен как MVC-шаблон. Он разделяет интерактивные прикладные программы на 3 части:

1. модель — содержит ключевые данные и функционал;

2. представление — показывает информацию пользователю (можно задавать более одного представления);

3. контроллер — занимается обработкой данных от пользователя.

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

Использование

· Архитектура WWW-приложений, написанных на основных языках программирования.

9. Доска

Такой шаблон подходит для проблем, для которых отсутствуют четкие детерминированные решения. Шаблон «Доска» состоит из 3 главных компонентов:

· доска — это структурированная глобальная память, содержащая объекты из пространства возможных решений;

· источник знания — специализированные модули со своим собственным представлением;

· компоненты управления — выбирает, настраивает и исполняет модули.

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

Использование

· идентификация и отслеживание транспортных средств;

· определение структур белка;

· интерпретация сигналов Sonar.

10. Интерпретатор

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

Использование

· языки запросов к базе данных (SQL);

· языки, которые используются для описания протоколов передачи данных.

Сравнение архитектурных шаблонов

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

Многоуровневый шаблон

Одним низким слоем могут пользоваться разные слои более высокого ранга.
Слои упрощают стандартизацию, т.к. мы четко определяем уровни.
Изменения вносятся внутри какого-то одного слоя, при этом остальные слои остаются неизменными.

Не универсален.
В ряде ситуаций возможен пропуск некоторых слоев.

Клиент-серверный шаблон

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

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

Шаблон «Ведущий-ведомый»

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

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

Шаблон «Каналы и фильтры»

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

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

Шаблон «Посредник»

Возможно динамическое изменение, добавление, удаление и перемещение объектов. Этот шаблон делает процесс распределения прозрачным для разработчика.

Необходима стандартизация описаний служб.

Одноранговый шаблон

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

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

Шаблон «Шина событий»

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

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

Шаблон «Модель-представление-контроллер»

Упрощает создание различных представлений одной и той же модели; их можно включить или отключить на этапе выполнения.

Возрастает сложность алгоритма. Может привести ко многим ненужным корректировкам действий пользователей.

Шаблон «Доска»

Легкое добавление новых приложений.
Можно без труда расширять структуры пространства данных.

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

Шаблон «Интерпретатор»

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

Проблемы с производительностью, т.к. интерпретированный язык медленнее скомпилированного.

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

О модели взаимодействия клиент-сервер простыми словами. Архитектура «клиент-сервер» с примерами

28.07.2016
Сервера и протоколы
Комментариев нет

Модель взаимодействия клиент-сервер. Архитектура «клиент-сервер».

Концепция взаимодействия клиент-сервер

Читать еще: C архитектура приложений

Простая схема взаимодействия клиент-сервер

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

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

Двухуровневая модель взаимодействия клиент-сервер

Многоуровневая архитектура взаимодействия клиент-сервер