Руководство по кэшированию

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

Введение

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

Трехсостояниевое кэширование 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:

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

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

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

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

Запросы с заголовком "Authorization" (например, 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, определено в разделе 13.4 RFC2616, и может быть сведено к следующему:

1. Для этого URL необходимо включить кэширование. См. директивы CacheEnable и CacheDisable.
2. Если ответ имеет код HTTP-статуса, отличный от 200, 203, 300, 301 или 410, он также должен указывать заголовок «Expires» или «Cache-Control».
3. Запрос должен быть HTTP-GET запросом.
4. Если ответ содержит заголовок «Authorization:», он также должен содержать опцию «s-maxage», «must-revalidate» или «public» в заголовке «Cache-Control:», иначе он не будет кэшироваться.
5. Если URL содержит строку запроса (например, из метода GET формы HTML), она не будет кэшироваться, если ответ не указывает явное время истечения, включив заголовок «Expires:», или директивы max-age или s-maxage заголовка «Cache-Control:», в соответствии с RFC2616 разделами 13.9 и 13.2.1.
6. Если ответ имеет статус 200 (OK), ответ также должен содержать по крайней мере один из заголовков «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, чтобы указать, какие заголовки должны учитываться кэшем при определении, отличаются ли два варианта друг от друга.

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

Vary: negotiate,accept-language,accept-charset

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

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

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

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

Модуль mod_cache полагается на конкретные реализации хранилища back-end для управления кэшем, а для кэширования на диск предоставляется 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», для данного URL будет создан каталог «.vary». В этом каталоге будет несколько файлов «.data», соответствующих различным переговорным вариантам содержимого.

Поддержание Кэша на Диске

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

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

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

Также рекомендуется выбрать соответствующий уровень «nice» для htcacheclean, чтобы инструмент не вызывал чрезмерной дисковой активности во время работы сервера.

<img alt="" height="406" src="data:image/gif;base64,R0lGODlhWAKWAff/AAAAAAsLCxQUFBwcHB8gICUmJisrKyYnKDU1NTQ2OTo6Ojc4OR80TCg2SCc+WTE7Rz5AQj1DSzRBUSxGZTNPcEREREVGSE1NTU5SWFVVVV1dXUlPVklXaE9ecV1gZUxifWNjZGtra2dnaGltcW9wcHNzc39/f3d4eElnikxwmlNrh1BymU94qFF6q0x/vHl+g1uGuHiDkWuIrGWKtGaKtXWLpHCSuFiMyViU21mR1FqQz1ya42CX13mdxmOe43em32uk6GGl9Geo9maq+22r9mut+2On+W+w/HWs7Xuv7HSn5HOu83Cv+Xiv8H6x7Xaw9XOy+3uz9Hq1+364/IaGhoeIiIuLi4eHiISNl4+QkoaQnZOUlJ2dnZWXmoOUqJyeoYGPoIqhu5+goJaltaOjo66urqSnqq+wsLS0tLe4uru7vLa3uaOpsImpzoSs246z3pS13Jy31pm32Z6415263JW12pCt0YWx5YOz64y044q264y57YK29IC3+Ia59YO6/Iu784q+/Ii38JG345S55ZO765y95Jm+6ZK+85C/+IGv5q28zaW3zKS61KO926u90qm/2aK30La9xrO+yru/xLi/yLG/0KG/4Y7A/J/A55vB7ZfA75TB9pPD/JvE9ZnH/J3J/KbA3q/A1avB2rXBzb3AxLrCy7PB0rTG27vF0b7I1L3K2bbJ36PA46PE66nH6q3K7KnE46HG8qPJ9qPM/KvN9KjP/KzR/K7Q97XJ4bPN67jP6bjL4bHO8bzS7LfQ7rXS9LPV/LvV8rnX+7zZ/LvY+cPExMTGycbJy8jHx8rKysjIx8TL08rO0sPM1s7R1MjS3tDP0NPT09PW2tfY2tzc3MPW68rV4sva7MXU5sHX8MTa88Pd/Mvd88jf+dbc49Le7Nzf49Df8Mfg/c/h9szi/NXh79zg5dvj7NTj9NLm/Nbo/dvm897p9tzr/OPj5OTm6ebo6uzs7OTr8+Lu/Ovu8ejv+Obw/e3x9Oz0/PPz8/L3/PX5/fj49/7+/vj39yH5BAAAAAAALAAAAABYApYBAAj+AP0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXLmDNr3vqummd98eT5SyYNJujNqFMf7XcBQgYNybio8SeiikVp7zCq2aK6t2+f+iBs0aevn7Lctf0ZTxZPYDVj0uThVi6t3ztjyfRVs3Cimr93pPv++cMtTZn0ZKIJUjNG7buyfsmMyc+tT5n53/jzq9RXwUo8fbTxVls/XGhgoDzxZADCCdKEcMV4GVDzGgnSGGOABWe8o0EIF5TRTwYXhKCABiJccAJBa1QgQhf+dAGCPlaUIEIBavRjAggZUKHfjjxS1A9xQAJJkD4KQCACF/1oYAVtVryjwBnGIJDMOxaoASAZGfRjxgnvIFBGPcplwIU/YmigTBUX6HNBCfqckIE8ZKQ5kBUVVNeiBuLByKYxEKCxhga59SjooAgZZwUVVVChKBVkBOoPf02KpoGAVihTAAghgFDdFhWcIE81GhhDwntlWKCBd2L6U4UCJIjg6QX+ZPhjQgn+lCGnQPGcoACLXWggEBoX5NbFpSGU4CihyA6qzxYDCBBAAM4KUEEyA/HHokBKMlmNAsb8KBB8CsR6xQUZAGhdBSxmwFuv8vxTXAaxzlrrrY/qA+w7XGQAIbX+qKGAMsSJl+zAPcIYAAAIJ8xttRWMia2AtnVhIoPvlBBCBcb0GwAV1pGgKxqyVrDGOwqecIU88MpKq60C+0OGCDDrw24GCigqjT5UZGACFd4R7HN+BiescMbfGuOoMt5J055xaFipjxpolOaPMgosbQwayYgXzxqlvQP1e1OO1zW/Ar2zBhq5VQOwGmWggfajxpRhDIA/191b0EIDsHD+RmSAYPffgGOEt9B7Y5SMMm61rJPiHTGOk+MbQW6T5BlRTpPlF2F+Uz9WHJy3AmQHLvroKA2esAFkSKP66qorw/rqrrMeO+yvz97667jnrvvut8te++++B0+78L0Pz/vxuUdDu/K9214e8MYXT/zz0zvvPPLY52499NJTH7333W+f/fjMP19+7OJ/n3713IPv/vjwu7++/O3PP3/8+KPvO90TmZ6wAANoVgABGEABFvCABCxgAgd4QAMyEIAEFAAEDShBAUYwggx0YAYV2MAFavCDHgxhB0doQQpO8IIl/GADVwhCEnLwhSsUIQJdWEIUTrBZJxwgBilIwxbO8If+MNygEH2YQxymsII39CALeyjDICpxiE0UYhGRaMIjTtGHQcQiFJnIxRrq0IpgTOISm1UAARSACvyLiP/yxsY2uvGNcIyjHOdIxzra8Y54zKMe98jHPvrxj4AMpCAHSchCGvKQeaSXGjvHxgCoqAQmiCQVIrkzSlpSUZaUJCUxmclJatKTlZwkKEVZyU/uDJSa7OQmUZnKU2aylK5UpSRZCUtOtpKUowzlJmFpyRjscpavHCUtcxnMYa4ymLvMJSlNqUxd/vKSx5RlLKEJTGna8pnXbKY2k/lKE/jylsasJjV5Gc1xXvOWtXSmLrf5yXBOE5vuPGct44lKdq6Tm83+BCclqyC1/jEybwMAGekGStCQwEgAbBRAGQrK0IZmZI0ImI1DJ0rRh6yxcBXNqEaH9E/CEW2jIM3oRT8a0pI2dKQmTenmCINSlbp0dC19qUztdlA2YnSmOE1WTHPKU2V1dGg9DaqgdirUovqGqEZN6maQqtSF8IMf+cgHPdzhDnrkgx+Q4cc+8nGPe6zDHffIx2S0uo+ufnUfJqnp50ja1IJgdSBbdYc6iBEMWnSCE7Pgxj3euhiterUcwbDFJzoxi3LcA619FQhU1zHXW9gVFOVI608RdtOmYrWsfy0HMeh6C1B0AhNTQAIMYEAIYqwDsYTBrDrKMY7NdrYTgfj+gxJaQINNmBa1qeWqO9ahWbrawrOYkIIUpkAMyXrOo0p96j6Wq9u5BvYToIVCEaRL3RxMwAE5wMQt1uEXsjL3r3S16x+kIN0jHIEIRLiBAyjggz/cwh1/wap3zdrazoJWCtMtgn6LQIQoEAO3BrUCQtdq1K3eY7Wc9exnAzEFKRDhCEMYQhGk0AdA7KEHD2iADoqAif/ypay8TfBg7yvdCE93Cn7Ygw0a4AAcQKHDV+ULVA9c399+9g8NLrF+pcAHQBSCEK1IB19FwlSTQpWr99itZp973yIMwbxQIAIUnkBlPNyBEIdoxSjG8AAG3GAIUKBFOcQaF+UimR6Mra/+Z8dbBChLmcpRcAIesKxlLyRAAjiYLmTJPJfvJjnEdYXuFNrcZihEmcpOiMIeCJGJUIziFKtoTkmKDNLFLlmw9yWvdNtshOn2+MeZmMMjFjGJRZiiFMcQQwUaYIMnCGEKt7hHmUGs5s/m+AhtjjCYP30IOjTiEZOQhCRKUYouIEACPWiCEKRAC3cM2S1QpcelQYEJBpP3wbo+ghRSTAhDOOLXwZbEqUsxJc09dLJ6Y2tFo53m1gbDvuMtb6GhEIUoWDkP3Q4FJERBilIYw9/YsQ8aKvCAGtyBCBwmBp/PgmTG9taxtiZvm49gaHtbWQ+DaPQjRDFu+RhDGdEgwwL+JBCGgxfhD8SAr1oM7HB3vzYQ5MU1xadc7zvcIQ+G0LIoTlEKNQD8cK6jhjzMLTh0V3agyl3uPeihjnEE9rOanu6DEU5vPwCi/63Yd7ArQWxUe9w+SgsHeC6gAC7QwQlCgEInxgFgrjzVzEnWLMRzHGWpo5fegtjDITLhiEcIu+sex040njGNarxj4BZggyPwgN4Ot90ry90qV9dRX+gKFwoU5y+uicCHT2tC34uQRL+JfQyPH04ahn+HPPBB9KIfF6gMjSpvnQ7xiJdYwlBA8dUJQYdvN4LUou+5fJLxDNWlPh6qrwdxpIEBCJQhFYNwtRS2+/irRBvB7wYuJv7+YGgIT1e43DaErzd+iuD/W/BKS33yiWOMClwgDaaIwxP0XI7qW3+raX43LUaMY8ybGArbZmG8NweiJgqTMHr+djjF5xnvsH4B03quZ1Pq9jNmNnlLJl74BWGbJ2VL8ASKBmSjwG/EFnjJAHRBJ3byoHwHISEi8wyLcHBD0GGyhhV+1nTEcAuCpl8Spl/oRWVPkHc5BwmnYAo+R4KHozzU0IDyQBwGsQwVkAHIIA2ikAdE8Grb9WxUoVVRlWTOZVfB5WSE1oNE4IF6wGihwG+nZnrYcYSo9w6hURwQ6BGUNjD7EGLwNgVTIG9DIGVT4GM593ukRgqm0HHoJw3noIT+QQKHkFMNIJIM56AKceAE04UJ44CFTPFWWsV04fUJDJZjOvh9FXYIhiBqjLAIplYKaRhw0UANqbeEQ4cPcHgQymAq0/AOzPAIbyAEQ0Bce2UV+AdYrzUF/VdeuLdtnHAIBGiKpLCMgBdwSIOCKfiAcQgSc8gjM7YOlHeD1JaHhFZx9XZvhhAKjnAKkzCCzhgNSHh8S5hGDCEhGWAe03AKcLAEYHaFTzFjTLdkazYFCMdfNGdvNgcH4YgKk3BqajB89hF01QCNsdgQyWAq1fAp8ecEUvYJbBcVULVbNmhfnjhdU+aBVrYHQXgKCCgfCak6rKiESziNkjVgyIUs/fD+VFLldLQQXfvFg39gdXsXCsA2bF3nbwnoOoYHD+vIDyzpHCCiDPwQD8/wCAd3BIEQDAtXFJhoaXUVXbi2X0yQe39QCFm2ccH3k1+Heoa3jv8Qk/0Qhw8JKP4gHfKIBNP1CfRgiUMhX/4weTcIW1G3X0QgBX+wB4XQCmcYemrgk+aYDEj4DkQZi2m5E9WoGtdYX/vHYFAgYWMYBXqgB3AwB44ACZDAjKZHGsbXiut4lAUhIRdQGvrwDqrgCEmAXp2gDlMpFPzwV7RnVzAHBUIAZVHgB3cwCHTAmUIoiCMIdOmnfktYD+JhmlNjKvTxDk1JhUUwBcHAXUdxfe72W03+tl9SoGiaKQe+9pmj93XKQA2siJzK15g/8ZiYQVb0VVedMGh8yQRLEAWCcAiX8JmmQAkAZwzHUIKxg4jFMRDMaRDuiDj9IA/TYApyQI/Tpw5AUYFe1ViciF/6VXdwVgjhyHHNWILGmYTJp57qiRGzqAHnIBD48A7H0AiSeAQwRpc5UYOtZVd5aF4URwRLgHeEcAmhQJzndwz/eXrSwJAFGhNq9ZK/sQ/uoFleOF4WuodSYGGG0AiAaAqVQAnDh5INGA/KJ40iwYgXEA3fEg/S8Ah5sATTeQsx1hNcJXeCdmtDkHZRugmjWIoHOGwImX5K2KUN+RHKUAGnMhCfogr+c4B2ajdmP7FYTmcLsNVgUmBeuDcFgOlrpShuwocdKGl4b+ilScGekbFVaNZYNfmoGthfT+AEZahlp1AJB6mKerqpRRoRYCqmAqEP58AMjXAH+tUJiIoTBiZXN0ijxFgEcIYHqToKPuqMxneI75CeKJEMF8CWAvEPZEoKb/AEQyAFtrAOMAoTfqVk7wZ1GthmiKYHedBoIjh8CqinqqcPZxkVntoYMukO2hhdhsZfUiYIhZAJvxdshCiU7fojjRmrEoGatKoc+FANpgAH0kcL6tCtKnFZ+UB5jmWvm3aZe6AJdDBqltqfpNGK0kiwELGWx7KayICLRLCLwdCLNPH+dgeWl7lZd1LWm4SgCY5giqUwnvKRmPKwemm5nCKLEUFbq0Y3gZ8KXnMXcxUnCHcAB3LQd6v6c8YnoCPqEgZbEPEwDZBwptO5shBrEpl4gfF5rwAYBXeAcXBAB1p3qcpQfCBKlMo5tBOxlj1TLdVAqBR5BJ2gcDMBYsC4jfglZTxmrsDZd6fob2BnnltKHP+gFfFaGFroVXnJjfgKBXwAmK3AsSNYeojZhqv3rnJrEbNaEKupDCwqBEWwt/ZHEjIpVYBFbWQ7ZZ/GdyJIekAKcp5LHEZJEyVat9+CD9JACnBAkVDwCdzqEu5JsWObX1WZaK3gCAfoc6YQpAH6DgH+oxxd8biCoaj2BXMTN52T2ggGyIyIKw21GBorGbpC6w/UoAFhWhA/orBy4ARgBgoPuxJQ1Vi2hnnnBQWCwHuAuIxF2LmauoT48K43UaLH8i3wMA2L8AYPBmvHuxJKClgYWJkU94EFWJA++XF62rMPGBba2xffKndj+2RRFmdzdoamEJqiiYhfKxOjC79MKQoQfATUybIk8auaZQtfaF5j+ARXdoakQIK4C6Jx2xN/Kq0EwQ+rmQyPwHhEgAlSGcMagVmUFwygEAj+N12nWobQe5hgl7vqexQjfBfyhX95GW8XKwX/u7GHW76aCiRVyxMzTMPKUKi7CWMi8VR3uQ7+ayxxF3q5vmZqpHCQp5eEb/iz2NsT0BqoB1EPChsHeJB2azebHuFXc7WN3XdeUXB1N7sIh7mKZRm3P2vFWXHGdVGbG8nJmxcFfPAGwCm+xZmYbriSRXG1B6EdqXB2FGe8q1sRllavNeppeJAHaWuALZzIZbmSqFwTdFson5IKDDth9vvMEFGbWXwLsFVeM3tzctAIBRmU1QCiKVjHaXGksDcYygXI3JyBuCYEy3afobAIJenBDXi9SI99NDwNk3DD1DnBV1xW6qDFxdxm/SUIU1qO5ug6+bycSEGyCdEP8aAMZopwUuC/HCGT7twJGahfQvAEfLCvj6Cznduu31L+xk+hynCxD/qbmwjdB/8rB5Fgz6N3OCm5yCqdEqjZTwahD/Bg0SbHxxmxD9J2lQ1mXhM20+CWhh97y0msFEvsu/C7ms7AoghHxZhMERPrdHoZhpcLB3GwcV13DOWpqem50/BatIEBYjB7sSBJCKEwhMQGoKrjhgP6FLqMEAm7CnoMBfYbzE5F0MRAbYF7mUPsd8UJsLjsFAq8EJJsCnXgBBQXm1v9EFxFD+PAzYEAZTQnkkLIda6az42LFyy9FvkAWFg5YX2waDcrbC2MuEkIwowMFXt9EPygoNY6f1NgCyo3EbU5DrQA07mnr3DM0CZZlvoMFY+tEAk6DcLralD+YAv3SxF1SAydMF4PBgWtPYqkxqpY+tTpi81pwTmvR1lGSxdataSFjQkT9wRzRgc8WY7KWsDsGBVg6tO4/Q7O4JRZTQwz+BCLRVfxCWH0BsaQgNxtS8ZVAa0ZsMAHgQ9BnasPFgixhs1GPVc16X9P4Ad54GuigKeJK3bKSd5scdplAWLB0An3iqN8QAh+x59fB6LXq9Yzwc8IIQ+3Golp9wn11xDKRQ/EYAt5GGVjuAd0sAii7Z+uI3aKeBUSzRDaoQqNUMkcNg6X7VYDvrzTFQWEAAlK/nPPMNtP/hcoLhYTSww1KZ/0dgfhrOQfV3xb6qxb0b7vyxDyQA3UvAT+2kYL9BDM+RsM0MW/RCAIgyBq/ebBitzYWRHlCGg1SC8UdDj5fC1SrrGm4aZ4fwIlYB+e5rXgnHmXpGR5XALmFCZ/AXfhvAIaWgfym3jO9HTDbGaTXlwQiCDCOFXgEwLU3AEqPvFdCAKCag81QAPoM4VvesQ1vEM8rgEaRcMzpbr+SBXwRBccVoESzBn4mySDv0fiSHqWzHgWyxxnLcHokbf5YnXuhsWt60Qq4m3Uqa6BlFWgLW8Q/CDg1DT/ebq1rvcXfHIEJ4QKYqrd4CmVBzgA5GRah5cma4HcjBqXNftZX4Y4E6DL+vDUiBhS+AEbq7YL+ztZdHuCqGgqdD+oH0+l4o17YD1CYN2XkJ86KL8cdFgeFEdFo7OEPFrCnNQyS+G5XAludzc68TK8asuyqeH17B+FuqM3nCxWILOffgaBYXwe6dm1rXo72Mh6w4BGrWOulG5V/Ru6t0X0ovWCMRJGg9tFo9M1Y8eD9RACnJAdbdQf1q161BfBEKgaHMQerIdsI28GBU/FXVY6mNrXk+gB2/wa53+sYucFlrvECnqDDu/x8QAWIxKuVGQB3Ww97J9iMqJFtEMEfggD8z+Bmj6B7QwDq976k4mBXP28OVIGrONzoDP1mtR99jd8vylaI6Apx+XhMeOFo8P5CQf90/WCZx4sUug0I8gtSj+rRY37xD/UA24inbZOljySaxP8OExX4K4wYSTgVIQPbDfohwQbf7YKzDjz8jjn/7l3/7wD//vj/7nH//uX//p/w9pDgr8iPeHDwcAwWiRJDXHpL17V09fv37+Gj50CDGiQ4oUIV60mPGhRIwdO1bcCBKjRof//JlE6a+itAwXlEW8+JFfP3nRFrlBYoSIlCJCmDgZ1GhRGjXGlFF7J68ew4waG07kaPHjU49UVcYESZJhSKlZp3aFmMyChmpXmWqVKq+aKTtJiAyBUkQukT1wIg0sKq1aPHn69KlEO3VkTKaDA0OVavXrWaxRvyJufBXwZMqVLeuzEgDAZs4FTnD+AQ2aTGjSo0mLJi3mNBfTXFSHfr2atWvZrWWXvm07NujdotkscjWr0xIgOG7QkFEDyxUqJpxTsdIFtmwxsVX3vl1b+2rsoW2jPv0dPHfa009Xp4IAgYnZ4suT3kIlRg0aN3DgyHFjRnIs8k2cMMGKLaTLzrvwUlutte52c89A8qazrTX3etutOxMMUKAK0RrkjbQurJBPhht0uE8HGGioIYb+/jMBOgILdDBBBHEz77wZY9zQxgJNu+693H6UETY15LGsSCMx04wzzgYooEknn4QySimnpLLKJw+wMkstozwAywdQ0IEIIna4oQUVOOAAAwwugACBLd+EM04555T+c4AAAmBSTgMW2KADFFpoYYUP0mzJAgXcpDNRRRdl9Ek7A9ASSykRsIADFVZogQUUOlAzgwwqQABLAholtVRJS53zgBCoMbJVypBUcrMCRKii1itqxdXWXHfltVdff62COWB3vRXYYmul4thhqXhBhRRgwEGIJX4IwwsvrBAwtC2sYI4KKoYFN1xcv81VWXHJ3dVbXM31lV1xS3CTBHGR/TaLLLrIQgsvatACiyqiI0OMD5GlF11eDebV3XkPLnfhXhV2GNcQCkCghHEXxnYLe/f1ot9sQRs4YmGNjVhkhEsO9+QrzGXXijLicTVmf2CNVQE1/MI5Z5135rlnn3/+BjpooXPGBx+ci8YnHWE4WSIIIpDIgxGCjDlGmaSGxjprrbfmumt9lGkpma7lCUcZNdBYgxKjDurLa7ffhjtuv4ypIANpvK7nHWmMWQONNIwx5pm95Ca8cMPh/ucpmY+0QoBYAVDAmMUnp7xyyy/3hx93gsGEJyKcgGORUozRK56lFMc8ddVXZ92yalp6CXN84KlGmqOu/qt13XfnPWaxQHhH9X/ytl2vq03qPXnll2d+MpqVjLx56ZO/R51bApGLCTzimKQUZaZJCvXpxye/yNcziP1yhuRBKJ7cy4c/fmXGKmt1feJ5hy/x4+e//+Wf50z0/DfAIt2DGJ/w3BP+ojaJYzzjHQvZHwEl2DpqtEQarNvKBDWou/lpIHirm8lWIrhBEpYQMADcjABNGL98qINzcSECHuTwCO9VAx4LWWEOK/e6C0RDh6kb4Q8tIxYPCtGIR6QcCiEnOSQujx8tBIUUjiAEIuhhDqSoIQ6buEWVVLCHXARj6jpYvzCWUYhKVKEZVbcPdxCjEzwpAugiYQrSPfAsavyhF32IRz4WqYMf7GMgCYgZx9WMiYKc3BPL8cIixFAOolPGXpCHyBXycI+U7OMfMblJ8qHxkJw00j3GQYspyOUJd4iEJAIXjqWUL4igBIwXLwhLMxIRkLTEZes8mUvK8GMdwXhjI0H+R8NkIEWLvCSgHpHJxfll4JbLhObi+pGZx6URl/zYxzpuMQUoCKEIMhRdMfsSzWS25JLk/KEm0blOI00zSdD7JC35YUBQcPMICowEA9n2SnYyj4ez7OcKxxhQfiJzl7nMxzrcGJclgA6S4HtfQOFHDQ18UaImtOVFJXpQ3RW0f/kYZSmLcMo4SMJ755DHJDW6Oo/6w5IrJaE6YYpOjoIyH+Ug5RSdkIdGmMIgSZnpRC0Y1AkqowJkISo5a4pJRZKSik6oQzipIQ98tDSpq1PmVf2XjAsUUasGpaYhYZkPYoCCD09wwhvisAiDVGOcX5XeS+Eav4zOFZdLReQ+1NH+CSh8Dg6MKEUypHGOiNpVeVk17PgGOj2rJpZ3eA0kP3AqBSIoIao1dF9jHUs5WW52ess46jM9G0hCVjOegWTjLf5wBCS4AbDKQKlmR7u4zs52ecvoKhlt20fIqo4fEvRlMKYwBCHcgYbSuKFsd+uq2i6Xd3V1Lh57a8YnEgMTfXXCFQ9S2Ohi1VPp6y7rjOrV8JaxtGJFpAE7McUmyIEUyoiHcl0lX5jK1bH0ldliyxvG4Ybxpnwdwk4X4UDu7hdz9jUw5sYr2gRbBr+96y8XW0iLbj7hDY+wWisbrDrEbrhyRNSth88YVngK0h0UvucdGHGMc9Tjog/2pzlFbDn+mR4RxleNMBKDW0oi3GEOyJjqjRuM4AY3tsYz1mGOjThPzhWhoXMoBfiEPGQZI3ly+rVyDpUsRANiQi5OcO92syxNynR4zEaC7plLuGUdgpSvRHgCHEhBYDVbjsh1psyR8SxBNq/wphR2clSZ8cA9U44lFwBooScz3hArGjBTltl5S1zGbDp1CTyNJJEcLbNqVPScm+YqeTftvz6TMLhSGEKPG3EMt0Law80ddTJCO+pBkjiApz0ik7EXwziYYhrxUCmti2Tm/rk6k/QTNqltnUJcC3Ge1iVudkkhDWAnm7lVprWerc3YZS8RjPsYx3WFkAQ5PwMewd52mYcq7FD+NzrdzSu1BP/ckyXAAcOENbaI76xoWSP13Z3stjWFmE0EjjQPi7Capv9tGWI3L98xezjztL3w5MXbf77cZiONy+pjUnwy/0z2xKEZ8S1anH/7oIdqG4mHnv4a3ZQjOVz3XWijOtPj0jN5/Lp8hAA3YtrVvnllZr7nNAcdwo0z7ZLJ2omegG7a74i5iBtO87Ew2Oi6DHizSfjfCsPhFFYrsNFh/eKiIvvqFc/6wMvxibhADeH4Pru6ER3yWce9VZrN+fSyeQtUL2HjbrW73BMNarMHHuvvvLUONZfxU/YU8IaP5bqzXXXIHz7pOQSpl4WAhzmYgtr4qHwXJT9qLIf+/nJ5Zx4/1EELykK1FMY0vUu/G3LKj5yoqFfePIvRBySQ++uEjv3UiV772J8e6egtIUg9gYQf2GESzXgH6IsvfDyXvviTw33y3HELPiihDSuuhj5+O31sk77u169c9nmnekwswfuSkIY8oq5milqU1qG2Ovpbpf7dkVUKQkCCOWiG+Jo/hyMq6qOMApSofnM3/du/tDM1beoJPhiFcAi7ykNANRM5B7wMCNygpXMyQsgGoFOzmMtA21IuRuNA7Du+SZscksuHKBICJ4CEb7jAxFLAHfK0ZMMtUVvBB0Q8ZiOhbNK8O1gFeMjBMxs7Rys6D0tCFgxCb9sgA5oCIXj+gkyYBulzwBMcM+v7QQfzQOBau766g1y4oRXkwixbsC+EuDAkoH0ghlJ6AjrIBvkLqidsnqGrPuJjwyLhP9+6h1voJidAhWrAwzHTwzoDsT4EwsuTt3JgOiLIA2eIrx9MQyvbwD78w9QJxD+YwVb4Bhf7QZATNhXUoEPUqE28HMmKxDzIBff5wkRUM/xjRMaJQoE7OWJANSIIBWi4wdiTxTNrwlpUCVWsHF+yhUFkhXNAxTG7RCQzRWJ8FTfkn6V7GkK4BphhwyVUtExkQ0lLPAK6B0CjQXTQQkscPVDLLWmsDGOcHL0KBCrKg1Woh5fTP24stEVkR+ehRvihwiH+eIJLmIZfJL+5Yzc+3Ed3lBnJAoW+woNcICxGxMc9i8Z9dIh+JB84/AMnk4M6rMXzAa9NU4auyj9GVMiYyYdkNIIkeIRvsMevakbvsr9RAy0fZMeTbJWE6gR5PMKYVMLyU0ebs8hixMjp2RxPTAJDCEViDEaIC69hJEacNJJyuC4meANeODfn8klD20GYpCuEvMmiZJ5+4AddBMhGgIaqYkqgdLSKTEixdCJ6oLDNQ4VzeEkObEo1

Рисунок 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:/path/to/datafile

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

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

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

mod_socache_dbm

Кэш общих объектов на основе DBM.

mod_socache_dc

Кэш общих объектов на основе Distcache.

mod_socache_memcache

Кэш общих объектов на основе Memcache.

mod_socache_shmcb

Кэш общих объектов на основе общей памяти.

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

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

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

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

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

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

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

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

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

CacheFile

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

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

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

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

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

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

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

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

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

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

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

colm@coroebus:~$ time cat testfile > /dev/null
real    0m0.065s
user    0m0.000s
sys     0m0.001s
colm@coroebus:~$ time cat testfile > /dev/null
real    0m0.003s
user    0m0.003s
sys     0m0.000s

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

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

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

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

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

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

Отказ в обслуживании/вывод из строя кэша

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

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