Каким механизмом CDN определяет, как долго отдавать объект без обращения к исходному серверу?
CDN использует политики кэширования, прежде всего TTL и заголовки HTTP-кэша, чтобы определить срок свежести объекта. Пока объект считается свежим, CDN отдаёт его из своей точки присутствия без запроса к исходному серверу; после истечения срока объект проверяется или загружается заново.
CDN появились для уменьшения задержки и нагрузки на исходные серверы при раздаче популярных объектов: веб-страниц, изображений, видео и файлов. Кэширование позволяет обслуживать запрос из географически близкой точки, не передавая каждый запрос через центральную инфраструктуру.
Исходная проблема заключалась в компромиссе между скоростью и актуальностью данных. Чем дольше объект хранится в кэше, тем меньше нагрузка на origin, но тем выше вероятность, что пользователи увидят устаревшую версию.
Пусть приложение опубликовало новую версию файла, но CDN продолжает отдавать старую. Это не обязательно означает, что публикация не состоялась: старая копия может оставаться свежей с точки зрения политики кэширования.
Ошибочный выбор TTL приводит либо к устаревшим данным, либо к частым обращениям к origin. В первом случае пользователи видят старый контент, во втором снижаются преимущества CDN и возрастает нагрузка на исходную инфраструктуру.
При первом запросе CDN получает объект у origin и сохраняет его вместе с метаданными кэширования. Срок свежести может задаваться заголовками ответа, например Cache-Control или Expires, а также правилами самого CDN, если заголовки отсутствуют или переопределены.
Пока объект свежий, CDN возвращает его без обращения к origin. После истечения TTL CDN может выполнить повторную загрузку объекта или сначала проверить, изменился ли он, используя условный запрос и валидатор вроде ETag или даты изменения. Это уменьшает объём передаваемых данных, но всё равно требует обращения к origin.
TTL не является гарантией мгновенного удаления объекта из всех кэшей. Уже сохранённые копии могут находиться в разных точках присутствия, поэтому для срочного обновления применяют инвалидацию кэша или очистку по ключу. Такая операция обычно ускоряет распространение новой версии, но зависит от возможностей и правил конкретного CDN.
Для редко меняющихся файлов разумен длинный TTL. Для часто меняющихся данных используют короткий TTL, валидацию или версионирование URL, когда новая версия получает новый адрес; это позволяет не ждать истечения старого TTL, но требует обновления ссылок в клиентах и документации.
Кэширование безопасно только при корректном выборе ключа кэша. Если ответ зависит от заголовков, cookie, языка или параметров запроса, эти признаки должны учитываться правилами кэширования; иначе CDN может вернуть одному пользователю ответ, сформированный для другого.
После выпуска новой версии JavaScript-файла часть пользователей продолжала получать старый файл. Рассматривались три варианта: полностью отключить кэширование, резко сократить TTL или применять версионирование URL.
Отключение кэширования решало проблему актуальности, но увеличивало задержку и нагрузку на origin. Короткий TTL уменьшал окно устаревания, однако не исключал его полностью. Было выбрано версионирование URL для каждого релиза: новый HTML ссылался на новый адрес файла, поэтому CDN считал его отдельным объектом.
Для HTML оставили более короткий срок кэширования, чтобы ссылки на новые версии распространялись быстрее. В результате неизменяемые ресурсы эффективно кэшировались долго, а обновление приложения не зависело от ожидания истечения старого TTL.
Нет. Истечение TTL означает, что объект больше нельзя безусловно считать свежим. CDN может повторно обратиться к origin, выполнить условную проверку и сохранить тот же объект, если он не изменился. Кроме того, поведение после истечения зависит от настроек CDN и режима обслуживания устаревшего контента.
Новый URL создаёт новый ключ кэша, поэтому запрос не совпадает со старой копией. Это предсказуемо работает даже при большом числе точек присутствия и не требует ждать завершения очистки. Компромисс состоит в необходимости менять ссылки и контролировать публикацию связанных ресурсов.
Если персонализирующие признаки не участвуют в ключе кэша, CDN может считать ответы одинаковыми и вернуть ранее сохранённый ответ другому пользователю. Это создаёт не только функциональную ошибку, но и риск раскрытия данных. Персонализированные ответы обычно не кэшируют публично либо явно учитывают необходимые заголовки, cookie и параметры при формировании политики кэширования.