Интеграция CoAP-протокола для IoT-устройств в мобильном приложении
CoAP (Constrained Application Protocol, RFC 7252) — это HTTP для микроконтроллеров. Семантика та же: GET, POST, PUT, DELETE, коды ответов из HTTP-пространства (2.05 Content = 200, 4.04 Not Found = 404), URL-ресурсы. Но работает поверх UDP, а не TCP, занимает десятки байт вместо сотен, и разработан для устройств с 10 КБ RAM и CR2032 питанием.
Мобильное приложение, которое общается с такими устройствами напрямую или через CoAP-прокси, — нишевый, но растущий сценарий. Thread-сети (умный дом по Matter-стандарту), промышленные датчики, медицинские носимые устройства — там CoAP.
UDP и потери пакетов: как CoAP решает надёжность
CoAP определяет два типа сообщений:
-
CON (Confirmable) — отправитель ждёт
ACK. При отсутствии — exponential backoff и повтор (по умолчанию: 2 попытки, интервал 2–32 секунды). Аналог TCP-гарантий. - NON (Non-confirmable) — fire and forget. Для телеметрии с высокой частотой обновления.
Каждое CON-сообщение несёт Message ID (2 байта) для дедупликации — получатель кешит последние обработанные ID и игнорирует повторы. Срок хранения в кеше — EXCHANGE_LIFETIME (247 секунд по RFC). При работе через NAT mobile → IoT-сеть нужно учитывать, что NAT binding тоже истекает (~30 секунд для UDP через многие carrier NAT).
Observe: подписка на ресурс без поллинга
RFC 7641 добавляет Observe option — аналог WebSocket subscription для CoAP. Клиент отправляет GET /sensor/temperature с Observe: 0 (subscribe). Сервер отправляет текущее значение и потом уведомления при каждом изменении. Observe: 1 — отписка.
Это ключевая фича для мобильного IoT-клиента: вместо поллинга каждые 5 секунд — один запрос, серверные push'и. Ограничение: по RFC сервер ведёт список наблюдателей. При смене IP клиента (мобильный интернет, Wi-Fi → 4G) сервер не знает о смене — нужно повторно регистрировать Observe с нового адреса.
На практике: при каждом смене сети (определяем через ConnectivityManager.NetworkCallback на Android, NWPathMonitor на iOS) — переотправляем все активные Observe-запросы.
DTLS: безопасность поверх UDP
CoAP без шифрования — небезопасен для продакшена. DTLS (Datagram TLS, RFC 6347) — TLS-аналог для UDP. Handshake тяжелее, чем TCP TLS (4–6 RTT против 1–2 для TLS 1.3), что критично для устройств с медленными процессорами.
Профили безопасности CoAP:
- NoSec — без шифрования. Только для изолированных сетей.
- PreSharedKey (PSK) — симметричный ключ, прошит в устройство на фабрике. Самый распространённый в промышленных сценариях.
- RawPublicKey — без PKI-инфраструктуры, но с публичными ключами.
- Certificate — полноценная PKI. Редко на constrained-устройствах.
Для мобильного клиента, подключающегося к PSK-устройствам: нужно хранить PSK-ключи безопасно (Keychain / EncryptedSharedPreferences) и реализовывать DTLS-handshake через библиотеку с PSK-поддержкой.
Клиентские библиотеки для мобиля
CoAP-библиотек для мобиля существенно меньше, чем MQTT. Реальные варианты:
| Платформа | Библиотека | DTLS | Observe |
|---|---|---|---|
| Android | Californium (Eclipse) | + (via Scandium) | + |
| iOS | libcoap (C, через FFI) | + | + |
| Flutter | coap (pub.dev) | частично | + |
| React Native | нет готового | — | — |
Для React Native единственный рабочий путь — нативный модуль (Californium на Android, libcoap на iOS через Objective-C bridge) или CoAP-to-HTTP прокси на бэкенде.
Californium (org.eclipse.californium:californium-core) — наиболее зрелая реализация. Observe через CoapClient.observe() с CoapHandler. DTLS через отдельный scandium артефакт. Пример инициализации PSK-соединения:
DtlsConnectorConfig config = new DtlsConnectorConfig.Builder()
.setPskStore(new StaticPskStore("device-id", pskBytes))
.build();
DTLSConnector connector = new DTLSConnector(config);
CoapEndpoint endpoint = new CoapEndpoint.Builder()
.setConnector(connector).build();
CoapClient client = new CoapClient("coaps://192.168.1.100/sensor/temperature");
client.setEndpoint(endpoint);
Для iOS libcoap компилируется через CocoaPods с кастомным podspec или через SPM как binary target (нужна пересборка под arm64/x86_64). Это не 15-минутная задача.
CoAP через CoAP-HTTP прокси
Если устройства в изолированной IoT-сети, а мобильный клиент должен общаться через интернет — CoAP-to-HTTP прокси (или CoAP-to-MQTT прокси) снимает сложность с мобильной стороны. Eclipse Hono, AWS IoT Core с CoAP endpoint, или самостоятельно развёрнутый Californium-прокси.
Мобильный клиент работает через обычный HTTPS/WebSocket, прокси транслирует в CoAP. Теряем прямой Observe (нужна его эмуляция через SSE или WebSocket на уровне прокси), получаем простоту клиентского кода и надёжность TCP.
Оценка и сроки
CoAP-интеграция — нестандартная задача. Срок зависит от сценария: если через прокси — 2–3 недели. Прямая CoAP с DTLS на нативных платформах — 4–8 недель с учётом настройки Californium/libcoap, DTLS-handshake и Observe. Обязательно уточняем профиль безопасности устройств и наличие готовой сетевой инфраструктуры перед оценкой.