Портал docs.cntd.ru скоро обновится, чтобы стать еще лучше и удобнее.
Попробовать новую версию
  • Текст документа
  • Статус
Оглавление
Поиск в тексте
Действующий

ГОСТ Р 58603-2019 (ИСО/МЭК 20922:2016)


НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ


Информационные технологии

ИНТЕРНЕТ ВЕЩЕЙ

Протокол организации очередей доставки телеметрических сообщений MQTT. Версия 3.1.1

Information technology. Internet of things. Message Queuing Telemetry Transport (MQTT) v3.1.1


ОКС 35.100.70

Дата введения 2021-01-01


Предисловие

1 ПОДГОТОВЛЕН Акционерным обществом "Всероссийский научно-исследовательский институт сертификации" (АО "ВНИИС") и Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр" (ООО ИАВЦ) на основе собственного перевода на русский язык англоязычной версии документа, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 022 "Информационные технологии"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 16 октября 2019 г. N 1005-ст

4 Настоящий стандарт является модифицированным по отношению к международному стандарту ИСО/МЭК 20922:2016* "Информационные технологии. Протокол организации очередей доставки телеметрических сообщений MQTT. v3.1.1" (ISO/IEC 20922:2016 "Information technology - Message Queuing Telemetry Transport (MQTT) v3.1.1", MOD) путем изменения его структуры для приведения в соответствие с правилами, установленными в ГОСТ 1.5 (подразделы 4.2 и 4.3). Сравнение структуры настоящего стандарта со структурой указанного международного стандарта приведено в дополнительном приложении Д
________________
* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - Примечание изготовителя базы данных.

5 ВВЕДЕН ВПЕРВЫЕ

6 Некоторые положения международного стандарта, указанного в пункте 4, могут являться объектом патентных прав. ИСО и МЭК не несут ответственности за идентификацию подобных патентных прав

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение


MQTT - клиент-серверный протокол передачи сообщений, основанный на модели "издатель - подписчик". Он является легким, открытым, простым, и спроектирован таким образом, чтобы его легко можно было реализовать. Данные характеристики делают его идеальным для использования во многих ситуациях, в том числе в ограниченных средах, например, для организации связи в среде межмашинного взаимодействия (М2М) и Интернета вещей (lоТ), где требуется небольшой размер кода и/или пропускная способность сети является приоритетом.

Протокол выполняется с использованием протоколов из набора TCP/IP или через другие сетевые протоколы, которые обеспечивают упорядоченные двунаправленные соединения без потерь. Его функции включают:

а) использование шаблона проектирования "издатель - подписчик", который обеспечивает распределение сообщений по принципу "один ко многим";

б) доставка сообщений, не зависящая от содержимого информационного наполнения;

в) три уровня качества услуги (QoS) передачи данных:

- "Не более одного раза", когда сообщения доставляются в соответствии с оптимальными затратами операционной среды. Может произойти потеря сообщений. Данный уровень может использоваться, например, для передачи данных датчика температуры окружающей среды, где потеря отдельного измерения не имеет значения, поскольку вскоре после этого будет опубликовано следующее измерение;

- "Не реже одного раза", в этом случае гарантируется доставка сообщений, но возможны дубликаты;

- "Ровно один раз", в этом случае гарантируется доставка сообщений ровно один раз. Данный уровень может использоваться, например, в биллинговых системах, где дублирующиеся или потерянные сообщения могут приводить к применению неправильных сборов;

г) малый объем служебного трафика и протокольные обмены сводятся к минимуму для снижения сетевого трафика;

д) механизм уведомления заинтересованных сторон в случае аварийного разрыва связи.

1 Область применения


Настоящий стандарт определяет требования к разработке Клиента MQTT и реализации Сервера MQTT.

Обязательные нормативные положения настоящего стандарта, составляющие требования к реализации протокола MQTT, отмечены специальными обозначениями, сформированными по шаблону [MQTT-x.x.x-y] (см. раздел 3), и размещенными сразу после соответствующего нормативного положения. Полный перечень обязательных нормативных положений справочно представлен в приложении Б.

Степень значимости отдельных требований и положений настоящего стандарта обозначаются специальными терминами, приведенными в подразделе 2.1 настоящего стандарта.

Критерии оценки соответствия реализации Клиента MQTT или Сервера MQTT требованиям настоящего стандарта, приведеные в разделе 9 настоящего стандарта.

2 Термины и определения


В настоящем стандарте применены следующие термины с соответствующими определениями.

2.1 Ключевые слова "ДОЛЖЕН", "НЕ ДОЛЖЕН", "ТРЕБУЕТСЯ", "БУДЕТ", "НЕ БУДЕТ", "СЛЕДУЕТ", "НЕ СЛЕДУЕТ", "РЕКОМЕНДУЕТСЯ", "МОЖЕТ" и "ОПЦИОНАЛЬНО" в настоящей Спецификации интерпретируются, как описано в IETF RFC (рабочем предложении инженерной рабочей группы Интернета) 2119 [1], следующим образом:

2.1.1 ДОЛЖЕН (MUST), а также термины "требуется" (REQUIRED) и "нужно" (SHALL) используется для требований, которые являются абсолютно необходимыми в данной спецификации.

2.1.2 НЕ ДОЛЖЕН (MUST NOT) или слова SHALL NOT (не позволяется) означают абсолютный запрет в рамках спецификации.

2.1.3 СЛЕДУЕТ (SHOULD), а также глагол рекомендуется (RECOMMENDED) используется для обозначения требований, от выполнения которых можно отказаться при наличии разумных причин. Однако при таком отказе следует помнить о возможных проблемах в результате отказа и принимать взвешенное решение.

2.1.4 НЕ СЛЕДУЕТ (SHOULD NOT) и глагол не рекомендуется (NOT RECOMMENDED) используются применительно к особенностям или функциям, которые допустимы и могут быть полезными, но могут вызывать проблемы. При реализации таких опций следует учитывать возможность возникновения проблем и принимать взвешенное решение.

2.1.5 МОЖЕТ (MAY), а также прилагательное необязательный (OPTIONAL) обозначают элементы, реализация которых является необязательной. Одни разработчики могут включать такие опции в свою продукцию для расширения возможностей, а другие - опускать в целях упрощения. Реализация, не включающая ту или иную опцию, должна быть готова к работе с реализациями, которые используют эту опцию (возможно совместная работа будет обеспечиваться за счет некоторого ущерба функциональности). Включающие опцию реализации должны быть готовы (естественно, без использования такой опции) к взаимодействию с реализациями, которые такую опцию не поддерживают.

2.2 сетевое соединение (network connection): Структура, предоставляемая базовым транспортным протоколом, который используется MQTT.

- подключает Клиента к Серверу;

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

Примечание - Примеры приведены в подразделе 7.2.

2.3 сообщение приложения (application message): Данные, передаваемые протоколом MQTT по сети для приложения. При передаче сообщений с использованием протокола MQTT обеспечивается соответствующий уровень качества услуг передачи данных и указывается название темы.

2.4 клиент (client): Программа или устройство, использующее MQTT. Клиент всегда устанавливает сетевое подключение к Серверу. Клиент может:

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

- выполнить подписку для запроса сообщений приложения, в получении которых Клиент заинтересован;

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

- отключиться от Сервера.

2.5 сервер (server): Программа или устройство, которое выступает в качестве посредника между Клиентами, которые публикуют сообщения приложений, и Клиентами, которые выполнили Подписки. Сервер может:

- принимать сетевые подключения от Клиентов;

- принимать сообщения приложений, публикуемые Клиентами;

- обрабатывать запросы на подписку и отмену подписки от Клиентов;

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

2.6 подписка (subscription): Подписка включает фильтр по темам и максимальный уровень качества услуг передачи данных. Подписка связана с одним Сеансом. Сеанс может включать несколько Подписок. Каждая Подписка в рамках Сеанса имеет различные фильтры по темам.

2.7 название темы (topic name): Метка, прикрепленная к сообщению приложения, сопоставляемая с Подписками, известными Серверу. Сервер отправляет копию сообщения приложения каждому Клиенту, имеющему соответствующую Подписку.

2.8 фильтр по темам (topic filter): Выражение, содержащееся в подписке, определяющее интерес к сообщениям одной или нескольких тем. Фильтр темы может содержать подстановочные знаки.

2.9 сеанс (session): Межсетевое взаимодействие между Клиентом и Сервером с сохранением состояния. Некоторые Сеансы продолжаются только во время сетевого соединения, другие могут охватывать несколько последовательных сетевых соединений между Клиентом и Сервером.

2.10 управляющий пакет MQTT (MQTT control packet): Пакет информации, который отправляется через Сетевое подключение. Спецификация MQTT определяет четырнадцать различных типов управляющих пакетов, один из которых (пакет PUBLISH /ОПУБЛИКОВАТЬ/) используется для передачи сообщений приложений.

2.11 последняя воля (will): Механизм протокола MQTT, включающий специальное сообщение приложения и набор характеризующих его параметров, предназначенный для обработки ситуаций аварийного разрыва соединения между Клиентом и Сервером, которые могут возникать при:

- ошибках ввода/вывода и отказов сети, обнаруженных Сервером;

- превышениях времени ожидания Клиентом;

- ошибках соблюдения протокола.

3 Обозначения и сокращения

3.1 Обозначения

3.1.1 [MQTT-x.x.x-y]: Обозначает положения настоящего стандарта, обязательные с точки зрения требований к протоколу MQTT, где х.х.х - номер раздела, у - порядковый номер положения в рамках раздела. Обозначение размещается непосредственно после первого появления соответствующего положения в тексте настоящего стандарта.

3.1.2 U+XXXX: Обозначает номер символа в кодировке UTF-8, где X - символ числа в 16-м исчислении (от 0 до F).

3.2 Сокращения


MQTT Клиент-серверный протокол передачи сообщений, основанный на модели "издатель - подписчик"

UTF-8

Формат преобразования Юникода, 8-бит

ASCII

7-битный кодированный набор символов

QoS

Качество предоставляемых услуг

TCP/IP

Набop сетевых протоколов передачи данных

UDP

Протокол пользовательских датаграмм

TLS

Протокол защиты транспортного уровня

IANA

Администрация адресного пространства Интернет

SSL

Уровень защищенных сокетов


4 Представление данных

4.1 Бит


Биты в байте обозначены с 7 по 0. Бит номер 7 является самым значимым битом, наименее значащему биту присваивается номер 0.

4.2 Целочисленные значения данных


Целочисленные значения данных составляют 16 бит в обратном порядке байтов: старший байт предшествует младшему байту.

Это означает, что 16-битное слово представлено в сети как наиболее значащий байт (MSB), за которым следует наименее значащий байт (LSB).

4.3 Закодированные строки UTF-8


Текстовые поля в управляющих пакетах, описанных ниже, кодируются как строки UTF-8. UTF-8 [2] - эффективный метод кодирования символов Unicode [5], который оптимизирует кодовую таблицу ASCII для поддержки обмена текстовыми сообщениями.

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

Если не указано иное, все кодированные строки UTF-8 могут иметь любую длину в диапазоне от 0 до 65535 байт.

Таблица 1 - Структура кодированных строк UTF-8

Бит

7

6

5

4

3

2

1

0

Байт 1

Длина строки MSB

Байт 2

Длина строки LSB

Байт 3...

Данные закодированного символа UTF-8, если длина >0


Символьные данные в кодированной строке UTF-8 ДОЛЖНЫ быть правильно сформированы, как определено спецификацией Unicode [5] и подтверждено в RFC 3629 [2]. В частности, эти данные НЕ ДОЛЖНЫ включать кодовые точки между U+D800 и U+DFFF. Если Сервер или Клиент получает управляющий пакет, содержащий неправильно сформированный UTF-8, он ДОЛЖЕН прервать сетевое подключение [MQTT-4.5.3-1].

Закодированная строка UTF-8 НЕ ДОЛЖНА включать кодировку нулевого символа U+0000. Если получатель (Сервер или Клиент) получает управляющий пакет, содержащий U+0000, он ДОЛЖЕН прервать сетевое соединение [MQTT-4.5.3-2].

В данные НЕ СЛЕДУЕТ включать кодовые пункты Unicode [5], перечисленные ниже. Если получатель (Сервер или Клиент) получает управляющий пакет, содержащий любой из них, он МОЖЕТ прервать сетевое соединение:

- управляющие символы U+0001..U+001F;

- управляющие символы U+007F..U+009F;

- кодовые точки, которые согласно спецификации Unicode [5] не являются символами (например, U+0FFFF).

Кодированная UTF-8 последовательность 0xEF 0хВВ 0xBF всегда должна интерпретироваться как U+FEFF ("НЕРАЗРЫВНЫЙ ПРОБЕЛ С НУЛЕВОЙ ШИРИНОЙ"), где бы она ни появлялась в строке, и НЕ ДОЛЖНА быть пропущена или удалена получателем пакета [MQTT-1.5.3-3].

Пример - Строка А, которая представлена ЗАГЛАВНОЙ ЛАТИНСКОЙ БУКВОЙ А, за которой следует кодовая точка U+2A6D4 (представляющей ИДЕОГРАФИЧЕСКОЕ РАСШИРЕНИЕ CJK символ В), кодируется следующим образом, приведенным в таблице 2.

Таблица 2 - Пример строки в кодировке UTF-8

Бит

7

6

5

4

3

2

1

0

Байт 1

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

0

0

0

0

0

0

0

0

Байт 2

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

0

0

0

0

0

1

0

1

Байт 3

'А' (0x41)

0

1

0

0

0

0

0

1

Байт 4

(0xF0)

1

1

1

1

0

0

0

0

Байт 5

(0хАА)

1

0

1

0

1

0

1

0

Байт 6

(0x9В)

1

0

0

1

1

0

1

1

Байт 7

(0x94)

1

0

0

1

0

1

0

0


5 Формат управляющего пакета MQTT

5.1 Структура управляющего пакета MQTT


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

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

Таблица 3 - Структура управляющего пакета MQTT

N

Части управляющего пакета MQTT

1

Фиксированный заголовок, присутствующий во всех пакетах управления MQTT

2

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

3

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


5.2 Фиксированный заголовок


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

Таблица 4 - Фиксированный формат заголовка

Бит

7

6

5

4

3

2

1

0

Байт 1

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

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

Байт 2...

Остаток байтов

5.2.1 Тип управляющего пакета MQTT

Позиция: байт 1, биты 7-4.

Значения, представленные в виде 4-разрядной величины без знака, приведены в таблице 5.

Таблица 5 - Типы управляющих пакетов

Название

Значение

Направление потока

Описание

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

0

Запрещено

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

CONNECT

1

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

Запрос Клиента на подключение к Серверу

CONNACK

2

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

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

PUBLISH

3

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

Опубликовать сообщение

PUBACK

4

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

Подтверждение публикации

PUBREC

5

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

Получение публикации (часть 1 механизма гарантированной поставки)

PUBREL

6

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

Сообщение для публикации отправлено (часть 2 механизма гарантированной поставки

PUBCOMP

7

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

Публикация сообщения окончена (часть 3 механизма гарантированной поставки)

SUBSCRIBE

8

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

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

SUBACK

9

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

Подтверждение подписки

UNSUBSCRIBE

10

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

Запрос об отказе от подписки

UNSUBACK

11

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

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

PINGREQ

12

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

Запрос PING

PINGRESP

13

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

Ответ PING

DISCONNECT

14

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

Сообщение об отключении Клиента

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

15

Запрещено

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

5.2.2 Флаги

Остальные биты [3-0] байта 1 в фиксированном заголовке содержат флаги, специфичные для каждого типа управляющего пакета MQTT, как приведено в таблице 6. Если в таблице 6 бит флага отмечен, как "Зарезервировано", то он зарезервирован для будущего использования и ДОЛЖЕН быть установлен в значение, указанное в данной таблице [MQTT-5.2.2-1]. Если полученный пакет содержит неверные флаги, получатель ДОЛЖЕН прервать сетевое соединение [MQTT-5.2.2-2]. Более подробная информация об обработке ошибок приведена в подразделе 7.8.

Таблица 6 - Биты флагов

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

Фиксированные флаги заголовков

Бит 3

Бит 2

Бит 1

Бит 0

CONNECT

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

0

0

0

0

CONNACK

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

0

0

0

0

PUBLISH

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

DUPГОСТ Р 58603-2019 (ИСО/МЭК 20922:2016) Информационные технологии (ИТ). Интернет вещей. Протокол организации очередей доставки телеметрических сообщений MQTT. Версия 3.1.1

QoSГОСТ Р 58603-2019 (ИСО/МЭК 20922:2016) Информационные технологии (ИТ). Интернет вещей. Протокол организации очередей доставки телеметрических сообщений MQTT. Версия 3.1.1

QoSГОСТ Р 58603-2019 (ИСО/МЭК 20922:2016) Информационные технологии (ИТ). Интернет вещей. Протокол организации очередей доставки телеметрических сообщений MQTT. Версия 3.1.1

RETAINГОСТ Р 58603-2019 (ИСО/МЭК 20922:2016) Информационные технологии (ИТ). Интернет вещей. Протокол организации очередей доставки телеметрических сообщений MQTT. Версия 3.1.1

PUBACK

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

0

0

0

0

PUBREC

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

0

0

0

0

PUBREL

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

0

0

1

0

PUBCOMP

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

0

0

0

0

SUBSCRIBE

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

0

0

1

0

SUBACK

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

0

0

0

0

UNSUBSCRIBE

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

0

0

1

0

UNSUBACK

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

0

0

0

0

PINGREQ

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

0

0

0

0

PINGRESP

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

0

0

0

0

DISCONNECT

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

0

0

0

0

______________
DUPГОСТ Р 58603-2019 (ИСО/МЭК 20922:2016) Информационные технологии (ИТ). Интернет вещей. Протокол организации очередей доставки телеметрических сообщений MQTT. Версия 3.1.1 = Повторная доставка управляющего пакета PUBLISH

QoSГОСТ Р 58603-2019 (ИСО/МЭК 20922:2016) Информационные технологии (ИТ). Интернет вещей. Протокол организации очередей доставки телеметрических сообщений MQTT. Версия 3.1.1 = Качество услуги передачи PUBLISH

RETAINГОСТ Р 58603-2019 (ИСО/МЭК 20922:2016) Информационные технологии (ИТ). Интернет вещей. Протокол организации очередей доставки телеметрических сообщений MQTT. Версия 3.1.1 = Флаг сохранения пакета PUBLISH

В пункте 6.3.1 приведено описание DUP, QoS и RETAIN в составе управляющего пакета PUBLISH.

5.2.3 Остаток байтов

Позиция: начинается с байта 2.

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

Число оставшихся в данном пакете байтов кодируется с использованием схемы кодирования с переменной длиной, которая использует один байт для значений до 127. Более крупные величины обрабатываются следующим образом. Наименее значимые семь бит каждого байта кодируют данные, а самый старший бит используется для указания, что в представлении присутствуют следующие байты. Таким образом, каждый байт кодирует 128 значений и "бит продолжения". Максимальное количество байтов в поле "Остаток байтов" равно четырем.

Пример - Десятичное число 64 кодируется как один байт, десятичное значение 64, шестнадцатеричное 0x40. Десятичное число 321 (= 65+2*128) кодируется как два байта, наименее значимые указываются первыми. Первый байт равен 65+128=193. Обратите внимание, что верхний бит установлен для указания хотя бы одного следующего байта. Второй байт равен 2.

Примечание - Кодирование остатка байтов позволяет приложениям отправлять управляющие пакеты размером до 268435455 (256 МБ). Представление этого числа в закодированном виде: 0xFF, 0xFF, 0xFF, 0x7F.

В таблице 7 приведены значения остатка байтов, представленные в порядке возрастания числа байтов.

Таблица 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)


Примечания

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

- ввод

- encodedByte = X MOD 128

- Х = Х DIV 128

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

- если (X>0)

- encodedByte = encodedByte ИЛИ 128

- endif

- 'output' encodedByte

- когда (X>0)

если MOD является оператором modulo (% in С), DIV является целым делением (/ in С), a OR - поразрядным или (| в С).

2 Алгоритм декодирования поля "Остаток байтов" выглядит следующим образом:

- множитель = 1

- значение = 0

- ввод

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

- значение + = (encodedByte AND 127) * множитель

- множитель * = 128

- если (множитель> 128 * 128 * 128)

- выводит ошибку (недопустимая Остаток байтов)

- когда ((encodedByte AND 128)! = 0)

- где AND - бит-бит и оператор (& в С).

Когда этот алгоритм завершается, величина содержит значение "Оставшейся длины".

5.3 Переменный заголовок


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

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

В таблице 8 приведены байты идентификатора пакета.

Таблица 8 - Байты идентификатора пакета

Бит

7

6

5

4

3

2

1

0

Байт 1

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

Байт 2

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


Компонент переменного заголовка для многих типов управляющих пакетов включает в себя поле идентификатора пакета из 2 байтов. Такими управляющими пакетами являются PUBLISH (где QoS >0), PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK.

Управляющие пакеты SUBSCRIBE, UNSUBSCRIBE и PUBLISH (в случаях, когда QoS >0) ДОЛЖНЫ содержать ненулевой 16-разрядный идентификатор пакета [MQTT-5.3.1-1]. Каждый раз, когда Клиент отправляет новый пакет одного из этих типов, он ДОЛЖЕН назначить ему неиспользуемый в настоящее время идентификатор пакета [MQTT-5.3.1-2]. Если Клиент повторно отправляет конкретный управляющий пакет, он ДОЛЖЕН использовать тот же идентификатор пакета в последующих повторных отправках этого пакета. Идентификатор пакета становится доступным для повторного использования после того, как Клиент обработал соответствующий пакет подтверждения. В случае QoS 1 PUBLISH - это соответствующий PUBACK; в случае QoS 2 - это PUBCOMP. Для SUBSCRIBE или UNSUBSCRIBE - это соответствующий SUBACK или UNSUBACK [MQTT-5.3.1-3]. Те же условия применяются к Серверу, когда он отправляет PUBLISH с QoS>0 [MQTT-5.3.1-4].

Пакет PUBLISH НЕ ДОЛЖЕН содержать идентификатор пакета, если его значение QoS установлено на 0 [MQTT-5.3.1-5].

Пакеты PUBACK, PUBREC или PUBREL ДОЛЖНЫ содержать тот же идентификатор пакета, что и первоначально отправленный пакет PUBLISH [MQTT-5.3.1-6]. Аналогично SUBACK и UNSUBACK ДОЛЖНЫ содержать идентификатор пакета, который использовался в соответствующем пакете SUBSCRIBE и UNSUBSC IBE, соответственно [MQTT-5.3.1-7].

Управляющие пакеты, требующие идентификатор пакета, приведены в таблице 9.

Таблица 9 - Управляющие пакеты, содержащие идентификатор пакета

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

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

CONNECT

НЕТ

CONNACK

НЕТ

PUBLISH

ДА (если QoS >0)

PUBACK

ДА

PUBREC

ДА

PUBREL

ДА

PUBCOMP

ДА

SUBSCRIBE

ДА

SUBACK

ДА

UNSUBSCRIBE

ДА

UNSUBACK

ДА

PINGREQ

НЕТ

PINGRESP

НЕТ

DISCONNECT

НЕТ


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

Пример - Клиент может отправить пакет PUBLISH с идентификатором пакета 0x1234, а затем получить другой пакет PUBLISH с идентификатором пакета 0x1234 со своего Сервера, прежде чем он получит PUBACK по отправленному PUBLISH.

Клиент

Сервер

Идентификатор пакета PUBLISH = 0x1234 --- ГОСТ Р 58603-2019 (ИСО/МЭК 20922:2016) Информационные технологии (ИТ). Интернет вещей. Протокол организации очередей доставки телеметрических сообщений MQTT. Версия 3.1.1

ГОСТ Р 58603-2019 (ИСО/МЭК 20922:2016) Информационные технологии (ИТ). Интернет вещей. Протокол организации очередей доставки телеметрических сообщений MQTT. Версия 3.1.1 -- Идентификатор пакета PUBLISH = 0x1234

Идентификатор пакета PUBACK = 0x1234 --- ГОСТ Р 58603-2019 (ИСО/МЭК 20922:2016) Информационные технологии (ИТ). Интернет вещей. Протокол организации очередей доставки телеметрических сообщений MQTT. Версия 3.1.1

ГОСТ Р 58603-2019 (ИСО/МЭК 20922:2016) Информационные технологии (ИТ). Интернет вещей. Протокол организации очередей доставки телеметрических сообщений MQTT. Версия 3.1.1 -- Идентификатор пакета PUBACK = 0x1234


5.4 Полезная нагрузка


Некоторые управляющие пакеты MQTT содержат полезную нагрузку в качестве конечной части пакета, как описано в главе 6. В случае пакета PUBLISH - это сообщение приложения. В таблице 10 приведены управляющие пакеты, в которые необходимо включать полезную нагрузку.

Таблица 10 - Управляющие пакеты, содержащие полезную нагрузку

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

Полезная нагрузка

CONNECT

Обязательно

CONNACK

Нет

PUBLISH

Опционально

PUBACK

Нет

PUBREC

Нет

PUBREL

Нет

PUBCOMP

Нет

SUBSCRIBE

Обязательно

SUBACK

Обязательно

UNSUBSCRIBE

Обязательно

UNSUBACK

Нет

PINGREQ

Нет

PINGRESP

Нет

DISCONNECT

Нет


6 Управляющие пакеты MQTT

6.1 CONNECT - Клиент запрашивает подключение к Серверу


После того, как Клиент установил сетевое соединение с Сервером, первым пакетом, отправленным Клиентом на Сервер, ДОЛЖЕН быть пакет CONNECT (СОЕДИНЕНИЕ) [MQTT-6.1.0-1].

Клиент может отправить пакет CONNECT через сетевое подключение только один раз. Сервер ДОЛЖЕН обработать второй пакет CONNECT, отправленный Клиентом, как нарушение протокола, и прервать соединение с Клиентом [MQTT-6.1.0-2]. Информация об обработке приведена в подразделе 7.8.

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

6.1.1 Фиксированный заголовок

В таблице 11 приведен фиксированный заголовок пакета CONNECT.

Таблица 11 - Фиксированный заголовок пакета CONNECT

Бит

7

6

5

4

3

2

1

0

Байт 1

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

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

0

0

0

1

0

0

0

0

Байт 2...

Остаток байтов


Поле "Остаток байтов"

Остаток байтов - это длина переменного заголовка (10 байт) плюс длина полезной нагрузки. Суммарное количество байт в остатке кодируется способом, описанным в подпункте 5.2.3.

6.1.2 Переменный заголовок

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

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

В таблице 12 приведены байты имени протокола.

Таблица 12 - Байты имени протокола

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

Описание

7

6

5

4

3

2

1

0

Байт 1

Длина MSB (0)

0

0

0

0

0

0

0

0

Байт 2

Длина LSB (4)

0

0

0

0

0

1

0

0

Байт 3

"М"

0

1

0

0

1

1

0

1

Байт 4

"Q"

0

1

0

1

0

0

0

1

Байт 5

"Т"

0

1

0

1

0

1

0

0

Байт 6

"Т"

0

1

0

1

0

1

0

0


Имя протокола - это кодированная строка UTF-8, которая представляет собой имя протокола "МQТТ", записанное заглавными буквами, как показано. Строка, ее смещение и длина не меняются в последующих изданиях спецификации MQTT.

Если имя протокола неверно, Сервер МОЖЕТ прервать соединение с Клиентом, или МОЖЕТ продолжить обработку пакета CONNECT в соответствии с некоторыми другими спецификациями. В последнем случае Сервер НЕ ДОЛЖЕН продолжать обрабатывать пакет CONNECT в соответствии с настоящей спецификацией [MQTT-6.1.2-1].

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

6.1.2.2 Уровень протокола

В таблице 13 приведен байт уровня протокола.

Таблица 13 - Байт уровня протокола

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

Описание

7

6

5

4

3

2

1

0

Байт 7

Уровень (4)

0

0

0

0

0

1

0

0


8-битная величина без знака, представляющая уровень версии протокола, используемый Клиентом. Значение поля "Уровень протокола" для версии 3.1.1 протокола 4 (0x04). Сервер ДОЛЖЕН ответить на пакет CONNECT передачей пакета CONNACK с кодом 0x01 (неподдерживаемая версия протокола), а затем прервать соединение с Клиентом, если уровень протокола не поддерживается Сервером [MQTT-6.1.2-2].

6.1.2.3 Флаги соединения

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

Таблица 14 - Байты флагов соединения

Бит

7

6

5

4

3

2

1

0

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

Флаг пароля

Флаг сохранения "последней воли"

QoS "последней воли"

Флаг "последней воли"

Флаг очистки Сеанса

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

Байт 8

X

X

X

X

X

X

X

X


Сервер ДОЛЖЕН проверить, что зарезервированный флаг в пакете управления CONNECT установлен на ноль и прервать соединение с Клиентом, если значение отлично от нуля [MQTT-6.1.2-3].

6.1.2.4 Флаг очистки Сеанса

Позиция: бит 1 байта флага соединения.

Значение этого бита определяет способ обработки состояния Сеанса.

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

Если для флага очистки Сеанса установлено значение "0", Сервер ДОЛЖЕН возобновить обмен данными с Клиентом на основе состояния текущего сеанса (как определено идентификатором Клиента). Если нет Сеанса, связанного с идентификатором Клиента, Сервер ДОЛЖЕН создать новый сеанс. Клиент и Сервер ДОЛЖНЫ сохранять информацию о состоянии текущего Сеанса после прекращения соединения между Клиентом и Сервером [MQTT-6.1.2-4]. После завершения Сеанса, по которому параметр "Очистить сеанс" установлен на 0, Сервер ДОЛЖЕН сохранить дополнительные сообщения с уровнем качества обслуживания 1 и 2, соответствующие любым подпискам, которые существовали у Клиента во время завершения Сеанса [MQTT-6.1.2-5]. Он МОЖЕТ также хранить сообщения с уровнем качества обслуживания 0, соответствующие тем же критериям.

Если для флага очистки Сеанса установлено значение "1", Клиент и Сервер ДОЛЖНЫ завершить любой предыдущий Сеанс между Клиентом и Сервером и запустить новый. Этот Сеанс длится до тех пор, пока существует сетевое подключение. Данные состояния, связанные с этим Сеансом, НЕ ДОЛЖНЫ повторно использоваться в любом последующем сеансе [MQTT-6.1.2-6].

Состояние сеанса у Клиента состоит из:

- сообщений с уровнем качества обслуживания 1 и 2, которые были отправлены на Сервер, но не были полностью подтверждены;

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

Состояние Сеанса на Сервере состоит из:

- признака существования Сеанса, даже если остальная часть состояния Сеанса пуста;

- подписок Клиента;

- QoS 1 и QoS 2, которые были отправлены Клиенту, но не были полностью подтверждены;

- QoS 1 и QoS 2, ожидающие передачи Клиенту;

- сообщения QoS 2, полученные от Клиента, но не полностью подтвержденные;

- опционально сообщения QoS 0, ожидающие передачи Клиенту.

Сохраненные сообщения не являются частью состояния Сеанса на Сервере, они НЕ ДОЛЖНЫ удаляться, когда Сеанс заканчивается [MQTT-6.1.2.7].

Более подробная информация и ограничения сохраненного состояния приведены в подразделе 4.1.

Если для параметра "Очистить сеанс" установлено значение 1, Клиент и Сервер не должны обрабатывать удаление состояния атомарно.

Примечания

1 Чтобы обеспечить надлежащее состояние в случае сбоя связи, Клиент должен повторить попытки подключения, установив параметр "Очистить сеанс" на 1, пока соединение не будет успешно выполнено.

2 Как правило, Клиент всегда будет подключаться с использованием параметра "Очистить Сеанс", установленного на 0 или на 1, и не будет переключаться с одного значения на другое. Выбор будет зависеть от приложения. Клиент, использующий "Очистить Сеанс", установленный на 1, не получит старые сообщения приложения и должен заново подписываться на любые темы, которые его интересуют, при каждом подключении. Клиент, использующий "Очистить Сеанс", установленный на 0, получит все сообщения QoS 1 или QoS 2, которые были опубликованы, пока он был отключен. Следовательно, чтобы гарантировать получение сообщений после отключения, используйте QoS 1 или QoS 2 с параметром "Очистить Сеанс", установленным на 0.

3 При подключении Клиента с параметром "Очистить сеанс", установленным на 0, он запрашивает, чтобы Сервер сохранил состояние сеанса MQTT после его отключения. Клиенты должны подключаться только с параметром "Очистить Сеанс", установленным на 0, если они планируют повторно подключиться к Серверу в какой-то более поздний момент времени. Когда Клиент решил, что он больше не использует Сеанс, он должен выполнить окончательное соединение с параметром "Очистить Сеанс", установленным на 1, а затем отключиться.

6.1.2.5 Флаг "последней воли"

Позиция: 2 бита флагов подключения.

Установка флага "последней воли" на 1 означает, что, если запрос о соединении принят, сообщение "последней воли" ДОЛЖНО храниться на Сервере и быть связано с сетевым подключением. Сообщение о "последней воле" ДОЛЖНО быть опубликовано, когда Сетевое подключение будет закрыто, если сообщение не было удалено Сервером при получении пакета DISCONNECT [MQTT-6.1.2-8].

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

- ошибкой ввода-вывода или сетевым сбоем, обнаруженными Сервером;

- Клиент не может выполнить соединение в течение времени активного соединения;

- Клиент закрывает сетевое соединение без предварительной отправки пакета DISCONNECT;

- Сервер закрывает сетевое подключение из-за ошибки протокола.

Если флаг "последней воли" установлен на 1, поля уровня качества обслуживания сообщения "последней воли" и сохранение сообщения "последней воли" во флагах соединения будут использоваться Сервером, а поля темы "последней воли" и сообщения "последней воли" ДОЛЖНЫ присутствовать в полезной нагрузке [MQTT-6.1.2-9].

Сообщение о "последней воле" ДОЛЖНО быть удалено из сохраненного состояния Сеанса на Сервере после публикации, или когда Сервер получил от Клиента пакет DISCONNECT [MQTT-6.1.2-10].

Если флаг дальнейших действий установлен на 0, значения полей QoS и будущее сохранение должны быть установлены на ноль, а поля будущей темы и сообщение о дальнейших действиях НЕ ДОЛЖНЫ присутствовать в полезной нагрузке [MQTT-6.1.2-11].

Если флаг дальнейших действий установлен на 0, сообщение "последней воли" НЕ ДОЛЖНО публиковаться при завершении данного сетевого подключения [MQTT-6.1.2-12].

Серверу СЛЕДУЕТ немедленно публиковать сообщения "последней воли". В случае отключения или сбоя Сервера, он МОЖЕТ отложить публикацию сообщений "последней воли" до последующего перезапуска. Если это произойдет, может наблюдаться задержка между временем, когда произошел сбой Сервера, и временем публикации сообщений "последней воле".

6.1.2.6 Уровень качества обслуживания (QoS) "последней воли"

Позиция: биты 4 и 3 флагов соединения.

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

Если флаг "последней воли" установлен на 0, то значение QoS "последней воли" ДОЛЖНО быть установлено на 0 (0x00) [MQTT-6.1.2-13].

Если флаг "последней воли" установлен на 1, значение QoS "последней воли" может быть 0 (0x00), 1 (0x01) или 2 (0x02). Значение НЕ ДОЛЖНО быть установлено на 3 (0x03) [MQTT-6.1.2-14].

6.1.2.7 Флаг сохранения "последней воли"

Позиция: бит 5 флагов соединения.

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

Если флаг "последней воли" установлен на 0, то флаг будущего сохранения ДОЛЖЕН быть установлен на 0 [MQTT-6.1.2-15].

Флаг "последней воли" установлен на 1 в следующих случаях:

- если для будущего сохранения установлено значение 0, Сервер ДОЛЖЕН публиковать сообщение о дальнейших действиях как не сохраненное сообщение [MQTT-6.1.2-16];

- если для будущего сохранения установлено значение 1, Сервер ДОЛЖЕН публиковать сообщение о дальнейших действиях как сохраненное сообщение [MQTT-6.1.2-17].

6.1.2.8 Флаг имени пользователя

Позиция: бит 7 флагов соединения.

Если параметр флага имени пользователя установлен на 0, имя пользователя НЕ ДОЛЖНО присутствовать в полезной нагрузке [MQTT-6.1.2-18].

Если параметр флага имени пользователя установлен на 1, имя пользователя ДОЛЖНО присутствовать в полезной нагрузке [MQTT-6.1.2-19].

6.1.2.9 Флаг пароля

Позиция: бит 6 байтов флагов соединения.

Если флаг пароля установлен на 0, пароль НЕ ДОЛЖЕН присутствовать в полезной нагрузке [MQTT-6.1.2-20].

Если флаг пароля установлен на 1, пароль ДОЛЖЕН присутствовать в полезной нагрузке [MQTT-6.1.2-21].

Если параметр флага имени пользователя установлен на 0, флаг пароля ДОЛЖЕН быть установлен на 0 [MQTT-6.1.2-22].

6.1.2.10 Интервал поддержки активного соединения

В таблице 15 приведены байты активного соединения.

Таблица 15 - Байты активного соединения

Бит

7

6

5

4

3

2

1

0

Байт 9

Активное соединение MSB

Байт 10

Активное соединение LSB


Активное соединение - это временной интервал, измеряемый в секундах и представляемый в виде 16-битного слова, что является максимально допустимым временным промежутком между моментом, в который Клиент заканчивает передачу одного управляющего пакета и моментом, в который он начинает отправлять следующий. Клиент несет ответственность за то, чтобы промежуток между отправляемыми управляющими пакетами не превышал значение активного соединения. В случае отсутствия необходимости в отправке каких-либо других управляющих пакетов Клиент ДОЛЖЕН отправить пакет PINGREQ [MQTT-6.1.2-23].

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

Если значение активного соединения не равно нулю, и Сервер не получает управляющий пакет от Клиента в течение полутора интервалов периода активного соединения, он ДОЛЖЕН отключить сетевое соединение с Клиентом, как если бы произошел сбой сети [MQTT -3.1.2-24].

Если Клиент не получает пакет PINGRESP в течение разумного промежутка времени после отправки PINGREQ, ему СЛЕДУЕТ прервать сетевое подключение к Серверу.

Значение активного соединения, равное нулю (0), приводит к отключению механизма отслеживания активного соединения. Это означает, что в этом случае Сервер не обязан отключать Клиента по причине отсутствия действий.

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

Примечание - Фактическое значение активного соединения является специфичным для приложения; обычно оно составляет несколько минут. Максимальное значение составляет 18 часов 12 минут и 15 секунд.

Пример - Переменный заголовок приведен в таблице 16.

Таблица 16 - Пример переменного заголовка

Описание

7

6

5

4

3

2

1

0

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

Байт 1

Длина MSB (0)

0

0

0

0

0

0

0

0

Байт 2

Длина LSB (4)

0

0

0

0

0

1

0

0

Байт 3

"М"

0

1

0

0

1

1

0

1

Байт 4

"Q"

0

1

0

1

0

0

0

1

Байт 5

"Т"

0

1

0

1

0

1

0

0

Байт 6

"Т"

0

1

0

1

0

1

0

0

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

Байт 7

Уровень (4)

0

0

0

0

0

1

0

0

Флаги соединения

Байт 8

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

Флаг пароля (1)

Будущее сохранение (0)

Будущее QoS (01)

Флаг дальнейших действий (1)

Очистить сеанс (1)

Зарезервировано (0)

1

1

0

0

1

1

1

0

Активное соединение

Байт 9

Активное соединение MSB (0)

0

0

0

0

0

0

0

0

Байт 10

Активное соединение LSB (10)

0

0

0

0

1

Доступ к полной версии этого документа ограничен

Ознакомиться с документом вы можете, заказав бесплатную демонстрацию систем «Кодекс» и «Техэксперт».

Что вы получите:

После завершения процесса оплаты вы получите доступ к полному тексту документа, возможность сохранить его в формате .pdf, а также копию документа на свой e-mail. На мобильный телефон придет подтверждение оплаты.

При возникновении проблем свяжитесь с нами по адресу spp@kodeks.ru

ГОСТ Р 58603-2019 (ИСО/МЭК 20922:2016) Информационные технологии (ИТ). Интернет вещей. Протокол организации очередей доставки телеметрических сообщений MQTT. Версия 3.1.1

Название документа: ГОСТ Р 58603-2019 (ИСО/МЭК 20922:2016) Информационные технологии (ИТ). Интернет вещей. Протокол организации очередей доставки телеметрических сообщений MQTT. Версия 3.1.1

Номер документа: 58603-2019

Вид документа: ГОСТ Р

Принявший орган: Росстандарт

Статус: Действующий

Опубликован: Официальное издание. М.: Стандартинформ, 2019 год
Дата принятия: 16 октября 2019

Дата начала действия: 01 января 2021