Стандартный протокол для передачи данных по Всемирной паутине -- это HTTP (HyperText Transfer Protocol -- протокол передачи гипертекста). Он описывает сообщения, которыми могут обмениваться клиенты и серверы. Каждое взаимодействие состоит из одного ASCII-запроса, на который следует один ответ, напоминающий ответ стандарта RFC 822 MIME. Все клиенты и все серверы должны следовать этому протоколу. Он определен в RFC 2616.
Соединения
Обычный способ взаимодействия браузера с сервером заключается в установке ТСР-соединения с портом 80 сервера, хотя формально эта процедура не является обязательной. Ценность использования TCP -- в том, что ни браузерам, ни серверам не приходится беспокоиться о потерянных, дублированных, слишком длинных сообщения и подтверждениях. Все это обеспечивается протоколом TCP.
В HTTP 1.0 после установки соединения посылался один запрос, на который приходил один ответ. После этого TCP-соединение разрывалось. В то время типичная веб-страница целиком состояла из HTML-текста, и такой способ взаимодействия был адекватным. Однако прошло несколько лет, и в странице оказалось множество значков, изображений и других украшений. Очевидно, что установка TCP-соединения для передачи одного значка нерациональна и слишком дорога.
Это соображение привело к созданию протокола HTTP 1.1, который поддерживал устойчивые соединения. Это означало, что появилась возможность установки TCP-соединения, отправки запроса, получения ответа, а затем передачи и приема дополнительных запросов и ответов. Таким образом, снизились накладные расходы, возникавшие при постоянных установках и разрывах соединения. Стало возможным также конвейеризировать запросы, то есть отправлять запрос 2 еще до прибытия ответа на запрос 1.
Несмотря на то что HTTP был разработан специально для использования в веб - технологиях, он был намеренно сделан более универсальным, чем это было необходимо, так как рассчитывался на будущее применение в объектно-ориентированных приложениях. По этой причине в дополнение к обычным запросам веб-страниц были разработаны специальные операции, называемые методами. Они обязаны своим существованием технологии SOAP. Каждый запрос состоит из одной или нескольких строк ASCII, причем первое слово является именем вызываемого метода. Встроенные методы перечислены в таблице на рис.6. Помимо этих общих методов, у различных объектов могут быть также свои специфические методы. Имена методов чувствительны к регистру символов, то есть метод GET существует, a get -- нет.
Рисунок 6 - Встроенные методы HTTP-запросов
Метод GET запрашивает у сервера страницу (под которой в общем случае подразумевается объект, но на практике это обычно просто файл), закодированную согласно стандарту MIME. Большую часть запросов к серверу составляют именно запросы GET.
Метод HEAD просто запрашивает заголовок сообщения, без самой страницы. С помощью этого метода можно узнать время последнего изменения страницы для сбора индексной информации или просто для проверки работоспособности данного URL.
Метод PUT является противоположностью метода GET: он не читает, а записывает страницу. Этот метод позволяет создать набор веб-страниц на удаленном сервере. Тело запроса содержит страницу. Она может быть кодирована с помощью MIME. В этом случае строки, следующие за командой PUT, могут включать различные заголовки, например, Content-Type или заголовки аутентификации, подтверждающие права абонента на запрашиваемую операцию.
Метод POST несколько напоминает метод PUT. Он также содержит URL, но вместо замены имеющихся данных новые данные «добавляются» (в неком общем смысле) к уже существующим. Это может быть публикация сообщения в конференции или добавление файла к электронной доске объявлений BBS. На практике ни PUT, ни POST широко не применяются.
Метод DELETE, что неудивительно, удаляет страницу. Как и в методе PUT, здесь особую роль могут играть аутентификация и разрешение на выполнение этой операции. Даже при наличии у пользователя разрешения на удаление страницы нет никакой гарантии, что метод DELETE удалит страницу, так как даже при согласии удаленного HTTP-сервера сам файл может оказаться защищенным от изменения или перемещения.
Метод TRACE предназначен для отладки. Он приказывает серверу отослать назад запрос. Этот метод особенно полезен, когда запросы обрабатываются некорректно и клиенту хочется узнать, что за запрос реально получает сервер.
Метод CONNECT в настоящее время не используется. Он зарезервирован для будущего применения.
Метод OPTIONS позволяет клиенту узнать у сервера о его свойствах или о свойствах какого-либо конкретного файла.
В ответ на каждый запрос от сервера поступает ответ, содержащий строку состояния, а также, возможно, дополнительную информацию (например, веб-страницу или ее часть). Строка состояния может содержать трехразрядный код состояния, сообщающий об успешном выполнении запроса или о причинах неудачи. Первый разряд предназначен для разделения всех ответов на пять основных групп, как показано в таблице на рис.7. Коды, начинающиеся с 1 Aхх), на практике используются редко. Коды, начинающиеся с 2, означают, что запрос был обработан успешно и данные (если их запрашивали) отосланы. Коды Зхх сообщают клиенту о том, что нужно попытать счастья в другом месте -- используя либо другой URL, либо свой собственный кэш.
Рисунок 7 - Группы кодов состояния, содержащиеся в ответах сервера
Коды, начинающиеся с 4, означают, что запрос по какой-либо причине, связанной с клиентом, потерпел неудачу: например, была запрошена несуществующая страница или сам запрос был некорректен. Наконец, коды 5хх сообщают об ошибках сервера, возникших либо вследствие ошибки программы, либо из-за временной перегрузки.
Пример использования HTTP
Поскольку HTTP является текстовым протоколом, взаимодействие с сервером посредством терминала (который в данном случае выступает как противоположность браузеру) можно организовать достаточно просто. Необходимо лишь установить TCP-соединение с портом 80 сервера. Читателю предоставляется возможность самому посмотреть, как работает этот сценарий (предпочтительнее запускать его в системе UNIX, поскольку некоторые другие системы могут не отображать статус соединения). Итак, последовательность команд такова:
Рисунок 8 - последовательность команд HTTP-протокола
Эта последовательность команд устанавливает telnet-соединение (то есть ТСР- соединение) с портом 80 веб-сервера IETF, расположенного по адресу www.ietf.org.
Результат сеанса связи записывается в файл log, который затем можно просмотреть. Далее следует команда GET. Указывается имя запрашиваемого файла и протокол передачи. Следом идет обязательная строка с заголовком Host. Пустая строка, которая находится за ней, также обязательна. Она сигнализирует серверу о том, что заголовки запросов закончились. Командой close (это команда программы telnet) соединение разрывается.
Файл журнала соединения, log, может быть просмотрен с помощью любого текстового редактора. Он должен начинаться примерно так, как показано в листинг на рис.8, если только на сайте IETF за это время не произошли какие-нибудь изменения.
Рисунок 9 - Начало вывода файла «www.ietf.org/rfc.html»
Первые три строки в этом листинге созданы программой telnet, а не удаленным сайтом. А вот строка, начинающаяся с HTTP/1.1, -- это уже ответ IETF, говорящий о том, что сервер желает общаться с вами при помощи протокола НТТР/1.1. Далее следует ряд заголовков и, наконец, само содержимое запрашиваемого файла. Заголовок ETag, который является уникальным идентификатором страницы, связанным с кэшированием, и X-Pad -- нестандартного заголовка, помогающего бороться с ошибками браузеров.
