TR-369 WebSocket vs MQTT vs STOMP: ¿cómo se comparan los transportes de USP?

Antes de que un Agente y un Controlador intercambien un solo mensaje USP, tienen que ponerse de acuerdo en cómo viaja. TR-369 llama a esa capa Message Transfer Protocol (MTP) y define cuatro. El que elijas decide si tus equipos necesitan un broker, cómo se identifican y cómo se comportan después de una caída. Esta guía compara WebSocket, STOMP, MQTT y UNIX Domain Socket usando solo lo que dice la especificación.

¿Qué es un Message Transfer Protocol?

Un MTP es el protocolo de la capa inferior a USP que transporta un Message, por ejemplo WebSocket (§1.4). El USP Record es la carga útil del MTP (§4.1.3), así que cada binding responde las mismas preguntas: cómo conectarse, cómo llevar un Record y cómo avisar de un fallo. En nuestra guía de TR-369 verás cómo se anidan Records y Messages.

Algunas reglas valen para todos los MTP (§4.1). Agentes y Controladores pueden soportar más de uno, y los Endpoints siempre responden por el MTP en el que recibieron el mensaje (§4.1.1). Una vez establecido el canal, el Agente que puede hacerlo envía el Connect Record del MTP en uso, como WebSocketConnectRecord o MQTTConnectRecord (R-MTP.6), y debería enviar un DisconnectRecord antes de irse (R-MTP.7). Desde USP 1.2, los problemas con un Record se informan con USP Records en lugar de mensajes propios de cada MTP, con códigos de error del 7100 al 7199 (§4.1.4, Issue History).

¿Cómo se comparan los cuatro MTP?

La diferencia que más pesa es conexión directa frente a conexión con broker. Con WebSocket, los dos Endpoints sostienen la sesión. Con STOMP y MQTT, cada Endpoint mantiene una sesión con un servidor que enruta los Records por él.

¿Cómo funciona el MTP WebSocket?

El binding WebSocket usa RFC 6455, con sesiones de larga duración que se reutilizan para los Records siguientes (§4.3, §4.3.2). El Agente debe poder abrir una sesión y también aceptar la que abra un Controlador (R-WS.5, R-WS.6). En general la abre el Agente, por seguridad, para no exponer un puerto abierto hacia Internet, y entre dos Endpoints se usa como máximo una sesión abierta (§4.3.2, R-WS.4).

El handshake lleva dos datos propios de USP (§4.3.2.1):

• El subprotocolo. El cliente envía v1.usp en el encabezado Sec-WebSocket-Protocol y el servidor lo devuelve (R-WS.9 a R-WS.11). Si no vuelve, el cliente no establece la sesión (R-WS.12).
• El Endpoint ID del cliente. Con TLS, el servidor no sabe quién se conecta sin mirar dentro del certificado, así que el cliente agrega eid= y su Endpoint ID a la query de la URI (R-WS.10b). El requisito anterior, usar una WebSocket Extension, se eliminó en USP 1.3 (R-WS.10a).

Los Records viajan en tramas de datos binarias (R-WS.14). Quien envía no debería fragmentarlos, pero quien recibe debe aceptar fragmentos (R-WS.14a, R-WS.14b). Si un Record no se puede extraer, por ejemplo porque llegó en una trama de texto, el receptor cierra la conexión con el código de estado 1003 (R-WS.16). Los Agentes mantienen viva la sesión con tramas Ping y Pong, a un intervalo configurable (R-WS.17, R-WS.18).

¿Cómo usan STOMP y MQTT un broker?

Los dos bindings con broker siguen los mismos pasos básicos: negociar TLS si está configurado, conectarse al servidor, suscribirse y enviar USP Records (§4.4, §4.5).

1. AgenteCliente STOMP o MQTTSe suscribe a su propio destino o Topic y agrega una dirección de respuesta a todo lo que envía.
2. BrokerServidor STOMP o MQTTAutentica a cada cliente y limita a qué puede suscribirse.
   • STOMP: destino
   • MQTT: Topic
3. ControladorCliente STOMP o MQTTEnvía al destino o Topic del Agente y responde en la dirección de respuesta.

Como no hay sesión directa, todo lo que pasa por el broker indica dónde responder. STOMP usa el encabezado reply-to-dest (R-STOMP.21). MQTT exige un Topic de respuesta (“reply to”) en cada paquete PUBLISH: en la propiedad Response Topic con MQTT 5.0, o después de /reply-to= al final del Topic Name con MQTT 3.1.1 (R-MQTT.22 a R-MQTT.24). El broker también puede indicarle al Agente dónde escuchar: subscribe-dest en STOMP, la User Property subscribe-topic en MQTT 5.0 (R-STOMP.6, §4.5.2).

El broker tiene obligaciones concretas. Un servidor STOMP debe autenticar a los clientes y dejar que cada uno se suscriba solo a su propio destino (R-STOMP.34). Un servidor MQTT debe autenticar a los clientes y soportar una Access Control List que limite los Topics que cada uno puede usar (R-MQTT.42).

• STOMP, Simple Text Oriented Message Protocol, se usa en su versión 1.2 (§4.4). Los Endpoints USP envían su Endpoint ID en el encabezado endpoint-id (R-STOMP.4), se suscriben con ack en “auto” y nunca envían tramas de transacción ni de acuse de recibo (R-STOMP.17, R-STOMP.26, R-STOMP.27).
• MQTT, Message Queuing Telemetry Transport, se sumó a USP en la versión 1.1 (Issue History). Los clientes deben implementar MQTT 5.0 y pueden sumar 3.1.1 (R-MQTT.1, R-MQTT.2). La versión 5.0 importa porque en 3.1.1 el cliente no tiene una forma sencilla de pasarle su Endpoint ID al servidor, y el servidor no tiene cómo indicarle al cliente su Topic de respuesta (§4.5.1.1). Los Agentes deben soportar MQTT sobre TCP, y MQTT sobre WebSockets está permitido (R-MQTT.3). Los Endpoints deben soportar QoS 0 y 1 (R-MQTT.20), y desde USP 1.5 deberían soportar ALPN en el handshake TLS (R-MQTT.48a).

En los registros DNS-SD, un Endpoint detrás de un broker anuncia la dirección del broker, no la suya (R-STOMP.32, R-MQTT.38). Lo explicamos en cómo encuentra un Agente USP a su Controlador.

¿Cuándo tiene sentido el MTP UNIX Domain Socket?

Cuando el Agente y el Controlador viven en el mismo equipo. Este MTP interno, agregado en USP 1.3, comunica procesos separados dentro de un mismo dispositivo (§4.6). El socket se asocia a una ruta de archivo local en lugar de un host y un puerto, cada Endpoint actúa como servidor o como cliente pero no ambos, y no hace falta anunciar nada por mDNS (§4.6.1).

FrameUn Header y luego uno o más campos TLV.

• Sincronización: 0x5f 0x55 0x53 0x50 (“_USP”)
• Longitud del resto: 4 bytes

Campo TLVTipo 1 Handshake, 2 Error, 3 USP Record, 4 Password.

• Type: 1 byte
• Length: 4 bytes
• Value

USP RecordLa codificación binaria en Protocol Buffers del Record, como valor de un TLV de tipo 3.

Los dos lados intercambian TLV de Handshake con sus Endpoint IDs antes de cualquier Record, y el cliente que no recibe respuesta en 30 segundos cierra la conexión (R-UDS.16 a R-UDS.18). Si la conexión se cae, el cliente reintenta dentro de un lapso aleatorio de 1 a 5 segundos (R-UDS.5). El cifrado no es obligatorio, aunque TLS es una opción desde USP 1.4, y USP 1.5 agregó el TLV de Password para autenticar con un secreto compartido (§4.6.4, Issue History).

¿Qué MTP necesitan TLS?

La base es R-MTP.0: un MTP debe usar transporte seguro cuando los mensajes USP cruzan fronteras entre redes (§4.1.2). Dentro de la LAN del usuario final, la seguridad del MTP puede no ser necesaria. Se espera que los MTP sobre TCP implementen al menos TLS 1.2, y cuando se usa TLS, el Agente debe exigirle a su par un certificado X.509 (§4.1.2, R-MTP.1).

Los bindings de MTP dan seguridad punto a punto, así que en un MTP con broker ese TLS protege cada tramo hasta el broker, no todo el camino entre Agente y Controlador (§6.4). Para eso, USP tiene los Trusted Brokers y el Secure Message Exchange de extremo a extremo, que explicamos en seguridad en TR-369.