Comment fonctionne la mise en cache avec les réponses Netscalar

Question

Au travail, notre site site derrière un NetScaler qui met en cache la réponse. J'essaie de comprendre comment cela fonctionne.

Ainsi, le site Web a une authentification, si vous n'avez pas le cookie fed-auth vous obtenez une réponse 302 pour rediriger vers la source Oauth. Et une réponse 200 si l'utilisateur est authentifié.

Le NetScaler est configuré pour mettre en cache les réponses de 200s mais pas 302S

Ma question est quand je fais une demande depuis le serveur est de déterminer 200 ou 302 comment NetScaler savoir pour retourner une réponse de cache sans aller au serveur? Une simple compréhension de la mise en cache me conduirait à la conclusion que toute requête retournerait la réponse 200 sans vérifier avec le serveur.

Mais ce n'est pas ce que nous voyons. Lors des tests manuels, le site fonctionne comme prévu, enregistrant les entrées et les sorties comme prévu. Cependant, lorsque des tests automatisés sont appliqués, l'utilisateur obtient la réponse en cache de 200. Je dis que c'est la réponse en cache parce que nous voyons un ETag et un Via: NS-Cache dans les en-têtes.

Si quelqu'un peut me diriger vers une ressource ou une brève explication afin que je puisse être mieux informé, cela serait apprécié.

Answer 1

Le comportement de mise en cache de NetScaler est entièrement géré par les stratégies et conforme à la norme RFC 2616. Il est très important lorsque vous mettez en cache un contenu si dynamique que vous compreniez quelle partie est spécifique à l'utilisateur. Tout ce qui peut être normalisé, par exemple, en laissant tomber des informations spécifiques à l'utilisateur comme les cookies, peut être mis en cache. Versus "Caching intégré". Importance des en-têtes HTTP.

Via: Ceci est l'en-tête quand il s'agit de vérifier que le NetScaler participe à la mise en cache

If-Modified-Since plus utile: Ceci est un en-tête du côté de la demande que le client utilise pour demander un cache, comme le NetScaler fournir l'objet complet s'il a changé depuis la date indiquée. Dans un grand pourcentage de cas (en parlant d'objets statiques ici) ces objets n'auraient pas changé, ce qui se traduira par une réponse HTTP 304 beaucoup plus petite non modifiée à la place de l'objet beaucoup plus grand.

Nous avons pensé à voir les deux côtés de l'équation. NSTRACE sur Netscaler et Fiddler s'exécutant sur le client effectuant des requêtes HTTP.

Pour prendre une trace à partir de l'interface graphique, utilisez l'option start new trace dans la section Diagnostics. Taille du paquet zéro. Sortie vers PCAP, Wireshark installé sur le poste de travail. WINSCP installé ou similaire pour extraire le fichier PCAP.

SSH/CLI https://developer-docs.citrix.com/projects/netscaler-command-reference/en/12.0/basic/nstrace/nstrace/

Pouvez-vous SSH/Putty à l'appareil ou virtuel sur IP MGMT?

Connectez-vous en tant que root.

Statistiques cache show -detail Entrez

plus bas dans la sortie, vous serez en mesure de voir quel est le pourcentage de hits sont 304 par rapport aux non-304.Le code d'en-tête HTTP 304 est envoyé dans la réponse au lieu d'une réponse complète (plus grande) lorsqu'un client indique qu'il a déjà un certain objet et vérifie seulement s'il existe une copie plus récente.

Pour montrer comment les statistiques changent au fil du temps

Voir les statistiques de cache -detail -ntimes 3 | grep 304

Pour voir tous les objets mis en cache

objet cache show

Sur le côté gauche est le localisateur ID

plongée Deeper

show objet en cache -Locateur

http://www.telerik.com/fiddler

Pour voir la réponse du client à partir du serveur

Le Netscaler répondra avec en-tête Etag et Via dire d'où vient le cache.

Espérons que cela pointe dans la bonne direction