urMQTT après le VPS : SQLite en mode utilisateur, comparaison avec Mosquitto, configuration comme donnée et constructeur dans le navigateur

Le deuxième article, urMQTT sur un vrai VPS, se terminait par une liste « La suite » : H6 (SQLite hors du noyau), H7 (sécurité du temps), X11 (comparaison avec Mosquitto sur le même VPS) et la première publication. Cet article suit cette liste dans le même ordre, puis ajoute deux choses qui n'y figuraient pas, parce qu'elles sont apparues en chemin : la configuration comme donnée, avec un constructeur web d'ISO, et un MQTT en clair facultatif, sans TLS. Comme avant : ce que nous avions prévu, ce que nous avons construit, ce qui nous a surpris et ce qui reste ouvert. Cet article contient aussi quelques résultats qui ne vont pas dans le sens d'urMQTT ; nous les avons conservés parce qu'ils font partie de la vérité.

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.

Moment	Commit	Heure	Lignes de Rust	Tests	ADR
article précédent	794f607	31.10. 23:00	89 790	739	104
H6 terminé	a0423cc	1.11. 03:59	95 078	754	107
X11	a29f49b	1.11. 07:56	95 579	754	108
constructeur web et miroir des publications	582783f	1.11. 16:49	105 645	848	122
MQTT en clair, documentation	8f959f1	1.11. 19:05	112 408	926	125
aujourd'hui	d21e3ec	1.11. 20:41	112 408	926	126

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 :

Mesure	Avant (dans le noyau)	Après (worker)	Différence
entrée et sortie du mode utilisateur	-	1,1 us par aller-retour
db-bench, 5000 insertions en 50 transactions, meilleur / médiane	61,9k / 58,4k op/s	54,7k / 53,3k op/s	-11,6% / -8,7%
une insertion par transaction, meilleur / médiane	2319 / 2148 op/s	2307 / 2126 op/s	-0,5% / -1%
sauvegarde complète en un seul appel (23 MiB)	514 ms	635 ms	+23%

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.

	urMQTT	Mosquitto 2.0.21
poignées de main/s, 32 / 64 / 128 clients (profil bench)	169 / 278 / 413	82 / 140 / 184
idem, avec les limites telles que livrées	185 / 262 / 333 (à 128 : 202 à 286 erreurs, réinitialisations de poignée de main)	-
mémoire par connexion inactive (20 000 connexions)	0,50 KB de heap du noyau (0,66 KB à 5000)	26,8 KB de croissance du processus
latence p50, QoS 0 / QoS 1, 800 messages/s, 64 B	14,0 / 14,8 ms	21,4 / 39,5 ms
QoS 1, 4800 messages/s, livrés/s (p50)	4209 (77 ms)	4235 (197 ms)
100 abonnés, 50 messages/s : p50	16,6 ms	99 ms
un seul flux, QoS 0, 64 B, publiés/s	2962 (0 à 7733)	22 749

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) :

Symptôme dans X11	Cause dans urMQTT	Changement
un flux 1,9k messages/s, souvent 0 livré	Réveil perdu : la boucle de sortie écrasait la liste des connexions prêtes par celle qui venait d'être écrite ; un abonné dont le tampon de sortie s'était rempli une fois n'était plus jamais servi jusqu'à ce qu'un PINGRESP le réveille	corrigé (ADR-223)
quelques pour cent de perte font passer 48k à 14k messages/s	chaque segment après un segment perdu était rejeté (réception seulement dans l'ordre), donc la récupération coûtait un aller-retour réseau par segment	file de segments hors ordre, SACK (ADR-222)
plafond de 4,4 MB/s à 15 ms	fenêtre de 16 bits, file d'envoi de 64 KiB et slow start qui comptait des ACK et non des octets	mise à l'échelle de la fenêtre, horodatages, comptage en octets (ADR-222)
chaque tour d'un flux qui tient dans la fenêtre attend 0 à 10 ms	le dispatcher dormait jusqu'au tick suivant de 10 ms (virtio-net n'a pas d'interruption de réception)	interrogation de la NIC toutes les 200 us tant qu'il existe des connexions (ADR-224)
1 à 8 connexions coupées par exécution	le watchdog facturait au handler le temps écoulé, et le VPS arrête les vCPU souvent et longtemps	le budget est le temps que le cœur a réellement travaillé (ADR-221)

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.

	code X11 (7f9517e)	maintenant (86a71ff)	Mosquitto
un flux, QoS 0, 64 B, publiés / livrés par s	1,9k / 0	23,7k / 12,6k	29,3k / 29,2k
un flux, QoS 0, 1 KiB	0 / 0	3,9k / 2,3k	5,4k / 5,4k
16 paires, déluge, QoS 0, 64 B	24,7k / 20,0k	43,2k / 37,4k	31,4k / 30,7k
16 paires, déluge, QoS 0, 1 KiB	3,7k / 2,9k	5,0k / 4,5k	5,9k / 5,7k
connexions perdues par exécution (16 paires, 64 B)	13 (7 à 16)	0 (0 à 0)	0

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.