Apache: Кэширование контента

RU EN

Пункт 11. Кэширование контента

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

Введение

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

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

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

Кэширование HTTP RFC2616 с тремя состояниями

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

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

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

Свежий

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

Несвежий

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

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

Несуществующий

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

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

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

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

Фаза быстрого обработчика

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

В этом сценарии кэш ведет себя так, как будто он «прикручен» к передней части сервера.

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

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

Нормальная фаза обработчика

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

В этом случае кэш ведет себя так, как будто он «прикручен» к задней части сервера.

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

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

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

Улучшение попадания в кэш

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

Свежесть

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Переменный/согласованный контент

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

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

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

Vary: negotiate,accept-language,accept-charset

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

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

Примеры настройки кэша

Связанные модули	Связанные директивы
`mod_cache` `mod_cache_disk` `mod_cache_socache` `mod_socache_memcache`	`CacheEnable` `CacheRoot` `CacheDirLevels` `CacheDirLength` `CacheSocache`

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

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

Обычно модуль настраивается следующим образом;

 CacheRoot "/var/cache/apache/"
КэшВключить диск /
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 подкаталога и так далее. CacheDirLength Если у вас нет веских причин не делать этого, рекомендуется использовать значение «1» .

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

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

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

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

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

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

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

Также рекомендуется выбрать соответствующий «хороший» уровень для 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 memcache: через запятую:

 CacheEnable socache /
CacheSocache memcache:mem1.example.com:11211,mem2.example.com:11212

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

 CacheEnable socache /
CacheSocache shmcb:/path/to/datafile(512000)

 CacheEnable socache /
CacheSocache dbm:/путь/к/файлу данных

Общее кэширование объектов с общим ключом и значением с двумя состояниями

Связанные модули	Связанные директивы
`mod_authn_socache` `mod_socache_dbm` `mod_socache_dc` `mod_socache_memcache` `mod_socache_shmcb` `mod_ssl`	`AuthnCacheSOCache` `SSLSessionCache` `SSLStaplingCache`

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

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

mod_socache_dbm: Кэш общих объектов на основе DBM.
mod_socache_dc: Кэш общих объектов на основе Distcache.
mod_socache_memcache: Кэш общих объектов на основе Memcache.
mod_socache_shmcb: Кэш общих объектов на основе общей памяти.

Кэширование учетных данных аутентификации

Модуль mod_authn_socache позволяет кэшировать результат аутентификации, разгружая серверы аутентификации.

Кэширование сеансов SSL

Модуль mod_ssl использует socache интерфейс для предоставления кэша сеанса и кэша сшивания.

Специализированное кэширование файлов

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

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

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

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

КэшФайл

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

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

 Кэш-файл /usr/local/apache2/htdocs/index.html

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

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

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

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

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

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

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

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

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

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

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

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

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

Кэширование MMap-файлов

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

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

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

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

Вопросы безопасности

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

Использование mod_cache в состоянии по умолчанию, где CacheQuickHandler установлено значение, On очень похоже на кеширующий обратный прокси-сервер, прикрепленный к передней части сервера. Запросы будут обслуживаться модулем кэширования, если только он не решит, что исходный сервер должен запрашиваться так же, как и внешний кеш, и это радикально меняет модель безопасности 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-запросов (вместо этого попробуйте свою любимую поисковую систему), однако важно знать, что можно сделать серию запросов и использовать уязвимость на исходный веб-сервер, чтобы злоумышленник мог полностью контролировать содержимое, полученное прокси-сервером.

Отказ в обслуживании / Cachebusting

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

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