Электронная библиотека
Программисту веб-дизайнеру
Другие материалы
HTTP/1.1, протокол передачи гипертекста
назад | содержание | вперед
1 Введение.
Протокол передачи Гипертекста (HTTP) - протокол прикладного уровня для распределенных, совместных, многосредных информационных систем. HTTP используется в World Wide Web (WWW) начиная с 1990 года. Первой версией HTTP, известной как HTTP/0.9, был простой протокол для передачи необработанных данных через Интернет. HTTP/1.0, как определено в RFC 1945 [6], был улучшением этого протокола, позволяя сообщениям иметь MIME-подобный формат, содержащий метаинформацию о передаваемых данных и имел модифицированную семантику запросов/ответов. Однако, HTTP/1.0 недостаточно хорошо учитывал особенности работы с иерархическими прокси-серверами (hierarchical proxies), кэшированием, постоянными соединениями, и виртуальными хостами (virtual hosts). Кроме того, быстрое увеличение не полностью совместимых приложений, называющих тот протокол, который они использовали "HTTP/1.0", потребовало введения версии протокола, в которой были бы заложены возможности, позволяющие приложениям определять истинные возможности друг друга.
Эта спецификация определяет протокол "HTTP/1.1". Этот протокол содержит более строгие требования, чем HTTP/1.0, гарантирующие надежную реализацию возможностей.
Практически информационные системы требуют большей функциональности, чем просто загрузку информации, включая поиск, модификацию при помощи внешнего интерфейса, и аннотацию (annotation). HTTP предоставляет открытый набор методов, которые указывают цель запроса. Они основаны на дисциплине ссылки, обеспеченной Универсальным Идентификатором Ресурса (URI) , как расположение (URL) или имя (URN), для идентификации ресурса, к которому этот метод применяется. Сообщения передаются в формате, подобном используемому электронной почтой, как определено Многоцелевыми Расширениями Электронной Почты (MIME).
HTTP также используется как обобщенный протокол связи между агентами пользователей и прокси-серверами/шлюзами (proxies/gateways) или другими сервисами Интернета, включая такие, как SMTP 16, NNTP [13], FTP [18], Gopher [2], и WAIS [10]. Таким образом, HTTP закладывает основы многосредного (hypermedia) доступа к ресурсам для разнообразных приложений.
Эта спецификация использует те же самые слова для определения требований к реализации протокола, что и RFC 1123 [8]. Эти слова следующие:
НЕОБХОДИМО, ДОЛЖЕН (MUST)
РЕКОМЕНДУЕТСЯ, СЛЕДУЕТ (SHOULD)
ВОЗМОЖНО, МОЖЕТ (MAY)
Реализация считается несовместимой, если нарушено хотя бы одно НЕОБХОДИМЫХ требований спецификации протокола. Реализация, удовлетворяющая всем НЕОБХОДИМЫМ и РЕКОМЕНДУЕМЫМ тредованиям называется полностью совместимой, а удовлетворяющая всем НЕОБХОДИМЫМ, но не всем РЕКОМЕНДУЕМЫМ требованиям называется условно совместимой.
Эта спецификация использует ряд терминов для описания роли участников, некоторых объектов, и HTTP связи.
Соединение (connection)
Виртуальный канал транспортого уровня, установленный между двумя программами с целью связи.
Сообщение (message)
Основной модуль HTTP связи, состоящей из структурной последовательности октетов, соответствующих синтаксису, определенному в разделе 4 и передаваемых по соединению.
Запрос (request)
Любое HTTP сообщение, содержащее запрос, определяемый в разделе 5.
Ответ (response)
Любое HTTP сообщение, содержащее ответ, определяемый в разделе 5.
Ресурс (resource)
Сетевой объект данных или сервис, который может быть идентифицирован URI, определеляемым в разделе 3.2. Ресурсы могут быть доступны в нескольких представлениях (например на нескольких языках, в разных форматах данных, иметь различный размер, иметь различную разрешающую способность) или различаться по другим параметрам.
Объект (entity)
Информация, передаваемая в качестве полезной нагрузки запроса или ответа. Объект состоит из метаинформации в форме полей заголовка объекта и содержания в форме тела объекта, как описано в разделе 7.
Представление (representation)
Объект включенный в ответ, и подчиняющийся обсуждению содержимого (Content Negotiation), что описано в разделе 12. Может существовать несколько представлений, связанных со специфическими состояниями ответа.
Обсуждение содержимого (content negotiation)
Механизм для выбора соответствующего представления во время обслуживания запроса, как описано в разделе 12. Представление объектов в любом ответе может быть обсуждено (включая ошибочные ответы).
Вариант (variant)
Ресурс может иметь одно, или несколько представлений, связанных с ним в данный момент. Каждое из этих представлений называется "вариант". Использование термина "вариант" не обязательно подразумевает, что ресурс подчинен обсуждению содержимого.
Клиент (client)
Программа, которая устанавливает соединения с целью посылки запросов.
Агент пользователя (user agent)
Клиент, который инициирует запрос. Как правило браузеры, редакторы, роботы (spiders), или другие инструментальные средства пользователя.
Сервер (server)
Приложение, которое слушает соединения, принимает запросы на обслуживание и посылает ответы. Любая такая программа способна быть как клиентом, так и сервером; наше использование данного термина относится скорее к роли, которую программа выполняет, создавая специфические соединения, нежели к возможностям программы вообще. Аналогично, любой сервер может действовать как первоначальный сервер, прокси-сервер, шлюз, или туннель (tunnel), изменяя поведение, основываясь на характере каждого запроса.
Первоначальный сервер (origin server)
Сервер, на котором данный ресурс постоянно находится или должен быть создан.
Прокси-сервер (proxy)
Программа-посредник, которая действует и как сервер, и как клиент с целью создания запросов от имени других клиентов. Запросы обслуживаются прокси-сервером, или передаются им, возможно с изменениями. Прокси-сервер должен удовлетворять требованиям клиента и сервера, согласно этой спецификации.
Шлюз (gateway)
Сервер, который действует как посредник для некоторого другого сервера. В отличие от прокси-сервера, шлюз получает запросы в качестве первоначального сервера для запрошенного ресурса; клиент запроса может не знать, что он соединяется со шлюзом.
Туннель (tunnel)
Программа-посредник, которая поддерживает соединение. Один раз созданный, туннель не рассматривается как часть HTTP связи, хотя туннель, возможно, был инициализирован запросом HTTP. Туннель прекращает существовать, когда оба конца соединения закрываются.
Кэш (cache)
Локальная память, в которой программа хранит сообщения ответов, и в которой располагается подсистема, управляющая хранением, поиском и стиранием сообщений. Кэш сохраняет ответы, которые могут быть сохранены, чтобы уменьшить время ответа и загрузку сети (траффик) при будущих эквивалентных запросах. Любой клиент или сервер может иметь кэш, но кэш не может использоваться сервером, который действует как туннель.
Кэшируемый (cachable)
Ответ является кэшируемым, если кэшу разрешено сохранить копию ответного сообщения для использования при ответе на последующие запросы. Правила для определения кэшируемости HTTP ответов определены в разделе 13. Даже если ресурс кэшируем, могут существовать дополнительные ограничения на использование кэшем сохраненной копии для сходного запроса.
Непосредственный (first-hand)
Ответ считается непосредственным, если он приходит непосредственно от первоначального сервера без ненужной задержки, возможно через один или несколько прокси-серверов. Ответ также является непосредственным, если его правильность только что была проверена непосредственно первоначальным сервером.
Точное время устаревания (explicit expiration time)
Время, определенное первоначальным сервером и показывающее кэшу, когда объект больше не может быть возвращен кэшем клиенту без дополнительной проверки правильности.
Эвристическое время устаревания (heuristic expiration time)
Время устаревания, назначенное кэшем, если не указано точное время устаревания.
Возраст (age)
Возраст ответа - время, прошедшее с момента отсылки, или успешной проверки ответа первоначальным сервером.
Время жизни (freshness lifetime)
Отрезок времени между порождением ответа и временем устаревания.
Свежий (fresh)
Ответ считается свежим, если его возраст еще не превысил время жизни.
Просроченнный (stale)
Ответ считается просроченным, если его возраст превысил время жизни.
Семантически прозрачный (semantically transparent)
Говорят, что кэш ведет себя "семантически прозрачным" образом в отношении специфического ответа, когда использование кэша не влияет ни на клиента запроса, ни на первоначальный сервер, но повышает эффективность. Когда кэш семантически прозрачен, клиент получает точно такой же ответ (за исключением промежуточных (hop-by-hop) заголовков), который получил бы, запрашивая непосредственно первоначальный сервер, а не кэш.
Указатель правильности (validator)
Элемент протокола (например, метка объекта или время последней модификации (Last-Modified time)), который используется, чтобы выяснить, является ли находящаяся в кэше копия эквивалентом объекта.
Протокол HTTP - это протокол запросов/ответов. Клиент посылает серверу запрос, содержащий метод запроса, URI, версию протокола, MIME-подобное сообщение, содержащее модификаторы запроса, клиентскую информацию, и, возможно, тело запроса, по соединению. Сервер отвечает строкой состояния, включающей версию протокола сообщения, код успешного выполнения или код ошибки, MIME-подобное сообщение, содержащее информацию о сервере, метаинформацию объекта, и, возможно, тело объекта. Связь между HTTP и MIME описана в приложении 19.4.
Большинство HTTP соединений инициализируется агентом пользователя и состоит из запроса, который нужно применить к ресурсу на некотором первоначальном сервере. В самом простом случае, он может быть выполнен посредством одиночного соединения (v) между агентом пользователя (UA) и первоначальным сервером (O).
цепочка запросов ---------------------> UA -------------------v------------------- O <----------------------- цепочка ответов
Более сложная ситуация возникает, когда в цепочке запросов/ответов присутствует один или несколько посредников. Существуют три основных разновидности посредников: прокси-сервера, шлюзы, и туннели. Прокси-сервер является агентом-посредником, который получает запросы на некоторый URI в абсолютной форме, изменяет все сообщение или его часть, и отсылает измененный запрос серверу, идентифицированному URI. Шлюз - это принимающий агент, действующий как бы уровень выше некоторого другого сервера(ов) и, в случае необходимости, транслирующий запросы в протокол основного сервера. Туннель действует как реле между двумя соединениями не изменяя сообщения; туннели используются, когда связь нужно производить через посредника (например Firewall), который не понимает содержание сообщений.
цепочка запросов -----------------------------------> UA -----v----- A -----v----- B -----v----- C -----v----- O <------------------------------------ цепочка ответов
На последнем рисунке показаны три посредника (A, B, и C) между агентом пользователя и первоначальным сервером. Запросы и ответы передаются через четыре отдельных соединения. Это различие важно, так как некоторые опции HTTP соединения применимы только к соединению с ближайшим не туннельным соседом, некоторые только к конечным точкам цепочки, а некоторые ко всем соединениям в цепочке. Хотя диаграмма линейна, каждый участник может быть задействован в нескольких соединениях одновременно. Например, B может получать запросы от других клиентов, а не только от A, и/или пересылать запросы к серверам, отличным от C, в то же время, когда он обрабатывает запрос от А.
Любая сторона соединения, которая не действует как туннель, может использовать внутренний кэш для обработки запросов. Эффект кэша заключается в том, что цепочка запросов/ответов сокращается, если один из участников в цепочке имеет кэшированный ответ, применимый к данному запросу. Далее иллюстрируется цепочка, возникающая в результате того, что B имеет кэшированую копию раннего ответа O (полеченного через C) для запроса, и который не кэшировался ни UA, ни A.
цепочка запросов -------> UA -----v----- A -----v----- B - - - - - - C - - - - - - O <-------- цепочка ответов
Не все ответы полезно кэшировать, а некоторые запросы могут содержать модификаторы, которые включают специальные требования, управляющие поведением кэша. Требования HTTP для поведения кэша в отношении кэшируемых ответов определены в разделе 13.
Фактически, имеется широкое разнообразие архитектур и конфигураций кэшей и прокси-серверов, в настоящее время разрабатываемых или развернутых в World Wide Web; эти системы включают национальные иерархии прокси-кэшей, которые сохраняют пропускную способность межокеанских каналов, системы, которые распространяют во много мест содержимое кэша, организации, которые распространяют подмножества кэшируемых данных на CD-ROM, и так далее. HTTP системы используются в корпоративных интранет-сетях с высокоскоростными линиями связи, и для доступа через PDA с маломощными линиями и неустойчивой связи. Цель HTTP/1.1 состоит в поддержании широкого многообразия конфигураций, уже построенных при введении ранних версий протокола, а также в удовлетворении потребностей разработчиков web приложений, требующих высокой надежности, по крайней мере надежных относительно индикации отказа.
HTTP соединение обычно происходит посредством TCP/IP соединений. Заданный по умолчанию порт TCP - 80, но могут использоваться и другие порты. HTTP также может быть реализован посредством любого другого протокола Интернета, или других сетей. HTTP необходима только надежная передача данных, следовательно может использоваться любой протокол, который гарантирует надежную передачу данных; отображение структуры запроса и ответа HTTP/1.1 на транспортные модули данных рассматриваемого протокола - вопрос, не решаемый этой спецификацией.
Большинство реализаций HTTP/1.0 использовало новое соединение для каждого обмена запросом/ответом. В HTTP/1.1, установленное соединение может использоваться для одного или нескольких обменов запросом/ответом, хотя соединение может быть закрыто по ряду причин (смотрите раздел 8.1).
назад | содержание | вперед