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

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

320

Часть

111.

Web-протоколы

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

ди,

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

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

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

отключить алгоритм Нагла.

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

функции readQ, чтобы прочесть запрос клиента. Потом сервер анализирует

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

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

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

мени, размера файла и даты последней его модификации и т.д.).

Передача ответного сообщения. После создания заголовка HTTP-ответа,

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

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

файла и writeQ для передачи данных соединению. Если выходной буфер по-

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

writeQ, пока предшествующие данные не будут успешно переданы клиенту.

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

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

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

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

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

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

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

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

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

с переключением контекста. Выполнение нескольких действий с помощью одного

системного вызова также оптимизирует работу TCP [NBK99J:

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

полнить запрос GET, Web-сервер должен прочитать файл и записать его в вы-

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

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

к ненужным накладным расходам. Данные когп1руются из файловой системы

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

ходной буфер операционной системы. Вместо этого данные могут копировать-

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

ного вызова. В большинстве операционных систем имеется системный вызов

sendfileQ или transmitfileQ для выполнения данной операции.

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

ловок и тело ответа с помощью системного вызова writevQ. Сервер обычно

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

ный вызов требует указать буфер (для заголовка ответа) и файл (для тела от-

вета),

а потом передаст содержимое буфера вместе с содержимым файла. Это

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

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

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

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

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

шет в буфер тело ответа. Объединение этих двух шагов позволяет уменьшить

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

вий с таймером задержки подтверждений, о чем рассказано в разделе 8.2.3.

Глава 8. Взаимодействие HTTP и TCP 321

• Отправка ответа и закрытие соединения одним вызовом. Сервер может за-

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

писи HTTP-ответа. Это позволяет серверу записать HTTP-заголовок, пере-

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

онная система знает, что сервер хочет закрыть ТСР-соединение. Закрытие со-

единения осуществляется пакетом, в котором установлен бит FIN. Операци-

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

как показано на рис. 8.10. Это возможно, так как операционная система уже

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

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

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

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

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

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

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

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

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

Сервер

Клиент-

Рис 8.10. Сервер устанавливает бит FIN у последнего пакета данных

Расширение операционной системы новыми системными вызовами может улуч-

шить производительность Web-серверов. Теоретически, Web-сервер мог бы быть

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

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

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

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

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

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

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

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

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

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

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

8.4.2. Управление соединениями

Эффективность Web-сервера зависит от числа одновременно открытых соеди-

нений. Web-серверы контролируют число открытых соединений двумя основными

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

нения.

322

Часть

III. Web-протоколы

УПРАВЛЕНИЕ ОДНОВРЕМЕННО ОТКРЫТЫМИ СОЕДИНЕНИЯМИ

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

ния информации о своем состоянии, входных и выходных буферах. Например, ка-

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

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

сервере, поддерживающем одновременно большое число соединений. Неактивные

соединения в состоянии TIME_WAIT также потребляют ресурсы сервера, как это

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

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

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

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

таданных на сервере, как об этом рассказано в главе 4 (раздел 4.3). Кэширование

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

большим числом соединений одновременно. Кэширование избавляет сервер от на-

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

данных.

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

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

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

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

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

ния списка соединений; в качестве усовершенствования соединения в состоянии

TIME_WAIT могли быть перенесены в конец списка в связи с малой вероятно-

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

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

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

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

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

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

пример, с помощью системного вызова select()). Накладные расходы на вызов сис-

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

ний, даже если эти соединения неактивны [BM98J.

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

НТТР-трафика. Создание и передача ответов потребляет дисковые, процессорные,

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

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

держке в создании и передаче ответных сообщений. Как крайний пример, предста-

вим себе Web-сервер, который запускает CGI-сцепарий, который требует двух се-

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

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

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

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

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

ходует ресурсы сервера впустую. В худшем случае такой сервер будет перегружен,

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

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

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

дует ограничивать их число без надобности. Ограничение числа одновременно от-

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

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

Глава 8. Взаимодействие HTTP и TCP 323

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

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

полнена, сервер отбрасывает пакеты SYN, отвергая тем самым запросы на новые

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

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

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

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

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

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

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

подключения к Internet.

СТРАТЕГИИ ЗАКРЫТИЯ ДОЛГОВРЕМЕННЫХ СОЕДИНЕНИЙ

В рамках управления числом соединений сервер НТТР/1.1 должен решать, ко-

гда закрывать долговременное соединение. Сохранение долговременного соедине-

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

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

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

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

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

гия

—

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

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

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

ние запроса в ближайшем будущем.

Но даже относительно небольшой таймаут может держать соединение открытым

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

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

дику [РМ95]. Сервер может использовать небольшой таймаут после первого запроса

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

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

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

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

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

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

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

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

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

данию 1ЮВ0Г0 соединения, когда исчерпывается лимит запросов.

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

зовать, так как они рассматривают каждое ТСР-соединение в отдельности. На серве-

ре,

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

преимущество, так как она не требует координации процессов. Сервер может приме-

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

ми.

Сервер в действительности имеет кэш соединений, и решение, какое соединение

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

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

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

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

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

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

324

Часть

III.

Web-протоколы

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

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

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

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

8.5. Резюме

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

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

ния. Таймеры, управляющие ключевыми операциями в TCP, оказывают влияние

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

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

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

ного обеспечения Web могут смягчить или наоборот усилить эти эффекты. В отли-

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

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

загружать различные Web-ресурсы. Параллельные соединения увеличивают за-

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

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

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

Эффективность Web-серверов и прокси-серверов зависит от применения эффек-

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

Часть

Измерение

описание

Web-трафика

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

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

тов,

в администрировании Web- и прокси-серверов и в эксплуатации IP-сетей.

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

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

сти Web. Измерение Web-трафика состоит из трех основных шагов: наблюдение за

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

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

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

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

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

вере;

мониторинг пакетов и активные измерения. Каждая технология имеет пре-

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

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

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

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

стандартов де-факто ведения журналов Web-серверов и прокси-серверов: Common

Log Format (CLF — Общий формат протоколирования) и Extended Common Log

Format (ECLF

—

Расширегшый общий формат протоколирования). Так как отсут-

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

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

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

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

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

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

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

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

отображения результатов измерений.

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

которые затрудняют оценку ряда основных характеристик сети. Часть информации

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

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

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

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

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

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

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

преимущества кэширования Web-ресурсов на прокси-серверах и частоту измене-

ний Web-pecypcoB. Мы не будем подробно обсуждать результаты анализа наблюде-

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

и анализа измерений трафика.

328

Часть

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

9.1.

Мотивация измерений Web-трафика

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

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

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

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

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

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

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

9.1.1.

Мотивация для разработчиков Web-сайтов

Разработчики Web-сайтов могут получить ценную информацию при изучении

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

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

бапнеров, размещенных на Web-сайте. Кроме того, анализ статистики посещений

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

формацию па сайте. Предположим, что большое число пользователей посещают

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

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

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

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

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

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

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

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

можно не находят нужную им информацию. Разработчик Web-сайта может решить

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

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

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

заходят па сайт. Например, если 25% посетителей приходят на сайт электронной

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

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

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

восемь секунд при соединении со скоростью 56,6 Кбит/с. Эта информация может

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

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

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

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

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

Большое число запросов, приходящих, скажем, из Италии, могут подсказать разра-

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

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

9.1.2. Мотивация для компаний, занимающихся хостингом

Измерения также играют важную роль при обслуживании Web-серверов. Рас-

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

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

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

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

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

необходима для подсчета арендных платежей и для распределения системных ре-

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

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

большую часть запросов днем (например, деловой сайт), может быть размещен на

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

(например, развлекательный сайт). Кроме того, измерения могут использоваться

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

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

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

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

Измерения могут помочь в настройке параметров серверов. Web-серверы имеют

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

как это было рассмотрено в главе 4 (раздел 4.6). Например, целесообразность раз-

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

ный клиент посылает несколько запросов за короткий промежуток времени. Если

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

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

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

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

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

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

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

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

ченным непосредственно к Web-серверу) без обращения к исходному серверу.

9.1.3.

Мотивация для сетевых операторов

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

пользу от измерений Web-трафика. Например, компания, имеющая локальную

сеть,

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

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

сов,

которые удовлетворяются из кэша. Подобным образом Internet-нровайдеры

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

кэширующий прокси-сервер будет поставлен в том или ином месте сети. Провай-

деры могут использовать результаты измере1Н1Й для срав1П1тельной оценки про-

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

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

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

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

рить,

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

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

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

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

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

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

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

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

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

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

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