Взаимодействие клиента и сервера: О модели взаимодействия клиент-сервер простыми словами. Архитектура «клиент-сервер» с примерами
Содержание
О модели взаимодействия клиент-сервер простыми словами. Архитектура «клиент-сервер» с примерами
Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем рубрику Сервера и протоколы. В этой записи мы поговорим о том, как работают приложения и сайты в сети Интернет, да и вообще в любой компьютерной сети. В основе работы приложения лежит так называемая модель взаимодействия клиент-сервер, которая позволяет разделять функционал и вычислительную нагрузку между клиентскими приложениями (заказчиками услуг) и серверными приложениями (поставщиками услуг).
Модель взаимодействия клиент-сервер. Архитектура «клиент-сервер».
Итак, небольшая аннотация к записи: сначала мы разберемся с концепцией взаимодействия клиент сервер. Затем поговорим о том зачем вообще веб-мастеру нужно понимать модель клиент-сервер. Далее мы посмотрим на архитектуру приложений, которые работают по принципу клиент-сервер и в завершении рассмотрим преимущества и недостатки данной модели.
Концепция взаимодействия клиент-сервер
Содержание статьи:
Миллионы людей каждый день выходят в сеть Интернет, чтобы почитать новости, пообщаться с друзьями, получить полезную информацию, совершить покупку или оплатить счет. Но большая часть рядовых пользователей даже не догадывается о том, как и с помощью чего они всё это делают, да на самом деле большинству людей это и не нужно, главное, чтобы они получали услугу вовремя и качественно.
Здесь мы разберемся с концепцией, которая позволяет нам выполнять все эти действия в сети Интернет. Данная концепция получила название «клиент-сервер». Как понятно из названия, в данной концепции участвуют две стороны: клиент и сервер. Здесь всё как в жизни: клиент – это заказчик той или иной услуги, а сервер – поставщик услуг. Клиент и сервер физически представляют собой программы, например, типичным клиентом является браузер. В качестве сервера можно привести следующие примеры: все HTTP сервера (в частности Apache), MySQL сервер, локальный веб-сервер AMPPS или готовая сборка Denwer (последних два примера – это не проста сервера, а целый набор серверов).
Клиент и сервер взаимодействую друг с другом в сети Интернет или в любой другой компьютерной сети при помощи различных сетевых протоколов, например, IP протокол, HTTP протокол, FTP и другие. Протоколов на самом деле очень много и каждый протокол позволяет оказывать ту или иную услугу. Например, при помощи HTTP протокола браузер отправляет специальное HTTP сообщение, в котором указано какую информацию и в каком виде он хочет получить от сервера, сервер, получив такое сообщение, отсылает браузеру в ответ похожее по структуре сообщение (или несколько сообщений), в котором содержится нужная информация, обычно это HTML документ.
Сообщения, которые посылают клиенты получили названия HTTP запросы. Запросы имеют специальные методы, которые говорят серверу о том, как обрабатывать сообщение. А сообщения, которые посылает сервер получили название HTTP ответы, они содержат помимо полезной информации еще и специальные коды состояния, которые позволяют браузеру узнать то, как сервер понял его запрос.
Сейчас мы схематично описали, как взаимодействуют клиент и сервер на седьмом уровне модели OSI, но, на самом деле это взаимодействие происходит на всех семи уровнях. Когда клиент отправляет запрос, сообщение упаковывается, можно представить, что сообщение заворачивается в семь оберток (хотя их может быть намного больше или же меньше), а когда сообщение получает сервер, он начинает эти обертки разворачивать.
Также стоит заметить, что в основе взаимодействия клиент-сервер лежит принцип того, что такое взаимодействие начинает клиент, сервер лишь отвечает клиенту и сообщает о том может ли он предоставить услугу клиенту и если может, то на каких условиях. Клиентское программное обеспечение и серверное программное обеспечение обычно установлено на разных машинах, но также они могут работать и на одном компьютере.
Данная концепция взаимодействия была разработана в первую очередь для того, чтобы разделить нагрузку между участниками процесса обмена информацией, а также для того, чтобы разделить программный код поставщика и заказчика. Ниже вы можете увидеть упрощенную схему взаимодействия клиент-сервер.
Простая схема взаимодействия клиент-сервер
Мы видим, что к одному серверу может обращаться сразу несколько клиентов (действительно, на одном сайте может находиться несколько посетителей). Также стоит заметить, что количество клиентов, которые могут одновременно взаимодействовать с сервером зависит от мощности сервера и от того, что хочет получить клиент от сервера.
Многие сетевые протоколы построены на архитектуре клиент-сервер, поэтому в их основе обычно лежат одинаковые или схожие принципы взаимодействия, а разницу мы видим лишь в деталях, которые обусловлены особенностями и спецификой области, для которой разрабатывался тот или иной сетевой протокол.
Почему веб-мастеру нужно понимать модель взаимодействия клиент-сервер
Давайте теперь ответим на вопрос: «зачем веб-мастеру или веб-разработчику понимать концепцию взаимодействия клиент-сервер?». Ответ, естественно, очевиден. Чтобы что-то делать своими руками нужно понимать, как это работает. Чтобы сделать сайт и, чтобы он правильно работал в сети Интернет или хотя бы просто работал, нам нужно понимать, как работает сеть Интернет.
Мы уже упоминали, что большая часть сетевых протоколов имеют архитектуру клиент-сервер. Например, веб-мастеру или веб-разработчику будут интересны протоколы седьмого и шестого уровня эталонной модели. Сетевым администраторам важно понимать, как происходит взаимодействие на уровнях с пятого по второй. Для инженеров связи наибольший интерес представляют протоколы с четвертого по первый уровень модели OSI.
Поэтому если вы действительно хотите быть профессионалом в сфере web, то сперва вам необходимо понимать, как происходит взаимодействии в сети (именно на седьмом уровне), а уже потом начинать изучать инструменты, которые позволят создавать сайты.
Архитектура «клиент-сервер»
Архитектура клиент-сервер определяет лишь общие принципы взаимодействия между компьютерами, детали взаимодействия определяют различные протоколы. Данная концепция нам говорит, что нужно разделять машины в сети на клиентские, которым всегда что-то надо и на серверные, которые дают то, что надо. При этом взаимодействие всегда начинает клиент, а правила, по которым происходит взаимодействие описывает протокол.
Существует два вида архитектуры взаимодействия клиент-сервер: первый получил название двухзвенная архитектура клиент-серверного взаимодействия, второй – многоуровневая архитектура клиент-сервер (иногда его называют трехуровневая архитектура или трехзвенная архитектура, но это частный случай).
Принцип работы двухуровневой архитектуры взаимодействия клиент-сервер заключается в том, что обработка запроса происходит на одной машине без использования сторонних ресурсов. Двухзвенная архитектура предъявляет жесткие требования к производительности сервера, но в тоже время является очень надежной. Двухуровневую модель взаимодействия клиент-сервер вы можете увидеть на рисунке ниже.
Двухуровневая модель взаимодействия клиент-сервер
Здесь четко видно, что есть клиент (1-ый уровень), который позволяет человеку сделать запрос, и есть сервер, который обрабатывает запрос клиента.
Если говорить про многоуровневую архитектуру взаимодействия клиент-сервер, то в качестве примера можно привести любую современную СУБД (за исключением, наверное, библиотеки SQLite, которая в принципе не использует концепцию клиент-сервер). Суть многоуровневой архитектуры заключается в том, что запрос клиента обрабатывается сразу несколькими серверами. Такой подход позволяет значительно снизить нагрузку на сервер из-за того, что происходит распределение операций, но в то же самое время данный подход не такой надежный, как двухзвенная архитектура. На рисунке ниже вы можете увидеть пример многоуровневой архитектуры клиент-сервер.
Многоуровневая архитектура взаимодействия клиент-сервер
Типичный пример трехуровневой модели клиент-сервер. Если говорить в контексте систем управления базами данных, то первый уровень – это клиент, который позволяет нам писать различные SQL запросы к базе данных. Второй уровень – это движок СУБД, который интерпретирует запросы и реализует взаимодействие между клиентом и файловой системой, а третий уровень – это хранилище данных.
Если мы посмотрим на данную архитектуру с позиции сайта. То первый уровень можно считать браузером, с помощью которого посетитель заходит на сайт, второй уровень – это связка Apache + PHP, а третий уровень – это база данных. Если уж говорить совсем просто, то PHP больше ничего и не делает, кроме как, гоняет строки и базы данных на экран и обратно в базу данных.
Преимущества и недостатки архитектуры клиент-сервер
Преимуществом модели взаимодействия клиент-сервер является то, что программный код клиентского приложения и серверного разделен. Если мы говорим про локальные компьютерные сети, то к преимуществам архитектуры клиент-сервер можно отнести пониженные требования к машинам клиентов, так как большая часть вычислительных операций будет производиться на сервере, а также архитектура клиент-сервер довольно гибкая и позволяет администратору сделать локальную сеть более защищенной.
К недостаткам модели взаимодействия клиент-сервер можно отнести то, что стоимость серверного оборудования значительно выше клиентского. Сервер должен обслуживать специально обученный и подготовленный человек. Если в локальной сети ложится сервер, то и клиенты не смогут работать (в качестве частного случая можно привести пример: мощности сервера не всегда хватает, чтобы удовлетворит запросы клиентов, если вы хоть раз работали с биллинговыми системами, то понимаете о чем я: время ожидания ответа от сервера может быть очень большим).
В качестве заключения нам стоит явно акцентировать внимание на том, что архитектура клиент-сервер не делит машины на только клиент или только сервер, а скорее позволяет распределить нагрузку и разделить функционал между клиентской частью и серверной.
Клиент-сервер — Изучение веб-разработки | 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
запросы добавляют новые ресурсы, данные которых зашифрованы в теле самого запроса.- Куки-файлы клиентской части. Куки-файлы содержат данные сессий о клиенте, включая ключи, которые сервер может использовать для определения статуса его авторизации и разрешения/права доступа к ресурсам.
- URL-параметры:
Веб-серверы ожидают сообщений с запросами от клиентов, обрабатывают их, когда они приходят и отвечают веб-браузеру через сообщение с 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
.
Очевидно, что веб-фреймворки могут помочь вам в решении многих других задач. В следующей статье мы обсудим намного больше преимуществ и некоторые популярные варианты веб-фреймворков.
На этом этапе вы должны хорошо ознакомиться с операциями, которые должен выполнять серверный код, и знать некоторые способы, с помощью которых веб-фреймворк на стороне сервера может сделать это проще.
В следующем модуле мы поможем вам выбрать лучший веб-фреймворк для вашего первого сайта.
Что такое взаимодействие Клиент-Сервер? | Info-Comp.ru
Сегодня речь пойдет о так называемом взаимодействии Клиент-Сервер, так как практически все программное обеспечение построено на данном принципе. А как Вы помните, что у нас сайт для начинающих программистов и понимание данного взаимодействия обязательно для новичка в программирование. Поэтому в данном материале мы рассмотрим, что это такое и для чего это нужно.
Как я уже сказал, если Вы хотите стать программистом то Вы должны понимать принцип данного взаимодействия, потому что хотите Вы или нет, Вам придется столкнуться с этим, так как это встречается практически везде, например все сайты в Интернете построены на этом, все программы которые используют базу данных, сюда также можно и отнести и автоматическое обновление программ, и многое другое.
Теперь поговорим подробней. Что такое взаимодействие Клиент-сервер? Это взаимодействие двух программных продуктов между собой, один из которых выступает в качестве сервера, а другой соответственно в качестве клиента. Клиент посылает запрос, а сервер отвечает ему. А что такое клиент и что такое сервер? Спросите Вы. Клиент это программная оболочка, с которой взаимодействует пользователь. А сервер это та часть программного обеспечения, которая выполняет все основные функции (хранит данные, выполняет расчеты). Другими словами, пользователь видит программу, которая, допустим, работает с какими-то данными, которые хранятся в базе данных, тем самым он видит всего лишь интерфейс этой программы, а все самое основное выполняет сервер, и процесс когда пользователь оперирует данными через интерфейс программы, при котором клиентская часть взаимодействует с серверной, и называется Клиент-Сервер. В качестве клиента не обязательно должен выступать интерфейс, который видит пользователь, в некоторых случаях в качестве клиента может выступать и просто программа или скрипт, например, данные на сайте хранятся в базе данных, соответственно скрипты, которые будут обращаться к базе данных и будут являться клиентом в данном случае, хотя и сами эти скрипты являются сервером для клиентской часть сайта (интерфейса).
А для чего это нужно?
Это лучше объяснить на примере.
Допустим, Вы написали программу, которая умеет работать с некими данными и установили ее пользователю, все замечательно работает, пока другой пользователь не скажет, а я хочу такую же программу, но чтобы данные у нас были одни, и при редактировании одним пользователем другой мог увидеть это изменение. И для этого Вам необходимо сделать какую-то базу данных доступ, к которой можно получить через интерфейс Вашей программы, причем данная база должна располагаться на отдельном сервере, для того чтобы все пользователи могли получить к ней доступ, конечно, которым Вы разрешите.
И тем самым всем пользователям, которым нужна эта программа, Вы устанавливаете только клиентскую часть и настраиваете взаимодействие с сервером. В данном случае подразумевается, что Вы на сервере установите СУБД (Система управления базами данных).
Где под клиентом понимается клиентская часть приложения, которая взаимодействует с серверной частью приложения по средствам сети.
Другой пример.
Все сайты в Интернете располагаются где-то на серверах (хостинге), а Вы соответственно хотите получить доступ к ним и для этого используете браузер и в данном случае браузер и есть клиент, а файлы на хостинге сервер. Если разбирать отдельно взятый сайт, то здесь также присутствует данное взаимодействие, к примеру, в браузере Вы видите всего лишь интерфейс приложения и при любых Ваших действиях на этом сайте данный интерфейс будет отправлять запрос серверу который выполнит все что Вы запросили и пришлет ответ, а клиент в свою очередь отобразит этот ответ, для того чтобы пользователь смог увидеть его.
Другими словами принцип клиент-сервер основан на том, что клиент отправляет запрос серверу, а сервер отвечает ему. И данные запрос-ответы могут выглядеть по-разному, могут использоваться разные протоколы, такие как tcp/ip, http, rdp и много других.
Теперь надеюсь, стало понятно, что такое Клиент-сервер, теперь давайте немного поговорим о том, как лучше реализовывать данное взаимодействие.
Как уже говорилось выше, если Вы захотели хранить данные в базе данных то лучше всего использовать СУБД, такие как MSSql, MySQL, Oracle, PostgreSQL так как данные СУБД предоставляют огромные возможности для серверной разработки. Так как, когда Вы будете разрабатывать программное обеспечение по такому принципу, Вам лучше всего четко разграничить клиент и сервер, т.е. клиент выполняет только роль интерфейса, из которого можно будет посылать запросы серверу на запуск процедур или функций, а соответственно сервер будет выполнять эти процедуры и функции и посылать результат их выполнения клиенту, предварительно, конечно же, Вы должны будете написать эти самые процедуры и функции, что и позволяют делать данные СУБД. Этим Вы упростите разработку и увеличите производительность Вашего программного обеспечения. Поэтому запомните клиент, во всех случаях, при взаимодействии Клиент-Сервер должен выполнять только лишь функцию интерфейса, и не нужно на него возлагать какие-то там другие задачи (обработка данных и другое), все, что можно перенести на сервер переносите, а пользователю предоставьте всего лишь интерфейс.
В связи с этим пришло время поговорить о преимуществах данной технологии:
- Низкие требования к компьютерам клиента, так как вся нагрузка должна возлагаться на сервер и серверную часть приложения, в некоторых случаях можно значительно сэкономить затраты на приобретение вычислительной техники в организациях;
- Многопользовательский режим. Ресурсами сервера могут пользоваться неограниченное число пользователей, при том что данные располагаются в одном месте;
- Целостность данных. Вывести из строя компьютер клиента гораздо проще, и чаще встречается, чем компьютер, который выполняет роль сервера. Как Вы знаете, проблемы с компьютерами у пользователей встречаются достаточно часто, так как они сами их себе и создают.
- Внесение изменений. Проще внести изменения один раз в серверной части, чем вносить их на каждом клиенте.
Есть также пару недостатков:
- Для быстродействия требуется приобрести достаточно мощный сервер, но как было уже сказано выше, это может и окупится, за счет компьютеров пользователей;
- Выход из строя серверной части прекратит работу всех клиентов, в связи с этим возникает необходимость постоянного мониторинга серверной части.
Перед тем как заняться разработкой приложения Вы должны знать, на чем Вы это будете реализовывать, так как существуют разные технологии и языки, например, при взаимодействии с СУБД Вам придется изучить SQL, хотя бы основы SQL, но лучше, если Вы будете знать, как написать функцию или процедуру, так как без этого Вам не обойтись, ну если конечно не разделить обязанности между программистами, например, один специалист разрабатывает серверную часть, а другой клиентскую, так, кстати, все и делают, потому что сами понимаете, что все знать просто невозможно.
Или на примере сайта в Интернете, существуют как серверные языки программирования, например PHP так и клиентские, например JavaScript, поэтому, если Вы решили сами создать нормальный сайт в Интернете, то учтите, что Вам придется с этим столкнуться и проще говоря, Вы должны будете стать Web-мастером который должен знать ой как много:).
Подведем итог.
Как Вы уже поняли, что взаимодействие Клиент-Сервер используется практически везде, и можно сказать, сеть построена, для того чтобы пользователь, по средствам программного обеспечения, мог взаимодействовать с другими пользователями или удаленными ресурсами, так как все что Вы запрашиваете или отправляете по сети основано на взаимодействие запрос-ответ. Поэтому начинающий программист должен понимать данное взаимодействие и в последствие реализовывать его.
Нравится2Не нравится
Клиенты и серверы | CiscoTips
В современных сетях при взаимодействии между конечными устройствами, как правило используются две модели:
- Клиент-серверное взаимодействие (client-server)
- Одноранговое взаимодействие (peer-to-peer)
Клиент-серверное взаимодействие
Любое конечное устройство может выступать в роли клиента или сервера. Сервер предоставляет некоторые сервисы или ресурсы клиенту. Клиент, соответственно обращается к серверу, получает некоторые ресурсы и пользуется ими.
Важно понимать, что отличие между клиентом и сервером в том, какое программное обеспечение установлено на них и как оно настроено. Например, если взять домашний компьютер и поставить на него приложение веб-сервер Apache, то можно сказать, что компьютер выступает в роли сервера. Если взять большой сервер IBM, поставить на него MS Windows и пользоваться веб-браузером, то можно сказать, что это оборудование используется как клиентская машина. Таким образом, разница между клиентом и сервером находится на уровне приложений модели OSI, с точки зрения нижестоящих уровней этой модели, разницы между ними нет.
На одном хосте может быть запущено несколько серверов. В небольших организациях часто практикуется один физический сервер, на котором работают одновременно, например, веб-сервер, почтовый сервер, файловый сервер и другие. К каждому из этих серверов могут подключаться свои клиенты.
Одноранговое взаимодействие
В этой модели устройства в сети равны: каждый выступает как в роли клиента, так и в роли сервера. Простейший пример – сеть MS Windows без домена. Несколько компьютеров обмениваются данными через открытые для общего доступа папки. Каждый получает и отдаёт файлы, выступая то как клиент, то как сервер.
Преимуществом одноранговой модели являются:
- Простота настройки.
- Меньшая стоимость внедрения (не требуется дорогостоящее оборудование для сервера).
- Может с успехом использоваться для простых задач вроде обмена файлами или сетевой печати.
Недостатки одноранговой модели в сравнении с клиент-серверной:
- Отсутствие возможности централизованного администрирования и управления сетью, так как все настройки применяются на каждом хосте отдельно.
- В связи с предыдущим пунктом, проблемы с безопасностью.
- Возможные проблемы с производительностью из-за того, что постороннее клиентское ПО может занимать ресурсы системы.
- В связи с предыдущими тремя пунктами, проблемы с масштабируемостью сети.
В организациях одноранговую сеть имеет смысл использовать только при небольшом (до десяти) количестве компьютеров и отсутствии специальных требований к централизованному администрированию и обеспечению безопасности.
Основные понятия и особенности клиент-серверной архитектуры — TestMatick
Термин «клиент-серверная архитектура» – сборное понятие, состоящее из двух взаимодополняющих компонентов: сервера и, собственно, клиента.
Клиент – локальный компьютер на стороне виртуального пользователя, который выполняет отправку запроса к серверу для возможности предоставления данных или выполнения определенной группы системных действий.
Сервер – очень мощный компьютер или специальное системное оборудование, которое предназначается для разрешения определенного круга задач по процессу выполнения программных кодов. Он выполняет работы сервисного обслуживания по клиентским запросам, предоставляет пользователям доступ к определенным системным ресурсам, сохраняет данные или БД.
Особенности такой модели заключаются в том, что пользователь отправляет определенный запрос на сервер, где тот системно обрабатывается и конечный результат отсылается клиенту. В возможности сервера входит одновременное обслуживание сразу нескольких клиентов.
Если одновременно поступает более одного запроса, то такие запросы устанавливаются в определенную очередь и сервером выполняются по очереди. Порой запросы могут иметь свои собственные приоритеты. Часть запросов с более высокими приоритетами будут постоянно выполняться в первоочередном порядке!
Параметры, которые могут реализоваться на стороне сервера:
- Хранение, защита и доступ к данным;
- Работа с поступающими клиентскими запросами;
- Процесс отправки ответа клиенту.
Параметры, которые могут реализоваться на стороне клиента:
- Площадка по предоставлению пользовательского графического интерфейса;
- Формулировка запроса к серверу и его последующая отправка;
- Получение итогов запроса и отправка дополнительной группы команд (запросы на добавление, обновление информации, удаление группы данных).
Архитектура системы клиент-сервер формулирует принципы виртуального общения между локальными компьютерами, а все правила и принципы взаимодействия находятся внутри протокола.
Сетевой протокол – это особый набор правил, на основании которого выполняется точное взаимодействие между компьютерами внутри виртуальной сети.
Виды сетевых протоколов
TCP/IP – совокупность протоколов передачи информации. TCP/IP – это особое обозначение всей сети, которая функционирует на основе протоколов TCP, а также IP.
TCP – вид протокола, который является связующим звеном для установки качественного соединения между 2 устройствами, передачи данных и верификации их получения.
IP – протокол, в функции которого входит корректность доставки сообщений по выбранному адресу. При этом информация делится на пакеты, которые могут поставляться по-разному.
MAC – вид протокола, на основании которого происходит процесс верификации сетевых устройств. Все устройства, которые подключены к сети Интернет, содержат свой оригинальный MAC-адрес.
ICMP – протокол, который ответственен за обмен данными, но не используется для процесса передачи информации.
UDP – протокол, управляющий передачей данных, но данные не проходят верификацию при получении. Этот протокол функционирует быстрее, чем протокол TCP.
HTTP – протокол для передачи информации (гипертекста), на базе которого функционируют все сегодняшние сайты. В его возможности входит процесс запрашивания необходимых данных у виртуально удаленной системы (файлы, веб-страницы и прочее).
FTP – протокол передачи информации из особого файлового сервера на ПК конечного пользователя.
POP3 – классический протокол простого почтового соединения, который ответственен за передачу почты.
SMTP – вид протокола, который может устанавливать правила для передачи виртуальной почты. Он ответственен за передачу и верификацию доставки, а также оповещения о возможных ошибках.
Концепции постройки клиент-серверной системы
Слабый клиент – производительный сервер.
При такой модели весь процесс обработки информации перенесен на мощности сервера, а у пользователя права доступа очень строго ограничены. Сервер начинает отправлять ответ, который вообще не требует дополнительной работы по обработке. Клиент взаимодействует с пользователем: создает и отправляет запрос, принимает входящие итоги и выводит данные на экран пользователя.
Сильный клиент.
Концепция, при которой часть обработки данных предоставляет клиенту. В такой ситуации сервер является простым хранилищем информации, а вся деятельность по обработке и предоставлению данных переносится на ПК пользователя.
Продукт или система, которая говорит о том, что часть обрабатывающей информации предоставляется пользователю.
При такой ситуации сервер выступает особым хранилищем информации, а вся деятельность по обработке и предоставлению данных может переноситься на ПК пользователя.
Есть сразу 2 вида клиент-серверных архитектур:
1. Двухуровневая, состоящая сразу из 2 узлов:
- сервер, который ответственен за получение входящих запросов и отправку ответа пользователю, применяя при этом собственные ресурсы системы;
- клиент, который может предоставлять пользовательский графический интерфейс.
Особенности работы заключаются в том, что на сервер приходит определенный запрос, потом его обрабатывают и дают напрямую, без дополнительного применения группы внешних ресурсов.
2. Трехуровневая система состоит из использования таких компонентов:
- предоставление информации – графический пользовательский, прикладной объект в виде сервера приложения;
- менеджмент ресурсов – сервер БД, который может предоставлять данные.
Особенность работы состоит в том, что сразу несколько серверов могут обрабатывать клиентские запросы. Процесс распределения операций может существенным образом снизить нагрузку на используемый сервер.
Трехуровневая архитектура может трансформироваться до многоуровневой, возможностью установки группы дополнительных серверов. Подобная виртуальная архитектура позволяет существенным образом повысить эффективность функционирования информационных систем, а также выполнить оптимизированное распределение части ее программно-аппаратных ресурсов.
Итоги
Нюансы взаимодействия системы клиент-сервер позволяют пользователям разделять определенный функционал и вычислительную нагрузку между подключенными клиентскими веб-продуктами и серверными приложениями при разнообразных процессах тестирования (от тестирования БД до замеров общей производительности системы).
Понимание программистами и тестировщиками внутренней архитектуры приложения позволяют им более качественно не только создавать продукт, но и тестировать его, выполняя полноценные проверки от кросбраузерного соответствия до регрессионных тестов.
Как описать взаимодействие между веб-сервером и веб-клиентом?
1. Установление соединения
Наиболее распространенный способ взаимодействия веб-серверов и клиентов-это соединение , которое следует протоколу управления передачей, или TCP . В принципе, при использовании TCP соединение устанавливается между клиентскими и серверными машинами с помощью серии проверок back-and-forth. Как только соединение установлено и открыто, данные могут быть отправлены между клиентом и сервером. Это соединение также можно назвать сеансом .
Существует также UDP , или протокол пользовательских дейтаграмм , который имеет несколько иной способ общения и имеет свой собственный набор плюсов и минусов. Я полагаю, что в последнее время некоторые браузеры, возможно, начали использовать комбинацию этих двух методов, чтобы получить наилучшие результаты.
Здесь можно сказать гораздо больше, но если вы не собираетесь писать браузер (или стать хакером), это не должно касаться вас слишком сильно за пределами основ.
2. Отправка Пакетов
Как только соединение клиент-сервер установлено, пакеты данных могут быть отправлены между ними. TCP пакеты содержат различные биты информации, чтобы помочь в связи между двумя портами. Для веб-программистов наиболее важной частью пакета будет раздел, включающий запрос HTTP .
HTTP, протокол передачи гипертекста — это еще один протокол, который описывает, каким должен быть состав/формат этих клиент-серверных коммуникаций.
Наиболее простой пример соответствующей части пакета, отправленного от клиента к серверу, выглядит следующим образом:
GET /index.html HTTP/1.1
Host: www.example.com
Первая строка здесь называется Response line
. GET
описывает используемый метод (другие включают POST, HEAD, PUT, DELETE и т. д.) /index.html
описывает запрашиваемый ресурс. Наконец, HTTP/1.11
описывает используемый протокол.
Вторая строка в этом случае является единственным header field
в запросе, и в этом случае это поле HOST
, которое является своего рода псевдонимом для адреса IP сервера, заданного DNS.
[Поскольку вы упомянули об этом, разница между запросом GET
и запросом POST
заключается просто в том , что в запросе GET
параметры (например, данные формы) включены как часть Response Line
, тогда как в запросе POST
параметры будут включены как часть Message Body
(см. ниже).]
3. Прием Пакетов
В зависимости от запроса, отправленного на сервер, сервер почешет голову, подумает о том, что вы его спросили, и ответит соответственно (то есть все, что вы запрограммируете).
Вот пример ответного пакета, отправленного с сервера:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
...
<html>
<head>
<title>A response from a server</title>
</head>
<body>
<h2>Hello World!</h2>
</body>
</html>
Первая строка здесь- Status Line
, которая включает в себя числовой код вместе с кратким текстовым описанием. 200 OK
очевидно означает успех. Большинство людей, вероятно, также знакомы с 404 Not Found
, например.
Вторая строка — это первая из Response Header Fields
. Другие часто добавляемые поля включают date
, Content-Length
и другие полезные метаданные.
Под заголовками и необходимой пустой строкой, наконец, находится (необязательно) Message Body
. Конечно, это обычно самая захватывающая часть ответа, поскольку она будет содержать такие вещи, как HTML для отображения нашими браузерами, JSON данных или почти все, что вы можете закодировать в операторе return
.
4. AJAX, асинхронные JavaScript и XML
Исходя из всего этого, AJAX довольно просто понять. Фактически, отправленные и полученные пакеты могут выглядеть идентично non-ajax
запросам.
Единственная разница заключается в том, как и когда браузер решает отправить пакет запроса. Обычно после обновления страницы браузер отправляет запрос на сервер. Однако при выдаче запроса AJAX программист просто говорит браузеру отправить пакет на сервер NOW, а не на обновление страницы.
Однако, учитывая характер запросов AJAX, обычно Message Body
не будет содержать весь документ HTML, а будет запрашивать меньшие, более конкретные биты данных, такие как запрос из базы данных.
Затем ваш JavaScript, который вызывает Ajax, также может действовать на основе ответа. Любой метод JavaScript доступен, так как вызов Ajax-это просто еще одна функция JavaScript. Таким образом, вы можете делать такие вещи, как innerHTML, чтобы добавить/заменить контент на Вашей странице некоторым HTML, возвращенным вызовом Ajax. В качестве альтернативы, однако, вы также можете сделать что-то вроде вызова Ajax, который просто должен возвращать True или False, а затем вы можете вызвать некоторую функцию JavaScript с помощью оператора if else. Как вы, надеюсь, видите, Ajax не имеет ничего общего с HTML, скажем, это просто функция JavaScript, которая делает запрос с сервера и возвращает ответ, каким бы он ни был.
5. Печенье
Протокол HTTP является примером протокола без состояния . В основном это означает, что каждая пара Request
и Response
(как мы описали) обрабатывается независимо от других запросов и ответов. Таким образом, сервер не должен следить за всеми тысячами пользователей, которые в данный момент требуют внимания. Вместо этого он может просто отвечать на каждый запрос индивидуально.
Однако иногда нам хочется, чтобы сервер запомнил нас. Как было бы досадно, если бы каждый раз, когда я хотел проверить свой Gmail, мне приходилось снова входить в систему, потому что сервер забывал обо мне?
Чтобы решить эту проблему, сервер может отправлять файлы cookie для хранения на компьютере клиента. Сервер может отправить ответ, который говорит клиенту хранить файл cookie и что именно он должен содержать. Браузер клиента отвечает за хранение этих файлов cookie в системе клиента, поэтому расположение этих файлов cookie будет варьироваться в зависимости от Вашего браузера и OS. Однако важно понимать, что это всего лишь небольшие файлы, хранящиеся на клиентской машине, которые на самом деле читаются и записываются любым, кто знает, как их найти и понять. Как вы можете себе представить, это создает несколько различных потенциальных угроз безопасности. Одним из решений является шифрование данных, хранящихся внутри этих файлов cookie, чтобы злоумышленник не смог воспользоваться предоставленной вами информацией. (Поскольку ваш браузер устанавливает эти файлы cookie, обычно в вашем браузере есть настройка, которую вы можете изменить, чтобы либо принять, либо отклонить, либо, возможно, установить новое местоположение для файлов cookie.
Таким образом, когда клиент делает запрос с сервера, он может включить файл Cookie в один из Request Header Fields
, который сообщит серверу: «Эй, я аутентифицированный пользователь, меня зовут Боб, и я как раз писал чрезвычайно увлекательный пост в блоге, прежде чем мой ноутбук умер», или: «у меня есть 3 дизайнерских костюма, выбранных в моем shopping cart, но я все еще планирую поискать ваш сайт завтра для 4-го», например.
6. Локальное Хранилище
HTML5 представила локальное хранилище как более безопасную альтернативу файлам cookie. В отличие от файлов cookie, при локальном хранении данные фактически не отправляются на сервер. Вместо этого браузер сам отслеживает состояние.
Эта альтернатива также позволяет хранить гораздо большие объемы данных, поскольку нет необходимости передавать их через Интернет между клиентом и сервером.
7. Продолжайте Исследования
Это должно охватывать основы и давать довольно ясную картину того, что происходит между клиентами и серверами. По каждому из этих пунктов можно сказать больше, и вы можете найти много информации с помощью простого поиска в Google.
как правильно проектировать и разрабатывать 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.
Обзор клиент-сервер
— Изучите веб-разработку
Теперь, когда вы знаете цель и потенциальные преимущества серверного программирования, мы собираемся подробно изучить, что происходит, когда сервер получает «динамический запрос» от браузера. Поскольку большая часть серверного кода веб-сайтов обрабатывает запросы и ответы аналогичным образом, это поможет вам понять, что вам нужно делать при написании большей части собственного кода.
Предварительные требования: | Базовая компьютерная грамотность.Базовое понимание того, что такое веб-сервер. |
---|---|
Цель: | Для понимания взаимодействия клиент-сервер на динамическом веб-сайте и, в частности, какие операции должны выполняться серверным кодом. |
В обсуждении нет настоящего кода, потому что мы еще не выбрали веб-фреймворк для написания нашего кода! Однако это обсуждение все еще очень актуально, потому что описанное поведение должно быть реализовано вашим серверным кодом, независимо от того, какой язык программирования или веб-фреймворк вы выберете.
Веб-браузеры взаимодействуют с веб-серверами с помощью протокола передачи P (HTTP) T ext T . Когда вы щелкаете ссылку на веб-странице, отправляете форму или запускаете поиск, браузер отправляет на сервер HTTP-запрос .
Этот запрос включает:
- URL-адрес, идентифицирующий целевой сервер и ресурс (например, HTML-файл, конкретную точку данных на сервере или инструмент для запуска).
- Метод, определяющий необходимое действие (например, получение файла или сохранение или обновление некоторых данных).Различные методы / глаголы и связанные с ними действия перечислены ниже:
-
GET
: получить определенный ресурс (например, HTML-файл, содержащий информацию о продукте, или список продуктов). -
POST
: Создайте новый ресурс (например, добавьте новую статью в вики, добавьте новый контакт в базу данных). -
HEAD
: получить информацию метаданных о конкретном ресурсе, не получая тела, как это сделал быGET
. Например, вы можете использовать запросHEAD
, чтобы узнать время последнего обновления ресурса, а затем использовать (более «дорогой») запросGET
для загрузки ресурса, если он изменился. -
PUT
: обновить существующий ресурс (или создать новый, если он не существует). -
УДАЛИТЬ
: удалить указанный ресурс. -
TRACE
,ОПЦИИ
,CONNECT
,PATCH
: Эти глаголы предназначены для менее распространенных / сложных задач, поэтому мы не будем их здесь рассматривать.
-
- В запросе может быть закодирована дополнительная информация (например, данные HTML-формы). Информация может быть закодирована как:
- Параметры URL:
GET
запросы кодируют данные в URL, отправленном на сервер, путем добавления пар имя / значение в его конец — например,http: // mysite.com ? name = Fred & age = 11
. У вас всегда есть вопросительный знак (?
), отделяющий остальную часть URL от параметров URL, знак равенства (=
), отделяющий каждое имя от связанного с ним значения, и амперсанд (и
), разделяющий каждую пару. Параметры URL-адреса по своей сути «небезопасны», поскольку они могут быть изменены пользователями, а затем отправлены повторно. В результате параметры URL /GET
запросов не используются для запросов, обновляющих данные на сервере. -
Данные POST
.POST
запросы добавляют новые ресурсы, данные для которых закодированы в теле запроса. - Клиентские файлы cookie. Файлы cookie содержат данные сеанса о клиенте, включая ключи, которые сервер может использовать для определения статуса входа в систему и разрешений / доступа к ресурсам.
- Параметры URL:
Веб-серверы ожидают сообщений с запросами клиентов, обрабатывают их, когда они приходят, и отвечают веб-браузеру с помощью сообщения HTTP-ответа.Ответ содержит код состояния HTTP-ответа, указывающий, был ли запрос выполнен успешно (например, « 200 OK
» для успеха, « 404 Not Found
», если ресурс не может быть найден, « 403 Forbidden,
», если пользователь не не авторизован для просмотра ресурса и т. д.). Тело успешного ответа на запрос GET
будет содержать запрошенный ресурс.
Когда возвращается HTML-страница, она отображается в веб-браузере. В рамках обработки браузер может обнаруживать ссылки на другие ресурсы (например,грамм. HTML-страница обычно ссылается на страницы JavaScript и CSS) и отправляет отдельные HTTP-запросы для загрузки этих файлов.
Как статические, так и динамические веб-сайты (обсуждаемые в следующих разделах) используют один и тот же протокол / шаблоны связи.
Пример запроса / ответа GET
Вы можете сделать простой запрос GET
, щелкнув ссылку или выполнив поиск на сайте (например, на домашней странице поисковой системы). Например, HTTP-запрос, который отправляется, когда вы выполняете поиск в MDN для термина «обзор клиентского сервера», будет очень похож на текст, показанный ниже (он не будет идентичным, потому что части сообщения зависят от вашего браузера / настроек. ).
Формат сообщений HTTP определен в «веб-стандарте» (RFC7230). Вам не нужно знать этот уровень детализации, но, по крайней мере, теперь вы знаете, откуда все это взялось!
Заявка
Каждая строка запроса содержит информацию о нем. Первая часть называется заголовком и содержит полезную информацию о запросе, точно так же, как заголовок HTML содержит полезную информацию о документе HTML (но не сам фактическое содержимое, которое находится в теле):
ПОЛУЧИТЬ https: // разработчик.mozilla.org/en-US/search?q=client+server+overview&topic=apps&topic=html&topic=css&topic=js&topic=api&topic=webdev HTTP / 1.1
Хост: developer.mozilla.org
Подключение: keep-alive
Прагма: без кеширования
Cache-Control: без кеширования
Небезопасные запросы на обновление: 1
Пользовательский агент: Mozilla / 5.0 (Windows NT 10.0; WOW64) AppleWebKit / 537.36 (KHTML, как Gecko) Chrome / 52.0.2743.116 Safari / 537.36
Принять: text / html, application / xhtml + xml, application / xml; q = 0.9, image / webp, * / *; q = 0.8
Реферал: https: // разработчик.mozilla.org/en-US/
Принятие кодировки: gzip, deflate, sdch, br
Accept-Charset: ISO-8859-1, UTF-8; q = 0,7, *; q = 0,7
Accept-Language: en-US, en; q = 0,8, es; q = 0,6
Cookie: sessionid = 6ynxs23n521lu21b1t136rhbv7ezngie; csrftoken = zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT; dwf_section_edit = Ложь; dwf_sg_task_completion = Ложь; _gat = 1; _ga = GA1.2.1688886003.14713; ffo = истина
Первая и вторая строки содержат большую часть информации, о которой мы говорили выше:
- Тип запроса (
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
).
Последняя строка содержит информацию о файлах cookie на стороне клиента — в этом случае файл cookie включает идентификатор для управления сеансами ( 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-запросы также могут иметь тело, но в данном случае оно пустое.
Ответ
Первая часть ответа на этот запрос показана ниже. Заголовок содержит следующую информацию:
- Первая строка включает код ответа
200 OK
, который сообщает нам, что запрос выполнен успешно. - Мы видим, что ответ имеет формат
текст / html
(Content-Type
). - Мы также можем видеть, что он использует набор символов UTF-8 (
Content-Type: text / html; charset = utf-8
). - Голова также сообщает нам, насколько она велика (
Content-Length: 41823
).
В конце сообщения мы видим содержимое тела , которое содержит фактический HTML, возвращенный запросом.
HTTP / 1.1 200 ОК
Сервер: Apache
X-Backend-Server: разработчик1.webapp.scl3.mozilla.com
Варьируются: Принять, Cookie, Принять-кодирование
Тип содержимого: текст / html; charset = utf-8
Дата: среда, 7 сентября 2016 г., 00:11:31 GMT
Keep-Alive: тайм-аут = 5, максимум = 999
Подключение: Keep-Alive
Параметры X-Frame: ОТКАЗАТЬ
Разрешить: ПОЛУЧИТЬ
X-Cache-Info: кеширование
Длина содержимого: 41823
<сценарий> (функция (d) {d.className = d.className.replace (/ \ bno-js /, ''); }) (document.documentElement);
...
Остальная часть заголовка ответа включает информацию об ответе (например, когда он был сгенерирован), сервере и о том, как он ожидает, что браузер будет обрабатывать страницу (например, строка X-Frame-Options: DENY
сообщает браузеру, что чтобы разрешить встраивание этой страницы в
на другом сайте).
Пример запроса / ответа POST
HTTP POST
создается, когда вы отправляете форму, содержащую информацию для сохранения на сервере.
Заявка
Текст ниже показывает HTTP-запрос, сделанный, когда пользователь отправляет новые данные профиля на этом сайте. Формат запроса почти такой же, как в примере запроса GET
, показанном ранее, хотя первая строка идентифицирует этот запрос как POST .
POST https://developer.mozilla.org/en-US/profiles/hamishwillee/edit HTTP / 1.1
Хост: developer.mozilla.org
Подключение: keep-alive
Длина содержимого: 432
Прагма: без кеширования
Cache-Control: без кеширования
Источник: https: // разработчик.mozilla.org
Небезопасные запросы на обновление: 1
Пользовательский агент: Mozilla / 5.0 (Windows NT 10.0; WOW64) AppleWebKit / 537.36 (KHTML, как Gecko) Chrome / 52.0.2743.116 Safari / 537.36
Тип содержимого: application / x-www-form-urlencoded
Принять: text / html, application / xhtml + xml, application / xml; q = 0.9, image / webp, * / *; q = 0.8
Референт: https://developer.mozilla.org/en-US/profiles/hamishwillee/edit
Принятие кодировки: 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 = Ложь; dwf_sg_task_completion = Ложь; _ga = GA1.2.1688886003.14713; ffo = истина
csrfmiddlewaretoken = zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT & user-username = hamishwillee & user-fullname = Hamish + Willee & user-title = & user-organization = & user-location = Австралия & user-locale = en-US & user-timezone = Australia & user-locale = en-US & user-timezone = ir-timezone = Australia-user-timezone = ir-timezone = ir-us twitter_url = & user-stackoverflow_url = & user-linkedin_url = & user-mozillians_url = & user-facebook_url =
Основное отличие в том, что URL не имеет параметров.Как видите, информация из формы закодирована в теле запроса (например, новое полное имя пользователя задается с помощью: & user-fullname = Hamish + Willee
).
Ответ
Ответ на запрос показан ниже. Код состояния « 302 Найдено
» сообщает браузеру, что публикация прошла успешно и что он должен отправить второй HTTP-запрос для загрузки страницы, указанной в поле Location
. В остальном информация аналогична информации для ответа на запрос GET
.
HTTP / 1.1 302 НАЙДЕНО
Сервер: Apache
X-Backend-сервер: developer3.webapp.scl3.mozilla.com
Vary: Cookie
Vary: Accept-Encoding
Тип содержимого: текст / html; charset = utf-8
Дата: среда, 7 сентября 2016 г., 00:38:13 GMT
Расположение: https://developer.mozilla.org/en-US/profiles/hamishwillee
Keep-Alive: тайм-аут = 5, максимум = 1000
Подключение: Keep-Alive
Параметры X-Frame: ОТКАЗАТЬ
X-Cache-Info: не кэшируется; запрос не был GET или HEAD
Content-Length: 0
Примечание : HTTP-ответы и запросы, показанные в этих примерах, были захвачены с помощью приложения Fiddler, но вы можете получить аналогичную информацию с помощью веб-снифферов (например.грамм. Websniffer) или расширений браузера, таких как HttpFox. Вы можете попробовать это сами. Используйте любой из связанных инструментов, а затем перемещайтесь по сайту и редактируйте информацию профиля, чтобы увидеть различные запросы и ответы. В большинстве современных браузеров также есть инструменты, которые отслеживают сетевые запросы (например, инструмент Network Monitor в Firefox).
Статический сайт - это сайт, который возвращает одно и то же жестко закодированное содержимое с сервера всякий раз, когда запрашивается конкретный ресурс. Так, например, если у вас есть страница о продукте по адресу / static / myproduct1.html
, эта же страница будет возвращена каждому пользователю. Если вы добавите на свой сайт еще один аналогичный продукт, вам потребуется добавить еще одну страницу (например, myproduct2.html
) и так далее. Это может стать действительно неэффективным - что произойдет, когда вы попадете на тысячи страниц продукта? Вы должны повторять много кода на каждой странице (базовый шаблон страницы, структура и т. Д.), И если вы хотите изменить что-либо в структуре страницы - например, добавить новый раздел «сопутствующие товары» - тогда вы должны придется менять каждую страницу индивидуально.
Примечание : Статические сайты отлично подходят, когда у вас небольшое количество страниц и вы хотите отправить одно и то же содержимое каждому пользователю. Однако их обслуживание может потребовать значительных затрат по мере увеличения количества страниц.
Давайте вспомним, как это работает, еще раз посмотрев на диаграмму статической архитектуры сайта, которую мы рассматривали в прошлой статье.
Когда пользователь хочет перейти на страницу, браузер отправляет запрос HTTP GET
с указанием URL-адреса его HTML-страницы.Сервер извлекает запрошенный документ из своей файловой системы и возвращает HTTP-ответ, содержащий документ и код состояния HTTP-ответа « 200 OK
» (указывающий на успех). Сервер может вернуть другой код состояния, например « 404 Not Found
», если файл отсутствует на сервере, или « 301 Moved Permanently
», если файл существует, но был перенаправлен в другое место.
Серверу статического сайта нужно будет только обрабатывать запросы GET, потому что сервер не хранит никаких изменяемых данных.Он также не меняет свои ответы на основе данных HTTP-запроса (например, параметров URL или файлов cookie).
Понимание того, как работают статические сайты, тем не менее полезно при изучении серверного программирования, потому что динамические сайты обрабатывают запросы статических файлов (CSS, JavaScript, статические изображения и т. Д.) Точно так же.
Динамический сайт - это сайт, который может генерировать и возвращать контент на основе определенного URL-адреса запроса и данных (вместо того, чтобы всегда возвращать один и тот же жестко закодированный файл для определенного URL-адреса).Используя пример сайта продукта, сервер будет хранить «данные» продукта в базе данных, а не в отдельных файлах HTML. При получении HTTP GET
Request для продукта сервер определяет идентификатор продукта, извлекает данные из базы данных, а затем создает HTML-страницу для ответа, вставляя данные в HTML-шаблон. У этого есть основные преимущества перед статическим сайтом:
Использование базы данных позволяет эффективно хранить информацию о продукте в легко расширяемом, изменяемом и доступном для поиска виде.
Использование шаблонов HTML позволяет очень легко изменить структуру HTML, потому что это нужно делать только в одном месте, в одном шаблоне, а не на потенциально тысячах статических страниц.
Анатомия динамического запроса
В этом разделе представлен пошаговый обзор «динамического» цикла HTTP-запроса и ответа, основанный на том, что мы рассмотрели в предыдущей статье, с гораздо более подробной информацией. Чтобы «сохранить реальность», мы будем использовать контекст веб-сайта менеджера спортивной команды, где тренер может выбрать название своей команды и размер команды в HTML-форме и получить обратно предлагаемый «лучший состав» для своей следующей игры.
На схеме ниже показаны основные элементы веб-сайта «тренера команды», а также пронумерованные метки для последовательности операций, когда тренер обращается к списку «лучших команд». Части сайта, которые делают его динамическим, - это веб-приложение (так мы будем ссылаться на код на стороне сервера, который обрабатывает HTTP-запросы и возвращает HTTP-ответы), база данных , которая содержит информацию об игроках, командах. , тренеры и их отношения, а также шаблоны HTML .
После того, как тренер отправит форму с названием команды и количеством игроков, последовательность операций будет:
- Веб-браузер создает запрос HTTP
GET
к серверу, используя базовый URL-адрес ресурса (/ лучший
) и кодируя команду и номер игрока либо как параметры 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-адрес, используемый для доставки определенной функции в одном месте, без необходимости изменять функцию обработчика.
Например, рассмотрим следующий код Django (Python), который отображает два шаблона URL-адресов на две функции просмотра. Первый шаблон гарантирует, что HTTP-запрос с URL ресурса / лучший
будет передан функции с именем index ()
в модуле views
. Запрос с шаблоном « / лучший / младший
» вместо этого будет передан в функцию просмотра junior ()
.
из django.conf.urls импортировать url из . импорт просмотров urlpatterns = [ url (r '^ $', просмотры.junior / $ '
), потому что они используют метод сопоставления с образцом, называемый «регулярными выражениями» (RegEx или RE). Вам не нужно знать, как работают регулярные выражения на этом этапе, кроме того, что они позволяют нам сопоставлять шаблоны в URL-адресе (а не жестко закодированные значения выше) и использовать их в качестве параметров в наших функциях просмотра. Например, очень простое регулярное выражение может сказать «соответствует одной заглавной букве, за которой следует от 4 до 7 строчных букв».Веб-фреймворк также упрощает функцию просмотра для извлечения информации из базы данных.Структура наших данных определяется в моделях, которые представляют собой классы Python, определяющие поля, которые будут храниться в базовой базе данных. Если у нас есть модель с именем Team с полем « team_type », то мы можем использовать простой синтаксис запроса, чтобы вернуть все команды, которые имеют определенный тип.
В приведенном ниже примере показан список всех команд, которые имеют точный (с учетом регистра)
team_type
«junior» - обратите внимание на формат: имя поля (team_type
), за которым следует двойное подчеркивание, а затем тип соответствия для использования. (в данном случаеточное
).Есть много других типов спичек, и мы можем соединить их в цепочку. Мы также можем контролировать порядок и количество возвращаемых результатов.из django.shortcuts import render из команды импорта .models def junior (запрос): list_teams = Team.objects.filter (team_type__exact = "младший") context = {'список': list_teams} возврат рендера (запрос, 'лучший / index.html', контекст)
После того, как функция
junior ()
получает список младших команд, она вызывает функциюrender ()
, передавая исходныйHttpRequest
, шаблон HTML и объект «context», определяющий информацию, которая должна быть включена в шаблон.Функцияrender ()
- это удобная функция, которая генерирует HTML с использованием контекста и шаблона HTML и возвращает его в объектеHttpResponse
.Очевидно, что веб-фреймворки могут помочь вам с множеством других задач. В следующей статье мы обсудим гораздо больше преимуществ и некоторые популярные варианты веб-фреймворков.
На этом этапе у вас должен быть хороший обзор операций, которые должен выполнять серверный код, и некоторые способы, с помощью которых серверная веб-инфраструктура может упростить эту задачу.
В следующем модуле мы поможем вам выбрать лучшую веб-платформу для вашего первого сайта.
Что такое клиент-сервер? Определение и часто задаваемые вопросы
Определение клиент-сервер
Клиент-сервер обозначает отношения между взаимодействующими программами в приложении, состоящими из клиентов, инициирующих запросы на услуги, и серверов, предоставляющих эту функцию или услугу.
Часто задаваемые вопросы
Что такое модель клиент-сервер?
Модель клиент-сервер, или архитектура клиент-сервер, представляет собой распределенную структуру приложений, разделяющую задачи между серверами и клиентами, которые либо находятся в одной системе, либо обмениваются данными через компьютерную сеть или Интернет.Клиент полагается на отправку запроса в другую программу, чтобы получить доступ к услуге, предоставляемой сервером. На сервере выполняется одна или несколько программ, которые совместно используют ресурсы и распределяют работу между клиентами.
Отношения клиент-сервер обмениваются данными по схеме обмена сообщениями запрос-ответ и должны придерживаться общего протокола связи, который формально определяет используемые правила, язык и шаблоны диалогов. Связь между клиентом и сервером обычно осуществляется в соответствии с набором протоколов TCP / IP.
Протокол TCP поддерживает соединение до тех пор, пока клиент и сервер не завершат обмен сообщениями. Протокол TCP определяет лучший способ распределения данных приложения в пакеты, которые могут доставляться сетью, передает пакеты и принимает пакеты из сети, а также управляет управлением потоком и повторной передачей отброшенных или искаженных пакетов. IP - это протокол без установления соединения, в котором каждый пакет, проходящий через Интернет, является независимой единицей данных, не связанной с любыми другими единицами данных.
Клиентские запросы упорядочены и распределены по приоритетам в системе планирования, которая помогает серверам справиться с получением запросов от множества различных клиентов за короткий промежуток времени. Подход клиент-сервер позволяет любому компьютеру общего назначения расширять свои возможности за счет использования общих ресурсов других хостов. Популярные клиент-серверные приложения включают электронную почту, World Wide Web и сетевую печать.
Категории клиент-серверных вычислений
Существует четыре основных категории клиент-серверных вычислений:
- Одноуровневая архитектура : состоит из простой программы, выполняемой на одном компьютере без необходимости доступа к сети .Запросы пользователей не управляют никакими сетевыми протоколами, поэтому код прост и сеть избавляется от лишнего трафика.
- Двухуровневая архитектура : состоит из клиента, сервера и протокола, который связывает два уровня. Код графического интерфейса пользователя находится на хосте клиента, а логика домена - на хосте сервера. Графический интерфейс клиент-сервер написан на языках высокого уровня, таких как C ++ и Java.
- Трехуровневая архитектура : состоит из уровня представления, который представляет собой уровень пользовательского интерфейса, уровня приложения, который является уровнем сервиса, выполняющего подробную обработку, и уровня данных, который состоит из сервера базы данных, на котором хранится информация. .
- Многоуровневая архитектура : делит приложение на логические уровни, которые разделяют обязанности и управляют зависимостями, и физические уровни, которые выполняются на отдельных машинах, улучшают масштабируемость и увеличивают задержку из-за дополнительных сетевых коммуникаций. Многоуровневая архитектура может быть закрытой, при которой уровень может взаимодействовать только со следующим уровнем ниже, или открытым уровнем, при котором уровень может взаимодействовать с любыми нижележащими уровнями.
Microsoft MySQL Server - популярный пример трехуровневой архитектуры, состоящей из трех основных компонентов: уровня протокола, реляционного механизма и механизма хранения.На всех клиентских машинах, которые напрямую подключаются к SQL Server, должен быть установлен клиент SQL Server. Процесс выполнения клиент-сервер Microsoft помогает управлять большинством наборов графических инструкций в операционной системе Windows.
Что такое сеть клиент-сервер?
Сеть клиент-сервер - это среда, через которую клиенты получают доступ к ресурсам и службам с центрального компьютера через локальную сеть (LAN) или глобальную сеть (WAN), такую как Интернет.Уникальный сервер, называемый демоном, может использоваться с единственной целью - ожидать клиентских запросов, после чего сетевое соединение инициируется до тех пор, пока клиентский запрос не будет выполнен.
Сетевой трафик подразделяется на клиент-сервер (трафик север-юг) или сервер-сервер (трафик восток-запад). Популярные сетевые услуги включают электронную почту, обмен файлами, печать и всемирную паутину. Основным преимуществом сети клиент-сервер является централизованное управление приложениями и данными.
Преимущества клиент-серверных вычислений
Модель архитектуры клиент-сервер дает множество преимуществ:
- Единый сервер, на котором размещены все необходимые данные в одном месте, облегчает защиту данных и управление авторизацией пользователей и аутентификация.
- Ресурсы, такие как сегменты сети, серверы и компьютеры, могут быть добавлены в сеть клиент-сервер без каких-либо значительных перерывов.
- Доступ к данным можно получить эффективно, не требуя, чтобы клиенты и сервер находились в непосредственной близости.
- Все узлы в системе клиент-сервер независимы, запрашивая данные только с сервера, что упрощает обновление, замену и перемещение узлов.
- Данные, передаваемые по протоколам клиент-сервер, не зависят от платформы.
Разница между клиентом и сервером
Клиенты, также известные как запрашивающие услуги, представляют собой части компьютерного оборудования или серверного программного обеспечения, которые запрашивают ресурсы и услуги, предоставляемые сервером.Клиентские вычисления классифицируются как «толстые», «тонкие» и «гибридные».
- Толстый клиент : клиент, который предоставляет широкие функциональные возможности, выполняет большую часть обработки данных самостоятельно и очень мало полагается на сервер.
- Тонкий клиент : сервер тонкого клиента - это легкий компьютер, который сильно зависит от ресурсов главного компьютера - сервер приложений выполняет большую часть любой необходимой обработки данных.
- Гибридный клиент : обладая сочетанием характеристик тонкого клиента и толстого клиента, гибридный клиент полагается на сервер для хранения постоянных данных, но может выполнять локальную обработку.
Сервер - это устройство или компьютерная программа, которая обеспечивает функции для других устройств или программ. Любой компьютеризированный процесс, который может быть использован или вызван клиентом для совместного использования ресурсов и распределения работы, является сервером. Вот некоторые распространенные примеры серверов:
- Сервер приложений : размещает веб-приложения, которые пользователи в сети могут использовать без необходимости их собственной копии.
- Computing Server : разделяет огромное количество компьютерных ресурсов с подключенными к сети компьютерами, которым требуется больше мощности процессора и оперативной памяти, чем обычно доступно для персонального компьютера.
- Сервер базы данных : поддерживает и совместно использует базы данных для любой компьютерной программы, которая принимает хорошо организованные данные, например, программное обеспечение для бухгалтерского учета и электронные таблицы.
- Веб-сервер : размещает веб-страницы и способствует существованию Всемирной паутины.
Разница между программированием на стороне сервера и программированием на стороне клиента
Программирование на стороне сервера относится к программе, которая выполняется на сервере и ориентирована на создание динамического содержимого.Серверное программирование используется для запросов и взаимодействия с базой данных, доступа к файлам на сервере, взаимодействия с другими серверами, обработки пользовательского ввода и структурирования веб-приложений. Популярные языки программирования для серверного программирования включают C ++, Java и JSP, PHP, Python и Ruby on Rails.
Клиентское программирование относится к программе, которая выполняется на клиентском компьютере и фокусируется на пользовательском интерфейсе и других процессах, таких как чтение и / или запись файлов cookie. Клиентское программирование используется для отправки запросов на сервер, взаимодействия с локальным хранилищем, взаимодействия с временным хранилищем, создания интерактивных веб-страниц и функций в качестве интерфейса между клиентом и сервером.Популярные языки программирования для клиент-серверного программирования включают AJAX, CSS, HTML, Javascript и VBScript.
Рендеринг на стороне сервера и рендеринг на стороне клиента
Рендеринг на стороне сервера означает способность приложения преобразовывать файлы HTML на сервере в полностью визуализированную страницу для клиента. Веб-браузер делает запрос информации с сервера, который отвечает, обычно за миллисекунды, полностью визуализированным HTML-дисплеем. Поисковые системы могут индексировать и сканировать контент до его доставки, что делает рендеринг на стороне сервера очень полезным для SEO.
При отрисовке клиент-сервер вместо получения всего содержимого из документа HTML содержимое отображается в браузере с использованием клиентской библиотеки JavaScript. Браузер не делает новый запрос к серверу при загрузке новой страницы. На ранжирование в поисковых системах может повлиять негативное влияние, поскольку контент не отображается до тех пор, пока страница не загружена в браузере, однако рендеринг веб-сайта, как правило, выполняется быстрее при рендеринге на стороне клиента.
Клиент-сервер и одноранговая сеть
Одноранговая сеть (P2P) - это децентрализованная модель связи, в которой все узлы в сети имеют одинаковые возможности и могут функционировать как в качестве клиента, так и в качестве сервера.Узлы в одноранговых вычислениях коллективно используют свои ресурсы и обмениваются данными друг с другом напрямую по запросу.
Алгоритм в протоколе одноранговой связи балансирует нагрузку, делая доступными другие одноранговые узлы для компенсации любого простоя ресурсов и перенаправляя запросы по мере изменения нагрузки и доступности одноранговых узлов. Основным преимуществом одноранговой сети является возможность расширения сети для управления большим количеством клиентов.
В вычислениях клиент-сервер, централизованной модели связи, сервер является центральным узлом, который взаимодействует с другими клиентскими узлами.Основным преимуществом отношений клиент-сервер перед одноранговыми отношениями является возможность управлять данными и приложениями на одном централизованном сервере.
Предлагает ли OmniSci клиент-серверное решение?
OmniSci Render использует серверные графические процессоры для мгновенного рендеринга интерактивных визуализаций данных высокой мощности. Используя технологию рендеринга на стороне сервера, OmniSci может импортировать и отображать миллионы строк данных по сети для клиента без каких-либо замедлений, связанных с передачей данных высокой мощности.Это отличает OmniSci от других технологий, которые передают результаты клиенту для рендеринга, что снижает общую производительность.
Взаимодействие клиент / сервер - инструменты программирования и управление файлами документация 0.7.5
С модулем сокета в Python,
мы можем определить взаимодействие клиент / сервер.
Компьютерные сети
Классифицируем типы подключений
на основе среды передачи и топологии сети.
Единица скорости передачи бит / с
,
сокращенно бит в секунду .9 \) бит / с
.
или через спутники на большие расстояния.
Три наиболее распространенных обычных топологии
показаны на рис. 78.
Рис. 78 Сеть типа «звезда», «кольцо» и «шина».
В звездообразной сети есть один центральный узел.
Все остальные узлы подключены к этому центральному узлу.
В кольцевой сети узлы замкнутой цепи,
сообщение кружок по кольцу узлов.В автобусной сети все узлы подключены к одной шине,
как используется в архитектуре фон Неймана.
Архитектура клиент / сервер определяет связь между двумя
компьютеры: один является сервером, а другой действует как клиент.
Клиент размещает запрос или заказ на сервере.
Сервер обрабатывает запрос.
Клиенту не нужно знать
как сервер обрабатывает запросы.
Мы различаем программное обеспечение и оборудование
клиент / серверных архитектур:
- веб-серверы и серверы баз данных предлагают программные услуги;
- предлагают аппаратные услуги.
Файловые серверы и серверы печати
Четыре уровня интернет-коммуникации
это приложение, транспорт, сеть и ссылка.
- Уровень приложения состоит из клиентского и серверного программного обеспечения.
Приложение готовит сообщение
и определяет адрес назначения. - Транспортный уровень форматирует сообщение, разрезая его.
в пакеты
прикрепление порядкового номера и адреса назначения к каждому пакету.
При получении пакеты собираются и повторно собираются в сообщение. - Сетевой уровень определяет (промежуточный) адрес
для каждого пакета.
Этот уровень определяет, когда пакет достиг своего конечного пункта назначения. - Канальный уровень отвечает
для фактической передачи пакетов.
Проиллюстрирована работа пластов.
на рис.79,
поскольку мы следуем одному сообщению от источника к месту назначения.
Рис. 79 Следование сообщению от источника к месту назначения.
Сетевые протоколы - это правила сетевого взаимодействия.Мы рассматриваем два типа протоколов:
- TCP Протокол управления передачей
Сначала отправляется сообщение о поступлении данных.
Только после того, как получатель подтвердит это сообщение
отправит ли отправитель данные.
Все успешные передачи подтверждены,
и повторные передачи подтверждаются. - UDP Протокол дейтаграмм пользователя
В отличие от TCP, перед отправкой данных соединение не устанавливается.
Отправитель просто продолжает после отправки сообщения.
TCP ориентирован на соединение, UDP - без установления соединения.TCP более надежен, тогда как UDP более оптимизирован.
Сокеты - это объекты, которые используются программами для подключения.
Сокеты были введены в 1981 году в BSD Unix.
Первоначально использовался для связи между процессами,
то есть: между двумя программами на одном компьютере.
Сокеты поддерживают связь между платформами,
не зависит от операционной системы.
Помимо IP-адреса компьютера,
и сервер, и клиент должны использовать один и тот же порт .
Порт - это 16-битное целое число, некоторые зарезервированы для
конкретные протоколы.Любой порт от 1024 до 65 535 - бесплатный.
Сокеты поддерживают как TCP, так и UDP.
Определение простого взаимодействия клиент / сервер
Простое взаимодействие клиент / сервер определяется
скрипты tcp_server.py
и tcp_client.py
которые соответственно определяют действия сервера
и клиент.
Оба сценария запускаются в отдельных окнах терминала.
Сначала запускаем tcp_server.py
,
как показано на Рис. 80.
Рис. 80 Сервер ожидает соединения от клиента.
Клиент tcp_client.py
работает в другом терминале,
показана на рис. 81.
Рис. 81 Клиент устанавливает соединение с сервером.
Как только запускаем скрипт tcp_client.py
мы замечаем изменение в окне терминала, где
запускается серверный скрипт, показанный на рис. 82.
Рис. 82 Сервер и клиент подключены.
В этом простом взаимодействии клиент / сервер
строка будет передана от клиента к серверу.Пользователь клиентского скрипта tcp_client.py
набирает в
сообщение, как показано на рис. 83.
Рис. 83 Пользователь вводит сообщение, запрашиваемое клиентским скриптом.
Затем серверный скрипт подтверждает сообщение,
как показано на Рис. 84.
Рис. 84 Сервер подтверждает сообщение, полученное от клиента.
Модуль сокета экспортирует сокет класса ()
который возвращает объект, представляющий сокет.
Первым аргументом сокета
является семейство адресов (AF):
.
-
AF_UNIX
: для сокетов UNIX; -
AF_INET
: наиболее часто используется для Интернета
AF_INET
поддерживает как TCP, так и UDP,
задается соответственно SOCK_STREAM
и SOCK_DGRAM
в качестве второго аргумента socket ()
.Например:
из сокета импортного сокета как сокета из сокета импорт AF_INET, SOCK_STREAM sock = Сокет (AF_INET, SOCK_STREAM)
Вызываются методы bind
и connect
.
для определения соединений между клиентом и сервером.
После создания сокета и сервер, и клиент определяют
server_address = (имя хоста, номер)
Для привязки сокета к адресу сервер выполняет
sock.bind (адрес_сервера)
и клиент связывается с сервером затем через
носок.подключиться (адрес_сервера)
Методами слушать
и принимать
, запросы принимаются.
С помощью listen ()
сервер указывает, сколько
будут приниматься входящие соединения:
sock.listen (2) # принимаем не более 2 соединений
Сервер принимает запросы через метод accept ()
:
клиент, client_address = sock.accept ()
Метод accept ()
возвращает
- сокет
клиент
для приема данных; - адрес клиента.
Методы send
и recv
используются для отправки и получения данных.
Клиент отправляет данные с помощью send ()
.
Сервер получает данные, применяя recv ()
.
data = client.recv (буфер)
к сокету клиент
, полученный с помощью accept ()
.
Когда все закончится, и клиент, и сервер делают
Отправляемое должно иметь тип байтов.
Применяются методы encode ()
и decode ()
.
для преобразования строк в байты и байтов в строки.
Чтобы избежать ошибки типа
TypeError: требуется объект, подобный байтам, а не str
мы должны работать с encode ()
и decode ()
,
как показано в сеансе ниже.
>>> п = 4 >>> b = str (n) .encode () >>> б b'4 ' >>> тип (б) <класс 'байты'> >>> c = int (б.декодировать ()) >>> c 4
Теперь мы готовы взглянуть на определение действий.
сервера в tcp_server.py
.
Этот скрипт с определением настройки запускается следующим образом:
из сокета импортного сокета как сокета из сокета импорт AF_INET, SOCK_STREAM HOSTNAME = '' # пусто, поэтому можно использовать любой адрес PORTNUMBER = 41267 # номер порта BUFFER = 80 # размер буфера SERVER_ADDRESS = (HOSTNAME, PORTNUMBER) СЕРВЕР = сокет (AF_INET, SOCK_STREAM) СЕРВЕР.привязать (АДРЕС_СЕРВЕРА) SERVER.listen (2)
Затем определяется взаимодействие с клиентом
в продолжении скрипта tcp_server.py
перечисленных ниже:
print ('сервер ожидает подключения') КЛИЕНТ, КЛИЕНТ_АДРЕС = СЕРВЕР.accept () print ('сервер принял запрос на подключение от', \ CLIENT_ADDRESS) print ('сервер ждет данных') ДАННЫЕ = КЛИЕНТ.recv (БУФЕР) .decode () print ('сервер получил \ "% s \"'% DATA) SERVER.close ()
Скрипт tcp_client.py
короче tcp_server.py
.
Клиентский сценарий приведен ниже.
из сокета импортного сокета как сокета из сокета импорт AF_INET, SOCK_STREAM HOSTNAME = 'localhost' # на том же хосте PORTNUMBER = 41267 # тот же номер порта BUFFER = 80 # размер буфера SERVER_ADDRESS = (HOSTNAME, PORTNUMBER) КЛИЕНТ = сокет (AF_INET, SOCK_STREAM) CLIENT.connect (АДРЕС_СЕРВЕРА) print ('клиент подключен') DATA = input ('Отправить сообщение:') CLIENT.send (DATA.encode ())
Отгадывая секрет
В качестве приложения рассмотрим небольшую игру
общения игрока / дилера.
Дилер генерирует секретный номер.
Игрок должен угадать число.
После каждого предположения дилер отправляет отзыв:
слишком низкий
, слишком высокий
или нашли секрет
.
Игра завершается, когда секрет обнаружен.
Игрок клиент, дилер сервер
Настройка сервера (дилера) начинается следующим образом:
из случайного импорта randint из сокета импорта сокета как Socket из сокета импорт AF_INET, SOCK_STREAM HOSTNAME = '' # пусто, поэтому можно использовать любой адрес PORTNUMBER = 11267 # номер порта BUFFER = 80 # размер буфера DEALER_ADDRESS = (HOSTNAME, PORTNUMBER) ДИЛЕР = сокет (AF_INET, SOCK_STREAM) ДИЛЕР.привязать (DEALER_ADDRESS) ДИЛЕР. Послушать (1) print ('дилер ждет подключения игрока') ИГРОК, ИГРОК_АДРЕС = ДИЛЕР.accept () print ('дилер принял запрос на подключение от', \ PLAYER_ADDRESS)
Сценарий для сервера продолжается ниже.
СЕКРЕТНО = randint (0, 9) print ('секрет% d'% SECRET) в то время как True: print ('дилер ждет ответа') УГАДАЙ = ИГРОК.recv (БУФЕР) .decode () print ('дилер получил' + УГАДАЙСЯ) если int (УГАДАЙ) <СЕКРЕТНО: ОТВЕТ = "слишком низко" elif int (УГАДАЙ)> СЕКРЕТНО: ОТВЕТ = 'слишком высоко' еще: ОТВЕТИТЕ = 'нашел секрет' ИГРОК.отправить (REPLY.encode ()) если REPLY == 'нашел секрет': перерыв ДИЛЕР.close ()
Код для клиента (плеера)
начинается с настройки связи.
из сокета импортного сокета как сокета из сокета импорт AF_INET, SOCK_STREAM HOSTNAME = 'localhost' # на том же хосте PORTNUMBER = 11267 # тот же номер порта BUFFER = 80 # размер буфера ДИЛЕР = (ИМЯ, НОМЕР ПОРТА) ИГРОК = Розетка (AF_INET, SOCK_STREAM) PLAYER.connect (ДИЛЕР)
Игроку предлагается угадать
пока секретное число не будет найдено.Затем сценарий для игрока продолжается ниже:
print ('игрок готов угадать') в то время как True: УГАДАЙ = ввод ('Дай номер:') PLAYER.send (GUESS.encode ()) ОТВЕТ = ИГРОК.recv (БУФЕР) .decode () печать ('>', ОТВЕТ) если ANSWER == 'нашел секрет': перерыв ИГРОК.close ()
Упражнения
- Расширьте взаимодействие клиент / сервер для имитации пароля
диалог. После получения данных от клиента сервер
возвращаетдоступ предоставлен
илидоступ запрещен
в зависимости от
от того, соответствуют ли полученные данные паролю. - Опишите, как бы вы реализовали игру в камень, бумагу,
и ножницы по типу клиент / сервер. - Переопределите манкалу в Project Two как взаимодействие клиент / сервер.
- Напишите реализацию сервера из предыдущего упражнения.
- Напишите реализацию клиента из предыдущего упражнения.
клиентов и серверов
клиентов и серверов
Уровень приложения: клиенты взаимодействуют с серверами для выполнения работы
В сетевых приложениях , клиент и сервер работают вместе, чтобы выполнить полезную работу.
Клиенты и серверы общаются друг с другом через Интернет или любую другую сеть. ( Клиент-серверные приложения также распространены в локальных сетях ). Клиент запрашивает некоторую службу , и сервер выполняет ее (или возвращает сообщение об ошибке, если есть проблема).
Интернет - это знакомое клиент-серверное приложение. Чтобы увидеть веб-страницу, вы запускаете веб-клиент, например Internet Explorer или Firefox.Когда вы вводите URL-адрес и нажимаете Enter, клиент включает его в сообщение Get, которое он отправляет по сети на веб-сервер. Если документ находится на этом веб-сервере, он отправляет его обратно клиенту. В противном случае он отправляет сообщение об ошибке (в формате веб-страницы). Когда клиент получает страницу (сообщение об ошибке pr), он форматирует и отображает ее.
- пользователь вводит URL и нажимает Enter
- клиентская программа отправляет сообщение Get, содержащее URL-адрес, на ожидающий сервер
- если на сервере есть запрошенный документ, он отправляет его обратно клиенту
- если на сервере нет документа, он отправляет клиенту сообщение об ошибке
- клиент отображает все, что было возвращено
- сервер ждет следующего запроса
Этот диалог между клиентом и сервером следует определенному шаблону или протоколу .Протокол определяет формат сообщений, которые могут быть отправлены, и их значения. Веб-протокол называется протоколом передачи гипертекста (HTTP).
Обратите внимание, что когда информация передается с сервера на клиент, как в этом случае, мы говорим о , загружающем , а когда мы передаем информацию на сервер, мы говорим о , загружающем .
Просмотр веб-страниц с помощью веб-клиента - популярное приложение, но существует множество других протоколов приложений, например:
Протокол | Приложение |
---|---|
HTTP , передача гипертекста | получение и просмотр веб-страниц |
FTP , передача файлов | копирование файлов с клиента на сервер или с сервера на клиент |
SMTP , простой почтовый транспорт | Отправить электронное письмо |
POP , Почтовое отделение | Прочитать электронную почту |
В некоторых приложениях компьютер запрограммирован как клиент и как сервер.Это одноранговых приложения.
Обратите внимание, что термины «клиент» и «сервер» относятся как к компьютерному оборудованию, так и к программе, на которой он запущен. Когда вы просматриваете информацию в Интернете, ваш компьютер - это клиентское оборудование, и на нем выполняется клиентская программа.
В случае Интернета люди также называют клиентскую программу браузером , поскольку он используется для тщательного просмотра содержимого веб-сайтов.
Заявление об ограничении ответственности: Взгляды и мнения, выраженные на неофициальных страницах штата Калифорния
Университет, преподаватели, сотрудники или студенты университета Домингес Хиллс являются строго такими же
авторы страницы.Содержание этих страниц не проверялось или
одобрен Калифорнийским государственным университетом, Домингес-Хиллз.
Что такое модель клиент-сервер?
Клиент-сервер - это отношения, в которых одна программа (клиент) запрашивает службу или ресурс у другой программы (сервера). На рубеже прошлого века термин «клиент-сервер» использовался, чтобы отличать распределенные вычисления на персональных компьютерах (ПК) от модели монолитных централизованных вычислений, используемой мэйнфреймами.
Сегодня компьютерные транзакции, в которых сервер выполняет запрос, сделанный клиентом, очень распространены, и модель клиент-сервер стала одной из центральных идей сетевых вычислений. В этом контексте клиент устанавливает соединение с сервером через локальную сеть (LAN) или глобальную сеть (WAN), такую как Интернет. Как только сервер выполнил запрос клиента, соединение разрывается. Поскольку несколько клиентских программ совместно используют службы одной и той же серверной программы, специальный сервер, называемый демоном, может быть активирован только для ожидания клиентских запросов.
На заре Интернета большая часть сетевого трафика была между удаленными клиентами, запрашивающими веб-контент, и серверами центра обработки данных, которые предоставляли контент. Такая схема движения называется движением с севера на юг. Сегодня, когда виртуализация и облачные вычисления достигли зрелости, сетевой трафик, скорее всего, будет межсерверным, по схеме, известной как трафик с востока на запад. Это, в свою очередь, изменило фокус администратора с централизованной модели безопасности, предназначенной для защиты периметра сети, на децентрализованную модель безопасности, которая больше фокусируется на контроле доступа отдельных пользователей к службам и данным и аудиту их поведения для обеспечения соответствия политикам и правилам.
Преимущества и недостатки модели клиент-сервер
Важным преимуществом модели клиент-сервер является то, что ее централизованная архитектура помогает упростить защиту данных с помощью средств управления доступом, которые обеспечиваются политиками безопасности. Кроме того, не имеет значения, созданы ли клиенты и сервер на одной и той же операционной системе, поскольку данные передаются через протоколы клиент-сервер, которые не зависят от платформы.
Важным недостатком модели клиент-сервер является то, что, если слишком много клиентов одновременно запрашивают данные с сервера, он может быть перегружен.Помимо перегрузки сети, слишком большое количество запросов может привести к отказу в обслуживании.
Клиент-серверные протоколы
Клиенты обычно обмениваются данными с серверами с помощью набора протоколов TCP / IP. TCP - это протокол с установлением соединения, что означает, что соединение устанавливается и поддерживается до тех пор, пока прикладные программы на каждом конце не закончат обмен сообщениями. Он определяет, как разбивать данные приложения на пакеты, которые могут доставлять сети, отправляет пакеты и принимает пакеты от сетевого уровня, управляет управлением потоком и обрабатывает повторную передачу отброшенных или искаженных пакетов, а также подтверждение всех поступающих пакетов.В модели взаимодействия открытых систем (OSI) TCP охватывает части уровня 4, транспортного уровня, и части уровня 5, сеансового уровня.
Напротив, IP - это протокол без установления соединения, что означает отсутствие постоянного соединения между конечными точками, которые обмениваются данными. Каждый пакет, который проходит через Интернет, рассматривается как независимая единица данных, не имеющая никакого отношения к любой другой единице данных. (Причина, по которой пакеты размещаются в правильном порядке, - это TCP.) В модели взаимодействия открытых систем (OSI) IP находится на уровне 3, сетевом уровне.
Другие модели взаимосвязей программ
Другие модели взаимоотношений программ включали ведущий / ведомый и одноранговые (P2P). В модели P2P каждый узел в сети может функционировать как сервер, так и как клиент. В модели ведущий / ведомый одно устройство или процесс (известный как ведущий) управляет одним или несколькими другими устройствами или процессами (известными как ведомые устройства , ). После установления отношения «ведущий / ведомый» управление всегда будет односторонним, от ведущего к ведомому.
Глава 23 - Взаимодействие клиент-сервер
Глава 23 - Взаимодействие клиент-сервер
Глава 23 - Взаимодействие клиент-сервер
Последнее изменение:
17 фев, среда, 12:57:34 1999 г.
Глава 23 - Страница 1
Введение
- Протоколы уровня приложений предоставляют услуги высокого уровня
- DNS
- Электронная почта
- Удаленный вход
- FTP
- Всемирная паутина
- Все эти приложения используют архитектуру клиент-сервер
Глава 23 - Страница 2
Интернет-протоколы и сетевые приложения
- Интернет-протоколы обеспечивают
- Универсальное устройство для надежной передачи данных
- Механизм связи с хозяевами
- Прикладные программы
- Использование интернет-протоколов для связи с другими приложениями
- Предоставлять услуги уровня пользователя
Глава 23 - Стр. 3
Установление контакта через Интернет-протоколы
- Приложение должно взаимодействовать с программным обеспечением протокола до
контакт установлен - Прослушивание Приложение сообщает программному обеспечению локального протокола, что оно готово
принимать входящие сообщения - Подключение приложения использует интернет-протокол для связи со слушателем
- Приложения обмениваются сообщениями через результирующее соединение
Глава 23 - Страница 4
Парадигма клиент-сервер
- Сервер приложение является `` слушателем ''
- Ожидает входящего сообщения
- Осуществляет обслуживание
- Возвращает результаты
- Клиентское приложение устанавливает соединение
- Отправляет сообщение на сервер
- Ожидает ответного сообщения
Глава 23 - Страница 5
Характеристики клиента
- Произвольная прикладная программа
- Становится клиентом, когда требуется сетевое обслуживание
- Также выполняет другие вычисления
- Вызвано пользователем напрямую
- Работает локально на компьютере пользователя
- Инициирует связь с сервером
- Может получить доступ к нескольким службам (по одной за раз)
- Не требует специального оборудования или сложной операционной системы
Глава 23 - Стр.6
Характеристики сервера
- Специальное приложение, предназначенное для предоставления сетевых услуг
- Запускается во время инициализации системы
- Работает на удаленном компьютере (обычно централизованном, общем компьютере)
- Ожидает запросов на обслуживание от клиентов; циклы ожидания следующего запроса
- Будет принимать запросы от произвольных клиентов; предоставляет одну услугу
каждый клиент - Требуется мощное оборудование и сложная операционная система
Глава 23 - Стр.7
ЭВМ `` Сервер-класс ''
- Общие централизованные компьютеры, на которых запущено множество серверных приложений
иногда называют `` серверами '' - Точнее, приложения являются `` серверами '' и
компьютер - это `` компьютер серверного класса '' - Серверы могут работать на очень простых компьютерах...
Глава 23 - Страница 8
Обмен сообщениями
- Обычно клиент и сервер обмениваются сообщениями:
- Клиент отправляет запрос, возможно, с данными
- Сервер отправляет ответ, возможно, с данными
- Клиент может отправлять несколько запросов; сервер отправляет несколько ответов
- Сервер может отправлять несколько ответов - представьте себе видео-канал
Глава 23 - Стр.9
Транспортные протоколы и парадигма клиент-сервер
- Клиенты и серверы обмениваются сообщениями по транспортным протоколам;
е.g., TCP или UDP - И клиент, и сервер должны иметь одинаковый стек протоколов, и оба
взаимодействовать с транспортным уровнем
Глава 23 - Стр.10
Несколько служб на одном компьютере
- Достаточно мощный компьютер - достаточно быстрый процессор, многозадачность
ОС - может работать несколько серверов - Серверы работают как независимые процессы и могут одновременно управлять клиентами
- Можно сократить расходы за счет совместного использования ресурсов несколькими службами
- Снижает накладные расходы на управление - нужно обслуживать только один компьютер серверного класса
- Один сервер может повлиять на другие, истощая ресурсы компьютера серверного класса
- Отказ одного компьютера серверного класса может вывести из строя несколько серверов
Глава 23 - Стр.11
Идентификация услуги
- Каждая служба получает уникальный идентификатор ; и клиент, и
- сервер использует этот идентификатор
- Сервер регистрируется с программным обеспечением локального протокола под идентификатором
- Клиентское программное обеспечение протокола контактов для сеанса под этим идентификатором
- Пример - TCP использует номера портов протокола в качестве идентификаторов
- Сервер регистрируется под номером порта для обслуживания
- Клиент запрашивает сеанс с номером порта для обслуживания
Глава 23 - Стр.12
Несколько серверов для одной службы
- Ответ на запрос клиента может потребовать значительного времени
- Другие клиенты должны ждать, пока предыдущие запросы не будут удовлетворены
- Несколько серверов могут обрабатывать запросы одновременно , выполнение
более короткие запросы, не дожидаясь более длинных запросов
Глава 23 - Стр.13
Главный-подчиненный сервер
- Один из способов запуска одновременных серверов - динамическое создание
серверные процессы для каждого клиента - Главный сервер принимает входящие запросы
и запускает подчиненный сервер для каждого клиента - Slave обрабатывает последующие запросы от своего клиента
- Главный сервер ожидает следующего запроса
Глава 23 - Стр.14
Выбор из нескольких серверов
- Как входящие сообщения доставляются на правильный сервер?
- Каждый транспортный сеанс имеет два уникальных идентификатора
- (IP-адрес, номер порта) на сервере
- (IP-адрес, номер порта) на клиенте
- Никакие два клиента на одном компьютере не могут использовать один и тот же исходный порт
- Таким образом, клиентские конечные точки уникальны, а протокол серверного компьютера
программное обеспечение может доставлять сообщения для исправления серверного процесса
Глава 23 - Стр.15
Транспорт с установлением соединения и без установления соединения
- Что выбрать?
- TCP - ориентированный на соединение
- Клиент устанавливает соединение с сервером
- Клиент и сервер обмениваются множеством сообщений произвольного размера
- Клиент прерывает соединение
- UDP - без установления соединения
- Клиент создает сообщение
- Клиент отправляет сообщение на сервер
- Сервер отвечает
- Сообщение должно поместиться в одну дейтаграмму UDP
- Некоторые службы используют оба
- DNS, chargen, motd
- Может быть предоставлено одним сервером
Глава 23 - Стр.16
Взаимодействие клиент-сервер
- Клиенты могут получать доступ к нескольким службам последовательно
- Клиенты могут получить доступ к разным серверам для одной услуги
- Серверы могут стать клиентами других серверов
- Могут возникнуть круговые зависимости...
Глава 23 - Стр.17
Резюме
- Парадигма клиент-сервер , используемая почти во всех распределенных вычислениях
- Клиент запрашивает обслуживание при необходимости
- Сервер ожидает клиентских запросов
- Серверы обычно работают на компьютере серверного класса
- Клиенты и серверы используют транспортные протоколы для связи
- Часто, но не всегда, существует протокол приложения
Модель клиент-сервер
- GeeksforGeeks
Модель клиент-сервер
Модель клиент-сервер - это распределенная структура приложения, которая разделяет задачу или рабочую нагрузку между поставщиками ресурса или услуги, называемыми серверами, и инициаторами запросов услуг, называемыми клиентами.В архитектуре клиент-сервер, когда клиентский компьютер отправляет запрос данных на сервер через Интернет, сервер принимает запрошенный процесс и доставляет запрошенные пакеты данных обратно клиенту. Клиенты не делятся своими ресурсами. Примерами модели клиент-сервер являются электронная почта, Интернет и т. Д.
Как работает модель клиент-сервер?
В этой статье мы собираемся погрузиться в модель клиент-сервер и посмотрим, как Internet работает через веб-браузеры.Эта статья поможет нам получить прочную основу для WEB и поможет с легкостью работать с WEB-технологиями.
- Клиент: Когда мы говорим слово Клиент , это означает, что мы говорим о человеке или организации, использующей определенную услугу. Точно так же в цифровом мире Клиент - это компьютер ( Хост ), то есть способный получать информацию или использовать конкретную услугу от поставщиков услуг ( Сервера ).
- Серверы: Точно так же, когда мы говорим о слове Серверы , оно означает человека или среду, которая что-то обслуживает.Точно так же в этом цифровом мире Server - это удаленный компьютер, который предоставляет информацию (данные) или доступ к определенным услугам.
Итак, в основном клиент что-то запрашивает, а сервер обслуживает его до тех пор, пока он присутствует в базе данных.
Как браузер взаимодействует с серверами?
Для взаимодействия с серверами клиента необходимо выполнить несколько шагов.
- Пользователь вводит URL (унифицированный указатель ресурсов) веб-сайта или файла.Затем браузер запрашивает сервер DNS (СИСТЕМА ДОМЕННЫХ ИМЕНИ).
- DNS-сервер ищет адрес WEB-сервера .
- DNS-сервер отвечает с IP-адресом веб-сервера .
- Браузер отправляет запрос HTTP / HTTPS на IP-адрес WEB-сервера (предоставляется DNS-сервером ).
- Сервер отправляет необходимые файлы сайта.
- Браузер затем отображает файлы и отображается веб-сайт.Этот рендеринг выполняется с помощью интерпретатора DOM (объектная модель документа), интерпретатора CSS и JS Engine , вместе известных как JIT или (Just in Time) компиляторы.
Преимущества модели клиент-сервер:
- Централизованная система со всеми данными в одном месте.
- Рентабельность требует меньших затрат на обслуживание, возможно восстановление данных.
- Емкость Клиента и Сервера можно изменять отдельно.
Недостатки модели клиент-сервер:
- Клиенты подвержены вирусам, троянам и червям, если они присутствуют на сервере или загружены на сервер.
- Сервер подвержен атакам типа «отказ в обслуживании» (DOS).
- Пакеты данных могут быть подделаны или изменены во время передачи.