Cache web,
proxy et proxy inverse

Les notions derrière Varnish : pourquoi garder une copie toute prête, et qui se place entre le visiteur et le serveur.

Le cache web

La mise en cache de documents web (pages, images) sert à réduire la bande passante, alléger la charge du serveur et accélérer la consultation. Un cache web conserve des copies des documents qui transitent par lui et peut, dans certaines conditions, répondre aux requêtes suivantes à partir de ses copies, sans recourir au serveur d'origine.

Qui gère un cache en chemin ?

• L'application qui génère les pages : les fichiers de cache d'un système de gestion de contenu.
• Le serveur qui héberge le site : le cache d'Apache.
• Les proxys : Varnish, notre invité de la semaine.
• L'ordinateur du visiteur : le cache du navigateur.
• Le réseau Internet lui-même : opérateurs et sociétés spécialisées, très utilisés par les sites à forte audience.

Chaque objet a une durée de validité : si la copie est encore bonne, on la sert sans redemander au serveur. C'est pourquoi une mise à jour de site peut prendre du temps à paraître : tous ces caches doivent se rafraîchir.

Varnish

Varnish est un serveur de cache HTTP apparu en 2006, distribué sous licence BSD. Déployé en proxy inverse entre les serveurs d'applications et les clients, il sert les requêtes plus rapidement tout en allégeant la charge des serveurs.

Le proxy

Un proxy est un composant logiciel qui joue le rôle d'intermédiaire entre deux hôtes pour faciliter ou surveiller leurs échanges. Dans les réseaux, c'est un programme (ou le serveur qui le porte) servant d'intermédiaire pour accéder à un autre réseau, généralement Internet.

Attention : le proxy vit dans la couche application (HTTP, FTP, SSH - niveau 7). Erreur classique : tenter de le voir avec traceroute. Il n'y apparaît pas, car cette commande travaille au niveau 3 (IP) et ne peut pas connaître le proxy.

Le proxy inverse (reverse-proxy)

Le proxy ordinaire (forward) protège les clients du réseau public : il canalise toutes les requêtes du réseau interne vers Internet, met en cache les contenus fréquents, et garde les appareils anonymes.

Le sens inverse

Le reverse-proxy opère exactement dans l'autre sens : il protège les serveurs web. Les requêtes venant d'Internet sont reçues par le proxy, vérifiées contre les règles de sécurité, puis transmises aux serveurs d'arrière-plan. Une sécurité supplémentaire, et un point unique pour optimiser le trafic.

Où vit le proxy inverse ?

En général derrière un pare-feu, dans le réseau interne ou une zone démilitarisée (DMZ). Comme le proxy avant, il est la seule connexion entre Internet et le réseau privé : toutes les requêtes passent par la même interface avant d'être transférées aux systèmes ciblés.

Cette mise en commun permet de contrôler le trafic entrant, de servir plusieurs serveurs sous le même URL, de distribuer les requêtes uniformément, et d'accélérer les réponses grâce au cache.

Cinq applications du proxy inverse

Cinq applications du proxy inverse

La répartition de charge et la protection reviendront en force à la semaine 8 : c'est exactement le rôle de HAProxy et de l'IP virtuelle.

L'autre famille : les caches d'exécution

Varnish évite d'exécuter le site : la réponse complète est déjà prête. Les caches d'exécution font l'inverse : ils accélèrent l'exécution quand elle doit avoir lieu - page personnalisée, usager connecté, contenu qui change à chaque requête.

Qui se cache où ?

Le trajet d'une requête se lit de gauche à droite : chaque étape peut répondre depuis SON cache et court-circuiter tout ce qui se trouve à sa droite.

Cache HTTP ou cache d'exécution ?

• Varnish (cache HTTP) : sert la page complète sans réveiller PHP ni MySQL. Imbattable pour les pages identiques pour tout le monde - fiches, catalogues, encyclopédie virale.
• mod_cache (Apache) : le même principe, intégré au serveur web - moins puissant que Varnish, mais sans machine supplémentaire.
• OPcache : accélère TOUTES les pages PHP, même personnalisées - il ne sert rien de tout prêt, il compile moins.
• Memcached / APCu / Redis : accélèrent les pages qu'on DOIT générer - profils, paniers, points des Guildes - en évitant les requêtes répétées à la base de données.

Les deux familles se complètent : Varnish absorbe les visiteurs anonymes, les caches d'exécution soulagent les pages personnalisées. La semaine 7, quand les Guildes rendront chaque page unique, vous saurez pourquoi le cache HTTP ne suffira plus.