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

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

490

Часть

VI.

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

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

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

общения.

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

параметров первого сообщения на уровне HTTP. При восстановле1Н1и сообще-

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

теми же ситуациями, что и лю-

бой другой компонент HTTP/1.1, а именно:

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

жить, что сообщение не содержит тела, а также следующее сообщение начина-

ется сразу же после двойного CRLF. Например, запросы GET и ответы 304

Not Modified не содержат тела сообщения.

• Наличие поля Content-Length. Некоторые сообщения содержат заголовок

Content-Length, который указывает размер тела сообщения. Это позволяет

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

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

• Сообщение, разбитое на фрагменты. Некоторые НТТР-сообщепия содержат

метаданные в теле сообщения. При этом содержимое НТТР-сообщепия делит-

ся на несколько фрагментов, как описывалось ранее в главе 7 (раздел 7.6). Ка-

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

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

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

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

• Multipart/byteranges. Сообщение-ответ с заголовком типа содержимого Соп-

tent-Type:multipart/byteranges имеет в теле сообщения несколько диапазо-

нов данных, о чем говорилось ранее в главе 7 (раздел 7.4.1). Заголовок

HTTP-ответа идентифицирует разгра1Н1читель, который помечает начало ка-

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

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

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

• Конец ТСР-соединения. Последний способ обнаружения монитором конца

сообщения-ответа

—

это выявить, что ТСР-соединение было завершено паке-

тами FIN или RST. Это может случиться, если сервер использует закрытие

ТСР-соединения для указания конца тела ответа, либо если клиент или сер-

вер прервали ТСР-соединение.

Введение в НТТР/1.1 разбиения на фрагменты и сообщений, состоящих из не-

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

бует от монитора пакетов просмотра тела сообщения. Для трафика НТТР/1.0

в этом нет необходимости. Кроме того, граница между двумя сообщениями может

проходить внутри одного 1Р-накета из-за конвейеризации.

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

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

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

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

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

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

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

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

данного сообщения и начало следующего сообщения. Утеря заголовка фрагмента

Глава

14.

Перспективы

исследований,

связанных

измерениями

491

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

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

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

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

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

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

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

аппаратных компонентов монитора пакетов.

В то время как потеря пакета с HTTP-заголовком порождает существенные про-

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

ботку потока. Потеря нескольких сотен байтов в большом документе в формате

Postscript не мешает монитору находить следующее сообщение в потоке. На самом

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

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

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

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

ти к следующему сообщению в потоке. Если монитор регистрирует только HTTP-за-

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

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

шинства захваченных IP-пакетов. Типовое сообщение НТТР-ответа содержит около

300 байтов в заголовке и около 10 килобайтов в теле сообщения. Ипюрирование

тела сообщения избавляет от необходимости просматривать примерно 97% перехва-

ченных данных.

14.1.6. Создание НТТР-трасс

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

цию об НТТР-трафике. Соответствующий набор полей зависит от того, для какого

вида анализа будут использоваться эти записанные значения (трассы). В противо-

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

кетов может содержать информацию па нескольких протокольных уровнях (IP,

TCP,

HTTP), а также метки времени для ключевых этапов каждой НТТР-транзак-

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

Web-трафика па пакетном уровне не существует никаких официальных или не-

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

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

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

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

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

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

аппаратных средств восстановления.

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

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

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

SYN-ACK и клиентского АСК. Метки времени для двух пакетов SYN помечают

начало каждого направления ТСР-соединения. Аналогично, метки времени пакетов

FIN или RST в каждом из направлений помечают конец соединения. Отслежива-

ние,

заканчивается ли соединение пакетом FIN или RST, дает возможность иденти-

фицировать прерванные передачи. Кроме того, трасса может идентифицировать,

сталкивался ли монитор с потерей пакетов для данного ТСР-соединения, и не па-

492

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

рушила ли потеря пакетов процесс восстановления. Помимо полей, приведенных

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

пакета в ТСР-соединении. Эти сведения могут оказаться полезными для опреде-

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

информации.

Таблица 14.1. Примеры полей в трассе пакетов

Категория

TCP/IP

HTTP

Содержимое

Примеры 1

IP-адреса клиента и сервера |

Количество переданных пакетов и байтов |

Метка времени для начала TCP-соединения (SYN) |

Метка времени для конца ТСР-соедипеиия (FIN/RST) |

Способ завершения потока (FIN или RST) |

Ошибки (отсутствующий пакет в составе потока) |

Заголовок запроса HTTP |

Заголовок ответа HTTP |

Метка времени начала HTTP-заголовка |

Метка времени начала тела HTTP |

Метка времени конца тела HTTP |

Ошибки (сообщения с некорректным синтаксисом HTTP) |

Контрольная сумма тела содержимого |

Встроенные ссылки

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

та HTTP. Выборочная регистрация подмножества заголовков сократит затраты на

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

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

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

базового ТСР-соединения, как было показано ранее на рис. 14.2. Поскольку одно

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

чала и конца ТСР-соединения не обязательно являются хорошими показателями

для определения времени отправки каждого НТТР-сообщепия. Монитор пакетов

может регистрировать метки времени для основных частей НТТР-сообщепия: на-

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

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

внимание метки времени, ассоциированные с соответствующими IP-пакетами.

Некоторые HTTP-сообщения содержат тело содержимого. Теоретически монитор

пакетов может записывать тело каждого НТТР-сообщепия. Однако это приведет

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

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

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

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

изменился ли Web-pecypc с последнего обращения к нему. Помимо этого, регистра-

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

Глава

14.

Перспективы

исследований^

связанных

измерениями

493

ной для определения Web-ресурсов, связанных с Web-страницей. Монитор может

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

в зависимости от информации в HTTP-заголовке. Например, просмотр заголовка

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

гут иметь гипертекстовые ссылки и встроенные ресурсы. Кроме того, монитор может

с помощью синтаксического анализатора HTML извлечь URL и записать их в трас-

су. Или же монитор может записать весь HTML-файл и отложить синтаксический

анализ данных на более позднее время.

14.2,

Анализ журналов Web-серверов

Необходимость обработки больших и разнообразных наборов да1Н1ых измере-

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

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

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

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

преобразования и анализа данных [KR98J.

14.2.1.

Синтаксический анализ и фильтрация

При оценке новых методов повышения эффективности Web требуется особое

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

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

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

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

изводительность других серверов. Анализ множества журналов различных Web-сай-

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

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

нение

0Д1ЮГ0

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

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

с разным количеством и типами полей, о чем говорилось в главе 9 (раздел 9.3). Часы

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

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

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

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

—

эффективный способ скрыть эти детали от про-

фаммного обеспечения, осуществляющего анализ данных.

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

—

необходимый начальный этан. Он требует

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

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

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

менную определегпюго типа. Например, коду ответа HTTP в серверном журнале

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

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

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

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

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

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

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

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

494

Часть

VI.

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

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

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

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

HTTP-запросов, о чем говорилось в главе 4 (раздел 4.4). Эти процессы конкури-

руют при записи данных в журнал сервера. Если сервер не осуществляет специ-

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

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

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

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

BCiHio важным при обработке HTTP-запросов. Даже если сервер пытается упоря-

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

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

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

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

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

лов,

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

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

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

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

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

вол новой строки (ctrl-M), который приводит к ошибочному обнаружению конца

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

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

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

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

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

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

ременной выделяется заранее (например, функция scan/Q в языке программирова-

ния С). Если длина URL превышает ожидаемую, процедура синтаксического anajni-

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

к повреждению других данных в памяти. Ошибки подобного рода особенно трудно

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

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

го анализа записи. Альтернативой является наличие в профамме отдельгюй проце-

дуры для обработки длинных URL в случае их обнаружения.

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

ни в различных серверных журналах. При анализе набора реальных серверных жур-

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

времени. Создание профаммы для синтаксического анализа и игггернретации раз-

личных форматов

—

хлопотное дело. Кроме того, такая профамма, скорее всего, бу-

дет иметь внутренние ошибки. Очень полезно иметь отдельную библиотеку проце-

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

ных журналах. Такие процедуры могут быть тщательно отлажены и многократно

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

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

ствующему, например, количеству секунд, прошедших с полуночи 1 января 1970 г.

(представление времени в UNIX). Это позволит остальным профаммам ипюриро-

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

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

которые создают эти журналы. На практике довольно трудно установить соотноше-

Глава

14.

Перспективы

исследований,

связанных

измерениями

495

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

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

лось ранее в главе 9 (раздел 9.3.1).

После синтаксического анализа записи и проверки синтаксических ошибок, ка-

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

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

тов HTTP должны представлять собой трехзначные целые числа, начинающиеся

с 1, 2, 3, 4 или 5, а все метки времени должны лежать внутри интервала времени,

соответствующего времени существования журнала. Записи с неправильными по-

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

также упрощает процесс написания и отладки программ для анализа измерегпхых

данных. Помимо этого, операции над журналами в универсальном формате позво-

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

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

ная версия журнала, содержащая имя клиента (IP-адрес), запрашиваемый URI, код

ответа и время запроса.

14.2.2.

Преобразования

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

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

зирующих программ, которые оперируют строками URL,

—

весьма утомительное за-

нятие. Для URL допустимо множество форматов, в результате чего один и тот же

ресурс в Web может иметь множество представлений. Рассмотрим ресурс foo.htmi,

размещегпшш па Web-сайте www.xyz.com. Записи в журнале для этого ресурса мо-

гут иметь множество различных URL, таких как http://www.xyz.com/foo.htmI,

www.xyz.com/foo.htmI, foo.htmi или www.xyz.eom///foo.htmI. Преобразование это-

го URL к канонической форме требует манипулирования строками для поиска и

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

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

просто. Наличие отдельной библиотеки процедур для синтаксического анализа и ра-

боты со строками может избавить от Х7Юпот, связанных с написанием профамм для

обработки журна7юв.

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

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

сервером при обработке запроса. Например:

• Удаление "http://" и доменного имени компьютера, если оно присутствует.

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

http://www.xyz.com/foo.html и foo.htmi ссылаются на один и тот же ресурс.

Имя сервера может иметь псевдоним, это означает, что http://www.xyz.com/

foo.htmi и http://xyz.com/foo.html относятся к одному и тому же ресурсу.

• Двойные символы "/" могут быть удалены. Например, /bar//foo.html может

быть преобразовано в /bar/foo.html.

• Могут быть извлечены составные части URL. Например, суффикс URL часто

идентифицирует тип содержимого ресурса (например, .html или .gif). Иденти-

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

сматривает удаление имени ресурса в конце URL; например, /files/bar/foo.html

имеет путь /files/bar.

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

Хотя многие URL могут быть преобразованы указанным образом, в некоторых

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

Например, http://www.xyz.com/bar может ссылаться на ресурс bar или же соот-

ветствовать документу http://www.xyz.com/bar/index.html, если bar — каталог.

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

как псевдоним другого URL. Распознать, что два URL соответствуют одному и

тому же ресурсу, при отсутствии информации о настройках сервера будет затруд-

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

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

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

пивших от образовательных учреждений (например, .edu в users.berkley.edu).

Для большинства задач анализа знание конкретных URL и имен клиентов или

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

одни и те же URL или относятся к одному клиенту. Для упрощения анализа поля,

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

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

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

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

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

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

формату. Профамма ассоциирует целое число с каждым URL в порядке их вхожде-

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

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

лым числом.

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

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

ствует ли в хэш-таблице приведе1Н1ый к каноническому виду URL, чтобы опреде-

лить,

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

ма ассоциирует новый URL со следующим по порядку целым числом и помещает

запись в хэш-таблицу. Для обработки журналов с большим числом различных

URL требуется эффективная реализация хэш-таблиц. Достаточно часто встречают-

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

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

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

тивной памяти. Если потребность в памяти превышает доступный объем, операци-

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

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

ла. Эффективные процедуры хэширования на таких языках, как С или Java, обыч-

\ю требуют гораздо меньше памяти, и преобразова1П1е данных осуществляется го-

раздо быстрее.

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

состоит из небольшого числа целых чисел. Анализ журналов предполагает после-

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

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

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

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

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

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

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

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

Глава 14. Перспективы исследований, связанных с измерениями 497

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

держать все запросы клиента 1, за которыми следуют все запросы клиента 2, и т.д.

Сортировка журнала по идентификаторам клиентов намного упрощает задачу под-

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

может оказаться сортировка но идентификаторам ресурсов.

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

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

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

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

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

могут иметь один и тот же идентификатор клиента и одну и ту же отметку време-

ни.

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

и встроенных изображений. Эти запросы поступают близко во времени, возможно,

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

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

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

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

порядок. Обеспечить, чтобы процедура упорядочения выполняла такую «стабиль-

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

таких записей в журнале.

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

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

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

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

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

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

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

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

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

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

на ранних этапах анализа данных измерений.

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

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

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

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

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

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

значительно облегчить выполнение задач анализа. Программа предварительной об-

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

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

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

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

с разработкой, отладкой и оптимизацией программного обеспечения. Например,

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

лись библиотеки sfio (safe/fast I/O) и libast

[KV91,

FKV95J, которые позволили на-

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

и анализа измеренных данных.

498

Часть

VI.

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

14.3.

Общедоступные журналы и трассы

Многие исследования параметров Web-трафика основываются ик общедоступ-

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

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

нилище журналов и трасс. В их числе Internet Traffic Archive

[ITAj,

хранилище,

создагнюе группой Web Characterization Group консорциума World Wide Web

Consortium [WCAJ, коллекция NLANR [IRCJ и CAnet Squid Logs [CanJ.

Журналы обычно предоставляются «как есть»

—

в форме, в которой они были

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

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

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

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

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

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

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

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

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

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

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

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

из хранилища.

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

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

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

Наличие хранилища сертифицированных журналов дает возможность осуществ-

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

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

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

Гругнюй Web Characterization Group была предпринята попытка определить

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

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

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

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

ны стандартные инструментальные средства. Если журнал был представлен в фор-

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

а и MCI

ню:

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

количество полей. Это облегчает написание простого синтаксического анали-

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

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

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

ются допустимыми.

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

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

щий записи в ожидаемом формате.

Глава 14. Перспективы исследований, связанных с измерениями 499

14.4.

Измерение параметров мультимедийных

потоков

Измерение параметров и анализ Web-трафика играет важную роль в оценке

Web-протоколов и программных компонентов. Однако измерению характеристик

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

деле вкратце рассматриваются четыре метода сбора да]Н1ых измерений параметров

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

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

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

щих сообщений и данных. Ниже будет описано, как эти методологии применяются

в реальных исследованиях.

14.4Л. Статический анализ мультимедийных ресурсов

Первоначально HTTP был доК1ииирующим протоколом для передачи имеющих-

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

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

щенных па Web-серверах [AS98]. Помимо традиционных параметров рабочей па-

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

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

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

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

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

казателей па основе содержимого файлов. Теоретически для решения каж/юй их

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

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

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

Для гюиска видеофайлов в Web исследователи используют существующие поиско-

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

строки в составе URL. Поиск подстроки, например, ".mpg" или ".avi", дает в результате

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

с ".mpg" или ".avi" в составе URL. Запрос к поисковой машине выдает список URL

для Web-страпиц. Затем исследователи написали отдельную профамму для зафузки

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

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

Web-страницах, необходимо обработать список для удаления повторяющихся URL.

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

правки HTTP-запроса GET для каждого URL. Около половины запросов по той или

иной причине оказываются безуспешными. Некоторые запросы возвращают ответ

404 Not Found, если запрошенный ресурс отсутствует на Web-сайте. В других слу-

чаях Web-сервер возвращает код 200 ОК. Однако это не обязательно подразумевает,

что ответ содержит нужный видеофайл. Например, файловое расширение в URL мо-

жет не соответствовать реальному формату файла. Кроме того, некоторые файлы

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

файлы имеют длительность менее одной секунды или частоту кадров, меньшую, чем

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

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

клип. Отсев некорректных URL и файлов, которые представляются некорректными,

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