Couche application¶

DNS, HTTP, TLS et WebSocket — les protocoles que l'architecte manipule au quotidien.

Le rôle de la couche application¶

La couche application est la seule que les développeurs voient directement. C'est ici que les décisions architecturales se concretisent : quel protocole choisir, comment structurer les échanges, comment sécuriser les communications.

Les couches inférieures fournissent un tuyau — fiable ou non, chiffre ou non. La couche application donne un sens aux données qui y circulent. Comprendre les protocoles applicatifs en profondeur permet de faire des choix eclaires plutôt que de subir les défauts.

DNS — Domain Name System¶

DNS est le système de nommage d'Internet. Il traduit des noms lisibles par l'humain (api.example.com) en adresses IP (93.184.216.34). Sans DNS, il faudrait memoriser des adresses IP — impensable à l'échelle d'Internet.

Résolution DNS¶

La résolution d'un nom DNS implique plusieurs acteurs :

sequenceDiagram
    participant C as Client
    participant R as Resolveur recursif<br>(FAI ou 8.8.8.8)
    participant Root as Serveur racine
    participant TLD as Serveur TLD (.com)
    participant Auth as Serveur autoritaire<br>(example.com)

    C->>R: Quelle est l'IP de api.example.com ?
    Note over R: Pas en cache
    R->>Root: api.example.com ?
    Root-->>R: Demande au serveur .com
    R->>TLD: api.example.com ?
    TLD-->>R: Demande au serveur example.com
    R->>Auth: api.example.com ?
    Auth-->>R: 93.184.216.34 (TTL=300)
    R-->>C: 93.184.216.34
    Note over R: Mise en cache pour 300s

Deux modes de résolution :

• Recursif : le resolveur fait tout le travail pour le client (le cas standard)
• Iteratif : chaque serveur renvoie le client vers le serveur suivant (utilisé entre les serveurs DNS)

Caching et TTL¶

Le caching est au cœur de DNS. Chaque réponse contient un TTL (Time To Live) en secondes. Le resolveur met la réponse en cache pour la durée du TTL. Un TTL court (30s) permet des changements rapides mais augmente la charge sur les serveurs autoritaires. Un TTL long (86400s = 24h) réduit la charge mais rend les changements lents a propager.

Types d'enregistrements¶

DNSSEC¶

DNS n'a aucun mécanisme d'authentification natif. Un attaquant qui intercepte les requêtes DNS peut renvoyer de fausses réponses (DNS spoofing). DNSSEC ajoute des signatures cryptographiques aux réponses DNS, permettant au client de vérifier que la réponse vient bien du serveur autoritaire et n'a pas été modifiée.

L'adoption de DNSSEC reste partielle. La chaîne de confiance est complexe à maintenir, et une signature expiree rend le domaine inaccessible — une panne plus grave que l'absence de DNSSEC.

DNS et architectures distribuées¶

Dans les systèmes distribués, DNS joue des rôles qui vont bien au-delà de la simple résolution de noms :

• Load balancing DNS : un enregistrement A avec plusieurs adresses IP distribué le trafic (round-robin DNS). Simple mais sans health check — si un serveur tombe, les clients continuent à l'interroger pendant la durée du TTL.
• Failover DNS : Route 53 (AWS), Cloud DNS (GCP) et Traffic Manager (Azure) surveillent la sante des endpoints et retirent les adresses IP des serveurs en panne. Le temps de basculement dépend du TTL.
• Service discovery : dans un cluster Kubernetes, chaque Service a un enregistrement DNS interne (my-service.my-namespace.svc.cluster.local). CoreDNS résout ces noms vers les IP des pods. Le TTL est typiquement de 30 secondes.
• GeoDNS : le resolveur renvoie l'adresse IP du serveur le plus proche geographiquement de l'utilisateur. C'est le mécanisme de base des CDN.

HTTP — HyperText Transfer Protocol¶

HTTP est le protocole de la couche application le plus utilise au monde. Il a évolue radicalement en 30 ans, passant d'un protocole textuel simple à un protocole binaire multiplexe chiffre.

HTTP/1.1¶

HTTP/1.1 (RFC 2616, révisé par RFC 7230-7235) a domine le web pendant 20 ans. Ses caractéristiques :

• Textuel : les en-têtes sont en texte clair, lisibles dans un tcpdump
• Requête-réponse : le client envoie une requête, le serveur répond
• Keep-alive : une connexion TCP peut être reutilisee pour plusieurs requêtes (défaut en HTTP/1.1)
• Pipelining : le client peut envoyer plusieurs requêtes sans attendre les réponses (en théorie — rarement utilisé en pratique car les réponses doivent arriver dans l'ordre)

Le problème principal de HTTP/1.1 : le head-of-line blocking. Même avec keep-alive, les requêtes sont traitees sequentiellement sur une connexion. Les navigateurs contournent ce problème en ouvrant 6 connexions TCP parallèles par domaine — un hack qui augmente la charge sur les serveurs et la congestion réseau.

HTTP/2¶

HTTP/2 (RFC 7540, 2015) résout le HOL blocking en introduisant le multiplexage binaire :

• Streams : plusieurs requêtes et réponses en parallèle sur une seule connexion TCP
• Binaire : format binaire au lieu de textuel (plus compact, plus rapide a parser)
• Header compression : HPACK compresse les en-têtes HTTP repetitifs (cookies, user-agent)
• Server push : le serveur peut envoyer des ressources avant que le client les demande
• Priorités : les streams peuvent être priorises

HTTP/3¶

HTTP/3 (RFC 9114, 2022) remplacé TCP par QUIC comme transport. Le gain principal : le multiplexage sans HOL blocking au niveau transport. Quand un paquet QUIC se perd, seul le stream affecte est bloque — les autres streams continuent.

TLS 1.3 — Transport Layer Security¶

TLS sécurisé les communications en fournissant trois garanties :

1. Confidentialite : les données sont chiffrees — un observateur sur le réseau ne voit que du bruit
2. Intégrité : les données ne peuvent pas être modifiées sans détection
3. Authentification : le serveur prouve son identité via un certificat numérique

Le handshake TLS 1.3¶

TLS 1.3 (RFC 8446, 2018) a simplifié le handshake par rapport à TLS 1.2, passant de 2 RTT a 1 RTT :

sequenceDiagram
    participant C as Client
    participant S as Serveur

    C->>S: ClientHello + Key Share + ALPN
    Note over S: Choisit cipher suite<br>Genere cle partagee
    S->>C: ServerHello + Key Share + Certificate + Finished
    Note over C: Verifie certificat<br>Genere cle partagee
    C->>S: Finished + Donnees applicatives
    Note over C,S: Communication chiffree

Les améliorations de TLS 1.3 :

• 1 RTT au lieu de 2 : le client envoie ses parametres de clé dans le premier message
• 0-RTT resumption : les connexions suivantes vers le même serveur peuvent envoyer des données chiffrees dans le premier paquet (avec des risques de replay)
• Ciphers simplifiés : seuls les algorithmes modernes sont supportes (AES-GCM, ChaCha20-Poly1305)
• Forward secrecy obligatoire : même si la clé privee du serveur est compromise plus tard, le trafic passe reste protégé

ALPN — Application-Layer Protocol Negotiation¶

ALPN est une extension TLS qui permet au client et au serveur de negocier le protocole applicatif pendant le handshake TLS. C'est ainsi que le navigateur et le serveur s'accordent sur HTTP/2 ou HTTP/1.1 sans RTT supplémentaire.

Certificats et chaîne de confiance¶

Un certificat TLS lie une clé publique a un nom de domaine. La confiance repose sur une hiérarchie :

1. Autorité de certification racine (Root CA) : pre-installee dans le navigateur/OS
2. Autorité intermédiaire : signee par la racine
3. Certificat du serveur : signe par l'intermédiaire

Let's Encrypt a revolutionne l'écosystème en fournissant des certificats gratuits et automatises (protocole ACME). En 2025, plus de 80% du trafic web est chiffre.

WebSocket¶

HTTP est un protocole requête-réponse : le client parle, le serveur répond. WebSocket (RFC 6455) etablit une connexion full-duplex permanente : le serveur peut envoyer des données au client sans que celui-ci les ait demandées.

Le mécanisme d'upgrade¶

WebSocket commence par une requête HTTP classique avec un en-tête Upgrade :

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

Le serveur répond avec un 101 Switching Protocols, et la connexion TCP est désormais un canal WebSocket bidirectionnel. Les trames WebSocket sont binaires ou textuelles, avec un overhead minimal (2-14 octets d'en-tête par trame).

Cas d'usage¶

gRPC et les alternatives modernes¶

gRPC (Google Remote Procédure Call) utilisé HTTP/2 comme transport et Protocol Buffers comme serialisation. Il supporte quatre patterns de communication :

1. Unaire : requête-réponse classique
2. Server streaming : le serveur envoie un flux de réponses
3. Client streaming : le client envoie un flux de requêtes
4. Bidirectionnel : les deux cotes envoient des flux simultanément

gRPC est particulièrement adapté aux communications inter-services dans un datacenter, ou la latence est faible et le typage fort des Protocol Buffers evite les erreurs de serialisation.

Impact pour l'architecte¶

DNS comme point de défaillance : DNS est souvent le premier maillon de la chaîne. Un TTL trop long empêche le failover. Un TTL trop court surchargé les serveurs DNS. Tester le comportement DNS de son stack technique (runtime, libraries HTTP, service mesh) est un prérequis.

HTTP/2 par défaut : en 2025, il n'y a aucune raison de déployer un nouveau service en HTTP/1.1. HTTP/2 est supporte partout et offre des gains de performance gratuits (multiplexage, compression des en-têtes). HTTP/3 est un bonus pour les clients mobiles.

TLS partout : le chiffrement n'est plus optionnel. Les performances de TLS 1.3 sont suffisantes pour ne pas être un argument contre. Le coût réel de TLS est la gestion des certificats, pas le CPU.

WebSocket avec parcimonie : WebSocket est puissant mais coûteux en infrastructure. Pour les notifications simples, Server-Sent Events (SSE) est plus léger et plus facile à scaler (connexion unidirectionnelle, compatible avec les load balancers HTTP standard).

Chapitre suivant : Performance réseau — bande passante, latence, MTU et les mécanismes de QoS.