Dalam internet of things diperlukan protokol yang mengatur komunikasi agar perangkat sensor, gateway dan server dapat saling bertukar data. Berikut ini akan dibahas enam protokol komunikasi yang sering digunakan sperti MQTT, CoAP, HTTP atau HTTPS, DDS, XMPP, dan AMQP.
1. MQTT (Message Queuing Telemetry Transport)
MQTT awalnya dikembangkan pada tahun 1999 oleh Andy Standford-Clark (IBM) dan Arlen Nipper dari Arcom (sekarang Eurotech/Cirrus Link) untuk industri minyak dan gas guna mengontrol jaringan pipa minyak melalui satelit dengan meminimalkan penggunaan bandwidth dan baterai. Oleh IBM, MQTT kemudian berkembang menjadi protokol open-source pada tahun 2010 dengan merilis MQTT versi 3.1. Berikutnya proses pengajuan standarisasi ke badan standar OASIS (Organization for the Advancement of Structured Information Standards) pada 2013, dimana proses standarisasi memakan
waktu sekitar satu tahun, dan pada 29 Oktober 2014, MQTT secara resmi disetujui sebagai Standar OASIS. Pada tahun 2016, MQTT 3.1.1 juga menjadi standar ISO (ISO/IEC 20922). Versi terbaru, MQTT 5.0 dirilis pada Maret 2019 menandai evolusi protokol untuk mendukung aplikasi IoT berskala besar.
Arsitektur dan Model Komunikasi MQTT didasarkan pada model komunikasi publish/subscribe (pub/sub). Model ini melibatkan tiga komponen utama seperti Client yang bertindak sebagai publisher (mengirim) atau subscriber (menerima), Broker sebagai Server perantara yang menerima pesan dan mendistribusikan ke subscriber, dan Topic sebagai kategori pesan. Dalam proses kontrol, protokol ini memilik 14 tipe paket kontrol yang dapat membantu mekanisme kerja publish/subscribe. Adapun paket tersebut sebagai berikut ini:
- CONNECT: Permintaan koneksi dari klien ke server (client to server).
- CONNACK: Konfirmasi penerimaan koneksi dari server ke klien (server to client).
- PUBLISH: Pesan yang mewakili publikasi baru atau terpisah (client to server atau
- server to client).
- PUBACK: Respons QoS 1 terhadap pesan PUBLISH (client to server atau server to client).
- PUBREC: Bagian pertama alur pesan QoS 2 (client to server atau server to client).
- PUBREL: Bagian kedua alur pesan QoS 2 (client to server atau server to client).
- PUBCOMP: Bagian terakhir alur pesan QoS 2 (client to server atau server to client).
- SUBSCRIBE: Pesan yang digunakan klien untuk berlangganan topik tertentu (client to server).
- SUBACK: Konfirmasi penerimaan pesan SUBSCRIBE (server to client).
- UNSUBSCRIBE: Pesan yang digunakan klien untuk berhenti berlangganan topik tertentu (client to server).
- UNSUBACK: Konfirmasi penerimaan pesan UNSUBSCRIBE (server to client).
- PINGREQ: Pesan heartbeat (sinyal jaga koneksi) yang dikirim klien (client to server).
- PINGRESP: Tanggapan heartbeat dari server (server to client).
- DISCONNECT: Pesan pemutusan koneksi yang dikirim klien secara teratur sebelum terputus (client to server).
MQTT juga menyediakan tiga tingkat layanan pengiriman pesan yaitu, QoS 0 artinya esan dikirim sekali tanpa konfirmasi dari broker (tanpa ACK), QoS 1 artinya Pesan dijamin terkirim minimal sekali, dan QoS 2 Pesan dijamin terkirim tepat satu kali, tanpa kehilangan dan tanpa duplikasi. Mengenai keamanan, MQTT tidak memiliki mekanisme keamanan yang terstandardisasi secara bawaan. Tapi MQTT merekomendasikan penggunaan Transport Layer Security (TLS) melalui TCP Port 8883 untuk mengenkripsi semua data yang dikirim antara klien dan broker. Untuk autentikasi, MQTT menggunakan username dan password. Klien juga dapat diminta untuk menggunakan sertifikat klien yang valid untuk autentikasi yang lebih kuat.
Protokol MQTT juga memilik varian MQTT-SN (MQTT for Sensor Networks) yang merupakan ekstensi dari MQTT yang dirancang khusus untuk Wireless Sensor Networks (WSN), terutama perangkat dengan sumber daya terbatas atau yang tidak selalu memakai TCP/IP, seperti Zigbee atau Bluetooth. Perbedaan utamanya adalah MQTT-SN menggunakan UDP sebagai transport, sedangkan MQTT standar menggunakan TCP.
2. Protokol HTTP/HTTPS
HTTP (Hypertext Transfer Protocol) adalah protokol aplikasi yang menjadi dasar komunikasi data untuk World Wide Web. HTTP kini juga digunakan secara luas dalam komunikasi machine-to-machine (M2M), otomasi, dan Internet of Things (IoT) karena mudah diakses. Protokol ini bekerja pada Application Layer dan menggunakan port 80 yang banyak digunakan sebagai jembatan komunikasi data, terutama pada sistem berbasis RESTful API atau web service. HTTP menyediakan mekanisme pertukaran data perangkat IoT melalui metode request–response seperti GET dan POST.
Dalam konteks keamanan HTTP tidak menyediakan enkripsi, sehingga data seperti kata sandi atau perintah kontrol yang dikirim dapat dimodifikasi oleh pihak yang tidak berwenang. Karena itu, perlu penambahan lapisan enkripsi SSL/TLS (HTTPS), dimana mekanisme keamanannya dengan menambahkan lapisan keamanan kriptografi SSL/TLS yang ditempatkan di bawah protokol HTTP namun di atas protokol TCP, sehingga seluruh pertukaran data terenkripsi dan terlindungi selama proses transmisi. SSL/TLS sendiri terdiri dari empat protokol, yaitu Handshake, Change-Cipher-Spec, Alert, dan Record. Keamanan ini didukung sertifikat digital X.509 yang dikeluarkan dalam kerangka Public Key Infrastructure (PKI) untuk memverifikasi identitas server atau klien. HTTPS menggunakan port 443, berbeda dari HTTP yang secara default menggunakan port 80 tanpa enkripsi.
HTTP juga terus berevolusi. Dimulai dari HTTP/0.9, 1.0, 1.1, melalui eksperimen SPDY, hingga lahir HTTP/2 yang distandarisasi melalui RFC 7540 pada Mei 2015. HTTP/2 tetap mempertahankan semantik HTTP/1.1 seperti metode, kode status, URI, dan header, tetapi menghadirkan peningkatan kinerja besar. Salah satu fitur utamanya adalah connection coalescence, yang memungkinkan pengiriman banyak objek melalui satu koneksi tunggal, mengurangi waktu yang dihabiskan untuk pembentukan koneksi dan proses TLS, serta menghilangkan kebutuhan banyak koneksi paralel seperti pada HTTP/1.1.
3. Constrained Application Protocol (CoAP)
Protokol komunikasi yang dirancang khusus untuk lingkungan dengan keterbatasan komputasi, daya, dan komunikasi, seperti perangkat Internet of Things (IoT) dan aplikasi machine-to-machine (M2M). Tujuannya adalah untuk perangkat kecil berdaya rendah dapat berinteraksi RESTful layaknya HTTP, tetapi dengan overhead jauh lebih ringan karena menggunakan format pesan biner. CoAP distandarisasi oleh IETF Constrained RESTful Environments (CoRE) Working Group dan diterbitkan sebagai RFC 7252, sementara metode resource discovery dijelaskan dalam RFC 6690 (CoRE Link Format).
Secara konsep, CoAP sangat mirip dengan HTTP. Protokol ini mendukung model request/response dan metode CRUD (Create, Read, Update, Delete) melalui GET, POST, PUT, dan DELETE. Namun, ada perbedaan mendasar pada CoAP yang menggunakan header biner ringkas, sehingga pesan lebih kecil dan lebih efisien untuk perangkat dengan memori dan bandwidth terbatas. Dari sisi arsitektur, CoAP berjalan di atas UDP (User Datagram Protocol), bukan TCP seperti HTTP. CoAP mendefinisikan empat jenis pesan yaitu CON (Confirmable) yang memerlukan konfirmasi ACK dan akan dikirim ulang bila gagal, NON (Non-confirmable) yang tidak membutuhkan konfirmasi tetapi tetap memakai message ID untuk mencegah duplikasi, ACK (Acknowledgement) sebagai jawaban terhadap CON, baik secara piggy-backed (digabung) maupun separate (terpisah), dan RST (Reset) yang digunakan penerima bila tidak dapat memproses pesan CON. Format pesan CoAP sangat ringkas, terdiri dari header empat byte, token opsional (0–8 byte), opsi, dan payload.
Kemudian, keamanan menjadi aspek penting yang dibangun langsung ke dalam CoAP melalui DTLS (Datagram Transport Layer Security), yang menjamin integritas, kerahasiaan, dan autentikasi pesan. Tiga mode keamanan dapat digunakan sesuai kebutuhan yaitu PreSharedKey, yang menggunakan kunci pra-bagi dan cipher suite TLS PSK WITH AES 128 CCM 8 untuk komunikasi grup, RawPublicKey yang mengandalkan pasangan kunci publik-asimetris tanpa sertifikat (TLS ECDHE ECDSA WITH AES 128 CCM 8), dan Certificates yang memakai sertifikat digital untuk autentikasi penuh. Kerangka tambahan seperti DCAF (Delegated CoAP Authentication and Authorization Framework) sedang dikembangkan untuk mendukung autentikasi dan otorisasi yang lebih modern.
4. Data Distribution Service (DDS)
Protokol ini merupakan standar middleware berpusat pada data yang dirancang untuk memfasilitasi komunikasi cepat, andal, dan real-time di antara perangkat yang saling terhubung. Berbeda dengan protokol pesan lainnya yang menitikberatkan pada
pertukaran pesan individual, DDS lebih pada data yang dibagikan. DDS mendukung pola komunikasi device-to-device maupun device-to-server, menjadikannya fondasi penting bagi sistem Internet of Things (IoT) dan aplikasi industri yang menuntut kinerja sangat tinggi.
DDS bekerja dengan model publish/subscribe, sehingga publisher dapat mengirimkan data ke banyak subscriber tanpa harus tahu siapa penerimanya. Kemudian, DDS memiliki fitur penting yaitu,
- Data-centric: Mendeskripsikan, menyimpan, dan menyebarkan data sebagai entitas yang dapat diakses kapan saja, bukan hanya mengirim pesan.
- Kinerja tinggi: Protokol ini dapat mempublikasikan jutaan pesan per detik ke banyak subscriber secara bersamaan, sebuah kebutuhan utama untuk sistem real- time berskala besar.
- Remotely accessible: data yang dipublikasikan dapat diakses dari jarak jauh, sehingga cocok untuk sistem terdistribusi lintas lokasi.
- Store and forward: DDS mampu menyimpan data sementara dan meneruskannya ketika subscriber kembali online, memastikan tidak ada data hilang saat koneksi terputus.
- DDS memiliki Interoperability Wire Protocol versi 2.2, yang menjamin interoperabilitas antarimplementasi DDS dari berbagai vendor.
Dari sisi standarisasi, DDS dikelola oleh Object Management Group (OMG). Standar utamanya, Data Distribution Service for Real-Time Systems, telah melalui beberapa versi, seperti versi 1.2 (2007) dan versi 1.4 (2015), termasuk DDS + DLRL 1.4 (2015) untuk mendukung pemetaan objek. Keamanan diatur dalam DDS Security 1.0 (2014), yang mendefinisikan mekanisme enkripsi, autentikasi, dan otorisasi komunikasi data. OMG juga menyediakan DDS UML Profile, sebuah metamodel yang memformalkan arsitektur DDS, meliputi paket DCPS/domain, common/topic, dan common/types, serta mendefinisikan komponen penting seperti Data Writer dan Domain Participant.
5. Extensible Messaging and Presence Protocol (XMPP)
XMPP berawal dari proyek open source bernama Jabber. Protokol ini kemudian distandarisasi oleh Internet Engineering Task Force (IETF) melalui RFC 6120 dan RFC 6121 pada tahun 2011. Setelah standarisasi, pengembangan ekstensinya dikelola oleh XMPP Standards Foundation (XSF), peran XSF di sini meliputi: Menerbitkan spesifikasi tambahan yang disebut XEP (XMPP Extension Protocols), Mendokumentasikan perangkat lunak server dan klien XMPP, serta menyediakan pustaka (library). XMPP adalah protokol komunikasi real-time yang open-source, aman, dan dapat diperluas. Pertama dikembangkan untuk layanan pesan instan, manajemen daftar kontak (roster), dan informasi kehadiran (presence), XMPP kini digunakan jauh lebih luas. Berbagai penerapan modernnya meliputi komunikasi machine-to-machine (M2M), Internet of Things (IoT), manajemen jaringan, video dan Voice over IP (VoIP), berbagi file, jejaring sosial, permainan daring (online gaming), hingga solusi Smart Grid.
XMPP berbasis XML, sehingga pesan yang dipertukarkan berupa aliran fragmen XML dua arah. Arsitektur XMPP memakai model jaringan yang mirip dengan email (SMTP) yang artinya, banyak server XMPP dapat saling terhubung dan menjadi jembatan komunikasi bagi klien yang berada di domain berbeda. XMPP mendukung pola komunikasi. Tiga stanza utama menjadi dasar pertukaran pesan yaitu: Presence stanza untuk menyiarkan status kehadiran, Message stanza untuk mengirim pesan asinkron, dan IQ (Information/Query) stanza untuk permintaan/respons mirip metode HTTP GET/POST. Selain itu, server dapat menyediakan publish/subscribe untuk distribusi data ke banyak subscriber dan multi-user chat (multicast) untuk percakapan real-time dalam suatu room.
- Dalam hal transport, XMPP berjalan di atas TCP dan umumnya menggunakan port 5222. Kemudian pada aspek keamanan, XMPP merupakan salah satu protokol komunikasi paling aman untuk IoT.
- Enkripsi: Seluruh komunikasi dapat dienkripsi menggunakan TLS (Transport Layer Security).
- Autentikasi: Dilakukan melalui SASL (Simple Authentication and Security Layer), yang mendukung berbagai metode seperti username/password, OAuth2, Kerberos, hingga sertifikat X.509. Metode yang direkomendasikan adalah SCRAM-SHA- 1/PLUS atau EXTERNAL bila menggunakan sertifikat.
- Otorisasi dan Provisioning: XMPP mengizinkan komunikasi hanya dengan kontak yang disetujui. Dalam IoT, perangkat dapat membuat identitasnya sendiri dan mendaftarkan ke Thing Registry atau provisioning server. Melalui Delegated Trust, pemilik atau penyedia dapat mengontrol siapa yang boleh terhubung dan bagaimana perangkat dioperasikan. Ekstensi seperti XEP-0324 (IoT Provisioning) dan XEP-0347 (IoT Discovery) mempermudah pendaftaran dan penemuan perangkat.
XMPP dirancang agar mudah diperluas melalui XMPP Extension Protocols (XEPs). Beberapa XEP penting untuk IoT antara lain.
- XEP-0325 (IoT Control) – untuk kontrol perangkat dan parameter.
- ProtoXEP: IoT Events – untuk langganan peristiwa sensor.
- XEP-0332 (HTTP over XMPP) – memungkinkan pengambilan data seperti gambar kamera melalui jalur XMPP.
- XEP-0045 (Multi-user Chat) – untuk obrolan grup real-time.
6. Advanced Message Queuing Protocol (AMQP)
AMQP adalah protokol middleware berorientasi pesan yang dirancang untuk pertukaran data yang aman, andal, dan lintas platform. Sejak awal dikembangkan digunakan pada industri keuangan dan perbankan. Sebagai protokol wire-level, AMQP menetapkan format data dalam bentuk byte stream bukan sekadar antarmuka API sehingga aplikasi dan sistem dengan bahasa pemrograman atau platform yang berbeda tetap dapat bertukar data.
AMQP distandarisasi oleh OASIS (Organization for the Advancement of Structured Information Standards) pada 2012, dan kemudian menjadi standar ISO/IEC pada 2014. Versi yang digunakan luas saat ini adalah AMQP 1.0. Perlu dicatat, AMQP 0.9.1 dan AMQP 1.0 memiliki paradigma komunikasi yang berbeda.
- MQP 0.9.1 berorientasi pada model publish/subscribe dengan broker sebagai pusat distribusi pesan.
- AMQP 1.0 lebih fleksibel, tidak terikat pada satu pola tertentu, dan dapat digunakan untuk peer-to-peer messaging tanpa broker.
Model komunikasi AMQP mendukung queue-based dan publish/subscribe di atas TCP, yang menjamin pengiriman pesan secara akurat. Beberapa fitur penting meliputi:
- Jaminan Pengiriman Pesan: mendukung tiga tingkat keandalan (at most once, at least once, dan exactly once)
- Flow Control: mekanisme berbasis token mencegah penerima dibanjiri pesan melebihi kapasitasnya.
- Interoperabilitas Tinggi: karena bersifat wire-level, AMQP memungkinkan klien dan server dari berbagai bahasa dan platform untuk bekerja sama.
- Format Biner Efisien: setiap pesan terdiri dari header yang memuat informasi pengiriman (seperti time-to-live, prioritas) dan frame sebagai unit data untuk inisiasi, terminasi, dan pengendalian pesan.
Sebagian besar implementasi AMQP menggunakan broker yang mengelola penyimpanan dan distribusi pesan. Broker ini memiliki beberapa komponen inti:
- Exchange – menerima pesan dari publisher dan mendistribusikannya ke antrian sesuai aturan yang ditetapkan.
- Queue – menampung pesan sampai consumer mengambilnya; antrian bisa persisten, sehingga pesan tetap tersimpan walaupun consumer sedang offline.
- Binding – menghubungkan exchange dan queue, menentukan bagaimana pesan dirutekan menggunakan routing key yang dapat memanfaatkan wildcard untuk pola distribusi yang fleksibel dan mendetail.
Dalam sisi keamanan, AMQP mengutamakan keamanan melalui TLS (Transport Layer Security)
- Autentikasi dilakukan menggunakan SASL (Simple Authentication and Security Layer) atau SSL, mendukung metode berbasis username/password maupun sertifikat digital.
- Enkripsi Payload memastikan isi pesan terlindungi dari penyadapan.
Pendekatan ini menjadikan AMQP aman digunakan di jaringan publik maupun infrastruktur cloud yang kompleks.
Tabel 1. Ringkasan Perbandingan Protokol IoT

6. Installasi Protokol MQTT
Pada bagian ini akan ditunjukkan salah satu contoh implementasi protokol MQTT pada perangkat IoT. Untuk dapat menggunakannya, terlebih dahulu diperlukan sebuah broker MQTT sebagai pusat komunikasi antara publisher dan subscriber. Berikut langkah- langkah proses instalasi broker MQTT (Mosquitto) pada sistem operasi Linux. Mosquitto dipilih karena ringan, stabil, dan paling populer untuk implementasi MQTT.
a. Persiapan awal
Sebelum memulai pastikan:
- Perangkat memiliki akses internet.
- Memiliki hak akses root atau dapat menggunakan sudi
- Sistem sudah diperbarui agar tidak ada paket yang konflik
![]()
b. Instalasi Mosquitto Broker
Mosquitto biasanya tersedia di repository resmi Linux. Jalankan perintah berikut:
![]()
Keterangan:
- mosquitto : paket utama broker MQTT
- mosquitto-clients : alat tambahan untuk pengujian, seperti mosquitto_pub (publisher) dan mosquitto_sub (subscriber).
c. Mengaktifkan dan Menjalankan Layanan
Setelah instalasi selesai, aktifkan layanan Mosquitto agar otomatis berjalan saat booting:

Cek status layanan:
![]()
Jika berhasil, akan muncul status active (running).
d. Pengujian Dasar (Tanpa Autentikasi & Enkripsi) Untuk memastikan broker bekerja:
Terminal 1 (subscriber):
![]()
Terminal 2 (publisher):
![]()
Jika pesan "Hello MQTT" muncul di Terminal 1, broker telah berjalan dengan baik
e. Konfigurasi Broker (Opsional tapi Disarankan)
Konfigurasi default biasanya tanpa keamanan. Untuk produksi atau IoT yang terhubung ke internet, disarankan menambahkan:
1. Username dan Password
- Buat file password:

Masukkan password saat diminta.
- Edit file konfigurasi:

Isi:

- Simpan dan restart broker:

- Uji koneksi:

2. Enkripsi TLS/SSL
Untuk komunikasi terenkripsi (port default 8883):
- Buat atau dapatkan sertifikat SSL/TLS.
- Tambahkan ke konfigurasi, misalnya:

- Restart broker:
![]()
f. Pengaturan Jaringan dan Firewall
Pastikan port 1883 (non-TLS) dan/atau 8883 (TLS) terbuka di firewall:

Jika broker akan diakses dari luar jaringan lokal, pastikan IP server dapat dijangkau (public IP atau DNS).
g. Periksa Log bila ada masalah
![]()