urMQTT depois do VPS: SQLite em modo utilizador, comparação com o Mosquitto, configuração como dado e um construtor no navegador

O segundo texto, urMQTT num VPS real, terminou com uma lista "O que se segue": H6 (SQLite fora do kernel), H7 (segurança do tempo), X11 (comparação com o Mosquitto no mesmo VPS) e a primeira versão. Este texto segue essa lista pela mesma ordem e depois acrescenta duas coisas que não estavam nela, porque surgiram pelo caminho: a configuração como dado, com um construtor web de ISO, e o MQTT simples opcional, sem TLS. Como antes: o que planeámos, o que construímos, o que nos surpreendeu e o que continua em aberto. Neste texto há também alguns resultados que não favorecem o urMQTT; deixámo-los porque fazem parte da verdade.

A nota prévia mantém-se: o projeto é pré-alfa, a primeira versão destina-se apenas a VPS com KVM, e os números medem código, testes e experiências determinadas, não maturidade em produção.

Como isto se desenrolou no tempo

Desde o texto anterior (31.10. às 23:00) até hoje (1.11. às 20:41) o repositório tem 59 commits novos, 178 no total. Todos nasceram num único dia de calendário, pelo que vale o mesmo aviso de antes: o projeto é construído com o Claude Code (os commits trazem Co-Authored-By: Claude), o plano, o código, os testes e os ADR nascem em ciclos curtos e fechados, e os números abaixo falam da quantidade de código e de verificações, não de quanto trabalho humano há neles.

Os números foram calculados com o mesmo método do texto anterior: todos os ficheiros .rs fora de vendor/ e fuzz/, funções #[test], títulos ## ADR- em docs/DECISIONS.md.

Momento	Commit	Hora	Linhas de Rust	Testes	ADR
texto anterior	794f607	31.10. 23:00	89 790	739	104
H6 concluído	a0423cc	1.11. 03:59	95 078	754	107
X11	a29f49b	1.11. 07:56	95 579	754	108
construtor web e espelho das versões	582783f	1.11. 16:49	105 645	848	122
MQTT simples, documentação	8f959f1	1.11. 19:05	112 408	926	125
hoje	d21e3ec	1.11. 20:41	112 408	926	126

Trabalhou-se em paralelo em vários ramos, pelo que a ordem dos commits não é estritamente a ordem do trabalho. Os ADR estão numerados até 232, mas a numeração tem lacunas (parte foi renumerada ao juntar ramos); contamos os títulos, não o número mais alto. Versões: v0.2.0 (1.11., 18:45 UTC) e v0.2.1 (1.11., 20:22 UTC), ambas marcadas como pre-release.

H6: SQLite em modo utilizador

O que planeámos. O SQLite são 254 268 linhas de C que fazem o parsing da base de dados, do WAL e do diário a partir do disco, e o disco pode ser fabricado ou alterado. Até aí corria no kernel, com os privilégios do kernel. O que construímos (ADR-210 a ADR-212): o SQLite, as suas partes da libc e o heap foram movidos para um programa separado, dbworker, que corre em EL0 (aarch64) ou ring 3 (x86_64), no seu próprio espaço de endereçamento. O kernel já não liga o SQLite. O worker comunica com o kernel através de uma janela de memória partilhada e de doze chamadas de sistema, e cada comprimento e deslocamento devolvidos é verificado antes de ser usado. Um erro no worker (acesso ilegal, instrução indefinida, orçamento de tempo de 30 s excedido) termina a chamada, o worker é reiniciado e a base de dados é aberta a partir do WAL como num arranque; após 5 reinícios num minuto o armazenamento é declarado avariado, em vez de reiniciar indefinidamente.

O custo, medido em aarch64 sob HVF, a mesma VM, kernel com SQLite incorporado contra kernel com worker, seis arranques alternados de cada:

Medição	Antes (no kernel)	Depois (worker)	Diferença
entrada e saída do modo utilizador	-	1,1 us por ciclo
db-bench, 5 000 inserções em 50 transações, melhor / mediana	61,9k / 58,4k op/s	54,7k / 53,3k op/s	-11,6% / -8,7%
uma inserção por transação, melhor / mediana	2 319 / 2 148 op/s	2 307 / 2 126 op/s	-0,5% / -1%
cópia de segurança completa numa só chamada (23 MiB)	514 ms	635 ms	+23%

As escritas em disco (1 572) e os flushes (319) são idênticos, como tem de ser. O que não está isolado é isto: o kernel continua a confiar no que o worker devolve, depois de verificar a forma. Um worker comprometido pode mentir (por exemplo, devolver uma lista vazia de certificados revogados e assim "desrevogá-los"), mas não pode ler a memória do kernel, as chaves TLS nem as chaves dos tickets. Não há KPTI, pelo que as fugas do tipo Spectre/Meltdown não estão impedidas e não afirmamos nada sobre elas; a chave PAC é partilhada por EL0 e EL1. Em x86_64 não medimos o custo da mudança em KVM (sob TCG o número não faria sentido), e o fuzzing do próprio worker e do protocolo ainda não está concluído. O conjunto de testes de armazenamento (79 cenários, cada um a usar o SQLite no worker) passa em aarch64 HVF e x86_64 TCG, e em aarch64 TCG passam 76 (um é ignorado porque o TCG não tem MSI-X).

O H7 está fechado, mas não da forma que anunciámos. O limite inferior do tempo (ADR-050) e o SNTP com consenso (T1) cobrem o âmbito do H7; o NTS (RFC 8915) fica fora do âmbito e está registado como risco residual, não como algo que funciona. Não consideramos que a segurança do tempo esteja "resolvida", mas sim que a sua parte demonstrável está concluída.

Nova opção de rede. A Contabo não dá DHCP a um ISO personalizado, pelo que o VPS precisava, até aqui, de uma imagem diferente da da VM de laboratório. Agora network.mode = "auto" (ADR-214) pergunta primeiro ao DHCP e, se não houver concessão dentro do prazo (dhcp_timeout_s, por omissão 15 s) ou se a perder, aplica o endereço estático por omissão. Experimentado manualmente em QEMU (com DHCP usa a concessão, sem rede volta ao endereço estático ao fim de 5 s); ainda não existe um cenário de smoke para isto.

X11: comparação com o Mosquitto no mesmo VPS

O mesmo tipo de máquina do texto anterior (Contabo, 4 vCPU AMD EPYC, 8 GiB), carga a partir de um anfitrião Linux a 15 ms de distância, TLS 1.3 mútuo com os mesmos certificados dos dois lados, Mosquitto 2.0.21 em Debian 13 sem persistência. O método e as decisões estão no ADR-213, os dados em bruto em docs/perf-results/. Mediana de três execuções.

	urMQTT	Mosquitto 2.0.21
handshakes/s, 32 / 64 / 128 clientes (perfil bench)	169 / 278 / 413	82 / 140 / 184
o mesmo, com os limites tal como são entregues	185 / 262 / 333 (com 128: 202 a 286 erros, resets de handshake)	-
memória por ligação inativa (20 000 ligações)	0,50 KB de heap do kernel (0,66 KB com 5 000)	26,8 KB de crescimento do processo
latência p50, QoS 0 / QoS 1, 800 mensagens/s, 64 B	14,0 / 14,8 ms	21,4 / 39,5 ms
QoS 1, 4 800 mensagens/s, entregues/s (p50)	4 209 (77 ms)	4 235 (197 ms)
100 subscritores, 50 mensagens/s: p50	16,6 ms	99 ms
fluxo único, QoS 0, 64 B, publicadas/s	2 962 (0 a 7 733)	22 749

O que isto significa e o que não significa. Os handshakes são limites inferiores para os dois servidores: o gerador de carga é uma VM partilhada com 60 a 70% de tempo de CPU roubado e, com 128 threads, estava perto do seu próprio limite, enquanto os núcleos de trabalho do urMQTT estavam ocupados apenas 12 a 13%. A razão com 128 clientes (cerca de 2,2 vezes) é a mais significativa; com 32 e 64 mede sobretudo a espera dos clientes. Os números de memória não contam o mesmo (heap do kernel contra RSS do processo), pelo que "cerca de 50 vezes menos" é uma ordem de grandeza, não uma razão precisa. A latência de 14 ms é uma ida e volta da rede (cerca de 15 ms), ou seja, "sem tempo mensurável do broker"; as caudas (p99 cerca de 100 a 200 ms) são dominadas, nos dois brokers, pelos anfitriões partilhados. Não afirmamos diferenças abaixo de cerca de 20%.

O que não correu a nosso favor e ficou nas tabelas: um fluxo TCP único através do urMQTT transportou 2 a 8 vezes menos do que através do Mosquitto, com variações de zero a 7,7 mil mensagens por segundo entre execuções, e o watchdog de 20 ms do handler interrompeu ligações vivas quando o hipervisor parou um vCPU (na configuração de produção action = "drop", 6 a 8 ligações por execução com inundação QoS 0). As duas coisas são descritas na secção seguinte, porque tinham causas no nosso código.

Porque é que o fluxo único era lento: causas, não desculpas

O mais fácil seria dizer "VPS partilhado". Não o fizemos: com o mesmo VPS e o mesmo método, procurámos as causas. Foram encontradas cinco, quatro no caminho de dados e uma no watchdog (ADR-221 a ADR-224):

Sintoma no X11	Causa no urMQTT	Alteração
fluxo único 1,9k mensagens/s, muitas vezes 0 entregues	Despertar perdido: o ciclo de saída devolvia a lista de ligações prontas por cima da que acabara de ser escrita; um subscritor cujo buffer de saída enchesse uma vez nunca mais era servido até um PINGRESP o acordar	corrigido (ADR-223)
uma perda de alguns por cento transforma 48k em 14k mensagens/s	cada segmento a seguir a um perdido era descartado (receção apenas por ordem), pelo que a recuperação custava uma ida e volta da rede por segmento	fila de segmentos fora de ordem, SACK (ADR-222)
teto de 4,4 MB/s a 15 ms	janela de 16 bits, fila de envio de 64 KiB e arranque lento que contava ACK, não bytes	escala da janela, timestamps, contagem de bytes (ADR-222)
cada ida e volta de um fluxo que cabe espera 0 a 10 ms	o despachante dormia até ao tick seguinte de 10 ms (o virtio-net não tem interrupção de receção)	polling da NIC a cada 200 us enquanto houver ligações (ADR-224)
1 a 8 ligações interrompidas por execução	o watchdog cobrava ao handler o tempo decorrido, e o VPS pára os vCPU com frequência e por muito tempo	o orçamento é o tempo em que o núcleo realmente trabalhou (ADR-221)

As paragens são reais: neste VPS os núcleos 0 a 2 tiveram uma mediana de 36 a 80 ticks atrasados por 5 segundos, e a pior paragem na janela teve mediana de cerca de 70 ms e chegou a 0,9 s (núcleo 3, base de dados e diário: até 1,55 s), enquanto o anfitrião não comunica tempo roubado (host steal 0 us). Por isso o watchdog precisava de outro relógio, não de um orçamento maior.

	código X11 (7f9517e)	agora (86a71ff)	Mosquitto
fluxo único, QoS 0, 64 B, publicadas / entregues por s	1,9k / 0	23,7k / 12,6k	29,3k / 29,2k
fluxo único, QoS 0, 1 KiB	0 / 0	3,9k / 2,3k	5,4k / 5,4k
16 pares, inundação, QoS 0, 64 B	24,7k / 20,0k	43,2k / 37,4k	31,4k / 30,7k
16 pares, inundação, QoS 0, 1 KiB	3,7k / 2,9k	5,0k / 4,5k	5,9k / 5,7k
ligações perdidas por execução (16 pares, 64 B)	13 (7 a 16)	0 (0 a 0)	0

Watchdog: 148 ligações interrompidas em 30 execuções com carga antes, 0 em 24 execuções depois; num aparelho local que atrasa e perde tramas, com 0,1% de perda um fluxo único de 64 B com 14,3k mensagens/s (kernel do X11) passa a ter 41,0k, e com 0,5% de 5,0k para 17,7k.

O que isto não diz. O urMQTT continua a não ser mais rápido do que o Mosquitto num fluxo único: com 64 B publica cerca de 80% da velocidade dele e entrega cerca de 40%, porque descarta QoS 0 quando o fluxo do subscritor é mais lento do que o do publicador (o Mosquitto, sem limite, põe em fila). Com 1 KiB na inundação de 16 pares o Mosquitto está à frente cerca de 15%, o que está dentro do ruído. O gerador voltou a ser uma VM partilhada com 58 a 77% de tempo roubado. A segunda ronda (bloqueio do heap fora do caminho de dados, SACK do lado do envio e outras coisas) está no ramo não integrado perf-single-flow-wip; os seus números ainda não são afirmações e não os apresentamos aqui.

A promessa que não fizemos, mas cumprimos: a configuração é dado

Até agora cada configuração era uma nova compilação: as chaves e os limites estavam incorporados na imagem. O C1 inverte isto (ADR-215 a ADR-219): o kernel é compilado uma vez e a configuração é dado.

• Blob urmqtt-cfg (C1a): registo versionado e canónico (campos por etiquetas crescentes, impressão digital SHA-256, assinatura Ed25519 separada opcional), 70 campos com valores por omissão e limites, e um descodificador que rejeita tudo o que esteja incorreto.
• O kernel lê-o como módulo do Limine (C1b), antes de qualquer outra coisa, em aarch64 e x86_64. Existe um único kernel de versão para cada ENV exceto dev (os ELF aarch64 de release, prod e bench têm o mesmo SHA-256; verificado apenas em aarch64). O kernel de versão rejeita uma configuração de desenvolvimento e, sem configuração, escreve "refusing to serve" e não serve nada.
• O disco instalado transporta a configuração e a atualização mantém-na (C1c).
• urmqtt-config e o modelo de ISO (C1d): pack, show, verify, e pack --iso substitui as duas cópias do espaço de configuração e os 24 resumos de módulos num ISO já pronto. O resultado é byte a byte igual ao ISO que mkiso.sh --config constrói. O modelo da versão v0.2.0 tem 63 111 168 bytes.
• Declaração de confiança (ADR-219): uma imagem configurada escreve no arranque a impressão digital da configuração (config: fingerprint ...), e a assinatura é opcional e desativada por omissão. Um ISO alterado não tem o resumo oficial; a impressão digital é a forma de ver o que está dentro dele.

O construtor em aldo.tech

O que urmqtt-config pack --iso faz, faz também uma página web, com o mesmo código: a biblioteca de ferramentas compilada para WebAssembly (1,06 MB, sem importações e sem blocos unsafe). A página está em aldo.tech/pt/produtos/urmqtt-builder/ e existe nos 15 idiomas do sítio (por exemplo hr).

• Nada sai do navegador. Os certificados, as chaves privadas e o ISO pronto ficam no computador; a página só descarrega os ficheiros da versão deste sítio, sem rastreamento nem scripts de terceiros. Num teste em produção, nenhum pedido transportou material de chaves.
• Espelho das versões (ADR-227): de hora a hora (systemd timer, baixa prioridade) copia as versões do GitHub, verifica cada uma antes de a publicar, e a página, no navegador, verifica a assinatura de SHA256SUMS com a chave incorporada na página, e só depois escreve a configuração no modelo. Uma verificação falhada bloqueia a transferência.
• Simples por omissão, avançado quando necessário (ADR-232): o primeiro ecrã tem três passos (onde vai funcionar, os seus certificados, o nome da imagem). Um único campo de arrastar ficheiros separa certificado, chave e CA pelo conteúdo. A vista avançada abre cada um dos 70 campos, pesquisa, importação e exportação de TOML; as duas vistas editam o mesmo estado. O modelo (63 MB) é descarregado enquanto o utilizador preenche o formulário. Num ensaio em produção, com um espelho de teste e uma chave de teste, a construção do ISO no navegador demorou 5 a 18 s.

Emulador, opcional. Ao lado de "Descarregar ISO" está "Experimentar no emulador": o QEMU compilado para WebAssembly executa a imagem acabada de construir num separador do navegador. Nada dele é descarregado antes do clique (cerca de 3 MB da primeira vez). O emulador é só BIOS, sem rede (para que o tráfego do utilizador não passe por um intermediário e desminta o "nada sai do navegador"), precisa de cerca de 1,5 GB de memória e de um navegador de computador (testado o Chrome; o Firefox e o Safari não). Nele o urMQTT chega a URMQTT READY em cerca de 8 s (com a contagem decrescente ignorada) e escreve a mesma impressão digital da configuração que a página, o que prova que foi arrancada exatamente essa configuração. O arranque é cerca de 2 vezes mais lento do que o QEMU nativo no mesmo Mac (0,82 s contra 1,9 s), e a criptografia cerca de 58 vezes mais lenta porque as instruções de hardware são emuladas. Por isso não tiramos do emulador nenhuma afirmação sobre velocidade, e a página diz-o antes do arranque. Na construção foi preciso corrigir quatro bytes no .wasm devido a um erro na tradução da instrução POPCNT no emulador original (ainda não o comunicámos); o próprio emulador está sob GPL, com oferta do código-fonte.

MQTT simples, só para redes em que confia

O MQTT simples (TCP 1883, sem TLS) é muito comum em IoT: é o predefinido no Mosquitto, na maioria dos firmwares para Arduino e ESP, no Tasmota, no Zigbee2MQTT e no Home Assistant, e usa-se também dentro de redes industriais segmentadas, atrás de VPN e em LAN privadas, incluindo em dispositivos sem relógio (os certificados exigem uma data), sem flash ou processador suficientes para TLS. Numa rede não fiável não é aceitável: quem está no caminho lê e altera o tráfego. Por isso o P1 (ADR-229 a ADR-231) é uma escolha explícita e limitada, desativada por omissão, e a porta TLS mantém-se; o TLS não é desligado por isto, a porta simples vem juntamente com ele.

• A lista de redes permitidas é obrigatória (allow_from, CIDR) e é verificada no SYN: fora da lista não há SYN-ACK nem estado. A internet inteira (0.0.0.0/0) exige uma opção explícita à parte.
• Três modos de autenticação: palavra-passe (por omissão quando ativado; PBKDF2-HMAC-SHA-256, sal, 10 000 iterações, comparação em tempo constante, bloqueio por endereço), anónimo (uma identidade configurada com a sua própria ACL) e por endereço (ip). O construtor calcula o hash da palavra-passe no navegador e guarda em memória apenas o resumo.
• Menos direitos do que o mTLS: um cliente simples nunca tem direitos de serviço, de operador nem de gestão, não tem $SYS nem consola, tem sessões próprias ($plain/<identidade>/<id do cliente>, apenas limpas), limites próprios, e o registo de permitidos continua a vinculá-lo.
• O que se perde está em SECURITY.md: confidencialidade, integridade, autenticidade do broker e a repetição de um início de sessão gravado. Isto não se corrige com configuração; é assim quando não há TLS.

Medido num portátil (Apple silicon, HVF, rede de utilizador do QEMU), 16 pares, 64 B, três execuções de 10 s: com 8 000 mensagens por segundo o caminho TLS e o simples entregam todas as mensagens com a mesma latência (p50 0,17 ms contra 0,13 a 0,18 ms), novas ligações por segundo: TLS cerca de 2 600 a 2 750, simples anónimo cerca de 4 900 a 7 800, e o início de sessão com palavra-passe é a parte cara: um PBKDF2 custa cerca de 2,5 ms, pelo que o número de novos inícios de sessão fica limitado a cerca de 200 por núcleo de dados por segundo (medido 308 a 342 em dois núcleos). A inundação nesta máquina não é um instrumento estável (20k a 440k entregues por segundo entre execuções) e não tiramos conclusões dela. A comparação do caminho simples com o Mosquitto no VPS ainda não foi feita. Testes: o grupo de smoke plaintext 7 de 7 em aarch64 HVF e em x86_64 TCG, novo alvo de fuzz plain_input (2,3 milhões de execuções sem achados).

Erros que o trabalho em produção encontrou

Duas coisas não foram apanhadas pelos testes, mas sim pela primeira ativação no sítio real:

• A página pedia os ficheiros da versão um diretório acima do correto, pelo que cada verificação de assinatura respondia 404 (correção 13af301). O teste usava um espelho de teste noutro caminho.
• O teclado do emulador nunca chegava ao convidado: a causa não era uma tradução incorreta das teclas, mas o facto de o diálogo nem sequer estar a escutar as teclas (correção no ADR-232, com uma entrada de arranque que não precisa de teclas).

Lições

• Procurem a causa, não culpem o ambiente. A maior parte das fraquezas do fluxo único e todas as ligações interrompidas eram nossas; o hipervisor é real, mas era preciso medi-lo, não presumi-lo.
• A comparação com outro produto tem de incluir também as perdas. Uma tabela em que só há vitórias nossas não seria uma comparação.
• O instrumento de medição tem limites. Um gerador partilhado com 60 a 70% de tempo roubado muda o que os números significam; por isso escrevemos "limite inferior" e não afirmamos diferenças abaixo de 20%.
• O isolamento não é uma prova. O SQLite em EL0 reduz o que um erro nele pode fazer, não aquilo sobre que pode mentir.
• Uma instalação real encontra o que os testes não pedem: um caminho mal composto e teclas que ninguém escuta.

O que ainda não está provado

• A chave de assinatura das versões é, por agora, uma chave de teste; a v0.2.0 e a v0.2.1 são pre-release, e as imagens que as acompanham são de desenvolvimento com certificados de teste (exceto o modelo, que não tem configuração).
• 13 traduções da página do construtor (e deste texto) foram escritas por uma IA e verificadas por testes e amostras, não por falantes nativos.
• A comparação com o Mosquitto é uma sessão, um caminho e um gerador partilhado, num VPS partilhado; diferenças abaixo de 20% não são afirmações.
• O caminho simples não foi medido no VPS nem contra o Mosquitto.
• O Lighthouse na nova vista simples não está confirmado (vista antiga: acessibilidade 95 ou mais).
• Bare metal, custo do worker em x86_64 em KVM, Firefox e Safari para o emulador: não medido.

O que se segue

• D1: broker de demonstração público. Não podemos tornar público o emulador do navegador: vive no separador de um visitante, é 20 a 100 vezes mais lento do que o KVM, não tem rede de entrada e desaparece quando o separador é fechado; redirecionar a internet para o navegador de outra pessoa seria também um abuso. É possível um verdadeiro broker de demonstração: o urMQTT num VPS atrás de um nome em aldo.tech, com uma CA de teste publicada, uma ACL estrita e pequenos limites. Por agora é apenas uma ideia, não uma construção, e precisa de consentimento explícito para a exposição pública.
• Segunda ronda para o fluxo único (ramo perf-single-flow-wip): só quando estiver medida no VPS e integrada.
• O caminho simples contra o Mosquitto no VPS, início de sessão e revogação de contas para MQTT simples através do canal de gestão assinado.
• Depois da versão: bare metal (X12 a X16), IOMMU e Secure Boot, cifragem do disco.

O código está em github.com/zeljan-alduk/urMQTT, e docs/PROGRESS.md continua a ser a única fonte de verdade sobre o que realmente funciona, docs/PERFORMANCE.md sobre o que foi medido. Pré-alfa, como antes; relatórios de erros e relatórios de segurança, segundo as instruções em SECURITY.md, são bem-vindos.