Taktische Messaging-Architektur: NATS vs. Kafka vs. MQTT für C2-Systeme

Ein taktisches Command-and-Control-System ist eine verteilte Anwendung, die über Funkgeräte, Fahrzeuge, abgesessene Operatoren und rückwärtige Server läuft. Der Messaging-Bus ist das Rückgrat. Wählt man den falschen, fühlt sich das System im Labor schnell an und stirbt an einer umkämpften Verbindung. Wählt man den richtigen, sieht der Operator ein fusioniertes Bild, das sich innerhalb seines Entscheidungszyklus aktualisiert.

Dieser Artikel durchläuft die vier Kandidaten, die tatsächlich in produktiven C2-Builds auftauchen — NATS, Apache Kafka, MQTT und RabbitMQ — und legt ein Entscheidungsframework dar, um zwischen ihnen zu wählen. Die Kurzfassung: Es gibt keine einzige Antwort. Echte Systeme betreiben zwei oder drei, überbrückt.

1. Das taktische Messaging-Problem

Taktische Netzwerke sind keine Rechenzentrumsnetzwerke. Bandbreite auf einem typischen VHF-Kampffunkgerät wird in Kilobit pro Sekunde gemessen, nicht in Megabit. Round-Trip-Zeiten über ein MANET (Mobile Ad-Hoc Network) überschreiten regelmäßig 500 ms. Paketverlust über 20 % ist unter Störung normal. Verbindungen flackern, wenn sich Plattformen hinter Gelände bewegen. Ein Satcom-Backhaul wird im Morgendrang und wieder beim letzten Licht überlastet.

Der Operator toleriert keine veralteten Daten. Ein fusionierter Track, der zwei Minuten alt ist, ist schlimmer als kein Track — er präsentiert eine selbstbewusste Lüge darüber, wo eine Bedrohung ist. Der Bus muss daher Message-Expiry erzwingen, frische Zustände gegenüber Rückständen priorisieren und elegant degradieren, wenn die Verbindung nach einer Partition zurückkehrt, statt zehn Minuten gewarteter Telemetrie auf einmal abzuladen.

Ordnung zählt auch, aber nicht einheitlich. Telemetrie kann zusammengefasst werden (nur die letzte Position zählt). Befehle können das nicht — ein bei T+5 erteiltes „Waffenfreigabe halten" darf nicht von einem bei T+3 erteilten „Waffen frei", das verspätet ankommt, überholt werden. Der Bus braucht unterschiedliche Liefersemantiken pro Topic, nicht eine globale Garantie.

Schließlich muss der Bus Partitionen überleben. Wenn die Funkverbindung nach einem fünfminütigen Ausfall zurückkehrt, sind drei Verhaltensweisen falsch: alle gewarteten Nachrichten auf einmal abzuladen (überlastet den Consumer), alles still zu verwerfen (verliert geordnete Befehle) und während des Catch-ups neu zu ordnen (liefert veraltete Waffen-frei nach frischem Waffenfreigabe-Halt). Das korrekte Verhalten ist pro Topic: Coalesce-on-Recovery für Telemetrie, geordnete Drain mit Zeitstempeln für Befehle, vollständiges Replay für Audit-Logs. Kein einziger Liefermodus erfüllt alle drei.

2. NATS und JetStream

NATS ist ein kleiner, opinionierter Pub-Sub-Bus, geschrieben in Go. Ein einzelnes Binary, keine externen Abhängigkeiten, standardmäßig In-Memory-Subjects und Submillisekunden-Publish-to-Deliver-Latenz im LAN. Der Footprint liegt in zweistelligen Megabytes — klein genug für einen Fahrzeug-Compute-Block oder einen ruggedisierten Edge-Knoten.

Core-NATS ist Fire-and-Forget. JetStream ist die 2020 hinzugefügte Persistenzschicht: dauerhafte Streams, Replay nach Sequenz oder Zeit, Consumer-Cursor, Message-Expiry und pro-Subject-Deduplikationsfenster. JetStream verwendet Raft für Replikation. Ein 3-Knoten-JetStream-Cluster ist das standardmäßige taktische Kern-Deployment — das Quorum überlebt einen Knotenausfall, und die Streams replizieren ohne separaten Zookeeper-artigen Koordinator.

NATS gewinnt, wenn der dominante Verkehr klein, häufig und niedrig-latent zwischen Diensten ist — Befehle, fusionierte Track-Updates, Microservice-RPC über Request-Reply-Subjects. Es ist der Standardbus für Dienst-zu-Dienst-Verkehr innerhalb einer Fusion-Engine.

Wo es bricht: JetStreams Replikation ist exzellent innerhalb eines Clusters, aber sie ist nicht für eine degradierte WAN ausgelegt. Leaf Nodes können eine NATS-Topologie nach außen zu Edge-Geräten erweitern, aber wenn der Leaf für Stunden offline ist, ist das Catch-up-Fenster durch die Retention des Streams begrenzt — nicht durch die Erwartungen des Leafs. Behandelt NATS als Kernbus, nicht als Weitverkehrsbus.

Der Fehlertoleranz-Trade-off, der benannt werden sollte: JetStream-Raft-Quorum erfordert, dass eine Mehrheit der Replikas einen Schreibvorgang bestätigt. In einem 3-Knoten-Cluster bedeutet das zwei Acks. Wenn ein Knoten zur Wartung ausfällt und ein zweiter seine Festplatte verliert, stocken Schreibvorgänge — der Cluster wahrt Konsistenz auf Kosten der Verfügbarkeit. Für einen taktischen Kern ist das die richtige Wahl; die Konsistenz des Lagebilds ist nicht verhandelbar. Aber das Operator-Muster zählt: keine JetStream-Drei-Knoten-Cluster betreiben, in denen zwei Knoten einen einzelnen Ausfallpunkt teilen wie einen Switch oder einen Stromzweig.

3. Apache Kafka

Kafka ist der Durabilitäts-Champion. Ein Append-only-Log pro Partition, Replikationsfaktor pro Topic konfigurierbar, Retention in Tagen oder Wochen gemessen und ein Consumer-Modell, das neuen Clients erlaubt, die Historie von Offset null wiederzugeben. Für After-Action-Review, Audit-Logging und Analytik über historische operative Daten ist Kafka fast immer die richtige Antwort.

Es ist auch teuer. Ein produktives Kafka-Cluster will mindestens drei Broker, schnelle lokale Festplatten, Gigabytes Page-Cache und entweder Zookeeper (Legacy) oder KRaft (aktuell, seit Kafka 3.3 GA Ende 2022, Standard ab 3.5+). Partition-Rebalancing unter Netzwerkpartition ist ein bekanntes operatives Risiko. Consumer-Group-Koordination setzt eine stabile Verbindung zum Group-Coordinator-Broker voraus.

Das „Kafka-für-alles"-Muster, das in Cloud-Native-Shops funktioniert, scheitert am taktischen Rand aus drei Gründen. Erstens ist der Ressourcen-Footprint falsch — ein JVM-basierter Broker auf einer lüfterlosen Edge-Box verliert jedes Mal gegen ein NATS-Binary. Zweitens bestraft Kafkas Strong-Durability-Standard auf einer verlustreichen Verbindung: Producer stocken im Warten auf Acks. Drittens ist die operative Komplexität (Broker-Config, Topic-Partitioning-Strategie, Retention-Tuning, ISR-Monitoring) nicht zu rechtfertigen, wenn die Box unbeaufsichtigt vorn steht.

Kafka gehört auf die strategische Ebene — den rückwärtigen Cluster, der aggregierte Event-Streams von vorn-eingesetzten Gateways aufnimmt und sie an Analytik, Trainingsdaten-Pipelines und Langzeit-Archive serviert.

4. MQTT

MQTT wurde 1999 für Ölpipeline-Telemetrie über Satellitenverbindungen entworfen — genau das Netzwerkprofil, das ein taktisches Sensornetzwerk heute präsentiert. Winziger Header-Overhead (2-Byte-Fixed-Header im Minimum), drei Quality-of-Service-Stufen (0 Fire-and-Forget, 1 At-Least-Once, 2 Exactly-Once) und eine Topic-Hierarchie, die natürlich auf Sensor → Einheit → Echelon-Strukturen abbildet.

MQTT 5.0, finalisiert 2019, fügte die Features hinzu, die es operativ ernsthaft für die Verteidigung machen. Shared Subscriptions ($share/group/topic) verteilen ein Topic über eine Consumer-Gruppe — nützlich für Fan-out-Verarbeitung von Sensordaten. Message-Expiry-Intervalle verwerfen veraltete taktische Daten automatisch am Broker. User Properties tragen Klassifizierungslabels und Freigabe-Markierungen als Nachrichten-Metadaten. Topic-Aliases komprimieren wiederholte lange Topic-Strings auf ein einzelnes Byte nach dem ersten Publish — ein echter Gewinn auf einem 9600-bps-Funkgerät.

Die Broker-Seite ist reif: Mosquitto für kleine Footprints, EMQX oder HiveMQ für größere geclusterte Deployments mit Shared Subscriptions und Bridging. Alle drei laufen auf Edge-Klasse-Hardware. MQTT-SN (Sensor Networks) erweitert das Protokoll über Nicht-TCP-Transports für die wirklich kleinen — batteriebetriebene Sensoren ohne IP-Stack.

MQTTs Schwäche ist Durabilität. Persistente Sessions und QoS 2 geben zuverlässige Zustellung an einen bekannten Client, aber MQTT ist kein Event-Log — es gibt keine Replay-by-Offset-Semantik. Wenn ein Consumer über sein Session-Expiry hinaus die Verbindung verliert, sind die Nachrichten weg. Für Sensortelemetrie ist das akzeptabel. Für einen Audit-Trail nicht.

5. RabbitMQ und AMQP

RabbitMQ ist älter als die Cloud-Native-Messaging-Welle und verdient sich noch seinen Platz. Das AMQP-0-9-1-Modell — Exchanges, Bindings, Queues — bietet Routing-Flexibilität, die Pub-Sub-Busse nicht erreichen können. Topic Exchanges mit Wildcard-Bindings, Header Exchanges für inhaltsbasiertes Routing, Dead-Letter-Queues für fehlgeschlagene Nachrichten, Pro-Queue-TTLs und Pro-Message-Acknowledgement mit Redelivery-Counts.

Für Workflows, in denen eine Nachricht genau einmal von genau einem Worker verarbeitet werden muss, mit expliziter Ack- und Retry-Semantik, ist RabbitMQ immer noch die sauberste Antwort. Beispiele in einem C2-Stack: Auftrags-Workflows, bei denen jeder Auftrag an einen Operator geht, Geocoding-Anfragen, die einen externen Dienst treffen, OCR-Jobs gegen erfasste Bilddaten. Das sind Queue-Probleme, keine Stream-Probleme, und Queue-Semantik ist, was RabbitMQ kann.

Observability ist die andere stille Stärke — die Management-UI, der Prometheus-Exporter und Pro-Queue-Metriken machen es zum am einfachsten zu betreibenden der vier um 03:00, wenn etwas schiefläuft. Für ein kleines Ops-Team, das eine unbeaufsichtigte taktische Cloud betreibt, zählt das.

RabbitMQs Grenzen zeigen sich bei sehr hohem Durchsatz (es ist kein Millionen-Nachrichten-pro-Sekunde-Bus) und auf unzuverlässigen Netzwerken (das verbindungsorientierte AMQP-Modell mag Link-Flaps nicht). Verwendet es für die Workflow-Schicht, nicht für den Telemetrie-Feuerstrahl.

6. Bridging von Bussen

Produktive C2-Systeme betreiben gleichzeitig zwei oder drei Busse. Ein repräsentatives Deployment: MQTT am Rand für Sensor- und Funkverkehr, NATS im taktischen Kern für Dienst-zu-Dienst-Befehle und fusionierte Tracks, Kafka auf strategischer Ebene für dauerhaftes Event-Archiv. RabbitMQ kann neben NATS für die Workflow-Schicht erscheinen.

Die Bridges sind Erstklassen-Komponenten, keine nachträglichen Einfälle. Ein MQTT-zu-NATS-Gateway abonniert ausgewählte MQTT-Topics, transformiert die Nutzlast in das kanonische interne Schema und veröffentlicht auf einem NATS-Subject neu. Eine NATS-zu-Kafka-Brücke konsumiert JetStream-Streams und produziert auf Kafka-Topics mit derselben Partition-Key-Strategie. Schema-Übersetzung, Backpressure-Handhabung und idempotenter Re-Publish bei Bridge-Neustart sind die harten Teile — nicht die Verbindung selbst.

Baut die Bridges mit derselben Engineering-Disziplin wie jeden anderen Dienst: Health Checks, Metriken, eine definierte Replay-Prozedur beim Neustart und klare Ownership. Der klassische Fehlermodus ist eine Bridge, die unter Last still Nachrichten verliert, weil ihre interne Queue überlief.

7. Sicherheit und Klassifizierung

Jeder Bus spricht TLS. Jeder Bus unterstützt Mutual TLS mit Client-Zertifikaten. Das ist notwendig, nicht hinreichend.

Pro-Enklave-Isolation ist die nächste Schicht: eine separate Broker-Instanz mit einer separaten Zertifizierungsstelle für jede Klassifizierungsstufe. Der Bus innerhalb der GEHEIM-Enklave spricht niemals direkt mit dem Bus innerhalb der NICHT-KLASSIFIZIERT-Enklave. Cross-Domain-Freigabe geht durch einen genehmigten Guard oder eine Cross-Domain-Solution, die strippt, transformiert und neu veröffentlicht — niemals durch eine Broker-Brücke.

Pro-Topic-ACLs sind die dritte Schicht. Auf NATS: Accounts und Subject-Permissions. Auf MQTT: Broker-ACL-Dateien oder ein Plugin. Auf Kafka: ACLs über die AdminClient-API. Auf RabbitMQ: User-Vhost-Resource-Permissions. Default-Deny ist die einzige akzeptable Haltung: Ein Dienst kann auf genau den Topics publizieren und abonnieren, die seine Rolle verlangt, und auf keinen anderen.

Nachrichten-Metadaten tragen Klassifizierungslabels — MQTT-5-User-Properties, NATS-Header, Kafka-Header. Der Broker setzt Klassifizierungssemantik nicht durch; die konsumierenden Dienste und der Cross-Domain-Guard tun das. Der Broker setzt durch, wer welches Topic lesen kann.

8. Entscheidungs-Framework

Jede Verkehrsklasse gegen vier Achsen bewerten:

Latenzbudget. Submillisekunden-Dienst-zu-Dienst-RPC: NATS. Zehntel Millisekunden für Sensortelemetrie: MQTT. Sekunden für Archiv-Ingest: Kafka. Pro-Nachricht-Workflow-Schritte mit Ack-Semantik: RabbitMQ.

Durchsatz. Bis ~10k Nachrichten/Sek. pro Topic auf bescheidener Hardware: jeder der vier. 100k+ dauerhaft pro Topic: NATS oder Kafka. Millionen über viele Topics: Kafka. Sensor-Fan-In von Tausenden niedrigratigen Clients: MQTT mit Shared Subscriptions.

Durabilität. Kein Replay erforderlich: Core-NATS oder MQTT QoS 0/1. Replay innerhalb einer Session oder eines kurzen Fensters: NATS JetStream, MQTT-persistente Sessions. Mehrtägiges audit-grad Replay: Kafka. Pro-Message-Ack mit Retry und Dead-Letter: RabbitMQ.

Edge-Netzwerk-Realität. 9600 bps Funk mit 30 % Verlust: MQTT mit Topic-Aliases und QoS 1. Taktisches LAN im Fahrzeug: NATS. Strategisches WAN zu einem Rück-Cluster: Kafka mit Gateway davor. Intermittierendes Satcom: MQTT für Telemetrie, asynchroner Kafka-Producer mit lokalem Spool für Archiv.

Baut die Matrix für euer spezifisches System. Jede Verkehrsklasse mappt auf einen Bus. Die Bridges zwischen ihnen sind explizit. Das Deployment betreibt die Busse, die es braucht, und keine weiteren — einen Bus hinzuzufügen hat operative Kosten, und diese Kosten werden in jeder Schicht gezahlt, nicht nur zur Integrationszeit.