Wydajność MQTT w porównaniu z TLS vs. MQTT

Chociaż MQTT jest dość wszechstronny, nie jest również zabezpieczony sam w sobie. To jest z założenia.

Według Stanforda-Clarka początkowo świadomie pominięto zabezpieczenia, ponieważ on i Nipper wiedzieli, że mechanizmy bezpieczeństwa można łączyć wokół MQTT w celu zwiększenia bezpieczeństwa. Ponadto w tym czasie Stanford-Clark powiedział, że informacje przesyłane za pośrednictwem MQTT, takie jak dane prędkości wiatru ze stacji pogodowej, nie wymagają szczególnej ochrony. - Źródło

Jednym z tych mechanizmów bezpieczeństwa, które można łączyć wokół MQTT, jest TLS. Większość brokerów obsługuje to obecnie. Oczywiście każdy środek owijający powoduje powstanie kosztów ogólnych. Narzut ten może być nieistotny (por. Blog HiveMQ ).

Obecnie szukam informacji (mam nadzieję, że to wiarygodne źródło) na temat utraty wydajności MQTT w porównaniu z TLS w porównaniu do zwykłego MQTT, aby ocenić wykonalność MQTT dla mojego projektu. Zwłaszcza, gdy technologia skaluje się do dużej liczby subskrybentów.

Czy istnieje sposób oprócz prototypowania, aby uzyskać prawidłowe dane dotyczące wydajności MQTT w porównaniu z TLS?

Nie spodziewałbym się, że różnica będzie zbyt znacząca po skonfigurowaniu połączenia .

Podział napowietrznej że TLS produkuje w ogóle można znaleźć tutaj . Ważne bity to:

• Całkowity narzut związany z ustanowieniem nowej sesji TLS wynosi średnio około 6,5 tys. Bajtów
• Całkowity narzut związany z wznowieniem istniejącej sesji TLS wynosi średnio około 330 bajtów
• Całkowity narzut zaszyfrowanych danych wynosi około 40 bajtów (20 + 15 + 5)
• Łatwo jest zmodyfikować powyższe obliczenia, aby dokładniej odzwierciedlić specyfikę środowiska, dlatego należy to uznać za podstawę do narzutu TLS, a nie autorytatywną odpowiedź na postawione pytanie.

Warto przeczytać, jak obliczono te liczby - powinieneś lepiej zrozumieć, w jaki sposób TLS działa z tym wszystkim. Jak zauważono w innych odpowiedziach, transmisja radiowa prawdopodobnie będzie jednym z największych zastosowań energii, co często stanowi ograniczenie w IoT, więc po ustanowieniu sesji narzut nie jest zbyt znaczący, szczególnie jeśli wiadomości są nie trywialnie krótki.

Jak zauważył HiveMQ w artykule Jak TLS wpływa na wydajność MQTT? :

Dobrą wiadomością jest to, że klient MQTT musi nawiązywać połączenie tylko raz na sesję - w przeciwieństwie do protokołów takich jak HTTP, które muszą ponownie ustanawiać połączenie przy każdym żądaniu (jeśli nie jest używane utrzymanie aktywności lub inne techniki, takie jak Long Ankiety są na miejscu). Po połączeniu z brokerem klient może wysyłać i odbierać wiadomości bez dodatkowego obciążenia związanego z uzgadnianiem. Korzystanie z TLS wymaga przydzielenia dodatkowych buforów, więc zużycie pamięci RAM jest również nieco wyższe na połączenie MQTT.

Zapewniają również wykres wykorzystania procesora w brokerze, gdy łączy się 50 000 klientów:

^{Źródło obrazu: HiveMQ (patrz wyżej powiązany artykuł)}

Pamiętaj, że prawie na pewno nie jest to typowy wzorzec użytkowania, ale dane są jednak interesujące. Jak widać, podczas uzgadniania istnieje duży narzut, ale potem obciążenie procesora jest prawie identyczne. Oczekiwałbym czegoś podobnego od klienta.

Jednak ogólna rada tutaj jest poprawna: wymyślony punkt odniesienia nie dostarczy ci informacji, których naprawdę potrzebujesz; aby wiedzieć, jak TLS wpłynie na twój przypadek użycia, musisz go przetestować w ... swoim przypadku użycia !

Nie bardzo, będziesz musiał przetestować i porównać swoją sytuację. Następujące czynniki mogą mieć bezpośredni wpływ na wydajność.

• Jakiego sprzętu klienta / brokera używasz, czy ma jakieś przyspieszenie sprzętowe dla kryptografii?
• Jaka jest wielkość wysyłanego ładunku?
• Jaki jest profil Connect / Reconnect dla Twojej aplikacji?

Przydatne oszacowania wydajności są trudne. Jest prawdopodobne, że aplikacja będzie wymagać szyfrowania przynajmniej dla części ruchu, więc nie będzie żadnych kosztów wdrożenia, aby zapewnić bezpieczeństwo dla tego podzbioru ruchu.

W przypadku implementacji z ograniczoną energią transmisja prawdopodobnie będzie bezprzewodowa. Nawet przy odpowiednim kanale radiowym koszt energii związany z ustanowieniem kanału i negocjowaniem połączenia prawdopodobnie przewyższy koszt przetwarzania zaszyfrowania prostej wiadomości - szczególnie jeśli niektóre wiadomości wymagają szyfrowania.

Jeśli wiadomości nie są trywialne, może być uzasadnione wykonywanie większej liczby operacji w punkcie końcowym w celu zmniejszenia ruchu w sieci.

Wreszcie, w scenariuszu, w którym kanał jest mocno obciążony, wydajność może nie być tak dobra, jak można się spodziewać po analizie bardziej trywialnej implementacji pełnego systemu.

Nawet jeśli możesz znaleźć odniesienie do poszukiwanych danych, jest mało prawdopodobne, aby odpowiedzieć na wystarczające pytanie, aby było wystarczające do podjęcia decyzji projektowych.