skip to Main Content
MQTT är ett nätverksprotokoll för IoT som står för “MQ Telemetry Transport”, där MQ är en referens till en produktserie från IBM med beteckningen MQ. MQTT utvecklades till en början för ändamålet att hantera meddelanden mellan enheter med strikta begränsningar avseende protokollets resursanvändning, det skulle helt enkelt vara ett lättviktsprotokoll och kom därför senare att anammas av många IoT-lösningar.

Protokollet släpptes först 1999 och var en proprietär lösning för att ansluta telemetrisystem inom oljeindustrin via satellit där oljeledningars telemetrilösningar kopplades upp. Under 2010 släpptes protokollet fritt för användning av alla och 2014 antogs MQTT som en OASIS standard (OASIS, Organization for the Advancement of Structured Information, ett internationellt konsortium för standarder inom strukturerad information).
mqtt hjärta och hjärna inom iot

MQTT där bandbredd är kritisk

Enheter på platser där bandbredden är begränsad drar mycket nytta av MQTT. Sådana tillämpningar hittar man exempelvis där man behöver kommunikation mellan sensorer och mobilnäten. MQTT ger dock fördelar utöver låg bandbreddsanvändning, MQTT har låg strömförbrukning, vilket gynnar batteridrivna enheter. Protokollet har dessutom effektiv sändning≤ av information till både en och flera mottagare. Då MQTT klarar av dubbelriktad kommunikation passar det väl till industriella kontrollsystem, där många används för fjärrstyrning och fjärrmätning. Innan MQTT infördes uppskattar man att upp till 80% data kunde förlorades vid kontakt med avlägsna områden. MQTT-protokollets effektivitet gjorde att man kunde öka mängden data i varje mätning och få säkrare och pålitligare kontroll.

Publicera och prenumerera-modellen

Protokollet använder sig utav en så kallad publish/subscribe-modell för att överföra meddelanden mellan enheter. Kort handlar det om att enheter som sänder meddelanden inte riktar det till några mottagare specifikt; meddelandena är istället taggade med olika kategorier/ämnen innan sändning. Mottagarna tar endast emot meddelanden som är av intresse, det vill säga de ämnen de prenumererar/lyssnar på – något man kan likna vid radiostationer och radiolyssnare. Ingen hårdkodad anslutning finns upprättad mellan enheterna utan allt sker genom taggning av ämnen, sändning och aktiv lyssning på ämnen som intresserar. Sändningen sker genom servern, även kallat MQTT broker. Denna centrala server lagrar meddelanden från uppkopplade noder, exempelvis enheter som samlat in mätdata. Något att notera är att alla noder både sänder och tar emot data via brokern om man vill göra en dubbelriktad överföring.

mqtt grundprincip

MQTT och meddelanden

Meddelanden innehåller information som transporteras mellan enheterna som också kan innehålla ämnen för att kategorisera innehållet. Ämnena underlättar som sagt både att publicera och hämta relevant data. Ämnena representeras med strängar och är separerade med snedstreck, där varje snedstreck representerar nivån på ämnet. MQTT brokern vidarebefordrar meddelandet till alla enheter, så länge meddelandet innehåller ämnen som är av intresse för de prenumererade enheterna.
mqtt publish subscribe
MQTT är känt som ett lättviktsprotokoll eftersom varje payload har minimalt med kod. Payloaden består bland annat utav en fast header, samt själva meddelandet som innehåller information och en nivå på Quality of Service. Headern är begränsad till 2 bytes medan payloaden teoretiskt sett kan vara upp till 256 MB. Det är ett värde som är en nästintill omöjlig storlek att tänka sig att man vill överföra via MQTT kan tyckas. Tanken här är att MQTT skall kunna mellanlagra mycket data och skicka sällan, exempelvis om en enhet loggar data offline och skickar sällan. Och även om gränsen är 256 MB är det inte ett värde du lär nå. MQTT är resurssnålt och skickar du exempelvis bara en status som ”connected” behöver payloaden inte ens innehålla data. Ett paket kan se ut så här:

mqtt-paket

Testamenten

MQTT är en dubbelriktad överföring som har en session awareness. Det vill säga att om en enhet i fält tappar uppkopplingen med brokern så kommer alla enheter som prenumerar på dess information att få att “Last Will and Testament”. Genom detta testamente kan därmed enheter försöka att väcka enheten genom att ta kontakt åt andra hållet för att återinitiera kontakten.

Samtidigt skickas ett cacheat meddelande med instruktioner till prenumeranterna på aktuella Topics, om en sändande klient skulle förlora anslutningen. MQTT brokern lagrar meddelanden ifall någon enhet tappar anslutningen; dessa skickas sedan ut till klienten när anslutningen återupptas.
rätt data vid rätt tillfälle

MQTT Sessioner

En MQTT session är uppdelad i fyra faser: anslutning, autentisering, kommunikation och terminering. En klient börjar med att skapa en TCP/IP anslutning till servern genom en standardport eller en anpassad port definierad av nätverkets administratör. Vid skapande av anslutningen är det viktigt att notera att servern kan fortsätta en gammal session så länge den får en återanvänd klientidentitet. Standardporten är 1883 för icke-krypterad kommunikation medan 8883 används för krypterad kommunikation genom SSL/TLS.

Under kommunikationsfasen kan en klient publicera, prenumerera, avprenumerera och pinga. Vid publicering skickas ett binärt datablock, innehållet, till det ämne som definieras av sändaren. Prenumeration på ämnen görs genom SUBSCRIBE/SUBACK paket medan avprenumeration sker genom ett par av UNSUBSCRIBE/UNSUBACK paket, för att gå in litet mer på djupet.

Certifikat, minsta tänkbara säkerhetsnivå

Med hjälp av SSL/TLS validerar klienten serverns certifikat och autentiserar servern. Klienten kan också förse servern med sitt egna certifikat under handskakningen som servern kan använda för att autentisera klienten. På senare tid har det blivit vanligt för servrar att stödja autentisering med SSL/TLS certifikat hos klienten, även om det inte är en del av MQTTs specifikation.

Eftersom MQTT designades till att användas med IoT och resursbegränsade enheter är SSL/TLS inte alltid något som används. I sådana fall sker autentisering genom användarnamn och lösenord i klartext som skickas från klienten till servern under CONNECT/CONNACK sekvensen. Vidare kan vissa servrar, exempelvis de som är publicerade på internet, acceptera anonyma klienter. I dessa fall lämnas både användarnamnet och lösenordet blankt. Vi rekommenderar inget annat än certifikatsbaserade noder i MQTT och går du via mobilnäten så kan dessutom ett eget APN vara att föredra. Det finns ingen budget som är för liten för att inte tänka säkerhet från början. Har du inte tid eller resurser att lägga på TLS-certifierade enheter, då är det bättre att du väntar till du har resurser att göra det säkert och skalbart.
Skalbar data enkelt och säkert

MQTT och Quality of Service

QoS är en nyckelfunktion i MQTT och säkerställer garanterad leverans med avseende på ett specifikt meddelande. Tre nivåer finns tillgängliga för klienten att välja mellan, där varje nivå specificerar hur innehållet hanteras av MQTT protokollet. De högre QoS nivåerna är mer tillförlitliga men leder till högre latens och krav på högre bandbredd.

Den enklaste QoS nivån är att skicka utan bekräftelse, även känt som QoS0 eller “fire and forget”. Denna nivån använder sig utav en PUBLISH sekvens; sändaren skickar ett meddelande till servern en gång och servern vidarebefordrar meddelandet till prenumeranterna en gång. Det finns ingen mekanism som säkerställer att meddelandet har tagits emot korrekt, meddelandet sparas heller inte hos servern.

Den andra QoS nivån är tjänst med bekräftelse, även kallat QoS1. Denna QoS nivå använder sig utav en PUBLISH/PUBACK sekvens mellan sändaren och servern såväl som mellan servern och lyssnarna. När mottagaren tagit emot ett meddelande skickar mottagaren ett paket som bekräftar detta. Om en sådan inte mottas inom rimlig tid av den första sändaren skickas samma meddelande ut igen. Detta kan leda till att lyssnaren tar emot samma meddelande flera gånger.

Den tredje och sista QoS nivån är garanterad leverans, även kallat QoS2. Meddelanden levereras i par om två paket: det första paret kallas PUBLISH/PUBREC och den andra PUBREL/PUBCOMP. De två paketen garanterar att meddelandet endast levereras en gång, oavsett antal försök.
fördelar och nackdelar

MQTTs för- och nackdelar

Fördelarna med MQTT är många. Det är ett effektivt sätt att distribuera information och det är mycket skalbart. Det reducerar bandbredd och maximerar användningen av den bandbredd som finns tillgänglig. Den kan reducera uppdateringsfrekvensen sett till paketstorleken.

MQTT är väl lämpad för fjärrsensorer och fjärrstyrning eftersom den också har en mycket kompakt overhead och är dubbelriktad. Den ger en tillfredsställande säkerhet och det är inte komplicerat utan istället ett öppet protokoll som sparar utvecklingstid. Genom att det inte har en polling-modell så kan den koncentrera mer data på mindre bandbredd.

Och nackdelarna då? En negativ aspekt av MQTT är bristen på kompatibilitet. Meddelanden är binära utan information på hur de är kodade, vilket kan leda till problem – speciellt i öppna arkitekturer där olika applikationer från olika tillverkare sömlöst ska kunna arbeta tillsammans. En annan brist har med MQTTs ämnesstruktur att göra. Det är jämförelsevis lätt att skapa ett stort träd som med tiden blir svår att dela in i mindre, logiska domäner. Större, globalt skalbara MQTT nätverk kan då vara svåra att implementera eftersom större träd leder till ökad komplexitet. Gäller att tänka till innan alltså!

Även MQTTs säkerhet bör nämnas: eftersom protokollet inte utvecklades med säkerhet som högsta prioritet är det i grunden okrypterat. MQTT har traditionellt använts i säkra backendnätverk för att klara uppgifter i specifika applikationer. Protokollet förlitar sig på användning av SSL/TLS om kommunikation ska ske säkert. Alla säkerhetsinställningar konfigureras i MQTT servern och måste följas av enheterna.

Ytterligare nackdelar inkluderar långsammare sändningscykler jämfört med CoAP.

Varför MQTT?

MQTT är ett lättviktsprotokoll med många användningsområden, inte minst när det gäller IoT och automatisering av projekt. Protokollet är lättanvänt, extremt effektiv och ökar jämförelsevis mängden tillgänglig bandbredd jämfört med pollande system som tenderar att utnyttja bandbredd mindre effektivt.

Induos logo
Induo AB
08-659 43 00

www.induo.com
[email protected]

Mer information:

Fyll i formuläret nedan med namn, e-post och kanske ett meddelande så hör vi av oss så snart vi kan, tack!

* Genom att skicka in formuläret samtycker du att vi lagrar dina uppgifter för att hjälpa dig med din förfrågan.

Läs mer om:

Leverantörer
Produkter

Socialt:

Följ oss i sociala medier:

linkedinfacebooktwitteryoutube

Back To Top
×Close search
Sök