Web-протоколы. Веб-сервисы как средство интеграции приложений в WWW Веб протоколы

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

Веб-служба, веб-сервис (англ. web-service) - это сетевая технология, обеспечивающая межпрограммное взаимодействие на основе веб-стандартов. Консорциум W3C определяет веб-сервис, как «программную систему, разработанную для поддержки интероперабельного межкомпьютерного (machine-to-machine) взаимодействия через сеть»

Веб-службы: концепции и протоколы

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

Рис. 1. Концепция веб-сервиса

• SOAP (Simple Object Access Protocol) — протокол обмена сообщениями между потребителем и поставщиком веб-сервиса;
• WSDL (Web Services Description Language) — язык описания внешних интерфейсов веб-службы;
• UDDI (Universal Discovery, Description and Integration) — универсальный интерфейс распознавания, описания и интеграции, используемый для формирования каталога веб-сервисов и доступа к нему.

Рис. 2. Протоколы веб-сервисов

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

SOAP

SOAP (изначально Simple Object Access Protocol , а в версии 1.2 официальная расшифровка аббревиатуры отсутствует) - простой протокол доступа к объектам (компонентам распределенной вычислительной системы), основанный на обмене структурированными сообщениями. Как любой текстовый протокол, SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTPS и др., но чаще всего SOAP используется поверх HTTP.

Все сообщения SOAP оформляются в виде структуры, называемой конвертом (envelop), включающей следующие элементы:

• Идентификатор сообщения (локальное имя).
• Опциональный элемент Header (заголовок):
  • Ноль или более свойств, доступных в этом пространстве имен.
• Обязательный элемент Body (тело сообщения)
  • Ноль или более ссылок на используемые пространства имен;
  • Дочерние элементы тела сообщения

Развернутый список элементов сообщения SOAP приведен в схеме данных (для SOAP версии 1.2).

Пример сообщения SOAP:

Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope "> Header > 1 2001-06-22T14:00:00-05:00 Header > Body > Get up at 6:30 AM Body > Envelope >

XML-RPC: Не конкурент, а альтернатива SOAP

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

Концепция XML-RPC

Таблица 1. Основные элементы протокола WSDL.

Элемент WSDL 1.1	Элемент WSDL 2.0	Краткое описание
PortType	Interface	Представляет описание интерфейса веб-сервиса (список операций и их параметров).
Service	Service	Список системных функций
Binding	Binding	Специфицирует интерфейсы и задает параметры связывания с протоколом SOAP: стиль связывания (RPC/Document) и транспорт (SOAP). Эта секция доступна и для каждой из операций
Operation	Operation	Определяет операцию, представляемую веб-сервером. WSDL-операция — это аналог традиционным функциям и процедурам.
Message	не использ.	Сообщение, связанное с определенной операцией. Содержит информацию, необходимую для выполнения данной операции. Каждое сообщение может состоять из нескольких логических частей, описывающих типы данных и имена атрибутов. В версии 2.0 было исключено, т.к. была внедрена поддержка XML Schema для всех элементов.
Types	Types	Описание данных в соответствии с XML Schema.

Рис. 3. Структура протокола WSDL

В спецификации WSDL 1.1 было определено 4 шаблона обмена сообщениями (типы операций):

• Однонаправленные операции (One-way): операция может принимать сообщение, но не будет возвращать ответ.
• Запрос-ответ (Request-response): операция может принять запрос и должна вернуть ответ.
• Вопрос-ответ (Solicit-response): операция может послать запрос и будет ждать ответ на него.
• Извещение (Notification): операция может послать сообщение, но не будет ожидать ответ.

В версии WSDL 2.0 эти шаблоны изменены и расширены в сторону поддержки сообщений об ошибках (например, шаблон Robust-in-only), но для обратной совместимости поддерживаются типы WSDL 1.1

UDDI опирается на отраслевые стандарты HTTP, XML, XML Schema (XSD), SOAP и WSDL. Концептуальная связь между UDDI и другими протоколами стека веб-сервисов показана на .

Рис. 4. Место UDDI в стеке протоколов веб-служб

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

Ключевыми функциями UDDI являются публикация информации о службе в реестре и поиск этой информации сторонними приложениями. Наряду с этими, реализованы и типовые для службы каталогов функции: представление модели хранимых данных и структуры информационной базы, отношения между объектами реестра, репликация, обеспечение безопасности и т.д. —Все основные функции реестра представлены в виде веб-сервисов и доступны через API UDDI.

Веб-сервисы: Pro et Contra

Достоинства

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

Недостатки

• Меньшая производительность и больший объем сетевого трафика по сравнению с такими технологиями как CORBA или DCOM.

Постоянный адрес этой страницы:

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

UNIX

Возможно, самый простой протокол у услуги daytime. Если подключиться к порту 13 машины, поддерживающей сервер daytime, этот сервер отправит в ответ информацию о текущей дате и времени и затем отключит соединение. Протокол выглядит следующим образом: «Если клиент устанавливает связь с сервером daytime, ему отправляются данные даты и времени, после чего соединение отключается». Большинство машин с UNIX поддерживают этот сервер. Можно связаться с ним, используя приложение Telnet. В UNIX сессия будет иметь следующий вид:

• %telnet web67.ntx.net 13
• Соединение с web67.ntx.net.
• Символ отмены "^]".
• Воскресенье 25 октября 08:34:06 1998

Windows

На машине, работающей под ОС Windows, можно получить доступ к этому серверу, введя «telnet web67.ntx.net 13» в окне MSDOS.

В этом примере web67.ntx.net - серверная машина UNIX, а 13 - номер порта для услуги daytime. Приложение Telnet подключается к порту 13 (telnet обычно подключается к порту 23, но можно указать любой другой порт для подключения), затем сервер отправляет данные даты и времени, после чего разрывает соединение. В большинстве версий Telnet есть возможность указывать номер порта и этой возможностью можно пользоваться независимо от того, какая версия Telnet установлена на машине.

Большинство протоколов более сложны, чем протокол для daytime, они определены в имеющихся в свободном доступе Рабочих предложениях (Request for Comment, RFC) (хороший архив всех RFC смотрите sunsite.auc.dk/RFC/). Каждый WEB сервер в Интернете соответствует требованиям протокола HTTP, собранным в документе The Original HTTP в 1991 году. Наиболее важная форма протокола, которая воспринимается HTTP сервером, включает только одну команду: GET. Если установить связь с сервером, работающим по протоколу HTTP и послать запрос «GET имя файла» сервер отреагирует отправкой источнику запроса содержимого указанного файла, после чего отключит соединение. Типичная сессия имеет следующий вид:

• %telnet сайт 80
• Попытка соединения с 78.110.59.235…
• Соединение с pcwork.ru.
• Символ отмены "^]".
• Соединение отключено внешним хост компьютером.

В начальном варианте протокола HTTP нужно было отправить только действительное имя файла, например, [/] или Позже протокол изменили, чтобы получить возможность обработки полных URL. Это позволило компаниям, которые занимаются виртуальных доменов, в условиях, когда много доменов размещают на одной машине, использовать для всех таких доменов один IP адрес.

Подведем итог

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

1. разделил URL на три части:

• Протокол («http»)
• Имя сервера («сайт») - в последнее время положительная тенденция сокращать первые три буквы www
• Имя файла («web server.htm»)

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

После получения IP адреса указанный браузер устанавливает соединение с WEB сервером, обладающим этим IP адресом, по порту 80.

В соответствии с протоколом HTTP, браузер отправляет на этот сервер запрос GET на получение файла (Заметим, что вместе с запросом GET с браузера на сервер могут отправляться куки - подробности можно узнать из статьи о том, как работают куки).

Сервер отправляет текст HTML запрошенной WEB страницы на браузер. (В заголовке страницы с сервера на браузер также могут передаваться куки).

Браузер считывает таги HTML и воспроизводит соответствующую страницу на экране монитора.

Дополнение: Безопасность

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

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

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

Дополнение: Динамические страницы

А как же с динамическими WEB страницами? Например:

• В любой книге отзывов разрешается оставлять сообщения в HTML форме и при следующем ее просмотре на этой странице сохраняется новая введенная информация.
• В экранной форме whois компании Network Solutions в ответ на ввод имени домена приходят WEB страница, вид которой зависит от введенного имени.
• В любой поисковой машине в HTML форму вводятся ключевые слова, после чего машина создает страницу, отображающую результат поиска по этим словам.

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

Каждая серверная машина открывает доступ из Интернета к услугам, используя пронумерованные порты, по одному для каждой услуги, имеющейся на сервере. Например, если на серверной машине имеется WEB сервер и FTP сервер, обычно доступ к WEB серверу производится через порт 80, а к FTP серверу - через порт 21. Клиенты подключаются к услуге, выбрав соответствующий адрес и подключившись к соответствующему порту.

Каждой популярной услуге поставлен в соответствие определенный номер порта. Ниже приводятся номера чаще всего используемых портов:

• echo 7
• daytime 13
• qotd 17 (Цитата дня)
• ftp 21
• telnet 23
• smtp 25 (Электронная почта)
• time 37
• nameserver 53 (Сервер имен)
• nicname 43 (Кто есть кто)
• gopher 70
• finger 79
• WWW 80

Ограничения

Если серверная машина разрешает подключение к порту из сети Интернет и этот порт не защищен , можно подключиться к нему из любой точки Интернета и пользоваться соответствующей услугой. Следует отметить, что нет каких-либо ограничений, предписывающих, например, WEB серверу подключаться по порту 80. Вводя в действие собственную машину и устанавливая на ней программное обеспечение WEB сервера, можно при желании указать, чтобы WEB сервер работал, например, по порту 918, или по любому другому незанятому порту. Затем, если машине присвоено имя xxx.yyy.com, можно подключиться к этому серверу через Интернет, используя URL xxx.yyy.com:918. Часть «:918» явно указывает на номер порта и должна добавляться всеми желающими связаться с этим сервером. Если порт не указан, браузер по умолчанию пытается подключиться к общепринятому порту 80.

HTTP . В его основу положено взаимодействие " клиент-сервер ", то есть предполагается, что:

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

   При этом возможны два способа организации работы компьютера-клиента:

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

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

Протокол HTTP

HTTP (HyperText Transfer Protocol - RFC 1945, RFC 2616) - протокол прикладного уровня для передачи гипертекста.

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

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

Все программное обеспечение для работы с протоколом HTTP разделяется на три основные категории:

• Серверы - поставщики услуг хранения и обработки информации (обработка запросов).
• Клиенты - конечные потребители услуг сервера (отправка запросов).
• Прокси-серверы для поддержки работы транспортных служб.

Основными клиентами являются браузеры , например: Internet Explorer, Opera, Mozilla Firefox, Netscape Navigator и другие. Наиболее популярными реализациями веб-серверов являются: Internet Information Services ( IIS ), Apache, lighttpd, nginx. Наиболее известные реализации прокси-серверов: Squid, UserGate, Multiproxy, Naviscope.

"Классическая" схема HTTP -сеанса выглядит так.

1. Установление TCP-соединения.
2. Запрос клиента.
3. Ответ сервера.
4. Разрыв TCP-соединения.

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

В состав HTTP -запроса, передаваемого клиентом серверу, входят следующие компоненты.

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

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

Рис. 2.1.

Строка состояния имеет следующий формат:

метод_запроса URL_pecypca версия_протокола_НТТР

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

Метод , указанный в строке состояния, определяет способ воздействия на ресурс , URL которого задан в той же строке. Метод может принимать значения GET , POST , HEAD , PUT , DELETE и т.д. Несмотря на обилие методов, для веб-программиста по-настоящему важны лишь два из них: GET и POST .

• GET . Согласно формальному определению, метод GET предназначается для получения ресурса с указанным URL. Получив запрос GET , сервер должен прочитать указанный ресурс и включить код ресурса в состав ответа клиенту. Ресурс, URL которого передается в составе запроса, не обязательно должен представлять собой HTML-страницу, файл с изображением или другие данные. URL ресурса может указывать на исполняемый код программы, который, при соблюдении определенных условий, должен быть запущен на сервере. В этом случае клиенту возвращается не код программы, а данные, сгенерированные в процессе ее выполнения. Несмотря на то что, по определению, метод GET предназначен для получения информации, он может применяться и в других целях. Метод GET вполне подходит для передачи небольших фрагментов данных на сервер.
• POST . Согласно тому же формальному определению, основное назначение метода POST - передача данных на сервер. Однако, подобно методу GET , метод POST может применяться по-разному и нередко используется для получения информации с сервера. Как и в случае с методом GET , URL, заданный в строке состояния, указывает на конкретный ресурс. Метод POST также может использоваться для запуска процесса.
• Методы HEAD и PUT являются модификациями методов GET и POST.

Версия протокола HTTP , как правило, задается в следующем формате:

HTTP/версия.модификация

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

Имя_поля: Значение

Назначение поля определяется его именем, которое отделяется от значения двоеточием.

Имена некоторых наиболее часто встречающихся в запросе клиента полей заголовка и их назначение приведены в таблице 2.1 .

Таблица 2.1. Поля заголовка запроса HTTP.

Поля заголовка HTTP -запроса	Значение
Host	Доменное имя или IP-адрес узла, к которому обращается клиент
Referer	URL документа, который ссылается на ресурс, указанный в строке состояния
From	Адрес электронной почты пользователя, работающего с клиентом
Accept	MIME-типы данных, обрабатываемых клиентом. Это поле может иметь несколько значений, отделяемых одно от другого запятыми. Часто поле заголовка Accept используется для того, чтобы сообщить серверу о том, какие типы графических файлов поддерживает клиент
Accept-Language	Набор двухсимвольных идентификаторов, разделенных запятыми, которые обозначают языки, поддерживаемые клиентом
Accept-Charset	Перечень поддерживаемых наборов символов
Content-Type	MIME-тип данных, содержащихся в теле запроса (если запрос не состоит из одного заголовка)
Content-Length	Число символов, содержащихся в теле запроса (если запрос не состоит из одного заголовка)
Range	Присутствует в том случае, если клиент запрашивает не весь документ, а лишь его часть
Connection	Используется для управления TCP-соединением. Если в поле содержится Close, это означает, что после обработки запроса сервер должен закрыть соединение. Значение Keep-Alive предлагает не закрывать TCP-соединение, чтобы оно могло быть использовано для последующих запросов
User-Agent	Информация о клиенте

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

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

Сетевые протоколы предписывают правила работы компьютерам, которые подключены к сети. Они строятся по многоуровневому принципу. Протокол некоторого уровня определяет одно из технических правил связи. В настоящее время для сетевых протоколов используется модель OSI (Open System Interconnection - Взаимодействие Открытых Систем, ВОС). Модель OSI – это семиуровневая логическая модель работы сети. Модель OSI реализуется группой протоколов и правил связи, организованных в несколько уровней.

На физическом уровне определяются физические (механические, электрические, оптические) характеристики линий связи.

На канальном уровне определяются правила использования физического уровня узлами сети.

- Сетевой уровень отвечает за адресацию и доставку сообщений.

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

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

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

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

Протокол TCP/IP - это два протокола нижнего уровня, являющиеся основой связи в Интернет. Протокол TCP (Transmission Control Protocol) разбивает передаваемую информацию на порции и нумерует все порции. С помощью протокола IP (Internet Protocol) все части передаются получателю. Далее с помощью протокола TCP проверяется, все ли части получены. При получении всех порций TCP располагает их в нужном порядке и собирает в единое целое.

Наиболее известные протоколы, используемые в сети Интернет:

HTTP (Hyper Text Transfer Protocol) - это протокол передачи гипертекста. Протокол HTTP используется при пересылке Web-страниц с одного компьютера на другой.

FTP (File Transfer Protocol) – это протокол передачи файлов со специального файлового сервера на компьютер пользователя. FTP дает возможность абоненту обмениваться двоичными и текстовыми файлами с любым компьютером сети. Установив связь с удаленным компьютером, пользователь может скопировать файл с удаленного компьютера на свой или скопировать файл со своего компьютера на удаленный.

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

Стандарт SMTP (Simple Mail Transfer Protocol) задает набор правил для передачи почты. Сервер SMTP возвращает либо подтверждение о приеме, либо сообщение об ошибке, либо запрашивает дополнительную информацию.

UUCP (Unix to Unix Copy Protocol) - это ныне устаревший, но все еще применяемый протокол передачи данных, в том числе для электронной почты. Этот протокол предполагает использование пакетного способа передачи информации, при котором сначала устанавливается соединение «клиент – сервер» и передается пакет данных, а затем автономно происходит его обработка, просмотр или подготовка писем.

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

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

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

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

Хотя HTTP был разработан еще в начале 1990-х годов, за счет своей расширяемости в дальнейшем он все время совершенствовался. HTTP является протоколом прикладного уровня, который чаще всего использует возможности другого протокола - TCP (или TLS - защищённый TCP) - для пересылки своих сообщений, однако любой другой надежный транспортный протокол теоретически может быть использован для доставки таких сообщений. Благодаря своей расширяемости, он используется не только для получения клиентом гипертекстовых документов, изображений и видео, но и для передачи содержимого серверам, например, с помощью HTML-форм. HTTP также может быть использован для получения только частей документа с целью обновления веб-страницы по запросу (например посредством AJAX запроса).

Составляющие систем, основанных на HTTP

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

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

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

Клиент: участник обмена

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

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

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

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

Веб-сервер

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

Сервер не обязательно расположен на одной машине, и наоборот - несколько серверов могут быть расположены (хоститься) на одной и той же машине. В соответствии с версией HTTP/1.1 и имея Host заголовок, они даже могут делить тот же самый IP-адрес.

Прокси

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

• caching (кеш может быть публичным или приватными, как кеш браузера)
• фильтрация (как сканирование антивируса, родительский контроль, …)
• выравнивание нагрузки (позволить нескольким серверам обслуживать разные запросы)
• аутентификация (контролировать доступом к разным ресурсам)
• протоколирование (разрешение на хранение истории операций)

Основные аспекты HTTP

HTTP - прост

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

HTTP - расширяемый

Введенные в HTTP/1.0 HTTP-заголовки сделали этот протокол легким для расширения и экспериментирования. Новая функциональность может быть даже введена простым соглашением между клиентом и сервером о семантике нового заголовка.

HTTP не имеет состояния, но имеет сессию

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

HTTP и соединения

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

HTTP/1.0 открывал TCP-соединение для каждого обмена запросом/ответом, имея два важных недостатка: открытие соединения требует нескольких обменов сообщениями, и потому медленно, хотя становится более эффективным при отправке нескольких сообщений, или при регулярной отправке сообщений: теплые соединения более эффективны, чем холодные .

Для смягчения этих недостатков, HTTP/1.1 предоставил конвеерную обработку (которую оказалось трудно реализовать) и устойчивые соединения: лежащее в основе TCP соединение можно частично контролировать через заголовок Connection . HTTP/2 сделал следующий шаг, добавив мультиплексирование сообщений через простое соединение, помогающее держать соединение теплым и более эффективным.

Проводятся эксперименты по разработке лучшего транспортного протокола, более подходящего для HTTP. Например, Google эксперементирует с QUIC , которая основана на UDP, для предоставления более надёжного и эффективного транспортного протокола.

Чем можно управлять через HTTP

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

Ниже перечислены общие функции, управляемые с HTTP.

• 
  Сервер может инструктировать прокси и клиенты: что и как долго кэшировать. Клиент может инструктировать прокси промежуточных кэшей игнорировать хранимые документы.
• Ослабление ограничений источника
  Для предотвращения шпионских и других, нарушающих приватность, вторжений, веб-браузер обчеспечивает строгое разделение между веб-сайтами. Только страницы из того же источника могут получить доступ к информации на веб-странице. Хотя такие ограничение нагружают сервер, заголовки HTTP могут ослабить строгое разделение на стороне сервера, позволяя документу стать частью информации с различных доменов (по причинам безопасности).
• Аутентификация
  Некоторые страницы доступны только специальным пользователям. Базовая аутентификация может предоставляться через HTTP, либо через использование заголовка WWW-Authenticate и подобных ему, либо с помощью настройки спецсессии, используя куки.
• Прокси и тунелирование
  Серверы и/или клиенты часто располагаются в интранете, и скрывают свои истинные IP-адреса от других. HTTP запросы идут через прокси для пересечения этого сетевого барьера. Не все прокси -- HTTP прокси. SOCKS-протокол, например, оперирует на более низком уровне. Другие, как, например, ftp, могут быть обработаны этими прокси.
• Сессии
  Использование HTTP кук позволяет связать запрос с состоянием на сервере. Это создает сессию, хотя ядро HTTP -- протокол без состояния. Это полезно не только для корзин в интернет-магазинах, но также для любых сайтов, позволяющих пользователю настроить выход.

HTTP поток

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

1. Открытие TCP соединения: TCP-соедиенение будет использоваться для отправки запроса или запросов, и получения ответа. Клиент может открыть новое соединение, переиспользовать существующее, или открыть несколько TCP-соединений к серверу.
2. Отправка HTTP-сообщения: HTTP-собщения (до HTTP/2) -- человеко-читаемо. Начиная с HTTP/2, простые сообщения инкапсилуруются во фреймы, делая невозможным их чтения напрямую, но принципиально остаются такими же. GET / HTTP/1.1 Host: сайт Accept-Language: fr
3. Читает ответ от сервера: HTTP/1.1 200 OK Date: Sat, 09 Oct 2010 14:28:02 GMT Server: Apache Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT ETag: "51142bc1-7449-479b075b2891b" Accept-Ranges: bytes Content-Length: 29769 Content-Type: text/html
4. Закрывает или переиспользует соединение для дальнейщих запросов.

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

HTTP сообщения

HTTP/1.1 и более ранние HTTP сообщения человеко-читаемы. В версии HTTP/2 эти сообщения встроены в новую бинарную структуру, фрейм, позволяющий оптимизации, такие как компрессия заголовков и мультиплексирование. Даже если часть оригинального HTTP сообщения отправлена в этой версии HTTP, семантика каждого сообщения не изменяется и клиент воссоздаёт (виртуально) оригинальный HTTP-запрос. Это также полезно для понимания HTTP/2 сообщений в формате HTTP/1.1.

Существует два типа HTTP сообщений, запросы и ответы, каждый в своем формате.

Запросы

Примеры HTTP запросов:

• HTTP-метод , обычно глагол подобно GET ,
• Заголовки (опционально), предоставляюшие дополнительную информацию для сервера.
• Или тело, для некоторых методов, таких как POST , которое содержит отправленный ресурс.

Ответы

Примеры ответов:

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

Вывод

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

Хотя HTTP/2 добавляет некоторую сложность, встраивая HTTP сообщения во фреймы для улучшения производительности, базовая структура сообщений осталась с HTTP/1.0. Сессионый поток остается простым, позволяя исследовать и отлаживать с простым