> 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 Протокол передачи телеметрии с очередями сообщений (MQTT) используется уже много лет, но сейчас он особенно актуален из-за взрывного роста IoT: как потребительские, так и промышленные устройства внедряют распределенные сети и периферийные вычисления, а устройства с постоянной передачей данных становятся частью повседневной жизни. Такой интенсивный рост заставляет искать способы эффективной передачи данных. ## Что такое MQTT Энди Стэнфорд-Кларк (IBM) и Арлен Ниппер (в то время работавший в Eurotech, Inc.) создали первую версию протокола в 1999 году. Его использовали для мониторинга нефтепроводов в рамках SCADA. Цель состояла в том, чтобы создать протокол, который был бы эффективным по использованию пропускной способности, легковесным и потреблял мало энергии батареи, поскольку устройства были подключены через спутниковый канал, который в то время был чрезвычайно дорогим. В настоящее время большинство устройств используют версию 5.0. Протокол передачи телеметрии с очередями сообщений (MQTT) — это легковесный сетевой протокол с моделью публикации и подписки, который передает Сообщения между устройствами. Обычно протокол работает поверх TCP/IP; однако поддерживать MQTT может любой сетевой протокол, который обеспечивает упорядоченные, без потерь, двунаправленные соединения. Он предназначен для подключений к удаленным объектам, где требуется «небольшой объем кода» или ограничена пропускная способность сети. Протокол является открытым стандартом OASIS и рекомендацией ISO (ISO/IEC 20922). С учетом условий эксплуатации протокол сделан небольшим и легким. Он идеально подходит для устройств с низким энергопотреблением и ограниченным сроком службы батареи. Сейчас к ним относятся смартфоны, а также постоянно растущее число датчиков и Внешнее оборудование. Таким образом, MQTT стал протоколом для потоковой передачи данных между устройствами с ограниченной вычислительной мощностью процессора и/или сроком службы батареи, а также для сетей с дорогой или низкой пропускной способностью, непредсказуемой стабильностью или высокой задержкой. Именно поэтому MQTT считается идеальным протоколом для IoT. Он построен на протоколе TCP/IP, но существует ветка MQTT-SN для работы поверх Bluetooth, UDP, ZigBee и в других IoT-сетях, отличных от TCP/IP. ## Как это работает ### Модель публикации и подписки В MQTT есть 2 основных понятия: MQTT-брокер и MQTT-клиент. MQTT-брокер — это сервер, который получает все Сообщения от клиентов и затем направляет Сообщения соответствующим клиентам-получателям. Проще говоря, брокер действует как почтовое отделение, MQTT не использует адрес предполагаемого получателя, а использует тему, называемую «Topic», и любой, кто хочет копию этого сообщения, подпишется на эту тему. Несколько клиентов могут получать сообщение от одного брокера (возможность «один ко многим»). Аналогично, несколько публикаторов могут публиковать темы одному подписчику (многие к одному). Клиент 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](/files/b6304ef5b382d5826f97028359095725979d93c3) Из двухбайтового фиксированного заголовка первый байт — это поле управления. Это 8-битное поле управления разделено на два 4-битных поля. Первые 4 старших бита — это поле типа команды. Этот тип определяет выполняемое действие: клиент хочет подписаться на тему, для подписчиков публикуется новое сообщение и т. д. Следующие 4 бита — это биты управляющих флагов, и они используются командой публикации; для остальных команд они зарезервированы, а значение будет равно 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](/files/7b1538cc27244c3601b67499c579a58eab2cf0a6) ## Преимущества и недостатки ### Преимущества: * MQTT не зависит от типа пакета. Полезная нагрузка протокола MQTT может содержать любые данные, например двоичные данные, ASCII-текст и т. д. Получатель должен интерпретировать и декодировать их в соответствии с форматом, используемым передатчиком. * Он использует пакеты малого размера и может применяться в приложениях с низкой пропускной способностью. * Он отличается меньшим энергопотреблением. * Это надежный протокол, поскольку он использует параметры QoS для обеспечения гарантированной доставки. * Благодаря модели публикации/подписки он хорошо масштабируется. * Он обеспечивает слабосвязанную архитектуру, поскольку устройство и сервер легко разделить. Идеально подходит для распределенных коммуникаций один-ко-многим и разнесенных приложений. * Публикующее устройство может отправлять данные на сервер в любое время независимо от своего состояния. * Оснащен функцией LWT (Last Will and Testament) для уведомления сторон о нештатном отключении клиента. * Использует TCP/IP для базовых заданий связи. * Предназначено для доставки сообщений согласно шаблонам «максимум один раз», «минимум один раз» и «ровно один раз». ### Недостатки: * MQTT не может поддерживать потоковую передачу видео. * Проблемы с задержкой. * Охрана не встроена. MQTT без шифрования. Вместо этого он использует TLS/SSL (Transport Layer Security/Secure Sockets Layer) для шифрования охраны. * Централизованный брокер может стать точкой отказа, поскольку клиентские соединения с брокерами всегда открыты. * Он не поддерживает расширенные функции, такие как управление потоком. ## Где можно использовать MQTT Поскольку приложения IoT сейчас внедряются в огромных масштабах, MQTT оказался в центре внимания как открытый, простой и масштабируемый способ развертывания распределенных вычислений и функций IoT для более широкой базы пользователей как на потребительском, так и на промышленном рынках. * Управление транспортом. Организации используют MQTT для создания более интеллектуальных систем управления транспортом, которые повышают оптимизацию автопарка, безопасность водителя и снижают затраты на топливо. Новые виды транспорта с использованием дронов также меняют способы доставки грузов. Связь между мобильным устройством оператора, телеметрической информацией непосредственно с транспортного средства и интеграцией в бэкенд-системы планирования и маршрутизации обеспечивает видимость, необходимую для улучшения общей работы автопарка. * Данные датчиков окружающей среды. MQTT поддерживает модель доставки сообщений «не более одного раза». В сетях с частичным покрытием территории или высокой задержкой это означает, что информация может быть потеряна или продублирована. В областях, где удаленные датчики записывают и передают данные через заданные интервалы, это не проблема, поскольку новые показания поступают регулярно. Датчики в удаленных средах обычно являются устройствами с низким энергопотреблением, что делает MQTT идеальным решением для датчиков IoT с относительно низким приоритетом передачи данных. * Данные о состоянии оборудования: чтобы быстро реагировать на возникающие проблемы и предотвращать простои. Например, для ветроэлектростанции вам нужна гарантированная доставка текущих эксплуатационных показателей местным командам еще до того, как эта информация попадет в центр обработки данных. В таких ситуациях доставка сообщений «не менее одного раза» гарантирует, что соответствующие флаги будут своевременно замечены нужными специалистами, даже если они придут в виде дубликатов. Это важно для машинно-машинной связи с более высоким приоритетом. * Биллинговые системы: Есть еще более приоритетные и точные сообщения, которые необходимо обрабатывать корректно. В бизнес-ситуациях, где дублирование записей недопустимо, в том числе в биллинговых системах, полезен флаг QoS передачи «ровно один раз». Это устраняет дублирование или потерю пакетов в биллинге или биллинговых системах, снижает число аномалий и ненужных противоречий в договоре. * Текстовые приложения для обмена сообщениями в реальном времени, использующие преимущества низкого расхода данных и энергии, характерного для MQTT. Например, Facebook использует MQTT в своем приложении Messenger не только потому, что протокол экономит заряд аккумулятора при обмене сообщениями между мобильными телефонами, но и потому, что он позволяет доставлять сообщения эффективно за миллисекунды, несмотря на нестабильные интернет-соединения по всему миру. ## Поддерживаемые Navixy MQTT-устройства * 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](/files/8475096aebb5eb059571172a0fad5310dad3ac26) ### Настройка 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.