Web-кэширование

Web-кэш, часто называемый прокси-сервером, представляет собой сеть, которая выполняет HTTP-запросы от имени сервера-источника. Web-кэш имеет собственное дисковое устройство хранения информации, содержащее ранее запрашивавшиеся копии объектов. Как показано на рис. 2.25, браузер пользователя можно настроить таким образом, чтобы все создаваемые HTTP-запросы сначала направлялись в web-кэш (данная процедура в браузерах Microsoft и Netscape выполняется очень просто).

После того как браузер настроен указанным образом, любой запрашиваемый объект сначала ищется в web-кэше. В качестве примера предположим, что браузер запрашивает объект _http://www.someschool.edu/campus.gif. Алгоритм использования кэш-сервера выглядит следующим образом.

1. Браузер устанавливает TCP-соединение с кэш-сервером и посылает ему запрос объекта.
2. Кэш-сервер проверяет наличие локальной копии требуемого объекта и в случае ее обнаружения формирует ответное сообщение и отсылает объект браузеру.
3. Если локальная копия отсутствует, кэш-сервер устанавливает ТСР-соедине-ние с сервером-источником http://www.someschool.edu и посылает ему запрос на получение объекта. Сервер-источник обрабатывает запрос и отсылает требуемый объект кэш-серверу.
4. После получения объекта кэш-сервер сохраняет его копию на локальном накопителе информации и передает объект браузеру через открытое ранее ТСР-со-единение.

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

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

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

Кэширование получило широкое распространение в Интернете по трем причинам. Первая заключается в том, что кэш-серверы способны значительно сократить время выполнения запроса пользователя, в особенности если скорость передачи между пользователем и кэш-сервером превышает скорость передачи между пользователем и сервером-источником. Зачастую для соединения пользователя с кэш-сервером используются высокоскоростные линии связи, поэтому при наличии на кэш-сервере требуемого объекта его доставка пользователю происходит за очень короткое время. Вторая причина популярности механизма кэширования состоит в том, что он способен значительно снизить трафик между локальными сетями и Интернетом. Это позволяет, в свою очередь, сократить расходы на дорогостоящие линии связи, соединяющие локальные сети с Интернетом. Кроме того, значительное сокращение трафика при кэшировании происходит и в Интернете в целом, приводя к лучшему качеству обслуживания приложений всех пользователей глобальной Сети. Наконец, третья причина успеха кэширования заключается в том, что оно позволяет с большой скоростью распространять ресурсы среди пользователей. Даже в случае, если поставщик использует недорогое низкоскоростное сетевое оборудование, наиболее популярные ресурсы в скором времени окажутся в web-кэшах, и, следовательно, пользователи смогут загружать их с приемлемым качеством обслуживания.

Чтобы лучше оценить достоинства кэширования, обратимся к примеру. На рис. 2.26 изображены две компьютерные сети: локальная высокоскоростная университетская сеть и Интернет. Маршрутизаторы локальной сети и Интернета соединены между собой линией связи, обеспечивающей скорость передачи 1,5 Мбит/с. Серверы-источники имеют прямое соединение с Интернетом, однако находятся в разных частях земного шара. Предположим, что средний размер объектов равен 100 ООО бит, а средняя частота запросов браузеров университетских компьютеров к web-серверам-источникам составляет 15 раз в секунду. Будем считать, что размер HTTP-запросов пренебрежимо мал и не создает дополнительного трафика на линии связи между локальной сетью и Интернетом. Предположим также, что среднее время, проходящее с момента передачи запроса (в виде одной IP-дейтаграммы) первым маршрутизатором Интернета, показанным на рисунке, до получения им ответа (как правило, в виде нескольких дейтаграмм), составляет 2 с. Эту величину мы неформально назовем «задержкой Интернета».

Полное время ответа, то есть время, проходящее с момента формирования запроса браузером до завершения приема требуемого объекта, складывается из трех составляющих: задержки локальной сети, времени доступа (задержки между двумя указанными выше маршрутизаторами) и задержки Интернета. Проведем грубую оценку времени ответа. Интенсивность трафика локальной сети (см. раздел «Задержки и потери данных в сетях с коммутацией пакетов» в главе 1) составляет:

(15 запросов в секунду) х (100 Кбит/запрос) / (10 Мбит/с) = 0,15,

а интенсивность трафика на линии доступа равна:

(15 запросов в секунду) х (100 Кбит/запрос) / (1,5 Мбит/с) = 1.

Интенсивность трафика в локальной сети, составляющая 0,15, способна привести к задержкам, не превышающим десятков миллисекунд. С другой стороны, единичная интенсивность на линии доступа может привести к неограниченному росту задержек. Таким образом, среднее время ответа в нашем примере может легко достигать нескольких минут и более, что, очевидно, неприемлемо с точки зрения качества обслуживания пользователей.

Одним из возможных решений проблемы является увеличение пропускной способности линии доступа, например до 10 Мбит/с. Это приведет к снижению интенсивности трафика на линии до 0,15, тем самым уменьшив задержку доступа до пренебрежимо малых значений. В этом случае время ответа будет приблизительно равно задержке Интернета и составит 2 с. К сожалению, подобное решение требует немалых финансовых затрат.

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

На практике вероятность того, что кэш способен удовлетворить запрос пользователя, лежит в интервале от 0,2 до 0,7; мы положим эту вероятность равной 0,4.

Поскольку пользователи соединены с кэш-сервером высокоскоростными линиями связи локальной сети, время ответа для запросов, выполняемых кэш-сервером, очень мало; мы будем считать его равным 10 миллисекундам. Указанное время ответа соответствует значению в 40 % от общего числа запросов; оставшиеся 60 % запросов будут вынуждены обслуживаться серверами-источниками. Тем не менее это позволяет снизить коэффициент интенсивности трафика на линии доступа с 1 до 0,6 и решает проблему перегрузки. Как правило, коэффициент интенсивности ниже 0,8 для линии связи с пропускной способностью 1,5 Мбит/с приводит к незначительным задержкам, не превышающим десятков миллисекунд. Учитывая двухсекундное значение задержки Интернета, мы можем пренебречь временем доступа, и среднее время ответа составит:

0,4 х (0,01 с) + 0,6 х (2,01 с) = 1,21 с.

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