MQTT

MQTT (Message Queuing Telemetry Transport) adalah protokol perpesanan 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 M QTT 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, peningkatan pelaporan kesalahan 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 versi MQTT lintas (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. Men AWS IoT SDK Perangkat dukung kedua protokol dan merupakan cara yang disarankan untuk menghubungkan perangkat ke AWS IoT Core. SDK AWS IoT Perangkat mendukung fungsi yang diperlukan untuk perangkat dan klien untuk terhubung dan mengakses AWS IoT layanan. SDK Perangkat mendukung protokol otentikasi yang diperlukan AWS IoT layanan dan persyaratan ID koneksi yang diperlukan protokol MQTT dan MQTT melalui protokol WSS. Untuk informasi tentang cara menyamb AWS IoT ung menggunakan AWS SDK 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 merekomendasikan menggunakan AWS IoT SDK Perangkat untuk terhubung AWS IoT, mereka tidak diperlukan. Namun, jika Anda tidak menggunakan SDK AWS IoT Perangkat, Anda harus menyediakan koneksi dan keamanan komunikasi yang diperlukan. Klien harus mengirim ekstensi TLS Indikasi Nama Server (SNI) dalam permintaan koneksi. Upaya koneksi yang tidak menyertakan SNI ditolak. Untuk informasi selengkapnya, lihat Keamanan Transportasi di AWS IoT. Klien yang menggunakan pengguna dan AWS kredentif IAM untuk mengotentikasi klien harus memberikan otentikasi Tanda Tangan Versi 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 AWS IoT SDK Perangkat dan ke kode sumber program sampel yang menggambarkan cara menghubungkan perangkat ke 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 AWS IoT Device SDK mendukung level MQTT Quality of Service (QoS) dan. 01 Protokol MQTT mendefinisikan tingkat ketiga QoS, level2, tetapi AWS IoT tidak mendukungnya. 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 mempengaruhi pesan yang diterbitkan ke dan oleh broker pesan.

Sesi persisten MQTT

Sesi persisten menyimpan langganan dan pesan klien, dengan Kualitas Layanan (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 dicatat dalam CloudWatch metrik dan CloudWatch Log. Untuk informasi tentang entri yang ditulis ke CloudWatch dan CloudWatch Log, lihat Metrik broker pesan danEntri log yang diantri.

Membuat sesi persisten

Di MQTT 3, Anda membuat sesi persisten MQTT dengan mengirim CONNECT pesan dan mengatur cleanSession bendera ke. 0 Jika tidak ada sesi untuk klien yang mengirim CONNECT pesan, sesi persisten baru 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 mengatur Clean Start flag danSession 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. Ketika Anda meny Clean Start et 0 el =, sesi penghubung melanjutkan sesi sebelumnya jika ada. Interval Kedaluwarsa Sesi mengontrol akhir sesi penghubung. Interval Kedaluwarsa Sesi menentukan waktu, dalam detik (bilangan bulat 4-byte), bahwa sesi akan bertahan setelah pemutusan. Pengaturan Session Expiry interval = 0 menyebabkan sesi segera berakhir setelah terputus. Jika Interval Kedaluwarsa Sesi tidak ditentukan dalam pesan CONNECT, defaultnya adalah 0.

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

Operasi selama sesi persisten

Klien menggunakan sessionPresent atribut dalam pesan koneksi (CONNACK) untuk menentukan apakah sesi persisten hadir. Jika sessionPresent ya1, sesi persisten hadir dan pesan yang disimpan untuk klien dikirimkan 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 koneksi berkelanjutan antara klien dan broker pesan MQTT. Ketika klien terhubung ke broker pesan menggunakan sesi persisten, broker pesan menyimpan semua langganan yang dilakukan klien selama koneksi. Ketika klien terputus, broker pesan menyimpan pesan QoS 1 yang tidak diakui dan pesan QoS 1 baru yang diterbitkan ke topik yang berlangganan 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 persisten, 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 sampai Publish requests per second per connection batas 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 diantri jika setidaknya satu pelanggan grup menggunakan sesi persisten dan tidak ada pelanggan yang online untuk menerima pesan QoS 1. De-antrian pesan dilakukan pada 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 berakhir dengan cara berikut:

Di MQTT 3, nilai default 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 menyambung kembali ke sesi persisten sebelum kedaluwarsa, sesi berakhir dan pesan yang disimpan akan dibuang. Ketika klien menyambung kembali setelah sesi berakhir dengan tanda cleanSession ke0, layanan membuat sesi persisten baru. Setiap langganan atau pesan dari sesi sebelumnya tidak tersedia untuk sesi ini karena telah dibuang saat sesi sebelumnya berakhir.

Biaya pesan sesi persisten

Pesan dibebankan kepada Anda Akun AWS ketika broker pesan mengirim pesan ke klien atau sesi persisten offline. Saat perangkat offline dengan sesi persisten menyambung kembali dan melanjutkan sesinya, 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 Kuota Layanan.

Pesan yang dipertahankan MQTT

AWS IoT Core mendukung ben RETAIN dera yang dijelaskan dalam protokol MQTT. Ketika klien menetapkan RETAIN bendera pada pesan MQTT yang diterbitkan, AWS IoT Core menyimpan pesan tersebut. Kemudian dapat dikirim ke pelanggan baru, diambil dengan memanggil GetRetainedMessage operasi, dan dilihat di AWS IoT konsol.

Tugas umum dengan pesan yang dipertahankan MQTT di AWS IoT Core

AWS IoT Core menyimpan pesan MQTT dengan set RETAIN bendera. 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 untuk topik tersebut.

Pesan yang disimpan MQTT memerlukan tindakan kebijakan khusus untuk mengotorisasi 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 bendera yang ditetapkan dari klien, dengan menggunakan AWS IoT konsol, atau dengan menelepon akan Publish dikenakan biaya pengiriman pesan tambahan yang dijelaskan dalam AWS IoT Core Harga - Pesan.

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

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

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

Membandingkan pesan yang dipertahankan MQTT dan sesi persisten MQTT

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

Untuk informasi tentang sesi persisten, lihatSesi persisten MQTT.

Dengan Pesan Tersimpan, klien penerbitan menentukan apakah pesan harus dipertahankan dan dikirim ke perangkat setelah terhubung, 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 yang akan datang 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 dipertahankan, AWS IoT Core mengembalikan respons yang dibatasi untuk pesan yang diterbitkan dengan RETAIN set dan payload yang lebih besar dari 0 byte sampai 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 Bayangan Perangkat menyimpan data dari perangkat, tetapi mereka 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 mengirim ke semua klien yang berlangganan topik ketika pemutusan yang belum diketahui 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 mengatur 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 Will Messages.

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

Broker akan menyimpan Pesan Will sampai terjadi pemutusan yang belum tahu. Ketika itu terjadi, broker akan mempublikasikan pesan ke semua klien yang berlangganan Will Topic 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, pesan LWT tidak dijamin akan dikirim secara berurutan selama koneksi ulang. Sebaiknya gunakan peristiwa siklus hidup untuk meningkatkan akurasi deteksi status konektivitas, karena peristiwa ini menyediakan atribut seperti cap waktu dan nomor versi untuk mengelola peristiwa yang tidak berurutan. Untuk daftar lengkap skenario pemutusan ketika broker akan mengirim pesan LWT, lihat Connect/Disconnect acara.

Menggunakan ConnectAttributes

ConnectAttributesmemungkinkan Anda untuk menentukan atribut apa yang ingin Anda gunakan dalam pesan koneksi Anda di 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 jika Anda ingin memilikinya.

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

Sebagai ConnectAttributes contoh, lihat Contoh Kebijakan Hubun gkan.

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 menyeimbangkan pesan MQTT di sejumlah pelanggan. Misalnya, Anda memiliki 1.000 perangkat yang menerbitkan ke topik yang sama, dan 10 aplikasi backend yang 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 tersebut. 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 langganan yang sama {ShareName}/{TopicFilter} termasuk dalam grup langganan bersama yang sama. Anda dapat membuat beberapa grup langganan bersama dan tidak melebihi batas Lang ganan Bersama per grup. Untuk informasi selengkapnya, lihat AWS IoT Core titik akhir dan kuota dari Refer ensi AWS Umum.

Tabel berikut membandingkan langganan non-bersama dan langganan bersama:

sports/tennis
sports/#

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

Non-shared alur 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 Refer ensi AWS Umum. Untuk menguji langganan bersama menggunakan klien AWS IoT MQTT di AWS IoT konsol, lihatMenguji Langganan Bersama di klien MQTT. Anda juga dapat melihat topik yang berlangganan klien yang terhubung, 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 MQTTv5.0 spesifikasi.

Antrian pesan langganan bersama

Untuk meningkatkan keandalan pengiriman pesan, langganan bersama menyertakan kemampuan antrian pesan yang menyimpan pesan saat tidak ada pelanggan online yang tersedia. Bila 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 diantri ketika tidak ada anggota yang ditemukan online atau ketika pelanggan melebihi batas. Publish requests per second per connection Pesan yang mengantri dikirimkan ketika anggota yang ada melanjutkan sesi persisten mereka, atau anggota baru bergabung dengan grup. Pesan antri dikirim hingga 20 pesan antri per detik per pelanggan grup aktif, bersama dengan pesan lain yang dikirimkan ke pelanggan sesuai langganan.

Secara default, retensi pesan yang diantri mengikuti ku Persistent Session expiry period ota. Namun, jika Interval Kedaluwarsa Pesan (MEI) diatur dalam pesan penerbitan masuk, MEI diutamakan. Ketika MEI hadir, ini menentukan periode penyimpanan pesan, terlepas dari periode kedaluwarsa Sesi Persisten.

Tarif antrian pesan dibatasi sesuai ku Queued messages per second per account ota, dan jumlah pesan dibatasi oleh ku Maximum number of queued messages per shared subscription group ota. Untuk melihat dan mengelola kuota Anda, akses konsol Kuota Layanan.

Anda dapat memantau Antrian CloudWatch dengan mencari ApproximateQueueDepth di bawah AWS/Usage namespace, atau Anda dapat menggunakan perintah CLI berikut untuk mencantumkan 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 mengantri sebelum mencapai batas yang dipertahankan. Pesan masuk baru yang akan melebihi batas dihilangkan. Sistem tidak mengganti pesan antri lama dengan yang lebih baru.

Antrian pesan dicatat dalam CloudWatch metrik dan CloudWatch Log. Untuk informasi tentang entri yang ditulis ke CloudWatch dan CloudWatch Log, lihat Metrik broker pesan danEntri log yang diantri. Pesan yang mengantri masih ditagih dengan tarif 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 grup secara online. Ketika berhenti berlangganan atau terputus, sesi bersih meninggalkan grup.

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

Mulai Bersih dan Kedaluwarsa Sesi

Anda dapat menggunakan Clean Start dan Session Expiration untuk menangani sesi persisten Anda dengan lebih fleksibel. Bendera Clean Start 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 saat pemutusan. Untuk informasi selengkapnya, lihat Sesi persisten MQTT.

Kode alasan pada 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, Mengakui). Untuk informasi selengkapnya, 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 Refer ensi 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 pesan tersebut dialihkan ke pelanggan setelah 20 detik, bidang kedaluwarsa pesan akan diperbarui menjadi 10. Dimungkinkan bagi 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.

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

Dalam komunikasi lintas versi, perilaku kedaluwarsa pesan ditentukan oleh versi MQTT dari pesan penerbitan 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 bagaimana kedaluwarsa pesan mendukung jenis pesan publikasi berikut:

Fitur MQTT 5 lainnya

Memutuskan sambungan server

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

Request/Response

Penerbit 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 muatan dan jenis konten

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

Properti MQTT 5

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

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

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 yang 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 fitur API dan konsol untuk membantu Anda mengelola koneksi MQTT, termasuk kemampuan untuk memutuskan koneksi 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 koneksi klien MQTT

Gunakan DeleteConnection API untuk memutuskan sambungan perangkat MQTT AWS IoT Core dengan menentukan ID klien mereka. Saat Anda memutuskan koneksi klien, put AWS IoT Core uskan koneksi klien dari broker AWS IoT Core pesan dan dapat secara opsional membersihkan status sesi dan menekan pesan Last Will and Testament (LWT).

Saat Anda memanggil DeleteConnection API, AWS IoT Core lakukan beberapa tindakan untuk memastikan pemutusan yang bersih. AWS IoT Core pertama mengirim pesan pemutusan MQTT ke klien untuk menghentikan 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 hubunganAPI_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 menyet cleanSession el 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 disetel 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 hubungan, 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. Ketika Anda perlu mengarahkan klien ke titik akhir yang berbeda atau Wilayah AWS, Anda dapat memutuskan sambungannya secara terprogram dan menyimpannya kembali ke AWS IoT Core titik akhir yang berbeda dengan mengubah pengaturan DNS. API ini dapat membantu menyelesaikan koneksi 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

Contoh permintaan:

// 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 memasukkan 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 koneksi ulang. Operasi pemutusan hanya mengakhiri koneksi saat ini dan tidak mencegah koneksi menyambung 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 AWS IoT Core tarif 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 mengembalikan metadata koneksi komprehensif yang membantu memecahkan 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 terputus lebih dari 30 menit, gunakan GetThingConnectivityData API 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 alamat IP sumber dan target dan port, yang membantu mengidentifikasi masalah routing jaringan atau masalah titik akhir koneksi. Informasi ini sangat 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

Contoh permintaan:

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 memasukkan 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 mengembalikan 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 Terlarang 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 langganan.

Kasus penggunaan

ListSubscriptionsAPI membantu Anda memecahkan masalah pengiriman pesan dan mengaudit perilaku langganan klien. Gunakan API ini untuk memverifikasi topik mana yang berlangganan klien, 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 tak 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

Contoh permintaan:

// 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 memasukkan 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 perangkat MQTT dan mengelola koneksi mereka. Konsol menyediakan antarmuka intuitif untuk melihat perangkat yang terhubung dan melakukan operasi pemutusan hubungan.

Lihat klien MQTT yang terhubung

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

Lihat langganan klien MQTT

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

Putuskan sambungan perangkat MQTT

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

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

Pi AWS IoT alang pesan menghasilkan entri log dengan eventType waktu Connect klien MQTT terhubung.

Hubungkan 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 Log umum CloudWatch , entri log Connect berisi atribut berikut: