Tactische Berichtenarchitectuur: NATS vs Kafka vs MQTT voor C2-systemen

Een tactisch command-and-control-systeem is een gedistribueerde applicatie die draait op radio's, voertuigen, voetoperatoren en servers in het achtergebied. De messaging-bus is de ruggengraat. Kies de verkeerde en het systeem voelt snel in het lab maar sterft op een betwiste verbinding. Kies de juiste en de operator ziet een gefuseerd beeld vernieuwen binnen hun beslissingscyclus.

Dit artikel behandelt de vier kandidaten die daadwerkelijk voorkomen in productie-C2-builds — NATS, Apache Kafka, MQTT en RabbitMQ — en legt een beslissingskader vast voor het kiezen ertussen. De korte versie: er is geen enkel antwoord. Echte systemen draaien er twee of drie, overbrugd.

1. Het Tactische Berichtenprobleem

Tactische netwerken zijn geen datacenternetwerken. Bandbreedte op een typieke VHF gevechtsradio wordt gemeten in kilobits per seconde, niet megabits. Round-trip-tijden over een MANET (mobiel ad-hoc-netwerk) overschrijden regelmatig 500ms. Pakketverlies boven 20% is normaal onder storingstactieken. Verbindingen flappen wanneer platforms achter terrein bewegen. Een satellietcommunicatie-backhaul raakt overbelast tijdens de ochtendinzet en weer bij het laatste daglicht.

De operator tolereert geen verouderde data. Een gefuseerd spoor dat twee minuten oud is, is erger dan geen spoor — het presenteert een zelfverzekerde leugen over waar een dreiging zich bevindt. De bus moet daarom berichtverval afdwingen, verse toestand prioriteren boven achterstand en gracieus degraderen wanneer de verbinding terugkeert na een partitie in plaats van tien minuten in de wachtrij geplaatste telemetrie in één keer te dumpen.

Volgorde is ook belangrijk, maar niet uniform. Telemetrie kan worden samengevoegd (alleen de laatste positie telt). Opdrachten niet — een "wapens vasthouden" uitgevaardigd op T+5 mag niet worden ingehaald door een "wapens vrij" uitgevaardigd op T+3 dat te laat aankwam. De bus heeft per onderwerp verschillende leveringssemantieken nodig, niet één globale garantie.

Ten slotte moet de bus een partitie overleven. Wanneer de radioverbinding terugkeert na een uitval van vijf minuten, zijn drie gedragingen verkeerd: alle berichten in de wachtrij in één keer dumpen (overweldigt de consument), alles stilzwijgend weggooien (verliest geordende opdrachten) en herordenen tijdens het inhalen (levert verouderd wapens-vrij na vers wapens-vasthouden). Het juiste gedrag is per onderwerp: samenvoegen-bij-herstel voor telemetrie, geordend leeglopen met tijdstempels voor opdrachten, volledige replay voor auditlogs. Geen enkele leveringsmodus bevredigt alle drie.

2. NATS en JetStream

NATS is een kleine, eigenzinnige pub-sub-bus geschreven in Go. Een enkel binair bestand, geen externe afhankelijkheden, standaard in-memory onderwerpen en sub-milliseconde publiceer-tot-lever-latentie op een LAN. Footprint is in de tientallen megabytes — klein genoeg voor een voertuigcomputer of een geharde edge-node.

Core NATS is fire-and-forget. JetStream is de persistentielaag toegevoegd in 2020: duurzame streams, replay op volgorde of tijd, consumercursors, berichtverval en per-onderwerp deduplicatievensters. JetStream gebruikt Raft voor replicatie. Een 3-node JetStream-cluster is de standaard tactische kern-implementatie — quorum overleeft één knooppuntverlies, en de streams repliceren zonder een afzonderlijke Zookeeper-stijl coördinator.

NATS wint wanneer het dominante verkeer kleine, frequente, lage-latentie berichten zijn tussen services — opdrachten, gefuseerde sporupdates, microservice-RPC via request-reply-onderwerpen. Het is de standaarddbus voor service-to-service-verkeer binnen een fusie-engine.

Waar het faalt: de replicatie van JetStream is uitstekend binnen een cluster maar is niet ontworpen om een verslechterd WAN te overspannen. Leaf-nodes kunnen een NATS-topologie uitbreiden naar edge-apparaten, maar als de leaf uren offline gaat, wordt het inhaalvenster begrensd door de retentie van de stream — niet door de verwachtingen van de leaf. Behandel NATS als de kernbus, niet de breedbandbus.

De te noemen fout-tolerantie-uitruil: JetStream Raft-quorum vereist dat een meerderheid van replica's een schrijfbewerking bevestigt. In een 3-node-cluster betekent dat twee bevestigingen. Als één knooppunt onderhoud ondergaat en een tweede zijn schijf verliest, stagneren schrijfbewerkingen — het cluster bewaart consistentie ten koste van beschikbaarheid. Voor een tactische kern is dat de juiste keuze; consistentie van het operationele beeld is niet onderhandelbaar. Maar het operatorpatroon is belangrijk: voer geen JetStream 3-node-clusters uit waarbij twee knooppunten een enkel storingspunt delen, zoals één switch of één voeding.

3. Apache Kafka

Kafka is de duurzaamheidskampioen. Een append-only-log per partitie, replicatiefactor configureerbaar per onderwerp, retentie gemeten in dagen of weken, en een consumentenmodel waarmee nieuwe clients geschiedenis kunnen herspelen vanaf offset nul. Voor after-action review, auditlogging en analyses over historische operationele data is Kafka bijna altijd het juiste antwoord.

Het is ook duur. Een productie-Kafka-cluster wil minimaal drie brokers, snelle lokale schijven, gigabytes paginacache en ofwel Zookeeper (legacy) of KRaft (huidig, sinds Kafka 3.3 GA eind 2022, standaard in 3.5+). Partitieherbalancering onder netwerkpartitie is een bekend operationeel gevaar. Consumentengroepcoördinatie gaat ervan uit dat er een stabiele verbinding is met de groepscoördinator-broker.

Het "Kafka-voor-alles"-patroon dat werkt in cloud-native winkels faalt aan de tactische rand om drie redenen. Ten eerste is de resourcefootprint verkeerd — een JVM-gebaseerde broker op een fanless edge-box verliest het altijd van een NATS-binair bestand. Ten tweede straft Kafka's standaard voor sterke duurzaamheid je op een verbinding met hoog verlies: producenten stagneren terwijl ze wachten op bevestigingen. Ten derde is de operationele complexiteit (brokerconfiguratie, onderwerppartitioneringsstrategie, retentieafstemming, ISR-monitoring) niet te rechtvaardigen wanneer de box onbeheerd op een vooruitgeschoven positie staat.

Kafka hoort thuis op het strategische niveau — het achtergebied-cluster dat geaggregeerde eventstreams inneemt van vooruitgeschoven gateways en deze levert aan analyses, trainingsgegevenspijplijnen en langetermijnarchief.

4. MQTT

MQTT is in 1999 ontworpen voor olieleidingtelemetrie via satellietverbindingen — precies het netwerkprofiel dat een tactisch sensornetwerk vandaag presenteert. Kleine header-overhead (2-byte vaste header in het minimale geval), drie kwaliteitsserviceniveaus (0 fire-and-forget, 1 ten minste één keer, 2 precies één keer) en een onderwerpshiërarchie die van nature wordt toegewezen aan sensor → eenheid → echelonstructuren.

MQTT 5.0, afgerond in 2019, voegde de functies toe die het operationeel serieus maken voor defensie. Gedeelde abonnementen ($share/groep/onderwerp) balanceren een onderwerp over een consumentengroep — nuttig voor fan-out verwerking van sensordata. Vervaltijden voor berichten verwijderen verouderde tactische data automatisch bij de broker. Gebruikerseigenschappen dragen classificatielabels en vrijgevingsmarkeringen als berichtmetadata. Onderwerpaliassen comprimeren herhaalde lange onderwerpstrings na de eerste publicatie tot één byte — een echte winst op een 9600 bps-radio.

De brokerszijde is volwassen: Mosquitto voor kleine footprints, EMQX of HiveMQ voor grotere geclusterde implementaties met gedeelde abonnementen en overbruggen. Alle drie draaien op edge-klasse hardware. MQTT-SN (Sensor Networks) breidt het protocol uit via niet-TCP-transporten voor de echt kleine — batterijgevoede sensoren zonder IP-stack.

De zwakte van MQTT is duurzaamheid. Persistente sessies en QoS 2 geven je betrouwbare levering aan een bekende client, maar MQTT is geen eventlog — er zijn geen replay-by-offset-semantieken. Als een consument de verbinding verbreekt na het verstrijken van zijn sessie, zijn de berichten weg. Voor sensortelemetrie is dat acceptabel. Voor een audittrail is dat niet zo.

5. RabbitMQ en AMQP

RabbitMQ dateert van vóór de cloud-native berichtengolf en verdient nog steeds zijn plaats. Het AMQP 0-9-1-model — exchanges, bindingen, wachtrijen — biedt routeringsflexibiliteit die pub-sub-buses niet kunnen evenaren. Onderwerpexchanges met wildcard-bindingen, header-exchanges voor op inhoud gebaseerde routing, dead-letter-wachtrijen voor mislukte berichten, per-wachtrij-TTL's en per-bericht-bevestiging met hertellingstelling voor leveringen.

Voor workflows waarbij een bericht precies één keer door precies één werker moet worden verwerkt, met expliciete bevestigings- en herpogingenSemantieken, is RabbitMQ nog steeds het schoonste antwoord. Voorbeelden in een C2-stack: toewijzingsworkflows waarbij elke toewijzing naar één operator gaat, geocoderingsverzoeken die een externe service bereiken, OCR-taken tegen vastgelegde beeldmateriaal. Dit zijn wachtrijproblemen, geen stroomproblemen, en wachtrijsemantieken zijn wat RabbitMQ doet.

Observeerbaarheid is de andere stille kracht — de beheers-UI, de Prometheus-exporteur en per-wachtrij-metrics maken het de gemakkelijkste van de vier om te bedienen om 03:00 wanneer er iets mis is. Voor een klein ops-team dat een onbeheerde tactische cloud beheert, maakt dat uit.

De limieten van RabbitMQ worden zichtbaar bij zeer hoge doorvoer (het is geen bus van een miljoen berichten per seconde) en op onstabiele netwerken (het verbindingsgeoriënteerde AMQP-model houdt niet van verbindingsflappen). Gebruik het voor de workflowlaag, niet de telemetriestroom.

6. Buses Overbruggen

Productie-C2-systemen draaien tegelijkertijd twee of drie buses. Een representatieve implementatie: MQTT aan de rand voor sensor- en radioverkeer, NATS in de tactische kern voor service-to-service-opdrachten en gefuseerde sporen, Kafka op het strategische niveau voor duurzaam eventarchief. RabbitMQ kan naast NATS verschijnen voor de workflowlaag.

De bruggen zijn eersteklas componenten, geen bijgedachten. Een MQTT-naar-NATS-gateway abonneert zich op geselecteerde MQTT-onderwerpen, transformeert de payload naar het canonieke interne schema en publiceert opnieuw op een NATS-onderwerp. Een NATS-naar-Kafka-brug verbruikt JetStream-streams en produceert naar Kafka-onderwerpen met dezelfde partitieringstrategie. Schemavertaling, terugdrukverwerking en idempotente herpublicatie bij brugherstart zijn de moeilijke delen — niet de verbinding zelf.

Bouw de bruggen met dezelfde technische discipline als elke andere service: gezondheidscontroles, metrics, een gedefinieerde replayprocedure bij herstart en duidelijk eigenaarschap. De klassieke faalwijze is een brug die stilzwijgend berichten laat vallen onder belasting omdat de interne wachtrij overliep.

7. Beveiliging en Classificatie

Elke bus spreekt TLS. Elke bus ondersteunt wederzijdse TLS met clientcertificaten. Dat is noodzakelijk, maar niet voldoende.

Isolatie per enclave is de volgende laag: een afzonderlijke broker-instantie met een afzonderlijke certificaatautoriteit voor elk classificatieniveau. De bus binnen de GEHEIME enclave praat nooit rechtstreeks met de bus binnen de NIET-GECLASSIFICEERDE enclave. Cross-domain-vrijgave gaat via een goedgekeurde bewaker of cross-domain-oplossing die strippt, transformeert en opnieuw publiceert — nooit via een brokerbrug.

Per-onderwerp-ACL's zijn de derde laag. Op NATS, accounts en onderwerprechten. Op MQTT, broker-ACL-bestanden of een plugin. Op Kafka, ACL's via de AdminClient API. Op RabbitMQ, gebruiker-vhost-resource-rechten. Standaard-weigeren is de enige aanvaardbare houding: een service kan publiceren naar en abonneren op precies de onderwerpen die zijn rol vereist, en geen andere.

Berichtmetadata draagt classificatielabels — MQTT 5 gebruikerseigenschappen, NATS-headers, Kafka-headers. De broker dwingt classificatiesemantieken niet af; de verbruikende services en de cross-domain-bewaker doen dat. De broker dwingt af wie welk onderwerp kan lezen.

8. Beslissingskader

Beoordeel elke verkeersklasse op vier assen:

Latentiebudget. Sub-milliseconde service-to-service-RPC: NATS. Tientallen milliseconden voor sensortelemetrie: MQTT. Seconden voor archiefinname: Kafka. Per-bericht-workflowstappen met bevestigingssemantieken: RabbitMQ.

Doorvoer. Tot ~10k berichten/sec per onderwerp op bescheiden hardware: elk van de vier. 100k+ aanhoudend per onderwerp: NATS of Kafka. Miljoenen over vele onderwerpen: Kafka. Sensorinvloed van duizenden laag-frequente clients: MQTT met gedeelde abonnementen.

Duurzaamheid. Geen replay vereist: core NATS of MQTT QoS 0/1. Replay binnen een sessie of korte periode: NATS JetStream, MQTT persistente sessies. Meerdaagse audit-grade replay: Kafka. Per-bericht-bevestiging met herpoging en dead-letter: RabbitMQ.

Edge-netwerkrealiteit. 9600 bps radio met 30% verlies: MQTT, met onderwerpaliassen en QoS 1. Tactisch LAN binnen een voertuig: NATS. Strategisch WAN naar een achtergebiedcluster: Kafka met een gateway ervoor. Intermitterende satellietcommunicatie: MQTT voor telemetrie, asynchrone Kafka-producent met lokale spool voor archief.

Bouw de matrix voor uw specifieke systeem. Elke verkeersklasse wordt toegewezen aan één bus. De bruggen ertussen zijn expliciet. De implementatie draait de buses die het nodig heeft en niet meer — het toevoegen van een bus heeft een operationele kost, en die kost wordt betaald elke dienst, niet alleen tijdens integratietijd.