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.
| 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 |
| Débit moyen en réception — chemin legacy | 389 225 paquets/s |
| Pire exécution | 351 816 paquets/s, soit 2,35× le seuil interne de 150 000 paquets/s |
| Suite de tests | 86 tests sur 86 réussis en Release |
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.
In English
All throughput figures come from a local multi-process bench — three OS processes over real UDP sockets, loopback and in-memory TUN: one million 64-byte IP packets delivered with zero loss, duplication, corruption or reordering, at more than 350,000 packets per second.
Design targets — session-ready, first payload, 0-RTT resumption, relay gate — are kept strictly separate from measurements; we never publish a target as a result.
WAN latency, with its full methodology, will be published here once multi-host qualification is complete.