Решения нового поколения в области кэширования предлагают экономичный беспроблемный способ высвобождения пропускной способности и ускорения работы приложений на базе Web.
С ростом значимости для компаний приложений Internet и Intranet администраторам сетей приходится испытывать все возрастающее давление с требованиями ускорить работу этих приложений. Многие решают проблему за счет увеличения пропускной способности соединений с Internet или по глобальной сети с удаленными узлами, но подобные методы не обязательно дают желаемые результаты. Проблема в том, что задержка между запросом и доставкой объектов Web связана с целым рядом факторов, в том числе с загруженностью сервера Web, с задержками при передаче данных на транзитных маршрутизаторах Internet и с ограниченной скоростью передачи данных по волоконно-оптической магистрали Internet.
Свет распространяется по оптическим кабелям со скоростью приблизительно 150 000 километров в секунду. Даже без учета задержек на сервере Web и маршрутизаторах и коммутаторах вдоль магистрали Internet сигналу потребуется около 30 миллисекунд для путешествия от западного до восточного побережья США.
Рассмотрим, для примера, простую страницу Web с 10 изображениями. Эта страница содержит 11 объектов - сам документ в формате HTML плюс изображения. Помимо первоначального обращения и получения ответа от сервера DNS доставка каждого объекта с сервера на клиент потребует двух пересылок информации туда и обратно - для открытия сеанса TCP и для осуществления транзакции HTTP. Таким образом, получение нашей простой страницы потребует 22 пересылок информации туда и обратно без учета поиска по DNS. Без учета задержек, вносимых сервером Web и сетевыми устройствами вдоль маршрута передачи данных, вся транзакция займет около одной секунды. С учетом же задержки на сервере Web и на устройствах вдоль маршрута передачи данных загрузка этой простой страницы запросто может занять пять секунд и даже более. Короче говоря, никакое увеличение пропускной способности не в силах сократить свойственную транзакциям Internet задержку при большой удаленности конечных точек.
Ввиду того, что обойти эти физические ограничения не представляется возможным, напрашивающееся решение заключается в хранении (или кэшировании) копий объектов как можно ближе к браузеру. Идея, лежащая в основе кэширования, которое используется в компьютерном мире уже многие годы, проста: активно используемые данные следует размещать как можно ближе к процессору во избежание возникновения задержек в относительно медленных путях передачи данных или устройствах хранения информации. В случае Internet процессор - это клиентский браузер, а медленный путь передачи данных и устройство хранения информации - это Internet.
ГОРА ИДЕТ К МАГОМЕТУ
Кэширование объектов Web на уровне браузера появилось уже относительно давно. Проблема с таким подходом в том, что два или более пользователей в одной и той же локальной сети не могут воспользоваться кэшируемыми объектами на ПК других пользователей. Вместо этого каждому пользователю приходится запрашивать идентичные объекты с сервера Web. При размещении кэш-сервера в глобальной сети или IP-подсети только первый запрос на объект Web будет проходить весь маршрут до сервера Web. Последующие запросы будут перехватываться кэш-сервером и выполняться им, а не сервером Web. Такой подход сокращает требования к пропускной способности и повышает общую производительность (см. Рисунок 1).
 Без кэширования HTTP каждому пользователю приходится извлекать объекты непосредственно с сервера Web (см. верхнюю половину рисунка). Размещение кэша вблизи шлюза Internet дает внутренним пользователям возможность извлекать часто запрашиваемые объекты из локальной сети. Это позволяет сократить нагрузку на соединение Internet и увеличить скорость работы приложений (см. нижнюю половину рисунка). |
Исторически proxy-серверы рассматривались как синоним кэш-серверов, что не вполне верно. Основная функция proxy-сервера состоит в том, что он выступает в роли посредника для пользователей Web, расположенных за брандмауэром и Internet. Proxy-серверы не обязательно имеют компонент для кэширования. Однако ввиду того, что они обеспечивали единую точку доступа для множества пользователей, proxy-серверы часто использовались для кэширования объектов.
Первыми кэш-серверами были proxy-серверы общественных и исследовательских организаций. Демон httpd Европейского совета ядерных исследований (CERN), а также финансируемый Агентством по передовым исследовательским проектам (ARPA) и Национальным научным фондом (NFS) компонент Harvest Cache в составе Harvest Project - типичные примеры таких ранних систем. (В рамках Harvest Project в 1994-96 гг. было разработано полномасштабное решение для сбора, индексирования, кэширования, тиражирования и доступа к информации в Internet.) Названные достижения исследовательских организаций вскоре появились в виде коммерческих предложений, хотя технологически они базировались на этих ранних исследованиях. Например, Proxy Server компании Netscape был разработан одним из главных архитекторов proxy-сервера CERN, в то время как NetCache от Network Appliance - это детище Питера Данцига, ранее работавшего над проектом Harvest Cache. В настоящее время на рынке имеется свыше двух десятков коммерческих и некоммерческих продуктов для организации кэширования как в виде серверного программного обеспечения, так и в виде готовых отдельно стоящих устройств. (Более подробная информация об аппаратных и программных продуктах для кэширования дается во врезке "Твердый кэш или мягкие доллары?".)
ПОТЕНЦИАЛЬНЫЕ ДОСТОИНСТВА И НЕДОСТАТКИ
Технология кэширования реализуется обычно по двум основным причинам - в целях более эффективного использования пропускной способности и для ускорения работы приложений на базе браузеров. Если доступ в Internet тяжелым бременем ложится на сеть вашей организации, то серверы кэширования предоставляют экономичный способ высвобождения пропускной способности без приобретения более дорогого соединения Internet. Серверы кэширования, кроме того, помогают ускорить работу браузеров, приобретающих все большее значение с переводом важных для бизнеса приложений в сети Intranet на базе IP.
Несмотря на очевидные преимущества, технология кэширования не лишена недостатков. Одна из потенциальных проблем связана с тенденцией к динамической доставке информационного наполнения Web. Провайдеры оперативной информации вполне законно обеспокоены тем, что вследствие кэширования посетители будут получать с их серверов устаревшую информацию. Однако современные кэш-серверы предусматривают обычно те или иные меры для предотвращения кэширования динамически генерируемых страниц. Например, кэш-сервер может игнорировать документы, URL которых содержит символы или подкаталоги, указывающие на то, что страница создается динамически, например, /cgi-bin/ и ?. Если провайдеры оперативной информации не хотят, чтобы их динамически генерируемые страницы кэшировались, то они могут блокировать кэширование, вставив заголовок Expires=0 во все страницы. Это позволяет предотвратить кэширование, объявив документ немедленно устаревшим.
Даже если все динамически генерируемые документы HTML не будут кэшироваться, кэширование тем не менее найдет себе место. Исследования показывают, что большинство объектов, доставляемых по Internet, - это статические объекты типа навигационных пиктограмм или логотипов компаний. В своей статье "Архитектура и реализация NetCache" Питер Данциг из Network Appliance приводит оценки, что 70% всего трафика Web представляют собой изображения и загружаемые файлы. Иными словами, от 80 до 90% всех передаваемых байтов могут быть кэшированы.
Другая проблема при широкомасштабной реализации кэширования состоит в том, что провайдеры информационного наполнения оказываются не в состоянии точно подсчитать число обращений, а это означает, что они не могут надежно измерить трафик к своим серверам. В случае коммерческих серверов, существование которых зависит от доходов от рекламы, т. е., опосредованно, от протоколирования посещений, эта проблема становится существенной. Один из способов обойти ее - задать заголовок Expires равным нулю. К сожалению, достоинства точного подсчета обращений могут не оправдаться из-за снижения производительности узла: конечные пользователи потеряют преимущества локального кэширования, а сервер Web станет испытывать возросшую нагрузку, потому что ему придется выполнять все запросы на получение объектов.
Некоторые специалисты в области рекламы используют новаторские решения для разрешения кэширования без ущерба для точного подсчета обращений. Один из подходов состоит во включении на страницы небольших некэшируемых объектов и перенаправлении запросов на эти объекты в сценарий для измерения обращений. Некоторые продукты, например DynaCache от Infolibria, имеют функцию для сообщения серверу Web об обращении к объекту после того, как он извлечен из кэша, исключая таким образом задержку при доставке объекта Web в браузер.
МЕРИЛО УСПЕХА
Успех применения кэширования можно измерить тремя способами - по соотношению обращений, по отношению байт и по среднему времени отклика. Первый показатель характеризует отношение числа выполненных с помощью кэша обращений к общему числу запрошенных объектов. Аналогично второй показатель характеризует отношение объема доставленных из кэша объектов к объему всех доставленных объектов. Третий показатель характеризует время доставки объектов непосредственно из Internet без кэширования в сравнении с временем доставки тех же самых объектов из кэша. Если отношение обращений и отношение байт можно без труда вычислить на основании информации журнальных файлов кэш-серверов, то время отклика можно оценить только в реальной рабочей среде.
Двумя основными влияющими на производительность факторами являются количество пользователей и размер кэша. С ростом числа пользователей вероятность того, что один и тот же объект будет запрошен из кэша несколькими пользователями, увеличивается. Аналогично, чем больше кэш, тем больше объектов он может вместить и тем дольше объекты остаются в кэше, в результате чего вероятность их повторного запроса из кэша возрастает.
Исследование, проведенное Национальной лабораторией по прикладным сетевым исследованиям (National Laboratory for Applied Network Research, NLANR) консорциума финансируемых NFS суперкомпьютерных серверов, показывает, что соотношения обращений в 30% достичь не представляет труда, тогда как цифры в 50% и выше возможны только при значительном числе пользователей или большом объеме кэша. NLANR также установила, что отношение байт обычно на 10% ниже, чем отношение обращений, иначе говоря, мелкие объекты кэшируются чаще, чем крупные. Хотя разработчики коммерческих продуктов для кэширования делают несколько более оптимистичные заявления, реальные показатели работы таких продуктов укладываются, как правило, в указанные рамки.
ЗА СЦЕНОЙ
Базовый принцип кэширования объектов одинаков для всех кэш-серверов. При запросе браузером объекта, уже имеющегося на кэш-сервере, сервер проверяет, что объект не устарел, и возвращает хранимую копию объекта браузеру. При отсутствии объекта в кэше или при его устаревании запрос направляется целевому серверу Web, чтобы тот передал запрашиваемый объект. При поступлении объекта из Internet кэш-сервер сохраняет копию для себя и возвращает объект браузеру. При запросе браузером устаревшего кэшированного объекта сервер обычно посылает запрос GET с условием If-Modified-Since серверу Web. Если объект не изменялся после указанной в заголовке запроса GET даты, то сервер Web отвечает code 304 (Not Modified). В результате объект предоставляется локально, а не с сервера Web, так как имеющаяся у него копия ничем не отличается от кэшированной. Ответ с кодом 304 позволяет экономить пропускную способность (объект доставляется из локального кэша), но он вносит типичные для передачи по Internet задержки, так как доставка ответа с кодом предполагает организацию двух сеансов с сервером Web с пересылкой информации туда и обратно.
Каждый кэш-сервер определяет время устаревания объекта по-своему. Простейший подход предполагает использование эвристического метода с учетом времени последней модификации (Last Modified Factor, LMF). Данный фактор определяется исходя из отношения времени, прошедшего с момента последней проверки объекта (при извлечении его с сервера Web в первый раз или при получении кода 304 в ответ на запрос обновленной версии), к возрасту этого объекта на момент его последней проверки. Объект считается устаревшим, когда LMF превосходит предопределенный уровень. Таким образом, если кэш-сервер извлекает объект, остававшийся неизменным на сервере Web на протяжении последних 100 дней, то в случае LMF, равного 10%, кэшируемый объект будет считаться устаревшим по истечении 10 дней.
Такой подход используется, как правило, некоммерческими кэш-серверами. Коммерческие же продукты обычно применяют более сложные алгоритмы, дабы браузеры не получали устаревшие объекты. Например, CacheFlow от CacheFlow использует технологию, с помощью которой он пытается определить, когда объекты будут запрошены браузером в следующий раз, и предварительно обновляет их. DynaCache от Infolibria имеет распределенную архитектуру, в которой независимые серверы DynaCache могут обнаруживать другие серверы в сети и делиться с ними информацией о кэшируемых объектах. Некоторые кэш-серверы, например Proxy Server от Netscape, позволяют администраторам указать, какие конкретные URL или серверы следует обновлять через фиксированные интервалы времени.
ПОСРЕДНИК В СРАВНЕНИИ С ПРОЗРАЧНЫМ КЭШИРОВАНИЕМ
Кэширование можно реализовать двумя способами: в виде посредника или в прозрачном режиме. Кэш-посредник действует как агент, выполняя запросы к Internet от имени пользователей, поэтому обычно он более требователен, чем прозрачный кэш. В этом режиме все клиенты Web должны быть сконфигурированы таким образом, чтобы они направляли все исходящие запросы на IP-адрес посредника. Посредник может иметь множество дополнительных функций администрирования трафика, например функции фильтрации и блокирования трафика, идентификации пользователей и определения шаблонов типичного поведения внутренних пользователей при просмотре Web.
Преимуществом использования кэша-посредника является защищенность и контролируемость: администратор может следить за тем, кто использует Web и что он просматривает. Основной недостаток состоит в том, что каждому браузеру необходимо указать этого посредника. Хотя и Netscape, и Microsoft поддерживают автоматический режим, благодаря которому сетевые администраторы могут сконфигурировать браузеры на автоматическое обращение к посредникам, эта функция может оказаться непригодной в случае крупных предприятий и провайдеров Internet ввиду огромного числа пользователей.
В отличие от посредника, прозрачный кэш перехватывает трафик незаметным образом на его пути от браузера к серверу Web. В типичной конфигурации прозрачный кэш находится вне сети где-нибудь поблизости от шлюза в Internet, использующего маршрутизатор на базе правил или коммутатор четвертого уровня для отвода трафика HTTP на кэш-сервер. Такой подход значительно снижает накладные расходы на администрирование за счет исключения необходимости конфигурации каждого браузера в отдельности. Ввиду того, что весь трафик Internet идет через прозрачный кэш-сервер, его отказ может привести к полной недоступности Internet для всех пользователей. Однако последние продукты включают функции взаимного резервирования, что ослабляет эту потенциальную проблему.
Помимо увеличения мощности процессоров и наращивания памяти или расширения дисков проблему масштабируемости должны помочь решить и два разрабатываемых протокола: протокол кэширования Internet (Internet Caching Protocol, ICP) и протокол маршрутизации между кэш-серверами (Cache Array Routing Protocol, CARP). ICP явился результатом исследований в рамках проекта Harvest Cache. Он позволяет вышестоящим и нижестоящим кэш-серверам обмениваться информацией об обращениях к кэшу и брать объекты у других кэш-серверов без обращения к серверу Web. CARP был подготовлен Microsoft в качестве предложения по стандарту Internet. Он описывает метод, с помощью которого свободно связанные серверы кэширования могут распределять между собой пространство URL для выравнивания нагрузки и подмены друг друга. Многие производители реализовали ICP в своих продуктах в том или ином виде, в то время как другие включили или объявили о намерениях включить поддержку CARP.
НЕКОТОРЫЕ РЕКОМЕНДАЦИИ
Если вы планируете добавить кэширование в вашу сеть, то вам придется решить три основных вопроса: какой метод кэширования использовать - с помощью посредника или прозрачный, где разместить кэш-серверы и какие процессоры и диски установить.
При использовании сервера кэширования в качестве посредника вам потребуется заняться конфигурацией настольных систем конечных пользователей, т. е. указать IP-адрес посредника каждому браузеру. Браузеры Microsoft и Netscape (версии 2.0 и выше) имеют функцию автоматической конфигурации, с помощью которой их можно удаленным образом сконфигурировать на использование proxy-сервера. Однако для активизации этой функции каждому браузеру необходимо указать страницу со сценариями автоматизации конфигурации посредника.
Что касается размещения серверов кэширования, их следует располагать во всех тех точках сети, где доступная пропускная способность ограничена. Наиболее очевидное место - возле шлюза в Internet. В крупных компаниях с одним или более удаленными офисами, связанными между собой по глобальной сети, размещение кэша в каждом удаленном офисе должно повысить скорость работы с Internet и сократить трафик через глобальную сеть. Сети с крупными подсетями на уровне рабочих групп или отделов могут выиграть от размещения кэш-серверов в стратегических местах каждой подсети. В идеале, такая конфигурация сокращает Internet-трафик по магистрали. Рисунок 2 демонстрирует пример размещения кэш-серверов в сети компании.
 Распределение серверов кэширования по предприятию - например по одному серверу в каждом удаленном офисе или в крупной подсети - позволяет сократить трафик Internet через глобальную сеть или по сетевой магистрали. |
Наконец, при введении кэширования вам придется учитывать два параметра: максимальное число обслуживаемых в секунду объектов и емкость системы хранения. Оба они рассчитываются исходя из доступной пропускной способности соединения Internet (или канала глобальной сети), размера рабочей группы, совместно использующей кэш, и предполагаемой нагрузки на кэш по обслуживанию браузеров. Объем кэша не должен быть слишком малым, так как в этом случае вы не достигнете ожидаемых результатов. Хуже того, он может снизить общую производительность. При выборе решения для кэширования мы советуем вам совместно с производителем определить, каков должен быть объем, скорость и масштабируемость кэша для вашей конкретной сети и приложений.
Фил Кеппелер - администратор сервера Web журнала Network Magazine. С ним можно связаться по адресу: pkeppler@mfi.com.
Твердый кэш или мягкие доллары?
Первоначально кэш-серверы разрабатывались в виде программных пакетов прикладного уровня для работы на стандартном серверном программном и аппаратном обеспечении. Однако недавно около десятка производителей выпустили или объявили о выпуске выделенных устройств кэширования, заявив, что они проще в установке и управлении, более надежны, чем программные продукты и имеют оптимизированные для задач кэширования операционные системы. Исследовательские фирмы, в том числе Forrester Research и The Gartner Group, подтверждают это заявление в своих прогнозах, согласно которым аппаратные кэш-серверы будут вскоре взяты на вооружение провайдерами Internet, а вслед за ними и крупными промышленными компаниями.
В настоящее время коммерческие аппаратные решения предлагают Cache Flow (Cache Flow), Network Appliance (NetCache) и Cisco Systems (Cache Engine). Еще один производитель, Infolibria, объявил о намерении выпустить DynaCache, который компания планировала представить в конце 1998 года. Выделенные аппаратные кэш-серверы стоят, однако, достаточно дорого - от 9000 до 65 000 долларов.
Тем не менее ставить крест на программных решениях пока рано. Они имеют несколько преимуществ, в том числе поддержку стандартных отраслевых серверов и операционных систем, простоту масштабируемости (за счет увеличения мощности процессора, емкости оперативной памяти или дисков) и экономичность с точки зрения затрат. Программные кэши менее дороги, нежели их аппаратные аналоги, к тому же, как правило, они могут работать на уже имеющемся аппаратном обеспечении. Цены на них варьируются в диапазоне от нуля до 30 000 долларов - плюс стоимость оборудования (в случае, если имеющуюся систему придется модернизировать).
Другое преимущество программных решений состоит в том, что они обычно предлагают более богатый арсенал посреднических функций, чем аппаратные решения (последние создаются, как правило, с нуля исключительно для поддержки функций кэширования).
Наиболее известным бесплатным кэш-сервером является Squid, ведущий свое начало от Harvest Cache Project и принадлежащий в настоящее время Национальной лаборатории по прикладным сетевым исследованиям (National Laboratory for Applied Network Research, NLANR) консорциума финансируемых NFS суперкомпьютерных серверов. Некоторые коммерческие организации также выпустили программные продукты, позиционируя их как высокопроизводительные масштабируемые кэш-серверы для провайдеров Internet и крупных компаний. Среди них Proxy Server от Netscape, Proxy от Microsoft, BorderManager FastCache от Novell, Web Traffic Express от IBM и Traffic Server от Inktomi.
Ресурсы Internet
Ссылки на исследования, статистику и библиографию в области кэширования можно найти на сервере Internet Resource Caching Национальной лаборатории прикладных исследований по адресу: http://ircache.nlanr.net. Этот сервер содержит также список как коммерческих, так и некоммерческих решений в области кэширования на странице http://ircache.nlanr.net/Cache/FAQ/ircache-faq-9.html.
Брайн Д. Дэвидсон, кандидат наук из Рутгерского университета, создал весьма информативный сервер по ресурсам кэширования www.cs.rutgers.edu/~davison/web-caching/. Он содержит новости в области кэширования, библиографию, список продуктов и т. п.
Если вы хотите более подробно узнать о Harvest Project, то можете обратиться на узел http://harvest.transarc.com со ссылками на результаты исследований, записи собраний, ответы на часто задаваемые вопросы и т. п.
CacheNow - так называется текущая кампания по реализации широкомасштабного кэширования в целях преодоления ограничений инфраструктуры и пропускной способности Internet. Информация о ней приводится на http://vancouver-webpages.com/CacheNow/.