Que se passe-t-il lorsque vous saisissez une URL dans le navigateur, du début à la fin
- Le protocole HTTP
- J'analyse uniquement les demandes d'URL
- Les choses se rapportent à macOS / Linux
- Phase de recherche DNS
- Établissement de liaison de demande TCP
- Envoi de la demande
- La réponse
- Analyser le HTML
Cet article décrit comment les navigateurs exécutent les demandes de page à l'aide du protocole HTTP / 1.1
Si vous avez déjà fait une interview, on vous a peut-être demandé: "Que se passe-t-il lorsque vous tapez quelque chose dans le champ de recherche Google et appuyez sur Entrée".
C'est l'une des questions les plus fréquemment posées. Les gens veulent juste voir si vous pouvez expliquer certains concepts assez basiques et si vous avez une idée du fonctionnement réel d'Internet.
Dans cet article, j'analyserai ce qui se passe lorsque vous tapez une URL dans la barre d'adresse de votre navigateur et appuyez sur Entrée.
C'est un sujet très intéressant à disséquer dans un article de blog, car il touche à de nombreuses technologies dans lesquelles je peux plonger dans des articles séparés.
C'est une technologie qui est très rarement modifiée et qui alimente l'un des écosystèmes les plus complexes et les plus vastes jamais construits par les humains.
Le protocole HTTP
Tout d'abord, je mentionne notamment HTTPS car les choses sont différentes d'une connexion HTTPS.
J'analyse uniquement les demandes d'URL
Les navigateurs modernes ont la capacité de savoir si ce que vous avez écrit dans la barre d'adresse est une URL réelle ou un terme de recherche, et ils utiliseront le moteur de recherche par défaut s'il ne s'agit pas d'une URL valide.
Je suppose que vous tapez une URL réelle.
Lorsque vous entrez l'URL et appuyez sur Entrée, le navigateur crée d'abord l'URL complète.
Si vous venez d'entrer un domaine, commeflaviocopes.com
, le navigateur par défaut ajouteraHTTP://
à lui, par défaut au protocole HTTP.
Les choses se rapportent à macOS / Linux
Juste FYI. Windows peut faire certaines choses légèrement différemment.
Phase de recherche DNS
Le navigateur lance leDNSrecherche pour obtenir l'adresse IP du serveur.
Le nom de domaine est un raccourci pratique pour nous, les humains, mais Internet est organisé de telle manière que les ordinateurs peuvent rechercher l'emplacement exact d'un serveur via son adresse IP, qui est un ensemble de nombres comme222.324.3.1
(IPv4).
Tout d'abord, il vérifie le cache local DNS, pour voir si le domaine a déjà été résolu récemment.
Chrome dispose d'un visualiseur de cache DNS pratique que vous pouvez voir surchrome: // net-internals / # dns
Si rien n'y est trouvé, le navigateur utilise le résolveur DNS, en utilisant legethostbyname
Appel système POSIX pour récupérer les informations sur l'hôte.
gethostbyname
gethostbyname
regarde d'abord dans le fichier d'hôtes local, qui sur macOS ou Linux se trouve dans/etc/hosts
, pour voir si le système fournit les informations localement.
Si cela ne donne aucune information sur le domaine, le système fait une demande au serveur DNS.
L'adresse du serveur DNS est stockée dans les préférences système.
Ce sont 2 serveurs DNS populaires:
8.8.8.8
: le serveur DNS public de Google1.1.1.1
: le serveur DNS CloudFlare
La plupart des gens utilisent le serveur DNS fourni par leur fournisseur d'accès Internet.
Le navigateur exécute la requête DNS en utilisant le protocole UDP.
TCP et UDP sont deux des protocoles fondamentaux de la mise en réseau informatique. Ils se situent au même niveau conceptuel, mais TCP est orienté connexion, tandis que UDP est un protocole sans connexion, plus léger, utilisé pour envoyer des messages avec peu de frais généraux.
La manière dont la requête UDP est effectuée n'est pas dans le cadre de ce didacticiel
Le serveur DNS peut avoir l'adresse IP du domaine dans le cache. Sinon, il demandera auserveur DNS racine. C'est un système (composé de 13 serveurs réels, répartis à travers la planète) qui gère l'intégralité de l'Internet.
Le serveur DNS faitne pasconnaître l'adresse de chaque nom de domaine de la planète.
Ce qu'il sait, c'est où lerésolveurs DNS de premier niveausommes.
Un domaine de premier niveau est l'extension de domaine:.com
,.it
,.pizza
etc.
Une fois que le serveur DNS racine reçoit la demande, il la transmet à ce serveur DNS de domaine de premier niveau (TLD).
Dites que vous recherchezflaviocopes.com
. Le serveur DNS du domaine racine renvoie l'adresse IP du serveur .com TLD.
Maintenant, notre résolveur DNS mettra en cache l'adresse IP de ce serveur TLD, il n'a donc pas à le demander à nouveau au serveur DNS racine.
Le serveur DNS TLD aura les adresses IP des serveurs de noms faisant autorité pour le domaine que nous recherchons.
Comment? Lorsque vous achetez un domaine, le registraire de domaine envoie le TDL approprié aux serveurs de noms. Lorsque vous mettez à jour les serveurs de noms (par exemple, lorsque vous changez de fournisseur d'hébergement), ces informations seront automatiquement mises à jour par votre registraire de domaine.
Ce sont les serveurs DNS du fournisseur d'hébergement. Ils sont généralement plus de 1, pour servir de sauvegarde.
Par exemple:
ns1.dreamhost.com
ns2.dreamhost.com
ns3.dreamhost.com
Le résolveur DNS commence par le premier et essaie de demander l'adresse IP du domaine (avec le sous-domaine également) que vous recherchez.
C'est la source ultime de vérité pour l'adresse IP.
Maintenant que nous avons l'adresse IP, nous pouvons continuer notre voyage.
Établissement de liaison de demande TCP
Avec l'adresse IP du serveur disponible, le navigateur peut désormais établir une connexion TCP vers celui-ci.
Une connexion TCP nécessite un peu de négociation avant de pouvoir être complètement initialisée et vous pouvez commencer à envoyer des données.
Une fois la connexion établie, nous pouvons envoyer la demande
Envoi de la demande
La requête est un document en texte clair structuré d'une manière précise déterminée par le protocole de communication.
Il est composé de 3 parties:
- la ligne de demande
- l'en-tête de la demande
- le corps de la requête
La ligne de demande
La ligne de demande définit, sur une seule ligne:
- la méthode HTTP
- l'emplacement de la ressource
- la version du protocole
Exemple:
GET / HTTP/1.1
L'en-tête de la demande
L'en-tête de la demande est un ensemble defield: value
paires qui définissent certaines valeurs.
Il y a 2 champs obligatoires, dont l'un estHost
, et l'autre estConnection
, alors que tous les autres champs sont facultatifs:
Host: flaviocopes.com
Connection: close
Host
indique le nom de domaine que nous voulons cibler, tandis queConnection
est toujours réglé surclose
sauf si la connexion doit rester ouverte.
Certains des champs d'en-tête les plus utilisés sont:
Origin
Accept
Accept-Encoding
Cookie
Cache-Control
Dnt
mais il en existe beaucoup d'autres.
La partie d'en-tête se termine par une ligne vide.
Le corps de la requête
Le corps de la requête est facultatif, non utilisé dans les requêtes GET mais très utilisé dans les requêtes POST et parfois dans d'autres verbes également, et il peut contenir des données dansJSONformat.
Puisque nous analysons maintenant une requête GET, le corps est vide et nous ne l'examinerons pas davantage.
La réponse
Une fois la demande envoyée, le serveur la traite et renvoie une réponse.
La réponse commence par le code d'état et le message d'état. Si la requête aboutit et renvoie un 200, elle commencera par:
200 OK
La demande peut renvoyer un code d'état et un message différents, comme l'un de ceux-ci:
404 Not Found
403 Forbidden
301 Moved Permanently
500 Internal Server Error
304 Not Modified
401 Unauthorized
La réponse contient alors une liste d'en-têtes HTTP et le corps de la réponse (qui, puisque nous faisons la demande dans le navigateur, va être HTML)
Analyser le HTML
Le navigateur a maintenant reçu le HTML et commence à l'analyser, et répétera exactement le même processus que nous avons fait pour toutes les ressources requises par la page:
- Fichiers CSS
- images
- le favicon
- Fichiers JavaScript
- …
La façon dont les navigateurs affichent la page est alors hors de portée, mais il est important de comprendre que le processus que j'ai décrit ne concerne pas uniquement les pages HTML, mais tout élément diffusé via HTTP.
Plus de didacticiels réseau:
- Introduction aux WebSockets
- Comment fonctionnent les requêtes HTTP
- La liste des en-têtes de requête HTTP
- La liste des en-têtes de réponse HTTP
- HTTP vs HTTPS
- Qu'est-ce qu'une RFC?
- Le protocole HTTP
- Le protocole HTTPS
- Le guide curl des requêtes HTTP
- Mise en cache dans HTTP
- La liste des codes d'état HTTP
- Qu'est-ce qu'un CDN?
- Le protocole HTTP / 2
- Qu'est-ce qu'un port
- DNS, système de noms de domaine
- Le protocole TCP
- Le protocole UDP
- Une introduction aux API REST
- Comment installer un certificat SSL local dans macOS
- Comment générer un certificat SSL local
- Comment configurer Nginx pour HTTPS
- Un proxy inverse nginx simple pour servir plusieurs applications Node.js à partir de sous-dossiers
- Qu'est-ce qu'un proxy inverse?