Geekly articles weekly

Protokol MQTT: Perendaman Konseptual

Protokol Antrian Transpor Pesan Antrian (MQTT) telah digunakan selama bertahun-tahun, tetapi sekarang ini sangat relevan karena pertumbuhan eksplosif dari IoT: perangkat konsumen dan industri mengimplementasikan jaringan terdistribusi dan komputasi tepi, dan perangkat dengan transmisi data terus menerus menjadi bagian dari kehidupan sehari-hari hidup.

Ini berarti bahwa protokol yang ringan, terbuka, dan terjangkau akan menjadi lebih penting dari waktu ke waktu. Artikel ini memberikan pencelupan konseptual di MQTT: cara kerjanya, bagaimana digunakan sekarang dan bagaimana akan digunakan di masa depan.

Pengantar kecil


MQTT adalah protokol pengiriman berbasis penerbit (subscriber). Versi awal pada tahun 1999 diterbitkan oleh Andy Stanford-Clark dari IBM dan Arlene Nipper dari Cirrus Link. Mereka memandang MQTT sebagai cara untuk menjaga komunikasi antara mesin dalam jaringan dengan bandwidth terbatas atau komunikasi yang tidak dapat diprediksi. Salah satu opsi pertama untuk penggunaannya adalah untuk memastikan bahwa potongan-potongan pipa kontak satu sama lain dan dengan tautan pusat melalui satelit.

Mengingat kondisi operasi yang keras, protokol dibuat kecil dan ringan. Ini sangat ideal untuk perangkat berdaya rendah dan dengan usia baterai terbatas. Ini sekarang termasuk smartphone di mana-mana, dan semakin banyak sensor dan perangkat yang terhubung.

Dengan demikian, MQTT telah menjadi protokol untuk streaming data antara perangkat dengan daya CPU terbatas dan / atau masa pakai baterai, serta untuk jaringan dengan bandwidth yang mahal atau rendah, stabilitas yang tidak dapat diprediksi atau latensi tinggi. Itulah sebabnya MQTT dikenal sebagai kendaraan ideal untuk IoT. Itu dibangun pada protokol TCP / IP, tetapi ada cabang MQTT-SN untuk bekerja melalui Bluetooth, UDP, ZigBee dan jaringan IoT lainnya selain TCP / IP.

MQTT bukan satu-satunya protokol pesan pub / sub-waktu dari jenisnya, tetapi telah menjadi tersebar luas di berbagai lingkungan yang bergantung pada komunikasi mesin-ke-mesin. Di antara rekan-rekannya adalah Protokol Perpesanan Aplikasi Web , Streaming Protokol Pesan Berorientasi Teks dan Protokol Antrian Pesan Alternatif .

MQTT adalah pilihan logis untuk pengembang yang ingin membuat aplikasi dengan fungsionalitas andal dan kompatibilitas luas dengan perangkat dan aplikasi yang terhubung ke Internet, termasuk browser, smartphone, dan perangkat IoT.

Bagaimana MQTT Bekerja: Dasar-Dasarnya


Sistem komunikasi yang dibangun di MQTT terdiri dari server penerbit, server broker, dan satu atau lebih klien. Penerbit tidak memerlukan pengaturan apa pun untuk jumlah atau lokasi pelanggan yang menerima pesan. Selain itu, pelanggan tidak perlu mencari penerbit tertentu. Mungkin ada beberapa broker pesan dalam sistem.



MQTT menyediakan cara untuk membuat hierarki saluran komunikasi - semacam cabang dengan daun. Setiap kali penerbit memiliki data baru untuk didistribusikan kepada pelanggan, pesan tersebut disertai dengan catatan kontrol pengiriman. Klien tingkat yang lebih tinggi dapat menerima setiap pesan, sementara klien tingkat yang lebih rendah dapat menerima pesan yang terkait dengan hanya satu atau dua saluran dasar, "cabang" di bagian bawah hierarki. Ini memfasilitasi pertukaran informasi mulai dari ukuran dua byte hingga 256 megabita .

Contoh bagaimana Anda dapat mengonfigurasi klien untuk terhubung melalui broker MQTT :

var options = { keepalive: 60, username: 'FIRST_HALF_OF_API_KEY', password: 'SECOND_HALF_OF_API_KEY', port: 8883 }; var client = mqtt.connect('mqtts:mqtt.ably.io', options);

Setiap data yang diterbitkan atau diterima oleh broker MQTT akan dikodekan dalam format biner, karena MQTT adalah protokol biner. Ini berarti bahwa untuk mendapatkan konten asli, Anda perlu menafsirkan pesan. Begini tampilannya dengan Ably dan JavaScript:

 var ably = new Ably.Realtime('REPLACE_WITH_YOUR_API_KEY'); var decoder = new TextDecoder(); var channel = ably.channels.get('input'); channel.subscribe(function(message) { var command = decoder.decode(message.data); });

Broker MQTT kadang-kadang dapat mengakumulasikan pesan yang terkait dengan saluran yang tidak memiliki pelanggan saat ini. Dalam hal ini, pesan akan dibuang atau disimpan, tergantung pada instruksi dalam pesan kontrol. Ini berguna dalam kasus di mana pelanggan baru mungkin memerlukan titik data yang terakhir direkam, daripada menunggu pengiriman berikutnya.

Perlu dicatat bahwa MQTT mentransmisikan kredensial keamanan dalam teks yang jelas, jika tidak otentikasi atau fungsi keamanan tidak didukung. Di sinilah kerangka kerja SSL berperan , membantu melindungi informasi yang dikirimkan agar tidak dicegat atau dirusak.

Selain itu, di MQTT, Anda dapat menggunakan otentikasi Ably pada token jika Anda tidak ingin mengungkapkan kunci API Anda ke klien MQTT yang sebenarnya sama sekali (dalam hal MQTT tanpa SSL, token diperlukan untuk mencegah transfer kunci API dalam teks yang jelas). Contoh otentikasi token:

 var options = { keepalive: 60, username: INSERT_TOKEN_HERE, password: '', port: 8883 }; var client = mqtt.connect('mqtts:mqtt.ably.io', options); client.subscribe("[mqtt]tokenevents", { /* Create a new token called 'NEW_TOKEN' */ client.end(); options.username = NEW_TOKEN; client = mqtt.connect('mqtts:mqtt.ably.io', options); });

Fungsionalitas MQTT: perendaman yang lebih dalam


Menurut IBM , MQTT memiliki sifat-sifat berikut:

  • Netral ke konten pesan
  • Ideal untuk komunikasi satu-ke-banyak yang didistribusikan dan aplikasi yang terputus
  • Dilengkapi dengan fungsi LWT (Wasiat Terakhir dan Wasiat, "wasiat terakhir dan wasiat") untuk memberi tahu pihak-pihak tentang pemutusan yang tidak wajar dari klien
  • Mengandalkan TCP / IP untuk tugas komunikasi dasar
  • Dirancang untuk mengirim pesan menggunakan templat "paling banyak sekali", "setidaknya sekali" dan "tepat sekali"

Seorang anggota sistem MQTT dapat mengambil peran sebagai penerbit, konsumen, atau keduanya sekaligus.

Salah satu ciri khas MQTT adalah pemahamannya yang unik tentang saluran: masing-masing diperlakukan sebagai jalur file, misalnya:

 channel = "user/path/channel"

Saluran memastikan bahwa setiap pelanggan menerima pesan yang ditujukan kepadanya. Dengan memperlakukan saluran sebagai jalur file, MQTT melakukan semua jenis fungsi komunikasi yang berguna, termasuk memfilter pesan berdasarkan di mana - pada tingkat apa atau di cabang mana - klien berlangganan jalur file.

Format pesan MQTT


Lihatlah dua komponen yang membentuk setiap pesan MQTT:

  • Byte 1 : berisi jenis pesan (permintaan koneksi klien, konfirmasi berlangganan, permintaan ping, dll.), Tanda duplikasi, instruksi untuk menyimpan pesan, dan informasi tentang kualitas layanan (QoS).
  • Byte 2 : berisi informasi tentang panjang pesan yang tersisa, termasuk muatan dan data apa pun di header variabel opsional.

Bendera QoS dalam byte 1 patut mendapat perhatian khusus, karena mendasari fungsi variabel yang didukung MQTT. Bendera QoS berisi nilai-nilai berikut berdasarkan niat dan urgensi pesan:

  • 0 = tidak lebih dari sekali: server terpicu dan lupa. Pesan mungkin hilang atau digandakan.
  • 1 = setidaknya sekali: penerima mengkonfirmasi pengiriman. Pesan dapat digandakan, tetapi pengiriman dijamin
  • 2 = tepat sekali: server menyediakan pengiriman. Pesan tiba tepat sekali tanpa kehilangan atau duplikasi

Mari kita lihat cara menggunakan level QoS yang berbeda di perangkat IoT dan aplikasi lain.

Di mana saya bisa menggunakan MQTT?


Karena aplikasi IoT sekarang sedang diimplementasikan dalam skala besar, MQTT telah mengemuka sebagai cara yang terbuka, sederhana, dan dapat diskalakan untuk menggunakan komputasi terdistribusi dan fungsi IoT untuk basis pengguna yang lebih luas - baik di pasar konsumen dan industri.

Seperti yang dinyatakan di atas, MQTT adalah protokol pengiriman pesan ringan yang dibuat untuk jaringan dan perangkat yang tidak terpercaya dengan pembatasan catu daya dan CPU. Namun, ini tidak berarti bahwa koneksi dengan paket loss potensial adalah satu-satunya aplikasi. MQTT menyediakan berbagai tingkat layanan untuk berbagai jenis infrastruktur IoT, dari pengulangan pengambilan sampel data hingga mengelola mesin industri:

  • Data Sensor Lingkungan : Seperti yang telah disebutkan, MQTT mendukung model pengiriman pesan “tidak lebih dari sekali”. Dalam jaringan dengan cakupan parsial atau latensi tinggi, ini berarti bahwa informasi dapat hilang atau digandakan . Di area di mana sensor jarak jauh merekam dan mengirimkan data pada interval yang ditentukan, ini bukan masalah, karena bacaan baru diterima secara teratur. Sensor di lingkungan terpencil biasanya merupakan perangkat berdaya rendah, menjadikan MQTT solusi ideal untuk sensor IoT dengan prioritas transfer data yang relatif rendah.
  • Data kinerja alat berat : untuk dengan cepat merespons masalah dan mencegah downtime. Misalnya, instalasi tenaga angin memerlukan jaminan pengiriman indikator kinerja saat ini kepada tim lokal bahkan sebelum informasi ini mencapai pusat data. Dalam situasi seperti itu, penyampaian pesan “setidaknya satu kali” memastikan bahwa spesialis yang tepat segera diperhatikan oleh spesialis yang diperlukan, bahkan jika mereka datang sebagai duplikat. Ini penting untuk komunikasi alat berat dengan prioritas lebih tinggi.
  • Sistem penagihan : bahkan ada lebih banyak prioritas dan pesan akurat yang perlu diproses dengan benar. Dalam situasi bisnis di mana duplikasi catatan tidak dapat diterima, termasuk dalam sistem penagihan, bendera QoS "tepat sekali" berguna. Ini menghilangkan duplikasi atau kehilangan paket dalam sistem penagihan atau penagihan, mengurangi jumlah anomali dan kontradiksi yang tidak perlu seperti yang disepakati.

Kapan tidak menggunakan MQTT?


Pengembang memiliki berbagai pilihan protokol untuk merancang dan menggunakan saluran komunikasi dua arah IoT, termasuk MQTT, HTTP, CoAP , WebSockets (jika CPU / baterai memungkinkan) dan lainnya. Apakah MQTT adalah pilihan terbaik tergantung pada perangkat keras dan tugas aplikasi.

Dirancang untuk lingkungan dengan bandwidth yang sangat rendah, protokol MQTT bisa sangat tidak fleksibel dalam upayanya untuk menghemat setiap byte. Misalnya, spesifikasi hanya menetapkan lima pesan kesalahan yang dapat digunakan server untuk menolak koneksi (misalnya, nama pengguna / kata sandi tidak valid atau versi protokol yang tidak dapat diterima). Jika server ingin menunjukkan beberapa kesalahan lain, itu tidak beruntung. Lebih buruk lagi, jika kesalahan terjadi setelah memulai koneksi, tidak ada mekanisme untuk melaporkan kesalahan sama sekali. Server hanya dapat mengangkat bahu dan tiba-tiba mengganggu koneksi TCP, meninggalkan klien tanpa petunjuk mengapa mereka menjatuhkannya (dan tanpa cara untuk membedakan pemutusan yang disengaja dari masalah jaringan sementara). Bagi orang-orang yang terbiasa dengan protokol pub / sub yang lebih fleksibel dan mudah di-debug (meskipun kurang ekonomis), pendekatan Spartan semacam itu mungkin tampak sedikit primitif.

MQTT sering disebut bersamaan dengan HTTP, jadi Google melakukan penelitian yang membandingkannya dalam waktu respons, volume lalu lintas, dan atribut lainnya yang penting bagi pengembang. MQTT mengambil tempat pertama dalam pengujian Google, tetapi hanya dalam kondisi ketika koneksi dapat digunakan kembali untuk mengirim beberapa muatan.

HTTP dan MQTT adalah pilihan yang baik untuk aplikasi IoT karena jumlah lalu lintas yang relatif kecil, baterai rendah dan persyaratan memori.

CoAP adalah protokol lain yang sering dibandingkan dengan MQTT untuk mengembangkan sistem IoT. Mereka serupa, tetapi ada perbedaan yang nyata. MQTT adalah protokol banyak-ke-banyak, sedangkan CoAP pada dasarnya adalah protokol satu-ke-satu untuk komunikasi antara server dan klien. Pada saat yang sama, CoAP menyediakan fitur metadata, penemuan, dan negosiasi konten yang tidak dimiliki MQTT .

Dalam kasus di mana klien hanya menerima data, Server-Sent Events juga merupakan opsi yang sesuai.

Cara mengatur MQTT dengan cepat


Repositori MQTT di GitHub memiliki daftar pustaka MQTT open source dalam berbagai bahasa. Berikut ini adalah dua contoh kustomisasi menggunakan broker MQTT open source, perpustakaan JavaScript, dan perpustakaan .NET.

Eclipse Mosquitto - broker MQTT open source


Eclipse Mosquitto adalah broker pesan sumber terbuka (EPL / EDL) yang mengimplementasikan protokol MQTT versi 5.0, 3.1.1 dan 3.1. Mosquitto ringan dan cocok untuk digunakan di semua perangkat: mulai dari komputer papan tunggal berdaya rendah hingga server penuh.

MQTT.js


MQTT.js adalah pustaka klien untuk protokol MQTT, ditulis dalam JavaScript untuk Node.js dan browser. Berikut ini adalah contoh pengiriman pesan menggunakan MQTT.js:

 var mqtt = require('mqtt') var client = mqtt.connect('mqtt://test.mosquitto.org') client.on('connect', function () { client.subscribe('presence', function (err) { if (!err) { client.publish('presence', 'Hello mqtt') } }) }) client.on('message', function (topic, message) { // message is Buffer console.log(message.toString()) client.end() })

MQTTnet


MQTTnet adalah .NET library berkinerja tinggi yang menyediakan klien dan server MQTT (broker).

Instalasi Klien MQTT:

 // Create a new MQTT client. var factory = new MqttFactory(); var mqttClient = factory.CreateMqttClient();

Setelah Anda mengkonfigurasi pengaturan klien MQTT, Anda dapat membuat koneksi. Kode berikut menunjukkan cara menyambung ke server:

 // Use WebSocket connection. var options = new MqttClientOptionsBuilder() .WithWebSocketServer("broker.hivemq.com:8000/mqtt") .Build(); await client.ConnectAsync(options);

Terima pesan masuk:

 client.UseApplicationMessageReceivedHandler(e => { Console.WriteLine("### RECEIVED APPLICATION MESSAGE ###"); Console.WriteLine($"+ Topic = {e.ApplicationMessage.Topic}"); Console.WriteLine($"+ Payload = {Encoding.UTF8.GetString(e.ApplicationMessage.Payload)}"); Console.WriteLine($"+ QoS = {e.ApplicationMessage.QualityOfServiceLevel}"); Console.WriteLine($"+ Retain = {e.ApplicationMessage.Retain}"); Console.WriteLine(); Task.Run(() => client.PublishAsync("hello/world")); });

Publikasi Posting:

 var message = new MqttApplicationMessageBuilder() .WithTopic("MyTopic") .WithPayload("Hello World") .WithExactlyOnceQoS() .WithRetainFlag() .Build(); await client.PublishAsync(message);

Lihat dokumentasi MQTTnet dan wiki untuk contoh lebih lanjut .

Penyedia tingkat perusahaan memiliki server MQTT yang siap digunakan untuk pengiriman pesan yang dapat diskalakan antara aplikasi seluler, mesin industri, dan beragam penggunaan IoT lainnya. Panduan ini memberi tahu Anda cara menggunakan MQTT melalui broker tingkat perusahaan.

Bagaimana dengan penskalaan?


Ketika berbicara tentang penskalaan MQTT, ada dua pertimbangan untuk dipertimbangkan: 1) apakah ini protokol yang benar; 2) terlepas dari pilihan protokol, infrastruktur dan kapabilitas jaringan apa yang diperlukan untuk menangani peningkatan lalu lintas antar perangkat yang menggunakan MQTT.

Mesin-ke-Mesin Ringan (LWM2M) adalah protokol lain yang dapat digunakan dengan MQTT di tingkat perusahaan. Dibandingkan dengan MQTT, kadang-kadang lebih cocok untuk sistem IoT jangka panjang . MQTT sangat ideal untuk uji coba IoT dengan mudah, sementara LWM2M menyediakan fitur untuk infrastruktur jangka panjang yang serbaguna. LWM2M juga menyediakan alat manajemen perangkat yang unggul seperti pemantauan koneksi, pembaruan firmware, dan tindakan perangkat jarak jauh. Untuk perusahaan dengan sejumlah besar perangkat tidak terkelola yang mengirim sejumlah besar data ke platform pusat, LWM2M adalah pilihan terbaik. Namun demikian, kita berbicara tentang penyebaran IoT skala besar, jadi biasanya MQTT lebih dari pilihan yang memadai. Selain itu, MQTT lebih umum dan memiliki dukungan yang lebih luas.

Sekarang tentang kemungkinan infrastruktur. Ketika datang ke server loading, jumlah koneksi simultan jarang menjadi hambatan. Sebagian besar server / broker MQTT yang baik mendukung ribuan koneksi bersamaan, tetapi berapa beban kerja yang diperlukan untuk memproses dan membalas pesan setelah server MQTT menerima data aktual? Sebagai aturan, ada semua jenis masalah potensial, seperti membaca dan menulis ke dan dari basis data, integrasi dengan server, distribusi dan pengelolaan sumber daya untuk setiap klien, dll. Begitu satu mesin berhenti untuk mengatasi beban, Anda perlu menambahkan server tambahan, yaitu, pikirkan tentang penyeimbangan beban, sinkronisasi pesan antara klien yang terhubung ke server yang berbeda, akses umum ke keadaan klien, terlepas dari waktu koneksi atau server tertentu yang terhubung dengan klien - daftar produk zhaetsya dan terus.

Masalah seperti itu pantas mendapatkan artikel terpisah, dan banyak informasi dapat ditemukan di bagian Teknik di blog kami . Secara khusus, lihat artikel tentang beberapa kompleksitas pelayanan infrastruktur pengiriman pesan waktu-nyata berskala besar .

Bagaimana situasi saat ini dengan MQTT?


Pada April 2019, OASIS merilis MQTT v5.0 sebagai standar resmi. OASIS adalah konsorsium nirlaba dari 600 organisasi anggota dan 5.000 anggota individu .

Versi 5.0 memperkenalkan sejumlah fitur baru yang seharusnya menarik bagi pengembang sistem waktu-nyata. Fitur-fitur baru ini kompatibel dengan versi MQTT saat ini. Diantaranya adalah:

  • Pelaporan kesalahan yang ditingkatkan : kode pengembalian sekarang dapat menginformasikan bahwa data tidak sedang dikirim karena alasan tertentu. String opsional didukung untuk menunjukkan alasannya. Mereka membantu meningkatkan diagnostik pemecahan masalah.
  • Berbagi Langganan : Untuk membantu menyeimbangkan beban, langganan dapat dibagi di antara banyak klien di sisi penerima.
  • Properti Pesan : Versi 5.0 memperkenalkan metadata sebagai bagian dari header pesan. Ini dapat menyampaikan informasi tambahan kepada pengguna akhir atau memfasilitasi beberapa fungsi lain yang tercantum di bawah ini.
  • Alias ​​Saluran : Penerbit dapat mengganti saluran dengan pengenal angka untuk mengurangi jumlah byte yang akan ditransmisikan.
  • Tanggal kedaluwarsa pesan: pesan dapat ditandai untuk dihapus secara otomatis jika sistem tidak dapat mengirimkannya dalam jangka waktu tertentu.

Untuk daftar lengkap fitur MQTT 5.0 yang baru, lihat Lampiran C pada standar resmi.

Selain banyak perangkat dan layanan konsumen di pasar, MQTT telah digunakan dalam infrastruktur perusahaan dalam segala bentuk dan ukuran . Ini adalah smartphone dan tablet, sistem pemantauan energi, perangkat medis, rig minyak dan rig, industri otomotif dan luar angkasa, serta sensor dan sistem visi mesin yang digunakan dalam penanganan material, konstruksi, rantai pasokan, ritel, dan banyak lagi.

MQTT dan Ably


MQTT adalah protokol yang populer, didukung secara luas, dan relatif matang. Ini bagus untuk banyak aplikasi waktu nyata , dan tidak hanya untuk menggunakan IoT. Namun, karena produksi dan konsumsi data real-time terus tumbuh secara eksponensial , MQTT mungkin tidak selalu menjadi protokol yang tepat untuk memenuhi kebutuhan streaming Anda. Ikuti bagian Konsep Realtime kami untuk informasi tentang protokol lain dan bagaimana mereka sesuai dengan situasi Anda.

Ably menyediakan broker dan adaptor protokol MQTT dengan terjemahan ke protokol Ably sendiri di kedua arah, yang memungkinkan Anda untuk berintegrasi dengan sistem dan koneksi yang ada. Soket Web yang didukung, HTTP, SSE, gRPC (sedang dikembangkan), STOMP, AMQP, dan protokol lainnya untuk mengatur infrastruktur pengiriman pesan yang didistribusikan secara real time. Ada lebih dari 40 perpustakaan klien SDK dan dukungan untuk protokol waktu nyata milik.

Source: https://habr.com/ru/post/id463669/

More articles:


All Articles