Nous mettrons à jour notre Politique de confidentialité prochainement. En voici un aperçu.

Réaliser l'audit d'un site web

Aborder les notions de Proxy cache, CDN et serveur

Testez gratuitement nos 1336 formations

pendant 10 jours !

Tester maintenant Afficher tous les abonnements
Vous allez partir à la découverte de la fonction Proxy cache et des notions de CDN et de performance serveur.
08:32

Transcription

Nous allons maintenant nous intéresser à la partie CDN et proxy. Le CDN est l'abréviation de « Content Delivery Network ». C'est un réseau qui va, comme son nom l'indique, délivrer, donc fournir du contenu à vos internautes. La logique est très simple. Plus l'internaute est éloigné de votre serveur, plus son expérience d'utilisation du site sera mauvaise, puisque lente. Si on réplique les contenus du site au plus proche de sa position géographique, il y accédera plus rapidement, et son expérience sera meilleure. Ainsi, si votre site est un site qui doit toucher un public très international, vous avez tout intérêt à mesurer la quantité de visiteurs et leur provenance, et à déployer votre site au plus proche de la plus grande quantité de vos internautes et de vos visiteurs. Il existe des prestataires comme Amazon, comme CloudFlare comme beaucoup d'autres, qui proposent des solutions de proxy et de CDN. Donc là, par exemple, j'ai utilisé une image de répartition de CloudFlare, et je vois qu'il y a beaucoup de serveurs un peu partout dans le monde dans des villes clés, et qui permettent de délivrer du contenu assez proche de vos utilisateurs. Nous allons vérifier maintenant si le site audité utilise bien un CDN. Pour cela, je peux inspecter le code et regarder la provenance de mes sites et de mes sources. Ou alors utiliser un site qui va faire le travail à ma place. Pour cela, je vais ouvrir un onglet avec le site cdnplanet.com et lancer une recherche sur paris.fr. Le résultat est sans appel. J'utilise bien un CDN, qui s'appelle EdgeCast. EdgeCast est un CDN fondé en 2006. Voilà, j'ai des informations sur ce prestataire. Donc je valide bien qu'il y a un CDN utilisé sur ce site. Maintenant, parlons du proxy. Le proxy est un outil qui va venir se positionner entre la charge du nombre de visites et votre serveur web pour protéger votre serveur web. Si votre serveur n'arrive pas à délivrer le contenu parce qu'il est trop sollicité, il va charger des pages blanches ou il va bloquer, et votre site sera inaccessible. Le proxy va garder dans sa mémoire les contenus, les médias et les pages qui n'ont pas été modifiés et va les servir directement aux internautes sans solliciter le serveur. Voilà un schéma très clair en provenance de Wikipedia. J'ai un poste A qui veut demander à B quelle heure il est. Il va passer le message au proxy. Le proxy passe la demande au poste B, qui lui répond, et le proxy répond au poste A. Et donc le proxy joue le rôle d'intermédiaire. En termes Web, encore une autre explication. J'ai bien un proxy, qui protège mon ordinateur du réseau externe. Il n'est pas facile de détecter l'utilisation d'un proxy sur un site. Mais je vais tout de même vous montrer une méthode très fiable qui va nous permettre d'identifier l'architecture serveur qui se trouve derrière le site audité, et vérifier si il utilise un proxy pour améliorer les performances. Pour cela, je vais inspecter la page d'accueil. Aller dans l'onglet Network et actualiser avec F5. Et je vais aller regarder les headers, donc les en-têtes HTTP de ma page web. Pour cela, je scrolle tout en haut et je clique sur le nom de ma page web, ma page HTML, qui est ici indiquée comme un document. Et je clique, si jamais ce n'est pas activé chez vous, sur Headers. Ici je vois que le serveur de ma page s'appelle ECS. pox A597. Je pense que c'est un proxy. En plus, j'ai le header X-Cache égal HIT qui indique que la requête s'est bien passé sur un cache. Par contre, j'ai ici le Cache Control égal zéro, qui ne me donne pas vraiment d'information sur la durée de vie de ma page dans le proxy. Cette information, en principe, est censée m'indiquer si la page est présente depuis longtemps dans le cache du proxy, ou pas. Mais elle n'est pas forcément enseignée systématiquement. Donc ce n'est pas vraiment un indicateur fiable. Je vais donc me fier à cet indicateur serveur ECS pox A 597 et faire une petite recherche. Il semblerait qu'ECS soit un service proposé par Amazon qui est assez cohérent avec l'idée de proxy. Je vais tout de même aller voir d'autres pages du site pour vérifier quel est leur comportement. En effet, la page d'accueil n'est pas tout le temps considérée comme une page standard, puisque c'est forcément une page qui va être systématiquement affichée par tout le monde, étant donné qu'il est interdit de faire du deep linking. Donc même les sites qui feraient des liens vers Paris sont censés faire des liens vers la page d'accueil, et non pas vers des pages qui se trouvent à des sous-niveaux. Donc elle est bien plus sollicitée que les autres pages. Allons voir donc une autre page. La page Actualités, et je vais cliquer aussi sur le document. Toujours serveur ECS. Allons voir encore une autre page. Toujours ECS. Allons voir maintenant des pages d'actualités qui sont un petit peu plus profondes dans le site. Et toujours la même méthode. Et là, mon serveur c'est nginx. Donc là, j'en déduis que le proxy n'est pas déployé sur toutes les pages. et que les pages qui sont emmenées à être mises à jour assez fréquemment sont servies directement par le serveur web. Alors, nginx est un serveur qui peut être aussi utilisé comme proxy car il est aussi très rapide dans sa livraison des documents demandés. Je vais donc comparer tout ça, et vérifier les adresses IP, pour vérifier donc si il y a bien des différences et vérifier aussi quel est le comportement des headers sur d'autres éléments que les pages HTML. Donc je vais tester un fichier CSS, du .js, et une image. Et ensuite, je vais réaliser des petits screenshots que je vais mettre côte à côte, et nous allons les comparer ensemble. Nous voyons ici, en haut à gauche, le screenshot concernant les headers de la page d'accueil. La page d'accueil provient de l'IP 93.184.220.20 et utilise le port 80. Le serveur annoncé est le serveur ECS. Ensuite, si je compare avec la sous-page. La sous-page elle est servie par la même adresse IP mais via le serveur nginx. Donc il semblerait que ECS soit donc une sur-couche du serveur nginx. Ce qui veut dire que le serveur web serait nginx et ECS est donc le proxy. Ensuite, si je regarde le screenshot relatif au header d'un fichier CSS, le fichier paris.CSS, il est livré aussi par ECS, et donc par la même adresse IP. Donc c'est assez logique. Tout ce qui est possible de mettre en cache ou qui ne change pas fréquemment, passe par un proxy. La logique est très bonne. Ensuite, nous avons un fichier .js en dessous, qui est servi aussi par le même serveur ECS. On remarque une différence au niveau des noms, puisque d'un côté nous avons ECS vie F3A1, et de l'autre côté vie F396. Je ne connais pas en détail le fonctionnement de ce proxy, mais il est possible donc qu'il y ait plusieurs proxy qui se partagent la charge. On appelle ça un « load balancer ». Dans ce cas, ça veut dire que l'architecture est assez lourde, et qu'il y a plusieurs proxy pour se répartir les tâches. Enfin, le dernier est un peu différent des autres puisqu'il provient d'une autre adresse, le site api-site.paris. Et c'est une photo. Vous vous rappelez, ce sont ces photos qui peuvent être chargées à différentes tailles selon les paramètres que l'on passe au serveur. L'adresse IP est donc différente, et le serveur est aussi un nginx. À noter qu'il y a une balise HIT tag aussi qui est assez intéressante puisque elle permet d'indiquer le numéro de version, en quelque sorte, dans le cache de cet élément, et indiquer donc au proxy si il a changé ou pas. Et donc à lui indiquer si il doit être servi par du cache ou par le serveur d'origine. On retrouve ce HIT tag au niveau des en-têtes du CSS, du .js, et pas des pages web. J'ai assez d'informations pour en déduire que mon architecture s'appuie bien sur des proxy, en plus du CDN, et qu'elle est donc dimensionnée pour servir avec de bonnes performances dans presque toutes les situations mon site web.

Réaliser l'audit d'un site web

Évaluez la qualité du travail de développement et d'intégration de votre site Internet. Détectez les éventuels problèmes de performance, de compatibilité, etc.

1h47 (24 vidéos)
Aucun commentaire n´est disponible actuellement
 

Votre formation est disponible en ligne avec option de téléchargement. Bonne nouvelle : vous ne devez pas choisir entre les deux. Dès que vous achetez une formation, vous disposez des deux options de consultation !

Le téléchargement vous permet de consulter la formation hors ligne et offre une interface plus conviviale. Si vous travaillez sur différents ordinateurs ou que vous ne voulez pas regarder la formation en une seule fois, connectez-vous sur cette page pour consulter en ligne les vidéos de la formation. Nous vous souhaitons un excellent apprentissage avec cette formation vidéo.

N'hésitez pas à nous contacter si vous avez des questions !