> 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 и сценарии использования в телематике. Протокол транспорта телеметрии с очередями сообщений (MQTT) используется уже много лет, но сейчас он особенно актуален из-за взрывного роста IoT: как потребительские, так и промышленные устройства внедряют распределенные сети и периферийные вычисления, а устройства с постоянной передачей данных становятся частью повседневной жизни. Такой интенсивный рост заставляет людей искать способы эффективно передавать данные. ## Что такое MQTT Энди Стэнфорд-Кларк (IBM) и Арлен Ниппер (в то время работавший в Eurotech, Inc.) создали первую версию протокола в 1999 году. Он использовался для мониторинга нефтепроводов в рамках SCADA. Целью было создать протокол, который эффективно использует полосу пропускания, имеет небольшой объем и отличается низким энергопотреблением, поскольку устройства были подключены через спутниковый канал, который в то время был чрезвычайно дорогим. В настоящее время большинство устройств используют версию 5,0. Транспорт телеметрии с очередями сообщений (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 старших бита — это поле типа команды. Этот тип определяет действие, которое будет выполнено: клиент хочет подписаться на тему, публикуется новое сообщение для подписчиков и т. д. Следующие 4 бита — это биты флага управления, и они используются командой PUBLISH; для остальных Команды они зарезервированы, и значение будет 0. Второй байт фиксированного заголовка содержит оставшуюся длину, то есть длину переменного заголовка + длину полезной нагрузки. Переменный заголовок присутствует не во всех пакетах MQTT. Некоторые Команды или Сообщения MQTT используют это поле для передачи дополнительной информации или флагов, и они различаются в зависимости от типа пакета. Идентификатор пакета является общим для большинства типов пакетов. В конце пакет может содержать полезную нагрузку. Даже полезная нагрузка необязательна и зависит от типа пакета. Это поле обычно содержит передаваемые данные. Например, для пакетов CONNECT полезная нагрузка — это идентификатор клиента и «имя пользователя и пароль», если они присутствуют. А для пакета PUBLISH это сообщение, которое нужно опубликовать. ### Качество обслуживания QoS относится к соглашению между отправителем сообщения и получателем сообщения. Это ключевая функция MQTT, дающая клиенту возможность выбирать между тремя уровнями обслуживания. Три разных уровня QoS определяют, как содержимое управляется протоколом MQTT. Хотя более высокие уровни QoS надежнее, они требуют большей задержки и большей пропускной способности, поэтому подписавшиеся клиенты могут указать максимальный уровень QoS, который они хотели бы получать. * Самый простой уровень QoS — это необслуживаемая передача без подтверждения. Этот уровень QoS использует последовательность пакетов PUBLISH: издатель один раз отправляет сообщение брокеру, а брокер один раз передает сообщение подписчикам. Здесь нет механизма, который гарантировал бы корректное получение сообщения, и брокер не сохраняет сообщение. Этот уровень QoS также может называться at most once, QoS0 или fire and forget. * Второй уровень QoS — это служба с подтверждением. Этот уровень QoS использует последовательность пакетов PUBLISH/PUBACK между издателем и его брокером, а также между брокером и подписчиками. Пакет подтверждения проверяет, что содержимое было получено, а механизм повторной передачи отправит исходное содержимое еще раз, если подтверждение не будет получено своевременно. Это может привести к тому, что подписчик получит несколько копий одного и того же сообщения. Этот уровень QoS также может называться at least once или QoS1. * Третий уровень QoS — это служба с гарантированной доставкой. Этот уровень QoS доставляет сообщение с помощью двух пар пакетов. Первая пара называется PUBLISH/PUBREC, а вторая — PUBREL/PUBCOMP. Эти две пары гарантируют, что независимо от числа повторных попыток сообщение будет доставлено только один раз. Этот уровень QoS также может называться exactly once или 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 (Last Will and Testament) для уведомления сторон о нештатном отключении клиента. * Использует 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` 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 optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.