Четыре уровня кэширования в сети: клиентский, сетевой, серверный и уровень приложения. Цена что надо
Фотографий, мы узнали, что кэширование и оперативная память играют ключевую роль в масштабируемости и производительности сайта.
Сайт может хранить данные для ускорения обработки последующих запросов на четырёх уровнях:
- клиентский;
- сетевой;
- серверный;
- уровень приложения.
Разные страницы веб-сайта зачастую обмениваются одними и теми же ресурсами. Пользователь должен повторно использовать ресурсы во время навигации. Изображения, скрипты и стили можно хранить в кэше месяцами, а сама страница документа может кэшироваться в течение нескольких минут в клиентском браузере.
Кэш на клиентском уровне
Заголовки HTTP отвечают за определение возможности кэширования ответа и за определение срока хранения данных. Следующий пример заголовка Cache-control указывает, что ответ может находиться в кэше в течение 7 дней. Браузер отправит повторный запрос на хранение данных, если срок хранения истечёт или пользователь целенаправленно обновит страницу.
Запрос и ответ, которые могут быть кэшированы в течение 604800 секунд.
Ответ также может включать заголовок Last-Modified или Etag . Эти заголовки нужны для проверки возможности повторного использования данных. Статус ответа 304 указывает, что содержимое не изменилось и повторная загрузка не требуется. Обратите внимание на парные заголовки Last-Modified и If-Modified-Since , а также на даты ниже:
Ответ с заголовком «Last-Modified» и последующим запросом с его использованием.
Заголовок Etag используется с If-None-Match аналогичным образом для обмена кодами ответа при определении изменений в контенте, если они имеются.
Сайт с продуманными HTTP-заголовками обретёт больший успех у пользователей. Кроме того, браузер сэкономит время и пропускную способность.
Кэш на сетевом уровне
Клиенты, запрашивающие одно и то же содержимое на прокси-сервере.
Множество клиентов, запрашивающих одно и то же содержимое одновременно.
Этот простой, но мощный механизм позволяет избежать беспорядка на стороне приложения при большом количестве запросов, когда заканчивается срок хранения контента.
Идея последнего, но не менее важного подхода заключается в том, что прокси-сервер может улучшить отказоустойчивость приложения. Существуют флаги директивы proxy_cache_use_stale для доставки контента с истёкшим сроком актуальности, когда приложение возвращает статус ошибки или когда связь между прокси-сервером и приложением не работает должным образом.
Ещё один важный аспект при использовании хранилищ кэша - это состояние гонки , которое происходит, когда разные экземпляры приложения обращаются к некэшированным данным одновременно. API кэширования запросов Rails содержит свойство race_condition_ttl для минимизации этого эффекта.
Упреждение состояния гонки для кэша с несколькими экземплярами приложений является сложной задачей. Оптимальным решением в этом случае выступает обновление данных кэша вне потока приложения и использование кэшированных данных в самом приложении. В архитектуре микросервиса можно защитить связь между приложением и сервисом с помощью nginx, как это описано выше.
Заключение
Надеемся, что эта статья поможет вам понять и выбрать лучшую стратегию для вашего приложения. HTTP-заголовки - это самое простое, что вы можете и должны настроить для оптимизации кэширования вашего приложения. Используйте также и другие стратегии, когда у вас появятся определённые проблемы в производительности, но помните, что преждевременная оптимизация - корень всех бед.
Игорь . Обновление:Ноябрь 21, 2017 .
Здравствуйте, уважаемые читатели блога сайт. Продолжаю цикл статей, которые касаются мероприятий по оптимизации, и сегодня настал черед для настройки использования в этих целях кэша браузера со стороны пользователей, что является очередным шагом выполнения по ускорению сайта.
Каждое действие, позволяющее приблизиться к этой цели, будет плюсом в продвижении веб-ресурса, а потому не поленитесь хотя бы взглянуть на материалы, где я давал описания , а также , что, несомненно, вам поможет в реализации общей задачи.
В продолжение я постараюсь предоставить внятные инструкции по настройке кэширования в браузере путем внедрения специального кода в замечательный файл.htaccess. Правда, это не всем и не всегда может помочь, но обо всем чуть ниже.
Думаю, каждый из вас представляет себе, что такое кэширование, хотя бы в общих чертах. На всякий случай объясню вкратце. Допустим, читатель открывает в окне браузера страницу вашего ресурса, все составляющие которой (содержание, стили, скрипты и т.п.) загружаются с сервера хостинга, что занимает определенное время.
Предположим, у нас есть возможность запустить механизм, который позволит сохранить копии элементов страниц прямо в web-обозревателе того пользователя, который их посещает. Тогда при каждом следующем обращении все эти элементы будут браться прямо из кеша браузера () посетителя, то есть из специальной папки, которая располагается на жестком диске его компьютера.
Выигрыш в скорости загрузки будет налицо. Вот такой алгоритм мы и будем изучать в настоящей статье. Кстати, в дополнение темы можете почитать о том, как наряду с ускорением сайта можно добиться , что весьма актуально в наши дни.
Пару-тройку лет назад я рассказывал об оптимизации одного из своих проектов на основании анализа Пейдж Спид, осуществленного посредством расширения (сейчас доступен только онлайн сервис), которое давало более детальную картину.
Что важно, в большинстве своем предложенный ниже код вполне достаточен для того, чтобы создать условия, при которых Pagespeed больше не будет предъявлять претензий, а, значит, он обеспечит ускорение загрузки страниц в необходимом объеме.
Итак, на основании выше сказанного нам нужно обеспечить вывод одного из заголовков Last-Modified и ETag, а также одного из пары Expires либо Cache-Control: max-age. Для наглядности и расширения диапазона рассмотрим различные варианты.
Вариации кодов для управления кешем с использованием заголовков Last-Modified, Expires и Cache-Control
Если на вашем хостинге уже настроен вывод того же Last-Modified, то пол-дела сделано (к слову, проверить наличие этого важного заголовка , включая в их список инструмент для проверки ответа сервера от Яндекса). Если же нет, то сделать это весьма несложно, прописав в том же незаменимом.htaccess пару строк:
RewriteRule .* - RewriteRule .* -
Правда, работать этот метод будет опять же при условии наличия "чистого Апача" (но ведь как раз этот случай мы и рассматриваем). Будем считать, что заголовок Last-Modified, в качестве значения которого, кстати, будет выводится дата последнего изменения, настроен.
Теперь настала очередь Cache-Control с параметром max-age, в качестве значения которого будет прописан срок хранения в кеше каждого конкретного статического объекта. На сцену выходит модуль mod headers , код которого и следует вставить в.htaccess:
Нужно отметить, что посредством контейнера ifModul на сервере осуществляется проверка наличия этого модуля. При его отсутствии директива выполняться не будет, поэтому ее использование в любом случае не должно привести к ошибкам.
Время сохранения кеша определяется с помощью параметра max-age , его значение выставляется в секундах. Благодаря комментариям (которые, к слову, вы можете спокойно удалить), стоящим после символа решетки «#», основа этой конструкции, думаю, понятна.
Однако, вместо mod headers вполне можно воспользоваться модулем mod expires , выводящим заголовок Expires (который, по мнению самого Гугла является предпочтительнее, поскольку имеет более широкую поддержку). При этом фрагмент кода для его включения будет таким:
Точкой отсчета срока годности кэша в случае использования заголовка Expires является дата первой загрузки. Причем, в отличие от Cache-Control, где временной период определяется только в секундах, здесь он может указываться в любом временном формате, включая year (год).
Для того, чтобы убедиться в этом, посмотрите на участок кода, касающийся изображений. Там я специально указал время в различных единицах исчисления: 1 month (месяц), 4 weeks (недели), 30 days (дни), 43829 minutes (минуты), 2592000 seconds (секунды).
Понятно, что в месяце и в году может быть различное количество дней, недель, минут и секунд, но это не принципиально, поскольку используются средние значения. Кстати, для JS, файлов CSS и изображений рекомендуется ставить временной период не менее недели, но не более года. При этом по факту в качестве значения заголовка Expires в ответе сервера будет указана дата предполагаемого срока завершения периода кеширования данной версии объекта.
В дополнение к упомянутым модулям полезно задействовать еще и mod setenvif . Дело в том, что веб-обозреватели семейства Microsoft Internet Explorer и некоторые версии Мазилы корректно не воспринимают в ответе сервера HTTP заголовок Vary, который также вносит свою важную лепту в управление кэшированием. Этот модуль как раз позволяет решить эту проблему, исключая Vary из состава ответа сервера:
В итоге мы получаем два конечных варианта настройки кеширования, которые вы можете проверить, вставив поочередно в.htaccess (оба одновременно использовать не рекомендую):
Еще раз напоминаю, что несмотря на наличие контейнера IfModule, который обеспечивает безопасность редактирования, не лишним будет каждый раз при изменении.htaccess делать резервную копию исходного варианта файла (можно просто скопировать его содержание и сохранить на компьютере), чтобы вас не застиг врасплох форс-мажор в той или иной вариации.
Код формирования заголовков Etag и Expires для настройки кэша
На случай, ежели предложенные выше директивы вдруг не сработают (даже если на вашем хостинге установлен "чистый" Апач), разберем другой случай, а именно, когда в качестве инструментов управления кэшированием выступает пара входящих в разряд обязательных заголовков Etag и Expires. Как вы помните, оба отвечает за своевременность выдачи файлов из кеша, инициируя проверку на актуальность текущей версии.
Но если в качестве значения Expires отображается дата последнего изменения, то в ETag используется тот или иной уникальный идентификатор ресурса (чаще в этой роли выступает версия файла). Для активации ETag требуется лишь ввести в тот же.htaccess одну строчку:
FileETag MTime Size
Ну а затем применить уже известный нам модуль mod expires. Можно добавить и mod setenvif, который, как я уже сказал выше, запрещает формирование заголовков Vary для определенной группы веб-браузеров, чтобы гарантировать образование кеша с их стороны:
FileETag MTime Size
Здесь использован комплекс с минимумом типов задействованных объектов, но зато наиболее востребованных (CSS, JavaScript и изображения), который также должен быть достаточным, чтобы обеспечить максимальную эффективность в ускорении сайта. При желании к комплекту «jpg|jpeg|gif|png|ico|css|js» можно добавить другие виды файлов.
Кроме того, в приведенном выше примере кода для всех файлов действует один и тот же период "жизни" кеша, равный одному году ("access plus 1 year"), который является рекомендуемым со стороны Гугла. Но можно для каждой группы объектов указать свой временной отрезок по примеру содержания модулей mod_expires и mod_headers из предыдущего раздела статьи.
Проверка наличия нужных заголовков в ответе сервера
После того, как вы вставите код в файл.htaccess, можно проверить, находятся ли необходимые заголовки в составе ответа сервера. Для этой цели можно воспользоваться каким-нибудь онлайн сервисом, например, Checkmy.ru , где в качестве клиента (User Agent), посылающего HTTP-запрос на сервер, выбираем любой браузер, а также вводим URL ресурса (для примера я взял путь до изображения, используемого в одной из статей блога):
После нажатия кнопки «Отправить запрос», через несколько секунд появится результат:
Как видите, в моем случае присутствуют все четыре заголовка. Я говорил, что обязательно должны выводится по одному из пар «Last-Modified — ETag» и «Expires — Cache-Control», остальные излишни. При этом полный комплект, насколько можно судить, не причинит вреда.
Кстати, ежели вы осуществите тестирование перед началом настройки кеширования, то сразу сможете определить, насколько продуктивными будут ваши действия.
Ведь если в ответе сервера будет присутствовать nginx, то настраивать нужно будет именно его (у меня это сделал провайдер), а файл конфигурации.htaccess будет здесь бесполезен. В таком случае, как я уже отмечал, придется задействовать помощь службы поддержки, если, конечно, ваш тариф хостинга и недостаточные знания не позволят самостоятельно решить вопрос.
Далее советую для закрепления материала обратиться к видео и посмотреть последовательно 6 уроков (один из которых посвящен настройке кеширования в браузерах), в которых подробно рассмотрены все наиболее важные аспекты ускорения сайта WP:
");">
Желаете получать своевременно свежие актуальные и полезные статьи? Тогда можете подписаться:
Еще статьи по данной теме:
60 отзывов
- Денис
Очень полезный способ для увеличения удобства нахождения на сайте. Ведь оптимизируя скорость загрузки Вы тем самым экономите время посетителя, и за это они будут благодарны заходя снова и снова на Ваш сайт. Что напрямую повлияет на доходы сайта положительным образом.
- Игорь
Абсолютно верно, Денис. В продвижении сайта все взаимосвязано.
- Marazzi
Ниче не поняла, браузер вобщето сам помоему запоминает сайты на которых была в кукис, Если куки подтиреть. СОГЛАСНО ВАШЕМУ МЕТОДУ то и ваша схема перестанет работать, вернее ятак понялда что это о чем идет разговор расчитано на постоянного посетителя который не подчищает историю7 ПОДПИСАЛАСЬ, ЖДУ ОТВЕТА1
- Сергей Дмитриевич
Весьма полезная информация. Мне пригодилась. Спасибо.
- Игорь
Marazzi, во первых куки и кэш разные вещи. Куки - особые файлы с набором данных, которые позволяют идентифицировать пользователя, если он посещает вебресурс. А cache (в переводе с англ.-склад, тайник) браузера - это своеобразное укромное место для хранения копий документов (например, вебстраниц сайта), которые при необходимости отображаются в браузере. Именно со стороне сервера происходит команда использовать кэш на стороне браузера пользователя, причем создается папка с кэшем именно на компьютере пользователя. Со своей стороны пользователь может регулировать частоту создания кэшированных копий страниц сайта, очищая папку с кэшем. Или вообще запретить кэширование, настройки современных браузеров это позволяют. Чем чаще вы чистите кэш, тем более новую версию страницы получаете.
- Николай
Супер,и здесь всё ОК!!!
- marazzi
Ну об этом я и говорила.
- Александр
- Николай
Спасибо за статью. Правда не совсем понятно как потом чистить этот кэш в случае, например, если на сайте появится новая рубрика или раздел, наоборот исчезнет. Я конечно утрирую сильно, но смысл тот же. Временами кэш нужно чистить, как это реализовано в этом коде?
- Ирина
ОК! Спасибо!
Этот код помог, теперь 80 из 100FileETag MTime Size ExpiresActive on ExpiresDefault «access plus 1 year»
- Игорь
Николай, не совсем понял Ваш вопрос. Это код для кэширования страниц в браузерах пользователей, они сами чистят кэш. Новые статьи и рубрики отображаются даже тогда, когда кэш полный. Надолго кэшируются только элементы, которые длительное время остаются неизменными.
- Андрей
Спасибо. А если мне нужно, чтобы кэшировались только определенные, например, логотип и флаги стран в footer, то как быть?
- Игорь
Андрей, а зачем Вам отделять изображения, одни кэшировать, другие нет? Обычно картинки не меняются с калейдоскопической быстротой.
- Андрей
Ну да, с картинками Вы правы. А определенную страницу не кэшировать(например, из админки). Такое возможно?
- Игорь
Конечно, возможно. Если Вы пользуетесь плагином кэширования, например Hyper Cache, то в его настройках есть уйма разнообразных опций, в том числе можно исключить страницы, которые не подлежат кэшированию.
- Ярослав
Очень полезная, статья, давно хотел настроить кеширование, вот только раньше везде находил первый представленный способ и он не делал ровным счетом ничего.
Зато благодаря вкторому способу все работает на ура!! PS 91 - Игорь
Хороший результат, Ярослав.
- stan
не работает ни один способ
- Игорь
Stan, вполне может быть, это во многом зависит от хостера.
- Илья
Слов нету сколько я искал статью как включить время кеширование браузера просто надо было вставить самый верхний код. Спасибо за статью.
- Игорь
Пожалуйста, Илья.
- Серый
Спасибо, работает!
- Сергей
так же не работает ни один способ
хостер адекватныйвидимо им писать в саппорт придётся
- Игорь Горнов
Да, Сергей, пожалуй. Сами видите, у многих получается реализовать.
- Александр Пузатых
Спасибо. Информация классная. Сейчас буду исправлять у себя на сайте. А то pgespeed выдает красную метку.
- Юрий
все сделал как описано, но скорость загрузки PageSpeed Insights не изменилась (74%). В чем может быть причина?
- Юрий
Вот мой htaccess
# BEGIN WordPressRewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]# END WordPress
добавляю ваш код и ничего не меняется
PageSpeed Insights как было 74% так и осталось.
Скажите в чем может быть проблема??? - Игорь Горнов
В особенностях конфигурации сервера Вашего хостинга, где расположен сайт. По моему, в статье и комментариях я уже отмечал, что этот метод не всем подходит.
- Валерий
Игорь, хорошая статья. Давно хотел это сделать, но не знал как. Теперь понятно. У меня один вопрос: "В какое место файла.htaccess нужно вставить код?".
- Игорь Горнов
Валерий, если у Вас уже есть какие-то фрагменты кода в.htaccess, то там должна быть такая строчка:
# END WordPress
В этом случае не только данный, но и любой код следует поместить выше этой строчки. Остальное не имеет значения.
- vokacan
Информация полезная, но разобраться новичку довольно сложно, на мой взгляд.
- Aely
Странно у меня то же не сработало, а что нужно делать, вернее что нужно у хостера спрашивать?
- Игорь Горнов
У хостера нужно спросить следующее: есть ли возможность включить кэширование на сервере для всех возможных файлов. Возможно, у них уже есть готовый алгоритм, отличный от предложенного мною.
- Aely
Спасибо, сейчас написал.
- Aely
Вот прикол, они(хостер) сказали что у них всё включено, а я им, а гуглспидтест - показывает "используйте кеш браузера", а они мне - это вопросы к гуглспидтест. Не могу понять кому верить?:)
- Игорь Горнов
Aely, такое отношение к клиенту со стороны хостера, по меньшей мере, странно. По идее, они должны бы объяснить и дать возможный алгоритм для внесения его в файл.htaccess, чтобы активировать функцию, даже если она у них включена. Интересно, а Вы не в первый раз обращались к службе поддержки, как она проявляла себя в других ситуациях?
17.04.1999 Фил Кеппелер
Как ожидается, кэш-серверы IP в 1999 г. будут пользоваться повышенным спросом на корпоративном рынке. Ниже мы рассмотрим последние предложения производителей. В отличие от пропускной способности глобальных сетей, память стала намного дешевле.
Как ожидается, кэш-серверы IP в 1999 г. будут пользоваться повышенным спросом на корпоративном рынке. Ниже мы рассмотрим последние предложения производителей.
В отличие от пропускной способности глобальных сетей, память стала намного дешевле. По данным исследования IDC, общий уровень цен на глобальные сети останется прежним или, в лучшем случае, несколько снизится. Тем временем стоимость памяти снижается в год на 31,4-39,8%.
С учетом этих фактов IP-кэширование становится привлекательным для оптимизации использования пропускной способности и повышения эффективности сети. Хранение часто запрашиваемых файлов ближе к конечным пользователям сокращает потребности в пропускной способности корпоративной глобальной сети или соединения Internet и, как следствие, исключает или откладывает необходимость в дорогостоящей модернизации. Оно позволяет также повысить производительность работы конечных пользователей, потому что объекты доставляются со скоростью локальной сети.
Сообщество Internet знало о преимуществах кэширования задолго до того, как Internet стал представлять собой коммерческий феномен, каковым он является сегодня. Обычно архивы файлов для таких служб Internet, как ftp, gopher и конференции, зеркальным образом копировались по всему миру, чтобы популярные файлы находились как можно ближе к пользователям. С появлением HTTP зеркальное копирование стало неэффективным ввиду огромного объема, чувствительности ко времени и случайной природы запрашиваемого информационного наполнения.
Кэш-серверы IP являются для HTTP тем же, чем было зеркальное копирование для архивных протоколов. Все кэш-серверы базируются, по сути, на одних и тех же принципах: они перехватывают запросы на объекты от браузера к серверу Web и сохраняют полученные от сервера объекты на жестком диске перед передачей их браузеру. Таким образом, при последующих запросах на тот же самый объект от других браузеров кэш-сервер возвращает копию объекта из своей памяти вместо того, чтобы передавать запрос на сервер Web для получения оригинала объекта. В идеале выполнение кэш-сервером запросов на объекты должно экономить и время, и пропускную способность. (Более детальное описание технологии кэширования можно найти в статье "Мал кэш - да дорог" в LAN №3 за этот год.)
Испытывая давление со стороны как потребителей, так и провайдеров информационного наполнения, провайдеры Internet стали основными пользователями IP-кэширования. Более быстрые средства соединения, такие, как цифровая абонентская линия (Digital Subscriber Line, DSL), IDSN и кабельные модемы, дают надежду на то, что когда-то слабейшее звено в цепи передачи данных - стандартный телефонный модем с максимальной скоростью передачи данных 56 Кбит/с - будет устранено. С ускорением соединений c Internet объем копируемых объектов увеличится пропорциональным образом, а это приведет к увеличению трафика по магистрали Internet. Одновременно провайдеры информационного наполнения переходят на более сложные и объемные форматы данных, такие, как потоковое аудио/видео и апплеты Java.
В результате этой атаки с двух сторон провайдеры Internet вынуждены искать более эффективные способы использования своей инфраструктуры, чтобы удовлетворить требования пользователей. IP-кэширование было и остается важной частью их решения.
Несмотря на то что многие провайдеры Internet признают преимущество IP-кэширования, предприятиям еще предстоит внедрить технологию в широком масштабе. По данным отчета Collaborative Research за февраль 1998 года, около 80% провайдеров Internet в США объявили о планах реализации кэширования в ближайшие полгода. С другой стороны, только 56% компаний собирались начать использовать кэширование в течение того же срока. Однако, как предсказывают эксперты, в 1999 году кэширование будет пользоваться повышенным спросом на корпоративном рынке. Согласно Collaborative Research, объем вложений в технологии кэширования в компаниях должен быстро обогнать соответствующий показатель для провайдеров Internet и вырасти с 85 млн долларов в 1998 году до свыше 1 млрд долларов в 2000 году (см. Таблицу).
| Мировой рынок продуктов для кэширования в 1998-2002 гг. | |||||
|---|---|---|---|---|---|
| Сегмент рынка | 1998 | 1999 | 2000 | 2001 | 2002 |
| Корпоративные пользователи | 85 млн долларов | 421 млн долларов | 1 113 млн долларов | 2 108 млн долларов | 3 157 млн долларов |
| Провайдеры Internet | 103 млн долларов | 214 млн долларов | 376 млн долларов | 481 млн долларов | 576 млн долларов |
| Другие | 19 млн долларов | 63 млн долларов | 149 млн долларов | 259 млн долларов | 373 млн долларов |
| Всего | 207 млн долларов | 698 млн долларов | 1 638 млн долларов | 2 848 млн долларов | 4 106 млн долларов |
| Источник: Collaborative Research, 1998 | |||||
Эта тенденция не осталась незамеченной производителями, и они активно переориентируют свои продукты на корпоративных клиентов. Первоначально выпускавшие продукты старшего класса для провайдеров Internet производители стали включать в свои линии продуктов предложения по относительно невысокой цене и с достаточным для компаний уровнем производительности. Кроме того, десяток новых производителей объявили или выпустили кэш-серверы на базе стандартного для отрасли аппаратного и программного обеспечения - например серверы на платформе Intel с бесплатным программным обеспечением кэширования Squid - с целью предложения как можно более дешевых продуктов.
ПОСРЕДНИК КАК КЭШ?
Первые кэш-серверы реализовывались обычно на базе proxy-серверов. Как таковые они выступали в роли брокеров объектов для группы пользователей, принимая все запросы и передавая их дальше адресату в Internet. Как общая точка доступа для всех пользователей, proxy-серверы оказались чрезвычайно привлекательны для реализации разнообразных дополнительных сервисов: фильтрации информационного наполнения, идентификации пользователей, протоколирования событий и кэширования объектов. Вкупе с брандмауэром proxy-сервер позволял создать защищенное соединение с Internet.
Одним из первых посредников с поддержкой кэширования был программный сервер Harvest Cache, появившийся в результате совместного проекта, финансируемого в 1994-1996 годах Агентством по исследовательским проектам в области передовых технологий (Advanced Research Projects Agency, ARPA), Национальным научным фондом (National Science Foundation, NSF) и NASA. С тех пор по крайней мере десяток продуктов был выпущен на рынок под маркой "кэширующих посредников". Примечательно, что и Netscape Communications, и Microsoft, и Novell имеют proxy-серверы с поддержкой кэширования, тесно интегрированные с их другими корпоративными инструментами. Помимо кэширования их продукты предлагают широкий выбор посреднических функций, таких, как идентификация пользователей, фильтрация информационного наполнения, сканирование на наличие вирусов, обеспечение защиты и протоколирование событий. Proxy от Microsoft выполняется на базе Windows NT 4.0; Proxy Server от Netscape - на базе большинства разновидностей UNIX, а также Windows NT; BorderManager FastCache от Novell - на IntranetWare, NetWare 4.11 и NetWare 5.
Другим широко используемым коммерческим посредником с кэшированием является Squid, продолжение Harvest Cache, развитием которого занимается Национальная лаборатория передовых сетевых исследований (National Laboratory for Advanced Network Research, NLANR). Возможно, благодаря тому, что он появился как продукт коллективных усилий в среде, где приветствуется и широко применяется стандартизованное и общепризнанное программное обеспечение, Squid занял твердое место на рынке провайдеров Internet и продолжает иметь относительно прочную инсталлированную базу.
Конфигурации с кэширующими посредниками имеют два основных недостатка. Во-первых, из-за того, что каждый пользовательский браузер должен быть сконфигурирован на обращение через посредника, выход сервера из строя приводит к тому, что все пользователи теряют свое соединение с Internet. Во-вторых, внесение в конфигурацию каждого пользовательского браузера информации о посреднике может оказаться трудоемкой в крупных предприятиях и, по существу, невыполнимой для оператора Internet задачей.
Чтобы избежать упомянутых затруднений в конфигурациях с посредником, вы можете реализовать в своей сети прозрачное кэширование посредством установки маршрутизатора с поддержкой заданных правил или коммутатора четвертого уровня для перенаправления трафика на кэш-сервер или группу серверов. Эти устройства перехватывают весь трафик HTTP через порт 80 и перенаправляют его в кэш. Кэш выполняет запросы HTTP и возвращает объекты назад браузеру. Действительно прозрачное решение в области кэширования должно поддерживать масштабирование посредством распределения нагрузки между несколькими кэш-серверами, а также переключение на резервные серверы в случае недоступности одного или всех кэш-серверов. Примерами коммутирующих устройств четвертого уровня могут служить ACEdirector от Alteon Networks и ServerIron от Foundry Networks.
Кэш-сервер Infolibria от DynaCache опирается на иной подход, обеспечивая прозрачность без использования отдельного коммутатора или маршрутизатора. Это достигается с помощью DynaLink Redirector (DLR), выделенного коммутатора четвертого уровня, взаимодействующего с DynaCache. DLR, интегральная составляющая стратегии компании в области кэширования, располагается в сети и переадресует в Internet только "промахи" кэша. По утверждению компании, подобная стратегия позволяет сократить нагрузку на маршрутизатор на две трети.
ПРОГРАММНЫЙ ПРОТИВ АППАРАТНОГО
В 1997 году в отчете под названием "Почему кэширование так важно" Forrester Research опубликовала прогноз, что провайдеры Internet и компании будут переходить с программных кэш-серверов на выделенные устройства кэширования. Аналогично, Dataquest заявила в июльском отчете 1998 года, что выделенные устройства будут доминировать на рынке продуктов для кэширования.
Нет, следовательно, ничего удивительного в том, что свыше полудюжины производителей в 1998 году выпустили устройства кэширования. Они заявляют, что их продукты предлагают лучшую производительность, чем программные аналоги, потому что операционная система и сервер кэширования тесно интегрированы друг с другом и оптимизированы для кэширования. Кроме того, они утверждают, что их продукты проще в настройке и конфигурации и представляют собой более надежные платформы ввиду меньшей вероятности образования брешей в защите из-за ошибок при администрировании или конфигурации. Обычно программные кэши, например рассматривавшиеся выше кэширующие посредники, разрабатываются с уклоном в сторону посреднических функций, в то время как аппаратные кэши создаются исключительно для поддержки кэширования при напряженных режимах эксплуатации. Несмотря на это, многие кэширующие устройства могут использоваться в конфигурациях с посредниками.
Network Appliance одной из первых предложила выделенное устройство кэширования. Для этого она адаптировала программное обеспечение NetCache для аппаратного продукта. Network Appliance приобрела программное обеспечение NetCache (и заполучила в придачу Питера Данцига, одного из главных архитекторов Harvest Project) вместе с небольшой молодой компанией Internet Middleware.
Среди других появившихся в 1998 году устройств кэширования - Cache Engine от Cisco Systems, CacheFlow от CacheFlow и DynaCache от InfoLibria. Не будучи выделенным устройством в строгом смысле слова, Netra Proxy от Sun Microsystems поставляется преконфигурированным на компьютере UltraSPARC II. Он содержит программное обеспечение кэширования от Sun и оптимизирован для осуществления этих функций.
Совсем недавно на рынке появились относительно недорогие устройства кэширования. Они базируются на стандартизованном аппаратном и программном обеспечении и представляют собой преконфигурированные серверные устройства, разработанные для того, чтобы сделать кэширование более простым и приемлемым по цене. Данный подход может оказаться привлекательным для небольших компаний или даже для крупных корпораций, если последние хотят воспользоваться преимуществами кэширования на уровне рабочих групп, но сомневаются в его целесообразности из-за высокой стоимости и сложности имеющихся решений. Цена на эти продукты колеблется в районе 2000 долларов, тогда как вышеупомянутые решения стоят не меньше 7000 долларов.
Тремя примерами недорогих устройств кэширования могут служить WebSpeed от Packetstorm Technologies, CacheQube и CacheRaQ от Cobalt Networks. WebSpeed продается по цене от 2100 до 7100 долларов в зависимости от размера кэша. WebSpeed использует процессоры Intel и бесплатную операционную систему Linux, а также программное обеспечение кэширования Squid. Компания делает ставку на то, что заказчики оценят недорогое преконфигурированное устройство, которое они могут установить в свои сети с минимальными усилиями. CacheQube и монтируемый в стойку CacheRaQ от Cobalt Network могут наращиваться как за счет увеличения емкости DRAM и дискового пространства, так и посредством создания кластера из нескольких устройств. CacheQube стоит 1899 долларов, а CacheRaQ - 2299 или 2799 долларов в зависимости от конфигурации.
Пытаясь опровергнуть прогнозы экспертов о том, что выделенные устройства кэширования будут доминировать на рынке, Inktomi выпустила Traffic Server, который компания позиционирует как высокопроизводительное решение в области кэширования, предназначенное главным образом для провайдеров Internet и крупных предприятий. В отличие от нее, другие программные кэши ориентированы на функции посредника и защиты в той же мере, что и на функции кэширования. При цене 30 000 долларов в расчете на ЦПУ Traffic Server имеет к тому же цену продукта уровня оператора связи.
СОВМЕСТИМОСТЬ И СТАНДАРТЫ
Ведущий свое начало от первых исследований в области кэширования в рамках проекта Harvest Project, протокол кэширования Internet (Internet Caching Protocol, ICP) определяет, как несколько кэш-серверов IP могут совместно использовать информацию о новизне объектов Web и как они получают объекты из других кэшей (в противовес извлечению объектов с исходного сервера Web). С помощью ICP администраторы серверов могут сконфигурировать кэш на подачу запроса к другим кэш-серверам, также поддерживающим ICP, на предмет наличия у них последней информации об объектах Web. Например, локальный кэш может попросить вышестоящий кэш посмотреть, нет ли у того более новой копии файла, и если такой копии нет, то не проверял ли тот возраст файла на исходном сервере. Даже если вышестоящий сервер не имеет более новой версии файла, то он мог недавно проверять факт изменения файла на исходном сервере. В зависимости от алгоритма обновления, локальный кэш может использовать эту информацию для получения более новой версии объекта с исходного сервера или задействовать вместо этого локальную копию (см. Рисунок).
Опрос вышестоящего кэша создает дополнительную задержку ввиду увеличения расстояния и времени передачи; однако экономия времени будет во многих случаях весьма значительна, так как запросу не надо преодолевать весь путь до сервера с оригиналом объекта. Кроме того, предоставление объектов с взаимодействующих по ICP серверов, расположенных вблизи от получателя, позволит сократить нагрузку на магистраль Internet, высвобождая пропускную способность для всего сообщества Internet в целом. Практически все решения в области кэширования сегодня поддерживают ICP.
Аналогично ICP, протокол маршрутизации для массива кэш-серверов (Caching Array Routing Protocol, CARP) представляет собой протокол для организации разделения нагрузки по кэшированию в рамках локального парка серверов. Он был разработан Microsoft и представлен в Консорциум World Wide Web (W3C) в качестве предложения по стандарту Internet. Помимо Microsoft около десятка других производителей, включая Packetstorm Technologies и Sun, объявили о своей поддержке CARP.
Чтобы устройство Cache Engine могло взаимодействовать с ее маршрутизаторами, Cisco разработала коммуникационный протокол для кэш-серверов в Web (Web Cache Communication Protocol, WCCP). С помощью WCCP маршрутизатор Cisco с поддержкой IOS перехватывает запросы HTTP, поступающие от браузеров, и перенаправляет их на кэш-сервер или выделенное устройство. WCCP поддерживает масштабируемость за счет распределения запросов между несколькими кэш-серверами в зависимости от их доступности.
В ноябре 1998 года Cisco начала выдавать лицензии на WCCP другим производителям продуктов для кэширования. Inktomi и Network Appliance заявили о намерениях включить поддержку WCCP в следующие редакции своих продуктов.
РЫНОЧНЫЕ ПОКАЗАТЕЛИ
Несмотря на некоторые разногласия относительно цифр, как ожидается, рынок продуктов кэширования Internet значительно вырастет в ближайшие четыре года. Collaborative Research прогнозирует рост рынка с 206 млн долларов США в 1998 году до свыше 4 млрд в 2002 году.
С учетом этих цифр, нет ничего удивительного в том, что крупнейшие производители и разработчики программного и аппаратного обеспечения пытаются использовать свое положение для проникновения на рынок решений в области кэширования. Например, обладая большой инсталлированной базой серверных операционных систем, Novell делает ставку на тесную интеграцию BorderManager с другими своими продуктами для привлечения к нему внимания со стороны корпоративных заказчиков.
Как и Novell, Microsoft и Sun борются за доминирующие позиции на рынке программного обеспечения и серверов Internet. Они обе имеют широкую инсталлированную базу серверов Web и позиционируют свои продукты - с сопутствующим арсеналом посреднических функций - как необходимые компоненты для интегрированной среды поддержки приложений Web. При наличии обширной инсталлированной базы сетевых устройств тесная интеграция Cache Engine с другими сетевыми компонентами Cisco может способствовать его широкому распространению.
ЦЕНА ЧТО НАДО
Решив внедрить кэширование у себя в сети, вы будете иметь выбор продуктов от бесплатных до стоящих 100 000 долларов и более. В общем случае чем дороже продукт, тем он мощнее.
В нижней части ценовой шкалы, где недавно доминировали программные кэш-серверы, вы можете теперь найти около десятка устройств кэширования. При использовании бесплатного продукта, такого, как Squid, доступного как в виде исходных кодов, так и в предварительно откомпилированном виде, вам потребуется компьютер, куда его можно было бы установить. Чтобы не входить в лишние расходы, вы можете перепрофилировать имеющееся оборудование под выполнение задач кэширования.
Netscape, Microsoft и Novell предлагают мощные программные кэш-серверы с широким набором посреднических функций. Их продукты стоят около 1000 долларов на один ЦПУ. Как и в случае Squid, общую стоимость решения можно уменьшить за счет применения имеющегося оборудования. В противном случае, стоимость покупки оборудования придется включить в расходную часть.
Фил Кеппелер - разработчик Web в дизайнерской и программистской фирме. С ним можно связаться по адресу: [email protected] .
Рассматриваемые продукты
Microsoft Netscape Communications National Laboratory for Advanced Network Research Alteon Networks ACEdirector
Брайан Д. Дэвидсон, кандидат наук из Рутгерского университета, ведет информационную страничку по ресурсам кэширования на своем сервере http://www.cs.rutgers.edu/~davison/Web-caching/ . Она содержит новости о кэшировании, перечень и таблицу кэширующих посредников, библиографию и т. п. Если вы хотите больше узнать о Harvest Project, то соответствующие ссылки на результаты исследований, стенограммы заседаний и ответы на часто задаваемые вопросы имеются по адресу: http://www.harvest.transarc.com . CacheNow - это текущая кампания по продвижению широкомасштабного кэширования в целях решения проблемы нехватки пропускной способности и преодоления ограничений инфраструктуры Internet. Сведения о ней имеются на http://vancouver-Webpages.com/CacheNow/ . |
Кэш-сервер - это хранилище результатов поисковых запросов, с возможностью обращения к нему через стандартный интерфейс авиа-вебсервисов.
Задачи, которые решает кэш-сервер
Кэш-сервер предназначен для ускорения работы стандартного поиска через авиа-вебсервисы, за счет использования сохраненных результатов при повторяющихся запросах. В случае, если один из результатов поиска не прошел проверку доступности, то сохраненные результаты удаляются и следующий поиск произойдет с новым запросом в ГРС.
Включение кэш-сервера
Для включения кэш-сервера необходимо:
Администратору необходимо :
- Зайти в раздел Для техподдержки → Nemo Connect Вебсервисы → Настройки Взаимодействия .
- Включить опцию Управление кэшем в разделе Использовать настройки в Авиа сервере из Немо 1 для разделов .
Менеджеру необходимо :
- Зайти в раздел
- Включить опцию Использовать кэш Nemo Connect
Настройки авиакэша
В разделе Управление продажами → Авиабилеты → Процессы → Процесс поиска → Правила кэширования перелётов перелётов можно задать неограниченного количество правил кэширования результатов авиа-поиска:
- Время до вылета в часах - означает, что для срабатывания правила до вылета должно быть указанное количество часов и более. Если срабатывает насколько правил, то выбирается то, что «ближе всего» к дате вылета. Например, есть правила: до вылета более 10, 20, 30 и 100 часов. Фактически до вылета 50 часов. Срабатывают первые 3 правила, и выбирается правило «до вылета 30 часов». Если ни одно правило не удовлетворяет требованиям, то берётся правило с наименьшим количеством часов. Например, есть 100, 200, 300 часов, а вылет фактически за 50 часов, в этом случае будет взято время жизни кэша от правила «100 часов до вылета».
- Время жизни кэша в минутах - период актуальности результатов поиска, сохраненных в кэше, с момента последнего поиска.
Учёт смены курсов в GDS
При смене курсов валют в GDS результаты поиска в кэше теряют актуальность, т.к. это приводит к изменению стоимости авиаперевозки в случаях, когда валюта итоговой стоимости отличается от валюты, в которой заведён тариф. Для решения этой проблемы в рамках авиа-сервера ведётся учёт изменений курсов валют. При получении результатов поиска из кэш-сервера проверяется, имели ли место изменения курса валюты тарифа относительно валюты итоговой стоимости. Если они были, то стоимость результатов поиска пересчитывается с учётом изменения курса валют. Данный функционал в настоящее время реализован только для поставщика Sabre.
Внимание! Для корректной работы необходимо наличие ключевого слова BSRDSP в EPR для всех PCC (настройки прописывает Sabre, обратитесь в службу поддержки ГРС). Данный параметр влияет на логику расчёта курсов и при его отсутствии пересчёт цен будет происходить некорректно.
Прим: Пересчёт стоимости идёт не только в части тарифа, но и в части такс. Если при этом таксы заведены в других валютах, отличных от валюты тарифа, то пересчёт будет всё равно произведён, т.к. нет возможности в результатах поиска получать информацию о валютах, в которых заведены таксы. Соответственно, результат в таких случаях может немного отклониться от фактического.
Данный функционал включается настройкой «Включить пересчёт курсов для результатов из кэша » в разделе Управление продажами → Авиабилеты → Процессы → Процесс поиска → Тонкая настройка .
В Sabre смена курсов происходит 1 раз в неделю в среду в полночь по часовому поясу, к которому относится PCC агентства. Синхронизация курсов на авиа-сервере запускается во вторник, среду и четверг в начале каждого часа(00:05, 01:05 и т.д) по московскому времени. При этом синхронизируются курсы для валют, которые встречались в результатах поиска.
Статистика поисковых запросов
Модуль отслеживает статистику совершенных поисков. На странице доступны фильтры:
- С даты - фильтр задает начало диапазона даты и времени для выборки данных.
- По дату - фильтр задает окончание диапазона даты и времени для выборки данных.
- Уровень детализации
- фильтр задает масштаб времени, рассматриваемых данных.
- День
- Перевод
Довольно подробное и интересное изложение материала, касающегося кэша и его использования. Часть 2 .
От переводчика: об опечатках и неточностях просьба сообщать в личку. Спасибо.
Веб-кэш располагается между одним или несколькими веб-серверами и клиентом, или множеством клиентов, и следит за входящими запросами, сохраняя при этом копии ответов - HTML-страниц, изображений и файлов (совокупно известных, как представления (representations); прим. переводчика - позвольте я буду употреблять слово “контент” - оно, на мой взгляд, не так режет слух), для собственных нужд. Затем, если поступает другой запрос с аналогичным url-адресом, кэш может использовать сохраненный прежде ответ, вместо повторного запроса к серверу.
Существует две основные причины, по которым используется веб-кэш:
1. Уменьшение времени ожидания - так как данные по запросу берутся из кэша (который располагается “ближе” к клиенту), требуется меньше времени для получения и отображения контента на стороне клиента. Это делает Веб более отзывчивым (прим. переводчика - “отзывчивым” в контексте быстроты реакции на запрос, а не эмоционально).
2. Снижение сетевого трафика - повторное использование контента снижает объем данных, передаваемых клиенту. Это, в свою очередь, экономит деньги, если клиент платит за трафик, и сохраняет низкими и более гибкими требования к пропускной способности канала.
Виды веб-кэшей
Кэш браузера (Browser cache)
Если вы изучите окно настроек любого современного веб-браузера (например, Internet Explorer, Safari или Mozilla), вы, вероятно, заметите параметр настройки «Кэш». Эта опция позволяет выделить область жесткого диска на вашем компьютере для хранения просмотренного ранее контента. Кэш браузера работает согласно довольно простым правилам. Он просто проверяет являются ли данные “свежими”, обычно один раз за сессию (то есть, один раз в текущем сеансе браузера).Этот кэш особенно полезен, когда пользователь нажимает кнопку “Назад” или кликает на ссылку, чтобы увидеть страницу, которую только что просматривал. Также, если вы используете одни и те же изображения навигации на вашем сайте, они будут выбираться из браузерного кэша почти мгновенно.
Прокси-кэш (Proxy cache)
Прокси-кэш работает по аналогичному принципу, но в гораздо большем масштабе. Прокси обслуживают сотни или тысячи пользователей; большие корпорации и интернет-провайдеры часто настраивают их на своих файрволах или используют как отдельные устройства (intermediaries).Поскольку прокси не являются частью клиента или исходного сервера, но при этом обращены в сеть, запросы должны быть к ним как-то переадресованы. Одним из способов является использование настроек браузера для того, чтобы вручную указать ему к какому прокси обращаться; другой способ - использование перехвата (interception proxy). В этом случае прокси обрабатывают веб-запросы, перенаправленные к ним сетью, так, что клиенту нет нужды настраивать их или даже знать об их существовании.
Прокси-кэши являются своего рода общей кэш-памятью (shared cache): вместо обслуживания одного человека, они работают с большим числом пользователей и поэтому очень хороши в сокращении времени ожидания и сетевого трафика. В основном, из-за того, что популярный контент запрашивается много раз.
Кэш-шлюз (Gateway Cache)
Также известные как “реверсивные прокси-кэши” (reverse proxy cache) или “суррогаты” (surrogate cache) шлюзы тоже являются посредниками, но вместо того, чтобы использоваться системными администраторами для сохранения пропускной способности канала, они (шлюзы) обычно используются веб-мастерами для того, чтобы сделать их сайты более масштабируемыми, надежными и эффективными.Запросы могут быть перенаправлены на шлюзы рядом методов, но обычно используется балансировщик нагрузки в той или иной форме.
Сети доставки контента (content delivery networks, CDN) распространяют шлюзы по всему интернету (или некоторой его части) и отдают кэшированный контент заинтересованным веб-сайтам. Speedera и Akamai являются примерами CDN.
Это учебное пособие преимущественно сфокусировано на браузерных кэшах и прокси, но некоторая информация подходит также и тем, кому интересны шлюзы.
Почему я должен им пользоваться
Кэширование является одной из наиболее неправильно понятых технологий в интернете. Веб-мастера, в частности, боятся потерять контроль над их сайтом, потому что прокси могут “скрыть” их пользователей, сделав сложным наблюдение посещаемости.К несчастью для них (веб-мастеров), даже если бы веб-кэша не существовало, есть слишком много переменных в интернете, чтобы гарантировать, что владельцы сайтов будут в состоянии получить точную картину того, как пользователи обращаются с сайтом. Если это является для вас большой проблемой, данное руководство научит вас как получить необходимую статистику, не делая ваш сайт “кэшененавистником”.
Другой проблемой является то, что кэш может хранить содержимое, которое устарело или просрочено.
С другой стороны, если вы ответственно подходите к проектированию вашего веб-сайта, кэш может помочь с более быстрой загрузкой и сохранением нагрузки на сервер и интернет-соединение в рамках допустимого. Разница может быть впечатляющей: загрузка сайта, не работающего с кэшем, может потребовать нескольких секунд; в то время как преимущества использования кэширования могут сделать её кажущейся мгновенной. Пользователи по достоинству оценят малое время загрузки сайта и, возможно, будут посещать его чаще.
Подумайте об этом в таком ключе: многие крупные интернет-компании тратят миллионы долларов на настройку ферм серверов по всему миру для репликации контента для того, чтобы ускорить, как только можно, доступ к данным для своих пользователей. Кэш делает то же самое для вас и он гораздо ближе к конечному пользователю.
CDN, с этой точки зрения, являются интересной разработкой, потому что, в отличие от многих прокси-кэшей, их шлюзы приведены в соответствие с интересами кэшируемого веб-сайта. Тем не менее, даже тогда, когда вы используете CDN, вы все равно должны учитывать, что там будет прокси и последующее кэширование в браузере.
Резюмируя, прокси и кэш браузера будут использоваться, нравится вам это или нет. Помните, если вы не настроите ваш сайт для корректного кэширования, он будет использовать настройки кэша по-умолчанию.
Как работает веб-кэш
Все виды кэшей обладают определенным набором правил, которые они используют, чтобы определить, когда брать контент из кэша, если он доступен. Некоторые из эти правил установлены протоколами (HTTP 1.0/HTTP 1.1), некоторые - администраторами кэша (пользователями браузера или администраторами прокси).Вообще говоря, это самые общие правила (не волнуйтесь, если вы не понимаете детали, они будут объяснены ниже):
- Если заголовки ответа сообщают кэшу не сохранять их, он не сохранит.
- Если запрос авторизованный (authorized) или безопасный (то есть, HTTPS), он не будет закэширован.
- Кэшированный контент считается “свежим” (то есть, может быть отправлен клиенту без проверки с исходного сервера), если:
- У него установлено время истечения или другой заголовок, контролирующий время жизни, и он еще не истек.
- Если кэш недавно проверял контент и тот был модифицирован достаточно давно.
- Если контент является устаревшим, исходному серверу будет предложено провалидировать его или сообщить кэшу, является ли имеющаяся копия по-прежнему актуальной.
- При определенных обстоятельствах - например, когда он отключен от сети - кэш может сохранять устаревшие ответы без проверки с исходного сервера.
Свежесть (freshness) и валидация (validation) являются наиболее важными способами, с помощью которых кэш работает с контентом. Свежий контент будет доступен мгновенно из кэша; валидное же содержимое избежит повторной отправки всех пакетов, если оно не было изменено.
