Vous consultez actuellement une version archivée de cet article. Consulter la dernière version (v1.0) →
3. Sécurisation TLS 1.2 vs 1.3
L'évolution du protocole TLS divise par deux le temps de négociation cryptographique :
Négociation des suites cryptographiques puis échange de clés Diffie-Hellman séparé.
Coût : 2 RTT complets avant l'envoi des premières données HTTP.
Devine les clés dès le ClientHello initial (0-RTT / 1-RTT).
Coût : 1 seul RTT, soit 50% de latence réseau économisée dès la première poignée de main.
4. Coût Cumulé de Connexion
Bilan du coût matériel d'une nouvelle connexion HTTPS sécurisée (Paris vers USA ~75 ms de RTT) :
5. Réutilisation & Connexions Persistantes
Pour amortir ce coût de démarrage, les serveurs backend réutilisent les connexions :
- Keep-Alive HTTP : Conserve la socket TCP/TLS ouverte après chaque requête pour éliminer les 2 RTT de négociation.
- Pool de Connexions HTTP (
http.Transport) : Réutilise un ensemble pré-établi de sockets vers les microservices tiers. - Règle d'or backend : Ne jamais recréer un
http.Clientpar requête sous peine d'épuiser les ports locaux enTIME_WAIT.
6. HTTP/1.1 : Blocage en Tête
Le protocole historique HTTP/1.1 souffre d'un défaut matériel majeur sur le socket :
Sur une connexion TCP HTTP/1.1, les requêtes sont strictement séquentielles.
Si la première requête est une tâche lente (ex: rapport SQL de 2 secondes), toutes les requêtes suivantes sont paralysées en attente dans la file du socket.
- Contournement coûteux : Les navigateurs ouvraient jusqu'à 6 connexions TCP concurrentes, gaspillant mémoire et ports.
7. HTTP/2 & HTTP/3 QUIC (Multiplexage)
Évolution des protocoles de transport pour éliminer les files d'attente réseau :
Trames binaires entrelacées sur un socket unique avec compression d'en-têtes HPACK.
1 seule connexion TCP.Flux totalement indépendants : la perte d'un paquet n'interrompt pas les flux voisins.
Zéro blocage HOL TCP.Transition 5G/Wi-Fi instantanée sans renégocier la connexion cryptographique.
Continuité de session.8. Le Goulot du Format JSON
Le format JSON domine les APIs Web, mais s'avère particulièrement inefficace pour les échanges internes :
Répétition continue des clés à chaque message (ex: "user_id": 123), surchargeant la bande passante.
Scanner du texte caractère par caractère et convertir des chaînes ASCII en entiers ou flottants.
Instanciation massive de chaînes temporaires et de maps dynamiques allouées sur le tas.
9. Sérialisation Binaire Protocol Buffers
Protocol Buffers (Google Protobuf) remplace le texte brut par un contrat typé et un encodage binaire compact :
1syntax = "proto3";
2
3message TelemetryEvent {
4 uint64 timestamp = 1; // Tag 1 (1 octet au lieu du nom textuel)
5 string session_id = 2; // Tag 2
6 uint32 duration_ms = 3; // Tag 3
7 bool is_success = 4; // Tag 4
8}
- Typage Statique Immuable : Schéma contractuel strict défini dans un fichier
.proto. - Désérialisation Instantanée : Pas de scan de texte, simple copie directe en mémoire alignée.
- Gain Majeur : Messages divisés par 3 à 10 en volume et traités 5 à 10 fois plus vite.
10. Varints & Comparatif JSON vs Protobuf
Encodage compact à longueur variable et comparaison des architectures de communication :
Un uint64 valant 1 occupe 1 seul octet au lieu de 8. Économise jusqu'à 85% de bande passante.
Lisible par un humain dans le navigateur, parfait pour les APIs publiques externes.
Interfaçage universel.Binaire pur compact pour les communications inter-services à fort débit.
Sobriété & Débit max.11. Synthèse de l'Optimisation Réseau
Les 3 règles fondamentales pour accélérer les flux réseau :
Garder les connexions TCP/TLS ouvertes pour éviter de repayer les 2 RTT de négociation.
Pools de connexions.Exploiter le multiplexage binaire pour éliminer le blocage en tête de ligne.
1 socket partagée.Remplacer le JSON par Protobuf pour les communications inter-services à fort débit.
Zéro parsing CPU lourd.TP Fil Rouge (Séance 7) : Distribution gRPC vs REST / JSON
Mission : Transformer le craqueur en architecture distribuée maître-esclaves, comparer l'API HTTP/JSON classique au streaming binaire gRPC Protobuf et mesurer l'impact réseau/CPU sous tir de charge.
1. Architecture Distribuée
Concevoir un nœud maître qui partitionne l'espace de recherche combinatoire de @kAl1 et distribue les sous-plages à des nœuds esclaves (workers distants).
2. Version A : REST / JSON
Implémenter une API HTTP/1.1 classique échangeant les blocs de candidats et les rapports de découverte au format JSON.
3. Version B : gRPC Protobuf
Définir le contrat .proto et implémenter le streaming bidirectionnel binaire sur HTTP/2 multiplexé (zéro parsing texte).
4. Tir de Charge k6 / ghz
Comparer avec un outil de tir de charge l'effondrement de la consommation de bande passante réseau et la baisse d'utilisation CPU.