Тема: протоколHTTP

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

Протокол HTTP (Hyper Text Transfer Protocol) — протокол обмена гипертекстовой информацией, то есть документами HTML. Вы наверное слышали, что HTML является базовым языком создания Web -страниц. Так вот, протокол HTTP предназначен для их передачи в сети. Таким образом, протокол HTTP используется Web -серверами. Соответственно, браузеры, используемые для блуждания по Интернету, являются HTTP -клиентам

Он является основным объектно-ориентированным протоколом, который может решать задачи управления обменом между серверами и объектами распределенных систем, используя их методы запросов. Основным направлением развития HTTP является определение типа и способов представления данных; применение систем, независимых от способа передачи данных. HTTP используется Word-Wide Web начиная с 1990 года. Первая версия НТТР - НТТР/0.9 - являлась простым протоколом передачи данных через Internet. В версии НТТР/1.0 добавлена возможность передачи сообщений в формате MIME, содержащем различную информацию о переданных данных и изменениях в семантике запрос/ответ. Однако, НТТР/1.0 полностью не удовлетворял требованиям открытой системы, надежного соединения и другим инструкциям, которые обеспечивают защиту вызванных приложений. Рассматриваемая версия НТТР - НТТР/1.1 полностью совместима с НТТР/1.0, но содержит более строгие требования для обеспечения совместимости с различными приложениями. Данный протокол позволяет расширять набор методов, которые определяют цель запросов. НТТР/1.1 разработан в соответствии с требованиями поддержки универсальных указателей идентификатора URI (Universal Resurse Identifier), ресурсов URL (Universal Resurse Location) и имени URN (Universal Resurse Name), для определения ресурса, к которому обратилось приложение. Сообщения передаются службами электронной почты (Internet Mail) и службами стандарта MIME (Multipurpose Internet Mail Extensions), разработанного с целью пересылки по электронной почте Internet любых типов данных. НТТР также используется как основной протокол для соединения агента пользователя и межсетевого шлюза с такими протоколами Internet как SMTP, NNTP, FTP, Gopher и WAIS, как протокол, позволяющий организовать гипер-доступ к ресурсам, доступным из различных приложений и облегчающий применение агентов пользователей. Описание протокола НТТР Протокол НТТР базируется на основе парадигмы запрос/ответ. Клиент посылает запросы серверу с указанием метода запроса, URI, версии протокола; сообщения передаются в соответствии со спецификацией MIME, содержащей информацию пользователя и поля, необходимые для установления соединения с сервером. Сервер, получив запрос, передает номер порта соединения, версию протокола соединения, сообщение об успешном соединении или ошибке при установлении сеанса, данные в соответствии со спецификацией MIME и служебные поля. Большинство соединений НТТР инициализируется агентом пользователя и состоит из запроса на доступ к ресурсам необходимого сервера. Более сложные ситуации возникают, когда в цепочке запрос/ответ присутствует процесс-посредник. Выделяют три формы процессов-посредников: заместитель, шлюз и туннель. Процесс-заместитель - это передающий агент, который принимает запрос для URI, перезаписывает все части сообщения и передает преобразованный запрос серверу, определяемому по параметрам URI. Шлюз (межсетевой) - это принимающий агент, выступающий в роли отдельного сетевого уровня, который, если необходимо, может передать запрос вышестоящим службам протоколов. Туннель - это коммутатор между двумя точками соединения, который не изменяет семантику сеанса; туннель используется, когда необходимо передать информацию через посредника в том случае, когда посредник не может определить тип передаваемой информации. Сообщения, направляемые в соответствии с цепочками запрос/ответ, должны пройти через четыре различных соединения. В Internet сеансы НТТР базируются на соединениях TCP/IP. По умолчанию используется порт 80, но возможно использование и других портов. Это не исключает возможности использовать НТТР как протокол прикладного уровня для других протоколов Internet или протоколов других сетей. НТТР предполагает наличие транспортного протокола; любой протокол, который удовлетворяет требованиям транспортного уровня, может использоваться для организации сеансов НТТР. Однако, функционирование НТТР/1.1 предполагает обеспечение устойчивого соединения. Как пользователь, так и сервер должны быть способны корректно обработать ситуации преждевременного завершения сеанса, истечения времени тайм-аута или ошибки программы. В любом случае прекращение сеанса одним или обоими абонентами всегда сопровождается уничтожением запросов, независимо от их статуса. Типы сообщений НТТР Сообщения НТТР состоят из запросов от программы-клиента к серверу и ответов сервера программе-клиенту. Существуют следующие типы сообщений: нулевой запрос, полный запрос, полный ответ. Нулевой запрос (пустая строка) всегда должен игнорироваться. Программа-клиент не должна посылать нулевой запрос, но возможны ситуации ошибок и тестирования, в которых нулевой запрос может быть послан как ошибочный, и он не должен являться причиной ошибки на сервере. Нулевой запрос имеет вид: Null-Reqest: CRLF. Сообщение полного запроса, передаваемое от программы-клиента к серверу включает метод доступа к ресурсу, идентификатор ресурса и версию используемого протокола. Для совместимости с более простым протоколом НТТР/0.9 используются две формы запросов НТТР: полный запрос и полный запрос с нулевым запросом (Full-Reqest | Null-Reqest). Полный запрос имеет вид:

Поле запроса	Основной Заголовок	Заголовок запроса	Заголовок объекта	Тело объекта
(Reqest-Line)	(General-Header)	(Reqest-Header)	(Entity-Header)	(Entity-Body)

Поле запроса состоит из метода доступа, идентификатора URI и версии протокола.

Поле “метод” определяет метод доступа к объекту, указанному в идентификаторе URI. Существуют следующие методы доступа:

 

	Conditional Get (условный) - когда в запросе используется поле If-Modified-Since. Метод Conditional Get означает, что определенный запросом объект будет передаваться в случае, если дата его модификации старше даты, указанной в поле If-Modified-Since;
	Partial Get (частный) - когда в запросе используется поле Range. Это позволяет определить, какую часть от определенного объекта требуется передать;

Options - метод запроса информации о параметрах соединения, используемых в цепочках запрос/ответ;

Get - метод нахождения объекта, определенного в поле URI запроса. В зависимости от семантики запроса выделяют две разновидности метода Get:

Head - метод, идентичный Get за исключением того, что сервер не должен возвращать объект (метаинформацию) в ответе. Этот метод может быть использован для получения информации об источнике, определенном по URI, без передачи сообщения;

Post - метод, посылающий все документы на сервер как второстепенные части одного из документов, определяемого по URI;

Put - метод, позволяющий поместить документ на сервер в соответствии с URI. Если URI указывает на уже существующий ресурс, то передаваемый объект должен быть воспринят как модифицированная версия уже существующего на сервере. Если существующий ресурс был изменен, то сервер передает сообщения 200 (“Оk”) или 204 (“не содержит”) для индикации правильного окончания запроса. Иначе, если URI не указывает на существующий ресурс, сервер может создать в соответствии с URI новый ресурс, запрашиваемый агентом пользователя. Если новый ресурс создан, то сервер должен проинформировать агента пользователя сообщением 201 (“создан”);

Delite - метод, использующийся для уничтожения ресурса на сервере по запросу URI;

Trace - метод, применяющийся для проверки корректности соединения. Конечный адресат в сети должен вернуть сообщение, посланное программой-клиентом с сообщением ответа 200 (“Ok”). Метод Trace не должен содержать тело объекта и должен включать поле Content-Lenght (текущая длина) заголовка запроса со значением 0.

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

	Cashe-Control - поле директив, используемое процессами буферизации при инициализации цепочек запрос/ответ;
	Connection - поле, позволяющее клиенту и серверу определить опции, которые используются только в процессе соединения;
	Date - поле, содержащее время и дату;
	Via - поле, включающее информацию о протоколе передачи и трафике сообщения от клиента к серверу при запросе и от сервера к клиенту при ответе;
	Upgrade - поле, позволяющее программе пользователя определять, какие дополнительно протоколы она поддерживает и готова использовать, если сервер имеет возможность на переключение протоколов. Сервер должен использовать поле Upgade, содержащее сообщение 101 (“переключение протоколов”), для индикации включенных протоколов.

Пример: Upgrade: HTTP/2.0, SHHTP/1.3, IRC/6.9,RTA/x11.

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

Accept - поле, которое может использоваться для определения множества медиатипов (media types), которые являются приемлемыми для ответа. Символ * используется для групп медиатипов, с символами */* используются все медиатипы, а “type/*” определяет все подтипы данного типа. Параметр диапазона q определяет значимость медиатипов в определенном диапазоне и определяет заинтересованность пользователя в конкретном медиатипе. По умолчанию q=1. В поле Accept, созданном клиентом НТТР/1.1, разделителем диапазона медиатипов от диапазона параметров является символ “:“. Сервер НТТР/1.1 должен корректно обрабатывать разделитель “;”, используемый в версии НТТР/1.0.

Например, выражение “Accept: audio/*: q=0.2, audio/basic” может быть интерпретировано как “Я предпочитаю данные audio/basic, но пошлите мне любые аудио данные после того, как передадите 80% требуемых”. Если поле Accept отсутствует, то программа-пользователь запрашивает любые типы данных.

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

Пример: Accept-Charset: ISO-8859-5

Если поле Accept-Charset отсутствует, то могут использоваться любые символы. Иначе передаваемые символы должны соответствовать символьным установкам.

	Поле Accept-Encoding содержит информацию об используемом методе уплотнения.
	Поле Accept-Language содержит информацию об используемом языке (En - английский; Da - датский и т.д.).

Пример: Accept-Language: da;

	Поле Authorization может использоваться для передачи информации программой пользователя о самой себе.
	Поле From может содержать e-mail адрес Internet для пользователя, который контролирует запросы программы-пользователя.

Пример: From: [e-mail].

	Поле Host определяет номера портов и хостов - источников в Internet. Оно должно содержать сетевой адрес сервера или межсетевого шлюза в формате URI. Если не указывается номер порта, то по умолчанию принимается номер 80.

Например, запрос к серверу < http: //www.w3.org/pub/WWW/> должен включать: Get /pub/WWW/HTTP1.1

Host: www/w3/org.

	Поле If-Modifided-Since используется совместно с методом Get для следующих целей: если запрашиваемый объект не был изменен со времени, указанного в поле, то копия объекта сервером передаваться не будет.
	Поле Referer позволяет программе клиента точно определить адрес (URI) источника. Это позволяет создать серверу внутренний список к ресурсам по интересам, регистрациям и т.д.
	Поле User-Agent содержит информацию об агенте пользователя. Это необходимо для определения статистики работы агента пользователя, для определения некорректной работы протоколов и автоматического распознавания агентов пользователей.
	Поле Max-Forward может использоваться с методом Trace для определения времени тайм-аута.

Принято, что поле протокола, содержащее данные, называется “полем данных” или просто “данные”. Для НТТР понятие “поле данных” слишком узкое и не отражает настоящего предназначения. Поэтому введен термин “объект”, поскольку запрашиваться/передаваться могут не только данные, но и различная метаинформация, такая как изображения, аудиоинформация, мультипликация и т.д. Полный запрос и полный ответ cодержат объект, который состоит из заголовка и тела.

Заголовок объекта содержит различную информацию о теле объекта, а если тело объекта отсутствует, информацию об источнике, определенном в URI. Заголовок объекта содержит следующие поля:

	Allow - поле содержит список установленных методов, поддерживаемых источником, определенном в URI.

Пример: Allow: Get, Head, Put.

	Content-Base - может быть использовано для спецификации базового URI с целью определения относительного URL в объекте.
	Content-Encoding - содержит информацию о типе кодирования, который был применен к источнику.
	Content-Language - поле содержит идентификатор языка, в формате которого передается информация.
	Content-Length - содержит размер объекта в десятичном виде.
	Content-Location - используется для определения адреса дополнительного источника, связанного с ссылкой в теле объекта.
	Content-Range - передается для определения размера блока сообщения, а также всей длины запрошенного/переданного объекта.

Пример: HTTP/1.0 206 Partial content

DATE: Wed, 22 Feb 1997 16: 00: 00 GMT

LAST MODIFIED: Wed, 22 Feb 1997 15: 50: 00 GMT

CONTENT-RANGE: 21010 - 47021 / 47022

CONTENT-LENGHT: 26012

CONTENT-TYPE: IMAGE / GIF

	Content-Type - содержит тип передаваемого объекта (тип метаинформации).
	Last-Modified - дата и время последней модификации объекта.
	Title - содержит название объекта.

Пример: Title: HTTP - Протокол передачи гипертекстов.

	Transfer-Encoding - содержит информацию о типе преобразования, который был применен к телу объекту для надежной передачи от источника к получателю.

Тело объекта передается вместе с запросом или ответом в формате, определенном в полях заголовка сообщения. Тело объекта передается с запросом в том случае, если метод вызывается однажды.

Сообщение ответа, не зависимо от того, присутствует или нет тело объекта, зависит как от метода запроса, так и от кода состояния. Все ответы при использовании метода HEAD, а также ответы с кодами 1хх (информационные), 204 (“не содержит”) и 304 (“не изменен”) не должны содержать тело объекта. Все остальные ответы должны содержать тело объекта или значение поля Content-Length, установленное в 0.

После того, как сервер примет и проанализирует запрос от клиента, он посылает в формате НТТР ответное сообщение, которое имеет следующий вид:

Поле состояния (Status-Line) содержит версию протокола, код состояния (status-code) и связанные со значением кода пояснения.

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

	1xx: информационный - запрос принят, процесс продолжается;
	2xx: успешное завершение - запрос был успешно принят, идентифицирован и обработан;
	3хх: переназначение - следующее действие должно быть обработано, чтобы завершить запрос;
	4хх: ошибка пользователя - запрос содержит неверный синтаксис или не может быть выполнен;
	5хх: ошибка сервера - сервер не может выполнить требуемый запрос.

Все возможные значения кода состояния приведены ниже:

Код состояния (Status-Code)

Пояснение (Reasone-Phrase)

415 416

Продолжение Переключение протоколов Норма Принят Создан Не авторитетная информация Не содержит Сбросить содержание Частично содержит Множественный выбор Перемещен постоянно Перемещен временно Смотри другой Не изменен Используй посредника Неверный запрос Неизвестен Необходима оплата Запретный Не найден Метод не может быть разрешен Не доступен Требуется идентификация посредника Тайм-аут запроса Конфликт Послан Необходима длина Предварительная ошибка Тело запроса слишком велико URI запроса слишком велико Неподдерживаемый тип медиатипов Не применим Внутренняя ошибка сервера Не выполнено Ошибка межсетевого шлюза Служба не доступна Тайм-аут межсетевого шлюза Версия НТТР не поддерживается

Основной заголовок, заголовок тела и тело объекта сообщения полного ответа идентичны соответствующим полям полного запроса.

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

	Location (местоположение) - используется для перенаправления приема информации к источнику, отличному от указанного в URI для завершения запроса или определения нового источника. Если поле состояния имеет значение 201, то поле Location будет содержать тот новый ресурс, который был создан запросом. Если поле состояния имеет значение 3хх, то Location должно содержать URL приоритетного сервера для автоматического переадресования ресурса.
	Proxy-Authenticate - поле используется совместно с полем состояния, значение которого равно 407. Параметры поля состояния из вызовов показывают параметры и схему идентификации посредника по запросу URI.
	Public (для общего использования) - содержит список нестандартных методов, поддерживаемых сервером. Пример: Public: OPTIONS, MGET, MHEAD.
	Retry-After (обратись после) - поле используется совместно с полем состояния, имеющим код 503, для индикации того, как долго служба не будет доступна по запросу клиенту. Значение поля может быть представлено как дата в формате НТТР или время в секундах после окончания запроса.

Пример: Retry-After: Wed, 14 Dec 1997 12: 12: 45 GMT

Retry-After: 180.

	Server - поле содержит информацию о программном обеспечении, используемом сервером при обращении запроса. Пример: Server: Cern / 3.0 libwww / 2.17.
	WWW-Authenticate - поле использует код поля состояния, значение которого равно 407. Параметры поля состоят по крайней мере из одного вызова, который показывает параметры и схему(ы) идентификации посредника по запросу URI.

Поле заголовка ответа может быть изменено/расширено только с измененной версией протокола. Неопределенные поля заголовков интерпретируются как тело объекта.

После установления соединения клиент НТТР посылает запрос. Запросы НТТР содержат методы доступа к объекту. Когда запрос будет послан, сервер имен начнет выполнять поиск хоста, указанного в URI запроса. После успешного завершения процедуры поиска начнется процесс установления соединения с сервером НТТР. Далее, в соответствии с методом запроса, сервер будет искать и готовить к передаче объекты, указанные в URI. Ответы сервера, помимо объекта, будут содержать коды состояния. Часто объекты содержат ссылки на другие объекты. Эти ссылки определяются с помощью синтаксиса языка гипертекстовых меток HTML. При инициализации метки автоматически формируется запрос к требуемому объекту, и алгоритм соединения и передачи объекта, описанный выше, повторяется снова.

Соглашения HTTP

Формат дата/время

Протокол НТТР поддерживает три различных формата представления информации о дате и времени:

	Sun, 22 Feb 1997 13:15:45 GMT (здесь GMT - время по Гринвичу);
	Sunday, 22 - Feb - 97 13:15:45 GMT;
	Sun Feb 22 13:15:45 1997.

Клиенты и серверы НТТР должны поддерживать все три формата, однако они должны создавать только первый формат для представления даты/времени в поле сообщения протокола НТТР.

Установка символов

Термин “установка символов” для НТТР подразумевает использования таблиц преобразования последовательности октетов в последовательность символов. Это определение позволяет использовать различные типы кодировок таблиц символов от самых простых, таких как US-ASCII, до комплексных таблиц, таких как ISO 2022.

Типы кодирования

Тип кодирования определяет способ преобразования объекта. Кодирование в основном используется для сжатия или криптографической защиты объекта доступа (информации). Тем самым обеспечивается семантическая защита сообщений и уменьшается объем передаваемой информации. Применяются следующие типы кодирования: gzip, x-gzip, compress, x-compress (gzip, compress соответствуют x-gzip, x-compress).

Кодирование gzip осуществляется программой GZIP. Этот формат соответствует кодированию Lempel-Ziv (LZ77) c 32-битовой проверочной последовательностью.

Кодирование compress осуществляется программой COMPRESS. Этот формат соответствует кодированию Lempel-Ziv-Welch (LZW).

Дата добавления: 2014-01-13