При принятии решения, следует ли и в течение какого времени кэшировать объект, CloudFront использует следующую логику:
Проверьте наличие любого Cache-Control заголовка ответа со следующими значениями:
no-cacheno-storeprivate
Если что-то из этого встречается, остановите и установите TTL объекта & sup1; до настроенного значения Минимальный TTL . Ненулевое значение означает, что CloudFront будет кэшировать объекты, которые иначе не были бы кэшированы.
В противном случае найдите директиву источника о том, как долго объект может быть кэширован. Для того, чтобы найти один из следующих заголовков ответа:
Cache-Control: s-maxage=xCache-Control: max-age=xExpires
Остановитесь на первом значении, найденном при использовании этого порядка, затем перейдите к следующему шагу.
Если значение не найдено, используйте TTL по умолчанию . Стоп.
В противном случае, используя значение, обнаруженное на предыдущем шаге:
- Если меньше чем Минимальный TTL , тогда установите TTL объекта на Минимальный TTL; в противном случае,
- Если больше Maximum TTL , тогда установите TTL объекта на Maximum TTL; в противном случае,
- Используйте значение, найденное на предыдущем шаге, в качестве TTL объекта.
См. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html.
Важно отметить, что TTL определяет, как долго CloudFront будет разрешено для кэширования ответа. Он не указывает, как долго CloudFront требуется для кэширования ответа. CloudFront может извлекать объекты из кэша до истечения TTL, если к объекту редко обращаются.
Белый список некоторые (но не все) заголовки для пересылки на источник не изменяют ни одну из вышеуказанных логических схем.
Изменяется то, как объекты оцениваются, чтобы определить, доступен ли кэшированный ответ.
Например, если вы перенаправляете заголовок Origin в источник, то каждое уникальное значение для заголовка Origin создает отдельную запись в кэше. Два идентичных запроса, за исключением заголовка Origin, считаются различными объектами ... поэтому кэшированный ответ для Origin: https://one.example.com не будет использоваться, если более поздний запрос для того же ресурса будет содержать Origin: https://two.example.com. Оба будут отправлены источнику, и оба будут кэшированы независимо, для использования при обслуживании будущих запросов с одинаковым соответствующим заголовком запроса.
CloudFront делает это, потому что если вам нужно перенаправить заголовки в источник, то это означает, что источник потенциально будет по-разному реагировать на разные значения для заголовков из белого списка ... поэтому они кэшируются отдельно.
Излишняя пересылка заголовков, таким образом, излишне снизит частоту обращений в кэш.
Нет задокументированного ограничения на количество различных копий одного и того же ресурса, который CloudFront может кэшировать, исходя из разных заголовков.
Но пересылка всех заголовков к источнику почти сводит к нулю вероятность того, что любой будущий запрос будет действительно идентичным. Это может занять много места в кэш-памяти и хранить объекты, которые больше никогда не будут использоваться повторно, поэтому CloudFront рассматривает это как особый случай и не допускает никакого кэширования в этом случае. В результате вы должны установить Minimum TTL равным 0 для согласованности.
& sup1; TTL объекта, как здесь используется, относится к внутреннему таймеру CloudFront для каждого кэшируемого объекта, который отслеживает, как долго разрешено продолжать обслуживать кэшированный объект, не возвращаясь к источнику. TTL объекта внутри CloudFront известен только CloudFront, поэтому это значение не влияет на кэширование в браузере.