Статус документа
Статус документа

ГОСТ Р 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 для поддержки обмена текстовыми сообщениями.

Доступ к полной версии документа ограничен
Полный текст этого документа доступен на портале с 20 до 24 часов по московскому времени 7 дней в неделю.
Также этот документ или информация о нем всегда доступны в профессиональных справочных системах «Техэксперт» и «Кодекс».
Нужен полный текст и статус документов ГОСТ, СНИП, СП?
Попробуйте «Техэксперт: Лаборатория. Инспекция. Сертификация» бесплатно
Реклама. Рекламодатель: Акционерное общество "Информационная компания "Кодекс". 2VtzqvQZoVs