Mise en cache du CDN, durée de vie (TTL) | Scene7

Pourquoi les images expirent immédiatement dans un navigateur ?

Solution

Mise en cache du CDN (réseau de diffusion du contenu) et durée de vie (TTL)

Avec Adobe Scene7, vous pouvez définir une expiration différente pour les images spécifiées. Par exemple, l’image par défaut qui s’affiche lorsqu’une image est introuvable est automatiquement configurée pour une expiration plus courte.

La durée de vie (TTL) est un mécanisme permettant de limiter la durée de vie des données d’un réseau. Nos fournisseurs CDN (Content Delivery Network, réseau de diffusion de contenu) proposent ce paramètre de configuration. Lorsque la durée de vie (TTL) est dépassée, la demande GET pour un objet déclenche une demande IMS (If Modified Since) à l'origine de Scene7. Si le fournisseur CDN reçoit une réponse 304 (Non modifié) de nos serveurs d'origine, l'objet est rafraîchi, avec un en-tête Expiré mis à jour, s'il a changé.

Il y a plusieurs années, nous avions une durée de vie (TTL) de dix heures, qui faisait autorité, et l'en-tête Expiré n'avait aucun impact sur la mise en cache du CDN. Ce paramètre a été modifié de sorte que lorsqu’un objet a expiré en fonction de la durée de vie du CDN ou en fonction de l’en-tête « Expiré : », l’objet était actualisé à la demande GET suivante. Ce processus actualise également les en-têtes. En résumé, nous remplaçons maintenant la durée de vie du CDN si l’heure d’expiration de l'en-tête est inférieure à la durée de vie configurée.

La condition ci-dessus s’applique lorsque l’objet est « dans le cache » sur Akamai. Lorsqu'Akamai crée une requête IMS (if-modified-since) à l’origine, il ne dispose d’aucun trafic à fort impact, car seuls les en-têtes HTTP sont échangés. L’objet n’est pas téléchargé à nouveau. Le CDN vérifie seulement si l’objet est inchangé et actualise la durée de vie de cet objet dans le cache.

L’impact de cette modification de la configuration du CDN (réseau de diffusion de contenu) est qu’il existe désormais des demandes IMS plus fréquentes aux serveurs d’origine pour du contenu avec une durée d’expiration faible.

Lorsque la configuration du CDN change, pourquoi une image expire immédiatement dans un navigateur ?

Exemple:

En-têtes de réponse :
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]

Il y a plusieurs années, nous avons découvert que cet objet était stocké dans le cache avec un en-tête Expiré dans le passé :

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

Avec nos précédents paramètres de configuration de réseau de diffusion de contenu (CDN), ce comportement était tel que conçu. Avoir un objet stocké en mémoire cache avec un en-tête Expiré dans le passé a entraîné l’expiration d’un en-tête Expiré en aval de « maintenant ». La date de « Dernière modification » n’avait pas changé. Par conséquent, une réponse HTTP 304 de l'origine pour une demande IMS (if-modified-since) ne mettait pas à jour les en-têtes des objets mis en cache avec Akamai. Lorsqu’un objet était mis en cache et expiré, le fournisseur CDN envoyait toujours une demande « if-modified-since » (IMS) à l’origine. Etant donné que la date de la « Dernière modification » est identique, le fournisseur CDN a reçu une réponse HTTP 304. Ensuite, la durée de vie de l'objet mis en cache (TTL) était mise à jour à dix heures en fonction de la configuration, mais l’objet et les en-têtes restaient inchangés.

À ce stade, nous avons mis à jour les métadonnées du CDN pour contrôler la mise à jour des en-têtes mis en cache.

La balise qui nous a permis de changer la mise en cache des en-têtes face à une réponse 304 du serveur d'origine était :

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

Par défaut, le fournisseur CDN ne met pas à jour les en-têtes d'un objet mis en cache avec les en-têtes reçus avec une réponse 304. Par conséquent, une fois le délai d'expiration dépassé, l'objet resterait obsolète dans le cache du CDN (et pour tout utilisateur final) jusqu'à ce que l'origine renvoie une réponse 200 avec un nouvel objet. Une fois le délai d'expiration atteint, si l'origine répondait par un 304, le serveur CDN continuait à revalider à chaque demande avec l'origine. Il enverrait également au navigateur du client un objet qui a déjà expiré. Cela a obligé le navigateur à revalider lors du chargement suivant.

Lors de l'activation de la balise cache:header-update.allow, cela a demandé aux serveurs CDN de mettre à jour les en-têtes de directives de cache dans la réponse mise en cache si elles diffèrent dans la réponse 304. Les en-têtes considérés comme des en-têtes de « directives de cache » pour cette fonction sont les suivants : Expiré, Cache-Control, Edge-Control (et implicitement Surrogate-Control).

Il existe également un contrôle associé sur la fréquence de mise à jour des en-têtes dans la mémoire cache. Ce contrôle existe pour eviter une situation dans laquelle le serveur CDN est requis pour écrire des en-têtes en cache sur chaque réponse car le serveur d'origine définit un nouvel en-tête Expiré avec chaque réponse (ce qui n'est pas le cas avec les réponses Adobe Scene7). Le paramètre par défaut de la fréquence de mise à jour de l’en-tête est d'une minute, mais cette valeur peut être modifiée avec la balise de métadonnées :

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

Lorsque la durée de vie (TTL) est atteinte, l’objet est considéré comme obsolète sur EdgeServers. Une demande IMS est toujours envoyée à l’origine pour vérifier l'heure de dernière modification de ce même objet.

Le changement de métadonnées réalisé permet d'actualiser les en-têtes avec la réponse 304 de l'origine. Cette modification n’a pas pour résultat un téléchargement complet de ce même objet si celui-ci n’a pas été modifié.

La demande IMS (if-modified-since) aux serveurs d’origine n'est effectuée que lorsque le contenu est obsolète. Autrement dit, après l'expiration de la durée de vie, les en-têtes ne sont plus mis à jour aussi souvent.