Сегодня мы рады объявить о Cache Response Rules. Это новый тип правил, который выполняется после ответа исходного сервера, но до того, как Cloudflare кэширует контент.
Если вы когда-нибудь раздражались, видя, как что-то, что должно легко покидать кэш, возвращается на исходный сервер из-за случайного Set-Cookie или неправильного Cache-Control — заголовков, которые иногда трудно или невозможно удалить или изменить на самом исходном сервере, — то Cache Response Rules и есть то исправление, применяемое в самый нужный момент.
Когда и как принимаются решения о кэшировании
Кэш CDN и исходный сервер работают в паре. Их цель — отвечать из кэша, когда это возможно, и обращаться к исходному серверу только тогда, когда периферия не может ответить. Каждый процент коэффициента попаданий в кэш зависит от правильного разделения обязанностей. Если мы проверяем кэш, когда не должны, мы тратим время на поиск, который всё равно не даст результата. Если проверяем слишком редко, исходный сервер обслуживает трафик, который должна была поглотить периферия, и выигрыш в производительности исчезает.
Важно, что исходный сервер управляет кэшем. Когда он возвращает кэшируемый ресурс, его заголовки ответа сообщают Cloudflare, как долго его можно отдавать, когда и как выполнять повторную проверку, и даже нужно ли его вообще кэшировать. Кэш эффективен ровно настолько, насколько позволяет исходный сервер. Если исходный сервер ошибается, кэш становится декорацией, а затраты на инфраструктуру исходного сервера взлетают до небес.
Большинство проблем с правом на кэширование решаются не во время запроса. Они проявляются после ответа исходного сервера.
Посетитель запрашивает /static/app.js. Cloudflare проверяет кэш, промах, и пересылает запрос на исходный сервер. Исходный сервер возвращает файл. Где-то в этих заголовках ответа, незаметно, находится заголовок Set-Cookie. Ресурс, который должен был кэшироваться в каждом центре обработки данных Cloudflare, теперь не подлежит кэшированию. Умножьте это на каждого посетителя на каждом сайте с таким же случайным заголовком — и вы получите коэффициент попаданий в кэш, который утекает пропускная способность исходного сервера, разрушает производительность и увеличивает затраты на инфраструктуру.
Существует длинный список вариаций этой же проблемы. Исходный сервер отправляет Cache-Control: no-cache для ресурсов, которые совершенно безопасно кэшировать на CDN. Исходный сервер отправляет правильные директивы, но они предназначены для браузера, а не для Cloudflare. Или исходный сервер добавляет ETag (идентификатор конкретной версии ресурса), который слишком агрессивен и вызывает повторную проверку при каждом условном запросе. Часто, особенно в больших командах, те, кто управляет ответами исходного сервера, и группа, управляющая CDN, разные. Это превращает изменение одной строки заголовка в недельные переговоры.
Ни одну из этих проблем невозможно решить во время запроса. К тому моменту, когда Cloudflare видит Set-Cookie на /app.js, фаза запроса уже завершена. Ответ уже в пути.
Поэтому мы поместили исправление в нужное место.
Cache Response Rules выполняются после того, как ответ исходного сервера поступает в Cloudflare, но до того, как он будет записан в кэш. С их помощью вы можете переписывать директивы Cache-Control, управлять тегами кэша и удалять заголовки, такие как Set-Cookie, ETag и Last-Modified, из ответа исходного сервера до того, как кэш Cloudflare увидит их. Исправление полностью находится на стороне Cloudflare. Никаких изменений кода исходного сервера не требуется.
Недостающий элемент
Если вы пользовались Cloudflare какое-то время, вы видели, как развивалась область управления кэшем. Несколько лет назад большая часть этого была внутри Page Rules, которые работали как единый, хоть и перегруженный, примитив, смешивающий кэширование с перенаправлениями, безопасностью и дюжиной других поведений, все оценивались на запросах. Позже мы разделили эти правила, чтобы только соответствующие изменения поведения оценивались на запросах, уменьшая ненужную задержку и позволяя сложное наложение правил между поведениями. Cache Rules стал выделенным, выразительным типом правил для решений по кэшированию, к которому присоединились CDN-Cache-Control, Origin Cache Control, custom cache keys и другие средства управления, которые дают вам точные способы сообщить Cloudflare, что безопасно кэшировать, как долго и при каких условиях.
Многие из этих средств управления имеют общую черту: они действуют на запрос.
Хотя это может показаться неинтуитивным, в этом есть смысл. Самые важные решения о кэшировании, которые Cloudflare должен принять, — это следует ли искать это в кэше и по какому ключу? На этот вопрос нужно ответить до того, как Cloudflare свяжется с исходным сервером. Если ответ «нет», когда должно быть «да», запрос уже заплатил за полный цикл общения с исходным сервером, и ответ ничего не может сделать, чтобы вернуть эту задержку. Правила времени запроса отвечают на этот вопрос, используя единственную информацию, доступную в этот момент: URL, расширение запрашиваемого файла, заголовки запроса, географию, тип устройства и так далее. Используя эти параметры запроса и правила, настроенные на изменение этих параметров, мы определяем, находится ли что-то вероятно в кэше, и ищем там, прежде чем обращаться к исходному серверу.
Но некоторые решения о кэшировании не могут быть приняты на основе запроса. Директивы Cache-Control исходного сервера (cache-control: max-age=3600) являются частью ответа, который Cloudflare получает от исходного сервера. Код состояния, ETag, временная метка Last-Modified, Set-Cookie и формат тега кэша, выбранный исходным сервером, — все это вещи в ответе, которые исходный сервер передает кэшу. Ничего из этого недоступно при выполнении правил времени запроса.
Ответы от исходного сервера являются источником истины, поэтому, если что-то нужно было изменить на Cloudflare, что не было доступно во время запроса, ранее у вас было три обходных пути:
- Изменить исходный сервер.
- Написать Worker, который повторно запрашивает и перезаписывает ответ.
- Смириться с худшим коэффициентом попаданий.
Каждый из этих вариантов требует времени инженеров, добавляет задержку или сжигает деньги. Cache Response Rules дают вам четвертый вариант: набор правил, где вы можете изменить ответ исходного сервера до того, как он попадет в кэш Cloudflare.
Две фазы, два вопроса
Самый простой способ думать о разнице между Cache Rules и новыми Cache Response Rules — это как о двух фазах, каждая отвечает на свой вопрос.
- Cache Rules выполняются в фазе запроса, до того, как Cloudflare свяжется с исходным сервером. Они отвечают: учитывая этот запрос, должен ли Cloudflare кэшировать ответ и по какому ключу кэша? Это три решения, которые могут быть приняты во время запроса с помощью Cache Rules: кэшировать ли (право на кэширование или обход), что представляет собой объект (ключ кэша и как идентифицировать сохраненный объект в будущем) и как кэшировать (TTL на периферии, TTL браузера, serve-stale и т.д.). Все эти вопросы должны быть решены до получения данных с исходного сервера, используя только то, что есть в запросе.
- Cache Response Rules выполняются в фазе ответа, после того, как исходный сервер ответил, но до того, как ответ будет записан в кэш Cloudflare. Cache Response Rules отвечают: теперь, когда исходный сервер ответил, следует ли нам скорректировать способ кэширования? Cache Response Rules могут переопределить как из запроса, удаляя заголовки, которые делают ответ непригодным для кэширования, изменяя директивы
cache-controlисходного сервера, которые сообщают Cloudflare, нужно ли кэшировать и как, или устанавливая теги кэша для очистки контента. Когда Cache Rule и Cache Response Rule конфликтуют друг с другом, Cache Response Rule имеет приоритет.
Фаза ответа не может делать всё, что может фаза запроса. Она не может изменить что, так как ключ уже зафиксирован. Однако она может изменить кэшировать ли и как Cloudflare кэширует, например, правило ответа может установить no-store, чтобы сделать кэшируемый объект некэшируемым, или удалить Set-Cookie, чтобы сделать некэшируемый контент пригодным для кэширования. Однако Cache Response Rules не могут сделать ранее непригодный запрос кэшируемым на фазе ответа, потому что уже слишком поздно.
Таким образом, Cache Response Rules не заменяют Cache Rules. Cache Rules решают кэшировать ли, что и как мы кэшируем на запросе. Cache Response Rules получают последнее слово по как и кэшировать ли, когда ответ исходного сервера увиден Cloudflare в фазе, которой раньше не существовало.
Что вы можете сделать
Cache Response Rules поддерживают три действия на данный момент.
- Удаление заголовков, нарушающих кэширование
Действие set_cache_settings удаляет такие элементы, как Set-Cookie, ETag или Last-Modified, из ответа источника до того, как Cloudflare оценивает его для кэширования:
Это исправление проблемы Set-Cookie-on-a-static-asset. Фреймворки источника часто прикрепляют сессионные cookie к каждому ответу (для балансировки нагрузки или других целей), включая ответы для ресурсов, которые пользователи не хотят ассоциировать с сессией. Удаление Set-Cookie на этапе ответа делает такие ресурсы снова кэшируемыми без необходимости изменять что-либо на источнике, балансировщике нагрузки или любом другом вышестоящем компоненте.
Правила ответов кэша также применяются к ответам, которые вообще не подходят для кэширования. Например, когда вы удаляете Set-Cookie из динамического ответа, правило срабатывает независимо от того, сохраняется ли объект когда-либо. Это позволяет контролировать, что видит клиент, даже если ответ не сохраняется в кэше. Вы также можете удалить ETag и Last-Modified, что полезно, когда эти заголовки неправильно настроены на источнике и вызывают "трэш". Это сопряжено с компромиссом: удаление как ETag, так и Last-Modified включает Smart Edge Revalidation для этого ответа. Если затем Правила ответов кэша добавят новые валидаторы, Cloudflare не включит Smart Edge Revalidation для условных запросов браузера.
Таким образом, удаление и изменение заголовков, даже в динамических запросах, — это мощный новый шаблон, которого ранее не существовало в Cloudflare, но при внесении этих изменений могут потребоваться дополнительные настройки, о которых стоит знать.
- Управление тегами кэша
set_cache_tags позволяет добавлять, удалять или устанавливать теги кэша, используемые для очистки по тегам в ответе. Теги могут быть статическими:
Или вычисляемыми из выражения в заголовке ответа:
Вторая форма особенно полезна при миграции CDN. Если ваш предыдущий CDN прикреплял суррогатные ключи к ответам с помощью заголовка, например Surrogate-Keys с разделителем-запятой, вы можете преобразовать их в формат Cache-Tag от Cloudflare непосредственно на этапе ответа.
Третий аргумент split() — это лимит: максимальное количество элементов результирующего массива может быть от 1 до 128. Используйте значение, комфортно превышающее реальное количество тегов на один ответ. Значение 1 вернёт весь заголовок как единый тег. Как только теги появляются в ответе, очистка по тегам начинает работать (и под "работает" мы подразумеваем обычно менее чем за 150 мс по всему миру).
- Изменение директив Cache-Control
set_cache_control — это действие, которое выполняет основную работу. Вы можете устанавливать или удалять отдельные директивы:
- Директивы длительности:
max-age,s-maxage,stale-if-error,stale-while-revalidate - Квалифицированные директивы:
private,no-cache(с необязательными квалификаторами имени заголовка) - Булевы директивы:
no-store,no-transform,must-revalidate,proxy-revalidate,must-understand,public,immutable
Для каждой директивы вы также можете установить cloudflare_only: true, что часто удивляет людей:
Когда cloudflare_only имеет значение true, директива влияет на то, как Cloudflare кэширует ответ, но значение Cache-Control, отправляемое браузеру ниже по цепочке, остаётся без изменений. Это версия на этапе ответа того, что CDN-Cache-Control даёт вам на источнике: кэшировать ресурс в Cloudflare на 24 часа, но сообщить браузеру что-то другое. Разница в том, что теперь вы делаете это через поверхность правил в панели управления Cloudflare, а не просите источник устанавливать отдельный заголовок.
Примеры, которые стоит позаимствовать
Ниже приведены несколько примеров, которые, как мы думаем, помогут вам оценить мощь Правил ответов кэша. Попробуйте их, переделывайте и делитесь с другими участниками сообщества, чтобы увидеть, как добиться мощных настроек кэша с помощью Правил кэша и Правил ответов кэша. Больше примеров можно найти в документации.
Удаление Set-Cookie для расширений статических ресурсов
Почему это работает: Самая частая причина «это должно кэшироваться, но не кэшируется» — это сессионное промежуточное ПО на источнике, которое прикрепляет Set-Cookie к каждому ответу. Удаление его для известных статических расширений превращает эти ответы в кэшируемые без каких-либо изменений на источнике.
Предостережение: Делайте это только для типов ресурсов, где cookie семантически не требуется. Если ваш источник использует cookie для управления вариантами поведения по этим URL (очень необычно, но возможно), удаляйте выборочно или ограничьте удаление этих заголовков по пути.
Долгое кэширование статических ресурсов в Cloudflare, короткое — в браузере
Почему это работает: Cloudflare хранит ресурс месяц и отдаёт его из кэша. Браузеры видят max-age=86400 и повторно проверяют через день. Вы разделяете два времени жизни кэша, не трогая источник.
Предостережение: immutable сообщает браузерам не выполнять повторную проверку даже при явном обновлении. Используйте его только с версионированными/хешированными именами файлов.
Переопределение no-cache для известного статического пути
Почему это работает: Стандартные настройки фреймворков иногда прикрепляют no-cache к каждому ответу. Если вы знаете, что /static/* безопасен для кэширования, вы можете удалить директиву и установить свой TTL (только для Cloudflare), не меняя то, что видит источник или любой нижестоящий кэш.
Предостережение: Будьте честны в том, что действительно статично. Если /static/ иногда используется для отдачи контента, зависящего от пользователя, сузьте совпадение (расширение, сигнал заголовка ответа, тип контента).
Преобразование тегов кэша при миграции CDN
Почему это работает: Многие проблемы миграции CDN возникают из-за того, что инструменты источника генерируют заголовки тегов кэша в формате другого вендора. Вместо того чтобы просить команду источника выпустить релиз, добавляющий Cache-Tag от Cloudflare, преобразуйте существующий заголовок на этапе ответа. Очистка по тегам в Cloudflare начинает работать немедленно.
Предостережение: Третий аргумент split() — это лимит (1–128) размера результирующего массива, а не что-то связанное с разделителем.
Как использовать Правила ответов кэша
Панель управления
- Перейдите в Cache > Cache Rules в панели управления Cloudflare.
- Выберите «Создать правило», затем Cache Response Rule.
- Выберите имя и выражение. Конструктор выражений отображает как поля запроса, так и поля ответа.
- Выберите действие: Modify cache-control directives, Modify cache tags или Strip headers.
- Для директив переключите Cloudflare only, если вы хотите применить изменение только к представлению ресурса в Cloudflare.
- Сохраните как черновик для итераций или разверните сразу.
API
Правила на этом этапе находятся по адресу:
Для получения дополнительной информации об использовании Правил ответов кэша, включая примеры для API и Terraform, обратитесь к документации.