TechSchool

 
  MQTT-3.1.1-CN  1 
 
MQTT Протокол 3.1.1 Китайская версия 
OASIS Стандарт 
2014 год 10 месяц 29 день 
ссылка на спецификацию 
текущая версия： 
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.doc (Авторитетный) 
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 
предыдущаяверсия: 
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/cos01/mqtt-v3.1.1-cos01.doc (Авторитетный) 
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 
последняя версия： 
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.doc (Aавторитетный) 
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 
Технический комитетКомитет: 
Стандарты структурированной информациипродвигающая организация MQTT Технический комитет 
Председатель： 
Raphael·J· Cohen (raphael.cohn@stormmq.com), Частное лицо 
Richard·J· Koppen (coppen@uk.ibm.com), IBM 
Правка： 
Andrew Banks (Andrew_Banks@uk.ibm.com), IBM 
Rahul Gupta (rahul.gupta@us.ibm.com), IBM 
Связанная документация： 
Эта спецификация связана с этим： 
  MQTT и NIST сетевая безопасностьФреймворк 1.0 Версия. Редакторы — Jeff Brown и Louis·Philip· Lamule. Последняя версия
Это: http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-
v1.0.html. 
Итог： 
MQTT являетсяклиентским сервисомРазработка конечной архитектурытканевая/модель подпискипротокол передачи сообщений.Его философия проектирования —лёгкость,открытость、
Простая、спецификация，ПоэтомуЛегко реализуется.Эти характеристики делаютего полезным для многих сценариевявляется очень хорошим выбором, включаяограниченные среды, такие как
Межмашинное взаимодействиеВерьте (M2M）и IoTсетевая среда (IoT），ЭтиСценарий требует очень мало кодаинкапсуляция кода или сетьпропускная способность сети
Очень дорого. 
этот протоколРаботаетВ TCP/IP, илиДругие обеспечивают упорядоченную, надёжное, двунаправленноеподключённое сетевое соединениевключено. Оно имеет следующиеследующие функции: 
  используя шаблон публикация/подпискасообщений, обеспечиваяраспределение сообщений один-ко-многими между приложениямиразвязку. 
  Передача сообщений не требуетзнать содержимое полезной нагрузки。 
  Предоставляет три уровнякачества обслуживания:. 

 
  MQTT-3.1.1-CN  2 
  “не более одного раза”, насколько операционная среда можетприложить максимальные усилиядля доставки сообщений.Сообщения могут быть потеряны.Например,Это
Этот уровень можно использовать дляданных датчиков окружающей среды,единичная потеря данныхпотеря не имеет значения,потому чтовскореотправит снова. 
   “не менее одного раза”, гарантируя, что сообщения могут прибытьдостичь,номогут повторяться. 
   “только один раз”，ГарантияСообщение доставляется только один раз. Например,ЭтоЭтот уровень можно использовать вплатёжной системев, если здесь
Дублирование или потеря сообщенияприведёт к неправильнойплате. 
  Очень малые накладные расходы на передачуи обмен протокольными даннымиобмен, минимизировать в наибольшей степенисетевой трафик 
  Происходит аварийное отключение соединенияКогда это происходит, можно уведомитьсоответствующие стороны. 
 
состояние: 
Этот документ в последний раз OASIS членами вИтоговый указанный вышепересмотрен или одобрен.уровень одобрения такжеУказано выше.если
Чтобы просмотреть самыйновую редакцию, пожалуйстапроверьте выше 
последняя версия
 Расположение. Создано техническим комитетомдругие редакции идругие технологии
Все технические документы перечислены здесьВнутри:https://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=mqtt#technical 。 
Члены технического комитетакомментарии к этой спецификацииОбсуждение должно быть отправлено в технический комитетсписок рассылки комитетаТаблица. Остальные должны отправитькомментарии в технический комитет
Публичные комментарии комитетасписок, методзаключается в том, чтобы нажатьНажмите технический комитетвеб-сайта ассоциации отправить комментарии кнопка,Веб-адрес: 
https://www.oasis-open.org/committees/mqtt/ 。 
О реализации данной спецификацииосновные задачибыл ли раскрыт какой-либо патент,и другая специализированнаяинформация, связанная с условиями лицензиидыхание, пожалуйста, обратитесь к технической документации
Веб-сайт технического комитетаРаздел интеллектуальной собственности（(https://www.oasis-open.org/committees/mqtt/ipr.php）。 
формат ссылкиФорма: 
При цитировании этой спецификации следуетследует использовать следующийформат цитирования: 
[mqtt-v3.1.1] 
MQTT Версия 3.1.1. Под редакцией Эндрю Бэнкса и Рахула Гупты. 29 октября 2014. OASIS 
Стандарт. 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/mqtt-v3.1.1.html. 
   

MQTT-3.1.1-CN 3

 ссылки на документы

 MQTT Протокол 3.1.1 Китайскийпроект перевода

 MQTT Протокол 3.1.1 Китайская версия PDF

 История изменений

издание книга

день период

Примечания к выпуску

1.0.0

2015-07-30

Перевести весь текст,Завершить первичную проверку, опубликовано какпервое издание

1.0.1

2015-10-22

Исправить несколько опечаток,дополнить несколько непереведённых местпереведённого текста

 закрытьдля переводчика

 GitHub

 Блог

 Электронная почта

 
  MQTT-3.1.1-CN  4 
Каталог 
Обзор ...................................................................................................................................................... 8 
1 MQTT Организационная структура протокола ........................................................................................................................ 8 
2 Термин ..................................................................................................................................................... 8 
3 нормативные ссылки .............................................................................................................................................. 9 
4 ненормативные ссылкииспользование ........................................................................................................................................ 10 
5 представление данных ............................................................................................................................................ 12 
5.1 двоичныйбит .................................................................................................................................... 12 
5.2 целочисленноезначение .................................................................................................................................... 12 
5.3 UTF-8 кодированная строка ..................................................................................................................... 12 
6 редакционные соглашения ............................................................................................................................................ 13 
MQTT управляющий пакетформат сообщения ........................................................................................................................... 14 
1 MQTT Структура управляющих сообщений ...................................................................................................................... 14 
2 фиксированный заголовок ............................................................................................................................................ 14 
2.1 MQTT Типы управляющих сообщений .............................................................................................................. 14 
2.2 Флаги ........................................................................................................................................... 15 
2.3 оставшаясядлина .................................................................................................................................... 16 
3 переменный заголовок ............................................................................................................................................ 17 
3.1 Идентификаторысообщения ................................................................................................................................. 17 
4 payload ............................................................................................................................................ 19 
MQTT управляющий пакеттекст .................................................................................................................................. 20 
1 CONNECT – Подключиться к серверу .................................................................................................................. 20 
1.1 Фиксированныйзаголовок .................................................................................................................................... 20 
1.2 переменныйзаголовок .................................................................................................................................... 20 
1.3 допустимаяполезная нагрузка .................................................................................................................................... 26 
1.4 response ........................................................................................................................................... 27 
2 CONNACK – подтверждениезапроса на подключениеНайти .............................................................................................................. 28 
2.1 Фиксированныйзаголовок .................................................................................................................................... 28 
2.2 переменныйзаголовок .................................................................................................................................... 28 
2.3 допустимаяполезная нагрузка .................................................................................................................................... 30 
3 PUBLISH – сообщение публикации ........................................................................................................................ 30 
3.1 Фиксированныйзаголовок .................................................................................................................................... 30 
3.2 переменныйзаголовок .................................................................................................................................... 32 
3.3 допустимаяполезная нагрузка .................................................................................................................................... 33 
3.4 response ........................................................................................................................................... 33 
3.5 action ........................................................................................................................................... 33 
4 PUBACK –подтверждение публикации .......................................................................................................................... 33 
4.1 Фиксированныйзаголовок .................................................................................................................................... 33 
4.2 переменныйзаголовок .................................................................................................................................... 34 
4.3 допустимаяполезная нагрузка .................................................................................................................................... 34 

 
  MQTT-3.1.1-CN  5 
4.4 action ........................................................................................................................................... 34 
5 PUBREC – отправитьпубликация получена (QoS 2, первыйшаг) ........................................................................................ 34 
5.1 Фиксированныйзаголовок .................................................................................................................................... 34 
5.2 переменныйзаголовок .................................................................................................................................... 34 
5.3 допустимаяполезная нагрузка .................................................................................................................................... 35 
5.4 action ........................................................................................................................................... 35 
6 PUBREL – публикацияосвобождена (QoS 2, второйшаг) ......................................................................................... 35 
6.1 Фиксированныйзаголовок .................................................................................................................................... 35 
6.2 переменныйзаголовок .................................................................................................................................... 35 
6.3 допустимаяполезная нагрузка .................................................................................................................................... 36 
6.4 action ........................................................................................................................................... 36 
7 PUBCOMP – отправитьпубликация завершена (QoS 2, шаг 3) ..................................................................................... 36 
7.1 Фиксированныйзаголовок .................................................................................................................................... 36 
7.2 переменныйзаголовок .................................................................................................................................... 36 
7.3 допустимаяполезная нагрузка .................................................................................................................................... 36 
7.4 action ........................................................................................................................................... 36 
8 SUBSCRIBE - тема подписки ................................................................................................................... 37 
8.1 Фиксированныйзаголовок .................................................................................................................................... 37 
8.2 переменныйзаголовок .................................................................................................................................... 37 
8.3 допустимаяполезная нагрузка .................................................................................................................................... 37 
8.4 response ........................................................................................................................................... 39 
9 SUBACK – подтверждение подписки ......................................................................................................................... 40 
9.1 Фиксированныйзаголовок .................................................................................................................................... 40 
9.2 переменныйзаголовок .................................................................................................................................... 40 
9.3 допустимаяполезная нагрузка .................................................................................................................................... 41 
10 UNSUBSCRIBE –Отменаподписки ............................................................................................................ 41 
10.1 фиксированный заголовок .................................................................................................................................. 42 
10.2 переменный заголовок .................................................................................................................................. 42 
10.3 payload .................................................................................................................................. 42 
10.4 response ......................................................................................................................................... 43 
11 UNSUBACK – Подтверждениеотмены подписки .......................................................................................................... 43 
11.1 фиксированный заголовок .................................................................................................................................. 44 
11.2 переменный заголовок .................................................................................................................................. 44 
11.3 payload .................................................................................................................................. 44 
12 PINGREQ – запрос проверки связи ..................................................................................................................... 44 
12.1 фиксированный заголовок .................................................................................................................................. 44 
12.2 переменный заголовок .................................................................................................................................. 45 
12.3 payload .................................................................................................................................. 45 
12.4 response ......................................................................................................................................... 45 
13 PINGRESP – ответ проверки связи ................................................................................................................... 45 
13.1 фиксированный заголовок .................................................................................................................................. 45 

 
  MQTT-3.1.1-CN  6 
13.2 переменный заголовок .................................................................................................................................. 45 
13.3 payload .................................................................................................................................. 45 
14 DISCONNECT –отключение............................................................................................................... 45 
14.1 фиксированный заголовок .................................................................................................................................. 46 
14.2 переменный заголовок .................................................................................................................................. 46 
14.3 payload .................................................................................................................................. 46 
14.4 response ......................................................................................................................................... 46 
рабочее поведение ............................................................................................................................................. 47 
1 хранение состояния ............................................................................................................................................ 47 
1.1 ненормативныйпример ................................................................................................................................. 47 
2 Сетевое соединение ............................................................................................................................................ 47 
3 Качество обслуживанияУровни и протокольные потоки .................................................................................................................. 48 
3.1 QoS 0:не болееодного раза доставки .................................................................................................................. 48 
3.2 QoS 1: как минимумдоставить один раз ................................................................................................................. 48 
3.3 QoS 2: только частьотправить один раз .................................................................................................................... 49 
4 распространение сообщенийПовтор .................................................................................................................................... 51 
5 сообщение получено ............................................................................................................................................ 51 
6 упорядочивание сообщений ............................................................................................................................................ 51 
7 имя топика иФильтр топика ......................................................................................................................... 52 
7.1 топикподстановочный знак ................................................................................................................................. 52 
7.2 с$открытымтопиком заголовка ........................................................................................................................... 53 
7.3 топикСемантика и использование ......................................................................................................................... 53 
8 Обработка ошибок ............................................................................................................................................ 54 
безопасность .................................................................................................................................................... 55 
1 Обзор ................................................................................................................................................... 55 
2 MQTT Решение: безопасность иаутентификация ........................................................................................................... 55 
3 легковесноеШифрование и устройства с ограниченными ресурсами .................................................................................................................. 55 
4 заметки по реализациипункт .................................................................................................................................... 55 
4.1 клиентАутентификация конечной точки ......................................................................................................................... 56 
4.2 клиентавторизация клиента ................................................................................................................................. 56 
4.3 СлужбыАутентификация конечной точки ......................................................................................................................... 56 
4.4 управляющиесообщения и прикладные сообщенияЦелостность сообщений .................................................................................................... 56 
4.5 управляющиесообщения и прикладные сообщенияКонфиденциальность сообщений .................................................................................................... 56 
4.6 Сообщениенеотказуемость передачиподлинность .............................................................................................................. 56 
4.7 обнаружениеклиента и сервераподмена клиента ....................................................................................................... 57 
4.8 обнаружениеаномального поведения ............................................................................................................................. 57 
4.9 прочиемеры безопасностипункт .................................................................................................................. 57 
4.10 Использование SOCKS брокер .................................................................................................................... 58 
4.11 конфигурация безопасностиФайл ........................................................................................................................... 58 
Использование WebSocket doдля сетевого уровня .............................................................................................................. 59 
1 IANA Примечаниеэлемент .................................................................................................................................. 59 

 
  MQTT-3.1.1-CN  7 
7  согласованность ................................................................................................................................................. 60 
7.1 цель согласованностиотметка ........................................................................................................................................ 60 
7.1.1 MQTT Серверная сторона ............................................................................................................................. 60 
7.1.2 MQTT клиент ............................................................................................................................. 60 
приложение B Обязательное нормативное утверждение (ненормативноенормативное) ............................................................................................................. 62 
 

MQTT-3.1.1-CN 8

1 Обзор

1.1 MQTT взаимодействиеорганизационная структура протокола

Данная спецификация разделена на семьглав:

 Глава 1 - Введение

 Глава 2 – MQTT формат управляющего сообщения

 Глава 3 – MQTT управляющий пакет

 Глава 4 – Операционноеповедение

 Глава 5 – безопасность

 Глава 6 – Использование WebSocket В качестве сетевого транспортного уровня t

 Глава 7 – согласованныецели безопасности

1.2 Термин

Используется в этой спецификацииКлючевые слова Требуется ДОЛЖЕН，не может НЕ ДОЛЖЕН，Требование ТРЕБУЕТСЯ，будет ДОЛЖЕН，Не будет ДОЛЖЕН

НЕ，следует СЛЕДУЕТ，не следует НЕ СЛЕДУЕТT，Рекомендуется РЕКОМЕНДУЕТСЯ，Да МОЖЕТ，Необязательно OPTIONAL

все в соответствии с IETF RFC 2119 [RFC2119] описание впояснении.

Сетевое подключение（Сетевое подключение）：

MQTT используетсяБазовый транспортный протоколИнфраструктура протокола。

 Клиент использует его для подключения к серверу.

 Он обеспечивает упорядоченную,надёжнуюиз,Двунаправленную передачу байтового потока.

см. примеры в 4.2 разделе.

сообщение приложения（Сообщение приложения）：

MQTT связь по протоколуПередача по сетиДанные приложения.сообщения приложения через MQTT при передаче ониСвязанная службаКачество обслуживания (QoS) итопик

（Тема）。

клиент（Клиент）：

Использование MQTT программой или устройством.клиенты всегда подключаютсяпо сети, чтобы подключиться кСерверу. ЭтоДа

 Публиковать сообщения приложения другим связаннымклиенту..

 Подпискасзапросомпринимает соответствующие сообщения приложения

 Отписаться, чтобы удалитьполучение сообщений приложениязапрос.

 Отключиться от сервераподключиться.

Серверная сторона（Сервер）：

программа или устройство, как отправляющее сообщениеклиент сообщения иклиент, запрашивающий подпискупосредник между. Серверсервер

 Принимать сетевые подключения от клиентов.

 Принимать публикуемое клиентомприкладное сообщение

MQTT-3.1.1-CN 9

 Обрабатывать подписку клиентаподписка и отписказапрос.

 пересылатьПрименять сообщения кклиентскойподписке соответствующего компонента。

Подписка（Подписка）：

Подписка содержит темуФильтр тем (TФильтр тем) инаибольшее серверноеКачество обслуживания (QoS) уровень. Подписка с однойСессией

（Сессия) связана ссоединением. Сессии могутсодержать более одной подписки. СессияКаждая подписка имеетразличные темы черезфильтр.

имя темы (Имя темы）：

Прикреплённая к сообщению приложенияметка на, известная серверу и с подпискойсопоставление подписки. Сервер отправляетодну копию сообщения приложениякопию каждой соответствующей

клиентской подписки.

фильтр темфильтр (Фильтр тем:）：

один, включённый в подписноевыражение, используемоедля представления связанныходной или нескольких основныхтем. Фильтры тем могутиспользовать подстановочные знаки.

Сеанс（Сеанс）：

Клиент-серверныйобмен состоянием привзаимодействии. Некоторые сеансы длятся, когдадлительность и сетькак сетевое соединение,другие могут быть внесколько клиентов и серверов

непрерывное сетевое соединениепродление интервала.

управляющий пакет（Управляющий пакет MQTT）：

передаваемый по сетевому соединениюпередаваемые информационные данныепакет.MQTT Спецификация определяет четырнадцатьразличных типов управляющих сообщенийтекст,гдеодин (PUBLISH отчёт

сообщение) используется для передачи прикладногосообщения об использовании.

1.3 СпецификацияСправочник

[RFC2119]

Bradner, S., "Ключевые слова для использования в RFC для указания уровней требований", BCP 14, RFC 2119, март

1997.

http://www.ietf.org/rfc/rfc2119.txt

[RFC3629]

Yergeau, F., "UTF-8, формат преобразования ISO 10646", STD 63, RFC 3629, ноябрь 2003

http://www.ietf.org/rfc/rfc3629.txt

[RFC5246]

Dierks, T. и E. Rescorla, "Протокол транспортного уровня безопасности (TLS) версии 1.2", RFC 5246, август

2008.

http://www.ietf.org/rfc/rfc5246.txt

[RFC6455]

Fette, I. и A. Melnikov, "Протокол WebSocket", RFC 6455, декабрь 2011.

http://www.ietf.org/rfc/rfc6455.txt

[Unicode]

Консорциум Unicode. Стандарт Unicode.

http://www.unicode.org/versions/latest/

 
  MQTT-3.1.1-CN  10 
1.4 Ненормативная ссылка 
[RFC793] 
Postel, J. Transmission Control Protocol. STD 7, IETF RFC 793, сентябрь 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] 
Стандарт шифрования данных (DES). 
http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf 
 
[FIPS1402] 
Требования безопасности для криптографических модулей (FIPS PUB 140-2) 
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf 
 
[IEEE 802.1AR] 
Стандарт IEEE для локальной и городской сетиs — безопасная идентификация устройства 
http://standards.ieee.org/findstds/standard/802.1AR-2009.html 
 
[ISO29192] 
ISO/IEC 29192-1:2012 Информационные технологии -- Методы обеспечения безопасности -- Легковесная криптография -- Часть 
1: Общие положения 
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=56425 
 
[MQTT NIST] 
MQTT дополнительная публикация, MQTT и the Структура NIST по улучшению кибербезопасности критической инфраструктурыe 
Кибербезопасность 
http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-v1.0.html 
 
[MQTTV31] 
MQTT V3.1 Спецификация протокола. 
http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html 
 
[NISTCSF] 
Улучшение критической инфраструктуры кибербезопасности. Указ 13636 
http://www.nist.gov/itl/upload/preliminary-cybersecurity-framework.pdf 
 
[NIST7628] 
NISTIR 7628 Руководящиеуказания по кибербезопасности интеллектуальной энергосети 
http://www.nist.gov/smartgrid/upload/nistir-7628_total.pdf 
 
[NSAB] 
КриптографияNSA Suite B 
http://www.nsa.gov/ia/programs/suiteb_cryptography/ 
 

 
  MQTT-3.1.1-CN  11 
[PCIDSS] 
PCI-DSS Стандартбезопасности данных индустрии платежных картard 
https://www.pcisecuritystandards.org/security_standards/ 
 
[RFC1928] 
Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., и L. Jones, "Протокол SOCKS версии 5", RFC 
1928, март 1996.  
http://www.ietf.org/rfc/rfc1928.txt 
 
[RFC4511] 
Sermersheim, J., ред., «Облегченныйпротокол доступа к каталогам(LDAP): Протокол», RFC 4511, июнь 
2006. 
http://www.ietf.org/rfc/rfc4511.txt 
 
[RFC5077] 
Salowey, J., Zhou, H., Eronen, P., и H. Tschofenig, "Transport Layer Security (TLS) Session 
Возобновление без серверногосостояния", RFC 5077, 20 января08. 
http://www.ietf.org/rfc/rfc5077.txt 
 
[RFC5280] 
Купер, Д., Сантессон, С., Фаррелл, С., Бойен, С., Хаусли, Р., и У. Полк, "Интернет X.509 открытыйключ 
Сертификат инфраструктуры и профиль спискааннулированных сертификатов (CRL)", RFC 5280, май 2008. 
http://www.ietf.org/rfc/rfc5280.txt 
 
[RFC6066] 
Eastlake 3rd, D., "Расширениябезопасноститранспортногоуровня (TLS): определения расширений", RFC 6066, январьy 
2011.  
http://www.ietf.org/rfc/rfc6066.txt  
 
[RFC6749] 
Hardt, D., Ed., "OAuth 2.0 : Структура авторизации", RFC 6749, октябрь 2012. 
http://www.ietf.org/rfc/rfc6749.txt 
 
[RFC6960] 
Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., и C. Adams, "X.509 Internet Public 
Инфраструктура ключей. Онлайн-протокол статуса сертификата - OCSP", RFC 6960, июнь 2013. 
http://www.ietf.org/rfc/rfc6960.txt 
 
[SARBANES] 
Закон Сарбейнса-Оксли 2002 года. 
http://www.gpo.gov/fdsys/pkg/PLAW-107publ204/html/PLAW-107publ204.htm 
 
[USEUSAFEHARB] 
Соглашение «Безопасная гавань» между США и ЕС 
http://export.gov/safeharbor/eu/eg_main_018365.asp 

MQTT-3.1.1-CN 12

1.5 представление данных

1.5.1 двоичный бит

биты в байте от 0 до 7. Бит № 7 — самый старшийзначащий бит, этот 0 бит является младшим значащим битом.

1.5.2 целочисленное значение

Целочисленное значение занимает 16 бит, используя big-endian (big-endian，старшийбайтперед младшим байтомначале). Это означаетс 16 -битнымсимволом в сети

в сети представлено как старшийзначащий байт (MSB), за которым следуетмладшее значащее словораздел (LSB）。

1.5.3 UTF-8 -кодированная строка

управляющий пакет, описанный нижетекст в управляющем сообщенииэто поле кодируется как UTF-8 символы форматастрока.UTF-8 [RFC3629] являетсяэффективным

Unicode кодировка символовформат, для поддержки radixдля текстовой связи, это ASCII Символьнаякодировка выполняетоптимизацию.

Каждая строкаимеет двухбайтовоеполе длины какв качестве префикса, оно выдаётдля этой строки UTF-8 закодированных байтовколичество,ониВлегенде

1.1 UTF-8 редакцияструктура кодовой строки описана вописана. Следовательно, что может быть передано UTF-8 кодировкаразмер строки имеетограничение, не может превышатьпроходить

65535 байт。

Если не указано иное,все UTF-8 редакциикодовой строкидлина должна быть 0 до 65535 байтав этом диапазоне。

легенда 1.1 UTF-8 закодированный символконец строкиструктура

двоичный бит

байт 1

максимальная длина строкистарший байт (MSB）

байт 2

максимальная длина строкимладший байт (LSB）

байт 3 ….

если длина превышает 0, здесь UTF-8 количество закодированных символовданные.

UTF-8 кодировкасимволы в строкесимвольные данныетребуетсяв соответствии с Unicode Спецификация [Unicode] определён и в RFC3629 [RFC3629] Средняя

подтверждён как действительный UTF-8 формат. Особенно необходимоотметить, чтоЭтиданныене можетсодержать код символа в U+D800 и U+DFFF между

данные.еслисервер или клиент получаетпришёл содержащийНедопустимый UTF-8 управляющих символовпакет, онтребуетсязакрыть сетевоесоединение [MQTT-

1.5.3-1]。

UTF-8 кодировкастрокане можетсодержать нулевой символ U+0000。есликлиент или сервер получаетдостиг содержащего U+0000 управленияпакет управления

текст,этоТребуетсязакрыть сетевое соединение [MQTT-1.5.3-2]。

в данныхне должнысодержать следующую Unicode кодовую точкукодировке. Еслиполучатель (сервер или клиент) получил пакетсодержащий следующее

управление произвольными символамипакет, онДазакрыть сетевое соединениеподключиться:

U+0001 и U+001F междуУправляющий символ

U+007F и U+009F междуУправляющий символ

Unicode Спецификацияопределённая не-символьная кодовая позиция (например, U+0FFFF）

Unicode Спецификацияопределённая гарантиязарезервированные символы (например, U+0FFFF）

MQTT-3.1.1-CN 13

UTF-8 кодирующаяпоследовательность 0XEF 0xBB 0xBF всегдаинтерпретируется как U+FEFF(символ неразрывного пробела нулевой ширины),независимо от того,где он появляется в символе

в какой позиции в строке,все получатели сообщенияне могут пропустить илиудалить его [MQTT-1.5.3-3]。

1.5.3.1 необязательныйПример

Например, строка A𪛔 Далатинскаябуква A за которой следуеткодовая точка U+2A6D4(Он представляетCJK Unifiedидеографический символ

Расширения B символ в)，Этокодирование строкиследующим образом:

Условные обозначения 1.2 UTF-8 закодированный символнеобязательная строкапример

Bit

байт 1

длина строки MSB (0x00)

байт 2

длина строки LSB (0x05)

байт 3

‘A’ (0x41)

байт 4

(0xF0)

байт 5

(0xAA)

байт 6

(0x9B)

байт 7

(0x94)

1.6 редакционные соглашения

В данной спецификации используется жёлтая подсветка дляяркого текстового идентификатораутверждения о соответствии,каждому утверждению о соответствииприсваивается один такойСсылка на формат:[MQTT-x.x.x-

y]。

MQTT-3.1.1-CN 14

2 MQTT управляющий пакетФорматирование

2.1 MQTT Структура управляющих сообщений

MQTT связь по протоколупутём обмена предопределённымисемантическими MQTT управляющими пакетами дляСвязь. В этом разделеописываетсяформат этих пакетов.

MQTT управляющий пакетпакет состоит из трёх частейсоставлен, согласно легенде 2.1 –MQTT управляющийструктура управляющего пакета порядок описания:

легенда 2.1 –MQTT управляющего пакетаСтруктура

Фиксированный заголовок постоянныйфиксированный заголовок, всеуправляющие пакеты все включаютсодержат

Переменный заголовок переменный заголовок,некоторые управляющие пакетысодержат

Полезная нагрузка полезная нагрузка, некоторые управляющие пакетысодержат

2.2 фиксированный заголовок

каждый MQTT управляющийуправляющие пакеты все содержатфиксированный заголовок。легенда 2.2 -сплошнойформат фиксированного заголовка описывает фиксированный заголовокформат заголовка.

легенда 2.2 -Фиксированныйформат заголовкаформула

Bit

байт 1

MQTT управляющий пакеттип сообщения

используется дляуказанного типа управляющего сообщениябит флага

байт 2…

оставшаясядлина

2.2.1 MQTT Типы управляющих сообщений

позиция:№ 1 байта, двоичные биты 7-4。

представлено как 4 № битазначения символов, эти значениясм. определение Таблица 2.1 -Типы управляющих сообщений

Table 2.1 -управляющегопакетатип

name

Значение

сообщениенаправление потока

Описание

Зарезервировано

Запретить

сохранять

CONNECT

от клиента к серверу

Клиент запрашивает подключениеНа стороне сервера

CONNACK

от сервера к клиенту

пакет подключенияподтверждение

PUBLISH

разрешены оба направления

публикуемое сообщение

PUBACK

разрешены оба направления

QoS 1 Сообщениепубликацияполученоподтверждение

PUBREC

разрешены оба направления

Публикация получена (гарантированнаядоставка, шаг 1)

PUBREL

разрешены оба направления

Освобождение публикации (гарантированнаядоставка, шаг 2)

MQTT-3.1.1-CN 15

PUBCOMP

разрешены оба направления

QoS 2 СообщениеПубликация завершена (гарантиягарантированное взаимодействие, шаг 3）

от клиента к серверу

Запрос подписки клиента

SUBACK

от сервера к клиенту

запрос подпискисообщениеподтверждение

UNSUBSCRIBE

от клиента к серверу

Клиент отписываетсязапрос

UNSUBACK

от сервера к клиенту

Отмена подпискисообщениеподтверждение

PINGREQ

от клиента к серверу

запрос проверки связи

PINGRESP

от сервера к клиенту

ответ проверки связи

DISCONNECT

от клиента к серверу

Клиент отключается

Зарезервировано

Запретить

сохранять

2.2.2 Флаги

фиксированный заголовок, 1 оставшиеся байты 4 биты [3-0]содержит каждый MQTT управляющий пакетфлаги, специфичные для типа сообщения,см. Таблица 2.2 -бит флага。

Таблица 2.2 любые, помеченные как“retain”флаговые биты, все зарезервированыдля будущего использования,Обязательноустановить как в таблицеперечисленные значения [MQTT-

2.2.2-1]。еслипри получении недопустимого флага, получательполучательОбязательноЗакрыть сетевое соединение. Имеютсясвязанные с обработкой ошибокПодробнее см. в 4.8 разделе [MQTT-

2.2.2-2]。

Таблица 2.2 -бит флага

управляющий пакет

solidфлаги фиксированного заголовка

Бит 3

Бит 2

Бит 1

Бит 0

CONNECT

Зарезервировано

CONNACK

Зарезервировано

PUBLISH

Используется в MQTT 3.1.1

DUP

QoS

RETAIN

PUBACK

Зарезервировано

PUBREC

Зарезервировано

PUBREL

Зарезервировано

PUBCOMP

Зарезервировано

SUBACK

Зарезервировано

UNSUBSCRIBE

Зарезервировано

UNSUBACK

Зарезервировано

PINGREQ

Зарезервировано

PINGRESP

Зарезервировано

DISCONNECT

Зарезервировано

MQTT-3.1.1-CN 16

DUP

=управлениедублирование доставки пакетовфлаг отправки

QoS

= PUBLISH сообщениеобуровне качества обслуживания

RETAIN

= PUBLISH пакетаretainФлаги

PUBLISH управлениев пакете DUP, QoS и RETAIN описание флагаописано в 3.3.1 разделе.

2.2.3 оставшаяся длина

позиция:от первого 2 начинается с байта.

оставшаясядлиннаястепень（Remaining Length）представляетКогдапредыдущее сообщениеоставшийся текстостатокРазделитьизбайтномер,включаяможетпеременное сообщениезаголовок иотрицательнаянагрузкаизданных。оставшаясядлиннаястепень

исключая байты, используемые для кодированияполе Remaining Lengthего собственное количество байтов。

оставшаяся длинаполе длиныиспользоватьпеременную длинуметод кодированияслучае,Для менее чем 128 значенияэто делаетИспользовать один символразделкодирование. большеезначение, как нижеспособОбработка.

Младшие 7 значащие биты используются для кодирования данных., самый старший битиспользуется для указания, есть ли ещёбайт из. Следовательно, каждый байтможет кодировать 128 числозначений

бит продолжения (

бит продолжения

）

. Поле Remaining Lengthмаксимальное количество 4 символовраздел.

ненормативныйкомментарий

ПримерНапример，десятьвведитесистемныйномер 64 будетС помощьюредактироватькодявляетсяодинэлементыСимволраздел, значениеДа 64，десятьшестьвведитеsystemТаблицапоказатьявляется 0x40,。десятьвведитесистемныйномерСимвол

321(=65+2*128)кодируетсясоставляет два байта,младший значащий бит находится вперед. Первое словораздел — это 65+128=193. обратите внимание, что наиболеестарший бит —

1 Представляетзапо крайней мереесть ещё один байт. Вторыебайты — 2。

неСпецификациякомментарий

这разрешатьпозволять следуетиспользоватьотправлятьмаксимум 256MB(268,435,455)большоймаленький системыуправленияsystem отчёттекст。这элементычисло ЗначениеВ отчёттекстСреднийизТаблицы показатьДа：

0xFF,0xFF,0xFF,0x7F。

Таблица 2.4 поля Remaining LengthРазмерпоказывает поле оставшейся длиныпредставленное значение зависит отроста байтов.

Таблица 2.4 оставшейся длиныполяРазмер

количество байт

минимальное значение

максимальное значение

0 (0x00)

127 (0x7F)

128 (0x80, 0x01)

16 383 (0xFF, 0x7F)

16 384 (0x80, 0x80, 0x01)

2 097 151 (0xFF, 0xFF, 0x7F)

2 097 152 (0x80, 0x80, 0x80, 0x01)

268 435 455 (0xFF, 0xFF, 0xFF, 0x7F)

соответственно обозначают (каждыйиз младших битов байта 7 , используемыхдля кодирования данных, самый старший бит является флаговым битом）：

1 когда байтов,от 0(0x00)до 127(0x7f)

2 когда байтов,от 128(0x80,0x01)до 16383(0Xff,0x7f)

3 когда байтов,от 16384(0x80,0x80,0x01)до 2097151(0xFF,0xFF,0x7F)

4 когда байтов,от 2097152(0x80,0x80,0x80,0x01)до 268435455(0xFF,0xFF,0xFF,0x7F)

MQTT-3.1.1-CN 17

ненормативныйкомментарий

неотрицательное целое число X использует схему кодирования переменной длиныалгоритм следующий:

encodedByte = X MOD 128

X = X DIV 128

// если есть ещёданные для кодирования, установитестарший бит этогобайта

if ( X > 0 )

encodedByte = encodedByte OR 128

endif

'output' encodedByte

while ( X > 0 )

MOD — этооперация по модулю,DIV — целочисленное деление,OR — это побитовая операция или（C язык,в котором соответственно%，/，|）

ненормативныйкомментарий

поля Remaining Lengthалгоритм декодирования следующий：

multiplier = 1

value = 0

encodedByte = 'следующийбайт из потока'

value += (encodedByte AND 127) * multiplier

multiplier *= 128

if (multiplier > 128*128*128)

throw Error(Malformed Remaining Length)

while ((encodedByte AND 128) != 0)

AND — это битовая операцияоперация AND (C в языке&）

когда этот алгоритм завершается，значение Packageчто включено — этозначение Remaining Length.

2.3 переменный заголовок

некоторый MQTT управляющий пакетсодержитчасть переменного заголовка.он находится в фиксированном заголовкеи полезная нагрузкамежду. Содержимое переменного заголовкав соответствии стипом пакета

варьируется. Может лиидентификатор пакета переменного заголовка(полеPacket Identifier）) существовать всообщениях нескольких типов.

2.3.1 идентификатор пакета

легенда 2.3 -сообщениекласс идентификаторатип

Bit

байт 1

идентификатор пакета MSB

байт 2

идентификатор пакета LSB

MQTT-3.1.1-CN 18

у многих управляющих пакетовчасть переменного заголовкасодержит двухбайтовое полеидентификатора пакета сообщения. Этотпакет является PUBLISH（QoS>0 время)，

PUBACK，PUBREC，PUBREL，PUBCOMP，SUBSCRIBE, SUBACK，UNSUBSCIBE，

UNSUBACK。

SUBSCRIBE，UNSUBSCRIBE и PUBLISH（QoS больше чем 0) управляющий пакетОбязательносодержитненулевой 16 бит идентификатора пакета

символ (Идентификаторпакета）[MQTT-2.3.1-1]. Клиент каждый разотправить новыйиз этих типоввсякий раз, когда сообщениеОбязательноназначитьтекущий

неиспользуемый идентификатор пакетаидентификатор [MQTT-2.3.1-2]. ЕслиКлиент хочет отправить повторноэто специальное управляющееуправляющее сообщение, при последующей повторной передачеэто сообщение

когда,онОбязательноиспользует тот же идентификатор.Когда клиент заканчивает обработку этогопакета, соответствующегоПосле подтверждения этотидентификатор сообщения будетосвобождён как повторно используемый.

QoS 1 из PUBLISH соответствующийявляется PUBACK，QoS 2 из PUBLISH соответствующийявляется PUBCOMP, и SUBSCRIBE или

UNSUBSCRIBE соответствующийотдельноДа SUBACK или UNSUBACK [MQTT-2.3.1-3]。отправитьэлементы QoS 0 из PUBLISH

сообщениеКогда, те же условия также применяются ксерверной стороне [MQTT-2.3.1-4]。

QoS Установлено в 0 из PUBLISH сообщениене можетсодержать идентификатор пакета [MQTT-2.3.1-5]。

PUBACK, PUBREC, PUBREL сообщениеТребуетсясодержащее иизначально отправлено PUBLISH отчетпакет с тем жеидентификатором сообщения [MQTT-2.3.1-

6]. Аналогично,SUBACK и UNSUBACK Требуетсясодержится в соответствующем SUBSCRIBE и UNSUBSCRIBE сообщениииспользуется в текстеиз

идентификатор пакета [MQTT-2.3.1-7]。

требуетсяУправляющий пакет идентификатора сообщения находится в Таблице 2.5 -, которая содержит идентификатор пакетауправляющий пакет из перечислен в.

Таблица 2.5 -содержитидентификатор сообщенияуправляющий символуправляющий пакет

управляющий пакет

идентификатор пакетасимвол идентификаторасегмент

CONNECT

Не требуется

CONNACK

Не требуется

PUBLISH

требуется (если QoS > 0）

PUBACK

требует

PUBREC

требует

PUBREL

требует

PUBCOMP

требует

SUBACK

требует

UNSUBSCRIBE

требует

UNSUBACK

требует

PINGREQ

Не требуется

PINGRESP

Не требуется

DISCONNECT

Не требуется

MQTT-3.1.1-CN 19

клиент и сервернезависимо назначилиидентификаторы сообщений. Следовательно, клиенткомбинация на стороне сервераиспользуя одно и то же сообщениеидентификатор сообщения может быть реализован, и

обмен отправленными сообщениями.

ненормативныйкомментарий

Клиент отправляет идентификаторсимвол является 0x1234 из PUBLISH пакета,это можетможет быть при получении тогосообщения PUBACK издо, сначала

получает отправленное серверомдругой, отличающийсяно идентификатор сообщенияидентификатор также 0x1234 из PUBLISH пакет.

Клиент Сервер

PUBLISH Packet Identifier=0x1234---

--PUBLISH Packet Identifier=0x1234

PUBACK Packet Identifier=0x1234---

--PUBACK Packet Identifier=0x1234

2.4 payload

некоторый MQTT управляющий пакет в пакетепоследняя часть пакетасодержит корректнуюполезную нагрузку, это будет врассмотрено в главе 3.для PUBLISH говорякорректный

полезная нагрузка— это сообщение приложения.Таблица 2.6 – содержит корректныйуправляющий пакет с полезной нагрузкой перечисляет требованияУправляющий пакет полезной нагрузки.

Таблица 2.6 – содержит полезную нагрузкууправляющего сообщениятекст

управляющий пакет

payload

CONNECT

требует

CONNACK

Не требуется

PUBLISH

Optional

PUBACK

Не требуется

PUBREC

Не требуется

PUBREL

Не требуется

PUBCOMP

Не требуется

требует

SUBACK

требует

UNSUBSCRIBE

требует

UNSUBACK

Не требуется

PINGREQ

Не требуется

PINGRESP

Не требуется

DISCONNECT

Не требуется

MQTT-3.1.1-CN 20

3 MQTT управляющий пакет

3.1 CONNECT – подключениесо стороны сервера

от клиента к серверуустановление сетевого соединенияпосле установления клиент отправляет насторону серверапервое сообщение изобязательныхДа CONNECT сообщение [MQTT-

3.1.0-1]。

по сетевому соединениюклиент может толькоотправить один раз CONNECT сообщение. СерверОбязательноклиент отправляетвторой отправленный CONNECT

пакет как нарушение протоколаобрабатывать обычным образом и разрыватьсоединение клиента [MQTT-3.1.0-2]. Что касается ошибокДля обработанной информации см. 4.8 раздел.

полезная нагрузка содержитодно или несколько кодирующихполей. Включаяуникальныйидентификатор клиента,Will топик,Will сообщение, использоватьимя пользователя и пароль.разделить

идентификатор клиентакроме，остальныхВсе поля являются необязательными, на основе флаговых битовдля определения переменного сообщенияв заголовкенужно ливключать эти поля。

3.1.1 фиксированный заголовок

легенда 3.1 –CONNECT фиксированный заголовок сообщенияфиксированный заголовок

Bit

байт 1

MQTT тип пакетатип (1)

Зарезервированные retainбиты

байт 2…

значение оставшейся длины

оставшаяся длинаполе длины

Оставшаяся длина равна Переменному заголовкудлина переменного заголовка（10 байт) плюс полезная нагрузкадлина. Кодированиесм. метод 2.2.3 разделописание.

3.1.2 переменный заголовок

CONNECT отчётПеременный заголовок сообщенияЗаголовок содержит в следующем порядкечетыре поля: протоколимя (Название протокола), протоколУровень（Протокол

Уровень），соединенияфлаг (Connect Flags) иKeep Alive (Keep Alive）。

3.1.2.1 Имяпротокола

легенда 3.2 -Имяпротоколасостоит из байтов

Описание

имя протокола

байт 1

длина MSB (0)

байт 2

длина LSB (4)

байт 3

‘M’

байт 4

‘Q’

байт 5

‘T’

MQTT-3.1.1-CN 21

байт 6

‘T’

Имя протокола — это строка, которая представляет протоколимя протокола MQTT из UTF-8 закодированная строка.MQTT из спецификацииБолее поздние версии не будутменять этосмещение строкии

длина.

если имя протокола неверноподтвердить серверДаотключить клиентасоединение, такжеДасогласнонекоторым другим спецификациямпродолжить обработку CONNECT сообщения. Для

в последнем случае,в соответствии с этой спецификацией,на стороне серверане можетпродолжить обработку CONNECT сообщение [MQTT-3.1.2-1]。

неСпецификациякомментарий

средство анализа пакетов, например, брандмауэры, может использовать протоколимя протокола для идентификации MQTT трафика.

3.1.2.2 уровень протоколадругое

легенда 3.3 - Протокол Уровень байт ПротоколУровеньбайтсоставлять

Описание

уровень протокола

байт 7

Уровень(4)

клиент использует 8 беззнаковый битзначение символа указываетверсию протокола. Дляв 3.1.1 редакциипротокол, уровень протоколазначение поля идентификатораДа 4(0x04). Если отправка

обнаружить неподдерживаемый протоколуровень, серверТребуетсяотправить вотправить код возвратаявляется 0x01(разница уровней протоколане поддерживается) в CONNACK сообщенииresponse

CONNECT сообщение, затем отключитьотключить соединениеклиента [MQTT-3.1.2-2]。

3.1.2.3 идентификатор соединениябудет

байт Connect Flags содержитсодержит некоторые, используемые для указанияопределять MQTT подключениепараметры поведения соединения. Это также указывает, что в полезной нагрузке естьсимволовсуществует ли поле.

легенда 3.4 -биты флагов подключения

Bit

Имя пользователяe

Флаг

Password

Флаг

WСохранение Will

WQoS Will

WФлаг Will

Очистка

Сессия

Зарезервировано

байт 8

На стороне сервераТребуетсяпроверить CONNECT управляющий пакетфлаг retain текстабит (эти 0 биты), является ли он 0，еслине является 0 должен разорватьклиентское соединение

[MQTT-3.1.2-3]。

3.1.2.4 чистый сеансречь

позиция:Бит байта флагов подключения 1 биты

этот бит указываетопределяет состояние сеансаспособ обработки.

клиент и сервермогут сохранять сеанссостояние, чтобы поддерживатьчерез сетевое соединениенадёжную передачу сообщений. Этот бит флагаиспользуется для управления состоянием сеанса

время жизни.

MQTT-3.1.1-CN 22

Если флаг Clean Session (CleanSession）установленустановлен в 0, серверТребуетсяна основетекущего сеанса (сделатьИдентифицируется по идентификатору клиентаразличие) из

восстановление состояния и клиентсвязь между сторонами. Еслиесли нет с этимидентификатором клиентасвязанного сеанса,на стороне сервераТребуетсясоздатьновый сеанс. В

после закрытия соединения,после отключения соединения, клиент и серверсерверТребуетсясохранять информацию о сеанседыхание [MQTT-3.1.2-4]. Когда флаг очисткисессии установлен 0

Соединение сессии разорвано.после этого, серверТребуетсяэтопосле QoS 1 и QoS 2 Уровеньсообщение сохраняется какчасть состояния сессии, если这

Некоторые сообщения соответствуют отключению.при подключении клиентлюбые подписки [MQTT-3.1.2-5]。сервер такжеДаСохранитьудовлетворяет тому же условиюиз QoS 0 Уровень

сообщение.

еслиочиститьуправлятьСессия（CleanSession）меткабудетПоНастройкиявляется 1，клиентконециСлужбыконецТребуетсяотброситьиздообязанностькак можносессия иоткрытьначатьaНовая

избудетречь。будетречьтолькоудерживатьпродолжитьисетьсетьподключитьЦзетот жепримердлинныйизкогдамежду。и这элементыбудетречьзакрытьобъединитьизсостояниеусловиечислосогласноне можетпообязанностьчтоизпослеизбудетречьтяжёлыйиспользование

[MQTT-3.1.2-6]。

Состояние сеанса клиента.состояние включает:

 Отправлено на сервер.конец,НоЕщё не подтверждено QoS 1 и QoS 2 уровеньдругие сообщения

 Получено от сервера., но ещё неподтверждения завершения QoS 2 уровеньдругие сообщения.

Состояние сеанса сервера.состояние включает:

 СеансСуществует ли он, даже если состояние сеансавсех остальных частейпусто.

 Информация о подписке клиента.сообщение.

 Отправлено клиенту.,Но⟦⟧ещё не подтверждено⟦⟧QoS 1Not yet acknowledged QoS 1 и QoS 2 уровеньдругие сообщения。

 собираетсяПередано клиенту. QoS 1 и QoS 2 уровеньдругие сообщения。

 Получено от клиента., но ещё неподтверждения завершения QoS 2 уровнядругие сообщения.

 необязательно,подготовитьОтправлено клиенту. QoS 0 сообщения уровня。

Сохранённые сообщения не находятся на стороне сервера.состояние серверной сессиичастью, будуткогда сессия завершаетсяне могутудалять сохранённые сообщениядыхание [MQTT-3.1.2.7]。

Относительно хранения состояния.ограничения и подробности см.№ 4.1 раздел.

когда флаг clean sessionустановлен в 1 когда,клиент и серверсерверное состояние не нужноесли атомарная операция。

ненормативныйкомментарий

Чтобы гарантировать, что в случаесостояние при сбоесогласованность, клиентсторона должна использовать сессиюфлаг состояния сессии 1 тяжёлыйповторный запрос на подключение, пока подключение не удастся

успех.

ненормативныйкомментарий

Вообще говоря, клиентыв конце всегда при подключениибудут очищать флаг сессиифлаг установлен в 0 или 1，И не используйте попеременно двавида значений. Этовыбор принимает

Зависит от конкретного приложения.. Флаг clean sessionфлаг установлен в 1 клиент небудет получать старыесообщение приложения,более тогопри каждом подключениипосле успеха

Всем нужно переподписаться.любойсвязанныйтопик. Флаг clean sessionустановлен в 0 изКлиент получит всекогда он подключаетсяотключениево время отправки

опубликованные QoS 1 и QoS 2 сообщение на уровне. Следовательно,необходимо обеспечитьне потеряны, пока соединение отключеносообщение, нужноиспользовать QoS 1 или

QoS 2 уровень, одновременно будет очищатьФлаг сессии установлен в 0。

ненормативныйкомментарий

MQTT-3.1.1-CN 23

флаг clean session 0 Когда клиент подключаетсяОн запрашивает сервер, чтобыпосле отключения соединения, сохранитьсохранять свое MQTT состояние сессии.если открыт

Планируется в некоторый более поздний моментпереподключиться в этот момент кэтому серверу,клиентское соединение должнодолжно использовать только флаг cleansession 0. Когда клиент решает

послеКогда эта сессия больше не используется, следуетследует очистить сессиюфлаг установлен в 0 наконец, затемподключиться один раз,Затем отключиться.

3.1.2.5 will-флаг

позиция:connect flags 2 бит.

willфлаг (Will Flag) установленявляется 1, указывая, еслиЕсли запрос на подключениепринят, will（Will Message）сообщениеобязательнохранится в

Сервер и с этимсетевое соединение связаносвязано. После того как сетевоекогда соединение закрыто,На стороне сервераОбязательноопубликовать этоwillсообщение,если толькосервер не получит

DISCONNECT когда сообщение удаленоЭтоwillMessage [MQTT-3.1.2-8] 。

Сообщение will публикуетсяпри условиях, включая, ноне ограничиваясь:

 Сервер обнаружилa I/O ошибку или сбой сети。

 Клиент поддерживает соединениесоединение (Keep Alive）в течение периода времени не удалосьсвязаться.

 Клиент не отправил первымотправить DISCONNECT Сообщение напрямую закрыло сетевое соединение.

 Из-за ошибки протокола серверсервер закрыл сетевоесетевое соединение.

еслиФлаг will установлен в 1, соединениево флаге соединения Will QoS и Will Retain Полябудут использоваться серверомчтобы,в то же времяв полезной нагрузкедолжен

нужносодержит Will Topic и Will Message Поля [MQTT-3.1.2-9]。

После публикации илисервер получилотправленный клиентом DISCONNECT пакет,будетсообщение затемТребуетсяУдалено из сохраненного состояния сеанса.

разделить [MQTT-3.1.2-10]。

еслиФлаг will установлен в 0，подключениев флаге Will QoS и Will Retain ПоляОбязательныеУстановлены в 0, ив полезной нагрузкене может

содержит поля WWill Topic и WWill Message Fields [MQTT-3.1.2-11]。

еслифлаг Will установлен в 0, сетькогда сетевое соединение разорвано，не можетотправить Will-сообщение [MQTT-3.1.2-12]。

сервер долженбыстроотправлятьтканьWillСообщение。Взакрытьмашинаилинеисправностьизчувствопри обстоятельствах，сервер можетотложитьбудетустранитьинформацияизлучатьтканьпрямокпослеоттяжёлогозапуска.

Если такого родаслучай, на сервереотказ сервера и будетпосле публикации сообщенияможет быть задержка между。

3.1.2.6 будет QoS

позиция:Флаги подключения 4 и 3 бит.

Эти два бита используются для указанияпубликацииWillСлужба, используемая при отправке сообщенияуровень качества.

еслиФлаг Will установлен в 0，Will QoS такжеТребуетсяУстановлено в 0(0x00) [MQTT-3.1.2-13]。

еслиФлаг Will установлен в 1，Will QoS значениеможет равняться 0(0x00)，1(0x01)，2(0x02). Этозначениене можетравняться 3

[MQTT-3.1.2-14]。

3.1.2.7 Will Retain

позиция:connect flags 5 бит.

MQTT-3.1.1-CN 24

еслиКогда сообщение Will публикуется, его нужно сохранитьretain, необходимо указатьзначение этого бита.

еслиФлаг Will установлен в 0, оставитьWill Retain (Will Retain）флаг такжеТребуетсяУстановлено в 0 [MQTT-3.1.2-15]。

еслиФлаг Will установлен в 1：

 еслиФлаг Will Retain установлен в 0, серверТребуетсяОбрабатывать сообщение Will как не-сохраненное сообщение при публикации [MQTT-3.1.2-16]。

 еслиФлаг will retain установлен в 1, серверТребуетсяобрабатывать сообщение will какОпубликовано как сохраненное сообщение [MQTT-3.1.2-17]。

3.1.2.8 Имя пользователяФлаги

позиция:connect flags 7 бит.

если флаг имени пользователя (User Name) установлен в 0, в полезной нагрузкене можетсодержатьполе имени пользователя [MQTT-3.1.2-18]。

если флаг имени пользователя (User Name) установлен в 1, в полезной нагрузкеТребуетсясодержитполе имени пользователя [MQTT-3.1.2-19]。

3.1.2.9 флаг пароляwill

позиция:connect flags 6 бит.

если флаг пароля (Password)установлен в 0, в полезной нагрузкене можетсодержит поле пароля [MQTT-3.1.2-20]。

если флаг пароля (Password)установлен в 1, в полезной нагрузкеТребуетсясодержит поле пароля [MQTT-3.1.2-21]。

Если флаг имени пользователяустановлен в 0, флаг пароля такжеТребуетсяУстановить в 0 [MQTT-3.1.2-22]。

3.1.2.10 keep alive

легенда 3.5 keep aliveбайт

Bit

байт 9

поддержание соединения Keep Alive MSB

байт 10

поддержание соединения Keep Alive LSB

Keep Alive (Keep Alive) — этозначение в секундахинтервал времени, выраженный какa 16 Слово битов, которое относится кклиент завершает передачуЧэн

от момента одного управляющего сообщения до момента отправки следующего сообщения, обамеждуразрешатьдопускатьПустопростойсамыйбольшойкогдаинтервалотдельный。клиент отвечаетзащищатьдоказыватьконтролировать

сообщениеиспускатьотправлятьизкогдаинтервалотдельныйНетпревышатьпроходитьЗначение keepalive.еслинеДалюбойегоэтоконтролясистемаотчёттекст можетсиспускатьотправлять,клиентОбязательноотправитьa

PINGREQ сообщение [MQTT-3.1.2-23]。

независимоКаково значение keep alive, клиентклиент в любое времяможно отправлять все PINGREQ пакет, и использовать PINGRESP сообщение для определения сети

Сетевая активность и активность на стороне сервераактивное состояние.

если keepaliveзначениененоль, ииодеждасерверВоднацелая пять десятыхразаиззащищатьподдерживать соединениеЦзекогдамеждувнутринетполучатькклиентконецизуправленияотчеттекст，этоОбязательноbreak

Откройте сеть клиентаподключение, учтите, что сетьсетевое подключение было отключено [MQTT-3.1.2-24]。

клиент отправил PINGREQ сообщениеПосле этого, если в течение разумного периода временивсё ещё не получил PINGRESP пакет, ондолжензакрыть соединение с сервером

Сетевое соединение конечной точки.

MQTT-3.1.1-CN 25

Значение keep-alive равноноль означаетпоказатьзакрыть хранитьудерживатьподключатьЦзезаслугаспособность。это означает, сервисконецНетНужнохотетьпотому чтогостьдомохозяйствоконечная точка неактивнаиbreakopenconnectconnect.Примечание：

Независимо от значения keep-alive, в любой момент, покаодеждаделоконечная точка распознаетявляетсяКлиент неактивен или не отвечает, и его можно отключить.клиентконечной точкиподключение

подключение.

ненормативныйкомментарий

Фактическое значение keep-aliveзначение задается приложениемзадается, обычнонесколько минут. Разрешитьмаксимальное значение — 18 часы 12 Разделить 15 секунды.

3.1.2.11 ненормативный переменный заголовокобластьПример

легенда 3.6 -переменный заголовокненормативныйПример

Описание

имя протокола

байт 1

Длина MSB (0)

байт 2

Длина LSB (4)

байт 3

‘M’

байт 4

‘Q’

байт 5

‘T’

байт 6

‘T’

уровень протокола

Описание

байт 7

Уровень (4) Уровень

флаг подключения Флаги подключения

байт 8

Флаг имени пользователя (1) флаг именипользователя

Флаг пароля (1) флаг плотного кода

Will Сохранение (0) Will флаг сохранения

Will QoS (01) Will Качество обслуживания

Will Флаг (1) Will Флаги

Clean Session (1) очисткаСессия

Зарезервировано (0) зарезервированный бит

время keepalive

байт 9

поддержание активности MSB (0)

байт 10

поддержание активности LSB (10)

MQTT-3.1.1-CN 26

3.1.3 payload

CONNECT сообщаетполезную нагрузку сообщенияpayload (payload) содержит одну илинесколько length-encodedполе с префиксом, флаги в переменном заголовкеопределяютли

Содержит эти поля.если включено，ОбязательноПоявляются в этом порядке: идентификатор клиентаидентификатор, тема willтема,willСообщение, имя пользователя, пароль

код [MQTT-3.1.3-1]。

3.1.3.1 клиентИдентификаторы

одеждаделоконецсделатьиспользоватьгостьдомашнее хозяйствоконецметказнатьсимвол (ClientId) знатьдругойгостьдомашнее хозяйствоконец。подключитьJieодеждаделоконецизкаждыйэлементыгостьдомашнее хозяйствоконецвсеДатолькоодинизгостьдомашнее хозяйствоконецметказнатьсимвол

（ClientId）。клиент и серверконечные точки должны использовать ClientId знатьразличать эти двамежду MQTT состояние, связанное с сеансомусловие [MQTT-3.1.3-

2]。

идентификатор клиента (ClientId) ТребуетсяСуществуеткроме тогоТребуетсяДа CONNECT сообщениеПервое в полезной нагрузкеполе [MQTT-3.1.3-3]。

идентификатор клиентаТребуетсяДа 1.5.3 определено в разделе UTF-8 закодированная строка [MQTT-3.1.3-4]。

На стороне сервераОбязательноРазрешено 1 до 23 байт длиной UTF-8 закодированный клиентИдентификатор клиента, клиентидентификатор клиента может содержать толькоэти символы:

“0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ”(прописные буквы,Строчные буквы

и цифры)[MQTT-3.1.3-5]。

На стороне сервераДапозволяет закодированному ... превышатьпроходить 23 символовклиента разделаИдентификаторы (ClientId). СерверДаразрешает пакетысодержащие те, которые не перечислены вышепредставляют символ

Идентификатор клиента (ClientId)。

На стороне сервераДапозволяет клиенту предоставитьпредоставить нулевой символИдентификатор клиента раздела (ClientId) , еслиСделав это,На стороне сервераОбязательноРассматривать это как особый

Особые случаи и назначить уникальныйуникальный идентификатор клиентаидентификатор этому клиентуклиенту. Затем онОбязательноПредположимклиент предоставилтот уникальный клиентскийидентификатор

символ,обычная обработкаЭто CONNECT сообщение [MQTT-3.1.3-6]。

Если клиент предоставляетнулевой байтидентификатора клиентасимвол, этоТребуетсятакже очиститфлаг сеанса установленустановлен в 1 [MQTT-3.1.3-7]。

Если клиент предоставляетиз ClientId равен нулю байти флаг Clean Sessionпомечен как 0, службаконецТребуетсяотправляет код возврата 0x02(Указывая, что идентификатор не

действителен) из CONNACK ответный пакетотвечает клиентуиз CONNECT сообщение，затемзакрыть сетевое соединение [MQTT-3.1.3-8]。

Если сервер отклоняетэтого ClientId，онТребуетсяотправитькод возврата равен 0x02(таблицауказывает, что идентификатор недействителенформат) из CONNACK ответный пакет

клиента CONNECT пакет,затем закрывает сетевоесоединение [MQTT-3.1.3-9]。

ненормативныйкомментарий

Реализация клиента можетпредоставлять удобныйметод, используемый для генерации случайногоиз ClientId. Когда Clean Sessionфлаг установлен в 0 следуетчто

Проактивно откажитесь от использования этогометода.

3.1.3.2 тема Will

еслиФлаг Will установлен в 1, естьследующее поле полезной нагрузкиполе — Willтема (Will Тема). WillтемаТребуетсяДа 1.5.3 раздел определяет

семантическая UTF-8 кодировкаString [MQTT-3.1.3-10]。

MQTT-3.1.1-CN 27

3.1.3.3 сообщение Will

еслиФлаг Will установлен в 1, естьследующее поле полезной нагрузкиполе — Willсообщение. Сообщение Willсообщение определяет, что будетопубликовано в теме Willответ темы

Используйте сообщение, см. 3.1.2.5 описание раздела. Это поле состоит издвухбайтовогодлина и сообщение Willполезная нагрузка сообщениясостоит из, представлено в виденулевые байты или

Последовательности из нескольких байтов.длина задает следующееданные, которые следуютколичество байтов, несодержитдлинаДва байта, занимаемые самим полембайтов.

завещаниеКогда сообщение публикуется в топик завещания, его полезная нагрузкаполезная нагрузка содержит только этоданные поляЧасть, не включает начальныйдва поля длины заголовкабайт.

3.1.3.4 Имя пользователя

если флаг имени пользователя (User Name) установлен в 1, следующая часть полезной нагрузкиполя — это в точности оно.Имя пользователяОбязательноДа 1.5.3 разделопределён

UTF-8 кодировкаString [MQTT-3.1.3-11]. службасервер можетон используется для идентификацииаутентификации и авторизации.

3.1.3.5 Password

если флаг пароля (Password)установлен в 1, следующее поле полезной нагрузки —его пароль.поле code содержит двухбайтовуюдлину секции

Поля，длинаУказывает количество байтов двоичных данных(не включая само поле длиныдва байта, занимаемые им самимбайт), затемследует 0 до 65535 байта

Двоичные данные.

легенда 3.7 - байты пароля

Bit

байт 1

длина данных MSB

байт 2

длина данных LSB

байт 3 ….

если длина превышает 0, то здесь часть данных

3.1.4 response

Примечание: сервер можеттак что в том же TCP порту или егоподдержку на других сетевых конечных точкахподдерживает несколько протоколов (включая этураннюю версию протоколаэто).если сервер

Сервер определяет, что протокол — это MQTT 3.1.1, затемон следует следующемуметоду проверки соединениязапроса.

1. После установления сетевого соединения, если серверв течение разумного временине получил в течение CONNECT отчётныйпакет, сервердолженЗакрытьэто соединение

подключение.

2. На стороне сервераТребуетсяв соответствии с 3.1 проверкой требований раздела CONNECT пакет,еслипакет не соответствуетспецификации, серверне отправляет

CONNACK сообщениезакрыть напрямуюсетевое соединение [MQTT-3.1.4-1]。

3. На стороне сервераДаПроверяет CONNECT пакетасоответствует ли содержимоеудовлетворять любому дополнительномуограничению,Давыполнять идентификацию,аутентификацию и авторизацию

Проверки. Если какая-либо проверка не проходит,однако, согласно 3.2 описанию раздела, онадолжнаотправить соответствующийсоответствующий,ненулевой код возврата

CONNACK ответ, иТребуетсязакрыть это сетевое соединение.

Если проверка успешна,сервер выполнитследующие шаги.

1. если ClientId указываетКлиент подключился к этому серверуСервер, тогда серверТребуетсяотключить существующего клиентаклиентское соединение [MQTT-

3.1.4-2]。

2. На стороне сервераТребуетсясогласно 3.1.2.4 разделуизОписанияВыполнитьПроцесс очистки сессии [MQTT-3.1.4-3]。

3. На стороне сервераТребуетсяотправляет код возвратанулевого CONNACK пакет как CONNECT пакетаответ подтверждения [MQTT-3.1.4-4]。

4. Начать распространение сообщений иподдерживать состояние соединенияотслеживать.

MQTT-3.1.1-CN 28

Разрешеноклиент отправляет CONNECT сообщениесразу отправляет после этогоДругие управляющие пакеты;клиенту ненужно дожидаться серверного CONNACK

пакет.еслисервер отклонил CONNECT, онне можетобрабатывать клиентаВ CONNECT после пакета отправлятьлюбые отправленные данные [MQTT-

3.1.4-5]。

ненормативныйкомментарий

Клиент обычно ждётждать CONNACK пакет. Однако,клиент имеет правополучить CONNACK передотправкой управляющих пакетов，

Поскольку нет необходимости поддерживатьсостояние соединения, этоможет упростить реализацию клиентскогоприложения.

3.2 CONNACK – подтверждение запроса на подключениеНайти

сервер отправляет CONNACK сообщениев ответ наполученный от клиента CONNECT отчётпакет. Серверотправил клиентупервое сообщение издолжен

нужноДа CONNACK [MQTT-3.2.0-1]。

Если клиент втечение разумного времени неполучил от серверапакет CONNACK ,клиентдолжензакрыть сетевоесоединение.

разумный

затраченное время

Зависит от типа приложенияи коммуникационной инфраструктурыреализации.

3.2.1 фиксированный заголовок

Формат фиксированного заголовкасм. легенду 3.8 – CONNACK отчёттекст фиксированныйфиксированный заголовок описание。

легенда 3.8 – CONNACK фиксированного заголовка пакета

Bit

байт 1

MQTT тип управляющего пакета (2)

Зарезервировано зарезервированный бит

байт 2

оставшаяся длина (2)

оставшаяся длинаполе длины

Представляетдлину переменного заголовка. Для CONNACK сообщенияэто значение равно 2。

3.2.2 переменный заголовок

Формат переменного заголовкасм. легенду 3.9 –CONNACK Сообщение можетпеременного заголовка изописания.

легенда 3.9 –CONNACK переменного заголовка пакета

Описание

флаги подтверждения соединения

Зарезервировано зарезервированный бит

байт 1

код возврата соединения

байт 2

MQTT-3.1.1-CN 29

3.2.2.1 Подтверждение соединенияФлаг подтверждения

№ 1 байтов

флаги подтверждения соединения

, бит 7-1 предназначен для обеспеченияЗарезервированный бит иТребуетсяУстановлено в 0。

№ 0 (SP)битов текущаяСессия（Session Present）Флаги。

3.2.2.2 текущая сессияречь

позиция:Бит флага подтверждения соединения 0 бит.

Если сервер получаетClean Session (CleanSession）Флагиравно 1 изсоединения, кромебудет CONNACK Код возврата в пакетеУстановлено в 0

кроме того, такжеТребуетсябудет CONNACK в пакетенастройка текущей сессии（Session Present）Флагиравно 0 [MQTT-3.2.2-1]。

Если сервер получаетa CleanSession является 0 изсоединения,флаг текущей сессиизначение зависит от того, является ли серверсохранил ли он уже ClientId

Соответствующая сессия клиентасостояние сессии. Еслисервер уже сохранилсохранённое состояние сессии, тоОбязательнобудет CONNACK Флаг текущей сессии в пакетеустановлен

установлен в 1 [MQTT-3.2.2-2]。Если сервернет сохранённогосостояние сессии, тоОбязательнобудет CONNACK сообщатьв сообщениинастройка текущей сессии

равно 0. Также необходимо CONNACK указыватькод возврата в тексте установлен в 0 [MQTT-3.2.2-3]。

Флаг текущей сессии используетсясервером и клиентомчтобы определить, есть ли ужесохранённое состояние сессииоставаться согласованными.

как толькоЗавершена настройка инициализации сессии, уже сохранённая сессияклиент с состоянием сессии будет ожидатьожидает, что сервер будет поддерживатьон хранитсостояние сессии.если клиент

Клиент получает от сервераполучилтекущееЗначение отличается от ожидаемого, клиент можетВыбрать продолжить этосессию или отключиться.клиентможет отбросить

Отказаться от клиента и серверасессию между конечными точкамисостояние, методявляется,отключиться, затемфлаг Clean Sessionфлаг установлен в 1, переподключиться,затемснова

Отключиться.

Если сервер отправляетсодержал не-с нулевым кодом возврата CONNACK пакет, онТребуетсябудет служить в качествефлаг предыдущей сессииУстановлен в 0 [MQTT-

3.2.2-4]。

3.2.2.3 возврат соединениякод ответа

позиция:переменного заголовка 2 байт。

поле Connect Return Codeиспользуя однобайтовоебеззнаковое значение,В Таблице 3.1 – возврат соединениязначение кода возврата перечислено в. Если сервер получаетдопустимый

метода CONNECT пакет, но, по-видимому,по некоторой причине не можетобработать его, серверсервер должен попытатьсяотправить один, содержащий ненулевой возвраткод возврата (в таблицеиз

одного конкретного) CONNACK пакет. Еслисервер отправилодин, содержащий ненулевой код возвратаот CONNACK пакет,тогда ондолжензакрыть

закрыть сетевое соединение [MQTT-3.2.2-5].。

Таблица 3.1 –Значение кода возврата подключения

Значение

код возвратаответ

Описание

0x00 соединение принятопринять

Соединение было принято серверомПринять

0x01 соединение отклоненоотклонено, неподдерживаемаяверсия протокола

Сервер не поддерживает клиентзапрошенный клиентом MQTT уровень протоколадругой

0x02 соединение отклоненоотклонено, недопустимый идентификатор клиента

Идентификатор клиента являетсяправильным UTF-8 кодировка,НоСлужбы

конечной точке не разрешено использовать

0x03 в соединении отказаноотказано, серверсервер недоступен

Сетевое соединение установлено, но MQTT служба недоступна

0x04 в соединении отказаноотказано, неверноеимя пользователя или пароль

имя пользователя или парольневерный формат данных

MQTT-3.1.1-CN 30

0x05 в соединении отказаноотказано, неавторизован

Клиент не авторизованподключиться к этой службеустройство

6-255

сохранять

Если вы считаете, что в приведённой выше таблицевсе соединения возвращаютни один из кодов возврата не подходит，тона стороне сервератребуетсяЗакройте сетевое соединение,не нужно отправлять CONNACK сообщение

текст [MQTT-3.2.2-6]。

3.2.3 payload

CONNACK сообщениенет допустимойполезной нагрузки.

3.3 PUBLISH – сообщение публикации

PUBLISH управляющийпакет относится к передаче от клиентаот клиента к серверуили от сервера к клиентупередача приложениясообщение.

3.3.1 фиксированный заголовок

легенда 3.10 – PUBLISH сообщениефиксированный заголовок пакетаописывает фиксированный заголовокформат заголовка

легенда 3.10 – PUBLISH фиксированный заголовок пакета

Bit

байт 1

MQTT управляющий пакеттип сообщения (3)

DUP

QoS уровень

RETAIN

байт 2

оставшаяся длина

3.3.1.1 флаг повторной передачибудет

позиция:№ 1 байт, 3 биты

если DUP флаг установлен в 0, указывая, что это клиент или серверпервый запрос серверазапрос на отправку этого PUBLISH пакета.если DUP флаги

установлен в 1, таблицауказывая, что это может бытьболее ранний запрос пакетаповторная передача запроса.

клиент или серверзапрос на повторную отправку PUBLISH когда сообщение,Требуетсябудет DUP меткафлаг установлен в 1 [MQTT-3.3.1.-1].. Для QoS

0 сообщение,DUP ФлагиТребуетсяУстановлено в 0 [MQTT-3.3.1-2]。

сервер отправляет PUBLISH сообщениеподписчикукогда,полученовходящего PUBLISH пакета DUP значение флагане будет распространяться.выдавать

отправленного (исходящего) PUBLISH сообщенияи полученноговходящего PUBLISH в пакете DUP флаг независимнезависимо установлен,его значениеТребуется

отдельно в соответствии с отправкойисходящего PUBLISH сообщенияявляется ли оно повторной передачейотправлено для определения [MQTT-3.3.1-3]。

ненормативныйкомментарий

получатель получает DUP флаг равен 1 упакета управления,не может предполагать, что он видитодин перед этим пакетомдубликат.

ненормативныйкомментарий

Что нужно особо отметить, так этоесть,DUP меткажурнал фокусируется на управляющемсамом пакете управления,с прикладным сообщением, которое он содержитне имеет значения. При использовании QoS 1

когда,Клиент может получить DUP флаг равен 0 у PUBLISH пакет,Этотпакет содержитодин, который он ранее получил

копия сообщения приложения, но используетсядругой идентификатор пакетаидентификатор. 2.3.1 раздел содержит некоторыеотносительно идентификатора пакетадополнительная информация.

MQTT-3.1.1-CN 31

3.3.1.2 качество обслуживанияуровень

позиция:№ 1 байт, 2-1 бит.

Это поле указывает сообщение приложениядля распространения сообщенийгарантия уровня качества обслуживания.качество обслуживанияуровень качества в таблице 3.2 -определение качества обслуживания приведено вout.

Таблица 3.2 -Качество обслуживанияопределение

QoS Значение

Бит 2

Бит 1

Описание

не более одного раза

не менее одного раза

доставить только один раз

зарезервированный бит

PUBLISH сообщениене можетwill QoS разместитьнекоторые биты установлены в 1。еслисервер или клиентклиентполучил QoS Все биты являются 1 из PUBLISH

пакет, онТребуетсязакрыть сетевое соединениеJie [MQTT-3.3.1-4]。

3.3.1.3 флаг retainwill

позиция:№ 1 байт, 0 бит.

Если клиент отправляетсервера PUBLISH пакетаretain (RETAIN）флаг установленявляется 1, серверТребуетсясохранить это сообщение приложения

информация иэтоизСлужбыкачествождатьуровень（QoS）, чтобыудобноэтоДаС помощьюраспространятьещё непришедшимизосновнойзаголовоксовпадениеназначенныйподписатьсячитатель [MQTT-3.3.1-5]。a

НоваяПодпискапостроитьнемедленно, длякаждогосовпадениеизтопикимя，еслихранитьВнедавнийзащититьоставшеесяустранитьсообщение,этоТребуетсяотправляетсяотправить вЭтоподписатьсячитатель [MQTT-

3.3.1-6]. Если Серверклиент получает сохранённое сообщение（RETAIN) флаг равен 1 из QoS 0 сообщение,этоТребуетсяотброситьранее для этого топикатопик сохранить

любого сообщения. Онодолжнобудетновое QoS 0 сообщение как этот топикновое сохранённое сообщение в топике, нов любое времяДарешает отбросить его

— еслиКогда это происходит, у этоготопика не будет сохранённыхсохранённое сообщение [MQTT-3.3.1-7]。связанное с состоянием хранилищаДля получения дополнительной информации см. 4.1 раздел.

На стороне сервераотправить PUBLISH сообщение вкогда клиент, например,если сообщение как клиентновоерезультат подписки отправляетсяотправить, этоТребуетсяRetain пакета

Флаг retain установлен в 1 [MQTT-3.3.1-8]. Когда PUBLISH отчеттекст отправленотправлено клиенту, потому что соответствуетназначить уже установленнуюкогда подписка, сервер

серверТребуетсяУстановить флаг retain в 0, независимо от тогополученное сообщениев сообщенииretainКаково значение флага [MQTT-3.3.1-9]。

retainфлаг равен 1 и допустимполезная нагрузка равна нулю байтиз PUBLISH отчетсообщение будетсервер обрабатывает его как обычное сообщениепри обработке оно будетотправлено в тему подписки

соответствующийклиентконец。в дополнение，тот жеaосновнойтопикНижнийлюбойприсутствуетхранитьизretainустранитьдыханиеТребуетсяС помощьюпереместитьразделить，Следовательно这элементытопикизпослеизлюбойподписатьсячитатьвсе

не получитксохраненному сообщению [MQTT-3.3.1-10]。

рассматривается как обычное

Это означаетсуществующееКлиент получаетсообщенияСреднийфлаг Retain неустановлен。

На стороне серверане можетхранить нулевого размераretained-сообщение [MQTT-3.3.1-11]。

Если клиент отправляет всервера PUBLISH пакетабит флага Retain 0，На стороне серверане можетхранить это сообщениетакжене можетудалить или заменить любое

существующие retained-сообщения [MQTT-3.3.1-12]。

ненормативныйкомментарий

не определено для издателяпериодически отправлять сообщения о состояниисообщение, в этом сценарии,retained-сообщения оченьполезны. Новые подпискиподписчик получит самое последнее состояниесостояние.

оставшаяся длинаполе длины

равноДлина переменного заголовка плюс полезная нагрузкадлина полезной нагрузки.

MQTT-3.1.1-CN 32

3.3.2 переменный заголовок

Переменный заголовок по порядкусодержитимятемы и идентификатор пакета.

3.3.2.1 имя темы

имя топика (Topic Name) используется дляидентификации полезной нагрузкигде должны публиковаться данныеинформационный канал。

имя топикаОбязательноДа PUBLISH отчётпеременный заголовокПервое поле заголовка.оноОбязательноДа 1.5.3 разделопределён UTF-8 -кодированная строка

[MQTT-3.3.2-1]。

PUBLISH -сообщенииимя темыне можетсодержать подстановочныйсимвол [MQTT-3.3.2-2]。

Сервер отправляет подписчикуподписывающегося клиента PUBLISH -сообщение сименем темыТребуетсясоответствиетемефильтра подписки (в соответствии с 4.7 сопоставлением, определённым в разделе

обработать）[MQTT-3.3.2-3]。

3.3.2.2 идентификатор пакетаидентификатор

только когда QoS ожиданияуровень равен 1 или 2 когда, идентификатор пакета（Packet Identifier) полеможет появляться только в PUBLISH в пакете.2.3.1

В разделе представлена информация о пакетеобновление идентификатора пакетадополнительная информация.

3.3.2.3 переменный заголовокненормативный заголовокПример

легенда 3.11 – PUBLISH отчётПеременный заголовок пакетаНенормативный пример иллюстрирует Таблица 3.3 - PUBLISH отчётненормативный пример кратко описывает

описан PUBLISH переменный заголовок пакетазаголовок.

Таблица 3.3 - PUBLISH Ненормативный пример сообщения

Поле

Значение

имя темы

a/b

идентификатор пакета

легенда 3.11 – PUBLISH переменный заголовок пакетаНенормативный пример

Описание

Имя топикаe имя топика

байт 1

Длина MSB (0)

байт 2

Длина LSB (3)

байт 3

‘a’ (0x61)

байт 4

‘/’ (0x2F)

байт 5

‘b’ (0x62)

идентификатор пакета

байт 6

идентификатор пакета MSB (0)

байт 7

идентификатор пакета LSB (10)

MQTT-3.1.1-CN 33

Имя топика в примереимеет “a/b”，длинуравную 3, идентификатор пакета равен “10”

3.3.3 payload

Полезная нагрузка будет содержатьопубликованноесообщение приложения. Данныесодержимое и формат определяютсяприложением.длина полезной нагрузкивычисляется следующим образом:с фиксированным

оставшаяся длина в заголовкезначение поля Length минусвычесть длину переменного заголовка.содержит нольдлина полезной нагрузкио PUBLISH сообщитьчто пакет действителен.

3.3.4 response

PUBLISH сообщениеполучательТребуетсясогласноСогласно PUBLISH в пакете QoS уровень QoS для отправки ответа, см. таблицу нижеописание формата [MQTT-

3.3.4-1]。

Таблица 3.4 – PUBLISH ожидаемый ответпакета

Уровень качества обслуживания

ожидаемый ответ

QoS 0

нет ответа

QoS 1

PUBACK сообщение

QoS 2

PUBREC сообщение

3.3.5 action

Клиент использует PUBLISH пакет отправляет прикладноесообщение на сервер, чтобы распространитьпо другим соответствующим подпискамсоответствующие клиенты.

Сервер использует PUBLISH пакет, отправляющий прикладноесообщение каждойподпискесоответствующейклиент.

Клиент использует полосовойфильтр тем с подстановочными знакамикогда фильтр запрашивает подписку, клиентподписка клиента можетбыть повторена，Следовательноопубликованные сообщения могут соответствовать нескольким

фильтру. ДляВ этом случае серверсерверобязандоставить сообщениевсем соответствующим подпискамназначенный QoS ждатьклиент с наивысшим уровнем [MQTT-3.3.5-

1]. Серверазатем в соответствии с подпискойна QoS уровень, распространение сообщениякопию каждомусоответствующему подписчику。

получает PUBLISH отчёткогда сообщение,действие получателязависит от 4.3 разделописанный QoS ожиданияуровень.

еслиреализация сервера не авторизует клиентаклиент публикует PUBLISH пакет,он не может уведомить об этомКлиент. Этотребуетсяв соответствии с обычнымобычным

QoS правило отправкиотправить положительноеподтверждение, илизакрыть сетевое соединение [MQTT-3.3.5-2]。

3.4 PUBACK –выдатьподтверждение публикации

PUBACK сообщениеявляется корректным QoS 1 уровняиз PUBLISH отчётответ на пакет。

3.4.1 фиксированный заголовок

легенда 3.12 - PUBACK отчётфиксированный текстопределённое сообщениеhead

Bit

байт 1

MQTT управляющий пакеттип сообщения (4)

зарезервированный бит

MQTT-3.1.1-CN 34

байт 2

оставшаяся длина(2)

оставшаяся длинаполе длины

указывающийдлину переменного заголовка. Для PUBACK сообщенияэто значение равно 2.

3.4.2 переменный заголовок

содержит те, что ожидают подтверждения PUBLISH пакет сообщенияPacket Identifier.

легенда 3.13 – PUBACK переменный заголовок пакета

Bit

байт 1

идентификатор пакета MSB

байт 2

идентификатор пакета LSB

3.4.3 payload

PUBACK сообщениебез полезной нагрузки。

3.4.4 action

см. полное описание в 4.3.2 разделе.

3.5 PUBREC – публикацияполучена (QoS 2, Шаг 1)

PUBREC отчётсообщение корректно QoS уровень 2 из PUBLISH отчётответ на сообщение. Это QoS 2 обмен по протоколу QoSвторое сообщение обменаtext.

3.5.1 фиксированный заголовок

легенда 3.14 – PUBREC фиксированныйзаголовок сообщения

Bit

байт 1

MQTT управляющий пакеттип сообщения e (5)

зарезервированный бит

байт 2

оставшаяся длина (2)

оставшаяся длинаполе длины

указывающийдлину переменного заголовка. Для PUBREC отчетногосообщениязначение равно 2。

3.5.2 переменный заголовок

переменный заголовок содержит и т. д.ожидающее подтверждение PUBLISH отчётидентификатор пакетаидентификатор.

MQTT-3.1.1-CN 35

легенда 3.15 – PUBREC переменныйзаголовок сообщения

Bit

байт 1

идентификатор пакета MSB

байт 2

идентификатор пакета LSB

3.5.3 payload

PUBREC сообщаетсообщение не имеет полезной нагрузки。

3.5.4 action

см. полное описание в 4.3.3 разделе.

3.6 PUBREL – публикацияосвобождение (QoS 2, Шаг 2)

PUBREL сообщениекорректно PUBREC ответ на сообщение.Это QoS 2 ожиданиеобмена на уровне протоколатретьего сообщения.

3.6.1 фиксированный заголовок

легенда 3.16 – PUBREL фиксированный заголовок пакета

Bit

байт 1

MQTT управляющий пакеттип сообщения (6)

зарезервированный бит

байт 2

оставшаяся длина (2)

PUBREL управляющийфиксированный заголовок пакетапервый бит заголовка 3,2,1,0 — это бит Retain，Обязательноустановлено в 0,0,1,0. СлужбаконецОбязательнолюбое другое значение

все считаются недопустимымии закрывают сетевоесоединение [MQTT-3.6.1-1]。

оставшаяся длинаполе длины

указывая длину переменного заголовка. Для PUBREL отчётзначение Packet равнов 2.

3.6.2 переменный заголовок

переменный заголовок содержит иожидание подтверждения PUBREC сообщениетот же идентификатор сообщенияидентификатор.

легенда 3.17 – PUBREL переменный заголовок пакета

Bit

байт 1

идентификатор пакета MSB

байт 2

идентификатор пакета LSB

MQTT-3.1.1-CN 36

3.6.3 payload

PUBREL сообщениене имеет Payloadполезной нагрузки.

3.6.4 action

см. полное описание в 4.3.3 разделе.

3.7 PUBCOMP – Публикация завершена (QoS 2, шаг 3)

PUBCOMP сообщаетсообщение корректно PUBREL сообщаетответ на пакет. Это QoS 2 уровеньпротокольного обменачетвёртый и последнийпакет.

3.7.1 фиксированный заголовок

легенда 3.18 – PUBCOMP сообщение фиксированноефиксированный заголовок

Bit

байт 1

MQTT управляющий пакеттип сообщения (7)

зарезервированный бит

байт 2

оставшаяся длина (2)

оставшаяся длинаполе длины

указывая длину переменного заголовка. Для PUBCOMP сообщаетэтот текстзначение равно 2。

3.7.2 переменный заголовок

переменный заголовок содержит иожидание подтверждения PUBREL сообщениетот же пакетидентификатор.

легенда 3.19 – PUBCOMP Сообщение можетпеременный заголовок

Bit

байт 1

идентификатор пакета MSB

байт 2

идентификатор пакета LSB

3.7.3 payload

PUBCOMP сообщаетсообщение не имеетполезной нагрузки.

3.7.4 action

см. полное описание в 4.3.3 разделе.

MQTT-3.1.1-CN 37

3.8 SUBSCRIBE - тема подписки

от клиента к серверуотправляет SUBSCRIBE сообщение, используемое длясоздания одной или несколькихподписок. Каждаяподписка регистрирует клиентатему, которая интересует клиентаили несколько

тему. Чтобыпереслать сообщениесоответствующим этим подпискамсоответствующей теме, серверсервер отправляет PUBLISH отчётныйпакет клиенту。SUBSCRIBE

сообщение также (для каждойподписки) указываетмаксимальный QoS уровеньожидания, Серверотправить на основе этогодоставить прикладное сообщение клиенту.

3.8.1 фиксированный заголовок

легенда 3.20 – ПОДПИСАТЬСЯ сообщение исправленофиксированный заголовок

Bit

байт 1

MQTT управляющий пакеттип сообщения (8)

зарезервированный бит

байт 2

оставшаяся длина

SUBSCRIBE управлениефиксированный заголовок управляющего пакетаиз 3,2,1,0 битовсохраняетсяbit,Требуетсясоответственно установлено в 0,0,1,0. СерверТребуетсялюбое другое

любое значение рассматривается как недопустимое и закрытьсетевое соединение [MQTT-3.8.1-1]。

оставшаяся длинаполе длины

равнодлине переменного заголовка (2 байт) плюсдлине полезной нагрузки.

3.8.2 переменный заголовок

заголовок переменной содержит клиентскийидентификатор клиента.2.3.1 Предоставьтео пакетеДополнительные сведения об идентификаторах.。

3.8.2.1 переменный заголовокненормативный заголовокПример

легенда 3.21 – идентификатор пакетаравен 10 из заголовка переменной, пример, не имеющий нормативного характераПример показывает сообщениеидентификатор сообщения установлен в 10 заголовке переменной, когда

заголовок.

легенда 3.21 – сообщениеидентификаторидентификатор равен 10 может бытьпеременное сообщениезаголовок, ненормативный примерПример

Описание

идентификатор пакета

байт 1

идентификатор пакета MSB (0)

байт 2

идентификатор пакета LSB (10)

3.8.3 payload

SUBSCRIBE пакетаполезная нагрузкасодержит темусписок фильтров тем,они представляют Клиентатемы, на которые клиент хочет подписаться。SUBSCRIBE

сообщениеФильтр темы в полезной нагрузкеСписокОбязательныйДа 1.5.3 разделопределено UTF-8 String [MQTT-3.8.3-1]. службасерверследуетПоддерживается

содержит подстановочный знак (4.7.1 раздел указываетзначение) изфильтра тем. Еслиесли сервер решит не поддерживатьсодержащий подстановочные знакифильтр топика,ОбязательноОтклонить

любой, содержащий подстановочные знакиподписка фильтразапрос [MQTT-3.8.3-2]。После каждого фильтраза которым следует байт, этот байтназывается clothes

требование к качеству обслуживания (Requested QoS）. Оно даёт серверуОт сервера к клиентуклиент отправляет сообщение приложенияразрешённый сообщениеммаксимальный QoS уровень.

MQTT-3.1.1-CN 38

SUBSCRIBE пакетаполезная нагрузкаТребуетсясодержиткак минимумпараФильтр тем и QoS уровенькомбинация полей.нет полезной нагрузкииз

SUBSCRIBE отчётсообщение является нарушением протоколаиз [MQTT-3.8.3-3]。об обработке ошибоксм. информацию об обработке 4.8 раздел.

максимальный запрошенный сервисполе уровня качества обслуживаниязакодированное как словобайт, после негоследует UTF-8 редактироватьимя темы кода,эти фильтры тем /и

QoS комбинация уровнейупакованы последовательно.

легенда 3.22 – SUBSCRIBE сообщениеполезная нагрузкаформатирование

Описание

Фильтр тем

байт 1

длина MSB

байт 2

длина LSB

байты 3..N

Фильтр тем（Фильтр тем）

требования к качеству обслуживания (Запрошенный QoS）

зарезервированный бит

Уровень качества обслуживания

байт N+1

текущая версия протоколане использовала службутребование QoS (Запрошенный QoS）старшие шесть битов байта. Если полезная нагрузкалюбой в полезной нагрузкебит не-

нулевое значение,или QoS Не равно 0,1 или 2, серверТребуетсясчитать SUBSCRIBE пакет являетсянедопустимым объединениемзакрыть сетевое соединение [MQTT-

3-8.3-4]。

3.8.3.1 полезная нагрузкаполезная нагрузка (не нормативная)Пример

легенда 3.23 – слово полезной нагрузкинестандартный формат байтовпример отображениеуже Таблица 3.5 – Даненормативная полезная нагрузкаПример кратко описан в

SUBSCRIBE сообщаетполезную нагрузку пакета。

Таблица 3.5 – полезная нагрузкаполезная нагрузка не являетсянормативным примером

имя темы

“a/b”

Требования к качеству обслуживания

0x01

имя темы

“c/d”

Требования к качеству обслуживания

0x02

легенда 3.23 – допустимаяполезная нагрузкаформат байтов не-спецификация показываетПример

Описание

Фильтр тем (TФильтр тем）

байт 1

Длина MSB (0)

байт 2

Длина LSB (3)

байт 3

‘a’ (0x61)

MQTT-3.1.1-CN 39

байт 4

‘/’ (0x2F)

байт 5

‘b’ (0x62)

требования к качеству обслуживания (Запрошенный QoS）

байт 6

Запрошенный QoS(1)

Фильтр тем (TФильтр тем）

байт 7

Длина MSB (0)

байт 8

Длина LSB (3)

байт 9

‘c’ (0x63)

байт 10

‘/’ (0x2F)

байт 11

‘d’ (0x64)

требования к качеству обслуживания (Запрошенный QoS）

байт 12

Запрошенный QoS(2)

3.8.4 response

сервер получает клиентскийэкземпляр, отправленный конечной точкой SUBSCRIBE когда сообщение,ОбязательноИспользование SUBACK ответный пакет [MQTT-3.8.4-1]。

SUBACK сообщениеТребуетсяи ожидание подтверждения SUBSCRIBE сообщениеимеют одинаковый идентификатор пакетасимвол [MQTT-3.8.4-2]。

позволяет серверу отправлятьотправлять SUBACK отчетдо сообщениязатем начать отправку и подпискусоответствующий PUBLISH пакет.

Если сервер получаетa SUBSCRIBE пакет, пакетФильтр тем существующей подпискисоответствующий фильтру темтот же,тогдаТребуется

использовать новую подписку, чтобы полностьюзаменяет существующуюподписку. Темы новой подпискифильтр и предыдущаятакие же, как у подписки,но ономаксимальное QoS значениене может

то же самое.Это соответствует этому фильтру темлюбое существующее сохраненноесохраненное сообщениеТребуетсяпередается повторно,но поток публикациине можетСреднийнарушить [MQTT-3.8.4-3]。

если фильтр темотличается от любых существующихсохраненных фильтров подписки, серверсервер создастновую подписку и отправит всесоответствующее сохранённоесообщение.

Если сервер получаетсодержащий несколько темфильтра SUBSCRIBE пакет,онТребуетсякак если бы он получил рядиз нескольких SUBSCRIBE

обрабатывать сообщение так же, затемодно,кроменужно объединить их ответыобъединённые в однонезависимое SUBACK сообщениеотправить [MQTT-3.8.4-4]。

сервер отправляет клиентуклиента SUBACK отчёттекстовая паракаждая пара фильтров тем и QoS ожидатьвсе уровниТребуетсясодержит код возврата.Этотвозврат

кодТребуетсяуказывает, что подписка предоставленамаксимальный предоставленный QoS уровень,илиуказывает, что эта подписка не удалась [MQTT-3.8.4-5]. Сервер можетпредоставить, чем

ниже требования подписчиканекоторые из QoS уровня.отправлено в ответ на подпискуотправленного сообщенияполезной нагрузки QoS Требуетсяпринадлежит исходному опубликованному сообщению

QoS и служба, предоставленные конечной точкой QoS из двухминимальное значение. Если исходное сообщениеинформация QoS Да 1 и максимальный предоставленный QoS Да 0, разрешитьразрешить серверу

Сервер повторно отправляеткопию сообщенияподписчику [MQTT-3.8.4-6]。

необязательныйПример

для конкретного топикафильтр топика,еслив настоящее время подписанклиенту предоставленмаксимальный QoS ожиданияуровень равен 1, тогдасоответствующий этому фильтру

фильтра QoS уровень 0 прикладное сообщение будет в соответствии с QoS уровень 0 доставлен этому клиенту.это означает, что клиентклиент получит не более этого

MQTT-3.1.1-CN 40

копия сообщения. С другой стороны,то есть публикация в тот жетопика QoS уровень 2 сообщениябудет понижен сервером до QoS ожидания

уровень 1 перераспределитьклиенту, следовательно, клиентклиент может получатьдублирующиеся сообщениякопия.

Если текущая подпискаклиенту предоставленмаксимальный QoS уровень 0, тогдапервоначально с QoS уровнем 2 опубликовано вклиентское приложение

сообщение может, когда занято,может быть потеряно,Носервер не должендолжен отправлять дубликаткопию сообщения. Публикация в тот жетопика QoS уровень

1 сообщение в путипри доставке клиенту можетможет быть потеряно или продублировано.

ненормативныйкомментарий

Использование QoS уровня 2 подпискиПодписка на фильтр топика, равныйто есть:

Я хочу публиковать в соответствии с нимивремени

QoS

уровень принимает соответствующие этомуэлементы

сообщение фильтра

. Это означает,определитьвозможное во время доставки сообщениямаксимальное QoS ожиданиеуровень — это ответственность издателя, иподписчик может

требует, чтобы сервер снизил QoS до более подходящегосоответствующего его уровню.

3.9 SUBACK – подтверждение подписки

сервер отправляет SUBACK пакет клиенту, используемый для подтверждения того, что онбыл получен иобрабатывается SUBSCRIBE пакет.

SUBACK сообщениесодержит списоккодов возврата, ониуказали SUBSCRIBE пожалуйстазапросакаждая подписка являетсямаксимально предоставленным QoS ожидатьуровень.

3.9.1 фиксированный заголовок

легенда 3.24 – SUBACK фиксированный заголовок пакета

Bit

байт 1

MQTT управляющий пакеттип сообщения (9)

зарезервированный бит

байт 2

оставшаяся длина

оставшаяся длинаполе длины

равна длине переменного заголовкаплюс полезная нагрузкадлина полезной нагрузки.

3.9.2 переменный заголовок

переменный заголовок содержит и т. д.ожидающее подтверждение SUBSCRIBE отчёттекстаидентификатор пакета.легенда 3.25 – SUBACK отчётпеременный заголовок пакета описывает возможные

формат переменного заголовка.

легенда 3.25 – SUBACK переменный заголовок пакета

Bit

байт 1

идентификатор пакета MSB

байт 2

идентификатор пакета LSB

MQTT-3.1.1-CN 41

3.9.3 payload

полезная нагрузка содержитсписок кодов возврата. Каждый код возвратасоответствует ожидающему подтверждениюот SUBSCRIBE одному из пакетовфильтр тем. Возврат

порядок кодовОбязательнои SUBSCRIBE сообщениев порядке фильтров темто же [MQTT-3.9.3-1]。

легенда 3.26 – SUBACK отчётполезная нагрузка пакетаформатирование описываетв полезной нагрузке однимбайтомзакодировано поле кодавозврата.

легенда 3.26 – SUBACK формат полезной нагрузки пакета

Bit

код возврата

байт 1

Допустимые значения кода возврата：

0x00 - максимальный QoS 0

0x01 - успех – максимальный QoS 1

0x02 - успех – максимальный QoS 2

0x80 - Ошибка ошибка

0x00, 0x01, 0x02, 0x80 внеиз SUBACK возвраткод возврата зарезервированиз,нельзяИспользование [MQTT-3.9.3-2]。

3.9.3.1 полезная нагрузкаполезная нагрузка (не нормативная)Пример

легенда 3.27 -полезная нагрузканенормативный пример байтового формата показан в Таблице 3.6 -Даненормативный пример полезной нагрузки кратко описан

SUBACK сообщениеполезной нагрузки.

Таблица 3.6 -полезная нагрузканенормативныйПример

Успех - Максимальный QoS 0

Успех - Максимальный QoS 2

Failure

128

легенда 3.27 -полезная нагрузкабайтовый форматНенормативный пример

Описание

байт 1

Успех - Максимальный QoS 0

байт 2

Успех - Максимальный QoS 2

байт 3

Failure

3.10 UNSUBSCRIBE –Отмена подписки

клиент отправляет UNSUBSCRIBE сообщениена сервер,используется для отписки оттемы подписки.

MQTT-3.1.1-CN 42

3.10.1 фиксированный заголовок

легенда 3.28 – UNSUBSCRIBE фиксированный заголовок пакета.

Bit

байт 1

MQTT тип управляющего пакета (10)

зарезервированный бит

байт 2

оставшаяся длина

UNSUBSCRIBE пакетфиксированный текстфиксированного заголовка 3,2,1,0 бит должен быть сохранен.Зарезервированный бит иRequiredустанавливаются отдельно,это 0,0,1,0。на стороне сервераRequired.считает любыеего.

все его значения недействительныдопустимо и закрыть сетьсетевое соединение [MQTT-3.10.1-1]。

оставшаяся длинаполе длины

равна длине переменного заголовкаплюс полезная нагрузкадлина полезной нагрузки.

3.10.2 переменный заголовок

Переменный заголовок содержитидентификатор пакета。2.3.1 . Этот разделпредоставляет информацию оподробнее об идентификаторах пакетовинформация.

легенда 3.29 – UNSUBSCRIBE переменный заголовок пакета

Bit

байт 1

идентификатор пакета MSB

байт 2

идентификатор пакета LSB

3.10.3 payload

UNSUBSCRIBE пакетадопустимаяполезная нагрузка содержит клиентскиетемы, от которых клиент хочет отписатьсясписок фильтров тем。UNSUBSCRIBE в пакете

ФильтртемОбязательныйупаковывается подряд,в соответствии с 1.5.3 указанным в разделесемантическая UTF-8 правкастроки кода [MQTT-3.10.3-1]。

UNSUBSCRIBE пакетадопустимаяполезная нагрузкаТребуетсякак минимумсодержитфильтр сообщений. Нет полезной нагрузкиполезной нагрузки UNSUBSCRIBE пакет является

нарушение протокола [MQTT-3.10.3-2]. ИмеетсяДополнительная информация об обработке ошибоксм. 4.8 раздел.

3.10.3.1 несоответствующая полезная нагрузкаобластьПример

легенда 3.30 -полезная нагрузкаНеофициальный байтовый форматПример показывает Таблица 3.7 -допустимыйНеофициальный пример полезной нагрузки кратко описан

UNSUBSCRIBE пакетадопустимаяполезная нагрузка.

Таблица 3.7 -полезная нагрузканеофициальный примерПример

Фильтр тем

“a/b”

Фильтр тем

“c/d”

MQTT-3.1.1-CN 43

легенда 3.30 -полезная нагрузкабайтовый форматнеофициальныйпример

Описание

Фильтр тем

байт 1

Длина MSB (0)

байт 2

Длина LSB (3)

байт 3

‘a’ (0x61)

байт 4

‘/’ (0x2F)

байт 5

‘b’ (0x62)

Фильтр тем

байт 6

Длина MSB (0)

байт 7

Длина LSB (3)

байт 8

‘c’ (0x63)

байт 9

‘/’ (0x2F)

байт 10

‘d’ (0x64)

3.10.4 response

UNSUBSCRIBE отчёттекст упоминаетпредоставленный фильтр тем (независимо от того, содержит ли онподстановочный знак）Требуетсяпри этом это хранится на серверетекущий клиентаосновной

набор фильтров тем по одномупосимвольное сравнение.если какой-либо фильтр полностьюточное совпадение,то он (серверсервер) свой собственныйПодписка будет удалена,В противном случае

не будет дальнейшейобработки [MQTT-3.10.4-1]。

Если сервер удаляетподписку:

 онТребуетсяпрекратить доставку любых новых сообщенийсообщения этому клиентуклиенту [MQTT-3.10.4-2]。

 онТребуетсязавершить доставку любых уженачинает отправлять клиентуотправленных конечной точкой QoS 1 и QoS 2 сообщения [MQTT-3.10.4-3]。

 онДапродолжать отправлять любые существующиеподготавливаемые к распространениюв буфер клиентахранить сообщение.

На стороне сервераТребуетсяотправить UNSUBACK ответный пакетклиента UNSUBSCRIBE запрос.UNSUBACK сообщениеТребуетсясодержит и

UNSUBSCRIBE отчёттекстовая фазатот же идентификатор пакета [MQTT-3.10.4-4]。даже еслине удалил ни однойподписки на тему,сервер такжеТребуетсяотправить

отправить SUBACK ответ [MQTT-3.10.4-5]。

Если сервер получаетсодержащий несколько темфильтра UNSUBSCRIBE пакет,онТребуетсякак если бы он получил серию изнескольких

UNSUBSCRIBE отчётодин текстобрабатывать этот пакет таким же образом,кроме тогообъединить их ответы в одинотдельный UNSUBACK вне сообщения.

[MQTT-3.10.4-6]。

3.11 UNSUBACK – Отмена подписки —подтверждение

сервер отправляет UNSUBACK сообщениеклиенту для подтверждения полученияв ответ на UNSUBSCRIBE пакет.

MQTT-3.1.1-CN 44

3.11.1 фиксированный заголовок

легенда 3.31 – UNSUBACK сообщение исправленофиксированный заголовок

Bit

байт 1

MQTT управляющий пакеттип сообщения (11)

зарезервированный бит

байт 2

оставшаяся длина (2)

оставшаяся длинаполе длины

указывая длину переменного заголовка, для UNSUBACK этого сообщениязначение равно 2。

3.11.2 переменный заголовок

переменный заголовок содержит и т. д.ожидающее подтверждение UNSUBSCRIBE сообщениеидентификатор пакета.

легенда 3.32 – UNSUBACK Сообщение можетпеременный заголовок

Bit

байт 1

идентификатор пакета MSB

байт 2

идентификатор пакета LSB

3.11.3 payload

UNSUBACK сообщение не имеетполезной нагрузки。

3.12 PINGREQ – запрос проверки связи

клиент отправляет PINGREQ сообщениена сервер. Использоватьв:

1. при отсутствии любого другогоуправляющего пакета от клиентакогда клиент отправляет на сервер,сообщить серверу, что клиентклиент жив.

2. запросить сервер отправить ответ подтверждает, что он все ещежив.

3. использовать сеть для подтверждениясетевое соединение не имеетотключения.

Keep Alive (Keep）обработкаиспользуется вэтом пакете,подробнодля получения информации, см. 3.1.2.10 раздел.

3.12.1 фиксированный заголовок

легенда 3.33 – PINGREQ фиксированный заголовок пакета

Bit

байт 1

MQTT тип управляющего пакета (12)

зарезервированный бит

MQTT-3.1.1-CN 45

байт 2

оставшаяся длина (0)

3.12.2 переменный заголовок

PINGREQ отчетСообщение не имеет переменного заголовка。

3.12.3 payload

PINGREQ отчетсообщение не имеет полезной нагрузки。

3.12.4 response

На стороне сервераТребуетсяотправить PINGRESP ответный пакетклиента PINGREQ сообщение [MQTT-3.12.4-1]。

3.13 PINGRESP – ответ проверки связи

сервер отправляет PINGRESP пакет отвечает клиентуклиента PINGREQ пакет.Означаетсервер всё ещё жив-ing.

Keep Alive (Keep Alive）обработкаиспользуется вэтом пакете,подробностисм. 3.1.2.10 раздел.

3.13.1 фиксированный заголовок

легенда 3.34 – PINGRESP сообщение фиксированофиксированный заголовок

Bit

байт 1

MQTT тип управляющего пакета (13)

зарезервированный бит

байт 2

оставшаяся длина (0)

3.13.2 переменный заголовок

PINGRESP сообщениенет переменного заголовказаголовок.

3.13.3 payload

PINGRESP сообщениене имеет полезной нагрузкиполезная нагрузка.

3.14 DISCONNECT –отключение

DISCONNECT пакет отправляется от клиента к серверупоследний пакет серверауправляющий пакет.указывает, что клиент отключился нормальносоединение.

MQTT-3.1.1-CN 46

3.14.1 фиксированный заголовок

легенда 3.35 – DISCONNECT сообщениефиксированный заголовок

Bit

байт 1

MQTT тип управляющего пакета (14)

зарезервированный бит

байт 2

оставшаяся длина (0)

На стороне сервераТребуетсяпроверить все сохранённыевсе зарезервированные биты установленыустановлены в 0, еслиони не 0 Требуетсяотключить [MQTT-3.14.1-1]。

3.14.2 переменный заголовок

DISCONNECT Пакет не имеет переменного заголовка.

3.14.3 payload

DISCONNECT пакет не имеет полезной нагрузкиполезная нагрузка.

3.14.4 response

клиент отправляет DISCONNECT отчётпосле сообщения:

 Требуетсязакрыть сетевое соединение [MQTT-3.14.4-1]。

 не можетчерез это сетевое соединение сноваотправлять какие-либо управляющиеуправляющий пакет [MQTT-3.14.4-2]。

сервер при получении DISCONNECT при отправке сообщения:

 Требуетсяотбросить любые связанные с текущим соединениемсвязанные неотправленныеопубликованныеwillсообщение, см. конкретное описание 3.1.2.5 раздел [MQTT-3.14.4-3]。

 долженЗакрыть сетевое соединение,если клиент еще этого не сделал.

MQTT-3.1.1-CN 47

4 рабочее поведение

4.1 хранение состояния

Для обеспечения качества обслуживаниягарантии QoS, клиентклиент и сервер имеютнеобходимые для хранения сеансовогосостояния. На протяжении сеансамежду, клиентклиент и сервервсеОбязательно

хранить состояние сеанса [MQTT-4.1.0-1]. СеансОбязательнодлится по крайней мере так же долго, как его активная сетьсетевое соединение такой же длительностивремя [MQTT-4.1.0-2]。

сохранённое сообщение серверасообщение не является состоянием сеансачастью состояния. Сервердолженсохранять сообщения такого типасообщение до тех пор, пока клиент не удалит его.

ненормативныйкомментарий

клиент и серверхранилище реализацииЁмкостьобязательно ограниченаиз, также может потребоватьсяподчиняться политике управленияограничения, например, в рамкахсеанса сетевого соединения

максимальный объём хранения состояния сеансавремя хранения. уже сохранённоесохранённое состояние сеансаПотеря может быть определённойвызванной операцией управления,например, дляпредопределённого элемента

автоматический ответ.последствия, которые оно вызывает— это завершение сеанса. Эти операции могутбыть ограничениями ресурсовили быть вызваны другими эксплуатационными причинамио. Нужно

Необходимо тщательно оценить клиентскуюклиентскую и сервернуюемкость хранилища,чтобы гарантировать, что места в хранилищевремени достаточно.

ненормативныйкомментарий

клиент или серверсбоев программного и аппаратного обеспечениявсе могут вызвать переход состояния сеанса кпотере или повреждению。

ненормативныйкомментарий

сервер и клиентнормальная работа можетозначать, что сохранённое состояниепотеря или повреждение состоянияэто операции управления или программное/аппаратное обеспечениевызванное сбоями.

административные операции могут бытьдля предопределённойавтоматической реакции на условия. Этонекоторые операции могут бытьограничениями ресурсов или другими операциямивызвано этой причиной.

например, сервер можетможет, основываясь на внешнихусловиях, решить неотправлять определённое сообщение сноваили некоторые сообщения, распределяемые любомулюбое текущее илипосле клиента

клиент.

ненормативныйкомментарий

MQTT пользователь должендолжен оценить MQTT реализации клиента и сервераёмкости хранилища,убедиться, что он может удовлетворить потребностьзапроса.

4.1.1 Ненормативный пример

например, если вы хотите собиратьиспользование показаний счётчиковпользователь может решить использовать QoS 1 уровеньсообщение, потому что они не могутполучение данных в сетисетевой путь передачи

потеряны в ..., но,Они могут думатьданные клиента и сервераданные могут храниться впамяти (энергозависимая память), потому что (они считают

источник питания являетсяочень надежным,не будет иметь слишком большогориска потери данных.

напротив, парковочныеприложения для выставления счетов и платежейпоставщик может решить, что какие-либони при каких обстоятельствахне могут привести к потере сообщений о доставке данныхпотери,Поэтомуони требуют, чтобы

передаваемые по сетиперед этим все данныеданные должны быть записаны наэнергонезависимое запоминающееустройство (например, жесткий диск）。

4.2 Сетевое соединение

MQTT протокол нуждаетсятребует, чтобы нижележащий транспортныйуровень мог обеспечитьупорядоченную, надежнуюпередачу,двунаправленныйтранспорт (от клиента ксерверной стороне и отсервера к клиенту

поток байтов конечной точки).

ненормативныйкомментарий

MQTT 3.1 используетпротокол транспортного уровняДа [RFC793] определён TCP/IP взаимодействуетобсуждение.следующий протокол такжеподдерживает:

MQTT-3.1.1-CN 48

 TLS Протокол [RFC5246]

 WebSocket Протокол [RFC6455]

ненормативныйкомментарий

TCP порт 8883 и 1883 уже в IANA Примечаниерегистрация, соответственно используемая для MQTT из TLS и не- TLS связь.

сетевая передача без установления соединениятранспортный протокол, такой как UDP Дане поддерживается,потому что они могутможет потерять пакет данныхили изменить порядок пакетов данных。

4.3 Уровень качества обслуживания и поток протокола

MQTT в соответствии с этимсервисом, определенным вкачестве обслуживания (QoS) уровне распространения приложенияСообщение. Распространениепротокол симметричен, в следующемв приведенном выше описании,клиент

и сервер может какотправитель также можетОн уже является получателем.Протокол доставки ориентирован наот одного отправителя кодному получателюСообщение приложения.одежда

серверРаспространяет сообщения приложения нескольким клиентамкогда в конце, каждый клиентклиент обрабатывает независимо. Доставлено клиентуисходящее приложение клиентасообщения и входящие сообщения приложения

для QoS уровень можетможет отличаться.

следующий ненормативный потокНа диаграмме показаны возможныеметоды реализации.。

4.3.1 QoS 0:не более одного раза

доставка сообщения зависит отнижележащей сетивозможностей. Получательне будет отправлять ответ, отправитель также небудет повторять попытку. Сообщениеможет быть доставлено один раз или может

не было доставлено вообще.

для QoS 0 протоколадоставки, отправительотправитель

 Требуетсяотправить QoS равно 0，DUP равно 0 из PUBLISH сообщения [MQTT-4.3.1-1]。

для QoS 0 протоколадоставки, получательполучатель

 Принять PUBLISH при сообщении, одновременно получитьполучить всё сообщениеверно.

легенда 4.1 – QoS 0 поток протоколадиаграмма,ненормативныйПример

отправительдействие

управляющий пакет

получательдействие

PUBLISH сообщение QoS 0, DUP=0

---------->

доставлять прикладные сообщения ксоответствующему последующему получателюполучать

тот (те)

4.3.2 QoS 1: как минимумРазделитьотправить один раз

одеждаделокачествоколичествоподтвердитьзащититьустранитьдыханиеКнесколькоотправитьдостичьодинраз。QoS 1 из PUBLISH отчёттекстизможетизменитьотчётзаголовокСреднийПакетсодержитодинэлементыотчёттекстметказнатьсимвол，Нужнохотеть

PUBACK подтверждение сообщения.2.3.1 разделпредоставляет информацию об идентификаторах пакетовдополнительная информация об идентификаторе。

для QoS 1 протоколадоставки, отправительотправитель

 каждый раз, когда отправляется новое прикладное сообщениевсе сообщенияТребуетсяНазначить не-используемый идентификатор пакетасимвол.

 отправленное PUBLISH сообщениеТребуетсясодержитидентификатор сообщения и QoS равно 1，DUP равно 0。

MQTT-3.1.1-CN 49

 Требуетсяэто PUBLISH отчетноесообщение, рассматриваемое как

неподтвержденное

，покане получит соответствующий от получателя PUBACK пакет.4.4 раздел

имеется ... о неподтвержденномобсуждении подтверждения сообщения。

[MQTT-4.3.2-1].

как только отправитель получит PUBACK пакет,этотидентификатор пакетаможно использовать повторно.

Примечание:Разрешено,отправитель ожидает подтвержденияпри использовании другогоидентификатора пакета для отправки последующихиз PUBLISH пакет.

для QoS 1 изпротокола доставки, получательполучатель

 ответ PUBACK сообщениеОбязательносодержитидентификаторы сообщений,этот идентификатор происходит изиз полученного,уже принял всеполномочия

PUBLISH пакет.

 отправил PUBACK отчётпосле сообщения,получатель долженлюбое, содержащее тот жеидентификатор входящего пакета PUBLISH сообщениекак

новое сообщение, иигнорировать его DUP меткузначение флага.

[MQTT-4.3.2-2].

легенда 4.2 – QoS 1 схема потока протоколадиаграмма,ненормативныйПример

отправительдействие

управляющий пакет

получательдействие

хранить сообщения

отправить PUBLISH сообщение QoS=1,

DUP=0, с сообщениемИдентификаторы

---------->

начать ... прикладного сообщенияпоследующее распространение

<----------

отправить PUBACK сообщение, с меткойсообщения

идентификатор

отбросить сообщение

не требует, чтобы получательотправил PUBACK до завершения распределенияотправить сообщения приложения. Исходноеотправитель получает PUBACK сообщениепосле этого,

все права на сообщение приложениябудут переданыэтому получателю.

4.3.3 QoS 2: толькодоставить один раз

это наивысший уровенькачества обслуживания,Сообщениепотеря и дублированиевсе недопустимы. Использование этого качества обслуживанияуровень качества будет иметь дополнительныенакладные расходы.

QoS 2 устраненияв переменном заголовке сообщенияимеет идентификатор пакета.2.3.1 разделпредоставляет информацию ообновлении идентификатора пакетадополнительную информацию.QoS 2 в PUBLISH

получатель пакета используетс использованием двухэтапного подтвержденияпроцесс подтверждения для подтверждения получения.

для QoS 2 ofпротокола доставки, отправительотправитель

 должен назначить отправляемому ...распределение нового прикладного сообщенияназначить неиспользуемый пакетныйидентификатор.

 отправитьиз PUBLISH сообщениеОбязательносодержитидентификатор пакета и QoS пакета равен 2,，DUP равен 0。

 Требуетсяэто PUBLISH отчетноесообщение, рассматриваемое как

неподтвержденное

，покане получит соответствующий от получателя PUBREC пакет.4.4 раздел

имеется ... о неподтвержденномобсуждении подтверждения сообщения。

MQTT-3.1.1-CN 50

 получен PUBREC после сообщенияТребуетсяотправить PUBREL пакет.PUBREL сообщение должнодолжно содержать тот жеисходный PUBLISH message

тот жеидентификатор пакета.

 Требуетсяэто PUBREL отчётноесообщение рассматривается как

неподтвержденное

，покане получит соответствующий от получателя PUBCOMP пакет.

 как только соответствующий ... был отправлендля PUBREL сообщения, тонельзяповторно отправить это PUBLISH пакет.

[MQTT-4.3.3-1].

как только отправитель получит PUBCOMP сообщение, этотидентификатор пакета может быть затем повторно использован。

дляQoS 2протокола доставки, принимающеелицо

 ответ PUBREC сообщениеТребуетсясодержитидентификатор пакета, этот идентификаториз полученного, уже принял всеавторизованные

PUBLISH пакет.

 После получения соответствующего PUBREL перед сообщением,получательдолженотправить PUBREC сообщаетподтверждениелюбого последующего пакета с тем жетем же идентификатором

из PUBLISH пакета. В этом случае,онне можетдублирование доставки сообщенийлюбому последующемуполучателю.

 ответ PUBREL пакета PUBCOMP сообщениеТребуетсясодержащее и PUBREL отчетсообщение с тем же идентификаторомсимвол.

 отправить PUBCOMP отчеттекстапосле, получательдолжен включить тот желюбой с тем же идентификатором сообщенияпоследующий PUBLISH отчеттекст долженсделать один

новая публикация.

[MQTT-4.3.3-2].

легенда 4.3 – QoS 2 схема потока протоколадиаграмма,ненормативныйпример

отправительдействие

управляющий пакет

получательдействие

хранить сообщения

отправить PUBLISH пакет,QoS=2,

DUP=0, сидентификатором пакета

---------->

Методы A: хранить сообщения, или методы B：

сохранить идентификатор пакета, затем начатьдо

доставить это прикладное сообщениедыхание

。

отправить PUBREC отчётныйтекст,с идентификатором сообщения

идентификатор.

<----------

отбросить сообщение, сохранить PUBREC в

идентификатор пакета

отправить PUBREL отчётныйтекст, с сообщениемметка

идентификатор

---------->

MQTT-3.1.1-CN 51

Методы A: начинает пересылать прикладное сообщениедыхание

затем отбросить сообщение или метод B：отбросить

идентификатор пакета

отправить PUBCOMP пакет,с сообщением

Идентификаторы

<----------

отбросить сохранённое состояниеусловие

не требует от получателяпри отправке PUBREC или PUBCOMP заранееполное распространение должнос сообщением. Исходный отправляющийполучатель получает

PUBREC отчётпосле пакета, прикладное сообщениеправо владения сообщением затембудет передано этому получателю。

легенда 4.3 – QoS 2 Протоколблок-схема, нестандартныйпример отображениеполучателя QoS 2 ожиданиедва типа сообщений уровняметод обработки.они

разница в том, что сообщение ...когда можно начатьначать распространение. Реализацияразработчик может решить использоватькакой метод использовать. При условии, что реализацияразработчик выбрал толькометод

метод,не повлияет на QoS потокнадёжность процесса.

4.4 повтор доставки сообщения

клиент устанавливает флаг Clean Startсеанса (CleanSession）Flagsявляется 0 переподключениекогда, клиенти серверОбязательноиспользовать исходныйповторно отправить начальный идентификатор сообщения

любое неподтверждённое PUBLISH сообщение (если QoS>0) и PUBREL сообщение [MQTT-4.4.0-1]. Это единственноеодноТребованиеклиент или

Сервер повторно отправляет сообщенияв такой ситуации.

ненормативныйкомментарий

Повторная передача управляющих пакетовнеобходима для преодолениянекоторых устаревших TCP данных в сетипроблема потери данных.развёрнут в этих средах MQTT

3.1.1 реальнаяРеализация всё ещё может потребоватьсясосредоточиться на этом вопросетема.

4.5 сообщение получено

Сервер берёт на себя входящеевладение прикладным сообщениемкогда авторизован, онТребуетсясообщениедобавить в подпискусессия соответствующего клиентав состоянии.правила сопоставления определяют

семантическое представление 4.7 раздел [MQTT-4.5.0-1]。

При нормальных обстоятельствах клиентклиент получает отправленноев его подпискусообщение. Клиенттакже может получать сообщения, не связанные с нимподписка точно совпадаетсоответствующее сообщение. Например

Если сервер автоматически отправляетклиенту назначеннуюподписку,возможнотакая ситуация возникаетситуация. В настоящее время обрабатывается UBSUBSCRIBE запросможет также получитьдля

сообщение. Клиентдолженв соответствии с возможнымиспользуемым качеством обслуживанияколичество (QoS) правило подтверждает, что он получиллюбой PUBLISH пакет,независимо оттого, что онВыбратьобрабатывать ли

Обработать сообщение приложения, содержащееся в пакетеиспользовать сообщение [MQTT-4.5.0-2]。

4.6 упорядочивание сообщений

Реализовать то, что определено в этой главево время потока протокола,клиентОбязанследовать следующим правиламтогда:

 Повторно отправить любой предыдущий PUBLISH отчеткогда сообщение,Требуетсяв соответствии с исходным PUBLISH сообщениепорядок отправкиповторно отправить по порядку (применимоиспользуется для QoS 1 и

QoS 2 Сообщение）[MQTT-4.6.0-1]。

 Требуетсяв соответствии с соответствующим PUBLISH Отправлять пакеты по порядку PUBACK отчеттекст (QoS 1 Сообщение）[MQTT-4.6.0-2]。

 Требуетсяв соответствии с соответствующим PUBLISH Отправлять пакеты по порядку PUBREC сообщение (QoS 2 Сообщение）[MQTT-4.6.0-3]。

 Требуетсяв соответствии с соответствующим PUBREC Отправлять пакеты по порядку PUBREL сообщение (QoS 2 Сообщение）[MQTT-4.6.0-4]。

На стороне сервераТребуетсяпо умолчанию считает, что каждая изтем имеетпорядок. ЭтоДапредоставлятьфункцию управления илидругие механизмы, чтобыпозволяет одному илинескольким мастерам

Рассматривать тему как неупорядоченную [MQTT-4.6.0-5]。

MQTT-3.1.1-CN 52

Сервер обрабатывает отправкув упорядоченные темыкогда сообщение,Требуетсякак указано вышеправила будут отправлять сообщениесообщение, распределяемое каждому подписчику. Кроме того, этоТребуетсяв соответствии с

Полученные от клиентаотправлять по порядку PUBLISH передаетсообщение потребителю(для той же темывопрос и QoS）[MQTT-4.6.0-6]。

ненормативныйкомментарий

Правила, перечисленные вышеобеспечивают, используя QoS 1 публикациии поток сообщений подписки,подписчики в соответствии с сообщениемпорядок при публикации сообщенияполучены по порядкукаждый

СообщениеПоследняя копия, но сообщение можетповторяться, этоможет привести к тому, что онопоследующие сообщенияпосле получения уже определённогоуже полученное сообщение

Повторно отправленная версия. Например, издатель в порядкепоследовательность 1,2,3,4 отправляет сообщения, подписчикпорядок, полученный получателемможет быть 1,2,3,2,3,4。

Если клиент и серверсервер может гарантировать любойв любое время, не более одного сообщенияинформация находится в

во время передачи (

в-полёте

）

(в определённом сообщениидо того, как сообщение подтверждено

Не отправляйте следующеесообщение), тогдачто,не будетДа QoS 1 сообщениябудет в любом из егополученных после последующих сообщений。 Например，

Порядок, в котором подписчики получаютпорядок может быть 1,2,3,3,4, а не 1,2,3,2,3,4. Окно передачи （в-fокне передачи) пустьесть 1

Означает, что в одной и той жепо теме,даже еслииздатель отправляетсерию различных QoS уровней сообщений,их порядок такжедолжен быть защищён

сохранить.

4.7 имя топика и фильтр топика

4.7.1 подстановочный знак топика

уровеньтопика (уровень топика), разделённыйразделителем, используемым для структурированияНормализация вводит имена топиков.если есть разделительраспределения, он будет основнымРазделить имя топика на несколько

уровень топика

level

уровень топика 。

Фильтр подписки на топикустройство может содержать специальныеспециальные подстановочные знаки, позволяющие вамподписаться на несколько сразутопиков.

Фильтр топика можетиспользовать подстановочные знаки, но имена топиковне могутИспользованиеподстановочного знака [MQTT-4.7.1-1]。

4.7.1.1 уровень топикаРазделители

слэш（‘/’ U+002F) используется дляКаждый из уровней топикаУровень, чтобы обеспечить иерархию дляструктуры имени топика. Когда клиентклиент подписывается на указанныйфильтр топика

Фильтр содержит два подстановочных знакакогда разделитель, уровень топикаразделитель уровней оченьполезен. Разделительиерархии топиков можетпоявляться в фильтрах топиковили имени топика

В любой позиции. Смежный разделительиерархии топиковпредставляет собойуровень топика нулевой длины.

4.7.1.2 многоуровневыйподстановочный знак

числовой флаг (‘#’ U+0023) используетсядля сопоставления в темахЛюбойУровеньподстановочный знак. Многоуровневыйподстановочный знак представляет своегородителя и любое количестводочерних элементов этого количества

Уровни. Многоуровневый подстановочный знакразделитель должен располагаться на егосвоём уровне или сопровождатьсяразделителем уровней темыпосле разделителя. НезависимоВ любой ситуацииситуация, всегдаОбязательноявляется темой

Последний изсимволов фильтра [MQTT-4.7.1-2]。

ненормативныйкомментарий

Например,еслиКлиент подписывается на темы “sport/tennis/player1/#”，Он будет получать, используя следующееимя темы опубликованоСообщение:

 “sport/tennis/player1”

 “sport/tennis/player1/ranking”

 “sport/tennis/player1/score/wimbledon”

ненормативныйкомментарий

 “sport/#”также совпадает сотдельным “sport” , потому что # включаяего родителя.

 “#”допустимиз,будет получать всесообщения приложения。

 “sport/tennis/#”такжедопустим.

 “sport/tennis#”недопустим.

MQTT-3.1.1-CN 53

 “sport/tennis/#/ranking”Данедопустимо.

4.7.1.3 одноуровневый подстановочныйсимвол

знак плюс (‘+’ U+002B) можно использовать толькодля одного уровня темыподстановочный знак соответствия уровнясимвол.

В фильтре темлюбой уровень можетможет использовать одноуровневый подстановочный знак,включаяпервый и последний уровни. ОднакоонОбязательнозанимает в фильтре

весь уровень [MQTT-4.7.1-3]。Может быть в фильтре темнесколько уровней вуровень, используя его,также можно использовать с многоуровневымиспользовать подстановочные знаки вместеиспользовать.

ненормативныйкомментарий

Например, “sport/tennis/+” соответствует “sport/tennis/player1” и “sport/tennis/player2” ，Ноне соответствует

“sport/tennis/player1/ranking” . Между тем, посколькуодноуровневый подстановочный знак толькоможет соответствовать одному уровнюуровень, “sport/+” не соответствует

“sport” но он соответствуетallocate “sport/”。

ненормативныйкомментарий

 “+” является допустимым.

 “+/tennis/#” является допустимым.

 “sport+” является недопустимым.

 “sport/+/player1” также является допустимым.

 “/finance” соответствует “+/+” и “/+” , но не соответствуетmatch “+”。

4.7.2 с$темами, начинающимися с

На стороне серверане можетбудет $ начинается с символасопоставление с ведущим именем темысопоставление с подстановочным знаком (#или+) открытьФильтр тем, начинающийся с [MQTT-4.7.2-1]Сервер долженпредотвращать

Клиент использует этот видимена тем и другиеклиенты обмениваются сообщениямисообщение. Реализация сервера можетбудет $ Имена тем, начинающиеся сдля других целей.

ненормативныйкомментарий

 $SYS/ широко"Используется для хранения информации, специфичной для серверасообщение или интерфейс управленияпрефикс темы。

 Приложения не могут использовать $ имена топиков, начинающиеся с символатопика.

ненормативныйкомментарий

 Подписка “#” Клиент не будет получатьлюбые опубликованные в “$” начальную темусообщения топика.

 Подписка “+/monitor/Clients” клиент небудет получать любые отправленные сообщения,распространяемые в “$SYS/mМонитор/Клиенты” исключениясообщение.

 Подписка “$SYS/#” клиентбудет получать сообщения, публикуемые в “$SYS/” начиная ссообщений по теме.

 Подписка “$SYS/monitor/+” наКлиент получит Publishв “$SYS/monitor/Clients” основныесообщения топика.

 Если клиент хочетпри получении “$SYS/” топик, начинающийся ссообщения и не начинающийся с $ топик, начинающийся ссообщения, ему нужноодновременно

Подписка “#” и ““$SYS/#”。

4.7.3 топиксемантикаи использование

имя топика и фильтр топикаФильтры должны соответствоватьследующим правилам:

 все имена топиков иФильтр топикаТребуетсякак минимум включатьсодержит один символ [MQTT-4.7.3-1]。

 имя топика и фильтр топикаФильтры чувствительны к региструнижний регистр.

 имя топика и фильтр топикаФильтры могут содержатьпробел.

MQTT-3.1.1-CN 54

 имя топика или фильтр топикаФильтры с ведущей илизавершающей косой чертой “/” различаются.

 содержит только косые черты “/” имя топика или фильтр топикаФильтр допустим.

 имя темы и фильтр темыфильтрне можетсодержать нулевой символ (Unicode U+0000) [Unicode] [MQTT-4.7.3-2]。

 имя темы и фильтр темыфильтр является UTF-8 закодированной строкой, онине могутПревышено 65535 байт [MQTT-4.7.3-3]. см. 1.5.3

секцию.

кромене может превышать UTF-закодированных символовпредел длины строкиКроме того, имя темы или темыуровни фильтраколичество не имеетдругих ограничений.

при сопоставлении подписок серверсерверне можетдля имени темы илифильтр темы выполняетвыполнять какую-либо нормализацию（нормализация) процесс, неможет изменять или заменять

любой нераспознанный символсимвол [MQTT-4.7.3-4]. СубъектКаждый не-подстановочный в фильтреуровни с подстановочными знаками должны сопоставляться один за другимсимволы соответствуют темесоответствующему уровню в имени

уровень считается успешным совпадением。

неСпецификациякомментарий

Использование UTF-8 Правила кодирования означают, фильтр темыи сравнение имен темСравнение можно выполнить, сравниваяпо сравнению с закодированным UTF-8 байтомили решением

закодированные Unicode символы.

неСпецификациякомментарий

 “ACCOUNTS” и “Accounts” — это разные субъектыЗаголовок.

 “Accounts payable” согласуетсяс именем субъекта

 “/finance” и “finance” различаются.

еслиФильтр подписанной темы и имя темы сообщениясовпадают, сообщения приложения будутотправлены каждомусоответствующему клиентуподписка. Темаможет быть

Администратором на серверепредопределена, или это может быть серверсервер получает первоеподписку или используя эту темусообщение приложения с именем темыдинамически добавляется при получении сообщения

из. Сервер также можетможет использовать средство безопасностикомпонент безопасности выборочноавторизовать клиента на использование определённогоресурса темы.

4.8 Обработка ошибок

Если не указано иное,Если сервер илиКлиент столкнулсяс поведением, нарушающим протокол,этоТребуетсяотключить передачу этогонарушения протоколав сеть управляющих сообщений

сетевое соединение [MQTT-4.8.0-1]。

клиент или серверреализация может столкнутьсяс временными ошибками (Tвременная ошибкаили)(например, внутрибуфер заполненслучай), что приводит кневозможности успешно

обработка MQTT пакета.

Если клиент или серверсерверная сторона обрабатывает входящийобнаружил временнуюошибку времени при обработке управляющего пакета,онТребуетсязакрыть транспорт, которыйСетевое соединение для управляющих пакетовJie

[MQTT-4.8.0-2]。еслисервер обнаружилвременную ошибку, онне долженотключатьсяподключаться или выполнятьлюбые по отношению к другим клиентамоперации, влияющие на узел

делать.

 
  MQTT-3.1.1-CN  55 
5  безопасность 
5.1 Обзор 
Содержание этой главы предназначено длясправочных целей, нестандартизировано. Однако, настоятельно рекомендуетсяобеспечить TLS обслуживаниясерверная реализациядолжнаИспользование TCP порта 8883
（IANA имя службы:secure-mqtt）。 
 
поставщик решенийНеобходимо учитывать множестворисков. Например: 
  Устройства могут быть украденыиспользование 
  клиент и серверстатические данные могутмогут быть доступны (могут быть исправленыизменены) 
  Поведение протокола может иметьпобочные эффекты (такие какатаки по времени) 
  атаки типа «отказ в обслуживании» 
  Связь может быть перехваченаперехват,изменениеперенаправление или раскрытие 
  поддельные управляющие сообщениявнедрение 
 
MQTT схема с помощьючасто развертывается взащищенная связьсреда. В этомслучае протоколреализация обычно требуетНеобходимо обеспечить эти механизмы: 
  Идентификационные данные пользователя и устройствааутентификация 
  Доступ к ресурсам сервераавторизация 
  MQTT управляющий пакеттекст и встроенное приложениецелостность данныхпроверка целостности 
  MQTT управляющий пакеттекст и встроенное приложениеконфиденциальность данныхчастное управление 
 
Будучи протоколом транспортного уровня，MQTT сосредоточен только на передаче сообщений;обеспечение надлежащей безопасностиполная функциональность — ответственность реализатораответственность. Используйте TLS [RFC5246] Да
относительно распространённый выбор. В дополнение к техническимпомимо вопросов безопасности,и географическим факторамфакторам (например, Соединённые ШтатыПринципы безопасной гавани ЕС 
[USEUSAFEHARB]）, отраслевыестандарты (например,индустрия сторонних платежейстандарты безопасности данных [PCIDSS]), нормативныеаспекты (Пример
такие как Sarbanes-глубокийOxley Act [SARBANES]) и т.д.проблема. 
5.2 MQTT Решение: Безопасность и аутентификация 
Реализации протокола могут захотетьдолжны соответствовать конкретнымотраслевым стандартам безопасности, таким как NIST netструктура кибербезопасности [NISTCSF] , сторонниеданные платежной индустриимир
полный стандарт [PCIDSS] , федеральныестандарты обработки информации США [FIPS1402] и NSA добавляеткомбинацию шифров B [NSAB] 。 
В MQTT патчадополнительная публикация （MQTT и NIST Framework для улучшения критической инфраструктуры 
Кибербезопасность [MQTT NIST]） можно найти вВ NIST Сетеваяструктура безопасности [NISTCSF] Среднееиспользование MQTT изруководства. Используйте
Отраслевая сертификация, независимыйаудит и технология аутентификациипомогают соответствоватьтребованиям соответствия. 
5.3 Легковесное шифрование и устройства с ограниченными ресурсами 
широко распространённое передовое шифрованиестандарт шифрования [AES] номершифрование данныхСтандарт [DES] 。 
рекомендуется для использования в качестве ограниченныхвозможностей устройств начального уровняспециально оптимизированное легковесноешифрование уровня, международныйстандарт ISO 29192 [ISO29192] 。 
5.4 вопросы реализации 
реализация и использование MQTT требуют учитывать множествопроблем безопасности.нижеэта часть не должнаследует рассматривать какпункты контрольного списка 。 
Реализации протокола могут реализоватьсейчас следующую частьчастично или полностью: 

 
  MQTT-3.1.1-CN  56 
5.4.1 идентификация клиентапроверка 
CONNECT сообщениетекст содержит поля имени пользователя и пароля.Реализацияможет решить, как использовать эти символыСодержание этого пункта. Реализаторы могут предоставитьсобственные
Механизм аутентификации,или использовать внешнююсистему аутентификации, такую как LDAP [RFC4511] или OAuth [RFC6749] , такжеможет использовать операционную систему
механизмы аутентификации. 
реализации могут передавать открытый текстдоставлять аутентификационные данные,обфусцировать эти данные, или не требоватькаких-либо аутентификационных данных,но следует осознаватьэто увеличит использование виртуального между промежуточнымиатака типа «человек посередине»
атак и атак повторного воспроизведенияриск.5.4.5 разделпредставил точныеметоды обеспечения конфиденциальности данных. 
На клиентских и серверныхконечных точкахвиртуальная частная сеть (VPN) можетгарантировать, что данные толькоАвторизованные клиентыклиент получает. 
Использование TLS [RFC5246] когда,Сервер может использоватьотправленные клиентом SSL сертификатпроверить клиенталичность. 
Реализация может позволить клиентуклиент через приложениесообщение отправки учетных данных на серверсертификат для проверки личностидоказательство. 
5.4.2 авторизация клиента 
На основе предоставленной клиентоминформации, такой как пользовательимя, идентификатор клиентаидентификатор (ClientId）、клиентимя хоста или IP адрес, илиаутентификация
В результате серверможет ограничить доступ к определеннымсерверным ресурсамдоступ. 
5.4.3 Сервисысама конечная точкапроверка подлинности 
MQTT протокол неявляется двусторонним доверием, он необеспечивает проверку клиентомподлинности серверамеханизм. 
НоИспользование TLS [RFC5246] когда, клиент может использовать сервисотправленный сервером SSL сертификатпроверитьидентичность сервера. С одного IP многодоменных имён
Обеспечить MQTT Реализация сервиса должнаучитывать RFC6066  [RFC6066] №. 3 разделопределён TLS из SNI Расширение.SNI позволяет клиентамзавершить
Сообщить серверу, что он хочетподключённого сервераимя хоста. 
Реализация может позволить серверусервер через приложениесообщение, отправляющее учётные данные клиентусертификат для проверки идентичностидоказательство. 
На клиенте и сервереконечные точкивиртуальная частная сеть (VPN) можетобеспечить клиентаподключается к ожидаемомусервера. 
 
5.4.4 управляющеесообщениеи сообщение приложенияцелостность сообщенияцелостность 
Приложение может быть в приложениисообщение отдельно содержит хеш-значение. Этосделав так, можно PUBLISH управлениесетевая передача и статические данныепредоставляют контент
Проверка целостности. 
TLS [RFC5246] упоминает, чтодля передаваемых по сети данныхпредусмотренхеш-алгоритм для проверки целостностиметод. 
На клиентских и серверныхконечных точкахподключение к виртуальной частной сети (VPN)Вы можете VPN покрытСетевой сегмент обеспечивает целостность данныхпроверка целостности. 
5.4.5 управляющие сообщения иприкладное сообщениенарушениеконфиденциальности 
TLS [RFC5246] можетдля передачи по сетизашифрован.. Если допустимый TLS набор шифровкомбинация содержит алгоритм шифрованияравен NULL，тогда он
Он не шифрует данные.должен обеспечить клиентуи серверуконфиденциальность, следует избегать использованияиспользует эти наборы шифровсоглашение. 
 
Приложения могут отдельно добавлятьдля шифрования сообщений приложенийсодержимое. Это можетпредоставлять сообщения приложений при передаченейтральную и статическуюконфиденциальность статических данныхКонфиденциальность. Но не может предоставлять сообщения приложений
Другие атрибуты сообщения, такие какшифрование имени темы. 
 
клиента и серверареализации могут шифроватьХранение статических данных, напримермогут шифровать сообщения приложенийсообщение как часть сессиихранилище. 
На клиентских и серверныхконечных точкахподключение к виртуальной частной сети (VPN)Вы можете VPN охваченныйСетевой сегмент обеспечиваетконфиденциальность данных。 
5.4.6 передача сообщенийнеотказуемостьподлинность 
Разработчику приложения, возможно,потребуется рассмотреть подходящиестратегии для реализации сквознойотрицаемости (не-отказуемость）。 

 
  MQTT-3.1.1-CN  57 
5.4.7 обнаружениеклиентклиент и серверна стороне серверакража 
Использование TLS [RFC5246] клиентаРеализации клиента и сервера должнымогут обеспечивать,Инициализировать TLS [RFC5246] при подключении предоставлятьпредоставлено SSL доказывать
Сертификат привязан к имени хоста (клиентам нужно подключатьсяили сервер, к которому будут подключаться) отношениесвязано. 
 
Использование TLS [RFC5246] клиентаРеализации клиента и сервера могутвыбирать предоставление обнаруженияПроверка списка отзыва сертификатов  (CRLs [RFC5280]) и онлайн
Протокол статуса сертификата  (OSCP) [RFC6960] изфункции,Отклонять использование отозванныхсертификата. 
 
Физическое развертывание можетустойчивое к вскрытию оборудование испециальные данные сообщений приложенийсочетание передачи.Например,aприборы могутвстроенный один GPS чтобы обеспечить
Не используется в несанкционированномрегионе.IEEE устройство безопасностиаутентификация устройства [IEEE 802.1AR] заключается в использованиидля реализации этого механизмаСтандарт для управления,он делает
Использовать зашифрованный идентификатор привязкидля проверки идентичности устройствакопия. 
 
5.4.8 обнаруживать аномальное поведение 
Реализация сервера можетотслеживать клиентскоеповедение, обнаруживать потенциальныеугрозы безопасности. Например: 
  Повторяющиеся запросы на подключение 
  Повторяющийсязапрос аутентификации 
  Аварийное завершение соединения 
  Сканирование тем (запросотправки или подписки на большоеколичество тем) 
  Отправка недоставляемыхсообщений (темы безподписчиков) 
  Клиент подключается, ноне отправляет данные 
Обнаружение нарушений правил безопасностив поведении, сервернаяреализация можетразорвать соединение клиентаподключить. 
Реализация сервера обнаруживаетнежелательное поведениеможет основываться на IP groundадресе или идентификаторе клиентачтобы реализоватьдинамический черный список. 
Развертывание сервиса можно выполнитьс использованиемуправления сетевым уровнем (если доступно), реализованного на основе IP базыадрес или другоеограничение скорости его информацииили черный список. 
5.4.9 другойпо безопасностимеры безопасностиэлемент 
Если клиент или серверна стороне сервера SSL Потеря сертификата, или яОни считают сертификат украденнымиспользованным или отозванным(Использовать CRLs [RFC5280] и 
OSCP [RFC6960])оситуации. 
 
клиент или серверпри проверке учетных данных,если обнаружено, что у пользователяимя пользователя и пароль потеряныили украдены, должендолжен отозвать или перевыпустить。 
 
При использовании долгоживущих соединений： 
  клиент и серверИспользование TLS [RFC5246] должны разрешатьразрешать повторное согласованиесогласовать сеанс для подтвержденияновых параметров шифрования (заменитьсеансовый ключ
Ключ, изменить набор шифровидентичность, изменить аутентификационныеучетные данные). 
  Сервер может разорватьсоединение клиента,и потребовать от нихиспользовать новые учетные данные для повторнойпроверки личности. 
 
В ограниченной сети довереннаяограниченная устройствами и клиентамиконечная точка может использовать TLS возобновление сеанса [RFC5077] сократить TLS сеансовоепереподключение [RFC5246] затрат
затраты. 
 
Подключенные к серверуи другие клиентыклиенты, подключенные к серверуконец Существует транзитивное отношение доверия между, все они имеют правона одну и ту же тему
публиковать сообщения. 

 
  MQTT-3.1.1-CN  58 
5.4.10 Использование SOCKS брокер 
Клиентская реализация должнаучитывать, что некоторые средысреда требует использования SOCKSv5 [RFC1928] поколенияуправление создаёт исходящеесетевое соединение.некоторые MQTT реальные
Безопасность теперь может быть использованатуннель (такой как SSH）через SOCKS брокер. однаРеализация решает поддерживать SOCKS когда,Она должна одновременно поддерживатьскрывать
имени, имени пользователя и пароляпроверка кода SOCKS прокси.для последнегослучая, реализоватьследует учитывать SOCKS можетможет использоватьаутентификацию открытым текстом,
СледовательноСледует избегать использования тех же учётных данныхподключение MQTT сервер. 
5.4.11 профиль безопасности 
Разработчик и проектировщик решенияпроектировщики могут пожелатьРассматривать безопасность как конфигурационный файлнабор долженприменяться к MQTT в протоколе. Ниже описываетсяпредставляет собой многоуровневую безопасность
общая иерархическая структура. 
5.4.11.1 Открытаяконфигурация связи 
Используйте конфигурацию открытой связипри настройке,MQTT Протокол работает на встроенном без дополнительныхнакладных расходов дополнительного защищенного механизма связиразмещенного в сети. 
5.4.11.2 безопасностьконфигурация сетевой связи 
Используйте защищенную сетевую связьпри настройке связиMQTT работа протоколавыполняется в защищеннойконтролируемой физической или виртуальнойв сети,Например VPN или объектФизическая защищенная сеть. 
5.4.11.3 Конфигурация защищенной передачи 
Используйте конфигурацию защищенной передачипри настройке,MQTT протокол работает наИспользование TLS [RFC5246] изФизическая или виртуальная сетьв сети, он обеспечиваетОбеспечивает аутентификацию личности，
Целостность и конфиденциальность。 
 
Использовать встроенные пользовательскиеПоля имени пользователя и пароля，TLS [RFC5246] идентификация клиентаАутентификация личности может использоватьсядля (или вместо）MQTT гостевойаутентификации клиента
доказательство. 
5.4.11.4 Безопасность на уровне отраслевых стандартовполная конфигурация 
Как и следовало ожидать,MQTT Позамыслу предназначен для поддержкимногих отраслевых приложенийконфигурация,Каждый определяетмодель угроз и для определенияпозиции угрозы
Специальный механизм безопасности. Специальный механизм безопасностирекомендует следующий методвыбора в плане: 
 
[NISTCSF] NIST структура сетевой безопасностирамки 
[NIST7628] NISTIR 7628 Руководство по кибербезопасности Smart Grid 
[FIPS1402] (FIPS PUB 140-2) модуль шифрованиятребования безопасности 
[PCIDSS] PCI-DSS Поддержка третьих сторонБезопасность данных платежной индустрииполный стандарт 
[NSAB] NSA комбинацияшифрования B 

MQTT-3.1.1-CN 59

6 Использование WebSocket в качествесетевого уровня

если MQTT In WebSocket [RFC6455] соединениепри передаче,Требуетсявыполнитьследующие условия:

 MQTT управляющий пакеттекстТребуетсяИспользование WebSocket двоичное числоКадр данных отправлен. Еслиполучен любой другой типкадра данных, принять

лицоТребуетсязакрыть сетевое соединение [MQTT-6.0.0-1]。

 один WebSocket номерКадр данных может содержать несколькоодин или часть MQTT Пакет. Получательне можетпредполагать MQTT управляющий пакетнажимать

WebSocket выравнивание границ кадров [MQTT-6.0.0-2]。

 клиентТребуетсяСтрока mqtt содержащаяся в немпредоставлена WebSocket суб-протоколв списке протоколов [MQTT-6.0.0-3]。

 Сервер выбирает и возвращаетвозвращенный WebSocket суб-протоколимя протоколаТребуетсяДа mqtt [MQTT-6.0.0-4] 。

 Используется для подключения клиентови серверного WebSocket URI Пара MQTT не влияет на протокол.

6.1 IANA Примечаниемеры предосторожности

эта спецификация запрашивает IANA In WebSocket подпротоколзарегистрирован под именем протокола WebSocket MQTT подпротокол,Используйте следующие данные：

легенда 6.1 - IANA WebSocket Идентификаторы

Идентификатор подпротокола

mqtt

Общее имя подпротокола

mqtt

определение подпротокола

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html

MQTT-3.1.1-CN 60

7 согласованность

MQTT спецификация определяетопределен MQTT гостевогоклиента реализация и MQTT Реализовано серверомтребования соответствия

MQTT реализация можетможет одновременно быть MQTT клиентом и MQTT сервер.Принимать входящие подключенияи устанавливать к другимисходящего подключения серверазакрывается

Сервер также должен соответствоватьобъединять MQTT гостевойклиент и MQTT требование на стороне сервераНайти [MQTT-7.0.0-1]。

Чтобы с любым другимсоответствующей реализациейвзаимодействовать,соответствующая реализация не можеттребуется использовать в этой спецификацииЛюбые внешне определённыеРасширения [MQTT-

7.0.0-2]。

7.1 цели соответствия

7.1.1 MQTT на стороне сервера

a MQTT Сервер удовлетворяет тольконижеВсечтобы считаться соответствующим требованиямНастоящая спецификация:

1. сервер отправляетвсех управляющих пакетовформат должен соответствоватьГлаве 2 иформату, описанному в Главе 3

2. соответствовать 4.7 сопоставлению тем, описанному в разделеправилам сопоставления.

3. соответствовать следующим главамвсем в этом разделеОбязательныетребования уровнязапрос,ясноПрименяется только к клиентукроме:

- Глава 1 – Введение

- Глава 2 – MQTT формат управляющего сообщенияформула

- Глава 3 – MQTT управляющий пакет

- Глава 4 – поведение при работе

- Глава 6 –(если MQTT сетевой уровень — это WebSocket）

- Глава 7 – цели соответствия

Соответствовать требованиям согласованностисервераТребуемаяподдержка с использованием одногоодного или нескольких нижележащих транспортныхТранспортный протокол, при условии, чтоОн обеспечивает упорядоченный, надежный,двунаправленныйбайтовый

поток (от клиента кServer и от сервисаServer к клиенту）[MQTT-7.1.1-1]. ОднакоСогласованность не зависит от того, поддерживает ли онПоддержка любого конкретного

транспортный протокол. СерверконецДаподдерживает 4.2 разделлюбой из перечисленныхтранспортный протокол, илилюбой другой, удовлетворяющий [MQTT-7.1.1-1] требуемаяпередача

протокол.

7.1.2 MQTT клиент

a MQTT Клиент удовлетворяетвсем нижеперечисленнымТолько тогда он считается соответствующим.Настоящей спецификации:

1. клиент отправляетвсех управляющих пакетовформат должен соответствоватьГлаве 2 иформату, описанному в Главе 3

2. соответствовать следующим главамвсем в этом разделеОбязательныетребования уровнязапрос,ясноПрименяется только к серверукроме:

- Глава 1 – Введение

- Глава 2 – MQTT формат управляющего сообщенияформула

- Глава 3 – MQTT управляющий пакет

- Глава 4 – поведение при работе

- Глава 6 – (если MQTT сетисетевой уровень является WebSocket）

- Глава 7 – цели соответствия

Соответствовать требованиям согласованностиклиентТребуетсяподдерживать использование одногоодного или нескольких нижележащих транспортныхтранспортных протоколов, при условии чтоОн обеспечивает упорядоченный, надежный,двунаправленныйбайтовый

поток (от клиента кServer и от сервисаServer к клиенту）[MQTT-7.1.2-1]. ОднакоСогласованность не зависит от того, поддерживает ли онПоддержка любого конкретного

MQTT-3.1.1-CN 61

транспортный протокол. КлиентскаясторонаДаподдерживает 4.2 разделлюбой из перечисленныхтранспортный протокол, илилюбой другой, удовлетворяющий [MQTT-7.1.2-1] требуемаяпередача

протокол.

MQTT-3.1.1-CN 62

приложение B Обязательноезаявление о соответствии спецификации(нестандартнаяобласть）

Это приложение не является нормативнымНормативные, только какВ основном тексте этого документаможно найтибольшое количествозаявлений о соответствииПриводится сводка.Требования соответствиястолбец ограничений

Таблица, показанная в Главе 7.

объявленный порядковый номер

заявление о спецификации

[MQTT-1.5.3-1]

UTF-8 Символы в закодированной строкесимвольные данныеТребованиесоответствует Unicode Спецификация [Unicode] определена и в

RFC3629 [RFC3629] средне-тяжелыйпризнан допустимым UTF-8 форматом. ОсобоСледует особо отметить, что,Этичисла

согласноне можетсодержать код символа в U+D800 и U+DFFF междуданные.Если сервер илиКлиент получает

содержит недопустимый UTF-8 символуправляющий пакет,этотребуетсязакрыть сетевое соединение。

[MQTT-1.5.3-2]

UTF-8 закодированная строкане можетсодержать нулевой символ U+0000。есликлиент или сервер получаетприбыл пакет

содержит U+0000 изуправляющих сообщений,этоТребуетсяЗакрыть сетевое соединение.

[MQTT-1.5.3-3]

UTF-8 последовательность кодировки 0XEF 0xBB 0xBF в целоминтерпретируется как U+FEFF(неразрывный пробел нулевой шириныСимвол

символ),независимо отОн появляется в строкев какой позиции,сообщениеПолучатели не могут пропустить или удалитьоставьте его.

[MQTT-2.2.2-1]

Таблица 2.2 любые, помеченные как“retain”флаговые биты, все зарезервированызарезервировано для будущего использования，Обязательнозадано в виде таблицы

Значения, перечисленные в.

[MQTT-2.2.2-2]

еслиПолучает недопустимый флаг,получательОбязательноЗакройте сетевое соединение.

[MQTT-2.3.1-1]

SUBSCRIBE，UNSUBSCRIBE и PUBLISH（QoS больше чем 0) управляющий пакетОбязательносодержит

ненулевые 16 битыИдентификатор пакета (Идентификатор пакета。

[MQTT-2.3.1-2]

Каждый раз, когда клиент отправляетНовый экземпляр этоготипа пакета, когдаОбязательноПрисвойте в настоящее времянеиспользуемый пакет.mark

идентификатор。

[MQTT-2.3.1-3]

еслиКлиент хочет повторно отправить этот конкретныйспециальный управляющий пакет, при повторной передаче позжекогда этот пакет,онОбязательносделать

Используйте тот же идентификатор. Когда клиентпосле обработки сообщения, соответствующегоПосле подтверждения этотИдентификатор пакета освобождается

сделать многоразовым.QoS 1 из PUBLISH парасоответствует PUBACK，QoS 2 из PUBLISH соответствующий

Да PUBCOMP, и SUBSCRIBE или UNSUBSCRIBE парасоответствующие соответственно являются SUBACK или

UNSUBACK

[MQTT-2.3.1-4]

отправить QoS 0 из PUBLISH сообщениекогда,то жеУсловия также применяются к серверномуконцу.

[MQTT-2.3.1-5]

QoS Установлено в 0 из PUBLISH сообщениене можетсодержать идентификатор пакета.

[MQTT-2.3.1-6]

PUBACK, PUBREC, PUBREL сообщениеТребуетсясодержащее иизначально отправлено PUBLISH сообщение с тем же

идентификатор пакета。

[MQTT-2.3.1-7]

и [MQTT-2.3.1-6] аналогично,SUBACK и UNSUBACK Требуетсясодержится в соответствующем

SUBSCRIBE и UNSUBSCRIBE сообщениеИдентификатор пакета, используемый всимвол.

[MQTT-3.1.0-1]

от клиента к серверуустановление сетевого соединенияпосле установления клиент отправляетпервое серверноесообщениеТребуетсяДа

CONNECT сообщение。

[MQTT-3.1.0-2]

по сетевому соединениювключено, клиент толькоможет быть отправлено один раз CONNECT сообщение. СерверсерверТребуетсяклиенту

второе отправленное CONNECT сообщение какобработка нарушения протоколаи разорвать соединение клиента。

[MQTT-3.1.2-1]

если имя протокола неверноподтвердить серверДаотключить клиентасоединение, такжеДасогласнонекоторым другим спецификациямВозобновить

обработку CONNECT сообщения. Дляв последнем случае,в соответствии с этой спецификацией,на стороне серверане можетпродолжить обработку

CONNECT сообщение。

MQTT-3.1.1-CN 63

[MQTT-3.1.2-2]

Если обнаружено, что не поддерживаетсяуровень протокола,На стороне сервераТребуетсяотправитькод возврата — 0x01(неподдерживаемый протокол

уровень протокола)из CONNACK сообщениеответ CONNECT пакет,затемОтключите соединение клиента。

[MQTT-3.1.2-3]

На стороне сервераТребуетсяпроверить CONNECT зарезервированныефлаги управляющего пакета ( 0 бит) — это признак того, является ли 0，еслиНет

является 0 должендолжен отключить клиентское соединение.

[MQTT-3.1.2-4]

Если флаг Clean Session (CleanSession）установленустановлен в 0, серверТребуетсяна основетекущего сеанса (сделать

Использовать идентификатор клиентаидентификации) состояниевозобновить с клиентомсвязь. Еслине связан с этим идентификатором клиентазнать

сеанс, связанный с идентификатором,На стороне сервераТребуетсясоздатьновый сеанс. ВПосле разрыва соединения, когда соединениеразрыв соединения

После,клиент и серверТребуетсяСохранитьинформацию о сеансе.

[MQTT-3.1.2-5]

Когда флаг clean sessionявляется 0 соединением сеансапосле разрыва соединения,На стороне сервераТребуетсяпосле этого QoS 1 и QoS 2

сохранение сообщений на уровнекак состояние сеансачастью, еслиэти сообщения соответствуютпри отключении, клиентлюбые из клиентских

любая подписка.

[MQTT-3.1.2-6]

Если флаг Clean Session (CleanSession）установленустановлен в 1, клиенти серверТребуетсяперед удалением

любого сеанса и начатьначать новый сеансИными словами, сеанс длится только до тех пор, пока сетьсетевое соединение, в течение такого жевремени.иЭто

состояние, связанное с сеансомДанныене могутпосле любогоповторного использования сеанса.

[MQTT-3.1.2.7]

Сохранённые сообщения не находятся на стороне сервера.состояние сеанса сервераявляется частью, сеанс завершаетсякогдане можетудалить сохранённые сообщениясообщение.

[MQTT-3.1.2-8]

Флаг Will (Will Flag) установлен, что 1указывает, еслиЕсли запрос на подключениепринят, Will (Will

Сообщение）СообщениеТребуетсяхранится насервере и с этой сетьюассоциация сетевого соединения.после закрытия сетевого соединения

при закрытии, серверТребуетсяопубликовать это Will-сообщение, если только серверне получил DISCONNECT при удалении сообщения

за исключением этого Will-сообщениясообщения.

[MQTT-3.1.2-9]

Если флаг Willустановлен в 1, соединениево флаге подключения Will QoS и Will Retain полябудут сервером

используются,в то же времяв полезной нагрузкеТребуетсясодержит Will Topic и WWill-сообщение Поля。

[MQTT-3.1.2-10]

После публикации илисервер получилотправленный клиентом DISCONNECT пакет, Will-сообщениеПростодолжен

нужноиз хранилищаУдалено из сохранённого состояния сессии.

[MQTT-3.1.2-11]

Если флаг Willустановлен в 0，подключениев флаге Will QoS и Will Retain ПоляОбязательноУстановлено в

0, ив полезной нагрузкене можетсодержать Will Topic и WWill-сообщение Поля。

[MQTT-3.1.2-12]

Если флаг Willустановлен в 0, сетькогда сетевое соединение отключено，не можетотправить Will-сообщение。.

[MQTT-3.1.2-13]

Если флаг Willустановлен в 0, оставитьуказать QoS такжеОбязательноУстановите в 0(0x00)。

[MQTT-3.1.2-14]

Если флаг Willустановлен в 1, оставьтеinstruct QoS значениеможет равняться 0(0x00)，1(0x01)，2(0x02)。

его значениене можетравняться 3。

[MQTT-3.1.2-15]

Если флаг Willустановлен в 0, оставьтеwill retain (Will Retain) флаг такжеОбязательноУстановите в 0。

[MQTT-3.1.2-16]

еслиФлаг Will Retain установлен в 0, серверТребуетсяОбрабатывать сообщение Will как не-сохраненное сообщение при публикации。

[MQTT-3.1.2-17]

еслиФлаг will retain установлен в 1, серверТребуетсяобрабатывать сообщение will какОпубликовано как сохраненное сообщение。

[MQTT-3.1.2-18]

если флаг имени пользователя (User Name) установлен в 0, в полезной нагрузкене можетсодержатьсяполе имени пользователя.

[MQTT-3.1.2-19]

если флаг имени пользователя (User Name) установлен в 1, в полезной нагрузкеОбязательносодержитполе имени пользователя.

[MQTT-3.1.2-20]

если флаг пароля (Password)установлен в 0, в полезной нагрузкене можетсодержит поле пароля。

[MQTT-3.1.2-21]

если флаг пароля (Password)установлен в 1, в полезной нагрузкеТребуетсясодержит поле пароля

MQTT-3.1.1-CN 64

[MQTT-3.1.2-22]

Если флаг имени пользователяустановлен в 0, флаг пароля такжеОбязательноУстановить в 0。

[MQTT-3.1.2-23]

Клиент отвечает за то, чтобыпередача управляющего пакетаинтервал времени не превышал keep-aliveзначение keep-alive.Если нет другого

его управляющий пакет можетможет отправить, клиентконецОбязательноотправить PINGREQ message。

[MQTT-3.1.2-24]

Если значение keep aliveне равно нулю, исервер в течение полуторакратноговремени keepaliveне получил от клиента в течение

управляющий пакет клиента,онОбязательноразорвать у клиентасетевое соединение,считатьсетевое соединение ужеразорвано.

[MQTT-3.1.3-1]

если включен,ОбязательноПоявляться в этом порядке: идентификатор клиентаподстановочный знак, тема will, willсообщение,использовать

имя пользователя，Пароль。

[MQTT-3.1.3-2]

Сервер использует клиентскийидентификатор клиента (ClientId) чтобы знатьидентифицировать клиента. Подключиться к серверу.у сервера каждого клиентавсе клиенты имеют уникальные

уникальный идентификатор клиентасимвол (ClientId). Клиент исервер должны обаИспользование ClientId знатьразличать эти два

между MQTT состоянием, связанным с сеансом。

[MQTT-3.1.3-3]

идентификатор клиента (ClientId) ТребуетсяСуществуеткроме тогоТребуетсяДа CONNECT сообщениеПервый в полезной нагрузкеa

Fields。

[MQTT-3.1.3-4]

идентификатор клиентаОбязательноДа 1.5.3 определен в разделе UTF-8 Закодированная строка。

[MQTT-3.1.3-5]

На стороне сервераТребуетсяРазрешено 1 до 23 байт длиной UTF-8 закодированный клиентИдентификатор клиента, клиентидентификатор клиента

может содержать только эти символысимвол:

“0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXY

Z”(прописные буквы, строчные буквы и цифрысимвол).

[MQTT-3.1.3-6]

На стороне сервераДаразрешить клиентуклиент предоставляет нулевой байтбайтовый идентификатор клиентаидентификатор (ClientId) ，если это сделано

завершено,На стороне сервераТребуетсярассматривать это как особый случай иназначить уникальный клиентидентификатор клиента длятому клиенту.но

после этогоТребуетсяпредположить, что клиентКонечная точка предоставляет этот уникальныйидентификатора клиентасимвол,обычныйобработать это CONNECT

message。

[MQTT-3.1.3-7]

если клиентконечная точка предоставляет нулевой байтидентификатора клиентасимвол, онОбязательнотакже очиститфлаг сеанса установленпоместить

является 1。

[MQTT-3.1.3-8]

Если клиент предоставляетиз ClientId равен нулю байти флаг Clean Sessionпомечен как 0, службаконецОбязательноотправить код возврата

является 0x02（Указывает, что идентификатор недействителен) из CONNACK ответный пакетклиента CONNECT отчет

текст,Затем закройте сетевое соединение。

[MQTT-3.1.3-9]

Если сервер отклоняетэтого ClientId，онОбязательноотправить возвраткод как 0x02(таблицауказывает, что идентификатор недействителен

формат) из CONNACK отчетответное сообщениеклиента CONNECT пакет, затемзакройте сетевое соединение。

[MQTT-3.1.3-10]

тема завещанияОбязательноДа 1.5.3 определено в разделе UTF-8 закодированная строка.

[MQTT-3.1.3-11]

Имя пользователяОбязательноДа 1.5.3 определено в разделе UTF-8 кодированная строка。

[MQTT-3.1.4-1]

На стороне сервераОбязательнов соответствии с 3.1 разделомпроверка требований CONNECT пакет,еслипакет не соответствуетспецификации, служба

не отправляет CONNACK сообщениепрямой текстзакрыть сетевое соединение。

[MQTT-3.1.4-2]

если ClientId Таблицауказывает, что клиентуже подключён кэтому серверу,тогда серверОбязательнопричина отключениянекоторые клиенты

соединение.

[MQTT-3.1.4-3]

На стороне сервераОбязательнов соответствии с 3.1.2.4 узлаописывает выполнение очисткипроцесс сеанса.

[MQTT-3.1.4-4]

На стороне сервераОбязательноотправить обратнокод возврата, равный нулю CONNACK пакет как CONNECT пакетаответное подтверждение.

[MQTT-3.1.4-5]

еслисервер отклонил CONNECT, онне можетобрабатывать клиента в CONNECT сообщениеотправить после сообщенияиз

любые данные。

MQTT-3.1.1-CN 65

[MQTT-3.2.0-1]

сервер отправляет CONNACK сообщениеответ, полученный от клиента CONNECT отчётСообщение. Сервер отправляет к

первое клиентскоесообщениеОбязательноДа CONNACK。

[MQTT-3.2.2-1]

Если сервер получаетClean Session (CleanSession）Флагиравно 1 отсоединения, кромебудет CONNACK

Код возврата в пакетеУстановлен в 0 вне, такжеОбязательнобудет CONNACK в пакетенастройка текущей сессии

（Session Present）флаг 0。

[MQTT-3.2.2-2]

Если сервер получаетa CleanSession является 0 изсоединения, текущая сессияЗначение флага сессии принимаетзависит от сервера

сохранил ли он уже ClientId Pairответить клиентусостояние сессии.если сервер уже сохранилсостояние сессии

состояние,оноОбязательнобудет CONNACK сообщатьфлаг текущей сессии в пакетеУстановить в 1。

[MQTT-3.2.2-3]

еслиУ сервера нет сохранённой сессиистатус,этоТребуетсябудет CONNACK в сообщениинастройка текущей сессиипоместить

является 0. Также необходимо CONNACK сообщитькод возврата в тексте установлен в 0。

[MQTT-3.2.2-4]

Если сервер отправляетсодержал не-с нулевым кодом возврата CONNACK пакет,этоТребуетсяпометить текущую сессию как

флаг установлен в 0。

[MQTT-3.2.2-5]

Если сервер отправляетсодержал не-с нулевым кодом возврата CONNACK пакет,тогдаэтоТребуетсязакрыть сеть

соединение。.

[MQTT-3.2.2-6]

Если считать, что приведённая выше таблица 3.1 все соединения в приведённой выше таблице возвращаюткоды возврата не совсем подходятподходят,тогдаНа стороне сервераТребуетсязакрыть сетевое соединение

соединение, не нужно отправлять CONNACK сообщение。

[MQTT-3.3.1-1]

клиент или серверзапрос на повторную отправку PUBLISH когда сообщение,Требуетсябудет DUP меткафлаг установлен в 1。

[MQTT-3.3.1-2]

для QoS 0 сообщения,DUP флагитребуютсяУстановить в 0

[MQTT-3.3.1-3]

сервер отправляет PUBLISH сообщение подписчикукогда,полученоиз (входящего) PUBLISH пакета DUP

значение флага не будетPropagation. Send(outbound) PUBLISH сообщение и получено(inbound)

PUBLISH отчётв сообщении DUP меткафлага независимаустановлено, его значениеТребуетсяотдельнооснование для отправки (out

станции) PUBLISH отчётявляется ли сообщениеповторной передачей, чтобы определить。

[MQTT-3.3.1-4]

PUBLISH сообщениене можетwill QoS разместитьнекоторые биты установлены в 1。еслисервер или клиент получает QoS место

все биты 1 из PUBLISH отчётасообщения, оноТребуетсяЗакрыть сетьсетевое соединение.

[MQTT-3.3.1-5]

Если клиент отправляет всерверный PUBLISH отчёттекстаretain (RETAIN) меткафлаг установлен в 1, обслуживание

серверТребуетсяСохранить это сообщение приложения и его служебныйуровень качества обслуживания (QoS), чтобыего можно распределитьВыдать

соответствие будущему имени темысовпавшему подписчику.

[MQTT-3.3.1-6]

устанавливается новая подпискапри установке для каждогосоответствующего имени темы, еслиСуществуетнедавнеесохранённое сообщение, оноТребуется

отправлено этой подпискечитателю.

[MQTT-3.3.1-7]

Если сервер получаетсохранённую (RETAIN) меткупомеченную как 1 из QoS 0 сообщения,оноТребуетсяперед отбрасыванием

сохранённое для этой темылюбое сообщение.онодолжноэто новое QoS 0 устранитьсообщение как этоновое сохранение темы

сохранить сообщение, но любойв любой моментДарешает отбросить его — еслиЭта ситуация возникает,у этойтемы не будет

имеет сохраненное сообщение。

[MQTT-3.3.1-8]

сервер отправляет PUBLISH пакет клиентукогда, если сообщениеявляется как клиентРезультат новой подписки

отправить, оноТребуетсябудет сообщатьФлаг retain сообщения установлен в 1。

[MQTT-3.3.1-9]

когда PUBLISH отчетсообщение, отправленноеклиенту, — потому что оно соответствуетустановленной подпискепри подписке серверТребуется

Установите флаг retain в 0，независимо отRetain в сообщении, которое он получилзначение флагаменьше.

MQTT-3.1.1-CN 66

[MQTT-3.3.1-10]

флаг retained установлен 1 и полезная нагрузка нулевого размера PUBLISH сообщениеБудет рассматриваться сервером как положительноеобычная обработка сообщений

обработано, оно будет отправленочтобы соответствовать теме подпискиподходящим клиентам. Кроме того,по той же темелюбые существующиесохраненные retained

сообщение должно быть удалено, поэтому эта темалюбые подписчики после темыне получатсохраненное сообщение。

[MQTT-3.3.1-11]

На стороне серверанельзяхранить нулевые по размерусохраненные сообщения。

[MQTT-3.3.1-12]

Если клиент отправляет насерверу PUBLISH сообщениетекстабит флага Retain 0, службаконецне можетхранить это сообщение

информация такжене можетУдалить или заменить любые существующие резервированиясообщение.

[MQTT-3.3.2-1]

имя топикаОбязательноДа PUBLISH отчётпеременный заголовокПервое поле заголовка.этоОбязательноДа 1.5.3 раздел определяетсемантику

UTF-8 кодированная строка.

[MQTT-3.3.2-2]

PUBLISH сообщениеимя темы в сообщениине можетсодержать подстановочные знаки.

[MQTT-3.3.2-3]

Сервер отправляет подписчикуподписывающегося клиента PUBLISH -сообщение сименем темыТребуетсясоответствиетеме подпискиФильтр

(согласно 4.7 сопоставлению, определённому в разделепроцесс).

[MQTT-3.3.4-1]

PUBLISH сообщениеполучатель сообщенияОбязательносогласноСогласно PUBLISH в пакете QoS уровеньотправить ответ, см.

Описание 3.4 таблицы.

[MQTT-3.3.5-1]

На стороне сервераОбязательносообщениеРаспространяется на все соответствующие подпискиназначено QoS клиент верхнего уровняконец.

[MQTT-3.3.5-2]

если сервер реализуетне авторизует определённого клиентаклиент публикует PUBLISH сообщение, у него нетспособа уведомить об этомклиент

конец.этоТребуетсяв соответствии с обычными QoS правиламиОтправить положительное подтверждениеподтверждение, илиЗакрыть сетевое соединение.

[MQTT-3.6.1-1]

PUBREL управляющийфиксированный заголовок управляющего пакетапервый бит заголовка 3,2,1,0 равензарезервированный бит,Требуетсяустановлен в 0,0,1,0. служба

серверТребуетсяРассматривать любые другие значения как недопустимые и закрытьсетевое соединение.

[MQTT-3.8.1-1]

SUBSCRIBE управляющийфиксированный заголовок управляющего сообщенияв фиксированном заголовке 3,2,1,0 бит зарезервированбит,Требуетсясоответственно установлен в 0,0,1,0。

На стороне сервераТребуетсядругоеЛюбое значение рассматривается какнедопустимое и закрытьзакрыть сетевое соединение.

[MQTT-3.8.3-1]

SUBSCRIBE отчётсообщение: допустимыйфильтр тем в полезной нагрузкеСписокТребуетсяДа 1.5.3 разделопределен UTF-8 Символ

string。

[MQTT-3.8.3-2]

если сервер выбираетне поддерживает содержащие подстановочные знакифильтр темы с подстановочными знаками,Обязательноотклонить любойфильтр, содержащий подстановочные знакиfilter

запрос на подписку фильтра。

[MQTT-3.8.3-3]

SUBSCRIBE отчетсообщенияполезная нагрузкаОбязательносодержит как минимум одиндля фильтра темы и QoS уровеньгруппа полей

совпадает. Нет полезной нагрузкиполезной нагрузки SUBSCRIBE сообщениеявляется нарушением протокола。

[MQTT-3-8.3-4]

если в полезной нагрузкелюбой бит ... имеет не-нулевое значение, или QoS Не равно 0,1 или 2，На стороне сервераОбязательноучитывать

SUBSCRIBE отчётноесообщение недействительно и закрыть сетевое соединениеподключиться.

[MQTT-3.8.4-1]

сервер получает клиентскийэкземпляр, отправленный конечной точкой SUBSCRIBE когда сообщение,ОбязательноИспользование SUBACK ответный пакет

ответ.

[MQTT-3.8.4-2]

SUBACK сообщениеТребуетсяи ожидание подтверждения SUBSCRIBE сообщениеимеют одинаковыйидентификатор пакета сообщения.

[MQTT-3.8.4-3]

Если сервер получаетa SUBSCRIBE пакет, пакетФильтр темы и тему существующейподписки

фильтр темы совпадает,тогдаНеобходимоиспользовать новую подпискуподписка полностью заменяет существующиесохранённые подписки. Новая подпискафильтр темы

фильтр и ранее подписанныйсовпадают, но у негомаксимальные QoS значения могут быть разными.с этим фильтром темысовпадающих с фильтром

любое существующее сохранённоеСообщениеНеобходимопередать повторно,Нопоток публикациине можетпрерываться.

[MQTT-3.8.4-4]

Если сервер получаетсодержащий несколько темфильтра SUBSCRIBE пакет,онНеобходимокак если бы было получено

серию из нескольких SUBSCRIBE сообщенийобрабатывать одинаково, за исключением того, что необходимообъединить их ответы в одинitems

отдельное SUBACK отчётноесообщение об отправке.

MQTT-3.1.1-CN 67

[MQTT-3.8.4-5]

сервер отправляет клиентуклиента SUBACK пару сообщенийдля каждой пары фильтров темустройство и QoS ожидатьвсе уровниНеобходимоПакет

содержит код возврата.этот код возвратаОбязательноуказывает, что подписка предоставленамаксимальный QoS уровень,или обозначает

эта подписка не удалась。

[MQTT-3.8.4-6]

сервер может предоставить,чем требует подписчик,более низкий QoS уровень. В ответ на подпискусообщение, отправленное по подпискеинформация

полезной нагрузки QoS ОбязательноДаисходного publish-сообщенияинформация QoS ипредоставленный сервером QoS двухнаименьший среди

значение. Если исходное сообщениеинформация QoS Да 1 и предоставленомаксимальный QoS Да 0, позволяя серверу повторноотправить

копию сообщенияПодписчику.

[MQTT-3.9.3-1]

порядок кодов возвратаОбязательнои SUBSCRIBE сообщениев фильтре темпорядок сервера тот же。

[MQTT-3.9.3-2]

0x00, 0x01, 0x02, 0x80 извнешних SUBACK коды возврата зарезервированыиз,нельзяиспользовать.

[MQTT-3.10.1-1]

UNSUBSCRIBE пакетфиксированный текстфиксированного заголовка 3,2,1,0 бит должен быть сохранен.Зарезервированный бит иТребуетсяустанавливать отдельноэто

0,0,1,0. службасерверТребуетсярассматривать любые другиезначения все недопустимыи закрыть сетевое соединениесоединение.

[MQTT-3.10.3-1]

UNSUBSCRIBE сообщениев текстефильтр темТребуетсядолжен быть непрерывно упакован, согласно 1.5.3 разделуопределённому

UTF-8 кодированная строка.

[MQTT-3.10.3-2]

UNSUBSCRIBE сообщениетекстполезная нагрузкаТребуетсякак минимум включатьсодержит фильтрсообщения. Нетполезной нагрузки

UNSUBSCRIBE сообщениетекстнарушает протокол。

[MQTT-3.10.4-1]

UNSUBSCRIBE отчёттекст упоминаетпредоставленный фильтр тем (независимо от того, содержит ли онподстановочный знак）Требуетсяс сервером поддерживать

клиент, у которого есть этотекущая темасравнивает набор фильтров посимвольносравнение. Если какой-либокакой-либо фильтр полностью совпадает

совпадает,Тогда он (сервер)его собственная подписка будет удалена, иначе не будетдальнейшей обработки。

[MQTT-3.10.4-2]

Если сервер удаляетподписку,онДолженпрекратить доставку любых новыхсообщений этомуКлиенту.

[MQTT-3.10.4-3]

Если сервер удаляетподписку,онДолжензавершить доставку любых ужеуже начатых клиентуотправленных клиенту QoS

1 и QoS 2 сообщения。

[MQTT-3.10.4-4]

Серверная сторонаДолжнаотправить UNSUBACK ответноесообщениеклиентского UNSUBSCRIBE запроса.

UNSUBACK сообщениеДолжносодержать и UNSUBSCRIBE сообщениетот же Packetidentifier.

[MQTT-3.10.4-5]

даже еслине удалил никаких подписок на темы,Серверная сторонатакжеДолжнаотправить SUBACK ответ。

[MQTT-3.10.4-6]

Если сервер получаетсодержащий несколько темфильтра UNSUBSCRIBE пакет,онТребуетсякак если бы получено

серия из нескольких UNSUBSCRIBE отчётовтак же, как сообщениеобрабатывает этот пакет,за исключением ихобъединить ответ в

отдельное UNSUBACK сообщениеснаружи.

[MQTT-3.12.4-1]

На стороне сервераТребуетсяотправить PINGRESP пакет в ответ наклиентское PINGREQ сообщение。

[MQTT-3.14.1-1]

На стороне сервераОбязательнопроверить всеВсе зарезервированные биты установленыустановлены в 0, еслиони не 0 Обязательноразорватьсоединение.

[MQTT-3.14.4-1]

клиент отправляет DISCONNECT сообщитьпосле сообщения,Обязательнозакрыть сетьсоединение.

[MQTT-3.14.4-2]

клиент отправляет DISCONNECT отчётпосле сообщения,не можетчерез этосетевое соединение затемотправлять любой управляющий пакет

text.

[MQTT-3.14.4-3]

сервер получает DISCONNECT отчёткогда сообщение,Требуетсяотбросить любой сНеподтверждённые сообщения, связанные с текущим соединениемпубликуемое завещание

сообщение о завещании, в частности описывающееописанное в 3.1.2.5 разделе.

[MQTT-4.1.0-1]

в течение всего сеанса, клиент и сервервсе серверыТребуетсяхранить состояние сеансасостояние.

[MQTT-4.1.0-2]

СеансТребуетсяДлится как минимум столько же, сколько его активное сетевое соединениеподключается в течение той же длительностипространство.

MQTT-3.1.1-CN 68

[MQTT-4.3.1-1]

для QoS 0 изпротокола доставки, отправительотправительТребуетсяотправить QoS равно 0，DUP равно 0 из⟦⟧PUBLISH PUBLISH

message。

[MQTT-4.3.2-1]

для QoS 1 протоколараспространения,отправитель

 ДОЛЖЕН отправить PUBLISH Packet, содержащий этот Packet Identifier с

QoS=1, DUP=0.

 отправленное PUBLISH сообщениедолжносодержатьидентификатор пакета и QoS равно 1，DUP равно

0。

 Необходимоэто PUBLISH сообщениерассматривать как

неподтвержденное

，покаполучает соответствующий пакет от получателя

из PUBACK пакета.4.4 байт имеетодин о неподтверждённомобсуждение сообщений.

[MQTT-4.3.2-2]

для QoS 1 изпротокола доставки, получательполучатель

 ответ PUBACK сообщениеОбязательносодержитидентификаторы сообщений,этот идентификатор берётся изпри получении

из,Что приняло владение PUBLISH пакет.

 отправил PUBACK отчётпосле сообщения,получатель долженлюбой, содержащий тот же идентификатор пакетазапись идентификатора

станция PUBLISH сообщениекак новоесообщение, и игнорировать его DUP Флагизначение.

[MQTT-4.3.3-1]

для QoS 2 ofпротокола доставки, отправительотправитель

 ДОЛЖЕН отправить PUBLISH пакет, содержащий этот Packet Identifier с

QoS=2, DUP=0.

 отправлено PUBLISH сообщениеТребуетсясодержит идентификатор пакета и пакетиз QoS равно 2,，DUP

equals 0。

 Необходимоэто PUBLISH сообщениерассматривать как

неподтвержденное

，покаполучает соответствующий пакет от получателя

из PUBREC пакета.4.4 разделЕсть сообщение о неподтвержденномобсуждение сообщений.

 получен PUBREC после сообщенияТребуетсяотправить PUBREL пакет.PUBREL пакет должен

Содержит исходный PUBLISH то же сообщение, что и сообщениеИдентификатор пакета.

 ДОЛЖЕН рассматривать PUBREL-пакет как «неподтвержденный», пока не

получил соответствующийPUBCOMP пакет от получателя.

 Требуетсяэто PUBREL отчётноесообщение рассматривается как

неподтвержденное

，покане получит соответствующий от получателя

PUBCOMP пакет.

 как только соответствующий ... был отправлендля PUBREL сообщения, тонельзяповторно отправить это PUBLISH пакет.

[MQTT-4.3.3-2]

дляQoS 2протокола доставки, принимающеелицо

 ответ PUBREC сообщениеТребуетсяСодержит идентификатор пакета, которыйидентификатор из полученного пакета、

ужепринимая владение PUBLISH пакетом.

 После получения соответствующего PUBREL перед сообщением,получательдолженотправить PUBREC отчётподтверждениеобязанность

любой последующий, имеющий тот жес тем же идентификатором PUBLISH пакет. В этом случаениже, онне можетповториться

доставлять сообщения любымпоследующим получателям。

 ответ PUBREL пакета PUBCOMP сообщениеТребуемыйсодержащий и PUBREL отчёттакой же, как сообщение

идентификатор.

 отправить PUBCOMP отчеттекстапосле, получательдолжен включить тот желюбой с тем же идентификатором сообщенияпосле

продолжить PUBLISH сообщениекак новуюпубликацию.

MQTT-3.1.1-CN 69

[MQTT-4.4.0-1]

клиент устанавливает флаг Clean Startсессия (CleanSession) меткапомечена как 0 переподключитьсякогда, клиенти серверТребуетсясделать

используя исходный идентификатор пакетаидентификатор повторно отправляет любоенеподтверждённое PUBLISH сообщение (если QoS>0) и

PUBREL сообщение。

[MQTT-4.5.0-1]

Сервер берёт на себя входящеевладение прикладным сообщениемкогда авторизован, онТребуетсясообщениедобавить в подпискусоответствующий клиентиз

в состоянии сессии.совпадениеСм. определение правила 4.7 раздел.

[MQTT-4.5.0-2]

клиентТребуетсяв соответствии с возможнымиспользуемым качеством обслуживания (QoS) подтверждение правилалюбой получаемый им PUBLISH пакет,

независимоОн выбирает, обрабатывать ли пакеты, содержащиесообщение приложения。

[MQTT-4.6.0-1]

Повторно отправить любой предыдущий PUBLISH отчеткогда сообщение,Требуетсяв соответствии с исходным PUBLISH сообщениеповторно передавать в порядке отправки

(применяется к QoS 1 и QoS 2 сообщению）。

[MQTT-4.6.0-2]

Требуетсяв соответствии с соответствующим PUBLISH Отправлять пакеты по порядку PUBACK отчеттекст (QoS 1 сообщение）。

[MQTT-4.6.0-3]

Требуетсяв соответствии с соответствующим PUBLISH отправлять пакеты в порядке PUBREC отчёттекст (QoS 2 сообщение）。

[MQTT-4.6.0-4]

Требуетсяв соответствии с соответствующим PUBREC порядком пакетовпоследовательно отправлять PUBREL сообщение (QoS 2 Сообщение）。

[MQTT-4.6.0-5]

На стороне сервераТребуетсяпо умолчаниюДля каждой темы существуетпорядок. ЭтоДапредоставлятьфункцию управления илидругой машине

механизм, чтобыРазрешеноОдна или несколько темрассматриваются какнеупорядоченные。

[MQTT-4.6.0-6]

Сервер обрабатывает отправкув упорядоченные темыкогда сообщение,Требуетсякак указано вышеправила будут отправлять сообщениесообщение, распределяемое каждойподписке

читатель.Кроме того, этоТребуетсяв соответствии с тем, что получено от клиентаотправлять в порядке получения PUBLISH сообщениепотребителю (для соответствующего

тот же топик и QoS）。

[MQTT-4.7.1-1]

Фильтр топиков можетиспользовать подстановочные знаки, но имена топиковне могутИспользованиеПодстановочный знак.

[MQTT-4.7.1-2]

многоуровневый подстановочный знак долженрасполагаться на своем собственномуровне или следовать за уровнем топикапосле разделителя уровней. Независимо от ситуации

условие,оно всеТребуетсяявляется последним уровнем фильтра топиковсимволы。

[MQTT-4.7.1-3]

В фильтре топиковлюбой уровень можетможет использовать одноуровневый подстановочный знак,включаяпервый и последнийуровень.

однакоонТребуетсязанимает весь уровень фильтра。

[MQTT-4.7.2-1]

На стороне серверане можетбудет $ Имя топика совпадать, начиная с символасовпадать с подстановочным знаком (#или+) открытьфильтр топиков в началеустройства.

[MQTT-4.7.3-1]

все имена тем иФильтр темОбязательноДолжен содержать как минимум один символ.

[MQTT-4.7.3-2]

имя темы и фильтр темфильтрне можетсодержать нулевой символ (Unicode U+0000) [Unicode] 。

[MQTT-4.7.3-3]

имя темы и фильтр темыфильтр является UTF-8 закодированной строкой, онине могутПревышено 65535 байт。

[MQTT-4.7.3-4]

при сопоставлении подписок серверсерверне можетдля имени темы илифильтр темы выполняетвыполнять какую-либо нормализацию

（нормализация）обработка,Невозможно изменить или заменить любойлюбой нераспознанный символсимвол.

[MQTT-4.8.0-1]

Если не указано иное,Если сервер илиКлиент столкнулсяс поведением, нарушающим протокол,этоТребуетсяотключить передачу этого

нарушение протокола, управляющеесетевым соединением пакетаподключить.

[MQTT-4.8.0-2]

Сеть управляющих сообщенийсоединение.

[MQTT-6.0.0-1]

MQTT управляющий пакетОбязательноИспользование WebSocket двоичное числоКадр данных отправлен. Еслиполучен любой другойТип

Кадр данных, полученлицомОбязательнозакрыть сетевое соединение。

[MQTT-6.0.0-2]

один WebSocket номерКадр данных может содержать несколькоодин или часть MQTT Пакет. Получательне можетПредположить

MQTT Управляющие сообщения в соответствии с WebSocket выравниванием границ кадров。

MQTT-3.1.1-CN 70

[MQTT-6.0.0-3]

клиентТребуетсясимвольнаястрока mqtt содержащаяся в немпредоставленный WebSocket суб-протоколв списке протоколов.

[MQTT-6.0.0-4]

Сервер выбирает и возвращаетвозвращенный WebSocket суб-протоколимя протоколаТребуетсяДа mqtt

[MQTT-7.0.0-1]

MQTT Реализация может одновременно быть MQTT клиентом и MQTT серверной стороной. Принимать входящиеПодключение сайта и установление соединения с его

Его серверный исходящийподключенный сервердолжен одновременно удовлетворять MQTT клиента и MQTT требованию серверной стороны

запрос.

[MQTT-7.0.0-2]

Чтобы с любой другойсоответствующей реализациейвзаимодействовать,соответствующая реализация не можетбыть обязана использовать в этомвне спецификации

Любое определённое расширение。

[MQTT-7.1.1-1]

упорядоченный, можетНадёжный двунаправленный поток байтов (От клиента к серверуНа стороне сервера и от сервера к клиентуклиент)

[MQTT-7.1.2-1]