HTTP
Материал из Cetki Wiki.
| Название: | Hypertext Transfer Protocol |
|---|---|
| Уровень (по модели OSI): | Прикладной |
| Семейство: | TCP/IP |
| Создан в: | 1990 г. |
| Порт/ID: | 80/TCP |
| Назначение протокола: | Доступ к гипертексту, ныне стал универсальным |
| Спецификация: | RFC 1945, RFC 2616 |
| Основные реализации: | {{{Реализации}}} |
| Основные реализации (клиенты): | Веб-браузеры, например Internet Explorer, Mozilla Firefox, Opera и др. |
| Основные реализации (серверы): | Apache, IIS |
| Расширяемость: | {{{Расширяемость}}} |
| Основные расширения: | {{{Основные расширения}}} |
HTTP (от англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — сетевой протокол прикладного уровня для передачи файлов. В стеке TCP/IP для HTTP зарезервированы[1] порты 80 и 8080 транспортных протоколов TCP и UDP (на практике используется только первый).
Основным назначением протокола HTTP является передача веб-страниц (текстовых файлов с разметкой HTML), хотя с помощью него с успехом передаются и другие файлы, как связанные с веб-страницами (изображения и приложения), так и не связанные с ними (в этом HTTP конкурирует с более сложным FTP).
HTTP предполагает, что клиентская программа — веб-браузер — способна отображать гипертекстовые веб-страницы и файлы других типов в удобной для пользователя форме.
Для правильного отображения HTTP позволяет клиенту узнать язык и кодировку веб-страницы и/или запросить версию страницы в нужных языке/кодировке, используя обозначения из стандарта MIME.
Содержание |
История развития
HTTP/0.9
HTTP был предложен в марте 1991 года Тимом Бернерсом-Ли, работавшим тогда в CERN, как механизм для доступа к документам в Интернете и облегчения навигации посредством использования гипертекста. Самая ранняя версия протокола HTTP/0.9 была впервые опубликована в январе 1992 г. (хотя реализация датируется 1990 годом). Спецификация протокола привела к упорядочению правил взаимодействия между клиентами и серверами HTTP, а также чёткому разделению функций между этими двумя компонентами. Были задокументированы основные синтаксические и семантические положения.
HTTP/1.0
В мае 1996 года для практической реализации HTTP был выпущен информационный документ RFC 1945, что послужило основой для реализации большинства компонентов HTTP/1.0.
HTTP/1.1
Последняя версия протокола. Последняя версия стандарта была принята в июне 1999 года[2]. Новым в этой версии был режим «постоянного соединения»: TCP-соединение может оставаться открытым после отправки ответа на запрос, что позволяет посылать несколько запросов за одно соединение. Клиент теперь обязан посылать информацию об имени хоста, к которому он обращается, что сделало возможным более простую организацию виртуального хостинга.
Структура протокола
HTTP — протокол прикладного уровня, аналогичными ему явлются FTP и SMTP. Обмен сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные URI. В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.
Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:
- Стартовая строка (англ. Starting line) — определяет тип сообщения;
- Заголовки (англ. Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения;
- Тело сообщения (англ. Message Body — непосредственно данные сообщения.
Заголовки и тело сообщения могут отсутствовать, но стартовая строка является обязательным элементом, так как указывает на тип запроса/ответа. Исключением является версия 0.9 протокола, у которой сообщение запроса содержит только стартовую строку, а сообщения ответа только сообщение.
Стартовая строка
Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:
- GET URI для версии протокола 0.9.
- Метод URI HTTP/Версия для остальных версий.
Здесь:
- URI определяет путь к запрашиваемому документу.
- Метод (англ. Method) — английское слово в верхнем регистре, указывающее тип запроса. В версии HTTP 0.9 использовался только метод GET.
- Версия (англ. Version) — пара разделённых точкой арабских цифр. Например: 1.0.
Чтобы запросить странницу данной статьи клиент должен передать строку:
- GET /wiki/Http HTTP/1.0
Стартовая строка ответа сервера имеет следующий формат:
- HTTP/Версия КодСостояния Пояснение
Здесь:
- Версия — пара разделённых точкой арабских цифр как запросе.
- КодСостояния (англ. Status Code) — три арабские цифры. По коду статуса определяется дальнейшее содержимое сообщение и поведение клиента.
- Пояснение (англ. Reason Phrase) — текстовое короткое пояснение к коду ответа для пользователя. Никак не влияет сообщение и является необязательным.
Например, на предыдущий наш запрос клиентом данной страницы сервер ответил строкой:
- HTTP/1.0 200 Ok
Методы
- OPTIONS
- Возвращает методы HTTP, которые поддерживаются сервером. Этот метод может служить для определения возможностей веб-сервера.
- GET
- Запрашивает содержимое указанного ресурса. Запрашиваемый ресурс может принимать параметры (например, поисковая система может принимать в качестве параметра искомую строку). Они передаются в строке URI (например:
http://www.example.net/resource?param1=value1¶m2=value2). Согласно стандарту HTTP, запросы типа GET считаются идемпотентными[3] — многократное повторение одного и того же запроса GET должно приводить к одинаковым результатам (при условии, что сам ресурс не изменился за время между запросами). Это позволяет кэшировать ответы на запросы GET. - HEAD
- Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Это полезно для извлечения мета-информации, заданной в заголовках ответа, без пересылки всего содержимого.
- POST
- Передаёт пользовательские данные (например, из HTML-формы) заданному ресурсу. Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами — текст комментария) включаются в тело запроса. В отличие от метода GET, метод POST не считается идемпотентным[3], то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться одна копия этого комментария).
- PUT
- Загружает указанный ресурс на сервер.
- DELETE
- Удаляет указанный ресурс.
- TRACE
- Возвращает полученный запрос так, что клиент может увидеть, что промежуточные сервера добавляют или изменяют в запросе.
- CONNECT
- Для использования вместе с прокси-серверами, которые могут динамически переключаться в туннельный режим SSL.
В основном используются методы GET и POST.
Коды состояния
Код состояния является частью первой строки ответа сервера. Он представляет из себя целое число из 3 арабских цифр. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая указывает на причину именно такого ответа.
Клиент узнаёт по коду ответа о результатах его запроса и определяет какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и все они описаны в соответствующих документах RFC. Введение новых кодов должно производится только после согласования с IETF. Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода.
В настоящее время выделено пять классов кодов состояния.
- 1xx Informational (Шаблон:Lang-ru)
- В этот класс выделены коды, информирующие о процессе передачи. В HTTP/1.0 сообщения с такими кодами должны игнорироваться. В HTTP/1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего серверу отправлять не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-сервера подобные сообщения должны отправлять дальше от сервера к клиенту.
- 2xx Success (Шаблон:Lang-ru)
- Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.
- 3xx Redirection (Шаблон:Lang-ru)
- Коды статуса класса 3xx сообщают клиенту что для успешного выполнения операции нужно произвести следующий запрос к другому URI. В большинстве случаев новый адрес указывается в поле Location заголовка. Клиент в этом случае должен, как правило, произвести автоматический переход (жарг. редирект).
- Обратите внимание, что при обращении к следующему ресурсу можно получить ответ из этого же класса кодов. Может получиться даже длинная цепочка из перенаправлений, которые, если будут производится автоматически, создадут чрезмерную нагрузку на оборудование. Поэтому разработчики протокола HTTP настоятельно рекомендуют после второго подряд подобного ответа обязательно запрашивать подтверждение на перенаправление у пользователя (раньше рекомендовалось после 5-го). За этим следить обязан клиент, так как текущий сервер может перенаправить клиента на ресурс другого сервера. Клиент также должен предотвратить попадание в круговые перенаправления.
- 4xx Client Error (Шаблон:Lang-ru)
- Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов кроме HEAD сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.
- 5xx Server Error (Шаблон:Lang-ru)
- Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.
Заголовки
Заголовки HTTP — это строки, каждая из которых состоит из имени параметра, за которым следует двоеточие и его значение. Они несут информацию для браузера или для серверных программ (таких, как CGI-приложения). Между заголовками и телом обязательно должна быть пустая строка.
Тело сообщения
Пример диалога HTTP
Запрос:
GET /wiki/HTTP HTTP/1.1 Host: ru.wikipedia.org User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Connection: close
Ответ:
HTTP/1.0 200 OK Server: Apache Content-Language: ru Content-Type: text/html; charset=utf-8 Content-Length: 1234
(далее следует текст запрошенной страницы)
