Client et serveur : le voyage d’une requête (HTTP, DNS)
De quoi parle cet épisode
Entre la saisie d’une adresse web et l’apparition de la page, une requête passe par six étapes : le DNS transforme le nom en IP, TCP serre la main du serveur, TLS s’accorde sur le chiffrement, et seulement ensuite viennent la requête, le travail du serveur et la réponse. Les millisecondes ici sont des valeurs typiques choisies pour la démonstration ; les vraies valeurs varient avec la distance et le serveur, mais la structure est la même : les trois premières étapes n’ont rien à voir avec le travail lui-même, mais prennent souvent la plus grosse part.
D’où les deux optimisations les plus courantes : mettre la réponse DNS en cache et réutiliser une connexion déjà établie pour que la poignée de main et le chiffrement n’aient lieu qu’une fois. Ralentir une étape ajoute autant au total, c’est pourquoi on se demande d’abord : sur quelle étape part le temps ?
Prérequis
Aucun prérequis : vous pouvez commencer ici.
Où on l’utilise dans le monde réel
- Préchargement et préconnexion des navigateurs Des navigateurs comme Chrome résolvent les domaines d’une page et ouvrent des connexions avant que vous cliquiez, regagnant du temps sur les trois premières étapes.
- DNS publics (comme 1.1.1.1 et 8.8.8.8) Ils mettent en cache les résolutions pour des millions d’utilisateurs, si bien que la plupart des requêtes ne vont jamais jusqu’à la source.
- HTTP/2 et HTTP/3 HTTP/2 fait passer plusieurs requêtes sur une même connexion ; HTTP/3 fusionne les poignées de main de transport et de chiffrement, raccourcissant encore les premières étapes.
À voir ensuite
- Conception d’API : REST et RPC Bientôt disponible
- Répartition de charge : partager le trafic entre machines Bientôt disponible
- Cache et CDN : taux de succès contre fraîcheur Bientôt disponible
Épisode 1
Voici l’épisode 1 de la série « Conception de systèmes » (29 prévus).