Salut et bienvenue dans ce nouvel épisode de Code Garage.
Je m'appelle Nicolas Brondin-Bernard et aujourd'hui, dans cet épisode, on va attaquer
un gros morceau, ça va être un épisode un peu plus long que d'habitude puisqu'on
va parler du navigateur web.
Et on va se poser la question de qu'est-ce qu'un navigateur web exactement et comment
il fonctionne.
On va parler à la fois de technique, même si je vais essayer de ne pas trop rentrer
dans les détails pour quand même garder le concept général, mais on va parler un
petit peu de théorie et de plein de choses comme ça.
Donc, évidemment, ça va être une simplification dans les faits.
Certains navigateurs modernes fonctionnent légèrement différemment, mais on va se dire
qu'on va décortiquer le fonctionnement d'un navigateur web basique comme on aurait
pu, enfin comme on pouvait avoir dans les années 2000.
Ok ? Mais voilà, la théorie n'a pas beaucoup changé.
Donc, c'est justement par ça qu'on va commencer.
On va commencer par la théorie.
On pourrait partir du principe qu'un navigateur web le plus basique possible n'est que deux
fonctions finalement.
Ce serait envoyer des requêtes HTTP et afficher un rendu graphique d'un contenu HTML
renvoyé par un serveur web.
Ok ? Ça, c'est vraiment la base.
En principe, un logiciel qui implémenterait ces deux méthodes, il pourrait déjà qualifier
de navigateur web sans aucun problème.
Évidemment, aujourd'hui, avec l'état du web actuel et les attentes des utilisateurs,
ce modèle théorique-là, il serait plus suffisant pour remplir ce job d'aujourd'hui.
Mais on a quand même des navigateurs web qui fonctionnent en ligne de commande.
Ok ? Donc, on peut se dire que ça fonctionne un petit peu comme ça et le rendu se fait
dans un terminal.
Donc, la définition reste valable.
Et d'ailleurs, si on regarde, il est possible encore aujourd'hui d'afficher la première
page web qui a été créée par Tim Berners-Lee au CERN en 85 et elle est encore en ligne.
Je vous la mettrai dans les notes de l'épisode disponibles.
Et donc, vous verrez que c'est que du texte et c'est très, très basique.
Et à l'époque, un navigateur web tel que je viens de vous le décrir en théorie, ça
fonctionnerait.
Mais maintenant, on va passer à la pratique et vous allez voir que ça change pas mal
de choses.
D'abord, qu'est-ce qui se passe quand on lance son navigateur web ? C'est qu'il
y a la création d'un processus système.
Quand on démarre le navigateur, en fait, ce navigateur, il va charger automatiquement
un nouvel onglet vierge.
Un nouvel onglet, ce n'est pas seulement utile pour les utilisateurs, c'est aussi
utile pour le bon fonctionnement technique du navigateur.
Quand on va créer un onglet, le navigateur, il va créer un nouveau processus système
enfant indépendant.
Et ça, ça va permettre deux choses.
D'abord, le navigateur et les onglets, ils pourront continuer à communiquer, mais
deux onglets ensemble ne pourront en théorie pas communiquer entre eux ce qui favorise
la sécurité.
Et aussi, si un des onglets consomme trop de mémoire et doit s'arrêter parce que sinon
il ferait planter le système, et bien seulement l'onglet en question qui prend trop de mémoire
pourra être terminé et il n'y aura pas besoin de fermer tout le navigateur.
Ça reste pareil un peu en théorie, mais normalement, c'est ce qui doit se passer.
Une fois qu'on a lancé notre navigateur, créé notre premier onglet, ce qu'on va
vouloir, c'est taper tout simplement le nom d'un site ou une recherche, mais pour
faciliter, on va dire, l'URL d'un site qu'on veut visiter.
Et ce qui va se passer ensuite, c'est qu'il y a une résolution DNS.
Donc, on tape notre recherche dans la barre de navigation et elle doit contenir un URL
valide pour que ça charge le site.
L'URL, ça peut être un nom de domaine ou ça peut être basé sur une adresse IP.
Si jamais l'utilisateur indique un nom de domaine, le navigateur, il devra aller récupérer
l'adresse IP pointant sur ce nom de domaine-là avant de pouvoir commencer à charger la page
grâce à une requête HTTP.
Parce que, souvenez-vous, le protocole HTTP est basé sur la suite TCP-IP et donc il
faut forcément une adresse IP pour que le réseau, il puisse transporter, router, on dit,
les paquets TCP.
Si jamais vous n'êtes pas trop familier avec la suite de protocole TCP-IP, j'ai fait
un article spécialement dessus, je vous le mettrai dans les notes de l'épisode.
Pour récupérer l'adresse IP, le navigateur, il va effectuer une requête DNS.
Donc, DNS, c'est domain name, ça va, donc on peut appeler un système de nom de domaine.
Et son seul but, lui, ça va être de faire une correspondance entre un nom et une IP.
Les requêtes DNS sont très fréquentes, donc elles sont mises en cache et elles sont surtout
soumises à plusieurs niveaux de cache.
En premier, il y a le navigateur qui va aller regarder dans son cache interne pour voir
s'il n'a pas déjà la correspondance d'une nom de domaine IP et que ce n'est pas périmé.
Sinon, le système d'exploitation, lui, il va aussi pouvoir regarder dans son cache.
Et sinon, la requête DNS, elle va vraiment partir sur le réseau.
Elle va traverser un certain nombre de serveurs DNS récursifs qui vont regarder dans leur
cache respectif et transmettre la requête à un autre serveur DNS si jamais ce n'est
pas présent dans leur cache.
Et ce, jusqu'à trouver tout simplement l'adresse IP correspondante qui sera retourné en réponse
à la requête.
Vous voyez, on n'a pour l'instant toujours pas parlé de la moindre première requête
HTTP.
Mais on y vient.
Donc la toute première requête HTTP, c'est une fois que l'adresse IP a été reçue.
Le navigateur va pouvoir envoyer cette requête pour demander la page d'accueil du site.
Quand l'utilisateur il veut accéder au site google.com, le navigateur met-on va récupérer
l'adresse IP 142.250.168.142.
Mais il va aussi agrémenter l'URL en ajoutant le protocole en l'occurrence HTTP ou HTTPS,
le port par défaut 80 là ici et l'UHERI par défaut.
L'UHERI, c'est l'identifier.
Donc c'est potentiellement ce qu'il y a après le nombre de mènes.
Donc ici, un slash index.html.
Même si ce n'est pas ce que vous demandez, il y a des navigateurs, l'ajoute automatiquement
ou alors le serveur web le détecte automatiquement.
Mais du coup, on va se retrouver avec une requête finale qui sera pas juste l'adresse IP évidemment,
mais qui va dire on va utiliser HTTP en version 1.1 par exemple ou 2.0.
Ça va être une requête GET sur l'adresse IP 142, etc.
sur le port 80 et la ressource qu'on veut c'est slash index.html.
Donc en vrai, la requête HTTP a ce fait bien que le nom de mènes et l'IP,
elle est contenue dans le paquet de CCP en dessous.
Mais l'exemple, on va dire, se comprend un peu mieux comme ça.
Évidemment, je ne vous aborde pas les concepts d'HTTPS et de SSL
pour garder l'épisode le plus abordable possible.
Ensuite, une fois qu'on a envoyé cette requête-là,
on va avoir l'interprétation de cette réponse HTTP.
La réponse HTTP contient trois éléments principaux,
évidemment, on contient plein d'autres, mais c'est ces trois principaux-là.
C'est le code de statut, l'antête de la réponse et le corps de la réponse.
Le code de statut, lui, il va permettre de savoir si la requête s'est bien passée.
Le code 200 va dire que la ressource demandée est bien présente et pourrait être traité.
Le code 301 va dire un navigateur qui doit envoyer sa requête à une autre URL,
c'est ce qu'on appelle une redirection.
Le code 404 va dire que la ressource demandée n'existe pas ou n'existe plus.
Si jamais vous voulez en savoir un peu plus sur les codes HTTP,
j'ai aussi un article dédié que je vous mets dans les notes de l'épisode.
L'antête HTTP, ça va aussi nous servir à enregistrer des cookies.
Si la réponse HTTP ne contient pas de redirection,
les données contenues dans l'antête pourront être traitées et notamment les cookies.
Les cookies, ce sont des données envoyées par le serveur que le navigateur devra stocker en
local et renvoyer à chaque requête automatiquement vers ce serveur-là.
Chaque cookie est stockée pour un domaine en particulier et pour un temps
limité. Ces cookies vont être utilisés pour avoir un suivi de l'utilisateur lors de sa
navigation sur le site, lui offrir des fonctionnalités qui nécessitent son
authentification ou des fois du tracking pour de la pub, etc.
Ensuite, on va avoir le corps de la réponse HTTP et là, il va falloir faire du traitement.
Logiquement, quand la requête s'est déroulée correctement,
le serveur va renvoyer une page web qui va être contenue dans le corps de la réponse.
Mais cette page web est simplement sous la forme d'une chaîne de caractère,
on va dire, qui va falloir traiter.
Donc le navigateur en utilisant toutes les données qui sont présentes dans la réponse,
il va devoir transformer cette chaîne de caractère.
On a documents HTML valides en s'appuyant sur le type de documents indiqués dans le premier
élément présent qui s'appelle le DOCTYPE. DOCTYPE, ça permet de configurer que le document
confirmé, pardon, que le document reçu, c'est bien un document HTML et il indique aussi la
version du langage que j'ai utilisé HTML5 par défaut s'il n'y en indique rien que DOCTYPE.
Ensuite, l'arbre d'homme qui va résulter de ce traitement, il va être constitué de deux
éléments de niveau supérieur, le HEAD et le BODY.
Alors petit précignon, DOM, c'est-à-dire document object modeling.
Toutes les métas données qui sont présentes dans le HEAD seront d'abord traités par avancel
du BODY parce que tout simplement, il faut avoir ces infos là en premier et c'est la
raison pour laquelle les scripts chargés pendant cette partie ne peuvent pas encore
avoir accès au corps de la page parce que ce dernier n'existe pas.
Ça peut arriver si vous appelez des scripts JavaScript dans l'entête, c'est pas forcément
recommandé, mais c'est surtout qu'ils ne vont pas pouvoir trouver le BODY de la page,
puisqu'il n'existera pas encore.
Par contre, en ce moment-là, on charge une partie des styles CSS avant que le contenu
généré dans le corps de la page soit déjà stylisé, pour qu'il soit déjà stylisé
quand le corps sera chargé.
Une fois que le document est chargé, il passera dans le moteur de rendu du navigateur
afin de pouvoir être présenté graphiquement à l'utilisateur.
Ensuite, il y a les chargements des dépendances de la page.
Il faut toujours garder en tête que pour chaque appel à une dépendance externe, une image,
une feuille de style, un script, etc., le navigateur va effectuer un nouvel appel,
un nouveau, un nouvel, c'est pas grave, appel HTTP et chaque dépendance sera injectée
et éventuellement exécutée quand c'est descripté dans le document HTML.
Et c'est seulement une fois que ces appels sont terminés qu'on considère le chargement
de la page comme terminé.
Mais en réalité, on sait jamais si un script ne va pas injecter dynamiquement une nouvelle
dépendance à aller chercher, c'est notamment parfois ce qu'on appelle du lesilodine.
Pendant ces chargements de dépendance, il va y avoir une gestion du cache puisque certaines
dépendances ont déjà été demandées pour d'autres pages du site ou pour d'autres sites,
certaines non.
Donc le navigateur à chaque fois va vérifier, enfin tout simplement, va plutôt indiquer
qu'il a déjà demandé cette URL avec un code qu'on appelle litag et le serveur va répondre
suivant l'itag qui lui a été envoyé, si ce document a changé ou non depuis la dernière fois.
Et donc s'il n'a pas changé, il n'a pas besoin de renvoyer, il va juste renvoyer un code
304 pour dire non, c'est dans ton cache tu peux utiliser ce que tu as déjà.
Et enfin, la dernière étape qu'on va traiter ici, c'est l'interprétation, l'exécution et la
compilation des scripts parce qu'en plus du moteur de rendu, chaque navigateur est composé
d'un moteur JavaScript.
Ce moteur JavaScript, il va récupérer chaque script sous forme de texte comme d'habitude,
il va le passer dans un interpréter syntaxique pour le transformer en code exécutable.
Ensuite, il va exécuter chaque script et on pourrait se dire que c'est terminé.
Sauf que les navigateurs modernes, ils font de l'analyse d'exécution et ils font ce qu'on
appelle une compilation JIT ou Just in Time. C'est un domaine qui est un petit peu complexe,
je vous mettrai un article pour celles et ceux qui veulent aller plus loin en note de l'épisode,
mais la compilation Just in Time, en gros, c'est le moteur JavaScript qui va se dire,
tiens, ce bout de code, il est appelé très, très, très souvent. Donc je vais essayer de
le réfectoriser et de le rendre le plus minimal possible et surtout le plus performant possible
parce que je l'exécute beaucoup, beaucoup, beaucoup de fois et j'utiliserai la version
recompilée, on va dire, quand on me le demandera la prochaine fois. Alors évidemment, il y a encore
beaucoup de choses que je n'ai pas abordé. On pourrait parler de l'analyse et de l'exécution
du CSS, des animations, du cycle de rafraîchissement du rendu de la page, ce qu'on appelle les
repaints et énormément de choses, mais ça prendrait beaucoup de temps et surtout, ce sont à mon
avis des choses que vous pouvez voir de votre côté et qui ne sont pas absolument nécessaires de
connaître par coeur ou au moins même de connaître, on va dire, de base. Ce qu'il faut savoir comment
est-ce qu'un navigateur fonctionne, c'est ce que je vous ai dit avant. Ce que vous devez
absolument savoir, c'est ce que je vous ai dit avant. Donc si vous voulez aller vous renseigner
plus sur ce que je viens de vous dire pour avancer encore plus loin, n'hésitez pas. J'espère que cet
épisode vous aura plu. Il a été un petit peu plus long. Du coup, j'ai un petit peu plus bafouillé
aussi. J'en suis désolé, mais c'était pas évident de tenir sur cette longueur-là. J'ai pas l'habitude
et sur ce, je vous dis à très bientôt pour un nouvel épisode de Codes Garage,
décidément, même à la conclusion, j'aurais eu du mal. Bonne journée et à très vite. Ciao !