Udostępnij przez


Funkcje MQTT obsługiwane przez brokera MQTT usługi Azure Event Grid

Transport telemetryczny kolejkowania komunikatów (MQTT) to protokół transportu komunikatów z subskrypcją publikowania, który został zaprojektowany dla środowisk ograniczonych. Protokół MQTT jest wydajny, skalowalny i niezawodny, co sprawia, że jest popularny w scenariuszach Internetu rzeczy (IoT). Broker MQTT obsługuje klientów, którzy publikują i subskrybują komunikaty za pośrednictwem protokołu MQTT w wersji 3.1.1, MQTT v3.1.1 za pośrednictwem protokołu WebSocket, MQTT v5 i MQTT v5 za pośrednictwem protokołu WebSocket. Broker MQTT obsługuje również komunikację między wersjami MQTT (MQTT 3.1.1 i MQTT 5).

Broker MQTT w usłudze Azure Event Grid obsługuje również urządzenia i usługi wysyłające komunikaty MQTT za pośrednictwem protokołu HTTPS, co upraszcza integrację z klientami innych niż MQTT. Usługa Event Grid umożliwia wysyłanie komunikatów MQTT do chmury na potrzeby analizy danych, przechowywania i wizualizacji, między innymi przypadków użycia. Ta funkcja jest obecnie dostępna w wersji zapoznawczej.

Protokół MQTT v5 wprowadził wiele ulepszeń dotyczących protokołu MQTT w wersji 3.1.1 w celu zapewnienia bardziej bezproblemowej, przejrzystej i wydajnej komunikacji. Dodano:

  • Lepsze raportowanie błędów.
  • Bardziej przezroczysta komunikacja z klientami za pośrednictwem funkcji, takich jak właściwości użytkownika i typ zawartości.
  • Większa kontrola nad klientami za pośrednictwem funkcji, takich jak wygaśnięcie komunikatu i sesji.
  • Standardowe ważne wzorce, takie jak wzorzec żądania-odpowiedź.

Przepływ połączenia

Klienci MQTT muszą łączyć się za pośrednictwem protokołu Transport Layer Security (TLS) 1.2 lub TLS 1.3. Próby pominięcia tego kroku kończą się niepowodzeniem z połączeniem.

Podczas nawiązywania połączenia z brokerem MQTT użyj następujących portów podczas komunikacji za pośrednictwem protokołu MQTT:

  • MQTT v3.1.1 i MQTT v5 na porcie TCP 8883
  • Protokół MQTT w wersji 3.1.1 za pośrednictwem protokołu WebSocket i MQTT w wersji 5 za pośrednictwem protokołu WebSocket na porcie TCP 443

Pakiet CONNECT powinien zawierać następujące właściwości:

  • Pole ClientId jest wymagane i powinno zawierać nazwę sesji klienta. Nazwa sesji musi być unikatowa w przestrzeni nazw. Możesz użyć nazwy uwierzytelniania klienta jako nazwy sesji, jeśli każdy klient używa jednej sesji na klienta. Jeśli jeden klient używa wielu sesji, musi używać różnych wartości dla ClientId każdej sesji.
  • Pole Username jest wymagane, jeśli nie wybrano wartości podczas alternativeAuthenticationNameSources tworzenia przestrzeni nazw. W takim przypadku należy podać nazwę uwierzytelniania klienta w Username polu . Ta nazwa musi być zgodna z podaną nazwą uwierzytelniania i wartością w polu certyfikatu klienta, które zostało określone podczas tworzenia zasobu klienta.

Dowiedz się więcej o uwierzytelnianiu klienta.

Obsługa wielu sesji

Obsługa wielu sesji umożliwia klientom MQTT aplikacji uzyskanie bardziej skalowalnej i niezawodnej implementacji przez nawiązanie połączenia z brokerem MQTT z wieloma aktywnymi sesjami w tym samym czasie.

Konfiguracja przestrzeni nazw

Przed użyciem tej funkcji należy skonfigurować przestrzeń nazw tak, aby zezwalała na wiele sesji na klienta. Aby skonfigurować wiele sesji na klienta w witrynie Azure Portal, wykonaj następujące kroki:

  1. Przejdź do przestrzeni nazw w witrynie Azure Portal.
  2. W obszarze Konfiguracja zmień wartość maksymalnej liczby sesji klienta na nazwę uwierzytelniania na liczbę sesji na klienta, którego potrzebujesz.
  3. Wybierz Zastosuj.

Uwaga

W przypadku konfiguracji interfejsu wiersza polecenia platformy Azure zaktualizuj MaxClientSessionsPerAuthenticationName właściwość w ładunku przestrzeni nazw przy użyciu żądanej wartości.

Przepływ połączenia

Pakiety CONNECT dla każdej sesji powinny zawierać następujące właściwości:

  • Username Podaj właściwość w pakiecie CONNECT, aby oznaczyć nazwę uwierzytelniania klienta.
  • ClientID Podaj właściwość w pakiecie CONNECT, aby oznaczyć nazwę sesji, na przykład jeśli istnieje co najmniej jedna wartość identyfikatora klienta dla każdej nazwy użytkownika.

Na przykład następujące kombinacje elementów i Username w pakiecie ClientId CONNECT umożliwiają klientowi Mgmt-application nawiązanie połączenia z brokerem MQTT za pośrednictwem trzech niezależnych sesji:

  • Pierwsza sesja:
    • Username: Mgmt-application
    • ClientId: Mgmt-Session1
  • Druga sesja:
    • Username: Mgmt-application
    • ClientId: Mgmt-Session2
  • Trzecia sesja:
    • Username: Mgmt-application
    • ClientId: Mgmt-Session3

Diagram przedstawiający przykład z wieloma sesjami.

Aby uzyskać więcej informacji, zobacz Ustanawianie wielu sesji dla jednego klienta.

Obsługa sesji

  • Jeśli klient próbuje przejąć aktywną sesję innego klienta, przedstawiając jego nazwę sesji z inną nazwą uwierzytelniania, żądanie połączenia zostanie odrzucone z powodu nieautoryzowanego błędu. Jeśli na przykład klient B próbuje nawiązać połączenie z sesją 123 przypisaną w tym czasie dla klienta A, żądanie połączenia klienta B zostanie odrzucone. Jeśli jednak ten sam klient spróbuje ponownie nawiązać połączenie z tymi samymi nazwami sesji i tą samą nazwą uwierzytelniania, może przejąć istniejącą sesję.
  • Jeśli zasób klienta zostanie usunięty bez zakończenia sesji, inni klienci nie będą mogli używać nazwy sesji do momentu wygaśnięcia sesji. Jeśli na przykład klient B tworzy sesję o nazwie sesji 123 , a następnie klient B zostanie usunięty, klient A nie może nawiązać połączenia z sesją 123 , dopóki nie wygaśnie.
  • Limit liczby sesji na klienta ma zastosowanie do sesji online i offline w dowolnym momencie. Rozważmy na przykład przestrzeń nazw z maksymalną sesją klienta na nazwę uwierzytelniania ustawioną na 1. Klient A łączy się z trwałą sesją 123 , a następnie zostaje rozłączony. Klient A nie może nawiązać połączenia z nową sesją 456 , ponieważ jego sesja 123 jest nadal aktywna, nawet jeśli jest w trybie offline. W związku z tym zalecamy, aby ten sam klient zawsze ponownie łączył się z tymi samymi statycznymi nazwami sesji, w przeciwieństwie do generowania nowej nazwy sesji z każdym ponownym połączeniem.

Funkcje MQTT

Broker MQTT usługi Event Grid obsługuje następujące funkcje MQTT.

Quality of Service

Broker MQTT obsługuje poziomy jakości usług (QoS) 0 i 1, które definiują gwarancję dostarczania komunikatów w przypadku pakietów PUBLISH i SUBSCRIBE między klientami a brokerem MQTT.

  • QoS 0 gwarantuje co najwyżej jednokrotne dostarczanie: subskrybent nie potwierdza komunikatów z QoS 0, a wydawca nie przekazuje ich ponownie.
  • QoS 1 gwarantuje co najmniej jednokrotne dostarczanie: subskrybent potwierdza komunikaty, a wydawca ponownie je przekazuje, jeśli nie zostały potwierdzone.

Funkcja QoS umożliwia klientom kontrolowanie wydajności i niezawodności komunikacji.

Sesje trwałe

Broker MQTT obsługuje trwałe sesje dla protokołu MQTT w wersji 3.1.1, dzięki czemu broker MQTT zachowuje informacje o sesji klienta po rozłączeniu w celu zapewnienia niezawodności komunikacji. Te informacje obejmują subskrypcje klienta i pominięte lub niezaznaczone komunikaty QoS 1. Klienci mogą skonfigurować sesję trwałą, ustawiając flagę cleanSession w pakiecie CONNECT na false.

Czyszczenie daty rozpoczęcia i wygaśnięcia sesji

Protokół MQTT w wersji 5 wprowadził funkcje czystego uruchamiania i wygasania sesji jako ulepszenia dotyczące protokołu MQTT w wersji 3.1.1 w obsłudze trwałości sesji. Clean start umożliwia klientowi rozpoczęcie nowej sesji z brokerem MQTT po odrzuceniu wszystkich poprzednich danych sesji. Wygaśnięcie sesji umożliwia klientowi informowanie brokera MQTT, gdy nieaktywna sesja zostanie uznana za wygasłą i automatycznie usuniętą.

W pakiecie CONNECT klient może ustawić flagę Clean Start na true. Klient może również ustawić krótki interwał wygaśnięcia sesji ze względów bezpieczeństwa lub uniknąć potencjalnych konfliktów danych, które mogły wystąpić podczas poprzedniej sesji. Klient może również ustawić flagę Clean Start na false lub interwał wygaśnięcia długiej sesji, aby zapewnić niezawodność i wydajność sesji trwałych.

Maksymalna konfiguracja interwału wygaśnięcia sesji

Możesz skonfigurować maksymalny interwał wygaśnięcia sesji dozwolony dla wszystkich klientów łączących się z przestrzenią nazw usługi Event Grid. W przypadku klientów MQTT w wersji 3.1.1 skonfigurowany limit jest stosowany jako domyślny interwał wygaśnięcia sesji dla wszystkich sesji trwałych. W przypadku klientów MQTT v5 skonfigurowany limit jest stosowany jako maksymalna wartość właściwości interwału wygaśnięcia sesji w pakiecie CONNECT. Każda wartość przekraczająca limit jest dostosowywana. Wartość domyślna dla tej właściwości przestrzeni nazw to jedna godzina i może ona wydłużyć się do ośmiu godzin. Aby skonfigurować maksymalny interwał wygaśnięcia sesji w witrynie Azure Portal, wykonaj następujące kroki:

  1. Przejdź do przestrzeni nazw w witrynie Azure Portal.
  2. W obszarze Konfiguracja zmień wartość maksymalnego interwału wygaśnięcia sesji w godzinach na żądany limit.
  3. Wybierz Zastosuj.

Zrzut ekranu przedstawiający konfigurację maksymalnego interwału wygaśnięcia sesji.

Przepełnienie sesji

Broker MQTT utrzymuje kolejkę komunikatów dla każdej aktywnej sesji MQTT, która nie jest połączona, dopóki klient nie połączy się ponownie z brokerem MQTT w celu odbierania komunikatów w kolejce. Jeśli klient nie łączy się z odbieraniem w kolejce komunikatów QoS 1, kolejka sesji gromadzi komunikaty, dopóki nie osiągnie limitu 100 komunikatów lub 1 MB. Po osiągnięciu limitu kolejki w ciągu cyklu życia sesji sesja zostanie zakończona.

Ostatnia willa i wiadomości testamentowe

Last Will and Testament (LWT) powiadamia klientów MQTT o nagłych rozłączeniach innych klientów MQTT. Można użyć LWT, aby zapewnić przewidywalny i niezawodny przepływ komunikacji między klientami MQTT podczas nieoczekiwanych rozłączeń. Ta funkcja jest cenna w scenariuszach, w których komunikacja w czasie rzeczywistym, niezawodność systemu i skoordynowane działania mają kluczowe znaczenie. Klienci, którzy współpracują ze sobą w celu wykonywania złożonych zadań, mogą reagować na komunikaty LWT, dostosowując swoje zachowanie, redystrybuując zadania lub przejmują pewne obowiązki w celu utrzymania wydajności i stabilności systemu.

Aby użyć LWT, klient może określić komunikat Will, Will temat i pozostałe właściwości Will w pakiecie CONNECT podczas połączenia. Gdy klient nagle rozłącza się, broker MQTT publikuje komunikat Will do wszystkich klientów, którzy zasubskrybowali temat Will. Aby zmniejszyć szum z powodu wahań rozłączeń, klient może ustawić interwał opóźnienia na wartość większą niż zero. W takim przypadku, jeśli klient nagle rozłącza się, ale przywraca połączenie przed wygaśnięciem interwału opóźnienia, komunikat Will nie zostanie opublikowany.

Właściwości użytkownika

Broker MQTT obsługuje właściwości użytkownika w pakietach PUBLISH MQTT v5, których można użyć do dodawania niestandardowych par klucz/wartość w nagłówku komunikatu, aby zapewnić więcej kontekstu komunikatu. Przypadki użycia właściwości użytkownika są uniwersalne. Tej funkcji można użyć do uwzględnienia przeznaczenia lub źródła komunikatu, aby odbiorca mógł obsłużyć komunikat bez analizowania ładunku, co pozwala zaoszczędzić zasoby obliczeniowe. Na przykład komunikat z właściwością użytkownika wskazującą jego przeznaczenie jako "ostrzeżenie" może wyzwolić inną logikę obsługi niż komunikat z celem "informacji".

Wzorzec odpowiedzi na żądanie

MQTT v5 wprowadził pola w nagłówku pakietów PUBLISH MQTT, które zapewniają kontekst komunikatu odpowiedzi we wzorcu żądania-odpowiedzi. Te pola obejmują temat odpowiedzi i identyfikator korelacji, którego osoba odpowiadająca może użyć w odpowiedzi bez wcześniejszej konfiguracji. Informacje o odpowiedzi umożliwiają wydajniejszą komunikację dla standardowego wzorca żądania-odpowiedzi, który jest używany w scenariuszach poleceń i kontroli.

Diagram przedstawiający przykład wzorca odpowiedzi na żądanie.

Interwał wygaśnięcia komunikatu

W programie MQTT v5 interwał wygaśnięcia komunikatu umożliwia wyświetlanie komunikatów o konfigurowalnej cyklu życia. Interwał wygaśnięcia komunikatu jest definiowany jako interwał czasu między czasem publikowania komunikatu w brokerze MQTT i czasem, kiedy broker musi odrzucić nieuprawniony komunikat. Ta funkcja jest przydatna w scenariuszach, w których komunikaty są prawidłowe tylko przez określony czas, takich jak polecenia wrażliwe na czas, przesyłanie strumieniowe danych w czasie rzeczywistym lub alerty zabezpieczeń. Ustawiając interwał wygaśnięcia komunikatu, broker MQTT może automatycznie usuwać nieaktualne komunikaty. Ten krok gwarantuje, że tylko odpowiednie informacje są dostępne dla subskrybentów. Jeśli interwał wygaśnięcia komunikatu jest ustawiony na zero, oznacza to, że komunikat nigdy nie powinien wygasać.

Aliasy tematów

W programie MQTT v5 aliasy tematów umożliwiają klientowi używanie krótszego aliasu zamiast pełnej nazwy tematu w opublikowanym komunikacie. Broker MQTT utrzymuje mapowanie między aliasem tematu a rzeczywistą nazwą tematu. Ta funkcja może zaoszczędzić przepustowość sieci i zmniejszyć rozmiar nagłówka komunikatu, szczególnie w przypadku tematów o długich nazwach. Jest to przydatne w scenariuszach, w których ten sam temat jest wielokrotnie publikowany w wielu komunikatach, takich jak w sieciach czujników. Broker MQTT obsługuje maksymalnie 10 aliasów tematów. Klient może użyć Topic Alias pola w pakiecie PUBLISH, aby zastąpić pełną nazwę tematu odpowiednim aliasem.

Diagram przedstawiający przykład aliasu tematu.

Sterowanie przepływem

W MQTT v5 sterowanie przepływem odnosi się do mechanizmu zarządzania szybkością i rozmiarem komunikatów, które klient może obsłużyć. Aby skonfigurować sterowanie przepływem, ustaw Maximum Packet Size parametry i Receive Maximum w pakiecie CONNECT. Parametr Receive Maximum umożliwia klientowi ograniczenie liczby komunikatów wysyłanych przez brokera do liczby komunikatów, które klient może obsłużyć. Parametr Maximum Packet Size definiuje maksymalny rozmiar pakietów, które klient może odbierać. Broker MQTT ma limit rozmiaru komunikatu 512 KiB. Ta funkcja zapewnia niezawodność i stabilność komunikacji dla ograniczonych urządzeń z ograniczoną szybkością przetwarzania lub możliwościami przechowywania.

Negatywne potwierdzenia i pakiet rozłączenia zainicjowany przez serwer

W przypadku protokołu MQTT v5 broker MQTT może wysyłać negatywne potwierdzenia i pakiety rozłączania inicjowane przez serwer, które zapewniają klientowi więcej informacji o błędach dostarczania komunikatów lub połączenia. Te funkcje pomagają klientowi zdiagnozować przyczynę awarii i podjąć odpowiednie działania korygujące. Broker MQTT używa kodów przyczyn zdefiniowanych w specyfikacji MQTT v5.

Kolejność komunikatów

Protokół MQTT v5 zapewnia dostarczanie komunikatów w kolejności w ramach każdego tematu i każdego klienta, gdy jest używany poziom QoS 1, co ma kluczowe znaczenie dla przepływów pracy wymagających integralności sekwencji. Jest to idealne rozwiązanie w przypadku scenariuszy, takich jak telemetria, wykonywanie poleceń i dane szeregów czasowych.

Nie gwarantuje jednak kolejności w różnych tematach ani w przypadku wysyłania komunikatów z różnymi poziomami QoS. Aby dowiedzieć się więcej, skontaktuj się z nami pod adresem askmqtt@microsoft.com.

Przypisane identyfikatory klienta

Protokół MQTT v5 wprowadza obsługę przypisanych identyfikatorów klienta, co umożliwia brokerowi MQTT generowanie i zwracanie unikatowego identyfikatora klienta, gdy klient go nie podaje. Obsługa brokera MQTT dla tej funkcji zapewnia bezproblemowe dołączanie klientów i zmniejsza potrzebę zarządzania własnymi identyfikatorami przez klientów. Jest to szczególnie przydatne w scenariuszach, w których aprowizacja klienta jest dynamiczna lub gdy urządzenia nie mają wstępnie skonfigurowanej tożsamości. Przypisane identyfikatory klientów można pobrać z odpowiedzi CONNACK i użyć ich ponownie na potrzeby przyszłych sesji w celu zachowania spójnej identyfikacji.

Zarządzanie identyfikatorem klienta i limitami sesji w MQTT

  • Przypisane identyfikatory klienta umożliwiają klientom łączenie się bez określania wstępnie zdefiniowanych identyfikatorów, włączania sesji tymczasowych lub trwałych.
  • Klienci mogą uniknąć zablokowania za pomocą krótkich interwałów wygaśnięcia sesji podczas pierwszego połączenia i zapisywania przypisanego identyfikatora klienta do użycia w przyszłości.
  • W przypadku aktualizacji lub resetowania oprogramowania układowego klienci powinni zachować swój znany identyfikator klienta lub użyć skromnych interwałów wygaśnięcia sesji, aby uniknąć długotrwałych blokad.
  • Konfiguracja przestrzeni nazw może zwiększyć limity sesji na jednego klienta, aby zminimalizować zakłócenia podczas aktualizacji lub wycofywania.

Bieżące ograniczenia

Broker MQTT dodaje więcej funkcji MQTT v5 i MQTT v3.1.1 w przyszłości, aby dostosować je do specyfikacji MQTT. Poniższa lista zawiera szczegółowe informacje o bieżących różnicach między funkcjami obsługiwanymi przez brokera MQTT i specyfikacjami MQTT.

Bieżące ograniczenia MQTT v5

Protokół MQTT v5 obecnie różni się od specyfikacji MQTT v5 w następujący sposób:

  • Subskrypcje udostępnione nie są jeszcze obsługiwane.
  • Maksymalny przedział opóźnienia będzie wynosił 300.
  • Maksymalna wartość QoS wynosi 1.
  • Maksymalny rozmiar pakietu to 512 KiB.
  • Identyfikatory subskrypcji nie są obsługiwane.
  • Maksymalny alias tematu to 10. Serwer nie przypisuje obecnie żadnych aliasów tematów dla komunikatów wychodzących. Klienci mogą przypisywać aliasy tematów i używać ich w ramach ustawionego limitu.
  • CONNACK nie zwraca Response Information właściwości, nawet jeśli żądanie CONNECT zawiera Request Response Information właściwość .
  • Właściwości użytkownika w pakietach CONNECT, SUBSCRIBE, DISCONNECT, PUBACK i AUTH nie są używane przez usługę, więc nie są obsługiwane. Jeśli którekolwiek z tych żądań zawiera właściwości użytkownika, żądanie zakończy się niepowodzeniem.
  • Jeśli serwer odbiera pakiet PUBACK od klienta z kodem odpowiedzi innej niżccess, połączenie zostanie przerwane.
  • Maksymalna wartość keep Alive wynosi 1160 sekund.

Bieżące ograniczenia MQTTv3.1.1

Protokół MQTT v5 obecnie różni się od specyfikacji MQTT w wersji 3.1.1 w następujący sposób:

  • Usługa QoS 2 nie jest obsługiwana. Żądanie publikowania z flagą RETAIN lub QoS 2 kończy się niepowodzeniem i zamyka połączenie.
  • Maksymalna wartość keep Alive wynosi 1160 sekund.

Przykłady kodu

To repozytorium zawiera przykłady kodu C#, C i Python, które pokazują, jak wysyłać dane telemetryczne, wysyłać polecenia i emitować alerty. Certyfikaty utworzone za pomocą przykładów są odpowiednie do testowania, ale nie są odpowiednie dla środowisk produkcyjnych.

Aby dowiedzieć się więcej o MQTT, zobacz specyfikację MQTT v5. Aby dowiedzieć się więcej na temat brokera MQTT, zobacz: