Jaké jsou výhody MQTT ve srovnání s tradičním HTTP protokolem

HTTP je nejrozšířenější a nejoblíbenější protokol. Ale MQTT se v posledních několika letech rychle prosadilo. Při diskusi o vývoji IoT si vývojáři musí vybrat mezi těmito dvěma.

MQTT se zaměřuje na data, zatímco HTTP se zaměřuje na dokumenty. HTTP je protokol požadavek-odpověď pro výpočetní techniku klient-server, který není vždy optimalizován pro mobilní zařízení. V tomto smyslu jsou hlavními výhodami MQTT: nízká hmotnost (MQTT přenáší data ve formě bajtových polí) a model publikování/předplatného, díky čemuž je MQTT velmi vhodný pro zařízení s omezenými zdroji a pomáhá šetřit baterii. Model publikování/odběru navíc umožňuje klientům být na sobě nezávislými, čímž se zvyšuje spolehlivost celého systému. V případě selhání klienta celý systém nadále normálně funguje.

MQTT má stále mnoho výhod:

1. Nízká protokolová režie, MQTT je unikátní v tom, že jeho hlavička na zprávu může být krátká až 2 bajty. MQ i HTTP mají mnohem vyšší režii na zprávu. S protokolem HTTP představuje opětovné navázání připojení HTTP pro každou novou zprávu požadavku značnou režii. Trvalá připojení používaná MQ a MQTT tuto režii výrazně snižují.

2. Tolerance k nestabilním sítím, MQTT a MQ se mohou zotavit ze selhání, jako je odpojení, a není vyžadován žádný další kód. HTTP to však nedokáže nativně a vyžaduje, aby klienti znovu zkusili kódování, což může přispívat k problémům s idempotenci.

3. Nízká spotřeba energie, MQTT je speciálně navržen pro nízkou spotřebu energie. Protokol HTTP nebyl navržen tak, aby to zohlednil, čímž se zvýšila spotřeba energie.

4. Klienti s miliony připojení na zásobníku HTTP vyžadují mnoho práce při poskytování podpory. I když je tato podpora možná, většina komerčních produktů je optimalizována tak, aby zvládla trvalá připojení tohoto řádu. IBM nabízí IBM MessageSight, jediný rackový server testovaný tak, aby zvládnul až 1 milion současně připojených zařízení přes MQTT. Naproti tomu MQTT není určeno pro velký počet souběžných klientů.

5. Push notifikace, musíte být schopni doručovat upozornění zákazníkům včas. K tomu je třeba použít nějaký druh periodického dotazování nebo push; push je nejlepším řešením z hlediska baterie, zatížení systému a šířky pásma.

Naše podnikání může potřebovat posílat citlivé informace bez prostředníka třetí strany. To snižuje hodnotu řešení specifických pro operační systém (jako je Apple iOS, oznámení Google Play) jako primárního transportního mechanismu.

HTTP umožňuje pouze jednu metodu zvanou COMET, která k provádění push používá trvalé požadavky HTTP. Tento přístup je nákladný z pohledu klienta i serveru. Jak MQ, tak MQTT podporují push jako jejich základní vlastnost.

6. Rozdíly v klientské platformě, klienti HTTP i MQTT byli implementováni na velkém počtu platforem. Jednoduchost MQTT pomáhá implementovat MQTT na dalších klientech s velmi malým úsilím.

7. Odolnost proti chybám brány firewall, některé podnikové brány firewall omezují odchozí připojení na některé definované porty. Tyto porty jsou obvykle omezeny na HTTP (port 80), HTTPS (port 443) atd. HTTP v těchto situacích samozřejmě může fungovat. MQTT lze zabalit do připojení WebSockets, které se objeví jako požadavek na upgrade HTTP, což v těchto případech umožňuje provoz. MQTT tento vzor neumožňuje.

Protokol MQTT ve srovnání s HTTP zaručuje vysokou přenosovou rychlost. Existují tři úrovně kvality služeb:

A. Maximálně jednou: Pokuste se zajistit doručení.

B. Alespoň jednou: Ujistěte se, že e-mail byl odeslán alespoň jednou, ale zpráva může být doručena i vícekrát.

C. Jen jednou: Zajistěte, aby každá zpráva byla druhou stranou přijata pouze jednou.

Ve skutečnosti je MQTT široce používán. MQTT najdete téměř v každé velké hardwarové a internetové společnosti, jako je Facebook, BP, alibaba, baidu atd.

Vzhledem k různým technickým výhodám samotného MQTT má stále více společností tendenci volit MQTT jako standardní protokol pro komunikaci produktů IoT. Proto inženýři postupně zjistili, že protokol MQTT má některé funkce, které je třeba zlepšit, pokud má být komerčně využíván ve velkém měřítku. například:

1. Neexistuje kompletní sada SDK a různé heterogenní terminály potřebují ke komunikaci se serverem MQTT odpovídající softwarové balíčky SDK. Například k dosažení propojení mezi MCU, Linuxem, Androidem, IOS, WEBem atd. musí být vyžadovány různé balíčky SDK.

2. Soubor a AV nejsou podporovány. V některých aplikačních scénářích nemusí být informace, které mají být přenášeny, omezeny na instrukce, jako jsou audio signály a video signály, které potřebují komunikovat prostřednictvím souboru a AV.

3. Nepodporuje integraci s HTTP třetí strany. Ačkolih protokol MQTT je lepší než běžný protokol HTTP, WEB servery založené na tradičním protokolu HTTP stále zaujímají hlavní trh, takže tyto servery musí realizovat propojení s protokolem MQTT, aby se snížily aktualizace. Náklady jsou také kritické.

4. Nepodporuje vyvažování zátěže. Aby se zabránilo vysoké souběžnosti a škodlivým útokům, je také nezbytný server pro vyrovnávání zátěže.

5. Nepodporuje rozhraní pro správu uživatelů. Pro uživatele je obzvláště důležité analyzovat data o chování zařízení, což je nevyhnutelný požadavek Průmyslu 4.0 a éry velkých dat.

6. Nepodporuje offline zprávy a kompenzuje problém, že server MQTT ztratí řídicí informace zařízení poté, co je zařízení offline.

7. Komunikace typu point-to-point není podporována a je převzat standardní protokol MQTT. Teoreticky lze komunikaci z bodu do bodu realizovat prostřednictvím vzájemného předplatného, ale logika je poměrně komplikovaná a existují obavy o bezpečnost zařízení. Když jsou zařízení B a zařízení C na stejné téma, zařízení A nemůže vědět, zda zprávu odeslalo zařízení B nebo zařízení C, a je také možné, že je zpráva odposlouchávána zařízením D.

8. Nepodporuje skupinovou komunikaci a skupinovou správu a realizuje správu členů skupiny a členové skupiny mohou komunikovat mezi sebou. Zvláště užitečné ve scénáři, kdy jedno zařízení ovládá více lidí nebo více zařízení ovládá jedna osoba.