Protokolle

Ein Protokoll ist ein Satz Regeln dafür, wie sich Daten zwischen Maschinen bewegen. Ohne gemeinsame Regeln können zwei Geräte einander nicht verstehen, ähnlich wie zwei Menschen, die verschiedene Sprachen sprechen, es ohne Dolmetscher nicht können.

Protokolle legen fest, wie Daten in Pakete aufgeteilt werden, wie Fehler erkannt und korrigiert werden, wie Verbindungen geöffnet und geschlossen werden und welche Form Nachrichten haben.

Der Aufbau eines Pakets

Nahezu jedes Paket, in jeder Schicht, hat dieselben zwei Teile:

Konkret enthält der Header Quelle und Ziel als IP-Adresse und Port, dazu Sequenznummern, Fehlerprüfung und Nachrichtentyp.

Die Schichten liegen ineinander. Eine MQTT-Nachricht ist die Payload eines TCP-Segments, das die Payload eines IP-Pakets ist, das die Payload dessen ist, was der Funk sendet. Jede Schicht fügt ihren eigenen Header hinzu und liest nur ihren eigenen. Genau das erlaubt es, dass dieselbe MQTT-Nachricht im einen Gebäude über WiFi und im nächsten über Mobilfunk reist.

Wie sich die Protokolle stapeln

Leichtgewichtige Protokolle wie CoAP und LwM2M ermöglichen effiziente Kommunikation für kleine batteriebetriebene Geräte, während MQTT und HTTP zuverlässigen Transport über TCP bieten.

Welches Protokoll auf welchem Netz läuft

Eine Netzwerktechnik gibt das Protokoll nicht vor, in der Praxis sind die Kombinationen aber vorhersehbar:

Netzwerktechnik	Übliche Protokolle	Beispielgeräte
LoRaWAN	MQTT, über den Netzwerkserver	Umweltsensoren, Zähler
NB-IoT	MQTT, CoAP, UDP	Zähler, Asset-Tracker, Umweltsensoren
LTE-M (Cat-M1)	MQTT, CoAP, UDP	Wearables, Fuhrpark-Tracker, Industriesensoren
WiFi	HTTP, MQTT, TCP	Kameras, smarte Steckdosen, Thermostate
Ethernet	HTTP, MQTT, TCP	Industriesteuerungen, SPS, Gateways
BLE	Gateway zu MQTT, HTTP oder CoAP	Wearables, Beacons, Schlösser, Medizintechnik
ZigBee, Z-Wave, Matter	Gateway zu MQTT	Gebäude- und Hausautomation
Rohes TCP	TCP	Industriegeräte, Gateways, Kameras

Ressourcenbeschränkte und kurzreichweitige Techniken sind auf ein Gateway angewiesen, das ihre Nachrichten in MQTT, HTTP oder CoAP übersetzt. So erreichen Geräte mit geringem Energiebedarf Systeme außerhalb ihres eigenen Netzes.

IP: Adressierung und Routing

Das Internet Protocol macht das Internet zu einem Netz statt zu vielen. Es gibt jedem Endpunkt eine Adresse und leitet Pakete zwischen ihnen weiter, ohne sich darum zu kümmern, welches Medium sie trägt.

• IPv4-Adressen sehen aus wie 192.168.1.10. Es gibt etwa vier Milliarden davon, was nicht reichte, weshalb die meisten Geräte hinter Network Address Translation sitzen.
• IPv6-Adressen sehen aus wie 2001:db8::1. Davon gibt es für jedes Gerät ein Vielfaches, und Mobilfunk-IoT-Netze nutzen es zunehmend.

IP selbst verspricht nichts. Es garantiert nicht, dass ein Paket ankommt, dass Pakete in der richtigen Reihenfolge ankommen oder dass sie nur einmal ankommen. Alles darüber fügt entweder diese Garantien hinzu oder entscheidet, ohne sie auszukommen. Diese Entscheidung ist der Unterschied zwischen TCP und UDP.

TCP: zuverlässig und geordnet

TCP baut eine Verbindung auf, bevor Daten fließen, mit einem Drei-Wege-Handshake, und baut sie danach wieder ab. Innerhalb der Verbindung nummeriert es jedes Byte, bestätigt das Angekommene, überträgt Verlorenes erneut und liefert das Ergebnis in der Sendereihenfolge an die Anwendung.

Nutzen Sie es, wenn Korrektheit schwerer wiegt als Overhead, was meistens der Fall ist. HTTP, MQTT und LwM2M über TCP bauen alle darauf auf.

Was es kostet:

• Der Aufbau braucht einen Hin- und Rückweg, bevor Daten fließen, und der Verschlüsselungs-Handshake braucht mehr.
• Die Verbindung offen zu halten kostet auf einem Batteriegerät Energie, weil der Funk regelmäßig aufwachen muss.
• Head-of-Line-Blocking: Ein verlorenes Segment verzögert alles, was dahinter wartet.

UDP: minimal und schnell

UDP sendet ein Datagramm an eine Adresse und einen Port und kümmert sich dann nicht weiter. Es gibt keine Verbindung, keine Bestätigung, keine Wiederholung und keine Reihenfolge. Ein Datagramm kommt vollständig an oder gar nicht.

Das klingt schlechter und ist es oft nicht. Für einen Sensor, der alle zehn Minuten eine Temperatur sendet, ist ein verlorenes Paket keine Wiederholung wert, denn ein frischerer Wert ist ohnehin unterwegs. Die Verbindung wegzulassen entfernt den Handshake, das Keep-Alive und den Zustand auf beiden Seiten, und all das ist Batterie und Speicher, die ein ressourcenbeschränktes Gerät nicht hat.

Nutzen Sie es für kleine, häufige und einzeln verzichtbare Nachrichten. CoAP, rohe UDP-Telemetrie und LwM2M über CoAP verwenden es.

HTTP: Anfrage und Antwort

HTTP ist die Grundlage des Web, der REST-APIs und von gRPC, das HTTP/2 als Transport nutzt. Im IoT sprechen so die meisten Systeme miteinander, und so melden sich viele Geräte.

Ein Client sendet eine Anfrage, und der Server liefert eine Antwort. Die Anfrage nennt eine Methode und einen Pfad; die Antwort trägt einen Statuscode und meist einen Body.

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"
}

Methoden

REST-APIs nutzen die HTTP-Methoden, um Bestimmtes auszudrücken:

Methode	Bedeutet	Typische Verwendung
GET	Lesen, ändert nichts	Ein Gerät abrufen, Geräte auflisten, Historie lesen
POST	Anlegen oder einreichen	Ein Gerät anlegen, einen Messwert senden
PUT	Das Ganze ersetzen	Ein Gerätedokument überschreiben
PATCH	Einen Teil davon ändern	Ein Feld aktualisieren
DELETE	Entfernen	Ein Gerät löschen

GET lässt sich gefahrlos wiederholen und zwischenspeichern. PUT und DELETE sind idempotent, das heißt, sie zweimal auszuführen führt zum selben Ergebnis wie einmal. POST ist keines von beidem, weshalb ein wiederholtes POST zwei Objekte anlegen kann.

Statuscodes

Die erste Ziffer sagt Ihnen, mit wem Sie darüber sprechen müssen:

Bereich	Bedeutung	Häufige Beispiele
2xx	Erfolg	200 OK, 201 Created, 204 No Content
3xx	Weiterleitung	301 Moved Permanently, 304 Not Modified
4xx	Die Anfrage war falsch	400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests
5xx	Der Server ist gescheitert	500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable

Ein 4xx bedeutet, die Anfrage zu korrigieren: die URL, die Zugangsdaten, die Berechtigungen oder den Body. Ein 5xx bedeutet, die Anfrage war vernünftig und die Gegenseite konnte sie nicht erfüllen, also mit Verzögerung erneut versuchen.

Header und Sicherheit

Header tragen alles, was nicht der Body ist: Content-Type sagt, was der Body ist, Authorization trägt die Zugangsdaten, Accept sagt, was der Client lesen kann. HTTPS ist HTTP innerhalb von TLS, was den gesamten Austausch einschließlich der Header verschlüsselt, und ist die einzige Form, die ein öffentliches Netz überqueren sollte.

Wofür HTTP weniger geeignet ist

HTTP ist ein Client, der einen Server fragt. Hat der Server zuerst etwas zu sagen, muss er warten, bis er gefragt wird. Ein Gerät, das Kommandos empfangen soll, muss also pollen, was Batterie kostet und Verzögerung hinzufügt. Genau diese Lücke füllt MQTT.

MQTT: Publish und Subscribe

MQTT ist ein leichtgewichtiges Protokoll, gebaut für genau die Lage, in der IoT sich befindet: viele kleine Geräte, in unzuverlässigen Netzen, hinter Firewalls, die kleine Nachrichten senden. Zusammen mit HTTP ist es das wichtigste Protokoll im modernen IoT.

Statt einen Server zu fragen, publiziert ein Gerät eine Nachricht an ein Topic auf einem Broker. Der Broker leitet sie an alle weiter, die dieses Topic abonniert haben. Publisher und Abonnenten wissen nie voneinander, und genau das lässt das Muster skalieren.

Warum es so gut zu IoT passt

Zwei Eigenschaften lösen still und leise Probleme, die echtes Geld kosten.

Die Session wird immer vom Gerät nach außen geöffnet, sodass es keine eingehenden Ports zu öffnen gibt und eine ganze Kategorie von Firewall-Diskussionen entfällt. Und der Overhead ist gering genug, dass sich Tausende Geräte bequem einen Broker teilen.

Eine MQTT-Integration verlangt meist nur, dass sich beide Seiten auf das Datenmodell einigen statt auf ein ganzes API. Deshalb ist es zur gemeinsamen Sprache zwischen Systemen geworden, nicht nur zwischen Geräten.

Topics

Ein Topic ist ein Pfad, und es ist das gesamte Adressierungsschema:

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

Abonnenten können Wildcards nutzen:

• + trifft genau eine Ebene. building/+/temperature trifft building/floor1/temperature und building/floor2/temperature.
• # trifft alles darunter und muss am Ende stehen. building/# trifft jedes Topic unterhalb von building.

Entwerfen Sie Topics als Hierarchie vom Allgemeinen zum Speziellen, damit ein Abonnent wählen kann, wie viel er entgegennimmt.

Quality of Service

MQTT bietet drei Zustellgarantien, je Nachricht wählbar:

QoS	Garantie	Kosten	Einsatz für
0	Höchstens einmal, senden und vergessen	Am geringsten	Häufige Messwerte, bei denen der nächste bald folgt
1	Mindestens einmal, kann sich doppeln	Eine Bestätigung	Der Großteil der Telemetrie, wo ein verlorener Wert zählt
2	Genau einmal	Vierteiliger Handshake	Kommandos und Abrechnungsereignisse, wo ein Duplikat schadet

QoS 1 ist die übliche Wahl. Es kann dieselbe Nachricht zweimal zustellen, weshalb alles, was darauf reagiert, eine Wiederholung vertragen sollte.

Die weiteren Funktionen, die man kennen sollte

• Retained Messages: Der Broker behält die letzte Nachricht eines Topics und gibt sie jedem neuen Abonnenten sofort, sodass ein Dashboard beim Verbinden einen Wert zeigt, statt auf die nächste Meldung zu warten.
• Last Will and Testament: Das Gerät hinterlegt beim Verbinden eine Nachricht, die der Broker publiziert, wenn das Gerät verschwindet, ohne sich abzumelden. So erkennen Sie ein Gerät, dem die Verbindung abgebrochen ist, im Unterschied zu einem, das sich ordentlich abgemeldet hat.
• Keep-Alive: ein beim Verbinden vereinbartes Herzschlagintervall. Hört der Broker innerhalb dieser Zeit nichts, gilt die Verbindung als tot und das Testament wird publiziert.
• Clean und Persistent Sessions: Eine Persistent Session lässt den Broker Abonnements und Nachrichten zwischenspeichern, während das Gerät offline ist, sodass über eine Lücke hinweg nichts verloren geht.

Sicherheit

MQTTS ist MQTT innerhalb von TLS, üblicherweise auf Port 8883, und sollte überall außerhalb eines vertrauenswürdigen Netzes verwendet werden. Die Authentifizierung erfolgt über Benutzername und Passwort oder über ein Client-Zertifikat, und die Berechtigung wird je Topic vergeben, sodass ein Gerät nur sein eigenes Topic publizieren darf und sonst nichts.

Yggio liefert einen vollständig kompatiblen MQTT-Broker mit eingebauter Zugriffssteuerung, und er tut mehr, als Nachrichten weiterzuleiten. An ihn publizierte Daten werden zugleich in den Datenflüssen von Yggio verarbeitet und als Zeitreihen gespeichert, sodass jede Nachricht sofort für Historie, Analyse und Visualisierung verfügbar ist, ohne dass jemand einen zweiten Weg dafür baut.

CoAP: REST für ressourcenbeschränkte Geräte

CoAP, das Constrained Application Protocol, wurde für die Maschine-zu-Maschine-Kommunikation auf Geräten mit sehr wenig Speicher, Rechenleistung und Batterie entworfen.

Es behält das Modell bei, das Entwickler von HTTP kennen, mit Ressourcen an Pfaden und den Methoden GET, POST, PUT und DELETE, und baut es auf UDP neu auf, mit einem kompakten Binär-Header von einstelliger Byte-Größe statt der Hunderte, die ein Satz HTTP-Header belegen kann.

Was es zusätzlich zu UDP bietet:

• Bestätigte und unbestätigte Nachrichten. Eine bestätigte Nachricht wird quittiert und andernfalls erneut gesendet, was Zuverlässigkeit dort bringt, wo man sie möchte, ohne dauerhafte Verbindung.
• Observe, womit ein Client Interesse an einer Ressource anmelden kann, sodass der Server bei Wertänderungen Aktualisierungen sendet. Das ist der Push, der einfachem HTTP fehlt.
• Block-wise Transfer, der Payloads größer als ein Datagramm in Teilen überträgt, genutzt für Firmware-Images.
• Discovery, sodass ein Client ein Gerät fragen kann, welche Ressourcen es anbietet.

Die Sicherheit ist DTLS, also TLS für Datagramme angepasst. OSCORE ist eine Alternative, die die Nachricht selbst statt des Kanals schützt, sodass sie es übersteht, von einem Gateway weitergeleitet zu werden, das die Verschlüsselung sonst terminieren müsste.

CoAP ist auf NB-IoT- und LTE-M-Geräten verbreitet und liegt unter LwM2M.

LwM2M: das Gerät verwalten, nicht nur seine Daten

Alles bisher Genannte bewegt Messwerte. LwM2M von der Open Mobile Alliance verwaltet das Gerät selbst und läuft normalerweise über CoAP, manchmal direkt über UDP oder TCP.

Es definiert eine Standardstruktur aus Objekten und Ressourcen, jeweils mit einer registrierten Nummer, sodass "Batteriestand" oder "Firmware-Version" auf jedem Gerät dasselbe bedeutet, das es implementiert. Diese Standardisierung ist der eigentliche Punkt: Geräteverwaltung hört auf, herstellerspezifisch zu sein.

Der abgedeckte Lebenszyklus:

• Bootstrap, bei dem ein Gerät Adresse und Zugangsdaten seines Verwaltungsservers erhält.
• Registrierung, bei der es sich anmeldet und mitteilt, welche Objekte es unterstützt.
• Geräteverwaltung und Konfiguration, also das Lesen und Schreiben dieser Ressourcen aus der Ferne.
• Firmware-Update über die Luftschnittstelle, mit Block-wise Transfer.
• Telemetrie, also das Melden von Werten nach Zeitplan oder bei Änderung.

Die Wahl zwischen ihnen

Protokoll	Transport	Muster	Am besten geeignet für
HTTP	TCP	Anfrage und Antwort	System zu System, REST-APIs, gelegentliche Meldungen netzbetriebener Geräte
MQTT	TCP	Publish und Subscribe	Fortlaufende Telemetrie, Kommandos an Geräte, System-zu-System-Streaming
CoAP	UDP	Anfrage und Antwort, plus Observe	Ressourcenbeschränkte Batteriegeräte, Mobilfunk-IoT
LwM2M	CoAP, UDP oder TCP	Geräteverwaltung und Telemetrie	Flotten mit standardisierter Fernkonfiguration und Firmware-Update
Rohes TCP oder UDP	TCP oder UDP	Was das Gerät eben tut	Altsysteme und Spezialgeräte

In der Praxis nutzt ein und derselbe Bestand mehrere gleichzeitig, was normal ist und genau das, wofür die Plattformschicht da ist.

Sicherheit über den Stack hinweg

Verschlüsselung wird je Teilstrecke angewandt statt einmal. Ein LoRaWAN-Messwert wird zum Beispiel innerhalb von LoRaWAN selbst mit AES-128 vom Gerät bis zum Netzwerkserver verschlüsselt, reist dann innerhalb von TLS vom Netzwerkserver zur Plattform und dann erneut innerhalb von TLS über MQTTS oder HTTPS zum Nutzer.

Das Prinzip zum Mitnehmen: Jede Schicht schützt ihre eigene Teilstrecke, und ein Gateway, das ein Protokoll beendet und ein anderes beginnt, ist eine Stelle, an der die Daten im Klartext vorliegen, sofern nicht etwas wie OSCORE die Nachricht durchgängig schützt.