Интеграция MQTT-протокола для IoT-коммуникации в мобильном приложении
MQTT — не просто «лёгкий» протокол для IoT. Это publish/subscribe поверх TCP с гарантиями доставки (QoS 0/1/2), персистентными сессиями и сообщениями «последней воли» (Last Will). Для мобильных приложений, которые управляют устройствами или мониторят сенсоры в реальном времени, MQTT — правильный выбор. Но мобильная специфика (фон, батарея, нестабильная сеть) требует аккуратной настройки.
QoS и его реальная цена
QoS 0 — fire and forget. Сообщение отправлено, подтверждения нет, дубликатов нет. Для отображения телеметрии (температура, GPS) — нормально, потеря одного пакета не критична.
QoS 1 — at least once. Брокер подтверждает получение PUBACK. Клиент хранит сообщение до получения PUBACK и повторяет при необходимости. Дубликаты возможны. Для команд устройству (включить/выключить) — чаще всего достаточно.
QoS 2 — exactly once. Четырёхфазный handshake: PUBLISH → PUBREC → PUBREL → PUBCOMP. Гарантирует ровно одну доставку. Для финансово значимых команд или критических операций. Цена — удвоенный трафик, удвоенная задержка.
На мобиле QoS 2 в фоне — проблема. Четырёхфазный обмен требует стабильного соединения на протяжении нескольких RTT. При потере сети на середине handshake сессия «застревает» до переподключения. На iOS с ограничениями фона — почти гарантированный сбой. Рекомендуем QoS 1 + idempotent команды на стороне устройства.
Клиентские библиотеки и их подводные камни
Android: Eclipse Paho Android Service — де-факто стандарт, но официально не поддерживается с 2021 года. Альтернатива — HiveMQ MQTT Client (com.hivemq:hivemq-mqtt-client), активно поддерживается, работает с Kotlin Coroutines через kotlinx.coroutines. Для MQTT 5 — только HiveMQ.
iOS: CocoaMQTT (Swift) или MQTTNio (SwiftNIO-based). CocoaMQTT проще в настройке, MQTTNio лучше масштабируется для высокочастотных потоков.
Flutter: mqtt_client — популярная библиотека, поддерживает MQTT 3.1.1. MQTT 5 поддержки пока нет. Для WebSocket-транспорта (когда MQTT поверх WSS, а не TCP) — MqttServerClient vs MqttBrowserClient — нужен правильный.
React Native: нет нативного MQTT. Варианты: react_native_mqtt (обёртка над нативными Paho для Android/iOS) или через WebSocket-транспорт с mqtt.js (работает в RN без полифиллов при WSS).
Управление соединением на мобиле
Keep-alive interval (CONNECT пакет, поле keepAlive) — брокер закроет соединение, если не получит PINGREQ в течение keepAlive * 1.5 секунд. Типичные значения для мобиля: 30–60 секунд. Меньше — больше трафика и расхода батареи. Больше — риск не заметить разрыв вовремя.
Last Will Message: при регистрации соединения укажите willTopic и willMessage (например {"status":"offline"}). Если соединение разорвётся аварийно (без DISCONNECT), брокер автоматически опубликует это сообщение. UI других клиентов увидит статус устройства как offline без дополнительной логики.
Persistent Session (cleanSession: false в MQTT 3.x, sessionExpiryInterval > 0 в MQTT 5): брокер хранит очередь QoS 1/2 сообщений для клиента, пока он офлайн. При переподключении клиент получает накопленные сообщения. Критично для IoT-команд, которые должны дойти до устройства даже при временном отключении. Хранить clientId постоянным — обязательное условие для работы персистентной сессии.
TLS и аутентификация
Для продакшена: MQTT over TLS (mqtts://, порт 8883). Взаимная TLS-аутентификация (mTLS) — стандарт для IoT-устройств, но для мобильного клиента обычно достаточно username/password + серверный TLS-сертификат.
На Android: хранить credentials в EncryptedSharedPreferences. На iOS: Keychain. Не хардкодить брокерный URL и credentials в коде — используем remote config или sealed secrets в CI.
Срок интеграции MQTT в существующее мобильное приложение — 1–3 недели в зависимости от сложности топик-схемы и требований к офлайн-режиму.