# Основы MQTT Протокол Message Queuing Telemetry Transport (MQTT) используется уже много лет, но сейчас он особенно актуален из-за стремительного роста IoT: как потребительские, так и промышленные устройства внедряют распределённые сети и периферийные вычисления, а устройства с постоянной передачей данных становятся частью повседневной жизни. Такой интенсивный рост заставляет искать способы эффективной передачи данных. ## Что такое MQTT Энди Стэнфорд-Кларк (IBM) и Арлен Ниппер (тогда работавший в Eurotech, Inc.) разработали первую версию протокола в 1999 году. Он использовался для мониторинга нефтепроводов в рамках SCADA. Цель состояла в том, чтобы создать протокол с эффективным использованием полосы пропускания, лёгкий и потребляющий мало энергии батареи, поскольку устройства были подключены через спутниковый канал, который в то время был крайне дорогим. На данный момент большинство устройств используют версию 5.0. Message Queuing Telemetry Transport (MQTT) — это лёгкий сетевой протокол publish-subscribe, передающий сообщения между устройствами. Протокол обычно работает поверх TCP/IP; однако любой сетевой протокол, который обеспечивает упорядоченные, без потерь, двунаправленные соединения, может поддерживать MQTT. Он предназначен для соединений с удалёнными объектами, где требуется «малый объём кода» или ограничена пропускная способность сети. Протокол является открытым стандартом OASIS и рекомендацией ISO (ISO/IEC 20922). С учётом условий эксплуатации протокол сделан небольшим и лёгким. Он идеально подходит для устройств с низким энергопотреблением и ограниченным сроком службы батареи. Сейчас к таким устройствам относятся смартфоны, а также постоянно растущее число датчиков и подключённых устройств. Таким образом, MQTT стал протоколом для потоковой передачи данных между устройствами с ограниченной вычислительной мощностью CPU и/или сроком службы батареи, а также для сетей с дорогой или низкой пропускной способностью, непредсказуемой стабильностью или высокой задержкой. Именно поэтому MQTT известен как идеальный протокол для IoT. Он построен на протоколе TCP/IP, но существует ветка MQTT-SN для работы по Bluetooth, UDP, ZigBee и в других IoT-сетях, отличных от TCP/IP. ## Как это работает ### Модель публикации и подписки В MQTT есть 2 основных понятия: MQTT Broker и MQTT client. MQTT broker — это сервер, который получает все сообщения от клиентов, а затем направляет их к соответствующим клиентам-получателям. Проще говоря, broker действует как почтовое отделение: MQTT не использует адрес предполагаемого получателя, а использует строку темы, называемую «Topic», и любой, кто хочет получить копию этого сообщения, подпишется на эту тему. Несколько клиентов могут получать сообщение от одного broker (возможность один-ко-многим). Аналогично, несколько издателей могут публиковать темы для одного подписчика (многие-к-одному). MQTT client — это любое устройство (от микроконтроллера до полнофункционального сервера), которое запускает библиотеку MQTT и подключается к MQTT broker по сети. * Клиент подключается к broker. Он может подписаться на любую тему сообщений («topic») в broker. Это соединение может быть обычным TCP/IP-соединением или зашифрованным TLS-соединением для конфиденциальных сообщений. * Клиент публикует сообщения под темой, отправляя сообщение и тему в broker. * Затем broker пересылает сообщение всем клиентам, подписанным на эту тему. Поскольку сообщения MQTT организованы по темам, разработчик приложения может гибко определить, какие клиенты могут взаимодействовать только с определёнными сообщениями. Например, датчики будут публиковать свои показания в теме «sensor\_data» и подписываться на тему «config\_change». Приложения для обработки данных, которые сохраняют данные датчиков во внутреннюю базу данных, будут подписываться на тему «sensor\_data». Приложение административной консоли может получать команды системного администратора для настройки конфигурации датчиков, например чувствительности и частоты измерений, и публиковать эти изменения в тему «config\_change». ### Типы сообщений MQTT Сеанс MQTT делится на четыре этапа: подключение, аутентификация, обмен данными и завершение. Клиент начинает с создания соединения Transmission Control Protocol/Internet Protocol (TCP/IP) с broker с использованием стандартного порта или пользовательского порта, определённого операторами broker. При создании соединения важно понимать, что сервер может продолжить старый сеанс, если ему будет предоставлен повторно используемый идентификатор клиента. Стандартные порты: 1883 — для незашифрованной связи и 8883 — для зашифрованной связи с использованием Secure Sockets Layer (SSL)/Transport Layer Security (TLS). Во время SSL/TLS-handshake клиент проверяет сертификат сервера и аутентифицирует сервер. Клиент также может предоставить broker сертификат клиента во время handshake. Broker может использовать его для аутентификации клиента. Хотя это не является частью спецификации MQTT, стало обычной практикой, что broker поддерживают аутентификацию клиента с помощью клиентских сертификатов SSL/TLS. Поскольку протокол MQTT нацелен на устройства с ограниченными ресурсами и IoT-устройства, SSL/TLS не всегда может быть вариантом и в некоторых случаях может быть нежелателен. В таких случаях аутентификация представляется в виде открытых текста имени пользователя и пароля, которые клиент отправляет серверу — как часть последовательности пакетов CONNECT/CONNACK. Кроме того, некоторые broker, особенно открытые broker, опубликованные в интернете, принимают анонимных клиентов. В таких случаях имя пользователя и пароль просто остаются пустыми. ### Формат сообщения MQTT MQTT считается лёгким протоколом, потому что все его сообщения имеют малый объём кода. Пакет состоит из фиксированного заголовка длиной 2 байта + переменного заголовка и полезной нагрузки. В этих первых 2 байтах фиксированный заголовок всегда присутствует во всех пакетах, а два других элемента — переменный заголовок и полезная нагрузка — присутствуют не всегда. ![Формат сообщения MQTT](/files/e8526b92586a987873fccefcd3b7db3c0469ad76) Из двухбайтового фиксированного заголовка первый байт является полем управления. Это 8-битное поле управления делится на два 4-битных поля. Первые 4 старших бита MSB — это поле типа команды. Этот тип определяет выполняемое действие: клиент хочет подписаться на тему, публикуется новое сообщение для подписчиков и т. д. Следующие 4 бита — это биты флагов управления, и они используются командой publish; для остальных команд они зарезервированы, и их значение будет 0. Второй байт фиксированного заголовка содержит оставшуюся длину, то есть длину переменного заголовка + длину полезной нагрузки. Переменный заголовок присутствует не во всех пакетах MQTT. Некоторые команды или сообщения MQTT используют это поле для предоставления дополнительной информации или флагов, и они различаются в зависимости от типа пакета. Идентификатор пакета присутствует в большинстве типов пакетов. В конце пакет может содержать полезную нагрузку. Полезная нагрузка тоже необязательна и зависит от типа пакета. Это поле обычно содержит передаваемые данные. Например, для пакетов CONNECT полезная нагрузка — это client ID и «username and password», если они присутствуют. А для пакета PUBLISH — это сообщение, которое нужно опубликовать. ### Качество обслуживания QoS — это соглашение между отправителем сообщения и получателем сообщения. Это ключевая функция MQTT, предоставляющая клиенту возможность выбирать между тремя уровнями обслуживания. Три различных уровня QoS определяют, как содержимое обрабатывается протоколом MQTT. Хотя более высокие уровни QoS являются более надёжными, они требуют большей задержки и пропускной способности, поэтому подписывающиеся клиенты могут указать максимальный уровень QoS, который они хотят получать. * Самый простой уровень QoS — это сервис без подтверждения. Этот уровень QoS использует последовательность пакетов PUBLISH; издатель отправляет сообщение в broker один раз, а broker передаёт сообщение подписчикам один раз. Здесь нет механизма, гарантирующего, что сообщение было получено корректно, и broker не сохраняет сообщение. Этот уровень QoS также может называться at most once, QoS0 или fire and forget. * Второй уровень QoS — это сервис с подтверждением. Этот уровень QoS использует последовательность пакетов PUBLISH/PUBACK между издателем и его broker, а также между broker и подписчиками. Пакет подтверждения удостоверяет, что содержимое было получено, а механизм повторной отправки отправит исходное содержимое снова, если подтверждение не будет получено своевременно. Это может привести к тому, что подписчик получит несколько копий одного и того же сообщения. Этот уровень QoS также может называться at least once или QoS1. * Третий уровень QoS — это гарантированный сервис. Этот уровень QoS доставляет сообщение с помощью двух пар пакетов. Первая пара называется PUBLISH/PUBREC, а вторая — PUBREL/PUBCOMP. Эти две пары гарантируют, что независимо от числа повторных попыток сообщение будет доставлено только один раз. Этот уровень QoS также может называться exactly once или QoS2. ![QoS MQTT](/files/07df48a324d504684a9631b3acea7c9d77ec78e3) ## Преимущества и недостатки ### Преимущества: * MQTT не зависит от типа пакета. Полезная нагрузка протокола MQTT может содержать любой тип данных, например двоичные данные, текст ASCII и т. д. Получатель должен интерпретировать и декодировать данные в соответствии с форматом, используемым передатчиком. * Он использует пакеты малого размера и может применяться в приложениях с низкой пропускной способностью. * Он обеспечивает меньшее потребление энергии батареи. * Это надёжный протокол, поскольку он использует варианты QoS для обеспечения гарантированной доставки. * Благодаря модели publish/subscribe он масштабируемый. * Он предлагает развязанную архитектуру, поскольку устройство и сервер легко разделить. Идеально подходит для распределённых однонаправленных коммуникаций и раздельных приложений. * Публикующее устройство может отправлять данные на сервер в любое время независимо от его состояния. * Оснащён функцией LWT (Last Will and Testament) для уведомления сторон о ненормальном отключении клиента. * Опирается на TCP/IP для базовых задач связи. * Предназначен для доставки сообщений в соответствии с шаблонами «maximum once», «minimum once» и «exactly once». ### Недостатки: * MQTT не поддерживает потоковую передачу видео. * Проблемы с задержкой. * Безопасность не встроена. MQTT не шифруется. Вместо этого для шифрования безопасности используется TLS/SSL (Transport Layer Security/Secure Sockets Layer). * Централизованный broker может стать точкой отказа, поскольку соединения клиентов с broker всегда открыты. * Он не поддерживает расширенные функции, такие как управление потоком. ## Где можно использовать MQTT Поскольку IoT-приложения сейчас внедряются в огромных масштабах, MQTT оказался в центре внимания как открытый, простой и масштабируемый способ развертывания распределённых вычислений и IoT-функциональности для более широкой пользовательской базы — как на потребительском, так и на промышленном рынках. * Управление автопарком. Организации используют MQTT для создания более интеллектуальных систем управления автопарком, которые повышают оптимизацию автопарка, безопасность водителей и снижают расходы на топливо. Новые виды транспорта с использованием дронов также меняют способы перевозки грузов. Связь между мобильным устройством, используемым оператором, телеметрической информацией непосредственно от транспортного средства и интеграцией в бэкэнд-системы планирования и маршрутизации обеспечивает необходимую прозрачность для повышения общей эффективности работы автопарка. * Данные экологических датчиков. MQTT поддерживает модель доставки сообщений «не более одного раза». В сетях с частичным покрытием территории или высокой задержкой это означает, что информация может быть потеряна или продублирована. В районах, где удалённые датчики фиксируют и передают данные через заданные интервалы, это не является проблемой, поскольку новые показания поступают регулярно. Датчики в удалённых условиях обычно являются маломощными устройствами, что делает MQTT идеальным решением для IoT-датчиков с относительно низким приоритетом передачи данных. * Данные о состоянии оборудования: чтобы быстро реагировать на возникающие проблемы и предотвращать простои. Например, для ветряной электростанции необходимо гарантировать доставку текущих показателей производительности местным командам ещё до того, как эта информация попадёт в центр обработки данных. В таких ситуациях доставка сообщений «не менее одного раза» гарантирует, что соответствующие флаги будут своевременно замечены нужными специалистами, даже если они придут в виде дубликатов. Это важно для machine-to-machine communication с более высоким приоритетом. * Системы выставления счетов: существуют ещё более приоритетные и точные сообщения, которые необходимо обрабатывать корректно. В бизнес-ситуациях, где дублирование записей недопустимо, включая системы выставления счетов, полезен флаг передачи QoS «exactly once». Это исключает дублирование или потерю пакетов в биллинговых системах, уменьшает количество аномалий и ненужных противоречий в соглашении. * Текстовые приложения обмена сообщениями для связи в реальном времени, которые используют низкое потребление данных и энергии MQTT. Например, Facebook использует MQTT для своего приложения Messenger не только потому, что протокол экономит заряд батареи при мобильной переписке между телефонами, но и потому, что он позволяет доставлять сообщения эффективно, за миллисекунды, несмотря на нестабильные интернет-соединения по всему миру. ## Устройства MQTT, поддерживаемые Navixy * Xirgo Global FMS500 Light MQTT (IOTM * Xirgo Global FMS500 Light+ MQTT (IOTM) * Xirgo Global FMS500 StCAN MQTT (IOTM) * BCE FMS500 Light MQTT (IOTM) * BCE FMS500 Light+ MQTT (IOTM) * BCE FMS500 StCAN MQTT (IOTM) * GlobalmatiX xTCU ## Как настроить устройства MQTT для работы с Navixy ### Конфигурация устройств Xirgo и BCE MQTT Чтобы настроить устройство Xirgo и BCE для работы с MQTT: * В FMSET: Выберите connectivity → Telemetry server → MQTT broker address settings) укажите host: [mqtt.eu.navixy.com](http://mqtt.eu.navixy.com/) для EU server и [mqtt.us.navixy.com](http://mqtt.eu.navixy.com/) для US server, port 1883. * И добавьте пользователя по умолчанию в MQTT Security -> Authorization\ ![MQTT device configuration](/files/d6484e117b5016f496cd8a78f70356906b5ae0a8) ### Конфигурация устройства Globalmatix MQTT Чтобы настроить устройство Globalmatix для работы с MQTT: * Укажите сервер port 1883 для EU и port 1883 для US * User/password - globalmatix/secretword * Topic globalmatix/in Чтобы настроить устройство Globalmatix для работы с MQTTS: * Укажите сервер port 8883 для EU и port 8883 для US * User/password - globalmatix/secretword * Topic globalmatix/in --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://navixy.com/docs/expert-center/ru/vehicle-telematics-technology/connectivity/mqtt-fundamentals.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.