Dans cet article, je vais présenter les différents mécanismes qui entrent en jeu entre le moment où un utilisateur tape une URL et celui où la page s’affiche dans son navigateur. Effectivement, on parle beaucoup de routage, de commutation, de protocoles divers, mais il faut absolument, pour préparer la certification Cisco CCNA, maitriser l’enchainement des mécanismes dans un cas comme celui présenté ici.
Tout d’abord, considérons notre environnement, celui d’un utilisateur raccordé à Internet depuis chez lui, c’est à dire depuis une offre Internet ADSL classique.
Ce qu’il se passe AVANT de taper l’URL dans le navigateur !
Avant même de taper une URL, l’ordinateur de notre utilisateur a été automatiquement configuré pour accéder au réseau Internet. Passons sur les mécanismes propres aux technologies sans-fil probablement utilisées.
La configuration automatique s’effectue par le protocole DHCP (Dynamic Host Configuration Protocol): le PC diffuse sur le réseau un requête DHCP Discover afin d’identifier un serveur DHCP susceptible de lui proposer une configuration.
Après plusieurs échanges, le PC se voit affecter une configuration IP constituée au minimum de l’adresse IP, le masque de sous-réseau, la passerelle par défaut et un serveur de résolution de noms (DNS).
« www.google.fr »: Browse !
Lorsqu’une URL est tapée dans le navigateur, la première étape impose d’identifier l’adresse IP associée au nom de la machine « www.google.fr ». C’est le protocole DNS qui permet cette identification. Ce protocole interroge le serveur DNS dont l’adresse est connue grâce à la phase de configuration automatique (via DHCP, donc). Le serveur DNS peut être localisé sur le même réseau que votre PC (c’est souvent la box qui joue le rôle de serveur DNS), dans ce cas pas besoin de routage spécifique: les requêtes sont simplement transmises à la box sur le réseau local.
Le serveur retourne donc une adresse IP: par exemple, 173.194.37.159 pour une machine www.google.fr. Cette adresse n’est pas sur le réseau de votre PC, du coup, les segments TCP sont envoyés à la machine distante (173.194.37.159) bien que les trames Ethernet soient transmises pour votre box qui joue le rôle de passerelle par défaut pour votre réseau.
La session TCP est établie après l’échange de segments SYN-ACK selon un rituel appelé « three-way handshake ».
Après l’établissement de la session, la requête HTTP « GET index.html » peut enfin être envoyée. C’est seulement après cette requête que le serveur peut répondre avec les différents éléments de la page qui va permettre d’être interprétée par votre navigateur web pour l’affichage de la célèbre page simplisme de requête google!
C’est tout?
Le fonctionnement décrit ici ne prend pas en compte le fonctionnement de l’accès au réseau WiFi probablement utilisé, le protocole ARP, etc.
Ce type de présentation montre bien l’intérêt d’un découpage de la problématique en couches comme le propose le modèle OSI ou encore TCP/IP…
N’hésitez pas à laisser vos commentaires dans la section « Leave a Comment » ci-dessous !
Laisser un commentaire