Documentation
Performances : mesures et objectifs
Cette page sépare rigoureusement trois choses : ce que nous avons mesuré, ce qui est démontré par test, et ce que l’architecture vise. Un chiffre mesuré est toujours accompagné de sa condition de banc ; un objectif de conception est toujours annoncé comme tel. Nous ne publions jamais un objectif comme s’il était une mesure.
MesuréCe que nous avons mesuré
Nos mesures viennent d'un banc multiprocessus : trois processus OS distincts qui échangent par de vraies sockets UDP, et non une simulation en mémoire dans un seul processus. Toutes les valeurs ci-dessous proviennent de ce banc.
Pourquoi avoir construit un test aussi exigeant ? Le référentiel de qualification Oracle visé impose que la capacité d'une pile QUIC soit exprimée en paquets par seconde et par CPU — paquets/s/CPU — afin de mesurer le coût réel du traitement protocolaire sans le masquer en ajoutant des vCPU. Notre gate fixe donc un minimum de 150 000 paquets/s/CPU. Le banc envoie un million de paquets IP de 64 octets : cette petite taille maximise le nombre de décisions, de protections cryptographiques, d'ACK et de passages dans la pile par unité de données. C'est la condition qui met réellement le CPU à l'épreuve.
| Indicateur | Résultat mesuré |
|---|---|
| Paquets délivrés | 1 000 000 de paquets IP de 64 octets, zéro perte, zéro duplication, zéro corruption, zéro réordonnancement |
| Débit moyen en réception — chemin TLS 1.3 à clés publiques brutes | 366 543 paquets/s/CPU |
| Pire exécution | 351 816 paquets/s/CPU, soit 2,35× le gate de qualification de 150 000 paquets/s/CPU |
| Suite de tests | 86 tests sur 86 réussis en Release |
Développer SwQuic a été une sacrée histoire. QUIC ne consiste pas à poser du chiffrement sur UDP : il faut maîtriser simultanément le handshake TLS 1.3, les espaces de numéros de paquets, la protection des en-têtes, les ACK, la détection de pertes, la congestion, le contrôle de flux, la migration de chemin et les datagrammes. Les premiers bancs ont révélé des défauts d'encapsulation et de comptabilité que des tests plus confortables auraient laissés passer. À force de corrections, de mesures et d'optimisations, cet acharnement d'ingénierie a produit une pile qui livre un million de paquets sans perte et dont la pire exécution dépasse encore le gate de 2,35×.
Les normes implémentées et vérifiées dans SwQuic
La condition Oracle porte sur la performance par CPU ; la conformité protocolaire, elle, vient des standards IETF et de leurs vecteurs de test. Le chemin chronométré ci-dessus est le transport QUIC/TLS 1.3 à clés publiques brutes. SwQuic couvre également les couches HTTP/3 et WebTransport utilisées par la plateforme.
- RFC 9000 — transport QUIC v1 : paquets, frames, streams, contrôle de flux, migration et validation de chemin.
- RFC 9001 — utilisation de TLS dans QUIC, protection des paquets et séparation des niveaux cryptographiques.
- RFC 9002 — détection des pertes, PTO et contrôle de congestion NewReno.
- RFC 8446 et RFC 8448 — TLS 1.3 et validation du calendrier de clés contre les vecteurs officiels.
- RFC 7250 — authentification TLS par clés publiques brutes, utilisée par le chemin mesuré ; RFC 7748 et RFC 8410 pour X25519 et les identités modernes associées.
- RFC 9221 — extension QUIC DATAGRAM pour les données temps réel qui ne doivent pas attendre une retransmission.
- RFC 9114 et RFC 9204 — HTTP/3 et QPACK ; RFC 7301 pour la négociation ALPN h3.
- RFC 9220 et RFC 9297 — mécanismes Extended CONNECT sur HTTP/3, HTTP Datagrams et Capsule Protocol employés par le transport navigateur.
DémontréCe qui est démontré par test (non chronométré)
Au-delà des débits, plusieurs comportements sont démontrés par des tests de bout en bout réels. Ils ne sont pas chronométrés : nous vérifions qu'ils fonctionnent, pas encore à quelle vitesse.
- Bout-en-bout réel entre deux nœuds via une vigie : TLS 1.3 à clés publiques brutes mutuel, élection déterministe du chemin, livraison bidirectionnelle.
- Migration QUIC réelle vers un nouveau tuple d'adresses, sans rompre la session.
- Traversée fail-closed : en cas d'échec, la connexion se ferme au lieu de retomber sur un chemin non protégé.
- Vigie embarquée (jalon 1).
ConceptionCe que l'architecture vise (objectifs, pas des mesures)
L'architecture vise des objectifs de service. Ce sont des cibles de conception, pas des mesures : nous les publions pour dire ce que le système doit tenir, non ce qu'il aurait déjà démontré.
- Session prête : p95 ≤ 1 RTT relayé + 100 ms.
- Premier payload : p95 ≤ 1,5 × RTT + 100 ms.
- Reprise 0-RTT : p95 ≤ 0,5 × RTT + 100 ms.
- Élection d'un chemin direct simple : p95 < 3 s.
- Datagrammes strictement prioritaires sur les flux de service.
- Gate relais : ≥ 1 Gbps et ≥ 150 000 pps par cœur.
Pourquoi la latence en direct est celle de votre réseau
En direct, sur un chemin direct validé, VIGIL-MESH n'ajoute qu'une seule couche de chiffrement de bout en bout au trajet réseau : pas de tunnel-dans-tunnel, pas de double chiffrement. La latence que vous ressentez est donc essentiellement celle de votre propre réseau.
L'objectif de conception est que le chemin élu reste à moins de max(5 ms, 10 %) du meilleur chemin validé.
Où nous en sommes
Nous avons un cœur de protocole et de transport avancé, plusieurs chemins de bout en bout réels démontrés en multiprocessus et une architecture conçue pour la continuité réseau. Nous finançons maintenant la qualification multi-hôte, les plateformes et les premiers pilotes.