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

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

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

информацию и позволяют отслеживать пользовательские запросы. Заголовок From

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

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

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

зователя. Другие заголовки, такие как Accept-Language, могут дать дополнитель-

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

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

принимает HTTP-ответ через ТСР-соединение. IP-адрес пользовательского компь-

ютера ассоциируется с браузером — конечной точкой ТСР-соединения, и отобра-

жается в каждом IP-пакете при передаче. Простой DNS-запрос может преобразо-

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

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

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

вателе может сделать другая сторона. Информация об организации пользователя

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

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

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

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

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

почты viv@foo.com посетил Web-сайт с информацией по определенным заболевани-

ям,

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

гюльзователя. Знание специфики запросов, посланных пользователем, дает еще

больше информации. Пусть пользователь загрузил Web-страницу, содержащую спи-

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

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

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

смотре сайта. Администратор Web-сайта может также продать адрес электронной

почты и информацию о просмотренных страницах сторонней компании.

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

пользователя и пароль на удаленном компьютере, как это oбcyждaJюcь в главе 7 (раз-

дел 7.10). При использовании обычной (Basic) схемы аутентификации в HTTP/1.0

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

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

НТТР/1.1 решает эту проблему путем поддержки аутентификации с помощью дай-

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

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

довательные запросы одного и того же пользователя. Сервер может связать cookie

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

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

Cookie используется мгюгими сайтами. Администраторы Web-сайтов могут сотруд-

ничать между собой с целью объединения информации и отслеживания 1Юльзовате-

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

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

ных изображений или ответов переадресации.

Поле заголовка запроса Referer содержит URL ресурса, с которого был осуще-

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

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

Referer может инфорлнфовать сторонних лиц о существовании ресурсов, не пред-

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

Web-страницу и послал ее URL определенной группе лиц. Никаких других гипер-

Глава 10. Описание параметров рабочей нагрузки 381

ссылок на эту страницу нет. Но если пользователь щелкнет на гинерссылке на этой

странице, то ее URL будет записан в поле заголовка Referer. Любые данные изме-

рений, которые включают содержимое поля Referer, будут содержать э1'от URL.

Запросы к таким URL могут фиксироваться прокси-серверами. Кроме того, клиент

может обнаружить такую страницу путем последовательного перебора набора URL

1[о

тех нор, пока не будет возвращена нужная страница. На практике ограничить

доступ к частным ДУеЬ-страницам можно только с помощью аутентификации но

имени пользователя и паролю.

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

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

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

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

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

что они будут отвергать cookies всех Web-сайтов за исключением указанного огра-

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

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

того,

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

при отправке формы пользователь может отказаться вводить адрес электрон1ЮЙ

почты. Пользователь может ограничить объем личной информации, передаваемой

в HTTP-заголовке, направляя запрос прокси-серверу, осуществляющему аноними-

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

дитной карточки, то использование SSL и HTTPS эффективно предотвращает пе-

рехват информации.

10.7,2.

Информация, доступная компонентам

программного обеспечения

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

мации, присутствующей в HTTP-запросе и ответном сообщении. Браузер имеет

наиболее полную информацию о пользовательских предпочте1Н1ях, нользоватеъчь-

ских действиях, содержимом HTTP-запросов и ответных сообщешгй. По сравне-

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

веренным» приложением. Однако он может передать личную информацию другим

программным компонентам через заголовок HTTP-запроса. Это происходит но

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

ки ответного НТТР-сообщепия. Во-вторых, браузер и серверное программное обес-

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

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

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

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

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

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

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

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

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

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

НТТР-занросам, передаваемым от лица пользователя Web-серверам. Кроме того,

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

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

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

382

Часть

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

може']'

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

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

.'jcii,

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

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

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

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

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

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

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

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

опредсле1Н10го клиента. По сравнению с прокси-сервером, Web-сервер имеет боль-

HHie трудности в распознавании того, какие из запросов пришли от данного клиен-

та. O/uiaKO если пользователь посылает личную информацию па Web-сайт, то сце-

jiapin'i, обрабатывающий пользовательский запрос, может связать эти данные

с cookie. Принимая эти cookie в последующих HTTP-запросах, сценарий может

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

может извлекать личную информацию из заголовка Authorization. В некоторых

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

мац1Н1 Web-сайту. Например, многие компании имеют Web-сайты, которые пре-

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

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

сти,

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

доступны третьей стороне.

Как участники передачи да1П1ых, браузеры, ирокси- и Web-серверы непосредст-

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

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

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

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

Honeirrbi могут восстановить HTTP-сообщение, как и другой 1Р-трафик, включая

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

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

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

дан]н>1м, что и Web-браузер. К тому же такие компопепты могут быть установлены

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

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

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

дение за его деятельностью.

10.7.3.

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

Несмотря на наличие доступа к тексту HTTP-сообщений большинство компо-

нентов программного обеспечения не регистрирует эту информацию. На практике

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

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

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

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

1П1СИ, а также в какой форме. Например, отслеживание или регистрация может

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

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

BaicieM является важной частью анализа рабочей нагрузки Web. Однако этот ана-

Глава 10, Описание параметров рабочей нагрузки 383

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

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

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

ния Web-сайта или рекламных материалов. Для этого нет необходимости в иденти-

фикации пользователя, запрашивающего страницы.

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

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

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

пример, провайдер может принять решение о мониторинге пакетов или ведении

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

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

Web-сервера для его настройки или для реорганизации информационного содер-

жания. Важная информация о клиентах, такая как имена клиентов, почтовые адре-

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

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

внутренних целей с ограниченным доступом к ним. Файлы, передаваемые другим

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

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

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

Новые технологии могут быть направлены па повышение защищенности пользо-

вателей. Например, Консорциум Всемирной паутины (W3C) разрабатывает Плат-

форму для описания параметров безопасности (РЗР — Platform for Privacy Prefe-

rences) [P3PJ, которая позволяет пользователю определять состав личной информа-

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

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

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

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

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

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

с «внутренней кухней» Web. Новые разработки могут помочь найти компромисс ме-

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

дан1Ш1е для анализа пользовательского поведения и рабочей нагрузки Web.

10.8.

Резюме

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

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

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

ки.

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

теристики относительно стабильны. Большая часть изменений характеристик

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

роятностей, а не самого распределения. Кроме того, соотношение между парамет-

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

ным. Разброс характеристик нагрузки Web, тенденции изменения во времени и

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

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

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

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

тировании нрокси- и Web-серверов различного назначения. Наконец, несмотря на

384

Часть

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

необходимость проведения детальных измере1Н1Й Web-трафика, сбор информации

о НТТР-занросах и ответах может нарушать конфидепциальпость пользователей.

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

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

следо!зателы10стей запросов данного пользователя. Мониторы пакетов и перехва-

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

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

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

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

фиденциальностью и необходимостью получения информации о характеристиках

рабочей нагрузки.

Часть

Web-приложения

Кэширование

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

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

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

ство пользователей предпочитают посещать небольшое число одних и тех

же

сай-

тов.

За несколько лет кэширование стало основной технологией сокращения тра-

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

• Основы и механизм кэширования. Обзорная часть главы начинается с основ-

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

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

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

Internet, через различные уровни стека протоколов (DNS, TCP, HTTP) к ис-

ходному серверу и обратно. Раздел

что

объясняет, что же влияет на принятие

решения о кэшировании сообщений. Семантически прозрачный кэш, который

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

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

HTTP. В разделе где говорится о местах, где выполняется кэширование на

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

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

нии сообщений. Обзор продолжает

обсуждение

актуальности кэша и замены

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

сов на принятие решения о кэшировании.

• Практика кэширования. Практическая часть главы начинается с взгляда на

то,

как кэши совместно используют информацию, и на различные протоколы,

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

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

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

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

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

ванием, на коммерческом и на социальном уровнях. Далее будет рассмотрена

репликация

—

концепция, близкая к кэшированию, но основанная на других

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

направления: распределение и адаптация Web-содержания.

Кэширование обсуждается также в других главах книги:

• В главе 2 кратко обсуждается кэширование браузерами.

• В главе 3 кратко показана роль прокси-серверов в кэшировании.

388 Часть V. Web-приложения

• В главе 7 (в разделе 7.3) в связи с кэшированием обсуждается протокол

HTTP/1.1.

• В главе 13 рассмотрены новые технологии кэширования.

В этой главе имеется исчерпывающий обзор темы. Отметим, что в главе терми-

ны объект и ответ считаются взаимозаменяемыми.

11.1.

Истоки и цели Web-кэширования

Проект стандарта HTTP/1.1 (RFC 2616) определяет кэширование как локальное

хранение ответных сообщений. Более свободная трактовка определения кэширова-

ния — перемещение содержания ближе к пользователю. Кэширование является,

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

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

ний. Начнем с краткой истории кэширования, далее определим цели кэширования и

перечислим проблемы, возникающие при решении задач кэширования.

Первый Web-сервер httpd (созданный в Швейцарии, в Женевской лаборатории

ЦЕРН) имел прокси-сервер, который включал кэш [LA94J. Один из самых ранних

проектов, связанных с Web-кэшированием, Harvest [BDH^94], индексировал ин-

формацию в Internet. Harvest кэшировал и реплицировал информацию, собранную

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

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

кэшах. Реестр отвечал за запросы о расположении других кэшей. Разнесенные

в пространстве кэши могли объединять свои ресурсы. После разработки Harvest

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

Ко времени появления HTTP/1.0 кэширование уже стало важным и необходи-

мым компонентом Web. Ранние эксперименты, связанные с кэшированием и изме-

рениями, проведенные до 1994 г. [ВС94], продемонстрировали возможности значи-

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

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

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

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

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

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

границы. Кэширование было первым из основных Web-приложений, используе-

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

Целями кэширования является уменьшить:

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

теля ответа (время ожидания ответа пользователем);

• нагрузку на сеть путем устранения повторных передач одинаковых ответов;

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

клиентом и сервером, обрабатывающим запрос.

Первая цель является наиболее известной целью кэширования. Сокращение вре-

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

Web,

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

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

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

чение к Internet. Быстрое получение Web-страниц увеличивает пользовательские

ожидания на получение большего объема информации с сайта.

Глава

11.

Кэширование

389

Вторая цель главным образом влияет на сеть, но имеет игггереспый побочный эф-

фект. Передача только

необходимой

информации (т.е. устранение повторных передач

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

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

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

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

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

число запросов от различных клиентов. Увеличение числа обрабатываемых запро-

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

дит к уменьшению числа отказов в установлении ТСР-соединений из-за перепол-

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

11.2.

Зачем нужно кэширование?

Начнем с мотивации кэширования. Хостинговые компании платят за полосу

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

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

обмена Web-сообщениями. Конечные пользователи получают значительный выиг-

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

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

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

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

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

точках Internet, то может оказаться полезным сокращение трафика или перенос его

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

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

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

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

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

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

женным ближе к серверу.

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

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

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

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

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

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

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

цессе загрузки ресурсов определяются следующими факторами:

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

ра с Internet;

• если ответ па запрос к DNS-серверу отсутствует в кэше, то затрачивается время

на обращение к DNS-серверу для преобразования доме^пюго имени в IP-адрес;

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

в сети;

• перегрузка исходного сервера;

• время создания ответа;

• время отображения ответа браузером.