Cómo elegir un protocolo de transporte para IoT: UDP, TCP/IP, HTTPS, MQTT y el papel de TagoTiP

Todo proyecto de IoT empieza con la misma pregunta fundamental: ¿cómo habla mi dispositivo con la nube? Los sensores, actuadores y microcontroladores generan datos que solo cobran valor cuando llegan a una plataforma donde se pueden almacenar, visualizar y usar para tomar decisiones. Pero llevar los datos de un dispositivo a la nube no es solo un detalle técnico: el protocolo que elijas afectará directamente a la duración de la batería de tu dispositivo, a los costos de datos, a la fiabilidad, a la complejidad y a la escalabilidad.

En este artículo recorreremos los protocolos de conectividad más habituales en IoT (UDP, TCP/IP, HTTPS y MQTT) y luego presentaremos TagoTiP (Transport IoT Protocol), un nuevo protocolo abierto desarrollado por TagoIO y pensado específicamente para dispositivos con recursos limitados como Arduino, ESP8266, ESP32 y cualquier otra placa IoT pequeña que necesite llegar a la nube de la forma más eficiente posible.

UDP: rápido, ligero y de tipo “dispara y olvida”

UDP (User Datagram Protocol) es uno de los protocolos de transporte más básicos en redes. Envía paquetes de datos sin establecer primero una conexión y sin ninguna confirmación de que los datos se recibieron.

Piensa en UDP como dejar una postal en un buzón. La envías y sigues con lo tuyo: no hay forma de saber si realmente llegó.

Las ventajas de UDP son notables para aplicaciones de IoT donde la velocidad y el bajo consumo importan más que la entrega garantizada. Como no hay handshake ni proceso de confirmación, UDP es extremadamente rápido y casi no impone carga sobre el dispositivo. Los paquetes son pequeños y el dispositivo puede volver a dormir casi de inmediato después de transmitir. Esto hace que UDP encaje muy bien con dispositivos alimentados por batería, despliegues NB-IoT y escenarios donde la pérdida ocasional de paquetes es aceptable, como el envío de lecturas periódicas de sensores en los que perder un valor de cada cien no es un problema.

Las desventajas también son reales. UDP no ofrece ninguna garantía de entrega. Los paquetes se pueden descartar en la red, llegar fuera de orden o duplicarse, y el emisor nunca lo sabrá. Tampoco hay seguridad integrada, ni gestión de sesiones, ni soporte nativo para la comunicación bidireccional. Implementar fiabilidad sobre UDP requiere lógica personalizada a nivel de aplicación, lo que añade complejidad de desarrollo.

Ideal para: telemetría de alta frecuencia, dispositivos con recursos limitados en redes de bajo consumo, aplicaciones donde la velocidad importa más que la entrega garantizada.

TCP/IP: comunicación fiable orientada a la conexión

TCP (Transmission Control Protocol), siempre acompañado de IP (Internet Protocol), es la columna vertebral de internet. A diferencia de UDP, TCP establece una conexión entre el dispositivo y el servidor antes de intercambiar cualquier dato, rastrea cada paquete, retransmite los que se pierden y garantiza que los datos lleguen en orden.

Si UDP es una postal, TCP es una carta certificada con acuse de recibo.

Las fortalezas de TCP/IP son evidentes: obtienes entrega garantizada, transmisión ordenada y comprobación de errores integrada. Para casos de uso de IoT donde la integridad de los datos es crítica (sistemas de control industrial, dispositivos médicos, telemetría financiera) TCP/IP es difícil de superar. También tiene soporte universal, lo que significa que prácticamente cualquier entorno de programación, desde C embebido en un microcontrolador hasta Python en una Raspberry Pi, dispone de bibliotecas TCP/IP.

Los costos también están claros. La fiabilidad de TCP viene de la sobrecarga. Establecer una conexión requiere un handshake de tres pasos. Mantener la conexión viva requiere paquetes keep-alive periódicos. Cada segmento lleva cabeceras que aumentan los costos de datos. En dispositivos muy limitados con poca RAM o en conexiones celulares facturadas por kilobyte, esa sobrecarga importa. TCP también mantiene abierta una conexión persistente, lo que choca con los ciclos de dormir y despertar que prolongan la batería en dispositivos de bajo consumo.

Ideal para: transmisión fiable de datos en aplicaciones críticas, dispositivos middleware y gateway, sistemas que requieren comunicación bidireccional con garantías de entrega.

HTTPS: el estándar web para datos seguros de IoT

HTTPS es HTTP (HyperText Transfer Protocol) sobre TLS (Transport Layer Security), que a su vez corre sobre TCP/IP. Es el mismo protocolo que usa tu navegador cada vez que visitas un sitio web seguro, y se ha convertido en una opción popular para que los dispositivos IoT envíen datos a las API de la nube.

El atractivo de HTTPS en IoT está en su universalidad y simplicidad. Toda plataforma en la nube, incluida TagoIO, expone una API REST sobre HTTPS. Enviar datos es tan sencillo como hacer una petición HTTP POST con un payload JSON. Existen bibliotecas para casi todos los lenguajes y frameworks de microcontroladores, incluidos el HTTPClient de Arduino y la pila Wi-Fi integrada del ESP32. La autenticación se gestiona mediante cabeceras con tokens, y TLS ofrece cifrado de extremo a extremo de fábrica, lo que satisface la mayoría de los requisitos de seguridad empresarial sin necesidad de implementación personalizada.

El reto es que HTTPS es el más pesado de los protocolos de IoT habituales. Los handshakes de TLS son costosos en cómputo y exigentes en memoria, a menudo demasiado para microcontroladores muy pequeños. Cada ciclo de petición y respuesta abre una conexión, negocia TLS, envía datos, recibe una respuesta y cierra la conexión. Para un dispositivo que envía una lectura por minuto, este ciclo es aceptable. Para un dispositivo que envía decenas de lecturas por segundo, o que corre en un diminuto microcontrolador de 8 bits con 2KB de RAM, HTTPS se vuelve rápidamente poco práctico. El consumo de energía también es bastante mayor que el de UDP o MQTT, debido al tiempo que la radio debe permanecer activa durante todo el ciclo de petición y respuesta.

Para ilustrar el peso de HTTPS en términos concretos: un payload HTTP/JSON típico que transporta una lectura de sensor ronda los 487 bytes una vez que incluyes cabeceras, estructura JSON y campos de autenticación. Para un dispositivo que transmite por un enlace celular limitado, esa sobrecarga se acumula rápido.

Ideal para: dispositivos Wi-Fi o celulares conectados a la nube con suficiente memoria, integraciones con API REST, carga segura de datos desde gateways y dispositivos edge.

MQTT: el estándar de la industria IoT

MQTT (Message Queuing Telemetry Transport) se diseñó desde cero para IoT. Creado originalmente a finales de los años noventa para monitorear oleoductos sobre conexiones satelitales, ha evolucionado hasta convertirse en uno de los protocolos de mensajería más adoptados de la industria.

MQTT usa un modelo de publicación y suscripción mediado por un broker central. Los dispositivos publican mensajes en topics (como factory/machine1/temperature), y los suscriptores (dashboards, motores de análisis u otros dispositivos) reciben esos mensajes al suscribirse a los topics correspondientes. El dispositivo y el dashboard nunca se comunican directamente; el broker gestiona todo el enrutamiento.

Las fortalezas de MQTT son numerosas. Es ligero y eficiente, con una sobrecarga mínima de paquete de apenas 2 bytes. Soporta tres niveles de Calidad de Servicio (QoS): QoS 0 para “dispara y olvida”, QoS 1 para entrega al menos una vez y QoS 2 para entrega exactamente una vez. Esta flexibilidad te permite ajustar el protocolo a los requisitos de fiabilidad de tu aplicación. MQTT también admite sesiones persistentes, de modo que un broker puede encolar mensajes para un dispositivo que estuvo temporalmente desconectado, algo que ni UDP ni HTTPS puro pueden hacer de forma nativa.

TagoIO ofrece varias opciones de broker MQTT dedicado. Los dispositivos publican datos, el Live Inspector de la plataforma los muestra llegando en tiempo real, y las Actions pueden procesarlos y almacenarlos automáticamente, sin necesidad de middleware personalizado adicional.

Las limitaciones de MQTT tienen que ver sobre todo con la sobrecarga de conexión. MQTT corre sobre TCP, lo que implica mantener una conexión persistente. Para dispositivos que duermen profundamente entre lecturas para ahorrar batería, establecer una conexión TCP en cada despertar añade latencia y consumo. El broker también representa un único punto de fallo a menos que implementes clustering o redundancia.

Ideal para: telemetría en tiempo real, gestión de flotas, comunicación bidireccional de dispositivos, aplicaciones que requieren persistencia de mensajes y garantías de QoS.

TagoTiP: un formato de trama común para UDP, TCP/IP, HTTPS y MQTT

Cada uno de los protocolos comentados arriba resuelve el problema del transporte (cómo viajan los bytes del dispositivo al servidor), pero ninguno responde a otra pregunta distinta e igual de práctica: ¿qué aspecto deben tener realmente esos bytes? Los desarrolladores que conectan una placa pequeña a TagoIO todavía tienen que decidir cómo estructurar sus datos, cómo autenticarse, cómo codificar nombres de variables, valores, unidades y marcas de tiempo, y cómo hacer todo eso de una forma que la plataforma pueda interpretar. Ese trabajo de implementación suele reconstruirse desde cero en cada proyecto nuevo.

Este es el problema que TagoTiP fue diseñado para resolver.

TagoTiP (Transport IoT Protocol) es un nuevo formato de trama abierto y una especificación de protocolo desarrollados por TagoIO, publicados en github.com/tago-io/tagotip bajo la licencia Apache 2.0. No es una alternativa a UDP, TCP/IP, HTTPS o MQTT: funciona sobre todos ellos. La misma trama TagoTiP se puede enviar por UDP para los dispositivos más limitados, por TCP para mayor fiabilidad, por HTTPS en entornos donde solo el puerto 443 está abierto, o como un payload MQTT para despliegues de publicación y suscripción. Los desarrolladores eligen el transporte que encaja con su hardware y su red; TagoTiP se ocupa de la estructura de los datos.

El beneficio práctico para placas pequeñas como Arduino, ESP8266 y ESP32 es importante: en lugar de armar a mano payloads JSON, gestionar cabeceras HTTP o construir codificadores binarios personalizados, el desarrollador escribe una sola línea compacta y la envía. TagoIO la interpreta de forma nativa en el otro extremo.

Una trama compacta y legible por humanos

Una trama TagoTiP es texto plano, estructurado y legible sin ninguna herramienta:

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

Desglosándola: PUSH es el método, 4deedd7bab8817ec es el Authorization Hash (los primeros 8 bytes del SHA-256 del token del dispositivo), sensor-01 es el identificador de serie del dispositivo, y el payload entre corchetes contiene dos variables separadas por puntos y coma. La trama completa ocupa aproximadamente 112 bytes, frente a unos 487 bytes de una petición HTTP/JSON equivalente, lo que hace que TagoTiP sea unas 4.3 veces más pequeño para los mismos datos.

Metadatos de variables ricos en una sola expresión

Cada variable admite sufijos opcionales para la unidad (#), la marca de tiempo (@), el grupo (^) y los metadatos ({}), todo en una expresión compacta:

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

Esto significa que una sola línea transporta todo lo que TagoIO necesita para almacenar un punto de datos bien anotado: nombre de la variable, valor, unidad, marca de tiempo, grupo y metadatos, sin anidamiento JSON ni un esquema personalizado.

Métodos del protocolo

TagoTiP define cuatro métodos que cubren todo el ciclo de comunicación entre el dispositivo y la plataforma, sin importar qué transporte se use por debajo:

Payloads de paso directo

Para dispositivos que ya producen payloads binarios, TagoTiP admite paso directo en hex y base64, enrutando los bytes en crudo directamente al payload parser del dispositivo en TagoIO:

PUSH|AUTH|SERIAL|>xDEADBEEF01020304

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

Esto hace que TagoTiP sea útil no solo para firmware nuevo, sino también como un envoltorio ligero para dispositivos existentes que ya generan datos binarios estructurados sobre cualquiera de los transportes admitidos.

TagoTiP/S: seguridad para enlaces sin TLS

Para entornos donde TLS no está disponible o resulta demasiado costoso en cómputo (LoRa, Sigfox, NB-IoT, UDP en crudo), TagoTiP incluye una variante segura llamada TagoTiP/S. Envuelve las tramas TagoTiP en un sobre binario cifrado con AEAD, ofreciendo fuerte confidencialidad e integridad sin un handshake de TLS.

TagoTiP/S admite varias suites de cifrado, desde la obligatoria AES-128-CCM hasta AES-256-GCM y ChaCha20-Poly1305. Incluso con el cifrado activado, el payload resultante es de apenas unos 119 bytes, 4.1 veces más pequeño que HTTP/JSON, con solo 29 bytes de sobrecarga de sobre para los cifrados basados en CCM.

Comparación de tamaños de un vistazo

Por qué esto importa para Arduino, ESP y placas pequeñas

El formato de trama se diseñó explícitamente para ser amigable con C: parsing lineal, tamaños de buffer predecibles, manejo mínimo de cadenas, lo que lo hace práctico de implementar en microcontroladores AVR de 8 bits y superiores. Placas con flash y RAM limitadas pueden implementar la conectividad con TagoIO en apenas unas pocas líneas de código, enviando la misma trama compacta sobre el transporte que su hardware admita. La elección del transporte queda en manos del desarrollador; TagoTiP se encarga de la estructura de datos que viaja por él.

Cómo elegir el protocolo adecuado: una guía práctica

Ningún transporte por sí solo es la mejor opción para toda aplicación de IoT. La elección correcta depende de las limitaciones de tu dispositivo, de tu red, de tus requisitos de fiabilidad y de tu cronograma de desarrollo.

Sin importar qué transporte elijas, TagoTiP te da un formato de datos consistente, compacto y con soporte nativo para transportarlo sobre cualquiera de ellos. Un desarrollador que trabaja con un Arduino o un ESP8266 puede escribir una sola trama TagoTiP y enviarla por UDP para mínima sobrecarga, por TCP para mayor fiabilidad, por HTTPS si solo el puerto 443 está disponible, o como un payload MQTT para despliegues de publicación y suscripción: los mismos datos estructurados, el mismo parsing de TagoIO, sin importar la ruta. La especificación abierta completa está en github.com/tago-io/tagotip.

En cuanto al transporte en sí: si tu dispositivo necesita máxima velocidad y mínima sobrecarga y puede tolerar la pérdida ocasional de paquetes, UDP es la opción natural, y TagoTiP sobre UDP es la ruta más eficiente hacia TagoIO para hardware limitado. Si necesitas entrega garantizada y ordenada para datos críticos, TCP/IP ofrece esa fiabilidad. Si lo que más importa es la seguridad y la compatibilidad universal, y tu dispositivo tiene los recursos para manejar TLS, HTTPS te da la integración más sencilla con una API REST. Y si necesitas comunicación bidireccional, persistencia de mensajes y garantías de QoS en una flota grande, MQTT sigue siendo el estándar probado de la industria.

Reflexiones finales

La diversidad de protocolos de conectividad de IoT refleja la diversidad de las propias aplicaciones de IoT. Un sensor embebido en un oleoducto en medio de un campo remoto tiene necesidades completamente distintas a las de un servidor gateway que agrega datos de cientos de dispositivos en una fábrica. Entender los compromisos de cada protocolo (sobrecarga, fiabilidad, energía, seguridad y complejidad para el desarrollador) es esencial para construir soluciones de IoT que funcionen en el mundo real.

TagoTiP encaja en este panorama no reemplazando ninguno de estos transportes, sino resolviendo la capa que está por encima de ellos: la estructura de los datos. En lugar de que cada desarrollador reinvente cómo codificar variables, unidades, marcas de tiempo y autenticación en el transporte que le toque usar, TagoTiP define un único formato compacto, legible por humanos y con seguridad de tipos que funciona en todos ellos. Para placas pequeñas como Arduino, ESP8266 y ESP32, esto significa menos código, menos errores y una ruta consistente hacia TagoIO sin importar cómo viajen los bytes.

Para conocer la especificación abierta completa, la gramática del protocolo y los detalles de implementación, visita el repositorio de TagoTiP en GitHub en github.com/tago-io/tagotip.