Choosing an IoT Transport Protocol: UDP, TCP/IP, HTTPS, MQTT, and the Role of TagoTiP

Every IoT project starts with the same fundamental question: how does my device talk to the cloud? Sensors, actuators, and microcontrollers generate data that only becomes valuable once it reaches a platform where it can be stored, visualized, and acted upon. But getting data from a device to the cloud isn't just a technical detail — the protocol you choose will directly impact your device's battery life, data costs, reliability, complexity, and scalability.

In this post, we'll walk through the most common connectivity protocols used in IoT — UDP, TCP/IP, HTTPS, and MQTT — and then introduce TagoTiP (Transport IoT Protocol), a new open protocol developed by TagoIO specifically designed for resource-constrained devices like the Arduino, ESP8266, ESP32, and any other small IoT board that needs to reach the cloud as efficiently as possible.

UDP — Fast, Lightweight, Fire-and-Forget

UDP (User Datagram Protocol) is one of the most fundamental transport protocols in networking. It sends packets of data without first establishing a connection and without any acknowledgment that data was received.

Think of UDP like dropping a postcard in a mailbox. You send it and move on — there's no way to know if it actually arrived.

The advantages of UDP are significant for IoT applications where speed and low overhead matter more than guaranteed delivery. Because there is no handshaking or acknowledgment process, UDP is extremely fast and imposes almost no overhead on the device. Packets are small, and the device can go back to sleep almost immediately after transmitting. This makes UDP particularly well-suited for battery-powered devices, NB-IoT deployments, and scenarios where occasional packet loss is acceptable — such as sending periodic sensor readings where missing one value out of a hundred is not a problem.

The downsides are real too. UDP provides no delivery guarantee whatsoever. Packets can be dropped by the network, arrive out of order, or be duplicated, and the sender will never know. There's also no built-in security, no session management, and no native support for two-way communication. Implementing reliability on top of UDP requires custom application-level logic, which adds development complexity.

Best for: High-frequency telemetry, constrained devices on low-power networks, applications where speed matters more than guaranteed delivery.

TCP/IP — Reliable, Connection-Oriented Communication

TCP (Transmission Control Protocol), always paired with IP (Internet Protocol), is the backbone of the internet. Unlike UDP, TCP establishes a connection between device and server before any data is exchanged, tracks every packet, retransmits lost ones, and ensures data arrives in order.

If UDP is a postcard, TCP is a registered letter with a return receipt.

The strengths of TCP/IP are obvious: you get guaranteed delivery, ordered transmission, and built-in error checking. For IoT use cases where data integrity is critical — industrial control systems, medical devices, financial telemetry — TCP/IP is hard to beat. It's also universally supported, meaning virtually every programming environment, from embedded C on a microcontroller to Python on a Raspberry Pi, has TCP/IP libraries available.

The costs are also clear. TCP's reliability comes from overhead. Establishing a connection requires a three-way handshake. Keeping the connection alive requires periodic keep-alive packets. Each segment carries headers that add to data costs. On heavily constrained devices with limited RAM or on cellular connections billed by kilobyte, this overhead matters. TCP also holds a persistent connection open, which conflicts with the sleep-and-wake duty cycles that extend battery life in low-power devices.

Best for: Reliable data transmission for critical applications, middleware and gateway devices, systems requiring two-way communication with delivery guarantees.

HTTPS — The Web Standard for Secure IoT Data

HTTPS is HTTP (HyperText Transfer Protocol) layered on top of TLS (Transport Layer Security), which itself runs over TCP/IP. It's the same protocol your browser uses every time you visit a secure website, and it has become a popular choice for IoT devices to push data to cloud APIs.

The appeal of HTTPS in IoT is its universality and simplicity. Every cloud platform, including TagoIO, exposes a REST API over HTTPS. Sending data is as straightforward as making an HTTP POST request with a JSON payload. Libraries exist for practically every language and microcontroller framework, including Arduino's HTTPClient and the ESP32's built-in Wi-Fi stack. Authentication is handled through token headers, and TLS provides end-to-end encryption out of the box, satisfying most enterprise security requirements without custom implementation.

The challenge is that HTTPS is the heaviest of the common IoT protocols. TLS handshakes are computationally expensive and memory-intensive — often too much for very small microcontrollers. Each request-response cycle opens a connection, negotiates TLS, sends data, receives a response, and closes the connection. For a device sending one reading per minute, this cycle is acceptable. For a device sending dozens of readings per second, or running on a tiny 8-bit microcontroller with 2KB of RAM, HTTPS quickly becomes impractical. Power consumption is also considerably higher than UDP or MQTT due to the time the radio must remain active during the full request-response cycle.

To illustrate the weight of HTTPS in real terms: a typical HTTP/JSON payload carrying one sensor reading is around 487 bytes once you include headers, JSON structure, and authentication fields. For a device transmitting over a constrained cellular link, that overhead adds up fast.

Best for: Cloud-connected Wi-Fi or cellular devices with sufficient memory, REST API integrations, secure data upload from gateways and edge devices.

MQTT — The IoT Industry Standard

MQTT (Message Queuing Telemetry Transport) was designed from the ground up for IoT. Originally developed in the late 1990s to monitor oil pipelines over satellite connections, it has evolved into one of the most widely adopted messaging protocols in the industry.

MQTT uses a publish/subscribe model mediated by a central broker. Devices publish messages to topics (such as factory/machine1/temperature), and subscribers — dashboards, analytics engines, or other devices — receive those messages by subscribing to the relevant topics. The device and the dashboard never communicate directly; the broker manages all routing.

MQTT's strengths are numerous. It is lightweight and efficient, with a minimum packet overhead of just 2 bytes. It supports three Quality of Service (QoS) levels: QoS 0 for fire-and-forget, QoS 1 for at-least-once delivery, and QoS 2 for exactly-once delivery. This flexibility lets you tune the protocol to your application's reliability requirements. MQTT also supports persistent sessions, so a broker can queue messages for a device that was temporarily offline — something neither UDP nor raw HTTPS can do natively.

TagoIO provides some options of a dedicated MQTT broker. Devices publish data, the platform's Live Inspector shows it arriving in real time, and Actions can automatically process and store it — no additional custom middleware required.

The limitations of MQTT are mostly about connection overhead. MQTT runs over TCP, which means maintaining a persistent connection. For devices that sleep deeply between readings to save battery, establishing a TCP connection on every wake-up adds latency and power draw. The broker also represents a single point of failure unless you implement clustering or redundancy.

Best for: Real-time telemetry, fleet management, bidirectional device communication, applications requiring message persistence and QoS guarantees.

TagoTiP — A Common Frame Format for UDP, TCP/IP, HTTPS, and MQTT

Each of the protocols discussed above solves the transport problem — how bytes get from device to server — but none of them answers a different, equally practical question: what should those bytes actually look like? Developers connecting a small board to TagoIO still need to decide how to structure their data, how to authenticate, how to encode variable names, values, units, and timestamps, and how to do all of that in a way the platform can parse. That implementation work typically gets rebuilt from scratch on every new project.

This is the problem TagoTiP was designed to solve.

TagoTiP (Transport IoT Protocol) is a new open frame format and protocol specification developed by TagoIO, published at github.com/tago-io/tagotip under the Apache 2.0 license. It is not an alternative to UDP, TCP/IP, HTTPS, or MQTT — it works on top of all of them. The same TagoTiP frame can be sent over UDP for the most constrained devices, over TCP for reliability, over HTTPS for environments where only port 443 is open, or as an MQTT payload for publish/subscribe deployments. Developers choose the transport that fits their hardware and network; TagoTiP handles the data structure.

The practical benefit for small boards like the Arduino, ESP8266, and ESP32 is significant: instead of hand-crafting JSON payloads, managing HTTP headers, or building custom binary encoders, a developer writes a single compact line and sends it. TagoIO parses it natively on the other end.

A Human-Readable, Compact Frame

A TagoTiP frame is plain text, structured and readable without any tooling:

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

Breaking this down: PUSH is the method, 4deedd7bab8817ec is the Authorization Hash (the first 8 bytes of the SHA-256 of the device token), sensor-01 is the device serial identifier, and the payload in brackets contains two variables separated by semicolons. The whole frame is approximately 112 bytes — compared to around 487 bytes for an equivalent HTTP/JSON request, making TagoTiP roughly 4.3x smaller for the same data.

Rich Variable Metadata in a Single Expression

Each variable supports optional suffixes for unit (#), timestamp (@), group (^), and metadata ({}), all in one compact expression:

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

This means a single line carries everything TagoIO needs to store a well-annotated data point — variable name, value, unit, timestamp, group, and metadata — without JSON nesting or a custom schema.

Protocol Methods

TagoTiP defines four methods that cover the full communication lifecycle between device and platform, regardless of which transport is used underneath:

Passthrough Payloads

For devices that already produce binary payloads, TagoTiP supports hex and base64 passthrough, routing raw bytes directly to a device's payload parser in TagoIO:

PUSH|AUTH|SERIAL|>xDEADBEEF01020304

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

This makes TagoTiP useful not only for new firmware, but as a lightweight wrapper for existing devices that already generate structured binary data over any of the supported transports.

TagoTiP/S — Security for Links Without TLS

For environments where TLS is unavailable or computationally too expensive — LoRa, Sigfox, NB-IoT, raw UDP — TagoTiP includes a secure variant called TagoTiP/S. It wraps TagoTiP frames in a binary AEAD-encrypted envelope, providing strong confidentiality and integrity without a TLS handshake.

TagoTiP/S supports multiple cipher suites, from the mandatory AES-128-CCM to AES-256-GCM and ChaCha20-Poly1305. Even with encryption enabled, the resulting payload is only about 119 bytes — 4.1x smaller than HTTP/JSON — with just 29 bytes of envelope overhead for CCM-based ciphers.

Size Comparison at a Glance

Why This Matters for Arduino, ESP, and Small Boards

The frame format was explicitly designed to be C-friendly — linear parsing, predictable buffer sizes, minimal string handling — making it practical to implement on 8-bit AVR microcontrollers and up. Boards with limited flash and RAM can implement TagoIO connectivity in just a few lines of code, sending the same compact frame over whichever transport their hardware supports. The choice of transport stays in the developer's hands; TagoTiP takes care of the data structure that goes through it.

Choosing the Right Protocol: A Practical Guide

No single transport is the best choice for every IoT application. The right choice depends on your device's constraints, your network, your reliability requirements, and your development timeline.

Regardless of which transport you choose, TagoTiP gives you a consistent, compact, and natively supported data format to carry over any of them. A developer working with an Arduino or ESP8266 can write one TagoTiP frame and send it over UDP for minimum overhead, over TCP for reliability, over HTTPS if only port 443 is available, or as an MQTT payload for publish/subscribe deployments — the same structured data, the same TagoIO parsing, regardless of the path. The full open specification is at github.com/tago-io/tagotip.

For the transport itself: if your device needs maximum speed and minimum overhead and can tolerate occasional packet loss, UDP is the natural fit — and TagoTiP over UDP is the most efficient path to TagoIO for constrained hardware. If you need guaranteed, ordered delivery for critical data, TCP/IP provides that reliability. If security and universal compatibility matter most and your device has the resources to handle TLS, HTTPS gives you the simplest REST API integration. And if you need bidirectional communication, message persistence, and QoS guarantees across a large fleet, MQTT remains the proven industry standard.

Final Thoughts

The diversity of IoT connectivity protocols reflects the diversity of IoT applications themselves. A sensor embedded in a pipeline deep in a remote field has completely different needs than a gateway server aggregating data from hundreds of devices in a factory. Understanding the tradeoffs of each protocol — overhead, reliability, power, security, and developer complexity — is essential to building IoT solutions that work in the real world.

TagoTiP fits into this landscape not by replacing any of these transports, but by solving the layer above them — the data structure. Instead of every developer re-inventing how to encode variables, units, timestamps, and authentication into whatever transport they happen to be using, TagoTiP defines a single compact, human-readable, type-safe format that works across all of them. For small boards like Arduino, ESP8266, and ESP32, this means less code, fewer bugs, and a consistent path to TagoIO regardless of how the bytes travel.

To explore the full open specification, protocol grammar, and implementation details, visit the TagoTiP GitHub repository at github.com/tago-io/tagotip.