Кришнамурти Б., Рексфорд Дж. Web-протоколы. Теория и практика

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

520

Часть VL Перспективы исследований

ляр,

исходный сервер может просто отправить сам экземпляр. Сервер может

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

если при этом затраты для исходного сервера не увеличиваются. Например,

исходный сервер может посчитать для себя более выгодным генерировать раз-

ность в одном избранном формате, предпочтя его всем другим. Если исходный

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

зующих определенный дельта-механизм, он может выбрать этот механизм, да-

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

ным для обратившегося с запросом клиента. Принятие решения, какие разно-

сти кэшировать и как долго хранить кэшированные значения, представляют со-

бой дополнительные задачи, которые должен решать исходный сервер.

Преобразование HTTP-сообщения. К основным действиям но преобразованию

HTTP-сообщений, описанным в [MKD^Ol], относятся следующие:

• Идентификация запрашиваемого ресурса сервером.

• Выбор варианта ресурса.

• Генерирование тела, ассоциированного с

экземпляром

(но не с содержимым)

ресурса.

• Формирование дельта-кодировангюго содержимого.

• Передача дельта-кодировахнюго сообщения.

На каждом из этапов сервер может принять решение не генерировать разность:

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

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

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

одной из форм манипулирования экземплярами. Это важно, поскольку клиент, до-

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

зона или диапазон дельта-кодированного экземпляра. При наличии возможности

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

сти,

а клиент должен четко задавать последовательность, чтобы ответ не был дву-

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

ций над экземплярами, был введен новый заголовок запроса. Чтобы сервер мог за-

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

экземплярами, был введен новый заголовок ответа.

Исследование основных этапов обработки разности. Существуют следующие

основные этапы обработки запроса клиента и ответа с кодированием разности:

• Клиент выражает свой интерес в применении дельта-кодирования.

• Сервер вычисляет и передает соответствующую разность.

• Осуществляется взаимодействие.

• Клиенту становятся доступными несколько экземпляров ресурса.

Сначала клиент выражает свою заинтересованность и возможность применения

дельта-механизма с помощью заголовка A-IM (Accept-Instance-Manipulation), ко-

торый задает множество приемлемых алгоритмов вычисления разности. Например,

GET /chap15.htrnl HTTP/1.1

Host: www.vcdiff.com

If-None-Match: "38432-s8-13"

A-IM:

vcdiff, diffe, gzip

Глава

15.

Перспективы исследований протоколов

521

означает, что клиент предпочитает в первую очередь кодирование

vcdiff,

а во вто-

рую очередь кодирование

diffe

для разности и

gzip

в качестве формата сжатия, даже

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

If-None-Match идентифицирует экземпляр, к которому следует применять дель-

та-механизм. Как и во всех других случаях, сервер может возвращать ответ 304 Not

Modified, если текущий экземпляр ресурса chaplS.html совпадает с вариантом,

связанным с атрибутом содержимого "38432-s8-13". Если текущий ресурс имеет

другой атрибут содержимого, сервер, допускающий применение дельта-механизма,

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

рый ссылается атрибут содержимого "38432-s8-13". Клиент предпочитает использо-

вать алгоритм

vcdiff,

и сервер должен попытаться применить именно этот механизм

вычисления разности, если такое возможно.

Сервер может принять решение не вычислять разность. На это есть несколько

причин. Например, сервер имеет основание предположить, что ответ, содержащий

разность, будет иметь больший размер, чем текущий экземпляр ресурса. Сервер

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

на прошлом опыте применения механизма кодирования. Сервер может иметь кэ-

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

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

иметь вид, подобный следующему:

НТТР/1.1

226 IM

Used

Date:

Sun,

Jul 2000 23:35:35

GMT

ETag: "192-qpt-899"

IM: vcdiff

Сервер использует новый код ответа 226 IM Used и заголовок ответа IM, указы-

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

вый атрибут содержимого (192-qpt-899), который будет предположительно сохра-

нен прокси-сервером или клиентом для дальнейшего использования.

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

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

извлечь часть разности:

GET /foo.html НТТР/1.1

Host: www.vcdiff.cofn

If-None-Match: "38432-s8-13"

A-IM:

vcdiff, range

Range: bytes=0-200

Сервер может отправить ответ, подобный следующему:

НТТР/1.1 226 IM Used

Date:

Men, 20 Nov 2000 11:48:45 GMT

ETag:

"192-pqr-99"

IM: vcdiff, range

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

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

"38432-S8-13",

а затем извлек первые 201 байт этого кодированного с помощью

vcdiff экземпляра. Обратите внимание, что заголовок Instance Manipulation (IM)

522

Часть

VI.

Перспективы исследований

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

кодирование разности с последующим извлечением диапазона.

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

ляет ввести новый код ответа. Поскольку большинство существующих на сего-

дняшний день прокси-серверов не поддерживают даже последнюю версию HTTP,

маловероятно, что в ближайшем будущем прокси-серверы смогут поддерживать

дельта-механизм. Большинство прокси-серверов игнорирует коды ответов, которые

они не понимают, и пересылают эти ответы, не кэшируя их; следовательно, они бу-

дут вести себя аналогичным образом и для ответов с новым кодом 226 IM Used.

Прокси-сервер, который не поддерживает дельта-механизм, но ошибочно кэширует

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

бен обработать разность. При использовании нового кода ответа 226 IM Used про-

кси-сервер, не воспринимающий дельта-механизм, скорее всего не будет кэширо-

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

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

на этот же ресурс позднее.

Клиент может иметь различные кэшированные экземпляры, для которых он хо-

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

ности для одного из этих нескольких экземпляров. В таких случаях клиент может

воспользоваться существующим заголовком If-None-Match для указания всех

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

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

GET /chap15.html НТГР/1.1

Host: www.vcdiff.com

If-None-Match: "38432-s8-13". "97-ru486-v", "2-dumbya-1f"

A-IM:

vodiff, diffe. gzip

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

пускается получение разности. Сервер может воспользоваться эвристикой при

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

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

НТТР/1.1 226 IM Used

Date:

Sun, 2 Jul 2000 23:35:35 GMT

ETag:

"282-ela-899"

IM:

vodiff

Delta-Base: "97-ru486-v"

Сервер выбирает экземпляр с атрибутом содержимого "97-ru486-v" в качестве

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

указывается в новом заголовке Delta-Base. Поле ETag в ответе с разностью иден-

тифицирует текущий экземпляр ответа. Клиент теперь знает, как реконструировать

последнюю версию ресурса. Если экземпляр, для которого создавалась разность, не

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

идентифицировать базовый экземпляр. Сервер просто возвращает разность для

этого базового экземпляра и не обязан предоставлять какую-либо дополнительную

информацию.

На рис. с 15.1 по 15.4 представлены упрощенные версии этапов обработки раз-

ности. Клиент имеет в своем кэше экземпляр vl ресурса г с ассоциированным

с ним атрибутом содержимого "xyz", полученным от исходного сервера А. Теперь

предположим, что юшент отправляет запрос па ресурс исходному серверу А, а в за-

Глава

15.

Перспективы исследований протоколов

523

Клиент

Кэш

[УТ]

GET г

lf~None-Match: xyz

Исходный

сервер А

v1 (ETag = xyz)

v2 (ETag = abc)

Рис. 15.1. Клиент запрашивает ресурс г с исходного сервера

головке If-None-Match запроса указан атрибут содержимого ETag экземпляра, ко-

торый он имеет в своем кэше (рис. 15.1).

Исходный сервер имеет новый экземпляр ресурса, а именно v2, с ассоциирован-

ным с ним атрибутом содержимого "abc". Исходный сервер А формирует разность

между экземплярами vl и v2 и возвращает ее клиенту вместе с атрибутом содер-

жимого нового экземпляра, а именно, "abc" (рис. 15.2). Клиент реконструирует те-

кущий экземпляр ресурса г на основе кэшированного экземпляра vl и разности.

Клиент

Кэш

[vl]

delta (vl ,v2)

ETag:

abc

Исходный

сервер A

vl (ETag = xyz)

v2 (ETag = abc)

Рис.

15.2. Исходный сервер возвращает разность относительно экземпляра vl

На рис. 15.3 представлен клиентский запрос на этот же ресурс, когда клиент

имеет два кэшированных экземпляра vl и v2.

Текущим является экземпляр v3. Исходный сервер вычисляет разность между

экземплярами v2 и v3, значение атрибута содержимого для нового экземпляра

"pqr". Он также включает заголовок Delta-Base со значением "abc", чтобы уведо-

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

разность, был v2 (рис. 15.4).

524

Часть

VI.

Перспективы исследований

Клиент

Кэш

[УТ|

GET г

If-None-Match: xyz, abc

•• • • - ^

Исходный

сервер А

v1 (ETag = xyz)

v2 (ETag = abc)

v3 (ETag = pqr)

Рис.

15.3. Клиент запрашивает ресурс г, указывая свои кэшироваииые экземпляры

Исходный

сервер А

Клиент

Кэш

[У2]

delta (v2,v3)

ETag:

pqr

Delta-Base: abc

^ . -.„ ,

v1 (ETag = xyz)

v2 (ETag = abc)

v3 (ETag = pqr)

Рис.

15.4. Исходный сервер возвращает разность между текущим экземпляром и

экземпляром v2

Сервер должен решить, сколько базовых экземпляров хранить, а также как дол-

го.

Такое решение, подобно решению по замещению содержимого кэша, принима-

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

вого экземпляра, хранимого сервером, в зависимости от сделанного клиентом вы-

бора сервер должен принять ряд решений. Например, сервер должен принять

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

вариаггг, либо выбирать один вариант случайно. Сервер также должен выбрать

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

жащие замещению, на новые экземпляры. Проблемы, связанные с такой стратеги-

ей,

не рассматриваются в данном предложении, не обсуждались при подготовке ра-

бочего проекта но использованию дельта-механизма.

Глава

15.

Перспективы исследований протоколов

525.

15.2.4.

Текущее состояние дел с внедрением

дельта-механизма в НТТР/1.1

Предложенная версия стандарта на момент издания этой книги рассматривает-

ся IETF. Имеются, по меньшей мере, две известные реализации предложения.

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

ситетов работают над этим.

15.3.

Совместимость с протоколом НТТР/1.1

По мере распространения HTTP/1.1 стали появляться многочисленные реали-

зации браузеров, прокси-серверов и Web-серверов. В достаточно короткое время

перестройка рынка программных Web-компонентов привела к появлению несколь-

ких доминирующих продуктов. В конце 1999 года три Web-сервера: Apache,

Microsoft/IIS и Netscape-Enterprise занимали свыше 95% рынка. Годом позже,

в конце 2000 г., эти три Web-сервера по-прежиему доминировали, хотя их доли на

рынке несколько изменились. Среди браузеров популярными остаются два основ-

ных (Internet Explorer и Netscape Navigator), каких-либо изменений здесь не пред-

видится.

Проблемы, связанные со следованием спецификации протокола, выражены дос-

таточно прямолинейно: являются ли реализации совместимыми с требованиями,

которые присутствуют в протоколе? В главе 6 (раздел 6.5) мы говорили о различ-

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

зации протокола. Чтобы реализация считалась совместимой со спецификацией

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

(Обязательно), SHOULD (Желательно) и MAY (Возможно) для синтаксиса и се-

мантики. Любая реализация, которая не удовлетворяет всем требованиям уровня

MUST, считается

несовместимой

со спецификацией протокола. Реализация, удов-

летворяющая всем требованиям уровней MUST и SHOULD, является безусловно

совместимой. Если соблюдаются не все требования уровня SHOULD, реализация

считается условно совместимой.

Как ни странно, какие-либо механизмы для выяснения, отвечают ли программ-

ные реализации (хотя бы несколько из наиболее популярных) требованиям со-

вместимости с НТТР/1.1, отсутствуют. В этом разделе мы рассмотрим, как прове-

рить,

какие из требований HTTP, описанные в документе RFC 2616, учитываются

в реализации сервера. Мы также поговорим, к чему может привести несовмести-

мость с требованиями спецификации. Материал этого раздела основан на данных

отчета [КА01] по результатам проведения первого масштабного и продолжитель-

ного исследования совместимости со спецификацией HTTP, проведенного в тече-

iHie 16 месяцев с июня 1999 г. по сентябрь 2000 г. Мы рассмотрим методологию

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

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

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

ний изменялась. Результаты, однако, не расходились с теми, которые были получе-

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

неизменной во время проведения исследований.

526

Часть VL Перспективы исследований

15,3.1.

Мотивация для проведения исследований

совместимости со спецификацией протокола

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

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

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

трафика, использующего определенную версию протокола. Администраторы сай-

тов могут воспользоваться информацией о степени распространения версий прото-

кола, чтобы принять решение, следует ли переходить на новую версию. Исследова-

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

ленная функция не получила широкого распространения, обеспечивают полезную

обратную связь. Разработчики могут попытаться понять, почему некоторые функ-

ции были быстро восприняты, а другие нет.

Взаимная совместимость различных реализаций клиентов, прокси-серверов и

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

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

няющим фактором, гарантирующим должное функционирование обменов данными

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

других компонентов. Если браузер не уверен, что определенный запрос будет вос-

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

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

Задача прокси-сервера и так достаточно сложна, принимая во внимание, что он дол-

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

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

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

задач может значительно возрасти. Хотя совместимые реализации могут быть уязви-

мыми для атак, связанных с отказом от обслуживания, или других гюпыток наруше-

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

15-3,2.

Тестирование совместимости клиентов

и прокси-серверов

Проблемы совместимости для серверов поднимают вопрос и о совместимости

двух других основных Web-компонентов: клиентов и прокси-серверов. Тестирова-

ние совместимости клиентов обычно более простая операция, чем тестирование со-

вместимости серверов. Браузеры дают возможность настраивать некоторые из сво-

их параметров. Например, IE 5.0 позволяет пользователю выбирать, какую версию

протокола использовать (НТТР/1.0 или НТТР/1.1). Выбор при этом делается не

между НТТР/1.0 и НТТР/1.1 в целом, но между подмножеством функций, харак-

терных для НТТР/1.1. Что еще более важно, реализованы ли доступные функции

совместимым образом. Например, браузер может объявить о реализации функции

запроса диапазона Range НТТР/1.1, но посылать запросы без указания диапазонов

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

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

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

заголовков, включенных в запросы. Группа заголовков ответов также может быть

легко перехвачена. Требования протокола применительно к клиентам обычно ме-

нее строгие. Выполнить проверку их соблюдения для клиентов, как правило, про-

ще,

чем для серверов.

Глава

15.

Перспективы исследований протоколов

527

Тестирование совместимости прокси-серверов

—

гораздо более сложная задача.

Спецификация протокола по большей части умалчивает о специфических прави-

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

кси-сервер является и клиентом, и сервером, совместимый прокси-сервер должен

представлять собой и совместимый клиент, и совместимый сервер. Хотя это об-

стоятельство и увеличивает сложность прокси-сервера как программного компо-

нента, тестирование его на совместимость затруднено по другим причинам.. Со-

вместимость прокси-сервера с протоколом должна тестироваться и при работе его

в качестве клиента, и при работе его в качестве сервера. Для направления запроса

в Internet через прокси-сервер требуется разрешение. Хотя имеется ряд про-

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

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

числительных ресурсов. Даже если разрешение на выполнение тестирования со-

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

прокси-сервер посылает серверу, не будет известно. Конфигурации различных про-

кси-серверов существенно различаются

—

системные администраторы часто моди-

фицируют конфигурацию прокси-серверов для кэширования. Что еще более важ-

1Ю,

пока лишь малое число прокси-серверов соответствуют

,НТТР/1.1.

Еще более

осложняет ситуацию то обстоятельство, что некоторые прокси-серверы НТТР/1.0

реализуют ряд функций НТТР/1.1. Путь HTTP-сообщения между клиентом и ис-

ходным сервером может проходить через несколько прокси-серверов, некоторые из

которых совместимы с НТТР/1.0, а другие — с НТТР/1.1. Прокси-серверы, со-

вместимые с НТТР/1.1, могут выявляться по наличию заголовков Via, а про-

кси-серверы, совместимые с НТТР/1.0, идентифицировать невозможно. Имеет

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

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

тов,

совместимых с НТТР/1.1.

В оставшейся части раздела основное внимание уделяется тестированию со-

вместимости серверов.

15.3-3.

Методология тестирования на совместимость

Ниже перечислены способы тестирования на совместимость с протоколом:

• Разработчики компонентов могут обратиться к таблице [FeaJ, сформирован-

ной Консорциумом Всемирной паутины (W3C) и содержащей различные

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

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

протоколом. Однако в реальности это не всегда так.

• Программное обеспечение может подвергаться многократным тестам, часть из

которых представляет собой тесты на совместимость. На практике это не

слишком широко распространено. Большинство тестов проверяют, способен

ли компонент справиться с большим потоком запросов (для серверов) и спо-

собен ли отображать произвольные ответы (для браузеров). Однако нельзя

сказать, что тесты на совместимость являются составной частью используе-

мых тестов.

• Серверы могут быть проверены в

оперативном

режиме путем отправки запро-

сов с удаленных клиентов. Это хороший способ тестирования различных сер-

веров. Каждый Web-сервер можно тестировать путем создания запросов груп-

пой клиентов и контроля корректности ответов.

528

Часть VL Перспективы исследований

Последний подход наиболее пригоден для тестирования совместимости, по-

скольку тестирование работающего Web-сервера само по себе дает достаточно реа-

листичный ответ на вопрос о совместимости. Web-серверы, как мы видели в главе

4 (раздел 4.6), настраиваются по многими параметрами, каждый из которых может

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

Web-сервер Apache имеет около 700 комбинаций параметров настройки [КА01].

Таким образом, выполнять тесты локально с перебором всех возможных комбина-

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

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

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

Кроме того, некоторые запросы могут иметь побочные эффекты. Мгюгие запросы

изменяют содержание сайта, а сценарии требуют для своего выполнения определен-

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

тов с помощью локальных настроек не может быть реализована.

Приняв решение тестировать работающие Web-серверы, мы должны выбрать,

какие серверы из миллионов имеющихся следует тестировать. Ниже приведены не-

которые способы выбора серверов:

• Выборочный метод. Выборочный метод предполагает выбор случайного под-

множества серверов из нескольких миллионов имеющихся. Однако при этом

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

каждого типа сервера. Исчерпывающее тестирование одного сервера во всех

возможных конфигурациях является непрактичным решением.

• Функциональное назначение. Ранее, в главе 4 (раздел 4.1), мы познакоми-

лись с различными способами классификации сайтов на основе их функцио-

нального назначения. Выбор серверов может также осуществляться по тому

же принципу: внутренний сайт компании, новостной сайт, портал, сайт поис-

ковой системы, сайт электронной коммерции и т.д. Степень совместимости

серверов может варьироваться в зависимости от функционального назначения

сайта. Еще более важно, что несоответствие сервера определенным требовани-

ям может иметь большее значение для одних сайтов по сравнению с другими.

Например, для сайта электронной коммерции отсутствие совместимости мо-

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

Это связано с тем, что сервер электронной коммерции с большей вероятно-

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

корпоративный сайт. Таким образом сделать разумный выбор на основе толь-

ко функционального назначения довольно трудно.

• Популярность. Другой подход учитывает популярность

Web-сайтов,

реализа-

цию Web-сервера и параметры настройки. Исследования популярных сайтов

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

сов.

Принимая во внимание это обстоятельство, можно предположить, что для

тестирования совместимости серверов достаточно будет рассмотреть йесколь-

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

вающих степень популярности Web-сайтов, наиболее известными являются

MediaMetrix [Med], Hot 100

[Hot],

AlexalOOO [Ale] и Netcraft [Netc]. Каждая

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

сти и периодически обновляет свои рейтинги.

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

вающий популярность, хотя последующие исследования могут осуществлять вы-

бор сайтов для тестирования на основе другой методологии. Чтобы обеспечить

Глава

15.

Перспективы исследований протоколов

529

большую широту охвата, в исследовании были объединены результаты, взятые из

двух рейтинговых списков: Fortune 500 [For99] и Global 200 [Glo98]. Объединен-

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

наиболее популярных сайтов.

15.3.4.

PRO-COW. Масштабное исследование

совместимости

Методология исследования совместимости в Web (PRO-COW — Protocol

Compliance on the Web) заключается в генерировании множества запросов, охва-

тывающих различные функции НТТР/1.1, и автоматической проверке ответов

с целью определить, удовлетворяют ли они требованиям, содержащимся в специ-

фикации. Например, если предполагается, что каждый ответ имеет заголовок Date,

ответы сервера, в которых этот заголовок отсутствует, считаются несовместимыми.

Более подробное описание исследования PRO-COW можно найти в [КА01].

Описание исследования совместимости поделено на четыре части и начинается

с различных категорий т^ов. После рассмотрения, имеет ли значение местополо-

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

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

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

С учетом эволюции Web-технологий особое значение приобретает долговечность

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

период в 16 месяцев снижается риск непостоянства результатов.

КАТЕГОРИИ ТЕСТОВ НА СОВМЕСТИМОСТЬ

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

следует оценить важность различных тестов на совместимость. В этой связи тесты

на совместимость делятся на три части в порядке уменьшения значимости:

Тестирование соответствия требованиям уровня MUST. Эти требования

четко сформулированы, и компоненты должны полностью им следовать. Лю-

бая реализация, которая не отвечает

всем

требованиям MUST, считается не-

совместимой. Разработчики протокола подчеркивают, что неспособность

функции подчиняться требованиям уровня MUST может привести к семан-

тическим нарушениям. Например, проект стандарта НТТР/1.1 настаивает,

что во всех сообщениях в долговременном соединении ДОЛЖНА (MUST)

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

ное соединение, отправляет сообщение без явного указания его длины. Полу-

чатель не знает, получил ли он все сообщение целиком. С учетом того факта,

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

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

сообщения друг от друга. Аналогично, прокси-сервер НЕ ДОЛЖЕН (MUST

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

шающим его фактическую версию. Версия протокола является индикатором

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

предположить, что отправитель реализует определенные функции. Напри-

мер,

получатель может подумать, что отправитель способен принимать и де-

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

Тестирование новых функций НТТР/1.1. НТТР/1.1 присущи несколько но-

вых функций (о различиях между НТТР/1.0 и НТТР/1.1 говорилось в гла-

ве 7). Некоторые из функций, такие как долговременные соединения, запросы