Mitkä ovat MQTT:n edut verrattuna perinteiseen HTTP-protokollaan

HTTP on yleisimmin käytetty ja suosituin protokolla. Mutta MQTT on noussut nopeasti viime vuosina. IoT-kehityksestä keskusteltaessa kehittäjien on valittava näiden kahden välillä.

MQTT keskittyy dataan, kun taas HTTP keskittyy asiakirjoihin. HTTP on asiakas-palvelin-laskennan pyyntö-vastausprotokolla, jota ei aina ole optimoitu mobiililaitteille. Näillä termeillä MQTT:n tärkeimmät edut ovat: kevyt (MQTT siirtää dataa tavutaulukoiden muodossa) ja julkaisu/tilausmalli, mikä tekee MQTT:stä erittäin sopivan laitteille, joilla on rajalliset resurssit ja auttaa säästämään akkua. Lisäksi julkaisu/tilaa -malli mahdollistaa asiakkaiden riippumattomuuden toisistaan, mikä lisää koko järjestelmän luotettavuutta. Asiakasvian sattuessa koko järjestelmä toimii edelleen normaalisti.

MQTT:llä on edelleen monia etuja, kuten:

1. Matala protokolla, MQTT on ainutlaatuinen siinä mielessä, että sen otsikko viestiä kohti voi olla niin lyhyt kuin 2 tavua. Sekä MQ:lla että HTTP:llä on paljon korkeammat viestikohtaiset lisäkustannukset. HTTP-yhteyden muodostaminen uudelleen jokaista uutta pyyntöviestiä varten aiheuttaa huomattavia ylimääräisiä kustannuksia. MQ:n ja MQTT:n käyttämät jatkuvat yhteydet vähentävät tätä ylimääräistä merkittävästi.

2. Epävakaiden verkkojen sietokyky, MQTT ja MQ voivat toipua vioista, kuten yhteyden katkeamisesta, eikä muita koodivaatimuksia ole. HTTP ei kuitenkaan voi tehdä tätä natiivisti, joten asiakkaiden on yritettävä koodausta uudelleen, mikä voi lisätä idempotenssiongelmia.

3. Alhainen virrankulutus, MQTT on erityisesti suunniteltu alhaiseen virrankulutukseen. HTTP:tä ei suunniteltu ottamaan tätä huomioon, mikä lisää virrankulutusta.

4. Asiakkaat, joilla on miljoonia yhteyksiä HTTP-pinossa, miljoonien samanaikaisten yhteyksien ylläpitäminen vaatii paljon työtä tuen tarjoamiseksi. Vaikka tämä tuki on mahdollista, useimmat kaupalliset tuotteet on optimoitu käsittelemään tämän suuruusluokan pysyviä yhteyksiä. IBM tarjoaa IBM MessageSightin, yhden telineeseen asennettavan palvelimen, joka on testattu käsittelemään jopa miljoonaa samanaikaisesti kytkettyä laitetta MQTT:n kautta. Sitä vastoin MQTT:tä ei ole suunniteltu suurelle määrälle samanaikaisia asiakkaita.

5. Push-ilmoitukset, sinun on pystyttävä toimittamaan ilmoitukset asiakkaille oikea-aikaisesti. Tätä varten on käytettävä jonkinlaista säännöllistä kyselyä tai push-toimintoa; push on paras ratkaisu akun, järjestelmän kuormituksen ja kaistanleveyden näkökulmasta.

Yrityksemme saattaa joutua lähettämään arkaluontoisia tietoja ilman kolmannen osapuolen välitystä. Tämä vähentää käyttöjärjestelmäkohtaisten ratkaisujen (kuten Apple iOS, Google Play -ilmoitusten) arvoa ensisijaisena siirtomekanismina.

HTTP sallii vain yhden COMET-nimisen menetelmän, joka käyttää pysyviä HTTP-pyyntöjä työntöjen suorittamiseen. Tämä lähestymistapa on kallis sekä asiakkaan että palvelimen näkökulmasta. Sekä MQ että MQTT tukevat push-toimintoa niiden perustavanlaatuisena ominaisuutena.

6. Asiakasalustojen erot, sekä HTTP- että MQTT-asiakkaat on toteutettu useilla alustoilla. MQTT:n yksinkertaisuus auttaa toteuttamaan MQTT:n lisäasiakkaille erittäin pienellä vaivalla.

7. Palomuurin vikasietoisuus, jotkin yritysten palomuurit rajoittavat lähtevät yhteydet joihinkin määritettyihin portteihin. Nämä portit rajoittuvat yleensä HTTP:hen (portti 80), HTTPS:ään (portti 443) jne. HTTP voi ilmeisesti toimia näissä tilanteissa. MQTT voidaan kääriä WebSockets-yhteyteen, joka näkyy HTTP-päivityspyynnönä, mikä mahdollistaa toiminnan näissä tapauksissa. MQTT ei salli tätä mallia.

Verrattuna HTTP:hen MQTT-protokolla takaa korkean siirtonopeuden. Palvelun laatutasoa on kolme:

A. Korkeintaan kerran: Yritä varmistaa toimitus.

B. Vähintään kerran: Varmista, että sähköposti lähetetään vähintään kerran, mutta viesti voidaan toimittaa myös useammin kuin kerran.

C. Vain kerran: Varmista, että toinen osapuoli vastaanottaa jokaisen viestin vain kerran.

Itse asiassa MQTT on laajalti käytössä. Löydät MQTT:n melkein mistä tahansa suuresta laitteisto- ja Internet-yrityksestä, kuten Facebookista, BP:stä, alibabasta, baidusta jne.

MQTT:n erilaisten teknisten etujen vuoksi yhä useammat yritykset valitsevat MQTT on IoT-tuoteviestinnän vakioprotokolla. Siksi insinöörit ovat vähitellen havainneet, että MQTT-protokollassa on joitain toimintoja, joita on parannettava, jos sitä halutaan kaupallistaa suuressa mittakaavassa. esimerkiksi:

1. Täydellistä SDK:ta ei ole, ja erilaiset heterogeeniset päätteet tarvitsevat vastaavat ohjelmisto-SDK-paketit kommunikoidakseen MQTT-palvelimen kanssa. Esimerkiksi MCU:n, Linuxin, Androidin, IOS:n, WEB:n jne. välisen yhteenliittämisen saavuttamiseksi tarvitaan erilaisia SDK-paketteja.

2. Tiedostoa ja AV:ta ei tueta. Joissakin sovellusskenaarioissa lähetettävät tiedot eivät välttämättä rajoitu ohjeisiin, kuten ääni- ja videosignaaleihin, joiden on kommunikoitava tiedoston ja AV:n kautta.

3. Se ei tue integraatiota kolmannen osapuolen HTTP:n kanssa. Vaikkah MQTT-protokolla on parempi kuin tavallinen HTTP-protokolla, perinteiseen HTTP-protokollaan perustuvat WEB-palvelimet ovat edelleen valtavirran markkinoilla, joten näiden palvelimien on ymmärrettävä yhteenliittäminen MQTT-protokollan kanssa päivitysten vähentämiseksi Kustannukset ovat myös kriittisiä.
< br/>4. Se ei tue kuormituksen tasapainotusta. Korkean samanaikaisuuden ja haitallisten hyökkäysten estämiseksi tarvitaan myös kuormitusta tasapainottava palvelin.

5. Se ei tue käyttäjien hallintaliittymää. Käyttäjille on erityisen tärkeää analysoida laitteiden käyttäytymistietoja, mikä on Teollisuus 4.0:n ja big datan aikakauden väistämätön vaatimus.

6. Se ei tue offline-viestejä ja korvaa sen ongelman, että MQTT-palvelin menettää laitteen ohjaustiedot, kun laite on offline-tilassa.

7. Point-to-point-viestintää ei tueta, ja käytössä on standardi MQTT-protokolla. Teoriassa point-to-point-viestintä voidaan toteuttaa keskinäisen tilauksen kautta, mutta logiikka on suhteellisen monimutkainen ja laitteen turvallisuudesta ollaan huolissaan. Kun laite B ja laite C ovat samasta aiheesta, laite A ei voi tietää, onko viestin lähettäjä laite B vai laite C, ja on myös mahdollista, että laite D salakuunteli viestin.

8. Se ei tue ryhmäviestintää ja ryhmänhallintaa ja toteuttaa ryhmän jäsenten hallinnan ja ryhmän jäsenet voivat kommunikoida keskenään. Erityisen hyödyllistä tilanteessa, jossa yhtä laitetta ohjaavat useat ihmiset tai useita laitteita ohjaa yksi henkilö.