Продуктивність 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, який потребує відновлення з'єднання під час кожного запиту (якщо не використовується жодна підтримка чи інші методи, наприклад Long Опитування на місці). Підключившись до брокера, клієнт може надсилати та отримувати повідомлення без додаткових рукостискань. Для використання TLS необхідно виділити додаткові буфери, тому споживання оперативної пам’яті також трохи вище за з'єднання MQTT.

Вони також надають графік використання процесора для брокера, коли 50 000 клієнтів підключаються:

^{Джерело зображення: HiveMQ (див. Вище зв'язану статтю)}

Зауважте, що це майже точно не є типовою схемою використання, але дані все-таки цікаві. Як бачите, під час рукостискання великі накладні витрати, але після цього накладні витрати процесора майже однакові. Я б очікував подібного на клієнта.

Але загальна порада тут правильна: надуманий орієнтир не дасть тобі потрібної інформації; щоб знати, як TLS вплине на ваш випадок використання, вам потрібно протестувати його у ... вашому випадку використання !

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

• Яке обладнання для клієнта / брокера ви використовуєте, чи має апаратне прискорення для криптовалюти?
• Який розмір корисного навантаження ви надсилаєте?
• Який профіль підключення / відновлення з'єднання для вашої програми?

Складати корисні оцінки ефективності важко. Цілком імовірно, що вашій програмі буде потрібно шифрування принаймні деякого її трафіку, тому навряд чи є якісь кошти на впровадження, щоб забезпечити доступність безпеки для цього підмножини трафіку.

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

Якщо ваші повідомлення нетривіальні, може бути певне обґрунтування для виконання більшої обробки в кінцевій точці, щоб зменшити мережевий трафік.

Нарешті, у сценарії, коли канал сильно завантажений, продуктивність може виявитися не такою хорошою, як ви очікуєте від аналізу більш тривіальної реалізації вашої повної системи.

Навіть якщо ви зможете знайти посилання на дані, які ви шукаєте, навряд чи відповісти на це питання достатньо, щоб ґрунтуватися на проектних рішеннях.