Что такое клиент сервер

Технология клиент-сервер: что это такое?

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

В технологии клиент-сервер есть два главных действующих лица:

• клиент — компьютерное или мобильное устройство при управлении пользователем, которое отправляет запрос или команду серверу (например, ввод поискового запроса в Google тоже относится к этому процессу);
• сервер — аппаратный или облачный сервер, который принимает запрос и выполняет его (обработка данных на сайтах, приложениях и в сервисах происходит через веб-узлы).

Отсюда и возникло название “клиент-сервер”. Его стали применять еще в начале развития эпохи интернета. Но в современных реалиях стоит добавить и третий элемент — сеть, через которую осуществляется передача данных.

Если бы не существовало архитектуры “клиент-сервер”, то работать в интернете было бы очень сложно. Дело в том, что все запросы конкретный сервер обрабатывает не одновременно, а в приоритетной очередности. Как и любой компьютерный процессор. Например, через мессенджер Telegram одновременно отправляют сообщение 10 000 пользователей. Сервера в data-центре компании Telegram получают этот запрос (от клиентов) и выполняют его в порядке очередности с молниеносной скоростью (основную функцию обработки выполняют процессоры серверного оборудования). Но если одновременно будет отправляться не 10 000, а, например, 100 000 или более сообщений, то может возникнуть задержка в обработке из-за нехватки вычислительных мощностей. Чье-то сообщение в очереди отправляется быстрее, а чье-то на доли миллисекунд или секунд дольше. Зависит от приоритетности.

При отсутствии сетевой архитектуры “клиент-сервер” все запросы выполнялись бы на серверном оборудовании одновременно и в хаотичном порядке. Это делало бы обработку данных во много раз дольше, не считая и других недостатков.

Помимо этого, архитектура “клиент-сервер” означает ещё и способ доставки пользователю данных какого-либо приложения. Благодаря данной архитектуре появился способ обеспечения безопасности при работе с приложениями. Есть возможность отследить сессии клиента, и на сессионном уровне (пятый уровень эталонной модели OSI) обеспечить контроль над клиентами. Это повышает и безопасность и устойчивость, что очень важно в высоко нагруженных IT-системах.

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

Архитектура в этой технологии делится на два вида:

1. Двухзвенная — в системе задействуется всего два устройства: клиент (любое программное обеспечение, браузер) и сервер. Пользователем отправляется запрос, который обрабатывается, и на него затем приходит ответ в виде какого-либо действия или оповещения.
2. Многоуровневая — в системе задействуется несколько устройств, как в современной архитектуре СУБД. Задачи от клиента перераспределяются между несколькими устройствами.

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

Интернет-сеть LAN построена по такому же принципу (Client/Server network). В ней сетевые устройства управляются одним или несколькими серверами. При этом клиенты могут обращаться с запросом к сетевым ресурсам только через серверы (например, через дата-центры провайдеров). Протокол HTTP (HyperText Transfer Protocol — протокол передачи гипертекста) и HTTPS тоже работают на технологии “клиент-сервер”.

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

Клиент-серверная архитектура — Введение в интернет

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

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

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

Клиент-серверная архитектура и ее компоненты

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

В клиент-серверной архитектуре используется три компонента:

• Клиент — программа, которую мы используем в интернете. Чаще всего это браузер, но может быть и другая отдельная программа
• Сервер — компьютер, на котором хранится сайт или приложение. Когда мы заходим на сайт магазина, мы обращаемся к серверу, на котором находится сайт
• База данных — программа, в которой хранятся все данные приложения. Для магазина это будет база клиентов, товаров и заказов

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

Особенности клиента

Клиент — это всегда программа. Ее назначение — дать пользователю удобный способ взаимодействия с сервером.

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

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

Особенности сервера

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

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

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

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

Особенности базы данных

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

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

При такой схеме работы архитектура называется трехуровневой, так как состоит из трех компонентов.

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

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

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

Рассмотрим плюсы и минусы клиент-серверной архитектуры и начнем с хороших сторон.

Плюсы

• Отсутствие дублирования. Весь сайт или приложение хранится на одном компьютере-сервере. Это позволяет использовать его с разных устройств, будь то компьютер или мобильный телефон
• Минимальные требования к пользователю. От него требуется только наличие программы-клиента. Для работы с сайтами достаточно иметь браузер
• Безопасность. Данные хранятся в базе данных и пользователи не могут их просматривать. Это обеспечивает безопасность для персональных данных
• Производительность. Серверы обычно производительнее, чем компьютеры пользователей. Это позволяет обрабатывать тысячи запросов от сотни разных пользователей одновременно. Например, этот урок на Хекслете может читать одновременно сотня человек и вы этого не заметите

Минусы

• Перегрузка сервера. Популярные порталы могут получать большое количество запросов одновременно. Например, при десятке миллионов запросов в секунду сервер может не выдержать и отключиться. Этим пользуются хакеры при использовании DDoS-атаки. Подробнее виды атак рассмотрим в следующих уроках
• Выход из строя сервера или базы данных. Это сделает сервис недоступным для всех пользователей
• Высокая стоимость оборудования. Сервер похож на простой компьютер, но его комплектующие должны быть рассчитаны на бесперебойную работу 24/7. Такая надежность обеспечивается компонентами со специальными функциями, из-за чего стоимость оборудования повышается
• Затраты на поддержку. Обычно недостаточно просто получить сервер и забыть про его существование. Должен быть специалист, который будет обслуживать сервер и быстро реагировать в случае поломок

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

Кластеры серверов и балансировщики

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

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

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

Чтобы определить, на какой сервер послать запрос, используется балансировщик — сервис, который пропускает все запросы через себя и следит, чтобы серверы не перегружались:

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

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

Выводы

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

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

Остались вопросы? Задайте их в разделе «Обсуждение»

Вам ответят команда поддержки Хекслета или другие студенты

Об обучении на Хекслете

• Статья «Как учиться и справляться с негативными мыслями»
• Статья «Ловушки обучения»
• Статья «Сложные простые задачи по программированию»
• Урок «Как эффективно учиться на Хекслете»
• Вебинар « Как самостоятельно учиться »

Открыть доступ

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

• 130 курсов, 2000+ часов теории
• 1000 практических заданий в браузере
• 360 000 студентов

Наши выпускники работают в компаниях:

Клиент-серверная архитектура в картинках

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

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

Об этом я и расскажу в статье. Объясню на пальцах, с примерами и забавными картинками =) Если вы больше любите видео-формат, можно посмотреть мой ролик на youtube на ту же тему.

Что это и как работает

Вот есть у нас некий Вася, который решил купить машину. Такую, как в рекламе — быструю, мощную, красивую! Только стоит она как хвост самолета, у Васи таких денег нет.

Конечно, Вася может подкопить несколько лет, а потом уже покупать машину. Но ведь хочется здесь и сейчас! Да и средство передвижения нужно…

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

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

Вася подумал, прикинул и сказал:

— Да, хочу именно так! 100 рублей с зарплаты платить в банк могу, а откладывать — нет. Потрачу.

Поэтому Вася идет в банк и говорит:

— Я Василий Иванов, хочу автокредит на 1000р.

Операционистка Катя должна проверить его кредитную историю. Вдруг ему нельзя давать кредит, у него плохая история? Может, он уже набрал 10 кредитов и ни один не выплачивает? Или вдруг он вообще террорист?! Нужно проверить, операционисты не знают черные списки наизусть.

У Кати есть специальная программа для проверки данных по клиентам. Эта программа может быть как web, так и desktop:

• Web — в браузере открыта, как google или facebook
• Desktop — на компьютере, как ворд или калькулятор

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

Катя ввела данные на клиенте. Но когда она нажала «проверить», клиент отправил запрос на сервер:

— Дай мне информацию по Васе Иванову!

Сервер отправил запрос в БД, базу данных:

— Select * from clients where fio = ‘Василий Иванов’. (Дай мне всю информацию по ФИО ‘Василий Иванов’)

— Вот тебе все, что нашла.

Сервер вернул эту информацию клиенту:

А клиент уже отрисовал ее для Кати:

— Ага, кредитная история хорошая.

И делает предложение Васе:

— Пожалуйста, если хотите взять кредит, то мы готовы выделить 1000р на 12 лет под 80% годовых. Устроит?

— Да, меня всё устраивает, давайте скорее деньги, и я побежал за машиной!
Все счастливы, все довольны.

Катя даже не догадывается, какой путь проделали данные в программе, когда она вбила туда ФИО своего клиента. Но мы с вами должны узнать, что же это за путь такой? И к чему все эти сложности? Почему именно такая структура? Почему есть клиент, почему есть сервер?

Зачем нужен клиент

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

Зачем нужен сервер

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

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

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

Нет дублирования кода

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

Не надо дублировать код, ведь вся основная логика вынесена на более мощный сервер.

Так безопаснее

На сервере и в базе хранится информация, недоступная простому операционисту. Это:

• Персональные данные клиентов
• Сведения о его финансах
• Черные списки банка
• .

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

Зачем нужна база

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

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

БД (база данных) — отдельный программный продукт, который позволяет:

• быстро делать выборки информации;
• сохранять информацию даже при рестарте системы.

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

См также:
Что такое База Данных (БД)

Плюсы архитектуры

Резюмируем плюсы архитектуры:

1. Мощный сервер дешевле 100+ мощных клиентских машин — если мы хотим, чтобы приложение не тормозило, нужна хорошая машина. Она у вас будет одна. Или несколько, если нагрузка большая, но явно меньше, чем количество клиентов.
2. Нет дублирования кода — основной код хранится на сервере, клиент отвечает только за «нарисовать красивенько» и простенькие проверки на полях «тут число, тут строка не длиннее 100 символов».
3. Персональные данные в безопасности — простой пользователь не видит лишнего. Он не знает ваше ключевое слово, паспортные данные и количество денег на счете.

Минусы архитектуры

Упало одно звено — все отдыхают

Если упал сервер или отвалилась база, то есть испортилось 1 звено — всё, все в ступоре, все отдыхают. Сотни, тысячи, да хоть миллионы клиентов если есть — никто не может работать. Все операционистки грустно смотрят на окно «Простите, что-то пошло не так» и разводят руками перед клиентом.

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

Как в таком случае клиент понимает, куда ему отправлять запрос?

Перед серверами ставят балансировщик, и клиент шлет запрос туда. Сколько бы серверов не поставили в кластер, клиенту это не интересно. У него есть один URL — адрес балансировщика.

И вот с клиента поступает запрос:

— Дай мне всю информацию по Васе Иванову.

— Ребята, новый запрос! Кто меньше загружен?

— У меня 5 запросов в очереди стоит.

Балансировщик отправляет запрос второму серверу.

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

Facebook, amazon, google — туда заходят миллионы пользователей. Один сервер с ними не справится. Поэтому ставят кластер, а балансировщик делит между ними нагрузку. И в таком случае в кластере может быть не 2 сервера, а 10, 15, сколько нужно, столько и ставим.

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

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

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

Но если с первым сервером что-то случится и он помрет, балансировщик перенаправит нагрузку на второй сервер:

В это время у администраторов будет время разобраться с проблемой на сервере 1.

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

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

1. Перенаправляем всю нагрузку на сервер 2
2. Останавливаем сервер 1
3. Обновляем сервер 1
4. Запускаем его и направляем на него всю нагрузку
5. Останавливаем сервер 2
6. Обновляем его
7. Запускаем
8. Снова делим нагрузку (если это горячий резерв)

Таким образом, схемы резервирования помогают нам устранить проблему «упало 1 звено — все отдыхают». Клиент никогда не узнает, что один или несколько серверов в кластере сдохли, у него всё как работало, так и работает.

Высокая стоимость оборудования

Сервера стоят дорого. Туда нельзя поставить обычный SSD как для домашнего компьютера. Почему? Потому что к железу для серверов совсем другие требования по надежности + есть поддержка специфичных функций:

— у HDD это специальная микропрограмма контроллера, которая оптимизирована для работы диска в RAID, дома это не нужно.

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

SSD — быстро работающий диск, HDD — обычный. RAID — когда мы N дисков вместе соединили, а DDR кэш — это оперативная память

Плюс у серверных решений гарантия обычно гораздо дольше: 5 лет, а не год.

По цене отличаются в 2 раза. Например, SSD:

• для дома гигабайт стоит 16,53р
• для сервера энтерпрайз гиг стоит 32 рубля

Вроде не сильно отличается, да? Но смысл в том, что для дома 1 тб хватает за глаза — и фоточки все влезут, и кино, и куча приложений… А для базы данных иногда и 10 тб будет мало. А если делать кластер, то умножаем стоимость на 2, если не больше. Поэтому и разница в цене кажется огромная, но при пересчете на гигабайт небольшая выходит.

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

Нужно нанять сисадмина ツ

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

Что тестировать

Чтобы понимать, что тестировать, надо понимать, с чем имеет дело человек.

Пользователь работает с клиентом. Это может быть web или desktop приложение, не суть. Операционистке Кате дали рабочее место, показали какую программу запускать и как с ней работать. Она знать не знает о наличии серверов и БД, она работает только с клиентом.

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

Сервер работает, на клиенте ошибка. И плевать на сотни «зеленых» автотестов. У пользователя все равно ошибка. И наша задача — посмотреть с его точки зрения.

Однако, если у вас есть доступ к серверу приложения и его базе данных — стоит проверять и их тоже! Так мы можем увидеть «будущий баг». Например:

• Сохранили карточку товара — система ее отрисовывает и говорит, что все хорошо. На клиенте все отлично!
• Проверили по базе — а там часть полей осталась пустая, разработчик неправильно указал название поля в БД. И информация потерялась.

— Ну, наверное, их и не заполняли.

А их заполняли! Просто сохранение криво сработало. Поэтому, если у нас только черный ящик, то нужно проверять, «а реально ли сохранились данные?». Сохранили? Откройте карточку в новом окне или вызовете информацию через API-метод.

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

Помимо простых пользователей бывают злые люди, которые пытаются встрять в наше приложение и своровать деньги / данные. Они используют не клиент или сервер — туда у них доступа нет. Они пытаются перехватить данные в пути от клиента к серверу, или от сервера к БД.

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

Тестировщик изучает уязвимости и потом рассказывает команде:

— Ребята, вот я проверил, у нас есть такие-то и такие-то потенциальные дыры. Давайте подумаем, надо нам их как-то закрывать или нет.

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

Но какие-то базовые проверки типа sql-иньекций или XSS-атак стоит изучить и проверить на своем приложении. Хотя бы чтобы понять их критичность. Ведь если атака сломает клиент — ну и пусть, сам себе буратино. А если атака положит сервер, это уже не очень хорошо. И надо хотя бы знать, от чего это бывает.

Итого

Клиент — та программа, с которой работает пользователь. Он знать не знает, это у него на компьютере программа целиком, или где-то за ней прячутся сервер с базой, а то и целый RAID. Он работает в браузере или с desktop-приложением. И всё, что ему нужно знать — это «куда тут тыкать».

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

Сервер — компьютер, на котором хранится само приложение. Весь код, вся логика, все дополнительные материалы и справочники. Например, справочник адресов ФИАС или справочник юр лиц ЕГРЮЛ — они тоже занимают место, как сами по себе, так и в памяти приложения.

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

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

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

Сколько места нужно под базу, зависит от количества данных. Есть огромные базы в банках, где и 1тб будет мало. А есть совсем небольшие, которые вы можете установить на своей машине. Например, XAMPP можно поставить. И врядли вы напихаете туда столько данных, что у вас не останется под них место.

Отдельной базы может не быть, тогда структура станет двузвенной: клиент-сервер. И все!

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

PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале

• тестирование
• клиент-сервер

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

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

В архитектуре «Клиент-Сервер» несколько компьютеров-клиентов (удалённые системы) посылают запросы и получают услуги от централизованной служебной машины – сервера (server – англ. «официант, обслуга»), которая также может называться хост-системой (host system, от host – англ. «хозяин», обычно гостиницы).

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

Рис. 1. Архитектура «Клиент-Сервер».

Типы клиент-серверной архитектуры

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

Постараемся внести ясность в этот вопрос.

Одноуровневая архитектура (1-Tier)

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

Рис. 2. Одноуровневая архитектура «клиент-сервер» (1-Tier).

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

Двухуровневая архитектура (2-Tier)

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

Рис. 3. Двухуровневая архитектура «клиент-сервер» (2-Tier).

Такая архитектура представляется наиболее логичной для архитектуры «клиент-сервер». В ней, однако, можно выделить два варианта. Когда общие данные хранятся на сервере, а логика их обработки и бизнес-данные хранятся на клиентской машине, то такая архитектура носит название “fat client thin server” (толстый клиент, тонкий сервер). Когда не только данные, но и логика их обработки и бизнес-данные хранятся на сервере, то это называется “thin client fat server” (тонкий клиент, толстый сервер). Такая архитектура послужила прообразом облачных вычислений (Cloud Computing).

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

• Легко конфигурировать и модифицировать приложения;
• Пользователю обычно легко работать в такой среде;
• Хорошая производительность и масштабируемость.

Однако, у двухуровневой архитектуры есть и ограничения:

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

Трёхуровневая архитектура (3-Tier)

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

Рис. 4. Трёхуровневая архитектура «клиент-сервер» (3-Tier).

Преимущества трёхуровневой архитектуры:

• Целостность данных;
• Более высокая безопасность, по сравнению с двухуровневой архитектурой;
• Защищённость базы данных от несанкционированного проникновения.

• Более сложная структура коммуникаций между клиентов и сервером, поскольку в нём также находится middleware.

Многоуровневая архитектура (N-Tier)

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

По сути, предыдущий вариант, трёхуровневая архитектура – не более, чем частный случай многоуровневой архитектуры.

Рис. 5. Многоуровневая архитектура «клиент-сервер» (N-Tier).

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

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

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

• Асимметричность протоколов. Между клиентами и сервером существуют отношения «один ко многим». Инициатором диалога с сервером обычно является клиент.
• Инкапсуляция услуг. После получения запроса на услугу от клиента, сервер решает, как должна быть выполнена данная услуга. Модификация («апгрейд») сервера может производиться без влияния на работу клиентов, поскольку это не влияет на опубликованный интерфейс взаимодействия между ними. Иными словами, максимум, что может при этом почувствовать пользователь – незначительная задержка отклика сервера в течение небольшого времени апгрейда.
• Целостность. Программы и общие данные для сервера управляются централизованно, что снижает стоимость обслуживания и защищает целостность данных. В то же время, данные клиентов остаются персонифицированными и независимыми.
• Местная прозрачность. Сервер – это программный процесс, который может исполняться на той же машине, что и клиент, либо на другой машине, подключенной по сети. Программное обеспечение «клиент-сервер» обычно скрывает местоположение сервера от клиентов, перенаправляя запрос на услуги через сеть.
• Обмен на основе сообщений. Клиенты и сервер являются нежёстко связанными («loosely-coupled») процессами, которые обмениваются сообщениями: запросами на услуги и ответами на них.
• Модульный дизайн, способный к расширению. Модульный дизайн программной платформы «клиент-сервер» придаёт ей устойчивость к отказам, то есть, отказ в каком-то модуле не вызывает отказа всего приложения. В такой системе, один или больше серверов могут отказать без остановки всей системы в целом, до тех пор, пока услуги отказавшего сервера могут быть предоставлены с резервного сервера. Другое преимущество модульности в том, что приложение «клиент-сервер» может автоматически реагировать на повышение или понижение нагрузки на систему, путём добавления или отключения услуг или серверов.
• Независимость от платформы. Идеальное приложение «клиент-сервер» не зависит от платформ оборудования или операционной системы. Клиенты и серверы могут развёртываться на различных аппаратных платформах и разных операционных системах.
• Масштабируемость. Системы «клиент-сервер» могут масштабироваться как горизонтально (по числу серверов и клиентов), так и вертикально (по производительности и спектру услуг).
• Разделение функционала. Система «клиент-сервер» — это соотношение между процессами, работающими на одной или на разных машинах. Сервер – это процесс предоставления услуг. Клиент – это потребитель услуг.
• Общее использование ресурсов. Один сервер может предоставлять услуги множеству клиентов одновременно, и регулировать их доступ к совместно используемым ресурсам.

Практические применения архитектуры «клиент-сервер»

Архитектуры «клиент-сервер» — один из основных принципов работы сети Интернет. Любой веб-сайт, или приложение в Интернет работает на сервере, а его пользователи являются клиентами. Социальные сети (Фейсбук, ВК и пр.), сайты электронной коммерции (Amazon, Озон и др.) , мобильные приложения (Instagram и т.д.), устройства Интернета вещей (умные колонки или смарт-часы) работают на основе клиент-серверной архитектуры.

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

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

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

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

К преимуществам архитектуры «клиент-сервер» можно отнести:

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

К недостаткам архитектуры «клиент-сервер» следует отнести:

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

Заключение

В настоящее время можно встретить термин Serverless Architecture, т.н. «бессерверная архитектура». Однако, по сути, она представляет собой процесс получения функций сервера в виде облачной услуги. То есть, серверы в облаке тоже есть, но для конечного пользователя они не видны, и он получает их сервисы в виде абстрактной «функции как услуги» FaaS (Function as a Service).

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

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

Вам может быть интересно: