Производительность MQTT по сравнению с TLS против MQTT

Хотя MQTT довольно универсален, он также не защищен сам по себе. Это по замыслу.

По словам Стэнфорд-Кларка, безопасность изначально была сознательно исключена из протокола, потому что он и Ниппер знали, что механизмы безопасности могут быть обернуты вокруг MQTT для повышения безопасности. Кроме того, в то время Стэнфорд-Кларк сказал, что информация, отправляемая через MQTT, например данные о скорости ветра с метеостанции, не нуждается в особой защите. - Источник

Одним из тех механизмов безопасности, которые можно обернуть вокруг MQTT, является TLS. Большинство брокеров поддерживают это в настоящее время. Конечно, любая мера оборачивания производит накладные расходы. Эти издержки могут быть незначительными (см. Блог HiveMQ ).

В настоящее время я ищу информацию (надеюсь, авторитетный источник) о потере производительности MQTT по сравнению с TLS по сравнению с простым MQTT, чтобы оценить жизнеспособность MQTT для моего проекта. Особенно, когда технология масштабируется на большое количество подписчиков.

Есть ли способ, кроме прототипирования, чтобы получить достоверные данные о производительности MQTT над TLS?

Я не ожидаю, что разница будет слишком значительной, как только соединение будет установлено .

Разбивка накладных расходов, которые TLS производит в целом, может быть найдена здесь . Важные биты:

• Общая нагрузка на создание нового сеанса TLS составляет в среднем около 6,5 тыс. Байт.
• Общая нагрузка на возобновление существующего сеанса TLS составляет в среднем около 330 байт.
• Общий объем служебных данных зашифрованных данных составляет около 40 байтов (20 + 15 + 5).
• Вышеприведенные вычисления легко изменить, чтобы более точно отразить специфику среды, поэтому это следует рассматривать как основу для издержек TLS, а не как авторитетный ответ на поставленный вопрос.

Стоит прочитать, чтобы увидеть, как были рассчитаны эти цифры - вы должны лучше понять, как TLS работает со всем этим. Как отмечалось в других ответах, радиопередача, вероятно, является одним из самых больших видов использования энергии, что часто является ограничением в IoT, поэтому после установления сеанса накладные расходы не слишком значительны, особенно если ваши сообщения нетривиально коротко.

Как отмечает HiveMQ в статье Как TLS влияет на производительность MQTT? :

Хорошая новость заключается в том, что клиенту MQTT необходимо устанавливать соединение только один раз за сеанс - в отличие от протоколов, таких как HTTP, которым необходимо восстанавливать соединение при каждом запросе (если не используется keep-alive или другие методы, такие как Long). Опрос на месте). После подключения к брокеру клиент может отправлять и получать сообщения без дополнительных затрат на рукопожатие. Использование TLS требует выделения дополнительных буферов, поэтому потребление ОЗУ также немного выше для каждого соединения MQTT.

Они также предоставляют график загрузки ЦП в брокере при подключении 50 000 клиентов:

^{Источник изображения: HiveMQ (см. Ссылку выше)}

Обратите внимание, что это почти наверняка не типичный шаблон использования, но данные, тем не менее, интересны. Как вы можете видеть, во время квитирования возникают большие издержки, но после этого нагрузка на процессор практически одинакова. Я ожидаю, что аналогичная вещь на клиенте.

Тем не менее, общий совет здесь верен: надуманный тест не даст вам информацию, которая вам действительно нужна; чтобы узнать, как TLS повлияет на ваш вариант использования, вам нужно проверить его в ... вашем варианте использования !

Не совсем, вам придется протестировать и сравнить вашу конкретную ситуацию. Следующее может оказать непосредственное влияние на производительность.

• Какое клиент / брокерское оборудование вы используете, имеет ли оно какое-либо аппаратное ускорение для криптографии?
• Каков размер полезной нагрузки, которую вы отправляете?
• Каков профиль подключения / переподключения для вашего приложения?

Сделать полезные оценки производительности сложно. Вполне вероятно, что вашему приложению потребуется шифрование, по крайней мере, для части его трафика, поэтому вряд ли будут какие-либо затраты на реализацию, чтобы обеспечить безопасность для этого подмножества трафика.

Для реализации с ограничением энергии передача, вероятно, будет беспроводной. Даже при наличии подходящего радиоканала затраты энергии на настройку канала и согласование соединения могут перевесить стоимость обработки для шифрования простого сообщения, особенно если некоторые сообщения нуждаются в шифровании.

Если ваши сообщения нетривиальны, может быть некоторое оправдание в выполнении большей обработки в конечной точке для уменьшения сетевого трафика.

Наконец, в сценарии, когда канал сильно загружен, производительность может быть не такой хорошей, как вы ожидаете от анализа более тривиальной реализации вашей полной системы.

Даже если вы можете найти справочную информацию для данных, которые вы ищете, вряд ли вы ответите на этот вопрос в достаточной мере, чтобы его было достаточно для принятия проектных решений.