urMQTT dopo il VPS: SQLite in modalità utente, confronto con Mosquitto, configurazione come dato e builder nel browser

Il secondo articolo, urMQTT su un vero VPS, si chiudeva con l'elenco "Che cosa viene dopo": H6 (SQLite fuori dal kernel), H7 (sicurezza del tempo), X11 (confronto con Mosquitto sullo stesso VPS) e la prima pubblicazione. Questo articolo segue quell'elenco nello stesso ordine e poi aggiunge due cose che nell'elenco non c'erano, perché sono comparse lungo la strada: la configurazione come dato, con un builder web di ISO, e l'MQTT in chiaro facoltativo, senza TLS. Come prima: che cosa avevamo pianificato, che cosa abbiamo costruito, che cosa ci ha sorpreso e che cosa è aperto. In questo articolo ci sono anche alcuni risultati che non vanno a favore di urMQTT; li abbiamo lasciati perché fanno parte della verità.

L'avvertenza iniziale resta la stessa: il progetto è pre-alfa, la prima pubblicazione è solo per VPS con KVM, e i numeri misurano codice, test ed esperimenti precisi, non la maturità in produzione.

Come si presenta nel tempo

Dall'articolo precedente (31.10. alle 23:00) a oggi (1.11. alle 20:41) il repository ha 59 nuovi commit, in tutto 178. Sono nati tutti in un solo giorno di calendario, quindi vale la stessa avvertenza di prima: il progetto è costruito con Claude Code (i commit portano Co-Authored-By: Claude), piano, codice, test e ADR nascono in cicli brevi e chiusi, e i numeri qui sotto parlano della quantità di codice e di verifiche, non di quanto lavoro umano ci sia dietro.

I numeri sono calcolati con lo stesso metodo dell'articolo precedente: tutti i file .rs fuori da vendor/ e fuzz/, le funzioni #[test], i titoli ## ADR- in docs/DECISIONS.md.

Momento	Commit	Ora	Righe di Rust	Test	ADR
articolo precedente	794f607	31.10. 23:00	89 790	739	104
H6 concluso	a0423cc	1.11. 03:59	95 078	754	107
X11	a29f49b	1.11. 07:56	95 579	754	108
builder web e mirror delle release	582783f	1.11. 16:49	105 645	848	122
MQTT in chiaro, documentazione	8f959f1	1.11. 19:05	112 408	926	125
oggi	d21e3ec	1.11. 20:41	112 408	926	126

Si è lavorato in parallelo su più branch, quindi l'ordine dei commit non è rigorosamente l'ordine del lavoro. Gli ADR sono numerati fino a 232, ma la numerazione ha dei vuoti (una parte è stata rinominata durante l'unione dei branch); contiamo i titoli, non il numero più alto. Le release: v0.2.0 (1.11., 18:45 UTC) e v0.2.1 (1.11., 20:22 UTC), entrambe contrassegnate come pre-release.

H6: SQLite in modalità utente

Che cosa avevamo pianificato. SQLite è fatto di 254 268 righe di C che analizzano il database, il WAL e il journal dal disco, e il disco può essere stato fabbricato o modificato. Finora girava nel kernel, con i privilegi del kernel. Che cosa abbiamo costruito (da ADR-210 a ADR-212): SQLite, le sue parti di libc e il suo heap sono stati spostati in un programma separato, dbworker, che gira in EL0 (aarch64) ovvero ring 3 (x86_64), in uno spazio di indirizzi proprio. Il kernel non linka più SQLite. Il worker parla con il kernel attraverso una finestra di memoria condivisa e dodici chiamate di sistema, e ogni lunghezza e ogni offset restituiti vengono controllati prima dell'uso. Un errore nel worker (accesso non consentito, istruzione non definita, budget di tempo di 30 s superato) termina la chiamata, il worker viene riavviato e il database viene riaperto dal WAL come all'avvio; dopo 5 riavvii in un minuto lo storage viene dichiarato guasto, invece di riavviarsi all'infinito.

Il costo, misurato su aarch64 con HVF, stessa VM, kernel con SQLite incorporato contro kernel con worker, sei avvii alternati per ciascuno:

Misura	Prima (nel kernel)	Dopo (worker)	Differenza
ingresso e uscita dalla modalità utente	-	1,1 us per giro
db-bench, 5 000 inserimenti in 50 transazioni, migliore / mediana	61,9k / 58,4k op/s	54,7k / 53,3k op/s	-11,6% / -8,7%
un inserimento per transazione, migliore / mediana	2 319 / 2 148 op/s	2 307 / 2 126 op/s	-0,5% / -1%
copia di sicurezza completa con una sola chiamata (23 MiB)	514 ms	635 ms	+23%

Le scritture su disco (1 572) e i flush (319) sono identici, come deve essere. Ciò che non è isolato è questo: il kernel continua a fidarsi di ciò che il worker restituisce, dopo il controllo della forma. Un worker compromesso può mentire (per esempio restituire una lista vuota di certificati revocati, e quindi "annullarne" la revoca), ma non può leggere la memoria del kernel, le chiavi TLS né le chiavi dei ticket. Non c'è KPTI, quindi le fughe di tipo Spectre/Meltdown non sono impedite e non affermiamo nulla al riguardo; la chiave PAC è condivisa tra EL0 ed EL1. Su x86_64 il costo del passaggio non lo abbiamo misurato su KVM (sotto TCG il numero sarebbe privo di senso), e il fuzzing del worker e del protocollo stesso non è concluso. La suite di test per lo storage (79 scenari, ognuno fa girare SQLite nel worker) passa su aarch64 HVF e su x86_64 TCG, su aarch64 TCG ne passano 76 (uno viene saltato perché TCG non ha MSI-X).

H7 è chiuso, ma non come avevamo annunciato. Il limite inferiore del tempo (ADR-050) e l'SNTP con consenso (T1) coprono il perimetro di H7; NTS (RFC 8915) resta fuori dal perimetro ed è annotato come rischio residuo, non come qualcosa che funziona. Non riteniamo che la sicurezza del tempo sia "risolta", ma che sia finita la sua parte dimostrabile.

Una nuova opzione di rete. Contabo non dà DHCP a un ISO personalizzato, quindi finora il VPS richiedeva un'immagine diversa da quella della VM di laboratorio. Ora network.mode = "auto" (ADR-214) interroga prima il DHCP e, se il lease non arriva nel tempo previsto (dhcp_timeout_s, predefinito 15 s) o lo perde, applica l'indirizzo statico indicato. Provato a mano su QEMU (con il DHCP usa il lease, senza rete dopo 5 s torna all'indirizzo statico); per questo non esiste ancora uno scenario smoke.

X11: confronto con Mosquitto sullo stesso VPS

Lo stesso tipo di macchina dell'articolo precedente (Contabo, 4 vCPU AMD EPYC, 8 GiB), carico da un host Linux a 15 ms di distanza, TLS 1.3 reciproco con gli stessi certificati da entrambe le parti, Mosquitto 2.0.21 su Debian 13 senza persistenza. Metodo e decisioni sono in ADR-213, i dati grezzi in docs/perf-results/. Mediana di tre esecuzioni.

	urMQTT	Mosquitto 2.0.21
handshake/s, 32 / 64 / 128 client (profilo bench)	169 / 278 / 413	82 / 140 / 184
idem, con i limiti come vengono distribuiti	185 / 262 / 333 (con 128: da 202 a 286 errori, reset degli handshake)	-
memoria per connessione inattiva (20 000 connessioni)	0,50 KB di heap del kernel (0,66 KB con 5 000)	26,8 KB di crescita del processo
latenza p50, QoS 0 / QoS 1, 800 messaggi/s, 64 B	14,0 / 14,8 ms	21,4 / 39,5 ms
QoS 1, 4 800 messaggi/s, consegnati/s (p50)	4 209 (77 ms)	4 235 (197 ms)
100 sottoscrittori, 50 messaggi/s: p50	16,6 ms	99 ms
flusso singolo, QoS 0, 64 B, pubblicati/s	2 962 (da 0 a 7 733)	22 749

Che cosa significa, e che cosa no. Gli handshake sono limiti inferiori per entrambi i server: il generatore di carico è una VM condivisa con il 60-70% di tempo di CPU rubato e con 128 thread era vicino al proprio limite, mentre i core di lavoro di urMQTT erano occupati solo per il 12-13%. Il rapporto con 128 client (circa 2,2 volte) è il più significativo; con 32 e 64 misura per lo più l'attesa dei client. I numeri di memoria non contano la stessa cosa (heap del kernel contro RSS del processo), quindi "circa 50 volte meno" è un ordine di grandezza, non un rapporto preciso. La latenza di 14 ms è un giro di rete (circa 15 ms), cioè "nessun tempo misurabile del broker"; le code (p99 circa 100-200 ms) sono dominate in entrambi i broker dagli host condivisi. Le differenze sotto circa il 20% non le affermiamo.

Che cosa non è andato a nostro favore ed è rimasto nelle tabelle: un singolo flusso TCP attraverso urMQTT portava da 2 a 8 volte meno che attraverso Mosquitto, con variazioni da zero a 7,7 mila messaggi al secondo tra un'esecuzione e l'altra, e il watchdog da 20 ms del gestore interrompeva connessioni vive quando l'hypervisor fermava una vCPU (nella configurazione di produzione action = "drop", da 6 a 8 connessioni per esecuzione con il flood QoS 0). Entrambe le cose sono descritte nella sezione seguente perché avevano cause nel nostro codice.

Perché il flusso singolo era lento: cause, non scuse

La cosa più facile sarebbe stata dire "VPS condiviso". Non l'abbiamo fatto: con lo stesso VPS e lo stesso metodo abbiamo cercato le cause. Ne sono state trovate cinque, quattro nel percorso dei dati e una nel watchdog (da ADR-221 a ADR-224):

Sintomo in X11	Causa in urMQTT	Modifica
flusso singolo 1,9k messaggi/s, spesso 0 consegnati	Risveglio perso: il ciclo di uscita restituiva l'elenco delle connessioni pronte sopra quello appena scritto; un sottoscrittore il cui buffer di uscita si era riempito una volta non veniva più servito finché un PINGRESP non lo svegliava	corretto (ADR-223)
qualche punto percentuale di perdita trasforma 48k in 14k messaggi/s	ogni segmento dopo uno perso veniva scartato (ricezione solo in ordine), quindi il recupero costava un giro di rete per segmento	coda dei segmenti fuori ordine, SACK (ADR-222)
tetto di 4,4 MB/s a 15 ms	finestra a 16 bit, coda di invio da 64 KiB e slow start che contava gli ACK, non i byte	scalatura della finestra, timestamp, conteggio dei byte (ADR-222)
ogni giro del flusso che sta nella finestra aspetta da 0 a 10 ms	il dispatcher dormiva fino al tick successivo da 10 ms (virtio-net non ha interrupt di ricezione)	polling della NIC ogni 200 us finché ci sono connessioni (ADR-224)
da 1 a 8 connessioni interrotte per esecuzione	il watchdog addebitava al gestore il tempo trascorso, e il VPS ferma le vCPU spesso e a lungo	il budget è il tempo in cui il core ha effettivamente lavorato (ADR-221)

Le interruzioni sono reali: su questo VPS i core da 0 a 2 hanno avuto una mediana da 36 a 80 tick in ritardo ogni 5 secondi, e l'interruzione peggiore nella finestra aveva una mediana di circa 70 ms e fino a 0,9 s (core 3, database e journal: fino a 1,55 s), mentre l'host non riporta tempo rubato (host steal 0 us). Per questo il watchdog aveva bisogno di un secondo orologio, non di un budget più grande.

	codice X11 (7f9517e)	ora (86a71ff)	Mosquitto
flusso singolo, QoS 0, 64 B, pubblicati / consegnati al s	1,9k / 0	23,7k / 12,6k	29,3k / 29,2k
flusso singolo, QoS 0, 1 KiB	0 / 0	3,9k / 2,3k	5,4k / 5,4k
16 coppie, flood, QoS 0, 64 B	24,7k / 20,0k	43,2k / 37,4k	31,4k / 30,7k
16 coppie, flood, QoS 0, 1 KiB	3,7k / 2,9k	5,0k / 4,5k	5,9k / 5,7k
connessioni perse per esecuzione (16 coppie, 64 B)	13 (da 7 a 16)	0 (da 0 a 0)	0

Watchdog: 148 connessioni interrotte in 30 esecuzioni sotto carico prima, 0 in 24 esecuzioni dopo; su un apparecchio locale che ritarda e perde frame, con una perdita dello 0,1% un flusso singolo da 64 B con 14,3k messaggi/s (kernel X11) ora arriva a 41,0k, e con lo 0,5% da 5,0k a 17,7k.

Che cosa questo non dice. urMQTT non è ancora più veloce di Mosquitto su un singolo flusso: a 64 B pubblica circa l'80% della sua velocità e consegna circa il 40%, perché scarta il QoS 0 quando il flusso del sottoscrittore è più lento di quello di chi pubblica (Mosquitto, senza limite, mette in coda). A 1 KiB nel flood a 16 coppie Mosquitto è avanti di circa il 15%, il che rientra nel rumore. Il generatore era di nuovo una VM condivisa con il 58-77% di tempo rubato. Il secondo giro (blocco dell'heap fuori dal percorso dei dati, SACK lato invio e altro) è sul branch non integrato perf-single-flow-wip; i suoi numeri non sono ancora affermazioni e qui non li riportiamo.

Una promessa che non avevamo fatto, ma che abbiamo mantenuto: la configurazione è un dato

Finora ogni configurazione era una nuova compilazione: chiavi e limiti erano incorporati nell'immagine. C1 lo rovescia (da ADR-215 a ADR-219): il kernel si compila una volta sola e la configurazione è un dato.

• Blob urmqtt-cfg (C1a): una registrazione versionata e canonica (campi per tag crescente, impronta SHA-256, firma Ed25519 separata facoltativa), 70 campi con valori predefiniti e limiti, un decodificatore che rifiuta tutto ciò che non è valido.
• Il kernel lo legge come modulo Limine (C1b), prima di qualsiasi altra cosa, su aarch64 e x86_64. Esiste un solo kernel pubblicato per ogni ENV tranne dev (gli ELF aarch64 per release, prod e bench hanno lo stesso SHA-256; verificato solo su aarch64). Il kernel pubblicato rifiuta la configurazione di sviluppo e, senza configurazione, scrive "refusing to serve" e non serve nulla.
• Il disco installato porta la configurazione e l'aggiornamento la conserva (C1c).
• urmqtt-config e il modello ISO (C1d): pack, show, verify, e pack --iso sostituisce entrambe le copie dello slot di configurazione e i 24 digest dei moduli in un ISO già pronto. Il risultato è identico byte per byte all'ISO che mkiso.sh --config costruisce. Il modello della release v0.2.0 è di 63 111 168 byte.
• Dichiarazione di fiducia (ADR-219): l'immagine configurata, all'avvio, stampa l'impronta della configurazione (config: fingerprint ...), mentre la firma è facoltativa e disattivata per impostazione predefinita. Un ISO modificato non ha il digest ufficiale; l'impronta è il modo per vedere che cosa contiene.

Il builder su aldo.tech

Ciò che fa urmqtt-config pack --iso lo fa anche la pagina web, con lo stesso codice: la libreria dello strumento compilata in WebAssembly (1,06 MB, senza import e senza blocchi unsafe). La pagina è su aldo.tech/it/prodotti/urmqtt-builder/ ed esiste in tutte le 15 lingue del sito (per esempio hr).

• Nulla lascia il browser. Certificati, chiavi private e l'ISO finito restano sul computer; la pagina scarica soltanto i file della release da questo sito, senza tracciamento e senza script di terze parti. Nel test dal vivo nessuna richiesta portava materiale di chiavi.
• Mirror delle release (ADR-227): ogni ora (timer systemd, a bassa priorità) copia le release da GitHub, ognuna viene verificata prima della pubblicazione, e la pagina nel browser verifica la firma di SHA256SUMS con la chiave incorporata nella pagina, e solo dopo scrive la configurazione nel modello. Una verifica fallita blocca il download.
• Semplice per impostazione predefinita, avanzato quando serve (ADR-232): la prima schermata ha tre passaggi (dove gira, i vostri certificati, il nome dell'immagine). Un solo campo di trascinamento ordina certificato, chiave e CA in base al contenuto. La vista avanzata apre ciascuno dei 70 campi, la ricerca, l'importazione e l'esportazione di TOML; le due viste modificano lo stesso stato. Il modello (63 MB) viene scaricato mentre l'utente compila il modulo. In una prova dal vivo, con mirror di prova e chiave di prova, la creazione dell'ISO nel browser è durata da 5 a 18 s.

L'emulatore, facoltativo. Accanto a "Scarica ISO" c'è "Prova nell'emulatore": QEMU compilato in WebAssembly avvia l'immagine appena creata in una scheda del browser. Nulla di esso viene scaricato prima del clic (circa 3 MB la prima volta). L'emulatore è solo BIOS, senza rete (perché il traffico dell'utente non passi attraverso un intermediario e non violi il "nulla lascia il browser"), richiede circa 1,5 GB di memoria e un browser per computer (testato Chrome; Firefox e Safari no). Al suo interno urMQTT arriva a URMQTT READY in circa 8 s (saltando il conto alla rovescia) e stampa la stessa impronta di configurazione della pagina, il che prova che è stata avviata proprio quella configurazione. L'avvio è circa 2 volte più lento del QEMU nativo sullo stesso Mac (0,82 s contro 1,9 s), e la crittografia circa 58 volte più lenta perché le istruzioni hardware sono emulate. Per questo dall'emulatore non ricaviamo alcuna affermazione sulla velocità, e la pagina lo dice prima dell'avvio. Durante la compilazione è stato necessario correggere quattro byte nel .wasm a causa di un errore nella traduzione dell'istruzione POPCNT nell'emulatore originale (non l'abbiamo ancora segnalato); l'emulatore stesso è sotto GPL, con offerta del codice sorgente.

MQTT in chiaro, solo per reti di cui ci si fida

L'MQTT in chiaro (TCP 1883, senza TLS) è molto diffuso nell'IoT: è l'impostazione predefinita di Mosquitto, nella maggior parte dei firmware per Arduino ed ESP, in Tasmota, Zigbee2MQTT e Home Assistant, e viene usato anche all'interno di reti industriali segmentate, dietro una VPN e su LAN private, e anche su dispositivi senza orologio (i certificati richiedono una data), senza abbastanza flash o processore per il TLS. Su una rete non affidabile non è accettabile: chi è sul percorso legge e modifica il traffico. Per questo P1 (da ADR-229 a ADR-231) è una scelta esplicita e limitata, disattivata per impostazione predefinita, e la porta TLS resta; il TLS non viene disattivato da questa opzione, la porta in chiaro si aggiunge.

• L'elenco delle reti consentite è obbligatorio (allow_from, CIDR) e viene controllato al SYN: fuori dall'elenco non c'è SYN-ACK né stato. L'intera internet (0.0.0.0/0) richiede un'opzione esplicita a parte.
• Tre modalità di accesso: password (predefinita quando è attivo; PBKDF2-HMAC-SHA-256, salt, 10 000 iterazioni, confronto a tempo costante, blocco per indirizzo), anonimo (una identità configurata con un proprio ACL) e per indirizzo (ip). Il builder calcola l'hash della password nel browser e in memoria tiene solo il digest.
• Meno diritti che con mTLS: un client in chiaro non ha mai diritti di servizio, di operatore né di gestione, non ha $SYS né console, ha proprie sessioni ($plain/<identità>/<id client>, solo pulite), propri limiti e il registro dei consentiti continua a vincolarlo.
• Che cosa si perde, lo dice SECURITY.md: riservatezza, integrità, autenticità del broker e la riproduzione di un accesso registrato. Questo non si può correggere con la configurazione; è così quando non c'è il TLS.

Misurato su un laptop (Apple silicon, HVF, rete utente QEMU), 16 coppie, 64 B, tre esecuzioni da 10 s: a 8 000 messaggi al secondo il percorso TLS e quello in chiaro consegnano tutti i messaggi con la stessa latenza (p50 0,17 ms contro da 0,13 a 0,18 ms), nuove connessioni al secondo: TLS circa 2 600-2 750, anonimo in chiaro circa 4 900-7 800, e l'accesso con password è la parte costosa: un PBKDF2 costa circa 2,5 ms, quindi il numero di nuovi accessi è limitato a circa 200 per core dati al secondo (misurati da 308 a 342 su due core). Il flood su quella macchina non è uno strumento stabile (da 20k a 440k consegnati al secondo tra un'esecuzione e l'altra) e non ne ricaviamo conclusioni. Il confronto del percorso in chiaro con Mosquitto su VPS non è ancora stato fatto. Test: gruppo smoke plaintext 7 su 7 su aarch64 HVF e su x86_64 TCG, nuovo target fuzz plain_input (2,3 milioni di esecuzioni senza risultati).

Gli errori trovati dall'uso dal vivo

Due cose non le hanno trovate i test, ma la prima messa in funzione sul sito vero:

• La pagina cercava i file della release una directory troppo in alto, quindi ogni verifica della firma rispondeva 404 (correzione 13af301). Il test usava un mirror di prova su un altro percorso.
• La tastiera dell'emulatore non è mai arrivata al guest: la causa non era una cattiva traduzione dei tasti, ma il fatto che la finestra di dialogo non ascoltava affatto i tasti (correzione in ADR-232, con una voce di avvio che non richiede tasti).

Lezioni

• Cercate la causa, non incolpate l'ambiente. La maggior parte delle debolezze del flusso singolo e tutte le connessioni interrotte erano nostre; l'hypervisor è reale, ma andava misurato, non presupposto.
• Il confronto con un altro prodotto deve includere anche le perdite. Una tabella con solo le nostre vittorie non sarebbe un confronto.
• Lo strumento di misura ha dei limiti. Un generatore condiviso con il 60-70% di tempo rubato cambia il significato dei numeri; per questo scriviamo "limite inferiore" e non affermiamo differenze sotto il 20%.
• L'isolamento non è una dimostrazione. SQLite in EL0 riduce ciò che un errore al suo interno può fare, non ciò su cui può mentire.
• Un'installazione reale trova ciò che i test non cercano: un percorso composto male e tasti che nessuno ascolta.

Che cosa non è ancora dimostrato

• La chiave di firma della release per ora è una chiave di prova; v0.2.0 e v0.2.1 sono pre-release, e le immagini che le accompagnano sono di sviluppo con certificati di prova (tranne il modello, che è senza configurazione).
• 13 traduzioni della pagina del builder (e di questo articolo) sono state scritte da un'AI e verificate con test e campioni, non da madrelingua.
• Il confronto con Mosquitto è una sola sessione, un solo percorso e un solo generatore condiviso, su un VPS condiviso; le differenze sotto il 20% non sono affermazioni.
• Il percorso in chiaro non è stato misurato su VPS né contro Mosquitto.
• Lighthouse sulla nuova vista semplice non è confermato (vista precedente: accessibilità 95 o più).
• Bare metal, costo del worker x86_64 su KVM, Firefox e Safari per l'emulatore: non misurato.

Che cosa viene dopo

• D1: broker demo pubblico. L'emulatore del browser non possiamo renderlo pubblico: vive nella scheda di un solo visitatore, è da 20 a 100 volte più lento di KVM, non ha rete in ingresso e sparisce con la chiusura della scheda; far passare internet nel browser di qualcun altro sarebbe anche un abuso. Un vero broker demo è possibile: urMQTT su un VPS dietro un nome su aldo.tech, con una CA di prova pubblicata, un ACL severo e piccoli limiti. Per ora è solo un'idea, non un lavoro in corso, e richiede un consenso esplicito per l'esposizione pubblica.
• Secondo giro per il flusso singolo (branch perf-single-flow-wip): solo quando sarà misurato su VPS e unito.
• Percorso in chiaro contro Mosquitto su VPS, registrazione e revoca dell'account per l'MQTT in chiaro attraverso il canale di gestione firmato.
• Dopo la pubblicazione: bare metal (da X12 a X16), IOMMU e Secure Boot, cifratura del disco.

Il codice è su github.com/zeljan-alduk/urMQTT, e docs/PROGRESS.md resta l'unica fonte di verità su ciò che funziona davvero, docs/PERFORMANCE.md su ciò che è stato misurato. Pre-alfa, come prima; segnalazioni di errori e di sicurezza secondo le istruzioni in SECURITY.md sono benvenute.