Каталог расширений

Популярные теги

3gp       avi       fb2       jpg       mp3       pdf      

Главная » Разное » Как включить на хостинге кэширование статических файлов

Как включить на хостинге кэширование статических файлов


Настройка сжатия и кэширования через .htaccess

В панелях управления Plesk и cPanel сжатие и кэширование для статических файлов настраивается через .htaccess. Для настройки кэширования используется модуль expires.

Mod_expires — модуль, который подсказывает вашему браузеру, какие статические файлы нужно кэшировать. Время хранения данных в кэше можно устанавливать в следующих значениях:

  • years,
  • months,
  • weeks,
  • days,
  • hours,
  • minutes,
  • seconds.

Настройка кэширования

Настройка expires:

  1. 1. Для настройки кэширования сайта .htaccess файл должен находиться в корневой директории вашего сайта. Если у вас нет этого файла воспользуйтесь справкой: У меня нет файла .htaccess, что делать?.
  2. 2.

    Добавьте в файл .htaccess строки следующего вида:

    Mod_expires

     <ifModule mod_expires.c> ExpiresActive On #кэшировать флэш и изображения на одну неделю ExpiresByType image/x-icon "access plus 7 days" ExpiresByType image/jpeg "access plus 7 days" ExpiresByType image/png "access plus 7 days" ExpiresByType image/gif "access plus 7 days" ExpiresByType application/x-shockwave-flash "access plus 7 days" #кэшировать css, javascript и текстовые файлы на одну неделю ExpiresByType text/css "access plus 7 days" ExpiresByType text/javascript "access plus 7 days" ExpiresByType application/javascript "access plus 7 days" ExpiresByType application/x-javascript "access plus 7 days" #кэшировать html и htm файлы на один день ExpiresByType text/html "access plus 1 day" #кэшировать xml файлы на десять минут ExpiresByType application/xhtml+xml "access plus 10 minutes" </ifModule>

    Совет

    Не обязательно кэшировать все указанные виды статических файлов, укажите только те, которые есть на вашем сайте. В качестве примера указано оптимальное время хранения 7 дней, но вы можете установить эти значения самостоятельно.

Настройка сжатия

На серверах виртуального хостинга сжатие .htaccess для статических файлов включено по умолчанию. Статические файлы обрабатываются веб-сервером Nginx, доступа к настройке которого нет.

Проверить наличие сжатия можно при помощи ресурса.

Если вам критична настройка сжатия, рекомендуем приобрести VPS сервер.

Не работает кэширование .htaccess

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

Облачные серверы нового поколения

Виртуализация KVM, почасовая оплата, резервные копии, готовые шаблоны, 10 доступных ОС на выбор!

Подробнее Помогла ли вам статья?

33 раза уже помогла

Включаем сжатие текста и кэширование статических файлов на хостинге Ru-Center

Я думаю, что все уже имеют представление об PageSpeed Insights – сервисе от Google, который показывает реальную скорость вашего сайта на различных устройствах и дает рекомендации по решению возможных проблем на нем.

Одними из популярных проблем, которые появляются в этом сервисе при проверке сайта (не только на хостинге Ru-Center) являются следующие:

Задайте правила эффективного использования кэша для статических объектов

и:

Включите сжатие текста

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

Исправляя эти ошибки, вы позволяете повысить оценку сервиса PageSpeed Insights (на момент написания статьи общее состояние сайта оценивается по 100-балльной шкале), ускорить загрузку вашего сайта и (если у вас много статических файлов) сэкономить интернет-трафик ваших пользователей.

Как именно исправить эти ошибки на хостинге Ru-Center так, чтобы PageSpeed Insights на них больше не «ругался», сегодня и пойдет речь.

Как включить сжатие текста и кэширование статических файлов на хостинге Ru-Center?

Обе процедуры (сжатие текста и кэширование статики) проделываются по одной схеме, меняется лишь небольшая часть кода.

1. Авторизуйтесь в панели управления хостингом.

2. Далее в левом меню перейдите в раздел «Сайты».

3. На открывшейся странице найдите домен вашего сайта и кликните по нему один раз левой кнопкой мыши.

4. На открывшейся странице, в верхней ее части перейдите в разделы «Настройки» - «Веб-сервер».

5. На открывшейся странице снимите флажок с пункта «Автоматический режим работы сайта» и нажмите кнопку «Сохранить».

6. Затем в левом меню перейдите в раздел «Файловый менеджер».

7. В нем перейдите по пути /home/pandoge/etc/nginx/sites-enabled/, где «pandoge» – логин вашего аккаунта. После чего откройте файл www.pandoge.com.site.conf одним нажатием на него название левой копкой мыши. «www.pandoge.com» в названии файла – это домен сайта, для которого мы делаем настройку и который мы ранее перевели в ручной режим работы (пункт 5).

8. В нем для настройки сжатия текста найдите строку, похожую на:

server_name pandoge.com www.pandoge.com;

и сразу после нее вставьте:

gzip_static on;
 gzip on;
 gzip_buffers 16 8k;
 gzip_comp_level 2; 
 gzip_min_length 1024; 
 gzip_types text/css text/plain text/json text/x-js text/javascript text/xml application/json application/x-javascript application/xml application/xml+rss application/javascript;
 gzip_disable "msie6";
 gzip_vary on;
 gzip_http_version 1.0;

«pandoge.com» в первом случае – это домен вашего сайта.

9. Здесь же для включения кэширования статических файлов найдите строку, похожую на:

location ~* ^.+\.(jpg|jpeg|gif|swf|png|ico|mp3|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|dat|avi|ppt|txt|tar|mid|midi|wav|bmp|rtf|wmv|mpeg|mpg|mp4|m4a|spx|ogx|ogv|oga|webm|weba|ogg|tbz|js|7z)$ {

Рядом с ней найдите строку, похожую на:

expires 720h;

и замените ее значение на «6M».

expires 6M;

Если такой строки у вас нет – просто добавьте ее.

После чего нажмите «Сохранить».

10. Далее в левом меню перейдите в раздел «Управление веб-сервером».

11. На открывшейся странице нажмите «Перезагрузить», после чего подождите, пока пропадет индикатор загрузки.

После всех этих шагов можете проверить свой сайт в PageSpeed Insights – ошибки должны исчезнуть. Если этого не произошло – напишите в комментариях, постараюсь вам помочь.

Обратите внимание, что кэширование файлов и сжатие текста не работает для внешних файлов. Подробнее об этом написано в отдельной нашей статье.

Кэширование статических файлов сайта через htaccess

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

Отметьте файлы, а вернее впишите их расширение, чтобы работать именно с ними и в кэш помещать именно их

<FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>

В данном случае мы используем модуль Header веб-сервера Apache и задаем:

  • max-age - время жизни кэшированных файлов, после которого будет происходить повторная загрузка файлов.

Используется конструкция filesMatch и получаемый от сервера заголовок CacheControl. Заголовок Header позволяет контролировать http запросы и ответы сервера. И теперь один раз скачав файлы, в следующий раз компьютер клиента уже не будет их грузить (а только через время max-age) - за счет этого и достигается увеличение в скорости загрузки страницы.

Для динамических страниц со сценариями, типа php - обычно отключают кэширование. Делаем это так, добавляем ниже конструкцию вида:

<FilesMatch ".(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>

 

Кэширование статичных страниц на стороне браузера - expires модуль

Мы можем закешировать страницы сайта с помощью модуля expires. Это возможность контролировать http заголовки на стороне браузера, с возможностью задавать время жизни кэша. Также работаем с файлов htaccess:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 month"

ExpiresByType image/gif "access plus 2 months"
ExpiresByType image/jpeg "access plus 2 months"
</IfModule>

Тут мы активируем модуль, затем задаем время жизни кэша по умолчанию, а затем конкретно - для конкретных файлов, а именно для gif-файлов - 2 месяца и столько же для jpeg-файлов. Указывайте время в секундах, минутах, часах, днях, неделях, месяцах или даже годах - не возбраняется).

Какие еще файлы или mime-type точнее можно указать: image/x-icon image/jpeg image/png image/gif application/x-shockwave-flash text/css text/javascript application/javascript application/x-javascript text/html application/xhtml+xml

Теперь у вас уже явно не возникнет вопроса: Как кэшировать статические файлы сайта?)

 

Добавить комментарий

Настройка времени кеширования статических файлов — База знаний JustHost.ru

Стандартные параметры кеширования на хостинге

Для следующих MIME-типов установлен период кеширования 7 дней:

  • image/*
  • text/css
  • application/x-javascript
  • application/javascript

Для остальных типов — кеширование отключено. Переопределить параметры можно через файл .htaccess.

Пример файла .htaccess

<IfModule mod_expires.c> ExpiresActive On ExpiresDefault "access 1 day" ExpiresByType text/javascript "access 2 day" ExpiresByType image/jpeg "access 3 day" <Files style.css> Header set Cache-Control "max-age=3600" </Files> </IfModule>

Здесь для всех типов файлов устанавливается период кеширования 1 день. Для типа text/javascript — 2 дня, для image/jpeg — 3 дня. Для файла style.css — 1 час.

В ExpiresByType можно указать любой MIME-тип.

Примеры использования директивы ExpiresByType

ExpiresByType text/cache-manifest       "access plus 0 seconds" ExpiresByType text/html                 "access plus 0 seconds" ExpiresByType text/xml                  "access plus 0 seconds" ExpiresByType application/xml           "access plus 0 seconds" ExpiresByType application/json          "access plus 0 seconds" ExpiresByType application/rss+xml       "access plus 1 hour" ExpiresByType application/atom+xml      "access plus 1 hour" ExpiresByType image/x-icon              "access plus 1 week" ExpiresByType image/gif                 "access plus 1 day" ExpiresByType image/png                 "access plus 1 day" ExpiresByType image/jpeg                "access plus 1 day" ExpiresByType video/ogg                 "access plus 1 day" ExpiresByType audio/ogg                 "access plus 1 day" ExpiresByType video/mp4                 "access plus 1 day" ExpiresByType video/webm                "access plus 1 day" ExpiresByType text/x-component          "access plus 1 day" ExpiresByType application/x-font-ttf    "access plus 1 day" ExpiresByType font/opentype             "access plus 1 day" ExpiresByType application/x-font-woff   "access plus 1 day" ExpiresByType application/x-font-woff2  "access plus 1 day" ExpiresByType image/svg+xml             "access plus 1 day" ExpiresByType application/vnd.ms-fontobject "access plus 1 day" ExpiresByType text/css                  "access plus 1 hour" ExpiresByType application/javascript    "access plus 1 hour" ExpiresByType application/x-javascript    "access plus 1 hour"

Описание параметров

Expires Default

Параметр ExpiresDefault устанавливает время кеширования по умолчанию. Если параметры кеширования уже установлены на сервере или определены на уровне виртуального хоста (.htaccess), то ExpireDefault будет переопределен.

Expires By Type

Параметр ExpiresByType устанавливает время кеширования для конкретного MIME-типа.

Пример конфигурации Nginx для контроля Expires

Сервера Nginx имеют другой формат данных и не используют файл .htaccess

server { #... location ~* \.(gif|ico|jpe?g|png)(\?[0-9]+)?$ { expires 1w; } location ~* \.(css|js)$ { expires 1d; } #... }

Поделиться ссылкой:

Похожее

Кешируем статику / Хабр

Существует мнение, что nginx — отличный инструмент для отдачи статики.
Есть статьи, где описываются настройки sendfile или aio для «улучшения» отдачи.
На Хабре есть чего почитать о настройке proxy_store с proxy_cache для минимизации проблем со стороны мозгов сайта.
Еще в QA иногда возникают вопросы про кеширование картинок, например.
Зачем заниматься этой ерундой! — говорят опытные пользователи — OS лучше вас знает как кешировать файлы! С кешем и префетчем в современных OS, точнее FS, проблем нет! Зачем плодить свои кеши и списки популярных материалов и все такое?...

Есть только одно вредное «но» — в среде исполнения nginx (в общем случае Linux) понятие "файл" и вообще «файловая система» — просто понятие.
И однажды, когда я, подмонтировав сервер по sshfs, обновил один скриптик, случилось волшебное:
1. На каждой страничке стало на 4 картинки больше.
2. Сервера сдохли.
Что поделать — картинки хранились на glusterFS. Наступил полный FUSE.

GlusterFS, как и интерфейс FUSE, сильно сжирает производительность, но он того стоит.
Изначально у нас был один сервер. Потом два, второй из который монтировал www с первого по nfs. Потом три, четыре.
Не очень надежно, но так уж исторически сложилось. Для спасения ситуации нужна была некая совершенно прозрачная система, in-place замена nfs. Кластерная ФС.
Сейчас на всех серверах стоит raid 10, и за полтора года эксплуатации он пару раз падал. В том числе совсем. Gluster молча поднимал копию ФС на новой железяке и все продолжало работать. Гластер свою работу знает.
Но на самом деле история начиналось немного не так.

Причина была другая, но решения проблем будет совпадать.
Нет ничего страшнее чем то что "исторически сложилось".
И в одном моем проекте «исторически сложилась» ситуация, когда картинки отдает php.
В свое время нужно было сделать файловый загрузчик с различными ACL, ресайзами и вотермарками. Это было почти 10 лет назад. Механизм прижился и с тех пор не менялся.
Сейчас для решения таких проблем есть много специализированных решений(elliptics, backpack и другие; а еще лучше CDN). Но тратить человекомесяцы на переход не хочется. Спать хочется, а не работать.
Да и php чтука, в принципе, неплохая. Но имеет свои пределы.
Но проблема тормозных бэкендов решена

Хабр, в очередной раз подсказал вариант решения — proxy_store и proxy_cache.
Но proxy_store использовать мне нельзя — сохранить негде, и с proxy_cache тоже проблемы.
Есть одно, большое такое, «но» — много лет назад я уже столкнулся с производительностью отдачи файлов и решил «пускай лучше nginx отдает конечные файлы за меня».
X-Accel-Redirect.
Проблема — nginx не может закешировать ответ из прокси если это не ответ, а команда. X-Accel-Redirect — не кешируется.
Выхода нет?
Исходную проблему зафиксировали

Теперь вернемся к началу топика.
Нам нужно отдать статику, на этот раз без вмешательства «умных» бэкэндов. Просто статику, но с glusterfs.
Директив для кеширования статики просто нет — не предусмотрены. Считается что OS сама не дура. Для статики есть только open_file_cache и настройка самой передачи файлов(sendfile/aio и компания).
Что делать?
Усложним задачу, и попробуем решить проблему исключительно средствами nginx, не внося никаких изменений в другие коды.
обычный конфиг
# Static files location location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|js|swf|txt|ico)$ { root /var/www/kashey; }
Пропатченый конфиг

Nginx делает proxy_pass сам на себя, кешируя результат. Возможно тут можно использовать fcgi, но так — нагляднее.
# Static files location location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|js|swf|txt|ico)$ { set $dopass 1; proxy_set_header Host $host; #если у нас есть "кука" - отдаем файл с реальной ФС if ($http_fiberpass) { root /var/www/kashey; #или proxy_pass на бэкэнд set $dopass 0; break; #но этот break не работает } #настройки кеширования, не забудьте описать proxy_cache_valid proxy_cache static_cache; #добавляем прокси "куку" proxy_set_header fiberpass "nginx"; if ($dopass) { #отправляем запрос к самому себе. proxy_pass http://127.0.0.1:80; } }

И никакой магии.
В случае с X-Accel-Redirect схема такая:
1. nginx получается запрос
2. пересылает себе, к сожалению запрос полный и реальный.
3. пересылает на прокси
4. получает ответ и отдает файл
5. ответ кешируется
6. ???
7. PROFIT

В случае с обычной статикой сложнее — root не заканчивает выполнение, break и return также не работают. Настройка прокси не может находиться внутри условного блока.
Что это дает?

В смысле с X-Accel-Redirect с apache снимается вал запросов. На загруженной системе разница может составить 50 раз.
Но это понятно — php сам по себе, а через апач тем более, не самое реактивное решение.
Latenсy запроса меньше 40мс, лично у меня, не получался (общее время php+gluster).
В случае использования варианта с proxy_cache скорость отдачи приравнивается к скорости отдачи статики.
А что со статикой?

Отдача с gluster — 13мс — это нормальное время для системы без кеша.

Отдача из кеша — 1мс — это замечательное.

Важно учесть — сервера находятся в Германии, а клиенты в России.
Нормальные пинги до сайта 60-100мс.
Так что для клиента ускорение практически не заметно.

Но оно заметно для сервера.
1. Снизилась нагрузка на сервера, в том числе в попугаях Load average и soft-irq.
2. Снизился трафик между серверами (можно решить включив WORM(Write Once Read Many volume), но это уже не «прозрачно»).

3. Все стало работать чуть быстрее.

В итоге работы которые на 10% снизили скорость реакции на клиенте, получились в результате 10-ти кратного ускорения отдачи статики. Что снизило общую нагрузку на сервера примерно раз в 20.
Обратное утверждение, к сожалению, тоже будет верно — сколько не старайся, клиент может и не заметить.

PS: Многие знакомые сисадмины даже не допускали мысли о возможности работы такой схемы. Не позволяет кешировать/проксировать — значит нельзя.

Хорошие программисты не всегда хорошие сисадмины, а сисадмины, обычно, вообще не программисты.
Настоящие герои всегда идут в обход, в брод, и на велосипедах.

PPS: я, кстати, не сисадмин. И, быть может, все сделал не правильно.

Кэширование статических файлов в Nginx

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

В текстовом редакторе откройте nginx.conf

найдите конфигурационный блок server {} для Вашего виртуального хоста. В данном конфигурационном блоке есть раздел location для обработки статических документов.

В итоге блок location будет выглядеть примерно так: 

location ~* ^.+.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ { root /var/www/username/data/www/usernamesite.ru; access_log /var/www/nginx-logs/usernamesite isp; access_log /var/www/httpd-logs/usernamesite.ru.access.log ; error_page 404 = @fallback; expires 7d; }

где expires 7d — это количество дней, сколько кэш статических файлов должен храниться на компьютере пользователя. Если вы не вносите правки в css, js, файлы своего сайта и не меняете картинки, то имеет смысл этот параметр увеличить, вплоть до нескольких месяцев или даже до года.

Второй вариант – научить панель указывать параметр expires для статики во всех виртуальных серверов в файле конфигурации nginx. Для этого создаем файл /usr/local/ispmgr/etc/server.templ со следующим содержимым: 

location ~* ^.+.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ { expires 7d; }

Теперь включим GZIP сжатие для статичных файлов

Сжатие GZIP экономит трафик и увеличивает скорость загрузки страниц.

Как включить GZIP для статики в NGINX 

server { .... gzip on; gzip_disable "msie6"; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript; }
Кэширование

- как управлять кешем с автоматическим управлением версиями статических файлов в ASP.NET?

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
  3. Вакансии Программирование и связанные с ним технические возможности карьерного роста
.

Как использовать кеширование вашего веб-сайта или блога в браузере


Что такое кеширование браузера?

  • Кэширование браузера сохраняет файлы ресурсов веб-страницы на локальном компьютере, когда пользователь посещает веб-страницу.
  • «Использование» кеширования браузера - это когда веб-мастер инструктирует браузеры, как следует обращаться с их ресурсами.

Когда веб-браузер отображает вашу веб-страницу, он должен загрузить несколько вещей, например, ваш логотип, ваш файл CSS и другие ресурсы.

Кэширование браузера «запоминает» ресурсы, которые браузер уже загрузил.Когда посетитель переходит на другую страницу вашего веб-сайта, ваш логотип, файлы CSS и т. Д. Не нужно загружать повторно, потому что в браузере они «запоминаются» (сохраняются). Это причина того, что первый просмотр веб-страницы занимает больше времени, чем повторные посещения.

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

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

Как использовать кеширование браузера

  1. Измените заголовки запросов ваших ресурсов, чтобы использовать кеширование.
  2. Оптимизируйте свою стратегию кэширования.

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

Для большинства людей способ включить кеширование - это добавить код в файл с именем .htaccess на вашем веб-хосте / сервере.

Это означает переход к файловому менеджеру (или куда бы вы ни пошли, чтобы добавить или загрузить файлы) на вашем веб-хосте.

The.Файл .htaccess контролирует многие важные вещи для вашего сайта. Если вы не знакомы с файлом .htaccess, прочтите мою статью о работе с .htaccess, чтобы узнать, как это сделать, прежде чем изменять его.

Кеширование браузера для .htaccess

Приведенный ниже код сообщает браузерам, что нужно кэшировать и как долго это «запоминать». Его следует добавить в начало файла .htaccess.

## EXPIRES CACHING ##

ExpiresActive On
ExpiresByType image / jpg "доступ на 1 год"
ExpiresByType image / jpeg "доступ 1 год"
ExpiresByType image / gif2 "доступ 1 год"
ExpiresByType image / gif2 "доступ 1 год"
/ png "доступ 1 год"
ExpiresByType text / css "доступ 1 месяц"
ExpiresByType text / html "доступ 1 месяц"
Приложение ExpiresByType / pdf "доступ 1 месяц"
ExpiresByType text / x-javascript "доступ 1 месяц"
Приложение ExpiresByType / x-shockwave-flash "доступ 1 месяц"
ExpiresByType image / x-icon "доступ 1 год"
ExpiresDefault "доступ 1 месяц"

## EXPIRES CACHING ##

Сохраните файл.htaccess, а затем обновите свою веб-страницу.

Как установить разное время кеширования для разных типов файлов

В приведенном выше коде вы можете видеть, что существуют периоды времени, такие как «1 год» или «1 месяц». Они связаны с типами файлов, например, в приведенном выше коде указано, что файл .jpg (изображение) следует кэшировать в течение года.

Если вы хотите изменить это и хотите, чтобы ваши изображения jpg кэшировались в течение месяца, вы просто замените «1 год» на «1 месяц». Приведенные выше значения оптимизированы для большинства веб-страниц и блогов.

Альтернативный метод кеширования .htaccess

Вышеупомянутый метод называется «Expires» и работает для большинства людей, использующих .htaccess, поэтому он заботится о кешировании для большинства людей, которые только начинают работать.

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

Также возможно, что метод expires не сработал для вашего сервера, в этом случае вы можете попробовать использовать Cache-Control.

Кэш-контроль

Примечание. Здесь я сделал более полное руководство по Cache-Control.

Cache-Control позволяет нам немного больше контролировать кеширование в браузере, и многим людям проще использовать его после настройки.

Пример использования в файле .htaccess:

# 1 месяц для большинства статических ресурсов

Заголовочный набор Cache-Control "max-age = 2592000, общедоступный"

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

Как работает контроль кеширования

Давайте рассмотрим приведенный выше код построчно.

# 1 месяц для большинства статических активов

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

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

Важная часть этой строки - обратить внимание на то, что в списке перечислены файлы различных типов (css, js, jpeg, png и т. Д.), И что последующие инструкции по кэшированию будут применяться к этим типам файлов. Например, если вы не хотите, чтобы ваши файлы jpg кэшировались в течение этого времени, вы можете удалить «jpg» из этой строки или, если вы хотите добавить к нему html, вы можете просто добавить «html» в эту строку.

Заголовочный набор Cache-Control "max-age = 2592000, общедоступный"

В приведенной выше строке вставляются фактические заголовки и указываются значения.

  • Часть «Header set Cache-Control» устанавливает заголовок.
  • Часть «max-age = 2592000» указывает, как долго он должен храниться в кэше (в секундах). В этом случае мы кэшируем на один месяц, что составляет «2592000» секунд.
  • «Общедоступная» часть заявляет, что это общедоступный (что хорошо, если вы хотите, чтобы он был кэширован).

Вышеупомянутая строка закрывает оператор и завершает блок кода.

Общая проблема кеширования

Если вы указываете свой HTML-код и изображения для кеширования на один год или другой длительный период времени, помните, что это может означать, что если вы внесете изменения в свои страницы, они могут быть видны не всем пользователям.Это потому, что пользователи будут обращать внимание на кешированные файлы, а не на живые. Если у вас есть файл, который вы изменяете время от времени (например, файл CSS), вы можете решить проблему с кешем, используя отпечаток URL.

Отпечатки URL-адресов

Получение нового (не кэшированного) файлового ресурса возможно при наличии уникального имени. Например, если бы наш файл css был назван «main.css», мы могли бы вместо этого назвать его «main_1.css». В следующий раз, когда мы изменим его, мы можем назвать его main_2.css. Это полезно для файлов, которые периодически меняются.

Методы кеширования

Важно указать один из max-age Expires или Cache-Control и один из Last-Modified или ETag для всех кэшируемых ресурсов. Излишне указывать и Expires, и Cache-Control: max-age, или указывать и Last-Modified, и ETag.


Патрик Секстон


.

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

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где застройщик
.

Как работает кеширование | Документы Microsoft

  • На чтение 9 минут

В этой статье

В этой статье представлен обзор общих концепций кэширования и того, как сеть доставки контента Azure (CDN) использует кеширование для повышения производительности. Если вы хотите узнать, как настроить поведение кэширования в конечной точке CDN, см. Разделы Управление поведением кэширования Azure CDN с помощью правил кэширования и Управление поведением кэширования Azure CDN с помощью строк запроса.

Введение в кэширование

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

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

Динамические ресурсы, которые часто меняются или являются уникальными для отдельного пользователя, не могут быть кэшированы.Однако эти типы ресурсов могут использовать оптимизацию динамического ускорения сайта (DSA) в сети доставки контента Azure для повышения производительности.

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

  • Веб-сервер: использует общий кеш (для нескольких пользователей).
  • Сеть доставки контента: использует общий кеш (для нескольких пользователей).
  • Интернет-провайдер (ISP): использует общий кеш (для нескольких пользователей).
  • Веб-браузер: использует частный кеш (для одного пользователя).

Каждый кеш обычно управляет своей актуальностью ресурсов и выполняет проверку, когда файл устарел. Это поведение определено в спецификации кэширования HTTP, RFC 7234.

Ресурс свежести

Поскольку кэшируемый ресурс потенциально может быть устаревшим или устаревшим (по сравнению с соответствующим ресурсом на исходном сервере), важно, чтобы любой механизм кэширования контролировал время обновления содержимого.Чтобы сэкономить время и потребление полосы пропускания, кэшированный ресурс не сравнивается с версией на исходном сервере при каждом обращении к нему. Вместо этого, если кэшированный ресурс считается свежим, предполагается, что он является самой последней версией и отправляется непосредственно клиенту. Кэшированный ресурс считается свежим, если его возраст меньше возраста или периода, определенного параметром кеширования. Например, когда браузер перезагружает веб-страницу, он проверяет, что каждый кэшированный ресурс на вашем жестком диске свежий, и загружает его.Если ресурс не является свежим (устаревшим), с сервера загружается его актуальная копия.

Проверка

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

Кэширование CDN

Кэширование является неотъемлемой частью работы CDN для ускорения доставки и снижения исходной нагрузки для статических ресурсов, таких как изображения, шрифты и видео. При кэшировании CDN статические ресурсы выборочно хранятся на стратегически размещенных серверах, которые более локальны для пользователя и имеют следующие преимущества:

  • Поскольку большая часть веб-трафика статична (например, изображения, шрифты и видео), кэширование CDN снижает задержку в сети, перемещая контент ближе к пользователю, тем самым сокращая расстояние, на которое проходят данные.

  • Путем передачи работы CDN кэширование может снизить сетевой трафик и нагрузку на исходный сервер. Это снижает затраты и требования к ресурсам для приложения даже при большом количестве пользователей.

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

Для определения актуальности кеша можно использовать два заголовка: Cache-Control и Expires . Cache-Control является более современным и имеет приоритет над Истекает , если оба существуют. Также для проверки используются два типа заголовков (называемых валидаторами): ETag и Last-Modified . ETag более актуален и имеет приоритет над Last-Modified , если оба определены.

Заголовки директивы Cache

Важно

По умолчанию конечная точка Azure CDN, оптимизированная для DSA, игнорирует заголовки директив кеширования и пропускает кэширование. Для Azure CDN Standard от Verizon и Azure CDN Standard из профилей Akamai вы можете настроить, как конечная точка Azure CDN обрабатывает эти заголовки, используя правила кэширования CDN для включения кэширования.Только для Azure CDN Premium из профилей Verizon вы используете механизм правил для включения кэширования.

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

Кэш-контроль:

  • Введено в HTTP 1.1, чтобы предоставить веб-издателям больший контроль над своим контентом и устранить ограничения заголовка Expires .
  • Переопределяет заголовок Expires , если он и Cache-Control определены.
  • При использовании в HTTP-запросе от клиента к POP CDN, Cache-Control по умолчанию игнорируется всеми профилями Azure CDN.
  • При использовании в ответе HTTP от клиента на POP CDN:
    • Azure CDN Standard / Premium от Verizon и Azure CDN Standard от Microsoft поддерживают все директивы Cache-Control .
    • Стандарт Azure CDN от Akamai поддерживает только следующие директивы Cache-Control ; все остальные игнорируются:
      • max-age : Кэш может хранить содержимое в течение указанного количества секунд.Например, Cache-Control: max-age = 5 . Эта директива определяет максимальное количество времени, в течение которого контент считается свежим.
      • no-cache : кэшировать содержимое, но проверять его каждый раз перед доставкой из кеша. Эквивалентно Cache-Control: max-age = 0 .
      • no-store : никогда не кэшировать содержимое. Удалите содержимое, если оно было ранее сохранено.

Срок годности:

  • Устаревший заголовок, представленный в HTTP 1.0; поддерживается для обратной совместимости.
  • Использует время истечения срока действия на основе даты с точностью до секунды.
  • Аналогично Cache-Control: max-age .
  • Используется, когда Cache-Control не существует.

Прагма:

  • По умолчанию не поддерживается Azure CDN.
  • Устаревший заголовок, представленный в HTTP 1.0; поддерживается для обратной совместимости.
  • Используется в качестве заголовка запроса клиента со следующей директивой: no-cache .Эта директива указывает серверу доставить свежую версию ресурса.
  • Pragma: no-cache эквивалентно Cache-Control: no-cache .

Валидаторы

Когда кеш устарел, используются валидаторы кеша HTTP для сравнения кэшированной версии файла с версией на исходном сервере. Azure CDN Standard / Premium от Verizon по умолчанию поддерживает валидаторы ETag и Last-Modified , а Azure CDN Standard от Microsoft и Azure CDN Standard от Akamai по умолчанию поддерживает только Last-Modified .

ETag:

  • Azure CDN Standard / Premium от Verizon по умолчанию поддерживает ETag , а Azure CDN Standard от Microsoft и Azure CDN Standard от Akamai - нет.
  • ETag определяет строку, уникальную для каждого файла и версии файла. Например, ETag: "17f0ddd99ed5bbe4edffdd6496d7131f" .
  • Введено в HTTP 1.1 и является более поздним, чем Last-Modified .Полезно, когда трудно определить дату последнего изменения.
  • Поддерживает как строгую, так и слабую проверку; однако Azure CDN поддерживает только строгую проверку. Для строгой проверки два представления ресурса должны быть побайтно идентичными.
  • Кэш проверяет файл, который использует ETag , отправляя заголовок If-None-Match с одним или несколькими валидаторами ETag в запросе. Например, If-None-Match: "17f0ddd99ed5bbe4edffdd6496d7131f" .Если версия сервера совпадает с валидатором ETag в списке, он отправляет в своем ответе код состояния 304 (Not Modified). Если версия отличается, сервер отвечает кодом состояния 200 (OK) и обновленным ресурсом.

Последнее изменение:

  • Только для Azure CDN Standard / Premium от Verizon , Last-Modified используется, если ETag не является частью ответа HTTP.
  • Задает дату и время, когда исходный сервер определил, что ресурс был последний раз изменен.Например, Last-Modified: Thu, 19 Oct 2017 09:28:00 GMT .
  • Кэш проверяет файл, используя Last-Modified , отправляя заголовок If-Modified-Since с датой и временем в запросе. Исходный сервер сравнивает эту дату с заголовком Last-Modified последнего ресурса. Если ресурс не был изменен с указанного времени, сервер возвращает код состояния 304 (Не изменен) в своем ответе. Если ресурс был изменен, сервер возвращает код состояния 200 (ОК) и обновленный ресурс.

Определение файлов, которые можно кэшировать

Не все ресурсы можно кэшировать. В следующей таблице показано, какие ресурсы можно кэшировать в зависимости от типа ответа HTTP. Ресурсы, доставленные с ответами HTTP, которые не соответствуют всем этим условиям, не могут быть кэшированы. Только для Azure CDN Premium от Verizon вы можете использовать механизм правил для настройки некоторых из этих условий.

Azure CDN от Microsoft Azure CDN от Verizon Azure CDN от Akamai
Коды состояния HTTP 200, 203, 206, 300, 301, 410, 416 200 200, 203, 300, 301, 302, 401
HTTP-методы GET, ГОЛОВКА ПОЛУЧИТЬ ПОЛУЧИТЬ
Пределы размера файла 300 ГБ 300 ГБ - Общая оптимизация веб-доставки: 1.8 ГБ
- Оптимизация потоковой передачи мультимедиа: 1,8 ГБ
- Оптимизация больших файлов: 150 ГБ

Для Azure CDN Standard от Microsoft кэширование для работы с ресурсом, исходный сервер должен поддерживать любые HTTP-запросы HEAD и GET, а значения длины содержимого должны быть одинаковыми для любых HTTP-ответов HEAD и GET для ресурса. . Для запроса HEAD исходный сервер должен поддерживать запрос HEAD и должен отвечать такими же заголовками, как если бы он получил запрос GET.

Поведение кэширования по умолчанию

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

Microsoft: общая веб-доставка Verizon: общая веб-доставка Verizon: DSA Akamai: общая веб-доставка Акамай: DSA Akamai: загрузка большого файла Akamai: обычная потоковая передача мультимедиа или видео по запросу
Честь происхождения Есть Есть № Есть № Есть Есть
Длительность кеш-памяти CDN 2 дня 7 дней Нет 7 дней Нет 1 день 1 год

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

Продолжительность кэша CDN : указывает время, в течение которого ресурс кэшируется в Azure CDN. Однако, если Honor origin имеет значение Да и ответ HTTP от исходного сервера включает заголовок директивы кеширования Expires или Cache-Control: max-age , Azure CDN вместо этого использует значение продолжительности, указанное в заголовке.

Следующие шаги

.

ReactJS: Как запретить браузеру кешировать статические файлы?

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
.Руководство по кэшированию

- HTTP-сервер Apache, версия 2.4

Этот документ дополняет mod_cache , mod_cache_disk , mod_file_cache и справочная документация htcacheclean. В нем описывается, как использовать функции кэширования HTTP-сервера Apache для ускорения работы в Интернете и обслуживание прокси, избегая при этом распространенных проблем и неправильной конфигурации.

См. Также

HTTP-сервер Apache предлагает ряд функций кэширования, которые предназначены для повышения производительности сервера в различных способами.

RFC2616 с тремя состояниями кэширование HTTP
mod_cache и его модули провайдера mod_cache_disk обеспечить интеллектуальное кэширование с поддержкой HTTP. Сам контент хранится в кеше, а mod_cache нацелен на соблюдение всех различных HTTP заголовки и параметры, управляющие кэшируемостью контента как описано в Раздел 13 RFC2616. mod_cache предназначен как для простых, так и для сложных конфигураций кеширования, где вы имеете дело с прокси-контентом, динамическим локальным контентом или необходимо ускорить доступ к локальным файлам на потенциально медленный диск.
Кэширование общих объектов с двумя состояниями ключ / значение
API кэша общих объектов (socache) и его модули провайдера предоставляют общесерверный кэш общих объектов на основе ключей / значений.Эти модули предназначены для кэширования данных низкого уровня, таких как сеансы SSL и учетные данные для аутентификации. Бэкэнды позволяют хранить данные на уровне сервера в разделяемой памяти или на уровне центра обработки данных в кэше, например как memcache или distcache.
Специализированное кэширование файлов
mod_file_cache предлагает возможность предварительной загрузки файлы в память при запуске сервера, и может улучшить доступ раз и сохранить дескрипторы файлов для часто используемых файлов, поскольку нет необходимости переходить на диск при каждом запросе.

Чтобы извлечь максимальную пользу из этого документа, вы должны быть знакомы с основы HTTP и прочли Руководства пользователя по Сопоставление URL-адресов с файловой системой и Согласование содержания.

Протокол HTTP содержит встроенную поддержку встроенного кэширования. механизм описано в разделе 13 RFC2616, а mod_cache Модуль можно использовать для использования этот.

В отличие от простого двухуровневого кэша ключ / значение, в котором содержимое полностью исчезает, когда больше не свежий, HTTP-кеш включает механизм для сохранения устаревшего контента и запроса исходного сервера изменилось ли это устаревшее содержимое, и если нет, сделайте его свежим еще раз.

Запись в кэше HTTP существует в одном из трех состояний:

Свежий
Если контент достаточно новый (младше свежести срок службы ), считается свежий . An HTTP-кеш может бесплатно обслуживать свежий контент без каких-либо обращается к исходному серверу вообще.
Несвежий

Если содержимое слишком старое (старше свежести срок службы ) считается устаревшим .An Кеш HTTP должен связаться с исходным сервером и проверить, содержание еще свежо перед тем, как передать устаревшее содержание в клиент. Исходный сервер либо ответит заменой контент, если он еще не действителен, или, в идеале, исходный сервер будет ответьте кодом, чтобы сообщить кешу, что контент все еще свежие, без необходимости создавать или отправлять контент снова. Контент снова становится свежим, и цикл продолжается.

Протокол HTTP позволяет кешу обслуживать устаревшие данные при определенных обстоятельствах, например, при попытке освежить сбой данных с исходного сервера с ошибкой 5xx, или когда другой запрос уже находится в процессе обновления данная запись.В этих случаях заголовок Предупреждение добавляется к ответу.

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

Полную информацию о том, как работает HTTP-кеширование, можно найти в Раздел 13 RFC2616.

Взаимодействие с сервером

Модуль mod_cache подключается к серверу двумя возможные места в зависимости от стоимости CacheQuickHandler директива:

Фаза быстрой обработки

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

В этом сценарии кеш ведет себя так, как если бы он был заблокирован на "перед сервером.

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

запросов с заголовком «Авторизация» (например, HTTP Basic Аутентификация) не кэшируются и не обслуживаются из кеша когда mod_cache работает на этом этапе.

Обычная фаза обработчика

Эта фаза происходит в конце обработки запроса, в конце концов этапы запроса завершены.

В этом сценарии кеш ведет себя так, как если бы он был заблокирован на "к задней части сервера.

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

Если URL-адрес не найден в кэше, mod_cache добавит фильтр в стек фильтров, чтобы записать ответ в кеш, а затем остановиться, разрешив нормальный обработка запроса продолжается.Если содержание определено как кэшируемый, контент будет сохранен в кеш для дальнейшего обслуживания, в противном случае содержимое будет проигнорировано.

Если содержимое, обнаруженное в кэше, устарело, mod_cache Модуль преобразует запрос в условный запрос . Если исходный сервер отвечает нормальный ответ, нормальный ответ кэшируется, заменяя содержимое уже кешировано. Если исходный сервер отвечает 304 Not Modified ответ, контент снова помечается как свежий, а кешированный контент обслуживается фильтром, а не сохраняется.

Улучшение обращений к кеш-памяти

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

Срок службы свежести

Правильно сформированный контент, предназначенный для кэширования, должен объявлять явное время жизни свежести с Cache-Control поля заголовка max-age или s-maxage , или включив заголовок Expires .

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

Когда это время жизни отсутствует в запросе или ответа, применяется время действия по умолчанию. По умолчанию время жизни для кешированных объектов составляет один час, однако это можно легко изменить с помощью директивы CacheDefaultExpire .

Если ответ не включает заголовок Expires , но содержит включить заголовок Last-Modified , mod_cache может сделать вывод о продолжительности жизни на основе эвристики, которая может быть контролируется с помощью директивы CacheLastModifiedFactor .

Для локального контента или для удаленного контента, который не определяет свой собственный Expires header, mod_expires можно использовать для точно настроить срок свежести, добавив max-age и Истекает .

Максимальный срок свежести также можно контролировать с помощью CacheMaxExpire .

Краткое руководство по условным запросам

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

Когда заголовок ETag существует в исходной кэшированной ответ, mod_cache добавит If-None-Соответствует заголовку запросу к исходному серверу. Когда заголовок Last-Modified существует в исходном кешированный ответ, mod_cache добавит If-Modified-Since заголовок запроса к источнику сервер. При выполнении любого из этих действий запрос условно .

Когда условный запрос получен исходным сервером, origin-сервер должен проверить, является ли ETag или Last-Modified параметр был изменен в соответствии с запросом. Если нет, то origin должен ответить кратким ответом «304 Not Modified». Этот сигналы кешу о том, что устаревшее содержимое еще свежо, должны быть используется для последующих запросов до нового времени жизни контента снова достигается.

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

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

Во-вторых, хорошо спроектированный исходный сервер будет спроектирован в таком способ, которым условные запросы будут значительно дешевле производим чем полный ответ. Для статических файлов обычно все задействован вызов stat () или аналогичный системный вызов, чтобы посмотрите, изменился ли файл по размеру или времени модификации.Таким образом, даже локальный контент может по-прежнему обслуживаться из кеша быстрее, если он не изменилось.

Серверы

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

Что можно кэшировать?

Полное определение того, какие ответы могут быть кэшированы по протоколу HTTP. кеш определяется в RFC2616, раздел 13.4 Кэшируемость ответа, и его можно резюмировать как следует:

  1. Кэширование должно быть включено для этого URL. См. Директивы CacheEnable и CacheDisable .
  2. Если ответ имеет код состояния HTTP, отличный от 200, 203, 300, 301 или 410 он также должен указывать заголовок «Expires» или «Cache-Control».
  3. Запрос должен быть запросом HTTP GET.
  4. Если ответ содержит заголовок «Авторизация:», он должен также содержат параметр s-maxage, must-revalidate или public в заголовке «Cache-Control:», иначе он не будет кэшироваться.
  5. Если URL-адрес включал строку запроса (например, из HTML-формы GET метод) он не будет кэшироваться, если в ответе не указан явное истечение срока действия путем включения заголовка "Expires:" или максимального возраста или директива s-maxage заголовка "Cache-Control:" согласно RFC2616 Разделы 13.9 и 13.2.1.
  6. Если ответ имеет статус 200 (ОК), ответ должен также включать по крайней мере один из Etag, Last-Modified или заголовки Expires или директивы max-age или s-maxage для заголовок "Cache-Control:", если только CacheIgnoreNoLastMod директива использовалась, чтобы требовать иначе.
  7. Если ответ включает параметр «private» в «Cache-Control:» заголовок, он не будет сохранен, если CacheStorePrivate был раньше требовали иначе.
  8. Аналогичным образом, если ответ включает в себя опцию «no-store» в Заголовок "Cache-Control:" не будет сохранен, если CacheStoreNoStore был используемый.
  9. Ответ не будет сохранен, если он включает заголовок "Vary:" содержащий совпадение "*".

Что не следует кэшировать?

Это должно быть на усмотрение клиента, создающего запрос, или источника сервер строит ответ, чтобы решить, действительно ли контент должен быть кэшируемым или нет, правильно установив Заголовок Cache-Control и mod_cache должен быть оставленным в покое, чтобы выполнить пожелания клиента или сервера в зависимости от ситуации.

Контент, чувствительный ко времени или изменяющийся в зависимости от сведения о запросе, не охваченные согласованием HTTP, не следует кэшировать. Этот контент должен объявить себя некэшируемым используя заголовок Cache-Control .

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

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

Переменное / согласованное содержимое

Когда исходный сервер предназначен для ответа с другим контентом на основе значения заголовков в запросе, например для обслуживания несколько языков в одном URL, механизм кеширования HTTP делает это можно кэшировать несколько вариантов одной и той же страницы по одному и тому же URL.

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

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

Варьировать: переговоры, accept-language, accept-charset

mod_cache будет обслуживать кэшированный контент только запрашивающие с заголовками accept-language и accept-charset совпадающие с исходным запросом.

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

Кэширование на диск

Модуль mod_cache полагается на определенное внутреннее хранилище реализации для управления кешем и для кэширования на диск mod_cache_disk предназначен для поддержки этого.

Обычно модуль настроен таким образом; 

 CacheRoot "/ var / cache / apache /" CacheEnable disk / CacheDirLevels 2 CacheDirLength 1

Важно отметить, что поскольку кэшированные файлы хранятся локально, операционная система Кэширование в памяти обычно применяется и к их доступу. Так хотя файлы хранятся на диске, если к ним часто обращаются вполне вероятно, что операционная система будет гарантировать, что они действительно служил по памяти.

Понимание кэш-хранилища

Для хранения элементов в кеше mod_cache_disk создает 22-символьный хэш запрашиваемого URL. Этот хеш включает имя хоста, протокол, порт, путь и любые аргументы CGI для URL-адреса, а также элементы, определенные заголовком Vary, чтобы гарантировать, что несколько URL-адреса не конфликтуют друг с другом.

Каждый символ может быть любым из 64-х различных символов, что означает что всего существует 64 ^ 22 возможных хэша.Например, URL-адрес может хешируется до xyTGxSMO2b68mBCykqkp1w . Этот хеш используется в качестве префикса для именования файлов, относящихся к этому URL-адресу в кеш, однако сначала он разбивается на каталоги в соответствии с CacheDirLevels и CacheDirLength директивы.

CacheDirLevels указывает, сколько уровней подкаталога должно быть, и CacheDirLength указывает, сколько символов должно быть в каждом каталоге.С участием в приведенном выше примере настроек хеш будет преобразован в префикс имени файла как / var / cache / apache / x / y / TGxSMO2b68mBCykqkp1w .

Общая цель этого метода - уменьшить количество подкаталоги или файлы, которые могут находиться в определенном каталоге, поскольку большинство файловых систем замедляются по мере увеличения этого числа. С участием установка "1" для CacheDirLength на любом уровне может быть не более 64 подкаталогов.При настройке 2 может быть 64 * 64 подкаталога и так далее. Если у вас нет веской причины не делать этого, используйте настройку "1" для CacheDirLength Рекомендовано.

Настройка CacheDirLevels зависит от того, сколько файлов вы планируете хранить в кеше. С настройкой "2", использованной в приведенном выше примере, большая Всего можно создать 4096 подкаталогов. С участием Кэшируется 1 миллион файлов, это примерно 245 кэшированных файлов. URL-адреса на каталог.

Каждый URL использует как минимум два файла в хранилище кешей. Обычно есть файл ".header", который включает метаинформацию о URL-адрес, например, когда истекает срок его действия, и файл ".data" который представляет собой дословную копию контента, который будет обслуживаться.

В случае согласования содержимого через заголовок "Vary", Каталог ".vary" будет создан для рассматриваемого URL. Этот в каталоге будет несколько файлов ".data", соответствующих иначе согласованный контент.

Обслуживание дискового кэша

Модуль mod_cache_disk не пытается регулировать объем дискового пространства, используемого кешем, хотя он изящно устранит любую ошибку диска и будет вести себя так, как если бы кеша никогда не было.

Вместо httpd предоставляется инструмент htcacheclean, который позволяет периодически чистить кеш. Определение того, как часто запускать htcacheclean и какой целевой размер использование кеша довольно сложно, и может потребоваться метод проб и ошибок, чтобы выбрать оптимальные значения.

htcacheclean имеет два режима операция. Его можно запускать как постоянный демон или периодически из cron. htcacheclean может занять до часа или больше для обработки очень больших (десятки гигабайт) кешей, и если вы запуская его из cron, рекомендуется определить, как долго run принимает, чтобы избежать одновременного запуска нескольких экземпляров.

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


Рисунок 1 : Типичный Последовательность роста / очистки кеша.

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

Кэширование в memcached

Использование модуля mod_cache_socache , mod_cache может кэшировать данные из различных реализаций (также известных как «поставщики»).С использованием mod_socache_memcache Модуль , например, можно указать, что memcached должен использоваться как механизм внутреннего хранилища.

Обычно модуль имеет такую ​​конфигурацию: 

 CacheEnable socache / CacheSocache memcache: memcd.example.com: 11211

Дополнительные сервера memcached могут быть указаны добавляя их в конец кэша памяти CacheSocache: строка через запятую: 

 CacheEnable socache / CacheSocache кэш памяти: mem1.example.com:11211,mem2.example.com:11212

Этот формат также используется с другими mod_cache_socache провайдеры. Например: 

 CacheEnable socache / CacheSocache shmcb: / путь / к / файлу данных (512000) 
 CacheEnable socache / База данных CacheSocache: / путь / к / файлу данных

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

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

Кэширование дескрипторов файлов

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

файл кэша

Самая простая форма кэширования в httpd - дескриптор файла. кеширование обеспечивается mod_file_cache . Вместо кеширования file-contents, этот кеш поддерживает таблицу дескрипторов открытых файлов. Файлы для кэширования таким образом указываются в файле конфигурации с помощью файл кэша директива.

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

 CacheFile /usr/local/apache2/htdocs/index.html

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

Хотя используется CacheFile не приводит к кэшированию содержимого файла как такового, это означает что если файл изменяется во время работы httpd, эти изменения будут не быть поднятым.Файл будет постоянно обслуживаться в том виде, в котором он был при запуске httpd.

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

Кэширование в памяти

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

Системная память не дешевая, байт за байтом она намного лучше дорогой тип хранилища, и важно убедиться, что он используется эффективно. Кэшируя файлы в памяти, вы уменьшаете количество память, доступная в системе.Как мы увидим, в случае эксплуатации системное кеширование, это не столько проблема, сколько при использовании Собственное кэширование в памяти httpd, важно убедиться, что вы не выделяйте кешу слишком много памяти. В противном случае система будет вынужден заменить память, что, вероятно, ухудшит производительность.

Кэширование операционной системы

Практически все современные операционные системы кэшируют файлы-данные в управляемой памяти. непосредственно ядром.Это мощная функция, и для большинства часть операционных систем понимает это правильно. Например, в Linux давайте посмотрим на разница во времени, необходимом для чтения файла в первый раз и второй раз; 

 colm @ coroebus: ~ тестовый файл $ time cat> / dev / null реальный 0m0.065s пользователь 0m0.000s sys 0m0.001s colm @ coroebus: ~ тестовый файл $ time cat> / dev / null реальный 0m0.003s пользователь 0m0.003s sys 0m0.000s

Даже для этого небольшого файла огромная разница в количестве времени, необходимого для чтения файла.Это потому, что ядро ​​кэшировало содержимое файла в памяти.

Убедившись, что в вашей системе есть "свободная" память, вы можете что все больше и больше файлового содержимого будет храниться в этом кеше. Этот может быть очень эффективным средством кэширования в памяти и не требует лишняя настройка httpd вообще.

Кроме того, поскольку операционная система знает, когда файлы удален или изменен, он может автоматически удалять содержимое файла из кешируйте при необходимости.Это большое преимущество перед httpd в памяти. кэширование, которое не знает, когда файл был изменен.

Несмотря на производительность и преимущества автоматической операционной системы кэширование есть некоторые обстоятельства, при которых кэширование в памяти может быть лучше выполняется httpd.

Кэширование MMapFile

mod_file_cache предоставляет MMapFile директива, которая позволяет httpd отображать содержимое статического файла в память по адресу время начала (с помощью системного вызова mmap).httpd будет использовать в памяти содержимое для всех последующих обращений к этому файлу. 

 MMapFile /usr/local/apache2/htdocs/index.html

Как и CacheFile директива, любая изменения в этих файлах не будут приняты httpd после того, как он началось.

MMapFile директива не отслеживает, сколько памяти она выделяет, поэтому вы должны убедиться, что не злоупотребляете директивой.Каждый ребенок httpd процесс будет копировать эту память, поэтому это критически важно чтобы гарантировать, что отображаемые файлы не настолько велики, чтобы вызвать система подкачки памяти.

Авторизация и контроль доступа

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

По мере обхода иерархии файловой системы для проверки потенциальных .htaccess файлов - очень дорогая операция, частичное поражение точки кеширования (для ускорения запросов), mod_cache не принимает решения о том, кэшируется ли субъект авторизован для обслуживания.Другими словами; если mod_cache кэшировал некоторый контент, он будет обслуживаться из кеша, пока срок хранения этого содержимого не истек.

Если, например, ваша конфигурация разрешает доступ к ресурсу по IP адрес, вы должны убедиться, что это содержимое не кэшируется. Ты можешь это сделать с помощью CacheDisable директива или mod_expires . Не отмечено флажком, mod_cache - очень похоже на обратный прокси - будет кешировать контент, когда он обслуживается, а затем обслуживает его любому клиенту на любом IP адрес.

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

Локальные эксплойты

Поскольку запросы к конечным пользователям могут обслуживаться из кеша, кеш сам по себе может стать целью для тех, кто хочет испортить или помешать содержание. Важно помнить, что кеш должен вообще раз будет доступен для записи пользователем, от имени которого запущен httpd.Это в разительный контраст с обычно рекомендуемой ситуацией поддержания все содержимое недоступно для записи пользователем Apache.

Если пользователь Apache скомпрометирован, например, из-за уязвимости в процесс CGI, возможно, что кэш может быть целевым. когда используя mod_cache_disk , относительно легко вставить или изменить кэшированный объект.

Это представляет несколько повышенный риск по сравнению с другими типы атак можно совершить как пользователь Apache.Если ты используя mod_cache_disk , вы должны иметь это в виду - убедитесь, что вы обновили httpd, когда будут объявлены обновления безопасности и запускать процессы CGI от имени пользователя, отличного от Apache, если возможно, с помощью suEXEC.

Отравление кэша

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

Например, если DNS-серверы, используемые вашей системой, запускают httpd уязвимы для отравления кеша DNS, злоумышленник может контролировать где httpd подключается при запросе контента с исходного сервера. Другой пример - так называемые атаки с использованием HTTP-запросов.

Этот документ не подходит для подробного обсуждения контрабанды HTTP-запросов (вместо этого попробуйте свою любимую поисковую систему) однако важно знать, что можно сделать серию запросов, и использовать уязвимость в источнике веб-сервер таким образом, что злоумышленник может полностью контролировать контент получено прокси.

Отказ в обслуживании / очистка кеша

Механизм Vary позволяет использовать несколько вариантов одного и того же URL-адреса. кешируются бок о бок. В зависимости от значений заголовка, предоставленных клиентом, кеш выберет правильный вариант для возврата клиенту. Этот механизм может стать проблемой, если попытаться изменить заголовок, который, как известно, содержит широкий диапазон возможных значений в нормальное использование, например заголовок User-Agent .В зависимости от от популярности конкретного веб-сайта тысячи или миллионы повторяющиеся записи в кеше могут быть созданы для одного и того же URL, переполнение из других записей в кеше.

В других случаях может потребоваться изменить URL-адрес определенного ресурс по каждому запросу, обычно путем добавления строки "cachebuster" в URL-адрес. Если этот контент объявлен кешируемым сервером для значительный срок свежести, эти записи могут вытеснить законные записи в кеше.Пока mod_cache обеспечивает CacheIgnoreURLSessionIdentifiers директиву, эту директиву следует использовать с осторожностью, чтобы гарантировать, что нижестоящие прокси или кеши браузера не подвергаются тому же отказу вопроса обслуживания.

.

Смотрите также