Memorizzazione nella cache del CDN, Time-to-Live (TTL) | Scene7

Perché le immagini scadono immediatamente in un browser? 

Soluzione

Memorizzazione nella cache del CDN e TTL (Time-To-Live)

Con Adobe Scene7, è possibile impostare scadenze diverse per immagini specifiche. Ad esempio, l'immagine predefinita che viene visualizzata quando un'immagine non viene trovata, viene configurata automaticamente per avere un tempo di scadenza più breve.

Time-To-Live (TTL) è un meccanismo per limitare la durata a vita dei dati in una rete. I nostri provider di Content Delivery Network (CDN) offrono questa impostazione di configurazione. Quando il time-to-live è passato, una richiesta GET per un oggetto innesca una richiesta IMS (If-Modified-Since) all'origine Scene7. Se il nostro provider di CDN riceve una risposta 304 (non modificata) dai nostri server di origine, l'oggetto viene aggiornato, insieme ad un'intestazione Expires aggiornata, se è cambiato.

Diversi anni fa, abbiamo avuto un TTL di dieci ore, che era autorevole, e l'intestazione Expires non ha avuto alcun impatto sulla nostra memorizzazione nella cache del CDN. Questa impostazione è stata modificata in modo che quando un oggetto è scaduto con il TTL del CDN o in base all'intestazione "Expires:", l'oggetto è stato aggiornato alla successiva richiesta "GET". Questo processo ha anche aggiornato le intestazioni. In breve, ora sovrascriviamo il TTL del CDN se il tempo di intestazione Expires è più breve del TTL configurato.

La condizione di cui sopra si applica quando l'oggetto è "in-cache" su Akamai. Quando Akamai inoltra una richiesta if-modified-since (IMS) all'origine, non causa alcun traffico ad alto impatto, perché vengono scambiate solo le intestazioni HTTP. L'oggetto non viene scaricato di nuovo. Il nostro CDN controlla solo se l'oggetto è invariato e aggiorna il TTL di quell'oggetto nella cache.

Questa modifica della configurazione del CDN ha portato richieste più frequenti di contenuti a basso tempo di scadenza da parte dei server di origine.

La configurazione del CDN cambia, perché un'immagine dovrebbe scadere immediatamente in un browser?

Esempio:

Response Headers:
Content-Type[image/jpeg]
Last-Modified[Wed, 20 Jun 2007 21:29:20 GMT]
Etag["0b3a49e639331555ba959a9f1e332c2f"]
Expires[Mon, 13 Aug 2007 02:00:28 GMT]
Date[Mon, 13 Aug 2007 02:00:28 GMT]
Connection[keep-alive]

Diversi anni fa, abbiamo scoperto che in passato questo oggetto era conservato in cache con un'intestazione Expires:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Expires: Mon, 13 Aug 2007 16:53:16 GMT
Last-Modified: Thu, 19 Jul 2007 21:42:18 GMT
ETag: "ebb5a6db6c4e78a15db53a29d9d0b9d2"
Content-Type: image/jpeg
Content-Length: 14141
Date: Mon, 13 Aug 2007 06:53:15 GMT
Age: 0
X-Akamai-Purge-Seq-Num: 1336350
Connection: keep-alive

Con le nostre precedenti impostazioni di configurazione del Content Delivery Network (CDN), questo comportamento era quello di progettazione. Avere un oggetto memorizzato in cache con un'intestazione Expires in passato ha dato un'intestazione di scadenza downstream di "ora". La data dell'"Ultima modifica" non è variata. Come risultato, una risposta HTTP 304 dall'origine per una richiesta if-modified-since (IMS) non ha aggiornato le intestazioni degli oggetti in cache con Akamai. Quando un oggetto è stato memorizzato in cache ed è scaduto, il nostro provider di CDN ha sempre inviato una richiesta "if-modified-since" (IMS) all'origine. Poiché la data "Ultima modifica" è la stessa, il nostro provider di CDN ha ricevuto una risposta HTTP 304. Poi, la cache degli oggetti Time-To-Live (TTL) è stata aggiornata a dieci ore in base alla configurazione, ma l'oggetto e le intestazioni sono rimasti invariati.

A quel punto, abbiamo aggiornato i metadati del CDN per controllare l'aggiornamento delle intestazioni memorizzate in cache.

Il tag che ci ha permesso di cambiare le intestazioni di possibilità di memorizzazione in cache su una risposta 304 dal server di origine è stato:

<cache:header-update.allow>su</cache:header-update.allow>

Per impostazione predefinita, il nostro provider di CDN non aggiorna le intestazioni in un oggetto memorizzato in cache con le intestazioni ricevute in una risposta 304. Come risultato, una volta trascorso il tempo di scadenza, l'oggetto diviene vecchio nella cache del CDN (e per qualsiasi utente finale) fino a quando l'origine non restituisce una risposta di 200 con un nuovo oggetto. Una volta raggiunto il tempo di scadenza, se l'origine rispondeva con un 304, il server CDN continuava a riconvalidare con l'origine ad ogni richiesta. Servirebbe anche al browser client un oggetto già scaduto. Ha causato la necessità di riconvalida del browser al carico successivo.

Quando abbiamo abilitato il tag cache:header-update.allow, questo ha dato istruzioni ai server del CDN di aggiornare le intestazioni cache-directive nella risposta memorizzata in cache se sono diverse nella risposta 304. Le intestazioni considerate "cache-directive" per questa caratteristica sono: Expires, Cache-Control, Edge-Control (e implicitamente Surrogate-Control).

C'è anche un relativo controllo sulla frequenza con cui le intestazioni sono aggiornate in cache. Questo controllo esiste per evitare una situazione in cui al server del CDN è richiesto di scrivere intestazioni nella cache su ogni risposta perché il server di origine sta impostando una nuova intestazione Expires ad ogni risposta (non è così con le risposte di Adobe Scene7). L'impostazione predefinita per la frequenza di aggiornamento dell'intestazione è di un minuto, ma questo valore può essere modificato con il tag metadati:

<cache:header-update.max-frequency>1m</cache:header-update.max-frequency>

Quando si raggiunge il TTL, l'oggetto viene considerato vecchio su EdgeServers. Una richiesta IMS viene sempre inviata all'origine per controllare l'ultima modifica all'ora dello stesso oggetto.

La modifica dei metadati che abbiamo fatto permette di rinfrescare le intestazioni insieme alla risposta 304 dall'origine. Questa modifica non ha portato uno scaricamento completo dello stesso oggetto se non è stato modificato.

Le richieste if-modified-since ai server di origine vengono fatte solo quando il contenuto è vecchio. Cioè, dopo la scadenza del TTL, le intestazioni non vengono aggiornate così frequentemente.