La précision d'emblée reste la même : le projet est en pré-alpha, la première publication ne concerne que les VPS avec KVM, et les chiffres mesurent du code, des tests et certaines expériences précises, pas une maturité en production.

À quoi cela ressemblait dans le temps

Depuis l'article précédent (31 octobre à 23:00) jusqu'à aujourd'hui (1er novembre à 20:41), le dépôt compte 59 nouveaux commits, 178 au total. Tous sont nés en un seul jour calendaire, donc la même mise en garde qu'avant s'applique : le projet se construit avec Claude Code (les commits portent Co-Authored-By: Claude), le plan, le code, les tests et les ADR naissent en boucles courtes et fermées, et les chiffres ci-dessous parlent de la quantité de code et de vérifications, pas de la part de travail humain qu'ils contiennent.

Les chiffres sont calculés avec la même méthode que dans l'article précédent : tous les fichiers .rs hors de vendor/ et fuzz/, les fonctions #[test], les titres ## ADR- dans docs/DECISIONS.md.

On a travaillé en parallèle sur plusieurs branches, donc l'ordre des commits n'est pas strictement l'ordre du travail. Les ADR sont numérotés jusqu'à 232, mais la numérotation a des trous (une partie a été renumérotée lors de la fusion de branches) ; nous comptons les titres, pas le plus grand numéro. Publications : v0.2.0 (1er novembre, 18:45 UTC) et v0.2.1 (1er novembre, 20:22 UTC), toutes deux marquées comme pré-publication.

H6 : SQLite en mode utilisateur

Ce que nous avions prévu. SQLite, c'est 254 268 lignes de C qui analysent la base, le WAL et le journal depuis le disque, et le disque peut être fabriqué ou modifié. Jusque-là, il tournait dans le noyau, avec les droits du noyau. Ce que nous avons construit (ADR-210 à ADR-212) : SQLite, ses parties de libc et son heap ont été déplacés dans un programme séparé, dbworker, qui s'exécute en EL0 (aarch64) ou en ring 3 (x86_64), dans son propre espace d'adressage. Le noyau ne lie plus SQLite. Le worker dialogue avec le noyau par une fenêtre de mémoire partagée et douze appels système, et chaque longueur et chaque décalage renvoyés sont vérifiés avant usage. Une erreur dans le worker (accès interdit, instruction non définie, budget de temps de 30 s dépassé) termine l'appel, le worker redémarre et la base se rouvre à partir du WAL comme au démarrage ; après 5 redémarrages en une minute, le stockage est déclaré défectueux au lieu de redémarrer indéfiniment.

Le coût, mesuré sur aarch64 sous HVF, avec la même VM, noyau avec SQLite intégré contre noyau avec worker, six exécutions alternées de chaque :

Les écritures sur disque (1572) et les flushs (319) sont identiques, comme il se doit. Ce qui n'est pas isolé : le noyau continue de faire confiance à ce que le worker renvoie, après vérification de la forme. Un worker compromis peut mentir (par exemple renvoyer une liste vide de certificats révoqués, et ainsi les « dé-révoquer »), mais il ne peut lire ni la mémoire du noyau, ni les clés TLS, ni les clés de ticket. Il n'y a pas de KPTI, donc les fuites de type Spectre/Meltdown ne sont pas empêchées et nous n'affirmons rien à leur sujet ; la clé PAC est partagée par EL0 et EL1. Sur x86_64, nous n'avons pas mesuré le coût de la bascule sur KVM (sous TCG le chiffre n'aurait aucun sens), et le fuzzing du worker et du protocole n'est pas terminé. Le groupe de tests de stockage (79 scénarios, chacun fait tourner SQLite dans le worker) passe sur aarch64 HVF et x86_64 TCG, et 76 sur aarch64 TCG (un est ignoré parce que TCG n'a pas MSI-X).

H7 est clos, mais pas comme nous l'avions annoncé. La borne inférieure du temps (ADR-050) et SNTP avec consensus (T1) couvrent le périmètre de H7 ; NTS (RFC 8915) reste hors périmètre et est consigné comme risque résiduel, et non comme quelque chose qui fonctionne. Nous ne considérons pas que la sécurité du temps est « résolue », mais que sa partie démontrable est terminée.

Une nouvelle option réseau. Contabo ne donne pas de DHCP à un ISO personnalisé, donc jusque-là le VPS exigeait une autre image que la VM de labo. Désormais network.mode = "auto" (ADR-214) interroge d'abord DHCP et, si aucun bail n'arrive dans le délai fixé (dhcp_timeout_s, 15 s par défaut) ou si le bail est perdu, applique l'adresse statique indiquée. Essayé à la main sur QEMU (avec DHCP il utilise le bail, sans réseau il revient à l'adresse statique après 5 s) ; il n'existe pas encore de scénario de smoke test pour cela.

X11 : comparaison avec Mosquitto sur le même VPS

Le même type de machine que dans l'article précédent (Contabo, 4 vCPU AMD EPYC, 8 GiB), charge depuis un hôte Linux à 15 ms, TLS 1.3 mutuel avec les mêmes certificats des deux côtés, Mosquitto 2.0.21 sur Debian 13 sans persistance. La méthode et les décisions sont dans l'ADR-213, les données brutes dans docs/perf-results/. Médiane de trois exécutions.

Ce que cela signifie, et ce que cela ne signifie pas. Les poignées de main sont des bornes inférieures pour les deux serveurs : le générateur de charge est une VM partagée avec 60 à 70% de temps processeur volé et, à 128 threads, il était proche de sa propre limite, alors que les cœurs de travail d'urMQTT n'étaient occupés qu'à 12 à 13%. Le rapport à 128 clients (environ 2,2 fois) est le plus significatif ; à 32 et 64, on mesure surtout l'attente des clients. Les chiffres de mémoire ne comptent pas la même chose (heap du noyau contre RSS du processus), donc « environ 50 fois moins » est un ordre de grandeur, pas un rapport précis. La latence de 14 ms est un aller-retour réseau (environ 15 ms), donc « pas de temps de broker mesurable » ; les queues (p99 autour de 100 à 200 ms) sont dominées chez les deux brokers par des hôtes partagés. Nous n'affirmons pas les différences inférieures à environ 20%.

Ce qui n'a pas joué en notre faveur et est resté dans les tableaux : un seul flux TCP à travers urMQTT portait 2 à 8 fois moins qu'à travers Mosquitto, avec des variations de zéro à 7,7 milliers de messages par seconde entre les exécutions, et le watchdog de 20 ms du handler coupait des connexions vivantes lorsque l'hyperviseur arrêtait un vCPU (dans la configuration de production action = "drop", 6 à 8 connexions par exécution lors d'un déluge QoS 0). Les deux sont décrits dans la section suivante, car ils avaient des causes dans notre code.

Pourquoi un seul flux était lent : des causes, pas des excuses

Le plus simple aurait été de dire « VPS partagé ». Nous ne l'avons pas fait : avec le même VPS et la même méthode, nous avons cherché des causes. Cinq ont été trouvées, quatre dans le chemin des données et une dans le watchdog (ADR-221 à ADR-224) :

Les arrêts sont réels : sur ce VPS, les cœurs 0 à 2 avaient une médiane de 36 à 80 ticks en retard par 5 secondes, et l'arrêt le plus long dans la fenêtre était d'une médiane d'environ 70 ms et jusqu'à 0,9 s (cœur 3, base et journal : jusqu'à 1,55 s), alors que l'hôte ne signale pas de temps volé (host steal 0 us). C'est pourquoi le watchdog avait besoin d'une autre horloge, pas d'un budget plus grand.

Watchdog : 148 connexions coupées en 30 exécutions chargées avant, 0 en 24 exécutions après ; sur un dispositif local qui retarde et perd des trames, avec 0,1% de perte, un flux de 64 B à 14,3k messages/s (noyau X11) en a maintenant 41,0k, et avec 0,5%, 5,0k passent à 17,7k.

Ce que cela ne dit pas. urMQTT n'est toujours pas plus rapide que Mosquitto sur un seul flux : à 64 B il publie environ 80% de sa vitesse et livre environ 40%, parce qu'il rejette du QoS 0 quand le flux de l'abonné est plus lent que celui de l'éditeur (Mosquitto, sans limite, met en file). À 1 KiB, dans le déluge à 16 paires, Mosquitto est devant d'environ 15%, ce qui est dans le bruit. Le générateur était de nouveau une VM partagée avec 58 à 77% de temps volé. Le deuxième tour (verrouillage du heap hors du chemin des données, SACK côté envoi et autres) se trouve sur la branche non intégrée perf-single-flow-wip ; ses chiffres ne sont pas encore des affirmations et nous ne les donnons pas ici.

Une promesse que nous n'avions pas faite, mais que nous avons tenue : la configuration est une donnée

Jusqu'ici, chaque configuration était une nouvelle construction : les clés et les limites étaient intégrées à l'image. C1 inverse cela (ADR-215 à ADR-219) : le noyau est construit une fois, et la configuration est une donnée.

• Le blob urmqtt-cfg (C1a) : un enregistrement versionné et canonique (champs par étiquettes croissantes, empreinte SHA-256, signature Ed25519 détachée facultative), 70 champs avec valeurs par défaut et bornes, un décodeur qui rejette tout ce qui est invalide.
• Le noyau le lit comme module Limine (C1b), avant tout le reste, sur aarch64 et x86_64. Il existe un seul noyau publié pour chaque ENV sauf dev (les ELF aarch64 pour release, prod et bench ont le même SHA-256 ; vérifié seulement sur aarch64). Le noyau publié rejette la configuration de développement, et sans configuration il écrit « refusing to serve » et ne sert rien.
• Le disque installé porte la configuration et la mise à jour la conserve (C1c).
• urmqtt-config et le modèle d'ISO (C1d) : pack, show, verify, et pack --iso remplace les deux copies de l'emplacement de configuration et les 24 condensats de modules dans un ISO prêt. Le résultat est identique octet pour octet à l'ISO que construit mkiso.sh --config. Le modèle de la publication v0.2.0 fait 63 111 168 octets.
• La déclaration de confiance (ADR-219) : l'image configurée écrit au démarrage l'empreinte de la configuration (config: fingerprint ...), et la signature est facultative et désactivée par défaut. Un ISO modifié n'a pas de condensat officiel ; l'empreinte est le moyen de voir ce qu'il contient.

Le constructeur sur aldo.tech

Ce que fait urmqtt-config pack --iso, la page web le fait aussi, avec le même code : la bibliothèque de l'outil compilée en WebAssembly (1,06 MB, sans imports et sans bloc unsafe). La page se trouve à aldo.tech/fr/produits/urmqtt-builder/ et existe dans les 15 langues du site (par exemple hr).

• Rien ne quitte le navigateur. Les certificats, les clés privées et l'ISO fini restent sur l'ordinateur ; la page ne télécharge que les fichiers de publication depuis ce site, sans suivi ni scripts tiers. Lors du test en direct, aucune requête ne portait de matériel de clé.
• Le miroir des publications (ADR-227) : heure par heure (timer systemd, basse priorité), il copie les publications depuis GitHub, chacune est vérifiée avant publication, et la page vérifie dans le navigateur la signature de SHA256SUMS avec la clé intégrée à la page, puis seulement écrit la configuration dans le modèle. Une vérification échouée bloque le téléchargement.
• Simple par défaut, avancé au besoin (ADR-232) : le premier écran compte trois étapes (où il tourne, vos certificats, le nom de l'image). Un seul champ de dépôt de fichiers trie le certificat, la clé et la CA selon leur contenu. La vue avancée ouvre chacun des 70 champs, la recherche, l'import et l'export de TOML ; les deux vues éditent le même état. Le modèle (63 MB) se télécharge pendant que l'utilisateur remplit le formulaire. Lors d'un essai en direct, avec un miroir de test et une clé de test, la construction de l'ISO dans le navigateur a pris 5 à 18 s.

L'émulateur, facultatif. À côté de « Télécharger l'ISO » se trouve « Essayer dans l'émulateur » : QEMU compilé en WebAssembly fait démarrer l'image qui vient d'être construite dans un onglet du navigateur. Rien de lui n'est téléchargé avant le clic (environ 3 MB la première fois). L'émulateur est BIOS seulement, sans réseau (pour que le trafic de l'utilisateur ne passe par aucun intermédiaire et n'enfreigne pas « rien ne quitte le navigateur »), demande environ 1,5 GB de mémoire et un navigateur de bureau (Chrome testé ; Firefox et Safari non). Dedans, urMQTT atteint URMQTT READY en environ 8 s (compte à rebours ignoré) et écrit la même empreinte de configuration que la page, ce qui prouve que c'est bien cette configuration qui a démarré. Le démarrage est environ 2 fois plus lent que QEMU natif sur le même Mac (0,82 s contre 1,9 s), et la cryptographie environ 58 fois plus lente parce que les instructions matérielles sont émulées. C'est pourquoi nous ne tirons de l'émulateur aucune affirmation sur la vitesse, et la page le dit avant le lancement. À la construction, il a fallu corriger quatre octets dans le .wasm à cause d'une erreur de traduction de l'instruction POPCNT dans l'émulateur d'origine (nous ne l'avons pas encore signalée) ; l'émulateur lui-même est sous GPL, avec une offre de code source.

MQTT en clair, seulement pour les réseaux de confiance

MQTT en clair (TCP 1883, sans TLS) est très répandu dans l'IoT : c'est le réglage par défaut de Mosquitto, de la plupart des firmwares pour Arduino et ESP, de Tasmota, de Zigbee2MQTT et de Home Assistant, et il est utilisé aussi dans des réseaux industriels segmentés, derrière des VPN et sur des LAN privés, y compris sur des appareils sans horloge (les certificats exigent une date), sans assez de flash ou de processeur pour TLS. Sur un réseau non fiable, il n'est pas acceptable : qui est sur le chemin lit et modifie le trafic. C'est pourquoi P1 (ADR-229 à ADR-231) est un choix explicite et limité, désactivé par défaut, et le port TLS reste ; TLS n'est pas désactivé par cela, le port en clair vient en plus.

• La liste des réseaux autorisés est obligatoire (allow_from, CIDR) et vérifiée au SYN : hors de la liste, il n'y a ni SYN-ACK ni état. Tout Internet (0.0.0.0/0) exige une option explicite distincte.
• Trois modes d'authentification : mot de passe (par défaut quand c'est activé ; PBKDF2-HMAC-SHA-256, sel, 10 000 itérations, comparaison en temps constant, verrouillage par adresse), anonyme (une identité configurée avec son propre ACL) et par adresse (ip). Le constructeur hache le mot de passe dans le navigateur et ne conserve en mémoire que le condensat.
• Moins de droits qu'avec mTLS : un client en clair n'a jamais de droits de service, d'opérateur ou de gestion, pas de $SYS ni de console, il a ses propres sessions ($plain/<identité>/<id du client>, seulement propres), ses propres limites, et le registre des appareils autorisés continue de s'appliquer à lui.
• Ce qui est perdu est écrit dans SECURITY.md : confidentialité, intégrité, authenticité du broker et rejeu d'une authentification enregistrée. La configuration ne peut pas y remédier ; c'est ainsi quand il n'y a pas de TLS.

Mesuré sur un portable (Apple silicon, HVF, réseau utilisateur QEMU), 16 paires, 64 B, trois exécutions de 10 s : à 8000 messages par seconde, le chemin TLS et le chemin en clair livrent tous les messages avec la même latence (p50 0,17 ms contre 0,13 à 0,18 ms), nouvelles connexions par seconde : TLS environ 2600 à 2750, anonyme en clair environ 4900 à 7800, et l'authentification par mot de passe est la partie coûteuse : un PBKDF2 coûte environ 2,5 ms, donc le nombre de nouvelles authentifications est limité à environ 200 par cœur de données et par seconde (mesuré : 308 à 342 sur deux cœurs). Le déluge sur cette machine n'est pas un instrument stable (20k à 440k livrés par seconde selon les exécutions) et nous n'en tirons aucune conclusion. La comparaison du chemin en clair avec Mosquitto sur le VPS n'est pas encore faite. Tests : le groupe de smoke tests plaintext 7 sur 7 sur aarch64 HVF et sur x86_64 TCG, nouvelle cible de fuzz plain_input (2,3 millions d'exécutions sans résultat).

Les erreurs trouvées par l'usage en direct

Deux choses n'ont pas été attrapées par les tests, mais par la première mise en service sur le vrai site :

• La page cherchait les fichiers de publication un répertoire trop haut, donc chaque vérification de signature répondait 404 (correctif 13af301). Le test utilisait un miroir de test à un autre chemin.
• Le clavier de l'émulateur n'arrivait jamais à l'invité : la cause n'était pas une mauvaise traduction des touches, mais le fait que la boîte de dialogue n'écoutait pas du tout les touches (correctif dans l'ADR-232, avec une entrée de démarrage sans touches).

Leçons

• Cherchez la cause, n'accusez pas l'environnement. La plupart des faiblesses d'un seul flux et toutes les connexions coupées étaient les nôtres ; l'hyperviseur est réel, mais il fallait le mesurer, pas le supposer.
• La comparaison avec un autre produit doit inclure aussi les pertes. Un tableau où il n'y a que nos victoires ne serait pas une comparaison.
• L'instrument de mesure a des limites. Un générateur partagé avec 60 à 70% de temps volé change ce que les chiffres signifient ; c'est pourquoi nous écrivons « borne inférieure » et n'affirmons pas les différences inférieures à 20%.
• L'isolation n'est pas une preuve. SQLite en EL0 réduit ce qu'une erreur en lui peut faire, pas ce qu'il peut mentir.
• Une installation réelle trouve ce que les tests ne cherchent pas : un chemin mal composé et des touches que personne n'écoute.

Ce qui n'est pas encore démontré

• La clé de signature des publications est pour l'instant une clé de test ; v0.2.0 et v0.2.1 sont des pré-publications, et les images qui les accompagnent sont des images de développement avec des certificats de test (sauf le modèle, qui est sans configuration).
• 13 traductions de la page du constructeur (et de cet article) ont été écrites par une IA et vérifiées par des tests et des échantillons, pas par des locuteurs natifs.
• La comparaison avec Mosquitto est une session, un chemin et un générateur partagé, sur un VPS partagé ; les différences inférieures à 20% ne sont pas des affirmations.
• Le chemin en clair n'a pas été mesuré sur le VPS ni face à Mosquitto.
• Lighthouse sur la nouvelle vue simple n'est pas confirmé (ancienne vue : accessibilité 95 ou plus).
• Bare metal, coût du worker x86_64 sur KVM, Firefox et Safari pour l'émulateur : non mesuré.

La suite

• D1 : un broker de démonstration public. Nous ne pouvons pas rendre public l'émulateur du navigateur : il vit dans l'onglet d'un seul visiteur, il est 20 à 100 fois plus lent que KVM, n'a pas de réseau entrant et disparaît à la fermeture de l'onglet ; rediriger Internet vers le navigateur de quelqu'un d'autre serait aussi un abus. Un vrai broker de démonstration est possible : urMQTT sur un VPS derrière un nom sur aldo.tech, avec une CA de test publiée, un ACL strict et de petites limites. Pour l'instant ce n'est qu'une idée, pas une construction, et cela exige un accord explicite pour l'exposition publique.
• Le deuxième tour pour un seul flux (branche perf-single-flow-wip) : seulement quand il aura été mesuré sur le VPS et fusionné.
• Le chemin en clair face à Mosquitto sur le VPS, enregistrement et révocation de compte pour MQTT en clair via le canal de gestion signé.
• Après la publication : bare metal (X12 à X16), IOMMU et Secure Boot, chiffrement du disque.

Le code est sur github.com/zeljan-alduk/urMQTT, et docs/PROGRESS.md reste la seule source de vérité sur ce qui fonctionne réellement, docs/PERFORMANCE.md sur ce qui a été mesuré. Pré-alpha, comme avant ; les rapports de bogues et les signalements de sécurité, selon les instructions de SECURITY.md, sont les bienvenus.

Une précision d'emblée : le projet reste en pré-alpha. Les chiffres de cet article mesurent du code et des tests, pas une maturité en production, et la première publication est volontairement limitée aux VPS avec KVM. Le bare metal viendra plus tard.

À quoi cela ressemblait dans le temps

Le premier commit date du 28 octobre 2026 à 23:48 (M0). Au 31 octobre à 23:00, le dépôt compte 119 commits, répartis en 3, 39, 38 et 39 par jour calendaire. Disons tout de suite comment c'est possible : le projet se construit avec Claude Code, et les commits portent des trailers Co-Authored-By: Claude. Quatre jours calendaires d'historique ne signifient pas qu'une seule personne a écrit 90 000 lignes en quatre jours ; cela signifie que le plan, l'implémentation, les tests et les ADR s'écrivent en boucles courtes et fermées, et que chaque étape se termine par le même rituel de vérification qu'auparavant. Les chiffres ci-dessous parlent de la quantité de code et de tests, pas du temps de travail réel que tout cela représente.

Le graphique montre trois courbes qui montent presque ensemble, ce qui est voulu : les tests et les décisions consignées suivent le code au lieu de rester à la traîne. La pente est la plus raide le 29 octobre, quand naît tout le chemin qui va du noyau au broker. Ensuite, les lignes s'ajoutent plus lentement, mais les tests croissent plus vite que le code (27 tests pour 1,6 millier de lignes au début, 739 pour 89,8 milliers aujourd'hui).

Les lignes sont tous les fichiers .rs hors de vendor/ et fuzz/, et les tests sont des fonctions #[test]. Ce que chaque étape a apporté, par date d'après l'historique git :

Promesse 1 : un seul ISO pour plusieurs plateformes

Ce que nous avions prévu. Un seul fichier qui démarre sur UEFI aarch64, UEFI x86_64 et BIOS x86_64. Ce que nous avons construit. Le portage vers x86_64 (X0 à X10) et un ISO universel avec le bootloader Limine, un ISO hybride unique d'où démarrent toutes ces combinaisons ; les tests de fumée le démarrent sur quatre machines virtuelles. Le menu comporte trois entrées : urMQTT (mode live, exécuté depuis la RAM, rien n'est écrit sur le disque), l'installation sur le disque de la machine sur laquelle il tourne (l'installation écrit le GPT et les données, puis éteint la machine) et Diagnostic (détection du matériel et mesures).

La première cible réelle a été un VPS, et non un ordinateur physique : la décision est que la première publication ne prend en charge que les VPS (KVM), et que le bare metal viendra après. Nous avons testé sur un VPS Contabo avec un processeur AMD EPYC (famille 23, Zen 1), 4 vCPU et 8 GiB de RAM, avec un réseau virtio-net et un disque virtio-scsi. Le premier essai nous a surpris : l'ISO attaché comme CD virtuel démarrait l'entrée par défaut, l'image de production refusait de fonctionner depuis un support en lecture seule et se réinitialisait, et nous nous sommes retrouvés dans une boucle infinie menu, noyau, réinitialisation sans rien de lisible. Aujourd'hui, une erreur fatale dans l'image de production laisse un message sur la console pendant 60 secondes avant la réinitialisation, et depuis un support optique elle affiche qu'elle a démarré depuis un support en lecture seule, puis s'arrête. Le mode live en RAM (O3) a ensuite contourné ce problème pour le cas courant.

L'entrée de diagnostic est née de cette expérience : une machine que nous ne voyons pas, nous devons pouvoir l'interroger sur ce qu'elle contient. Elle affiche le CPU, la RAM, le réseau, les disques et les périphériques PCI, mesure le débit mémoire, le disque et la cryptographie, et écrit les mêmes mesures en JSON sur le port série. L'écriture sur le disque n'est permise que dans l'espace non alloué, et seulement après avoir saisi WIPE ; sur la capture ci-dessous, cette étape a été sautée.

Ce qui reste ouvert. Le vrai matériel. Après la première publication viendra le bare metal (démarrage USB, NVMe et AHCI, carte réseau d'un vrai ordinateur), avec l'IOMMU et Secure Boot, car sans IOMMU un périphérique malveillant ou défectueux peut écrire dans toute la mémoire. Dans cette version, nous n'affirmons rien à ce sujet.

La poignée de main : de 1,2 ms à 0,24 ms

La première mesure du diagnostic sur le VPS a donné un chiffre gênant : la poignée de main mTLS, uniquement la cryptographie côté serveur, durait 1,2 ms. Sur aarch64, nous utilisions déjà les instructions matérielles AES et SHA, mais x86_64 n'avait rien de comparable pour la clé publique : RustCrypto est portable et à temps constant, donc lent aussi. Trois changements l'ont fait baisser.

• Pour P-256, nous avons repris l'assembleur nistz256 d'OpenSSL et de ring (ADR-130), avec des tables à base fixe pour la signature et la vérification des signatures de la CA (ADR-110, ADR-111).
• X25519 a été réécrit sur quatre membres de 64 bits avec les instructions MULX/ADX (ADR-131).
• Nous avons ensuite profilé tout le reste (ADR-132, ADR-200).

Les chiffres varient d'environ 10% d'une exécution à l'autre, c'est pourquoi nous avons noté une fourchette plutôt qu'une valeur unique. Au total, cela représente environ cinq fois moins de temps CPU par poignée de main.

Ce que nous avons appris sur memcpy. Quand la cryptographie a chuté, le profil a montré quelque chose d'inattendu : les fonctions mem* (memcpy, memmove, memset) consommaient 7% de la poignée de main, 13 à 39% du chemin d'un enregistrement TLS (39% pour 64 B, 13% pour 4 KiB) et 17 à 34% de la distribution des PUBLISH. Nous les avons remplacées par de l'assembleur SSE2 pour x86_64 (ADR-200), avec des tests différentiels contre l'implémentation de référence pour toutes les tailles, tous les alignements et tous les chevauchements. Par appel, cela donne 55 à 75 cycles contre 7 à 12 pour 1 à 64 octets.

Lecture du graphique : plus l'enregistrement est petit, plus la part du temps consacrée à la copie est grande, et plus le gain est important. Pour les petits messages, qui forment l'essentiel du trafic MQTT, c'est ce qui compte.

Ce que cela ne veut pas dire. Sur x86_64 natif, nous n'avons mesuré OpenSSL 3.5.5 (ADR-130) que comme référence pour l'assembleur, et non comme comparaison de produits. La comparaison Linux plus Mosquitto sur le même VPS (tâche X11) n'a pas encore été faite. Nous n'affirmons donc pas qu'urMQTT est plus rapide que Linux : ce n'est pas mesuré. Les chiffres ci-dessus comparent urMQTT à lui-même.

La surcharge a été le second résultat. Sur le VPS, depuis un seul Mac (RTT 35 ms), 128 clients ont donné 618 poignées de main par seconde, 256 clients 393, et 512 clients 67, avec des milliers de connexions refusées. Ce n'était pas un plateau mais un effondrement. Nous avons trouvé les causes dans le code (deux sont confirmées dans QEMU/HVF, mais n'ont pas pu être reproduites sur le VPS), plusieurs à la fois : une connexion refusée renvoyait le client sur le segment suivant portant un cookie SYN valide, le refus par RST disait au client de réessayer aussitôt, et la réception était en O(file). Le correctif (ADR-080 à ADR-082) laisse tomber un SYN qui ne serait pas accepté, mémorise les flux refusés, maintient la réception en O(1) et compte les poignées de main par cœur. Il est possible (hypothèse, non vérifiée) qu'une partie de la cause se soit trouvée aussi côté client : l'outil de charge fermait en premier, si bien qu'un seul Mac, avec 16 384 ports éphémères et un TIME_WAIT de 30 secondes, était limité à environ 550 connexions par seconde. Nous n'avons donc pas encore mesuré le vrai plafond du serveur.

Promesse 2 : un disque brut, mais soigneux

Ce que nous avions prévu. Garder notre propre disposition sans système de fichiers, et ajouter tout ce qu'un système de fichiers apporte d'habitude : alignement, croissance, discard, sauvegardes et vérifications. Pourquoi pas un système de fichiers. Nous en avons débattu et la décision est confirmée : urMQTT écrit une seule base, un seul journal de télémétrie et ses propres métadonnées, n'a besoin ni de répertoires, ni de permissions, ni de noms de fichiers, et chaque couche supplémentaire serait du code de plus dans la partie de confiance et une manière de plus de perdre un enregistrement en silence. Le disque est un GPT avec une partition ESP et une partition de données urMQTT, sur laquelle se trouve la disposition propre au projet.

Ce que nous avons construit (S2 à S6).

• Disposition v2 (S2). Topologie du disque, alignement sur 1 MiB ou sur la taille d'E/S optimale, blocs physiques entiers, paire A/B de superblocs avec génération (ADR-140). La disposition v1 est refusée par le noyau avec un message clair, et l'outil hors ligne urmqtt-disk migrate la migre (ADR-141) : par défaut c'est un passage à blanc, on copie puis on bascule seulement ensuite, avec retour arrière et injection de fautes à chaque écriture.
• Croissance (S3). Au démarrage, le disque peut grandir (jamais rétrécir), et sur virtio-blk aussi pendant l'exécution, via l'interruption de changement de configuration (ADR-142, ADR-143).
• Discard et write-zeroes (S4). Les disques à allocation dynamique rendent l'espace à l'hôte. Dans un test, le fichier qcow2 sur l'hôte est passé de 62 à 16 MiB après l'expiration des segments de télémétrie, et la récupération ne fait jamais confiance au contenu qui a été rejeté.
• Sauvegarde de la base sur le disque (S5). Une copie A/B avec l'API de sauvegarde en ligne de SQLite par pas de 16 pages : l'étape la plus longue dure 4,6 ms contre 445 ms quand on copie en un seul appel. Les commits pendant la copie ont eu un maximum de 2,4 ms contre 2,2 ms sans elle. Si quick_check échoue au démarrage, la base est restaurée à partir de la copie.
• Nettoyage et démarrage borné (S6). Le scrubber lit le disque avec un budget d'E/S limité et signale les enregistrements corrompus, et le démarrage ne lit que le segment le plus récent de chaque partition, si bien que le temps de démarrage ne croît pas avec la taille de la région de télémétrie. Nous avons ainsi fermé un problème que nous avions calculé à l'avance : sur un grand disque, une récupération complète aurait pris de quelques minutes à plusieurs dizaines de minutes.

Tout le groupe de tests de fumée du stockage passe sur les deux architectures : 79 réussis, 0 échoués, sur aarch64 sous HVF et sur x86_64 sous TCG. Nous avons aussi mesuré que S4 n'a pas ralenti la base : 53,3 milliers d'insertions par seconde par lots avant et après, sans différence mesurable.

Ce qui a surpris. La part des cas limites dans une disposition « simple » : virtio-scsi et virtio-blk signalent la topologie de manières différentes, et une écriture incomplète au milieu d'une migration doit toujours laisser au moins une version valide. C'est pourquoi chaque écriture sur le chemin de migration et de croissance a subi une injection de fautes.

Ce qui reste ouvert. Les pages SQLite n'ont pas de somme de contrôle, donc la base ne détectera pas un bit modifié à l'intérieur d'une valeur d'une ligne ; les enregistrements de télémétrie et le contenu des copies ont un CRC et sont détectés. Le chiffrement du disque (S7) n'est pas terminé.

Promesse 3 : démontrablement sûr, autant que nous y parvenons

Durcissement (H4). L'allocateur efface la mémoire libérée et la vérifie à la réutilisation, détecte les double libérations, lie les pointeurs de la liste libre par XOR et met les clés à zéro à la libération (ADR-170). Protection de la pile (-Zstack-protector=strong, 1315 fonctions, et SQLite avec -fstack-protector-strong, ADR-171). Les rapports d'erreur en production ne contiennent ni registres ni adresses (ADR-172). KASLR sur les deux architectures : le noyau est PIE et Limine le déplace d'environ 19 bits, tandis que le heap, les piles et la fenêtre MMIO sont placés au hasard (ADR-173). Sur aarch64, MTE marque le heap (ADR-174), mais seulement sous TCG : HVF et x86 n'en disposent pas. Nous avons évalué kCFI sans le retenir, car le compilateur du nightly épinglé plante avec une erreur interne ; l'IOMMU est reporté avec le bare metal (ADR-175, ADR-176).

Le coût est mesuré, pas supposé. Sur le chemin de la poignée de main (dp-bench, aarch64 HVF, poignées de main complètes TLS 1.3 + mTLS + CONNECT) :

Au total, le coût sur le chemin de la poignée de main est donc d'environ 5% pour les éléments mesurés proprement, et avec PIE et le marquage on obtient environ 7% sur un cœur et environ 11% sur quatre, mais cette mesure est bruitée. Nous la jugeons acceptable, mais nous ne l'avons pas reproduite sur le VPS x86_64.

Il vaut la peine de comparer avec le chiffre du premier article (862 poignées de main par seconde sur un cœur). Le même outil aujourd'hui, avec le pilote de chiffrement matériel sur aarch64 (X0b) et la série d'accélérations arrivées depuis, donne 1941 avant le durcissement. Nous n'avons pas isolé la contribution de chaque changement, donc nous n'affirmons rien sur la cause.

Comment cela a été vérifié, et ce qui ne l'a pas été. H5 a ajouté Miri sur un sous-ensemble de crates de l'hôte, des preuves Kani, des sanitizers, un model-fuzzer pour les ACL et des rapports de couverture. Kani a prouvé record_len dans TLS, parse dans TCP et deux arithmétiques de la roue de timers. Non prouvés (délai dépassé) : les deux décodeurs MQTT, les deux analyses de configuration et le comportement de la roue de timers ; le job CI de Kani n'est donc pas encore bloquant. Miri ne peut pas exécuter d'assembleur. Chaîne d'approvisionnement (H9) : SBOM CycloneDX de 215 composants, cargo-vet passe avec 39 audités complètement et 140 exemptions, et cargo-deny est configuré pour traiter les avis de vulnérabilité comme un échec de la CI (ces jobs CI n'ont été vérifiés jusqu'ici qu'en local, pas sur GitHub, et le test négatif n'a pas été exécuté), avec VULNERABILITY-HANDLING.md. L'état honnête : sur 67 versions de crates tierces liées au noyau, 53 sont des exemptions et non des audits. Vet prouve que l'ensemble des dépendances ne peut pas changer sans différence visible, pas que le TCB a été examiné. Nous n'avons écrit notre propre audit d'aucun crate.

SNTP (T1) est dans ce sens une petite histoire de sécurité : il est facultatif, uniquement vers des serveurs IPv4 privés, avec un saut maximal et à la condition que les sources s'accordent (médiane, majorité à moins d'une seconde). Une horloge que n'importe qui sur le chemin peut décaler n'est pas une horloge à laquelle nous pouvons nous fier pour la validité des certificats.

Sur le Mac : aarch64 en natif et x86_64 par émulation

Nous développons sur un Mac, et celui-ci offre deux manières d'exécuter le même code, très différentes l'une de l'autre.

La règle est simple : les chiffres sous TCG sont de l'émulation et nous ne les citons pas comme des performances. Nous ne mesurons les performances x86 que sur un vrai VPS. C'est pourquoi les chiffres de cryptographie ci-dessus viennent du VPS Contabo, et non du Mac.

Leçons

• Mesurez sur une vraie machine avant d'optimiser. Notre première approche consistait à optimiser ce que nous croyions lent ; ce n'est que le diagnostic sur le VPS qui a montré 1,2 ms et où le temps passe exactement.
• La surcharge est une fonctionnalité à part. Un système rapide sous charge peut s'effondrer au-delà ; refuser doit coûter moins cher qu'accepter.
• Le profil surprend. Le plus grand gain isolé pour les petits messages ne se trouvait pas dans la cryptographie mais dans la copie de mémoire.
• Un disque sans système de fichiers demande plus de travail, pas moins. Ce qu'un système de fichiers apporte d'habitude (alignement, croissance, discard, copies, vérifications) nous devons l'écrire et le vérifier nous-mêmes, chaque étape avec injection de fautes.
• L'honnêteté dans les chiffres. Les mesures de mémoire sur un VPS partagé varient jusqu'à 10 fois d'une exécution à l'autre et ne disent rien du code, nous ne les citons donc pas. Les chiffres cryptographiques sont stables à environ 10%.
• La vitesse de développement n'est pas la maturité. Les tests et les ADR croissent avec le code, mais quatre jours ne font pas un vrai fonctionnement en production.

La suite

• H6 : SQLite isolé au niveau EL0, de sorte qu'une erreur dans la base n'ouvre pas le noyau.
• H7 : le reste de la sécurité du temps (NTS et traitement des sauts) ; SNTP n'est qu'un premier pas.
• X11 : comparaison avec Linux et Mosquitto sur le même VPS ; ce n'est qu'alors qu'il a un sens de parler de vitesse relative.
• Publication : première publication publique pour VPS (KVM), avec artefacts signés et instructions.
• Après la publication : bare metal (X12 à X16), IOMMU et Secure Boot, ainsi que le chiffrement du disque.

Le code est sur github.com/zeljan-alduk/urMQTT, et docs/PROGRESS.md reste l'unique source de vérité sur ce qui fonctionne réellement. Pré-alpha, comme avant ; les rapports de bogues et les signalements de sécurité, selon les indications de SECURITY.md, sont les bienvenus.

C'est ainsi qu'est né urMQTT : un unikernel qui est un broker MQTT. Le noyau, la pile TCP/IP, TLS 1.3, MQTT et une base de données intégrée tiennent dans un seul binaire Rust qui démarre depuis un seul ISO. Pas de processus, pas d'appels système, pas de shell. La première plateforme sur laquelle il est construit et testé est aarch64, et le même code se dirige vers x86_64, par UEFI et BIOS classique, et vers du matériel réel : l'objectif est un seul ISO qui démarre sur tous. Le projet est open source sous licence MIT ou Apache 2.0, et dans cet article nous souhaitons consigner où nous en sommes, comment il est construit en interne et ce que nous avons appris en chemin.

Ce que signifie exactement « unikernel »

Un broker classique est un programme qui s'exécute sur un système d'exploitation. urMQTT n'a aucun système d'exploitation en dessous de lui : il s'amorce lui-même via le firmware UEFI et le bootloader Limine, met en place ses propres tables de pages, programme le contrôleur d'interruptions et le timer, découvre les périphériques virtio via PCIe, obtient une adresse par DHCP et écoute sur un seul port. Tout ce que feraient habituellement le noyau, les pilotes, la pile réseau et l'application tient ici dans un seul ELF qui s'exécute au niveau EL1.

La comparaison avec une installation typique parle d'elle-même :

Les priorités sont, dans cet ordre : sécurité, scalabilité, performances multicœurs, faible empreinte et installation immuable. Chaque fois que deux objectifs entrent en conflit, celui qui figure plus haut dans cette liste l'emporte.

Où nous en sommes

Le projet est en pré-alpha, mais dix-sept jalons de développement, de M0 à M17, sont bouclés. Aujourd'hui, urMQTT sert MQTT 3.1.1 sur TLS 1.3 avec des certificats clients obligatoires, et conserve son état dans SQLite sur un disque brut. En bref, voici ce qu'il fait déjà :

• Noyau : vecteurs d'exceptions propres avec rapports décodés, tables de pages propres avec W^X appliqué, pages de garde, PAC et BTI là où le processeur les possède, GICv3 et GICv2, timer générique, SMP jusqu'à 64 cœurs.
• Découverte du matériel à partir du DTB ou d'ACPI vers une description de plateforme unique, avec un résultat identique depuis les deux sources.
• Pilotes : PCIe ECAM, MSI-X, virtio-net, virtio-blk, virtio-scsi et virtio-rng, ainsi qu'un CSPRNG initialisé avec de l'entropie matérielle.
• Réseau : DHCPv4, ARP, ICMP et IPv4 strict maison, puis un TCP maison côté serveur uniquement : cookies SYN, roue de timers hiérarchique, NewReno, fusion des ACK, aucun état TIME_WAIT.
• TLS : TLS 1.3 uniquement, mTLS obligatoire, identité de l'appareil issue du CN ou d'un SAN URI ; la poignée de main est assurée par rustls, puis une couche d'enregistrements maison avec AES-128-GCM et ChaCha20-Poly1305. Reprise de session par tickets PSK, liste de révocation, contrôle d'admission dès la poignée de main.
• MQTT : codec sans copie, fuzzé et testé avec de vrais clients mosquitto ; QoS 0 et 1, jokers, messages retenus, testament (LWT), sessions persistantes, ACL limitées à devices/{id}/#, limites de débit par appareil.
• Stockage : SQLite dans le noyau via un VFS sur disque brut, en mode WAL, avec vérification d'intégrité au démarrage ; registre des appareils, révocations, messages retenus, sessions persistantes avec files de messages pour les appareils hors ligne ; par cœur, un journal de télémétrie distinct avec CRC par enregistrement et récupération après un plantage.
• Exploitation et supervision : timer de surveillance pour les gestionnaires, contrôle de santé, journalisation limitée, syslog et statsd sur UDP, une admission qui résiste aux tempêtes de reconnexions.
• Livraison : reconstructions identiques au bit près vérifiées en CI, ISO et image disque GPT brute, signatures minisign, instructions pour KVM, Proxmox et Hetzner.

Chaque étape est marquée par le jalon qui l'a apportée, et le fichier docs/PROGRESS.md du dépôt est la seule source de vérité sur ce qui fonctionne réellement.

L'architecture en trois images

La conception complète est décrite dans docs/ARCHITECTURE.md, et les raisons de chaque décision importante sont consignées sous forme d'ADR dans docs/DECISIONS.md. Voici un aperçu.

Les couches

Du haut vers le bas : le broker (sessions, arbre des sujets, QoS, messages retenus, testaments, ACL, limites), le codec MQTT, TLS, TCP, la couche réseau, puis les pilotes. À côté de ce chemin principal se trouve le stockage (SQLite et le journal de télémétrie), et sous le tout la gestion de la mémoire, la découverte de la plateforme et la configuration compilée en constantes au moment de la construction, avec le certificat CA, le certificat du serveur et sa clé intégrés. L'hyperviseur avec ses périphériques virtio est la seule chose qui reste hors de l'image.

Un thread par cœur, aucun état partagé

Chaque cœur de données fait tourner sa propre boucle avec sa propre pile TCP, ses états TLS, sa part du broker (sessions et arbre des sujets), son cache de heap et sa partition de télémétrie. Les cœurs ne partagent aucun état modifiable, seulement des anneaux bornés sans verrou, un pour chaque paire ordonnée de cœurs. Le cœur le plus élevé exécute SQLite et rien d'autre.

La carte réseau n'a aujourd'hui qu'une paire de files, détenue par le cœur 0. Il oriente chaque flux MQTT vers l'un des cœurs de travail d'après le hash Toeplitz de son quadruplet, et envoie ce que les cœurs de travail renvoient. Une session vit sur son cœur d'attache, déterminé par le hash de l'identifiant du client, de sorte que la prise de contrôle, les testaments et la persistance ne franchissent jamais les cœurs. Une connexion qui atterrit sur un autre cœur y conserve son TCP et son TLS, et transmet le MQTT en clair au cœur d'attache avec un contrôle de flux fondé sur des crédits. Chaque message routé est en outre diffusé vers les autres parts du broker, dont chacune détient une réplique des messages retenus.

Trois règles maintiennent ce modèle. Traitement de bout en bout : un paquet reçu est traité intégralement sur un seul cœur, du TCP au message chiffré de réponse en passant par le déchiffrement TLS sur place, l'analyse MQTT et le routage, sans files de tâches et sans copie dans des tampons applicatifs. Interrogation adaptative : sous charge, les files de réception sont interrogées activement, et au repos le cœur retourne aux interruptions et à WFI ; les gestionnaires d'interruptions se contentent d'acquitter l'interruption et de marquer le travail. Timer de surveillance : un tick de 10 ms par cœur attrape les gestionnaires qui dépassent leur budget.

La vie d'un PUBLISH

L'appareil envoie un enregistrement TLS. La carte réseau le remet à la boucle du cœur par un descripteur, sans copie. La boucle vérifie le TCP, déchiffre le TLS sur place et analyse le MQTT depuis un tampon emprunté, puis contrôle en mémoire l'ACL, la limite de débit et le chemin dans l'arbre des sujets. Si un autre cœur s'intéresse à ce sujet, il reçoit un message de routage avec une référence au contenu et l'identifiant du sujet ; la base reçoit un enregistrement de télémétrie ou une mise à jour de message retenu, par lots. La réponse PUBACK est chiffrée directement dans le tampon sortant et fusionnée avec l'ACK TCP, de sorte qu'un seul segment part vers l'appareil. Pour un autre cœur, le message ne coûte qu'un chiffrement par abonné au moment de l'envoi.

Ce que coûte une connexion

L'objectif est au plus 512 octets par connexion TLS inactive, avec une ambition de 256. Tant qu'une connexion est au repos, rien n'est conservé en tampon pour elle : les données reçues sont traitées directement depuis la trame réseau, et les tampons d'envoi, d'enregistrement et MQTT n'existent que tant que quelque chose est inachevé ou non acquitté. Le noyau le mesure lui-même : des compteurs exacts du heap, en octets demandés et en blocs occupés, consignés toutes les dix secondes sous la forme du heap au-dessus du niveau de base par connexion ouverte.

Mesuré sous HVF avec quatre cœurs virtuels, dont trois de travail, chaque appareil tenant une connexion mTLS et un abonnement en QoS 1, arrondis de l'allocateur compris :

Le pool de trames réseau est fixe, d'environ 2 MiB, soit à peu près 200 B par connexion à dix mille connexions et environ 2 B à un million. Nous n'avons pas pu mesurer davantage : le réseau en mode utilisateur de QEMU sous macOS a cessé d'accepter des connexions à 10 197, à peu près à la limite de 10 240 descripteurs du processus QEMU. Le chiffre diminue à mesure que les parts fixes sont réparties sur davantage de connexions, il ne croît donc pas avec leur nombre.

Le modèle de sécurité

La sécurité est la première priorité et l'emporte sur tous les autres objectifs en cas de conflit. Le modèle comporte plusieurs couches :

• Un seul port. TCP 8883, uniquement TLS 1.3, certificats clients obligatoires signés par la CA intégrée à l'image. L'identifiant du client MQTT doit être égal à l'identifiant de l'appareil figurant dans le certificat.
• Aucune entrée. Pas de shell, pas de saisie console, pas de SSH, pas d'API d'administration, pas de code dynamique, pas de SQL accessible par le réseau et pas de système de fichiers.
• Sûreté mémoire. Rust, avec forbid(unsafe_code) dans les paquets de protocole ; chaque bloc unsafe porte un commentaire // SAFETY: vérifié par un lint, et aucune panique sur une entrée externe : clippy interdit unwrap, expect, l'indexation et panic! dans les paquets du chemin de données.
• Atténuation de l'exploitation. W^X est appliqué par l'encodage des descripteurs et par le bit SCTLR_EL1.WXN, et audité à chaque démarrage. Après le démarrage, les tables de pages sont en lecture seule, sans alias inscriptible. La moitié basse de l'espace d'adressage est désactivée. Chaque pile a des pages de garde, et les exceptions s'exécutent sur une pile distincte. PAC et BTI sont activés lorsque le processeur les prend en charge, ce que vérifient les tests de fumée.
• Résistance aux abus. Cookies SYN ; l'admission refuse de nouvelles connexions, avant toute cryptographie, lorsque le heap est bas, que la base prend du retard, que trop de poignées de main sont en cours par cœur ou par adresse source, ou que le débit de poignées de main est trop élevé. Limites de débit par appareil, files bornées, fenêtre TCP liée à la contre-pression du broker, journalisation limitée, timer de surveillance et contrôle de santé.
• Immuabilité. La configuration, la CA et la clé du serveur sont intégrées à l'image. Changer quoi que ce soit signifie une nouvelle image.

Le modèle de menaces est consigné dans docs/SECURITY.md.

Un stockage sans système de fichiers

Les données vivent sur un disque distinct, virtio-blk ou virtio-scsi, sur lequel il n'y a pas de système de fichiers. La disposition est minimale et propre au projet :

LBA 0      [ superbloc : magic · version de la disposition · uuid · table des régions · CRC-32C ]
LBA 8, 16  [ table des tailles de fichiers, emplacements A/B (le plus récent valide l'emporte) ]
LBA 64     [ base principale SQLite ½ ][ WAL SQLite ⅛ ][ journal 1 MiB ][ journal de télémétrie : 8 partitions … ]
derniers 4 KiB [ zone d'autotest du périphérique bloc au démarrage ]

SQLite (3.54.1 vendorisé, avec vérification du condensat à la construction) est compilé dans le noyau avec clang, sans bibliothèque standard, et utilise un heap memsys5 fixe. Son VFS fait correspondre trois fichiers fixes à des régions du disque. Il fonctionne en mode WAL avec locking_mode=EXCLUSIVE, il n'a donc pas besoin d'index en mémoire partagée, et avec synchronous=FULL ; si quick_check trouve une erreur au démarrage, le système s'arrête en toute sécurité. La base contient le registre des appareils, les révocations, les messages retenus et les sessions persistantes avec des files de messages QoS 1 pour les appareils qui ne sont pas connectés.

Le cœur dédié à la base, celui qui porte le numéro le plus élevé, exécute SQLite et rien d'autre. Le plan de données lui envoie les changements d'état par un anneau SPSC sans verrou ; il les regroupe en une transaction toutes les 5 ms ou toutes les 512 opérations et renvoie les acquittements par un second anneau. Un disque vide est formaté au premier démarrage ; tout le reste n'est jamais reformaté par-dessus.

La télémétrie suit une autre voie. Chaque PUBLISH accepté sur les sujets de storage.telemetry_topics part dans la partition du journal de télémétrie de son cœur : un anneau de segments avec CRC par enregistrement, salé par le numéro de séquence du segment, de sorte que les anciens passages de l'anneau ne réapparaissent jamais. Les cœurs transmettent les enregistrements à la base par leur propre anneau, sans copie, et celle-ci les écrit toutes les 5 ms ou tous les 256 KiB. Au démarrage, la récupération conserve chaque enregistrement écrit, tronque la queue inachevée et reprend dans un nouveau segment. La rétention se fait par la taille, à travers l'anneau, et par l'âge, via retention_days. Nous l'avons vérifié avec un million d'enregistrements et avec kill -9 en pleine écriture.

Les chiffres

L'outil de charge dans tools/loadgen fait trois choses : une tempête de poignées de main TLS 1.3 avec mTLS et CONNECT, des connexions de longue durée avec PINGREQ qui publient de la télémétrie chaque seconde, et des tempêtes de reconnexions. make bench sur un Apple M4 Pro sous HVF donne :

Le chiffre dans l'invité, où le client et le serveur se trouvent dans la même machine virtuelle et où chaque cœur de travail fonctionne seul de son côté, montre que le plan de données passe à l'échelle de façon linéaire. Le chiffre réseau est limité par le réseau en mode utilisateur monothread de QEMU, et non par l'invité ; cela aussi est consigné, sous la référence ADR-032.

Nous testons les tempêtes de reconnexions en connectant tous les appareils en même temps, en répétant avec un délai les tentatives refusées, puis en les faisant tous tomber sans DISCONNECT. Le paramètre heap_limit_mb= en mode développement force l'admission à considérer le heap plus petit qu'il ne l'est, ce qui permet de tester une tempête plus grande que le heap avec peu de sockets. Lors d'un tour de ce type avec 3 000 appareils, 1 368 se sont connectés en 36 secondes, et 5 619 tentatives ont été proprement refusées, avec une limite de 8 MiB ; la mémoire est revenue à son niveau après la tempête.

Notre façon de travailler

Le projet est piloté par une spécification écrite, PROMPT.md, avec un plan de jalons, et chaque jalon se termine par le même rituel : make check et make smoke au vert, un commit portant l'étiquette M<n>, une entrée dans docs/PROGRESS.md et un ADR pour chaque décision qui n'est pas évidente. Les règles sont courtes et non négociables : pas de panique sur une entrée externe, unsafe uniquement dans les paquets matériels et FFI et toujours avec un commentaire, pas d'allocations sur le chemin chaud, un commentaire pour chaque ordre d'opérations atomiques, chaque limite provient de la configuration, et les éléments provisoires volontaires échouent bruyamment.

La CI fait plus que ce que nous pourrions faire à la main : fmt, clippy pour l'hôte et pour aarch64-unknown-none, typos, actionlint et shellcheck ; des tests sous Linux et macOS sur arm64 ; la construction du noyau pour la configuration de développement et de production avec la taille de l'ELF dans le résumé ; le démarrage sous QEMU avec tous les scénarios de test de fumée et la conservation des journaux série ; cargo-deny pour les avis, les licences et les sources ; une minute de fuzzing sur chacune des onze cibles, et la nuit dix minutes par cible avec un corpus mis en cache. S'y ajoutent CodeQL, OpenSSF Scorecard, Dependabot et une publication avec provenance SLSA. Chaque action tierce est épinglée sur un SHA de commit complet.

Nous prenons la reproductibilité au pied de la lettre : make repro construit HEAD deux fois dans des arbres de travail neufs et compare l'ELF, l'ISO et l'image brute octet par octet. Les publications sont signées avec minisign, et les artefacts peuvent être vérifiés avec gh attestation verify. L'image de production contient la clé privée du serveur, l'ISO lui-même est donc un secret ; les images jointes aux publications sur GitHub sont des images de développement, avec des clés temporaires, et ne servent qu'à essayer le projet.

Ce que nous avons appris

Quelques leçons qui ont changé le plan :

• Un TCP maison s'est finalement avéré rentable. Le prototype fonctionnait avec smoltcp et nous a bien servi jusqu'à M13. Mais un serveur qui tient des centaines de milliers de connexions n'a pas besoin d'un TCP client : il lui faut des cookies SYN, une roue de timers et un état de 96 octets. Avec M14, nous avons remplacé smoltcp par notre propre pile uniquement côté serveur, avec des tests de perte simulée et du fuzzing de segments.
• Mesurez la mémoire de l'intérieur. Les estimations par connexion étaient inutilisables tant que le noyau ne s'est pas mis à compter lui-même le heap en blocs de l'allocateur plutôt qu'en octets demandés. C'est alors seulement que nous avons vu où partent réellement les 512 octets, et nous sommes descendus à 494.
• L'outil de test fait partie du produit. La plus grande limite n'était pas le noyau, mais le réseau en mode utilisateur de QEMU et le nombre de ports éphémères sur la machine de développement. Pour cent mille connexions et plus, il faut vmnet-shared sous macOS ou Linux avec KVM, une interface tap et plusieurs adresses clientes.
• SQLite sans système d'exploitation est possible, mais seulement à des conditions strictes : un heap fixe, un verrouillage exclusif sans mémoire partagée, un VFS qui ne connaît pas les fichiers, et une admission qui ne laisse pas la base prendre du retard.
• Les tempêtes de reconnexions sont l'état normal, pas l'exception. Quand le réseau mobile tombe puis revient, des milliers d'appareils frappent à la porte en même temps. C'est pourquoi l'admission refuse la connexion avant toute cryptographie, et chaque connexion refusée ne coûte presque rien.

La suite

Le travail après M17 est prévu dans trois directions, et l'ordre entre elles est consigné dans docs/PLAN.md. Rien de tout cela n'est encore construit.

• Un seul ISO pour plusieurs plateformes. Un même fichier urmqtt-<env>-<version>.iso et une image GPT brute qui démarrent sur UEFI aarch64, UEFI x86_64 et BIOS x86_64, dans des machines virtuelles et sur du matériel réel, en commençant par un PC Intel. Toujours une appliance avec tout à l'intérieur, reproductible et signée.
• Un disque brut, sans système de fichiers. Une spécification du format au niveau de l'octet, un outil hôte urmqtt-disk qui partage les analyseurs avec le noyau, un alignement des régions sur 1 MiB, la croissance du disque avec les données, discard pour les disques à allocation dynamique, des instantanés A/B de la base, une vérification des bits et, en option, un chiffrement AES-256-XTS avec AES matériel.
• Sûreté démontrable. Révocation et liste d'appareils autorisés à l'exécution par un canal de contrôle signé, sans nouvelle image ; tests différentiels et de conformité de notre TLS et de notre TCP ; KASLR, protection de la pile, kCFI, MTE et un allocateur durci ; SQLite isolé au niveau EL0 ; Secure Boot ; SBOM et cargo-vet ; et enfin un dossier pour un audit externe.

Les plateformes qui ne proposent que des périphériques non virtio, comme AWS ENA ou Azure MANA, ne sont pas prises en charge pour l'instant. Raspberry Pi 4 et 5 comme hôte KVM, Hetzner CAX et Oracle Ampere A1 sont documentés et pris en charge dans le code, mais n'ont pas encore été essayés sur un vrai service.

Essayez-le

Le dépôt se trouve sur github.com/zeljan-alduk/urMQTT. Avec Rust et sa chaîne d'outils nightly épinglée, ainsi que QEMU, make certs, make run et un client mosquitto suffisent pour un premier PUBLISH sur mTLS sur votre propre machine. L'avertissement du début vaut aussi pour la fin : il s'agit d'un pré-alpha, et tout ce qui fonctionne est consigné dans docs/PROGRESS.md. Les rapports de bogues, les questions de conception et les signalements de sécurité, selon les indications de SECURITY.md, sont les bienvenus. Nous reviendrons ici à chaque nouveau jalon.

Sur ce blog, nous notons ce que nous avons appris en chemin. Pas de textes marketing, mais des notes concrètes : ce qui a mal tourné, comment nous l'avons résolu et ce que nous ferions autrement aujourd'hui.

De quoi nous allons parler

• La billettique dans les transports publics. Cartes sans contact, modules SAM, fonctionnement hors ligne et tout ce qu'un terminal doit supporter dans un véhicule qui vibre douze heures par jour.
• Les applications mobiles sur le terrain. Android et Flutter sur des appareils qui ne sont pas des téléphones ordinaires : avec lecteurs de cartes, imprimantes et batteries qui doivent tenir toute une journée de service.
• Le backend et la supervision de flotte. Comment savoir qu'un appareil dans un véhicule a un problème avant que le conducteur ne le signale.
• Le matériel. Du prototype sur l'établi à la carte qui part en production en série, et toutes les erreurs entre les deux.
• Les modèles d'IA en local. Où les modèles sur votre propre matériel ont du sens, et où le cloud et une API sont tout simplement le meilleur choix.

Comment nous allons écrire

Court et concret, avec du code et des chiffres quand nous en avons. Nous publierons quand nous aurons quelque chose à dire, pas selon un calendrier. Les articles sont écrits en croate et traduits dans toutes les langues de ce site ; vous pouvez aussi nous suivre par RSS.

Si un sujet vous intéresse ou si vous travaillez sur un problème similaire, écrivez-nous à info@aldo.tech.