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

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

530

Часть

VI.

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

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

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

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

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

7 (раздел 7.4.1), возможность принимать запрос на диапазон в НТТР/1.1 не яв-

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

скольку это уменьшает число пакетов, передаваемых по сети. Точно так же,

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

ся по умолчанию, но не является требованием уровня MUST в НТТР/1.1.

Тестирование других изменений. Как указывалось в главе 7, количество изме-

нений, введенных в

НТТР/1.1,

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

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

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

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

вать длинные URI запросов. Хотя спецификация протокола не содержит кон-

кретного ограничения длины, она вводит код ответа 414 Request-URI Too

Long. Реализация сервера должна быть достаточно интеллектуальной, чтобы

контролировать переполнение буфера при получении сообщения-запроса

с очень длинным URI.

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

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

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

клиентов, на стороне которых выполняется тестирование. Технически местополо-

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

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

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

того,

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

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

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

положение клиента имеет значение. Местоположение клиента может повлиять на

то,

какая реплика сервера получает запрос и отвечает на него. Исследование игно-

рирует роль прокси-серверов

—

все запросы передаются исходному серверу напря-

мую.

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

кси-серверов учитывается — осуществляется тестирование, является ли про-

кси-сервер совместимым с протоколом, а также оказывает ли прокси-сервер

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

му серверу. Если исходный сервер имеет заместителя или имеются другие локаль-

ные серверы (например, с изображениями), они также подлежат тестированию. Та-

кие серверы могут функционировать под другой версией серверного программного

обеспечения, отличающейся от версии исходного сервера. Серверы-заместители

могут работать не под НТТР/1.1, поэтому от них нельзя требовать совместимости

с НТТР/1.1. Для проверки гипотезы, оказывает ли влияние местоположение кли-

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

положение которых было различно.

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

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

выбрана программа для тестирования. Для тестирования базовой совместимости

можно связаться с Web-сервером с помощью telnet (через порт 80), но эта возмож-

Глава

15.

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

531

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

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

клиентское инструментальное средство httperf

[MJ98],

которое представляет собой

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

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

синтаксический анализ HTTP-ответов, генератор рабочей нагрузки, который фор-

мирует потоки HTTP-запросов, и средство сбора статистики, который собирает

статистические данные о сделанных запросах. Средство httperf поддерживает

НТТР/1.1 и доступно в исходных кодах, что облегчает модификацию. Выбор рас-

положения клиентов для выполнения тестов

—

более сложная задача. В идеале же-

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

ется при выборе серверов. Однако в отличие от статистики популярности серверов

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

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

увидим в резюме (раздел 15.3.5), последующие более глубокие исследования уже

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

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

странах.

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

Исследование совместимости выполнялось трижды в течение 16 месяцев. Во

время выполнения тестов тремя наиболее популярными серверами^ являлись

Apache, Netscape-Enterprise и Microsoft-IIS. Указанные серверы составляют около

95%

от всех тестируемых серверов. Относительная популярность серверов для вы-

полняемой группы тестов не обязательно распространяется на Web в целом. На-

пример, доля Web-сервера Apache устойчиво составляла 60% [Netc], в то время как

в процессе тестирования выборка серверов Apache составила около 30%. Для сер-

веров Apache и Netscape-Enterprise информация о конфигурации может быть полу-

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

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

Apache и Netscape:

Server: Apache/1.ЗЬЗ 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 требует от серверов по-

^ Здесь и далее мы используем термин «сервер» для обозначения функционирующего на

тестируемом сайте программного обеспечения Web-сервера.

532

Часть

VI.

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

сылать код состояния 200 ОК и включать в ответы соответствующие заголовки, та-

кие как Date и либо Content-Length, либо Transfer-Encoding: chunked. Свыше

70%

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

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

вет на запрос GET, а также, чтобы ответ имел надлежащий заголовок Date.

Серверы Apache и Microsoft-IIS показали себя с наилучшей стороны: они вы-

держали тесты. Около 20% серверов Netscape-Enterprise не выдержало всех тестов.

Последним версиям Netscape-Enterprise свойственно большее количество проблем,

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

ванным серверам, между группами серверов Apache, Microsoft-HS и Netscape-

Enterprise имеются значительные различия. Свыше одной пятой всех серверов не

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

исследования осенью 2000 года доля серверов, не прошедших тестов, составляла

еще около 20%, хотя количество серверов, не выдержавших все три теста, несколь-

ко уменьшилось.

Тесты второй категории предусматривали проверку важных новых функций,

появившихся в НТТР/1.1, таких как долговременные срединения, конвейеризация

и запросы па диапазоны. Как обсуждалось в главе 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 меньше внимания, а возмож-

Глава

15.

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

533

ность обработки длинных URI относится именно к требованиям уровня SHOULD.

Разрабо1'чики протокола могут, принимать решения о вюпочепии требований в тот

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

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

того,

что определенная функция не была подвергнута тщательному тестированию. Не

все программные ошибки могут быть устранены за счет хювьппения строгости требо-

ваний. Однако в рискова1П1ЫХ ситуациях следует принимать во внимание относитель-

но разрешительный характер требований уровня SHOULD. Альтернативной возмож-

ностью является добавление потенциально рискованных ситуаций в раздел Security

Considerations (Соображения но безопасности) спецификации протокола.

15.3-5,

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

Исследования, выполнявшиеся в течение 16 месяцев, выявили повышение сте-

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

личных списках рассылки проводилась дискуссия о проведении не афишируемых

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

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

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

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

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

Пользователи и администраторы серверов могут быстро оценить уровни совмести-

мости различных Web-компонентов. Большая степень открытости дает возмож-

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

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

Более широкое тестирование на совместимость должно охватывать больший на-

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

кси-серверов наряду с исходными серверами. К концу 2000 г. прокси-серверы, со-

вместимые с НТТР/1.1, еще не получили широкого распространения, хотя в этом

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

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

назначение и информационное содержимое сайта (например, сайт новостей, сайт

электронной коммерции и т.д.). Тестированием могут также охватываться попу-

лярные на местном уровне сайты; т.е. если тестирование выполняется из Италии,

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

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

15.4.

Комплексное измерение показателей

эффективности Web

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

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

шению эффективности Web. Эффективность Web определяется несколькими фак-

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

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

передачи ответов, и нагрузку на Web-сервер, связанную с обработкой запросов.

Простой способ проверить эффективность — сформировать группу запросов

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

534

Часть

VI.

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

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

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

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

в виде запросов, направленных репрезентативной группе Web-сайтов. Группу ре-

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

ски популярных сайтов регулярно публикуются, а также учитывая, что большая

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

фикация группы репрезентативных клиентов

—

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

В этом разделе мы поговорим об измерении комплексных показателей ответов

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

торов, влияющих на комплексную эффективность Web, и сосредоточим внимание на

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

плексного исследования [KWOO], вкратце остановившись на некоторых деталях и

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

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

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

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

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

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

дуемые параметры и предположить, какие факторы можно игнорировать.

15.4.1.

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

эффективность

На эффективность Web-транзакций оказывают влияние несколько факторов.

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

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

тов в сети, а также нагрузка на исходный сервер. Объем доступных данных о мес-

тах происхождения запросов или характеристиках соединений клиентов с Internet

достаточно ограничен.

В таблице 15.1 представлены некоторые компоненты, влияющие на эффектив-

гюсть Web. Таксономия не отражает фактических задержек, вносимых каждым из

факторов. На это есть две причины: отсутствие убедительных масштабных иссле-

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

эффективности. Хотя проведение всестороннего исследования, которое учитывало

бы все факторы,

—

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

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

исчерпывающей — в ней приведены не все факторы, которые могут оказывать

влияние на суммарную задержку. В таблице сведены

наиболее характерные

источ-

ники задержки.

В первом столбце таблицы 15.1 представлены различные этапы Web-транзак-

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

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

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

в первом столбце (избежать его или осложнить его выполнение). Примером вариа-

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

DNS,

если IP-адрес сервера содержится в кэше DNS. Другой пример

—

дополни-

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

HTML-документа.

Глава

15.

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

535

Таблица 15.1. Компоненты задержки

Этап Web-транзакции

Щелчок мышью в браузере

Просмотр кэша браузера

Построение HTTP-запроса

DNS-запрос на IP-адрес прокси-сервера

Перехватывающий прокси-сервер

ТСР-соединение с прокси-сервером

Иерархия кэшей

Доменное имя расположенного выше по

потоку сервера

Обращение к следующему прокси-серверу

в цепочке

ТСР-соедипение с исходным сервером

Переадресация запроса сервером

Синтаксический анализ HTTP-запроса

сервером

Нагрузка на сервер

Создание ответа сервером

Синтаксический анализ и отображение

ресурса браузером

Факторы, влияющие на задержку |

Обращение/отсутствие обращения к кэшу

DNS,

быстродействие клиентского

компьютера

Версия протокола

Обращение к кэшу DNS, обращение

к корневому серверу DNS

Быстродействие аппаратных средств/группы

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

Характеристики соединения с провайдером /

долговременное соединение

Нагрузка на прокси-сервер/кэш |

UDP/ICP

Обращение к DNS

Версии протоколов, задержка в сети

Наличие сервера-заместителя |

Соединение с новым сервером

Статический/динамический ресурс, задержка

при выполнении CGI-сцснария

Задержка па стороне сервера

Размер выходного буфера сокста |

Выдача дополнительных запросов

Рассмотрим типовую Web-транзакцию, которая начинается с выбора пользова-

телем URL и заканчивается отображением ответа браузером. В главе 2 (раз-

дел 2.3.1) мы обсуждали классический пример. Мы игнорировали потенциальное

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

ры,

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

ром. Мы также игнорировали особенности соединения с провайдером Internet

и/или с Internet, а также потенциальные задержки, вызванные заторами в сети.

Таблица 15.1 отражает попытку дать полную картину различных этапов Web-тран-

закции. Щелчок мышью пользователем на гинерссылке приводит к обращению

к кэшу браузера, чтобы проверить, доступен ли ресурс локально. Если нет, щелчок

обусловливает HTTP-запрос.

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

ternet. Соединение может быть низкоскоростным коммутируемым соединением,

быстродействующим соединением с помощью кабельного модема или DSL. Сам

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

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

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

536

Часть

VI.

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

использование ресурсов и кэширование. Браузеры пользователей могут быть явно

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

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

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

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

го имени (например, proxyOl.aoLcom), посылается DNS-запрос для получения

IP-адреса прокси-сервера. Как говорилось в главе 5 (раздел 5.3.3), доменное имя

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

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

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

IP-адрес будет получен. В большинстве случаев такой DNS-запрос посылается

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

локальным E)NS-cepBepoM.

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

хватывающим прокси-сервером (см. главу И, раздел 11.10.2). Заметим, что браузер

не осведомлен о таких перехватах. Если ответ пришел от одного из кэширующих

прокси-серверов, общее время ожидания может быть небольшим. Если же ответ не

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

должен быть отправлен выше по потоку.

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

прокси-серверу, который является частью иерархии кэшей. Прокси-сервер может

обратиться к иерархии кэшей, если он не способен найти ресурс в своем кэше. За-

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

ванием протокола Internet Cache Protocol (ICP) другим кэшам на том же уровне

иерархии. Успешный ответ от одного из кэшей на данном уровне иерархии сохра-

нит малое значение общей задержки. Однако если ответ от кэша на данном уровне

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

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

в иерархии кэшей Squid составляет несколько миллисекунд в предположении, что

UDP-сообщения не были потеряны.

Как в случае явно указанного прокси-сервера, так и в случае наличия перехва-

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

ние.

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

дополнительная задержка.

До сих пор мы обсуждали роль браузеров и прокси-серверов. Теперь мы рас-

смотрим роль, которую играет протокол HTTP применительно к соединениям и

кэшированию. Если клиент уже установил долговременное соединение с про-

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

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

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

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

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

При этом начинают играть роль характеристики соединения между сетью провай-

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

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

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

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

пользователя, начинают сказываться факторы, связанные с обращением к DNS и

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

жду границей сети провайдера и конечным прокси-сервером (который может пред-

Глава

15.

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

537

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

жек между компонентами. Эта часть измерений (от границы сети провайдера до

конечного прокси-сервера перед исходным сервером) склонна к большой изменчи-

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

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

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

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

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

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

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

шить переадресовать запрос на другой сайт. Такая переадресация может быть обу-

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

сайта или тем, что ресурс был перемещен.

Если предположить, что ресурс не был перемещен и является доступным, то мо-

жет быть сформирован ответ. Нагрузка на исходный сервер является важным фак-

тором, способствующим возникновению задержку при генерировании ответа. Не-

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

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

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

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

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

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

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

ответа. Синтаксический анализ и воспроизведение ответа — еще один фактор,

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

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

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

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

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

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

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

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

серверы.

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

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

ванием комплексной эффективности. Причинами применения такой альтернатив-

ной стратегии доставки является снижение нагрузки на исходный сервер и потен-

циально более эффективная доставка содержания альтернативными серверами.

Одновременно со снижением нагрузки, исходный сервер сохраняет соединения и

обслуживает большее число пользователей. С точки зрения пользователя, изна-

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

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

11.13) играют все более важную роль в Web.

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

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

тельно увеличить время ожидания. Точно так же, потеря пакета SYN в процессе ус-

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

о чем говорилось в главе 8 (раздел 8.1.1). Другие виды потерь не столь важны.

538

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

15,4.2.

Отчет по исследованию комплексной эффективности

Исследование [KWOO], поставившее своей целью изучить факторы, влияющие

на комплексную эффективность Web, проводилось с конца 1999 года в течение

всего 2000 года. Инфрастуктура и методология этого исследования основывались

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

ле 15.3.4. Группа Web-сайтов была увеличена, чтобы включить популярные сайты,

работающие под НТТР/1.0.

В этом разделе мы вкратце расскажем об исследовании, начав с его методоло-

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

ные,

приведенные в [KWOO], могли измениться, главная наша

\хелъ

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

с этим исследованием

—

сделать акцент на этапах проведения экспериментов. По-

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

дачах последующих, более широких исследований.

МЕТОДОЛОГИЯ КОМПЛЕКСНОГО ИССЛЕДОВАНИЯ

Комплексное исследование представляло собой активное исследование по изме-

рению характеристик

—

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

Группы клиентов находились по всему миру и отбирались главным образом по

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

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

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

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

можности, различные настройки кэша), характеристики соединения с Internet и

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

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

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

Исследование комплексной эффективности игнорирует роль, которую могут иг-

рать прокси-серверы. Вместо этого генерировался трафик с использованием httperf

[MJ98].

Назначение

httperf,

как уже говорилось в разделе 15.3.4, состоит генерации

HTTP-запросов, установлении соединений, передаче запросов и получении инфор-

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

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

ента в реальном исследовании комплексхюй эффективности. Средство передает за-

прос клиента непосредственно исходному серверу и не предусматривает наличие од-

ного или нескольких прокси-серверов на пути. Хотя ряд свойств

httperf,

таких как

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

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

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

тимым НТТР/1.1. Например, оно не выполняет функций браузера по воспроизведе-

нию ответа и поэтому позволяет получать лишь нижнюю оценку величины

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

с НТТР/1.1 клиент, который также способен предоставлять информацию о времени

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

фикации с целью регистрации необходимой статистической информации.

После того, как было выбрано местоположение клиентов и сами клиенты, сле-

дующим шагом является выбор группы серверов. Для локальных Web-серверов

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

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

множества серверов, выбранных на основе популярности сайтов. По-настоящему

Глава

15.

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

539

репрезентативное исследование должно принимать во внимание множество факто-

ров,

относящихся к Web-сайтам.

• Популярность. Общая популярность сайта является мерой, насколько в ис-

следовании отражены привычки пользователей. Исследование не должно со-

средотачивать внимание на неизвестных Web-сайтах, которые редко посеща-

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

обслуживают значительную долю трафика запросов.

• Репрезентативность. Набор сайтов, включаемых в исследование, должен со-

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

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

мерции должны включать разнообразные формы, в ходе одного Web-сеанса

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

вероятность использования cookies.

• Версия и параметры настройки. Версии протоколов сервера могут быть раз-

личными (НТТР/1.0 или НТТР/1.1). Для конкретной версии протокола имеет-

ся множество реализаций, включая Apache или Netscape. Для одной программ-

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

пример, подключения или отключения протокола Secure Socket Layer (SSL).

• Конфигурация сайта. Сайты конфигурируются различными способами: не-

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

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

теля и т.д.

• Архитектура сервера. Следует принимать во внимание различные архитекту-

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

с множеством программных потоков, с множеством процессов и т.д. (см. гла-

ву 4, раздел 4.4).

• Содержание сервера. Имеются значительные вариации содержания Web-

сайтов

—

некоторые сайты содержат в основном изображения, другие —тек-

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

сы.

К другим атрибутам ресурсов относятся возможность кэширования и час-

тота изменений.

• Роль сетей распространения содержания. На некоторых сайтах значитель-

ная часть ресурсов доставляется через сети распространения содержания.

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

странения содержания.

Перечисленные выше факторы не являются исчерпывающими. Однако этот пе-

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

следования эффективности. Разнообразие и сложность факторов делают задачу

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

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

граммного обеспечения, следук)щим шагом является разработка набора тестов. Ти-

пичными целями комплексного исследования являются: измерение времени ожи-

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

в пересчете на байт, учет вариантов соединений (например, одно долговременное

соединение для загрузки нескольких ресурсов), оценка влияния функциональных

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

т.д.

Исследование должно считаться со всеми этими факторами, особое внимание

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