Das richtige IoT-Transportprotokoll wählen: UDP, TCP/IP, HTTPS, MQTT und die Rolle von TagoTiP

Jedes IoT-Projekt beginnt mit derselben grundlegenden Frage: Wie kommuniziert mein Gerät mit der Cloud? Sensoren, Aktoren und Mikrocontroller erzeugen Daten, die erst dann wertvoll werden, wenn sie eine Plattform erreichen, auf der sie gespeichert, visualisiert und genutzt werden können. Doch Daten von einem Gerät in die Cloud zu bringen, ist nicht nur ein technisches Detail: Das gewählte Protokoll wirkt sich direkt auf die Batterielaufzeit, die Datenkosten, die Zuverlässigkeit, die Komplexität und die Skalierbarkeit Ihres Geräts aus.

In diesem Beitrag gehen wir die gängigsten Konnektivitätsprotokolle im IoT durch: UDP, TCP/IP, HTTPS und MQTT. Anschließend stellen wir TagoTiP (Transport IoT Protocol) vor, ein neues offenes Protokoll von TagoIO, das speziell für ressourcenbeschränkte Geräte wie Arduino, ESP8266, ESP32 und jedes andere kleine IoT-Board entwickelt wurde, das die Cloud so effizient wie möglich erreichen muss.

UDP: schnell, leichtgewichtig, ohne Empfangsbestätigung

UDP (User Datagram Protocol) ist eines der grundlegendsten Transportprotokolle in der Netzwerktechnik. Es sendet Datenpakete, ohne zuvor eine Verbindung aufzubauen und ohne jede Bestätigung darüber, dass die Daten empfangen wurden.

Stellen Sie sich UDP wie eine Postkarte vor, die Sie in den Briefkasten werfen. Sie schicken sie ab und machen weiter: Sie haben keine Möglichkeit zu erfahren, ob sie tatsächlich angekommen ist.

Die Vorteile von UDP sind erheblich für IoT-Anwendungen, bei denen Geschwindigkeit und geringer Overhead wichtiger sind als die garantierte Zustellung. Da es keinen Handshake und keinen Bestätigungsprozess gibt, ist UDP extrem schnell und belastet das Gerät kaum. Die Pakete sind klein, und das Gerät kann fast unmittelbar nach dem Senden wieder in den Schlafmodus wechseln. Damit eignet sich UDP besonders gut für batteriebetriebene Geräte, NB-IoT-Einsätze und Szenarien, in denen gelegentlicher Paketverlust akzeptabel ist, etwa beim Senden periodischer Sensormesswerte, wo das Fehlen eines Werts von hundert kein Problem darstellt.

Auch die Nachteile sind real. UDP bietet überhaupt keine Zustellungsgarantie. Pakete können vom Netzwerk verworfen werden, in falscher Reihenfolge ankommen oder dupliziert werden, ohne dass der Sender es je erfährt. Es gibt auch keine integrierte Sicherheit, kein Session-Management und keine native Unterstützung für die Zwei-Wege-Kommunikation. Zuverlässigkeit auf Basis von UDP umzusetzen, erfordert eigene Logik auf Anwendungsebene, was die Entwicklung komplexer macht.

Am besten geeignet für: Hochfrequente Telemetrie, eingeschränkte Geräte in stromsparenden Netzen, Anwendungen, bei denen Geschwindigkeit wichtiger ist als die garantierte Zustellung.

TCP/IP: zuverlässige, verbindungsorientierte Kommunikation

TCP (Transmission Control Protocol), immer gepaart mit IP (Internet Protocol), ist das Rückgrat des Internets. Anders als UDP baut TCP eine Verbindung zwischen Gerät und Server auf, bevor überhaupt Daten ausgetauscht werden, verfolgt jedes Paket, überträgt verloren gegangene erneut und stellt sicher, dass die Daten in der richtigen Reihenfolge ankommen.

Wenn UDP eine Postkarte ist, dann ist TCP ein Einschreiben mit Rückschein.

Die Stärken von TCP/IP liegen auf der Hand: Sie erhalten eine garantierte Zustellung, eine geordnete Übertragung und eine integrierte Fehlerprüfung. Für IoT-Anwendungsfälle, in denen die Datenintegrität entscheidend ist, etwa bei industriellen Steuerungssystemen, Medizingeräten oder Finanztelemetrie, ist TCP/IP kaum zu schlagen. Es wird zudem universell unterstützt, das heißt, praktisch jede Programmierumgebung, von eingebettetem C auf einem Mikrocontroller bis hin zu Python auf einem Raspberry Pi, verfügt über TCP/IP-Bibliotheken.

Die Kosten sind ebenfalls klar. Die Zuverlässigkeit von TCP entsteht durch Overhead. Der Verbindungsaufbau erfordert einen Drei-Wege-Handshake. Das Aufrechterhalten der Verbindung erfordert periodische Keep-alive-Pakete. Jedes Segment trägt Header, die die Datenkosten erhöhen. Auf stark eingeschränkten Geräten mit wenig RAM oder bei Mobilfunkverbindungen, die nach Kilobyte abgerechnet werden, fällt dieser Overhead ins Gewicht. TCP hält außerdem eine dauerhafte Verbindung offen, was im Widerspruch zu den Schlaf-Wach-Zyklen steht, die bei stromsparenden Geräten die Batterielaufzeit verlängern.

Am besten geeignet für: Zuverlässige Datenübertragung bei kritischen Anwendungen, Middleware- und Gateway-Geräte, Systeme, die eine Zwei-Wege-Kommunikation mit Zustellungsgarantie benötigen.

HTTPS: der Webstandard für sichere IoT-Daten

HTTPS ist HTTP (HyperText Transfer Protocol) über TLS (Transport Layer Security), das wiederum über TCP/IP läuft. Es ist dasselbe Protokoll, das Ihr Browser jedes Mal verwendet, wenn Sie eine sichere Website besuchen, und es hat sich zu einer beliebten Wahl für IoT-Geräte entwickelt, um Daten an Cloud-APIs zu senden.

Der Reiz von HTTPS im IoT liegt in seiner Universalität und Einfachheit. Jede Cloud-Plattform, einschließlich TagoIO, stellt eine REST-API über HTTPS bereit. Daten zu senden ist so einfach wie ein HTTP-POST-Request mit einem JSON-Payload. Bibliotheken gibt es für praktisch jede Sprache und jedes Mikrocontroller-Framework, darunter Arduinos HTTPClient und den integrierten Wi-Fi-Stack des ESP32. Die Authentifizierung erfolgt über Token-Header, und TLS liefert von Haus aus eine durchgehende Verschlüsselung, die die meisten Sicherheitsanforderungen von Unternehmen ohne eigene Implementierung erfüllt.

Die Herausforderung besteht darin, dass HTTPS das schwerste der gängigen IoT-Protokolle ist. TLS-Handshakes sind rechenintensiv und speicherhungrig, oft zu viel für sehr kleine Mikrocontroller. Jeder Request-Response-Zyklus öffnet eine Verbindung, handelt TLS aus, sendet Daten, empfängt eine Antwort und schließt die Verbindung. Für ein Gerät, das einen Messwert pro Minute sendet, ist dieser Zyklus akzeptabel. Für ein Gerät, das Dutzende Messwerte pro Sekunde sendet oder auf einem winzigen 8-Bit-Mikrocontroller mit 2 KB RAM läuft, wird HTTPS schnell unpraktikabel. Auch der Stromverbrauch ist deutlich höher als bei UDP oder MQTT, weil das Funkmodul während des gesamten Request-Response-Zyklus aktiv bleiben muss.

Um das Gewicht von HTTPS konkret zu veranschaulichen: Ein typischer HTTP/JSON-Payload, der einen einzelnen Sensormesswert trägt, umfasst rund 487 Byte, wenn man Header, JSON-Struktur und Authentifizierungsfelder einbezieht. Für ein Gerät, das über eine eingeschränkte Mobilfunkverbindung sendet, summiert sich dieser Overhead schnell.

Am besten geeignet für: Cloud-vernetzte Wi-Fi- oder Mobilfunkgeräte mit ausreichend Speicher, REST-API-Integrationen, sicherer Daten-Upload von Gateways und Edge-Geräten.

MQTT: der Industriestandard für das IoT

MQTT (Message Queuing Telemetry Transport) wurde von Grund auf für das IoT entwickelt. Ursprünglich Ende der 1990er-Jahre konzipiert, um Ölpipelines über Satellitenverbindungen zu überwachen, hat es sich zu einem der am weitesten verbreiteten Messaging-Protokolle der Branche entwickelt.

MQTT nutzt ein Publish/Subscribe-Modell, das über einen zentralen Broker vermittelt wird. Geräte veröffentlichen Nachrichten zu Topics (etwa factory/machine1/temperature), und Abonnenten wie Dashboards, Analyse-Engines oder andere Geräte erhalten diese Nachrichten, indem sie die entsprechenden Topics abonnieren. Gerät und Dashboard kommunizieren nie direkt miteinander; der Broker übernimmt das gesamte Routing.

Die Stärken von MQTT sind zahlreich. Es ist leichtgewichtig und effizient, mit einem minimalen Paket-Overhead von nur 2 Byte. Es unterstützt drei Quality-of-Service-Stufen (QoS): QoS 0 ohne Empfangsbestätigung, QoS 1 für die mindestens einmalige Zustellung und QoS 2 für die genau einmalige Zustellung. Diese Flexibilität erlaubt es, das Protokoll an die Zuverlässigkeitsanforderungen Ihrer Anwendung anzupassen. MQTT unterstützt außerdem persistente Sessions, sodass ein Broker Nachrichten für ein vorübergehend offline gegangenes Gerät zwischenspeichern kann, etwas, das weder UDP noch reines HTTPS nativ können.

TagoIO bietet einige Optionen für einen dedizierten MQTT-Broker. Geräte veröffentlichen Daten, der Live Inspector der Plattform zeigt sie in Echtzeit beim Eintreffen, und Actions können sie automatisch verarbeiten und speichern, ohne zusätzliche eigene Middleware.

Die Grenzen von MQTT betreffen vor allem den Verbindungs-Overhead. MQTT läuft über TCP, was bedeutet, dass eine dauerhafte Verbindung aufrechterhalten werden muss. Bei Geräten, die zwischen den Messungen tief schlafen, um Batterie zu sparen, erhöht der Aufbau einer TCP-Verbindung bei jedem Aufwachen Latenz und Stromverbrauch. Der Broker stellt zudem einen Single Point of Failure dar, sofern Sie kein Clustering oder keine Redundanz umsetzen.

Am besten geeignet für: Echtzeit-Telemetrie, Flottenmanagement, bidirektionale Gerätekommunikation, Anwendungen, die Nachrichtenpersistenz und QoS-Garantien benötigen.

TagoTiP: ein gemeinsames Frame-Format für UDP, TCP/IP, HTTPS und MQTT

Jedes der oben besprochenen Protokolle löst das Transportproblem, also wie Bytes vom Gerät zum Server gelangen. Doch keines davon beantwortet eine andere, ebenso praktische Frage: Wie sollen diese Bytes eigentlich aussehen? Entwickler, die ein kleines Board mit TagoIO verbinden, müssen weiterhin entscheiden, wie sie ihre Daten strukturieren, wie sie sich authentifizieren, wie sie Variablennamen, Werte, Einheiten und Zeitstempel kodieren und wie sie all das so umsetzen, dass die Plattform es parsen kann. Diese Implementierungsarbeit wird in der Regel bei jedem neuen Projekt von Grund auf neu erledigt.

Genau dieses Problem soll TagoTiP lösen.

TagoTiP (Transport IoT Protocol) ist ein neues offenes Frame-Format und eine Protokollspezifikation von TagoIO, veröffentlicht unter github.com/tago-io/tagotip unter der Apache-2.0-Lizenz. Es ist keine Alternative zu UDP, TCP/IP, HTTPS oder MQTT, sondern arbeitet auf all diesen Protokollen auf. Derselbe TagoTiP-Frame lässt sich über UDP für die am stärksten eingeschränkten Geräte senden, über TCP für Zuverlässigkeit, über HTTPS für Umgebungen, in denen nur Port 443 offen ist, oder als MQTT-Payload für Publish/Subscribe-Einsätze. Entwickler wählen den Transport, der zu ihrer Hardware und ihrem Netzwerk passt; TagoTiP kümmert sich um die Datenstruktur.

Der praktische Nutzen für kleine Boards wie Arduino, ESP8266 und ESP32 ist erheblich: Statt JSON-Payloads von Hand zu erstellen, HTTP-Header zu verwalten oder eigene binäre Encoder zu bauen, schreibt ein Entwickler eine einzige kompakte Zeile und sendet sie. TagoIO parst sie auf der Gegenseite nativ.

Ein menschenlesbarer, kompakter Frame

Ein TagoTiP-Frame ist reiner Text, strukturiert und ohne jedes Werkzeug lesbar:

PUSH|4deedd7bab8817ec|sensor-01|[temperature:=32.5#C;humidity:=65#%]

Aufgeschlüsselt: PUSH ist die Methode, 4deedd7bab8817ec ist der Authorization Hash (die ersten 8 Byte des SHA-256 des Geräte-Tokens), sensor-01 ist die Seriennummer des Geräts, und der Payload in eckigen Klammern enthält zwei durch Semikolons getrennte Variablen. Der gesamte Frame umfasst etwa 112 Byte, verglichen mit rund 487 Byte für eine gleichwertige HTTP/JSON-Anfrage, womit TagoTiP für dieselben Daten etwa 4,3-mal kleiner ist.

Reichhaltige Variablen-Metadaten in einem einzigen Ausdruck

Jede Variable unterstützt optionale Suffixe für Einheit (#), Zeitstempel (@), Gruppe (^) und Metadaten ({}), alle in einem kompakten Ausdruck:

temperature:=32.5#C@1694567890000^reading_001{source=dht22,quality=high}

Das bedeutet: Eine einzige Zeile trägt alles, was TagoIO benötigt, um einen gut annotierten Datenpunkt zu speichern, also Variablenname, Wert, Einheit, Zeitstempel, Gruppe und Metadaten, ganz ohne JSON-Verschachtelung oder ein eigenes Schema.

Protokollmethoden

TagoTiP definiert vier Methoden, die den gesamten Kommunikationszyklus zwischen Gerät und Plattform abdecken, unabhängig davon, welcher Transport darunter zum Einsatz kommt:

Passthrough-Payloads

Für Geräte, die bereits binäre Payloads erzeugen, unterstützt TagoTiP Hex- und Base64-Passthrough und leitet rohe Bytes direkt an den Payload-Parser eines Geräts in TagoIO weiter:

PUSH|AUTH|SERIAL|>xDEADBEEF01020304

PUSH|AUTH|SERIAL|>b3q2+7wECAwQ=

Damit ist TagoTiP nicht nur für neue Firmware nützlich, sondern auch als leichtgewichtige Hülle für bestehende Geräte, die über einen der unterstützten Transporte bereits strukturierte Binärdaten erzeugen.

TagoTiP/S: Sicherheit für Verbindungen ohne TLS

Für Umgebungen, in denen TLS nicht verfügbar oder rechnerisch zu teuer ist, etwa LoRa, Sigfox, NB-IoT oder rohes UDP, enthält TagoTiP eine sichere Variante namens TagoTiP/S. Sie verpackt TagoTiP-Frames in einen binären, AEAD-verschlüsselten Umschlag und sorgt so für starke Vertraulichkeit und Integrität ohne TLS-Handshake.

TagoTiP/S unterstützt mehrere Cipher Suites, vom verpflichtenden AES-128-CCM bis hin zu AES-256-GCM und ChaCha20-Poly1305. Selbst mit aktivierter Verschlüsselung umfasst der resultierende Payload nur etwa 119 Byte, 4,1-mal kleiner als HTTP/JSON, mit lediglich 29 Byte Umschlag-Overhead bei CCM-basierten Ciphern.

Größenvergleich auf einen Blick

Warum das für Arduino, ESP und kleine Boards wichtig ist

Das Frame-Format wurde ausdrücklich C-freundlich entworfen, mit linearem Parsing, vorhersehbaren Puffergrößen und minimaler String-Verarbeitung, sodass es sich auf 8-Bit-AVR-Mikrocontrollern und aufwärts praktisch umsetzen lässt. Boards mit begrenztem Flash und RAM können die TagoIO-Konnektivität in nur wenigen Codezeilen umsetzen und denselben kompakten Frame über den jeweils von ihrer Hardware unterstützten Transport senden. Die Wahl des Transports bleibt in der Hand des Entwicklers; TagoTiP übernimmt die Datenstruktur, die hindurchgeht.

Das richtige Protokoll wählen: ein praxisnaher Leitfaden

Kein einzelner Transport ist die beste Wahl für jede IoT-Anwendung. Die richtige Wahl hängt von den Einschränkungen Ihres Geräts, Ihrem Netzwerk, Ihren Zuverlässigkeitsanforderungen und Ihrem Entwicklungszeitplan ab.

Unabhängig davon, welchen Transport Sie wählen, gibt Ihnen TagoTiP ein einheitliches, kompaktes und nativ unterstütztes Datenformat, das Sie über jeden davon transportieren können. Ein Entwickler, der mit einem Arduino oder ESP8266 arbeitet, kann einen TagoTiP-Frame schreiben und ihn über UDP für minimalen Overhead, über TCP für Zuverlässigkeit, über HTTPS, wenn nur Port 443 verfügbar ist, oder als MQTT-Payload für Publish/Subscribe-Einsätze senden: dieselben strukturierten Daten, dasselbe Parsing in TagoIO, unabhängig vom Weg. Die vollständige offene Spezifikation finden Sie unter github.com/tago-io/tagotip.

Zum Transport selbst: Wenn Ihr Gerät maximale Geschwindigkeit und minimalen Overhead braucht und gelegentlichen Paketverlust verkraften kann, ist UDP die natürliche Wahl, und TagoTiP über UDP ist der effizienteste Weg zu TagoIO für eingeschränkte Hardware. Wenn Sie für kritische Daten eine garantierte, geordnete Zustellung benötigen, liefert TCP/IP diese Zuverlässigkeit. Wenn Sicherheit und universelle Kompatibilität am wichtigsten sind und Ihr Gerät die Ressourcen für TLS hat, gibt Ihnen HTTPS die einfachste REST-API-Integration. Und wenn Sie über eine große Flotte hinweg bidirektionale Kommunikation, Nachrichtenpersistenz und QoS-Garantien benötigen, bleibt MQTT der bewährte Industriestandard.

Schlussgedanken

Die Vielfalt der IoT-Konnektivitätsprotokolle spiegelt die Vielfalt der IoT-Anwendungen selbst wider. Ein Sensor, der tief in einem entlegenen Feld in einer Pipeline steckt, hat völlig andere Anforderungen als ein Gateway-Server, der Daten von Hunderten Geräten in einer Fabrik zusammenführt. Die Kompromisse jedes Protokolls zu verstehen, also Overhead, Zuverlässigkeit, Stromverbrauch, Sicherheit und Entwicklungskomplexität, ist entscheidend, um IoT-Lösungen zu bauen, die in der realen Welt funktionieren.

TagoTiP fügt sich in dieses Umfeld ein, nicht indem es einen dieser Transporte ersetzt, sondern indem es die Schicht darüber löst: die Datenstruktur. Statt dass jeder Entwickler neu erfindet, wie Variablen, Einheiten, Zeitstempel und Authentifizierung in den gerade verwendeten Transport kodiert werden, definiert TagoTiP ein einziges kompaktes, menschenlesbares und typsicheres Format, das über alle hinweg funktioniert. Für kleine Boards wie Arduino, ESP8266 und ESP32 bedeutet das weniger Code, weniger Fehler und einen einheitlichen Weg zu TagoIO, unabhängig davon, wie die Bytes reisen.

Um die vollständige offene Spezifikation, die Protokollgrammatik und die Implementierungsdetails zu erkunden, besuchen Sie das TagoTiP-GitHub-Repository unter github.com/tago-io/tagotip.