TCP/IP para dispositivos

01 · Punto de partida

La base común de Internet

Los tres temas anteriores trataron radios: formas de llevar bits por el aire. Pero un dispositivo no habla con «el Wi-Fi»: habla con un servidor que puede estar en otro continente, atravesando docenas de redes de distinta tecnología. Lo que permite esa conversación es un conjunto de reglas común que no depende de la radio: la familia de protocolos de Internet, conocida por sus dos protagonistas, TCP e IP.

Como programador de aplicaciones, quizá nunca miraste esta capa: requests.get(url) o fetch la esconden. En un microcontrolador, en cambio, vas a manejarla más de cerca: elegir entre TCP y UDP, decidir cuántas conexiones abrir, poner tiempos máximos, entender por qué una consulta de nombres tarda y cuánta energía cuesta cada viaje. En IoT los detalles de la red son detalles de consumo.

Los fragmentos de C++ siguen el estilo Arduino para ESP32. Los tiempos y tamaños de las tablas son órdenes de magnitud para razonar.

02 · Capas

Las capas y quién hace qué

La comunicación se divide en capas, cada una con una tarea y apoyada en la inferior. Un mensaje de tu aplicación se va envolviendo en «sobres» a medida que baja, y se desenvuelve al subir del otro lado.

El esquema explica la división de responsabilidades. El enlace (Wi-Fi) lleva el paquete hasta el router. La capa IP lo hace avanzar router por router hasta el destino. El transporte (TCP o UDP) lo entrega al programa que lo espera. Y la aplicación (MQTT, HTTP) le da sentido. Cada capa ignora los detalles de las demás: por eso el mismo MQTT funciona sobre Wi-Fi, Ethernet o celular sin cambios.

03 · Identificar equipos

Direcciones, subredes y NAT

La dirección IP y la máscara

Una dirección IPv4 son cuatro números de 0 a 255 (32 bits), como 192.168.1.57. Se divide en dos partes: la que identifica la red y la que identifica al equipo dentro de esa red. La máscara de subred indica dónde está el corte: con 255.255.255.0 (o /24 en notación abreviada), los tres primeros números son la red y el último, el equipo. Esa red local admite 254 equipos.

La máscara le sirve al dispositivo para decidir si el destino está en su red (envía directo) o fuera (envía a la puerta de enlace, el router, para que lo haga avanzar). Los datos que obtiene del DHCP (tema 14) son justamente cuatro: su dirección, la máscara, la puerta de enlace y el servidor DNS.

Direcciones privadas y NAT

Hay rangos de direcciones reservados para uso interno que no se enrutan por Internet: 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16. Casi todas las redes domésticas y de oficina los usan. Para salir a Internet, el router hace NAT (traducción de direcciones): reemplaza la dirección privada del dispositivo por la pública del router, y recuerda a quién corresponde cada conversación para devolver las respuestas.

Esto tiene una consecuencia fundamental para IoT: desde afuera no se puede iniciar una conexión hacia un dispositivo que está detrás de un NAT. El router solo deja pasar las respuestas a conexiones que alguien de adentro abrió. Por eso, en la inmensa mayoría de los diseños, es el dispositivo el que inicia la conexión con el servidor, y mantiene esa conexión abierta si necesita recibir órdenes (como hace MQTT). La alternativa, abrir puertos en el router del cliente, es insegura, inviable para productos masivos y casi nunca se usa.

IPv6

Las direcciones IPv4 se agotaron. IPv6 usa 128 bits (2001:db8::1) y ofrece direcciones de sobra para que cada dispositivo tenga una pública, sin NAT. Los chips modernos lo soportan y las redes celulares lo usan cada vez más, pero la mayoría de las redes domésticas y de servicios todavía se apoyan en IPv4, y conviene que el firmware maneje ambas.

04 · Programas y nombres

Puertos y DNS

Una dirección IP identifica al equipo, pero en él corren varios programas a la vez. El puerto (un número de 0 a 65535) distingue a cuál va cada mensaje. Algunos son convenciones universales:

Una conexión queda definida por la dupla de direcciones y puertos de ambos extremos. El dispositivo, como cliente, usa un puerto de origen elegido al azar; el servidor escucha en un puerto conocido.

DNS: los nombres

Las personas usamos nombres (broker.ejemplo.com) y las redes usan direcciones. El DNS es la libreta de direcciones de Internet: el dispositivo le pregunta al servidor DNS (que obtuvo por DHCP) cuál es la dirección de un nombre y recibe la respuesta, junto con un TTL, el tiempo durante el cual puede recordarla. Cada resolución cuesta al menos un viaje de ida y vuelta, y si el servidor DNS falla, el nombre no se resuelve aunque el servidor de destino esté perfecto.

Para el IoT, los nombres tienen una virtud enorme: permiten mover el servidor a otra dirección sin tocar el firmware de los equipos instalados. Cuestan un viaje y un punto de falla más, por lo que conviene resolver una vez, guardar la dirección con su TTL y volver a resolver solo si la conexión falla. Es la optimización del tema 14.

05 · Transporte

TCP y UDP

La capa de transporte ofrece dos servicios muy distintos, y la elección condiciona todo el diseño del envío.

TCP da una comodidad enorme: el programador escribe bytes en un extremo y los lee, completos y en orden, en el otro, sin preocuparse por pérdidas. A cambio, abrir la conexión cuesta un viaje, mantenerla cuesta memoria y energía, y cuando la red es muy mala, la espera de las retransmisiones puede alargar mucho un envío. UDP es lo opuesto: casi sin costo, pero cada garantía que se necesite (confirmación, reintento, orden) la tiene que construir la aplicación. Protocolos como CoAP lo hacen con un esquema simple de confirmación y reintento.

Una regla de oro: si el mensaje es breve, independiente y puede repetirse sin problema, UDP es candidato; si hay una conversación, un flujo o datos que no pueden perderse sin enterarse, TCP. Y si hay que proteger la comunicación, TLS se suma sobre TCP (o DTLS sobre UDP) con su propio costo en viajes.

06 · Programar la red

Sockets desde el firmware

Un socket es la interfaz con la que un programa usa la red: un punto de conexión con una dirección y un puerto. Las operaciones son siempre las mismas en cualquier lenguaje: crear el socket, conectar (o enlazar, si se espera recibir), enviar y recibir, y cerrar. Un cliente TCP, que es lo que hace un dispositivo IoT, sigue estos pasos:

1. Resolver el nombre del servidor (si no se tiene la dirección).
2. Conectar a la dirección y el puerto. Aquí se produce el apretón de manos.
3. Enviar el pedido y leer la respuesta, con un tiempo máximo.
4. Cerrar la conexión o dejarla abierta para el próximo envío.

#include <WiFi.h>
#include <WiFiUdp.h>

const char *SERVIDOR = "datos.ejemplo.com";
const uint16_t PUERTO_TCP = 8080;
const uint16_t PUERTO_UDP = 5005;

// Envío por TCP: conectar, enviar, leer la respuesta y cerrar, con tiempos máximos.
bool enviarPorTcp(const String &mensaje) {
  WiFiClient cliente;
  if (!cliente.connect(SERVIDOR, PUERTO_TCP, 5000)) {     // resuelve el nombre y conecta; 5 s como máximo
    Serial.println("No conectó");
    return false;
  }
  cliente.setTimeout(3000);                                // 3 s como máximo para leer
  cliente.print(mensaje + "\n");
  String respuesta = cliente.readStringUntil('\n');        // espera hasta el fin de línea o el tiempo máximo
  cliente.stop();
  return respuesta == "OK";
}

// Envío por UDP: un datagrama, sin conexión.
void enviarPorUdp(const uint8_t *datos, size_t largo) {
  IPAddress ip;
  if (!WiFi.hostByName(SERVIDOR, ip)) return;              // resolver el nombre con DNS
  WiFiUDP udp;
  udp.beginPacket(ip, PUERTO_UDP);
  udp.write(datos, largo);
  udp.endPacket();                                         // sale el datagrama; nadie garantiza que llegue
}

Observá lo que el código hace por cuidado: cada operación que espera tiene un tiempo máximo. Sin ellos, un servidor caído deja al dispositivo colgado en el connect o en la lectura durante minutos, con la radio encendida. Y siempre se cierra el cliente al terminar: una conexión olvidada ocupa memoria que en un microcontrolador es muy escasa.

Dos modos de trabajar con sockets importan: el bloqueante, donde el programa se detiene hasta que la operación termina (simple, pero congela el resto), y el no bloqueante, donde se pregunta cada tanto si hay algo (más complejo, pero permite atender otras tareas). En un sistema con un sistema operativo de tiempo real, lo habitual es dedicar una tarea a la red y dejar que se bloquee ahí.

07 · El costo real

Cada viaje de ida y vuelta cuesta

La unidad de medida del costo de una comunicación no es el byte, sino el viaje de ida y vuelta (RTT, round-trip time): el tiempo que tarda un mensaje en llegar al destino y volver su respuesta. En una red Wi-Fi local es de unos 5 a 30 milisegundos; hasta un servidor en Internet, de 30 a 150; por una red celular, de 100 a 500; por satélite, unos 600 o más. Cada etapa que requiere una respuesta antes de seguir suma un RTT al tiempo y, con la radio encendida, al consumo.

El diagrama muestra que de los cinco viajes de un envío HTTPS completo con TLS 1.2, solo el último lleva el dato. Los otros cuatro son preparación: DNS, apertura de TCP y negociación del cifrado. Por eso las optimizaciones apuntan siempre en la misma dirección:

• Evitar el DNS guardando la dirección (un viaje menos).
• Reutilizar la conexión en lugar de abrir una nueva para cada envío (se ahorran TCP y TLS enteros, a costa de mantenerla viva).
• Usar TLS 1.3, que reduce el apretón de manos a un solo viaje, o reanudar sesiones TLS ya negociadas.
• Usar UDP cuando el mensaje lo permite, sin conexión que abrir.
• Agrupar los datos para hacer menos envíos con más contenido (tema 12).

Además de los viajes, el cifrado cuesta cálculo: en un microcontrolador, la verificación del certificado y el intercambio de claves pueden llevar de varias centenas de milisegundos a más de un segundo de procesador, con la radio y el chip encendidos. Y también cuesta bytes: el apretón de manos de TLS mueve varios kilobytes (sobre todo por los certificados) para entregar a veces solo veinte bytes útiles.

08 · Analogía con programación

Contar los viajes en Python

El programa modela cinco formas de enviar un mensaje de 20 bytes y cuenta, para cada una, los viajes de ida y vuelta: uno por el pedido y su respuesta, uno más si hay que resolver el nombre con DNS, uno de apretón de manos de TCP si se abre conexión, y uno o dos de TLS. A los viajes multiplicados por el RTT les suma el tiempo de cálculo del cifrado, y con la corriente del Wi-Fi (100 mA) obtiene la energía por envío. Al final usa el módulo estándar ipaddress para analizar una red local.

CORRIENTE_MA = 100        # corriente media con la radio Wi-Fi activa

# protocolo: (viajes de ida y vuelta de la conexión, milisegundos de cálculo de cifrado, bytes que viajan por la red)
PROTOCOLOS = {
    "UDP con confirmación":     (0, 0,   100),     # sin conexión: solo pedido y respuesta
    "TCP sin cifrar (HTTP)":    (1, 0,   1000),    # apretón de manos de TCP
    "TCP con TLS 1.2 (HTTPS)":  (3, 400, 5200),    # TCP (1) + TLS 1.2 (2)
    "TCP con TLS 1.3 (HTTPS)":  (2, 300, 4700),    # TCP (1) + TLS 1.3 (1)
    "Conexión TLS ya abierta":  (0, 0,   700),     # se reutiliza la conexión: solo pedido y respuesta
}
BYTES_DNS = 170           # consulta y respuesta de DNS


def costo_del_envio(protocolo, rtt_ms, resolver_dns):
    viajes_conexion, cpu_ms, bytes_red = PROTOCOLOS[protocolo]
    if protocolo == "Conexión TLS ya abierta":
        resolver_dns = False                                        # la conexión existe: no hay nada que resolver
    viajes = viajes_conexion + 1 + (1 if resolver_dns else 0)      # + 1 por pedido y respuesta, + 1 si hay DNS
    tiempo_ms = viajes * rtt_ms + cpu_ms
    mah = CORRIENTE_MA * tiempo_ms / 3.6e6
    return viajes, tiempo_ms, mah, bytes_red + (BYTES_DNS if resolver_dns else 0)


print("RTT = 100 ms, resolviendo el nombre con DNS:")
print("protocolo                    viajes   tiempo     mAh por envío   bytes en la red")
for nombre in PROTOCOLOS:
    viajes, ms, mah, b = costo_del_envio(nombre, 100, True)
    print(f"{nombre:<27} {viajes:>6} {ms:>8.0f} ms {mah:>14.4f} {b:>16}")

print()
print("Mismo costo con la IP del servidor guardada y RTT distinto:")
for rtt in (20, 100, 400):
    fila = []
    for nombre in ("UDP con confirmación", "TCP con TLS 1.2 (HTTPS)", "Conexión TLS ya abierta"):
        viajes, ms, mah, b = costo_del_envio(nombre, rtt, False)
        fila.append(f"{ms:>6.0f} ms")
    print(f"RTT {rtt:>3} ms:  UDP {fila[0]}   TLS 1.2 {fila[1]}   reutilizada {fila[2]}")

# Direcciones: ¿pertenece cada equipo a la misma red local?
import ipaddress

red = ipaddress.ip_network("192.168.1.0/24")
print()
print(f"Red {red}: máscara {red.netmask}, {red.num_addresses - 2} direcciones para equipos, difusión {red.broadcast_address}")
for texto in ("192.168.1.57", "192.168.2.10", "8.8.8.8"):
    ip = ipaddress.ip_address(texto)
    print(f"  {texto:<14} en la red local: {ip in red}   privada: {ip.is_private}")

Resultado con los valores iniciales. Con RTT de 100 ms y resolviendo el nombre: UDP necesita 2 viajes (200 ms, 0,0056 mAh, 270 bytes en la red); TCP sin cifrar, 3 viajes (300 ms); TCP con TLS 1.2, 5 viajes y 900 ms (0,0250 mAh, 5370 bytes); con TLS 1.3, 4 viajes y 700 ms; y con una conexión TLS ya abierta, 1 viaje, 100 ms y 700 bytes. Con la dirección guardada y TLS 1.2 el envío tarda 480 ms con RTT de 20 ms, 800 ms con 100 ms y 2000 ms con 400 ms, mientras que UDP o una conexión reutilizada tardan 20, 100 y 400 ms. La red de ejemplo 192.168.1.0/24 tiene 254 direcciones para equipos; la 192.168.1.57 pertenece a ella, la 192.168.2.10 es privada pero de otra red, y la 8.8.8.8 es pública.

Dos conclusiones del modelo. Una: la preparación de una conexión cifrada cuesta 8 veces lo que el pedido: de los 900 ms, 100 son el pedido y 800 son DNS, TCP, TLS y cálculo. Otra: la latencia de la red multiplica el costo: con RTT de 400 ms, un envío HTTPS completo con TLS 1.2 llega a 2,4 segundos (con DNS); la misma preparación en una red celular es mucho más cara que en el Wi-Fi.

09 · Exploración interactiva

¿Cuánto tarda un envío?, de extremo a extremo

Este laboratorio ejecuta el mismo modelo del código anterior. Elegí el protocolo, la latencia de la red (RTT) y si el nombre del servidor se resuelve con DNS. Cada barra descompone el tiempo del envío en DNS, conexión TCP, apretón de manos TLS, cálculo de cifrado y el pedido con su respuesta; la del protocolo elegido va resaltada. Los tiempos, bytes y la corriente son valores didácticos.

Recorrido guiado

1. Con los valores iniciales (TLS 1.2, RTT 100 ms, resolviendo DNS), calculá. 5 viajes, 900 ms, 0,0250 mAh y 5370 bytes: «Medio». La barra celeste del pedido es solo una pequeña parte.
2. Cambiá a UDP con confirmación: 2 viajes (DNS y pedido), 200 ms, 0,0056 mAh y 270 bytes. Para 20 bytes útiles viajan 270 bytes por la red, contra 5370 con TLS 1.2.
3. Probá TCP sin cifrar: 3 viajes y 300 ms. La conexión TCP agrega un viaje; el cifrado de TLS 1.2 agrega otros dos y 400 ms de cálculo.
4. Pasá a TLS 1.3: 4 viajes y 700 ms. Un viaje menos y menos cálculo, 200 ms de ahorro por envío.
5. Elegí Conexión TLS ya abierta: 1 viaje y 100 ms, y el DNS desaparece. Es la forma más barata de enviar con cifrado, a costa de mantener la conexión.
6. Volvé a TLS 1.2, cambiá a Dirección IP guardada y subí el RTT a 400 ms: 4 viajes y 2000 ms, con «Pesado». En una red celular lenta, el mismo envío cuesta 2,5 veces lo que en Internet fija (800 ms). Con 20 ms de RTT son 480 ms.

10 · Método de trabajo

Cómo diagnosticar una conexión

Cuando «conecta al Wi-Fi pero no llega el dato», recorré las capas de abajo hacia arriba. Cada paso descarta una familia de causas:

1. Enlace. ¿Está asociado al punto de acceso? ¿Qué RSSI tiene? (Tema 14.)
2. Dirección. ¿Obtuvo una IP? ¿Está en la subred correcta? ¿Qué puerta de enlace tiene?
3. Alcance del router. ¿Responde la puerta de enlace? Un ping al router distingue un problema local de uno de Internet.
4. Salida a Internet. ¿Llega a una dirección pública conocida (por ejemplo, un servidor DNS público)?
5. DNS. ¿Resuelve el nombre del servidor? Probá con la IP directa para separar el problema.
6. Transporte. ¿Conecta al puerto? Un firewall o un puerto equivocado produce un fallo de conexión.
7. Cifrado. ¿Falla el apretón de manos de TLS? Causas típicas: reloj desajustado (los certificados tienen fecha), certificado de la autoridad ausente o vencido.
8. Aplicación. ¿El servidor acepta las credenciales y el formato del mensaje?

Registrá en el monitor serie, con marca de tiempo, el resultado de cada paso. Un diagnóstico de campo que dice «falló en el paso 5: DNS» ahorra días frente a «no conecta».

11 · Comprensión

Confusiones frecuentes

12 · Práctica guiada

Predecí antes de comprobar

1. Misma red o no

Un dispositivo tiene la IP 192.168.1.57 con máscara 255.255.255.0 y puerta de enlace 192.168.1.1. Indicá si envía directo o por la puerta de enlace cuando el destino es: (a) 192.168.1.20; (b) 192.168.2.10; (c) 8.8.8.8.

2. Contar viajes

Un envío HTTPS con TLS 1.2 resuelve el nombre, abre TCP y negocia TLS antes de mandar el pedido. ¿Cuántos viajes de ida y vuelta tiene? ¿Y si la dirección está guardada y se usa TLS 1.3?

3. Elegir el transporte

Elegí TCP o UDP para: (a) un termómetro que informa su lectura cada minuto y no pasa nada si se pierde una; (b) la actualización de firmware completa; (c) un comando de apertura de puerta que debe ejecutarse una sola vez.

4. El NAT que olvida

Un router celular olvida las conexiones inactivas después de 60 segundos. Un dispositivo MQTT mantiene la conexión abierta y envía datos cada 5 minutos. ¿Qué pasa y cómo se evita?

5. Tiempo con latencia

Un envío HTTPS (TLS 1.2, dirección guardada) requiere 4 viajes y 400 ms de cálculo. ¿Cuánto tarda con RTT de 20, 100 y 400 ms? ¿Y la energía a 100 mA con 400 ms?

6. Diagnóstico por capas

El dispositivo tiene IP y responde el ping al router, pero no conecta con broker.ejemplo.com. Probando con la IP directa del broker, conecta. ¿Dónde está el problema?

13 · Síntesis

Ideas para recordar

¿Listo para el tema 18?

Antes de avanzar, tomá el firmware de tu dispositivo y registrá, con marcas de tiempo, cuánto tarda cada paso de un envío: resolución del nombre, conexión TCP, apretón de manos TLS y pedido. Calculá qué parte del tiempo total es el dato y qué parte es preparación, y decidí cuál de las cinco optimizaciones del tema aplicarías primero.

En el próximo tema cerramos el bloque de redes con la reconexión y las fallas de red: cortes, señal débil, reintentos con espera creciente y qué hacer con los datos cuando no hay conexión.