Protokół MQTT – zasilanie komunikatora na Facebooku do urządzeń IoT

Streszczenie:

Wiadomości błyskawiczne lub komunikacja w czasie rzeczywistym: za sceną

Dla wielu osób, zwłaszcza osób pracujących z węzłem.JS, komunikacja w czasie rzeczywistym (RTC) może wydawać się znajome. Aplikacje czatowe zbudowane za pomocą węzła.JS stały się wspólnym punktem wyjścia dla programistów. Jednak osiągnięcie prawdziwej komunikacji w czasie rzeczywistym nie jest tak łatwe, jak mogłoby się wydawać. W tym artykule przedstawię przegląd problemów praktycznych, przed którymi stoją główne firmy, takie jak Facebook, Slack, Discord i Telegram w kontaktach z RTC.

Zauważ, że ten artykuł koncentruje się wyłącznie na RTC i nie obejmuje takich tematów, jak projektowanie systemu lub kodowanie systemu bazy danych.

Kluczowe punkty:

1. Komunikacja w czasie rzeczywistym jest nadal trudnym tematem ze względu na niestabilną łączność sieciową i inne problemy.

2. Zrozumienie podstawowych pojęć, takich jak komunikacja dwustronna, WebSocket, zdarzenia Server-Sent, krótkie/długie ankiety i MQTT jest niezbędne dla RTC.

3. Analiza danych wymienianych między przeglądarkami i serwerami głównych aplikacji czatu może zapewnić cenne informacje.

4. Facebook Messenger używa MQTT przez WebSocket do wysyłania/odbierania wiadomości, pisania i innych funkcji.

5. Instagram wykorzystuje również MQTT przez WebSocket, ale z dodatkowymi wywołaniami interfejsu API dla funkcji takich jak wyświetlanie wiadomości i listy użytkowników.

6. Telegram opiera się wyłącznie na WebSocket dla wszystkich swoich funkcji.

7. Slack i Discord łączą WebSocket i API wywołania różnych funkcji.

8. Zalo używa długiego ankiet API i HTTP do odbierania wiadomości i innych funkcji.

9. Duże firmy mocno polegają na WebSocket/TCP w celu komunikacji w czasie rzeczywistym.

10. Łączenie WebSocket z wywołaniami API ułatwia skalowanie i zarządzanie systemem.

Pytania:

1. Jakie technologie wykorzystują Facebook Messenger i Instagram do komunikacji w czasie rzeczywistym?

Zarówno Facebook Messenger, jak i Instagram używają MQTT przez WebSocket do komunikacji w czasie rzeczywistym.

2. Jakie są funkcje obsługiwane przez system komunikacji w czasie rzeczywistym Facebooka Messenger?

System komunikacji w czasie rzeczywistym Facebooka obsługuje takie funkcje, jak wysyłanie/odbieranie wiadomości, pisanie i żądania.

3. Czym różni się system komunikacji w czasie rzeczywistym na Instagramie od komunikatu Facebooka?

Podczas gdy Instagram używa również MQTT przez WebSocket do komunikacji w czasie rzeczywistym, dodatkowo opiera się na wywołania interfejsu API dla funkcji, takich jak przeglądanie wiadomości i list użytkowników.

4. Która technologia wykorzystuje telegram do komunikacji w czasie rzeczywistym?

Telegram opiera się wyłącznie na WebSocket dla wszystkich funkcji komunikacji w czasie rzeczywistym.

5. Jak działa system komunikacji w czasie rzeczywistym Slack?

Slack łączy połączenia WebSocket i API, aby włączyć wiadomość i pisać w czasie rzeczywistym, a także funkcjonalność, takie jak wyświetlanie elementów i wysyłanie wiadomości.

6. Jaka jest technologia systemu komunikacji w czasie rzeczywistym Discord?

System komunikacji w czasie rzeczywistym w czasie rzeczywistym wykorzystuje wezwania WebSocket i API do odbierania wiadomości, wyświetlania elementów, wysyłania wiadomości, pisania i widocznej funkcjonalności.

7. Jak Zalo radzi sobie z komunikacją w czasie rzeczywistym?

Zalo używa kombinacji interpretacji API i HTTP w celu komunikacji w czasie rzeczywistym. Obsługuje funkcje, takie jak odbieranie wiadomości, wyświetlanie elementów, wysyłanie wiadomości, pisanie i widoczne funkcje.

8. Na czym wielkie firmy polegają na komunikacji w czasie rzeczywistym?

Duże firmy mocno polegają na WebSocket/TCP w celu komunikacji w czasie rzeczywistym.

9. Jakie zalety łączą WebSocket z ofertą połączeń API?

Łączenie WebSocket z wywołaniami API ułatwia skalowanie i zarządzanie systemem komunikacji w czasie rzeczywistym. Połączenia API mogą być używane do wysyłania wiadomości od klientów i mogą wykorzystywać istniejące warstwy oprogramowania pośredniego do uwierzytelniania, autoryzacji i ograniczania stawek.

10. Dlaczego niektóre firmy używają połączenia połączeń WebSocket i API?

Korzystanie zarówno z połączeń WebSocket, jak i API pozwala firmom wykorzystać skalowalność interfejsów API HTTP dla niektórych funkcji, jednocześnie ciesząc się korzyściami Web. Dodatkowo umożliwia ponowne wykorzystanie istniejących warstw oprogramowania pośredniego i upraszcza proces skalowania.

11. Dlaczego system komunikacji w czasie rzeczywistym na Instagramie różni się od komunikatora Facebooka?

Instagram został początkowo opracowany osobno od Facebooka, a później został nabyty. Dlatego mogą występować różnice w systemach synchronizacji używanych przez Facebook (oparty na WebSocket) i istniejący system Instagrama.

12. Jakie jest znaczenie zrozumienia podstawowych pojęć, takich jak WebSocket i MQTT dla komunikacji w czasie rzeczywistym?

Podstawowe pojęcia, takie jak WebSocket i MQTT, są niezbędne do zrozumienia komunikacji w czasie rzeczywistym i umożliwiają programistom budowanie bardziej wydajnych i niezawodnych systemów.

13. Jak samouczki do budowania aplikacji czatu za pomocą węzła.JS pomagają programistom?

Samouczki na temat budowy aplikacji czatu za pomocą węzła.JS zapewnia programistom niezbędną pewność siebie, aby rozpocząć podróż do komunikacji w czasie rzeczywistym. Powinny jednak zdawać sobie sprawę, że budowanie prawdziwego systemu komunikacji w czasie rzeczywistym obejmuje przezwyciężenie różnych wyzwań.

14. Dlaczego skalowanie serwera WebSocket jest zadaniem nietrywialnym?

Skalowanie serwera WebSocket jest zadaniem nietrywialnym, ponieważ WebSocket jest stanowym protokołem komunikacji, który wymaga otwarcia pojedynczego trwałego połączenia. Podczas gdy WebSocket jest wydajny do wysyłania wiadomości z serwerów do klientów, używanie ich do innych zadań logicznych, takich jak nagrywanie wiadomości od klientów, może być trudne.

15. Jaki jest cel sprawdzania danych wymienianych między przeglądarkami i serwerami głównych aplikacji czatu?

Sprawdzanie danych wymienianych między przeglądarkami i serwerami głównych aplikacji czatu pozwala programistom uzyskać wgląd w praktyczną wdrożenie komunikacji w czasie rzeczywistym i uczyć się z istniejących systemów.

Protokół MQTT – zasilanie komunikatora na Facebooku do urządzeń IoT

Ładunki wiadomości są kodowane w binarie. W otwartej sieci, w której odbiorca pochodzi od innego producenta, będzie miał problemy z dekodowaniem go, ponieważ nie ma informacji na temat kodowania ładunku wiadomości.

Wiadomości błyskawiczne lub komunikacja w czasie rzeczywistym: za sceną

Dla wielu ludzi, zwłaszcza facetów pracujących z węzłem.JS, ten temat nie jest całkiem nowy. Jest wiele samouczków takich jak “Utwórz prostą aplikację czatu za pomocą węzła.JS”, “Aplikacja czatu w czasie rzeczywistym za pomocą węzła.JS Express i gniazdo.io”, itp. Jakoś sprawiają, że aplikacje czatu stają się “Witaj świecie” dla każdego z nas, którzy chcą rozpocząć naszą podróż z węzłem.JS. Dobrą rzeczą w ich istnieniu jest zapewnienie ci pewności siebie. Do pewnego stopnia, w jaki sposób nie jesteś pewny siebie, jeśli jesteś w stanie zbudować coś takiego jak Facebook Messenger w tak krótkim czasie (może 1h może?)? Złe jest to To nie jest takie łatwe.

Faktem jest, że bez względu na to, ile wysiłku zaproponowano, komunikacja w czasie rzeczywistym (RTC) jest nadal gorącym tematem zarówno w branży, jak i akademickiej społeczności. Ze względu na wiele skutków poza kontrolą, pod względem niestabilnej łączności sieciowej, duplikatu/konfliktu, duplikat., Zdobycie prawdziwego doświadczenia w czasie rzeczywistym jest trudne (nie, to nie jest ten, który czujesz, jak kończenie samouczków ze sobą. W tym poście zapewnię przegląd problemów praktycznych, które zostały rozważane przez dużych facetów, takich jak Facebook, Slack, Discord, Telegram itp.

Zauważ, że dotyczy to tylko komunikacji w czasie rzeczywistym, sugerowałbym rozejrzenie się w podstawowych pojęciach, takich jak komunikacja 2-drogowa, WebSocket, zdarzenia serwera, krótkie/długie sondaż, MQTT. Ponadto nie chodzi o projektowanie systemu, wybór lub kodowanie systemu DB, tylko RTC.

Od dużych facetów

Co byś zrobił, gdyby twój szef poprosi Cię o zbudowanie systemu czatu takiego jak Facebook Messenger lub WhatsApp? Oto lista, przez którą możesz przejść:

• Znajdź samouczek?
• Ebook projektowy systemu
• Zaprojektuj aplikację do czatu dla milionów użytkowników edukacyjnych.io
• Mamy nadzieję, że blog inżynierii na Facebooku wyciekł coś w swojej pracy
• Google “Jak zrobić aplikację czatu” z ponad 3 miliardami wyników.

Ale istnieje niezbędny krok, który powinieneś zrobić, od samego początku lub po tych wszystkich krokach: Otwórz ich aplikację internetową, sprawdź dane wymienione między przeglądarkami i serwerami. To’S Co pokażę w następnej sekcji, na podstawie głównych funkcji backenda czatu:

• Wymień wątki, wyświetl wiadomości
• Wyślij wiadomość
• Odbierz wiadomość
• Pisanie na maszynie
• Widziany

Komunikator facebookowy

Technologia: MQTT przez WebSocket

Funkcja: Wyślij/odbieraj wiadomości, pisanie, żądanie itp. W całym WebSocket

Spójrz na dane odpowiedzi żądań WebSocket na ich Edge-Chat.posłaniec.com. Wszystkie żądania ładowania danych, listy elementów, wysyłania/odbierania wiadomości, pisania, są wykonywane za pośrednictwem wiadomości publikowania i subskrybowania WebSocket, a nie interfejsu API.

Instagram

Ta sama firma, a zatem te same technologie. Ale nie to samo pochodzenie, dlatego z pewną różnicą.

Technologia: MQTT przez WebSocket + API

Funkcja: wysyłaj/odbieraj wiadomości i wpisywanie na WebSocket, lista elementów, widziane, list użytkownika online itp. Over API.

Telegram

Technologia: WebSocket

Funkcja: W całym WebSocket

Luźny

Technologia: WebSocket + API

Funkcja: odbieraj wiadomości i wpisywaj na WebSocket, wymieniaj elementy, wysyłanie wiadomości przez API.

Niezgoda

Technologia: WebSocket + API

Funkcja: odbieraj wiadomości przez WebSocket, lista elementów, wysyłanie wiadomości, pisanie, widziane przez interfejs API.

Zalo

Technologia: API i HTTP długie ankiety

Funkcja: odbieraj wiadomości w stosunku do długiego ankiety HTTP, lista elementów, wysyłanie wiadomości, pisanie, widziane nad interfejsem API.

Nasza kolej

Więc wymyślimy kilka obserwacji:

• Duże faceci całkowicie polegają na WebSocket/TCP
• Niezbyt dużych facetów łączą WebSocket, aby odbierać wiadomości z serwera i interfejsu API, aby wysyłać wiadomości do serwera.
• Zalo Case – Nie mam pojęcia

Oto niektóre z moich myśli:

• Podczas gdy wydajność korzystania z WebSocket jest znacznie lepsza niż wywoływanie żądań HTTP, skalowanie serwera WebSocket jest zadaniem nietrywialnym, ponieważ jest to protokół stanowy, ponieważ utrzymuje jedno, trwałe połączenie otwarte. Dlatego służy tylko do wysyłania wiadomości do klientów. Jeśli używasz go do innych zadań logicznych, takich jak nagrywanie wiadomości od klientów, prosisz o zrobienie tego, czego nie ma robić.
• API HTTP jest przydatne do wysyłania wiadomości od klientów, ponieważ skalowanie interfejsów API bez statystyki jest znacznie łatwiejsze niż w skali WebSocket. Ponadto może ponownie wykorzystać istniejące warstwy oprogramowania pośredniego do uwierzytelnienia, autoryzacji, ograniczenia stawki itp.
• Dla tych, którzy mogą budować skalowalne systemy WebSocket, preferowane jest całkowicie przenieś żądania HTTP w celu korzystania z WebSocket w celu optymalizacji transmisji wiadomości. Wymaga synchronizacji całego mechanizmu żądania danych, nawet w przypadku zadań nierealistycznych.
• Zrozumiałe jest, że Instagram jest kupowany, a nie pierwotnie opracowywany przez Facebook, musi istnieć luka między Facebookiem’System synchronizacji S (oparty na WebSocket) i istniejący Instagram One.
• W przypadku aplikacji takich jak Slack, Discord, wykorzystują skalowalność interfejsów API HTTP i używają tylko WebSocket do wysyłania wiadomości z serwerów lub w przypadku wysokich żądań, takich jak pisanie.
• Podejście, które Zalo śledzi, można wyjaśnić 3 zaletami i) obsługując bardzo stare przeglądarki z długą kompatybilnością ankietową HTTP, a nie WebSocket, II) Web Zalo może być dodatkową wersją dla telefonu komórkowego Zalo, III) łatwiejsze do skalowania API niż WebSocket.

Następnym razem, jeśli usłyszysz, że ktoś sugeruje pełne korzystanie z WebSocket zarówno do wysyłania, jak i odbierania wiadomości, facet musi być:

• Albo nowy w wymaganiach w czasie rzeczywistym i brak praktycznego doświadczenia, a pod koniec dnia system jest trudny do skalowania i niezdolnego do obsługi, gdy popyt na ruch wzrasta.
• Lub bardzo bardzo doświadczenie w systemach na dużą skalę, takich jak Facebook lub Telegram.

Za kulisami

W tej ostatniej sekcji niech’s (teoretycznie) doświadczaj rzeczy (bóle w **), że nauczyciele ze strony świata nigdy nie mieli okazji ci powiedzieć.

Gniazdo elektryczne.io?

Ta biblioteka wydaje się być magiczną panaceum, ponieważ pomaga nam w nudnych zadaniach, takich jak konfigurowanie serwera, ping/ponga, utrzymuj, sesja sklepu, bla bla. Wszystko, co moglibyście zacząć od tego, jeśli pracuje z węzłem w czasie rzeczywistym.JS. Niestety, są rzeczy, z którymi będziesz się z tym zmagać.

• Brak mechanizmu QoS. Wkrótce doświadczysz dyskomfortu, gdy sieć po stronie klienta nie jest tak stabilna zgodnie z oczekiwaniami. Wiadomości są utracone, ponieważ łączność wciąż rośnie i w dół gniazdo elektryczne.io – bez gwarancji QoS może’t niech zaufanie.
• skalowanie? Gdy węzeł WebSocket zostanie przeciąkowany, skalujesz lub wycofasz. To’s co normalnie robisz, prawda? W tej chwili adapter Redis pojawi się na zdjęciu jako most wśród węzłów za pośrednictwem Pubsub Redis. Chodzi o to, że zliczanie mechanizmu wywołania zwrotnego PubSub zgodnie z liczbą węzłów fizycznych spowodowało kilka problemów przy dołączaniu do innych procesów, które emitują wiadomości. A także dlatego, że Redis PubSub jest używany na całym serwerze Redis zamiast numeru bazy danych, komunikaty z różnych środowisk można łatwo pomylić.
• Break wersji. Jak dotąd gniazdo.IO jest nadal w trakcie rozwoju, a niektóre funkcje są dostępne tylko w najnowszej wersji. W tej chwili go przyjęliśmy, części maszynopis i adapterów nie zostały zakończone i było wiele błędów w fazie rozwoju.
• Ack przez oddzwanianie. Nie mam’Tam jak oddzwonienie, to’S It. Używam tylko ogień I zapominać Wydarzenia, nie więcej, ponieważ nie mam’Myślę, że całkowicie jestem w stanie poradzić.
• Niestabilny ping/pong: Nawet przy dobrej łączności, gniazdo elektryczne.io Klient nadal często odłącza się po pewnym okresie, niezależnie od zmiany czasu ping/ponga lub zwiększającego limit czasu dla równoważenia obciążenia. Wszystkie te problemy zostały otwarte, a jeśli je masz, po prostu nie masz szczęścia.

Ogólnie, gniazdo elektryczne.io Wykonuje swoje zadanie na poziomie podstawowym. Aby przyjąć go w celu prawdziwego projektu o wymaganiach stabilności, wciąż jest wiele do wykonania, ja.mi. Gwarancja QoS, skalowanie, śledzenie tego śledzenia. Najtrudniejszą częścią jest synchronizacja stanu klienta i serwera, gdy nastąpi odłączenie.

MQTT

MQTT jest popularny w aplikacjach IoT ze względu. Został zaprojektowany z mechanizmem pub/sub-mechanizmu i ma dobre wbudowane funkcje, takie jak QoS, trwaczna sesja, ostatnia wiadomość. Jest to protokół używany przez Facebook do ich aplikacji w czasie rzeczywistym jako wspomniany-MQTT nad WebSocket.

Próbowaliśmy, ponieważ chcemy, aby nasza aplikacja dotarła na szczyt świata. Ale znowu to nie jest takie łatwe.

• Zmiana naszego sposobu myślenia. W MQTT nie ma żadnych koncepcji takich jak pokój lub backendy routingowe. Pokój ma na celu zarządzać na backend gniazdo elektryczne.io i ułatwia tworzenie pokoju czatowego, wstawienie nowych użytkowników i automatyczną emisję wiadomości do czatów. Dzięki MQTT musisz sam zarządzać pokój, emituj wiadomości do każdego tematu, ponieważ sposób, w jaki temat jest słuchany, zależy od klienta. Subskrypcja określonego tematu ma miejsce dopiero po ustanowieniu łączności, gdy masz ograniczone zmuszanie klientów do rezygnacji z subskrypcji lub subskrypcji nowych tematów.
• skalowanie? Nie, to tylko marketing lub reklama, jakkolwiek nazywasz, kiedy faceci tacy jak Mosquitto, Vernemq lub EMQ x mówią, że mogą bardzo dobrze skalować. Kiedy wypróbowaliśmy kilku z tych brokerów wiadomości dla klastrów o dużym zapotrzebowaniu na ruch, nadchodzi wiele problemów i są one zbyt bolesne, aby naprawić jeden po drugim. C’est la vie, używasz ich produktów, polegasz na nich, a jeśli nie będą’nie naprawić problemu, co możemy powiedzieć?
• Połączenie konfliktu. To jest bardzo trudne po stronie klienta. Aby wykorzystać funkcję trwałej sesji, musimy utrzymać niezmienione identyfikatory klienta-co jest trudnym zadaniem, jeśli aplikacja nie jest dobrze zakodowana. Wiele razy, chociaż zdefiniowano tylko 1 instancję połączenia MQTT, tak naprawdę nie mieliśmy pojęcia, jak do diabła może istnieć kilka instancji z tym samym identyfikatorem. W rezultacie klienci kopią się nawzajem i żaden z nich nie może się połączyć. W takich przypadkach nikt inny niż faceci z frontend.
• Bezpieczeństwo. Trudniej jest spełnić wymagania bezpieczeństwa dla systemu MQTT i dla gniazdo elektryczne.io Po pierwsze, głównie z powodu organizacji tematu i wzoru subskrybowania.

Jeśli zauważysz, możesz dowiedzieć się, że MQTT jest bardziej wrażliwy niż podejście API. Kwestie bezpieczeństwa pochodzą nie tylko z naszej implementacji, ale także z brokerów wiadomości z trzeciej strony. Problem bezpieczeństwa na EMQ X pozwalający ominąć autoryza. Przynajmniej wdrożenie MQTT poprawia niezawodność naszego systemu czatu, unika brakujących wiadomości jak wcześniej.

Wniosek

Komunikacja w czasie rzeczywistym jest trudnym problemem i wymaga dużo wiedzy i doświadczenia. Ten sam wymóg, i.mi. “Wysłannik taki jak Facebook” Można to zrobić w 1h, 3h, a także kilka lat w zależności od sytuacji.

Uznawać

Chciałbym wysłać wielkie podziękowania Quang Minh (A.k.Minh Monmen) na zgodę na przetłumaczenie jego oryginalnego postu.

Protokół MQTT – zasilanie komunikatora na Facebooku do urządzeń IoT

UDZIAŁ

• LinkedIn
• Świergot
• Facebook Instagram -> Google+ GooglePlus -> Copy ->

W 2011 roku Lucy Zhang, Ben Davenport i Jon Perlow dołączyli do Facebooka i zaczęli budować komunikatora na Facebooku. Główną przeszkodą w ich wysiłku było od dawna opóźnienie podczas wysyłania wiadomości. Metoda, której używali do wysyłania wiadomości, była niezawodna, ale powolna. Byli również w stanie to zoptymalizować do pewnego stopnia. Kilka tygodni przed uruchomieniem badali protokół przesyłania protokołu Telemetry Transport (MQTT). Z pomocą MQTT Lucy Zhang i Team byli w stanie nawiązać i utrzymywać trwałe połączenie z serwerami Facebooka bez zmniejszania żywotności baterii.

Więc czym jest protokół MQTT?

Utworzony w 1999 roku przez Dr. Andy Stanford-Clark z IBM i Arlen Nipper z ARCOM, MQTT to lekki protokół przesyłania wiadomości oprócz protokołu TCP/IP. MQTT jest zaprojektowany dla urządzeń ograniczonych (urządzenia o niskiej pamięci i przepustowości sieci) oraz sieci bezprzewodowych o różnych poziomach opóźnień z powodu niewiarygodnego połączenia.

MQTT Protocol to klient-serwer, wydawca/subskrybent, otwarty i lekki protokół transportu przesyłania wiadomości. Sercem MQTT jest centralny punkt komunikacji znany jako broker MQTT. Odpowiada za rozproszenie wiadomości do prawowitych klientów.

Każdy klient, który publikuje wiadomość do brokera MQTT, zawiera informacje o routingu, znane jako temat. Klienci mogą subskrybować wiele tematów i brokerować wszystkie opublikowane wiadomości pasujące do tematu. Klienci nie’T muszą się znać, aby otrzymywać informacje; muszą po prostu zasubskrybować odpowiednie tematy.

Na przykład wyobraź sobie prostą sieć trzech klientów, ja.E A, B i C, gdzie każdy jest podłączony do brokera za pośrednictwem połączenia TCP. Klient-B i Client-C Subskrybuj temat: Temperatura.

Klient-A publikuje 34.5 dla temperatury tematu. Broker identyfikuje to i przekazuje tę wiadomość wszystkim subskrybentom, które w tym przypadku to klient-B i Client-C.

Architektura MQTT wydawcy-subscriber sprawia, że ​​jest to wysoce skalowalne rozwiązanie, bez tworzenia zależności między producentami danych a konsumentami.

Format wiadomości protokołu MQTT

Wszystkie wiadomości MQTT mają mały kod ślad, dlatego jest popularny jako lekki protokół przesyłania wiadomości. Każda wiadomość MQTT składa się z następujących:

• Naprawiono nagłówek (2 bajty)
• Opcjonalny nagłówek zmiennej
• Ładunek wiadomości (

• Poziom jakości usług (QoS)

MQTT obsługuje komunikację jeden do jednego, jeden do wielu i wiele do wielu.

Obniżając ilość przesyłanych danych, MQTT stanowi idealny protokół dla ograniczonych urządzeń IoT.

Ładunki wiadomości są kodowane w binarie. W otwartej sieci, w której odbiorca pochodzi od innego producenta, będzie miał problemy z dekodowaniem go, ponieważ nie ma informacji na temat kodowania ładunku wiadomości.

Poziom jakości usług (QoS) dla protokołu MQTT

Jakość poziomów usług określa sposób zarządzania treścią. MQTT używa trzech różnych poziomów QoS. Ważne jest, aby wybrać odpowiedni poziom QoS dla każdej wiadomości, ponieważ określa, w jaki sposób klient i serwer komunikują się, aby dostarczyć wiadomość. Poziomy QoS MQTT są następujące:

• QoS 0 : Wiadomości dostarczane zgodnie z najlepszymi wysiłkami środowiska operacyjnego, ale może wystąpić utrata wiadomości
• QoS 1 : Zapewnienie wiadomości, ale można utworzyć duplikaty
• QoS 2 : Wiadomość, aby dostarczyć dokładnie raz

MQTT zapewnia nam opcję ustawienia odpowiedniego poziomu QoS, ale pamiętaj, Wyższe QoS, obniżyć wydajność .

Bezpieczeństwo protokołu MQTT

MQTT umożliwia przekazanie nazwy użytkownika i hasła jako pakietu MQTT. Szyfrowanie wiadomości w sieci można obsługiwać niezależnie od MQTT z Secure Sockets Layer (SSL). Ma wbudowaną minimalną funkcję uwierzytelniania. Nazwa użytkownika i hasło są wysyłane jako wyraźny tekst. Aby zapewnić bezpieczeństwo, należy zastosować Secure Sockets Layer (SSL)/ Transport Layer Security (TLS), ale SSL/ TLS nie jest lekkim protokołem.

Wielu ekspertów branżowych uważa, że ​​MQTT odgrywa ważną rolę w IoT, przyczyniając się do takich dziedzin, jak śledzenie zapasów i IoT medyczny..

Czy Messenger używa MQTT

We wtorek wprowadziliśmy Facebook Messenger, nową samodzielną aplikację do przesyłania wiadomości, która umożliwia wysyłanie wiadomości 1 na 1 lub do grup znajomych. Dołączyłem do Facebooka pięć miesięcy temu z moimi dwoma innymi współzałożycielami, Benem Davenportem i Jonem Perlowem, którzy pracowali ze mną nad zbudowaniem aplikacji do przesyłania wiadomości grupowych o nazwie Beluga. Nasza nowa aplikacja, Facebook Messenger, reprezentuje to, co najlepsze z obu światów – łączy łatwość i prostotę Beluga ze skalą i integracją wiadomości na Facebooku.

Miałem kilka doświadczeń życiowych, które doprowadziły mnie do stworzenia Beluga. Na przykład grupa z nas spotykała się z filmem na festiwalu filmowym Tribeca w Nowym Jorku, ale godzina poprzedzająca film była całkowitą porażką komunikacji. Miałem przyjaciela, który powiedział mi, że inny przyjaciel spóźnił się. Oszczędzaliśmy bilet na innego przyjaciela, ale postanowił nie przychodzić i nikt nie wiedział. To nie było’T aż do godziny później, kiedy wróciłem do domu, zobaczyłem, że jestem od przyjaciela, który się spóźnił, i e -mail od przyjaciela, który zwolnił za kaucją. Uważamy, że Facebook Messenger’S Możliwość integracji czatu, wiadomości tekstowych i e -maili pomaga rozwiązać ten dokładny problem.

Zaczęliśmy budować Beluga jako narzędzie do koordynacji grupy, ale odkryliśmy, że umożliwianie lekkiej, prywatnej, natychmiastowej komunikacji może zmienić sposób, w jaki grupa ludzi łączy się ze sobą znacznie. Zamiast wysyłać e -mailem zdjęcia wakacyjne tygodnie po podróży, ludzie zaczynają dzielić się więcej w tej chwili. Natychmiastowy charakter komunikatów umożliwia spontaniczne rozmowy i łączy lukę między osobami łączącymi się z komputerów a tymi na urządzeniach mobilnych. Posłaniec’S Integracja z czatem na Facebooku sprawia, że ​​ten scenariusz staje się rzeczywistością.

Nurkowanie w nowych wodach

Kiedy dołączyliśmy do Facebooka i zaczęliśmy budować Messenger, naszym pierwszym wyzwaniem technicznym było nauczenie się całego stosu infrastruktury na Facebooku. Wspaniale było budować na skalowalnej platformie, która już uruchomiła setki milionów użytkowników, ale system zawierał pewne założenia i decyzje projektowe, które nie były’T zawsze całkiem z produktem, który chcieliśmy zbudować. Na szczęście nasi nowi koledzy byli również podekscytowani wizją Messengera i dołączyli do wysiłku, aby upewnić się, że system może zrobić to, czego potrzebujemy.

Jednym z problemów, które doświadczyliśmy, było długie opóźnienie podczas wysyłania wiadomości. Metoda, której używaliśmy do wysłania, była niezawodna, ale powolna, i istniały ograniczenia, ile możemy ją poprawić. Mając zaledwie kilka tygodni do uruchomienia, ostatecznie zbudowaliśmy nowy mechanizm, który utrzymuje trwałe połączenie z naszymi serwerami. Aby to zrobić bez zabijania żywotności baterii, zastosowaliśmy protokół o nazwie MQTT, z którym eksperymentowaliśmy w Beluga. MQTT jest specjalnie zaprojektowany do aplikacji, takich jak wysyłanie danych telemetrycznych do sond kosmicznych, więc jest zaprojektowany do oszczędnego używania przepustowości i baterii. Utrzymując komunikaty o połączeniu i routingu MQTT za pośrednictwem naszego rurociągu czatu, często mogliśmy osiągnąć dostawę telefonu na telefon w setkach milisekund, a nie w wielu sekundach.

Oprócz wydajności i problemów związanych z integracją systemu, największymi wyzwaniami były tak naprawdę decyzje dotyczące produktu dotyczące tego, jak płynnie zintegrować różne kanały komunikacji z różnymi oczekiwaniami użytkowników. Ludzie komunikują się inaczej na czacie niż na telefonie – na przykład możesz rozpocząć rozmowę na czacie “Hej ty?” Ale prawdopodobnie byś tego nie zrobił’t Wyślij to jako tekst, z powodu oczywiście osoby’S Tam! Możesz spróbować uczynić system inteligentny i zrobić “Prawidłowy” rzecz w wielu różnych przypadkach, ale jeśli uczynisz zasady zbyt skomplikowane, może się to wydawać “magiczny” I nie jak niezawodny kanał komunikacyjny.

Aby zapewnić, że Messenger poczuł się dobrze, stale testowaliśmy różne projekty z naszymi kolegami. Gdy wprowadziliśmy kompilacje do coraz większej liczby osób na Facebooku, otrzymaliśmy jeszcze więcej informacji zwrotnych i dowiedzieliśmy się, gdzie nasze założenia różnią się od rzeczywistości. My’Tak bardzo podekscytowany, że mogę w końcu uruchomić komunikator Facebooka dla publiczności – i czekamy na opinie od milionów więcej osób.

Mamy nadzieję, że lubisz korzystać z Facebooka Messenger tak samo, jak podobało nam się to budowanie!

Lucy Zhang, inżynier oprogramowania, nie może się doczekać, aby nigdy więcej nie mieć trudności z koordynowaniem nocy filmowej.

Jak zrobić fajnego posłańca, który szybko działa z słabym Internetem

Dlaczego powinieneś używać MQTT i węzła.JS do wiadomości w czasie rzeczywistym

9 min Przeczytaj

23 maja 2017

Obecnie coraz więcej aplikacji, które opracowujemy w S-Pro, wymaga wiadomości w czasie rzeczywistym i transferu danych. W większości przypadków używamy gniazda.Biblioteka IO dla węzła.JS. Istnieją jednak alternatywy, które mają ich zalety. MQTT (Transport telemetryczny w kolejce wiadomości) jest jednym z nich. I to’S Co my’Porozmawiaj tutaj!

Co to jest MQTT

“Jest to publikacja/subskrypcja, niezwykle prosty i lekki protokół przesyłania wiadomości, zaprojektowany dla ograniczonych urządzeń i niskiej przepustowości, sieci o wysokiej opóźnieniu lub niewiarygodnej sieci. Zasady projektowania mają na celu zminimalizowanie przepustowości sieci i wymagań dotyczących zasobów urządzeń, jednocześnie próbując zapewnić niezawodność i pewien stopień pewności dostawy. Zasady te również okazują się idealnym protokołem pojawiających się “maszyna do maszyny” (M2M) lub “Internet przedmiotów” World of Connected Urządzenia oraz dla aplikacji mobilnych, w których przepustowość i zasilanie baterii są premium.” – – http: // mqtt.ORG/FAQ

Zatem MQTT jest uproszczonym protokołem sieciowym, który działa nad TCP/IP. Pomaga wymieniać wiadomości między urządzeniami za pośrednictwem wzoru publikacji. Pierwsza wersja protokołu została opracowana przez Dr. Andy Stanford-Clark (IBM) i Arlen Nipper (ARCOM) w 1999 r. MQTT 3.1.1 specyfikacja została znormalizowana przez konsorcjum Oasis w 2014 roku.

Dlaczego ci się spodoba?

• Łatwy w użyciu. Protokół jest jednostką programową bez dodatkowej funkcjonalności, którą można łatwo zintegrować z dowolnym złożonym systemem.
• Wzór publikowania Subskrypcji jest wygodny dla większości rozwiązań. Umożliwia urządzeniom komunikację i publikowanie/odbieranie wiadomości, które nie były wcześniej znane ani wcześniej zdefiniowane.
• Łatwy w zarządzaniu.
• Obciążenie kanału komunikacyjnego jest zmniejszone.
• Działa z powolnym lub niestabilnym połączeniem.
• Nie ma ograniczeń w formacie przesyłanej treści.

A co z korzyściami?

• dwójkowy
• Niskie koszty ogólne (2+ bajty)
• Wiele poziomów QoS
• Wiadomości offline
• Temat Wildcards +, #
• zachowane wiadomości, ostatnia wola i testament, bicie serca i inne rzeczy…

Pozwalać’s spójrz na to!

Binarne i niskie koszty ogólne

W strukturze przesyłanych danych binarnych jest bardzo niskie. Oznacza to, że w porównaniu z wieloma innymi protokołami (na przykład z HTTP) prawie nie ładuje sieci z przesyłaniem informacji, co jest konieczne tylko do funkcjonowania protokołu. Zgodnie z pomiarami wykonanymi w sieciach 3G, MQTT’Pojemność S jest 93 razy wyższa niż w przypadku protokołu reszty (reprezentacyjnego transferu stanu), który działa w stosunku do HTTP.

Wiele poziomów QoS

MQTT może określić poziom jakości usługi (QoS). Ogólnie rzecz biorąc, istnieją trzy poziomy:

• QoS 0. Odbiorca nie potwierdza otrzymania wiadomości. W związku z tym nadawca przesyła wiadomość tylko raz, bez próby retransmisji jej w przyszłości. To jest “Wyślij i zapomnij” metoda.
• QoS 1. Gwarantowane jest, że odbiornik otrzyma wiadomość przynajmniej raz. W takim przypadku subskrybent może otrzymywać tę samą wiadomość kilka razy. A nadawca podejmie wielokrotne próby wysyłania, dopóki nie otrzyma potwierdzenia pomyślnego dostarczania wiadomości.
• QoS 2. Najwolniejsza procedura dostarczania wiadomości odpowiada temu poziomowi jakości usługi, ale jest najbardziej niezawodna. Jego główną cechą jest implementacja “jednorazowa dostawa wiadomości” strategia. Zapewnia czteroetapową procedurę potwierdzania dostarczania wiadomości.

Wybierasz określony poziom jakości usług w oparciu o:

• Charakterystyka przesyłanych danych
• znaczenie tego, które należy dostarczyć.

Wiadomości offline/trwałe sesja

Ta opcja może być włączona lub wyłączona. Gdy “0” jest ustawiony, broker zapisuje sesję i cały klient’S subskrypcje. Następnym razem, gdy połączenie zostanie ustanowione, pokazuje wszystkie wiadomości z QoS1 i QoS2, które zostały odebrane przez brokera podczas odłączenia. Odpowiednio, kiedy “1” jest ustawione, a połączenie jest odnawiane, klient będzie musiał ponownie subskrybować tematy.

Temat Wildcards

Temat to ciąg UTF-8, który jest używany przez brokera do filtrowania wiadomości dla każdego podłączonego klienta. Temat składa się z jednego lub więcej poziomów tematu. Każdy poziom tematu jest oddzielony przez cięcie do przodu (separator poziomu tematu).

Gdy klient subskrybuje temat, może użyć dokładnego tematu, do którego komunikat został opublikowany lub może subskrybować więcej tematów jednocześnie za pomocą Wildcards.

Karta wieloznaczna na jednym poziomie jest substytutem jednego poziomu tematu. Symbol plus reprezentuje jednopoziomową kartę wieloznaczną w temacie.

Podczas gdy wieloznaczna karta na jednym poziomie obejmuje tylko jeden poziom tematu, wielopoziomowa karta wieloznaczna obejmuje dowolną liczbę poziomów tematu. Aby określić pasujące tematy, konieczne jest, aby wielopoziomowa karta wieloznaczna jest zawsze ostatnią postacią w temacie i jest poprzedzona slashem do przodu.

Inne funkcje

Ponadto MQTT ma inne fajne funkcje, takie jak zachowane wiadomości, ostatnia wola i testament oraz bicie serca. Wygraliśmy’T Oblicz je w tym artykule, ale informacje są szeroko dostępne w Internecie. Więc jeśli jesteś zainteresowany, śmiało.

Brokerzy i klienci dla węzła.JS

Pozwalać’s Zrób jakiś kod! W tej sekcji my’Pokazuj, jak łatwo możesz uzyskać działające rozwiązanie z węzłem.JS. Także Ty’Poznaj niektóre moduły. Pozwalać’S próbuj wdrożyć taki schemat w praktyce.

MQTT wymaga brokera, który jest sercem każdego protokołu publikowania/subskrybowania. Broker jest przede wszystkim odpowiedzialny za odbieranie wszystkich wiadomości, filtrowanie ich, decydowanie o tym, kto jest nimi zainteresowany, a następnie wysyłanie wiadomości do wszystkich subskrybowanych klientów.

Jako broker użyjemy Mosca.

Mosca to broker MQTT jako moduł NPM. Możesz go użyć zarówno z wiersza poleceń, jak i z modułu NPM. W takim przypadku użyjemy go jako modułu.

Aby obsługiwać wiadomości offline, których użyjemy Ascoltatori z MongoDB. Ogólnie rzecz biorąc, Ascoltatori to prosta biblioteka publikacji/subskrypcji obsługująca następujące brokerzy/protokoły:

• Redis, Klucz/magazyn wartości utworzony przez @antrez.
• MongoDB, Skalowalna, wysokowydajna baza danych zorientowana na dokumenty.
• Moskitto i wszystkie wdrożenia MQTT protokół.
• Rabbitmq i wszystkie wdrożenia AMQP protokół.
• Zeromq używać Ascoltatori w sposób P2P.
• Qlobberfsq, Udostępniona kolejka systemu plików.
• Apache Kafka, wysokowydajny rozproszony system przesyłania wiadomości.
• Routing tylko z pamięci, używając Qlobber.

Możesz zobaczyć poniższy kod backend. Jest to kod prawdziwego serwera, który obejmuje brokera MQTT, serwer HTTPS do obsługi odbierania pakietów MQTT za pośrednictwem WebSockets, adapter Ascoltatori w celu zapisywania wiadomości w bazie danych MongoDB.

// wymagaj brokera MQTTvar mosca = wymaga (&bdquo;mosca&rdquo;);// Zdefiniuj połączenie z MongoDBvar Mongo_Con = 'MongoDB: // localhost: 27017/mqtt';// te ustawienia są wymagane, aby włączyć trwałą funkcję sesji.// Wszystkie wiadomości będą przechowywane w MongoDBvar ascoltatore = Typ: &bdquo;Mongo&rdquo;,URL: Mongo_Con,pubsubcollection: &bdquo;Ascoltatori&rdquo;,Mongo: <>>;// Ustawienia końcowe dla brokera Mosca MQTTUstawienia var = Port: 1883,Backend: Ascoltatore,trwałość: Fabryka: Mosca.trwałość.Mongo,URL: Mongo_Con>>;// Zdefiniuj serwery HTTP i MQTTvar http = wymaga (&bdquo;http&rdquo;),httpserv = http.createServer (),MQTTSERV = nowa Mosca.Serwer (Ustawienia);// dołącz HTTP do serwera MQTTMQTTServ.accalttpserver (httpserv);httpserv.Słuchaj (3000);// wyzwala, gdy serwer MQTT jest gotowy do przyjęcia żądańMQTTServ.na (&bdquo;gotowy&rdquo;, gotowy);// wyzwala się, gdy opublikowana jest nowa wiadomośćMQTTServ.na (&bdquo;opublikowane&rdquo;, funkcja (pakiet, klient) konsola.Dziennik (pakiet.Temat + ':' + pakiet.ładunek);>);funkcja gotowa () konsola.log (&bdquo;MOSCA Server jest uruchomiony&rdquo;);>

Aby wdrożyć klienta MQTT, użyjemy NPM MQTT.Moduł JS.

// wymagają biblioteki MQTTvar mqtt = wymaga („mqtt”);// Zdefiniuj łączenie klienta z naszym serwerem MQTT// Clean: False środki nie uruchamiaj nowej sesji w ponownym połączeniu// To pozwala nam korzystać z funkcji Protocol MQTT Protocol MQTT// Ponadto ClientId musi być unikalny dla każdego ciągu klientavar client = MQTT.Connect ('mqtt: // localhost', Clean: False,ClientId: „console_client”>);// Wyzwalacza na Connect// CleanT subskrybuje temat z QoS: 1, co oznacza poziom QoS. Klient otrzyma wszystkie wiadomości w ponownym połączeniu.// następnie publikuje nowe przesłanie na temat tematu. Ta wiadomość zostanie przechowywana w DB i wysłana do subskrybentów. Subskrybenci offline z QoS 1 otrzymają to ponownie.//klient.na („Connect”, funkcja () klient.subskrybuj ('/hello/s-pro',);klient.Publikuj („/hello/s-pro”, „hello, s-pro!',);>);// zrób coś, gdy nadejdzie nowa wiadomość.klient.na („komunikat”, funkcja (temat, wiadomość) konsola.log (temat + ':' + wiadomość.ToString ());>);

Pozwalać’S rozważ jeszcze jeden przykład klienta’s Wdrożenie. W takim przypadku będzie to MQTT nad WebSockets. Ten przykład będzie szczególnie przydatny dla klientów pracujących z przeglądarkami lub hybrydowymi aplikacjami mobilnymi.

Cały kod będzie podobny do poprzedniego. Jedyną różnicą jest klient’S Definicja.

klient = MQTT.Connect ('WS: // MQTT.TK: 3000/MQTT ', Clean: False,ClientId: nazwa użytkownika>);

Jak widać, tutaj łączymy się z naszym serwerem za pośrednictwem gniazd. Możesz znaleźć kod roboczy na naszym Github. Wszystkie przykłady kodu działają idealnie i były używane przez autora podczas prezentacji jako żywy przykład.

Skalowalność

Ta sekcja wykracza poza zakres tego artykułu ze względu na jego ogrom. Ale to’jest ważne, aby wspomnieć, w jakim stopniu to rozwiązanie jest rozszerzalne. Możesz utworzyć skalowalną infrastrukturę MQTT za pomocą węzła.JS, Redis, Haproxy dość łatwo. Inną opcją jest użycie Apache Kafka. Pod koniec artykułu, ty’Zobacz kilka odniesień do interesujących rozwiązań w tym obszarze.

Wniosek

Tak więc w tym artykule zbadaliśmy i przetestowaliśmy w praktyce, jak łatwo jest użyć protokołu MQTT do przesyłania wiadomości za pomocą JavaScript i Węzło.JS. Mosca Broker może być używany po stronie serwera. Ponadto obsługuje WebSockets. To znaczy, jeśli to konieczne, możesz odbierać wiadomości z urządzeń IoT i przesyłać je do aplikacji mobilnych lub komputerowych przez TCP za pośrednictwem WebSockets. Ponadto MQTT jest bardzo skalowalny. Ale nawet bez tego jest bardzo szybki i może przetwarzać komunikaty 10k+ na sekundę z łącznych połączeń 10k+.

Jeśli ci się podobało, pokaż swoje wsparcie, klaszcząc nas, aby podzielić się z innymi osobami na średnim.