QoS 0, 1 и 2: за что плата платит за надёжность

Затвор ворот во дворе раз в десяток нажатий молчал, и первая мысль была дежурной: поднять QoS с нуля до максимума — надёжнее же. Открыл документацию PubSubClient и упёрся в смешное: у publish() вообще нет параметра QoS. Ни нулевого, ни второго — библиотека шлёт всегда с нулевым уровнем, и это не недоработка, а осознанный выбор автора. Разбираюсь здесь, что теряет и что экономит плата на каждом уровне, почему двойка на слабой плате — балласт и где проходит граница, за которой нулевого действительно мало. Арифметика уровней в общих чертах уже была в уроке про QoS — я не повторяю её, а считаю цену в пакетах и байтах RAM.

Интуиция «надёжнее значит выше уровень» подводит в обе стороны. HTTP-клиентов мы привыкли обвешивать ретраями руками: таймаут, повтор, пауза с ростом — и в MQTT по привычке тянем максимальную гарантию. Только каждый уровень — не флажок в настройке, а живой обмен пакетами, который ест эфир, RAM и миллисекунды цикла. На настольном сервере это незаметно, на плате с радиомодулем за доллар — заметно сразу.

QoS 0 — «максимум один раз»: один пакет PUBLISH и всё. Потерялся — никто не заметит: ни подтверждения, ни повтора. Звучит страшно, пока не вспомнишь, под чем едет MQTT: TCP сам ретранслирует сегменты внутри живого соединения, поэтому нулевой уровень теряет сообщения в основном на обрывах — роутер перезагрузился, Wi-Fi отвалился, стык с LTE дрогнул. Телеметрия, которая идёт каждые десять секунд, такое прощает: следующее показание исправит график без всяких гарантий доставки. Потерянное значение живёт в графике дыркой шириной в один период — я называю это надёжностью повтором, и для показаний её хватает.

QoS 1 — «минимум один раз»: отправитель ждёт PUBACK на свой packet-id и, не дождавшись, шлёт пакет заново с пометкой dup. Доставка гарантирована, единственность — нет: подтверждение могло потеряться уже после доставки, и подписчик получит сообщение дважды. Цена: два пакета на сообщение в лучшем случае, память о неотправленном на отправителе и терпимость к дубликатам на получателе. Практическое следствие: обработчик команды обязан переживать дубликат, и это дешевле, чем кажется, — показываю после скетча.

QoS 2 — «ровно один раз»: четырёхтактный обмен, который давит и потери, и дубликаты:

Четыре пакета вместо одного, состояние транзакции на обеих сторонах, повторные такты при любой заминке. Придуман уровень для случаев, где дубликат дороже потери: оплата, учёт, накопительные команды. В домашнем MQTT я не встретил ни одного топика, где повторное срабатывание стоило бы денег: счётчики шлют накопленные итоги и дубликат итога безвреден, реле ждут абсолютных команд on/off, дубликат которых тоже безвреден. Мой вывод, готовый к спору: в квартире QoS 2 не нужен никогда, а более спорная половина вывода в том, что и QoS 1 нужен реже, чем кажется. Я включаю его там, где потеря команды видна глазом и жалуется человек: ворота, замок, насос. Всё остальное чинится повтором, retain и здравым смыслом. Двойка на слабой плате плоха ещё и памятью: клиент обязан держать транзакцию до PUBCOMP, а очереди-confirmations на ESP8266 с его 80 КБ кучи — роскошь, за которую платит фрагментацией.

Факт, который определил мой выбор раз и навсегда: publish() в PubSubClient шлёт только QoS 0 — параметра в API не существует; subscribe() умеет нулевой и первый; второй недостижим ни в какую сторону. Для ESP32 и Arduino это значит, что вся надёжность исходящих строится поверх библиотеки: retained-статус вместо гарантии доставки, повторная публикация после reconnect, подтверждение на уровне приложения. Как реле получает команду по подписке QoS 1 и приложение гасит дубликаты, разобрано в уроке про реле с подтверждением. Согласование уровней напомню одной строкой: брокер отдаёт подписчику минимум из двух обещаний — публикуете с двойкой, а он подписался с нулём, прилетит нулевой.

Простота PubSubClient — это одновременно его плата и его бонус: клиент не держит очередь исходящих с packet-id, потому что исходящих с подтверждением у него нет, и RAM на это не тратится. Клиенты с полноценным QoS 1/2 исходящих — AsyncMqttClient, стек ESP-IDF — платят за гарантии памятью, колбэками и очередями ретрансмиссий. Буфер входящих пакетов и его пресловутые 256/512 байт — отдельная история, разобранная в уроке про буфер 512.

Сетка, которую применяю без размышлений. QoS 0 — всё, что повторяется: телеметрия чаще раза в 10 секунд, пульсы, статусы с retain, логи. QoS 1 — то, что должно доехать при живом соединении: команды реле, и подписка на команды в PubSubClient ставится на первый уровень ровно поэтому. QoS 2 — не использую: единственное место, где я его видел вживую, — платный шлюз оператора, а не дом. Если сообщение обязано дождаться офлайн-клиента, это решается не уровнем QoS, а retained-сообщением и восстановлением после рестарта — механика в уроке про рестарт, и тот же принцип прикрывает команды сценам: сценарий описывает целевое состояние, а не цепочку переключений, а про паузы между попытками reconnect — в уроке про backoff. Свежую проверку здоровья я собираю дешево: узел публикует счётчик uptime раз в минуту, панель краснеет, когда счётчик замер, — у тишины нет пакета, который можно было бы гарантировать.

Теперь цена в байтах на проводе. К MQTT-пакету транспорт добавляет свои шубы: 20 байт IPv4, 20 байт TCP, поверх Ethernet — ещё 18 с преамбулой и кадром. Телеметрический пакет QoS 0 на 26 байт выезжает в сегмент примерно на 84 байта; подтверждение QoS 1 — ещё один такой сегмент в ответ, и на вялой сети это десятки миллисекунд ожидания на каждое сообщение. QoS 2 умножает всё на четыре и добавляет состояние транзакции в куче. И не байтами едиными: каждый лишний пакет — проход loop() через обработку входящих, а на слабой плате при потоке сообщений именно этот бюджет цикла и кончается. Суточная арифметика узла с пульсом: 1440 сообщений QoS 0 — сотня с небольшим килобайт в эфире, те же сообщения с QoS 2 — под полмегабайта и ворох лишних пробуждений радио.

Отсюда пропорция, которую я вывел на своём брокере: переход QoS 0 → QoS 1 — примерно двойная цена одного сообщения в эфире плюс одна RTT задержки; QoS 1 → QoS 2 — ещё двойная сверху. Платите её только там, где дубликат или потеря ломают логику, а не график. И не путайте уровни с постоянной сессией: доставка офлайн-клиенту — механизм брокера, а не QoS, и помеченный retain итог спасает офлайн лучше любого уровня.