¿Qué diferencia hay entre UDP y TCP para telemetría?
Debajo de cada protocolo SCADA sobre una red IP se sienta una elección entre dos capas de transporte, TCP y UDP, y esa elección moldea en silencio cuántos bytes quema, qué tan rápido se recupera de una señal caída, y qué tan duro trabaja su batería. TCP garantiza entrega ordenada y confiable manteniendo una conexión y retransmitiendo cualquier cosa perdida, mientras que UDP simplemente dispara un paquete y lo olvida. Para la telemetría, donde los mensajes son diminutos y los enlaces suelen ser celulares inestables, la confiabilidad que TCP provee no es gratis, y a veces gana un diseño liviano sin conexión con confirmaciones a nivel de aplicación. Esta guía compara los dos para telemetría de campo y explica por qué varios protocolos industriales le dejan correr sobre cualquiera de ellos.
UDP frente a TCP para telemetría en una línea: TCP es un transporte orientado a conexión que establece una sesión, entrega los datos en orden, y retransmite automáticamente los segmentos perdidos, dando confiabilidad a costa de apretones de manos, encabezados y tráfico de mantenimiento extra. UDP es sin conexión: envía cada paquete de forma independiente con mínimo sobrecosto y sin retransmisión ni orden incorporados, así que es más liviano pero deja la confiabilidad a la aplicación. Para telemetría sobre enlaces celulares restringidos, UDP con confirmación a nivel de aplicación puede ahorrar bytes y batería, mientras que TCP conviene donde el que la red maneje la confiabilidad vale su sobrecosto, y protocolos como DNP3 e IEC 60870 pueden correr sobre cualquiera de los dos.
Orientado a conexión frente a sin conexión
TCP es orientado a conexión, lo que significa que antes de que fluya cualquier dato los dos extremos completan un apretón de manos para establecer una sesión, acordar números de secuencia, y montar el estado que cada lado necesita para rastrear lo que se ha enviado y confirmado. De ahí en adelante TCP numera cada byte, los entrega a la aplicación en orden, y retransmite cualquier cosa que no se confirme, así que la aplicación recibe un flujo limpio y ordenado como si la red fuera perfecta. Cuando el intercambio termina, un desmontaje cierra la conexión. Toda esta contabilidad es justo lo que hace confiable a TCP, y es también lo que lo hace pesado para un mensaje que es solo un puñado de bytes.
UDP es sin conexión. No hay apretón de manos ni estado de sesión; el emisor simplemente direcciona un paquete y lo envía, y el receptor toma lo que llegue. UDP no retransmite, no reordena, y no garantiza que un paquete llegue en absoluto. Su encabezado es mínimo, así que un mensaje de telemetría pequeño viaja con muy poca envoltura. El precio es que si un paquete se pierde el transporte nunca lo notará, así que cualquier garantía de que una lectura de verdad llegó tiene que construirse a nivel de aplicación, típicamente haciendo que el receptor envíe un acuse corto que el emisor espera.
La distinción importa porque el tráfico de telemetría es inusual. La mayoría del tráfico de internet son transferencias grandes donde el sobrecosto por mensaje de TCP desaparece contra megabytes de carga útil. La telemetría es lo inverso: cantidades enormes de mensajes muy pequeños, donde el costo fijo de establecer, mantener y desmontar una conexión puede empequeñecer al dato mismo. Esa inversión es por lo que la elección de transporte, que apenas importa para una descarga de archivo, se vuelve una decisión de diseño real para una flota de RTU.
Bytes y batería en enlaces celulares
En un enlace celular medido, cada byte que el transporte agrega es un byte que usted paga, y TCP agrega varios. El apretón de manos para abrir una conexión y el intercambio para cerrarla son puro sobrecosto sin dato de aplicación, y si un dispositivo abre una conexión fresca para cada reporte, ese costo se repite cada vez. Peor aún, las conexiones TCP que permanecen abiertas durante un período tranquilo por lo general necesitan tráfico de mantenimiento para que el equipo intermedio no descarte en silencio la sesión ociosa, y esos mantenimientos gotean bytes aun cuando nada pasa. Para un sitio que reporta una carga útil diminuta cada pocos minutos, este andamiaje puede ser una porción grande del uso total.
La batería sigue a los bytes en muchos dispositivos de campo, porque la radio celular suele ser el mayor consumo de energía, y cada transmisión y recepción despierta la radio y la mantiene en un estado de mayor potencia. Un diseño UDP que envía un paquete pequeño, opcionalmente espera un acuse pequeño, y luego deja que la radio duerma, mantiene la radio despierta el menor tiempo posible. Un diseño TCP que debe hacer el apretón de manos, transferir, mantener y desmontar mantiene la radio ocupada más tiempo y la cicla con más frecuencia. En un sitio solar o de batería muestreado a lo largo de años, esa diferencia se acumula en reducciones reales de presupuesto de energía y visitas de mantenimiento.
Nada de esto hace a TCP equivocado; lo hace una decisión considerada. Donde la red de verdad necesita garantizar un flujo ordenado, donde los mensajes son lo bastante grandes como para que el sobrecosto sea proporcionalmente pequeño, o donde los firewalls y equipos intermedios solo pasan limpiamente las conexiones establecidas, TCP se gana su costo. El punto es elegir deliberadamente en lugar de irse por TCP por ser lo familiar, en especial cuando una flota de reportadores pequeños, frecuentes y a batería es justo el caso al que UDP le quedaba bien.
Cómo los protocolos SCADA usan cada transporte
Varios protocolos industriales se diseñaron para ser flexibles sobre su transporte, y por eso la decisión de UDP frente a TCP suele vivir en la configuración en lugar de en la elección del protocolo mismo. DNP3 e IEC 60870 pueden llevarse sobre TCP o sobre UDP, así que los mismos mensajes a nivel de aplicación y el mismo modelo de objetos corren sin cambio mientras el transporte por debajo se elige para ajustar el enlace. Esa separación deja a un operador elegir entrega ordenada y confiable para un sitio bien conectado y un modo sin conexión más liviano para uno restringido, sin cambiar cómo los datos se modelan o se interpretan aguas arriba.
Cuando un protocolo corre sobre UDP, la responsabilidad de confirmar la entrega sube a la capa de aplicación, y los protocolos SCADA maduros ya llevan la maquinaria para hacer esto. Pueden solicitar una confirmación para un mensaje, reintentar si la confirmación no llega dentro de un tiempo de espera, y detectar duplicados, así que la aplicación logra la garantía que necesita sin pagar por una conexión de transporte persistente. En efecto el protocolo implementa apenas suficiente confiabilidad para los mensajes que la requieren, en lugar de hacer que el transporte garantice confiabilidad para todo incluyendo datos donde la pérdida sería inofensiva.
En un despliegue de SCADA en la nube, esta flexibilidad se vuelve una perilla de ajuste para toda la flota. Los sitios sobre conexiones fijas generosas pueden usar TCP y dejar que la red maneje la confiabilidad, mientras que los sitios remotos a batería sobre celular medido pueden usar un modo sin conexión con confirmaciones de aplicación para ahorrar bytes y energía, todos reportando a la misma plataforma. Un sistema como Merobix ingiere los datos resultantes de la misma manera sin importar el transporte, así que los ingenieros de campo pueden optimizar cada enlace según sus realidades físicas mientras los operadores ven una imagen consistente de cada sitio.
Preguntas frecuentes
¿UDP o TCP es mejor para la telemetría del SCADA?
Ninguno es universalmente mejor; depende del enlace y del patrón de mensajes. UDP es más liviano en bytes y más suave con la batería porque evita apretones de manos y mantenimientos, lo que conviene a reportes pequeños y frecuentes sobre celular medido, pero deja la confiabilidad a la aplicación. TCP garantiza entrega ordenada y confiable en el transporte mismo, lo que vale su sobrecosto en sitios bien conectados o transferencias más grandes, así que la respuesta correcta se elige por sitio en lugar de declararse una vez para toda la flota.
¿UDP pierde datos comparado con TCP?
UDP mismo no retransmite los paquetes perdidos, así que por su cuenta un paquete UDP caído simplemente se fue, mientras que TCP reenvía automáticamente cualquier cosa no confirmada. Sin embargo, los protocolos industriales que corren sobre UDP agregan su propia lógica de confirmación y reintento a nivel de aplicación, así que una lectura crítica aún puede confirmarse y reenviarse sin el costo permanente de una conexión TCP. El resultado es confiabilidad donde se necesita mientras que los datos inofensivos o pronto reemplazados pueden enviarse sin entrega garantizada.
¿DNP3 puede correr sobre UDP y sobre TCP?
Sí. DNP3 se definió para correr sobre IP usando ya sea TCP o UDP, e IEC 60870 ofrece flexibilidad de transporte similar, así que los mismos mensajes de aplicación viajan sin cambio mientras el transporte se elige para ajustar el enlace. Esto deja a los operadores usar TCP donde un flujo ordenado y confiable vale el sobrecosto y UDP donde ahorrar bytes y batería importa más, manteniendo idéntico el modelo de datos aguas arriba de cualquier modo.
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.