La mise en cache HTTP est simple en théorie : lorsque les valeurs de Cache-Control, ETag et TTL sont correctes, les clients et les intermédiaires réutilisent la même réponse. En production, les applications envoient régulièrement ces headers manquants, incorrects ou trop restrictifs. Le résultat est que le contenu pouvant être mis en cache continue de frapper inutilement le backend.
Même pour les assets statiques, de petites différences d'URL érodent l'efficacité du cache. La même image de produit ou page de catalogue peut se comporter comme un objet différent en raison de paramètres de tracking. L'hôte, la query string, les headers client ou un header Cache-Control mal configuré abaissent inutilement le taux de hit de cache.
Pour le contenu dynamique, le problème est plus grand. Le même chemin peut retourner des réponses différentes pour le mobile et le desktop ; les prix peuvent varier selon le pays ; le même endpoint peut produire des données différentes par tenant. Si la clé de cache ne porte pas ce contexte, le mauvais contenu est retourné. Ajoutez trop de headers à la clé de cache et le cache fonctionne à peine du tout.
Les solutions de cache externe ou CDN sont utiles en périphérie d'internet, mais elles ne sont pas toujours adaptées au trafic on-prem, aux API privées ou aux clouds souverains. Faire du cache au niveau de la couche ADC nécessite généralement des fichiers de configuration, un langage de règles personnalisé ou un produit séparé.
La Mise en Cache des Réponses de TR7 réunit les profils de cache, les règles conditionnelles, les clés de cache dynamiques et les options de remplacement standard sous un seul modèle de gestion vService.
TR7 gère le comportement du cache à travers quatre couches : les profils, les conditions, les clés dynamiques et les remplacements contrôlés.
Un profil de cache rassemble le nom, la taille, le TTL, le comportement ETag et la configuration des headers de débogage en un seul endroit. Le même profil peut être partagé entre plusieurs vServices pendant que chaque service est régi par ses propres limites de cache.
Chaque règle de cache se lie au chemin, à la méthode, au header, au cookie ou à d'autres variables via le moteur de condition FX. Un catalogue public sur le même backend peut être mis en cache pendant que le panier de l'utilisateur est exclu — sans modifier aucun code applicatif.
Le pays, le type d'appareil, l'ID de tenant, le segment d'utilisateur ou un header personnalisé peuvent être ajoutés à la clé de cache. La même URL se divise en slots de cache séparés par contexte, préservant la rapidité du cache tout en renforçant l'exactitude du contenu.
Les vérifications de l'hôte, de la query string, du header de requête et du header de réponse peuvent chacune être délibérément contournées. Les backends mal configurés ou les paramètres de tracking ne réduisent plus les taux de hit. Les opérateurs décident explicitement quel standard remplacer et quand.
La Mise en Cache des Réponses rend chaque comportement — du profil de cache à la clé dynamique — configurable au niveau du vService.
Chaque profil est défini avec un nom, une taille maximale et un timeout. La limite de taille maintient l'utilisation du cache par service sous contrôle. Le timeout est configurable en secondes, minutes ou heures. L'application du même profil à plusieurs vServices réduit la répétition opérationnelle.
TR7 peut ajouter un header de débogage aux réponses, permettant à un développeur ou opérateur de voir dans le panneau Réseau du navigateur si une réponse provient du cache ou du backend. Aucun outil de log supplémentaire n'est nécessaire pour une vérification rapide — cela accélère la mise en service et l'ajustement.
Plusieurs règles peuvent être définies au sein d'un seul profil de cache. Chaque règle est déclenchée par le chemin, la méthode, le header, le cookie ou des conditions FX. `/assets/*` peut être mis en cache longtemps pendant que `/api/cart` est exclu. Différents comportements de cache au sein d'un seul vService sont gérés depuis un seul panneau.
ETag peut être activé par règle. Lorsqu'un client demande le même objet à nouveau et que le contenu n'a pas changé, il reçoit une réponse de validation au lieu du corps complet. Cela réduit la consommation de bande passante et est particulièrement efficace pour les assets statiques et les réponses API peu fréquemment modifiées.
Lorsque la mise en cache dynamique est activée, des variables personnalisées peuvent être ajoutées à la clé de cache. Le pays, le type d'appareil, l'ID de tenant, le groupe de test A/B ou une valeur extraite d'un JWT peuvent tous faire partie de la clé. La même URL se sépare proprement selon les contextes. Cela rend la mise en cache pratique pour les scénarios d'API modernes et SaaS.
Lorsque le même backend sert un contenu identique sous plusieurs domaines, l'hôte peut être retiré de la clé de cache. Des domaines comme `a.example` et `b.example` peuvent alors partager le même objet mis en cache, réduisant la duplication de cache. Cette option ne doit être utilisée que lorsque le contenu est véritablement partagé.
`utm_source`, les codes de campagne et les paramètres d'analytique peuvent faire apparaître le même contenu comme des objets différents. Avec l'ignorance de query string active, ces paramètres sont exclus de la clé de cache. La même page sous plusieurs variantes de paramètres de tracking ne frappe plus répétitivement le backend. Les taux de hit pour le contenu public s'améliorent sensiblement.
Certains clients ou bots ajoutent des headers qui tentent de contourner la mise en cache sur chaque requête. L'ignorance de vérification de requête permet de délibérément ignorer ce comportement. Le contenu statique et les réponses d'API publiques sont protégés d'une charge backend inutile. Ce paramètre doit être appliqué avec soin sur les endpoints sensibles à la sécurité.
Un backend peut mistakenly envoyer `no-store` ou des headers de cache trop restrictifs. L'ignorance de vérification de réponse permet aux opérateurs de délibérément contourner ces headers. Les bénéfices du cache sont obtenus sans modifier le code applicatif. Cette option ne doit être utilisée que pour les réponses déterministes et sûres.
Le comportement de cache HTTP standard se concentre sur les réponses GET et HEAD. TR7 permet aux opérateurs d'inclure également les réponses POST dans la portée du cache. C'est particulièrement utile lorsque les requêtes GraphQL arrivent via POST. Le hash du corps ou des variables FX pertinentes peuvent être ajoutés à la clé de cache pour garantir une séparation sûre.
Le cache est maintenu en mémoire runtime. Les changements de configuration sont appliqués via un modèle de soft reload ; aucun endpoint d'invalidation runtime n'est revendiqué. La mise à jour d'un profil ou d'une règle de cache actualise le comportement de cache concerné. Lorsque l'appareil redémarre, le cache recommence à se réchauffer depuis zéro.
Lorsque la limite de taille du cache est atteinte, les objets les moins utilisés ou périmés sont évincés. Les opérateurs n'ont pas besoin de gérer les objets individuels manuellement. La limite de taille empêche le cache d'un vService d'affecter d'autres services. La taille du profil peut être augmentée pour les grands catalogues d'assets.
La Mise en Cache des Réponses doit être planifiée conjointement avec le TTL du cache, la taille des objets, la conception des clés, le modèle d'invalidation et les limites de sécurité.
La taille maximale d'un profil de cache est définie en Mo ; jusqu'à 2 048 Mo par profil est pris en charge. Les profils plus grands conviennent aux grands catalogues d'assets ; une limite plus basse suffit pour les petits caches de réponses API.
Un TTL très court provoque des cycles de cache inutiles et diminue le bénéfice de la mise en cache. TR7 impose un minimum de 10 secondes pour éviter des cycles de remplissage-vidage inutiles. Le TTL doit être ajusté à la fréquence de mise à jour de chaque endpoint.
Une clé de cache mal conçue peut retourner du contenu spécifique à un utilisateur ou tenant dans le mauvais contexte. Lorsque la différenciation par tenant, pays, type d'appareil ou segment d'utilisateur est nécessaire, ces valeurs doivent être incluses dans les clés de cache dynamiques. Les endpoints sensibles doivent être exclus de la mise en cache par défaut.
Le cache est basé en mémoire ; il démarre vide lorsque l'appareil ou le service redémarre. Cela élimine la complexité du cache de disque persistant. Le cache se réchauffe à nouveau avec la vague de trafic initiale.
Aucun endpoint d'invalidation runtime n'est revendiqué. Le comportement du cache est géré en éditant les profils ou les règles et en déclenchant un soft reload. Pour changer le comportement d'un endpoint spécifique, mettez à jour la règle de cache concernée.
Les changements de profil de cache, de timeout, d'option d'ignorance et de clé dynamique doivent être capturés dans le journal d'audit. Qui a changé le comportement du cache de quel endpoint est visible. C'est particulièrement important pour la conformité et l'analyse des incidents.
Les pages de produits et les API de catalogue sont mises en cache pour une période définie. Le pays est ajouté à la clé de cache afin que les marchés avec des prix ou niveaux de stock différents reçoivent le contenu correct.
Les endpoints d'actualités, d'annonces ou de contenu public peuvent être mis en cache pendant quelques minutes. L'ignorance de la query string empêche les paramètres de tracking d'abaisser le taux de hit.
L'ID de tenant ou un header personnalisé est ajouté à la clé de cache. Le même chemin route de manière sûre vers des slots de cache séparés pour différents tenants.
Même lorsque les requêtes GraphQL arrivent via POST, les requêtes déterministes peuvent être mises en cache. Le hash du corps ou des variables FX pertinentes sont ajoutés à la clé de cache pour minimiser le risque de retourner une réponse incorrecte.
Les fichiers CSS, JS, images et fonts sont mis en cache avec un long TTL. Avec ETag actif, les clients évitent le téléchargement complet du corps lorsque le contenu inchangé est demandé.
La famille User-Agent ou la classe d'appareil est ajoutée à la clé de cache. La même URL est maintenue dans des slots de cache séparés pour le mobile et le desktop.
Profils de cache, règles conditionnelles, clés dynamiques et options de remplacement conformes RFC pour la mise en cache des réponses. Laissez-nous vous présenter une mise en place en direct sur vos propres services.