什麼是CloudFront中的TTL 0有用？

Question

幾個星期前，亞馬遜宣佈，他們已經降低了內容保質期：

Amazon CloudFront Lowers Minimum Content Expiration Period

這麼多，你實際上可以現在設置TTL在CloudFront的爲0。所以我的問題是，爲什麼它可能是有用的有一個TTL設置爲0的CloudFront分配。對我來說，這意味着不需要緩存，因此每個到達CloudFront的請求最終都會觸發原點。

我錯過了什麼？

Answer 1

的Amazon CloudFront這個新功能實際上是許多用例是非常有用的，因爲擊中作品有點不同的比它的外觀一見鍾情，並不一定是問題，相反的來源;儘管此功能已經早些發佈，但它與最近發佈的Amazon CloudFront - Support for Dynamic Content，例如，對於眼下的問題：

可變長時間生存（TTL） - 在許多情況下，動態內容要麼是 不能緩存或緩存的時間很短的時間，也許 短短秒。過去，CloudFront的最低TTL爲60分鐘，因爲所有內容都被認爲是靜態的。新的最小TTL 值爲0秒。 如果您將特定來源的TTL設置爲0，則 CloudFront仍將緩存來自該來源的內容。 然後它將 使用GET請求一個If-Modified-Since頭，從而給 原點的機會信號CloudFront的可以繼續使用 緩存的內容，如果它不在原點改變。 [重點礦山]

換句話說，使用0主要手段一個TTL，即CloudFront的委託授權用於超高速緩存控制原點，是否，並且如果多長時間即原點服務器決定CloudFront緩存對象;請注意具體而言，與GET請求一個If-Modified-Since標題並不一定意味着該對象本身從原點檢索，而原點可以（也應該）返回HTTP status code 304 - Not Modified適用：

表示資源自上次請求後未被修改。 使用此功能可節省服務器和客戶端上的帶寬和重新處理時間，因爲只有必須發送和接收標頭數據與 服務器正在重新處理的頁面的整體相比較 ，然後再次使用服務器和客戶端的更多帶寬發送。 [重點煤礦]

見馬克諾丁漢大學的優秀Caching Tutorial有關力學和HTTP緩存控制，在HTTP架構的一個非常重要和有效部分的收益細節。

瞭解所有這些部分是如何一起工作可能會有點困難確實，因此在部分指定最短時間時CloudFront的的環境中應用CloudFront的緩存對象的下載分佈嘗試內Specifying How Long Objects Stay in a CloudFront Edge Cache (Object Expiration)總結影響的表有或沒有TTL = 0。

Answer 2

請注意，亞馬遜並不是說「TTL爲0」，而是說「最小TTL爲0」。這是非常不同的。以上描述非常可取，但不能保證Cloudfront實際執行此操作。

在我現在的經驗中，我可以看到緩存圖像在邊緣停留了幾分鐘，而原點已經改變了。

因此，我認爲「最小TTL爲0」可能更像是「亞馬遜沒有嚴格意圖將其保留在緩存中」，也許「並且會經常重新提取」。

對於像CMS這樣的網絡用戶發佈新內容的應用，我認爲TTL-0仍然不足。您仍然必須從CMS調用失效，或者爲不同的版本號使用不同的路徑。