Networking

Ce que le DNS fait vraiment à chaque requête Chaque requête vers example.com commence par une recherche qui n’a rien à voir avec votre application : il faut d’abord transformer ce nom en adresse IP avant qu’un seul paquet TCP ne quitte la machine. Cette traduction, c’est le DNS, le Domain Name System, et elle intervient à chaque requête, que le client soit un navigateur, curl, ou un service backend qui en appelle un autre par son hostname. ...

Ce que TLS protège vraiment sur une connexion HTTPS Chargez une page en http:// en clair sur un réseau que vous ne contrôlez pas, un aéroport ou le routeur d’un café, et tout ce que vous envoyez circule en texte lisible. Le chemin de l’URL, les cookies, les champs du formulaire, le mot de passe dans un POST de connexion : n’importe qui sur ce réseau avec un sniffer de paquets les lit au passage. TLS, Transport Layer Security, est le protocole qui bloque cela. Il se place entre TCP et le protocole applicatif, si bien que quand HTTP commence à parler, la connexion est déjà chiffrée et rattachée à une identité serveur vérifiée. HTTPS, c’est HTTP exécuté sur cette connexion au lieu d’une connexion en clair. ...

Ce qu’un CDN fait réellement à une requête Un utilisateur à Tokyo qui charge une page hébergée sur un serveur en Virginie paie cette distance deux fois : une fois pour que la requête arrive, une fois pour que la réponse revienne. La fibre optique transporte les données à une fraction fixe de la vitesse de la lumière, et ce seul trajet coûte déjà 150 à 200 ms d’aller-retour avant même que l’origine n’ait commencé à travailler. Ajoutez une requête en base de données et un ou deux sauts réseau lents, et une page qui semble instantanée juste à côté devient poussive à l’autre bout de la planète. ...

Ce qui se trouve entre le navigateur et votre app Pointez votre navigateur vers example.com et la requête ne touche jamais le processus qui exécute votre code. Elle rencontre d’abord autre chose : un serveur qui lit la requête, décide quel backend doit répondre, la lui transmet, puis renvoie la réponse comme s’il l’avait produite lui-même. Ce serveur, c’est un reverse proxy. Nginx, Caddy, Traefik et HAProxy font tous ce travail, tout comme le load balancer placé devant un cluster Kubernetes. Le schéma ne change jamais : les clients ne parlent qu’au proxy, à rien d’autre. Les serveurs réels restent derrière, en nombre quelconque et où qu’ils tournent. ...

Pourquoi deux conteneurs sur le même hôte ne se voient pas par défaut Lancez Postgres et votre API avec un simple docker run, et l’API n’arrive pas à joindre la base de données, alors que les deux conteneurs tournent sur la même machine. 1 2 docker run -d --name db postgres:16 docker run -d --name api myapp Les deux atterrissent sur la bridge par défaut de Docker, celle que reçoit tout conteneur Docker sauf indication contraire. Ils obtiennent une adresse IP. Ce qu’ils n’obtiennent pas, c’est un moyen de se trouver par leur nom : l’API devrait donc coder en dur l’IP interne de la base de données, une adresse qui change à chaque redémarrage du conteneur. ...