MQTT-3.1.1-CN 1
MQTT protocolo 3.1.1 Versión en chino
OASIS estándar
2014 año 10 mes 29 día
Enlaces de especificación
Versión actual：
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.doc (Authoritative)
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf
AnteriorVersión:
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/cos01/mqtt-v3.1.1-cos01.doc (Authoritative)
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/cos01/mqtt-v3.1.1-cos01.html
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/cos01/mqtt-v3.1.1-cos01.pdf
Última versión：
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.doc (Authoritative)
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.pdf
Comité técnicoComité:
Estándar de información estructuradaOrganización promotora MQTT Comité técnico
presidente：
Rafael ·J·Cohen (raphael.cohn@stormmq.com), individual
Richard ·J·Koppen (coppen@uk.ibm.com), IBM
editar：
Andrew Banks (Andrew_Banks@uk.ibm.com), IBM
Rahul Gupta (rahul.gupta@us.ibm.com), IBM
Documentos relacionados：
Esta especificación está relacionada con esto.：
MQTT y NIST Seguridad de redesmarco 1.0 versión. Los editores son Jeff Brown y Louis· Philip·Lamule. Última versión.
este: http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-
v1.0.html.
Resumen：
MQTT Es unServicio de clienteDesarrollo de la arquitectura del ladotela/Modelo de suscripcióndel protocolo de transmisión de mensajes.Su idea de diseño esligera,abierta,、
simple,、estándar,，por lo tantofácil de implementar.Estas características hacen quepara muchos escenariossea una muy buena opción, incluyendoentornos restringidos como
la comunicación máquina a máquina(M2M）así como el entorno de Internet de las Cosas (IoT），estosescenarios requieren un pequeño código de empaquetado o ancho de banda de red
muy caro.
Este protocolose ejecutaEn TCP/IP, osobre otras que proporcionan conexionesordenadas, confiables y bidireccionalesde red. Tiene las siguientes características:
utiliza el patrón de publicación/suscripciónde mensajes, proporcionandodistribución de mensajes de uno a muchosy desacoplamiento entreaplicaciones.
La transmisión de mensajes no necesitaconocer el contenido de la carga útil.。
Proporciona tres niveles decalidad de servicio:.
MQTT-3.1.1-CN 2
“como máximo una vez,”el mayor esfuerzo que el entorno operativopueda proporcionar para distribuirlos mensajes.Los mensajes pueden perderse.Por ejemplo,Este
El nivel puede usarse paradatos de sensores ambientales,la pérdida de datos individualesno importa,porquepronto seenviarán nuevamente.
“Al menos una vez.”, garantiza que el mensaje puede llegarllegar,peropuede repetirse.
“solo una vez”，garantíaEl mensaje solo llega una vez. Por ejemplo,EsteEl nivel se puede usar enun sistema de facturaciónen, aquí si
el mensaje se repite o se pierdecausará una incorrectafacturación.
muy pequeño consumo de transmisióny el intercambio de datos de protocolocambio, minimizando al máximotráfico de red
desconexión anormal de conexióncuando ocurre, puede notificara las partes relevantes.
Estado:
Este documento fue finalmente OASIS miembros enla fecha indicada arriba finalmenterevisado o aprobado.El nivel de aprobación tambiénse enumera arriba.Si
Para ver la revisión másreciente de este documento, por favorCompruebe la ubicación
Última versión
superior. Producido por el comité técnicootras revisiones yotros
documentos técnicos se enumeranaquí:https://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=mqtt#technical 。
miembros del comité técnicocomentarios sobre esta especificacióndeben enviarse al comité técnicoa la lista de correo del comitélista. Otras personas deben enviarcomentarios al comité técnico
a los comentarios públicos del comitélista, métodoes hacer clicComité Técnicodel sitio web enviar comentario botón,la dirección web es
https://www.oasis-open.org/committees/mqtt/ 。
sobre la implementación de esta especificacióncualquierqué patentes han sido divulgadas,y otras patentesinformación relacionada con los términos de la licenciainformación, consulte la
del sitio web del comité técnicosección de propiedad intelectual（(https://www.oasis-open.org/committees/mqtt/ipr.php）。
formato de cita:
al citar esta especificacióndebe usar lo siguienteformato de cita:
[mqtt-v3.1.1]
MQTT Version 3.1.1. Edited by Andrew Banks and Rahul Gupta. 29 October 2014. OASIS
Standard. http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html. Latest version:
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html.
MQTT-3.1.1-CN 3
enlace al documento
MQTT protocolo 3.1.1 chinoproyecto de traducción
MQTT protocolo 3.1.1 Versión en chino PDF
historial de revisiones
versión edición
día número
notas de la versión
1.0.0
2015-07-30
traducir todo el texto,completar la revisión preliminar, publicar laprimera versión
1.0.1
2015-10-22
corregir algunos errores tipográficos,agregar algunas partes no traducidasdel texto
Acercade los traductores
GitHub
Blog
Email
MQTT-3.1.1-CN 4
índice
1 Descripción general ...................................................................................................................................................... 8
1.1 MQTT estructura del protocolo ........................................................................................................................ 8
1.2 términos ..................................................................................................................................................... 8
1.3 referencias normativas .............................................................................................................................................. 9
1.4 referencias no normativasusar ........................................................................................................................................ 10
1.5 representación de datos ............................................................................................................................................ 12
1.5.1 binariodígito .................................................................................................................................... 12
1.5.2 enterovalor numérico .................................................................................................................................... 12
1.5.3 UTF-8 cadena codificada ..................................................................................................................... 12
1.6 convenciones de edición ............................................................................................................................................ 13
2 MQTT paquete de controlformato de mensaje ........................................................................................................................... 14
2.1 MQTT estructura de los paquetes de control ...................................................................................................................... 14
2.2 cabecera fija ............................................................................................................................................ 14
2.2.1 MQTT tipo de paquete de control .............................................................................................................. 14
2.2.2 banderas ........................................................................................................................................... 15
2.2.3 restantelongitud .................................................................................................................................... 16
2.3 cabecera variable ............................................................................................................................................ 17
2.3.1 paqueteidentificador ................................................................................................................................. 17
2.4 carga útil ............................................................................................................................................ 19
3 MQTT paquete de controltexto .................................................................................................................................. 20
3.1 CONNECT – conexión al servidor .................................................................................................................. 20
3.1.1 fijocabecera .................................................................................................................................... 20
3.1.2 variablecabecera .................................................................................................................................... 20
3.1.3 útilcarga .................................................................................................................................... 26
3.1.4 Respuesta ........................................................................................................................................... 27
3.2 CONNACK – ConfirmarSolicitud de conexiónRuego .............................................................................................................. 28
3.2.1 fijocabecera .................................................................................................................................... 28
3.2.2 variablecabecera .................................................................................................................................... 28
3.2.3 útilcarga .................................................................................................................................... 30
3.3 PUBLISH – Publicar mensaje ........................................................................................................................ 30
3.3.1 fijocabecera .................................................................................................................................... 30
3.3.2 variablecabecera .................................................................................................................................... 32
3.3.3 útilcarga .................................................................................................................................... 33
3.3.4 Respuesta ........................................................................................................................................... 33
3.3.5 Acción ........................................................................................................................................... 33
3.4 PUBACK –Confirmación de publicación .......................................................................................................................... 33
3.4.1 fijocabecera .................................................................................................................................... 33
3.4.2 variablecabecera .................................................................................................................................... 34
3.4.3 útilcarga .................................................................................................................................... 34
MQTT-3.1.1-CN 5
3.4.4 Acción ........................................................................................................................................... 34
3.5 PUBREC – PublicarPublicación recibida (QoS 2, primerpaso) ........................................................................................ 34
3.5.1 fijocabecera .................................................................................................................................... 34
3.5.2 variablecabecera .................................................................................................................................... 34
3.5.3 útilcarga .................................................................................................................................... 35
3.5.4 Acción ........................................................................................................................................... 35
3.6 PUBREL – Publicarliberación (QoS 2, segundopaso) ......................................................................................... 35
3.6.1 fijocabecera .................................................................................................................................... 35
3.6.2 variablecabecera .................................................................................................................................... 35
3.6.3 útilcarga .................................................................................................................................... 36
3.6.4 Acción ........................................................................................................................................... 36
3.7 PUBCOMP – PublicarPublicación completada (QoS 2, tercer paso) ..................................................................................... 36
3.7.1 fijocabecera .................................................................................................................................... 36
3.7.2 variablecabecera .................................................................................................................................... 36
3.7.3 útilcarga .................................................................................................................................... 36
3.7.4 Acción ........................................................................................................................................... 36
3.8 SUBSCRIBE - Suscribir tema ................................................................................................................... 37
3.8.1 fijocabecera .................................................................................................................................... 37
3.8.2 variablecabecera .................................................................................................................................... 37
3.8.3 útilcarga .................................................................................................................................... 37
3.8.4 Respuesta ........................................................................................................................................... 39
3.9 SUBACK – Confirmación de suscripción ......................................................................................................................... 40
3.9.1 fijocabecera .................................................................................................................................... 40
3.9.2 variablecabecera .................................................................................................................................... 40
3.9.3 útilcarga .................................................................................................................................... 41
3.10 UNSUBSCRIBE –Cancelarsuscripción ............................................................................................................ 41
3.10.1 cabecera fija .................................................................................................................................. 42
3.10.2 cabecera variable .................................................................................................................................. 42
3.10.3 carga útil .................................................................................................................................. 42
3.10.4 Respuesta ......................................................................................................................................... 43
3.11 UNSUBACK – Cancelar suscripciónAcuse de recibo .......................................................................................................... 43
3.11.1 cabecera fija .................................................................................................................................. 44
3.11.2 cabecera variable .................................................................................................................................. 44
3.11.3 carga útil .................................................................................................................................. 44
3.12 PINGREQ – Solicitud de ping ..................................................................................................................... 44
3.12.1 cabecera fija .................................................................................................................................. 44
3.12.2 cabecera variable .................................................................................................................................. 45
3.12.3 carga útil .................................................................................................................................. 45
3.12.4 Respuesta ......................................................................................................................................... 45
3.13 PINGRESP – Respuesta de ping ................................................................................................................... 45
3.13.1 cabecera fija .................................................................................................................................. 45
MQTT-3.1.1-CN 6
3.13.2 cabecera variable .................................................................................................................................. 45
3.13.3 carga útil .................................................................................................................................. 45
3.14 DISCONNECT –Desconectar............................................................................................................... 45
3.14.1 cabecera fija .................................................................................................................................. 46
3.14.2 cabecera variable .................................................................................................................................. 46
3.14.3 carga útil .................................................................................................................................. 46
3.14.4 Respuesta ......................................................................................................................................... 46
4 Comportamiento de operación ............................................................................................................................................. 47
4.1 Almacenamiento de estado ............................................................................................................................................ 47
4.1.1 No normativoejemplo ................................................................................................................................. 47
4.2 Conexión de red ............................................................................................................................................ 47
4.3 Calidad de servicioNiveles y flujo de protocolo .................................................................................................................. 48
4.3.1 QoS 0:Como máximoEntrega una vez .................................................................................................................. 48
4.3.2 QoS 1: Como mínimoEntrega una vez ................................................................................................................. 48
4.3.3 QoS 2: Solouna vez .................................................................................................................... 49
4.4 Entrega de mensajesReintento .................................................................................................................................... 51
4.5 Mensaje recibido ............................................................................................................................................ 51
4.6 Ordenamiento de mensajes ............................................................................................................................................ 51
4.7 Nombre del tema yFiltro de tema ......................................................................................................................... 52
4.7.1 TemaComodín ................................................................................................................................. 52
4.7.2 con$Comenzandotemas que comienzan con ........................................................................................................................... 53
4.7.3 TemaSemántica y uso ......................................................................................................................... 53
4.8 Manejo de errores ............................................................................................................................................ 54
5 Seguridad .................................................................................................................................................... 55
5.1 Descripción general ................................................................................................................................................... 55
5.2 MQTT Soluciones: Seguridad yAutenticación ........................................................................................................... 55
5.3 LigeroCifrado y dispositivos restringidos .................................................................................................................. 55
5.4 Consideraciones de implementaciónAsuntos .................................................................................................................................... 55
5.4.1 ClienteAutenticación del extremo ......................................................................................................................... 56
5.4.2 ClienteAutorización del extremo ................................................................................................................................. 56
5.4.3 ServicioAutenticación del extremo ......................................................................................................................... 56
5.4.4 ControlMensajes y mensaje de aplicaciónIntegridad del mensaje .................................................................................................... 56
5.4.5 ControlMensajes y mensaje de aplicaciónConfidencialidad del mensaje .................................................................................................... 56
5.4.6 mensajeNo repudio de la transmisiónReconocimiento .............................................................................................................. 56
5.4.7 DetecciónCliente y servidorSuplantación del extremo ....................................................................................................... 57
5.4.8 DetecciónComportamiento anormal ............................................................................................................................. 57
5.4.9 OtrosConsideraciones de seguridadelemento .................................................................................................................. 57
5.4.10 Usar SOCKS Proxy .................................................................................................................... 58
5.4.11 Configuración de seguridadArchivo ........................................................................................................................... 58
6 Usar WebSocket Comocapa de red .............................................................................................................. 59
6.1 IANA NotaAsuntos .................................................................................................................................. 59
MQTT-3.1.1-CN 7
7 Conformidad ................................................................................................................................................. 60
7.1 Objetivo de conformidadmarca ........................................................................................................................................ 60
7.1.1 MQTT Servidor ............................................................................................................................. 60
7.1.2 MQTT Cliente ............................................................................................................................. 60
apéndice B Declaración normativa obligatoria (no normativanorma) ............................................................................................................. 62
MQTT-3.1.1-CN 8
1 Descripción general
1.1 MQTT cooperarEstructura organizativa del protocolo
Esta especificación se divide en siete.Capítulos:
Capítulo 1 - introducción
Capítulo 2 – MQTT Formato de mensaje de control
Capítulo 3 – MQTT Paquete de control
Capítulo 4 – operacióncomportamiento
Capítulo 5 – Seguridad
Capítulo 6 – Usar WebSocket Como capa de transporte de red. t
Capítulo 7 – consistenteObjetivo de conformidad
1.2 términos
Lo que se utiliza en esta especificación.Palabra clave debe MUST，no puede MUST NOT，requisito REQUIRED，será SHALL，no SHALL
NOT，debería SHOULD，No debería SHOULD NOT，recomendado RECOMMENDED，puede MAY，opcional OPTIONAL
Todos según IETF RFC 2119 [RFC2119] La descripción enExplicación.
Conexión de red（Network Connection）：
MQTT UtilizadoProtocolo de transporte subyacenteInfraestructura de protocolo。
El cliente lo usa para conectarse al servidor.
Proporciona un servicio ordenado yconfiablede,Transmisión bidireccional de flujo de bytes.
Ver ejemplo 4.2 sección.
Mensaje de aplicación（Application Message）：
MQTT Protocolo de comunicaciónTransmisión a través de la redDatos de aplicación.Los mensajes de aplicación a través de MQTT Al transmitirse, ellosServicios asociadosCalidad de servicio (QoS) yTema
（Topic）。
Cliente（Client）：
Usar MQTT del programa o dispositivo.El cliente siempre se conectaa través de la red aServidor. Élpuede
Publicar el mensaje de la aplicación a otros relacionadosdel cliente..
suscripciónconsolicitudAceptar mensajes de aplicación relevantes
Cancelar la suscripción para eliminar.recibir mensajes de aplicaciónde la solicitud.
Desconectar la conexión del servidor.conexión.
Servidor（Server）：
Un programa o dispositivo., como el envío de mensajesel cliente de mensajes ydel cliente que solicita la suscripciónintermediario entre. Servextremo de servicio
Aceptar conexiones de red de los clientes
Aceptar la publicación del cliente.de los mensajes de aplicación
MQTT-3.1.1-CN 9
Procesar las suscripciones del cliente.suscripción y cancelación de suscripciónSolicitud.
reenviarAplicar mensaje a los que cumplen la condición.cliente del componentesuscripción。
suscripción（Subscription）：
La suscripción contiene un tema.filtro de temas (Topic Filter) yun servidor más grandeCalidad de servicio (QoS) nivel. La suscripción con un solosesión
（Session) cerrarConexión. La sesión puedecontiene más de una suscripción. Sesióncada suscripción tiene unDiferentes temas sobreFiltro.
Nombre del tema (Topic Name）：
Adjunto al mensaje de aplicación.Una etiqueta en, conocido por el servidor y con la suscripciónCoincidencia de suscripción. El servidor envíaUno de los mensajes de aplicaciónuna copia a cada coincidencia
La suscripción del cliente.
Filtrado de temaFiltro (Topic Filter:）：
una expresión incluida en la suscripción,utilizada pararepresentaruno o mástemas relacionados. El filtro de temas puedeusar comodines.
sesión（Session）：
Entre el cliente y el servidorse produce la interacción de estado.Algunas sesiones durantanto como laconexión de red,otras puedenextenderse a través de múltiples
conexiones de red sucesivasentre el cliente y el servidor.
Paquete de control（MQTT Control Packet）：
A través de una conexión de red se envíanlos paquetes de datos de información.MQTT La especificación define catorcetipos diferentes de mensajes de control,de los cualesuno (PUBLISH mensaje
) se utiliza para transmitirmensajes de aplicación.
1.3 estándar,Cita
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March
1997.
http://www.ietf.org/rfc/rfc2119.txt
[RFC3629]
Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003
http://www.ietf.org/rfc/rfc3629.txt
[RFC5246]
Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August
2008.
http://www.ietf.org/rfc/rfc5246.txt
[RFC6455]
Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011.
http://www.ietf.org/rfc/rfc6455.txt
[Unicode]
The Unicode Consortium. The Unicode Standard.
http://www.unicode.org/versions/latest/
MQTT-3.1.1-CN 10
1.4 Referencias no normativas
[RFC793]
Postel, J. Transmission Control Protocol. STD 7, IETF RFC 793, September 1981.
http://www.ietf.org/rfc/rfc793.txt
[AES]
Advanced Encryption Standard (AES) (FIPS PUB 197).
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
[DES]
Data Encryption Standard (DES).
http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf
[FIPS1402]
Security Requirements for Cryptographic Modules (FIPS PUB 140-2)
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
[IEEE 802.1AR]
IEEE Standard for Local and metropolitan area networks - Secure Device Identity
http://standards.ieee.org/findstds/standard/802.1AR-2009.html
[ISO29192]
ISO/IEC 29192-1:2012 Information technology -- Security techniques -- Lightweight cryptography -- Part
1: General
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=56425
[MQTT NIST]
MQTT supplemental publication, MQTT and the NIST Framework for Improving Critical Infrastructure
Cybersecurity
http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-v1.0.html
[MQTTV31]
MQTT V3.1 Protocol Specification.
http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html
[NISTCSF]
Improving Critical Infrastructure Cybersecurity Executive Order 13636
http://www.nist.gov/itl/upload/preliminary-cybersecurity-framework.pdf
[NIST7628]
NISTIR 7628 Guidelines for Smart Grid Cyber Security
http://www.nist.gov/smartgrid/upload/nistir-7628_total.pdf
[NSAB]
NSA Suite B Cryptography
http://www.nsa.gov/ia/programs/suiteb_cryptography/
MQTT-3.1.1-CN 11
[PCIDSS]
PCI-DSS Payment Card Industry Data Security Standard
https://www.pcisecuritystandards.org/security_standards/
[RFC1928]
Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC
1928, March 1996.
http://www.ietf.org/rfc/rfc1928.txt
[RFC4511]
Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June
2006.
http://www.ietf.org/rfc/rfc4511.txt
[RFC5077]
Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session
Resumption without Server-Side State", RFC 5077, January 2008.
http://www.ietf.org/rfc/rfc5077.txt
[RFC5280]
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
http://www.ietf.org/rfc/rfc5280.txt
[RFC6066]
Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January
2011.
http://www.ietf.org/rfc/rfc6066.txt
[RFC6749]
Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012.
http://www.ietf.org/rfc/rfc6749.txt
[RFC6960]
Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public
Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, June 2013.
http://www.ietf.org/rfc/rfc6960.txt
[SARBANES]
Sarbanes-Oxley Act of 2002.
http://www.gpo.gov/fdsys/pkg/PLAW-107publ204/html/PLAW-107publ204.htm
[USEUSAFEHARB]
U.S.-EU Safe Harbor
http://export.gov/safeharbor/eu/eg_main_018365.asp
MQTT-3.1.1-CN 12
1.5 representación de datos
1.5.1 Bits
Los bits de un byte se numeran desde 0 llegar 70. El bit 0 7 es el más significativo,el bit 7 0 es el menos significativo.
1.5.2 Valores enteros
Los valores enteros son de 16 16 bits, usando orden big-endian (big-endian，el byte de orden altova antes del byte de orden bajo). Esto significaque unapalabra de 16 bits en la red 16 Posiciónse representa como el byte más
significativo (MSB)), seguidoMSBdel byte menossignificativo (el control que se describiráLSB）。
1.5.3 UTF-8 cadena codificada
más adelante)El texto del mensajeEste campo se codifica como UTF-8 caracteres del formatocadena.UTF-8 [RFC3629] Es uneficiente
Unicode codificación de caracteresformato, para soportar la basecomunicación basada en texto, esta ASCII caracteresla codificación haceha optimizado.
Cada cadenatiene un campo de dos bytesde longitud comocomo prefijo, dade esta cadena UTF-8 bytes de la codificaciónnúmero,ellosEnleyenda
1.1 UTF-8 codificaciónestructura de la cadena codificada se describe endescripción. Por lo tanto, lo que se puede transmitir UTF-8 codificaciónel tamaño de la cadena tiene unlímite, no puedeexceder
65535 va antes del byte de orden bajo。
a menos que se especifique lo contrario,todas las UTF-8 codificacióncadenas codificadasde longitud deben estar dentro de 0 llegar 65535 va antes del byte de orden bajoeste rango。
leyenda 1.1 UTF-8 caracteres codificadosde la cadenaestructura
Bits
7
6
5
4
3
2
1
0
byte 1
el más de la longitud de la cadenabyte más significativo (MSB）
byte 2
el más de la longitud de la cadenabyte menos significativo (LSB）
byte 3 ….
si la longitud es mayor que 0, aquí es UTF-8 número de caracteres codificadosdatos.
UTF-8 codificaciónlos caracteres en la cadenadatos de caracteresdebese ajustan a Unicode estándar, [Unicode] definidos y en RFC3629 [RFC3629] Medio
reiterados válidos UTF-8 formato. Especialmente se necesitacabe señalar que,estosdatosno puedecontiene códigos de caracteres en U+D800 y U+DFFF entre
datos.Siel servidor o el cliente recibeha llegado un mensaje que contieneinválidos UTF-8 control de caracteresmensaje, estedebecerrar la redconexión [MQTT-
1.5.3-1]。
UTF-8 codificaciónla cadenano puedecontiene caracteres nulos U+0000。Siel cliente o el servidor recibeha llegado un mensaje que contiene U+0000 del controlmensaje de control
,ellodebecerrar la conexión de red [MQTT-1.5.3-2]。
en los datosNo deberíaincluye la codificación de Unicode punto de códigolo siguiente. Siun receptor (servidor o cliente) recibe un paqueteque contiene lo siguiente
control de cualquier caráctermensaje, estepuedecerrar la conexiónde red:
U+0001 y U+001F entrecaracteres de control
U+007F y U+009F entrecaracteres de control
Unicode estándar,no caracteres definidospuntos de código de carácter (por ejemplo U+0FFFF）
Unicode estándar,definidoscaracteres reservados (por ejemplo U+0FFFF）
MQTT-3.1.1-CN 13
UTF-8 codificaciónla secuencia 0XEF 0xBB 0xBF siemprese interpreta como U+FEFF(espacio de no separación de ancho cerocarácter),independientemente deque aparezca en la
cadena en cualquier posición,el receptor del mensajeno puede omitir oeliminarlo [MQTT-1.5.3-3]。
1.5.3.1 no normativoEjemplo
Por ejemplo, la cadena A𪛔 Síunaletra latina A seguida de unpunto de código U+2A6D4(que representa unCJK unificadoideogramas
Extensión B caracteres en la)，Estecodificación de cadenacomo sigue:
leyenda 1.2 UTF-8 caracteres codificadoscadena no normativaejemplo
Bit
7
6
5
4
3
2
1
0
byte 1
longitud de la cadena MSB (0x00)
0
0
0
0
0
0
0
0
byte 2
longitud de la cadena LSB (0x05)
0
0
0
0
0
1
0
1
byte 3
‘A’ (0x41)
0
1
0
0
0
0
0
1
byte 4
(0xF0)
1
1
1
1
0
0
0
0
byte 5
(0xAA)
1
0
1
0
1
0
1
0
byte 6
(0x9B)
1
0
0
1
1
0
1
1
byte 7
(0x94)
1
0
0
1
0
1
0
0
1.6 convenciones de edición
esta especificación utiliza texto resaltado en amarillopara identificardeclaraciones de conformidad,cada declaración de conformidadA cada uno se le asignó uno de este tipo.Referencia de formato:[MQTT-x.x.x-
y]。
MQTT-3.1.1-CN 14
2 MQTT Paquete de controlFormato
2.1 MQTT estructura de los paquetes de control
MQTT Protocolo de comunicaciónMediante el intercambio depredefinidos MQTT paquetes de control paracomunicarse. Esta seccióndescribe el formato de estospaquetes.
MQTT paquete de controlEl paquete consta de trespartes, según el leyenda 2.1 –MQTT ordendescrito en la estructura del paquete de control orden de descripción:
leyenda 2.1 –MQTT Del paquete de controlestructura
Fixed header Cabecerafija, todos lospaquetes de controlincluyen
Variable header cabecera variable,algunos paquetes de controlincluyen
Payload carga útil, algunos paquetes de controlincluyen
2.2 cabecera fija
Cada MQTT ordentodos los paquetes de controlincluyen una cabecera fija。leyenda 2.2 -CabeceraFormato de la cabecera fija describe la cabecera fijasu formato.
leyenda 2.2 -fijoEl formato de lacabecera.
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT paquete de controlTipo de paquete
se utiliza paraespecificar el tipo de paquete de controlindicadores
byte 2…
restantelongitud
2.2.1 MQTT tipo de paquete de control
Posición:ordinal 1 un byte, bits binarios 7-4。
se representan como 4 un valor de 4 bits sinsigno, estos valoresse definen en la tabla 2.1 -tipo de paquete de control
tabla 2.1 -ControlTipo depaquete
Nombre
Valor
paqueteDirección de flujo
Descripción
Reserved
0
Prohibido
Reservado
CONNECT
1
Del cliente al servidor
El cliente solicita la conexiónServidor
CONNACK
2
Del servidor al cliente
Paquete de conexiónAcuse de recibo
PUBLISH
3
Permitido en ambas direcciones
Publicar mensaje
PUBACK
4
Permitido en ambas direcciones
QoS 1 mensajePublicarRecibidoAcuse de recibo
PUBREC
5
Permitido en ambas direcciones
Publicación recibida (garantía deentrega, primer paso)
PUBREL
6
Permitido en ambas direcciones
Publicación liberada (garantía deEntrega del segundo paso)
MQTT-3.1.1-CN 15
PUBCOMP
7
Permitido en ambas direcciones
QoS 2 mensajePublicación completada (garantizar el tercer paso de interacción）
SUBSCRIBE
8
Del cliente al servidor
Solicitud de suscripción del cliente
SUBACK
9
Del servidor al cliente
Solicitud de suscripciónpaqueteAcuse de recibo
UNSUBSCRIBE
10
Del cliente al servidor
Cancelación de suscripción del clientesolicitud
UNSUBACK
11
Del servidor al cliente
Cancelar suscripciónpaqueteAcuse de recibo
PINGREQ
12
Del cliente al servidor
Solicitud de ping
PINGRESP
13
Del servidor al cliente
Respuesta de ping
DISCONNECT
14
Del cliente al servidor
Desconexión del cliente
Reserved
15
Prohibido
Reservado
2.2.2 banderas
Cabecera fija, el 1 resto del byte 4 Posición [3-0]Contiene, para cada MQTT paquete de controltipo de mensaje, los indicadores específicos,véase tabla 2.2 -indicadores。
tabla 2.2 en los que cualquier marcado como“Reservado”los bits de los indicadores, son todos reservados para uso futuro,debese establece en la tablalos valores enumerados [MQTT-
2.2.2-1]。SiSi se recibe un indicador no válido, el receptordebeCerrar la conexión de red. Relacionado con el manejo de erroresVer detalles en 4.8 la sección [MQTT-
2.2.2-2]。
tabla 2.2 -indicadores
Paquete de control
CabeceraIndicadores de cabecera fija
Bit 3
Bit 2
Bit 1
Bit 0
CONNECT
Reserved
0
0
0
0
CONNACK
Reserved
0
0
0
0
PUBLISH
Used in MQTT 3.1.1
DUP
1
QoS
2
QoS
2
RETAIN
3
PUBACK
Reserved
0
0
0
0
PUBREC
Reserved
0
0
0
0
PUBREL
Reserved
0
0
1
0
PUBCOMP
Reserved
0
0
0
0
SUBSCRIBE
Reserved
0
0
1
0
SUBACK
Reserved
0
0
0
0
UNSUBSCRIBE
Reserved
0
0
1
0
UNSUBACK
Reserved
0
0
0
0
PINGREQ
Reserved
0
0
0
0
PINGRESP
Reserved
0
0
0
0
DISCONNECT
Reserved
0
0
0
0
MQTT-3.1.1-CN 16
DUP
1
=ControlLa repetición del mensajeindicador de entrega
QoS
2
= PUBLISH paquetedeNivel de calidad de servicio
RETAIN
3
= PUBLISH del mensajeReservadobanderas
PUBLISH Controlen el mensaje DUP, QoS y RETAIN descripción del indicadorver 3.3.1 sección.
2.2.3 Longitud restante
Posición:Desde el 2 byte en adelante.
restantelongitudGrado（Remaining Length）representaCuandomensaje anteriormensaje restanteparte restantedividirdeva antes del byte de orden bajonúmero,incluyevariable de cabeceraycargaútildedatos。restantelongitudGrado
No incluye los bytes utilizados para codificar elcampo de longitud restanteen sí mismo。
El campo de longitudrestanteusa unlongitud variableesquema de codificación,Para valores menores que 128 el valorutilizaun solo bytela seccióncodificación. Los valores más grandesse procesande la siguientemanera.
bajo 7 Los bits significativos se utilizan para codificar datos, el bit más significativose utiliza para indicar si hay másbytes. Por lo tanto, cadabyte puede codificar 128 númerosValor
y un
bit de continuación (
continuation bit
）
). El campo de longitud restantepuede tener como máximo 4 bytessección.
no normativoComentario:
EjemploComo，dígitosdecimalesenbase 64 puedeEdredóncodificación10Paraunaunidadcaráctersección, el valorSí 64，dígitos6decimalesentablase muestraPara 0x40,。dígitosdecimalesenbasecarácter
321(=65+2*128)codificadocomo dos bytes,el bit menos significativo vadelante. El primerbyte es 65+128=193. Nótese que elbit más significativo es
1 representadespuésComo mínimohay otro byte. El segundobyte es. 2。
Noestándar,Comentario:
estoSe debepermitir enviarusarelpuede tener como máximo 256MB(268,435,455)grandePequeño deordenen mensajetexto。 estounidadbase ValorEn mensajetextoMediodetabla se muestraSí：
0xFF,0xFF,0xFF,0x7F。
tabla 2.4 tamañodel campo de longitud restante.Muestra cómo el valor representadopor el campo de longitud restante crece conel número de bytes.
tabla 2.4 Longitud restanteEldel campo de longitud restante.
número de bytes
Valor mínimo
valor máximo
1
0 (0x00)
127 (0x7F)
2
128 (0x80, 0x01)
16 383 (0xFF, 0x7F)
3
16 384 (0x80, 0x80, 0x01)
2 097 151 (0xFF, 0xFF, 0x7F)
4
2 097 152 (0x80, 0x80, 0x80, 0x01)
268 435 455 (0xFF, 0xFF, 0xFF, 0x7F)
del campo representa respectivamente (cadabyte, los bits de menor peso 7 Posiciónse utilizan para codificar datos, el bit más significativo es un bit de indicador,）：
1 cuando hay bytes,desde 0(0x00)llegar 127(0x7f)
2 cuando hay bytes,desde 128(0x80,0x01)llegar 16383(0Xff,0x7f)
3 cuando hay bytes,desde 16384(0x80,0x80,0x01)llegar 2097151(0xFF,0xFF,0x7F)
4 cuando hay bytes,desde 2097152(0x80,0x80,0x80,0x01)llegar 268435455(0xFF,0xFF,0xFF,0x7F)
MQTT-3.1.1-CN 17
no normativoComentario:
el entero no negativo X se codifica mediante el esquema de codificación de longitud variablecuyo algoritmo es el siguiente:
do
encodedByte = X MOD 128
X = X DIV 128
// if there are more data to encode, set the top bit of this byte
if ( X > 0 )
encodedByte = encodedByte OR 128
endif
'output' encodedByte
while ( X > 0 )
MOD es la operaciónmódulo,DIV es la división de enteros,OR es la operación de bits OR,（C que en el lenguajeson respectivamente.%，/，|）
no normativoComentario:
tamañoEl algoritmo de decodificación es el siguiente:：
multiplier = 1
value = 0
do
encodedByte = 'next byte from stream'
value += (encodedByte AND 127) * multiplier
multiplier *= 128
if (multiplier > 128*128*128)
throw Error(Malformed Remaining Length)
while ((encodedByte AND 128) != 0)
AND es la operación de bitsY (C en el lenguaje),&）
cuando este algoritmo termina,，value Paqueteel contenido esEl valor de la longitud restante.
2.3 cabecera variable
Algunos MQTT paquete de controlcontiene un encabezado variablesección.Está en el encabezado fijoy la carga útilentre. El encabezado variableel contenido segúndel tipo de mensaje
varía. Puedemensaje del encabezado variableidentificador (Packet Identifier）el campo existe enmuchos tipos de mensajes.
2.3.1 identificador de paquete
leyenda 2.3 -paquetetipo de identificadorpaquete
Bit
7
6
5
4
3
2
1
0
byte 1
identificador de paquete MSB
byte 2
identificador de paquete LSB
MQTT-3.1.1-CN 18
de muchos paquetes de controlparte del encabezado variablecontiene un campo de dos bytesde identificador de paquete. Estospaquetes son PUBLISH（QoS>0 cuando)，
PUBACK，PUBREC，PUBREL，PUBCOMP，SUBSCRIBE, SUBACK，UNSUBSCIBE，
UNSUBACK。
SUBSCRIBE，UNSUBSCRIBE y PUBLISH（QoS mayor que 0) paquete de controldebecontiene unno nulo 16 identificador de paquete
(Packet Identifier）[MQTT-2.3.1-1]. Cada vez que el clienteenvía un nuevode estos tiposcuando envía un paquete, siempredebeasigna unactualmente
identificador de paquete no utilizadoidentificador [MQTT-2.3.1-2]. Siun cliente quiere reenviareste paquete de control especialal reenviarese paquete
cuandoellodebeusa el mismo identificador.Cuando el cliente ha procesadola confirmación correspondiente a este mensajedespués, esteidentificador de paquetese libera para reutilizar.
QoS 1 de PUBLISH correspondea PUBACK，QoS 2 de PUBLISH correspondea PUBCOMP, con SUBSCRIBE o
UNSUBSCRIBE correspondienterespectivamenteSí SUBACK o UNSUBACK [MQTT-2.3.1-3]。enviar ununidad QoS 0 de PUBLISH
paquetecuando, las mismas condiciones también se aplican aServidor [MQTT-2.3.1-4]。
QoS establecido en 0 de PUBLISH paqueteno puedecontiene el identificador de paquete [MQTT-2.3.1-5]。
PUBACK, PUBREC, PUBREL paquetedebecontiene conenviado originalmente PUBLISH mensajeel mismo mensajeidentificador del mensaje [MQTT-2.3.1-
6]. De manera similar,SUBACK y UNSUBACK debecontenido en el correspondiente SUBSCRIBE y UNSUBSCRIBE mensajeutilizado en el mensajede
identificador de paquete [MQTT-2.3.1-7]。
requiereel paquete de control con identificador de paquete en tabla 2.5 -contiene el identificador de paquetedel paquete de control se enumeran en.
tabla 2.5 -incluyenidentificador de paquetecontrol del identificadorpaquete de control
Paquete de control
identificador de paquetecampo del identificadorcampo
CONNECT
no requiere
CONNACK
no requiere
PUBLISH
requiere (si QoS > 0）
PUBACK
requiere
PUBREC
requiere
PUBREL
requiere
PUBCOMP
requiere
SUBSCRIBE
requiere
SUBACK
requiere
UNSUBSCRIBE
requiere
UNSUBACK
requiere
PINGREQ
no requiere
PINGRESP
no requiere
DISCONNECT
no requiere
MQTT-3.1.1-CN 19
Entre el cliente y el servidorindependientemente entre síasignar identificadores de paquete. Por lo tanto, el clientecombinación del lado del servidorusando el mismoel identificador de paquete puede realizar y
intercambio de mensajes concurrente.
no normativoComentario:
el cliente envía el identificadores 0x1234 de PUBLISH el paquete,es posible quepueda recibir esedel paquete PUBACK deantes, primero
recibir el envío del servidorotro diferentepero cuyo identificador de paquetetambién es 0x1234 de PUBLISH paquete.
Client Server
PUBLISH Packet Identifier=0x1234---
--PUBLISH Packet Identifier=0x1234
PUBACK Packet Identifier=0x1234---
--PUBACK Packet Identifier=0x1234
2.4 carga útil
Algunos MQTT el paquete de control en el paqueteen la última parte contienecontiene una carga útilcarga, esto se tratará en el capítulocapítulo tres.Para PUBLISH en cuanto aútil
cargaes el mensaje de aplicación.tabla 2.6 – contiene la carga útilpaquete de control con carga útil enumera los requisitospaquete de control de la carga útil.
tabla 2.6 – que contiene la carga útildel paquete de controltexto
Paquete de control
carga útil
CONNECT
requiere
CONNACK
no requiere
PUBLISH
opcional
PUBACK
no requiere
PUBREC
no requiere
PUBREL
no requiere
PUBCOMP
no requiere
SUBSCRIBE
requiere
SUBACK
requiere
UNSUBSCRIBE
requiere
UNSUBACK
no requiere
PINGREQ
no requiere
PINGRESP
no requiere
DISCONNECT
no requiere
MQTT-3.1.1-CN 20
3 MQTT Paquete de control
3.1 CONNECT – conexiónServidor
Del cliente al servidorde la conexión de reddespués de establecida, el cliente envía alServidorel primer paquetedebeSí CONNECT paquete [MQTT-
3.1.0-1]。
en una conexión de redel cliente solopuede enviar una vez CONNECT paquete. El servidordebeel segundo paquete que el clienteenvía CONNECT
como violación del protocolotratado y desconexiónla conexión del cliente [MQTT-3.1.0-2]. Sobre los erroresconsulte la información de manejo 4.8 sección.
la carga útil contiene unoo más campos codificadosde los campos. Incluyeel único del clienteidentificador,Will tema,Will mensaje, nombre de usuarioy contraseña.División
el identificador del clienteexcepto，Otrostodos los demás campos son opcionales, basado en las banderaspara determinaren la cabecera variablesies necesario incluir estos campos。
3.1.1 cabecera fija
leyenda 3.1 –CONNECT del paquete, lacabecera fija
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT tipo de paquetepaquete (1)
Reserved ReservadoPosición
0
0
0
1
0
0
0
0
byte 2…
valor de longitud restante
El campo de longitudrestante
la longitud restante es igual a lalongitud de la cabecera variable（10 va antes del byte de orden bajo) más la longitud de lacarga útil. Codificaciónel método de codificación se detalla en 2.2.3 la secciónla descripción.
3.1.2 cabecera variable
CONNECT mensajela cabecera variable del paquetecontiene en el siguiente ordencuatro campos: protocoloNombre del protocolo (Protocol Name), protocolonivel（Protocol
Level），conexiónbanderas (Connect Flags) yKeep Alive (Keep Alive）。
3.1.2.1 protocolonombre
leyenda 3.2 -protocolonombrecomposición de bytes
Descripción
7
6
5
4
3
2
1
0
nombre de protocolo
byte 1
longitud MSB (0)
0
0
0
0
0
0
0
0
byte 2
longitud LSB (4)
0
0
0
0
0
1
0
0
byte 3
‘M’
0
1
0
0
1
1
0
1
byte 4
‘Q’
0
1
0
1
0
0
0
1
byte 5
‘T’
0
1
0
1
0
1
0
0
MQTT-3.1.1-CN 21
byte 6
‘T’
0
1
0
1
0
1
0
0
El nombre de protocolo es una cadena que representa elnombre de protocolo MQTT de UTF-8 codificada.MQTT de la especificaciónlas versiones posteriores nocambiarán estedesplazamiento de la cadenay
longitud.
Si el nombre de protocolo no escorrecto, el servidorpuededesconecta al clientela conexión, tambiénpuedesegúnalguna otra especificacióncontinúa procesando CONNECT los mensajes. Para
el último caso,según esta especificación,Servidorno puedecontinúa procesando CONNECT paquete [MQTT-3.1.2-1]。
Noestándar,Comentario:
las herramientas de inspección de paquetes, por ejemplo, cortafuegos, se puede usar elnombre de protocolo para identificar MQTT el tráfico.
3.1.2.2 nivel de protocolonivel
leyenda 3.3 - Protocol Level byte protocolonivelva antes del byte de orden bajocomposición
Descripción
7
6
5
4
3
2
1
0
nivel de protocolo
byte 7
Level(4)
0
0
0
0
0
1
0
0
el cliente utiliza un 8 valor sin signo debits para representarla revisión del protocolo. Paraque 3.1.1 versiónprotocolo, nivel de protocoloel valor del campo de nivelSí 4(0x04). Si se detecta un
nivel de protocolo no soportado, el servidordebeenvía uncódigo de retornoPara 0x01(nivel de protocolono soportado) CONNACK paqueteRespuesta
CONNECT paquete, y luego desconectala conexión del clienteconexión [MQTT-3.1.2-2]。
3.1.2.3 bandera deconexión
El byte de banderas de conexióncontiene algunos parámetros utilizados para especificarel MQTT comportamiento de conexiónparámetros del comportamiento de conexión. También indica que hayEl carácter en el payloadSi el segmento existe.
leyenda 3.4 -El bit de bandera de conexión
Bit
7
6
5
4
3
2
1
0
User Name
Flag
Password
Flag
Will Retain
Will QoS
Will Flag
Clean
Session
Reserved
byte 8
X
X
X
X
X
X
X
0
ServidordebeVerificación CONNECT paquete de controlEl flag de retención del mensajeBit (el 0 Posición) si es 0，Sino es 0 debe desconectarseconexión del cliente
[MQTT-3.1.2-3]。
3.1.2.4 limpieza desesión
Posición:El n.º del byte de bandera de conexión 1 Posición
Este bit binario indicael estado de sesiónel método de procesamiento.
Entre el cliente y el servidorse puede guardar la sesiónestado, para soportara través de conexiones de redtransmisión confiable de mensajes. Este bit de banderapara controlar el estado de la sesión
tiempo de vida.
MQTT-3.1.1-CN 22
Si se limpia la sesión (CleanSession）la bandera se establecea 0, el servidordebebasándose enla sesión actual (usandoel identificador del cliente)
la recuperación de estado con el clientela comunicación. Sino hay con esteidentificador del clienteuna sesión asociada,Servidordebecrear unanueva sesión. En
después de que la conexión se cierre,cuando la conexión se cierre,, el cliente y elextremo de serviciodebeservidor guardan la información de sesióninformación [MQTT-3.1.2-4]. Al limpiarla bandera de sesión es 0
la conexión de sesión se desconectadespués, el servidordebeguardarlos posteriores QoS 1 y QoS 2 nivelmensajes comouna parte del estado de sesiónsiesto
Algunos mensajes coinciden con la desconexiónel cliente al conectarsede cualquier suscripción [MQTT-3.1.2-5]。el servidor tambiénpuedealmacenaque cumplan las mismas condicionesde QoS 0 nivel
de los mensajes.
SiLimpiezagestiónsesión（CleanSession）marcaconexiónEdredónConfiguraciónPara 1，ClienteextremoyServicioextremodebedescartardeantes decualquiersesiónyComenzandoiniciarunNuevo
depuedesesión。puedesesiónsolamentemantenercontinuaryredredcomportamiento de conexiónConectarmismomuestralongituddeCuandoentre。yestounidadpuedesesiónAcercaenlacedeestadoestadobasedatosno puedeEdredóncualquierquédedespuésdepuedesesiónreiniciarusar
[MQTT-3.1.2-6]。
El estado de sesión del clienteincluye:
ya enviados al servidorextremo,peroaún no confirmados por completo QoS 1 y QoS 2 nivelotros mensajes
recibidos del servidor, pero aún noconfirmados por completo QoS 2 nivelotros mensajes.
El estado de sesión del servidorincluye:
sesiónexiste, incluso si el estado de sesiónlas demás partes delestán vacías.
La suscripción del clienteinformación.
Ya enviados al clienteextremo,peroaún no confirmados por completo QoS 1 y QoS 2 nivelotros mensajes。
a punto detransmitidos al cliente QoS 1 y QoS 2 nivelotros mensajes。
recibidos del cliente, pero aún noconfirmados por completo QoS 2 nivelotros mensajes.
opcional,preparadospara enviar al cliente QoS 0 mensajes de nivel。
Los mensajes retenidos no son parte del servicioestado de sesión del servidorde la sesióncuando la sesión terminano puedeeliminar mensajes retenidosinformación [MQTT-3.1.2.7]。
Sobre el almacenamiento de estadoVer limitaciones y detallesordinal 4.1 sección.
Cuando el indicador de sesión limpiase establece en 1 cuandoel cliente y el servidorel estado del servidor no necesita eliminarseSi es una operación atómica,。
no normativoComentario:
para garantizar que, cuando ocurrauna falla, la consistencia del estadose mantenga, el clientedebe utilizar elindicador de estado de sesión 1 reiniciarpara solicitar la reconexiónhasta que la conexión sea
establecida.
no normativoComentario:
En general, el cliente,al conectarse, siempreestablece el indicador de limpiezade sesión; 0 o 1，y no alterna los dosvalores. Estaelección
depende de la aplicación específica.Los clientes con el indicador de limpiezade sesión; 1 de sesión norecibirán los antiguosmensajes de aplicación,ydespués de cada reconexiónexitosa,
deben volver a suscribirseCualquiera los temasrelevantes. Los clientes con el indicadorde limpieza de sesión establecido 0 derecibirán todos losmensajes de nivel publicadosmientras su conexiónestuvo
desconectada. QoS 1 y QoS 2 Por lo tanto,para garantizarque no se pierdan los mensajes durante la desconexión,es necesarioUsar QoS 1 o
QoS 2 niveltambién establecer el indicadorde limpieza de sesión. 0。
no normativoComentario:
MQTT-3.1.1-CN 23
Cuando el cliente con el indicador 0 de limpieza de sesión se conecta,solicita al servidor quedespués de la desconexión conservesu MQTT estado de sesión.Si tiene
la intención de reconectarse en algúnmomento posteriorEste servidor,la conexión del cliente deberíausar solo el indicador de sesiónlimpia 0. Cuando el cliente decida
más tardeya no usar esta sesión, deberíalimpiar la sesión,de limpieza de sesión establecido 0 finalmente, conectaruna vez más,y luego desconectarse.
3.1.2.5 El indicador de testamento es el
Posición:[n].º bit de los indicadores de conexión 2 .
El testamentobanderas (Will Flag) se establecePara 1, lo que indica que sila solicitud de conexión esaceptada, el testamento（Will Message）mensajedebese almacena en
el servidor y con estaconexión de redasociada. Después, cuando laconexión se cierre,Servidordebese publica esteEl testamentomensaje,a menos queel servidor reciba
DISCONNECT un paquete y elimineEsteEl testamentomensaje [MQTT-3.1.2-8] 。
las condiciones para la publicación del mensajede testamento, incluyendo perono limitado a:
el servidor detectaun I/O un error o una falla de red。
el cliente, dentro del intervalo demantenimiento de la conexión (Keep Alive）no pudocomunicarse.
El cliente, sinenviar primero un paquete DISCONNECT, cerró DISCONNECT directamente la conexión de red.
Debido a un error de protocolo,el servidor cerró la conexión dered.
SiEl indicador de testamento se establece a 1[valor], el bit n.ºde los indicadores de conexión Will QoS y Will Retain Camposerá utilizado por el servidorpara,al mismo tiempoen la carga útildebe
debeincluyen Will Topic y Will Message Campo [MQTT-3.1.2-9]。
una vez publicado oel servidor ha recibidoenviado por el cliente DISCONNECT el paquete,El testamentoel mensaje entoncesdebese elimina del estado de sesión almacenado
División [MQTT-3.1.2-10]。
SiEl indicador de testamento se establece a 0，conexiónen el indicador Will QoS y Will Retain Campodebeestablecido en 0, yen la carga útilno puede
incluyen Will Topic y Will Message Campo [MQTT-3.1.2-11]。
SiEl indicador de testamento se establece a 0, redcuando la conexión de red se interrumpe，no puedeenviar el mensaje de testamento [MQTT-3.1.2-12]。
el servidor deberíarápidamentePublicartelaEl testamentomensaje。EnAcercamáquinaofalladesituaciónbajo，el servidor puedediferirEl testamentocancelardel mensajePublicarteladirectollegarmás tardedereiniciarinicio.
si ocurre este tipo desituación, en el serviciofalla del dispositivo y testamentoel mensaje publicadoentre puede haber un retraso。
3.1.2.6 El testamento QoS
Posición:[n].º bit de los indicadores de conexión 4 y el 3 .
estos dos se usan para especificarPublicarEl testamentoel servicio utilizado al enviar el mensajenivel de calidad.
SiEl indicador de testamento se establece a 0，El testamento QoS tambiéndebeestablecido en 0(0x00) [MQTT-3.1.2-13]。
SiEl indicador de testamento se establece a 1，El testamento QoS el valorpuede ser igual a 0(0x00)，1(0x01)，2(0x02). Estoel valorno puedeigual a 3
[MQTT-3.1.2-14]。
3.1.2.7 testamento retenido
Posición:[n].º bit de los indicadores de conexión 5 .
MQTT-3.1.1-CN 24
Siel mensaje de testamento al publicarse necesita conservarconservar, se necesita especificarel valor de este bit.
SiEl indicador de testamento se establece a 0, testamentoretención (Will Retain）el indicador tambiéndebeestablecido en 0 [MQTT-3.1.2-15]。
SiEl indicador de testamento se establece a 1：
Siel testamento retenido se establece en 0, el servidordebetratar el mensaje de testamento como nopublicar mensaje retenido [MQTT-3.1.2-16]。
Siel testamento retenido se establece en 1, el servidordebetratar el mensaje de testamento comopublicar como mensaje retenido [MQTT-3.1.2-17]。
3.1.2.8 nombre de usuariobanderas
Posición:[n].º bit de los indicadores de conexión 7 .
si el nombre de usuario (User Name) el indicador se establece en 0, en la carga útilno puedeincluyencampo de nombre de usuario [MQTT-3.1.2-18]。
si el nombre de usuario (User Name) el indicador se establece en 1, en la carga útildebeincluyencampo de nombre de usuario [MQTT-3.1.2-19]。
3.1.2.9 indicador de contraseñaconexión
Posición:[n].º bit de los indicadores de conexión 6 .
si la contraseña (Password) indicadorse establece en 0, en la carga útilno puedeContiene el campo de contraseña [MQTT-3.1.2-20]。
si la contraseña (Password) indicadorse establece en 1, en la carga útildebeContiene el campo de contraseña [MQTT-3.1.2-21]。
Si el indicador de nombre de usuario.se establece en 0, el indicador de contraseña tambiéndebeestablecido en 0 [MQTT-3.1.2-22]。
3.1.2.10 Mantener la conexión
leyenda 3.5 Mantener la conexiónva antes del byte de orden bajo
Bit
7
6
5
4
3
2
1
0
byte 9
Mantener la conexión Keep Alive MSB
byte 10
Mantener la conexión Keep Alive LSB
Keep Alive (Keep Alive) es unun valor en segundosel intervalo de tiempo, representado comoun 16 La palabra de bits, se refiere aEl cliente termina de transmitirCheng
El momento de un mensaje de control hasta el momento de enviar el siguiente mensaje., ambosentreSe debepermitirVacíolibrede lo másgrandeCuandointervalosseparar。El cliente es responsableprotegerpruebaControl
paquetePublicarenviar primero un paquete DISCONNECT, cerródeCuandointervalossepararNosuperarexcederEl valor de keep-alive.Sino tenertenerCualquiersuellodel controlenmensajeel texto puedeconPublicarenviar,Clientedebeelun
PINGREQ paquete [MQTT-3.1.2-23]。
sin importar¿Cuál es el valor de mantener la conexión, cliente?El cliente en cualquier momentotodos pueden enviar PINGREQ El mensaje, y utiliza. PINGRESP el mensaje determina la red
La actividad de la red y del servidor.Estado activo.
Si se mantiene la conexiónel valorNoCero, yademásservicioextremo de servicioEnunapunto cincoMúltiplodeprotegermantener conexiónConectarCuandoentredentrono hayrecibirllegarClienteextremodeControlmensajetexto，ellodebecortar
Abrir la red del cliente.conexión, se considera que la redLa conexión de red se ha interrumpido [MQTT-3.1.2-24]。
El cliente ha enviado PINGREQ paqueteDespués, si dentro de un tiempo razonableaún no se ha recibido PINGRESP mensaje, estedeberíacierre del servicio
La conexión de red del extremo.
MQTT-3.1.1-CN 25
El valor de keep-alive es.cero indicase muestraCierre y mantenimientomantenercomportamiento de conexiónConectarfunciónpoder。Esto significa que, servicioextremoNoNecesitaquererporqueclienteusuarioextremo noactivoYcortarComenzandocomportamiento de conexiónconexión.Nota：
No importa el valor del keep-alive, en cualquier momento, siempre queservicioel servidorreconozcaParaque el cliente está inactivo o no responde, puede desconectarseClientedel servidorcomportamiento de conexión
conexión.
no normativoComentario:
el valor real del keep-alivees especificado por la aplicaciónfijado, generalmente esunos minutos. Se permiteel valor máximo es 18 horas 12 dividir 15 segundos.
3.1.2.11 El encabezado variable nonormativoEjemplo
leyenda 3.6 -cabecera variableno normativoEjemplo
Descripción
7
6
5
4
3
2
1
0
nombre de protocolo
byte 1
Length MSB (0)
0
0
0
0
0
0
0
0
byte 2
Length LSB (4)
0
0
0
0
0
1
0
0
byte 3
‘M’
0
1
0
0
1
1
0
1
byte 4
‘Q’
0
1
0
1
0
0
0
1
byte 5
‘T’
0
1
0
1
0
1
0
0
byte 6
‘T’
0
1
0
1
0
1
0
0
nivel de protocolo
Descripción
7
6
5
4
3
2
1
0
byte 7
Level (4) nivel
0
0
0
0
0
1
0
0
banderas de conexión Connect Flags
byte 8
User Name Flag (1) usuarioindicador de nombre
Password Flag (1) contraseñaindicador de contraseña
Will Retain (0) Will bandera de retención
Will QoS (01) Will Calidad de servicio
Will Flag (1) Will banderas
Clean Session (1) limpiezasesión
Reserved (0) bits reservados
1
1
0
0
1
1
1
0
tiempo de keep-alive
byte 9
Mantener la conexión MSB (0)
0
0
0
0
0
0
0
0
byte 10
Mantener la conexión LSB (10)
0
0
0
0
1
0
1
0
MQTT-3.1.1-CN 26
3.1.3 carga útil
CONNECT mensajela carga útil del mensaje(Payloadpayload) contiene uno ovarios camposcon prefijo de longitud, los indicadores en el encabezado variabledeterminansi
si incluyen estos campos.Si están incluidos，debeaparecen en este orden: identificador del cliente, temadel testamento,El testamentomensaje, nombre de usuario, contra
10 [MQTT-3.1.3-1]。
3.1.3.1 Clienteidentificador
servicioel servidorextremoHacerusarclienteusuarioextremomarcaseñacarácter (ClientId) señanivelclienteusuarioextremo。comportamiento de conexiónConectarservicioel servidorextremodecadaunidadclienteusuarioextremoclientetenerúnicounadeclienteusuarioextremomarcaseñacarácter
（ClientId）。Cliente y servidordebe usar ClientId señapara distinguir entrelos dos MQTT el estado relacionado con la sesiónestado [MQTT-3.1.3-
2]。
identificador del cliente (ClientId) debeexisteydebeSí CONNECT paqueteel primer campode la carga útil [MQTT-3.1.3-3]。
identificador del clientedebeSí 1.5.3 definido por la sección UTF-8 cadena codificada [MQTT-3.1.3-4]。
Servidordebese permite 1 llegar 23 de N bytes de longitud UTF-8 identificador de cliente codificadoidentificador del clienteel identificador de cliente solo puede contenerestos caracteres:
“0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ”（letra mayúscula,Letras minúsculas
y dígitos)[MQTT-3.1.3-5]。
ServidorpuedePermite que después de codificar supereexceder 23 bytescliente del nodoidentificador (ClientId). El servidorpuedePermitir paquetesque incluye no enumerados arribaTabla de caracteres
El identificador del cliente. (ClientId)。
ServidorpuedePermite que el cliente proporcioneproporciona un carácter ceroIdentificador de cliente del nodo (ClientId) , siAl hacer esto,Servidordebeconsiderar esto como especial
Caso especial y asignar único.un identificador de clienteidentificador a ese clientecliente. Luego éldebeSuponga queEl cliente proporcionóEse único cliente.identificador
símbolo,Procesamiento normalEste CONNECT paquete [MQTT-3.1.3-6]。
Si el cliente proporciona.un byte cerodel identificador de clienteSímbolo, éldebeAl mismo tiempo borraráel indicador de sesión limpia se establecea 1 [MQTT-3.1.3-7]。
Si el cliente proporciona.de ClientId a cero bytesy limpiar el indicador de sesiónmarcado como 0, servicioextremodebeenvía un código de retorno de 0x02(indica que el identificador no
conforme) de CONNACK Mensaje de respuestaResponder al clientede CONNECT paquete，luegocerrar la conexión de red [MQTT-3.1.3-8]。
Si el servidor rechaza.de esto ClientId，ellodebeelEl código de retorno es 0x02(tablaindica que el identificador no es válidodel formato) CONNACK Respuesta de paquete
del cliente CONNECT el paquete,Luego cierra la redconexión [MQTT-3.1.3-9]。
no normativoComentario:
La implementación del cliente puede.Proporciona una manera convenientemétodo utilizado para generar aleatoriode ClientId. Al limpiar la sesiónel indicador se establece en 0 cuando debeLa
Renunciar activamente a usar este.Método.
3.1.3.2 Tema de última voluntad
SiEl indicador de testamento se establece a 1, hayel siguiente campo del payloadun campo es el testamentotema (Will Topic). Última voluntadTemadebeSí 1.5.3 sección determinada
predefinidos UTF-8 codificacióncadena [MQTT-3.1.3-10]。
MQTT-3.1.1-CN 27
3.1.3.3 Mensaje de última voluntad
SiEl indicador de testamento se establece a 1, hayel siguiente campo del payloadun campo es el testamentoMensaje. El mensaje de testamentoEl mensaje define lo que serápublicado al tema del testamentorespuesta de la pregunta
mensaje de uso, ver 3.1.2.5 Descripción del byte. Este campo está compuesto porun campo de dos byteslongitud y mensaje de testamentola carga útil del mensajecompuesto, representado comoCero bytes o
Múltiples secuencias de bytes.la longitud da lo siguienteEn los datos siguientesel número de bytes, noincluyenlongitudLos dos que ocupa el propio campoun byte.
El testamentoCuando el mensaje se publica en el tema de testamento, su carga útilla carga útil solo contiene estedatos del camposección., no incluye el iniciolos dos campos de longitud del encabezadobyte.
3.1.3.4 nombre de usuario
si el nombre de usuario (User Name) el indicador se establece en 1, el siguiente de la carga útillos campos son esos.nombre de usuariodebeSí 1.5.3 la seccióndefinido
UTF-8 codificacióncadena [MQTT-3.1.3-11]. servicioel servidor puedese utiliza para identidadVerificación y autorización.
3.1.3.5 contraseña
si la contraseña (Password) indicadorse establece en 1, el siguiente campo de la carga útil esél. secretoel campo de código contiene un valor de dos caracteresLongitud del byte
Campo，longitudIndica el número de bytes de los datos binarios.(sin incluir el campo de longitud en sí mismolos dos que ocupa el propiobytes), luegoseguir 0 llegar 65535 va antes del byte de orden bajo
Los datos binarios.
leyenda 3.7 - Bytes de contraseña
Bit
7
6
5
4
3
2
1
0
byte 1
Longitud de datos MSB
byte 2
Longitud de datos LSB
byte 3 ….
si la longitud es mayor que 0, aquí está la parte de datos
3.1.4 Respuesta
Nota: El servidor puede.para en el mismo TCP Puerto u otroSoportar en otros extremos de red.admite múltiples protocolos (incluido esteversión temprana del protocolotexto).si el servidor
El servidor determina que el protocolo es. MQTT 3.1.1, entoncesde acuerdo con lo siguientemétodo para verificar la conexiónSolicitud.
1. Una vez establecida la conexión de red, si el servidoren un tiempo razonableno se ha recibido dentro CONNECT mensajemensaje, el servidordeberíaCerraresta conexión
conexión.
2. Servidordebesegún 3.1 verificación de los requisitos de la sección CONNECT el paquete,Siel mensaje no cumpleespecificación, el servidorno enviar
CONNACK paqueteCerrar directamenteConexión de red [MQTT-3.1.4-1]。
3. Servidorpuedeverificar CONNECT del mensajesi el contenido satisfacecualquier requisito adicionalla limitación,puederealizar autenticaciónautenticación y autorización
verificar. Si alguna de las comprobaciones no se supera.No obstante, según 3.2 la descripción de la sección, estodeberíaenviar un adecuadoapropiada,código de retorno distinto de cero
CONNACK respuesta, ydebeCerrar esta conexión de red.
Si la verificación es exitosa,el servidor ejecutarálos siguientes pasos.
1. Si ClientId indicaEl cliente ya se ha conectado a este servidor.Lado del servicio, entonces el servidordebedesconectar al cliente existenteConexión del cliente [MQTT-
3.1.4-2]。
2. Servidordebesegún 3.1.2.4 la seccióndeDescripciónejecutarEl proceso de limpieza de la sesión [MQTT-3.1.4-3]。
3. Servidordebeenvía un código de retorno dede cero CONNACK paquete como CONNECT del mensajeRespuesta de confirmación [MQTT-3.1.4-4]。
4. Comienza la distribución de mensajes ymantener el estado de conexiónsupervisión.
MQTT-3.1.1-CN 28
se permiteel cliente, al enviar CONNECT paqueteinmediatamente despuésOtros mensajes de control;El cliente noNecesita esperar el del servidor CONNACK
paquete.Siel servidor rechazó CONNECT, ellono puedeprocesar el clienteEn CONNECT después del mensaje, enviarcualquier dato enviado [MQTT-
3.1.4-5]。
no normativoComentario:
El cliente suele esperaresperar un CONNACK mensaje. Sin embargoel cliente tiene derecho aRecibido CONNACK antes deenviar paquetes de control，
Debido a que no es necesario mantenerel estado de conexión, estopuede simplificar la implementación del clienteaparece.
3.2 CONNACK – confirmar solicitud de conexiónRuego
el servidor envía CONNACK paqueterespuesta del clienterecibido CONNECT mensajemensaje. El servidorenviado al clienteel primer paquetedebe
debeSí CONNACK [MQTT-3.2.0-1]。
Si el cliente está endentro de un tiempo razonable norecibido del servidorde CONNACK el paquete,Clientedeberíacerrar la redred.
razonable
El tiempo depende
Depende del tipo de aplicacióny la infraestructura de comunicacionesaplicar.
3.2.1 cabecera fija
El formato de la cabecera fijavéase leyenda 3.8 – CONNACK mensajedocumento fijocabecera fija la descripción de。
leyenda 3.8 – CONNACK cabecera fija del paquete
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT tipo de paquete de control (2)
Reserved bits reservados
0
0
1
0
0
0
0
0
byte 2
Longitud restante (2)
0
0
0
0
0
0
1
0
El campo de longitudrestante
representaLa longitud de la cabecera variable. Para CONNACK paqueteeste valor es igual a 2。
3.2.2 cabecera variable
El formato de la cabecera variablevéase leyenda 3.9 –CONNACK el mensaje puedecabecera variable dedescripción.
leyenda 3.9 –CONNACK cabecera variable del paquete
Descripción
7
6
5
4
3
2
1
0
indicadores de confirmación de conexión
Reserved bits reservados
SP
1
byte 1
0
0
0
0
0
0
0
X
código de retorno de conexión
byte 2
X
X
X
X
X
X
X
X
MQTT-3.1.1-CN 29
3.2.2.1 confirmación de conexiónindicador de confirmación
ordinal 1 byte es.
indicadores de confirmación de conexión
, posición 7-1 es mantenerreservado ydebeestablecido en 0。
ordinal 0 (SP)Posición es el actualsesión（Session Present）banderas。
3.2.2.2 sesión actualsesión
Posición:el enésimo del indicador de confirmación de conexión 0 .
Si el servidor recibelimpiar sesión (CleanSession）banderasPara 1 dela conexión, exceptohabrá CONNACK El código de retorno en el paqueteestablecido en 0
Además, tambiéndebeva a CONNACK en el mensajeconfiguración de la sesión actual（Session Present）banderasPara 0 [MQTT-3.2.2-1]。
Si el servidor recibeun CleanSession Para 0 deconexión,indicador de sesión actualel valor depende de si el servidor essi ya se ha guardado ClientId
La sesión correspondiente al clienteestado de sesión. SiEl servidor ya haguardado el estado de sesión, ellodebeva a CONNACK La sesión actual en el paqueteEstablecer el indicador de sesión
a 1 [MQTT-3.2.2-2]。si el servidorNo hay ningúnestado de sesión, estedebeva a CONNACK mensajeen el textoconfiguración de la sesión actual
Para 0. También se debe CONNACK mensajeel código de retorno en el mensaje se establece en 0 [MQTT-3.2.2-3]。
El indicador de sesión actual haceel servidor y el clienteen si ya hayen el estado de sesión almacenado se guardaMantener la coherencia.
una vezSe ha completado la configuración de inicialización de la sesión., ya ha guardado la sesiónel cliente con estado de sesión esperaráespera que el servidor mantengaalmacenael estado de sesión.si el cliente
El cliente recibe del servidorllegadoactualmenteel valor difiere del esperado, el cliente puedeelegir continuar con estasesión o desconexión.Clientepuede descartarse
Descarta el cliente y el servidorsesión entre los extremosestado, métodoSí,Desconectar, va amarcador de limpieza de sesiónde sesión; 1, al reconectar,luegonuevamente
Desconectar.
Si el servidor envíaun mensaje que contiene undel código de retorno cero CONNACK mensaje, estedebecuandoindicador de sesión anteriorestablecido en 0 [MQTT-
3.2.2-4]。
3.2.2.3 la conexión devuelvecódigo de retorno
Posición:primer byte de la cabecera variable 2 bytes。
El campo de código de retorno de conexiónusa un bytede valor sin signo,En tabla 3.1 –Retorno de conexiónValor del código de retorno se enumeran. Si el servidor recibeun válido
del método CONNECT mensaje, pero ocurresi por alguna razón nopuede procesarlo, elservidor debería intentarenviar un mensaje que contiene un código de retorno distinto de cerocódigo de retorno (en la tablade
de uno) CONNACK mensaje. Siel servidor envióun mensaje que contiene un código de retorno no nulode CONNACK el paquete,entoncesdebeAcerca
cerrar la conexión de red [MQTT-3.2.2-5].。
tabla 3.1 –El valor del código de retorno de conexión
Valor
código de retornoRespuesta
Descripción
0
0x00 Conexión aceptadaaceptar
La conexión ha sido rechazada por el servidorAceptan
1
0x01 Conexión rechazadarechazo, no soportadoVersión del protocolo
El servidor no admite el clientesolicitado por el cliente MQTT nivel de protocolonivel
2
0x02 Conexión rechazadarechazado, noidentificador de cliente válido
El identificador del cliente escorrecto UTF-8 codificación,peroServicio
el cliente no puede usar
3
0x03 Conexión rechazadarechazado, el servidorservidor no disponible
La conexión de red se ha establecido, pero MQTT servicio no disponible
4
0x04 Conexión rechazadarechazada, no válidaEl nombre de usuario o la contraseña de
Del nombre de usuario o contraseñaformato de datos no válido
MQTT-3.1.1-CN 30
5
0x05 Conexión rechazadarechazado, noautorización
El cliente no está autorizadoconectarse a este serviciodispositivo
6-255
Reservado
Si se considera que en la tabla anteriortodas las conexiones devuelvenLos códigos de retorno no son muy adecuados，entoncesServidordebeCerrar la conexión de red,no es necesario enviar CONNACK mensaje
texto [MQTT-3.2.2-6]。
3.2.3 carga útil
CONNACK paqueteSin una ... válidacarga útil.
3.3 PUBLISH – Publicar mensaje
PUBLISH ControlEl mensaje se envía desde el clienteal servidoro el servidor al clientepara transmitir un mensaje de aplicaciónmensaje.
3.3.1 cabecera fija
leyenda 3.10 – PUBLISH mensajeencabezado fijo del paquetedescribe la cabecera fijaFormato de la cabecera
leyenda 3.10 – PUBLISH cabecera fija del paquete
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT paquete de controltipo de mensaje (3)
DUP
QoS nivel
RETAIN
0
0
1
1
X
X
X
X
byte 2
Longitud restante
3.3.1.1 indicador de reenvíoconexión
Posición:ordinal 1 byte, el 3 Posición
Si DUP el indicador se establece en 0indica que esto es un cliente o servidorel servidor solicita por primera vezsolicitud de enviar este PUBLISH paquete.Si DUP banderas
se establece en 1, tablaindicando que esto puede ser unmensaje solicitado anteriormentereenvío de la solicitud.
El cliente o el servidorsolicita reenviar un PUBLISH Cuando el mensaje,debeva a DUP marcade sesión; 1 [MQTT-3.3.1.-1].. Para QoS
0 el mensaje de,DUP banderasdebeestablecido en 0 [MQTT-3.3.1-2]。
el servidor envía PUBLISH paquetea los suscriptorescuandoRecibidode (entrante) PUBLISH del mensaje DUP el valor del indicadorno se propagará.Publicar
del envío (saliente) PUBLISH paquetey el recibidode (entrante) PUBLISH en el mensaje DUP el indicador es únicoconfigurado de forma independiente,su valordebe
Basado únicamente en el envíode (saliente) PUBLISH paquetesi es un reenvíoenviado para determinar [MQTT-3.3.1-3]。
no normativoComentario:
El receptor recibe un DUP el indicador es 1 decuando el mensaje de controlNo se puede asumir que veantes de este mensajeuna copia de.
no normativoComentario:
Es necesario señalar especialmenteSí,DUP marcael registro se centra en elmensaje de control en sí,con el mensaje de aplicación que contieneirrelevante. Al usar QoS 1
cuandoEl cliente puede recibir un DUP el indicador es 0 de PUBLISH el paquete,Esteel paquete contiene unel que había recibido anteriormente
Una copia del mensaje de aplicación, pero se utilizadiferentes identificadores de paqueteidentificador. 2.3.1 la sección proporciona informaciónAcerca del identificador del paqueteMás información.
MQTT-3.1.1-CN 31
3.3.1.2 calidad de servicionivel de calidad
Posición:ordinal 1 byte, el 2-1 .
Este campo indica que se debeusado en la distribución de mensajesgarantía del nivel de calidad de servicio.calidad de servicioel nivel de calidad en tabla 3.2 -definición de calidad de servicio se enumeranse muestra.
tabla 3.2 -Calidad de serviciodefinición
QoS Valor
Bit 2
Bit 1
Descripción
0
0
0
como máximo una vez
1
0
1
al menos una vez
2
1
0
solo se distribuye una vez
-
1
1
bits reservados
PUBLISH paqueteno puedeva a QoS lugaralgunos bits se establecen en 1。Siservidor o clienteclienteRecibido QoS todos los bits son 1 de PUBLISH
mensaje, estedebecerrar la conexiónConectar [MQTT-3.3.1-4]。
3.3.1.3 indicador de retenciónconexión
Posición:ordinal 1 byte, el 0 .
Si el cliente envía aldel lado del servidor PUBLISH del mensajeretención (RETAIN）el indicador se establecePara 1, el servidordebealmacenar este mensaje de aplicación
mensaje yellodeServiciocalidadesperarnivel（QoS）, paraconvenienteellopuedeEdredóndistribuira novenirdeprincipaltítuloemparejarasignadosreservarlector [MQTT-3.3.1-5]。un
la nuevasuscripciónconstruirinmediatamenterespecto aCadacoincidenciadeTemanombre，SialmacenarEnrecientementeprotegerretenidoscancelarmensaje,ellodebees enviadoenviado aEstereservarlector [MQTT-
3.3.1-6]. Si el servidorel extremo recibe un mensaje retenido（RETAIN) el indicador es 1 de QoS 0 mensaje,ellodebedescartaranteriormente para ese maestrotema retenido
de cualquier mensaje. Estedeberíaesteun nuevo QoS 0 mensaje como ese temanuevo mensaje retenido del tema, peroes en cualquier momentopuedeelige descartarlo
— SiCuando esto ocurre, eseel tema no tendrá retenciónmensaje retenido [MQTT-3.3.1-7]。sobre el estado de almacenamientomás información en 4.1 sección.
Servidorel PUBLISH mensaje acuando el cliente, por ejemploSi el mensaje es como clienteun nuevoel resultado de la suscripción se envíaenvía, éstedebela retención del paquete
establecer el indicador de retención 1 [MQTT-3.3.1-8]. Cuando un PUBLISH mensajepublicación del documentoEnviado al cliente porque coincidecoincidir con una ya establecidaal momento de la suscripción, el servidor
extremo de serviciodebeestablecer el indicador de retención en 0, sin importar queel mensaje recibidoen el mensajeReservadocuál es el valor del indicador [MQTT-3.3.1-9]。
Reservadoel indicador es 1 y válidocarga útil de cero bytesde PUBLISH mensajeel mensaje seráEl servidor lo trata como un mensaje normalprocesado, seráenviado al tema suscrito
coincidenteClienteextremo。además，mismounprincipaltemaabajoCualquierpresentealmacenardeReservadocancelarinformacióndebeEdredónmoverDivisión，por lo tantoestounidadTemadedespuésdeCualquierreservarleertodos
no recibiráa unmensaje retenido [MQTT-3.3.1-10]。
como normal
significaexistenteel cliente recibeel mensaje deMedioel indicador de retención nose establece。
Servidorno puedealmacenamiento de cero bytesmensaje retenido [MQTT-3.3.1-11]。
Si el cliente envía aldel lado del servidor PUBLISH del mensajeel bit del indicador de retención 0，Servidorno puedealmacenar este mensajetambiénno puedeeliminar o reemplazar cualquier
mensaje retenido existente [MQTT-3.3.1-12]。
no normativoComentario:
para el publicador no definidoenvío periódico de mensajes de estadoeste escenario,el mensaje retenido es muyútil. La nueva suscripciónEl suscriptor recibirá el estado más recienteestado.
El campo de longitudrestante
igual aLa longitud de la cabecera variable más la carga útilLa longitud de la carga útil.
MQTT-3.1.1-CN 32
3.3.2 cabecera variable
Encabezado variable en ordenincluyenTemaNombre e identificador de paquete.
3.3.2.1 Nombre del tema
Nombre del tema (Topic Name) se utiliza paraidentificar la carga útildónde deben publicarse los datosun canal de información。
Nombre del temadebeSí PUBLISH mensajeencabezado variable del mensajeEl primer campo del encabezado.ellodebeSí 1.5.3 la seccióndefinido UTF-8 Cadena codificada
[MQTT-3.3.2-1]。
PUBLISH paquetenombre del tema enno puedecontiene comodinescomodines [MQTT-3.3.2-2]。
El servidor envía al suscriptordel cliente suscriptor PUBLISH paqueteel nombre del temadebecoincidenciael tema de la suscripciónfiltro (según 4.7 la coincidencia definida en la sección
proceso）[MQTT-3.3.2-3]。
3.3.2.2 identificador de paqueteidentificador
solo cuando QoS esperarel nivel es 1 o 2 Cuando, el identificador de paquete（Packet Identifier) campopuede aparecer en PUBLISH en el mensaje.2.3.1
La sección proporciona información sobre elmás del identificador de paquetemás información.
3.3.2.3 encabezado variableencabezado no normativoEjemplo
leyenda 3.11 – PUBLISH mensajeencabezado variable del mensajeejemplo no normativo ilustra tabla 3.3 - PUBLISH mensajeejemplo no normativo brevemente descrito en
descrito PUBLISH el encabezado variable del mensajeencabezado.
tabla 3.3 - PUBLISH ejemplo no normativo del mensaje
Field
Value
Nombre del tema
a/b
identificador de paquete
10
leyenda 3.11 – PUBLISH cabecera variable del paqueteejemplo no normativo
Descripción
7
6
5
4
3
2
1
0
Topic Name Nombre del tema
byte 1
Length MSB (0)
0
0
0
0
0
0
0
0
byte 2
Length LSB (3)
0
0
0
0
0
0
1
1
byte 3
‘a’ (0x61)
0
1
1
0
0
0
0
1
byte 4
‘/’ (0x2F)
0
0
1
0
1
1
1
1
byte 5
‘b’ (0x62)
0
1
1
0
0
0
1
0
identificador de paquete
byte 6
identificador de paquete MSB (0)
0
0
0
0
0
0
0
0
byte 7
identificador de paquete LSB (10)
0
0
0
0
1
0
1
0
MQTT-3.1.1-CN 33
el nombre del tema en el ejemploPara “a/b”，longitudigual a 3, el identificador de paquete es “10”
3.3.3 carga útil
la carga útil contienela aplicación que se publicarámensaje. Los datosel contenido y el formato sonespecíficos de la aplicación.la longitud de la carga útilse calcula de la siguiente manera:con fijo
la longitud restante en el encabezadoel valor del campo de longitud disminuyemenos la longitud del encabezado variable.contiene cerolongitud de la carga útilde PUBLISH mensajeel paquete es válido.
3.3.4 Respuesta
PUBLISH paqueteel receptordebesegúnsegún PUBLISH en el mensaje QoS respuesta de envío de nivelrespuesta, véase la siguiente tabladescripción del formato [MQTT-
3.3.4-1]。
tabla 3.4 – PUBLISH la expectativa del paqueteRespuesta
Nivel de calidad de servicio
respuesta esperada
QoS 0
sin respuesta
QoS 1
PUBACK paquete
QoS 2
PUBREC paquete
3.3.5 Acción
el cliente utiliza PUBLISH el paquete envía mensajes de aplicaciónal servidor, el propósito es distribuira otras suscripciones coincidentesclientes coincidentes.
el servidor utiliza PUBLISH el paquete envía mensajes de aplicaciónmensaje a cadasuscripcióncoincidenciadel cliente.
el cliente utiliza un filtro con comodinesel filtro de temas con comodínCuando el filtro solicita la suscripción, el clientela suscripción del cliente puedepuede repetirse，por lo tantoEl mensaje publicado puede coincidir con múltiples
un filtro. Paraen este caso, el servidorextremo de serviciodebedistribuirá el mensaje atodas las suscripciones coincidenasignados QoS esperarel cliente con el nivel más alto [MQTT-3.3.5-
1]. del servidordespués se puede según la suscripciónde QoS nivel, distribuyendo la copia del mensajea cadasuscriptor coincidente。
recibir un PUBLISH mensajecuando el mensaje,acción del receptordepende de 4.3 la seccióndescrito QoS esperarnivel.
SiLa implementación del servidor no autoriza a un clienteel cliente publica PUBLISH el paquete,No tiene manera de notificar aquello.cliente. Estedebesegún la normanormal
QoS reglas de envíoenviar una confirmación positivaconfirmación, ocerrar la conexión de red [MQTT-3.3.5-2]。
3.4 PUBACK –Publicarconfirmación de publicación
PUBACK paquetees correcto QoS 1 nivelde PUBLISH mensajerespuesta del mensaje。
3.4.1 cabecera fija
leyenda 3.12 - PUBACK mensajedocumento fijoinformeCabeza
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT paquete de controltipo de mensaje (4)
bits reservados
0
1
0
0
0
0
0
0
MQTT-3.1.1-CN 34
byte 2
Longitud restante(2)
0
0
0
0
0
0
1
0
El campo de longitudrestante
que representa el encabezado variablelongitud. Para PUBACK paqueteeste valor es igual a 2.
3.4.2 cabecera variable
que contiene paquetes en espera de confirmación PUBLISH el encabezado del mensajeidentificador de paquete.
leyenda 3.13 – PUBACK cabecera variable del paquete
Bit
7
6
5
4
3
2
1
0
byte 1
identificador de paquete MSB
byte 2
identificador de paquete LSB
3.4.3 carga útil
PUBACK paquetesin carga útil。
3.4.4 Acción
véase la descripción completa en 4.3.2 sección.
3.5 PUBREC – Publicarrecibido (QoS 2, primer paso)
PUBREC mensajeel mensaje es una respuesta a QoS nivel 2 de PUBLISH mensajela respuesta del paquete. Es QoS 2 interacción de protocolo de nivelel segundo paquete del intercambiodocumento.
3.5.1 cabecera fija
leyenda 3.14 – PUBREC fijo del mensajecabecera
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT paquete de controltipo de mensaje e (5)
bits reservados
0
1
0
1
0
0
0
0
byte 2
Longitud restante (2)
0
0
0
0
0
0
1
0
El campo de longitudrestante
que representa el encabezado variablelongitud. Para PUBREC mensajeel mensaje, suvalor igual a 2。
3.5.2 cabecera variable
el encabezado variable contiene el identificador de paquete en espera de confirmaciónpendiente de confirmación PUBLISH mensajeidentificador de paquete delidentificador.
MQTT-3.1.1-CN 35
leyenda 3.15 – PUBREC variable del mensajecabecera
Bit
7
6
5
4
3
2
1
0
byte 1
identificador de paquete MSB
byte 2
identificador de paquete LSB
3.5.3 carga útil
PUBREC mensajeel paquete no tiene carga útil。
3.5.4 Acción
véase la descripción completa en 4.3.3 sección.
3.6 PUBREL – Publicarliberación (QoS 2, segundo paso)
PUBREL paquetees correcto PUBREC la respuesta al paquete.Es QoS 2 esperardel intercambio de protocolo a nivelel tercer paquete.
3.6.1 cabecera fija
leyenda 3.16 – PUBREL cabecera fija del paquete
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT paquete de controltipo de mensaje (6)
bits reservados
0
1
1
0
0
0
1
0
byte 2
Longitud restante (2)
0
0
0
0
0
0
1
0
PUBREL Controlencabezado fijo del paqueteel primero de la cabecera 3,2,1,0 el bit es un bit de retención，debese establece en 0,0,1,0. El servicioextremodebecualquier otro valor
se considera no válidoy cerrar la redconexión [MQTT-3.6.1-1]。
El campo de longitudrestante
que representa el encabezado variablelongitud. Para PUBREL mensajeel valor de este paquete es igualque 2.
3.6.2 cabecera variable
el encabezado variable contiene el mismoen espera de confirmación PUBREC paqueteel mismo identificador del paqueteidentificador.
leyenda 3.17 – PUBREL cabecera variable del paquete
Bit
7
6
5
4
3
2
1
0
byte 1
identificador de paquete MSB
byte 2
identificador de paquete LSB
MQTT-3.1.1-CN 36
3.6.3 carga útil
PUBREL paquetesin carga útilcarga.
3.6.4 Acción
véase la descripción completa en 4.3.3 sección.
3.7 PUBCOMP – publicación completada (QoS 2, tercer paso)
PUBCOMP mensajeel mensaje es una respuesta a PUBREL mensajerespuesta del mensaje. Es QoS 2 nivelel del intercambio de protocoloel cuarto y últimoun paquete.
3.7.1 cabecera fija
leyenda 3.18 – PUBCOMP mensaje fijocabecera fija
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT paquete de controltipo de mensaje (7)
bits reservados
0
1
1
1
0
0
0
0
byte 2
Longitud restante (2)
0
0
0
0
0
0
1
0
El campo de longitudrestante
que representa el encabezado variablelongitud. Para PUBCOMP mensajeeste documentoun valor igual a 2。
3.7.2 cabecera variable
el encabezado variable contiene el mismoen espera de confirmación PUBREL paqueteel mismo paqueteidentificador.
leyenda 3.19 – PUBCOMP el mensaje puedecabecera variable
Bit
7
6
5
4
3
2
1
0
byte 1
identificador de paquete MSB
byte 2
identificador de paquete LSB
3.7.3 carga útil
PUBCOMP mensajeel mensaje no tienecarga útil.
3.7.4 Acción
véase la descripción completa en 4.3.3 sección.
MQTT-3.1.1-CN 37
3.8 SUBSCRIBE - Suscribir tema
el cliente al servidorel SUBSCRIBE el mensaje se utiliza paracrear una o mássuscripciones. Cadala suscripción registra el interés del clienteen un tema que le interesao más
tema. Para que la aplicaciónreenviar mensajes de aplicación aque coinciden con esas suscripcioneslos temas coincidentes, el servidorel servidor envía PUBLISH mensajepaquete al cliente。SUBSCRIBE
el paquete también (para cadasuscripción) especificael máximo QoS esperarnivel, el servidorenviar de acuerdo con estoMensaje de aplicación al cliente.
3.8.1 cabecera fija
leyenda 3.20 – SUBSCRIBE mensaje fijocabecera fija
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT paquete de controltipo de mensaje (8)
bits reservados
1
0
0
0
0
0
1
0
byte 2
Longitud restante
SUBSCRIBE ordencabecera fija del paquete de controlel ordinal 3,2,1,0 Posiciónestá reservadoposición,debese establecen respectivamente como 0,0,1,0. El servidordebecualquier otra
cualquier valor se considera noválido y cerrarConexión de red [MQTT-3.8.1-1]。
El campo de longitudrestante
igual ala longitud de la cabecera variable (2 va antes del byte de orden bajo) más la carga útillongitud de la carga.
3.8.2 cabecera variable
el encabezado variable contiene el identificador del clienteidentificador del cliente.2.3.1 Proporcionainformación sobre el paquetemás información del identificador。
3.8.2.1 encabezado variableencabezado no normativoEjemplo
leyenda 3.21 – identificador de paqueteigual a 10 de la cabecera variable, ejemplo no normativoEjemplo muestra el mensajeel identificador del paquete se establece en 10 encabezado variable cuando
encabezado.
leyenda 3.21 – paqueteidentificadorsímbolo igual 10 posibleiable de cabeceracabecera, ejemplo no normativoEjemplo
Descripción
7
6
5
4
3
2
1
0
identificador de paquete
byte 1
identificador de paquete MSB (0)
0
0
0
0
0
0
0
0
byte 2
identificador de paquete LSB (10)
0
0
0
0
1
0
1
0
3.8.3 carga útil
SUBSCRIBE del mensajecarga útilcontiene un temalista de filtros de tema,Ellos representan al clienteEl tema al que el cliente desea suscribirse。SUBSCRIBE
paqueteLos filtros de tema en la carga útillistadebeSí 1.5.3 la seccióndefinido UTF-8 cadena [MQTT-3.8.3-1]. servicioextremo de serviciodeberíaAdmite
contiene comodines (4.7.1 sección determinadadel significado) delfiltro de tema. Por ejemploSi el servidor elige no soportarque contienen comodinesfiltro de tema,deberechazar
cualquier filtro que contenga comodinesla suscripción del filtrosolicitud [MQTT-3.8.3-2]。después de cada filtroseguido de un byte, este byte sese llama servicio
requisito de calidad de servicio (Requested QoS）. Le da al servidorel servidor al clienteel cliente envía mensajes de aplicaciónlo permitido por el mensajepuede tener como máximo QoS nivel.
MQTT-3.1.1-CN 38
SUBSCRIBE del mensajecarga útildebeincluyenComo mínimoun parFiltro de tema y QoS nivelcombinación de campos.sin carga útilde
SUBSCRIBE mensajeel paquete es una violación del protocolo.de [MQTT-3.8.3-3]。relativo al manejo de erroresconsulte la información relevante 4.8 sección.
el máximo nivel de servicio solicitadocampo de nivel de calidad de serviciocodificado como una palabrasección, después de la cualseguir UTF-8 codificaciónel nombre del tema codificado,esos filtros de tema /y
QoS combinación de nivelesse empaquetan de forma contigua
leyenda 3.22 – SUBSCRIBE paquetecarga útilFormato
Descripción
7
6
5
4
3
2
1
0
Filtro de tema
byte 1
longitud MSB
byte 2
longitud LSB
bytes 3..N
Filtro de tema（Topic Filter）
Requisitos de calidad de servicio (Requested QoS）
bits reservados
Nivel de calidad de servicio
byte N+1
0
0
0
0
0
0
X
X
Protocolo de la versión actualno utiliza el serviciorequisitos de calidad (Requested QoS）los seis bits superiores del byte. Si es válidocualquier parte de la carga útilel bit no es
valor cero,o QoS no es igual 0,1 o 2, el servidordebeconsidera SUBSCRIBE paquetes sonno válido ycerrar la conexión de red [MQTT-
3-8.3-4]。
3.8.3.1 carga útilcarga no normativaEjemplo
leyenda 3.23 – byte de carga útilformato de sección no estándarejemplo mostrarya tabla 3.5 – tenercarga útil no normativaEjemplo en la descripción concisa
SUBSCRIBE mensajela carga útil del documento。
tabla 3.5 – carga útilcarga noejemplo normativo
Nombre del tema
“a/b”
requisitos de calidad de servicio
0x01
Nombre del tema
“c/d”
requisitos de calidad de servicio
0x02
leyenda 3.23 – útilcargaformato de bytes noejemplo normativoEjemplo
Descripción
7
6
5
4
3
2
1
0
filtro de temas (Topic Filter）
byte 1
Length MSB (0)
0
0
0
0
0
0
0
0
byte 2
Length LSB (3)
0
0
0
0
0
0
1
1
byte 3
‘a’ (0x61)
0
1
1
0
0
0
0
1
MQTT-3.1.1-CN 39
byte 4
‘/’ (0x2F)
0
0
1
0
1
1
1
1
byte 5
‘b’ (0x62)
0
1
1
0
0
0
1
0
Requisitos de calidad de servicio (Requested QoS）
byte 6
Requested QoS(1)
0
0
0
0
0
0
0
1
filtro de temas (Topic Filter）
byte 7
Length MSB (0)
0
0
0
0
0
0
0
0
byte 8
Length LSB (3)
0
0
0
0
0
0
1
1
byte 9
‘c’ (0x63)
0
1
1
0
0
0
1
1
byte 10
‘/’ (0x2F)
0
0
1
0
1
1
1
1
byte 11
‘d’ (0x64)
0
1
1
0
0
1
0
0
Requisitos de calidad de servicio (Requested QoS）
byte 12
Requested QoS(2)
0
0
0
0
0
0
1
0
3.8.4 Respuesta
El servidor recibe al clienteuno enviado por el extremo SUBSCRIBE Cuando el mensaje,debeUsar SUBACK Respuesta de paquete [MQTT-3.8.4-1]。
SUBACK paquetedebey esperando confirmación SUBSCRIBE paquetetienen el mismo identificador de paquetecarácter [MQTT-3.8.4-2]。
Permitir al servidor enviarenviar primero un paquete DISCONNECT, cerró SUBACK mensajeantes del textocomienza a enviar la suscripcióncoincidente PUBLISH paquete.
Si el servidor recibeun SUBSCRIBE paquete, paqueteel filtro de temas y el de una suscripción existentefiltros de temas entre síigual,entoncesdebe
Usar la nueva suscripción por completoreemplazo de la base existentesuscripción. El tema de la nueva suscripciónfiltros y anteslos mismos que la suscripción,peroel máximo de QoS Valorpuede no
igual.Los que coinciden con este filtro de temacualquier retención existentemensaje retenidodebese reenvía,pero el flujo de publicaciónno puedeMediocortar [MQTT-3.8.4-3]。
Si el filtro de temadiferente de cualquier existenteAlmacenar los filtros de suscripción, el servidorel servidor creará ununa nueva suscripción y enviar todosretenido coincidentemensaje.
Si el servidor recibecontiene múltiples temasdel filtro SUBSCRIBE el paquete,ellodebecomo si hubiera recibido una serie dede múltiples SUBSCRIBE
Tratar el mensaje de la misma manera, entoncesun,exceptonecesita sus respuestasfusionar en un soloindependiente SUBACK paqueteel [MQTT-3.8.4-4]。
El servidor envía al clientedel cliente SUBACK mensajepar de documentoscada par de filtros de tema y QoS esperartodos los nivelesdebecontiene un código de retorno.EsteDevuelve
10debeindica que esa suscripción fue concedidael máximo concedido QoS nivel,oindica que esta suscripción falló [MQTT-3.8.4-5]. El servidor puedepara otorgar que
El nivel bajo solicitado por el suscriptoralgunos QoS nivel.Enviado en respuesta a la suscripcióndel mensaje salientede la carga útil QoS debees del mensaje de publicación original
QoS y serviciootorgado por el extremo QoS de los dosvalor mínimo. Si el mensaje originaldel mensaje QoS Sí 1 Y el máximo otorgado QoS Sí 0, permitepermitir servicio
El servidor reenvía uncopia del mensajea los suscriptores [MQTT-3.8.4-6]。
no normativoEjemplo
Para un tema específicofiltro de tema,Sique está suscribiéndosese concede al clienteel máximo de QoS esperarel nivel es 1, entoncescoincide con este filtro
del filtro QoS nivel 0 El mensaje de aplicación se procesará según QoS nivel 0 distribuir a este cliente.esto significa que el clienteEl cliente recibirá como máximo este
MQTT-3.1.1-CN 40
Una copia del mensaje. Por otro ladoes decir, publicar al mismode un tema QoS nivel 2 el mensaje deserá degradado por el servidor a QoS esperar
nivel 1 redistribuir aCliente, por lo tanto el clienteel cliente podría recibirmensajes duplicadoscopia.
Si el que se está suscribiendose concede al clienteel máximo de QoS el nivel es 0, entoncesoriginalmente según QoS nivel 2 publicado ala aplicación del cliente
El mensaje en momentos de carga puedepuede perderse,peroel servidor no debedebe enviar duplicadoscopia del mensaje. Publicar al mismode un tema QoS nivel
1 del mensaje en transmisiónCuando se entrega al cliente puedepuede perderse o duplicarse.
no normativoComentario:
Usar QoS nivel 2 reservarSuscribirse a un filtro de tema igual aes decir:
Quiero publicar de acuerdo con ellos.cuando
QoS
Aceptar el nivel que coincide con esteunidad
mensajes del filtro
. Esto significa que,determinarposible durante la distribución de mensajespuede tener como máximo QoS esperarel nivel es el publicadorla responsabilidad, yel suscriptor puede
Solicitar al servidor que reduzca QoS a más adecuadocorresponde a su nivel.
3.9 SUBACK – Confirmación de suscripción
el servidor envía SUBACK mensaje al cliente, para confirmarloque ha recibido y estáen el proceso SUBSCRIBE paquete.
SUBACK paquetecontiene un retornolista de códigos, ellosespecificó SUBSCRIBE solicitarde la solicitudcada suscripción esel máximo otorgado QoS esperarnivel.
3.9.1 cabecera fija
leyenda 3.24 – SUBACK cabecera fija del paquete
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT paquete de controltipo de mensaje (9)
bits reservados
1
0
0
1
0
0
0
0
byte 2
Longitud restante
El campo de longitudrestante
Igual al del encabezado variablela longitud más la cargaLa longitud de la carga útil.
3.9.2 cabecera variable
el encabezado variable contiene el identificador de paquete en espera de confirmaciónpendiente de confirmación SUBSCRIBE mensajedel documentoidentificador de mensaje.leyenda 3.25 – SUBACK mensajeencabezado variable del mensaje describe lo que se puede
El formato del encabezado variable.
leyenda 3.25 – SUBACK cabecera variable del paquete
Bit
7
6
5
4
3
2
1
0
byte 1
identificador de paquete MSB
byte 2
identificador de paquete LSB
MQTT-3.1.1-CN 41
3.9.3 carga útil
la carga útil contiene unouna lista de códigos de retorno. Cada código de retornocorresponde a la confirmación pendientede SUBSCRIBE uno de los paquetesun filtro de temas. Devuelve
el orden de los códigosdebey SUBSCRIBE paqueteel orden de los filtros de temamismo [MQTT-3.9.3-1]。
leyenda 3.26 – SUBACK mensajecarga útil del paqueteFormato describecarga útil individualva antes del byte de orden bajoel retorno codificadocampo de código.
leyenda 3.26 – SUBACK formato de la carga útil del mensaje
Bit
7
6
5
4
3
2
1
0
código de retorno
byte 1
X
0
0
0
0
0
X
X
Valores de código de retorno permitidos：
0x00 - puede tener como máximo QoS 0
0x01 - éxito – puede tener como máximo QoS 1
0x02 - éxito – puede tener como máximo QoS 2
0x80 - Failure fracaso
0x00, 0x01, 0x02, 0x80 exceptode SUBACK regresarel código de retorno está reservadode,no puedeUsar [MQTT-3.9.3-2]。
3.9.3.1 carga útilcarga no normativaEjemplo
leyenda 3.27 -carga útilejemplo no normativo de formato de bytes se muestra en tabla 3.6 -tenerejemplo no normativo de carga útil de la descripción breve
SUBACK paquetede la carga útil.
tabla 3.6 -carga útilno normativoEjemplo
Success - Maximum QoS 0
0
Success - Maximum QoS 2
2
Failure
128
leyenda 3.27 -carga útilformato de bytesejemplo no normativo
Descripción
7
6
5
4
3
2
1
0
byte 1
Success - Maximum QoS 0
0
0
0
0
0
0
0
0
byte 2
Success - Maximum QoS 2
0
0
0
0
0
0
1
0
byte 3
Failure
1
0
0
0
0
0
0
0
3.10 UNSUBSCRIBE –Cancelar suscripción
el cliente envía UNSUBSCRIBE paqueteal servidor,para cancelar la suscripcióntema de suscripción.
MQTT-3.1.1-CN 42
3.10.1 cabecera fija
leyenda 3.28 – UNSUBSCRIBE cabecera fija del paquete
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT tipo de paquete de control (10)
bits reservados
1
0
1
0
0
0
1
0
byte 2
Longitud restante
UNSUBSCRIBE mensajedocumento fijodel encabezado fijo, el 3,2,1,0 el bit está reservadoreservado ydebeestablecer respectivamentePara 0,0,1,0。Servidordebeconsidera que cualquiersu
Sus valores son todos inválidoslegal y cerrar la redconexión de red [MQTT-3.10.1-1]。
El campo de longitudrestante
Igual al del encabezado variablela longitud más la cargaLa longitud de la carga útil.
3.10.2 cabecera variable
El encabezado variable contiene unun identificador de paquete。2.3.1 la secciónproporciona información sobremás sobre el identificador de paqueteinformación.
leyenda 3.29 – UNSUBSCRIBE cabecera variable del paquete
Bit
7
6
5
4
3
2
1
0
byte 1
identificador de paquete MSB
byte 2
identificador de paquete LSB
3.10.3 carga útil
UNSUBSCRIBE del mensajeútilla carga útil contiene al clienteEl cliente desea cancelar la suscripción al temalista de filtros de temas。UNSUBSCRIBE en el mensaje
TemafiltrodebeEstán empaquetados de forma continua,según 1.5.3 sección determinadapredefinidos UTF-8 codificacióncadenas codificadas [MQTT-3.10.3-1]。
UNSUBSCRIBE del mensajeútilcargadebeComo mínimoincluyenUn filtro de mensaje. no hay carga útilde carga UNSUBSCRIBE paquetes son
que viola el protocolo [MQTT-3.10.3-2]. HayMás información sobre el manejo de erroresconsulte 4.8 sección.
3.10.3.1 carga útil no válidanormativoEjemplo
leyenda 3.30 -carga útilFormato de bytes no normativoEjemplo muestra tabla 3.7 -útilEjemplo no normativo de carga útil de la descripción breve
UNSUBSCRIBE del mensajeútilcarga útil.
tabla 3.7 -carga útilmuestra no normativaEjemplo
Filtro de tema
“a/b”
Filtro de tema
“c/d”
MQTT-3.1.1-CN 43
leyenda 3.30 -carga útilformato de bytesNo normativoejemplo
Descripción
7
6
5
4
3
2
1
0
Filtro de tema
byte 1
Length MSB (0)
0
0
0
0
0
0
0
0
byte 2
Length LSB (3)
0
0
0
0
0
0
1
1
byte 3
‘a’ (0x61)
0
1
1
0
0
0
0
1
byte 4
‘/’ (0x2F)
0
0
1
0
1
1
1
1
byte 5
‘b’ (0x62)
0
1
1
0
0
0
1
0
Filtro de tema
byte 6
Length MSB (0)
0
0
0
0
0
0
0
0
byte 7
Length LSB (3)
0
0
0
0
0
0
1
1
byte 8
‘c’ (0x63)
0
1
1
0
0
0
1
1
byte 9
‘/’ (0x2F)
0
0
1
0
1
1
1
1
byte 10
‘d’ (0x64)
0
1
1
0
0
1
0
0
3.10.4 Respuesta
UNSUBSCRIBE mensajeel documento proponeel filtro de tema proporcionado (sin importar si contieneComodín）debecon este que mantiene el servidorel actual del clienteprincipal
Colección de filtros de tema, uno por unouna comparación de caracteres.Si hay algún filtro completocoincidencia completa,entonces este (servidorpropio del servidor)La suscripción será eliminada,de lo contrario
No habrá másprocesamiento [MQTT-3.10.4-1]。
Si el servidor eliminauna suscripción:
ellodebedetener la distribución de cualquier mensaje nuevomensaje a este clientecliente [MQTT-3.10.4-2]。
ellodebecompletar la distribución de cualquier mensaje yacomienza a enviar al clienteenviado por el extremo QoS 1 y QoS 2 el mensaje de [MQTT-3.10.4-3]。
ellopuedecontinuar enviando cualquier mensaje existentela preparación para la distribucióncaché para el clientemensaje almacenado.
Servidordebeel UNSUBACK Respuesta de paquetedel cliente UNSUBSCRIBE Solicitud.UNSUBACK paquetedebeincluye y
UNSUBSCRIBE mensajedocumentos relacionadosEl mismo identificador de mensaje [MQTT-3.10.4-4]。incluso sino elimina ningúncualquier suscripción de tema,el servidor tambiéndebePublicar
enviar un SUBACK Respuesta [MQTT-3.10.4-5]。
Si el servidor recibecontiene múltiples temasdel filtro UNSUBSCRIBE el paquete,ellodebecomo si hubiera recibido una serie demúltiples
UNSUBSCRIBE mensajeun documentoprocesar ese mensaje de esta manera,además defusionar sus respuestas en una solaun solo UNSUBACK fuera del mensaje.
[MQTT-3.10.4-6]。
3.11 UNSUBACK – Cancelar suscripciónAcuse de recibo
el servidor envía UNSUBACK paqueteal cliente para confirmar la recepciónllegar UNSUBSCRIBE paquete.
MQTT-3.1.1-CN 44
3.11.1 cabecera fija
leyenda 3.31 – UNSUBACK mensaje fijocabecera fija
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT paquete de controltipo de mensaje (11)
bits reservados
1
0
1
1
0
0
0
0
byte 2
Longitud restante (2)
0
0
0
0
0
0
1
0
El campo de longitudrestante
que representa el encabezado variablelongitud, para UNSUBACK este mensajeun valor igual a 2。
3.11.2 cabecera variable
el encabezado variable contiene el identificador de paquete en espera de confirmaciónpendiente de confirmación UNSUBSCRIBE paqueteEl identificador de mensaje.
leyenda 3.32 – UNSUBACK el mensaje puedecabecera variable
Bit
7
6
5
4
3
2
1
0
byte 1
identificador de paquete MSB
byte 2
identificador de paquete LSB
3.11.3 carga útil
UNSUBACK el mensaje no tienecarga útil。
3.12 PINGREQ – Solicitud de ping
el cliente envía PINGREQ paquetePara el servidor. Useen:
1. Sin ningún otropaquete de control desde el clientecuando el cliente envía al servidor,informar al servidor del clienteel cliente sigue vivo.
2. Solicitar al servidor que envíe la respuesta confirma que todavíavivo.
3. Usar la red para confirmarla conexión de red nodesconectar.
Keep Alive (Keep Alive）procesamientoutilizado eneste paquete,detalladoinformación, consulte 3.1.2.10 sección.
3.12.1 cabecera fija
leyenda 3.33 – PINGREQ cabecera fija del paquete
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT tipo de paquete de control (12)
bits reservados
MQTT-3.1.1-CN 45
1
1
0
0
0
0
0
0
byte 2
Longitud restante (0)
0
0
0
0
0
0
0
0
3.12.2 cabecera variable
PINGREQ mensajeEl mensaje no tiene cabecera variable。
3.12.3 carga útil
PINGREQ mensajeel paquete no tiene carga útil。
3.12.4 Respuesta
Servidordebeel PINGRESP Respuesta de paquetedel cliente PINGREQ paquete [MQTT-3.12.4-1]。
3.13 PINGRESP – Respuesta de ping
el servidor envía PINGRESP el paquete responde al clientedel cliente PINGREQ paquete.representael servidor sigue vivoestá.
Keep Alive (Keep Alive）procesamientoutilizado eneste paquete,detallesconsulte 3.1.2.10 sección.
3.13.1 cabecera fija
leyenda 3.34 – PINGRESP mensaje fijocabecera fija
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT tipo de paquete de control (13)
bits reservados
1
1
0
1
0
0
0
0
byte 2
Longitud restante (0)
0
0
0
0
0
0
0
0
3.13.2 cabecera variable
PINGRESP paqueteno hay encabezado variableencabezado.
3.13.3 carga útil
PINGRESP paquetesin carga útilcarga.
3.14 DISCONNECT –Desconectar
DISCONNECT El paquete es enviado por el cliente al servidorel último del servidorun paquete de control.indica que el cliente se desconectó normalmenteconexión.
MQTT-3.1.1-CN 46
3.14.1 cabecera fija
leyenda 3.35 – DISCONNECT paquetecabecera fija
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT tipo de paquete de control (14)
bits reservados
1
1
1
0
0
0
0
0
byte 2
Longitud restante (0)
0
0
0
0
0
0
0
0
Servidordebeverificar todos los retenidoslos bits reservados se establecena 0, siellos no son 0 debeDesconectar [MQTT-3.14.1-1]。
3.14.2 cabecera variable
DISCONNECT El paquete no tiene encabezado variable.
3.14.3 carga útil
DISCONNECT el paquete no tiene carga útilcarga útil.
3.14.4 Respuesta
el cliente envía DISCONNECT mensajedespués del mensaje:
debecerrar la conexión de red [MQTT-3.14.4-1]。
no puedeA través de esa conexión de red de nuevoenviar cualquier controlpaquete de control [MQTT-3.14.4-2]。
el servidor al recibir DISCONNECT cuando el mensaje:
debeDescartar cualquier cosa con la conexión actualel no enviado asociadodesconectada.El testamentomensaje, ver la descripción específica en 3.1.2.5 la sección [MQTT-3.14.4-3]。
deberíaCerrar la conexión de red,Si el cliente Aún no lo ha hecho.
MQTT-3.1.1-CN 47
4 Comportamiento de operación
4.1 Almacenamiento de estado
Para proporcionar la calidad de serviciogarantía de calidad, el clienteel cliente y el servidor tienennecesario almacenar la sesiónestado. Durante toda la sesiónentre, el clientecliente y servidorclientedebe
almacenar el estado de la sesión [MQTT-4.1.0-1]. Sesióndebeal menos durante el tiempo que su conexión de red activala conexión de red de la misma duracióntiempo de este [MQTT-4.1.0-2]。
El mensaje retenido por el servidorla información no es el estado de sesióncomponente del estado. El servidordeberíaretener ese tipo de mensajemensaje hasta que el cliente lo elimine.
no normativoComentario:
Entre el cliente y el servidorel almacenamiento implementadocapacidadnecesariamente es finitode, también puede necesitarsujeto a la política de gestiónrestricciones, como a través desesión de conexión de red
El almacenamiento máximo del estado de la sesióntiempo de almacenamiento. Guardadoestado de sesión guardadola pérdida puede ser algunacausado por una operación de administración,por ejemplo, paraalguna condición predefinida
La respuesta automática del componente.las consecuencias que causaes decir, terminación de la sesión. Estas operaciones puedenser limitaciones de recursoso provocado por otras razones operativasde. Necesita
Evaluar cuidadosamente al clientecliente y servidorde la capacidad de almacenamiento,para asegurar que el espacio de almacenamientotiempo suficiente.
no normativoComentario:
El cliente o el servidorde fallos de hardware y softwarepuede provocar que el estado de la sesiónde pérdida o daño。
no normativoComentario:
El servidor y el clienteel funcionamiento normal puedesignifica que el estado guardadopérdida o daño del estadoes una operación de administración o de software/hardwarecausado por fallos.
La operación de administración puede serpara un predefinidorespuesta automática a las condiciones. Estoalgunas operaciones pueden serlimitaciones de recursos u otras operacionesprovocado por una causa.
Por ejemplo, el servidor puedepodría basarse en el exteriorcondiciones, decidir noun mensaje de nuevoo ciertos mensajes se distribuyan a cualquiercualquier actual oel cliente posterior
cliente.
no normativoComentario:
MQTT el usuario debedebe evaluar MQTT la implementación del cliente y del servidorde la capacidad de almacenamiento,garantizar que se satisfagan las necesidadessolicitud.
4.1.1 ejemplo no normativo
Por ejemplo, si se desea recopilaruso de las lecturas del medidorel usuario podría decidir usar QoS 1 nivelde los mensajes, porque ellos no puedenaceptar datos en la redtransmisión de red
se pierde en, pero,ellos podrían pensarlos datos del cliente y del servidorlos datos se pueden almacenar enmemoria (memoria volátil), porque (ellos sienten
El suministro de energía esmuy fiable,no habrá demasiadoRiesgo de pérdida de datos.
Por el contrario, estacionaraplicaciones de facturación y pagoEl proveedor puede decidir cualquierbajo ninguna circunstanciaPuede causar la pérdida de mensajes de datospérdida,por lo tantoellos requieren que en
Transmisión a través de la redantes, todos los datoslos datos deben escribirse enalmacenamiento no volátilen el dispositivo (como el disco duro）。
4.2 Conexión de red
MQTT el protocolo debesolicitar el transporte básicola capa pueda proporcionarordenado y confiablede,bidireccionaltransmisión (desde el cliente hastaServidor y desdedel servidor al cliente
Flujo de bytes del extremo.
no normativoComentario:
MQTT 3.1 HacerProtocolo de capa de transporte utilizadoSí [RFC793] definido TCP/IP cooperarprotocolo.el siguiente protocolo tambiénsoporte:
MQTT-3.1.1-CN 48
TLS protocolo [RFC5246]
WebSocket protocolo [RFC6455]
no normativoComentario:
TCP puerto 8883 y 1883 ya en IANA Nota.registro, respectivamente para MQTT de TLS y no TLS comunicación.
Transmisión de red sin conexiónprotocolo de transporte como UDP Síno soportado,porque ellos puedenpuede perder datoso reordenar paquetes de datos。
4.3 El nivel de calidad de servicio y el flujo de protocolo
MQTT según estoel servicio definido encalidad del servicio (QoS) aplicaciones de distribución por nivelesMensaje. DistribuciónEl protocolo es simétrico, en lo que sigueen la siguiente descripción,Cliente
y el servidor puede tantoel emisor también puedepuede ser el receptor.el protocolo de distribución se centra enes desde un único remitente ade un solo receptormensajes de aplicación.servicio
extremo de servicioDistribuir mensajes de aplicación a múltiples clientescuando el cliente, cadael cliente procesa de forma independiente. Se distribuye al clienteaplicación de salida del extremomensajes y mensajes de aplicación entrantes
de QoS el nivel puedepuede ser diferente.
El siguiente flujo no normativoel diagrama de flujo muestra que se puedeposibles métodos de implementación。
4.3.1 QoS 0:como máximo una vez
La distribución de mensajes dependede la red subyacentecapacidad. El receptorno enviará respuesta, el remitente tampocoreintentará. El mensajepuede entregarse una vez o también
no se entregó en absoluto.
Para QoS 0 deprotocolo de distribución, el emisorremitente
debeel QoS igual a 0，DUP igual a 0 de PUBLISH paquete [MQTT-4.3.1-1]。
Para QoS 0 deprotocolo de distribución, el receptorceptor
Aceptan PUBLISH al recibir el mensaje, simultáneamente recibetodos los mensajes recibidospermiso.
leyenda 4.1 – QoS 0 flujo del protocolodiagrama de flujo,no normativoEjemplo
remitenteAcción
Paquete de control
receptorAcción
PUBLISH paquete QoS 0, DUP=0
---------->
Distribuir mensajes de aplicación areceptores posteriores apropiadosrecibir
persona(s)
4.3.2 QoS 1: Como mínimodividiruna vez
servicioel servidorcalidadcantidadConfirmarprotegercancelarinformaciónhastapocoenviar primero un paquete DISCONNECT, cerróalcanzarunavez。QoS 1 de PUBLISH mensajetextodevarcambiarmensajeCabezaMedioPaqueteincluyenunaunidadmensajetextomarcaseñacarácter，Necesitaquerer
PUBACK paqueteconfirmación.2.3.1 la secciónproporciona información sobre el identificador del paquetemás información del identificador。
Para QoS 1 deprotocolo de distribución, el emisorremitente
Cada vez que envía una nueva aplicaciónusar todos los mensajesdebeasignar un no utilizadoEl identificador de paquete utilizadocarácter.
enviado PUBLISH paquetedebeincluyenidentificador de mensaje y QoS igual a 1，DUP igual a 0。
MQTT-3.1.1-CN 49
debeeste PUBLISH mensajeel texto se considera como
no confirmado
，hasta querecibir del receptor el correspondiente PUBACK paquete.4.4 la sección
Hay uno sobre lo no confirmadodiscusión del reconocimiento de mensajes。
[MQTT-4.3.2-1].
Una vez que el remitente reciba PUBACK el paquete,Esteidentificador de paquetese puede reutilizar.
Nota:se permiteel emisor está esperando la confirmaciónal usar diferentesEl identificador de paquete envía los siguientesde PUBLISH paquete.
Para QoS 1 deprotocolo de distribución, el receptorceptor
de la respuesta PUBACK paquetedebecontiene unidentificador de mensaje,usando este identificadordel recibido,ya ha aceptado todosdel permiso
PUBLISH paquete.
envió PUBACK mensajedespués del texto,el receptor debecualquiera que contenga el mismoel entrante del identificador de paquete PUBLISH paquetecomo un
un nuevo mensaje, yignorar su DUP marcael valor de la marca.
[MQTT-4.3.2-2].
leyenda 4.2 – QoS 1 flujo del protocolodiagrama de flujo,no normativoEjemplo
remitenteAcción
Paquete de control
receptorAcción
almacenar mensajes
el PUBLISH paquete QoS=1,
DUP=0, con el mensajeidentificador
---------->
Comienzo del mensaje de aplicacióndistribución posterior
1
<----------
el PUBACK mensaje, con el mensajemarca
identificador
descartar mensajes
1
No se requiere que el receptorel PUBACK antes de la distribución completaEnviar mensajes de aplicación. El originalel emisor recibe PUBACK paquetedespués,
Todos los mensajes de aplicaciónel derecho se transferirá aeste receptor.
4.3.3 QoS 2: solamenteEntrega una vez
Este es el nivel más alto decalidad de servicio,mensajepérdida y duplicacióntodos son inaceptablesde. Usando esta calidad de servicioel nivel de calidad tendrá un adicionalsobrecarga externa.
QoS 2 la desaparicióninformación en el encabezado variableTiene identificador de paquete.2.3.1 la secciónproporciona información sobreel cambio del identificador de paquetemás información.QoS 2 de PUBLISH
el receptor del paquete utilizausando una confirmación de dos pasosProceso de acuse de recibo para confirmar la recepción.
Para QoS 2 deprotocolo de distribución, el emisorremitente
debe proporcionar a lo que se va a enviarnueva distribución de mensajes de aplicaciónAsignar un identificador de paquete no utilizadoidentificador.
elde PUBLISH paquetedebeincluyenidentificador de paquete y del paquete QoS igual a 2,，DUP igual a 0。
debeeste PUBLISH mensajeel texto se considera como
no confirmado
，hasta querecibir del receptor el correspondiente PUBREC paquete.4.4 la sección
Hay uno sobre lo no confirmadodiscusión del reconocimiento de mensajes。
MQTT-3.1.1-CN 50
Recibido PUBREC después del mensajedebeenviar un PUBREL paquete.PUBREL el mensaje debedebe contener conoriginal PUBLISH paquete
mismoEl identificador de mensaje.
debeeste PUBREL mensajeel texto se considera como
no confirmado
，hasta querecibir del receptor el correspondiente PUBCOMP paquete.
una vez que se ha enviado el correspondientede PUBREL entonces el mensajeno puedereenviar este PUBLISH paquete.
[MQTT-4.3.3-1].
Una vez que el remitente reciba PUBCOMP mensaje, esteel identificador de paquete se puede reutilizar。
Nota:se permiteel emisor está esperando la confirmaciónal usar diferentesEl identificador de paquete envía los siguientesde PUBLISH paquete.
ParaQoS 2del protocolo de distribución, recibirpersona
de la respuesta PUBREC paquetedebeincluyenidentificador de paquete, este identificadordel recibido, ya ha aceptado todosautorizado
PUBLISH paquete.
al recibir el correspondiente PUBREL antes del mensaje,receptordebeel PUBREC mensajeconfirmación de mensajecualquier subsiguiente que tenga la mismamismo identificador
de PUBLISH paquete. En este caso,ellono puedemensaje de distribución duplicadoa cualquier posteriorreceptor.
Respuesta PUBREL del mensaje PUBCOMP paquetedebecontiene con PUBREL mensajeidentificador del mismo mensajecarácter.
el PUBCOMP mensajedel documentodespués, el receptordebe contener el mismocualquiera con el mismo identificador de paqueteposterior PUBLISH mensajecuando el documentocomo un
una nueva publicación.
[MQTT-4.3.3-2].
leyenda 4.3 – QoS 2 flujo del protocolodiagrama de flujo,no normativoEjemplo
remitenteAcción
Paquete de control
receptorAcción
almacenar mensajes
el PUBLISH el paquete,QoS=2,
DUP=0, conidentificador de paquete
---------->
Método A: almacenar mensajes, o método B：
almacenar el identificador de paquetey luego comenzar aantes
distribuir este mensaje de aplicacióninformación
1
。
el PUBREC mensaje,con el indicador de mensaje
identificador.
<----------
descartar el mensaje, almacenar PUBREC en el
identificador de paquete
el PUBREL mensajemensaje, con mensajemarca
identificador
---------->
MQTT-3.1.1-CN 51
Método A: comienza a reenviar mensajes de aplicacióninformación
1
luego descartar el mensaje o método B：descartar
identificador de paquete
el PUBCOMP el paquete,con mensaje
identificador
<----------
descartar el estado guardadoestado
1
no requiere receptoral enviar PUBREC o PUBCOMP antes dela distribución completa debeusar el mensaje. El envío originalel receptor recibe
PUBREC mensajedespués del paquete, el mensaje de aplicaciónla propiedad del mensaje, entoncesse transferirá a este receptor。
leyenda 4.3 – QoS 2 protocolodiagrama de flujo, no normativoejemplo mostrarel receptor hacia QoS 2 esperardos tipos de mensajes de nivelmétodo de procesamiento.ellos
la diferencia es qué mensajecuándo se puede comenzar acomenzar la distribución. Implementaciónel implementador puede decidir usarusar qué método. Siempre queel implementador solo eligióuna forma
método,no afectará QoS flujofiabilidad del proceso.
4.4 reintento de distribución de mensajes
el cliente establece la limpiezasesión (CleanSession）banderasPara 0 reconexióncuando el clientey el servidordebeusando el originalreenviar el identificador de paquete original
cualquier no confirmado PUBLISH mensaje (si QoS>0) y PUBREL paquete [MQTT-4.4.0-1]. Esta es la únicaunarequisitocliente o
el servidor reenvía el mensajedel caso.
no normativoComentario:
el reenvío del paquete de controlfue necesario superaralgunos obsoletos TCP los datos en la redproblema de pérdida de datos.desplegados en esos entornos MQTT
3.1.1 realahora puede que todavía sea necesariopreocuparse por este problemaproblema.
4.5 Mensaje recibido
el servidor se hace cargo de la entradala propiedad de los mensajes de aplicacióncuando tiene derecho, estedebeel mensajeañadir a la suscripciónla sesión del cliente coincidenteen el estado.la regla de coincidencia define
véase el significado 4.7 la sección [MQTT-4.5.0-1]。
en condiciones normales, el clienteel cliente recibe el envíode su suscripciónmensaje. El clientetambién puede recibir algo que no está relacionado con élla suscripción coincide exactamentemensaje coincidente. Si
si el servidor automáticamente daal cliente se le asignóuna suscripción,posibleocurre esta situaciónsituación. Procesando UBSUBSCRIBE solicitudcuando también puede recibirllegar
mensaje. El clientedebesegún sea posiblela calidad de servicio utilizadacantidad (QoS) la regla confirma que lo recibióde cualquier PUBLISH el paquete,sin importarelloselecciónsi procesa
procesar la aplicación contenida en el paqueteUsar mensaje [MQTT-4.5.0-2]。
4.6 Ordenamiento de mensajes
implementar lo definido en este capítulodurante el flujo del protocolo,Clientedebesigue las siguientes reglasregla:
reenviar cualquier anterior PUBLISH mensajecuando el mensaje,debeSegún el original PUBLISH paquetedel orden de envíoreenviar en orden (si correspondese utiliza para QoS 1 y
QoS 2 mensaje）[MQTT-4.6.0-1]。
debesegún el correspondiente PUBLISH el envío ordenado de los paquetes PUBACK mensajedocumento (QoS 1 mensaje）[MQTT-4.6.0-2]。
debesegún el correspondiente PUBLISH el envío ordenado de los paquetes PUBREC Mensaje (QoS 2 mensaje）[MQTT-4.6.0-3]。
debesegún el correspondiente PUBREC el envío ordenado de los paquetes PUBREL Mensaje (QoS 2 mensaje）[MQTT-4.6.0-4]。
Servidordebepor defecto se asume que cadatodos los temas tienendel orden. EstopuedeProporcionar ununa función de administración ootros mecanismos, parapermitir asignar uno oVarios temas
tratar el tema como no ordenado [MQTT-4.6.0-5]。
MQTT-3.1.1-CN 52
el servidor procesa el envíoa temas ordenadoscuando el mensaje,debesegún lo anteriorciertas reglas para el mensajedistribuir el mensaje a cada suscriptor. Además, ellodebesegún
recibido del clienteenviar en orden PUBLISH mensajemensaje a los consumidores(para el mismo tematema y QoS）[MQTT-4.6.0-6]。
no normativoComentario:
las reglas enumeradas anteriormenteasegurar, usar QoS 1 Publicary el flujo de mensajes suscritos,el suscriptor según el mensajeel orden de publicación del mensajeRecibido en ordencada mensaje
mensajede la copia final, pero el mensaje puedepuede repetirse, lo quepuede causar que en sude su mensaje posteriorluego recibe un yaque ha recibido el mensaje
versión reenviada. Por ejemplo, el publicador en ordenorden 1,2,3,4 enviar mensaje, suscribirseel orden de recepciónPuede ser 1,2,3,2,3,4。
si el cliente y el servidorel servidor puede garantizar cualquieren cualquier momento hay como máximo un mensajemensaje en
en transmisión (
in-flight
）
(en cierto mensajeantes de que sea confirmado
no enviar el siguientemensaje), entoncesentonces,notener QoS 1 el mensaje deocurrirá en cualquiera de susrecibe después del mensaje subsiguiente。 Por ejemplo，
el orden en que el suscriptor recibeel orden puede ser 1,2,3,3,4, en lugar de 1,2,3,2,3,4. La ventana de transmisión （in-flight window) establecerPara 1
significa que, en el mismoen un tema,incluso siel publicador envíauna serie de diferentes QoS mensajes de nivel,su orden tambiénse conserva
permanece.
4.7 nombre del tema y filtro de temas
4.7.1 comodín de tema
TemaNivel (topic level) Separarel símbolo se usa para estructurarel cambio introduce el nombre del tema.si existe distribuciónel separador, que separa lo principaldividir el nombre del tema en varios
Nivel de tema
nivel
topic level 。
el filtro de tema de la suscripciónel filtro puede contenerun comodín especial, que permitesuscribirse a varios a la vezTema.
en el filtro de tema se puedepara usar comodines, pero el nombre del temano puedeUsarComodín [MQTT-4.7.1-1]。
4.7.1.1 nivel del temaSeparador
barra inclinada（‘/’ U+002F) se utiliza paracada segmento del temajerarquía, proporcionando una jerarquía para el nombre del temaestructura. Cuando el clienteel cliente se suscribe a lo especificadofiltro de tema
el filtro contiene dos tipos de comodinescuando el símbolo, el nivel del temael separador de nivel es muyútil. El temael separador de niveles puedepuede aparecer en el filtro de temaso del nombre del tema
Cualquier posición. Adyacentede la jerarquía de temasel separador representa untema de longitud ceroNivel.
4.7.1.2 multinivelComodín
marcador numérico (‘#’ U+0023) Se usaen la coincidencia de temasarbitrariojerarquíadel comodín. Comodín de múltiples nivelesel comodín representa supadre y cualquier númeroCantidad de sub
Nivel. Comodín multinivelel símbolo debe estar en susu propio nivel o seguido deseparador de niveles de temadetrás del símbolo. Sin importarQué situacióncaso, siempredebeEs el tema
El final del filtroUn carácter [MQTT-4.7.1-2]。
no normativoComentario:
Por ejemplo,SiEl cliente se suscribe al tema “sport/tennis/player1/#”，recibirá usando lo siguientedel nombre del tema publicadoMensaje:
“sport/tennis/player1”
“sport/tennis/player1/ranking”
“sport/tennis/player1/score/wimbledon”
no normativoComentario:
“sport/#”También coincideSeparado “sport” , porque # incluyesu padre.
“#”Es válidode,Se recibirán todosde los mensajes de aplicación。
“sport/tennis/#”tambiénEs válidode.
“sport/tennis#”Es inválidode.
MQTT-3.1.1-CN 53
“sport/tennis/#/ranking”Síinválido.
4.7.1.3 Comodín de un solo nivelcomodines
signo más (‘+’ U+002B) solo se puede usaren un solo nivel de temacomodín de coincidencia de nivelcarácter.
En el filtro de temacualquier nivel puedese puede usar el comodín de un solo nivel,Incluye elun nivel y el último nivel. Sin embargoellodebeocupar el filtro
todo el nivel [MQTT-4.7.1-3]。Puede en el filtro de temamúltiples niveles en el filtrousarlo en el nivel,también se puede usar con varios nivelesusar junto con comodinesuso.
no normativoComentario:
Por ejemplo, “sport/tennis/+” coincidencia “sport/tennis/player1” y “sport/tennis/player2” ，peroNo coincide
“sport/tennis/player1/ranking” . Al mismo tiempo, debido ael comodín de un solo nivel solopuede coincidir con un nivelnivel, “sport/+” No coincide
“sport” sin embargo, coincideconfigurar “sport/”。
no normativoComentario:
“+” Es válidode.
“+/tennis/#” Es válidode.
“sport+” Es inválidode.
“sport/+/player1” también es válido.
“/finance” coincidencia “+/+” y “/+” , pero nocoincidencia “+”。
4.7.2 con$temas que empiecen con
Servidorno puedeva a $ Inicio de carácterel nombre del tema al inicio coincidecoincide con el comodín (#o+) ComenzandoEl filtro de tema al comienzo [MQTT-4.7.2-1]. El servidor deberíabloquear
El cliente utiliza este tipo deel nombre del tema con otrosel cliente intercambia mensajesEl mensaje. La implementación del servidor puedeva a $ Para nombres de tema que comienzan conpara otros fines.
no normativoComentario:
$SYS/ Es ampliamentese utiliza para contener información específica del servidorinterfaz de información o controlel prefijo del tema。
la aplicación no puede usar $ el tema que comienza con un carácterproblema.
no normativoComentario:
suscripción “#” El cliente no recibiráa cualquier publicación a “$” Tema inicialmensajes de los temas.
suscripción “+/monitor/Clients” de sesión norecibirá cualquier envíodesplegar a “$SYS/monitor/Clients” la desaparicióninformación.
suscripción “$SYS/#” del clienterecibirá publicaciones a “$SYS/” comienzomensajes del tema.
suscripción “$SYS/monitor/+” deel cliente recibirá la publicaciónllegar “$SYS/monitor/Clients” principalmensajes de los temas.
Si el cliente también deseaal aceptar con “$SYS/” temas que comienzanlos mensajes y no con $ temas que comienzande los mensajes, necesitaal mismo tiempo
suscripción “#” y ““$SYS/#”。
4.7.3 TemasemánticaY uso
nombre de tema y filtro de temael filtro debe cumplirLas siguientes reglas:
todos los nombres de tema yFiltro de temadebeAl menos incluyecontiene un carácter [MQTT-4.7.3-1]。
nombre de tema y filtro de temael filtro distingue mayúsculas de minúsculasen minúsculas.
nombre de tema y filtro de temael filtro puede contenerEspacio.
MQTT-3.1.1-CN 54
nombre de tema o filtro de temael filtro con un prefijo obarra final “/” Distinguir.
solo contiene barras “/” del nombre del tema o filtro de temasel filtro es válido.
nombre de tema y filtro de temafiltrono puedecontiene caracteres nulos (Unicode U+0000) [Unicode] [MQTT-4.7.3-2]。
nombre de tema y filtro de temaEl filtro es UTF-8 cadena codificada, ellosno puedesupera 65535 va antes del byte de orden bajo [MQTT-4.7.3-3]Ver. 1.5.3
sección.
exceptono puede exceder UTF-caracteres codificadosla limitación de longitud de la cadenaademás, el nombre del tema o el temael nivel del filtrola cantidad no tieneOtras restricciones.
Al coincidir con la suscripción, el servidorextremo de serviciono puedePara el nombre del tema oel filtro de tema ejecutarealizar cualquier normalización（normalization) procesamiento, nopuede modificar o reemplazar
Cualquier carácter no reconocidocarácter [MQTT-4.7.3-4]. Temacada carácter no comodín en el filtroel nivel de caracteres requiere carácter por carácterel carácter coincide con el temael nivel correspondiente en el nombre
nivel para que se considere una coincidencia exitosa。
Noestándar,Comentario:
Usar UTF-8 Las reglas de codificación implican que, el filtro de temay la comparación del nombre del temala comparación puede realizarse mediantecomparar los codificados UTF-8 va antes del byte de orden bajoo solución
Después del código Unicode Carácter.
Noestándar,Comentario:
“ACCOUNTS” y “Accounts” son temas diferentesTítulo.
“Accounts payable” es conformenombre del tema del método
“/finance” y “finance” Son diferentesde.
SiEl filtro de tema de la suscripción y el mensajela coincidencia del nombre del tema, los mensajes de aplicación seránenviados a cadaun cliente que coincidasuscripción del cliente. El temaPuede ser
El administrador en el servidorpredefinido, o posiblemente el servidorel servidor recibe el primeruna suscripción o usar ese temael mensaje de aplicación del nombre del temase agrega dinámicamente cuando el mensaje
. El servidor también puedepuede utilizar un componente de seguridadel componente de seguridad puede seleccionarautorizar específicamente al cliente a usar algúnun recurso de tema.
4.8 Manejo de errores
a menos que se especifique lo contrario,si el servidor oel cliente se encuentra concomportamiento de violación de protocolo,ellodebedesactivar la transmisión de esteuna violación de protocolola red de mensajes de control
conexión de red [MQTT-4.8.0-1]。
El cliente o el servidorla implementación puede encontrarsea un error transitorio (Transient Error)(por ejemplo, dentroel búfer interno está llenola situación) que provocano puede tener éxito
procesamiento MQTT paquete.
Si el cliente o el servidorEl servidor procesa la entradaal encontrar una condición transitoria al procesar el mensaje de controlerror al,ellodebeCerrar esa transmisiónconexión de red del paquete de controlConectar
[MQTT-4.8.0-2]。SiEl servidor ha detectadoError transitorio, esteNo deberíamientras su conexiónConexión o ejecuciónCualquier cosa a otros clientesoperación que afecta al extremo
trabajo.
MQTT-3.1.1-CN 55
5 Seguridad
5.1 Descripción general
El contenido de este capítulo es únicamente parareferencia, es no estándarnormalizado. Sin embargo, se recomienda encarecidamenteproporcionar TLS del servicioimplementación del servidordeberíaUsar TCP puerto 8883
（IANA nombre del servicio:secure-mqtt）。
proveedor de solucionesHay que considerar muchosriesgos. Por ejemplo:
El dispositivo podría ser robadousar
Entre el cliente y el servidorLos datos estáticos puedenpuede ser accesible (puede ser modificadomodificación)
El comportamiento del protocolo puede tenerefectos secundarios (como el cálculoataque de temporizador)
ataque de denegación de servicio
La comunicación podría ser interceptadainterceptar,modificar, redirección o divulgación
mensaje de control falsoinyección
MQTT Solución comúncomúnmente implementado encomunicación seguraen el entorno. En esteEn este caso, el protocolola implementación generalmente necesitadebe proporcionar estos mecanismos:
Identidad de usuarios y dispositivosAutenticación
Acceso a recursos del servidorautorización
MQTT paquete de controltexto y aplicaciones embebidasintegridad de los datosverificación de integridad
MQTT paquete de controltexto y aplicaciones embebidasprivacidad de los datosControl de privacidad
Como protocolo de capa de transporte，MQTT solo se centra en la transmisión de mensajes,proporcionar la seguridad adecuadatoda la funcionalidad es responsabilidad del implementadorresponsabilidad. Uso TLS [RFC5246] Sí
Una opción relativamente común. Además de lo técnicoAdemás de los problemas de seguridad,también factores geográficosfactor (por ejemplo, Estados UnidosPrincipios de puerto seguro de la UE
[USEUSAFEHARB]）, industriaestándar (por ejemplo, el terceroindustria de pagos de tercerosestándar de seguridad de datos [PCIDSS]), supervisiónconsideraciones sobre (Ejemplo
como Sarbanes-misterioLey de Oxley [SARBANES]), etc.Problema.
5.2 MQTT Solución: seguridad y autenticación
La implementación del protocolo puede quererdebe cumplir con determinadosnormas de seguridad industrial, como NIST redmarco de ciberseguridad [NISTCSF] , tercerosdatos de la industria de pagosseguro
Todos los estándares [PCIDSS] , el gobierno federal de los Estados Unidosnorma de procesamiento de información [FIPS1402] y NSA SumaCombinación de cifrado B [NSAB] 。
En MQTT del complementopublicaciones complementarias （MQTT and the NIST Framework for Improving Critical Infrastructure
Cybersecurity [MQTT NIST]） se puede encontrar enEn NIST redmarco de seguridad [NISTCSF] MedioUsar MQTT deGuía. Uso
Evidencia de la industria, independientetécnicas de auditoría y certificaciónla técnica ayuda a cumplirrequisitos de cumplimiento.
5.3 Cifrado ligero y dispositivos restringidos
Adopción generalizada de cifrado avanzadoEstándar de cifrado [AES] baseCifrado de datosestándar [DES] 。
Recomendado para uso restringidolas características de los dispositivos de gama bajaespecialmente optimizado y ligerocifrado internacional ligeroestándar ISO 29192 [ISO29192] 。
5.4 notas de implementación
implementación y uso MQTT cuando hay que considerar muchosproblemas de seguridad.abajola parte no deberíadebe considerarse como ununidad lista de verificación 。
La implementación del protocolo puede implementarimplementar una parte de lo siguienteparte o totalidad:
MQTT-3.1.1-CN 56
5.4.1 identidad del clienteVerificación
CONNECT mensajeel texto contiene al usuarioCampos de nombre y contraseña.implementapuede decidir cómo utilizar estas palabrasel contenido del segmento. La implementaciónel implementador puede proporcionarPropio
Mecanismo de autenticación,o utilizar un externosistema de autenticación como LDAP [RFC4511] o OAuth [RFC6749] , tambiénpuede utilizar el sistema operativo
el mecanismo de autenticación.
La implementación puede transmitir en texto clarotransmitir datos de autenticación,ofuscar esos datos, o no se requiereCualquier dato de autenticación,pero debe ser conscientea esto aumentará enAtaque de intermediario
de ataques y ataques de reproducciónRiesgo.5.4.5 la secciónpresenta la confirmaciónmétodos para asegurar la privacidad de los datos.
En el cliente y el servidorentre extremos usando virtualred privada virtual (VPN) Puedeasegurar que los datos soloclientes autorizadosel extremo recibe.
Usar TLS [RFC5246] cuandoEl servidor puede usarenviado por el cliente SSL certificadoverificar al clientede la identidad.
La implementación puede permitir al clienteel cliente a través de la aplicaciónel mensaje envía credenciales al servidorcertificado para verificación de identidadverificación.
5.4.2 autorización del cliente
Basado en lo que proporciona el clienteinformación como el usuarionombre, identificador de clienteIdentificador (ClientId）、Clientedel nombre de host o IP dirección, oautenticación de identidad
El resultado, el servidorpuede restringir a ciertosrecursos del servidorde acceso.
5.4.3 Servicioidentidad del terminalAutenticación
MQTT El protocolo noes confianza bidireccional, no tieneproporcionar verificación del clienteverificar la identidad del servidordel mecanismo.
peroUsar TLS [RFC5246] Cuando, el cliente puede usar el servidorenviado por el servidor SSL certificadoverificar el servidorde la identidad. Desde un solo IP muchonombre de dominio
Proporciona MQTT La implementación del servicio deberíaconsiderar RFC6066 [RFC6066] ordinal 3 la seccióndefinido TLS de SNI Extensión.SNI permitir al clienteextremo
Indicar al servidor lo que quiereservidor conectadonombre de host.
La implementación puede permitir al servidorel servidor a través de la aplicaciónel mensaje envía credenciales al clientecertificado para verificación de identidadverificación.
En el cliente y el servidorentre extremos usando virtualred privada virtual (VPN) Puedeasegurar que el clientela conexión es la esperadadel servidor.
5.4.4 Controlpaquetey la aplicaciónIntegridad de la informaciónintegridad
La aplicación puede, en la aplicaciónincluye por separado en el mensajecontiene el valor hash. Estohacerlo puede PUBLISH Controltransmisión por red de los mensajestransmisión y datos estáticosproporcionar contenido
La comprobación de integridad.
TLS [RFC5246] proponerproporcionar a la redhacer con los datos transmitidosalgoritmo hash de verificación de integridadmétodo.
En el cliente y el servidorentre extremos usando virtualred privada virtual (VPN) ConexiónPuede estar en VPN Cubiertoel segmento de red proporciona integridad de datosuna comprobación de integridad.
5.4.5 mensajes de control yMensaje de aplicacióninformaciónla confidencialidad.
TLS [RFC5246] varpara la transmisión por redcifrado de los datos transmitidos. Si es válido TLS Conjunto de cifradola combinación incluye el cifradoEl algoritmo es NULL，entonces
No cifrará los datos.para asegurar que el clientey del lado del servidorconfidencialidad, se debe evitar queutilizar estos conjuntos de cifradoconforme.
La aplicación puede agregar por separadocifrado de los mensajes de la aplicacióncontenido. Esto puedeproporciona la vía de transmisión de mensajes de aplicaciónNeutral y estáticoprivacidad de los datos estáticosidad. Pero no puede dar a los mensajes de aplicación
Otros atributos de la información, comocifrado del nombre del tema.
Entre el cliente y el servidorla implementación puede cifraralmacenar datos estáticos, por ejemplopuede eliminar la aplicaciónmensajes como parte de la sesiónAlmacenamiento.
En el cliente y el servidorentre extremos usando virtualred privada virtual (VPN) ConexiónPuede estar en VPN Cubiertoel segmento de red garantiza la confidencialidad de los datosConfidencialidad。
5.4.6 de la transmisión de mensajesNo repudioReconocimiento
El diseñador de la aplicación puedees necesario considerar lo apropiadola estrategia, para implementarlograr de extremo a extremo nonegabilidad (non-repudiation）。
MQTT-3.1.1-CN 57
5.4.7 DetecciónClienteCliente y servidorDel servidorusurpación
Usar TLS [RFC5246] Del clientelas implementaciones del cliente y del servidor debenpuede garantizar,Inicialización TLS [RFC5246] al conectarproporcionado SSL prueba
El certificado está vinculado al nombre de host (el cliente necesita conectarsede o el servidor será conectado) RelacionadoRelacionado.
Usar TLS [RFC5246] Del clientelas implementaciones del cliente y del servidor, puedenpara elegir proporcionar verificaciónVerificar la lista de revocación de certificados (CRLs [RFC5280]) Y en línea
protocolo de estado de certificados (OSCP) [RFC6960] deFunción,rechazar el uso de los revocadosCertificado.
El despliegue físico puedehardware a prueba de manipulaciones ydatos especiales de los mensajes de aplicacióncombinación de transmisión.Por ejemplo,unel instrumento puedeincluye un GPS Para garantizar
No en lo no autorizadouso regional.IEEE Dispositivo de seguridadAutenticación de dispositivo [IEEE 802.1AR] Es decirpara implementar este mecanismoUn estándar de control,utiliza
Usando un identificador vinculado criptográficamenteel token verifica la identidad del dispositivoidentidad.
5.4.8 detectar comportamientos anómalos
La implementación del servidor puedeMonitoreo del clientecomportamiento, detectar potencialen los riesgos de seguridad. Por ejemplo:
Solicitudes de conexión repetidas
Autenticación repetidasolicitud
Terminación anómala de la conexión
Escaneo de temas (solicitudenviar o suscribirse a grandescantidad de temas)
Enviar lo que no puede ser entregadomensajes (sin suscripciónsuscriptores del tema)
El cliente se conecta, perono enviar datos
Se detecta una violación de las reglas de seguridad.entonces el comportamiento, servidorel servidor puede implementardesconectar la conexión del clienteconexión.
La implementación del servidor realiza la detección.comportamiento no deseadocomportamiento, puede basarse en IP tierradirección o identificador del clienteimplementar un identificadorlista negra dinámica.
El despliegue del servicio puede hacer queusar control de nivel de redcontrol (si está disponible) implementación basada en IP tierraDirección u otrolímite de velocidad de su informacióno lista negra.
5.4.9 Otrosde seguridadprecauciones de seguridadelemento
Si el cliente o el servidorDel servidor SSL pérdida de certificados, o yoconsideran el robo de certificados.uso o revocado(utilizar CRLs [RFC5280] y
OSCP [RFC6960])deSituación.
El cliente o el servidoral verificar las credenciales,si se detecta al usuariose pierden el nombre y la contraseñao son robados, debeesa revocación o reemisión。
Al utilizar conexiones persistentes：
Entre el cliente y el servidorUsar TLS [RFC5246] cuando se debe permitirpermitir renegociarnegociar la sesión para confirmarnuevos parámetros de cifrado (reemplazandoClave de sesión
clave, cambiar la suite de cifradocumplir, reemplazar la autenticacióncredencial).
El servidor puede desconectar la conexión.conexión del cliente,y exigirles queusen nuevas credenciales paraverificar la identidad de nuevo.
el receptor en una red restringidalimitar dispositivos y clientesel extremo puede usar TLS reanudación de sesión [RFC5077] reducir TLS sesiónreconexión [RFC5246] de costo
costo.
que se conecta al servidorcliente y otrosel cliente conectado al servidorextremo Hay una relación de transferencia de confianza entre, todos tienen derecho aen el mismo tema
publicar mensajes.
MQTT-3.1.1-CN 58
5.4.10 Usar SOCKS Proxy
La implementación del cliente deberíadarse cuenta de que algunos entornosel entorno exige usar SOCKSv5 [RFC1928] representargestionar la creación de salientesconexión de red.Algunos MQTT real
ahora se puede utilizar la seguridadtúnel (como SSH）Mediante SOCKS Proxy. Unouna implementación decide admitir SOCKS cuandodeberían soportar simultáneamenteocultar
el nombre y la contraseña de usuariode verificación de código SOCKS Proxy.para este últimocaso, la implementacióndebe tener en cuenta SOCKS varPuede usarautenticación en texto plano,
por lo tantoSe debería evitar usar las mismas credencialesconexión MQTT servidor.
5.4.11 perfil de configuración de seguridad
implementadores y diseñadores de solucioneslos diseñadores pueden querertratar la seguridad como un archivo de configuraciónEl conjunto debeusado en MQTT En el protocolo. Lo que se describe a continuaciónes una seguridad en capas
estructura de nivel de seguridad.
5.4.11.1 abierta,configuración de comunicación
usar una configuración de comunicación abiertaAl configurar,MQTT El protocolo se ejecuta en un entorno sin cuota integradael inicio del mecanismo externo de comunicación seguraponer en la red.
5.4.11.2 Seguridadconfiguración de comunicaciones de red
usar comunicación de red seguraal configurar la comunicación,MQTT operación del protocoloejecutar en un entorno segurocontrolado físico o virtualen la red,Como VPN o cosagestionar redes seguras.
5.4.11.3 configuración de transmisión segura
usar una configuración de transmisión seguraAl configurar,MQTT el protocolo se ejecuta enUsar TLS [RFC5246] dered física o virtualen la red, proporcionaproporciona autenticación de identidad，
integridad y confidencialidad。
usar el usuario integradocampos de nombre y contraseña，TLS [RFC5246] identidad del clientela autenticación de identidad puede ser utilizadaen (o en lugar de）MQTT clienteautenticación del cliente
verificación.
5.4.11.4 la seguridad de los estándares industrialesconfiguración de seguridad
Como es de esperar,MQTT Edredóndiseñado para soportarmuchas aplicaciones de estándares industrialesconfiguración,cada una define unun modelo de amenazas y para definiramenaza de bits
el mecanismo de seguridad especial. Seguridad especialel mecanismo recomienda de las siguientes manerasselección entre las opciones:
[NISTCSF] NIST marco de seguridad de redsoporte
[NIST7628] NISTIR 7628 Guía de ciberseguridad para redes eléctricas inteligentes
[FIPS1402] (FIPS PUB 140-2) módulo de cifradolos requisitos de seguridad de
[PCIDSS] PCI-DSS soporte de tercerosseguridad de datos de la industria de pagosTodos los estándares
[NSAB] NSA cifradocombinación B
MQTT-3.1.1-CN 59
6 Usar WebSocket comocapa de red
Si MQTT En WebSocket [RFC6455] conexiónen la transmisión,debesatisfacerLas siguientes condiciones:
MQTT paquete de controltextodebeUsar WebSocket datos binariosLa trama de datos se envía. Sirecibir cualquier otro tipo detrama de datos, recibir
personadebecerrar la conexión de red [MQTT-6.0.0-1]。
único WebSocket baseUna trama de datos puede contener múltiplesuno o parte MQTT mensaje. El receptorno puedeSuponga que MQTT Paquete de controlsegún
WebSocket alineación de límites de trama [MQTT-6.0.0-2]。
Clientedebela cadena mqtt incluido en élproporcionado por WebSocket subprotocoloen la lista de protocolos [MQTT-6.0.0-3]。
El servidor selecciona y devuelvede respuesta WebSocket subprotocolonombre de protocolodebeSí mqtt [MQTT-6.0.0-4] 。
para conectarse al clientey del servidor WebSocket URI Sobre MQTT El protocolo no tiene ningún impacto.
6.1 IANA Nota.consideraciones
esta especificación requiere IANA En WebSocket subprotocoloregistrado en la entrada del nombre de protocolo WebSocket MQTT subprotocolo,Use los siguientes datos：
leyenda 6.1 - IANA WebSocket identificador
identificador de subprotocolo
mqtt
nombre común del subprotocolo
mqtt
el subprotocolo define
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html
MQTT-3.1.1-CN 60
7 Conformidad
MQTT la especificación definedefinido MQTT clientela implementación del cliente y MQTT implementado por el servidorrequisitos de conformidad
MQTT la implementación puedepuede ser simultáneamente MQTT el cliente y MQTT el servidor.aceptar conexiones entrantesy establecer a otrosde la conexión saliente del servidorservicio
El servidor debe cumplir simultáneamentecombinar MQTT clientecliente y MQTT los requisitos del lado del servidorRuego [MQTT-7.0.0-1]。
para con cualquier otroimplementación conformeinteroperabilidad, unala implementación conforme no puedese requiere usar dentro de esta especificacióncualquier definido externamenteExtensión [MQTT-
7.0.0-2]。
7.1 objetivos de conformidad
7.1.1 MQTT Servidor
un MQTT El servidor solo si cumpleabajotodosde los requisitos se considera conformeEsta especificación:
1. el servidor envíatodos los mensajes de controlel formato debe cumplir conel capítulo 2 y elel formato descrito en el capítulo tres
2. cumplir con el 4.7 el tema descrito en la sección coincidereglas de asignación.
3. cumplir con los siguientes capítulostodos en la seccióndeberequisitos de nivelrequisito,clarosolo se aplica al clienteexcepto:
- Capítulo 1 – introducción
- Capítulo 2 – MQTT formato del paquete de controlcabecera.
- Capítulo 3 – MQTT Paquete de control
- Capítulo 4 – Comportamiento de operación
- Capítulo 6 –(Si MQTT la capa de red es WebSocket）
- Capítulo 7 – objetivos de conformidad
satisfacer los requisitos de consistenciadel servidordebeadmite el uso de ununo o más protocolos de transporte subyacentesprotocolo de transporte, siempre queproporciona ordenado, fiable,bidireccionalva antes del byte de orden bajo
Flujo (desde el cliente hastaservidor y desde el servidoral cliente）[MQTT-7.1.1-1]. PeroLa conformidad no depende de que soportesoportar cualquier específico
Protocolo de transporte. Servicioextremopuedesoporta el 4.2 la seccióncualquiera de los listadosProtocolo de transporte, ocualquier otro que satisfaga [MQTT-7.1.1-1] requeridotransmisión
protocolo.
7.1.2 MQTT Cliente
un MQTT El cliente solo si cumpletodos los siguientes requisitoslos requisitos se consideran conformesEsta especificación:
1. el cliente envíatodos los mensajes de controlel formato debe cumplir conel capítulo 2 y elel formato descrito en el capítulo tres
2. cumplir con los siguientes capítulostodos en la seccióndeberequisitos de nivelrequisito,clarosolo se aplica al servidorexcepto:
- Capítulo 1 – introducción
- Capítulo 2 – MQTT formato del paquete de controlcabecera.
- Capítulo 3 – MQTT Paquete de control
- Capítulo 4 – Comportamiento de operación
- Capítulo 6 – (Si MQTT de la redla capa de red es WebSocket）
- Capítulo 7 – objetivos de conformidad
satisfacer los requisitos de consistenciadel clientedebeadmite el uso de ununo o más protocolos de transporte subyacentesprotocolo de transporte, siempre queproporciona ordenado, fiable,bidireccionalva antes del byte de orden bajo
Flujo (desde el cliente hastaservidor y desde el servidoral cliente）[MQTT-7.1.2-1]. PeroLa conformidad no depende de que soportesoportar cualquier específico
MQTT-3.1.1-CN 61
Protocolo de transporte. Clienteextremopuedesoporta el 4.2 la seccióncualquiera de los listadosProtocolo de transporte, ocualquier otro que satisfaga [MQTT-7.1.2-1] requeridotransmisión
protocolo.
MQTT-3.1.1-CN 62
apéndice B obligatoriodeclaración normativa(no normativonormativo）
Este apéndice es no normativonormativos, solo comoen el cuerpo de este documentoque se puede encontrargran cantidaddeclaración de conformidadse proporciona un resumen.de los requisitos de conformidadlista de restricciones
Ver tabla en el capítulo siete.
número de secuencia de declaración
declaración de especificación
[MQTT-1.5.3-1]
UTF-8 caracteres de la cadena codificadadatos de caracteresdebese ajustan a Unicode estándar, [Unicode] definidos y en
RFC3629 [RFC3629] medio pesadodeclaración válida UTF-8 formato. Especialmenteno es necesario señalar que,estosbase
datosno puedecontiene códigos de caracteres en U+D800 y U+DFFF entrelos datos.si el servidor oel cliente recibe
uno que contiene un valor no válido UTF-8 caracteresmensaje de control,ellodebecerrar la conexión de red。
[MQTT-1.5.3-2]
UTF-8 Cadena codificadano puedecontiene caracteres nulos U+0000。Siel cliente o el servidor recibellegó un paquete
incluyen U+0000 depaquete de control,ellodebeCerrar la conexión de red.
[MQTT-1.5.3-3]
UTF-8 secuencia de codificación 0XEF 0xBB 0xBF totalse interpreta como U+FEFF(espacio de no separación de ancho cerocarácter
carácter),independientemente deaparece en la cadena de caracteresqué posición,paqueteel receptor no puede saltarse ni eliminarsepararlo.
[MQTT-2.2.2-1]
tabla 2.2 en los que cualquier marcado como“Reservado”los bits de los indicadores, son todos resreservado para uso futuro，debeEstablecer como tabla
valores enumerados.
[MQTT-2.2.2-2]
Sirecibe un indicador inválido,receptordebeCerrar la conexión de red.
[MQTT-2.3.1-1]
SUBSCRIBE，UNSUBSCRIBE y PUBLISH（QoS mayor que 0) paquete de controldebecontiene un
no nulo 16 Posiciónidentificador de mensaje (Packet Identifier。
[MQTT-2.3.1-2]
El cliente, cada vez que envíaun nuevo de estostipo de mensaje, siempredebeasignar un actualmensaje no utilizadomarca
identificador。
[MQTT-2.3.1-3]
SiUn cliente debe reenviar este mensaje en particularmensaje de control especial, al reenviar posteriormentecuando ese mensaje,ellodebeHacer
con el mismo identificador. Cuando el clientedespués de procesar lo correspondiente a este mensajedespués, esteel identificador del mensaje se libera
Colocar reutilizable.QoS 1 de PUBLISH Sobrecorresponde a PUBACK，QoS 2 de PUBLISH correspondiente
Sí PUBCOMP, con SUBSCRIBE o UNSUBSCRIBE Sobrecorresponden respectivamente SUBACK o
UNSUBACK
[MQTT-2.3.1-4]
enviar un QoS 0 de PUBLISH paquetecuandomismolas condiciones también se aplican al servidorextremo.
[MQTT-2.3.1-5]
QoS establecido en 0 de PUBLISH paqueteno puedecontiene el identificador de paquete.
[MQTT-2.3.1-6]
PUBACK, PUBREC, PUBREL paquetedebecontiene conenviado originalmente PUBLISH el mismo paquete
identificador de paquete。
[MQTT-2.3.1-7]
y [MQTT-2.3.1-6] similar,SUBACK y UNSUBACK debecontenido en el correspondiente
SUBSCRIBE y UNSUBSCRIBE paqueteidentificador de paquete utilizado encarácter.
[MQTT-3.1.0-1]
Del cliente al servidorde la conexión de reddespués de establecida, el cliente envía alel primero del servidorun mensajedebeSí
CONNECT paquete。
[MQTT-3.1.0-2]
en una conexión de redel cliente solopuede enviar una vez CONNECT mensaje. Servidorextremo de serviciodebeal cliente
el segundo enviado CONNECT tratar el mensaje comoManejo de violaciones de protocoloy desconectar la conexión del cliente。
[MQTT-3.1.2-1]
Si el nombre de protocolo no escorrecto, el servidorpuededesconecta al clientela conexión, tambiénpuedesegúnalguna otra especificacióncontinuar
procesamiento CONNECT paquete. ParaEn el último caso,según esta especificación,Servidorno puedecontinúa procesando
CONNECT paquete。
MQTT-3.1.1-CN 63
[MQTT-3.1.2-2]
Si se descubre que no se admitedel nivel de protocolo,Servidordebeenviar unEl código de retorno es 0x01(protocolo no soportado
nivel de protocolo)de CONNACK paqueteRespuesta CONNECT el paquete,luegodesconectar la conexión del cliente。
[MQTT-3.1.2-3]
ServidordebeVerificación CONNECT la retención del paquete de controlbit de retención (el 0 bit) si es 0，SiNo
Para 0 debedebe desconectar la conexión del cliente.
[MQTT-3.1.2-4]
Si se limpia la sesión (CleanSession）la bandera se establecea 0, el servidordebebasándose enla sesión actual (usando
usando el identificador del clienteestado de la identificación)reanudar con el clientela comunicación. Sino con el identificador de este clienteseña
la sesión asociada al identificador,Servidordebecrear unanueva sesión. Endespués de que se desconecte la conexión, cuando la conexióndesconexión
después,Entre el cliente y el servidordebealmacenainformación de sesión.
[MQTT-3.1.2-5]
Cuando el indicador de sesión limpiaPara 0 conexión de sesióndespués de la desconexión,Servidordebedespués de eso QoS 1 y QoS 2
guardar los mensajes de nivelpara el estado de la sesiónsiestos mensajes coincidenal desconectarse el clientecualquier del cliente
cualquier suscripción.
[MQTT-3.1.2-6]
Si se limpia la sesión (CleanSession）la bandera se establecea 1, el clientey el servidordebedescartar antes
cualquier sesión y abririniciar una nueva sesiónPalabra. La sesión solo dura y la redla conexión de red de la misma duraciónel tiempo.yEste
estado asociado a la sesióndatosno puededespués de cualquierla reutilización de la sesión.
[MQTT-3.1.2.7]
Los mensajes retenidos no son parte del servicioestado de sesión del servidoruna parte, la sesión terminaCuandono puedeeliminar mensajes retenidosinformación.
[MQTT-3.1.2-8]
marcador de voluntad (Will Flag) se establecePara 1, lo que indica que sila solicitud de conexión esaceptado, testamento (Will
Message）mensajedebese almacena enel servidor y con esta redasociación de conexión de red.después se cierra la conexión de red
al cerrarse, el servidordebePublicar este mensaje de testamento, a menos que el servidorRecibido DISCONNECT eliminar al recibir el mensaje
excepto este mensaje de testamentoinformación.
[MQTT-3.1.2-9]
si el indicador de testamento esestablecido en 1[valor], el bit n.ºde los indicadores de conexión Will QoS y Will Retain Camposerá por el servidor
se usa,al mismo tiempoen la carga útildebeincluyen Will Topic y Will Message Campo。
[MQTT-3.1.2-10]
una vez publicado oel servidor ha recibidoenviado por el cliente DISCONNECT mensaje, mensaje de testamentoSolodebe
debedesde almacenamientoeliminado del estado de sesión almacenado.
[MQTT-3.1.2-11]
si el indicador de testamento esestablecido en 0，conexiónen el indicador Will QoS y Will Retain Campodebeestablecido en
0, yen la carga útilno puedeincluyen Will Topic y Will Message Campo。
[MQTT-3.1.2-12]
si el indicador de testamento esestablecido en 0, redcuando la conexión de red se interrumpe，no puedeenviar el mensaje de testamento。.
[MQTT-3.1.2-13]
si el indicador de testamento esestablecido en 0, testamentoencomendar QoS tambiéndebeestablecido en 0(0x00)。
[MQTT-3.1.2-14]
si el indicador de testamento esestablecido en 1, testamentoencomendar QoS el valorpuede ser igual a 0(0x00)，1(0x01)，2(0x02)。
su valorno puedeigual a 3。
[MQTT-3.1.2-15]
si el indicador de testamento esestablecido en 0, testamentoretención (Will Retain) el indicador tambiéndebeestablecido en 0。
[MQTT-3.1.2-16]
Siel testamento retenido se establece en 0, el servidordebetratar el mensaje de testamento como nopublicar mensaje retenido。
[MQTT-3.1.2-17]
Siel testamento retenido se establece en 1, el servidordebetratar el mensaje de testamento comopublicar como mensaje retenido。
[MQTT-3.1.2-18]
si el nombre de usuario (User Name) el indicador se establece en 0, en la carga útilno puedeincluyencampo de nombre de usuario.
[MQTT-3.1.2-19]
si el nombre de usuario (User Name) el indicador se establece en 1, en la carga útildebeincluyencampo de nombre de usuario.
[MQTT-3.1.2-20]
si la contraseña (Password) indicadorse establece en 0, en la carga útilno puedeContiene el campo de contraseña。
[MQTT-3.1.2-21]
si la contraseña (Password) indicadorse establece en 1, en la carga útildebeContiene el campo de contraseña
MQTT-3.1.1-CN 64
[MQTT-3.1.2-22]
Si el indicador de nombre de usuario.se establece en 0, el indicador de contraseña tambiéndebeestablecido en 0。
[MQTT-3.1.2-23]
El cliente es responsable de garantizarel envío de paquetes de controlel intervalo de tiempo no excede la conservaciónel valor de mantener la conexión.si no hay ningún otro
su paquete de control puedepara enviar, el clienteextremodebeenviar un PINGREQ paquete。
[MQTT-3.1.2-24]
si el keep-aliveel valor es distinto de cero, yel servidor en una y media vecestiempo de keep-aliveno ha recibido del cliente dentro de
el paquete de control del cliente,ellodebela desconexión del clienteconexión de red,consideraconexión de red yadesconectar.
[MQTT-3.1.3-1]
si se incluye,debeaparecen en este orden: identificador del clientecarácter, tema del testamento, testamentomensaje,usar
nombre de cuenta，contraseña。
[MQTT-3.1.3-2]
el servidor utiliza el clienteidentificador del extremo (ClientId) señaOtro cliente. Conectar al servidorcada cliente del servidorcada cliente tiene un único
un identificador de cliente único(ClientId). El cliente yel servidor también debeUsar ClientId señapara distinguir entre
los dos MQTT estado relacionado con la sesión。
[MQTT-3.1.3-3]
identificador del cliente (ClientId) debeexisteydebeSí CONNECT paqueteel primer campoun
Campo。
[MQTT-3.1.3-4]
identificador del clientedebeSí 1.5.3 definido por la sección UTF-8 cadena codificada。
[MQTT-3.1.3-5]
Servidordebese permite 1 llegar 23 de N bytes de longitud UTF-8 identificador de cliente codificadoidentificador del clienteidentificador del cliente
solo puede contener estos caracterescarácter:
“0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXY
Z”(letras mayúsculas, letras minúsculas y númeroscarácter).
[MQTT-3.1.3-6]
Servidorpuedepermite al clienteEl cliente proporciona un carácter ceroel identificador de cliente del byteidentificador (ClientId) ，si se hace esto
ya,Servidordebetratar esto como un caso especial yasignar un único clienteel identificador de cliente aese cliente.sin embargo
luego esodebesuponer que el clienteEl extremo proporciona ese únicodel identificador de clientesímbolo,normalprocesar este CONNECT
paquete。
[MQTT-3.1.3-7]
si el clienteel extremo proporciona un byte cerodel identificador de clienteSímbolo, éldebeAl mismo tiempo borraráel indicador de sesión limpia se establececolocar
Para 1。
[MQTT-3.1.3-8]
Si el cliente proporciona.de ClientId a cero bytesy limpiar el indicador de sesiónmarcado como 0, servicioextremodebeenviar código de retorno
Para 0x02（Indica que el identificador no es válido) de CONNACK Respuesta de paquetedel cliente CONNECT mensaje
,Luego cierra la conexión de red。
[MQTT-3.1.3-9]
Si el servidor rechaza.de esto ClientId，ellodebeenviar respuestael código es 0x02(tablaindica que el identificador no es válido
del formato) CONNACK mensajerespuesta del mensajedel cliente CONNECT paquete, luegocerrar la conexión de red。
[MQTT-3.1.3-10]
Tema de última voluntaddebeSí 1.5.3 definido por la sección UTF-8 cadena codificada.
[MQTT-3.1.3-11]
nombre de usuariodebeSí 1.5.3 definido por la sección UTF-8 cadena codificada。
[MQTT-3.1.4-1]
Servidordebesegún 3.1 la secciónverificación de requisitos CONNECT el paquete,Siel mensaje no cumpleespecificación, servidor
el extremo no envía CONNACK mensajetexto directocerrar la conexión de red。
[MQTT-3.1.4-2]
Si ClientId tablaindica que el clienteya conectado aEste servidor,entonces el servidordeberazón de desconexiónalgunos clientes
Conexión de extremo.
[MQTT-3.1.4-3]
Servidordebesegún 3.1.2.4 del nododescribe la ejecución de la limpiezael proceso de la sesión.
[MQTT-3.1.4-4]
Servidordebeenviar de vueltacódigo de retorno de cero CONNACK paquete como CONNECT del mensajerespuesta de confirmación.
[MQTT-3.1.4-5]
Siel servidor rechazó CONNECT, ellono puedemanejar al cliente en CONNECT mensajeenviar después del paquetede
cualquier dato。
MQTT-3.1.1-CN 65
[MQTT-3.2.0-1]
el servidor envía CONNACK paqueterespuesta recibida del cliente CONNECT mensajeMensaje. El servidor envía a
El primero del clientepaquetedebeSí CONNACK。
[MQTT-3.2.2-1]
Si el servidor recibelimpiar sesión (CleanSession）banderasPara 1 dela conexión, exceptohabrá CONNACK
El código de retorno en el paqueteestablecido en 0 excepto, tambiéndebeva a CONNACK en el mensajeconfiguración de la sesión actual
（Session Present）el indicador es 0。
[MQTT-3.2.2-2]
Si el servidor recibeun CleanSession Para 0 deconexión, la sesión actualel valor de la bandera de sesión dependedepende del servidor
Si ya se ha guardado ClientId SobreResponder al clienteel estado de sesión.si el servidor ya ha guardadoestado de sesión
estado,ellodebeva a CONNACK mensajeel indicador de sesión actual en el textoestablecido en 1。
[MQTT-3.2.2-3]
SiEl servidor no tiene ninguna sesión guardadaestado,ellodebeva a CONNACK en el mensajede la configuración de la sesión actualcolocar
Para 0. También se debe CONNACK mensajeel código de retorno en el mensaje se establece en 0。
[MQTT-3.2.2-4]
Si el servidor envíaun mensaje que contiene undel código de retorno cero CONNACK el paquete,ellodebemarcar la sesión actual
de sesión; 0。
[MQTT-3.2.2-5]
Si el servidor envíaun mensaje que contiene undel código de retorno cero CONNACK el paquete,entoncesellodebecerrar la red
conexión。.
[MQTT-3.2.2-6]
Si se considera la tabla anterior 3.1 de todas las conexiones, el retornolos códigos de retorno no son muy adecuadosadecuado,entoncesServidordebecerrar la conexión
Conexión, no es necesario enviar CONNACK paquete。
[MQTT-3.3.1-1]
El cliente o el servidorsolicita reenviar un PUBLISH Cuando el mensaje,debeva a DUP marcade sesión; 1。
[MQTT-3.3.1-2]
Para QoS 0 el mensaje de,DUP banderasdebeestablecido en 0
[MQTT-3.3.1-3]
el servidor envía PUBLISH mensaje al suscriptorcuandoRecibidode (entrante) PUBLISH del mensaje DUP
El valor del indicador no seráPropagación. Enviar (saliente) del PUBLISH Mensaje y recepción (entrante) del
PUBLISH mensajeen el texto DUP marcaes independienteEstablecido, su valordebepor separadosegún el envío (salida
de la estación) PUBLISH mensajesi el mensaje esUna retransmisión para determinar。
[MQTT-3.3.1-4]
PUBLISH paqueteno puedeva a QoS lugaralgunos bits se establecen en 1。Siel servidor o el cliente recibe QoS lugar
todos los bits son 1 de PUBLISH mensajemensaje, éldebecerrar la redred.
[MQTT-3.3.1-5]
Si el cliente envía aldel lado del servidor PUBLISH mensajedel documentoretención (RETAIN) etiquetael marcador se establece en 1, servidor
extremo de serviciodebeAlmacenar este mensaje de la aplicación y su servicioNivel de calidad de servicio (QoS), paraPuede ser distribuidoPara
Futura coincidencia del nombre del temasuscriptores asignados.
[MQTT-3.3.1-6]
Una nueva suscripción creadainmediatamente, para cadael nombre de tema coincidente, siexisterecientementeel mensaje retenido, ellodebe
Enviado a este suscriptorlector.
[MQTT-3.3.1-7]
Si el servidor recibeun mensaje retenido (RETAIN) etiquetamarcado como 1 de QoS 0 mensaje,ellodebedescartar antes
Retenido para ese temade cualquier mensaje.ellodeberíaeste nuevo QoS 0 cancelarmensaje como esela nueva retención de un tema
Mensaje retenido, pero cualquieren cualquier momentopuedeelige descartarlo — SiEsta situación ocurre,eseel tema no tendrá
hay un mensaje retenido。
[MQTT-3.3.1-8]
el servidor envía PUBLISH mensaje al clientecuando, si el mensajees como un clienteEl resultado de una nueva suscripción
envía, lodebereportaráEl indicador de retención del mensaje se establece en 1。
[MQTT-3.3.1-9]
cuando un PUBLISH mensajemensaje enviado ael cliente es porque coincide con ununa suscripción establecidaal momento de suscribirse, el servidordebe
establecer el indicador de retención en 0，sin importarretener en este mensaje que recibióel valor del indicador esmenos.
MQTT-3.1.1-CN 66
[MQTT-3.3.1-10]
el marcador de retención es 1 y con una carga útil de cero bytes PUBLISH paqueteSerá considerado por el servidor como positivoprocesamiento de mensaje normal
Procesado, será enviadopara emparejar el tema de suscripcióncliente coincidente. Además,bajo el mismo temacualquier existentealmacenamiento retenido
El mensaje debe ser eliminadopor lo tanto, este temacualquier suscriptor después del temano recibirá unun mensaje retenido。
[MQTT-3.3.1-11]
Servidorno puedealmacenar ceroMensaje retenido de bytes。
[MQTT-3.3.1-12]
Si el cliente envía aldel lado del servidor PUBLISH mensajedel documentoel bit del indicador de retención 0, servicioextremono puedealmacenar este mensaje
información tambiénno puedeEliminar o reemplazar cualquier reserva existentemensaje.
[MQTT-3.3.2-1]
Nombre del temadebeSí PUBLISH mensajeencabezado variable del mensajeEl primer campo del encabezado.ellodebeSí 1.5.3 sección determinadapredefinidos
UTF-8 codificada.
[MQTT-3.3.2-2]
PUBLISH mensajeel nombre del tema en el textono puedeincluye comodines.
[MQTT-3.3.2-3]
El servidor envía al suscriptordel cliente suscriptor PUBLISH paqueteel nombre del temadebecoincidenciael tema de la suscripciónfiltro
(según 4.7 la coincidencia definida en la secciónproceso).
[MQTT-3.3.4-1]
PUBLISH mensajeel receptor del paquetedebesegúnsegún PUBLISH en el mensaje QoS nivelenviar respuesta, ver
tabla 3.4 la descripción de.
[MQTT-3.3.5-1]
Servidordebeel mensajeSe distribuye a todas las suscripciones coincidentesasignados QoS El cliente con el nivel más altoextremo.
[MQTT-3.3.5-2]
Si el servidor implementano autoriza a un determinado clienteel cliente publica PUBLISH el mensaje, no tieneforma de notificar a eseCliente
extremo.ellodebede acuerdo con lo normal QoS reglaEnviar una confirmación positivaconfirmar, oCerrar la conexión de red.
[MQTT-3.6.1-1]
PUBREL ordenencabezado fijo del mensaje de controlel primero de la cabecera 3,2,1,0 la posición esbit reservado,debese establece en 0,0,1,0. servicio
extremo de serviciodebeTratar cualquier otro valor como noválido y cerrarconexión de red.
[MQTT-3.8.1-1]
SUBSCRIBE ordenmensaje de control fijodel encabezado fijo, el 3,2,1,0 el bit está reservadoposición,debese establecen respectivamente como 0,0,1,0。
Servidordebetransmitir otrosCualquier valor de ello se considera comoilegal y cerrarcerrar la conexión de red.
[MQTT-3.8.3-1]
SUBSCRIBE mensajemensaje válidoel filtro de temas en la carga útillistadebeSí 1.5.3 la seccióndefinido UTF-8 carácter
cadena。
[MQTT-3.8.3-2]
Si el servidor seleccionano admite incluir comodinesel filtro de temas con comodines,deberechazar cualquierincluye filtro de comodinesfiltrar
la solicitud de suscripción del filtro。
[MQTT-3.8.3-3]
SUBSCRIBE mensajeel mensaje tienecarga útildebecontiene al menos unpara el filtro de temas y QoS nivelgrupo de campos
Coincidencia. Sin carga útilde carga SUBSCRIBE paquetees una violación del protocolo.。
[MQTT-3-8.3-4]
Si en la carga útilde cualquier bit es novalor cero, o QoS no es igual 0,1 o 2，Servidordebeconsidera
SUBSCRIBE mensajeel mensaje no esválido y cerrar la conexión de redconexión.
[MQTT-3.8.4-1]
El servidor recibe al clienteuno enviado por el extremo SUBSCRIBE Cuando el mensaje,debeUsar SUBACK Mensaje de respuesta
respuesta.
[MQTT-3.8.4-2]
SUBACK paquetedebey esperando confirmación SUBSCRIBE paquetetiene el mismo paqueteidentificador de paquete.
[MQTT-3.8.4-3]
Si el servidor recibeun SUBSCRIBE paquete, paquetedel filtro de temas y uno existenteel tema de la suscripción
Filtro de tema idéntico,entoncesdebeusando la nueva suscripciónla suscripción reemplaza por completo la actualla suscripción guardada. La nueva suscripción defiltro de tema
Filtro y suscripción previaigual, peroel máximo de QoS el valor puede ser diferente.con este filtro de temascoincide con el filtro
Cualquier retenido existentemensajedebese reenvía,peroflujo de publicaciónno puedeinterrupción.
[MQTT-3.8.4-4]
Si el servidor recibecontiene múltiples temasdel filtro SUBSCRIBE el paquete,ellodebecomo si hubiera recibido un
varios de la serie SUBSCRIBE paqueteprocesar ese de la misma manera, excepto que es necesariofusionar sus respuestas en una solaunidad
Separado SUBACK mensajemensaje enviado.
MQTT-3.1.1-CN 67
[MQTT-3.8.4-5]
El servidor envía al clientedel cliente SUBACK par de mensajesCada par de filtros de temadispositivo y QoS esperartodos los nivelesdebePaquete
Contiene un código de retorno.este código de retornodebeindica que esa suscripción fue otorgadael máximo de QoS nivel,o indica
esta suscripción falla。
[MQTT-3.8.4-6]
El servidor puede otorgarde lo que el suscriptor requiereun poco más bajo QoS Nivel. En respuesta a la suscripciónmensaje enviado por la suscripcióndel mensaje
de la carga útil QoS debeSímensaje de publicación originaldel mensaje QoS yotorgado por el servidor QoS dosel menor de los
Valor. Si el mensaje originaldel mensaje QoS Sí 1 y se le concedeel máximo de QoS Sí 0, permitiendo que el servidor repitaenviar un
Una copia del mensaje asuscriptor.
[MQTT-3.9.3-1]
el orden de los códigos de retornodebey SUBSCRIBE paquetefiltro de temasEl orden del dispositivo es el mismo。
[MQTT-3.9.3-2]
0x00, 0x01, 0x02, 0x80 deexterno SUBACK El código de retorno está reservadode,no puedeuso.
[MQTT-3.10.1-1]
UNSUBSCRIBE mensajedocumento fijodel encabezado fijo, el 3,2,1,0 el bit está reservadoreservado ydebeestablecer respectivamentePara
0,0,1,0. servicioextremo de serviciodebeConsidera cualquier otroLos valores son todos inválidosy cerrar la redconexión.
[MQTT-3.10.3-1]
UNSUBSCRIBE mensajeen el textodel filtro de temasdebese empaqueta de forma continua, según 1.5.3 la seccióndefinido
UTF-8 cadena codificada.
[MQTT-3.10.3-2]
UNSUBSCRIBE mensajedel documentocarga útildebeAl menos incluyecontiene un mensajeFiltro. No hayde la carga útil
UNSUBSCRIBE mensajeel texto esque viola el protocolo。
[MQTT-3.10.4-1]
UNSUBSCRIBE mensajeel documento proponeel filtro de tema proporcionado (sin importar si contieneComodín）debemantener con el servidor
De este clientedel filtro de tema actualel conjunto de filtros se compara carácter por carácterComparación. Si hay algúnCualquier filtro coincide completamente
configuración,Entonces él (el servidor)su propia suscripción será eliminada, de lo contrario no habráprocesamiento adicional。
[MQTT-3.10.4-2]
Si el servidor eliminauna suscripción,ellodebeDejar de distribuir cualquier nuevomensaje a estecliente.
[MQTT-3.10.4-3]
Si el servidor eliminauna suscripción,ellodebeCompletar la distribución de cualquier yaya ha comenzado a enviar al clienteenviado por el cliente QoS
1 y QoS 2 el mensaje de。
[MQTT-3.10.4-4]
Servidordebeel UNSUBACK mensajerespuesta del mensajedel cliente UNSUBSCRIBE Solicitud.
UNSUBACK paquetedebeincluye y UNSUBSCRIBE paqueteel mismo paqueteidentificador.
[MQTT-3.10.4-5]
incluso siNo se eliminó ninguna suscripción a temas,Servidortambiéndebeenviar un SUBACK Respuesta。
[MQTT-3.10.4-6]
Si el servidor recibecontiene múltiples temasdel filtro UNSUBSCRIBE el paquete,ellodebecomo si hubiera recibido
una serie de múltiples UNSUBSCRIBE mensajese procesa igual que el mensajeprocesar ese paquete,excepto para susrespuesta combinada en
un único UNSUBACK paqueteexterior.
[MQTT-3.12.4-1]
Servidordebeel PINGRESP Respuesta de paquetedel cliente PINGREQ paquete。
[MQTT-3.14.1-1]
Servidordebeverificar lo queTodos los indicadores de retención se establecena 0, siellos no son 0 debemientras su conexiónconexión.
[MQTT-3.14.4-1]
el cliente envía DISCONNECT mensajedespués del texto,debecerrar la redconexión.
[MQTT-3.14.4-2]
el cliente envía DISCONNECT mensajedespués del texto,no puedea través de eseconexión de red nuevamenteEnviar cualquier mensaje de control
documento.
[MQTT-3.14.4-3]
el servidor reciba DISCONNECT mensajecuando el mensaje,debedescartar cualquierLo no asociado a la conexión actualtestamento publicado
Mensaje de instrucción, descripción específicaver 3.1.2.5 sección.
[MQTT-4.1.0-1]
durante toda la sesión, el cliente y elel servidor tambiéndebealmacenar estado de sesiónestado.
[MQTT-4.1.0-2]
sesióndebeAl menos continuar con su conexión de red activaconectar durante el mismo tiempoespacio.
MQTT-3.1.1-CN 68
[MQTT-4.3.1-1]
Para QoS 0 deprotocolo de distribución, el emisorremitentedebeel QoS igual a 0，DUP igual a 0 de PUBLISH
paquete。
[MQTT-4.3.2-1]
Para QoS 1 deprotocolo de distribución,remitente
Cada vez que envía una nueva aplicaciónusar todos los mensajesdebeasignar un no utilizadoEl identificador de paquete utilizadocarácter.
MUST send a PUBLISH Packet containing this Packet Identifier with
QoS=1, DUP=0.
enviado PUBLISH paquetedebecontiene el mensajeidentificador y QoS igual a 1，DUP igual a
0。
debeeste PUBLISH paquetese considera como
no confirmado
，hasta querecibido del receptor lo correspondiente
de PUBACK paquete.4.4 el byte tiene ununa sobre no confirmadodiscusión de mensajes.
[MQTT-4.3.2-2]
Para QoS 1 deprotocolo de distribución, el receptorceptor
de la respuesta PUBACK paquetedebecontiene unidentificador de mensaje,usando este identificadordesde la recepción
de,que ha aceptado la propiedad PUBLISH paquete.
envió PUBACK mensajedespués del texto,el receptor debecualquier paquete que contenga el mismo identificador de paquetedel identificador entrante
sitio PUBLISH paquetecomo un nuevoel mensaje, e ignorar su DUP banderasel valor de.
[MQTT-4.3.3-1]
Para QoS 2 deprotocolo de distribución, el emisorremitente
debe proporcionar a lo que se va a enviarnueva distribución de mensajes de aplicaciónAsignar un identificador de paquete no utilizadoidentificador.
MUST send a PUBLISH packet containing this Packet Identifier with
QoS=2, DUP=0.
enviado PUBLISH paquetedebecontiene el mensajeidentificador y paquetede QoS igual a 2,，DUP
igual a 0。
debeeste PUBLISH paquetese considera como
no confirmado
，hasta querecibido del receptor lo correspondiente
de PUBREC paquete.4.4 la secciónHay una sobre lo no confirmadodiscusión de mensajes.
Recibido PUBREC después del mensajedebeenviar un PUBREL paquete.PUBREL el mensaje debe
contiene el original PUBLISH el mismo paqueteidentificador de paquete.
MUST treat the PUBREL packet as “unacknowledged” until it has
received the corresponding PUBCOMP packet from the receiver.
debeeste PUBREL mensajeel texto se considera como
no confirmado
，hasta querecibir del receptor el correspondiente
PUBCOMP paquete.
una vez que se ha enviado el correspondientede PUBREL entonces el mensajeno puedereenviar este PUBLISH paquete.
[MQTT-4.3.3-2]
ParaQoS 2del protocolo de distribución, recibirpersona
de la respuesta PUBREC paquetedebeContiene un identificador de paquete, esteidentificador de lo recibido、
yaaceptar la propiedad de PUBLISH paquete.
al recibir el correspondiente PUBREL antes del mensaje,receptordebeel PUBREC mensajeconfirmación de mensajecualquier
cualquier subsiguiente con la mismacon el mismo identificador PUBLISH paquete. en este casodebajo, élno puederepetir
distribuir mensajes a cualquierlos receptores posteriores。
Respuesta PUBREL del mensaje PUBCOMP paquetedebecontiene con PUBREL mensajeel mismo mensaje
identificador.
el PUBCOMP mensajedel documentodespués, el receptordebe contener el mismocualquiera con el mismo identificador de paquetedespués
continuar PUBLISH paquetecomo un nuevola publicación.
MQTT-3.1.1-CN 69
[MQTT-4.4.0-1]
el cliente establece la limpiezasesión (CleanSession) etiquetamarcado como 0 reconexióncuando el clientey el servidordebeHacer
con el identificador del paquete originalreenviar cualquier identificadorno confirmado PUBLISH mensaje (si QoS>0) y
PUBREL paquete。
[MQTT-4.5.0-1]
el servidor se hace cargo de la entradala propiedad de los mensajes de aplicacióncuando tiene derecho, estedebeel mensajeañadir a la suscripciónclientes coincidentesde
en el estado de sesión.coincidenciaver definición de reglas 4.7 sección.
[MQTT-4.5.0-2]
Clientedebesegún sea posiblela calidad de servicio utilizada (QoS) confirmación de reglacualquier cosa que reciba PUBLISH el paquete,
sin importarelige si procesar el mensaje que contienede los mensajes de aplicación。
[MQTT-4.6.0-1]
reenviar cualquier anterior PUBLISH mensajecuando el mensaje,debeSegún el original PUBLISH paquetereenviar en el orden de envío
(se aplica a QoS 1 y QoS 2 mensaje）。
[MQTT-4.6.0-2]
debesegún el correspondiente PUBLISH el envío ordenado de los paquetes PUBACK mensajedocumento (QoS 1 mensaje）。
[MQTT-4.6.0-3]
debesegún el correspondiente PUBLISH el envío ordenado de los paquetes PUBREC mensajedocumento (QoS 2 mensaje）。
[MQTT-4.6.0-4]
debesegún el correspondiente PUBREC orden de los mensajesenviar en orden PUBREL Mensaje (QoS 2 mensaje）。
[MQTT-4.6.0-5]
Servidordebeautenticación predeterminadaPara cada tema haydel orden. EstopuedeProporcionar ununa función de administración ootras máquinas
mecanismo, parase permiteUno o más temastratar comodesordenado。
[MQTT-4.6.0-6]
el servidor procesa el envíoa temas ordenadoscuando el mensaje,debesegún lo anteriorciertas reglas para el mensajemensaje distribuido a cadareservar
lector.además, ellodebesegún lo recibido del clienteenviar en el orden de recepción PUBLISH paquetea los consumidores (para los correspondientes
el mismo tema y QoS）。
[MQTT-4.7.1-1]
en el filtro de tema se puedepara usar comodines, pero el nombre del temano puedeUsarcomodín.
[MQTT-4.7.1-2]
los comodines multinivel debensituado en su propionivel o después del nivel de temadespués del separador de nivel. Independientemente de la situación
situación,todo esodebees el último carácter del filtro de temaUn carácter。
[MQTT-4.7.1-3]
En el filtro de temacualquier nivel puedese puede usar el comodín de un solo nivel,Incluye eluno y el últimoun nivel.
sin embargoellodebeocupa todo el nivel del filtro。
[MQTT-4.7.2-1]
Servidorno puedeva a $ Coincidencia de nombres de tema que comienzan con caracterescoincide con el comodín (#o+) Comenzandoel filtro de temas del encabezadodispositivo.
[MQTT-4.7.3-1]
todos los nombres de tema yFiltro de temadebeDebe contener al menos un carácter.
[MQTT-4.7.3-2]
nombre de tema y filtro de temafiltrono puedecontiene caracteres nulos (Unicode U+0000) [Unicode] 。
[MQTT-4.7.3-3]
nombre de tema y filtro de temaEl filtro es UTF-8 cadena codificada, ellosno puedesupera 65535 va antes del byte de orden bajo。
[MQTT-4.7.3-4]
Al coincidir con la suscripción, el servidorextremo de serviciono puedePara el nombre del tema oel filtro de tema ejecutarealizar cualquier normalización
（normalization）procesamiento,No se puede modificar ni reemplazar ningúncualquier carácter no reconocidocarácter.
[MQTT-4.8.0-1]
a menos que se especifique lo contrario,si el servidor oel cliente se encuentra concomportamiento de violación de protocolo,ellodebedesactivar la transmisión de este
un control de violación de protocoloconexión de red del paqueteconexión.
[MQTT-4.8.0-2]
Si el cliente o el servidorEl servidor procesa la entradaal encontrar una condición transitoria al procesar el mensaje de controlerror al,ellodebeCerrar esa transmisión
la red de paquetes de controlconexión.
[MQTT-6.0.0-1]
MQTT Paquete de controldebeUsar WebSocket datos binariosLa trama de datos se envía. Sirecibir cualquier otroTipo
de la trama de datos, recibirpersonadebecerrar la conexión de red。
[MQTT-6.0.0-2]
único WebSocket baseUna trama de datos puede contener múltiplesuno o parte MQTT mensaje. El receptorno puedeSuponga que
MQTT mensajes de control según WebSocket alineación de límites de trama。
MQTT-3.1.1-CN 70
[MQTT-6.0.0-3]
Clientedebeel caráctercadena mqtt incluido en élproporcionado por WebSocket subprotocoloen la lista de protocolos.
[MQTT-6.0.0-4]
El servidor selecciona y devuelvede respuesta WebSocket subprotocolonombre de protocolodebeSí mqtt
[MQTT-7.0.0-1]
MQTT la implementación puede ser a la vez MQTT el cliente y MQTT Servidor. Aceptar entrantesConexión de estación y establecimiento a su
su saliente del servidorservidor conectadodebe cumplir simultáneamente MQTT el cliente y MQTT los requisitos del lado del servidor
solicitud.
[MQTT-7.0.0-2]
para con cualquier otroimplementación conformeinteroperabilidad, unala implementación conforme no puederequiere usar en estefuera de la especificación
cualquier extensión definida。
[MQTT-7.1.1-1]
satisfacer los requisitos de consistenciadel servidordebeadmite el uso de ununo o más protocolos de transporte subyacentesprotocolo de transporte, siempre queproporciona
ordenado yFlujo de bytes bidireccional confiable (del cliente al servidorServidor y desde el servidor al clientecliente)
[MQTT-7.1.2-1]
satisfacer los requisitos de consistenciadel clientedebeadmite el uso de ununo o más protocolos de transporte subyacentesprotocolo de transporte, siempre queproporciona
ordenado yFlujo de bytes bidireccional confiable (del cliente al servidorServidor y desde el servidor al clientecliente)
