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

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

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

Заголовки HTTP-запросов и ответов предоставляют богатую информацию о передаче данных в сети. Но некоторые журналы и данные мониторинга пакетов не содержат полных НТТР-заголовков. Большинство журналов серверов записывают строку запроса и код ответа, по не полные заголовки ответов и запросов. Сбор более детальной информации требует перенастройки или модификации сервера. Монитор пакетов, клиент, прокси-сервер или Web-сервер могли бы записывать заголовок каждого сообщения и все тело сообщения. Но на практике это зачастую неосуществимо. Многие исследования опираются на журналы Web-серверов и прокси-серверов, в которых записана только часть всех строк НТТР-заголовков. В некоторых случаях запрос, зарегистрированный в журнале, может быть уточнен посредством отправки запроса тому же серверу и наблюдения за ответом. Но такой подход будет неуместен, если запрошенный ресурс был изменен на сервере или если ответ зависит от состава заголовков НТТР-запроса.

Некоторая недостающая информация может быть реконструирована на основе таких полей, как метод запроса, запрошенный URI и код ответа, которые доступны в журнале сервера. По значению поля, содержащего запрошенный URI, можно определить тип запрошенного ресурса. Например, URI, заканчивающиеся на .htmI или .htm скорее всего соответствуют HTML-файлам, в то время как URI, закапчивающиеся на .gif или .jpg, скорее всего соответствуют изображениям; хотя некоторые изображения имеют другие расширения файлов, а некоторые URI, закапчивающиеся на .gif или .jpg, могут не соответствовать изображениям. Подобным образом но запрошенному URI или методу запроса можно определить, вызывает ли запрос иснолнение сценария на сервере. Запрошенный URI, включающий строку "cgi" или "cgi-bin", обычно соответствует сценарию1. Запросы GET с параметрами в копце URI, а также запросы POST обычно соответствуют HTML-формам. Эти эвристики могут использоваться в простых статистических процедурах, например, при вычислении доли запросов, ответы на которые представляют собой динамически генерируемое содержимое или содержимое определенного типа.

Некоторые коды ответов подразумевают паличие определенных строк в заголовке HTTP-запроса. Например, ответ 206 Partial Content подразумевает, что клиент запросил часть ресурса, используя заголовок Range. Аналогично, ответ 304 Not Modified подразумевает, что запрос включал проверку актуальности ресурса, например, с помощью строки заголовка If-Modified-Since. Однако в ответ на запрос Range или If-Modified-Since Можно получить ответ 200 OK, как если бы был возвращен весь ресурс. Таким образом, коды ответов могут дать иредставлепие только о нижней границе частоты появления определенных типов запросов, но не их Точное число. Некоторые аналитические задачи могут использовать коды ответов для определения того, какие запросы игнорировать при проведении тех или иных расчетов. Например, рассмотрим задачу подсчета количества уиикальпых запросов на ресурсы сервера на основе серверного журнала. Запрошенный URI, который всегда приводит к ответу 404 Not Found не должен быть включен в обрабатываемые данные, так как запрошенный ресурс отсутствовал на сервере в период формирования журнала.

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

На практике бывает трудпо выявить, связаны ли пары запрос-ответ с одним и тем же пользователем. Например, IP-адрес клиента, зафиксированный сервером, не обязательно является уникальным идентификатором пользователя. С одним и гем же клиентом могут работать несколько пользователей, а один и тог же пользователь может выходить в Internet с различными клиентскими IP-адресами, как описано в разделе 9.2.1. Подобным же образом, IP-адрес сервера, полученный при мониторинге пакетов, не является уникальным идентификатором. На одном и том же компьютере могут работать несколько Web-серверов, а один и тот же Web-сайт может размещаться на различных компьютерах. Доменное имя сервера можно получить из запрошенного URI или строки Host заголовка запроса НТТР/1.1, предполагая, что результаты измерений включают эту строку. В запросах НТТР/1.0 такого поля нет. В некоторых случаях IP-адрес сервера может быть преобразован в доменное имя на более поздней стадии проведения анализа с помощью запроса к DNS-серверу. Но к моменту анализа ответ DNS-сервера может отличаться от того же на момент передачи данных.

Различение уникальных ресурсов также может быть в некоторых случаях затруднено. При обработке запроса сервер преобразует запрашиваемый URI в имя файла. Рассмотрим задачу определения числа уникальных ресурсов, запрошенных с Web-cepвepa, на основе поля Request в журнале сервера. В некоторых случаях различные запрашиваемые URI соответствуют одному и тому же ресурсу. Например, http://www.foo.com и http://www.foo.com/index.html Обычно соответствуют одиому и тому же файлу (/www/index.html). Хотя значение URI зависит от регистра символов, Web-cepвep может быть настроен таким образом, чтобы трактовать запрос http://www.foo.com^NDEX.HTML как другое имя для http://www.foo.com/index.html. Некоторые преобразования включают в себя достаточно тривиальные операции, такие как удаление повторных символов "/". Запрошенные URI, которые отличаются в чем-то незначительном, могут быть отслежены во время обработки журнала. В других ситуациях сервер может трактовать некоторые URI как псевдопимы других URI. Без доступа к настройкам сервера распознавание таких имеи практически невозможно. Большинство исследований обычно предполагает, что различные URI соответствуют различным ресурсам.

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

Анализ результатов измерений Web-трафика Обычно требует определения того, когда и как часто происходят определенные события, связанные с пользователем. Изучение поведения пользователя включает, например, определение, когда пользователь щелкает мышью на гиперссылке. Даже если программный клиент используется лишь одним пользователем, все равно определение и классификация действий пользователя представляет собой сложпую задачу. Информация из НТТР-запро- сов и ответов, также как длительность передачи и размер отправленных данных, могут быть использованы для реконструкции ключевых событий. Например, поле Time в журпале сервера предоставляет удобпый способ определить последовательность запросов, отправленных одним и тем же клиентом. Время между последующими запросами может подсказать, какие запросы отпосягся к одному сеапсу посещения Web-сайта и какие из эгих запросов соответствуют активизации пользователем гиперссылки, в отличие от запросов на встроенные ресурсы, которые посылаются браузером автоматически.

HTTP не сохраняет своего состояния, что затрудняет определение того, какие запросы связапы друг с другом, так как сеанс взаимодействия клиента и Web-сервера не имеет четкого пачала и конца. Вместо этого, начало сеанса взаимодействия между клиентом и Web-сервером можно определить на основе измерепий, полученных при протоколировании и мопигорииге пакетов. Первый запрос соответствует пачалу ce- апса. Запрос, пришедший через несколько десятков секунд после предыдущего запроса, сделанного тем же самым клиентом, может рассматриваться как принадлежащий тому же сеансу. Более точные выводы возможны при наличии дополнительной информации о структуре сайта. Например, запрошенный URI может соответствовать гииерссылке на одной из предыдущих страниц, что увеличивает вероятность того, что запрос был инициирован в результате щелчка мышью на гиперссылке на одной из эгих страниц. Информация о гиперссылках на просмотренных страницах может быть получепа из поля Referer в НТТР-запросе. Структура гипертекста может быть получепа с помощью анализа Web-страниц на этапе обработки данных, хотя их содержимое может быть изменено со времеии проведения измерений.

Одиночное действие пользователя, такое как щелчок мышью на гиперссылке, может инициировать несколько HTTP-запросов для загрузки Web-страницы и встроенных в иее изображений. Выявлеиие действий пользователя требует эффективных способов различения запросов, вызванных непосредственно пользователем, и запросов, сгенерированных автоматически. Хотя журнал браузера различает эти запросы, журнал прокси-cepBepa/Web-cepBepa или результаты мониторинга пакетов не будут содержать этой информации, если только не достуипо содержимое всей страницы. Вместо этого может различаться время между последующими запросами: если запрос приходит меньше чем, скажем, через одну или две секунды после предыдущего запроса, отправленного тем же клиентом, то он автоматически считается выданным браузером. Выводы будут точнее, если запрашиваемый URI соответствует изображению, Например, GIF- или JPEG-файлу. Занрошенный ре- cypc с еще большей вероятностью является встроенным изображением, если запрашиваемый URI содержит тог же путь, что и путь к самой странице. Например, запрос http://www.foo.com/bar/pict.gif, который следует в скором времени за запросом http://www.foo.com/bar/index.html скорее всего соответствует встроенному изображению.

Большие промежутки времени между запросами соответствуют щелчку мыши, произведенному пользователем, особенно если запрашивается ресурс, не являющийся изображением. Определение того, какие запросы обусловлены действиями пользователя, важпо для изучения взаимодействия пользователя с Web-сайтом, например, для определения среднего числа переходов между Web-страницами на ce- апс работы пользователя с сайтом. Время между переходами со страницы на страницу может трактоваться как время бездействия или обдумывания. В общем случае эвристика, оспованная на времени между переходами со страницы на страницу, слишком проста. Пользователь может потратить несколько мииут, «обдумывая» содержимое Web-страницы, перед тем, как щелкнуть на гиперссылке, а может щелкнуть мышью на гиперссылке мепьше, чем через секупду. Более того, пользователь может перестать работать на компьютере на какой-то период времени, а затем продолжить iipocMarpHBaTbWeb-caftT. Кроме того, клиент может отправить набор запросов от лица разпых пользователей. Но по-прежпему эвристика, основывающаяся на времени, представляет едипствеипый способ получить информацию о поведения пользователя на основе измерений трафика.

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

Определение того, когда Web-ресурсы создаются, модифицируются и удаляются полезно для анализа изменений на Web-сайте. Кроме того, статистика частоты изме- пеиий может влиять на политику Web-кэшировапия. В идеале Web-сервер мог бы создавать записи о создании, модификации и удалении ресурсов помимо протоколирования запросов пользователей. На практике наблюдение за изменениями затруд- пепо, так как результаты измерений трафика Обычно не включают такой информации. Ресурсы, которые не были пи разу запрошепы, не появятся в журнале. Кроме того, ресурс мог быть модифицирован несколько раз между последующими запросами, а журналы серверов обычно не включают информацию о возрасте ресурса или времени последней модификации. Статистика модификации ресурсов может быть получена косвенным образом из HTTP-заголовков, размеров ответов и времени каждой записи в журнале. В некоторых случаях этих данных бывает достаточно для оценки возраста запрашиваемого ресурса и времени между модификациями.

Рассмотрим задачу по определению возраста ресурса ко времени запроса, основываясь на информации из HTTP-заголовков. Возраст — это разница между временем запроса и временем модификации. Хотя большинство серверов включают время получения запроса в журнал, время последней модификации Обычно не включается. Но монитор пакетов и журнал браузера могут записывать поля Last-Modified и Date из заголовка HTTP-ответа. Возраст ресурса является разностыо этих двух времен. Если результаты измерений не включают время из заголовка Date, время запроса может быть отмечено там, где проходит измерение. Например, журнал монитора пакетов или прокси-сервера может записать время наблюдения запроса. Однако регистрация времени наблюдения запроса не отражает времени на сервере, где генерируется заголовок Last-Modified. Часы, работающие на разпых Компьютерах в Internet, могут не быть синхронизированы. Если возможно, следует внести поправку на разницу времени между часами.

Другой нодход к изучению времени модификации ресурсов включает в себя сравнение заголовков Last-Modified, следующих друг за другом ответов с одним и тем же URI. Если ответные сообщения имеют разные поля Last-Modified, то ресурс изменился хотя бы однажды между этими ответами. Разница между значениями Last- Modified дает нижнюю границу времени1, которое прошло между двумя последующими модификациями ресурса. Предположим, например, что один ответ содержал зпачепие Last-Modified, равное 13 часам, а второй — 14. Предыдущая версия запроса существовала не более часа. Если ресурс менялся больше, чем один раз в промежутке между двумя ответами, то время между модификациями будет мепьше одного часа. Этот подход нечувствителен к разнице между часами сервера и компьютера, так как оба значения были записаны на Компьютере, где функционирует Web-cepвep.

Заголовки HTTP-ответов не всегда включают строку Last-Modified. В некоторых случаях сообщение ответа может включать в себя другой заголовок, например, ETag, который используется для различения версий ресурса. Изменение значения этого поля сигнализирует, что ресурс изменился между двумя последующими запросами, не предоставляя информации о том, когда произошло изменение. В других случаях изменение ресурса может быть определено но изменению Значения заголовка Content-Length. Если два ответа с одинм и тем же URI имеют разные значения Content-Length, то ресурсы различны. Но обратное предположение неверно. Ресурс может быть изменен без изменения его размера. Тем не менее, сравнение строк Content-Length позволяет получить консервативную оценку частоты изменений.

Строки Content-Length может не быть среди данных некоторых измерений. Например, журнал сервера может записывать размер отправленных Ъанных вместо размера ответа. На некоторых серверах размер отправленных данных может не включать размер заголовка ответа. Размер отправленных данных не совпадает для разных запросов одного и того же URI, если некоторые запросы были отменены до того, как все данные были переданы или ответы имеют разные кодировки данных. В некоторых случаях Можно косвенным образом определить, какие запросы были отменены. Рассмотрим в качестве примера журнал сервера, который содержит 20 запросов некоторого URI. Предположим, что один запрос имеет меньший размер отправленных данных, чем остальные, а размеры отправленных данных остальных 19 запросов совпадают. Эгот укороченный ответ мог быть обусловлен отменой запроса. Правда, ресурс мог быть изменен дважды, причем второе изменение вернуло ему его первоначальный размер. Еще один эвристический прием основывается на том, что некоторые прокси-серверы и Web-серверы пишут ответы в буфер сокета блоками фиксированного размера (4096 или 8192 байта). Размеры отправленных данных, делящиеся нацело на размер блока, скорее всего, соответствуют отмененным запросам.

Источник: 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