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

Методология исследования совместимости в Web (PRO-COW — Protocol Compliance on the Web) заключается в генерировании множества запросов, охватывающих различные фуикции НТТР/1.1, и автоматической проверке ответов с целью определить, удовлетворяют ли они требованиям, содержащимся в спецификации. Например, если предполагается, что каждый ответ имеет заголовок Date, ответы сервера, в которых этот заголовок отсутствует, считаются несовместимыми. Более подробное описание исследования PRO-COW можно найти в [KA01].

Описание исследования совместимости поделено на четыре части и начинается с различных категорий тестов. После рассмотрения, имеет ли значение местоположение клиента для выполнения тестирования, мы вкратце рассмотрим среду для выполнения тестирования, программное обеспечение, используемое для выполнения тестов. Наконец, мы познакомимся с реальными тестами и их результатами. С учетом эволюции Web-технологий особое значение приобретает долговечность результатов тестирования. За счет выполнения трех отдельных групп измерений за период в 16 месяцев снижается риск непостоянства результатов.

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

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

1.       Тестирование соответствия требованиям уровня MUST. Эти требования четко сформулированы, и компоненты должны полностью им следовать. Любая реализация, которая не отвечает всем требованиям MUST, считается несовместимой. Разработчики протокола подчеркивают, что неспособность функции подчиняться требованиям уровня MUST может привести к семантическим нарушениям. Например, проект стандарта НТТР/1.1 настаивает, что во всех сообщениях в долговременном соединении ДОЛЖНА (MUST) быть указана длина. Предположим, что сервер, обслуживающий долговременное соединение, отправляет сообщение без явного указания его длины. Получатель не знает, получил ли он все сообщение целиком. С учетом того факта, что может быть отправлено дополнительное сообщение (поскольку соединение является долговременным), получатель не будет знать, как отделить два сообщения друг от друга. Аналогично, прокси-сервер НЕ ДОЛЖЕН (MUST NOT) посылать сообщение со значением указателя версии протокола, превышающим его фактическую версию. Версия протокола является индикатором функциональных возможностей отправителя. Получатель может ошибочно предположить, что отправитель реализует определенные функции. Например, получатель может подумать, что отправитель способен принимать и декодировать сообщения, разделенные на фрагменты.

2.       Тестирование новых функций НТТР/1.1. НТТР/1.1 присущи несколько новых функций (о различиях между НТТР/1.0 и НТТР/1.1 говорилось в главе 7). Некоторые из функций, такие как долговременные соединения, запросы на диапазоны, являются более важными, чем другие, такие как уведомление об ошибке. Однако полный комплект тестов на совместимость должен проверять все новые функции новой версии протокола. Например, важным добавлением в НТТР/1.1 является запросы на диапазоны. Однако, как обсуждалось в главе 7 (раздел 7.4.1), возможность принимать запрос на диапазон в НТТР/1.1 не является обязательной. Серверам рекомендуется принимать такие запросы, поскольку это уменьшает число пакетов, передаваемых rio сети. Точно так же, способность использовать долговременные соединения, хотя и подразумевается по умолчанию, но не является требованием уровня MUST в НТТР/1.1.

3. Тестирование других изменений. Как указывалось в главе 7, количество изменений, введенных в НТТР/1.1, достаточно велико. После разбиения изменений на категории и упорядочения можно выполнить их тестирование. Например, в спецификацию были введены предупреждения, связанные с обработкой сообщений произвольной длины. Сервер может оказаться неспособным обрабатывать длинные URI запросов. Хотя спецификация протокола не содержит конкретного ограничения длины, она вводит код ответа 414 Request-URI Too Long. Реализация сервера должна быть достаточно интеллектуальной, чтобы контролировать переполнение буфера при получении сообщения-запроса с очень длинным URI.

МЕСТОПОЛОЖЕНИЕ КЛИЕНТОВ, С ПОМОЩЬЮ КОТОРЫХ ВЫПОЛНЯЕТСЯ

ТЕСТИРОВАНИЕ

После того, как набор тестов выбран, должно быть определено местоположение клиентов, на стороне которых выполняется тестирование. Технически местоположение клиентов, выдающих запрос, не должно иметь значения. Web-сервер, который не использует в ответах информацию о местоположении клиента и его идентификационные данные, будет отвечать одним и тем же образом, иезависимо от того, кем был выдан запрос. При выполнении теста, при котором запросы передаются от клиента непосредственно исходному серверу, это не является проблемой. Однако если запрос проходит через один или нескольких прокси-серверов, местоположение клиента имеет значение. Местоположение клиента может повлиять на то, какая реплика сервера получает запрос и отвечает на него. Исследование игнорирует роль прокси-серверов — все запросы передаются исходиому серверу напрямую. При проведении более широкого исследования совместимости роль прокси-серверов учитывается — осуществляется тестирование, является ли прокси-сервер совместимым с протоколом, а также оказывает ли прокси-сервер влияние на выполнение теста на совместимость при пересылке запросов исходному серверу. Если исходный сервер имеет заместителя или имеются другие локальные серверы (например, с изображениями), они также подлежат тестированию. Такие серверы могут функционировать под другой версией серверного программного обеспечения, отличающейся от версии исходного сервера. Серверы-заместители могут работать не под НТТР/1.1, поэтому от них нельзя требовать совместимости с НТТР/1.1. Для проверки гипотезы, оказывает ли влияние местоположение клиентов на результаты проверки на совместимость, использовались клиенты, местоположение которых было различно.

СРЕДА ДЛЯ ТЕСТИРОВАНИЯ СОВМЕСТИМОСТИ

После того, как выбор тестов и местоположения был обоснован, должна быть выбрана программа для тестирования. Для тестирования базовой совместимости можно связаться с Web-сервером с помощью telnet (через порт 80), но эта возможность не подходит для выполнения обширных тестов в автоматическом режиме. Основной программой, используемой для генерирования групп запросов, является клиентское инструментальное средство httperf [MJ98J, которое представляет собой настраиваемое средство измерения производительности с тремя основными логическими компонентами: ядро, которое посылает HTTP-запросы и осуществляет синтаксический анализ HTTP-ответов, генератор рабочей нагрузки, который формирует потоки HTTP-запросов, и средство сбора статистики, который собирает статистические данные о сделанных запросах. Средство httperf поддерживает НТТР/1.1 и доступно в исходных кодах, что облегчает модификацию. Выбор расположения клиентов для выполнения тестов — более сложная задача. В идеале желательно выбирать репрезентативный набор клиентов, подобно тому, как это делается при выборе серверов. Однако в отличие от статистики популярности серверов статистические данными о распределении местоположения клиентов отсутствуют. Как оказалось, местоположение клиентов особой роли не играет. Однако как мы увидим в резюме (раздел 15.3.5), последующие более глубокие исследования уже не смогут игнорировать местоположение клиентов. В ходе данного исследования тесты выполнялись как в организациях, где работали авторы, так и в различных странах.

ТЕСТЫ И РЕЗУЛЬТАТЫ ИССЛЕДОВАНИЯ СОВМЕСТИМОСТИ

Исследование совместимости выполнялось трижды в течение 16 месяцев. Во время выполнения тестов тремя наиболее популярными серверами1 являлись Apache, Netscape-Enterprise и Microsoft-IIS. Указанные серверы составляют около 95% от всех тестируемых серверов. Относительная популярность серверов для выполняемой Группы тестов не обязательно распространяется на Web в целом. Например, доля Web-сервера Apache устойчиво составляла 60% [Netc], в то время как в процессе тестирования выборка серверов Apache составила около 30%. Для серверов Apache и Netscape-Enterprise информация о конфигурации может быть получена из заголовка ответа Server. Вот несколько примеров из нескольких сотен различных вариантов конфигураций, которые могут быть получены для серверов Apache и Netscape:

Server: Apache/1.3b3 mod_perl/1.07

Server: Netscape-Communications/1.1+SiteTrack 1.10i26mck

Server: Apache/1.2.5 FrontPage/3.0.3

Однако серверы Microsoft-IIS не сообщают каких-либо параметров конфигурации за исключением идентификационных номеров версий программного обеспечения (например, IIS/4.0 и IIS/5.0). Результаты исследования представлены с разбивкой по серверам и не могут быть обобщены на все имеющиеся версии.

К первой категории тестов относится тестирование методов GET и HEAD, а также проверка правильности реакции на отсутствие заголовка запроса Host. Напомним, что правильная обработка заголовка Host (см. главу 7, раздел 7.#) является требованием уровня MUST, а все серверы, поддерживающие НТТР/1.1, обязаны возвращать ошибку, если заголовок отсутствует в каком-либо запросе НТТР/1.1. Около трети серверов не являются совместимыми в отношении обработки заголовка Host.

Условная совместимость имеет место в случае отсутствия заголовков Content- Length и Transfer-Encoding: chunked. Около 80% серверов работают с методом GET должным образом. Совместимость с запросами GET требует от серверов посылать код состояния 200 OK и включать в ответы соответствующие заголовки, такие как Date и либо Content-Length, либо Transfer-Encoding: chunked. Свыше 70% серверов являются безусловно совместимыми при работе с методом HEAD. При этом требуется, чтобы ответ содержал те же заголовки содержимого, что и ответ на запрос GET, а также, чтобы ответ имел надлежащий заголовок Date.

Серверы Apache и Microsoft-IIS показали себя с наилучшей стороны: они выдержали тесты. Около 20% серверов Netscape-Enterprise не выдержало всех тестов. Последним версиям Netscape-Enterprise свойственно большее количество проблем, чем более ранним версиям. Хотя результаты были агрегированы но всем тестированным серверам, между группами серверов Apache, Microsoft-IIS и Netscape- Enterprise имеются значительные различия. Свыше одной пятой всех серверов не прошло, по меньшей мере, один из трех тестов. На момеит проведения последнего исследования осенью 2000 года доля серверов, не прошедших тестов, составляла еще около 20%, хотя количество серверов, не выдержавших все три теста, несколько уменьшилось.

Тесты второй категории предусматривали проверку важных новых функций, появившихся в НТТР/1.1, таких как долговременные С9едииения, конвейеризация и запросы на диапазоны. Как обсуждалось в главе 7 (раздел 7.5.2), долговременные соединения относятся к требованиям уровня SHOULD (Желательно). Однако из-за выгоды, которую приносят долговременные соединения, они приняты в НТТР/1.1 по умолчанию. Другими словами, сервер должен быть явным образом настроен, если необходимо запретить долговременные соединения. Около 70% серверов поддерживают долговременные соединения. Примерно столько же серверов способны обслуживать конвейериые запросы. Однако лишь половина из подвергнутых тестированию серверов оказалась способна обслуживать запросы на диапазоны. Опять-таки, возможность обработки запросов на диапазоны является требованием уровня SHOULD (Желательно) в спецификации протокола. В целом при проведении тестов второй категории только 40% серверов оказались полностью совместимыми, а 20% серверов не нрошли все тесты. Третье исследование, выполненное осенью 2000 г., не показало каких-либо значительных улучшений относительно двух предыдущих исследований.

Объединенные тесты первой и второй категорий прошло примерно 30% серверов, а 7% серверов провалило все тесты.

Накоиец, тесты третьей категории ориентированы на менее значимые функции, такие как редко используемые методы (OPTIONS, TRACE), потенциально рискованные ситуации (длинные URL) и различные форматы представления дат. Хотя тестируемые методы пока еще используются мало, в будущем ситуация может измениться. Метод OPTIONS (см. главу 7, раздел 7.7.1) может использоваться для получения информации о функциональных возможностях сервера. Отправитель может, например, проверить, способен ли сервер обслуживать передачу с сообщений, разделенных на фрагменты, прежде чем отправить запрос.

Наиболее показательный тест состоял в проверке обработки длинных URI запросов. Ряд серверов не проверял переполнение буфера, что приводило к ненормальному функционированию серверного программного обеспечения. К счастью, эти ошибки были быстро устранены после того, как авторы исследования уведомили разработчиков программного обеспечения серверов. Принимая во внимание, что для многих компаний, занимающихся электронной коммерцией, требуется, чтобы их Web-сайты были постоянно доступными, подобная простая проблема не должна остаться без внимания. Наличие таких проблем заключается в том, что разработчики, как правило, уделяют требованиям совместимости уровня SHOULD меньше внимания, а возможность обработки длинных URI относится именно к требованиям ypoBiM SHOULD. Разработчики протокола могут, принимать решения о включении требований в тот или иной уровень совместимости на основе дополнительных критериев, таких как потенциальная возможность возникновения катастрофических ситуаций в результате того, что определенная функция не была подвергнута тщательному тестированию. Не все программные ошибки могут быть устранены за счет повышения строгости требований. Однако в рискованных ситуациях следует принимать во внимание относительно разрешительный характер требований ypoBiw SHOULD. Альтернативной возможностью является добавление потенциально рискованных ситуаций в раздел Security Considerations (Соображения по безопасности) спецификации протокола

Совместимость c протоколом. Резюме

Исследования, выполнявшиеся в течение 16 месяцев, выявили повышение степени совместимости, но процесс тестирования должен быть более строгим. В различных списках рассылки проводилась дискуссия о проведении не афишируемъис тестов, результаты которых не подлежали бы публичному распространению, чтобы не приводить в замешательство разработчиков программных компонентов. Хотя эта идея достаточно интересна, публикация результатов проведения стандартного набора тестов на совместимость основными производителями программного обеспечения над своими продуктами, представляется значительно лучшим вариантом. Пользователи и администраторы серверов могут быстро оценить уровни совместимости различных Web-компонентов. Большая степень открытости дает возможность разработчикам сделать их программное обеспечение более совместимым со спецификацией протокола.

Более широкое тестирование на совместимость должно охватывать больший набор местоположений клиентов и обеспечивать проведение тестирования про- кси-серверов наряду с исходными серверами. К концу 2000 г. прокси-серверы, совместимые с НТТР/1.1, еще не получили широкого распространения, хотя в этом направлении ожидаются скорые изменения. Помимо этого, техиика выбора серверных сайтов для тестирования может основываться на других критериях, таких как назначение и информационное содержимое сайта (например, сайт новостей, сайт электронной коммерции и т.д.). Тестированием могут также охватываться популярные на местном уровне сайты; т.е. если тестирование выполняется из Италии, могут подвергаться тестированию несколько популярных в Италии сайтов, даже если они не входят в перечень глобально популярных сайтов.

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

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

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100