что такое клиент в интернете
IT-блог о веб-технологиях, серверах, протоколах, базах данных, СУБД, SQL, компьютерных сетях, языках программирования и создание сайтов.
Что такое клиент? Клиентский компьютер и клиентское приложение
Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем рубрику Сервера и протоколы. Также я решил, что на моем блоге просто необходима рубрика Вопрос-ответ, в которой будет два раздела: «Что такое?» и «Как сделать?». Большинство публикаций на моем блоге довольно большие и подробные, но в этих разделах я буду стараться ответить на один простой вопрос коротко, понятно и с примерами. Грубо говоря, каждая запись — это ответ на вопрос, который задает новичок в сфере web.
Что такое клиент? Клиентский компьютер и клиентское приложение
В этой записи мы разберемся со значением термина клиент и поговорим о том, что такое клиентский компьютер и клиентское приложение. Надеюсь, что данная рубрика окажется действительно полезной и нужной для новичков.
Общее определение термина клиент
Мой блог имеет достаточно узкую тематику, но давайте сперва разберемся с термином клиент и посмотрим, что это слово означает. Как не банально, но клиент – это заказчик той или иной услуги или покупатель. Неважно где и что вы покупаете, например, вы покупаете доменное имя и становитесь клиентом регистратора или вы покупаете хостинг, тогда вы становитесь клиентом хостинг-провайдера. Покупая хлеб в магазине, вы становитесь клиентом магазина.
Вообще, термин клиент пришел к нам из Древнего Рима, в исконном значении слова клиент – это свободный гражданин Римской Империи, который находится в зависимости от патрона (знатного гражданина), но в то же время клиент пользуется покровительством и защитой патрона.
Если говорить про информатику, то клиент – это программное средство или физическое устройство, которое посылает запросы серверу (поставщику услуг)
Клиентский компьютер
В принципе, для описания термина клиентский компьютер нам подойдут оба определения, представленных выше. Если говорить про сеть Интернет, то ваше устройство, с помощью которого вы зашли на мой сайт – это клиентский компьютер, вы искали информацию и нашли ее на моем блоге, соответственно, вы искали того, кто удовлетворит вашу потребность в информации.
Если говорить про локальную сеть или, как частный случай, корпоративную сеть, то клиентский компьютер – это маломощный компьютер, который пользуется вычислительными мощностями сервера при необходимости выполнения той или иной операции. В общем, клиентский компьютер – это машина, которая пользуется услугами.
Клиентская программа/приложение
С клиентскими программами все несколько сложнее, чем с клиентскими компьютерами. Типичным примером клиентского приложения является браузер, с помощью которого вы заходите на сайты. Во-первых, вам нужно понимать архитектуру взаимодействия клиент-сервер. Во-вторых, вам нужно знать, что и клиентские программы, и серверные могут взаимодействовать на одном и том же компьютере.
В общем случае клиентское приложение – это приложение, отправляющее запросы серверу с целью получения той или иной информации. Термин клиент в области IT чаще всего применяется именно к приложениям. Если говорить о сфере веб, то мы уже упоминали о браузерах, которые отправляют серверу специальные HTTP сообщения, которые получили название HTTP запрос, серверы в свою очередь отправляют клиенту сообщения, которые называются HTTP ответы.
Запросы клиента содержат специальные HTTP методы, которые позволяют указать серверу на то, как он должен обрабатывать запрос (некоторые запросы позволяют получить информацию с сервера, некоторые удалить информацию, а некоторые записать, всё зависит от метода). HTTP сервер, отправляя ответ, сообщает клиенту о том, как он понял запрос при помощи специальных кодов состояния.
Если говорить про MySQL сервер, то у него есть клиент, который позволяет выполнять SQL запросы к базе данных из командой строки (это специальное приложение), а также есть клиент с графическим интерфейсом, который позволяет управлять базами данных при помощи мышки. В качестве сервера, к которому делают запросы браузеры, можно привести пример сервера Apache. Если же вас интересуют готовые сборки серверов для веб-разработки, то можно порекомендовать: локальный веб-сервер AMPPS и российскую сборку Denwer.
Подведем итоги: клиентское приложение – это программа, которая позволяет человеку взаимодействовать с сервером и получать требуемые услуги.
Тонкий клиент – что это и с чем его едят (на примере WTWare)
Тонкий клиент (англ. thin client) в компьютерных технологиях — бездисковый компьютер-клиент в сетях с клиент-серверной или терминальной архитектурой, который переносит все или большую часть задач по обработке информации на сервер (Wikipedia ).
Если проще, то тонкий клиент – это недокомьютер, который загружает легкую операционную систему (обычно используется Linux, в обзоре возьмем это за априори) и соединяется с терминальным сервером.
Обычно тонкие клиенты создаются для экономии на железе и ПО, в редких случаях по иным соображениям.
В этой статье я постараюсь сделать краткий обзор WTWare, являющегося Linux дистрибьютивом, разработанным специально для создания тонких клиентов.
Сначала о тонком клиенте.
Тонкий клиент представляет собой системный блок, у которого обычно нет жесткого диска, и присутствует только минимальный набор железа, нужный для запуска операционной системы тонного клиента (далее просто тонкого клиента). К системному блоку подключены питание, мышь, клавиатура, монитор, сетевой кабель. Кроме стандартного набора к тонкому клиенту могут быть подключены другие устройства, при условии, что он сможет их распознать и передать терминальному серверу.
Схема сети с тонкими клиентами выглядит примерно так:
WTWare — дистрибутив GNU/Linux, разработанный специально для создания тонких клиентов. За основу взят популярный клиент под названием Thinstation. Основное различие – ориентированность на русских пользователей (в самом Thinstation есть проблемы с кириллицей), плюс всякие мелкие фиксы.
Я не буду рассказывать про настройку DHCP и TFTP серверов, там все вполне стандартно. Напомню только, что в DHCP сервере нужно указать адрес TFTP сервера, а в TFTP сервере путь до файла загрузки и имя этого самого файла.
Так же я не буду углубляться в тонкую настройку WTWare, т.к. информация на официальном сайте WTWare вполне доступная, ее много и вся она на русском языке. Укажу лишь на основные аспекты.
Итак. В первую очередь качаем образ Thinstation с сайта WTWare. Распаковываем.
Загрузочный файл называется pxelinux.0 при загрузке по протоколу PXE (если BootROM встроен в вашу сетевую или материнскую плату) или wtshell.nbi для загрузчика Etherboot (при использовании эмулятора BootROM).
К слову говоря, Etherboot — оpensource проект, который выпускает прошивки практически для всех существующих сетевых карт. Прошивка Etherboot может быть записана в микросхему BootROM или flash-память сетевой карты, может быть запущена с дискеты или жесткого диска как загрузочный сектор или как программа из DOS.
Далее если вы загружаетесь через LAN и у вас правильно настроены DHCP и TFTP сервера – все должно заработать «как есть». Единственное – не будет найден терминальный сервер, ведь вы еще не конфигурировали ваши тонкие клиенты.
Если вы загружаетесь иным способом, то стоит прочитать тут, выбрав интересующий вас способ загрузки.
Опять таки я не буду углубляться в дебри конфигурационных файлов, потому как там сотни параметров. Тут можно увидеть их полный список. Я расскажу лишь об основных.
Конфигурационные переменные индивидуальных файлов:
user = username // имя пользователя
password = user_password // пароль пользователя
domain = enterprise_domain // домен предприятия
Если в индивидуальный файл записать переменную, которая присутствует в общем файле — она получит более высокий приоритет.
Так же в индивидуальные файлы прописываются дополнительно подключенные устройства, такие как принтеры, сканера и т.п.
И в конце хотел упомянуть об еще одной интересной возможности – подключение локальных ресурсов (Floppy, DVD, Flash, HDD, Sound). В конфиге выглядит примерно так:
floppy = on
cdrom = on
usb1 = on
sound = on
Диск будет доступен в сессии текущего пользователя из Проводника Windows по адресу: \\tsclient\
Стоит заметить, что сама система бесплатна, но можно приобрести лицензию с очень интересной целью – что бы убрать логотип WTWare из загрузочной заставки. Как я понимаю, это сделано для предприятий, массово внедряющих данный продукт под эгидой аутсорсинга.
Оборудование для создания тонких клиентов:
На сайте WTWare так же можно приобрести оборудование для создания тонких клиентов (дабы не собирать их из хлама). Надо сказать, что оно (оборудование) отвечает всем требованиям гламура. Несколько скринов:
Ну, вот, пожалуй, и все. При правильной настройке терминального, DHCP и TFTP сервера все должно заработать слету. В интернете очень много русскоязычной литературы, поэтому проблем с настройкой быть не должно. Да и вообще в плане документации система мне очень понравилась, на сайте производителя есть почти все.
Клиент
Почти в каждом бизнесе корпорации используют клиентов, имея свою корпоративную сеть, имея клиентский компьютер для каждого из своих сотрудников, которым необходим доступ к информации с серверов, причем каждый из клиентских компьютеров подключен к главному серверу корпорации. Этот сервер будет содержать файлы и информацию, которые имеют первостепенное значение для эффективности рабочего места, обеспечивая доступ к Интернету и внутрисерверному контенту. [2]
Когда дело доходит до обработки, любая работа, выполняемая на сервере, называется «серверная», а любая информация и данные, генерируемые локально на стороне клиента, называется «клиентская» работа. [3]
Cодержание
Функциональность
Классификация
Клиенты делятся на три категории: [4]
Тонкий клиент
Это клиентская программа с минимальной функцией, которая использует только ресурсы, предоставляемые хост-компьютером или сервером. Его работа довольно проста: отобразить результаты, которые генерирует сервер. Все, что ему нужно, это сервер для выполнения тяжелой подъема (который является обработкой). Тонких клиентов можно рассматривать как услугу по отношению к клиентам через пользовательский интерфейс, который обслуживается для них. Тонкие клиенты становятся лучшим вариантом, когда сервер имеет больше вычислительной мощности, чем любой из его получателей. Тонкие клиентские вычисления являются одним из наиболее естественных способов поддержания вычислительных услуг без необходимости жертвовать вычислительной мощностью компьютера получателя.
Толстый или толстый клиент
Этот клиент прямо противоположен тому, что представляет собой тонкий клиент, и относится к большей части обрабатывающей деятельности, которая не зависит от центральных серверов мэйнфреймов, обрабатывающих данные и информацию. Однако ему может потребоваться источник информации (по крайней мере, один сервер) для загрузки и обновления данных или даже администрирования самой программы. В большинстве случаев, антивирусные программы относятся к этой категории, так как могут работать независимо друг от друга без необходимости постоянного подключения к серверу, если только нет запланированных обновлений и специальных загрузок. Загрузки и выгрузки должны осуществляться для того, чтобы программа знала о некоторых вирусах, а также передавала информацию на сервер-источник. Толстые клиенты также реализуются на рабочих местах, где хост-сервер или основной сервер имеет большую скорость сети, ограниченную вычислительную мощность и ограниченный объем памяти. Это происходит потому, что толстые клиенты могут работать почти независимо друг от друга.
Гибридный клиент
Этот клиент содержит некоторые черты, которые встречаются как в тонких, так и в толстых клиентах. Гибридный клиент может работать независимо, но все равно может полагаться на исходный сервер для важных данных или хранения таких данных.
Клиентская сторона по сравнению с серверной работой
Когда клиент генерирует запрос на определенную веб-страницу, этот запрос сначала должен быть обработан через веб-сервер. Если запрос является скриптом на стороне сервера (в данном случае Perl или PHP) до того, как эта информация будет возвращена клиенту, скрипт выполняется на сервере, и результаты скрипта возвращаются клиенту. [5]
После получения клиентом возвращаемой информации с сервера, который он содержит, клиентский сценарий (например, JavaScript) в браузере компьютера пользователя будет затем выполнять сценарий перед его отображением на веб-странице.
Языки клиентской стороны имеют следующие особенности: [5:1]
Кодирование на стороне сервера и языки имеют следующие особенности: [3:1]
В сущности, большинство веб-сайтов используют языки как клиентской, так и серверной части. Хотя обе эти стороны могут выполнять основные функции с любой проблемой, некоторые функции могут быть выполнены только языками клиентской стороны и несколькими другими, которые также могут быть сделаны языками серверной стороны.
Проще говоря, внешний скриптинг дает преимущество на всем, что требует взаимодействия с пользователем, примером чего является видеоигра. Внутренний сценарий полезен, когда речь идет о сложных и динамических данных, которые необходимо загрузить, например, уведомление пользователя о том, что он уже вошел в систему устройства или даже в другое устройство.
Различия между веб-сервером и веб-клиентом
С точки зрения того, как они функционируют, и веб-сервер, и веб-клиент (получатель) имеют различные режимы работы. Поскольку мы обсудили различия между работой на стороне сервера и работой на стороне клиента, нам нужно знать, как эти два компонента работают рука об руку, чтобы доставить контент пользователю. [4:1]
Веб-сервер
По сути, это система, которая обрабатывает запросы получателя, а также предоставляет различные формы содержимого веб-страниц через протокол HyperText Transfer Protocol (HTTP) и отправляет файлы по протоколу FTP (File Transfer Protocol). Как только пользователь вводит URL-адрес в адресной строке браузера, веб-сервер будет посылать запрос в то место, где сохраняется домен. Затем запрашиваемая информация будет доступна и предоставлена хост-сервером. Обработка и предоставление веб-страницы получателю (клиенту) является основной функцией веб-страницы.
Веб-клиент
Веб-клиент можно сравнить с программным обеспечением или веб-браузером, который либо установлен на компьютере, либо уже встроен в систему компьютера (например, IE). Эти браузеры затем используются для взаимодействия с веб-сервером по запросу пользователя. В этом случае, это потребительское программное обеспечение (созданное и разработанное компанией для адаптации к потребностям пользователей), которое извлекает данные с серверов. Клиент и сервер являются двумя важными компонентами соединения, в то время как две разные машины также управляют этими компонентами. Веб-клиент в основном запрашивает информацию, в то время как веб-сервер, по сути, представляет собой компьютер/процессор, специально предназначенный для приема запросов с удаленных компьютеров и отправки этой информации запрашивающей стороне. Основной функцией веб-клиентов должно быть «окно», в котором пользователи будут просматривать информацию, обрабатываемую сервером. После этого веб-хост разрешит соединения с сервером для просмотра сохраненной информации.
Когда речь заходит о разработке сайта, программисты, как и веб-разработчики, должны знать, откуда поступает устойчивый поток информации. Возможность различать работу на стороне сервера и на стороне клиента повысит эффективность веб-страницы, которую обслуживает пользователь. [1:2] Если определенная страница сталкивается с проблемами при потоковой передаче контента и медиа-платформ, которые присутствуют на веб-странице, то пользователю и веб-разработчику будет легче устранять эти проблемы, поскольку они уже будут иметь представление о преимуществах и недостатках работы и сценариев на стороне сервера и клиента.
Кроме того, способность различать различия между различными типами клиентов даст разработчикам преимущество в том, как они смогут приспособить своего клиента к их аудитории и демографическим особенностям, оптимизируя возможности клиента в соответствии с потребностями пользователей.
Клиент-серверная архитектура в картинках
Знакомая картинка? А вы ведь постоянно сталкиваетесь с этой архитектурой — когда покупаете билет в кино онлайн, бронируете путевку на море или записываетесь к врачу.
На клиент-серверной архитектуре построены все сайты и интернет-сервисы. Также ее используют десктоп-программы, которые передают данные по интернету. Поэтому ИТ-специалисту нужно понимать, что это такое и как работает.
Об этом я и расскажу в статье. Объясню на пальцах, с примерами и забавными картинками =) Если вы больше любите видео-формат, можно посмотреть мой ролик на youtube на ту же тему.
Содержание
Что это и как работает
Вот есть у нас некий Вася, который решил купить машину. Такую, как в рекламе — быструю, мощную, красивую! Только стоит она как хвост самолета, у Васи таких денег нет.
Конечно, Вася может подкопить несколько лет, а потом уже покупать машину. Но ведь хочется здесь и сейчас! Да и средство передвижения нужно…
А еще Вася не умеет копить — получил зарплату, закупился основным, оплатил жилье, всё! Остальное можно потратить. Для таких людей есть банки, куда можно прийти и взять деньги в кредит.
Конечно, потом вы будете переплачивать, возвращая их назад. Проценты-то конские. Но зато уже сейчас можете позволить купить себе что-то дорогое.
Вася подумал, прикинул и сказал:
— Да, хочу именно так! 100 рублей с зарплаты платить в банк могу, а откладывать — нет. Потрачу.
Поэтому Вася идет в банк и говорит:
— Я Василий Иванов, хочу автокредит на 1000р.
У Кати есть специальная программа для проверки данных по клиентам. Эта программа может быть как web, так и desktop:
Катя вбивает в программу «Василий Иванов» и получает информацию по клиенту — есть ли он в черных списках? Была ли кредитная история раньше? И так далее. Но что происходит в потрохах приложения?
Катя ввела данные на клиенте. Но когда она нажала «проверить», клиент отправил запрос на сервер:
— Дай мне информацию по Васе Иванову!
Сервер отправил запрос в БД, базу данных:
— Select * from clients where fio = ‘Василий Иванов’. (Дай мне всю информацию по ФИО ‘Василий Иванов’)
— Вот тебе все, что нашла.
Сервер вернул эту информацию клиенту:
А клиент уже отрисовал ее для Кати:
— Ага, кредитная история хорошая.
И делает предложение Васе:
— Пожалуйста, если хотите взять кредит, то мы готовы выделить 1000р на 12 лет под 80% годовых. Устроит?
— Да, меня всё устраивает, давайте скорее деньги, и я побежал за машиной!
Все счастливы, все довольны.
Катя даже не догадывается, какой путь проделали данные в программе, когда она вбила туда ФИО своего клиента. Но мы с вами должны узнать, что же это за путь такой? И к чему все эти сложности? Почему именно такая структура? Почему есть клиент, почему есть сервер?
Зачем нужен клиент
Тут все просто — с клиентом работает пользователь. Он нужен, чтобы превратить байтики программного кода в красивую и понятную картинку. Пользователь — не программист, он не понимает язык программирования или sql. Он понимает формочки и кнопочки. Их в клиенте и рисуем.
Зачем нужен сервер
Клиентов может быть много. В примере с банком у нас может быть по 10 отделений в 10 городах России, а в каждом отделении по 10 операционисток. Тысяча Катек, и у каждой отдельный компьютер.
А мы ведь хотим, чтобы приложение работало быстро. Чтобы оно не тупило и не зависало, нервируя операциониста и заставляя клиента ждать. Значит, машина нужна мощная. Но если делать мощным каждый компьютер операциониста, денег придется вложить очень много!
Поэтому мы выносим всю основную логику на сервер. И вот его уже делаем мощным! А клиентские машины могут быть дешевыми, потому что на них остается лишь логика в стиле «запросить информацию и красиво отрисовать».
Нет дублирования кода
Если бы у нас были только клиентские машины, на каждой из них хранился бы одинаковый код по обработке логики, лежала вся база данных, все справочники террористов и прочая. Но так как сервер и БД вынесены в отдельные звенья, с клиентской машины освобождается куча места… И кода.
Не надо дублировать код, ведь вся основная логика вынесена на более мощный сервер.
На сервере и в базе хранится информация, недоступная простому операционисту. Это:
Есть операционисты, готовые за денюшку слить информацию о клиентах. Есть нечистые на руку люди, готовые невзначай заглянуть через плечо. А, может, клиент сам такой человек. Представляете, отпихивает Вася хрупкую Катю, садится за ее компьютер, и переводит себе на счет миллионы, пока его не повяжет охрана.
Зачем нужна база
При чем же тут БД? Вот у нас есть наш сервер, пусть он и хранит всю информацию. Бывает и так, иногда база просто не нужна и у нас остается двузвенная архитектура клиент-сервер.
В таком случае все данных сервер хранит в памяти. Вот только если сервер упадет, или просто перезагрузится — вся информация будет потеряна. Все, что было в памяти, стирается при выключении системы.
БД (база данных) — отдельный программный продукт, который позволяет:
Да, базы может не быть. Но когда она есть, мы уверены в сохранности данных и легко можем по ним поискать.
Плюсы архитектуры
Резюмируем плюсы архитектуры:
Минусы архитектуры
Упало одно звено — все отдыхают
Если упал сервер или отвалилась база, то есть испортилось 1 звено — всё, все в ступоре, все отдыхают. Сотни, тысячи, да хоть миллионы клиентов если есть — никто не может работать. Все операционистки грустно смотрят на окно «Простите, что-то пошло не так» и разводят руками перед клиентом.
Именно поэтому в бизнес-критичном ПО архитектуру усложняют и даже дублируют. Банк с тысячами операционистов не может позволить себе простой. Поэтому они используют кластер серверов — один упал, остальные работают.
Как в таком случае клиент понимает, куда ему отправлять запрос?
Перед серверами ставят балансировщик, и клиент шлет запрос туда. Сколько бы серверов не поставили в кластер, клиенту это не интересно. У него есть один URL — адрес балансировщика.
И вот с клиента поступает запрос:
— Дай мне всю информацию по Васе Иванову.
— Ребята, новый запрос! Кто меньше загружен?
— У меня 5 запросов в очереди стоит.
Балансировщик отправляет запрос второму серверу.
Такая схема используется для высоконагруженного приложения — когда запросов поступает так много, что один сервер с ними просто не справляется.
Facebook, amazon, google — туда заходят миллионы пользователей. Один сервер с ними не справится. Поэтому ставят кластер, а балансировщик делит между ними нагрузку. И в таком случае в кластере может быть не 2 сервера, а 10, 15, сколько нужно, столько и ставим.
При этом мы можем точно также балансировать базу данных. У нас может быть несколько копий баз данных на самых разных машинах, и балансировщик отправляет запросы то к одной, то ко второй.
Такая схема называется горячий резерв — когда у нас есть несколько серверов, работающих в параллель, и балансировщик распределяет нагрузку между ними.
При этом может быть и схема холодного резерва — когда у нас второй сервер является резервной копией «на всякий случай». Все запросы идут на первый сервер, второй отдыхает.
Но если с первым сервером что-то случится и он помрет, балансировщик перенаправит нагрузку на второй сервер:
В это время у администраторов будет время разобраться с проблемой на сервере 1.
Схема холодного резерва используется тогда, когда один сервер способен выдержать нагрузку и выдавать хорошую скорость работы. Но приложение при этом бизнес-критичное и простой неприемлем.
Простой может быть не только потому, что случилось что-то плохое. Есть еще штатное обновление приложения. Обе схемы резервирования позволяют обновляться безболезненно. Если в кластере два сервера, обновление будет выглядеть так:
Таким образом, схемы резервирования помогают нам устранить проблему «упало 1 звено — все отдыхают». Клиент никогда не узнает, что один или несколько серверов в кластере сдохли, у него всё как работало, так и работает.
Высокая стоимость оборудования
Сервера стоят дорого. Туда нельзя поставить обычный SSD как для домашнего компьютера. Почему? Потому что к железу для серверов совсем другие требования по надежности + есть поддержка специфичных функций:
— у HDD это специальная микропрограмма контроллера, которая оптимизирована для работы диска в RAID, дома это не нужно.
— у SSD это наличие группы конденсаторов, которые хранят энергию на случай отключения питания, чтобы хватило времени скинуть из DDR кэша данные в энергонезависимую память и данные не побились.
SSD — быстро работающий диск, HDD — обычный. RAID — когда мы N дисков вместе соединили, а DDR кэш — это оперативная память
Плюс у серверных решений гарантия обычно гораздо дольше: 5 лет, а не год.
По цене отличаются в 2 раза. Например, SSD:
Вроде не сильно отличается, да? Но смысл в том, что для дома 1 тб хватает за глаза — и фоточки все влезут, и кино, и куча приложений… А для базы данных иногда и 10 тб будет мало. А если делать кластер, то умножаем стоимость на 2, если не больше. Поэтому и разница в цене кажется огромная, но при пересчете на гигабайт небольшая выходит.
Не забывайте, что дома вам просто надо свои фоточки держать, да и те обычно в облаке. А на сервере бизнес-критичный функционал, который жрет дофига ресурсов и который надо дублировать на случай «вдруг первый сдохнет».
Нужно нанять сисадмина ツ
Нам нужно нанять сисадмина, который будет следить за всеми нашеми серверами приложения и БД. Добавляем его зарплату к стоимости оборудования!
Что тестировать
Чтобы понимать, что тестировать, надо понимать, с чем имеет дело человек.
Пользователь работает с клиентом. Это может быть web или desktop приложение, не суть. Операционистке Кате дали рабочее место, показали какую программу запускать и как с ней работать. Она знать не знает о наличии серверов и БД, она работает только с клиентом.
Поэтому тестировщик в первую очередь проверяет клиент! Потому что сервер может работать идеально, вы можете даже написать тесты на уровне API и они все будут зелененькие, и кажется, что все зашибись! А пользователь загрузит отчет и увидит ошибку. Ой.
Сервер работает, на клиенте ошибка. И плевать на сотни «зеленых» автотестов. У пользователя все равно ошибка. И наша задача — посмотреть с его точки зрения.
Однако, если у вас есть доступ к серверу приложения и его базе данных — стоит проверять и их тоже! Так мы можем увидеть «будущий баг». Например:
— Ну, наверное, их и не заполняли.
А их заполняли! Просто сохранение криво сработало. Поэтому, если у нас только черный ящик, то нужно проверять, «а реально ли сохранились данные?». Сохранили? Откройте карточку в новом окне или вызовете информацию через API-метод.
Если доступ к базе есть — просто проверьте по ней, что все хорошо. Если есть доступ к серверным логам — проверьте их на наличие ошибок.
Помимо простых пользователей бывают злые люди, которые пытаются встрять в наше приложение и своровать деньги / данные. Они используют не клиент или сервер — туда у них доступа нет. Они пытаются перехватить данные в пути от клиента к серверу, или от сервера к БД.
Ну а раз нехорошие люди могут это сделать, то тестировщик тоже должен это уметь! Потому что тестировщик предоставляет информацию о нашем продукте.
Тестировщик изучает уязвимости и потом рассказывает команде:
— Ребята, вот я проверил, у нас есть такие-то и такие-то потенциальные дыры. Давайте подумаем, надо нам их как-то закрывать или нет.
То есть не факт, что исправлять проблему будут. Может, у вас некритичное приложение — данные не утекут, деньги вы не храните. Тогда и заморачиваться лишний раз никто не будет, потому что тестировать на защищенность — дорого, специалистов мало.
Но какие-то базовые проверки типа sql-иньекций или XSS-атак стоит изучить и проверить на своем приложении. Хотя бы чтобы понять их критичность. Ведь если атака сломает клиент — ну и пусть, сам себе буратино. А если атака положит сервер, это уже не очень хорошо. И надо хотя бы знать, от чего это бывает.
Итого
Клиент — та программа, с которой работает пользователь. Он знать не знает, это у него на компьютере программа целиком, или где-то за ней прячутся сервер с базой, а то и целый RAID. Он работает в браузере или с desktop-приложением. И всё, что ему нужно знать — это «куда тут тыкать».
Клиенту не нужно много памяти, места на диске и других ресурсов. Поэтому рабочие места относительно дешево стоят. А это именно то, что нам нужно, особенно если нужно закупить оборудование для тысяч операционисток банка.
Сервер — компьютер, на котором хранится само приложение. Весь код, вся логика, все дополнительные материалы и справочники. Например, справочник адресов ФИАС или справочник юр лиц ЕГРЮЛ — они тоже занимают место, как сами по себе, так и в памяти приложения.
Иногда говорят «сервер приложения» и «сервер БД». Это нормально, ведь фактически сервер — это просто машина, компьютер. А базу и сервер приложения обычно хранят на разных машинах, ради безопасности. В таком случае, если говорят «сервер приложения» — речь о втором звене нашей схемы.
Приложения бывают самые разные. Есть ресурсоемкие, им нужно много памяти и места на диске. Есть «легкие», которые можно развернуть даже на домашнем компьютере.
БД (база данных) — хранилище данных. Тут вы можете легко поискать информацию + уверены в том, что она сохранится, даже если в приложении что-то сломается. Подробнее о ней — в статье «Что такое База Данных (БД)»
Сколько места нужно под базу, зависит от количества данных. Есть огромные базы в банках, где и 1тб будет мало. А есть совсем небольшие, которые вы можете установить на своей машине. Например, XAMPP можно поставить. И врядли вы напихаете туда столько данных, что у вас не останется под них место.
Отдельной базы может не быть, тогда структура станет двузвенной: клиент-сервер. И все!
Схема условная, в реальной жизни у нас как минимум будет больше клиентов. А если приложение высоконагруженное, то будет несколько серверов и несколько баз данных:
PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале