Как установить параметры при установлении соединения MQTT?
Установление соединения MQTT — это первый шаг в общении с использованием протокола MQTT. Протокол MQTT предоставляет расширенные параметры подключения, позволяющие разработчикам создавать приложения IoT, отвечающие различным бизнес-потребностям.
В этой статье представлена роль каждого параметра подключения в MQTT, и она поможет разработчикам сделать первые шаги в использовании MQTT.
Введение в соединение MQTT
Соединения MQTT инициируются от клиента к брокеру. Любое приложение или устройство, на котором запущена клиентская библиотека MQTT, является MQTT-клиент. MQTT-брокер обрабатывает клиентское подключение, отключение, запросы на подписку (или отмену подписки) и маршрутизирует сообщения при получении запросов на публикацию.
После установления сетевого соединения с брокером самым первым сообщением, которое должен отправить клиент, является CONNECT пакет. Брокер должен ответить CONNACK клиенту в качестве ответа, и соединение MQTT успешно установлено после того, как клиент получает CONNACK пакет. Если клиент не получает CONNACK пакет от брокера вовремя (обычно это настраиваемый тайм-аут со стороны клиента), он может активно закрыть сетевое соединение.
Спецификация протокола MQTT не ограничивает, какой транспорт использовать, наиболее часто используемым транспортным протоколом для MQTT являются TCP/TLS и Websocket. EMQ также внедрил MQTT через QUIC.
MQTT через TCP/TLS
TCP/TLS широко используется и представляет собой ориентированный на соединение, надежный протокол связи на транспортном уровне, основанный на потоке байтов. Это гарантирует, что полученные байты совпадают с байтами, отправленными через механизм подтверждения и повторной передачи.
MQTT обычно основан на TCP/TLS, который наследует многие преимущества TCP/TLS и может стабильно работать в средах с низкой пропускной способностью, высокой задержкой и ограниченными ресурсами.
MQTT через WebSocket
С быстрым развитием веб-технологий все больше и больше приложений могут быть реализованы в веб-браузере, используя преимущества мощного механизма рендеринга для пользовательского интерфейса. WebSocket, собственный метод связи для веб-приложений, также широко используется.
Многие веб-приложения IoT, такие как системы мониторинга устройств, должны отображать данные устройства в режиме реального времени в браузере. Однако браузеры передают данные на основе протокола HTTP и не могут использовать MQTT через TCP.
Основатель протокола MQTT предвидит важность веб-приложений, поэтому протокол MQTT с момента своего создания поддерживает связь через MQTT через WebSocket. Проверить блог для получения дополнительной информации о том, как использовать MQTT через WebSocket.
MQTT через QUIC
QUIC (RFC 9000) — это базовый транспортный протокол интернет-протокола следующего поколения HTTP/3, который обеспечивает подключение к современному мобильному Интернету с меньшими издержками соединения и задержкой сообщений по сравнению с протоколами TCP/TLS.
Основываясь на преимуществах QUIC, которые делают его очень подходящим для сценариев обмена сообщениями IoT, EMQX 5.0 представляет MQTT вместо QUIC.
Использование параметров соединения MQTT
Адрес подключения
Адрес подключения MQTT обычно включает IP-адрес брокера (или доменное имя), порт брокера и протокол. В случае кластерных MQTT-брокеров обычно балансировщик нагрузки помещается впереди, поэтому IP-адрес или доменное имя могут фактически быть балансировщиком нагрузки.
Соединения MQTT на основе TCP
Например, mqtt://broker.emqx.io:1883 — это адрес соединения MQTT на основе TCP, и mqtts://broker.emqx.io:1883 — адрес защищенного соединения MQTT на основе TLS/SSL.
В некоторых клиентских библиотеках соединение на основе TCP
tcp://ip:1883
Соединение на основе WebSocket
Адрес подключения также должен содержать путь при использовании подключения WebSocket. Путь по умолчанию, настроенный для EMQX является /mqtt.
Например, ws://broker.emqx.io:8083/mqtt — это адрес подключения MQTT на основе WebSocket, и wss://broker.emqx.io:8083/mqtt — это адрес защищенного соединения MQTT на основе WebSocket.
ID клиента
Брокер MQTT использует идентификатор клиента для идентификации клиентов, и каждый клиент, подключающийся к брокеру, должен иметь уникальный идентификатор клиента. Идентификатор клиента представляет собой строку в кодировке UTF-8. Если клиент подключается со строкой нулевой длины, брокер должен назначить для нее уникальную строку.
В зависимости от версии протокола MQTT и деталей реализации брокера допустимый набор символов, принимаемых брокером, различается. Самая консервативная схема — использовать символы [0-9a-zA-Z] и ограничьте длину до 23 байт.
Из-за уникальной природы идентификатора клиента, если два клиента подключаются к одному и тому же брокеру с одним и тем же идентификатором клиента, клиент, подключающийся позже, заставит того, кто подключился раньше, отключиться.
Имя пользователя Пароль
Протокол MQTT поддерживает аутентификацию по имени пользователя и паролю, но если базовый транспортный уровень не зашифрован, имя пользователя и пароль будут передаваться в виде открытого текста, следовательно, для лучшей безопасности.mqtts или wss рекомендуется протокол.
Большинство брокеров MQTT по умолчанию разрешают анонимный вход в систему, то есть нет необходимости указывать имя пользователя или пароль (или задавать пустые строки).
Время ожидания подключения
Время ожидания до получения брокера CONNACK пакет, если CONNACK не получен в течение этого времени, соединение закрывается.
Сохранить жизнь
Keep Alive — это интервал в секундах. Если сообщения для отправки нет, клиент будет периодически отправлять посреднику контрольное сообщение в соответствии со значением Keep Alive, чтобы гарантировать, что посредник не разорвет соединение.
После успешного установления соединения, если брокер не получит никаких пакетов от клиента в течение 1,5 раз Keep Alive, он будет считать, что есть проблема с соединением с клиентом, и брокер отключится от клиента.
Проверить блог для получения более подробной информации о Keep Alive.
Чистая сессия
Установлен в false означает создание постоянной сессии. Когда клиент отключается, сеанс сохраняется и сохраняет автономные сообщения до истечения срока действия сеанса. Установлен в true для создания нового временного сеанса, который автоматически уничтожается при отключении клиента.
Постоянный сеанс позволяет клиенту подписки получать сообщения, когда он находится в автономном режиме. Эта функция очень полезна в сценариях IoT, где сеть нестабильна.
Количество сообщений, которые брокер сохраняет для постоянных сеансов, зависит от настроек брокера. Например, публичный MQTT-брокер EMQX настроен на хранение сообщений в автономном режиме в течение 5 минут, а максимальное количество сообщений составляет 1000 (для сообщений QoS 1 и QoS 2).
Примечание: Предпосылка постоянного восстановления сеанса заключается в том, что клиент повторно подключается с фиксированным идентификатором клиента. Если идентификатор клиента является динамическим, будет создан новый постоянный сеанс.
Последнее желание
Когда клиент MQTT, настроивший Will Message, аварийно отключается от сети, MQTT-брокер публикует Will Message, установленный этим клиентом.
Неожиданный офлайн включает: соединение закрыто сервером из-за сбоя в сети; устройство внезапно отключилось; устройство пытается выполнить недопустимую операцию, и соединение закрывается сервером и т. д.
Сообщение Will можно рассматривать как упрощенное сообщение MQTT, которое также содержит Topic, Payload, QoS, Retain и т. д.
Когда устройство неожиданно отключается, сообщение будет отправлено на
Will Topic.Will Payloadявляется содержанием сообщения, которое должно быть отправлено.Will QoSтакое же, как QoS стандартных сообщений MQTT.Will Retainустановлен вtrueозначает, что сообщение будет сохранено. При получении сообщения сretainфлаг установлен, брокер MQTT должен сохранить сообщение для темы, в которой сообщение было опубликовано, и он должен сохранить только самое последнее сообщение. Таким образом, подписчики, заинтересованные в этой теме, могут выйти из сети и повторно подключиться в любое время, чтобы получить последнее сообщение, вместо того, чтобы ждать следующего сообщения от издателя после подписки.
Протокол
Наиболее часто используемыми версиями протокола MQTT являются MQTT v3.1, MQTT v3.1.1 и MQTT v5.0. В настоящее время MQTT 5.0 стал предпочтительным протоколом для большинства IoT-предприятий, и мы рекомендуем разработчикам MQTT-новичков использовать эту версию напрямую.
Проверьте MQTT 5.0 Серия блогов, предоставленная EMQ, чтобы узнать об использовании новых функций MQTT 5.0.
Новые параметры подключения в MQTT v5.0
Интервал чистого начала и окончания сеанса
Чистый сеанс был удален в MQTT 5.0, но были добавлены Чистый старт и Интервал окончания сеанса.
Когда чистый старт true он отбрасывает любой существующий сеанс и создает новый сеанс. А false значение означает, что сервер должен использовать сеанс, связанный с идентификатором клиента, для возобновления связи с клиентом (если сеанс не существует).
Если Интервал истечения сеанса установлен на 0 или отсутствует, сеанс завершается при закрытии сетевого подключения. Если это 0xFFFFFFFF (UINT_MAX), срок действия сеанса не истекает. Если он больше 0, количество секунд, в течение которых сеанс будет оставаться после закрытия сетевого подключения.
Подключить свойства
MQTT 5.0 также добавляет новые свойства подключения для повышения расширяемости протокола. Проверить блог чтобы узнать больше о Connect Properties.
Как установить безопасное соединение MQTT?
Хотя протокол MQTT предоставляет такие механизмы аутентификации, как имя пользователя и пароль, идентификатор клиента и т. д., этого недостаточно для безопасности IoT. При передаче открытого текста на основе TCP трудно гарантировать безопасность данных.
TLS (Transport Layer Security) или, в некотором контексте, новое устаревшее название SSL, в первую очередь нацелены на обеспечение конфиденциальности и целостности данных между двумя или более взаимодействующими компьютерными приложениями. Работая поверх TLS, MQTT может в полной мере использовать свои функции безопасности для обеспечения целостности данных и доверия клиентов.
Шаги по включению SSL/TLS варьируются от брокера MQTT к брокеру MQTT. EMQX имеет встроенную поддержку TLS/SSL, включая поддержку односторонней/двусторонней аутентификации, сертификатов X.509, SSL с балансировкой нагрузки и многих других сертификатов безопасности.
Односторонняя аутентификация — это способ установить безопасную связь только путем проверки сертификата сервера. Он гарантирует, что связь зашифрована, но не может проверить подлинность клиента. Обычно его необходимо сочетать с механизмами аутентификации, такими как имя пользователя и пароль и идентификатор клиента.
Двусторонняя аутентификация означает, что и сервер, и клиент должны предоставить сертификаты при аутентификации связи, и обе стороны должны пройти аутентификацию, чтобы гарантировать, что другой доверяет. Для некоторых сценариев приложений с высокими требованиями к безопасности требуется включить двустороннюю аутентификацию.
Примечание: Если вы используете MQTT через WebSocket в браузере, двусторонняя аутентификация еще не поддерживается.
Резюме
На этом этапе у вас должно быть хорошее представление о том, как устанавливаются соединения MQTT, и о роли каждого параметра соединения.
Далее вы можете проверить Простое для понимания руководство по протоколу MQTT серия статей, предоставленных EMQ, чтобы узнать о темах MQTT, подстановочных знаках, сохраненных сообщениях, Last-Will и других функциях. Изучите более продвинутые приложения MQTT и начните разработку приложений и сервисов MQTT.
Первоначально опубликовано на https://www.emqx.com.
