Чукарин А.В. Прикладные протоколы Интернет и World Wide Web

Подождите немного. Документ загружается.

возвращается результат выполнения этой программы, но не текст

программы. Дополнительные данные, которые надо передать для

обработки, кодируются в запрос ресурса. Имеется разновидность

метода GET – условный GET. При использовании этого метода сервер

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

передачи. Это позволяет разгрузить сеть, избавив ее от передачи

ненужной информации. Условие указывается в поле "if-Modified-Since"

заголовка запроса. При использовании метода GET в поле тела ресурса

возвращается собственно затребованная информация (текст HTML-

документа, например).

HEAD – метод, аналогичный GET, но не возвращает тела

ресурса. Используется для получения информации о ресурсе.

Условного HEAD не существует. Данный метод используется для

тестирования гипертекстовых ссылок.

POST – этот метод разработан для передачи большого объема

информации на сервер. Им пользуются для аннотирования

существующих ресурсов, посылки почтовых сообщений, работы с

формами интерфейсов к внешним базам данных и внешним

исполняемым программам. В отличие от GET и HEAD, в POST

передается тело ресурса, которое и является информацией из поля

форм или других источников ввода. В первых версиях протокола были

определены и другие методы доступа (DELETE, например), но они не

нашли должного применения. Многие функции, которые возлагали на

эти методы, можно успешно выполнять через POST.

Полная форма запроса содержит тип протокола доступа, адрес

сервера ресурса, и адрес ресурса на сервере (рис. 8.1).

Рис. 8.1. Полный адрес ресурса.

Однако такой адрес реально нужен для работы через

промежуточный сервер, т.к. тот может пересылать запросы. При

обращении к первичному серверу клиент может опускать протокол и

адрес, устанавливая взаимодействие с сервером по адресу, указанному в

URL (в исходном документе), и порту 80, передавая только путь от

корня сервера (упрощенный запрос).

8.1.3. Ответ сервера

Ответ сервера может быть, как и запрос, упрощенным или

полным. При упрощенном ответе сервер возвращает только тело

ресурса (например, текст HTML-документа). При полном ответе

клиенту возвращается строка состояния (Status-Line), общий заголовок,

заголовок ответа, заголовок ресурса и тело ресурса. В форме Бекуса-

Наура полный ответ представляется следующим образом:

<Полный ответ> := <Строка состояния> (<Общий заголовок>

|<Заголовок ответа>|<Заголовок ресурса>) <символ новой

строки>[<тело ресурса>]

Строка состояния состоит из версии протокола, кода возврата и

краткого описания этого кода. Например, она может выглядеть так:

"HTTP/1.0 200 Success".

Заголовок ответа сервера может состоять из адреса URI

запрашиваемого ресурса, и/или наименования программы сервера,

и/или кода идентификации для работы в защищенном режиме. Состав

полей заголовка ресурса является общим и для запроса клиента и для

ответа сервера, и состоит из разрешения на метод доступа, типа

кодировки тела ресурса (содержания ресурса), длины тела ресурса, типа

ресурса, время действия данной копии ресурса, времени последнего

изменения ресурса и расширения заголовка.

8.1.4. Защита сервера от несанкционированного доступа

Изначально разработка защищенных способов обмена данными

в системе World Wide Web не предполагалась. Однако быстрое развитие

популярности системы привело к тому, что многие коммерческие

организации стали устанавливать серверы HTTP на свои машины.

Кроме этого, конфиденциальной информации много и в научно-

исследовательских государственных организациях. Таким образом,

возникла необходимость в разработке механизмов защиты информации

для системы WWW.

На рисунке 8.2 показана принципиальная схема WWW-

технологии. Из этой схемы видно, что в этой технологии имеется как

минимум две потенциальные «дыры».

CGI

Рис. 8.2. Базовая архитектура World Wide Web.

Первая – связана с чтением защищенных текстовых файлов. Для

решения этой задачи имеется достаточно много традиционных

механизмов, встроенных в операционные системы. Проблема

возникает, если администратор системы решит использовать для

размещения WWW-файлов и FTP-архива одно и тоже дисковое

пространство. В этом случае защищенные WWW-файлы окажутся

доступными для «анонимного» FTP-доступа. Многие серверы

разрешают создавать в дереве поддерживаемых ими документов

«домашние» страницы пользователей с помощью методов POST и GET.

Это значит, что пользователи могут изменять информацию на

компьютере сервера. Данные, вводимые пользователем, передаются как

тело ресурса при методе POST через стандартный ввод, а методе GET

через переменные окружения. Естественно, что разрешение создания

файлов на сервере протокола HTTP создает потенциальную опасность

доступа к защищенной информации лиц, не имеющих права доступа к

ней. Решается эта проблема путем создания специальных файлов прав

пользователей сервера WWW.

Рис. 8.3. Схема управления ресурсов сервером HTTP.

Вторая возможность проникновения в компьютерную систему

через сервер WWW связана с CGI-скриптами, подробнее о которых см.

раздел 9. CGI-скрипт – это программа, которую сервер HTTP может

запускать для реализации механизмов, не предусмотренных в

протоколе. Многие достаточно мощные информационные механизмы

WWW реализованы посредством CGI-скриптов. К ним относятся:

программы поиска по ключевым словам, программы реализации

графических гипертекстовых ссылок – imagemap, программы

сопряжения с системами управления базами данных и т.п. Естественно,

что при этом появляется возможность получить доступ к системным

ресурсам. Обычно внешняя программа запускается с идентификатором

пользователя, отличным от идентификатора сервера. Данный

идентификатор указывается при конфигурировании сервера. Наиболее

безопасным здесь является идентификатор пользователя nobody (65534).

Основная опасность скриптов заключена в том, что данные в скрипт

посылаются программой-клиентом. Для того, чтобы в качестве

параметров не передавали «подозрительных» данных, многие серверы

производят проверку параметров на наличие допустимых символов.

Одной из характерных для скриптов проблем является размер входных

данных. Многие «умные» серверы обрезают слишком большие входные

потоки и тем самым защищают скрипты от «поломки».

Практически любой сервер имеет механизм назначения

паролей и прав доступа для различных пользователей, который

базируется на схеме идентификации протокола HTTP 1.0. Данная схема

предполагает, что программа-клиент посылает серверу идентификатор

пользователя и пароль. Понятно, что такой механизм не обеспечивает

защиты передаваемой по сети информации, и она может стать легкой

добычей злоумышленников.

Для того чтобы этого не происходило, в рамках WWW ведется

разработка других схем защиты. Они строятся на двух широко

известных принципах: контроль доступа по IP-адресам и шифрование.

Первый принцип реализован в программе типа «Firewall». Сервер

разрешает обращаться к себе только с определенных IP-адресов и

выполнять только определенные операции. Слабое место такого

подхода с точки зрения WWW заключается в том, что обратиться могут

через сервер-посредник (proxy), которому разрешен доступ к ресурсам

защищенного первичного сервера. Поэтому применяют шифрование

паролей и идентификаторов по аналогии с системой «Керберос». На

принципе шифрования построен протокол SHTTP (Secure HTTP).

8.1.5. Universal Resource Identifier – универсальный идентификатор.

Спецификация универсального адреса информационного ресурса в сети и

URL

Необходимость в URI была понятна разработчикам WWW c

момента зарождения системы, т.к. предполагалось объединение в

единую информационную среду средств, использующих различные

способы идентификации информационных ресурсов. Первоначально

это были FTP-архивы, информационно-поисковая система Alise, и

справочная система ЦЕРН. Однако исходная спецификация включала в

себя обращения к FTP, Gopher, WAIS, Usenet, E-mail, Prospero, Telnet,

Whois, X.500 и HTTP (WWW). В итоге была разработана универсальная

спецификация, которая позволяет расширять список адресуемых

ресурсов за счет появления новых схем.

Место применения URI – гипертекстовые ссылки, которые

записываются в тегах <A HREF=URI> и <LINK HREF=URI>.

Встраиваемые графические объекты также адресуются по

спецификации URI в тегах <IMG SRC=URI> и <FIG SRC=URI>.

Реализация URI для WWW называется URL (Uniform Resource Locator).

Точнее, URL – это реализация схемы URI, отображенная на алгоритм

доступа к ресурсам по сетевым протоколам. Существует еще и URN

(Uniform Resource Name), которое отображает URI в пространство имен

на сети.

8.1.6. Принципы построения адреса WWW

В основу URI были заложены следующие принципы:

• Расширяемость – новые адресные схемы должны были

легко вписываться в существующий синтаксис URI.

• Полнота – по возможности, любая из существовавших

схем должна была описываться посредством URI.

• Читаемость – адрес должен был быть легко читаем

пользователем, что вообще характерно для технологии

WWW – документы вместе с ссылками могут

разрабатываться в обычном текстовом редакторе.

Расширяемость была достигнута за счет выбора определенного

порядка интерпретации адресов, который базируется на понятии

«адресная схема». Идентификатор схемы стоит перед остатком адреса,

отделен от него двоеточием и определяет порядок интерпретации

остатка.

Полнота и читаемость порождали коллизию, связанную с тем,

что в некоторых схемах используется двоичная информация. Эта

проблема была решена за счет формы представления такой

информации. Символы, которые несут служебные функции, и

двоичные данные отображаются в URI в шестнадцатеричном коде и

предваряются символом «%».

Рассмотрим пример простого адреса URI:

http://rudn.ru/test/index.html.

Перед двоеточием стоит идентификатор схемы адреса – «http».

Это имя отделено двоеточием от остатка URI, который называется

«путь». В данном случае путь состоит из доменного адреса машины, на

которой установлен сервер HTTP и пути от корня дерева сервера к

файлу «index.html».

Кроме представленной выше полной записи URI, существует

упрощенная. Она предполагает, что к моменту ее использования

многие параметры адреса ресурса уже определены (протокол, адрес

машины в сети, некоторые элементы пути). При таких предположениях

автор гипертекстовых страниц может указывать только относительный

адрес ресурса, т.е. адрес относительно определенных базовых ресурсов.

8.2. Дополнительные сведения о протоколе HTTP

8.2.1 Использование сервера-посредника (прокси)

Промежуточная программа, которая выполняет функции, как

сервера, так и клиента. Такая программа предназначена для

обслуживания запросов так, как если бы это делал первичный сервер.

Запросы обслуживаются внутри или переадресуются другим серверам.

Туннель - промежуточная программа, которая работает как

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

стороны, соединенные им прерывают сессию. Туннель может быть

активирован с помощью HTTP-запроса.

Время пригодности объекта (expiration time) – время, при

котором исходный сервер требует, чтобы объект не посылался более

кэшем без перепроверки пригодности.

Эвристическое значение времени жизни (heuristic expiration

time) – время пригодности, присваиваемое объекту в кэше, если это

время не задано явно.

Возраст – возраст отклика ремя с момента его посылки или

проверки его пригодности исходным сервером.

Время жизни (freshness lifetime) - продолжительность времени с

момента генерации отклика до истечения его пригодности.

Семантическая прозрачность – кэш по отношению к

конкретному отклику функционирует в семантически прозрачном

режиме, когда его использование не имеет последствий ни для

исходного сервера, ни для запрашивающего клиента. Когда кэш

семантически прозрачен, клиент получает в точности тот же отклик (за

исключением транспортных заголовков), какой он бы получил при

непосредственном обращении к исходному серверу.

Валидатор – протокольный элемент (например, метка объекта

или время last-modified), который используется для выяснения того,

является ли запись в кэше эквивалентной копией объекта.

Метод - процедура, выполняемая над ресурсом (get, put, head,

post, delete, trace и т.д).

Рис. 8.4. Взаимодействие клиента, кэша и исходного сервера в протоколе

HTTP.

Кэш может находиться в ЭВМ клиента или агента пользователя,

но может размещаться на соседнем континенте. Число прокси между

клиентом и исходным сервером может варьироваться и ограничивается

сверху только здравым смыслом.

Рис. 8.5. Структура ресурса и объекта.

Протокол HTTP представляет собой протокол запросов-

откликов. Клиент посылает запрос серверу в форме, определяющей

метод, URI и версию протокола. В конце запроса следует MIME-

подобное сообщение, содержащее модификаторы, информацию о

клиенте и, возможно, другие данные. Сервер откликается, посылая

статусную строку, которая включает в себя версию протокола, код

результата (успех/неудача) и MIME-подобное сообщение, в котором

содержатся данные о сервере и метаинформация.

Большинство HTTP-обменов инициируются пользователем и

состоят из запросов ресурсов, имеющихся на определенном сервере. В

простейшем случае такой запрос может быть реализован путем

соединения пользовательского агента (UA) и базового сервера.

8.2.2. Status Code и Reason Phrase в протоколе HTTP/1.1

Status-Code это код результата попытки понять и выполнить

запрос. Состоит из трех цифр. Reason-Phrase – короткое текстовое

описание Status-Code. Status-Code предназначен для программ, Reason-

Phrase – для пользователя или администратора.

Первая цифра Status-Code определяет класс кода. Две

следующие цифры никак не категоризируются. Существует пять

классов кодов:

• 1xx: Информация – запрос принят, продолжение

процесса

• 2xx: Успех – запрос был успешно принят, распознан и

выполнен

• 3xx: Перенаправление – дальнейшее действие должно

быть перенаправлено для завершения запроса

• 4xx: Ошибка клиента – неверный синтаксис запроса или

недостаточно клиентских данных для выполнения

запроса

• 5xx: Ошибка сервера – невозможность выполнения

полностью появившегося запроса

Ниже представлена таблица наиболее распространенных

значений Status-Code и соответствующих им значений Reason-Phrase

для HTTP/1.1.

Таблица 8.1.

Status-

Code

Reason-Phrase

"304"

Not Modified (не изменялось)

"400"

Bad Request (неправильный запрос)

"401"

Unauthorized (неавторизованный запрос)

"403"

Forbidden (запрещено)

"404"

Not Found (не найдено)

"500"

Internal Server Error (внутренняя ошибка сервера)

"505"

HTTP Version not supported (неподдерживаемая версия

HTTP)

Status-Code расширяемы. От HTTP-приложений не требует

обязательное понимание всех зарегистрированных Status-Code. Однако

приложения обязаны понимать класс любого Status-Code (первая

цифра) и если встречен непонятный Status-Code, то приложения

должны отреагировать на такой код как на x00. К примеру, если принят

нераспознаваемый код со значением 431 – приложение должно

поступить, как будто бы был принят код 400. В таких случаях

приложениям следует возвращать пользователю нераспознанный код,

причем желательно в формате, пригодном для чтения.

8.3. Список вопросов для самоконтроля

а) Нарисуйте и поясните схему задействования сервера-

посредника в протоколе HTTP.

б) Каковы структуры ресурса и объекта?

в) Охарактеризуйте понятия URI, URL и URN.

г) Какие основные методы доступа по протоколу HTTP Вам

известны?

д) Приведите пример полной формы запроса к ресурсу.

е) Укажите основные принципы построения адреса в WWW.

ж) Какие базовые классы кодов статуса Вы знаете?

з) Если HTTP-сервер вернул статус-код, равный 177, как в

общем случае поступит HTTP-клиент?