> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/expert-center/ru/vehicle-telematics-technology/connectivity/mqtt-fundamentals.md). # Основы MQTT Публикационно-подписной протокол, обеспечивающий легковесное взаимодействие IoT-устройств. Охватывает настройку MQTT-брокера, форматы сообщений, уровни QoS и сценарии использования в телематике. Протокол Message Queuing Telemetry Transport (MQTT) используется уже много лет, но сейчас он особенно актуален из-за взрывного роста IoT: как потребительские, так и промышленные устройства внедряют распределенные сети и периферийные вычисления, а устройства с постоянной передачей данных становятся частью повседневной жизни. Такой интенсивный рост заставляет людей искать способы эффективно передавать данные. ## Что такое MQTT Энди Стэнфорд-Кларк (IBM) и Арлен Ниппер (в то время работавший в Eurotech, Inc.) создали первую версию протокола в 1999 году. Его использовали для мониторинга нефтепроводов в рамках SCADA. Цель состояла в том, чтобы получить протокол, эффективный по пропускной способности, легковесный и мало расходующий заряд батареи, поскольку устройства были подключены через спутниковую линию связи, которая в то время была чрезвычайно дорогой. В настоящее время большинство устройств используют версию 5.0. Message Queuing Telemetry Transport (MQTT) — это легковесный сетевой протокол публикации и подписки, который передает сообщения между устройствами. Обычно протокол работает поверх 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-брокер и MQTT-клиент. MQTT-брокер — это сервер, который получает все сообщения от клиентов, а затем маршрутизирует сообщения соответствующим клиентам-получателям. Проще говоря, брокер действует как почтовое отделение: MQTT не использует адрес предполагаемого получателя, а использует строку темы, и любой, кому нужна копия этого сообщения, подпишется на эту тему. Несколько клиентов могут получать сообщение от одного брокера (возможность «один ко многим»). Аналогично, несколько отправителей могут публиковать темы одному подписчику (многие к одному). MQTT-клиент — это любое устройство (от микроконтроллера до полноценного сервера), на котором работает библиотека MQTT и которое подключается к MQTT-брокеру по сети. * Клиент подключается к брокеру. Он может подписаться на любую тему сообщений в брокере. Это соединение может быть обычным TCP/IP-соединением или зашифрованным TLS-соединением для конфиденциальных сообщений. * Клиент публикует сообщения в рамках темы, отправляя сообщение и тему брокеру. * Затем брокер пересылает сообщение всем клиентам, подписанным на эту тему. Поскольку сообщения MQTT организованы по темам, разработчик приложения может гибко задать, что определенные клиенты могут взаимодействовать только с определенными сообщениями. Например, датчики будут публиковать свои показания в теме «sensor\_data» и подписываться на тему «config\_change». Приложения обработки данных, сохраняющие данные датчиков в бэкенд-базу данных, будут подписываться на тему «sensor\_data». Приложение администраторской консоли может получать команды системного администратора для настройки конфигурации датчиков, например чувствительность и частоту дискретизации, и публиковать эти изменения в тему «config\_change». ### Типы сообщений MQTT Сеанс MQTT делится на четыре этапа: подключение, аутентификация, обмен данными и завершение. Клиент начинает с создания соединения по протоколу управления передачей/Интернет-протоколу (TCP/IP) с брокером, используя либо стандартный порт, либо пользовательский порт, определенный операторами брокера. При создании соединения важно понимать, что сервер может продолжить старый сеанс, если ему предоставлен повторно используемый идентификатор клиента. Стандартные порты: 1883 для незашифрованной связи и 8883 для зашифрованной связи — с использованием уровня защищенных сокетов (SSL)/безопасности транспортного уровня (TLS). Во время рукопожатия SSL/TLS клиент проверяет сертификат сервера и аутентифицирует сервер. Во время рукопожатия клиент также может предоставить брокеру клиентский сертификат. Брокер может использовать его для аутентификации клиента. Хотя это и не является частью спецификации MQTT, для брокеров стало привычным поддерживать аутентификацию клиента с помощью клиентских сертификатов SSL/TLS. Поскольку протокол MQTT стремится быть протоколом для устройств с ограниченными ресурсами и IoT-устройств, SSL/TLS не всегда может быть вариантом и в некоторых случаях может быть нежелателен. В таких случаях аутентификация представляется в виде имени пользователя и пароля в открытом виде, которые клиент отправляет серверу — это является частью последовательности пакетов CONNECT/CONNACK. Кроме того, некоторые брокеры, особенно открытые брокеры, размещенные в интернете, принимают анонимных клиентов. В таких случаях имя пользователя и пароль просто остаются пустыми. ### Формат сообщений MQTT MQTT считается легковесным протоколом, поскольку все его сообщения имеют малый объем кода. Пакет состоит из 2-байтового фиксированного заголовка + переменного заголовка и полезной нагрузки. В этих первых 2 байтах фиксированный заголовок всегда присутствует во всех пакетах, а два других — переменный заголовок и полезная нагрузка — присутствуют не всегда. ![Формат сообщений MQTT](https://2371323805-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-6ea9b1f21c9f81792c5f2c59d36794c86f4881ab%2Fimagen-20231019-231143.png?alt=media) Из двухбайтового фиксированного заголовка первый байт — это поле управления. Это 8-битное поле управления делится на два 4-битных поля. Первые 4 старших бита MSB — это поле типа команды. Этот тип определяет выполняемое действие: клиент хочет подписаться на тему, для подписчиков публикуется новое сообщение и т. д. Следующие 4 бита — это биты управляющего флага; их использует команда PUBLISH, а для остальных команд они зарезервированы, и их значение равно 0. Второй байт фиксированного заголовка содержит оставшуюся длину, то есть длину переменного заголовка + длину полезной нагрузки. Переменный заголовок присутствует не во всех пакетах MQTT. Некоторые команды или сообщения MQTT используют это поле для передачи дополнительной информации или флагов, а его содержимое зависит от типа пакета. Идентификатор пакета присутствует в большинстве типов пакетов. В итоге пакет может содержать полезную нагрузку. Даже полезная нагрузка необязательна и зависит от типа пакета. Это поле обычно содержит передаваемые данные. Например, для пакетов CONNECT полезная нагрузка — это идентификатор клиента и «имя пользователя и пароль», если они присутствуют. А для пакета PUBLISH — это сообщение, которое требуется опубликовать. ### Качество обслуживания QoS — это соглашение между отправителем сообщения и его получателем. Это ключевая функция MQTT, которая дает клиенту возможность выбирать между тремя уровнями обслуживания. Три различных уровня QoS определяют, как MQTT управляет содержимым. Хотя более высокие уровни QoS надежнее, они характеризуются большей задержкой и более высокими требованиями к пропускной способности, поэтому подписывающиеся клиенты могут указать максимальный уровень QoS, который хотели бы получать. * Самый простой уровень QoS — режим без подтверждения. Этот уровень QoS использует последовательность пакетов PUBLISH; отправитель один раз отправляет сообщение брокеру, а брокер один раз передает сообщение подписчикам. Не предусмотрен механизм проверки того, что сообщение было получено корректно, и брокер не сохраняет сообщение. Этот уровень QoS также может называться «не более одного раза», QoS0 или «отправил и забыл». * Второй уровень QoS — режим с подтверждением. Этот уровень QoS использует последовательность пакетов PUBLISH/PUBACK между отправителем и его брокером, а также между брокером и подписчиками. Пакет подтверждения проверяет, что содержимое получено, а механизм повторной отправки отправит исходное содержимое еще раз, если подтверждение не будет получено своевременно. Это может привести к тому, что подписчик получит несколько копий одного и того же сообщения. Этот уровень QoS также может называться «не менее одного раза» или QoS1. * Третий уровень QoS — это гарантированный режим. Этот уровень QoS доставляет сообщение с помощью двух пар пакетов. Первая пара называется PUBLISH/PUBREC, а вторая — PUBREL/PUBCOMP. Две пары гарантируют, что независимо от числа повторных попыток сообщение будет доставлено только один раз. Этот уровень QoS также может называться «ровно один раз» или QoS2. ![QoS в MQTT](https://2371323805-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-9ab221645f4cb2fd3ec068c2cbd9aa27a4196e83%2Fchrome_q1ak4noiok-600x466.png?alt=media) ## Преимущества и недостатки ### Преимущества: * MQTT не зависит от типа пакета. Полезная нагрузка протокола MQTT может содержать любые типы данных, такие как двоичные данные, текст ASCII и т. д. Получатель должен интерпретировать и декодировать данные в соответствии с форматом, использованным передатчиком. * Он использует пакеты небольшого размера и может применяться в приложениях с низкой пропускной способностью. * Он обеспечивает более низкое энергопотребление. * Он является надежным протоколом, поскольку использует опции QoS для гарантированной доставки. * Благодаря модели публикации/подписки он хорошо масштабируется. * Он предлагает слабосвязанную архитектуру, поскольку устройство и сервер легко отделить друг от друга. Идеально подходит для распределенных коммуникаций «один ко многим» и разнесенных приложений. * Устройство, публикующее данные, может отправлять их на сервер в любое время независимо от своего состояния. * Оснащен функцией LWT (последняя воля и завещание) для уведомления сторон о нештатном отключении клиента. * Использует TCP/IP для базовых задач обмена данными. * Предназначен для доставки сообщений по схемам «максимум один раз», «минимум один раз» и «ровно один раз». ### Недостатки: * MQTT не поддерживает потоковую передачу видео. * Проблемы с задержкой. * Охрана не встроена. MQTT не зашифрован. Вместо этого он использует TLS/SSL (безопасность транспортного уровня/уровень защищенных сокетов) для шифрования. * Централизованный брокер может стать точкой отказа, поскольку соединения клиентов с брокерами постоянно открыты. * Он не поддерживает расширенные функции, такие как управление потоком. ## Где можно использовать MQTT Поскольку приложения IoT сейчас внедряются в огромных масштабах, MQTT оказался в центре внимания как открытый, простой и масштабируемый способ внедрять распределенные вычисления и функции IoT для более широкой пользовательской аудитории как на потребительском, так и на промышленном рынках. * Управление транспортом. Организации используют MQTT для создания более умных систем управления транспортом, которые улучшают эффективность автопарка, безопасность водителей и снижают расходы на топливо. Новые виды транспорта с использованием дронов тоже меняют способы перевозки грузов. Связь между мобильным устройством, используемым оператором, телеметрической информацией, поступающей напрямую от транспортного средства, и интеграцией с бэкенд-системами планирования и маршрутизации обеспечивает необходимую прозрачность для улучшения работы всего автопарка. * Данные датчиков окружающей среды. MQTT поддерживает модель доставки сообщений «не более одного раза». В сетях с неполным покрытием территории или высокой задержкой это означает, что информация может потеряться или дублироваться. В областях, где удаленные датчики записывают и передают данные с заданными интервалами, это не проблема, поскольку новые показания поступают регулярно. Датчики в удаленных условиях обычно являются устройствами с низким энергопотреблением, что делает MQTT идеальным решением для IoT-датчиков с относительно низким приоритетом передачи данных. * Данные о состоянии оборудования: чтобы быстро реагировать на возникающие проблемы и предотвращать простои. Например, для ветроэлектростанции требуется гарантированная доставка текущих показателей производительности местным командам еще до того, как эта информация попадет в центр обработки данных. В таких ситуациях доставка сообщений «не менее одного раза» гарантирует, что соответствующие флаги своевременно заметят нужные специалисты, даже если они придут дубликатами. Это важно для межмашинного взаимодействия с более высоким приоритетом. * Биллинговые системы: существуют еще более приоритетные и точные сообщения, которые необходимо обрабатывать корректно. В бизнес-ситуациях, где дублирование записей недопустимо, в том числе в биллинговых системах, полезен флаг QoS передачи «ровно один раз». Это исключает дублирование или потерю пакетов в биллинговых системах, снижает количество аномалий и ненужных противоречий в соглашении. * Текстовые приложения для обмена сообщениями в реальном времени, которые используют низкое потребление данных и энергии, характерное для 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 ### Настройка MQTT-устройств Xirgo и BCE Чтобы настроить устройства Xirgo и BCE для работы с MQTT: * В FMSET: выберите **Подключение** → **Сервер телеметрии** → **Настройки адреса MQTT-брокера** и укажите хост: [mqtt.eu.navixy.com](http://mqtt.eu.navixy.com/) для сервера ЕС и [mqtt.us.navixy.com](http://mqtt.us.navixy.com/) для сервера США, порт 1883. * И добавьте пользователя по умолчанию в **Охрана MQTT** -> **Авторизация**\ ![MQTT device configuration](https://2371323805-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-197f3834a584ce60ef3ef825d645d2e490e2b1b7%2Fimagen-20231019-231034.png?alt=media) ### Настройка MQTT-устройства Globalmatix Чтобы настроить устройство Globalmatix для работы с MQTT: * Укажите сервер порт 1883 для ЕС и порт 1883 для США * **Имя пользователя/пароль**: globalmatix/secretword * **Тема**: globalmatix/in Чтобы настроить устройство Globalmatix для работы с MQTTS: * Укажите **сервер** порт 8883 для ЕС и порт 8883 для США * **Имя пользователя/пароль**: globalmatix/secretword * **Тема**: globalmatix/in --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://navixy.com/docs/expert-center/ru/vehicle-telematics-technology/connectivity/mqtt-fundamentals.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.