MQTT 3.1.1 Essentials 翻譯+重點整理

https://www.hivemq.com/mqtt-essentials/

Сентябрь 2020 г.

Часть 1: Знакомство с MQTT

https://www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt/

Опубликовано: 12 января 2015 г.

MQTT並非是message queue的解決方案，即使它能做到。

Многие источники неверно называют MQTT протоколом очередей сообщений. Это просто не соответствует действительности. MQTT не является традиционным решением для создания очередей сообщений (хотя в некоторых случаях это возможно, о чем мы подробно расскажем в одном из следующих постов).

2019年，MQTT 5 版本釋出。

В марте 2019 года OASIS ратифицировала новую спецификацию MQTT 5.

Часть 2: Основы публикации и подписки

https://www.hivemq.com/blog/mqtt-essentials-part2-publish-subscribe/ Опубликовано: 19 января 2015 г.

Шаблон публикации/подписки

從3個維度探討decoupling的好處:

• 空間解耦: pub/sub不需要知道對方(например, 不需交換對方的ip,port)
• 時間解耦: pub/sub不需要同時執行
• 同步性解耦: pub/sub不會因為發送或接收訊息時中斷工作。

Наиболее важным аспектом pub/sub является отделение издателя сообщения от получателя (подписчика). Это развязывание имеет несколько аспектов:

• Развязка пространства: Издатель и подписчик не должны знать друг друга (например, нет обмена IP-адресами и портами).
• Развязка по времени: Издатель и подписчик не должны работать в одно и то же время.
• Развязка синхронизации: Операции обоих компонентов не должны прерываться во время публикации или получения.

Масштабируемость

比起傳統client-server,pub/sub的擴充性更好。原因包含broker可以被高度平行化以及訊息能被event-driven方式處理。關鍵字：кэширование сообщений, интеллектуальная маршрутизация сообщений。

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

Фильтрация сообщений

ФИЛЬТРАЦИЯ ПО СУБЪЕКТУ: 根據message的主題過濾。

ФИЛЬТРОВКА НА ОСНОВЕ СОДЕРЖАНИЯ: 根據message的關鍵字過濾，重點是message不能被加密以及不能輕易被更改。

ФИЛЬТРАЦИЯ НА ОСНОВЕ ТИПА: 當使用OOP語言，透過тип/класс進行過濾。

У брокера есть несколько вариантов фильтрации:

• ВАРИАНТ 1: ФИЛЬТРАЦИЯ НА ОСНОВЕ СУБЪЕКТАЭта фильтрация основана на предмете или теме, которая является частью каждого сообщения. Принимающий клиент подписывается на интересующие его темы у брокера. С этого момента брокер гарантирует, что принимающий клиент получит все сообщения, опубликованные в подписанных темах. В общем случае темы представляют собой строки с иерархической структурой, позволяющей осуществлять фильтрацию на основе ограниченного числа выражений.
• ВАРИАНТ 2: Фильтрация на основе содержимого При фильтрации на основе содержимого брокер фильтрует сообщение на основе определенного языка фильтрации содержимого. Принимающие клиенты подписываются на запросы фильтрации сообщений, которые их интересуют. Существенным недостатком этого метода является то, что содержание сообщения должно быть известно заранее и не может быть зашифровано или легко изменено.
• ВАРИАНТ 3: ФИЛЬТРАЦИЯ НА ОСНОВЕ ТИПАПри использовании объектно-ориентированных языков фильтрация на основе типа/класса сообщения (события) является обычной практикой. Например, подписчик может прослушивать все сообщения типа Exception или любого подтипа.

pub/sub並非適用於所有use case。而decoupling面臨的挑戰包含:

1. 必須要事先知道來自pub data的資料結構。
2. тематическая фильтрация, pub和sub都需要知道使用哪個topic。
3. доставка сообщений, pub無法假設會有人接收它正傳出的message, 所以可能發生沒有sub讀取message的情形。

Конечно, публикация/подписка не является решением для каждого случая использования. Есть несколько моментов, которые необходимо учитывать, прежде чем использовать эту модель. Разделение издателя и подписчика, которое является ключевым в pub/sub, представляет собой несколько собственных проблем. Например, вам необходимо заранее знать, как структурированы публикуемые данные. Для тематической фильтрации и издатель, и подписчик должны знать, какие темы использовать. Еще один момент, о котором следует помнить, — доставка сообщений. Издатель не может полагать, что кто-то слушает отправляемые сообщения. В некоторых случаях может оказаться, что ни один подписчик не читает конкретное сообщение.

MQTT

這段主要說明MQTT實現哪些pub/sub的功能，以及透過QoS levels解決上述的pub/sub的挑戰，但看不太懂QoS的例子，待後續章節是否會詳細說明QoS。

Отличие от очередей сообщений

message queue會一直儲存message直到consumer來拿資料。但是MQTT會把沒有sub的message處理掉。

Очередь сообщений хранит сообщения до тех пор, пока они не будут потреблены При использовании очереди сообщений каждое входящее сообщение хранится в очереди до тех пор, пока его не заберет клиент (часто называемый потребителем). Если ни один клиент не забирает сообщение, оно остается в очереди и ждет, пока его не употребят. В очереди сообщений невозможно, чтобы сообщение не было обработано ни одним клиентом, как это происходит в MQTT, если никто не подписывается на тему.

message queue的message只能被一個consumer進行處理。但MQTT的多個sub可以接收同一個topic的message。

Сообщение потребляется только одним клиентом Еще одно большое отличие заключается в том, что в традиционной очереди сообщений сообщение может быть обработано только одним потребителем. Нагрузка распределяется между всеми потребителями очереди. В MQTT поведение совершенно противоположное: каждый подписчик, подписавшийся на тему, получает сообщение.

queue必須被明確地命名且建立後才能對message進行publish/consume，但MQTT可以即時建立topic。

Очереди именуются и должны быть созданы в явном виде Очередь гораздо более жесткая структура, чем тема. Прежде чем очередь можно будет использовать, она должна быть создана в явном виде отдельной командой. Только после того, как очередь названа и создана, можно публиковать или потреблять сообщения. В отличие от этого, темы MQTT чрезвычайно гибкие и могут создаваться «на лету».

Часть 3: Клиент, брокер и установление соединения

https://www.hivemq.com/blog/mqtt-essentials-part-3-client-broker-connection-establishment/ Опубликовано: 17 июля 2019 г.

Введение — Клиент

pub/sub都被視為MQTT клиенты，而單一client可以同時扮演pub和sub的角色。

И издатели, и подписчики являются клиентами MQTT. Метки publisher и subscriber относятся к тому, публикует ли клиент в данный момент сообщения или подписывается на сообщения (функции публикации и подписки могут быть реализованы в одном и том же MQTT-клиенте).

Введение — Брокер

брокер的工作包含: 接收訊息,過濾訊息,確認誰訂閱訊息,傳送訊息給訂閱者,保留persistent session的session data, authentication, authorization of clients

MQTT соединение

Протокол MQTT是基於TCP/IP стек。

Протокол MQTT основан на TCP/IP. И клиент, и брокер должны иметь стек TCP/IP.

初始化連線：

1. клиент 傳送 сообщение CONNECT 給 брокер.
2. брокер 回傳 CONNACK сообщение 以及 код статуса.

broker會一直持續開啟connection, 直到client傳送disconnect command或是連線中斷。

MQTT-соединение всегда осуществляется между одним клиентом и брокером. Клиенты никогда не соединяются друг с другом напрямую. Чтобы инициировать соединение, клиент посылает брокеру сообщение CONNECT. Брокер отвечает сообщением CONNACK и кодом состояния. Как только соединение установлено, брокер держит его открытым до тех пор, пока клиент не отправит команду disconnect или пока соединение не разорвется.

MQTT-соединение через NAT

MQTT不會受到NAT影響。詳細原因看不太明白…

Клиент инициирует соединение с помощью сообщения CONNECT

這段介紹 CONNECT сообщение 包含哪些資訊。

ClientId

Брокер использует ClientID для идентификации клиента и текущего состояния клиента.

В MQTT 3.1.1 (текущий стандарт) вы можете отправить пустой ClientId, если вам не нужно, чтобы брокер хранил состояние. Пустой ClientID приводит к соединению без какого-либо состояния. В этом случае флаг чистой сессии должен быть установлен в true, иначе брокер отклонит соединение.

Чистая сессия

Флаг чистой сессии сообщает брокеру, хочет ли клиент установить постоянную сессию или нет.

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

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

Сообщение завещания

Сообщение последней воли является частью функции «Последняя воля и завещание» (LWT) MQTT. Это сообщение уведомляет других клиентов, когда клиент безболезненно отключается.

KeepAlive

Keep alive — это интервал времени в секундах, который клиент задает и передает брокеру при установлении соединения. Этот интервал определяет самый длительный период времени, который брокер и клиент могут выдержать без отправки сообщения.

Клиент обязуется регулярно посылать брокеру сообщения PING Request. Брокер отвечает PING-ответом. Этот метод позволяет обеим сторонам определить, доступна ли еще другая сторона.

Брокер отвечает сообщением CONNACK

當broker收到 CONNECT message、會回傳 CONNACK message。

Когда брокер получает сообщение CONNECT, он обязан ответить сообщением CONNACK. Сообщение CONNACK содержит две записи данных:

1. Флаг присутствия сессии
2. Флаг подтверждения соединения

Флаг присутствия сессии

回傳告訴client上一次的連線是否已經有 persistent session。

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

如果client的 Clean Session 是True,回傳的 session present flag 一定會是 False,
但是client的 Clean Session 是False,回傳的 session present flag 有2種可能:

1. 如果broker有保存 информация о сессии, 回傳 True
2. 如果broker沒保存 информация о сессии, 回傳 False

這個flag幫助client確認是否需要subscribe topics, 或是topic是否仍存在 persistent session。

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

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

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

Код возврата 只有 0 才代表成功。

Свободные концы

看後續章節、會說明如何讓connection保持open、或是如何得知 связь потеряна。

Часть 4: Публикация, подписка и отмена подписки

https://www.hivemq.com/blog/mqtt-essentials-part-4-mqtt-publish-subscribe-unsubscribe/ Опубликовано: 2 февраля 2015 г.

Публикация

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

data-agnostic, 由client決定layload的結構。

MQTT не зависит от данных. Сценарий использования клиента определяет, как будет структурирована полезная нагрузка. Отправляющий клиент (издатель) решает, хочет ли он отправить двоичные данные, текстовые данные или даже полноценный XML или JSON.

Название темы

QoS

詳見 часть 6 книги MQTT Essentials.

Это число указывает на уровень качества обслуживания (QoS) сообщения.

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

Флаг сохранения

詳見 часть 8 из MQTT Essentials.

Брокер 收到这样的 PUBLISH 包以后，将保存这个消息，当有一个新的订阅者订阅相应主题的时候，Broker 会马上将这个消息发送给订阅者。

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

Когда новый клиент подписывается на тему, он получает последнее сообщение, сохраненное для этой темы.

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

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

Идентификатор пакета уникально идентифицирует сообщение в процессе его передачи между клиентом и брокером.

QoS > 0

Идентификатор пакета имеет значение только для уровней QoS больше нуля.

Флаг DUP

是否是重複的message。參考QoS章節會比較容易懂。

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

QoS > 0

當client傳送message給broker,broker讀message,根據QoS進行ack,處理message(確認對應的topic,並傳送給對應的subscribers)。

Подписаться

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

Список подписок

Подписка = (имя темы, уровень QoS)

подстановочные знаки: 可以用pattern指定多個topics

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

Suback

基於訂閱數量會回傳多個 коды возврата。

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

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

Код возврата

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

直接看圖

Отписаться

直接看圖

Часть 5: Темы и лучшие практики

https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/ Опубликовано: 20 августа 2019 г.

Темы

1. В MQTT слово тема относится к строке UTF-8, которую брокер использует для фильтрации сообщений для каждого подключенного клиента. Тема состоит из одного или нескольких уровней тем.
2. Каждый уровень темы разделяется прямой косой чертой (разделитель уровней темы).
3. По сравнению с очередью сообщений, темы MQTT очень легковесны. Клиенту не нужно создавать нужную тему перед публикацией или подпиской на нее. Брокер принимает каждую корректную тему без предварительной инициализации.
4. Обратите внимание, что каждая тема должна содержать не менее 1 символа, и что строка темы допускает пустые пробелы.
5. Темы чувствительны к регистру.
6. Передняя косая черта сама по себе является допустимой темой.

Дикие символы

Одноуровневый: +

直接看圖

Многоуровневый:

直接看圖

Темы, начинающиеся с $

Темы с символом $ зарезервированы для внутренней статистики брокера MQTT.

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

https://github.com/mqtt/mqtt.github.io/wiki/SYS-Topics

$SYS/broker/clients/connected
$SYS/broker/clients/disconnected
$SYS/broker/clients/total
$SYS/broker/messages/sent
$SYS/broker/uptime

Лучшие практики

Никогда не используйте ведущую прямую косую черту

/myhome/groundfloor/livingroom 代表最上層有個0字元的topic

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

1. 不容易閱讀和debug
2. UTF-8有很多不同 типы белого пространства

Держите тему короткой и лаконичной

Используйте только символы ASCII, избегайте непечатаемых символов

не ASCII UTF-8 會有顯示問題

Вставьте в тему уникальный идентификатор или идентификатор клиента

1. 可以幫助識別誰傳送message
2. 可以作為授權管理,client只能能傳送message至對應的topic

Не подписывайтесь на

透過在broker寫插件進行將message寫入db,而不要直接透過subscribe將全部資料讀出。

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

Наша рекомендация — реализовать расширение в брокере MQTT. Например, с помощью системы плагинов HiveMQ вы можете подключиться к поведению HiveMQ и добавить асинхронную процедуру для обработки каждого входящего сообщения и сохранения его в базе данных.

Не забывайте о расширяемости

建立topic tree時先想好未來的擴展性,避免未來將topic tree砍掉重建。

Используйте конкретные темы, а не общие

盡量將topic區分開，方便使用其他MQTT features (e.g. retained messages).

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

https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/ 16 февраля 2015 г.

Что такое качество обслуживания?

QoS是雙方一起遵守的協議。

Уровень качества обслуживания (QoS) — это соглашение между отправителем сообщения и получателем сообщения, которое определяет гарантию доставки для конкретного сообщения. В MQTT существует 3 уровня QoS:

1. не более одного раза (0)
2. По крайней мере, один раз (1)
3. Точно один раз (2).

當提及MQTT QoS，必須考量到以下2個情境

Когда вы говорите о QoS в MQTT, вам необходимо рассмотреть две стороны доставки сообщений:

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

Почему важно качество обслуживания?

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

QoS 0 — не более одного раза

盡力而為 .

Этот уровень обслуживания гарантирует доставку с максимальной отдачей.

射後不理

QoS уровня 0 часто называется «fire and forget» и обеспечивает те же гарантии, что и лежащий в основе протокол TCP.

QoS 1 — по крайней мере один раз

sender會保留message直到收到 PUBACK пакет，否則會一直重傳。

收到PUBACK packet也就代表至少收到一次message。

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

呼應前面章節提到的 флаг DUP.

Если публикующий клиент посылает сообщение повторно, он устанавливает флаг дублирования (DUP). В QoS 1 этот флаг DUP используется только для внутренних целей и не обрабатывается брокером или клиентом. Получатель сообщения отправляет PUBACK, независимо от флага DUP.

QoS 2 — ровно один раз

最安全但也是速度最慢的QoS level

必須產生2次 запрос/ответ

QoS 2 — это самый безопасный и медленный уровень качества обслуживания. Гарантия обеспечивается как минимум двумя потоками запрос/ответ (четырехчастное рукопожатие) между отправителем и получателем.

отправитель收到PUBREC пакет之後,丟棄PUBLISH пакет,並保存PUBREC пакет,並回傳 PUBREL пакет.

Как только отправитель получает пакет PUBREC от получателя, отправитель может спокойно отбросить первоначальный пакет PUBLISH. Отправитель сохраняет пакет PUBREC от получателя и отвечает пакетом PUBREL.

После того, как получатель получает пакет PUBREL, он может отбросить все сохраненные состояния и ответить пакетом PUBCOMP (то же самое верно, когда отправитель получает PUBCOMP). Пока приемник не завершит обработку и не отправит пакет PUBCOMP обратно отправителю, он хранит ссылку на идентификатор пакета исходного пакета PUBLISH. Этот шаг важен для того, чтобы избежать обработки сообщения во второй раз. После того, как отправитель получает пакет PUBCOMP, идентификатор пакета опубликованного сообщения становится доступным для повторного использования.

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

Лучшая практика

Используйте QoS 0, когда …

1. 穩定的網路
2. 不在意訊息遺失
3. 不需要 очередь сообщений

Используйте QoS 1, когда …

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

Используйте QoS 2, когда …

如果重複的message讓sub收到會造成影響。

Постановка в очередь сообщений с QoS 1 и 2

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

Часть 7: Постоянный сеанс и постановка сообщений в очередь

Часть 8: Сохраненные сообщения

Часть 9: Последняя воля и завещание

Часть 10: Keep Alive & Client Take-Over