Vous êtes-vous déjà interrogé sur la série complexe d'événements qui se produisent dans la fraction de seconde entre la saisie de « google.com » dans votre navigateur et l'apparition de la page de recherche familière ? Dans cette exploration détaillée, nous découvrirons le monde fascinant des technologies Web, des protocoles de réseau et la danse complexe des données qui rendent nos expériences en ligne possibles.

1. Le voyage commence : votre navigateur et votre système d'exploitation

1.1 Premiers pas du navigateur

Lorsque vous tapez « google.com » et appuyez sur Entrée, votre navigateur entre en action :

1. Analyse d'URL : le navigateur analyse d'abord l'URL que vous avez saisie. Il identifie le protocole (dans ce cas, implicite "http://" ou "https://"), le nom de domaine ("google.com") et tout chemin d'accès ou paramètres de requête supplémentaires (aucun dans cet exemple simple) .

2. Vérification HSTS : pour les sites Web soucieux de la sécurité comme Google, le navigateur vérifie sa liste HTTP Strict Transport Security (HSTS). Si google.com figure sur cette liste (ce qui est le cas), le navigateur met automatiquement à niveau la requête vers HTTPS.

3. Vérification du cache : avant de contacter le réseau, le navigateur vérifie son cache local. Ce cache stocke les informations des visites précédentes, notamment :

   • Cache DNS : L'adresse IP associée à google.com
   • Cache de ressources : fichiers HTML, CSS, JavaScript et images de la page d'accueil de Google

Si l'un de ces éléments est trouvé et toujours valide (non expiré), le navigateur peut ignorer certaines des étapes suivantes.

1.2 Rôle du système d'exploitation

Si le navigateur ne trouve pas les informations nécessaires dans son cache, il se tourne vers le système d'exploitation (OS) pour obtenir de l'aide :

1. Vérification du fichier hosts : le système d'exploitation recherche d'abord dans le fichier "hosts" local. Ce fichier peut mapper des noms de domaine sur des adresses IP, contournant potentiellement la recherche DNS. Cependant, pour la plupart des utilisateurs, google.com ne figurera pas dans ce fichier.

2. Cache client DNS : le système d'exploitation gère son propre cache DNS, distinct de celui du navigateur. Il vérifie ici ensuite.

3. Configuration du résolveur : si l'adresse IP n'est pas dans le cache local, le système d'exploitation se prépare à demander à un serveur DNS. Il lit sa configuration réseau pour savoir quel serveur DNS interroger (généralement fourni par votre fournisseur d'accès Internet ou défini manuellement).

2. Résolution DNS : recherche de l'adresse de Google

Si l'adresse IP de google.com n'est pas mise en cache, nous devons demander au système de noms de domaine (DNS) de traduire le "google.com" lisible par l'homme en une adresse IP utilisable par machine.

2.1 La hiérarchie DNS

Le DNS est organisé selon une structure hiérarchique :

1. Serveurs racine : au sommet de la hiérarchie. Ils savent où trouver les serveurs faisant autorité pour les domaines de premier niveau (TLD) comme .com, .org, .net, etc.

2. Serveurs TLD : ces serveurs connaissent tous les domaines enregistrés sous leur TLD. Le serveur TLD .com connaît google.com.

3. Serveurs de noms faisant autorité : ils sont chargés de tout savoir sur un domaine spécifique, y compris sa ou ses adresses IP.

2.2 Le processus de requête DNS

1. Résolveur récursif : le serveur DNS de votre FAI (ou un autre résolveur configuré) reçoit la requête pour google.com. Si la réponse n'est pas mise en cache, il démarre un processus récursif :

• Il demande à un serveur racine à propos de .com
• Le serveur racine le renvoie à un serveur TLD .com
• Il interroge le serveur TLD .com à propos de google.com
• Le serveur .com le renvoie aux serveurs de noms faisant autorité de Google
• Il demande au serveur de noms de Google l'adresse IP de google.com
• Le serveur de noms de Google répond avec l'adresse IP

1. Mise en cache : chaque étape de ce processus peut impliquer la mise en cache, le parcours complet n'est donc pas toujours nécessaire. Le résolveur met en cache le résultat final, généralement pendant une durée spécifiée par Google (le Time To Live, ou TTL).

2. Équilibrage de charge : les grands services comme Google renvoient souvent plusieurs adresses IP. Cela permet un équilibrage de charge et une fiabilité améliorée.

2.3 Exemple de recherche DNS

Disons que la recherche DNS renvoie le résultat (simplifié) suivant :

google.com.     300    IN    A     172.217.167.78

Cela signifie:

• Le domaine est google.com
• L'enregistrement a une durée de vie maximale de 300 secondes (5 minutes)
• Il s'agit d'un enregistrement Internet (IN)
• Il s'agit d'un type d'enregistrement Adresse (A)
• L'adresse IP est 172.217.167.78

3. Établir une connexion : TCP/IP

Maintenant que nous avons l'adresse IP de Google, il est temps d'établir une connexion.

3.1 La pile TCP/IP

1. Couche d'application : votre navigateur fonctionne ici, en utilisant HTTP(S) pour communiquer.

2. Couche de transport : TCP est utilisé ici pour garantir une livraison fiable et ordonnée des données.

3. Couche Internet : IP est utilisé pour acheminer les paquets entre les réseaux.

4. Couche de liaison : cela gère la transmission physique des données, que ce soit via Ethernet, Wi-Fi, réseaux cellulaires, etc.

3.2 La poignée de main TCP

Pour établir une connexion, une négociation à trois se produit :

1. SYN : votre ordinateur envoie un paquet SYN (synchronisation) au serveur de Google.
2. SYN-ACK : le serveur de Google répond avec un paquet SYN-ACK.
3. ACK : votre ordinateur renvoie un paquet ACK (accusé de réception).

Ce processus établit des numéros de séquence pour la conversation, garantissant que les paquets peuvent être correctement ordonnés et que tout paquet perdu peut être détecté et retransmis.

3.3 Prise de contact TLS

Pour les connexions HTTPS (que Google utilise), une négociation TLS (Transport Layer Security) supplémentaire se produit :

1. Client Bonjour : votre navigateur envoie les versions SSL/TLS prises en charge, les suites de chiffrement et un nombre aléatoire.
2. Serveur Bonjour : Le serveur choisit la version SSL/TLS et la suite de chiffrement, envoie son certificat et un autre numéro aléatoire.
3. Authentification : votre navigateur vérifie le certificat du serveur auprès d'une autorité de certification de confiance.
4. Échange de clés : une clé symétrique sécurisée est établie pour chiffrer la session.

4. Requête HTTP : demander la page

Une fois une connexion sécurisée établie, votre navigateur envoie une requête HTTP GET pour la page d'accueil de Google.

4.1 Exemple de requête HTTP

GET / HTTP/2
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0
Accept: text/html,application/xhtml xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1

Cette demande comprend :

• La méthode (GET) et le chemin (/) que nous demandons
• La version HTTP (HTTP/2)*
• Divers en-têtes fournissant des informations sur le navigateur et ses capacités *Remarque : HTTP/2 fait référence à HTTPS uniquement, et non à la connexion http. Cette requête est envoyée via une connexion HTTPS déjà établie, même si les en-têtes ne mentionnent pas explicitement HTTPS.

5. Traitement du serveur : Google répond

Les serveurs de Google reçoivent cette demande et la traitent. Cela peut impliquer :

1. Équilibrage de charge : répartition de la requête entre plusieurs serveurs.
2. Serveurs d'applications : exécution de code pour générer une réponse.
3. Requêtes de base de données : récupération de données personnalisées ou de suggestions de recherche.
4. Mise en cache : récupération du contenu pré-généré lorsque cela est possible.

6. Réponse HTTP : envoi de la page

Le serveur de Google renvoie une réponse HTTP, qui pourrait ressembler à ceci :

HTTP/2 200 OK
Content-Type: text/html; charset=UTF-8
Date: Sat, 21 Sep 2024 12:00:00 GMT
Expires: Sat, 21 Sep 2024 12:00:00 GMT
Cache-Control: private, max-age=0
Server: gws
X-XSS-Protection: 0
X-Frame-Options: SAMEORIGIN
[... other headers ...]



  
    
    
    [... rest of the HTML ...]
  
  
    [... body content ...]
  

Cette réponse comprend :

• Code d'état (200 OK)
• Divers en-têtes fournissant des métadonnées sur la réponse
• Le contenu HTML de la page

7. Rendu : donner vie à la page

Votre navigateur dispose désormais du contenu HTML et commence à afficher la page :

1. Analyse HTML : le navigateur analyse le code HTML, créant ainsi le modèle d'objet de document (DOM).

2. Demande de ressources supplémentaires : lorsqu'il rencontre des liens vers CSS, JavaScript, des images, etc., il envoie des requêtes HTTP supplémentaires pour ces ressources.

3. Analyse CSS : le navigateur analyse le CSS et applique des styles aux éléments du DOM, créant ainsi le modèle d'objet CSS (CSSOM).

4. Exécution de JavaScript : le navigateur exécute JavaScript, ce qui peut modifier le DOM et le CSSOM.

5. Rendu : le navigateur utilise le DOM et le CSSOM finaux pour afficher la page sur votre écran.

Conclusion

Ce qui semble être une action simple : taper "google.com" et appuyer sur Entrée - implique en réalité une série complexe d'étapes, depuis les recherches DNS et les protocoles réseau jusqu'au traitement côté serveur et au rendu côté client. Cette danse complexe se déroule en quelques millisecondes seulement, mettant en valeur l'incroyable ingénierie qui alimente nos expériences en ligne.

La compréhension de ces processus satisfait non seulement notre curiosité, mais aide également les développeurs Web et les professionnels de l'informatique à optimiser les sites Web, à résoudre les problèmes et à créer des applications Web plus efficaces et plus sécurisées. La prochaine fois que vous visiterez un site Web, prenez un moment pour apprécier les merveilles technologiques qui opèrent en coulisses pour amener le Web sur votre écran !

Les images de ce blog sont générées par l'IA.

Lisez également HTTP vs HTTPS quelle est la différence entre eux