Vilka är fördelarna med MQTT jämfört med det traditionella HTTP-protokollet

HTTP är det mest använda och populära protokollet. Men MQTT har snabbt vunnit mark under de senaste åren. När man diskuterar IoT-utveckling måste utvecklare välja mellan dessa två.

MQTT fokuserar på data medan HTTP fokuserar på dokument. HTTP är ett begäran-svar-protokoll för klient-serverberäkning, som inte alltid är optimerat för mobila enheter. I dessa termer är de främsta fördelarna med MQTT: lätt (MQTT överför data i form av byte-arrayer) och publicerings-/prenumerationsmodell, vilket gör MQTT mycket lämplig för enheter med begränsade resurser och hjälper till att spara batteri. Dessutom gör publicerings-/prenumerationsmodellen det möjligt för kunder att vara oberoende av varandra, vilket ökar tillförlitligheten i det övergripande systemet. I händelse av ett klientfel fortsätter hela systemet att fungera normalt.

Det finns fortfarande många fördelar med MQTT, enligt följande:

1. Låg protokolloverhead, MQTT är unik genom att dess rubrik per meddelande kan vara så kort som 2 byte. Både MQ och HTTP har en mycket högre omkostnad per meddelande. Med HTTP innebär det betydande omkostnader att återupprätta HTTP-anslutningen för varje nytt begärandemeddelande. De beständiga anslutningarna som används av MQ och MQTT minskar denna omkostnad avsevärt.

2. Tolerans mot instabila nätverk, MQTT och MQ kan återhämta sig från fel som frånkoppling, och det finns inget ytterligare kodkrav. HTTP kan dock inte göra detta inbyggt, vilket kräver att klienterna försöker kodningen igen, vilket kan öka problem med idempotens.

3. Låg strömförbrukning, MQTT är speciellt designad för låg strömförbrukning. HTTP har inte utformats för att ta hänsyn till detta, vilket ökar strömförbrukningen.

4. Klienter med miljontals anslutningar, på HTTP-stacken, och att underhålla miljontals samtidiga anslutningar kräver mycket arbete för att tillhandahålla support. Även om detta stöd är möjligt, är de flesta kommersiella produkter optimerade för att hantera ihållande anslutningar av denna storleksordning. IBM erbjuder IBM MessageSight, en enkel rackmonterad server som testats för att hantera upp till 1 miljon samtidigt anslutna enheter över MQTT. Däremot är MQTT inte designad för ett stort antal samtidiga klienter.

5. Pushnotiser, du måste kunna leverera aviseringar till kunder i rätt tid. För detta måste någon form av periodisk undersökning eller push användas; push är den bästa lösningen ur ett batteri-, systembelastnings- och bandbreddsperspektiv.

Vår verksamhet kan behöva skicka känslig information utan förmedling av en tredje part. Detta minskar värdet av OS-specifika lösningar (som Apple iOS, Google Play-aviseringar) som den primära transportmekanismen.

HTTP tillåter bara en metod som kallas COMET, som använder beständiga HTTP-förfrågningar för att utföra push. Detta tillvägagångssätt är dyrt ur både klient- och serverperspektiv. Både MQ och MQTT stöder push som en grundläggande egenskap hos dem.

6. Klientplattformsskillnader, både HTTP- och MQTT-klienter har implementerats på ett stort antal plattformar. Enkelheten med MQTT hjälper till att implementera MQTT på ytterligare klienter med mycket liten ansträngning.

7. Brandväggs feltolerans, vissa företagsbrandväggar begränsar utgående anslutningar till vissa definierade portar. Dessa portar är vanligtvis begränsade till HTTP (port 80), HTTPS (port 443), etc. HTTP kan uppenbarligen fungera i dessa situationer. MQTT kan lindas in i en WebSockets-anslutning som visas som en HTTP-uppgraderingsbegäran, vilket tillåter drift i dessa fall. MQTT tillåter inte detta mönster.

Jämfört med HTTP garanterar MQTT-protokollet en hög överföringshastighet. Det finns tre nivåer av servicekvalitet:

A. Som mest en gång: Försök att säkerställa leverans.

B. Minst en gång: Se till att e-postmeddelandet skickas minst en gång, men meddelandet kan också levereras mer än en gång.

C. Bara en gång: Se till att varje meddelande bara tas emot en gång av den andra parten.

MQTT används faktiskt flitigt. Du kan hitta MQTT i nästan alla stora hårdvaru- och internetföretag, som Facebook, BP, alibaba, baidu, etc.

På grund av de olika tekniska fördelarna med själva MQTT, tenderar fler och fler företag att välja MQTT som standardprotokoll för IoT-produktkommunikation. Därför har ingenjörer gradvis upptäckt att MQTT-protokollet har några funktioner som behöver förbättras om det ska kommersialiseras i stor skala. till exempel:

1. Det finns ingen komplett SDK, och olika heterogena terminaler behöver motsvarande mjukvaru-SDK-paket för att kommunicera med MQTT-servern. Till exempel, för att uppnå sammankoppling mellan MCU, Linux, Android, IOS, WEB, etc., måste olika SDK-paket krävas.

2. Fil och AV stöds inte. I vissa applikationsscenarier kanske informationen som ska överföras inte är begränsad till instruktioner, såsom ljudsignaler och videosignaler, som behöver kommunicera via fil och AV.

3. Det stöder inte integration med tredjeparts HTTP. Även omh MQTT-protokollet är överlägset det vanliga HTTP-protokollet, WEB-servrar baserade på det traditionella HTTP-protokollet ockuperar fortfarande den vanliga marknaden, så dessa servrar måste realisera sammankopplingen med MQTT-protokollet för att minska uppgraderingar Kostnaden är också kritisk.
< br/>4. Den stöder inte lastbalansering. För att förhindra hög samtidighet och skadliga attacker är en lastbalanserande server också viktig.

5. Det stöder inte användargränssnittet. Det är särskilt viktigt för användare att analysera data om enhetens beteende, vilket är ett oundvikligt krav för Industry 4.0 och big datas era.

6. Den stöder inte offlinemeddelanden och kompenserar för problemet att MQTT-servern förlorar kontrollinformationen för enheten efter att enheten är offline.

7. Punkt-till-punkt-kommunikation stöds inte och standardprotokollet MQTT används. I teorin kan punkt-till-punkt-kommunikation realiseras genom ömsesidigt abonnemang, men logiken är relativt komplicerad och det finns farhågor om enhetens säkerhet. När enhet B och enhet C handlar om samma ämne kan enhet A inte veta om det är enhet B eller enhet C som skickade meddelandet, och det är också möjligt att meddelandet avlyssnas av enhet D.

8. Det stöder inte gruppkommunikation och gruppledning, och realiserar hanteringen av gruppmedlemmar, och gruppmedlemmar kan kommunicera med varandra. I ett scenario där en enhet styrs av flera personer, eller flera enheter styrs av en person, är det särskilt användbart.