Уявіть: сотня датчиків температури на складі, кожен з 10 КБ RAM, надсилає дані на мобільний планшет техніка. HTTP занадто важкий, MQTT потребує брокера. Рішення — CoAP (протокол керування для обмежених пристроїв, описаний у RFC 7252). Ми, як мобільні розробники, часто стикаємося з необхідністю інтеграції такого протоколу. Семантика CoAP та сама: GET, POST, PUT, DELETE, коди відповідей (2.05 Content = 200, 4.04 Not Found = 404). Але працює поверх UDP, займає десятки байт замість сотень, і спроектований для пристроїв з 10 КБ RAM та батарейним живленням. Мобільний додаток, який спілкується з такими пристроями напряму або через CoAP-проксі — нішевий, але зростаючий сценарій: Thread-мережі (Matter), промислові датчики, медичні носимі пристрої.
Як CoAP вирішує проблему надійності на UDP?
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: що обрати для IoT?
CoAP виграє у MQTT за розміром повідомлення (в 2-3 рази менше) та не потребує брокера, але поступається в надійності гарантованої доставки та підтримці складних черг. Для сценаріїв "датчик-додаток" з рідкісними запитами CoAP ефективніший; для постійно працюючих потоків даних з багатьма точками — MQTT.
Клієнтські бібліотеки для мобільних платформ
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 через проксі: коли не потрібно напряму
Якщо пристрої в ізольованій IoT-мережі, а мобільний клієнт має спілкуватися через інтернет — CoAP-to-HTTP проксі (або CoAP-to-MQTT проксі) знімає складність з мобільної сторони. Eclipse Hono, AWS IoT Core з CoAP endpoint, або самостійно розгорнутий Californium-проксі. Мобільний клієнт працює через звичайний HTTPS/WebSocket, проксі транслює в CoAP. Втрачаємо прямий Observe (потрібна його емуляція через SSE або WebSocket на рівні проксі), отримуємо простоту клієнтського коду та надійність TCP.
Деталі реалізації DTLS handshake
При використанні PSK handshake складається з 4 кроків: ClientHello, ServerHello (з PSK identity), ChangeCipherSpec, Finished. На constrained-пристроях це може займати до 2 секунд. Рекомендується кешувати сесію DTLS (session ID або session ticket) для повторних підключень.Що входить у роботу
- Розробка протоколу обміну (ресурсна модель, формати payload).
- Реалізація Observe на мобільній стороні з обробкою зміни мережі.
- Налаштування DTLS (PSK або сертифікати) та інтеграція з Keychain/EncryptedSharedPreferences.
- Тестування на реальних пристроях та емуляторах мережі.
- Документація з інтеграції (схеми, приклади запитів).
- Консультації щодо вибору інфраструктури (проксі/без проксі).
Ми — команда мобільних розробників з 7+ роками досвіду та 12+ проектами в IoT. Якщо у вас схожа задача — зв'яжіться, ми оцінимо складність і запропонуємо архітектуру під ваш сценарій.
Оцінка та терміни
CoAP-інтеграція — нестандартна задача. Термін залежить від сценарію: якщо через проксі — 2–3 тижні. Пряма CoAP з DTLS на нативних платформах — 4–8 тижнів з урахуванням налаштування Californium/libcoap, DTLS-handshake та Observe. Обов'язково уточнюємо профіль безпеки пристроїв та наявність готової мережевої інфраструктури перед оцінкою.