Názory k článku Protokol MQTT: komunikační standard pro IoT
-
sid (neregistrovaný)
presne tak, je to jeden z protokolov ktory sa dost casto pouziva, ale tiez by som povedal, ze urcite veci mu chybaju. napr v podstate iba prenasa binarne data takze serializacia/deserializacia neznameho zariadenia nejakym univerzalnym klientom je dost otazna. Mozno by to chcelo niekolko profilov (napr nieco ako nano kde by payload bol tak ako je) a nad tym nejaky profil kde by format dat bol nejako specifikovany. Zase ale nieco menej zlozite a univerzalne ako je napr. OPC UA ktore toto ma sice vyriesene dokonale ale za cenu velkej komplexnosti. Kazdopadne ak nie je problem sirka pasma (co povacsine pri IOT asi je) tak OPCUA je nasobne dokonalejsi standard ako MQTT.
-
MarSik (neregistrovaný)
Takže OPC UA je komplexnější, potřebuje větší šířku pásma, ale jinak je to lepší standard. Jestli ono to nebude tím, že 1) MQTT nebylo vytvořeno právě proto, abychom se obešli bez všech možných vrstev a profilů... 2) MQTT je protokol na úrovní HTTP a aplikační data se řeší až nad ním.
Náročnost implementace těch "dospělých" standardů je taky někde úplně jinde a hodně štěstí při pokusu tu implementaci nacpat do ATtiny.
Trošku mi to OPC mimochodem připomíná dospělé SOAP, CORBA a podobné, které už jsou doufám definitivně na smetišti dějin ve prospěch primitivního REST API (což taky není standard, že ano), STOMPu, nebo třeba JSON-RPC.
-
Jan (neregistrovaný)
Proč „tím pádem”? Všechny 3 tebou uvedené protokoly jsou v hierarchii pod HTTP. A ano, z dnešního pohledu to jsou docela špatné protokoly. Viz např. řešení NAK a řada dalších věcí. Ale beru to tak, že mají své roky. Ale použít HTTP jako spodní vrstvu pro další vrstvy, tak to je fakt totální volovina.
-
robotron (neregistrovaný)
Oba si zrejme vetu "z toho plyne, ze je to spatny protokol" vztahujeme k necemu jinymu. Ja predpokladal, ze Kiwi ji miril na MQTT. Proto reaguju ve smyslu, ze MQTT neni spatny pouze proto, ze je urceny k tomu, aby do nej byly pouzdreny vyssi vrstvy.
Ano, vseobecne pouzivani HTTP jako obalu na ne-HTTP veci vidim osobne taky jako desnou volovinu, ale vzilo se to dost.
-
sid (neregistrovaný)
to ani nespochybnujem, pre zariadenia ktore maju malu ROM/RAM to urcite nie je to prave. Ale pre hocico co je len podpriemerny ARM procesor (odskusane na 200Mhz,16MB RAM, plny OPC UA profil) je to podstatne lepsie. Ked si pozriete standard OPCUA tak zistite ze v oblasti automatizacie riesi naozaj prakticke veci.
Ak vam OPC UA pripomina SOAP a CORBA tak ciastocne davam za pravdu. Akurat ale na to ide podstatne rozumnejsim sposobom, dokonca sa konecne rozhybali aj ohladom specifikacii a SW (co bol dost velky problem, kedze to stalo nemale peniaze)
-
robotron (neregistrovaný)
MQTT jsem zacal pouzivat asi pred pul rokem ve spolupraci s ProtocolBuffers, hlavnim ucelem je rizeni laboratornich experimentu a vubec pristroju. Jsem si vedom, ze jak MQTT, tak ProtoBuf maji nektera omezeni -- MQTT napriklad neumi nic jineho, nez model pub-sub. ProtoBuf zase casto provadi spoustu bitovych presunu (jsou-li pouzity inty promenne delky). Nicmene jsem zatim dost spokojen, delal jsem i zatezove testy, ze jsem pres to posilal v realnem case syrove obrazky z kamer. Nebylo to vyznamne pomalejsi, nez kdyz jsem je posilal pres stdin/stdout trubky.
Vyhovuje mi pomerne siroka podpora jazyku. S MQTT+protobufem zatim ja a par kolegu pouzivame C, C++ (na jedinej ucel, dynamicke parsovani .proto souboru za behu bez rekompilace), Julii, Python. Do Julie jsem si dopsal jednovlaknovou blokujici podporu MQTT, podpora ProtoBuf.jl uz tam byla a fungovala slusne (predevcirem jsem odhalil jednu chybu, ale byla hned opravena).
Pro zajemce o MQTT doporucim aktualni broker mosquitto 1.4.5, mel jsem predtim 1.3.4 a ten se za nekterejch okolnosti divne sekal (zpozdeni okolo 1..2s).
Par tipu:
- pro logovani provozu pouzivam SQLite, jednoduchej subscriber uklada timestamp a binarni MQTT payload; lze pak dokonce indexovat i podle jednotlivejch ProtoBuf poli, staci doplnit o .so modul parsujici ProtoBuf; logovani ale funguje i pro ne-ProtoBuf provoz v ramci MQTT;
- vic mosquitto serveru lze pohodlne sbridgovat, zatim jsem ale neprisel na to, jak to udelat, aby zprava, kterou si klient odhlasi, prestala pres bridge chodit.
-
> zatim jsem ale neprisel na to, jak to udelat, aby zprava, kterou si klient odhlasi, prestala pres bridge chodit.
To nejde, aspoň ne standardním MQTT. Ve standardním MQTT se totiž bridgující broker chová jako standardní klient - tj. pokud má svým klientům umožnit subskripci třeba na A/B, musí si sám A/B subskribovat - tj. chodí na něj všechny zprávy z tohodle topicu i kdyby na něj žádný jeho klient subskribovaný nebyl.
HiveMQ má svůj speciální (čti: nestandardní) bridgeovací protokol, tam to možná jde, nevím, detaily neznám.
-
xxxxx (neregistrovaný)
Nijak. Pokud třeba, tak se nechává až na úrovni dat, která se přeposílají. Často není nutné /typicky lokální síť oddělená od zbytku doslova fyzicky/ tak by zbytečně zabíralo prostor /jak programový - implementace, tak i datový - přenosový/ a tím i spotřebu v koncových zařízeních.
-
M. (neregistrovaný)
No, ne úplně. Je podporováno ověřování (certifikáty nebo jméno/heslo) a můžu na brooker serveru konfigurovat kdo má přístup k jakým topicům pro R/W/RW. Ale je pravda, pokud víc zařízení má zapisovat do stejných topiců nebo se používají rozsáhlejší bridge propojení, tak musí mít write práva a pak musím řešit ověřování na aplikační úrovní v těch jednotlivých zprávách (např flattened JWS, pokud si tím posíláme JSON data).
-
xxxxx (neregistrovaný)
Pokud jsem pochopil, tak certifikáty jsou externí, stojící nad protokolem (mimo, nejsou přímou součástí paketů) - nebo se pletu?. Pak už je (z low-level pohledu) totéž (tedy neřešené), jestli si udělám něco svého (a posílám v datech) či použiji framework (či naprogramuji svůj - uff) a komunikaci do toho zabalím, namísto obyčejného (u klientů často omezeného omezeného) TCP/IP stacku.
A jméno/heslo je v podstatě "plaintext", byť v binární formě. Takže OK pro případ, pokud tím chci ošetřit abych omylem neposlal něco někam, kam nemám - t.j. odchytit programátorské chyby. Ale coby ochrana proti MitM či i jen slabšímu - pouhému odposlechu - a podstrčení falešné zprávy, to není.
-
karel (neregistrovaný)
Heslo v plaintextu nevadí pokud je prenášeno po bezpečném spojení, tedy pokud chcete bezpečnost první co tak komunikovat pře tls což mqtt broukry umí a druhé využít vestavěný ACL a to včetně používání jmen a hesel.
Pokud chcete použít více broukrů tak tam už je to s oprávnění horší, musí se to dobře nakonfigurovat, ovšem každý brouker zvlášť. Jde o to, že broukry se mezi sebou syncronizují taktéž pomocí publish a subscribe, připojený brouker je pro nadřazený brouker jen clientem.
Ještě je rozdíl mezi id clenta a loginem+heslo více různých klientů může používat stejný login a heslo.
-
xxxxx (neregistrovaný)
Ach jo. Nemotat transportní vrstvu a definici protokolu. Pro jistotu jsem znovu projel dokumentaci http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718111 Mimo jiné: "As a transport protocol, MQTT is concerned only with message transmission and it is the implementer’s responsibility to provide appropriate security features" a "A conformant Server MUST support the use of one or more underlying transport protocols that provide an ordered, lossless, stream of bytes from the Client to Server and Server to Client [MQTT-7.1.1-1]. However conformance does not depend on it supporting any specific transport protocols. A Server MAY support any of the transport protocols listed in Section 4.2, or any other transport protocol that meets the requirements of [MQTT-7.1.1-1]"
Takže ještě jednou. MQTT jako takové nedefinuje zabezpečení z pohledu útoků, útočníků. Tedy např. mohu vydat zařízení, o kterém mohu prohlásit, že je MQTT klient či server a žádné zabezpečení (krom toho plaintext login+hesla) mít nemusí.
Odpověď na otázku "Jak je to s bezpečností? Jak je zaručeno, že zprávu X odeslalo zařízení A a ne zařízení A', které se za A vydává?" ... tedy je ... "Není nijak zaručeno", musí se to ohlídat jiným způsobem - např. fyzickým oddělením sítě či na úrovni přeposílaných dat - ať už vlastní kontrolní implementace dovnitř dat paketu nebo zabalení celého protokolu (standardizovaně ssl/tsl/... nebo zase nějaké vlastní /coby extrém/).
-
> Odpověď na otázku "Jak je to s bezpečností? Jak je zaručeno, že zprávu X odeslalo zařízení A a ne zařízení A', které se za A vydává?" ... tedy je ... "Není nijak zaručeno", musí se to ohlídat jiným způsobem
???
Na úrovni brokeru jsou ACL - tj. jde zaručit (a v praxi se to používá), že do určitého topicu můžou zapisovat jenom určití klienti. Např. klient X může zapisovat jenom do topiců client/X/#.
Samotný bezpečný kanál MQTT nijak neřeší, spolíhá na nižší vrstvy. Na tom ale není nic divnýho, třeba HTTP to dělá úplně stejně.
-
MQTT protokol bezpečnost opravdu neřeší (kromě autentizace plain text username/password, která není moc použitelná). MQTT broker zabezpečení řeší autentizací a zajištěním integrity spojení na úrovni TLS (stejně jako např. u HTTPS), autorizace řeší s pomocí ACL (Access Control List), které definují, co který klient smí a nesmí.
BigClown primárně používá uzavření MQTT brokeru a MQTT klientů do jedné bezpečnostní zóny (Linux server), kde do komunikace nevstupuje žádná strana mimo toto prostředí a toto prostředí je spravováno jedním správcem, který důvěřuje SW, který tam pouští.
Komunikace po MQTT v rámci "domácího" systému probíhá tedy jen na loopback síťovém rozhraní. Výhodou jedné bezpečnostní zóny je snadná rozšiřitelnost bez náročného řešení bezpečnostních záležitostí (o těchto detailech si povíme v dalších dílech seriálu).
I tak má uživatel možnost otevřít MQTT směrem ven a použít TLS a ACL MQTT brokeru či bezpečnostní mechanizmy předřazených systémů (např. reverzní HTTPS websocket proxy).
Komunikaci mimo bezpečnostní zónu Linux serveru (včetně bezpečnosti) řeší jednotlivé komponenty samostatně podle potřeb typu komunikace.
-
ehmmmm (neregistrovaný)
No dobre, tak dalsi relativne novy protokol.
Asi to sam tusim, ale bylo by nejake srovnani s vyse zminenym OPCUA, nebo KNX/EIB, LonWorks/LonTalk a podobnymi? Stoji to za to venovat tomu pozornost? Jaka je pravdepodobnost, ze se to bude pouzivat i za 10 let? (Rozumejte, z pohledu konzervy, ktery uz napr. cca 5 let pokukuje po IPv6, ale chape, ze to ma dalsich 5 let jeste cas.)
A co teda ten MQTT vlastne umi? Jenom ten subscribe a publish obecnych dat? Nebo jeste neco?
(Na druhou stranu prave to by mohlo mit sanci na uspech. Kdyz si predstavim, jak dlouho tu jsou a jeste dlouho budou ruzne RS232/RS485 a k nim treba i Modbus prave diky tomu, ze jsou fakt trivialni...)Potom primo v clanku je veta: "V BigClown jsme implementaci MQTT-SN zvažovali, ale protože potřebujeme optimalizovat i payload, pustili jsme se do vlastního protokolu."
Tak k cemu potom takovy standard je, kdyz i autor clanku si radsi vymysli neco jineho?
Asi tomu treba nechat jeste nejaky cas, nez si to sedne. Mame rok 2016, tak treba do roku 2020-2025? -
M. (neregistrovaný)
Myslím, že MQTT používá toršku jiný princip, než 0MQ a nanomsg, který je daný tím, z čeho vzešel.
Každá z těchto dvou skupin protokolů má trošku jiné vhodné použití a my to třeba máme mixováno, že se používají paralelně vedle sebe pro různé druhy přenosů podle toho, zda je pro danou věc vhodný pub/sub nebo req/rep atd princip. Přímí soupeři jsou spíše 0MQ a nanomsg.
Co by mě ale zajímalo, zda už pro 0MQ a nanomsg exisutje nějaká jendoduchá implementace pro možnost komunikvat mezi aplikací běžící jako javascript klient v prohlížeči a něčím běžícím někde jinde na nějakém relativně omezeném HW. Pro MQTT je to hezky řešeno a funkční, kdy dneska MQTT mosquitto brooker umí fungovat přímo jako websocket proxina a i static content HTTP server (i když máme nasazeno stále z histrických důvodů lighttpd a mod_websocked na MQTT) a javascript knohovna šlape celkem OK. Pro nanomsg v této chvíli stále neexistuje javascript knihovna (jen bind pro node.js), pžřstože ten protokol používá i Websocket trasport a pro 0MQ je pár proxin, ale jde většinou o různé Python, Flash atd frameworky. -
Ano, MQTT je přesně takto triviální.
U toho MQTT-SN jsem to napsal trošku nejasně. MQTT-SN je pokus přivést MQTT do bezdrátové non-IP komunikace, který nám moc nevyhovoval, proto jsme zvolili vlastní řešení, které je technicky stále MQTT s přidaným zabezpečením pro "zónu rádio", který se pro "zónu linux server" překládá do MQTT.
-
M. (neregistrovaný)
Zmíněné protokoly OPCUA, nebo KNX/EIB, LonWorks/LonTalk atd vychází z průmyslového prostředí a často jsou pro průmyslové sběrnice.
Kdežto MQTT vyšel z jiné oblasti obecných velkých MQ systémů a byl zjednodušován tak, aby se dal použít aspoň ten pubsub MQ princip i v jednoduchých zařízeních, pokud jsou schopna TCP/IP (a v případě MQTT-SN i bez toho IP).
MQTT tu je už od roku 2000 a ještě nějakou dobu určitě bude, s přehledme do roku 2025 (s ohledme na to, kde jej máme v technologických systémech nasazen a jaké doby provozu/servisu jsou k tomu nasmlouvány). :-) -
Sid (neregistrovaný)
Konkretne opcua nema s priemyselnymi zbernicami nic a publish subscribe model ma vyrieseny povrdal by som este o cosi lepsie ako mqtt. Aj ked zalezi od pohladu samozrejme. Napr zmeny mozu byt posielane iba pri zmene hodnoty o nejaku stanovenu hodnotu (ci uz absolutnu alebo relativnu). Nevyhodu ktoru treba ale spomenut je ze opcua funguje systemom client request server response takze server sam o sebe neposiela nic toto bolo zvolene z ohladom na firewall na strane klienta.
-
M. (neregistrovaný)
Ano, OPC UA není sběrnicový protokol, ale ty další už ano. Musím brát, že OPC standard a MQTT přišly z jiných světů a řeší něco jiného. OPC UA je komplexnější, složitější (těch 11 knih speciikace proti "pár" stranám MQTT), protože se snaží podchytit celý proces předávání technologických dat, včetně řešení datového modelu, kdežto MQTT je v podstatě jen transportní vrstva což je někdy plus a někdy mínus. OPC UA dodnes nemá řada software ze SCADA oblasti implementováno v použitelném stavu. Je to stále "horká novinka", ale díky za něj, proti původnímu OPC nad Windows COM (nepoužitelný vtip s OPC-XMLDA je jen tak pro předávání pěti hodnot po minutě), takže dosti problém na ne-Windows platformách.
Pokud potřebuji komplexnějí datové struktury předávat, které zapadají do modelu OPC, tak je to super, pokud chci jen jednoduše formátované parametry, kde není žádná složitost, tak MQTT je také super na použití, zvláště pokud mám všechny komunikující strany pod kontrolou, a v porovnání s jinými jednoduchými technologickými protokoloy řeší další problémy navíc. Je to zkrátka něco na půli cesty mezi Modbus/TCP a OPC UA, který dokáže zvládat celkem slušné objemy dat.
A nakonec mlůžu použít i nějakou bráno mezo MQTT a OPC (ale viděl jsme jen na staré Win COM OPC a ne na OPC-UA). :-) -
> Na přednáškách říkám posluchačům, že se s MQTT už jistě setkali, a ani nevěděli, že ho
> používají – totiž Facebook Messenger používá právě tento protokol. Dle diskusí soudě
> na Root.cz není Facebook příliš oblíbený, takže se neodvážím dělat nějaké odhady…Me to naopak hodne zajima. Mel jsem za to, ze MQTT je dobre hlavne pro komunikaci zarizeni v lokalni siti.
Jak je to s MQTT pres internet? Jak to resi treba Facebook?
Kazdy kllient se muze zaregistrovat do libovolneho topicu, ale jsou v nich sifrovana data a tak je neprecte?
Nebo broker povoluje klientum prihlaseni jen k urcitym (jejich) topicum?Pokud budeme mit oblibeny priklad - ESP8266 s DS18B20 teplomerem - jak to lepe/bezpecneji posilat pres internet? RESTem, nebo pres MQTT? HTTPS+REST mi stale prijde bezpecnejsi a jasne definujici pravidla bezpecnosti.
-
Ad bezpečné "posílání přes Internet" - TLS + HTTP + REST je na tom stejně jako TLS + MQTT. Ale bez DNSSEC, další PKI obsluhy (např. validace a deployment certifikátů), stavového firewallu, bezpečné synchronizace času, záplatování chyb SW (a dalších komponent) nejde ani HTTP ani MQTT rozumně dělat bezpečně, proto se podle našeho názoru nedá obejít bez "dospělého" klienta, např. v podobě linuxového serveru.
-
V non IOT architekturach se vetsinou neresi pocet TCP spojeni, takze pokud nejake zarizeni neni pripojeno, je to spise error stav, ktery se musi co nejdrive napravit... -> connection musi stale existovat
Naopak v IOT architekturach (ted resim svuj prvni IOT POC projekt) jsem se dostal trochu jinam:
1. Pokud uvazuji imaginarnich napr. 500,000 zarizeni, tak to jako sorry, ale to uz muze byt problem mozna na firewallu, ale hlavne na message brokerech. Nemam zkusenost s moquito, ale Weblogic JMS, ActiveMQ, Rabbit.. a kazdy pripojeni potrebuje pamet
2. Posilam data napr. jednou za den/hodinu, takze proste poslu behem par vterin data a zarizeni prepnu do sleep modu, aby papalo malo elektrinyA ted tu mam mozny problem, nevim, proto se tu ptam na nasledujici scenar:
1. Zarizeni posle data na data pro server
2. Server ma subscribci, dostane data
3. Zarizeni vytvori subskripci na nejaky rekneme reply topic
4. Zarizeni se hodi do sleep modu, tj. vypne komplet wifi -> pripojeni k brokeru je dole
5. Server posle response do topicu
6. Zarizeni se nahodi a pripoji se zpet do brokeruOtazka:
1. Musi zarizeni vytvaret novou subskripci, nebo je predesla subscripce persistentni na brokeru i po docasnem odpojeni a po znovupripojeni dostane zarizeni vsechny zpravy z topicu, ktere server behem trvani vypnuti publikoval? -
Persistent session znamená jenom tohle:
Dejme tomu, že se klient potřebuje subscribovat na topiky A,B,C,D. Jestliže se úspěšně subscribuje, potom ztratí spojení a při následném připojení (pod stejným client id) NEpoužije flag "clean session", bude dál dostávat zprávy z topiků A,B,C,D (tj. nemusí se na ně subscribovat znovu)
...pořád ale platí, že klient má pode MQTT specifikace povinnost držet spojení otevřené (musí reagovat na zprávy, musí posílat PINGREQ).
Výš napsané platí pro protokol MQTT. MQTT-SN je jiný protokol než MQTT a je speciálně určen pro jednoduché sensory. Mj. nevyžaduje udržovat spojení a umožňuje klientům přecházet do spánku (kdy nepřijímají zprávy). Po sémantické stránce je ale s MQTT plně kompatibilní (v praxi to znamená, že naprogramovat MQTT <-> MQTT-SN bridge je relativně jednoduché).
Specifikace protokolu MQTT je tady: http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/MQTT_V3.1_Protocol_Specific.pdf
Specifikace protokolu MQTT-SN je tady: http://mqtt.org/new/wp-content/uploads/2009/06/MQTT-SN_spec_v1.2.pdf
-
Superior answer.
Ja myslel, ze to SN je jen nejaka konfigurace, ale to je uplne jiny protokol, diky za detailni vysvetleni...
No v mem pripade se mi zda stejne lepsi Persistent Session. Jasne, musim udelat skalovatelnou architekturu. Message broker nebude mit problem persistovat data smerem k zarizenim i po nekolik dni vypadku (uvazuju, ze se zarizeni rozbije a nekdo ho musi vymenit). I pokud by tam litaly tisice zprav, tak jsem v pohode.
Podobnym zpusobem jsem nekdy pouzival Kafku broker, ze slouzil jako obrovsky zasobnik dat.
Zaver: Ale stejne se jdu detailneji kouknout na SN, mozna ze zitra to uvidim jinak.. :-)
Pekny vecer, resp. rano.
-
> Message broker nebude mit problem persistovat data smerem k zarizenim i po nekolik dni vypadku (uvazuju, ze se zarizeni rozbije a nekdo ho musi vymenit). I pokud by tam litaly tisice zprav, tak jsem v pohode.
Na to pozor, MQTT specifikace tohle negarantuje. Pokud klient není připojený ve chvíli, kdy zpráva dorazí, tak ji server nemá povinnost doručit později. Některé implementace to dělají*, ale povinné to není. Takže jestli tohle chcete dělat, musíte si dobře vyzkoušet, jak se jednotlivé brokery chovají a riskujete vendor lock in na jednoho brokera, který bude splňovat požadavky.
* http://www.hivemq.com/blog/mqtt-essentials-part-7-persistent-session-queuing-messages
-
Aha, neni guaranteed delivery. Okej, chapu. Takze mozna, ze bude SN stejne lepsi volba pro muj use case, no asi nebude problem udelat implementaci nad obema a zatezove testy no.
Tady jsem nasel message brokery:
https://github.com/mqtt/mqtt.github.io/wiki/public_brokers
https://github.com/mqtt/mqtt.github.io/wiki/serversTak to si projdu, no. Uvazuju, ze bych mozna pouzil jako prvni choice ActiveMQ Artemis, protoze:
- Klient muze pouzit ciste MQTT (ActiveMQ nepodporuje SN protocol) pro submit dat, to je jedno, ze hodinu spi. Jakmile se probudi, pripoji se do sdileneho topicu (muze jich byt nakonec vic podle oblasti napr.) a to proste bude pokryte
- Pro server to device bych pouzil ne topic, ale "durable queue" s tim, ze jedna queue per device a pokud zarizeni spi, tak tam na nej budou cekat vsechny zpravy bezpecne.To by mohlo fungovat, ne?
-
K článku bych jenom doplnit, že tak, jak je v něm popsaný QoS, funguje až od verze 5, která je docela nová a nejsem si jistý, jak je to s podporou u brokerů. Ve verzi 3 žádné "maximální chtěné QoS" není a platí tam prostě "jak jsem přijal, tak odesílám".
Viz
http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html#subscribe
vs
http://docs.oasis-open.org/mqtt/mqtt/v5.0/csprd01/mqtt-v5.0-csprd01.html#_Toc489530191
ČLÁNKY DO MAILU