Beranda iot mqtt real-time websocket

Mengenal Perbedaan MQTT vs WebSocket: Mana Lebih Cocok untuk IoT & Real-time?

Updated: • 0 • min read
Table of Contents

Dunia teknologi komunikasi itu dinamis banget, apalagi buat aplikasi yang butuh real-time atau komunikasi efisien. Nah, dua nama yang sering muncul ketika ngomongin komunikasi data, terutama di dunia Internet of Things (IoT) dan aplikasi web modern, adalah MQTT dan WebSocket. Meski sama-sama buat kirim-kirim data, cara kerja dan peruntukannya beda loh. Yuk, kita bedah satu per satu!

Apa Itu MQTT?

MQTT, singkatan dari Message Queuing Telemetry Transport, adalah protokol messaging ringan yang dirancang khusus untuk perangkat dengan sumber daya terbatas dan jaringan yang kurang stabil. Protokol ini beroperasi di atas protokol transportasi TCP/IP. Awalnya dikembangkan di IBM pada tahun 1999, MQTT kini jadi standar de facto di dunia IoT karena efisiensinya.

Cara Kerja MQTT: Model Publish/Subscribe

Beda sama model tradisional client-server yang mana client selalu request data ke server, MQTT pake model Publish/Subscribe. Di model ini, ada tiga komponen utama: Publisher, Subscriber, dan Broker.

  • Publisher: Adalah perangkat atau aplikasi yang mengirim data atau pesan. Mereka tidak mengirim pesan langsung ke penerima, melainkan ke Broker.
  • Subscriber: Adalah perangkat atau aplikasi yang tertarik menerima pesan tentang topik tertentu. Mereka juga tidak menerima pesan langsung dari Publisher, melainkan mendaftar (subscribe) ke Broker untuk topik yang diminati.
  • Broker: Ini adalah jantung sistem MQTT. Broker bertugas menerima semua pesan dari Publisher, memfilter pesan berdasarkan topik, dan meneruskannya ke semua Subscriber yang telah mendaftar ke topik tersebut. Broker ini kayak kantor pos raksasa yang tahu siapa aja yang mau terima surat tentang “cuaca Jakarta” atau “kondisi suhu ruangan A”.

Setiap pesan di MQTT dikirimkan ke suatu Topik. Topik ini semacam alamat atau kategori pesan. Contoh topik bisa “home/livingroom/temperature” atau “plant/status/humidity”. Publisher mengirim pesan ke topik, dan Subscriber menerima pesan dari topik yang mereka subscribe. Ini membuat komunikasi jadi sangat fleksibel dan terlepas antara pengirim dan penerima.

Kenapa MQTT Populer di IoT?

Ada beberapa alasan kenapa MQTT jadi pilihan utama buat aplikasi IoT:

  1. Ringan (Lightweight): Header pesan MQTT itu kecil banget, cuma 2 byte. Ini bikin konsumsi bandwidth dan daya jadi minim, cocok buat perangkat IoT yang biasanya pake baterai atau punya koneksi terbatas.
  2. Efisiensi Daya: Dengan model publish/subscribe, perangkat subscriber tidak perlu terus-menerus menanyakan (polling) server apakah ada data baru. Mereka cuma perlu menjaga koneksi ke broker dan akan diberi tahu broker saat ada pesan baru di topik yang mereka subscribe. Ini sangat menghemat daya.
  3. Reliabilitas: MQTT punya tiga level Quality of Service (QoS): QoS 0 (At most once), QoS 1 (At least once), dan QoS 2 (Exactly once). Level QoS ini menentukan seberapa yakin pesan akan terkirim, dari yang paling dasar sampai yang menjamin pesan sampai persis sekali tanpa duplikasi, meskipun harus mengorbankan sedikit overhead. Ini penting buat data krusial di IoT.
  4. Skalabilitas: Model broker memungkinkan ribuan bahkan jutaan perangkat terhubung secara bersamaan tanpa publisher atau subscriber perlu tahu keberadaan satu sama lain. Cukup terhubung ke broker yang powerful.
  5. Fitur Last Will and Testament (LWT): Ini fitur keren di MQTT. Saat sebuah perangkat connect ke broker, dia bisa ngasih tahu broker sebuah pesan yang akan dipublikasikan ke topik tertentu kalau-kalau koneksi perangkat itu terputus secara tidak wajar (mati mendadak). Ini berguna buat memberitahu sistem lain bahwa sebuah perangkat sedang offline.

MQTT sering digunakan dalam smart homes, industri manufaktur (IIoT), pertanian cerdas, pelacakan aset, dan banyak lagi aplikasi yang melibatkan sensor dan aktuator yang saling berkomunikasi.

MQTT Architecture
Image just for illustration

Apa Itu WebSocket?

WebSocket adalah protokol komunikasi yang menyediakan saluran komunikasi full-duplex melalui satu koneksi TCP tunggal. Artinya, setelah koneksi terjalin antara client (misalnya browser web) dan server, data bisa dikirimkan bolak-balik oleh client maupun server kapan saja tanpa perlu membangun koneksi baru untuk setiap pertukaran data.

Sebelum ada WebSocket, aplikasi web yang butuh komunikasi real-time biasanya pake teknik polling (client berulang kali nanya ke server) atau long-polling (client nanya ke server, server nahan request sampai ada data baru atau timeout, baru bales). Teknik ini boros resource dan latency-nya lumayan. WebSocket hadir sebagai solusi yang lebih elegan dan efisien.

Cara Kerja WebSocket: Koneksi Full-Duplex

WebSocket dimulai dengan jabat tangan (handshake) standar HTTP/1.1. Client mengirim request upgrade ke server untuk beralih dari protokol HTTP ke protokol WebSocket. Kalau server mendukung dan setuju, koneksi akan di-upgrade menjadi koneksi WebSocket yang persisten dan full-duplex.

Setelah koneksi terjalin, client dan server bisa saling mengirim data dalam bentuk “frame” kecil. Koneksi ini akan terus terbuka sampai salah satu pihak menutupnya. Ini memungkinkan komunikasi real-time yang sesungguhnya, di mana server bisa “mendorong” (push) data ke client kapan saja tanpa harus menunggu client meminta.

Kenapa WebSocket Populer di Aplikasi Web?

WebSocket punya keunggulan yang bikin dia cocok buat aplikasi web modern:

  1. Komunikasi Real-time: Ini keunggulan utamanya. WebSocket memungkinkan server mengirim data ke client secara instan saat data itu tersedia, menciptakan pengalaman pengguna yang sangat responsif, seperti di aplikasi chat, live trading, notifikasi, atau game online berbasis web.
  2. Overhead Rendah: Setelah koneksi awal (handshake HTTP) selesai, header frame data WebSocket itu jauh lebih kecil dibanding header request/response HTTP yang berulang-ulang. Ini menghemat bandwidth dan mengurangi latency.
  3. Kompatibilitas Browser: WebSocket adalah standar web (bagian dari HTML5) dan didukung secara luas oleh semua browser modern. Ini membuatnya jadi pilihan alami untuk komunikasi real-time di frontend web.
  4. Full-Duplex: Kemampuan kirim dan terima data secara simultan di satu koneksi sangat efisien.

WebSocket sering digunakan dalam aplikasi chat berbasis web, live dashboards, aplikasi kolaborasi real-time (misalnya pengedit dokumen bersama), game browser multiplayer, dan aplikasi lain yang butuh server push data ke client web.

WebSocket Full Duplex
Image just for illustration

Perbedaan Kunci Antara MQTT dan WebSocket

Sekarang kita masuk ke inti perbandingannya. Meski sama-sama bisa dipake buat komunikasi asinkron dan real-time, perbedaan fundamental mereka ada di beberapa aspek:

Level Protokol

  • MQTT: Adalah protokol messaging lapisan aplikasi (Application Layer). Dia beroperasi di atas protokol transport (umumnya TCP). Fokusnya adalah pada pengiriman pesan yang efisien, terutama di lingkungan yang constrained.
  • WebSocket: Adalah protokol komunikasi lapisan transport (Transport Layer), meskipun dimulai dengan handshake HTTP (Application Layer). Dia menyediakan saluran komunikasi, bukan mekanisme messaging dengan topik dan broker.

Pola Komunikasi

  • MQTT: Menggunakan pola Publish/Subscribe. Komunikasi melibatkan Publisher, Subscriber, dan Broker sebagai perantara. Pengirim tidak perlu tahu siapa penerimanya, dan penerima tidak perlu tahu siapa pengirimnya. Komunikasi terpusat di Broker.
  • WebSocket: Menggunakan pola Client-Server dengan koneksi full-duplex. Client terhubung langsung ke Server. Komunikasi biasanya point-to-point antara client spesifik dan server (meskipun server bisa mengirim ke banyak client). Tidak ada konsep broker di level protokol WebSocket itu sendiri, meskipun bisa diimplementasikan di atasnya.

```mermaid
graph LR
subgraph MQTT
A[Publisher] →|Publish message to Topic X| B(Broker)
B →|Forward message to Subscriber| C[Subscriber 1]
B →|Forward message to Subscriber| D[Subscriber 2]
C →|Subscribe to Topic X| B
D →|Subscribe to Topic X| B
end

subgraph WebSocket
    E[Client 1] <-->|Full-duplex connection| F(Server)
    G[Client 2] <-->|Full-duplex connection| F
end

```
Image just for illustration (Mermaid Diagram showing communication patterns)

Overhead dan Performa

  • MQTT: Didesain agar sangat ringan dengan header pesan minimal (2 byte) dan payload biner yang fleksibel. Sangat efisien di bandwidth rendah. Latency bisa dipengaruhi oleh broker, tapi secara protokol sangat cepat untuk mengirim pesan kecil.
  • WebSocket: Setelah handshake, header frame data cukup kecil, jauh lebih kecil dari header HTTP penuh. Namun, header frame WebSocket (minimal 2 byte + masking key 4 byte jika dari client) bisa sedikit lebih besar dari header pesan MQTT murni. Tapi, keuntungan WebSocket ada di koneksi persisten yang mengurangi overhead pembuatan koneksi berulang.

Use Cases (Kasus Penggunaan)

  • MQTT: Sangat kuat di IoT, messaging antar server, dan aplikasi yang butuh komunikasi efisien antar perangkat dengan sumber daya terbatas atau di jaringan tidak stabil. Cocok untuk mengirim data sensor, perintah kontrol, atau notifikasi antar perangkat/aplikasi yang decoupled.
  • WebSocket: Sangat kuat di aplikasi web real-time (browser ke server), chat, live updates, online gaming via web, dan kasus lain di mana client (biasanya browser) dan server butuh saluran komunikasi dua arah yang cepat dan persisten.

Reliabilitas

  • MQTT: Memiliki mekanisme QoS (0, 1, 2) yang built-in di protokolnya untuk mengatur tingkat jaminan pengiriman pesan, dari “kirim aja, gak peduli sampe apa nggak” sampai “jamin sampe dan cuma sekali”.
  • WebSocket: Tidak punya mekanisme QoS built-in di level protokolnya. WebSocket hanya menjamin urutan pengiriman frame data dalam satu koneksi TCP. Jaminan pengiriman pesan atau penanganan pesan duplikat harus diimplementasikan di lapisan aplikasi di atas WebSocket.

Keamanan

  • MQTT: Bisa diamankan dengan TLS/SSL untuk enkripsi koneksi ke broker. Autentikasi bisa pake username/password, sertifikat klien, atau integrasi dengan sistem autentikasi lain. Otorisasi (siapa boleh publish atau subscribe ke topik mana) biasanya diatur di broker.
  • WebSocket: Karena dimulai dengan handshake HTTP, bisa diamankan dengan WSS (WebSocket Secure), yang merupakan WebSocket di atas TLS/SSL. Autentikasi dan otorisasi sama seperti aplikasi web umumnya, bisa pake session, token (JWT), atau mekanisme lain yang diimplementasikan di server aplikasi.

Peran Broker/Server

  • MQTT: Sangat bergantung pada Broker MQTT. Broker adalah komponen sentral yang mengelola koneksi, topik, dan pengiriman pesan. Tanpa broker, komunikasi publish/subscribe tidak bisa terjadi.
  • WebSocket: Bergantung pada Server WebSocket (biasanya terintegrasi dengan server aplikasi). Server ini mengelola koneksi client dan logika aplikasi untuk mengirim/menerima data. Tidak ada perantara sentral yang mengatur pesan berdasarkan topik secara native (kecuali diimplementasikan di server aplikasi itu sendiri).

Berikut tabel ringkasan perbedaannya:

Fitur MQTT WebSocket
Pola Komunikasi Publish/Subscribe Client-Server (Full-duplex)
Level Protokol Application Layer Transport Layer (melalui Handshake HTTP)
Komponen Sentral Broker Server Aplikasi
Overhead Sangat Rendah (Header 2 byte) Rendah (setelah Handshake)
Jaminan Pesan QoS (0, 1, 2) - Built-in Tidak ada (harus diimplementasi di atasnya)
Target Utama IoT, M2M (Machine-to-Machine), Jaringan Terbatas Aplikasi Web Real-time (Browser <-> Server)
Koneksi Persistent (Client ke Broker) Persistent (Client ke Server)
Dukungan Browser Tidak Native (perlu Library JS) Native & Didukung Luas
Data Format Binary Fleksibel Bisa Text (UTF-8) atau Binary

MQTT vs WebSocket Table Comparison
Image just for illustration

Kapan Sebaiknya Menggunakan MQTT?

Kamu harus mempertimbangkan MQTT jika aplikasimu punya karakteristik berikut:

  • Lingkungan IoT atau M2M: Perangkat punya sumber daya (CPU, memori, daya) dan bandwidth yang terbatas.
  • Jaringan Tidak Stabil: Koneksi sering terputus, dan kamu butuh protokol yang bisa menangani itu dengan baik (misalnya dengan persistent session dan QoS).
  • Komunikasi Antar Banyak Perangkat: Kamu butuh cara efisien untuk banyak perangkat saling bertukar informasi tanpa perlu tahu alamat IP masing-masing, atau banyak perangkat butuh menerima update dari satu sumber. Model publish/subscribe sangat ideal di sini.
  • Skalabilitas dengan Broker: Kamu memproyeksikan akan ada ribuan atau jutaan perangkat yang terhubung secara simultan. Broker MQTT yang skalabel bisa menangani beban ini.
  • Butuh Jaminan Pengiriman Pesan: Fitur QoS MQTT itu penting untuk data yang tidak boleh hilang atau duplikat.

Contoh: Sistem monitoring suhu di gudang besar dengan ratusan sensor, sistem pelacakan armada kendaraan, platform smart home yang menghubungkan berbagai merek perangkat.

Kapan Sebaiknya Menggunakan WebSocket?

Pilih WebSocket jika kasus penggunaanmu seperti ini:

  • Aplikasi Web Real-time: Kamu butuh komunikasi dua arah yang cepat antara browser client dan server aplikasi.
  • Integrasi dengan Infrastruktur Web Standar: Kamu memanfaatkan web server (Apache, Nginx, Node.js/Express, dll.) dan ekosistem web lainnya.
  • Dukungan Browser Native: Client-mu adalah browser web modern yang sudah mendukung WebSocket.
  • Komunikasi Point-to-Point atau Server Push ke Grup Client: Kamu butuh server untuk mengirim data secara proaktif ke client tertentu atau sekelompok client yang sedang terhubung.
  • Data yang Dikirim Berformat Teks (JSON, XML) atau Biner yang Dikelola Aplikasi: WebSocket menangani frame data biner atau teks, format pesannya dikelola oleh lapisan aplikasi.

Contoh: Aplikasi chat web, dashboard monitoring real-time di browser, notifikasi push ke pengguna web, aplikasi kolaborasi online, game online berbasis web.

Bisakah MQTT dan WebSocket Bekerja Sama?

Tentu saja bisa! Mereka punya kekuatan di area yang berbeda, jadi seringkali mereka saling melengkapi, bukan bersaing.

Salah satu arsitektur umum adalah menggabungkan keduanya:

  1. Perangkat IoT menggunakan MQTT untuk mengirim data ke Broker MQTT.
  2. Server Aplikasi berlangganan (subscribe) ke topik-topik yang relevan di Broker MQTT.
  3. Server Aplikasi memproses data yang diterima dari MQTT Broker.
  4. Server Aplikasi menggunakan WebSocket untuk mengirim data real-time yang sudah diproses tersebut ke Browser Web Client yang terhubung.

Atau, ada juga Broker MQTT yang mendukung WebSocket frontend. Ini memungkinkan client berbasis web (menggunakan library MQTT over WebSocket di JavaScript) untuk terhubung langsung ke Broker MQTT dan berpartisipasi dalam pola publish/subscribe, tanpa perlu server aplikasi perantara. Ini bagus untuk aplikasi web sederhana yang hanya butuh menampilkan data real-time langsung dari perangkat IoT.

```mermaid
graph LR
subgraph Sistem Gabungan
subgraph IoT Network
A[Sensor 1] – MQTT → B(MQTT Broker)
C[Sensor 2] – MQTT → B
end

    subgraph Web Application
        D(Server App) -- Subscribe MQTT --> B
        D -- WebSocket --> E[Browser Client 1]
        D -- WebSocket --> F[Browser Client 2]
    end
end

B -- Publish Message --> D
D -- Send via WebSocket --> E
D -- Send via WebSocket --> F

```
Image just for illustration (Mermaid Diagram showing combined architecture)

Mengerti perbedaan dan kelebihan masing-masing protokol ini sangat penting untuk memilih solusi komunikasi yang paling pas dan efisien untuk kebutuhan aplikasimu, entah itu untuk proyek IoT, aplikasi web, atau kombinasi keduanya.

Memilih protokol yang tepat bisa sangat mempengaruhi performa, skalabilitas, biaya, dan kemudahan pengembangan sistem kamu. Jadi, jangan sampai salah pilih ya!

Bagaimana pengalamanmu menggunakan MQTT atau WebSocket? Atau mungkin kamu punya pertanyaan lain seputar kedua protokol ini? Yuk, share pengalaman atau pertanyaanmu di kolom komentar di bawah!

Posting Komentar