Я розробляю прилад, який вимірює температуру, вологість і масу. В даний час він використовує HTTPS для завантаження даних на віддалений сервер. Тепер я знаю, що існує протокол під назвою MQTT, який вважається "протоколом Інтернету речей".
У якому випадку і чому я повинен перейти з HTTPS на MQTT?
Відповіді:
MQTT - це "месенджер" між пристроями:
/domotics/myplace/mydevice/temperatureX(як "корисний вантаж")В іншому місці вашого будинку:
/domotics/+/+/temperatureщоб отримувати ВСІ відомості про температуру з усіх пристроїв, які використовують цей формат теми Див. Специфікацію MQTT для отримання додаткової інформації про підстановку ( +і #) теми теми MQTT .Xі зробить все, що завгодно!В іншому місці вашого будинку:
/domotics/myplace/mydevice/#щоб отримати ВСЮ інформацію з вашого пристрою та записати їїXі зробить все, що завгодно!MQTT дуже корисний, щоб не розміщувати веб-сервіси та розетки по всьому серверу. Node-RED використовує MQTT, а Domoticz можна налаштувати для отримання inта встановлення outсигналів.
Я особисто використовую MQTT вдома, щоб вимкнути комп’ютери: /house/computers/mycomputerpayload:0
Транспортний протокол MQ Telemetry, відомий як MQTT , призначений для пристроїв, що працюють на низькій потужності та низькій пропускній здатності. Це легкий протокол обміну повідомленнями / підписки, що означає, що будь-який інший пристрій може підписатися на певну тему.
HTTP / HTTPS розроблений як протокол відповіді на запит для обчислень клієнт-сервер, які ніколи не турбуються про енергоспоживання та мають багато накладних даних.
Використовуйте MQTT, якщо:
Чи пропонують MQTT стільки ж безпеки, скільки HTTPS?
MQTT покладається на TCP як транспортний протокол, що означає, що за замовчуванням з'єднання не використовує зашифрований зв'язок. Для шифрування всього зв'язку MQTT більшість брокерів MQTT - як HiveMQ - дозволяють використовувати TLS замість простого TCP.
Посилання: HiveMQ
MQTT (телеметрія транспорту черги повідомлень), здається, добре підходить для запропонованої програми.
Він легкий як щодо пропускної здатності (найменший розмір пакета із заголовком всього 2 байти), так і сліду коду клієнта (що дозволяє йому працювати на тонких клієнтах, таких як ESP8266, типовий клієнт IoT). Скорочення переданих даних корисно для більш тривалого терміну служби акумулятора для клієнтів, що живлять без мережі, як датчики.
MQTT також пропонує прості методи ( дієслова ), які добре відповідають завданням IoT, як довговічні підписки, які відновлюють з'єднання після несподіваних відключень клієнта. У порівнянні з HTTP / HTTPS також простіше витягнути дані з пакету (парсер не потрібен).
Тут я написав статтю, яка показує та еволюцію в системі комунікацій, яку ми мали у своєму проекті. Йдеться про мікро-сервіси, але ви можете вважати будь-який датчик мікросервісом зі своїм завданням збирати та публікувати будь-які дані телеметрії.
Тому найважливіший висновок полягає в тому, що краще використовувати MQTT, коли вам просто потрібно кудись надіслати подію, і ви нічого не знаєте про одержувача. І набагато краще використовувати HTTP (зазвичай REST), коли ви знаєте щось про одержувача та потребуєте певної відповіді - наприклад, у випадку будь-яких команд.
З точки зору трафіку, процесора, пам'яті та енергоспоживання MQTT та HTTP в основному однакові.
Що стосується вашої цитати, MQTT - це "протокол Інтернету речей":
Так, існує велика кількість розробників, які використовують цей протокол (див. IoT Developer Survey 2018), але CoAP (це HTTP, налаштований на IoT, заснований на UDP) пропонує альтернативу для HTTP у випадку, якщо ви хочете використовувати легку функцію запиту / відповіді в межах ваша заявка.
MQTT, з іншого боку, забезпечує вбудовану логіку публікації / підписки, що робить її чудовою для масштабування (ви можете використовувати більше шлюзів для більшої кількості пристроїв). Існує також альтернатива UDP (наприклад, CoAP для HTTP), яка називається MQTT-SN (MQTT для сенсорних мереж). Це забезпечує навіть менші накладні витрати, ніж CoAP, але не використовує R / R.