2.2.2. Принципы построения HTTP-соединения

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

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

Рис. 2.3. Простая схема взаимодействия между клиентом и сервером HTTP

В более сложной ситуации, в процессе передачи данных принимают участие несколько промежуточных объектов (рис. 2.4). Они могут быть трех видов:

• Рroху представляет собой промежуточный агент, который принимает запрос клиента и, в зависимости от своих настроек, изменяет часть или все сообщение запроса и передает переформатированный запрос далее по цепочке, например, другим серверам или запрашиваемому серверу. В момент принятия запросов Proxy может работать как сервер, а при передаче запросов - как клиент. Proxy часто используется как ретранслятор протоколов внутренней сети в Internet и, как правило, представляет собой «главные ворота» выхода пользователей внутренней сети наружу.

• Gateway (шлюз) представляет собой промежуточный сервер. В отличие от proxy, шлюз принимает запросы клиента, будто он и есть запрашиваемый сервер и передает их далее. Работа шлюза совершенно прозрачна для клиента. Шлюз, как правило, используется как ретранслятор запросов или протоколов внешней сети во внутреннюю, к ресурсам сервера, т. е. это «главные ворота» входа пользователей внешней сети.

• Tunnel (туннель) представляет собой программу-посредник между двумя соединениями. Туннели используются в тех случаях, когда необходимо организовать поток данных через какой-либо промежуточный объект (например, тот же proxy), который не может интерпретировать структуру потока данных.

Рис. 2.4. Схема взаимодействия клиента и сервера через промежуточные объекты сети

На схеме показано соединение между клиентом и сервером с тремя промежуточными объектами («А», «В» и «С»). Сообщения запроса и ответа должны пройти через четыре отдельных канала, а каждый из промежуточных объектов может одновременно поддерживать несколько соединений. Например, «В» может получать одновременно запрос как от «А», так и от других клиентов, и передавать сообщения на «С» и на другие серверы.

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

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

Рис. 2.5. Схема использования кэша

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

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

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

HTTP-соединение должно открываться клиентом перед каждым запросом и закрываться сервером после отправки ответа. Как клиент, так и сервер должны иметь ввиду, что соединение может быть преждевременно закрыто либо пользователем, либо по истечении времени соединения, либо из-за сбоя системы.