Fitur MQTT yang didukung oleh fitur broker MQTT Azure Event Grid

MQTT adalah protokol transportasi olahpesan terbitkan-berlangganan yang dirancang untuk lingkungan yang dibatasi. Ini efisien, dapat diskalakan, dan dapat diandalkan, yang menjadikannya standar emas untuk komunikasi dalam skenario IoT. Broker MQTT mendukung klien yang menerbitkan dan berlangganan pesan melalui MQTT v3.1.1, MQTT v3.1.1 melalui WebSockets, MQTT v5, dan MQTT v5 melalui WebSockets. Broker MQTT juga mendukung komunikasi versi MQTT silang (MQTT 3.1.1 dan MQTT 5).

MQTT v5 memperkenalkan banyak peningkatan melalui MQTT v3.1.1 untuk memberikan komunikasi yang lebih mulus, transparan, dan efisien. Ini ditambahkan:

  • Pelaporan kesalahan yang lebih baik.
  • Klien komunikasi yang lebih transparan melalui fitur seperti properti pengguna dan jenis konten.
  • Kontrol lebih besar kepada klien melalui komunikasi melalui fitur seperti pesan dan kedaluwarsa sesi.
  • Pola penting standar seperti pola respons permintaan.

alur Koneksi ion:

Klien MQTT Anda harus terhubung melalui TLS 1.2 atau TLS 1.3. Upaya untuk melewati langkah ini gagal dengan koneksi.

Saat menyambungkan ke broker MQTT, gunakan port berikut selama komunikasi melalui MQTT:

  • MQTT v3.1.1 dan MQTT v5 pada port TCP 8883
  • MQTT v3.1.1 melalui WebSocket dan MQTTv5 melalui WebSocket pada port TCP 443.

Paket CONNECT harus menyertakan properti berikut:

  • Bidang ClientId diperlukan, dan harus menyertakan nama sesi klien. Nama sesi harus unik di seluruh namespace layanan. Anda dapat menggunakan nama autentikasi klien sebagai nama sesi jika setiap klien menggunakan satu sesi per klien. Jika satu klien menggunakan beberapa sesi, klien perlu menggunakan nilai yang berbeda untuk ClientId untuk setiap sesinya.
  • Bidang Nama Pengguna diperlukan jika Anda tidak memilih nilai di alternativeAuthenticationNameSources selama pembuatan namespace layanan. Dalam hal ini, Anda perlu memberikan nama autentikasi klien Anda di bidang Nama Pengguna. Nama tersebut perlu cocok dengan nama autentikasi yang disediakan dan nilai di bidang sertifikat klien yang ditentukan selama pembuatan sumber daya klien.

Pelajari selengkapnya tentang Autentikasi klien.

Dukungan multi-sesi

Dukungan multi-sesi memungkinkan klien MQTT aplikasi Anda memiliki implementasi yang lebih dapat diskalakan dan andal dengan menyambungkan ke broker MQTT dengan beberapa sesi aktif secara bersamaan.

Konfigurasi namespace

Sebelum menggunakan fitur ini, Anda perlu mengonfigurasi namespace layanan untuk mengizinkan beberapa sesi per klien. Gunakan langkah-langkah berikut untuk mengonfigurasi beberapa sesi per klien di portal Azure:

  • Buka namespace Anda di portal Azure.
  • Di bawah Konfigurasi, ubah nilai untuk Sesi klien maksimum per nama autentikasi menjadi jumlah sesi yang diinginkan per klien.
  • Pilih Terapkan.

Catatan

Untuk konfigurasi Azure CLI, perbarui properti MaxClientSessionsPerAuthenticationName di payload namespace layanan dengan nilai yang diinginkan.

alur Koneksi ion:

Paket CONNECT untuk setiap sesi harus menyertakan properti berikut:

  • Berikan properti Nama Pengguna dalam paket CONNECT untuk menandakan nama autentikasi klien Anda.
  • Berikan properti ClientID dalam paket CONNECT untuk menandakan nama sesi seperti ada satu atau beberapa nilai untuk ClientID untuk setiap Nama Pengguna.

Misalnya, kombinasi Nama Pengguna dan ClientIds berikut dalam paket CONNECT memungkinkan klien "Mgmt-application" untuk terhubung ke broker MQTT selama tiga sesi independen:

  • Sesi Pertama:
    • Nama pengguna: Mgmt-application
    • ClientId: Mgmt-Session1
  • Sesi Kedua:
    • Nama pengguna: Mgmt-application
    • ClientId: Mgmt-Session2
  • Sesi Ketiga:
    • Nama pengguna: Mgmt-application
    • ClientId: Mgmt-Session3

Diagram contoh multi-sesi.

Untuk informasi selengkapnya, lihat Cara membuat beberapa sesi untuk satu klien.

Menangani sesi:

  • Jika klien mencoba mengambil alih sesi aktif klien lain dengan menyajikan nama sesinya dengan nama autentikasi yang berbeda, permintaan koneksinya ditolak dengan kesalahan yang tidak sah. Misalnya, jika Klien B mencoba menyambungkan ke sesi 123 yang ditetapkan pada saat itu untuk klien A, permintaan koneksi Klien B ditolak. Meskipun demikian, jika klien yang sama mencoba terhubung kembali dengan nama sesi yang sama dan nama autentikasi yang sama, klien dapat mengambil alih sesi yang ada.
  • Jika sumber daya klien dihapus tanpa mengakhiri sesinya, klien lain tidak dapat menggunakan nama sesinya hingga sesi kedaluwarsa. Misalnya, Jika klien B membuat sesi dengan nama sesi 123 maka klien B akan dihapus, klien A tidak dapat tersambung ke sesi 123 hingga kedaluwarsa.
  • Batas jumlah sesi per klien berlaku untuk sesi online dan offline kapan saja. Misalnya, pertimbangkan namespace layanan dengan sesi klien maksimum per nama autentikasi diatur ke 1. Jika klien A terhubung dengan sesi persisten 123 maka terputus, klien A tidak akan dapat terhubung dengan sesi baru 456 karena sesi 123 masih aktif meskipun offline. Oleh karena itu, kami menyarankan agar klien yang sama selalu terhubung kembali dengan nama sesi statis yang sama dibandingkan dengan menghasilkan nama sesi baru dengan setiap koneksi ulang.

Fitur MQTT

Fitur broker MQTT Azure Event Grid mendukung fitur MQTT berikut:

Kualitas layanan (QoS)

Broker MQTT mendukung QoS 0 dan 1, yang menentukan jaminan pengiriman pesan pada paket PUBLISH dan SUBSCRIBE antara klien dan broker MQTT. QoS 0 menjamin pengiriman paling banyak sekali; pesan dengan QoS 0 tidak diakui oleh pelanggan atau dikirim ulang oleh penerbit. QoS 1 menjamin pengiriman setidaknya sekali; pesan diakui oleh pelanggan dan dikirim ulang oleh penerbit jika mereka tidak diakui. QoS memungkinkan klien Anda mengontrol efisiensi dan keandalan komunikasi.

Sesi persisten

Broker MQTT mendukung sesi persisten untuk MQTT v3.1.1 sehingga broker MQTT mempertahankan informasi tentang sesi klien jika terjadi pemutusan sambungan untuk memastikan keandalan komunikasi. Informasi ini mencakup langganan klien dan pesan QoS 1 yang terlewat/tidak diakui. Klien dapat mengonfigurasi sesi persisten melalui pengaturan bendera cleanSession dalam paket CONNECT ke false.

Bersihkan kedaluwarsa mulai dan sesi

MQTT v5 memperkenalkan fitur mulai bersih dan kedaluwarsa sesi sebagai peningkatan atas MQTT v3.1.1 dalam menangani persistensi sesi. Clean Start adalah fitur yang memungkinkan klien untuk memulai sesi baru dengan broker MQTT, membuang data sesi sebelumnya. Kedaluwarsa Sesi memungkinkan klien untuk memberi tahu broker MQTT ketika sesi yang tidak aktif dianggap kedaluwarsa dan dihapus secara otomatis. Dalam paket CONNECT, klien dapat mengatur bendera Clean Start ke interval kedaluwarsa sesi benar dan/atau singkat karena alasan keamanan atau untuk menghindari potensi konflik data yang mungkin terjadi selama sesi sebelumnya. Klien juga dapat mengatur awal yang bersih ke interval kedaluwarsa sesi false dan/atau panjang untuk memastikan keandalan dan efisiensi sesi persisten.

Konfigurasi interval kedaluwarsa sesi maksimum

Anda dapat mengonfigurasi interval kedaluwarsa sesi maksimum yang diizinkan untuk semua klien Anda yang terhubung ke namespace Layanan Event Grid. Untuk klien MQTT v3.1.1, batas yang dikonfigurasi diterapkan sebagai interval kedaluwarsa sesi default untuk semua sesi persisten. Untuk klien MQTT v5, batas yang dikonfigurasi diterapkan sebagai nilai maksimum untuk properti Interval Kedaluwarsa Sesi dalam paket CONNECT; nilai apa pun yang melebihi batas disesuaikan. Nilai default untuk properti namespace ini adalah 1 jam dan dapat diperpanjang hingga 8 jam. Gunakan langkah-langkah berikut untuk mengonfigurasi interval kedaluwarsa sesi maksimum dalam portal Azure:

  • Buka namespace Anda di portal Azure.
  • Di bawah Konfigurasi, ubah nilai untuk interval Kedaluwarsa sesi maksimum dalam jam ke batas yang diinginkan.
  • Pilih Terapkan.

cuplikan layar untuk konfigurasi interval kedaluwarsa sesi maksimum.

Luapan sesi

Broker MQTT mempertahankan antrean pesan untuk setiap sesi MQTT aktif yang tidak terhubung, sampai klien terhubung dengan broker MQTT lagi untuk menerima pesan dalam antrean. Jika klien tidak tersambung untuk menerima pesan QOS1 yang diantrekan, antrean sesi mulai mengumpulkan pesan hingga mencapai batasnya: 100 pesan atau 1 MB. Setelah antrean mencapai batasnya selama masa pakai sesi, sesi dihentikan.

Pesan Wasiat dan Perjanjian Terakhir (LWT) (pratinjau)

Last Will and Testament (LWT) memberi tahu klien MQTT Anda dengan pemutusan sambungan mendadak klien MQTT lainnya. Anda dapat menggunakan LWT untuk memastikan aliran komunikasi yang dapat diprediksi dan dapat diandalkan di antara klien MQTT selama pemutusan sambungan tak terduga, yang berharga untuk skenario di mana komunikasi real-time, keandalan sistem, dan tindakan terkoordinasi sangat penting. Klien yang berkolaborasi untuk melakukan tugas kompleks dapat bereaksi terhadap pesan LWT satu sama lain dengan menyesuaikan perilaku mereka, mendistribusikan ulang tugas, atau mengambil alih tanggung jawab tertentu untuk menjaga performa dan stabilitas sistem. Untuk menggunakan LWT, klien dapat menentukan akan pesan, akan topik, dan sisa properti akan dalam paket CONNECT selama koneksi. Ketika klien terputus tiba-tiba, broker MQTT menerbitkan pesan akan kepada semua klien yang berlangganan topik kehendak.

Properti pengguna

Broker MQTT mendukung properti pengguna pada paket MQTT v5 PUBLISH yang memungkinkan Anda menambahkan pasangan kunci-nilai kustom di header pesan untuk memberikan konteks lebih lanjut tentang pesan. Kasus penggunaan untuk properti pengguna serbaguna. Anda dapat menggunakan fitur ini untuk menyertakan tujuan atau asal pesan sehingga penerima dapat menangani pesan tanpa mengurai payload, menyimpan sumber daya komputasi. Misalnya, pesan dengan properti pengguna yang menunjukkan tujuannya sebagai "peringatan" dapat memicu logika penanganan yang berbeda dari satu dengan tujuan "informasi."

Pola respons permintaan

MQTTv5 memperkenalkan bidang di header paket MQTT PUBLISH yang menyediakan konteks untuk pesan respons dalam pola respons permintaan. Bidang-bidang ini mencakup topik respons dan ID korelasi yang dapat digunakan responden dalam respons tanpa konfigurasi sebelumnya. Informasi respons memungkinkan komunikasi yang lebih efisien untuk pola respons permintaan standar yang digunakan dalam skenario perintah dan kontrol.

Diagram contoh pola permintaan-respons.

Interval kedaluwarsa pesan:

Di MQTT v5, interval kedaluwarsa pesan memungkinkan pesan memiliki umur yang dapat dikonfigurasi. Interval kedaluwarsa pesan didefinisikan sebagai interval waktu antara waktu pesan diterbitkan ke broker MQTT dan waktu ketika broker MQTT perlu membuang pesan yang tidak terkirim. Fitur ini berguna dalam skenario di mana pesan hanya valid untuk jumlah waktu tertentu, seperti perintah sensitif waktu, streaming data real-time, atau pemberitahuan keamanan. Dengan mengatur interval kedaluwarsa pesan, broker MQTT dapat secara otomatis menghapus pesan yang kedaluwarsa, memastikan bahwa hanya informasi yang relevan yang tersedia untuk pelanggan. Jika interval kedaluwarsa pesan diatur ke nol, itu berarti pesan tidak boleh kedaluwarsa.

Alias topik:

Di MQTT v5, alias topik memungkinkan klien untuk menggunakan alias yang lebih pendek sebagai pengganti nama topik lengkap dalam pesan yang diterbitkan. Broker MQTT mempertahankan pemetaan antara alias topik dan nama topik yang sebenarnya. Fitur ini dapat menyimpan bandwidth jaringan dan mengurangi ukuran header pesan, terutama untuk topik dengan nama panjang. Ini berguna dalam skenario di mana topik yang sama berulang kali diterbitkan dalam beberapa pesan, seperti di jaringan sensor. Broker MQTT mendukung hingga 10 alias topik. Klien dapat menggunakan bidang Alias Topik dalam paket PUBLISH untuk mengganti nama topik lengkap dengan alias yang sesuai.

Diagram contoh alias topik.

Kontrol alur

Di MQTT v5, kontrol alur mengacu pada mekanisme untuk mengelola laju dan ukuran pesan yang dapat ditangani klien. Kontrol alur dapat dikonfigurasi dengan mengatur Parameter Ukuran Paket Maksimum dan Terima Maksimum dalam paket CONNECT. Parameter Terima Maksimum memungkinkan klien membatasi jumlah pesan yang dikirim oleh broker ke jumlah pesan yang dapat ditangani klien. Parameter Ukuran Paket Maksimum menentukan ukuran maksimum paket yang dapat diterima klien. Broker MQTT memiliki batas ukuran pesan 512 KiB. Fitur ini memastikan keandalan dan stabilitas komunikasi untuk perangkat yang dibatasi dengan kecepatan pemrosesan atau kemampuan penyimpanan terbatas.

Pengakuan negatif dan paket pemutusan sambungan yang dimulai server

Untuk MQTT v5, broker MQTT dapat mengirim pengakuan negatif (NACK) dan paket pemutusan sambungan yang dimulai server yang memberi klien informasi lebih lanjut tentang kegagalan pengiriman pesan atau koneksi. Fitur-fitur ini membantu klien mendiagnosis alasan di balik kegagalan dan mengambil tindakan mitigasi yang sesuai. Broker MQTT menggunakan kode alasan yang ditentukan dalam Spesifikasi MQTT v5.

Batasan saat ini

Broker MQTT menambahkan lebih banyak fitur MQTT v5 dan MQTT v3.1.1 di masa depan untuk menyelaraskan lebih banyak dengan spesifikasi MQTT. Daftar berikut merinci perbedaan saat ini antara fitur yang didukung oleh broker MQTT dan spesifikasi MQTT:

Batasan MQTTv5 saat ini

MQTT v5 saat ini berbeda dari Spesifikasi MQTT v5 dengan cara berikut:

  • Langganan Bersama belum didukung.
  • Pertahankan bendera belum didukung.
  • Interval penundaan akan belum didukung.
  • QoS maksimum adalah 1.
  • Ukuran Paket Maksimum adalah 512 KiB
  • Pemesanan pesan tidak dijamin.
  • Pengidentifikasi Langganan tidak didukung.
  • Pengidentifikasi Klien yang Ditetapkan belum didukung.
  • Topik Alias Maksimum adalah 10. Server tidak menetapkan alias topik apa pun untuk pesan keluar saat ini. Klien dapat menetapkan dan menggunakan alias topik dalam batas yang ditetapkan.
  • CONNACK tidak mengembalikan properti Informasi Respons meskipun permintaan CONNECT berisi properti Informasi Respons Permintaan.
  • Properti Pengguna di paket CONNECT, SUBSCRIBE, DISCONNECT, PUBACK, AUTH tidak digunakan oleh layanan sehingga tidak didukung. Jika salah satu permintaan ini menyertakan properti pengguna, permintaan gagal.
  • Jika server menerima PUBACK dari klien dengan kode respons yang tidak berhasil, koneksi akan dihentikan.
  • Keep Alive Maximum adalah 1.160 detik.

Batasan saat ini MQTTv3.1.1

MQTT v5 saat ini berbeda dari Spesifikasi MQTT v3.1.1 dengan cara berikut:

  • QoS2 dan Pertahankan Bendera belum didukung. Permintaan penerbitan dengan bendera pertahankan atau dengan QoS2 gagal dan menutup koneksi.
  • Pemesanan pesan tidak dijamin.
  • Keep Alive Maximum adalah 1.160 detik.

Sampel kode:

Repositori ini berisi sampel kode C#, C, dan python yang menunjukkan cara mengirim telemetri, mengirim perintah, dan menyiarkan pemberitahuan. Sertifikat yang dibuat melalui sampel cocok untuk pengujian, tetapi tidak cocok untuk lingkungan produksi.

Langkah berikutnya:

Pelajari selengkapnya tentang MQTT:

Pelajari selengkapnya tentang broker MQTT: