Тактична система командування і контролю — це розподілений застосунок, що працює через радіо, машини, спішених операторів та сервери в тилу. Шина повідомлень — це хребет. Виберіть неправильну — і система здасться швидкою в лабораторії та помре на каналі під протидією. Виберіть правильну — і оператор побачить злиту картину, що оновлюється всередині його циклу прийняття рішень.

Ця стаття проходить чотирьох кандидатів, які реально з'являються у виробничих C2-збірках — NATS, Apache Kafka, MQTT та RabbitMQ — і викладає фреймворк рішення для вибору між ними. Коротка версія: єдиної відповіді немає. Реальні системи запускають дві або три, з'єднані мостами.

1. Проблема тактичних повідомлень

Тактичні мережі — не мережі дата-центрів. Пропускна здатність на типовому VHF бойовому радіо вимірюється в кілобітах за секунду, не в мегабітах. Round-trip time через MANET (мобільна ad-hoc мережа) регулярно перетинає 500 мс. Втрати пакетів понад 20% — нормальні під радіоелектронною протидією. Канали мерехтять, коли платформи рухаються за рельєфом. Супутниковий бекхол перевантажений на ранкову роботу і знову на сутінкову.

Оператор не толерує застарілих даних. Злитий трек, якому дві хвилини — гірший, ніж відсутність треку: він представляє впевнену брехню про те, де загроза. Шина має забезпечувати закінчення повідомлень, пріоритезувати свіжий стан над беклогом і витончено деградувати, коли канал повертається після розколу, замість того щоб скидати десять хвилин накопиченої телеметрії одразу.

Порядок теж має значення, але не однорідно. Телеметрію можна об'єднати (важить лише остання позиція). Команди — ні: "weapons hold", виданий у T+5, не повинен бути обігнаний "weapons free", виданим у T+3, що прийшов із запізненням. Шина потребує різної семантики доставки на топік, не однієї глобальної гарантії.

Нарешті, шина має пережити розкол. Коли радіоканал повертається після п'ятихвилинного падіння, три типи поведінки неправильні: скидання кожного черги повідомлення одразу (придушує споживача), мовчазне відкидання всього (втрачає впорядковані команди) та перевпорядкування під час догону (доставляє застаріле weapons-free після свіжого weapons-hold). Правильна поведінка — на топік: coalesce-on-recovery для телеметрії, впорядкований дренаж з часовими мітками для команд, повний повтор для аудит-журналів. Жоден режим доставки не задовольняє всіх трьох.

2. NATS і JetStream

NATS — мала, опінійовна pub-sub шина, написана на Go. Один бінарник, без зовнішніх залежностей, за замовчуванням in-memory subjects, sub-millisecond латентність публікації-до-доставки на LAN. Слід — десятки мегабайт — досить мало для машинного обчислювального блоку або ругдизованого крайового вузла.

Core NATS — fire-and-forget. JetStream — шар персистентності, доданий у 2020: довговічні потоки, повтор за послідовністю або часом, споживчі курсори, закінчення повідомлень та per-subject дедуплікаційні вікна. JetStream використовує Raft для реплікації. Кластер JetStream з 3 вузлів — стандартне розгортання тактичного ядра: кворум переживає втрату одного вузла, і потоки реплікуються без окремого Zookeeper-стилю координатора.

NATS виграє, коли домінуючий трафік — це малі, часті, низьколатентні повідомлення між сервісами — команди, оновлення злитих треків, мікросервісне RPC через request-reply subjects. Це шина за замовчуванням для трафіку сервіс-до-сервісу всередині движка злиття.

Де ламається: реплікація JetStream чудова всередині кластера, але не спроєктована охоплювати деградовану WAN. Leaf nodes можуть розширити NATS-топологію назовні до крайових пристроїв, але якщо leaf офлайн годинами, вікно догону обмежене retention потоку, а не очікуваннями leaf. Розглядайте NATS як шину ядра, не як шину широкої зони.

Компроміс відмовостійкості, який варто назвати: JetStream Raft-кворум вимагає більшості реплік для підтвердження запису. У кластері з 3 вузлів це означає два підтвердження. Якщо один вузол вимкнений на обслуговування, а другий втратив диск, записи зависають — кластер зберігає консистентність ціною доступності. Для тактичного ядра це правильний вибір; консистентність операційної картини не обговорюється. Але оператор має розуміти патерн: не запускайте кластери JetStream з трьох вузлів, де два вузли мають спільну точку відмови (один свіч або одне живлення).

3. Apache Kafka

Kafka — чемпіон довговічності. Append-only лог на партицію, replication factor конфігурований на топік, retention вимірюється в днях або тижнях, і споживча модель, що дозволяє новим клієнтам повторювати історію з нульового offset. Для after-action review, аудит-логування та аналітики історичних операційних даних Kafka майже завжди — правильна відповідь.

Вона також дорога. Виробничий кластер Kafka хоче мінімум три брокери, швидкі локальні диски, гігабайти page cache та або Zookeeper (застарілий) або KRaft (поточний, з Kafka 3.3 GA наприкінці 2022, за замовчуванням у 3.5+). Ребалансування партицій під розколом мережі — відома операційна небезпека. Координація consumer group припускає стабільне з'єднання з координатором consumer group брокером.

Патерн "Kafka-для-всього", що працює в cloud-native середовищах, провалюється на тактичному краю з трьох причин. По-перше, ресурсний слід неправильний — JVM-брокер на вентиляторному крайовому ящику програє бінарнику NATS щоразу. По-друге, замовчувана сильна довговічність Kafka карає вас на каналі з високими втратами: продюсери зависають, чекаючи ack. По-третє, операційна складність (конфіг брокера, стратегія партиціонування топіків, тюнінг retention, моніторинг ISR) не виправдана, коли ящик неприйнятий на передовій позиції.

Kafka належить стратегічному рівню — кластер у тилу, що поглинає агреговані потоки подій з передових шлюзів і обслуговує їх аналітиці, пайплайнам навчальних даних та довгостроковим архівам.

4. MQTT

MQTT був спроєктований у 1999 для нафтопровідної телеметрії через супутникові канали — саме той мережевий профіль, який сьогодні представляє тактична сенсорна мережа. Крихітне накладні витрати заголовка (2-байтовий fixed header у мінімальному випадку), три рівні quality-of-service (0 fire-and-forget, 1 at-least-once, 2 exactly-once) та ієрархія топіків, яка природно зіставляється на структури сенсор → підрозділ → ешелон.

MQTT 5.0, фіналізований у 2019, додав функції, що роблять його операційно серйозним для оборони. Shared subscriptions ($share/group/topic) load-balance топіку через consumer group — корисно для fan-out обробки сенсорних даних. Інтервали закінчення повідомлень автоматично відкидають застарілі тактичні дані на брокері. User properties несуть мітки грифу та release markings як метадані повідомлення. Topic aliases стискають повторювані довгі рядки топіків в один байт після першої публікації — реальна перемога на радіо 9600 bps.

Сторона брокера зріла: Mosquitto для малих слідів, EMQX або HiveMQ для більших кластеризованих розгортань з shared subscriptions та bridging. Усі три працюють на крайовому класі обладнання. MQTT-SN (Sensor Networks) розширює протокол через non-TCP transports для справді крихітних — батарейних сенсорів без IP-стеку.

Слабкість MQTT — довговічність. Persistent sessions та QoS 2 дають надійну доставку до відомого клієнта, але MQTT — не лог подій: немає replay-by-offset семантики. Якщо споживач відключений за межами session expiry, повідомлення зникають. Для сенсорної телеметрії це прийнятно. Для аудит-сліду — ні.

5. RabbitMQ і AMQP

RabbitMQ передував cloud-native хвилі обміну повідомленнями і досі заробляє своє місце. Модель AMQP 0-9-1 — exchanges, bindings, queues — дає гнучкість маршрутизації, з якою pub-sub шини не можуть зрівнятися. Topic exchanges з wildcard bindings, header exchanges для content-based routing, dead-letter queues для невдалих повідомлень, per-queue TTL та per-message acknowledgement з лічильниками redelivery.

Для workflow, де повідомлення має бути оброблене рівно один раз рівно одним worker, з явним ack та retry-семантикою, RabbitMQ досі — найчистіша відповідь. Приклади у C2-стеку: tasking workflows, де кожне tasking йде одному оператору, запити геокодування, що б'ють у зовнішній сервіс, OCR-завдання проти захопленої образності. Це проблеми черг, не потоків, а семантика черг — це те, що робить RabbitMQ.

Спостережуваність — інша тиха сильна сторона: management UI, експортер Prometheus та per-queue метрики роблять його найпростішим з чотирьох у експлуатації о 03:00, коли щось не так. Для малої команди операцій, що керує безперервною тактичною хмарою, це важливо.

Обмеження RabbitMQ проявляються при дуже високій пропускній здатності (це не шина мільйона повідомлень за секунду) та на хитких мережах (connection-oriented модель AMQP не любить обриви каналу). Використовуйте її для шару workflow, не для пожежного шланга телеметрії.

6. Мости між шинами

Виробничі C2-системи запускають дві або три шини одночасно. Репрезентативне розгортання: MQTT на краю для сенсорного та радіо-трафіку, NATS у тактичному ядрі для команд сервіс-до-сервісу та злитих треків, Kafka на стратегічному рівні для довговічного архіву подій. RabbitMQ може з'являтися поруч з NATS для шару workflow.

Мости — компоненти першого класу, не запізнілі думки. Шлюз MQTT-до-NATS підписується на вибрані MQTT-топіки, трансформує payload до канонічної внутрішньої схеми та повторно публікує на subject NATS. Міст NATS-до-Kafka споживає JetStream-потоки та продюсує до Kafka-топіків з тією самою стратегією partition key. Трансляція схем, обробка backpressure та ідемпотентна повторна публікація при перезапуску мосту — це складні частини, не саме з'єднання.

Будуйте мости з тою самою інженерною дисципліною, що й будь-який інший сервіс: health checks, метрики, визначена процедура повтору при перезапуску та чітке володіння. Класичний режим провалу — міст, що мовчки скидає повідомлення під навантаженням, бо його внутрішня черга переповнилася.

7. Безпека та класифікація

Кожна шина говорить TLS. Кожна шина підтримує mutual TLS з клієнтськими сертифікатами. Це необхідно, але недостатньо.

Per-enclave ізоляція — наступний шар: окремий екземпляр брокера з окремим certificate authority для кожного рівня грифу. Шина всередині SECRET enclave ніколи не говорить з шиною всередині UNCLASSIFIED enclave безпосередньо. Cross-domain release йде через схвалений guard або cross-domain solution, який стрипає, трансформує та повторно публікує — ніколи через міст-брокер.

Per-topic ACL — третій шар. На NATS — accounts та subject permissions. На MQTT — broker ACL files або плагін. На Kafka — ACL через AdminClient API. На RabbitMQ — user-vhost-resource permissions. Default-deny — єдина прийнятна поза: сервіс може публікувати на та підписуватися з саме тих топіків, яких вимагає його роль, і не з інших.

Метадані повідомлень несуть мітки грифу — MQTT 5 user properties, NATS headers, Kafka headers. Брокер не забезпечує семантику грифу; це роблять споживчі сервіси та cross-domain guard. Брокер забезпечує, хто може читати який топік.

Ключовий висновок: Шина повідомлень є частиною межі безпеки, а не окремо від неї. Розглядайте конфігурацію брокера — ACL, TLS, ізоляцію акаунтів — з тією самою строгістю, що й дизайн offline-first застосунка та відповідність символіці. Неправильно сконфігурований ACL — це викид грифу, що чекає, щоб статися.

8. Фреймворк рішення

Оцініть кожен клас трафіку за чотирма осями:

Бюджет латентності. Sub-millisecond сервіс-до-сервісу RPC: NATS. Десятки мілісекунд для сенсорної телеметрії: MQTT. Секунди для приймання в архів: Kafka. Per-message workflow-кроки з ack-семантикою: RabbitMQ.

Пропускна здатність. До ~10 тис. повідомлень/с на топік на скромному обладнанні: будь-яка з чотирьох. 100k+ на топік: NATS або Kafka. Мільйони через багато топіків: Kafka. Sensor fan-in з тисяч низькошвидкісних клієнтів: MQTT з shared subscriptions.

Довговічність. Повтор не потрібен: core NATS або MQTT QoS 0/1. Повтор у межах сесії або короткого вікна: NATS JetStream, MQTT persistent sessions. Багатоденний аудит-grade повтор: Kafka. Per-message ack з retry та dead-letter: RabbitMQ.

Реальність крайової мережі. 9600 bps радіо з 30% втратами: MQTT, з topic aliases і QoS 1. Тактична LAN всередині машини: NATS. Стратегічна WAN до тилового кластера: Kafka зі шлюзом попереду. Переривчастий satcom: MQTT для телеметрії, асинхронний Kafka producer з локальним спулом для архіву.

Побудуйте матрицю для вашої конкретної системи. Кожен клас трафіку зіставляється з однією шиною. Мости між ними — явні. Розгортання запускає шини, які йому потрібні, і не більше — додавання шини має операційну вартість, і ця вартість сплачується кожну зміну, не лише в момент інтеграції.