Сервер и клиент: Клиент-серверная архитектура в картинках / Хабр

Содержание

Клиент-сервер — Изучение веб-разработки | MDN

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

Перед стартом:	Базовая компьютерная грамотность. Базовое понимание того, что такое веб-сервер.
Цель:	Изучить взаимодействие между клиентом и сервером на динамическом веб-сайте и, в частности, узнать, какие действия нужно произвести в коде серверной части.

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

Веб-браузеры взаимодействуют с веб-серверами при помощи протокола передачи гипертекста (HTTP). Когда вы кликаете на ссылку на странице, заполняете форму или производите поиск, браузер отправляет на сервер HTTP-запрос.

Этот запрос включает:

Путь (URL), который определяет целевой сервер и ресурс (например, HTML-файл, конкретная точка данных на сервере или запускаемый инструмент).
Метод, который определяет необходимое действие (например, получить файл, сохранить или обновить какие-либо данные). Различные методы/команды и связанные с ними действия перечислены ниже:
- GET – получить определённый ресурс (например, HTML-файл, содержащий информацию о товаре или список товаров).
- POST – создать новый ресурс (например, добавить новую статью на вики, добавить новый контакт в базу данных).
- HEAD – получить метаданные об определённом ресурсе без получения содержания, как это делает запрос GET. Например, вы можете использовать запрос HEAD, чтобы узнать, когда ресурс в последний раз обновлялся, и только потом использовать (более «затратный») запрос GET, чтобы загрузить сам ресурс, если он был изменён.
- PUT – обновить существующий ресурс (или создать новый, если таковой не существует).
- DELETE – удалить определённый ресурс.
- TRACE, OPTIONS, CONNECT, PATCH – эти команды используются для менее популярных/более сложных задач, поэтому пока мы не будем их рассматривать.
Дополнительная информация может быть закодирована в запросе (например, данные HTML-формы). Информация может быть закодирована как:
- URL-параметры: GET запросы зашифровывают данные в URL-адресе, который отправляется на сервер, путём добавления пар имя/значение в его конец, например, http://mysite.com?name=Fred&age=11. В этом случае всегда ставится знак вопроса (?), отделяющий основную часть URL-адреса от URL-параметров, знак равно (=), отделяющий каждое имя от соответствующего ему значения, и амперсанд (&), разделяющий пары. URL-параметры, по своей сути, «небезопасны», так как могут быть изменены пользователями и затем отправлены повторно. В результате, URL-параметры /GET запросы не используются для запросов, которые обновляют данные на сервере.
- POST данные. POST запросы добавляют новые ресурсы, данные которых зашифрованы в теле самого запроса.
- Куки-файлы клиентской части. Куки-файлы содержат данные сессий о клиенте, включая ключи, которые сервер может использовать для определения статуса его авторизации и разрешения/права доступа к ресурсам.

Веб-серверы ожидают сообщений с запросами от клиентов, обрабатывают их, когда они приходят и отвечают веб-браузеру через сообщение с HTTP-ответом. Ответ содержит Код статуса HTTP-ответа, который показывает, был ли запрос успешным (например, «200 OK» означает успех, «404 Not Found» если ресурс не может быть найден, «403 Forbidden», если пользователь не имеет права просматривать ресурс, и т. д.). Тело успешного ответа на запрос GET будет содержать запрашиваемый ресурс.

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

Как статические, так и динамические веб-сайты (речь о которых идёт в следующих разделах) используют точно такой же протокол/шаблоны обмена данными.

Пример GET запроса/ответа

Вы можете сформировать простой GET запрос кликнув по ссылке или через поиск по сайту (такой как страница поисковой системы). Например, HTTP-запрос, отправленный во время выполнения запроса «client server overview» на сайте MDN, будет во многом похож на текст ниже (он не будет идентичным, потому что части сообщения зависят от вашего браузера/настроек).

Формат HTTP сообщения определён в «веб-стандарте» (RFC7230). Вам не нужно знать этот уровень детализации, но, по крайней мере, теперь вы знаете, откуда это появилось!

Запрос

Каждая строка запроса содержит информацию о запросе. Первая часть называется заголовок и содержит важную информацию о запросе, точно так же, как HTML head содержит важную информацию о HTML-документе (но не содержимое документа, которое расположено внутри тэга «body»):

GET https://developer.mozilla.org/en-US/search?q=client+server+overview&topic=apps&topic=html&topic=css&topic=js&topic=api&topic=webdev HTTP/1.1
Host: developer.mozilla.org
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Referer: https://developer.mozilla.org/en-US/
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: en-US,en;q=0.8,es;q=0.6
Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; csrftoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT; dwf_section_edit=False; dwf_sg_task_completion=False; _gat=1; _ga=GA1.2.1688886003.1471911953; ffo=true

Первая и вторая строки содержат большую часть информации, о которой говорилось выше:

Тип запроса (GET).
URL целевого ресурса (/en-US/search).
URL-параметры (q=client%2Bserver%2Boverview&topic=apps&topic=html&topic=css&topic=js&topic=api&topic=webdev).
Целевой/хост-веб-сайт (developer.mozilla.org).
Конец первой строки также содержит короткую строку, идентифицирующую версию протокола (HTTP/1.1).

Последняя строка содержит информацию о клиентских куки — в данном случае можно увидеть куки, включающие id для управления сессиями (Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; ...).

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

Мой браузер (User-Agent) — Mozilla Firefox (Mozilla/5.0).
Он может принимать информацию, упакованную в gzip (Accept-Encoding: gzip).
Он может принимать указанные кодировки (Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7) и языков (Accept-Language: de,en;q=0.7,en-us;q=0.3).
Строка Referer идентифицирует адрес веб-страницы, содержащей ссылку на этот ресурс (то есть источник оригинального запроса, https://developer.mozilla.org/en-US/).

HTTP-запрос может также содержать body, но в данном случае этого нет.

Ответ

Первая часть ответа на запрос показана ниже. Заголовок содержит следующую информацию:

Первая строка содержит код ответа 200 OK, говорящий о том, что запрос выполнен успешно.
Мы можем видеть, что ответ имеет text/html формат (Content-Type).
Также мы видим, что ответ использует кодировку UTF-8 (Content-Type: text/html; charset=utf-8).
Заголовок также содержит длину ответа (Content-Length: 41823).

В конце сообщения мы видим содержимое body, содержащее HTML-код возвращаемого ответа.

HTTP/1.1 200 OK
Server: Apache
X-Backend-Server: developer1.webapp.scl3.mozilla.com
Vary: Accept,Cookie, Accept-Encoding
Content-Type: text/html; charset=utf-8
Date: Wed, 07 Sep 2016 00:11:31 GMT
Keep-Alive: timeout=5, max=999
Connection: Keep-Alive
X-Frame-Options: DENY
Allow: GET
X-Cache-Info: caching
Content-Length: 41823



<!DOCTYPE html>
<html lang="en-US" dir="ltr"  data-ffo-opensanslight=false data-ffo-opensans=false >
<head prefix="og: http://ogp.me/ns#">
  <meta charset="utf-8">
  <meta http-equiv="X-UA-Compatible" content="IE=Edge">
  <script>(function(d) { d.className = d.className.replace(/\bno-js/, ''); })(document.documentElement);</script>
  ...

Остальная часть заголовка ответа содержит информацию об ответе (например, когда он был сгенерирован), сервере и о том, как он ожидает, что браузер обработает страницу (например, строка X-Frame-Options: DENY говорит браузеру не допускать внедрения этой страницы, если она будет внедрена в <iframe> (en-US) на другом сайте).

Пример POST запроса/ответа

HTTP POST создаётся, когда вы отправляете форму, содержащую информацию, которая должна быть сохранена на сервере.

Запрос

В приведённом ниже тексте показан HTTP-запрос, сделанный когда пользователь загружает новые данные профиля на этом сайте. Формат запроса почти такой же, как пример запроса GET, показанный ранее, хотя первая строка идентифицирует этот запрос как POST.

POST https://developer.mozilla.org/en-US/profiles/hamishwillee/edit HTTP/1.1
Host: developer.mozilla.org
Connection: keep-alive
Content-Length: 432
Pragma: no-cache
Cache-Control: no-cache
Origin: https://developer.mozilla.org
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Referer: https://developer.mozilla.org/en-US/profiles/hamishwillee/edit
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8,es;q=0.6
Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; _gat=1; csrftoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT; dwf_section_edit=False; dwf_sg_task_completion=False; _ga=GA1.2.1688886003.1471911953; ffo=true

csrfmiddlewaretoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT&user-username=hamishwillee&user-fullname=Hamish+Willee&user-title=&user-organization=&user-location=Australia&user-locale=en-US&user-timezone=Australia%2FMelbourne&user-irc_nickname=&user-interests=&user-expertise=&user-twitter_url=&user-stackoverflow_url=&user-linkedin_url=&user-mozillians_url=&user-facebook_url=

Основное различие заключается в том, что URL-адрес не имеет параметров. Как вы можете видеть, информация из формы закодирована в теле запроса (например, новое полное имя пользователя устанавливается с использованием: &user-fullname=Hamish+Willee).

Ответ

Ответ от запроса показан ниже. Код состояния «302 Found» сообщает браузеру, что сообщение обработано, и что необходим второй HTTP-запрос для загрузки страницы, указанной в поле Location. В остальном информация аналогична информации для ответа на запрос GET .

HTTP/1.1 302 FOUND
Server: Apache
X-Backend-Server: developer3.webapp.scl3.mozilla.com
Vary: Cookie
Vary: Accept-Encoding
Content-Type: text/html; charset=utf-8
Date: Wed, 07 Sep 2016 00:38:13 GMT
Location: https://developer.mozilla.org/en-US/profiles/hamishwillee
Keep-Alive: timeout=5, max=1000
Connection: Keep-Alive
X-Frame-Options: DENY
X-Cache-Info: not cacheable; request wasn't a GET or HEAD
Content-Length: 0

На заметку: HTTP-ответы и запросы, показанные в этих примерах, были захвачены с помощью приложения Fiddler, но вы можете получить аналогичную информацию с помощью веб-снифферов (например, http://web-sniffer.net/) или с помощью расширений браузера, таких как HttpFox. Вы можете попробовать это сами. Воспользуйтесь любым из предложенных инструментов, а затем перейдите по сайту и отредактируйте информацию профиля, чтобы увидеть различные запросы и ответы. В большинстве современных браузеров также есть инструменты, которые отслеживают сетевые запросы (например, инструмент Network Monitor в Firefox).

Статический сайт — это тот, который возвращает тот же жёсткий кодированный контент с сервера всякий раз, когда запрашивается конкретный ресурс. Например, если у вас есть страница о товаре в /static/myproduct1.html, эта же страница будет возвращена каждому пользователю. Если вы добавите ещё один подобный товар на свой сайт, вам нужно будет добавить ещё одну страницу (например, myproduct2.html) и так далее. Это может стать действительно неэффективным — что происходит, когда вы попадаете на тысячи страниц товаров? Вы повторяли бы много кода на каждой странице (основной шаблон страницы, структуру и т. д.), И если бы вы захотели изменить что-либо в структуре страницы — например, добавить новый раздел «связанные товары» — тогда вам придётся менять каждую страницу отдельно.

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

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

Когда пользователь хочет перейти на страницу, браузер отправляет HTTP-запрос GET с указанием URL-адреса его HTML-страницы. Сервер извлекает запрошенный документ из своей файловой системы и возвращает HTTP-ответ, содержащий документ и код состояния HTTP Response status code 200 OK (успех). Сервер может вернуть другой код состояния, например, «404 Not Found», если файл отсутствует на сервере или «301 Moved Permanently», если файл существует, но был перемещён в другое место.

Серверу для статического сайта нужно будет только обрабатывать GET-запросы, потому что сервер не сохраняет никаких модифицируемых данных. Он также не изменяет свои ответы на основе данных HTTP-запроса (например, URL-параметров или файлов cookie).

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

Динамический сайт — это тот, который может генерировать и возвращать контент на основе конкретного URL-адреса запроса и данных (а не всегда возвращать один и тот же жёсткий код для определённого URL-адреса). Используя пример сайта товара, сервер будет хранить «данные» товара в базе данных, а не отдельные HTML-файлы. При получении GET-запроса для товара сервер определяет идентификатор товара, извлекает данные из базы данных и затем создаёт HTML-страницу для ответа, вставляя данные в HTML-шаблон. Это имеет большие преимущества перед статическим сайтом:

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

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

Анатомия динамического запроса

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

На приведённой ниже диаграмме показаны основные элементы веб-сайта «team coach», а также пронумерованные ярлыки для последовательности операций, когда тренер обращается к списку «лучших команд». Частями сайта, которые делают его динамичным, являются веб-приложение (так мы будем ссылаться на серверный код, обрабатывающий HTTP-запросы и возвращающие HTTP-ответы), база данных, которая содержит информацию об игроках, командах, тренерах и их отношениях, и HTML-шаблоны.

После того, как тренер отправит форму с именем команды и количеством игроков, последовательность операций будет следующей:

Веб-браузер отправит HTTP-запрос GET на сервер с использованием базового URL-адреса ресурса (/best) и кодирования номера команды и игрока в форме URL-параметров (например, /best?team=my_team_name&show=11) или как часть URL-адреса (например, /best/my_team_name/11/). Запрос GET используется, потому что речь идёт только о запросе выборки данных (а не об их изменении).
Веб-сервер определяет, что запрос является «динамическим» и пересылает его в веб-приложение для обработки (веб-сервер определяет, как обрабатывать разные URL-адреса на основе правил сопоставления шаблонов, определённых в его конфигурации).
Веб-приложение определяет, что цель запроса состоит в том, чтобы получить «лучший список команд» на основе URL (/best/) и узнать имя команды и количество игроков из URL-адреса. Затем веб-приложение получает требуемую информацию из базы данных (используя дополнительные «внутренние» параметры, чтобы определить, какие игроки являются «лучшими», и, возможно, определяя личность зарегистрированного тренера из файла cookie на стороне клиента).
Веб-приложение динамически создаёт HTML-страницу, помещая данные (из базы данных) в заполнители внутри HTML-шаблона.
Веб-приложение возвращает сгенерированный HTML в веб-браузер (через веб-сервер) вместе с кодом состояния HTTP 200 («успех»). Если что-либо препятствует возврату HTML, веб-приложение вернёт другой код, например, «404», чтобы указать, что команда не существует.
Затем веб-браузер начнёт обрабатывать возвращённый HTML, отправив отдельные запросы, чтобы получить любые другие файлы CSS или JavaScript, на которые он ссылается (см. шаг 7).
Веб-сервер загружает статические файлы из файловой системы и возвращает их непосредственно в браузер (опять же, правильная обработка файлов основана на правилах конфигурации и сопоставлении шаблонов URL).

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

Выполнение другой работы

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

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

Возвращение чего-то другого, кроме HTML

Серверный код сайта может возвращать не только HTML-фрагменты и файлы в ответе. Он может динамически создавать и возвращать другие типы файлов (текст, PDF, CSV и т. д.) или даже данные (JSON, XML и т. д.).

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

Веб-фреймворки на стороне сервера делают написание кода для обработки описанных выше операций намного проще.

Одной из наиболее важных операций, которые они выполняют, является предоставление простых механизмов для сопоставления URL-адресов для разных ресурсов/страниц с конкретными функциями обработчика. Это упрощает сохранение кода, связанного с каждым типом ресурса, отдельно от остального. Это также имеет преимущества с точки зрения обслуживания, поскольку вы можете изменить URL-адрес, используемый для доставки определённой функции в одном месте, без необходимости изменять функцию обработчика.junior/$’, потому что они используют метод сопоставления шаблонов под названием «регулярные выражения» (RegEx или RE). Вам не нужно знать, как работают регулярные выражения на этом этапе, кроме того, что они позволяют нам сопоставлять шаблоны в URL-адресе (а не жёстко закодированные значения выше) и использовать их в качестве параметров в наших функциях просмотра. В качестве примера, действительно простой RegEx может говорить «соответствовать одной заглавной букве, за которой следуют от 4 до 7 строчных букв».

Веб-фреймворк также упрощает функцию просмотра для получения информации из базы данных. Структура наших данных определяется в моделях, которые являются классами Python, которые определяют поля, которые должны храниться в основной базе данных. Если у нас есть модель с именем Team с полем «team_type», мы можем использовать простой синтаксис запроса, чтобы получить все команды, имеющие определённый тип.

В приведённом ниже примере представлен список всех команд, у которых есть точный (с учётом регистра) team_type «junior» («младший») — обратите внимание на формат: имя поля (team_type), за которым следует двойной знак подчёркивания, а затем тип соответствия для использования (в этом случае exact («точное»)). Существует много других типов соответствия, и мы можем объединить их. Мы также можем контролировать порядок и количество возвращаемых результатов.



from django.shortcuts import render

from .models import Team


def junior(request):
    list_teams = Team.objects.filter(team_type__exact="junior")
    context = {'list': list_teams}
    return render(request, 'best/index.html', context)

После того, как функция junior() получает список младших команд, она вызывает функцию render(), передавая исходный HttpRequest, HTML-шаблон и объект «context», определяющий информацию, которая должна быть включена в шаблон. Функция render() — это функция удобства, которая генерирует HTML с использованием контекста и HTML-шаблона и возвращает его в объект HttpResponse.

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

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

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

Технология «клиент-сервер» и мониторы транзакций | Открытые системы. СУБД

модель сервера приложений (Application Server — AS).

В RDA-модели коды компонента представления и прикладного компонента совмещены и выполнятся на компьютере-клиенте, Последний поддерживает как функции ввода и отображения данных, так и чисто прикладные функции. Доступ к информационным ресурсам обеспечивается, как правило, операторами специального языка (языка SQL, например, если речь идет о базах данных) или вызовами функций специальной библиотеки ( если имеется соответствующий API). Запросы к информационным ресурсам направляются по сети удаленному компьютеру (например, серверу базы данных). Последний обрабатывает и выполняет запросы и возвращает клиенту блоки данных (рисунок 1). Говоря об архитектуре «клиент-сервер», в большинстве случаев имеют в виду именно эту модель.

Рис. 1. Модель доступа к удаленным данным

DSB-модель (рисунок 2) строится в предположении, что процесс, выполняемый на компьютере-клиенте, ограничивается функциями представления, в то время как собственно прикладные функции реализованы в хранимых процедурах (stored procedure), которые также называют компилируемыми резидентными процедурами, или процедурами базы данных Они хранятся непосредственно в базе данных и выполняются на компьютере-сервере базы данных (где функционирует и компонент, управляющий доступом к данным, то есть ядро СУБД). Понятие информационного ресурса сужено до баз данных, поскольку механизм хранимых процедур — отличительная характеристика DBS-модели — имеется пока только в СУБД, да и то не во всех.

Рис. 2. Модель сервера базы данных

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

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

Рис. 3. Модель сервера приложений

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

RDA-модель

Главное преимущество RDA-модели лежит в практической плоскости. Сегодня существует множество инструментальных средств, обеспечивающих быстрое создание desktop-приложений, работающих с SQL-ориентированными СУБД. Большинство из них поддерживают графический интерфейс пользователя в MS Windows, стандарт интерфейса ODBC, содержат средства автоматической генерации кода. Иными словами, основное достоинство RDA-модели заключается в унификации и широком выборе средств разработки приложений. Подавляющее большинство этих средств разработки на языках четвертого поколения ( включая и средства автоматизации программирования) как раз и создают коды, в которых смешаны прикладные функции и функции представления.

RDA-модель имеет ряд ограничений.

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

Во-вторых, удовлетворительное администрирование приложений в RDA-модели практически невозможно. Очевидно, что если различные по своей природе функции (функции представления и чисто прикладные функции) смешаны в одной и той же программе, написанной на языке 4GL, то при необходимости изменения прикладных функций приходится переписывать всю программу целиком. При коллективной работе над проектом, как правило, каждому разработчику поручается реализация отдельных прикладных функций, что делает невозможным контроль за их взаимной непротиворечивостью. Каждому из разработчиков приходится программировать интерфейс с пользователем, что ставит под вопрос единый стиль интерфейса и его целостность.

DBS-модель

Несмотря на широкое распространение, RDA-модель уступает место более технологичной DBS-модели. Последняя реализована в некоторых реляционных СУБД (Ingres, Sybase, Oracle). Ее основу составляет механизм хранимых процедур — средство программирования ядра СУБД. Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует ядро СУБД. Язык, на котором разрабатываются хранимые процедуры, представляет собой процедурное расширение языка запросов SQL и уникален для каждой конкретной СУБД. Попытки стандартизации языка SQL, касающиеся хранимых процедур, пока не привели к ощутимому успеху. Кроме того, во многих реализациях процедуры являются интерпретируемыми, что делает их выполнение более медленным, нежели выполнение программ, написанных на языках третьего поколения. Механизм хранимых процедур — один из составных компонентов активного сервера базы данных [2].

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

Во-первых, средства, используемые для написания хранимых процедур, строго говоря, не являются языками программирования в полном смысле слова. Скорее, это — разнообразные процедурные расширения SQL, не выдерживающие сравнения по изобразительным средствам и функциональным возможностям с языками третьего поколения, такими как C или Pascal. Они встроены в конкретные СУБД, и, естественно, рамки их использования ограничены. Следовательно, система, в которой прикладной компонент реализован при помощи хранимых процедур, не является мобильной относительно СУБД. Кроме того, в большинстве СУБД отсутствуют возможности отладки и тестирования хранимых процедур, что превращает последние в весьма опасный механизм. Действительно, сколько-нибудь сложная неотлаженная комбинация срабатывания триггеров и запуска процедур может, по меткому выражению одного из разработчиков, «полностью разнести всю базу данных».

Во-вторых, DBS-модель не обеспечивает требуемой эффективности использования вычислительных ресурсов. Объективные ограничения в ядре СУБД не позволяют пока организовать в его рамках эффективный баланс загрузки, миграцию процедур на другие компьютеры-серверы БД и реализовать другие полезные функции. Попытки разработчиков СУБД предусмотреть в своих системах эти возможности (распределенные хранимые процедуры, запросы с приоритетами и т. д.) пока не позволяют добиться желаемого эффекта.

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

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

поддержка приоритетной обработки запросов.

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

AS-модель

Основным элементом принятой в AS-модели трехзвенной схемы является сервер приложения. В его рамках реализовано несколько прикладных функций, каждая из которых оформлена как служба (service) и предоставляет некоторые услуги всем программам, которые желают и могут ими воспользоваться. Серверов приложений может быть несколько, и каждый их них предоставляет определенный набор услуг. Любая программа, которая пользуется ими, рассматривается как клиент приложения (Applicaation Client — AC). Детали реализации прикладных функций в сервере приложений полностью скрыты от клиента приложения. AC обращается с запросом к конкретной службе, но не к AS, то есть серверы приложений обезличены и служат лишь своего рода «рамкой» для оформления служб, что позволяет эффективно управлять балансом загрузки. Запросы, поступающие от АС, выстраиваются в очередь к AS-процессу, который извлекает и передает их для обработки службе в соответствии с приоритетами.

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

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

Мониторы транзакций

Мониторы обработки транзакций (Transaction Processing Monitor — TPM), или, проще, мониторы транзакций — программные системы (которые часто относят к категории middleware), обеспечивающие эффективное управление информационно-вычислительными ресурсами в распределенной системе. Они представляют собой гибкую, открытую среду для разработки и управления мобильными приложениями, ориентированными на оперативную обработку распределенных транзакций. В числе важнейших характеристик ТРМ — масштабируемость, поддержка функциональной полноты и целостности приложений, достижение максимальной производительности при обработке данных при невысоких стоимостных показателях, поддержка целостности данных в гетерогенной среде.

Среда разработки приложений

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

Концетрация чисто прикладных функций в серверах приложений и использование унифицированных интерфейсов с другими логическими компонентами делает прикладную систему практически полностью независимой, во-первых, от конкретной реализации интерфейса с пользователем, и, во-вторых, от необходимого ей менеджера ресурсов. Первое означает, что для реализации компонента представления может быть выбран практически любой удобный и привычный для разработчика инструментарий, будь то Visual Basic, Object Vision или просто С. Следствием второго является то, что менеджер ресурсов (например, СУБД) может быть безболезненно заменен на другой, поддерживающий тот же стандарт интерфейса с прикладной программой — для реляционных СУБД в качестве унифицированного интерфейса используется встроенный (embedded) SQL TMP, функционирующие на множестве платформ (например, TUXEDO System), позволяют разрабатывать приложения, не зависящие ни от конкретной платформы, ни от конкретных средств разработки, ни от конкретных средств коммуникации. Все это заставляет рассматривать их как мощный инструмент для создания полностью мобильных приложений в гетерогенной среде.

Центр проектирования приложений

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

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

Баланс загрузки

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

Масштабируемость

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

Оптимальное соотношение цена/производительность

ТРМ обладает возможностями, которые существенно снижают стоимость обработки данных в online-приложениях. Небольшие затраты на приобретение ТРМ с лихвой компенсируются экономией на СУБД. Дело в том, что, как правило, стоимость современных СУБД рассчитывается исходя их числа одновременных подключений. Клиент считается подключенным к СУБД, начиная с момента открытия сеанса с базой данных и заканчивая ее закрытием (хотя в рамках одного подключения некоторые СУБД, например, INGRES, позволяют открыть несколько сеансов с различными БД). В течение сеанса СУБД считает клиента активным и вынуждена хранить контекст его подключения, даже в том случае, если клиент вообще не направляет запросов СУБД, а выполняет свои внутренние функции, либо просто ждет ввода от пользователя (который, быть может, ушел пообедать).

Основная функция ТРМ — обеспечение быстрой обработки запросов, поступающих к AS от множества клиентов (от сотен до многих тысяч). ТРМ выполняет ее, мультиплексируя запросы на обслуживание, направляя их к AS, число которых контролируется им самим. Запросы на обработку данных формируются AS на языке SQL и адресуются СУБД. Между АС и СУБД появляется дополнительный слой (AS), которые выполняют роль мультиплексора. Действительно, АС подключается к AS, передает ему данные для обработки; после того, как AS выполнил требуемые действия, он получает результаты обработки и отключается. Контекст подключения не сохраняется, так как в этом нет никакой необходимости. В то же время клиент обращается с запросами на обслуживание не к СУБД, а к AS, следовательно, СУБД регистрирует и отслеживает подключения AS, но не АС. Однако таких подключений по определению будет гораздо меньше, чем возможных подключений клиентов — хотя бы потому, что сервер приложений предоставляет сервис, разделяемый одновременно несколькими клиентами. Но это позволяет ограничить максимально возможное число одновременных подключений к СУБД, уменьшив тем самым ее стоимость. Фактические данные, приведенные, например, в [3], свидетельствуют о том, что выигрыш в стоимости в приобретении пары «монитор транзакций — СУБД» по сравнению с приобретением только СУБД (как это не кажется парадоксальным) может достигать 50%, при этом производительность может возрасти в несколько раз.

Для понимания идей, заложенных в мониторы транзакций, важно рассмотреть модель обработки распределенных транзакций, которая была предложена USL и принята X/Open в качестве стандарта.

Модель обработки транзакций

Модель X/Open DTP описывает взаимодействие трех субъектов обработки транзакций — прикладной программы (в качестве прикладной программы фигурирует как AS, так и АС), менеджера транзакций (Transaction Manager — TM) и менеджера ресурсов (Recource Manager — RM).

На RM возложено управление информационными ресурсами — будь то файлы, базы данных или что-то другое. Прикладная программа взаимодействует с RM либо с помощью набора специальных функций, либо, если в качестве RM выступает реляционная SQL-ориентированная СУБД — посредством операторов языка SQL, инициируя необходимые операции с данными. Последние оформляются как транзакции, обработку которых берет на себя ТМ. Если с помощью монитора транзакций необходимо решать задачи обработки глобальных транзакций, то место менеджера ресурсов должна занять СУБД, поддерживающая протокол двухфазовый фиксации транзакций и удовлетворяющая стандарту X/Open XA (например, Oracle 7.0, Open INGRES, Informix-Online 5.0).

Роль ТМ в модели X/Open DTP — роль диспетчера, главного координатора транзакций. Он обладает полным набором управления как локальными, так и глобальными транзакциями. В последнем случае транзакция может обновлять данные на нескольких узлах, причем управление данными на них осуществляется, вообще говоря, различными RM. Обработки распределенных транзакций обеспечивается за счет использования протокола двухфазовой фиксации транзакций, который гарантирует целостность данных в информационной системе, распределенной по нескольким узлам, независимо от того, какой RM управляет обработкой данных на каждом таком узле. Эта уникальная возможность мониторов транзакций как раз и позволяет рассматривать их как своего рода «клей», как средство интеграции в гетерогенной информационной среде.

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

Функции ТРМ в модели X/Open DTP не ограничиваются только управлением транзакциями. Он берет на себя также координацию взаимодействия клиента и сервера (поэтому иногда его называют Transaction & Communication Manager). При этом используется высокоуровневый интерфейс ATMI (Application Transaction Monitor Interface), представляющий собой набор вызовов функций на языке третьего поколения (например, на языке С). С его помощью разработчик реализует один из нескольких режимов взаимодействия клиента и сервера в рамках расширенной модели «клиент-сервер». Ни AS, ни АС не содержат явных вызовов менеджера транзакций — они включены в библиотечные функции ATMI и невидимы извне. Таким образом, детали взаимодействия прикладной программы и монитора транзакций скрыты от разработчика, что и дает основание говорить об ATMI как о высокоуровневом интерфейсе.

Стандартный способ передачи данных между AC и AS — буфера данных. Они представляют собой определяемые разработчиком структуры данных, память под которые выделяется ТМ. В процессе передачи данных ТМ выполняет различные преобразования (например, согласует формат представления данных при передаче их между машинами с разными архитектурами).

Модель X/Open DTP не описывает в деталях структуру монитора транзакций. Она лишь определяет, из каких компонентов должна состоять любая система DTP и как эти компоненты взаимодействуют друг с другом. Будучи воплощенной в конкретной системе, модель дополняется возможностями, существенно расширяющими традиционные представления о технологии «клиент-сервер». Например, монитор транзакций TUXEDO позволяет организовать взаимодействие АС и AS несколькими способами.

С помощью синхронного вызова tpcall() АС вызывает конкретную службу (один из параметров — имя службы), передает ей исходные данные в буфере и немедленно получает от службы результат обработки. Асинхронный вызов (функция tpcall()) делает то же самое, с тем лишь отличием, что результат обработки возвращается не сразу; клиент запрашивает службу для получения результатов обработки вызовом tpgetrply(). Асинхронный способ взаимодействия позволяет клиенту передать серверу запрос, продолжить работу и получить результаты запроса самостоятельно и в нужный момент времени. Кроме того, поддерживается диалоговый режим взаимодействия, позволяющий сохранять его контекст от сообщения к сообщению. Клиент подключается к серверу (вызов tpconnect()), получая его в монопольное использования до момента окончания диалога (вызов tpdiscon()). Наконец, существует вариант обмена сообщениями между клиентом и сервером через хранимые на диске очереди.

Система управления очередями

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

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

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

Упрощенно работа с очередями выглядит следующим образом. Клиент посылает запрос конкретной службе, направляя его серверу TMQUEUE (вызов tpenqueue()). Последний помещает сообщение в очередь запросов к данной службе. Сервер TMQFORWARD извлекает сообщение из очереди запросов и направляет его службе (вызов tpcall()). Последняя, выполнив предписанные действия и сформировав ответ на запрос также в виде сообщения, посылает его в очередь ответов. Клиент, при помощи вызова tpdequeue(), запрашивает сервер TMQUEUE на получение сообщения из очереди ответов, что тот и выполняет.

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

***

На современном рынке мониторов транзакций основными «действующими лицами» являются такие системы, как ACMS (DEC), CICS (IBM), TOP END (NCR), PATHWAY (Tandem), ENCINA (Transarc), TUXEDO System (USL). Особе место TUXEDO System в этом ряду объясняется несколькими факторами. Система была разработана специалистами USL (компании, ныне поглощенной Novell Inc.), развивалась и совершенствовалась в течение более десяти лет и сегодня фактически приобрела статус стандарта для открытых систем OLTP. Будучи «ветераном» TMP, они послужила прототипом для мониторов транзакций, разработанных крупнейшими поставщиками компьютерных платформ. Ориентация на широкий спектр компьютеров под управлением ОС UNIX позволила системе охватить множество платформ, среди которых AT&T, Amdahl, Bull, Compaq, DataGeneral, Dell, DEC, HP, IBM, ICL, Motorola, NCR, NEC, Pyramid, Sequent, Siemens Nixdorf, Silicon Graphics, Stratus, Su, Tandem, Teradata, Unisys. Компактность кода (около 30 функций ATMI), рациональная архитектура, эффективное использование базовых механизмов ОС UNIX и ряд других привлекательных качеств (в которых автор удостоверился на практике) снискали TUXEDO System популярность среди разработчиков и менеджеров информационных систем.

В России TUXEDO System впервые была представлена на конференции SUUG в 1992 году. Сегодня система доступна для российских разработчиков. Написанию статьи предшествовали многочисленные и плодотворные обсуждения этой темы с Владимиром Елисеевым, им же сделаны ценные замечания по тексту статьи, за что автора выражает глубокую признательность.

как правильно проектировать и разрабатывать web API

Рассказывает Владимир, веб-разработчик Noveo

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

Приближение первое: Действующие лица

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

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

Клиент и сервер

Сервером в данном случае мы считаем абстрактную машину в сети, способную получить HTTP-запрос, обработать его и вернуть корректный ответ. В контексте данной статьи совершенно не важны его физическая суть и внутренняя архитектура, будь то студенческий ноутбук или огромный кластер из промышленных серверов, разбросанных по всему миру. Нам в той же мере совершенно неважно, что у него под капотом, кто встречает запрос у дверей, Apache или Nginx, какой неведомый зверь, PHP, Python или Ruby выполняет его обработку и формирует ответ, какое хранилище данных используется: Postgresql, MySQL или MongoDB. Главное, чтобы сервер отвечал главному правилу — услышать, понять и ~~простить~~ ответить.

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

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

Философия REST

REST (Representational state transfer) изначально был задуман как простой и однозначный интерфейс для управления данными, предполагавший всего несколько базовых операций с непосредственным сетевым хранилищем (сервером): извлечение данных (GET), сохранение (POST), изменение (PUT/PATCH) и удаление (DELETE). Разумеется, этот перечень всегда сопровождался такими опциями, как обработка ошибок в запросе (корректно ли составлен запрос), разграничение доступа к данным (вдруг этого вам знать не следует) и валидация входящих данных (вдруг вы написали ерунду), в общем, всеми возможными проверками, которые сервер выполняет перед тем, как выполнить желание клиента.

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

Независимость сервера от клиента — серверы и клиенты могут быть мгновенно заменены другими независимо друг от друга, так как интерфейс между ними не меняется. Сервер не хранит состояний клиента.
Уникальность адресов ресурсов — каждая единица данных (любой степени вложенности) имеет свой собственный уникальный URL, который, по сути, целиком является однозначным идентификатором ресурса.

Пример: GET /api/v1/users/25/name

Независимость формата хранения данных от формата их передачи — сервер может поддерживать несколько различных форматов для передачи одних и тех же данных (JSON, XML и т.д.), но хранит данные в своем внутреннем формате, независимо от поддерживаемых.

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

Чего нам не хватает

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

Вызовы функций

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

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

Еще вариант – создание и разрыв связей между данными. Например, добавление пользователя в группу. Вызываем у сущности группа функцию addUser, в качестве параметра передаем объект пользователь, получаем результат.

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

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

Множественные операции

Часто бывает так, и разработчики клиентов поймут, о чем я, что клиентскому приложению удобнее создавать/изменять/удалять/ сразу несколько однородных объектов одним запросом, и по каждому объекту возможен свой вердикт серверной стороны. Тут есть как минимум несколько вариантов: либо все изменения выполнены, либо они выполнены частично (для части объектов), либо произошла ошибка. Ну и стратегий тоже несколько: применять изменения только в случае успеха для всех, либо применять частично, либо откатываться в случае любой ошибки, а это уже тянет на полноценный механизм транзакций.

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

Статистические запросы, агрегаторы, форматирование данных

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

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

Разновидности данных

Объекты

Ключевым типом данных в общении между клиентом и сервером выступает объект. По сути, объект – это перечень свойств и соответствующих им значений. Мы можем отправить объект на сервер в запросе и получить в результат запроса в виде объекта. При этом объект не обязательно будет реальной сущностью, хранящейся в базе данных, по крайней мере, в том виде, в котором он отправлен или получен. Например, учетные данные для авторизации передаются в виде объекта, но не являются самостоятельной сущностью. Даже хранимые в БД объекты склонны обрастать дополнительными свойствами внутрисистемного характера, например, датами создания и редактирования, различными системными метками и флагами. Свойства объектов могут быть как собственными скалярными значениями, так и содержать связанные объекты и коллекции объектов, которые не являются частью объекта. Часть свойств объектов может быть редактируемой, часть системной, доступной только для чтения, а часть может носить статистический характер и вычисляться на лету (например, количество лайков). Некоторые свойства объекта могут быть скрыты, в зависимости от прав пользователя.

Коллекции объектов

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

Скалярные значения

В чистом виде скалярные значения как отдельная сущность на моей памяти встречались крайне редко. Обычно они фигурировали как свойства объектов или коллекций, и в этом качестве они могут быть доступны как для чтения, так и для записи. Например, имя пользователя может быть получено и изменено в индивидуальном порядке GET /users/1/name. На практике эта возможность пригождается редко, но в случае необходимости хотелось бы, чтобы она была под рукой. Особенно это касается свойств коллекции, например числа записей (с фильтрацией или без нее): GET /news/count.

Приближение второе: Правильный путь

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

О чем стоит подумать, стоя на берегу

Версионность

Рано или поздно любая действующая система начинает эволюционировать: развиваться, усложняться, масштабироваться, усовремениваться. Для разработчиков REST API это чревато в первую очередь тем, что необходимо запускать новые версии API при работающих старых. Здесь я говорю больше не об архитектурных изменениях под капотом вашей системы, а о том, что изменяется сам формат данных и набор операций с ними. В любом случае версионность нужно предусмотреть как в изначальной организации исходного кода, так и в принципе построения URL. Что касается URL, здесь существует два наиболее популярных способа указания версии API, которой адресован запрос. Префиксация пути example-api.com/v1/ и разведение версий на уровне субдомена v1.example-api.com . Использовать можно любой из них, в зависимости от потребности и необходимости.

Автономность компонентов

Web API сложных систем, поддерживающих несколько пользовательских ролей, зачастую требует разделения на части, каждая из которых обслуживает свой спектр задач. По сути, каждая часть может быть самостоятельным приложением, работать на разных физических машинах и платформах. В контексте описания API нам совершенно не важно, как сервер обрабатывает запрос и какие силы и технологии в этом замешаны. Для клиента API – система инкапсулированная. Тем не менее разные части системы могут обладать совершенно разной функциональностью, например, административная и пользовательская часть. И методология работы с одними и теми же, казалось бы, ресурсами может существенно отличаться. Поэтому такие части необходимо разделять на уровне домена admin.v1.example-api.com или префикса пути example-api.com/v1/admin/ . Это требование не является обязательным, и многое зависит от сложности системы и её назначения.

Формат обмена данными

Самым удобным и функциональным, на мой взгляд, форматом обмена данными является JSON, но никто не запрещает использовать XML, YAML или любой другой формат, позволяющий хранить сериализованные объекты без потери типа данных. При желании можно сделать в API поддержку нескольких форматов ввода/вывода. Достаточно задействовать HTTP заголовок запроса для указания желаемого формата ответа Accept и Content-Type для указания формата переданных в запросе данных. Другим популярным способом является добавление расширения к URL ресурса, например, GET /users.xml , но такой способ кажется менее гибким и красивым, хотя бы потому, что утяжеляет URL и верен скорее для GET-запросов, нежели для всех возможных операций.

Локализация и многоязычность

На практике многоязычность API чаще всего сводится к переводу сервисных сообщений и сообщений об ошибках на требуемый язык для прямого отображения конечному пользователю. Многоязычный контент тоже имеет место быть, но сохранение и выдача контента на разных языках, на мой взгляд, должна разграничиваться более явно, например, если у вас одна и та же статья существует на разных языках, то по факту это две разных сущности, сгруппированные по признаку единства содержания. Для идентификации ожидаемого языка можно использовать разные способы. Самым простым можно считать стандартный HTTP-заголовок Accept-Language . Я встречал и другие способы, такие, как добавление GET-параметра language="en" , использование префикса пути example-api.com/en/ или даже на уровне доменного имени en.example-api.com . Мне кажется, что выбор способа указания локали зависит от конкретного приложения и задач, стоящих перед ним.

Внутренняя маршрутизация

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

Пути к коллекциям

Для указания пути к коллекции мы просто используем название соответствующей сущности, например, если это список пользователей, то путь будет таким /users . К коллекции как таковой применимы два метода: GET (получение лимитированного списка сущностей) и POST (создание нового элемента). В запросах на получение списков мы можем использовать множество дополнительных GET параметров, применяемых для постраничного вывода, сортировки, фильтрации, поиска etc, но они должны быть опциональными, т.е. эти параметры не должны передаваться как часть пути!

Элементы коллекции

Для обращения к конкретному элементу коллекции мы используем в маршруте его уникальный идентификатор /users/25 . Это и есть уникальный путь к нему. Для работы с объектом применимы методы GET (получение объекта), PUT/PATCH (изменение) и DELETE (удаление).

Уникальные объекты

Во множестве сервисов существуют уникальные для текущего пользователя объекты, например профиль текущего пользователя /profile , или персональные настройки /settings . Разумеется, с одной стороны, это элементы одной из коллекций, но они являются отправной точкой в использовании нашего Web API клиентским приложением, и к тому же позволяют намного более широкий спектр операций над данными. При этом коллекция, хранящая пользовательские настройки может быть вообще недоступна из соображений безопасности и конфиденциальности данных.

Свойства объектов и коллекций

Для того, чтобы добраться до любого из свойств объекта напрямую, достаточно добавить к пути до объекта имя свойства, например получить имя пользователя /users/25/name . К свойству применимы методы GET (получение значения) и PUT/PATCH (изменение значения). Метод DELETE не применим, т.к. свойство является структурной частью объекта, как формализованной единицы данных.

В предыдущей части мы говорили о том, что у коллекций, как и у объектов, могут быть собственные свойства. На моей памяти мне пригодилось только свойство count, но ваше приложение может быть более сложным и специфичным. Пути к свойствам коллекций строятся по тому же принципу, что и к свойствам их элементов: /users/count . Для свойств коллекций применим только метод GET (получение свойства), т.к. коллекция – это только интерфейс для доступа к списку.

Коллекции связанных объектов

Одной из разновидностей свойств объектов могут быть связанные объекты или коллекции связанных объектов. Такие сущности, как правило, не являются собственным свойством объекта, а лишь отсылками к его связям с другими сущностями. Например, перечень ролей, которые были присвоены пользователю /users/25/roles . По поводу работы с вложенными объектами и коллекциями мы подробно поговорим в одной из следующих частей, а на данном этапе нам достаточно того, что мы имеем возможность обращаться к ним напрямую, как к любому другому свойству объекта.

Функции объектов и коллекций

Для построения пути к интерфейсу вызова функции у коллекции или объекта мы используем тот же самый подход, что и для обращения к свойству. Например, для объекта /users/25/sendPasswordReminder или коллекции /users/disableUnconfirmed. Для вызовов функций мы в любом случае используем метод POST. Почему? Напомню, что в классическом REST не существует специального глагола для вызова функций, а потому нам придется использовать один из существующих. На мой взгляд, для этого больше всего подходит метод POST т.к. он позволяет передавать на сервер необходимые аргументы, не является идемпотентным (возвращающим один и тот же результат при многократном обращении) и наиболее абстрактен по семантике.

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

Приближение третье: Запросы и ответы

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

Универсальный ответ

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

Success — маркер успешности выполнения запроса

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

POST /api/v1/articles/22/publish
{
    "success": true
}

Error — сведения об ошибке

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

GET /api/v1/user
{
    "success": false,
    "error": {
        "code" : 401,
        "message" : "Authorization failed"
    }
}

Data — данные, возвращаемые сервером

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

Пример возвращаемых данных в случае успеха. В данном случае ответ содержит запрашиваемый объект user.

GET /api/v1/user
{
    "success": true,
    "data": {
        "id" : 125,
        "email" : "[email protected]",
        "name" : "John",
        "surname" : "Smith",
    }
}

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

PUT /api/v1/user
{
    "success": false,
    "error": {
        "code" : 422,
        "message" : "Validation failed"
    }
    "data": {
        "email" : "Email could not be blank.",
    }
}

Pagination — сведения, необходимые для организации постраничной навигации

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

Минимальный набор значений для пагинации состоит из:

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

Некоторые разработчики web API также включают в пагинацию набор готовых ссылок на соседние страницы, а также первую, последнюю и текущую.

GET /api/v1/articles
Response:
{
    "success": true,
    "data": [
        {
            "id" : 1,
            "title" : "Interesting thing",
        },
        {
            "id" : 2,
            "title" : "Boring text",
        }
    ],
    "pagination": {
        "totalRecords" : 2,
        "totalPages" : 1,
        "currentPage" : 1,
        "perPage" : 20,
        "maxPerPage" : 100,
    }
}

Работа над ошибками

Как уже упоминалось выше, не все запросы к web API завершаются успехом, но это тоже часть игры. Система информирования об ошибках является мощным инструментом, облегчающим работу клиента и направляющим клиентское приложение по правильному пути. Слово «ошибка» в этом контексте не совсем уместно. Здесь больше подойдёт слово исключение, так как на самом деле запрос успешно получен, проанализирован, и на него возвращается адекватный ответ, объясняющий, почему запрос не может быть выполнен.

Каковы же потенциальные причины получаемых исключений?

500 Internal server error — всё сломалось, но мы скоро починим

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

400 Bad request — а теперь у вас всё сломалось

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

401 Unauthorized — незнакомец, назови себя

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

403 Forbidden — вам сюда нельзя

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

404 Not found — по этому адресу никто не живёт

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

405 Method not allowed — нельзя такое делать

Эта разновидность исключения напрямую связана с использованным при запросе глаголом (GET, PUT, POST, DELETE), который, в свою очередь, свидетельствует о действии, которое мы пытаемся совершить с ресурсом. Если запрошенный ресурс не поддерживает указанное действие, сервер говорит об этом прямо.

422 Unprocessable entity — исправьте и пришлите снова

Одно из самых полезных исключений. Возвращается каждый раз, когда в данных запроса существуют логические ошибки. Под данными запроса мы подразумеваем либо набор параметров и соответствующих им значений, переданных методом GET, либо поля объекта, передаваемого в теле запроса методами POST, PUT и DELETE. Если данные не прошли валидацию, сервер в секции «data» возвращает отчет о том, какие именно параметры невалидны и почему.

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

Запросы

Получение элементов коллекции

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

Постраничная навигация

page — параметр указывает на то, какая страница должна быть отображена. Если этот параметр не передан, то отображается первая страница. Из первого же успешного ответа сервера будет ясно, сколько страниц имеет коллекция при текущих параметрах фильтрации. Если значение превышает максимальное число страниц, то разумнее всего вернуть ошибку 404 Not found.

GET /api/v1/news?page=1

perPage — указывает на желаемое число элементов на странице. Как правило, API имеет собственное значение по умолчанию, которое возвращает в качестве поля perPage в секции pagination, но в ряде случаев позволяет увеличивать это значение до разумных пределов, предоставив максимальное значение maxPerPage:

GET /api/v1/news?perPage=100

Сортировка результатов

Зачастую результаты выборки требуется упорядочить по возрастанию или убыванию значений определенных полей, которые поддерживают сравнительную (для числовых полей) или алфавитную (для строковых полей) сортировку. Например, нам нужно упорядочить список пользователей по имени или товары по цене. Помимо этого мы можем задать направление сортировки от A до Я или в обратном направлении, причём разное для разных полей.

sortBy — существует несколько подходов к передаче данных о сложной сортировке в GET параметрах. Здесь необходимо четко указать порядок сортировки и направление.

В некоторых API это предлагается сделать в виде строки:

GET /api/v1/products?sortBy=name.desc,price.asc

В других вариантах предлагается использовать массив:

GET /api/v1/products?
sortBy[0][field]=name&
sortBy[0][direction]=desc&
sortBy[1][field]=price&
sortBy[1][direction]=asc

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

Простая фильтрация по значению

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

GET /api/v1/articles?authorId=25

Усложнённые варианты фильтрации

Многие интерфейсы требуют более сложной системы фильтрации и поиска. Перечислю основные и наиболее часто встречаемые варианты фильтрации.

Фильтрация по верхней и нижней границе с использованием операторов сравнения from (больше или равно), higher (больше), to (меньше или равно), lower (меньше). Применяется к полям, значения которых поддаются ранжированию.

GET /api/v1/products?price[from]=500&price[to]=1000

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

GET /api/v1/products?status[]=1&status[]=2

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

GET /api/v1/users?name[like]=John
GET /api/v1/products?code[like]=123

Именованные фильтры

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

GET /api/v1/products?filters[]=recommended

Именованные фильтры могут также иметь свои параметры.

GET /api/v1/products?filters[recommended]=kidds

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

За перевод материала выражаем благодарность международной IT-компании Noveo.

Клиент и сервер | Блог только про Java

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

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

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

То есть разработчикам клиентских программ необходим механизм, с помощью которого они могли бы делать обычные вызовы методов, не волнуясь ни о пересылке данных по сети, ни о выполнении синтаксического анализа ответных данных. Для них решением является установка на клиента так называемого прокси-объекта(proxy object). Прокси-объект это такой объект, который размещается на виртуальной машине клиента и выглядит для клиентской программы так, будто бы он является удаленным объектом. Клиент может вызывать этот прокси-объект путем выполнения обычного вызова метода, а тот затем уже связываться с сервером посредством сетевого протокола.

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

Каким образом прокси-объекты могут взаимодействовать друг с другом? Это зависит от применяемой для их реализации технологии. Наиболее распространенным являются три следующих варианта:

Технология Java RMI(Remote Method Invocation — удаленный вызов методов), которая позволяет обеспечивать вызов методов между распределенными объектами Java.
Технология CORBA(Common Object Request Broker Arhitecture — общая архитектура посредника запросов к объектам), которая позволяет обеспечивать вызов методов между объектами, написанными на любом языке программирования. Взаимодействие между объектами в этой технологии реализуется на основе протокола IIOP(Internet Inter-ORB Protocol).
Архитектура Web-служб, которая представляет собой целую коллекцию протоколов, часто в общем описываемых с помощью префикса WS-*. Она тоже подходит для объектов, написанных на любом языке программирования, однако для обеспечения взаимодействия между ними предусматривает применение форматов, основанных на XML. Форматом для передачи объектов является SOAP(Simple Object Access Protocol — простой протокол доступа к объектам).

В случае реализации рассчитанных или взаимодействие программ с помощью кода Java, в универсальности и сложности CORBA и WS-* нет абсолютно никакой необходимости. Такой простой механизм, как RMI, был специально разработан компанией Sun для обеспечения возможности взаимодействия между приложениями Java.

Познакомиться с технологией RMI стоит даже тем, кто и не планирует применять его в своих собственных программах. Это позволит изучить все важные для программирования распределенных приложений механизмы на примере довольно простой архитектуры. Более того, тем, кто пользуется Java-технологиями уровня предприятия, тоже будет очень полезно получить хотя бы общее представление о RMI, поскольку там именно этот протокол и применяется для обеспечения взаимодействия между been-компонентами уровня предприятия(Enterprise Java Beans — EJB).

EJB-компоненты — это применяемые на стороне сервера компоненты, которые создаются для образования сложных приложений, работающих на множестве серверов. Дабы эффективно использовать, потребуется хорошо разбираться в сопряженных с удаленными вызовами затратах.

В отличие от RMI, технология CORBA и WS-* не требуют использования никакого конкретного языка программирования. Они позволяются создавать клиентские и серверные программы на C, C++, Java и любом другом языке программирования. От разработчика ожидается предоставление описания интерфейса с указанием сигнатур методов и типов данных, которые его объекты способны обрабатывать. Это описание должно составляться на специальном языке, называемом IDL(Interface Definition Language — язык описания интерфейсов), если речь идет о CORBA, или WSDL(Web Services Description Language — язык описания Web-служб), если речь идет о WS-*.

На протяжении многих лет довольно много людей считали CORBA объектной моделью будущего. Однако сегодня, откровенно говоря, CORBA имеет репутацию(порой вполне заслуженной) архитектуры с низкой производительностью, сложной реализацией и проблемами взаимодействия, потому не пользуется особым успехом.

Web-службы тоже считались не менее перспективными, когда только появились, поскольку имели более простой вид и, конечно же, основывались на эффективных возможностях WWW и XML. Однако по прошествии времени после доработок многих комитетов стек протоколов Web-служб стал выглядеть гораздо сложнее и включать многие из тех же возможностей, которые уже давно присутствовал и CORBA.

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

Что такое клиент-серверная архитектура — особенности и недостатки

Сегодня практически 90% сервисов в Интернете работают, используя архитектуру клиент-сервер. Но при этом ещё не все понимают её смысл и принцип работы. Давайте это исправим! Что же такое клиент-серверная архитектура? Это это такая система организации сети, в которой выполняемые задачи условно делятся между двумя подсистемами: клиентом и сервером. Клиент — это объект, запрашивающий информацию по сети. В его роли выступает обычно персональный компьютер, ноутбук, планшет или смартфон. Сервер — это тоже компьютер (обычно очень мощный и высокопроизводительный компьютер или целый мэйнфрейм). Самый просто пример — Вы скачиваете какой-нибудь документ или музыкальную запись из Интернета. Ваш компьютер — клиент, а сайт, с которого Вы качаете информацию — это сервер.
При этом достаточно часто используются такие термины, как «upstream» и «downstream», обозначающие передачу данных от одного устройства к другому в разных направлениях. С точки зрения пользователя локальной сети или сети Интернет, «upstream» — это исходящий поток данных, который отправляется от его компьютера к удаленному, расположенному в другой точке сети. А «downstream» — это входящий поток, то есть информация передаётся уже в обратном направлении, от удаленного компьютера к пользователю.

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

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

Если рассматривать глобальную сеть — Интернет, то там различий нет, всё фактически то же самое. Вот схема:

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

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

Как и любая другая технология, клиент-серверная архитектура имеет свои преимущества и свои недостатки. Рассмотрим их.

Преимущества:

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

Недостатки:

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

Сеть клиент сервер это

«Клиент — сервер» (англ. client–server ) — вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг, называемыми серверами, и заказчиками услуг, называемыми клиентами. Фактически клиент и сервер — это программное обеспечение. Обычно эти программы расположены на разных вычислительных машинах и взаимодействуют между собой через вычислительную сеть посредством сетевых протоколов, но они могут быть расположены также и на одной машине. Программы-серверы ожидают от клиентских программ запросы и предоставляют им свои ресурсы в виде данных (например, загрузка файлов посредством HTTP, FTP, BitTorrent, потоковое мультимедиа или работа с базами данных) или в виде сервисных функций (например, работа с электронной почтой, общение посредством систем мгновенного обмена сообщениями или просмотр web-страниц во всемирной паутине). Поскольку одна программа-сервер может выполнять запросы от множества программ-клиентов, её размещают на специально выделенной вычислительной машине, настроенной особым образом, как правило, совместно с другими программами-серверами, поэтому производительность этой машины должна быть высокой. Из-за особой роли такой машины в сети, специфики её оборудования и программного обеспечения, её также называют сервером, а машины, выполняющие клиентские программы, соответственно, клиентами.

Содержание

Преимущества [ править | править код ]

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

Недостатки [ править | править код ]

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

Многоуровневая архитектура «клиент — сервер» [ править | править код ]

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

Частные случаи многоуровневой архитектуры:

Сеть с выделенным сервером [ править | править код ]

Сеть с выделенным сервером (англ. client/server network ) — это локальная вычислительная сеть (LAN), в которой сетевые устройства централизованы и управляются одним или несколькими серверами. Индивидуальные рабочие станции или клиенты (такие, как ПК) должны обращаться к ресурсам сети через сервер(а).

См. также [ править | править код ]

Литература [ править | править код ]

Валерий Коржов. Многоуровневые системы клиент-сервер (неопр.) . Издательство Открытые системы (17 июня 1997). Дата обращения 31 января 2010.

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

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 больше ничего и не делает, кроме как, гоняет строки и базы данных на экран и обратно в базу данных.

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

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

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

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

Wikimedia Foundation . 2010 .

Смотреть что такое «Клиент-сервер» в других словарях:

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

КЛИЕНТ-СЕРВЕР — КЛИЕНТ СЕРВЕР, тип взаимосвязи между компьютерами в КОМПЬЮТЕРНОЙ СЕТИ. Компьютер клиент делает запросы и отсылает их на выделенный ему компьютер сервер. Сервер выполняет задание и выдает клиенту результат … Научно-технический энциклопедический словарь

Клиент — сервер — (англ. Client server) сетевая архитектура, в которой устройства являются либо клиентами, либо серверами. Клиентом (front end) является запрашивающая машина (обычно ПК), сервером (back end) машина, которая отвечает на запрос. Оба термина (клиент и … Википедия

КЛИЕНТ-СЕРВЕР — Вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг (сервисов), называемыми серверами, и заказчиками услуг, называемыми клиентами. Нередко клиенты и серверы взаимодействуют через… … Словарь бизнес-терминов

клиент/сервер (связь между сетями уровней иерархической структуры) — Термин, относящийся к прозрачной транспортировке соединения тракта уровня клиента (то есть более высокого уровня) с сетевой трассой уровня сервера (то есть более низкого уровня) (МСЭ Т Y.1711). [http://www.iks media.ru/glossary/index.html?gloss >Справочник технического переводчика

Технология «клиент-сервер» — Клиент сервер (англ. Client server) вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг (сервисов), называемыми серверами, и заказчиками услуг, называемыми клиентами.… … Википедия

Технология «клиент-сервер» — Клиент сервер ( en. Client server) сетевая архитектура, в которой устройства являются либо клиентами, либо серверами. Клиентом (front end) является запрашивающая машина (обычно ПК), сервером (back end) машина, которая отвечает на запрос. Оба… … Википедия

архитектура клиент-сервер — Логическое продолжение концепции модульного программирования. Модуль клиент (программа), установленный на ПК пользователя, запрашивает сервис (например получение информации из базы данных) у модуля сервера (программы), расположенного на другом… … Справочник технического переводчика

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

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

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

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

Сравнение
Таблица

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

Клиент – компьютер, использующий ресурсы сервера и предоставляющий пользователю возможность взаимодействия с системой и сетью.

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

Сравнение

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

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

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

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

к содержанию ↑

Таблица

Клиент	Сервер
Отправляет запросы серверу по сети	Получает запросы, обрабатывает и возвращает результат клиенту
Установлено клиентское ПО	Установлено серверное ПО
Требования к аппаратным ресурсам системы минимальны	В зависимости от количества клиентов и сложности задач требует соответствующей производительности
Напрямую взаимодействует с пользователем	Не взаимодействует с пользователем, поэтому может не иметь периферийных устройств
Может включаться и отключаться произвольно	Работает всегда, пока есть необходимость обслуживания клиентов
Заранее известен способ обращения к серверу и его адрес	Получает сведения о клиенте из запроса

Терминология между клиентом и сервером | Баелдунг по информатике

1. Введение

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

2. Определения

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

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

3. Модель клиент-сервер

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

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

Давайте посмотрим на базовую топологию модели клиент-сервер на следующем рисунке:

Модель клиент-сервер стала одной из основных концепций сетевых вычислений, потому что сегодня так популярны компьютерные транзакции, в которых серверы выполняют запросы клиентов.В этой модели клиенты подключаются к серверам через локальную сеть (LAN) или глобальную сеть (WAN), например через Интернет.

Ссылка прерывается, когда сервер выполняет заказ клиента. Есть некоторые соединения, которые поддерживают связь между клиентом и сервером, например WebSocket.

3.1. Клиент-серверные протоколы

Набор протоколов TCP / IP обычно используется для связи клиентов с серверами. TCP — это протокол с установлением соединения. Указывает, что он устанавливает и поддерживает связь до тех пор, пока клиентские программы на обоих концах не закончат обмен сообщениями.

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

TCP включает большую часть уровня 4, транспортного уровня, и часть уровня 5, уровня сеанса в модели взаимодействия открытых систем (OSI).

Для сравнения, IP — это протокол без установления соединения , который гарантирует отсутствие непрерывной связи между конечными точками.Каждый пакет, который проходит через Интернет, считается отдельной единицей данных. Он не имеет отношения к какой-либо другой единице данных. IP находится на уровне 3, сетевом уровне модели взаимодействия открытых систем (OSI).

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

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

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

4. Заключение

В этой статье мы кратко описали терминологию клиентов и серверов. Существуют также некоторые другие вычислительные модели, такие как главный-подчиненный и одноранговая (P2P).

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

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

Авторы Внизу

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

Проектирование системы

— связь клиент-сервер | Ларри | Пэн Ян | Основы информатики

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

Связь клиент-сервер
Протоколы API

Большая часть обмена данными в Интернете происходит через HTTP. Есть два режима передачи данных между клиентом и сервером. HTTP PUSH и HTTP PULL .Для каждого ответа сначала должен быть запрос. Клиент отправляет запрос, а сервер отвечает данными. Это режим связи HTTP по умолчанию, называемый механизмом HTTP PULL. В HTTP PUSH клиент отправляет запрос конкретной информации на сервер только в первый раз, а после этого сервер продолжает отправлять новые обновления клиенту всякий раз, когда они доступны. В механизме HTTP Push задействовано несколько технологий, таких как:

Ajax Long polling
Веб-сокеты
Источник события HTML5 (событие, отправленное сервером)
Очереди сообщений
Потоковая передача по HTTP

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

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

1.1 Ajax Polling

Polling — это стандартный метод, используемый подавляющим большинством приложений AJAX . Клиент неоднократно опрашивает (или запрашивает) у сервера данные и ждет, пока сервер ответит данными. Если данные недоступны, возвращается пустой ответ.

Клиент открывает соединение и запрашивает данные с сервера , используя обычный HTTP .
Запрошенная веб-страница отправляет запросы на сервер с регулярными интервалами (например, 0,5 секунды).
Сервер вычисляет ответ и отправляет его обратно , как обычный HTTP-трафик.
Клиент периодически повторяет три вышеуказанных шага для получения обновлений с сервера.

Проблемы:

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

1.2 HTTP Long-Polling

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

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

1.3 WebSockets

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

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

Определить, следует ли использовать WebSockets для текущей работы, просто:

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

Примеры использования:

Социальные каналы
Совместное редактирование / кодирование: с помощью WebSockets мы можем работать с одним и тем же документом и пропустить все слияния.
Приложения для чата
Приложения для отслеживания
Взаимодействие с аудиторией в реальном времени
Обновления устройств Интернета вещей

1.4 Событие, отправленное сервером (SSE)

Это технология, которая позволяет браузеру (клиенту) получать автоматические обновления, такие как текстовые данные о событиях с сервера через HTTP-соединение. Клиент устанавливает постоянное и долгосрочное соединение с сервером. Сервер использует это соединение для отправки данных клиенту. Если клиент хочет отправить данные на сервер, это потребует использования другой технологии / протокола.

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

Пример использования:

Когда требуется трафик в реальном времени от сервера к клиенту.
Когда сервер генерирует данные в цикле и отправляет несколько событий клиенту.
Обновления Facebook / Twitter, обновление статусов, push-уведомления, информационные бюллетени и новостная лента, обновления цен на акции, спортивные результаты и т. Д.

В последние годы появилось много типов протоколов API, таких как RPC и GraphQL.

6 протоколов API

2.1 SOAP

SOAP — это старейший веб-ориентированный протокол API, который до сих пор широко используется. Это пример удаленного процедурного вызова или RPC. SOAP — это простой протокол доступа к объектам. Чтобы сделать запросы, потребуется немало усилий. Для выполнения вызовов необходимо создавать XML-документы, а форматирование XML, требуемое для SOAP, не совсем интуитивно понятно. Это не только затрудняет реализацию вызова, но также затрудняет отладку проблем, поскольку для отладки требуется анализ длинных строк сложных данных.

С другой стороны, SOAP полагается на стандартные протоколы, особенно HTTP и SMTP. Это означает, что вы можете использовать SOAP практически в любой среде, поскольку эти протоколы доступны во всех операционных системах.

2.2. REST

REST, сокращение от «Репрезентативная передача состояния», представляет собой протокол API, который был представлен в диссертации 2000 года Роем Филдингом, целью которого было устранение некоторых недостатков SOAP.

Как и SOAP, REST полагается на стандартный транспортный протокол HTTP для обмена информацией между различными приложениями или службами.Однако REST более гибкий, поскольку он поддерживает различные форматы данных, а не требует XML. JSON, который, возможно, легче читать и писать, чем XML, — это формат, который многие разработчики используют для REST API. API-интерфейсы REST также могут предложить лучшую производительность, чем SOAP, поскольку они могут кэшировать информацию .

2.3 JSON-RPC

Хотя REST поддерживает структуры данных RPC, это не единственный протокол API в этой категории. Если вам нравится JSON, вы можете вместо этого использовать JSON-RPC, протокол, представленный в середине 2000-х годов.

По сравнению с REST и SOAP, JSON-RPC имеет относительно узкую область применения. Он поддерживает небольшой набор команд и не предлагает такой гибкости, как протокол, подобный REST, в отношении того, как именно вы его реализуете. Однако, если вам нравится простота и у вас есть простой вариант использования, который соответствует области действия JSON-RPC, это может быть лучшим решением, чем REST.

JSON-RPC можно использовать в HTTP и WebSocket.

Пример запроса и ответа JSON-RPC:

 // запрос 
 curl -d "{\" jsonrpc \ ": \" 2.0 \ ", \" id \ ": 2, \" method \ ": \" subtract \ ", \" params \ ": {\" subtrahend \ ": 23.4, \" minuend \ ": 42.8},}» --header "Content-Type: application / json" http: // myserver: 8080 / openroad / jsonrpcservertest // response 
 {"result": 19.400, "id": 2, "jsonrpc": "2.0"}

2.4 gRPC

gRPC — это API с открытым исходным кодом, который также относится к категории RPC. В отличие от SOAP, gRPC намного новее, он был публично выпущен Google в 2015 году. Как и REST и SOAP, gRPC использует HTTP в качестве транспортного уровня.Однако, в отличие от этих других протоколов API, gRPC позволяет разработчикам определять любые типы вызовов функций , которые они хотят, вместо того, чтобы выбирать из предопределенных параметров (например, GET и PUT в случае REST).

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

Способность gRPC упростить сложные удаленные вызовы помогла сделать его популярным в контексте создания API-интерфейсов для микросервисов или приложений на основе Docker , которые влекут за собой огромное количество удаленных вызовов.

2.5 GraphQL

В некотором смысле GraphQL для Facebook — это то же самое, что gRPC для Google: это протокол API, который был разработан внутри Facebook в 2013 году. Он официально определен как язык запросов, а также представляет собой попытку преодолеть некоторые из ограничения или неэффективность REST.

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

2.6 Apache Thrift

Как и GraphQL, Apache Thrift родился в Facebook и функционирует, по сути, как среда RPC. Однако цели проектирования и целевые варианты использования Thrift значительно отличаются от GraphQL.

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

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

2.7 SOAP vs REST

2.8 Webhooks (это не API)

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

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

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

От сервера к клиенту — отдельные списки

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

Продолжение статьи ниже

Инициирование запроса # section2

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

Проверить HSTS # section3

Во-первых, браузеру необходимо определить, указывает ли URL-адрес схему HTTP (небезопасную).Если это HTTP-запрос, браузеру необходимо проверить, находится ли домен в списке HSTS (HTTP Strict Transport Security). Этот список состоит как из предварительно загруженного списка, так и из списка ранее посещенных сайтов, которые выбрали использование HSTS; оба хранятся в браузере. Если запрошенный узел HTTP находится в списке HSTS, выполняется запрос к HTTPS-версии URL-адреса вместо HTTP. Вот почему вы заметите, что даже если вы попытаетесь ввести http://www.bing.com в современный браузер, он отправит вас на https: // www.bing.com вместо этого.

Проверка обслуживающего персонала № section4

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

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

В случае, когда нет сервис-воркера для обработки начального запроса (или если используется предварительная загрузка навигации), браузер переходит к просмотру сетевого уровня.

Проверьте сетевой кеш # section5

Браузер через сетевой уровень проверяет, есть ли свежий ответ в его кеше. Обычно это определяется заголовком Cache-Control в ответе, где установка max-age может определять, как долго кэшированный элемент считается свежим, а установка no-store указывает, следует ли вообще кэшировать .И, конечно же, если браузер ничего не находит в своем сетевом кеше, тогда потребуется сетевой запрос. Если в кеше есть свежий ответ, он возвращается для загрузки страницы. Если ресурс найден, но он не свежий, браузер может преобразовать запрос в запрос условной повторной проверки, который содержит заголовок If-Modified-Since или If-None-Match , который сообщает серверу, какая версия содержимого у браузера уже есть в кеше.Сервер может либо сообщить браузеру, что его копия все еще свежая, вернув HTTP 304 (не изменено) без тела, либо сообщить браузеру, что его копия устарела, вернув ответ HTTP 200 (OK) с новая версия ресурса.

Проверить соединение # section6

Если есть ранее установленное соединение для хоста и порт для запроса, соединение будет использоваться повторно, а не устанавливать новое. В противном случае браузер обращается к сетевому уровню, чтобы понять, нужно ли ему выполнять поиск в DNS (системе доменных имен).Это будет включать просмотр локального кэша DNS (который хранится на вашем устройстве), и, в зависимости от свежести этого кеша, можно также обращаться к удаленным серверам имен (они могут быть размещены поставщиками услуг Интернета), что в конечном итоге приведет к в правильном IP-адресе, к которому браузер должен подключиться.

В некоторых случаях браузер может предсказать, к каким доменам будет осуществляться доступ, и могут быть настроены соединения с этими доменами. Страница может подсказывать браузеру, к какому подключению нужно подключаться, используя подсказки ресурсов, такие как rel = "preconnect" в теге ссылки.Один из таких сценариев, когда использование подсказок ресурсов полезно, — это когда пользователь находится на странице результатов поиска Bing и ожидается, что первые несколько результатов поиска будут посещены с наибольшей вероятностью. В этом случае предварительные подключения к этим доменам могут помочь избавиться от необходимости оплачивать поиск в DNS и настройку подключения позже при нажатии на эти ссылки.

Установить соединение # section7

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

Отправить запрос на сервер # section8

Первый запрос, который пройдет через это соединение, — это запрос страницы верхнего уровня. Обычно это HTML-файл, который передается с сервера обратно клиенту.

Обработать ответ # section9

Когда данные передаются клиенту, данные ответа анализируются. Сначала браузер проверяет заголовки ответа.Заголовки HTTP — это пары имя-значение, которые отправляются как часть ответа HTTP. Если заголовки ответа указывают на перенаправление (например, через заголовок Location), браузер снова запускает процесс навигации и возвращается к самому первому шагу проверки, требуется ли обновление HSTS.

Если ответ сервера сжат или разбит на части, браузер попытается распаковать и разбить его на части.

По мере чтения ответа браузер также начнет параллельную запись его в сетевой кеш.

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

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

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

Щелкните, чтобы увидеть полноразмерное изображение

Как вы знаете, страница будет продолжать делать запросы, потому что на странице есть много подресурсов, которые важны для общего взаимодействия, включая изображения, JavaScript и таблицы стилей.Кроме того, ресурсы, на которые есть ссылки в этих подресурсах, такие как фоновые изображения (указанные в CSS) или другие ресурсы, инициированные вызовами fetch () , import () или AJAX . Без них у нас была бы просто обычная страница без особого взаимодействия. Как вы видели в объяснении ранее и на блок-схеме, каждый запрашиваемый ресурс частично зависит от политик кэширования браузера.

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

Конечно, у сетевого кэша есть квота, которая влияет как на количество элементов, которые будут храниться, так и на то, как долго они будут храниться.Это не означает, что веб-сайт не имеет права голоса в этом вопросе. Заголовки Cache-Control в ответах управляют логикой кеширования браузера. В некоторых случаях разумно указать браузеру вообще не кэшировать элемент (например, с Cache-Control: no-store ), потому что ожидается, что он всегда будет другим. В других случаях имеет смысл, чтобы браузер кэшировал элемент на неопределенный срок с помощью Cache-Control: immutable , потому что ответ для данного URL никогда не изменится. В таком случае имеет смысл использовать разные URL-адреса для указания на разные версии одного и того же ресурса, а не вносить изменения в ресурс с одним и тем же URL-адресом, поскольку всегда будет использоваться кэшированная версия.

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

Источник — это просто кортеж, состоящий из схемы / протокола, имени хоста и порта. Например, https://www.bing.com:443 имеет протокол HTTPS, имя хоста www.bing.com и порт 443. Если какие-либо из них отличаются по сравнению с другим происхождением, они считаются другим происхождением. Например, https: // images.bing.com:443 и http://www.bing.com:80 имеют разное происхождение.

Источник — важное понятие для браузера, поскольку оно определяет, как данные изолированы и защищены. В большинстве случаев в целях безопасности браузер применяет политику одного и того же происхождения, что означает, что один источник не может получить доступ к данным другого источника — оба должны быть одного источника. В частности, в случае кеширования, представленном ранее, ни https://images.bing.com:443, ни http://www.bing.com:80 не могут видеть программный кеш другого.

Если bing.com хочет загрузить файл JavaScript с сайта microsoft.com, он будет делать запрос ресурсов из разных источников, при котором браузер будет применять политику того же происхождения. Чтобы разрешить такое поведение, microsoft.com должен сотрудничать с bing.com, указав заголовки CORS (Cross-Origin Resource Sharing), которые позволяют bing.com загружать файл JavaScript с microsoft.com. Рекомендуется установить правильные заголовки CORS, чтобы браузеры могли надлежащим образом обрабатывать запросы ресурсов из разных источников.

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

Какова основная функция системы клиент-сервер? | Small Business

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

Основы

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

Аппаратное обеспечение

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

Операционные системы

Хотя операционная система Microsoft Windows в настоящее время занимает наибольшую долю рынка среди операционных систем для настольных ПК, это не единственная операционная система на рынке. Когда ваше программное обеспечение делит свою работу между централизованным сервером и отдельными программными клиентами, вы можете продавать свое программное обеспечение для Windows, OS X и даже Linux, только переписав программный клиент. Саму серверную систему вам нужно запрограммировать только один раз, а затем просто запрограммировать различные версии вашего программного обеспечения-клиента для взаимодействия с единой версией вашего серверного программного обеспечения.

Реализации

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

Ссылки

Биография писателя

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

Базовый клиент / сервер

Далее: Сообщения
Up: Текущие распределенные архитектуры
Предыдущая: Текущие распределенные архитектуры

См. Рис. 3 на стр.

**Рисунок 3:**
Базовый клиент / сервер

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

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

Логика в приложении может находиться либо на клиенте, либо на сервере, но традиционно логика приложения находится на клиенте, что делает клиента « толстым ».

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

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

Обмен сообщениями
Удаленный вызов процедур (PRC)

Рональд Лерой Бурбэк

1998-12-16

Клиент-серверные вычисления

МОДЕЛЬ ВЫЧИСЛЕНИЯ КЛИЕНТ / СЕРВЕР

Это описанные клиент-серверные вычисления.

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

Ответственность клиента обычно заключается в следующем:

Обрабатывать пользовательский интерфейс.
Перевести запрос пользователя в желаемый протокол.
Отправить запрос на сервер.
Дождитесь ответа сервера.
Преобразуйте ответ в «удобочитаемые» результаты.
Представить результаты пользователю.

В функции сервера входят:

Слушайте запрос клиента.
Обработать этот запрос.
Вернуть результаты клиенту.

Типичное взаимодействие клиент / сервер выглядит следующим образом:

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

Типичное взаимодействие клиент / сервер

Это взаимодействие клиент / сервер очень похоже на посещение французского ресторана.В ресторане вам (пользователю) официант (клиент) предлагает меню выбора. Сделав ваш выбор, официант принимает к сведению ваш выбор, переводит его на французский и представляет французскому шеф-повару (официанту) на кухне. После того, как повар приготовит вам еду, официант возвращается с вашей закусочной (результаты). Надеюсь, официант вернется с выбранными вами предметами, но не всегда; иногда что-то «теряется в переводе».

Гибкая разработка пользовательского интерфейса — наиболее очевидное преимущество клиент-серверных вычислений.Можно создать интерфейс, не зависящий от сервера, на котором размещены данные. Следовательно, пользовательский интерфейс клиент-серверного приложения может быть написан на Macintosh, а сервер может быть написан на мэйнфрейме. Клиенты также могут быть написаны для компьютеров на базе DOS или UNIX. Это позволяет хранить информацию на центральном сервере и распространять на различные типы удаленных компьютеров. Поскольку за пользовательский интерфейс отвечает клиент, у сервера есть больше вычислительных ресурсов, которые можно потратить на анализ запросов и распространение информации.Это еще одно важное преимущество клиент-серверных вычислений; он стремится использовать сильные стороны различных вычислительных платформ для создания более мощных приложений. Хотя его вычислительные возможности и возможности хранения ничтожны по сравнению с мэйнфреймом, нет причин, по которым Macintosh нельзя было бы использовать в качестве сервера для менее требовательных приложений.

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

Docker Client VS Server | dockerlabs

Каждое приложение / продукт, которое мы используем, прямо или косвенно следует архитектуре клиент-сервер.Возьмем, к примеру, facebook, twitter, gmail и т. Д., Все эти приложения основаны на архитектуре клиент-сервер.

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

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

Вернуться к оглавлению

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

Вернуться к оглавлению

Теперь мы понимаем, что означает клиент и сервер в вычислениях. Давайте углубимся в то, что такое Docker Client и Docker Server.

Изображение предоставлено: https: // www.xenonstack.com/blog/docker-application-solutions/

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

Для связи с демоном докера для выполнения определенной задачи, такой как запуск contaienr, сборка какого-либо образа выполняется через клиент докера.Вы, наверное, уже догадались, Docker CLI. Наряду с Docker CLI демон Docker также предоставляет REST API, который можно использовать для программного доступа к службам, предоставляемым демоном.

Подмножество клиента и сервера докера.

Изображение предоставлено: https://docs.docker.com/engine/docker-overview/

Примечание:

Целью этого руководства было понять архитектуру клиент-сервер докера. Есть несколько других тем, которые нужно осветить, например, что такое Docker Registry?
Эти темы, среди некоторых других продвинутых, будут объяснены в будущих руководствах, продолжайте следить.Удачного Докеризации!

Перейти к индексу для начинающих