Protokoll

Ett protokoll är en uppsättning regler för hur data flyttas mellan maskiner. Utan gemensamma regler kan två enheter inte förstå varandra, ungefär som två personer som talar olika språk inte kan det utan tolk.

Protokoll definierar hur data delas upp i paket, hur fel upptäcks och korrigeras, hur anslutningar öppnas och stängs, och vilken form meddelanden har.

Ett pakets anatomi

Nästan varje paket, i varje lager, har samma två delar:

Konkret innehåller headern källa och destination i form av IP-adress och port, plus sekvensnummer, felkontroll och meddelandetyp.

Lagren ligger i varandra. Ett MQTT-meddelande är payloaden i ett TCP-segment, som är payloaden i ett IP-paket, som är payloaden i vad radion än sänder. Varje lager lägger till sin egen header och läser bara sin egen, vilket är det som gör att samma MQTT-meddelande kan färdas över WiFi i en byggnad och över mobilnät i nästa.

Hur protokollen staplas

Lättviktiga protokoll som CoAP och LwM2M gör effektiv kommunikation möjlig för små batteridrivna enheter, medan MQTT och HTTP ger tillförlitlig transport över TCP.

Vilket protokoll som körs på vilket nät

En nätverksteknik bestämmer inte protokollet, men i praktiken är kombinationerna förutsägbara:

Nätverksteknik	Vanliga protokoll	Exempel på enheter
LoRaWAN	MQTT, via nätverksservern	Miljösensorer, mätare
NB-IoT	MQTT, CoAP, UDP	Mätare, tillgångstrackers, miljösensorer
LTE-M (Cat-M1)	MQTT, CoAP, UDP	Wearables, fordonstrackers, industrisensorer
WiFi	HTTP, MQTT, TCP	Kameror, smarta uttag, termostater
Ethernet	HTTP, MQTT, TCP	Industristyrsystem, PLC:er, gateways
BLE	Gateway till MQTT, HTTP eller CoAP	Wearables, beacons, lås, medicinteknik
ZigBee, Z-Wave, Matter	Gateway till MQTT	Fastighets- och hemautomation
Rå TCP	TCP	Industriutrustning, gateways, kameror

Resursbegränsade tekniker och kortdistanstekniker förlitar sig på en gateway som översätter deras meddelanden till MQTT, HTTP eller CoAP, vilket är så lågeffektsenheter når system utanför sitt eget nät.

IP: adressering och routing

Internet Protocol är det som gör internet till ett nät i stället för många. Det ger varje ändpunkt en adress och dirigerar paket mellan dem, utan att bry sig om vilket medium som bär dem.

• IPv4-adresser ser ut som 192.168.1.10. Det finns ungefär fyra miljarder, vilket tog slut, så de flesta enheter sitter bakom nätadressöversättning.
• IPv6-adresser ser ut som 2001:db8::1. Det finns tillräckligt för varje enhet många gånger om, och mobila IoT-nät använder det i allt högre grad.

IP självt lovar ingenting. Det garanterar inte att ett paket kommer fram, att paket kommer i ordning, eller att de bara kommer en gång. Allt ovanför lägger antingen till de garantierna eller bestämmer sig för att klara sig utan dem. Det beslutet är skillnaden mellan TCP och UDP.

TCP: tillförlitligt och ordnat

TCP upprättar en anslutning innan någon data flödar, med en trevägshandskakning, och river den efteråt. Inom anslutningen numrerar det varje byte, kvitterar det som kom fram, sänder om det som inte gjorde det, och levererar resultatet till applikationen i den ordning det skickades.

Använd det när korrekthet väger tyngre än overhead, vilket är de flesta gånger. HTTP, MQTT och LwM2M över TCP bygger alla på det.

Vad det kostar:

• Uppkopplingen tar en tur och retur innan någon data rör sig, och krypteringshandskakningen tar mer.
• Att hålla anslutningen öppen kostar energi på en batteridriven enhet, eftersom radion måste vakna regelbundet.
• Head-of-line-blockering: ett förlorat segment fördröjer allt som köar bakom det.

UDP: minimalt och snabbt

UDP skickar ett datagram till en adress och port och slutar sedan bry sig. Det finns ingen anslutning, ingen kvittering, ingen omsändning och ingen ordning. Ett datagram kommer fram helt eller inte alls.

Det låter sämre och är det ofta inte. För en sensor som skickar en temperatur var tionde minut är ett förlorat paket inte värt en omsändning, eftersom ett färskare värde ändå är på väg. Att ta bort anslutningen tar bort handskakningen, keep-alive och tillståndet i båda ändar, vilket allt är batteri och minne som en resursbegränsad enhet inte har.

Använd det för små, frekventa och var för sig umbärliga meddelanden. CoAP, rå UDP-telemetri och LwM2M över CoAP använder alla det.

HTTP: fråga och svar

HTTP är grunden för webben, för REST-API:er och för gRPC, som använder HTTP/2 som transport. I IoT är det så de flesta system talar med varandra, och hur många enheter rapporterar in.

En klient skickar en förfrågan, och servern returnerar ett svar. Förfrågan anger en metod och en sökväg; svaret bär en statuskod och oftast en kropp.

GET /iotnode/stats/{id} HTTP/1.1
Host: yggio.example.net
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 85

{
  "sensorId": "temp-001",
  "timestamp": "2025-10-08T10:30:00Z",
  "temperature": 22.5,
  "unit": "C"
}

Metoder

REST-API:er använder HTTP-metoderna för att betyda bestämda saker:

Metod	Betyder	Typisk användning
GET	Läs, ändrar ingenting	Hämta en enhet, lista enheter, läsa historik
POST	Skapa, eller skicka in	Skapa en enhet, posta ett mätvärde
PUT	Ersätt hela objektet	Skriv över ett enhetsdokument
PATCH	Ändra en del av det	Uppdatera ett fält
DELETE	Ta bort det	Ta bort en enhet

GET är säker att upprepa och säker att cacha. PUT och DELETE är idempotenta, vilket betyder att göra dem två gånger ger samma resultat som att göra dem en gång. POST är ingetdera, vilket är varför ett omsänt POST kan skapa två av något.

Statuskoder

Första siffran berättar vem du ska prata med om saken:

Intervall	Betydelse	Vanliga exempel
2xx	Lyckades	200 OK, 201 Created, 204 No Content
3xx	Omdirigering	301 Moved Permanently, 304 Not Modified
4xx	Förfrågan var fel	400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests
5xx	Servern misslyckades	500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable

En 4xx betyder att förfrågan ska rättas: URL:en, inloggningsuppgifterna, rättigheterna eller kroppen. En 5xx betyder att förfrågan var rimlig och att motparten inte kunde uppfylla den, så försök igen efter en fördröjning.

Headers och säkerhet

Headers bär allt som inte är kroppen: Content-Type anger vad kroppen är, Authorization bär inloggningsuppgiften, Accept anger vad klienten kan läsa. HTTPS är HTTP inuti TLS, vilket krypterar hela utbytet inklusive headers, och är den enda formen som bör passera ett publikt nät.

Vad HTTP passar sämre för

HTTP är en klient som frågar en server. Om servern har något att säga först måste den vänta på att bli tillfrågad, så en enhet som ska ta emot kommandon måste polla, vilket kostar batteri och lägger till fördröjning. Det är precis den luckan MQTT fyller.

MQTT: publish och subscribe

MQTT är ett lättviktigt protokoll byggt för exakt den situation IoT befinner sig i: många små enheter, på opålitliga nät, bakom brandväggar, som skickar små meddelanden. Tillsammans med HTTP är det det viktigaste protokollet i modern IoT.

I stället för att fråga en server publicerar en enhet ett meddelande till ett topic på en broker. Brokern vidarebefordrar det till alla som prenumererar på det topicet. Publicerare och prenumeranter känner aldrig till varandra, vilket är det som gör att mönstret skalar.

Varför det passar IoT så väl

Två egenskaper löser i tysthet problem som kostar riktiga pengar.

Sessionen öppnas alltid av enheten och utåt, så det finns inga inkommande portar att öppna och en hel kategori av brandväggsdiskussioner försvinner. Och overheaden är låg nog att tusentals enheter delar en broker utan problem.

En MQTT-integration kräver oftast bara att båda parter är överens om datamodellen snarare än om ett helt API, vilket är varför det har blivit det gemensamma språket mellan system, inte bara mellan enheter.

Topics

Ett topic är en sökväg, och det är hela adresseringen:

Yggio/output/v2/<credentials id>/<node id>

Prenumeranter kan använda wildcards:

• + matchar exakt en nivå. building/+/temperature matchar building/floor1/temperature och building/floor2/temperature.
• # matchar allt under, och måste stå sist. building/# matchar varje topic under building.

Utforma topics som en hierarki från allmänt till specifikt, så att en prenumerant kan välja hur mycket den vill ta emot.

Quality of service

MQTT erbjuder tre leveransgarantier, valda per meddelande:

QoS	Garanti	Kostnad	Använd för
0	Högst en gång, skicka och glöm	Lägst	Frekventa mätvärden där nästa snart kommer
1	Minst en gång, kan dubbleras	En kvittens	Merparten av telemetri, där ett förlorat värde spelar roll
2	Exakt en gång	Fyrdelad handskakning	Kommandon och debiteringshändelser, där en dubblett vore skadlig

QoS 1 är det vanliga valet. Det kan leverera samma meddelande två gånger, så allt som agerar på det bör tåla en upprepning.

De övriga funktionerna värda att känna till

• Retained messages: brokern behåller det senaste meddelandet på ett topic och ger det till varje ny prenumerant direkt, så att en dashboard visar ett värde vid anslutning i stället för att vänta på nästa rapport.
• Last will and testament: enheten registrerar ett meddelande när den ansluter, som brokern publicerar om enheten försvinner utan att säga adjö. Det är så du upptäcker en enhet som tappade anslutningen snarare än en som loggade ut.
• Keep-alive: ett hjärtslagsintervall som avtalas vid anslutning. Hör brokern ingenting inom det betraktas anslutningen som död och testamentet publiceras.
• Clean och persistent sessions: en persistent session låter brokern behålla prenumerationer och köade meddelanden medan enheten är offline, så att inget missas över ett avbrott.

Säkerhet

MQTTS är MQTT inuti TLS, normalt på port 8883, och är det som bör användas överallt utanför ett betrott nät. Autentisering sker med användarnamn och lösenord eller med klientcertifikat, och behörighet sätts per topic, så en enhet kan tillåtas publicera bara sitt eget topic och inget annat.

Yggio levererar en fullt kompatibel MQTT-broker med inbyggd behörighetsstyrning, och den gör mer än att vidarebefordra meddelanden. Data som publiceras till den bearbetas i Yggios dataflöden och lagras som tidsserier samtidigt, så varje meddelande är omedelbart tillgängligt för historik, analys och visualisering utan att någon bygger en andra väg för det.

CoAP: REST för resursbegränsade enheter

CoAP, Constrained Application Protocol, konstruerades för maskin-till-maskin-kommunikation på enheter med mycket lite minne, processorkraft och batteri.

Det behåller modellen utvecklare redan känner från HTTP, med resurser på sökvägar och metoderna GET, POST, PUT och DELETE, och bygger om den på UDP med en kompakt binär header som mäts i ensiffriga byte i stället för de hundratals som en uppsättning HTTP-headers kan ta.

Vad det lägger till ovanpå UDP:

• Bekräftade och obekräftade meddelanden. Ett bekräftat meddelande kvitteras och sänds om ifall det inte blir det, vilket ger tillförlitlighet där man vill ha den utan en permanent anslutning.
• Observe, som låter en klient anmäla intresse för en resurs så att servern skickar uppdateringar när värdet ändras. Det är den push som vanlig HTTP saknar.
• Block-wise transfer, som flyttar payloads större än ett datagram i delar, används för firmwarefiler.
• Upptäckt, så att en klient kan fråga en enhet vilka resurser den erbjuder.

Säkerheten är DTLS, som är TLS anpassat för datagram. OSCORE är ett alternativ som skyddar själva meddelandet i stället för kanalen, så att det överlever att vidarebefordras av en gateway som annars skulle behöva avsluta krypteringen.

CoAP är vanligt på NB-IoT- och LTE-M-enheter, och under LwM2M.

LwM2M: att hantera enheten, inte bara dess data

Allt ovanför flyttar mätvärden. LwM2M, från Open Mobile Alliance, hanterar själva enheten och körs normalt över CoAP, ibland direkt över UDP eller TCP.

Det definierar en standardstruktur av objekt och resurser, var och en med ett registrerat nummer, så att "batterinivå" eller "firmwareversion" betyder samma sak på varje enhet som implementerar det. Den standardiseringen är hela poängen: enhetshantering slutar vara tillverkarspecifik.

Livscykeln det täcker:

• Bootstrap, där en enhet får adressen till och inloggningsuppgifterna för sin hanteringsserver.
• Registrering, där den anmäler sig och vilka objekt den stödjer.
• Enhetshantering och konfiguration, att läsa och skriva de resurserna på distans.
• Firmwareuppdatering över luften, med block-wise transfer.
• Telemetri, att rapportera värden enligt schema eller vid förändring.

Att välja mellan dem

Protokoll	Transport	Mönster	Passar bäst för
HTTP	TCP	Fråga och svar	System till system, REST-API:er, gles rapportering från nätanslutna enheter
MQTT	TCP	Publish och subscribe	Kontinuerlig telemetri, kommandon till enheter, strömmande system till system
CoAP	UDP	Fråga och svar, plus observe	Resursbegränsade batteridrivna enheter, mobilt IoT
LwM2M	CoAP, UDP eller TCP	Enhetshantering och telemetri	Flottor som behöver standardiserad fjärrkonfiguration och firmwareuppdatering
Rå TCP eller UDP	TCP eller UDP	Vad enheten nu gör	Äldre och specialbyggd utrustning

I praktiken använder ett och samma bestånd flera samtidigt, vilket är normalt och är precis vad plattformslagret finns till för att ta hand om.

Säkerhet genom stacken

Kryptering appliceras i varje steg snarare än en gång. Ett LoRaWAN-mätvärde krypteras till exempel med AES-128 inom LoRaWAN självt från enheten till nätverksservern, färdas sedan inuti TLS från nätverksservern till plattformen, och sedan inuti TLS igen över MQTTS eller HTTPS ut till användaren.

Principen att ta med sig: varje lager skyddar sin egen sträcka, och en gateway som avslutar ett protokoll och startar ett annat är en punkt där datan finns i klartext om inte något i stil med OSCORE skyddar meddelandet hela vägen.