Jakie są zalety protokołu MQTT w porównaniu z tradycyjnym protokołem HTTP

HTTP jest najszerzej stosowanym i najpopularniejszym protokołem. Jednak MQTT szybko zyskał na popularności w ciągu ostatnich kilku lat. Podczas omawiania rozwoju IoT, deweloperzy muszą wybierać między tymi dwoma.

MQTT koncentruje się na danych, podczas gdy HTTP koncentruje się na dokumentach. HTTP to protokół żądanie-odpowiedź dla obliczeń klient-serwer, który nie zawsze jest zoptymalizowany pod kątem urządzeń mobilnych. W tym kontekście głównymi Zaletami MQTT są: lekkość (MQTT przesyła dane w formie tablic bajtów) i model publikuj/subskrybuj, co sprawia, że MQTT jest bardzo odpowiedni dla urządzeń o ograniczonych zasobach i pomaga oszczędzać baterię. Ponadto model publikuj/subskrybuj umożliwia klientom niezależność od siebie, zwiększając tym samym niezawodność całego systemu. W przypadku awarii klienta cały system nadal działa normalnie.

Istnieje nadal wiele zalet MQTT, takich jak:

1. Niskie obciążenie protokołu, MQTT jest wyjątkowe, ponieważ jego nagłówek na wiadomość może mieć zaledwie 2 bajty. Zarówno MQ, jak i HTTP mają znacznie wyższe obciążenie na wiadomość. W przypadku HTTP ponowne nawiązanie połączenia HTTP dla każdej nowej wiadomości żądania wiąże się ze znacznym obciążeniem. Trwałe połączenia używane przez MQ i MQTT znacznie zmniejszają to obciążenie.

2. Tolerancja na niestabilne sieci, MQTT i MQ mogą odzyskać się po awariach, takich jak rozłączenie, i nie ma dalszych wymagań dotyczących kodu. Jednak HTTP nie może tego zrobić natywnie, wymagając od klientów ponownej próby kodowania, co może zwiększyć problemy z idempotentnością.

3. Niskie zużycie energii, MQTT jest specjalnie zaprojektowane do niskiego zużycia energii. HTTP nie zostało zaprojektowane tak, aby to uwzględnić, co zwiększa zużycie energii.

4. Klienci z milionami połączeń na stosie HTTP, utrzymanie milionów równoczesnych połączeń wymaga dużo pracy, aby zapewnić obsługę. Chociaż ta obsługa jest możliwa, większość komercyjnych produktów jest zoptymalizowana do obsługi trwałych połączeń tego rzędu wielkości. IBM oferuje IBM MessageSight, pojedynczy serwer montowany w szafie, który został przetestowany pod kątem obsługi do 1 miliona jednocześnie podłączonych urządzeń przez MQTT. Natomiast MQTT nie jest przeznaczony dla dużej liczby równoczesnych klientów.

5. Powiadomienia push, musisz być w stanie dostarczać powiadomienia klientom w odpowiednim czasie. W tym celu należy zastosować pewien rodzaj okresowego sondowania lub push; push jest najlepszym rozwiązaniem z perspektywy baterii, obciążenia systemu i przepustowości.

Nasza firma może potrzebować wysyłać poufne informacje bez pośrednictwa strony trzeciej. Zmniejsza to wartość rozwiązań specyficznych dla systemu operacyjnego (takich jak powiadomienia Apple iOS, Google Play) jako głównego mechanizmu transportu.

HTTP pozwala tylko na jedną metodę zwaną COMET, wykorzystującą trwałe żądania HTTP do wykonywania push. To podejście jest kosztowne zarówno z perspektywy klienta, jak i serwera. Zarówno MQ, jak i MQTT obsługują push jako podstawową cechę.

6. Różnice platform klienckich, zarówno klienci HTTP, jak i MQTT zostali zaimplementowani na wielu platformach. Prostota MQTT pomaga zaimplementować MQTT na dodatkowych klientach przy bardzo niewielkim wysiłku.

7. Tolerancja błędów zapory, niektóre korporacyjne zapory ograniczają połączenia wychodzące do niektórych zdefiniowanych portów. Porty te są zwykle ograniczone do HTTP (port 80), HTTPS (port 443) itp. HTTP oczywiście może działać w takich sytuacjach. MQTT można zawinąć w połączenie WebSockets, które pojawia się jako żądanie uaktualnienia HTTP, umożliwiając działanie w tych przypadkach. MQTT nie zezwala na ten wzorzec.

W porównaniu do HTTP, protokół MQTT gwarantuje wysoką szybkość transferu. Istnieją trzy poziomy jakości usług:

A. Najwyżej raz: Spróbuj zapewnić dostarczenie.

B. Przynajmniej raz: Upewnij się, że wiadomość e-mail została wysłana przynajmniej raz, ale wiadomość może być również dostarczona więcej niż raz.

C. Tylko raz: Upewnij się, że każda wiadomość zostanie odebrana tylko raz przez drugą stronę.

W rzeczywistości protokół MQTT jest szeroko stosowany. Można go znaleźć w niemal każdej dużej firmie sprzętowej i internetowej, takiej jak Facebook, BP, Alibaba, Baidu itp.

Ze względu na różne techniczne zalety samego protokołu MQTT coraz więcej firm wybiera protokół MQTT jako standardowy protokół komunikacji produktów IoT. Dlatego inżynierowie stopniowo odkryli, że protokół MQTT ma pewne funkcje, które należy ulepszyć, jeśli ma zostać skomercjalizowany na dużą skalę. na przykład:

1. Nie ma kompletnego zestawu SDK, a różne heterogeniczne terminale potrzebują odpowiednich pakietów oprogramowania SDK do komunikacji z serwerem MQTT. Na przykład, aby osiągnąć połączenie między MCU, Linux, Android, IOS, WEB itp., muszą być wymagane różne pakiety SDK.

2. Pliki i AV nie są obsługiwane. W niektórych scenariuszach aplikacji informacje do przesłania mogą nie być ograniczone do instrukcji, takich jak sygnały audio i sygnały wideo, które muszą komunikować się za pośrednictwem plików i AV.

3. Nie obsługuje integracji z zewnętrznym protokołem HTTP. Mimo żeh protokół MQTT jest lepszy od zwykłego protokołu HTTP, serwery WEB oparte na tradycyjnym protokole HTTP nadal zajmują główny rynek, więc te serwery muszą realizować połączenie z protokołem MQTT, aby zmniejszyć liczbę uaktualnień. Koszt jest również krytyczny.

4. Nie obsługuje równoważenia obciążenia. Aby zapobiec wysokiej współbieżności i złośliwym atakom, niezbędny jest również serwer równoważenia obciążenia.

5. Nie obsługuje interfejsu zarządzania użytkownikami. Szczególnie ważne jest, aby użytkownicy analizowali dane dotyczące zachowania urządzenia, co jest nieuniknionym wymogiem Przemysłu 4.0 i ery dużych danych.

6. Nie obsługuje wiadomości offline i rekompensuje problem utraty przez serwer MQTT informacji sterujących urządzeniem po przejściu urządzenia w tryb offline.

7. Komunikacja typu punkt-punkt nie jest obsługiwana, a przyjęty jest standardowy protokół MQTT. Teoretycznie komunikacja typu punkt-punkt może być realizowana poprzez wzajemną subskrypcję, ale logika jest stosunkowo skomplikowana i istnieją obawy dotyczące bezpieczeństwa urządzenia. Gdy urządzenie B i urządzenie C są na tym samym temacie, urządzenie A nie może wiedzieć, czy to urządzenie B czy urządzenie C wysłało wiadomość, a także możliwe jest, że wiadomość została podsłuchana przez urządzenie D.

8. Nie obsługuje komunikacji grupowej i zarządzania grupą, a realizuje zarządzanie członkami grupy, a członkowie grupy mogą się ze sobą komunikować. W scenariuszu, w którym jedno urządzenie jest kontrolowane przez wiele osób lub wiele urządzeń jest kontrolowanych przez jedną osobę, jest to szczególnie przydatne.