MQTT

MQTT (Message Queuing Telemetry Transport) adalah protokol pesan ringan dan diadopsi secara luas yang dirancang untuk perangkat terbatas. AWS IoT Core dukungan untuk MQTT didasarkan pada spesifikasi MQTT v3.1.1 dan spesifikasi MQTT v5.0, dengan beberapa perbedaan, seperti yang didokumentasikan dalam. AWS IoT perbedaan dari spesifikasi MQTT Sebagai versi terbaru dari standar, MQTT 5 memperkenalkan beberapa fitur utama yang membuat MQTT-based sistem lebih kuat, termasuk peningkatan skalabilitas baru, pelaporan kesalahan yang ditingkatkan dengan respons kode alasan, pengatur waktu kedaluwarsa pesan dan sesi, dan header pesan pengguna khusus. Untuk informasi selengkapnya tentang fitur MQTT 5 yang AWS IoT Core mendukung, lihat fitur yang didukung MQTT 5. AWS IoT Core juga mendukung komunikasi lintas versi MQTT (MQTT 3 dan MQTT 5). Penerbit MQTT 3 dapat mengirim pesan MQTT 3 ke pelanggan MQTT 5 yang akan menerima pesan publikasi MQTT 5, dan sebaliknya.

AWS IoT Core mendukung koneksi perangkat yang menggunakan protokol MQTT dan MQTT melalui protokol WSS dan yang diidentifikasi oleh ID klien. AWS IoT SDK perangkatDukungan kedua protokol dan merupakan cara yang disarankan untuk menghubungkan perangkat ke. AWS IoT Core AWS IoT Perangkat SDK mendukung fungsi yang diperlukan untuk perangkat dan klien untuk terhubung dan mengakses AWS IoT layanan. Perangkat SDK mendukung protokol otentikasi yang diperlukan AWS IoT layanan dan persyaratan ID koneksi yang diperlukan oleh protokol MQTT dan MQTT melalui protokol WSS. Untuk informasi tentang cara menyambung AWS IoT menggunakan SDK AWS Perangkat dan tautan ke contoh AWS IoT dalam bahasa yang didukung, lihatMenghubungkan dengan MQTT menggunakan AWS IoT SDK perangkat. Untuk informasi selengkapnya tentang metode otentikasi dan pemetaan port untuk pesan MQTT, lihat. Protokol, pemetaan port, dan otentikasi

Meskipun kami menyarankan untuk menggunakan SDK AWS IoT Perangkat untuk terhubung AWS IoT, mereka tidak diperlukan. Namun, jika Anda tidak menggunakan SDK AWS IoT Perangkat, Anda harus menyediakan keamanan koneksi dan komunikasi yang diperlukan. Klien harus mengirimkan ekstensi TLS Server Name Indication (SNI) dalam permintaan koneksi. Upaya koneksi yang tidak termasuk SNI ditolak. Untuk informasi selengkapnya, lihat Keamanan Transportasi di AWS IoT. Klien yang menggunakan pengguna IAM dan AWS kredensialnya untuk mengautentikasi klien harus memberikan otentikasi Signature Version 4 yang benar.

Setelah klien Anda terhubung, Anda dapat memantau dan mengelola koneksi klien MQTT mereka menggunakan konsol atau API. Untuk informasi selengkapnya, lihat Manajemen koneksi MQTT.

Menghubungkan dengan MQTT menggunakan AWS IoT SDK perangkat

Bagian ini berisi tautan ke SDK AWS IoT Perangkat dan kode sumber program contoh yang menggambarkan cara menghubungkan perangkat. AWS IoT Contoh aplikasi yang ditautkan di sini menunjukkan cara terhubung AWS IoT menggunakan protokol MQTT dan MQTT melalui WSS.

Opsi Kualitas Layanan (QoS) MQTT

AWS IoT dan SDK AWS IoT Perangkat mendukung tingkat MQTT Quality of Service (QoS) dan. 0 1 Protokol MQTT mendefinisikan tingkat ketiga QoS, level2, tetapi tidak mendukungnya. AWS IoT Hanya protokol MQTT yang mendukung fitur QoS. HTTPS mendukung QoS dengan meneruskan parameter string kueri ?qos=qos di mana nilainya bisa 0 atau 1.

Tabel ini menjelaskan bagaimana setiap level QoS memengaruhi pesan yang dipublikasikan ke dan oleh broker pesan.

Sesi persisten MQTT

Sesi persisten menyimpan langganan dan pesan klien, dengan Quality of Service (QoS) 1, yang belum diakui oleh klien. Ketika perangkat terhubung kembali ke sesi persisten, sesi dilanjutkan, langganan dipulihkan, dan pesan berlangganan yang tidak diakui diterima dan disimpan sebelum koneksi ulang dikirim ke klien.

Pemrosesan pesan yang disimpan direkam dalam CloudWatch metrik dan CloudWatch Log. Untuk informasi tentang entri yang ditulis ke CloudWatch dan CloudWatch Log, lihat Metrik broker pesan danEntri log antrian.

Membuat sesi persisten

Di MQTT 3, Anda membuat sesi persisten MQTT dengan mengirim CONNECT pesan dan menyetel flag ke. cleanSession 0 Jika tidak ada sesi untuk klien yang mengirim CONNECT pesan, sesi persisten baru akan dibuat. Jika sesi sudah ada untuk klien, klien melanjutkan sesi yang ada. Untuk membuat sesi bersih, Anda mengirim CONNECT pesan dan mengatur cleanSession bendera ke1, dan broker tidak akan menyimpan status sesi apa pun saat klien terputus.

Di MQTT 5, Anda menangani sesi persisten dengan menyetel bendera danClean Start. Session Expiry Interval Clean Start mengontrol awal sesi penghubung dan akhir sesi sebelumnya. Ketika Anda menetapkan Clean Start =1, sesi baru dibuat dan sesi sebelumnya dihentikan jika ada. Saat Anda mengatur Clean Start =0, sesi penghubung melanjutkan sesi sebelumnya jika ada. Interval Kedaluwarsa Sesi mengontrol akhir sesi penghubung. Session Expiry Interval menentukan waktu, dalam detik (4-byte integer), bahwa sesi akan bertahan setelah terputus. Pengaturan Session Expiry interval = 0 menyebabkan sesi segera berakhir setelah terputus. Jika Interval Kedaluwarsa Sesi tidak ditentukan dalam pesan CONNECT, defaultnya adalah 0.

Dalam MQTT 5, jika Anda mengatur Clean Start = 1 dan Session Expiry Interval =0, ini setara dengan sesi bersih MQTT 3. Jika Anda mengatur Clean Start = 0 dan Session Expiry Interval >0, ini setara dengan sesi persisten MQTT 3.

Operasi selama sesi persisten

Klien menggunakan sessionPresent atribut dalam pesan koneksi yang diakui (CONNACK) untuk menentukan apakah ada sesi persisten. Jika sessionPresent ada1, sesi persisten hadir dan pesan yang disimpan untuk klien dikirim ke klien setelah klien menerimaCONNACK, seperti yang dijelaskan dalam lalu lintas Pesan setelah koneksi ulang ke sesi persisten. Jika sessionPresent ya1, klien tidak perlu berlangganan kembali. Namun, jika sessionPresent ada0, tidak ada sesi persisten yang hadir dan klien harus berlangganan kembali ke filter topiknya.

Setelah klien bergabung dengan sesi persisten, klien dapat mempublikasikan pesan dan berlangganan filter topik tanpa tanda tambahan pada setiap operasi.

Lalu lintas pesan setelah koneksi ulang ke sesi persisten

Sesi persisten mewakili hubungan yang sedang berlangsung antara klien dan broker pesan MQTT. Ketika klien terhubung ke broker pesan menggunakan sesi persisten, broker pesan menyimpan semua langganan yang dibuat klien selama koneksi. Ketika klien terputus, broker pesan menyimpan pesan QoS 1 yang tidak diakui dan pesan QoS 1 baru yang dipublikasikan ke topik yang menjadi langganan klien. Pesan disimpan sesuai dengan batas akun. Pesan yang melebihi batas akan dihapus. Untuk informasi selengkapnya tentang batas pesan persisten, lihat AWS IoT Core titik akhir dan kuota. Ketika klien terhubung kembali ke sesi persistennya, semua langganan dipulihkan dan semua pesan yang disimpan dikirim ke klien dengan kecepatan maksimum 10 pesan per detik. Di MQTT 5, jika QoS 1 keluar dengan Interval Kedaluwarsa Pesan berakhir saat klien offline, setelah koneksi dilanjutkan, klien tidak akan menerima pesan kedaluwarsa.

Setelah koneksi ulang, pesan yang disimpan dikirim ke klien, dengan kecepatan yang dibatasi hingga 10 pesan tersimpan per detik, bersama dengan lalu lintas pesan saat ini hingga Publish requests per second per connectionbatas tercapai. Karena tingkat pengiriman pesan yang disimpan terbatas, akan memakan waktu beberapa detik untuk mengirimkan semua pesan yang disimpan jika sesi memiliki lebih dari 10 pesan tersimpan untuk dikirim setelah koneksi ulang.

Untuk pelanggan bersama, pesan akan diantrian jika setidaknya satu pelanggan grup menggunakan sesi persisten dan tidak ada pelanggan yang online untuk menerima pesan QoS 1. Dequeuing pesan dilakukan dengan kecepatan maksimum 20 pesan per detik per pelanggan aktif dalam grup. Untuk informasi selengkapnya, lihat antrian pesan langganan bersama.

Mengakhiri sesi persisten

Sesi persisten dapat diakhiri dengan cara-cara berikut:

Di MQTT 3, nilai default dari waktu kedaluwarsa sesi persisten adalah satu jam, dan ini berlaku untuk semua sesi di akun.

Di MQTT 5, Anda dapat mengatur Interval Kedaluwarsa Sesi untuk setiap sesi pada paket CONNECT dan DISCONNECT.

Untuk Interval Kedaluwarsa Sesi pada paket DISCONNECT:

Koneksi ulang setelah sesi persisten telah kedaluwarsa

Jika klien tidak terhubung kembali ke sesi persistennya sebelum berakhir, sesi berakhir dan pesan yang disimpan akan dibuang. Ketika klien tersambung kembali setelah sesi berakhir dengan cleanSession tanda ke0, layanan akan membuat sesi persisten baru. Setiap langganan atau pesan dari sesi sebelumnya tidak tersedia untuk sesi ini karena mereka dibuang ketika sesi sebelumnya kedaluwarsa.

Biaya pesan sesi persisten

Pesan dibebankan kepada Anda Akun AWS ketika broker pesan mengirim pesan ke klien atau sesi persisten offline. Ketika perangkat offline dengan sesi persisten menghubungkan kembali dan melanjutkan sesi, pesan yang disimpan dikirim ke perangkat dan dibebankan ke akun Anda lagi. Untuk informasi selengkapnya tentang harga pesan, lihat AWS IoT Core harga - Pesan.

Waktu kedaluwarsa sesi persisten default satu jam dapat ditingkatkan dengan menggunakan proses peningkatan batas standar. Perhatikan bahwa meningkatkan waktu kedaluwarsa sesi dapat meningkatkan biaya pesan Anda karena waktu tambahan dapat memungkinkan lebih banyak pesan disimpan untuk perangkat offline dan pesan tambahan tersebut akan dibebankan ke akun Anda dengan tarif pesan standar. Waktu kedaluwarsa sesi adalah perkiraan dan sesi dapat bertahan hingga 30 menit lebih lama dari batas akun; Namun, sesi tidak akan lebih pendek dari batas akun. Untuk informasi selengkapnya tentang batas sesi, lihat AWS Service Quotas.

Pesan yang dipertahankan MQTT

AWS IoT Core mendukung RETAIN bendera yang dijelaskan dalam protokol MQTT. Saat klien menyetel RETAIN bendera pada pesan MQTT yang diterbitkannya, AWS IoT Core akan menyimpan pesan tersebut. Kemudian dapat dikirim ke pelanggan baru, diambil dengan memanggil GetRetainedMessageoperasi, dan dilihat di AWS IoT konsol.

Tugas umum dengan pesan yang disimpan MQTT di AWS IoT Core

AWS IoT Core menyimpan pesan MQTT dengan set bendera. RETAIN Pesan yang disimpan ini dikirim ke semua klien yang telah berlangganan topik, sebagai pesan MQTT normal, dan mereka juga disimpan untuk dikirim ke pelanggan baru ke topik tersebut.

Pesan yang disimpan MQTT memerlukan tindakan kebijakan khusus untuk memberi wewenang kepada klien untuk mengaksesnya. Untuk contoh penggunaan kebijakan pesan yang dipertahankan, lihatContoh kebijakan pesan yang dipertahankan.

Bagian ini menjelaskan operasi umum yang melibatkan pesan yang disimpan.

Penagihan dan pesan yang disimpan

Menerbitkan pesan dengan RETAIN tanda yang disetel dari klien, menggunakan AWS IoT konsol, atau dengan menelepon Publishmenimbulkan biaya pesan tambahan yang dijelaskan dalam AWS IoT Core harga - Pesan.

Mengambil pesan yang disimpan oleh klien, dengan menggunakan AWS IoT konsol, atau dengan menelepon GetRetainedMessagemenimbulkan biaya pengiriman pesan selain biaya penggunaan API normal. Biaya tambahan dijelaskan dalam AWS IoT Core harga - Pesan.

MQTT Akan pesan yang dipublikasikan ketika perangkat terputus secara tak terduga dikenakan biaya pesan yang dijelaskan dalam harga - Pesan.AWS IoT Core

Untuk informasi selengkapnya tentang biaya pengiriman pesan, lihat AWS IoT Core harga - Pesan.

Membandingkan pesan yang dipertahankan MQTT dan sesi persisten MQTT

Pesan yang disimpan dan sesi persisten adalah fitur standar MQTT yang memungkinkan perangkat menerima pesan yang diterbitkan saat sedang offline. Pesan yang disimpan dapat dipublikasikan dari sesi persisten. Bagian ini menjelaskan aspek-aspek kunci dari fitur-fitur ini dan bagaimana mereka bekerja sama.

Untuk informasi tentang sesi persisten, lihatSesi persisten MQTT.

Dengan Pesan Tertahan, klien penerbitan menentukan apakah pesan harus disimpan dan dikirim ke perangkat setelah tersambung, apakah pesan tersebut memiliki sesi sebelumnya atau tidak. Pilihan untuk menyimpan pesan dibuat oleh penerbit dan pesan yang disimpan dikirimkan ke semua klien saat ini dan masa depan yang berlangganan langganan QoS 0 atau QoS 1. Pesan yang disimpan hanya menyimpan satu pesan pada topik tertentu pada satu waktu.

Ketika akun telah menyimpan jumlah maksimum pesan yang disimpan, AWS IoT Core mengembalikan respons terbatas ke pesan yang diterbitkan dengan set RETAIN dan muatan lebih besar dari 0 byte hingga beberapa pesan yang disimpan dihapus dan jumlah pesan yang dipertahankan turun di bawah batas.

MQTT menyimpan pesan dan AWS IoT Bayangan Perangkat

Pesan yang disimpan dan Device Shadows menyimpan data dari perangkat, tetapi berperilaku berbeda dan melayani tujuan yang berbeda. Bagian ini menjelaskan persamaan dan perbedaan mereka.

Pesan Last Will and Testament (LWT) MQTT

Last Will and Testament (LWT) adalah fitur di MQTT. Dengan LWT, klien dapat menentukan pesan yang akan dipublikasikan broker ke topik yang ditentukan klien dan mengirimkannya ke semua klien yang berlangganan topik ketika pemutusan yang belum tahu terjadi. Pesan yang ditentukan klien disebut pesan LWT atau Pesan Will, dan topik yang ditentukan klien disebut sebagai Topik Will. Anda dapat menentukan pesan LWT saat perangkat terhubung ke broker. Pesan-pesan ini dapat dipertahankan dengan menyetel Will Retain bendera di Connect Flag bits bidang selama koneksi. Misalnya, jika Will Retain bendera disetel ke1, Pesan Will akan disimpan di broker di Topik Will terkait. Untuk informasi selengkapnya, lihat Akan Pesan.

Saat mengelola koneksi klien, Anda dapat mengontrol apakah pesan LWT dipublikasikan saat Anda memutuskan sambungan klien. Untuk informasi selengkapnya, lihat Manajemen koneksi MQTT.

Broker akan menyimpan Pesan Will sampai terjadi pemutusan yang belum diketahui. Ketika itu terjadi, broker akan mempublikasikan pesan ke semua klien yang berlangganan Topik Will untuk memberi tahu pemutusan. Jika klien terputus dari broker dengan pemutusan yang diprakarsai klien menggunakan pesan MQTT DISCONNECT, broker tidak akan mempublikasikan pesan LWT yang disimpan. Dalam semua kasus lain, pesan LWT akan dikirim. Karena sifat asinkron dari pemrosesan pemutusan sambungan, pesan LWT tidak dijamin akan dikirim secara berurutan selama penyambungan ulang. Kami menyarankan Anda menggunakan peristiwa siklus hidup untuk meningkatkan akurasi deteksi status konektivitas, karena peristiwa ini menyediakan atribut seperti stempel waktu dan nomor versi untuk mengelola peristiwa yang tidak sesuai pesanan. Untuk daftar lengkap skenario pemutusan ketika broker akan mengirim pesan LWT, lihat acara. Connect/Disconnect

Menggunakan ConnectAttributes

ConnectAttributesmemungkinkan Anda untuk menentukan atribut apa yang ingin Anda gunakan dalam pesan connect Anda dalam kebijakan IAM Anda seperti PersistentConnect danLastWill. DenganConnectAttributes, Anda dapat membuat kebijakan yang tidak memberikan akses perangkat ke fitur baru secara default, yang dapat membantu jika perangkat dikompromikan.

connectAttributesmendukung fitur-fitur berikut:

Secara default, kebijakan Anda memiliki koneksi non-persisten dan tidak ada atribut yang diteruskan untuk koneksi ini. Anda harus menentukan koneksi persisten dalam kebijakan IAM Anda jika Anda ingin memilikinya.

Saat mengelola koneksi klien melalui konsol atau API, Anda dapat melihat atribut koneksi dan konfigurasi sesi untuk klien yang terhubung. Untuk informasi selengkapnya, lihat Manajemen koneksi MQTT.

Untuk ConnectAttributes contoh, lihat Connect Policy Examples.

Fitur yang didukung MQTT 5

AWS IoT Core dukungan untuk MQTT 5 didasarkan pada spesifikasi MQTT v5.0 dengan beberapa perbedaan seperti yang didokumentasikan dalam. AWS IoT perbedaan dari spesifikasi MQTT

Langganan bersama

AWS IoT Core mendukung langganan bersama untuk MQTT 3.1.1 dan MQTT 5. Langganan bersama memungkinkan beberapa klien untuk berbagi langganan ke topik dan hanya satu klien yang akan menerima pesan yang dipublikasikan ke topik tersebut menggunakan distribusi acak. Langganan bersama dapat secara efektif memuat pesan MQTT saldo di sejumlah pelanggan. Misalnya, Anda memiliki 1.000 perangkat yang menerbitkan topik yang sama, dan 10 aplikasi backend memproses pesan tersebut. Dalam hal ini, aplikasi backend dapat berlangganan topik yang sama, dan masing-masing akan secara acak menerima pesan yang diterbitkan oleh perangkat ke topik bersama. Ini secara efektif “berbagi” beban pesan-pesan itu. Langganan bersama juga memungkinkan ketahanan yang lebih baik. Ketika aplikasi backend terputus, broker mendistribusikan beban ke pelanggan yang tersisa dalam grup. Ketika semua pelanggan terputus, pesan diantri.

Kemampuan antrian pesan tersedia untuk langganan bersama pada koneksi MQTT 3.1.1 dan MQTT 5 untuk meningkatkan keandalan pengiriman pesan.

Untuk menggunakan langganan bersama, klien berlangganan filter topik langganan bersama sebagai berikut:

$share/{ShareName}/{TopicFilter}

Langganan yang memiliki yang sama {ShareName}/{TopicFilter} termasuk dalam grup langganan bersama yang sama. Anda dapat membuat beberapa grup langganan bersama dan tidak melebihi batas Langganan Bersama per grup. Untuk informasi selengkapnya, lihat AWS IoT Core titik akhir dan kuota dari Referensi AWS Umum.

Tabel berikut membandingkan langganan non-bersama dan langganan bersama:

sports/tennis
sports/#

$share/consumer/sports/tennis
$share/consumer/sports/#

Non-shared aliran langganan	Alur langganan bersama

Catatan penting untuk menggunakan langganan bersama

Untuk informasi selengkapnya tentang batas langganan bersama, lihat AWS IoT Core titik akhir dan kuota dari Referensi Umum.AWS Untuk menguji langganan bersama menggunakan klien AWS IoT MQTT di konsol, lihat.AWS IoT Menguji Langganan Bersama di klien MQTT Anda juga dapat melihat topik mana klien yang terhubung berlangganan, termasuk langganan bersama, dengan menggunakan fitur manajemen koneksi klien. Untuk informasi selengkapnya, lihat Manajemen koneksi MQTT. Untuk informasi selengkapnya tentang langganan bersama, lihat Langganan Bersama dari spesifikasi. MQTTv5.0

Antrian pesan langganan bersama

Untuk meningkatkan keandalan pengiriman pesan, langganan bersama mencakup kemampuan antrian pesan yang menyimpan pesan ketika tidak ada pelanggan online yang tersedia. Jika grup langganan bersama berisi setidaknya satu anggota dengan sesi persisten, fitur antrian diaktifkan untuk grup. Saat mendistribusikan pesan, anggota online dipilih sebagai penerima. Pesan QoS 1 diantrian ketika tidak ada anggota yang ditemukan online atau ketika pelanggan melebihi batas. Publish requests per second per connection Pesan antrian dikirimkan ketika anggota yang ada melanjutkan sesi persisten mereka, atau anggota baru bergabung dengan grup. Pesan antrian dikirimkan hingga 20 pesan antrian per detik per pelanggan grup aktif, bersama dengan pesan lain yang dikirimkan ke pelanggan sesuai langganan.

Secara default, penyimpanan pesan antrian mengikuti kuota. Persistent Session expiry period Namun, jika Interval Kedaluwarsa Pesan (MEI) diatur dalam pesan publikasi masuk, MEI akan diutamakan. Ketika MEI hadir, ini menentukan periode penyimpanan pesan, terlepas dari periode kedaluwarsa Sesi Persisten.

Tarif antrian pesan dibatasi sesuai dengan Queued messages per second per accountkuota, dan jumlah pesan dibatasi oleh Maximum number of queued messages per shared subscription groupkuota. Untuk melihat dan mengelola kuota Anda, akses konsol Service Quotas.

Anda dapat memantau Antrian CloudWatch dengan mencari ApproximateQueueDepth di bawah AWS/Usage namespace, atau Anda dapat menggunakan perintah CLI berikut untuk membuat daftar metrik yang terkait dengan kedalaman antrian setiap grup langganan bersama.

aws cloudwatch list-metrics --namespace "AWS/Usage" --dimensions Name=Resource,Value='ApproximateQueueDepth'

Ketika batas ini terlampaui, hanya pesan yang sudah antri sebelum mencapai batas yang dipertahankan. Pesan masuk baru yang akan melebihi batas dijatuhkan. Sistem tidak mengganti pesan antrian yang lebih lama dengan yang lebih baru.

Antrian pesan direkam dalam CloudWatch metrik dan Log. CloudWatch Untuk informasi tentang entri yang ditulis ke CloudWatch dan CloudWatch Log, lihat Metrik broker pesan danEntri log antrian. Pesan antrian masih ditagih pada tingkat pesan standar. Untuk informasi selengkapnya tentang harga pesan, lihat AWS IoT Core Harga.

Siklus hidup sesi dalam grup langganan bersama

Ketika sesi bersih berlangganan grup, itu menjadi anggota online grup. Ketika berhenti berlangganan atau terputus, sesi bersih meninggalkan grup.

Ketika sesi persisten berlangganan ke grup, itu menjadi anggota online grup. Ketika terputus, itu masih tetap dalam grup, tetapi menjadi anggota offline grup. Ketika terhubung kembali, itu menjadi anggota online lagi. Sesi persisten meninggalkan grup ketika secara eksplisit berhenti berlangganan atau ketika kedaluwarsa setelah terputus.

Mulai Bersih dan Kedaluwarsa Sesi

Anda dapat menggunakan Clean Start dan Session Expiry untuk menangani sesi persisten Anda dengan lebih fleksibel. Bendera Mulai Bersih menunjukkan apakah sesi harus dimulai tanpa menggunakan sesi yang ada. Interval Kedaluwarsa Sesi menunjukkan berapa lama untuk mempertahankan sesi setelah pemutusan. Interval kedaluwarsa sesi dapat dimodifikasi pada saat pemutusan. Untuk informasi selengkapnya, lihat Sesi persisten MQTT.

Kode alasan di semua ACK

Anda dapat men-debug atau memproses pesan kesalahan dengan lebih mudah menggunakan kode alasan. Kode alasan dikembalikan oleh broker pesan berdasarkan jenis interaksi dengan broker (Berlangganan, Publikasikan, Akui). Untuk informasi lebih lanjut, lihat kode alasan MQTT. Untuk daftar lengkap kode alasan MQTT, lihat Spesifikasi MQTT v5.

Alias topik

Anda dapat mengganti nama topik dengan alias topik, yang merupakan bilangan bulat dua byte. Menggunakan alias topik dapat mengoptimalkan transmisi nama topik untuk berpotensi mengurangi biaya data pada layanan data terukur. AWS IoT Core memiliki batas default 8 alias topik. Untuk informasi selengkapnya, lihat AWS IoT Core titik akhir dan kuota dari Referensi AWS Umum.

Kedaluwarsa pesan

Anda dapat menambahkan nilai kedaluwarsa pesan ke pesan yang dipublikasikan. Nilai-nilai ini mewakili Interval Kedaluwarsa Pesan (MEI) dalam hitungan detik. Jika pesan belum dikirim ke pelanggan dalam interval tersebut, pesan akan kedaluwarsa dan dihapus. Jika Anda tidak menetapkan nilai kedaluwarsa pesan, pesan tidak akan kedaluwarsa.

Pada outbound, pelanggan akan menerima pesan dengan sisa waktu yang tersisa dalam interval kedaluwarsa. Misalnya, jika pesan publikasi masuk memiliki pesan kedaluwarsa 30 detik, dan dialihkan ke pelanggan setelah 20 detik, bidang kedaluwarsa pesan akan diperbarui menjadi 10. Dimungkinkan untuk pesan yang diterima oleh pelanggan untuk memiliki MEI yang diperbarui sebesar 0. Ini karena segera setelah waktu yang tersisa adalah 999 ms atau kurang, itu akan diperbarui ke 0.

Dalam AWS IoT Core, MEI minimum adalah 1. Jika interval diatur ke 0 dari sisi klien, itu akan disesuaikan ke 1. Interval kadaluwarsa pesan maksimum adalah 604800 (7 hari). Nilai apa pun yang lebih tinggi dari ini akan disesuaikan dengan nilai maksimum.

Dalam komunikasi lintas versi, perilaku kedaluwarsa pesan ditentukan oleh versi MQTT dari pesan publikasi masuk. Misalnya, pesan dengan kedaluwarsa pesan yang dikirim oleh sesi yang terhubung melalui MQTT5 dapat kedaluwarsa untuk perangkat yang berlangganan sesi MQTT3. Tabel di bawah ini mencantumkan cara kedaluwarsa pesan mendukung jenis pesan publikasi berikut:

Fitur MQTT 5 lainnya

Putuskan sambungan server

Ketika pemutusan terjadi, server dapat secara proaktif mengirim klien DISCONNECT untuk memberi tahu penutupan koneksi dengan kode alasan untuk pemutusan.

Request/Response

Penayang dapat meminta tanggapan dikirim oleh penerima ke topik yang ditentukan penerbit pada saat penerimaan.

Ukuran Paket Maksimum

Klien dan Server dapat secara independen menentukan ukuran paket maksimum yang mereka dukung.

Format payload dan jenis konten

Anda dapat menentukan format payload (biner, teks) dan jenis konten saat pesan dipublikasikan. Ini diteruskan ke penerima pesan.

Properti MQTT 5

Properti MQTT 5 merupakan tambahan penting pada standar MQTT untuk mendukung fitur MQTT 5 baru seperti Session Expiry dan polanya. Request/Response Di AWS IoT Core, Anda dapat membuat aturan yang dapat meneruskan properti dalam pesan keluar, atau menggunakan HTTP Publish untuk mempublikasikan pesan MQTT dengan beberapa properti baru.

Tabel berikut mencantumkan semua properti MQTT 5 yang mendukung. AWS IoT Core

Kode alasan MQTT

MQTT 5 memperkenalkan pelaporan kesalahan yang ditingkatkan dengan respons kode alasan. AWS IoT Core dapat mengembalikan kode alasan termasuk tetapi tidak terbatas pada berikut dikelompokkan berdasarkan paket. Untuk daftar lengkap kode alasan yang didukung oleh MQTT 5, lihat spesifikasi MQTT 5.

AWS IoT perbedaan dari spesifikasi MQTT

Implementasi broker pesan didasarkan pada spesifikasi MQTT v3.1.1 dan spesifikasi MQTT v5.0, tetapi berbeda dari spesifikasi dengan cara ini:

Manajemen koneksi MQTT

AWS IoT Core menyediakan API dan fitur konsol untuk membantu Anda mengelola koneksi MQTT, termasuk kemampuan untuk memutuskan sambungan klien, melihat detail koneksi, dan mengelola sesi mereka. Kemampuan ini memberi Anda kontrol lebih besar atas armada AWS IoT klien Anda dan membantu mengatasi masalah koneksi.

Memutuskan sambungan klien MQTT

Gunakan DeleteConnection API untuk memutuskan sambungan perangkat MQTT AWS IoT Core dengan menentukan ID klien mereka. Ketika Anda memutuskan klien, AWS IoT Core putuskan klien dari broker AWS IoT Core pesan dan secara opsional dapat membersihkan status sesi dan menekan pesan Kehendak dan Perjanjian Terakhir (LWT).

Saat Anda memanggil DeleteConnection API, AWS IoT Core lakukan beberapa tindakan untuk memastikan pemutusan yang bersih. AWS IoT Core pertama mengirimkan pesan pemutusan MQTT ke klien untuk mengakhiri sesi MQTT. Layanan kemudian menutup TCP/TLS soket yang mendasarinya.

Broker pesan mengirimkan DISCONNECT paket ke perangkat dan menerbitkan peristiwa siklus hidup dengan alasan pemutusan sambungan. API_INITIATED_DISCONNECT Ini membantu Anda mengidentifikasi kapan pemutusan dimulai melalui API daripada oleh klien atau karena masalah jaringan. Anda dapat memantau peristiwa ini untuk tujuan visibilitas, pemecahan masalah, dan audit. Misalnya, Anda dapat menggunakan AWS IoT aturan untuk memproses peristiwa ini untuk melacak kapan dan mengapa klien terputus.

Jika Anda menyetel cleanSession parameter ketrue, AWS IoT Core menghapus status sesi klien, termasuk semua langganan dan pesan antrian. Jika Anda membersihkan sesi, sesi persisten dihentikan. Jika klien adalah sesi persisten dan preventWillMessage parameter diatur kefalse, layanan mengirimkan pesan LWT jika tersedia, yang berguna selama operasi pemeliharaan yang direncanakan.

Saat Anda memanggil DeleteConnection API, proses pemutusan segera dimulai, tetapi waktu yang tepat kapan klien mengenali pemutusan dapat bervariasi berdasarkan kondisi jaringan dan implementasi klien. Sebagian besar klien akan mendeteksi pemutusan dalam beberapa detik, tetapi dalam beberapa kasus dengan konektivitas jaringan yang buruk, mungkin perlu waktu lebih lama bagi klien untuk mengenali bahwa itu telah terputus.

Untuk informasi lebih lanjut tenngenai harga, lihat harga AWS IoT Core.

Kasus penggunaan

DeleteConnectionAPI berguna untuk mengelola klien yang berperilaku buruk yang menunjukkan perilaku bermasalah atau mengkonsumsi sumber daya yang berlebihan. Dengan memaksa pemutusan sambungan, Anda dapat memastikan bahwa klien membangun kembali koneksi mereka dengan otentikasi dan otorisasi yang tepat, yang dapat membantu menyelesaikan masalah konsumsi sumber daya.

Skenario pengalihan klien juga mendapat manfaat dari API ini. Saat Anda perlu mengarahkan klien ke titik akhir yang berbeda atau Wilayah AWS, Anda dapat memutuskannya secara terprogram dan menyambungkannya kembali ke titik akhir yang berbeda AWS IoT Core dengan mengubah pengaturan DNS. API ini dapat membantu menyelesaikan koneksi yang macet atau menghapus status sesi bermasalah yang mungkin mencegah operasi normal.

Parameter API:

DeleteConnectionAPI menerima parameter berikut:

Sintaks API

DeleteConnectionAPI menggunakan format permintaan HTTP berikut:

DELETE /connections/<clientId>?cleanSession=<cleanSession>&preventWillMessage=<preventWillMessage> HTTP/1.1

Permintaan contoh:

// Basic disconnect (preserves session, allows LWT message)
DELETE /connections/myDevice123 HTTP/1.1

// Disconnect and clear session
DELETE /connections/myDevice123?cleanSession=TRUE HTTP/1.1

// Disconnect, clear session, and prevent LWT message
DELETE /connections/myDevice123?cleanSession=TRUE&preventWillMessage=TRUE HTTP/1.1

Permintaan yang berhasil mengembalikan HTTP 200 OK tanpa badan respons.

Izin yang diperlukan

Untuk menggunakan DeleteConnection API, Anda memerlukan izin IAM berikut:

iot:DeleteConnection

Anda dapat membuat cakupan izin ini ke ID klien tertentu menggunakan kebijakan berbasis sumber daya. Contoh:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iot:DeleteConnection",
            "Resource": "arn:aws:iot:us-east-1:987654321:client/myDevice*"
        }
    ]
}

Pertimbangan penting

Klien yang terputus dapat segera mencoba menyambung kembali kecuali Anda telah menerapkan logika tambahan untuk mencegah penyambungan kembali. Operasi pemutusan hanya menghentikan koneksi saat ini dan tidak mencegah koneksi terhubung kembali. Jika Anda perlu mencegah koneksi ulang, pertimbangkan untuk menerapkan logika sisi klien atau menonaktifkan kredensi perangkat.

Batas tarif berlaku untuk API sebagai bagian dari pembatasan tarif AWS IoT Core API standar. Saat merencanakan operasi pemutusan massal, pastikan Anda memperhitungkan batasan ini dan menerapkan logika coba ulang dan strategi batching yang sesuai untuk menghindari pelambatan. Untuk informasi lebih lanjut, lihat AWS IoT Core kuota dan titik akhir.

Tanggapan kesalahan

DeleteConnectionAPI dapat mengembalikan respons kesalahan berikut:

Melihat detail koneksi

Gunakan GetConnection API untuk mengambil informasi terperinci tentang koneksi klien MQTT aktif, termasuk status koneksi, detail sesi, dan informasi jaringan.

GetConnectionAPI menampilkan metadata koneksi komprehensif yang membantu mengatasi masalah konektivitas, memantau perilaku klien, dan mengaudit pola koneksi. Anda dapat menggunakan informasi ini untuk memahami siklus hidup koneksi klien dan mendiagnosis masalah dengan sesi MQTT. Informasi koneksi tersedia selama 30 menit setelah pemutusan terlepas dari apakah klien menggunakan sesi bersih atau persisten. Untuk metatdata yang terputus lebih dari 30 menit, gunakan GetThingConnectivityDataAPI yang mengharuskan pengindeksan armada diaktifkan.

Kasus penggunaan

GetConnectionAPI berguna untuk memecahkan masalah koneksi dan memantau perilaku klien. Anda dapat memverifikasi status konektivitas klien, memeriksa pengaturan sesi persisten, dan meninjau stempel waktu koneksi untuk memahami pola konektivitas klien.

Diagnostik jaringan juga mendapat manfaat dari API ini. Rincian koneksi termasuk sumber dan alamat IP target dan port, yang membantu mengidentifikasi masalah perutean jaringan atau masalah titik akhir koneksi. Informasi ini berharga saat men-debug masalah konektivitas atau mengoptimalkan konfigurasi jaringan.

Parameter API:

GetConnectionAPI menerima parameter berikut:

Sintaks API

GetConnectionAPI menggunakan format permintaan HTTP berikut:

GET /connections/<client-id>?includeSocketInformation=false HTTP/1.1

Permintaan contoh:

GET /connections/myDevice123?includeSocketInformation=false HTTP/1.1

// Get connection details for a client with special characters (URL encoded)
// Original client ID: "my device/123"
GET /connections/my%20device%2F123?includeSocketInformation=true HTTP/1.1

Contoh respons untuk klien yang terhubung:

{
    "clientId": "abcd12345fvgbh",
    "connected": true,
    "cleanSession": false,
    "connectedSince": 1573002340451,
    "thingName": "deviceABC",
    "sourceIp": "203.0.113.1",
    "sourcePort": 8883,
    "targetIp": "198.51.100.1",
    "targetPort": 8883,
    "keepAliveDuration": 60,
    "disconnectReason": null,
    "sessionExpiry": 3600
}

Bidang respons:

Izin yang diperlukan

Untuk menggunakan GetConnection API, Anda memerlukan izin IAM berikut:

iot:GetConnection

Anda dapat membuat cakupan izin ini ke ID klien tertentu menggunakan kebijakan berbasis sumber daya.

Contoh kebijakan otorisasi

Contoh 1: Izinkan GetConnection dengan informasi soket untuk semua klien

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iot:GetConnection",
            "Resource": "arn:aws:iot:us-east-1:987654321:client/*"
        }
    ]
}

Dengan kebijakan ini, panggilan API berikut menampilkan detail koneksi termasuk informasi soket:

GET /connections/myDevice123?includeSocketInformation=true HTTP/1.1

Hasil: API mengembalikan semua bidang koneksi, termasuksourceIp,sourcePort,targetIp, dantargetPort.

Contoh 2: Izinkan GetConnection tetapi tolak informasi soket untuk klien tertentu

Anda dapat menggunakan pendekatan berbasis kondisi atau pendekatan penolakan eksplisit:

Condition-based pendekatan:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iot:GetConnection",
            "Resource": "arn:aws:iot:us-east-1:987654321:client/myDevice*",
            "Condition": {
                "Bool": {
                    "iot:IncludeSocketInformation": "false"
                }
            }
        }
    ]
}

Pendekatan penolakan eksplisit:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "iot:GetConnection",
            "Resource": "arn:aws:iot:us-east-1:987654321:client/myDevice*",
            "Condition": {
                "Bool": {
                    "iot:IncludeSocketInformation": "true"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": ["iot:GetConnection"],
            "Resource": "arn:aws:iot:us-east-1:987654321:client/myDevice*"
        }
    ]
}

Dengan salah satu kebijakan, panggilan API berikut ditolak:

GET /connections/myDevice123?includeSocketInformation=true HTTP/1.1

Hasil: API mengembalikan kesalahan 403 Forbidden karena akses informasi soket dibatasi untuk klien ini.

Tanggapan kesalahan

GetConnectionAPI dapat mengembalikan respons kesalahan berikut:

Mengelola langganan klien

Gunakan ListSubscriptions API untuk mengambil semua langganan topik untuk sesi klien MQTT. API ini mengembalikan langganan untuk klien yang terhubung dan klien offline dengan sesi persisten, memberikan visibilitas ke dalam pola langganan klien dan membantu memecahkan masalah terkait langganan.

ListSubscriptionsAPI menyediakan informasi langganan komprehensif yang membantu mengaudit perilaku klien, memecahkan masalah pengiriman pesan, dan memahami pola langganan di seluruh armada perangkat Anda. Anda dapat menggunakan informasi ini untuk memverifikasi bahwa klien berlangganan topik yang diharapkan dan mengidentifikasi potensi konflik berlangganan.

Kasus penggunaan

ListSubscriptionsAPI membantu Anda memecahkan masalah pengiriman pesan dan mengaudit perilaku berlangganan klien. Gunakan API ini untuk memverifikasi topik mana klien berlangganan, memvalidasi level QoS, dan mengidentifikasi langganan yang tumpang tindih atau kartu sementara yang terlalu permisif.

Skenario manajemen langganan juga mendapat manfaat dari API ini. Saat klien melaporkan pesan yang hilang atau pengiriman pesan yang tidak terduga, Anda dapat menggunakan API ini untuk memverifikasi langganan mereka saat ini dan memastikannya sesuai dengan konfigurasi yang diharapkan. Ini sangat berharga untuk men-debug hierarki langganan yang kompleks dan konfigurasi langganan bersama.

Parameter API:

ListSubscriptionsAPI menerima parameter berikut:

Sintaks API

ListSubscriptionsAPI menggunakan format permintaan HTTP berikut:

GET /connections/<client-id>/subscriptions?nextToken=token&maxResults=max HTTP/1.1

Permintaan contoh:

// Get subscriptions for a specific client
GET /connections/myDevice123/subscriptions HTTP/1.1

// Get subscriptions with custom page size
GET /connections/myDevice123/subscriptions?maxResults=50 HTTP/1.1

// Get next page of results using pagination token
GET /connections/myDevice123/subscriptions?nextToken=eyJhbGciOiJIUzI1NiJ9&maxResults=50 HTTP/1.1

Contoh respons:

{
    "subscriptions": [
        {"topicFilter": "device/myDevice123/commands", "qos": 1},
        {"topicFilter": "device/myDevice123/shadow", "qos": 0}
    ],
    "nextToken": "eyJhbGciOiJIUzI1NiJ9"
}

Bidang respons:

Izin yang diperlukan

Untuk menggunakan ListSubscriptions API, Anda memerlukan izin IAM berikut:

iot:ListSubscriptions

Anda dapat membuat cakupan izin ini ke ID klien tertentu menggunakan kebijakan berbasis sumber daya. Contoh:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iot:ListSubscriptions",
            "Resource": "arn:aws:iot:us-east-1:987654321:client/myDevice*"
        }
    ]
}

Tanggapan kesalahan

ListSubscriptionsAPI dapat mengembalikan respons kesalahan berikut:

Manajemen koneksi MQTT menggunakan konsol

Anda dapat menggunakan AWS IoT konsol untuk memutuskan sambungan perangkat MQTT dan mengelola koneksi mereka. Konsol menyediakan antarmuka intuitif untuk melihat perangkat yang terhubung dan melakukan operasi pemutusan sambungan.

Lihat klien MQTT yang terhubung

Prosedur ini menunjukkan kepada Anda cara melihat perangkat MQTT yang saat ini terhubung di konsol. AWS IoT

Lihat langganan klien MQTT

Prosedur ini menunjukkan cara melihat langganan topik untuk klien MQTT tertentu menggunakan konsol. AWS IoT

Putuskan sambungan perangkat MQTT

Prosedur ini menunjukkan kepada Anda cara memutuskan sambungan perangkat MQTT tertentu menggunakan konsol. AWS IoT

AWS IoT perbedaan dari spesifikasi MQTT

Implementasi broker pesan didasarkan pada spesifikasi MQTT v3.1.1 dan spesifikasi MQTT v5.0, tetapi berbeda dari spesifikasi dengan cara ini:

CloudWatch Log AWS IoT entri log

Broker AWS IoT pesan menghasilkan entri log dengan eventType Connect kapan klien MQTT terhubung.

Connect contoh entri log

{
    "timestamp": "2017-08-10 15:37:23.476",
    "logLevel": "INFO",
    "traceId": "20b23f3f-d7f1-feae-169f-82263394fbdb",
    "accountId": "123456789012",
    "status": "Success",
    "eventType": "Connect",
    "protocol": "MQTT",
    "clientId": "abf27092886e49a8a5c1922749736453",
    "thingName": "myDevice",
    "principalId": "145179c40e2219e18a909d896a5340b74cf97a39641beec2fc3eeafc5a932167",
    "sourceIp": "205.251.233.181",
    "sourcePort": 13490,
    "keepAliveDuration": 60,
    "sessionExpiry": 3600,
    "cleanSession": boolean
}

Selain atribut CloudWatch Log umum, Connect entri log berisi atribut berikut: