Comment fonctionnent les requêtes HTTP

Que se passe-t-il lorsque vous saisissez une URL dans le navigateur, du début à la fin

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 legethostbynameAppel système POSIX pour récupérer les informations sur l'hôte.

gethostbyname

gethostbynameregarde 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 Google
1.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,.pizzaetc.

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: valuepaires 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

Hostindique le nom de domaine que nous voulons cibler, tandis queConnectionest toujours réglé surclosesauf 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.