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

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

340

Часть

IV. Измерение и описание Web-трафика

• Request processing time. Это поле содержит время в секундах, потраченное

сервером на генерацию ответа. Это поле особенно полезно, если сервер тратит

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

бующие исполнения сценария.

• Request header size. Это поле содержит число байтов в заголовке HTTP-за-

проса, посланного клиентом.

• Request body size. Это поле содержит число байтов в теле HTTP-запроса, по-

сланного клиентом. Запрос обычно не имеет тела, если только клиент не по-

шлет запрос PUT или POST.

• Сумма размеров заголовка и тела запроса составляют полный размер запроса

клиента.

Оставшиеся поля, приведенные в таблице 9.2, относятся к прокси-серверам.

В отличие от клиентов и серверов, прокси-сервер работает и как клиент, и как сер-

вер.

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

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

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

поля, отсутствующие в журналах Web-серверов. Например, прокси-сервер может

использовать следующие поля:

• Remote response code. Это поле содержит трехразрядный код, включенный

в поле Status-Line заголовка HTTP-ответа, отправленного сервером про-

кси-серверу. Значение поля Remote response code может отличаться от значе-

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

кси-сервером клиенту.

• Remote content length. Значение этого поля

—

число байтов в сообщении, по-

сланном сервером прокси-серверу. Значение в поле Remote content length

может отличаться от поля content length, которое содержит размер сообщения,

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

• Remote response header size. Это размер в байтах заголовка ответа сервера

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

• Proxy request header size. Это поле содержит размер заголовка запроса, по-

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

ния поля request header size, в котором записано число байтов, отправленных

прокси-серверу клиентом.

• Proxy response header size. Поле содержит размер заголовка ответа, послан-

ного прокси-сервером клиенту.

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

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

9.4. Предварительная обработка результатов

измерений

Результаты измерений Web-трафика обычно имеют большой объем, их можно

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

следующие три шага:

Глава

Измерение Web-трафика

341

• Синтаксический анализ для обнаружения ошибочных записей.

• Фильтрация данных для удаления ненужных нолей.

• Преобразование данных в формат, удобный для анализа.

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

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

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

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

тельной обработки данных измерений приведены в главе 14 (раздел 14.2).

9.4.1.

Синтаксический анализ результатов измерений

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

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

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

мер,

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

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

формат. Синтаксический анализ включает в себя определение границ между от-

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

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

а поля

—

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

включать в себя ноле длины, показывающее начало следующей записи. Каждое

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

жет заключаться в квадратные скобки (например, [15/Oct/2000:00:00:25 -0400]), а

строка запроса

—

в кавычки (например, "GET /img/logo.gif НТТР/1.0").

Программа синтаксического анализа может быть написана на любом языке про-

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

рений. Например, анализ журнала в формате CLF не очень сложен по сравнению

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

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

мер,

запись может иметь неправильное число полей или гголе может иметь непра-

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

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

иметь дело только с синтаксически корректными данными. Программа синтаксиче-

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

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

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

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

в формате CLF разных Web-серверов часто имеют различия в синтаксисе. Устра-

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

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

9.4.2. Фильтрация результатов измерения

Следующий этап предварительной обработки

—

фильтрация результатов измере-

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

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

вания. Например, у каждой записи в журнале формата CLF на рис. 9.1 в полях

Remote identity и Authenticated user стоят "-", потому что на сервере отключена

идентификация и не применяется аутентификация (не записывается информация о

342

Часть

IV.

Измерение

описание Web-трафика

регистрации пользователей). Из журнала можно исключить эти ноля, так как они

неинформативны. Кроме того, программа, производящая фильтрацию, может уда-

лить ненужные для анализа поля. Примером может служить результат мониторинга

пакетов, который включает полные заголовки ответов и запросов. Использование

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

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

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

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

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

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

ниями полей могут оказать отрицательное влияние па последующий анализ. На-

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

чение времени, но не попадающее во временной интервал, который покрывает

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

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

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

сы,

возвращающие некоторые коды ошибок. Подобным образом анализ ресурсов

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

соответствующими стандартным форматам изображений (например, .gif и .jpg).

9.4.3.

Преобразование данных измерений

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

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

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

вать.

Например, поле запроса в журнале формата CLF может быть преобразовано

в три отдельных поля: метод запроса, запрошенный URI и версия протокола. Подоб-

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

формату. Например, Content-Length и Content-length следует трактовать как один

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

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

час,

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

мер,

представление времени в UNIX (число секунд, прошедших с полуночи

января

1970 года). В качестве другого примера IP-адрес клиента в десятичной точечной за-

писи (10.34.197.3) может быть преобразован в 32-разрядное беззнаковое целое число

для уменьшения объема данных.

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

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

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

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

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

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

имена в ходе обработки HTTP-запросов. Тем не менее, это преобразование следует

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

нение преобразования в процессе предварительной обработки также избавляет от

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

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

информацию пользователей. Например, программа предварительной обработки

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

Глава 9. Измерение Web-трафика 343

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

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

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

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

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

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

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

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

лов.

Сценарии, написанные на awk или Peri, позволяют производить статистиче-

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

В любой из этих ситуаций наличие чистого и логично скомпонованного исходного

набора записей сильно упрощает анализ результатов измерений трафика.

9.5.

Получение информации по результатам

измерений

Результаты измерений не всегда содержат всю информацию, необходимую для

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

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

чают всех нужных нолей, например значений времени или HTTP-заголовков.

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

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

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

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

9.5.1.

Ограничения информации об HTTP-заголовках

Заголовки HTTP-запросов и ответов предоставляют богатую информацию о пе-

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

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

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

детальной информации требует перенастройки или модификации сервера. Монитор

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

ждого сообщения и все тело сообщения. Но на практике это зачастую неосуществи-

мо.

Многие исследования опираются на журналы Web-серверов и прокси-серверов,

в которых записана только часть всех строк HTTP-заголовков. В некоторых случаях

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

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

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

состава заголовков НТТР-занроса.

Некоторая недостающая информация может быть реконструирована на основе

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

в журнале сервера. По значению поля, содержащего запрошенный URI, можно оп-

ределить тип запрошенного ресурса. Например, URI, заканчивающиеся на .html

или .htm скорее всего соответствуют HTML-файлам, в то время как URI, заканчи-

вающиеся на .gif или .jpg, скорее всего соответствуют изображениям; хотя некото-

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

вающиеся на .gif или .jpg, могут не соответствовать изображениям. Подобным об-

разом по запрошенному URI или методу запроса можно определить, вызывает ли

344

Часть

IV. Измерение и описание Web-трафика

запрос исполнение сценария на сервере. Запрошенный URI, включающий строку

"cgi"

или "cgi-bin", обычно соответствует сценарию\ Запросы GET с параметрами

в конце URI, а также запросы POST обычно соответствуют HTML-формам. Эти

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

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

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

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

ке НТТР-занроса. Например, ответ 206 Partial Content подразумевает, что клиент

запросил часть ресурса, используя заголовок Range. Аналогично, ответ 304 Not

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

мер,

с помоидью строки заголовка If-Modified-Since. Однако в ответ на запрос Range

или If-Modified-Since можно получить ответ 200 ОК, как если бы был возвращен

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

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

ло.

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

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

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

сервера на основе серверного журнала. Запрошенный URI, который всегда приводит

к ответу 404 Not Found не должен быть включен в обрабатываемые данные, так как

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

9.5.2. Неоднозначная идентификация клиента/сервера

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

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

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

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

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

сано в разделе

9.2.1.

Подобным же образом, IP-адрес сервера, получе1Н1ый при мо-

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

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

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

чить из запрошенного URI или строки Host заголовка запроса НТТР/1.1, предпо-

лагая, что результаты измерений включают эту строку. В запросах НТТР/1.0 тако-

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

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

к DNS-серверу. Но к моменту анализа ответ DNS-сервера может отличаться от

того же на момент передачи данных.

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

труднено. При обработке запроса сервер преобразует запрашиваемый URI в имя

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

с Web-сервера, на основе поля Request в журнале сервера. В некоторых случаях

различные запрашиваемые URI соответствуют одному и тому же ресурсу. Напри-

мер,

http://www.foo.com и http://www.foo.com/index.html обычно соответствуют

одному и тому же файлу (/www/index.html). Хотя значение URI зависит от регистра

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

http://www.foo.com/INDEX.HTML как другое имя для http://www.foo.com/index.html.

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

^ Можно добавить, что ресурсы с расширениями .asp, .php, .pi также представляют собой

сценарии. —

Прим.

ред.

Глава 9. Измерение Web-трафика 345

как удаление повторных символов "/". Запрошенные URI, которые отличаются

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

гих ситуациях сервер может трактовать некоторые URI как псевдонимы других URL

Без доступа к настройкам сервера распознавание таких имен прак1ически невозмож-

но.

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

ют различным ресурсам.

9.5.3.

Реконструкция действий пользователя

Анализ результатов измерений Web-трафика обычно требует определения того,

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

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

ватель щелкает мышью на гинерссылке. Даже если программный клиент использу-

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

пользователя представляет собой сложную задачу. Информация из НТТР-занро-

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

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

Time в журнале сервера предоставляет удобный способ определить последователь-

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

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

щения Web-сайта и какие из этих запросов соответствуют активизации пользова-

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

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

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

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

не имеет четкого начала и конца. Вместо этого, начало сеанса взаимодействия между

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

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

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

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

щий тому же сеансу. Более точные выводы возможны при наличии дополнительной

информации о структуре сайта. Например, запрошенный URI может соответство-

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

того,

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

одной из этих страниц. Информация о гиперссылках на просмотренных страницах

может быть получена из поля Referer в НТТР-занросе. Структура гипертекста мо-

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

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

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

может инициировать несколько HTTP-запросов для загрузки Web-страницы и

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

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

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

запросы, журнал прокси-сервера/Web-cepBepa или результаты мониторинга паке-

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

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

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

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

считается выданным браузером. Выводы будут точнее, если запрашиваемый URI

соответствует изображению, например, GIF- или JPEG-файлу. Запрошенный ре-

346

Часть

IV. Измерение и описание Web-трафика

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

инизаемый URI содержит тот же путь, что и путь к самой странице. Например, за-

прос http://www.foo.com/bar/pict.gif, который следует в скором времени за запро-

сом http://www.foo.com/bar/index.html скорее всего соответствует встроенному

изображению.

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

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

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

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

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

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

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

чае эвристика, основагншя на времени между переходами со страницы па страницу,

слишком проста. Пользователь может потратить несколько минут, «обдумывая»

содержимое Web-сграницы, перед тем, как щелкнуть на гиперссылке, а может

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

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

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

запросов от лица разных пользователей. Но по-прежнему эвристика, основываю-

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

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

9.5.4. Отслеживание модификации ресурсов

Определение того, когда Web-ресурсы создаются, модифицируются и удаляются

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

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

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

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

нено,

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

ции. Ресурсы, которые не были ни разу запрошены, не появятся в журнале. Кроме

того,

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

ми,

а журналы серверов обычно не включают информацию о возрасте ресурса или

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

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

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

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

Рассмотрим задачу но определению возраста ресурса ко времени запроса, осно-

вываясь на информации из HTTP-заголовков. Возраст

—

это разница между време-

нем запроса и временем модификации. Хотя большинство серверов включают время

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

Но монитор пакетов и журнал браузера могут записывать поля Last-Modified и

Date из заголовка HTTP-ответа. Возраст ресурса является разностью этих двух вре-

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

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

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

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

рируется заголовок Last-Modified. Часы, работающие на разных компьютерах в In-

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

па разницу времени между часами.

Глава 9. Измерение Web-трафика 347

Другой 1ЮДХОД к изучению времени модификации ресурсов включает в себя срав-

нение заголовков Last-Modified, следующих друг за другом ответов с одним и тем же

URI. Если ответные сообщения имеют разные ноля Last-Modified, то ресурс изменил-

ся хотя бы однажды между этими ответами. Разница между значениями Last-

Modified дает нижнюю границу времени^ которое прошло между двумя последующи-

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

ние Last-Modified, равное 13 часам, а второй

—

14. Предыдущая версия запроса суще-

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

ду двумя ответами, то время между модификациями будет меньше одного часа. Этот

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

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

тле

функционирует Web-сервер.

Заголовки HTTP-ответов не всегда включают строку Last-Modified. В некоторых

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

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

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

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

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

Content-Length. Если два ответа с одним и тем же URI имеют разные значения

Content-Length, то ресурсы различны. Но обрапюе предположение неверно. Ресурс

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

Content-Length позволяет получить консервативную оценку частоты изменений.

Строки Content-Length может не быть среди данных некоторых измерений. На-

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

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

размер заголовка ответа. Размер отправленных данных не совпадает для разных за-

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

данные были нереданы или ответы имеют разные кодировки данных. В некоторых

случаях М0Ж1Ю косвегпхым образом определить, какие запросы были отменены. Рас-

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

рого URI. Предгюложим, что один запрос имеет меньший размер отнравлегншхх дан-

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

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

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

размер. Еще один эвристический прием основывается на том, что некоторые про-

кси-серверы и Web-серверы пишут ответы в буфер сокета блоками фиксированного

размера (4096 или 8192 байта). Размеры отнравлегпхых данных, делящиеся нацело на

размер блока, скорее всего, соответствуют отменеьпшш запросам.

9.6. Примеры исследовательских проектов

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

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

для получения информации о характеристиках Web-трафика:

• Исследование журналов серверов в Университете провинции Саскачеван.

Шесть журналов серверов с записями 1995 года был проанализирован на

предмет изучения параметров Web-трафика [AW97].

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

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

—

Прим.

ред.

348 Часть IV. Измерение и описание Web-трафика

• Исследование журналов прокси-серверов в Британской Колумбии. Набор

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

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

конфигурациях [DMF97J.

• Исследование клиентских журналов Бостонского университета. Журналы,

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

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

щего при этом сетевого трафика [СВС95, CB97J.

• Мониторинг пакетов в AT&T. Журнал монитора пакетов 1996 года был ис-

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

этих изменений [DFKM97].

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

жим рассмотрение примеров активных Web-измерений до главы 15 (раздел 15.4).

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

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

же существенно зависят от места и времени сбора данных).

9.6.1.

Исследование журналов Web-серверов, проведенное

Университетом провинции Саскачеван

Изучение журналов Web-серверов, проведенное Университетом провинции

Саскачеван, имело целью определить ключевые характеристики Web-трафика

[AW97].

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

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

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

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

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

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

тов в ответе в следующем формате:

Hostname — [dd/mmm/yyyy:hh:mm:ss:tz] request status bytes

Журналы не включали информации о времени, потраченном на генерацию и пе-

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

информации о полном наборе файлов на серверах, которые могли быть запрошены

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

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

из журналов серверов, как показано в таблице 9.3. Некоторые основные статистики

были рассчитан*ы неносредствегпю, исходя из значений полей журналов. Напри-

мер,

число различающихся запрошенных URI, сред1П1Й размер ответа, а также час-

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

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

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

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

следовательными запросами, приходящими на сервер. Это позволило оцепить дина-

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

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

дующими запросами одного и того же ресурса. Исследование этих свойств было

важгю из-за их влияния на эффективность Web-кэшировапия. Другая информация

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

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

содержимого. Количество переданной информации, связанное с за11роше1П1ым URI,

Глава 9. Измерение Web-трафика

349

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

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

Таблица 9.3. Ключевые метрики исследования журналов Web-сервсров, проведенное

Университетом провинции Саскачевап

Категория

Основные статистики

Пользовательские предпочтения

Данные, полученные косвенно

Метрика |

Число различающихся запрошенных URI |

Средний размер/медиана ответов |

Частоты кодов ответов |

Время между запросами

Популярность запрашиваемых ресурсов |

Время между запросамрт одного и того же ресурса |

Типы содержания запрашиваемых ресурсов |

Среднее значеиие/медиапа размеров ресурсов |

Частоты модификаций ресурсов |

Частоты отмененных запросов

9.6.2. Исследование журналов прокси-серверов

в Британской Колумбии

Исследователи Университета Британской Колумбии проводили исследование

Web-кэширования на основе семи журналов прокси-серверов, датированных 1996

и 1997 годами [DMF97]. Эти журналы предоставлены различными учреждениями,

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

ра. Все эти организации использовали прокси-сервер Squid, описанный в главе 11

(раздел 11.10.1). Журналы отличались друг от друга но характеру содержащейся

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

запроса, запрошенный URI и размер ответа. Чтобы защитить интересы пользовате-

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

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

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

в течение последующих дней; другие пять серверов применяли одну и ту же функ-

цию па протяжении всего периода протоколирования. Шесть журналов были от кэ-

ширующих прокси-серверов. Эти журналы включали дополнительное поле, пока-

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

ле не включали это поле, по включали значения заголовков Last-Modified и

Expires, когда они присутствовали в HTTP-ответе сервера.

В отличие от предыдущего проекта, данный проект не ставил цели статистически

охарактеризовать результаты измерений. Вместо этого журна7Ш1 были использованы

для оценки эффекгивгюсти кэширования на прокси-серверах при помощи моделиро-

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

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

кси-сервера, основанную на Squid. Моделирование являлось цепной альтернативой

экспериментам па работающем прокси-сервере. Во-первых, перенастраивать работаю-

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