Гипертекстный протокол HTTP

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

Создателем этой технологии явился Тим Бернес Ли, который работал в конце 80-х годов в ЦЕРН (Женева), а до этого вел разработки в области экспертных систем, которые базируются на гипертексте. Ему в голову пришла мысль объединить гипертекст и возможности Интернет.

Первые WWW-системы (1990 год) носили диалоговый характер и базировались на меню (никакой графики!). (Смотри также http://book.itep.ru/4/45/www_456.htm.)

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

Первые версии, такие, как HTTP/0.9, представляли собой простые протоколы для передачи данных через Интернет. Версия HTTP/1.0, описанная в RFC-1945 [7.6], улучшила протокол, разрешив использование сообщений в формате MIME, содержащих метаинформацию о передаваемых данных, и модификаторы для запросов/откликов. Дальнейшее развитие сетей WWW-серверов потребовало новых усовершенствований, которые вряд ли станут последними (RFC-2616 и 2817 HTTPv1.1).

Реальные информационные системы требуют больших возможностей, чем простой поиск и доставка данных. Для описания характера, наименования и места расположения информационных ресурсов введены: универсальный идентификатор ресурса URI (Uniform Resource Identifier), универсальный указатель ресурса URL и универсальное имя ресурса URN. Формат сообщений — сходный с используемыми в электронной почте и описанный в стандарте MIME (Multipurpose Internet Mail Extensions).

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

Прокси

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

Туннель

Программа, которая работает как ретранслятор между двумя объектами. Туннель закрывается, когда обе стороны, соединенные им, прерывают сессию. Туннель может быть активирован с помощью HTTPзапроса.

Время пригодности объекта (expiration time)

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

Эвристическое значение времени жизни (heuristic expiration time)

Время пригодности, присваиваемое объекту в кэше, если это время не задано явно.

Возраст

Возраст отклика — время с момента его посылки или проверки его пригодности исходным сервером.

Время жизни (freshness lifetime)

Продолжительность времени с момента генерации отклика до истечения его пригодности.

Свежий

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

Устаревший

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

Семантическая прозрачность

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

Валидатор

Протокольный элемент (например, метка объекта или время lastmodified), который используется для выяснения того, является ли запись в кэше эквивалентной копией объекта.

Метод

Процедура, выполняемая над ресурсом (get, put, head, post, delete, trace и т.д.).

Рис. 7.1. Взаимодействие клиента, кэша и исходного сервера в протоколе HTTP

Кэш может находиться в ЭВМ клиента или агента пользователя, но может размещаться на соседнем континенте. Число прокси между клиентом и исходным сервером может варьироваться и ограничивается сверху только здравым смыслом (см. рис. 7.1).

Рис. 7.2. Структура ресурса и объекта

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

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

Более сложная ситуация возникает, когда присутствует один или более посредников в цепочке обслуживания запроса/отклика. Существует три стандартных формы посредников: прокси, туннель и внешний шлюз (gateway). Прокси представляет собой агент переадресации, получающий запрос для URI, переписывающий все сообщение или его часть и отправляющий переделанный запрос серверу, указанному URI. Внешний порт (gateway) — это приемник, который работает на уровень выше некоторых других серверов и транслирует, если необходимо, запрос нижележащему протоколу сервера. Туннель действует как соединитель точка­точка и не производит каких­-либо видоизменений сообщений. Туннель используется, если нужно пройти через какуюто систему (например, Firewall) в условиях, когда эта система не анализирует содержимое сообщений.

Рис. 7.3. UA — агент пользователя

На рисунке 7.3 показаны три промежуточные ступени (A, B, и C) между агентом пользователя (UA) и базовым сервером (O). Запрос или отклик, двигаясь по этой цепочке, должен пройти четыре различных соединительных сегмента. Это обстоятельство крайне важно, так как некоторые опции HTTP применимы только для ближайших соединений. Хотя схема линейна, на практике узлы могут участвовать в большом числе других взаимодействий. Например, B может получать запросы от большого числа клиентов помимо A и переадресовывать запросы к другим серверам, кроме C.

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

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

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

В действительности имеется широкое разнообразие архитектур и конфигураций буферных запоминающих устройств и прокси, разрабатываемых в настоящее время или уже доступных через World Wide Web. Эти системы включают иерархии проксисерверов национального масштаба, задачей которых является сокращение трансокеанского трафика, системы, которые обслуживают широковещательные и мультикастинговые обмены, организации, которые распространяют фрагменты информации с CDROM, занесенной в кэши и т. д.. HTTPсистемы, используются в корпоративных сетях Интранет с большими пропускными способностями и перемежающимися соединениями. Целью HTTP/1.1 является поддержка широкого разнообразия уже существующих систем и расширение возможностей будущих приложений в отношении надежности и адаптируемости.

Коммуникации HTTP обычно реализуются через соединения TCP/IP. Порт по умолчанию имеет номер 80, но и другие номера портов вполне допустимы. Это не исключает применения HTTP поверх любого другого протокола в Интернет или других сетей. HTTP предполагает надежное соединение; возможен любой протокол, который может гарантировать корректную доставку сообщений.

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