MQTT Nedir? Pratik Bir Giriş

MQTT (orijinal adıyla MQ Telemetry Transport), publish/subscribe (yayınla/abone ol) modeli üzerine kurulu hafif bir mesajlaşma protokolüdür. Client’lar birbirleriyle hiçbir zaman doğrudan konuşmaz — mesajlarını bir topic ile etiketleyerek merkezi bir broker’a gönderirler ve broker her mesajı, eşleşen bir topic’e abone olmuş tüm client’lara iletir. MQTT’nin sensör ağlarından akıllı evlere, araç telemetrisinden canlı dashboard’lara kadar her yerde çalışmasının nedeni bu basit modeldir.

Bu giriş yazısı MQTT’nin nasıl çalıştığını, önemli özelliklerinin neler olduğunu ve ne zaman doğru araç olduğunu (ve ne zaman olmadığını) açıklıyor. Adım adım takip etmek isterseniz online MQTT client’ı başka bir sekmede açın.

Kısa bir tarihçe

MQTT, 1999’da Andy Stanford-Clark (IBM) ve Arlen Nipper tarafından petrol boru hatlarını pahalı ve güvenilmez uydu bağlantıları üzerinden izlemek için tasarlandı. Tasarım hedefleri — küçücük paketler, minimum client kodu, kararsız ağlara tolerans — Nesnelerin İnterneti’ne (IoT) mükemmel şekilde uydu. MQTT 3.1.1 2014’te bir OASIS standardı oldu (daha sonra ISO/IEC 20922), ardından 2019’da reason code’lar, user property’ler, mesaj süresinin dolması (message expiry) ve daha fazlasıyla MQTT 5.0 geldi. Her iki sürüm de bugün yaygın olarak kullanılıyor; farklar için MQTT 5 ile 3.1.1 karşılaştırması yazısına bakın.

MQTT nasıl çalışır: publish/subscribe

MQTT’de yalnızca iki rol vardır:

• Client’lar — broker’a bağlanan her program veya cihaz. Bir client yayın yapabilir, abone olabilir ya da her ikisini birden yapabilir. Bir sıcaklık sensörü, bir mobil uygulama ve bir backend servisi birer client’tan ibarettir.
• Broker — bağlantıları kabul eden, client’ların kimliğini doğrulayan, topic’leri eşleştiren ve mesajları teslim eden sunucu. Popüler broker’lar arasında Mosquitto, EMQX ve HiveMQ bulunur.

Publisher’lar ve subscriber’lar birbirinden bağımsızdır (decoupled): bir publisher mesajını kimin aldığını (alan biri varsa) bilmez, subscriber’lar da mesajı kimin gönderdiğini bilmez. Ortak paylaştıkları tek şey bir topic adıdır. Bu sayede veriyi üreten cihazlara dokunmadan yeni bir tüketici — bir dashboard, bir veritabanı yazıcısı, bir uyarı servisi — eklemek çok kolaydır.

sensor-17  --PUBLISH home/kitchen/temperature "21.5"-->  broker
broker     --PUBLISH home/kitchen/temperature "21.5"-->  dashboard   (subscribed to home/+/temperature)
broker     --PUBLISH home/kitchen/temperature "21.5"-->  logger      (subscribed to home/#)

Topic’ler: bir mesajın adresi

Topic, factory/line-2/press-4/pressure gibi seviyeleri eğik çizgiyle ayrılmış bir UTF-8 string’idir. Topic’ler önceden oluşturulmaz — biri onlara yayın yaptığı anda var olurlar. Subscriber’lar iki wildcard (joker karakter) kullanabilir: + tam olarak bir seviyeyle, # ise sondaki herhangi sayıda seviyeyle eşleşir. İyi bir topic tasarımı yetkilendirme ve ölçeklenme açısından çok önemlidir; MQTT topic’leri ve wildcard’lar rehberimiz bu konuyu derinlemesine ele alıyor.

Bağlantı ve paketleri

MQTT uzun ömürlü bir bağlantı üzerinden çalışır — genellikle TCP, isteğe bağlı olarak TLS ile sarmalanmış, ya da tarayıcılar için WebSocket. Oturum bir CONNECT paketiyle başlar (client ID, isteğe bağlı kullanıcı adı ve parola, keep-alive, Last Will) ve broker CONNACK ile yanıt verir. Bundan sonra en sık kullanılan paketler şunlardır:

Bir MQTT paketinin sabit başlığı (fixed header) yalnızca iki bayttır ve payload opak bir ikili veridir — JSON, düz metin, Protobuf ya da ham baytların hepsi kullanılabilir. MQTT’yi kısıtlı kaynaklara sahip cihazlarda ve kotalı ağlarda cazip kılan da bu düşük ek yüktür.

MQTT’nin temel özellikleri

Quality of Service (QoS)

Her yayının ve aboneliğin bir QoS seviyesi vardır: 0 (en fazla bir kez), 1 (en az bir kez) veya 2 (tam olarak bir kez). Daha yüksek seviyeler, daha güçlü teslim garantileri karşılığında ek onay paketleri getirir. Ayrıntılar ve paket akışları MQTT QoS seviyeleri yazısında.

Retained mesajlar

Retain bayrağıyla yayınlanan bir mesaj, broker tarafından o topic’in bilinen son değeri olarak saklanır ve her yeni subscriber’a anında teslim edilir. online/offline veya güncel ayar değeri gibi durum bilgileri için idealdir. Retained mesajlar yazısına bakın.

Last Will and Testament

Bir client, temiz bir disconnect yapmadan ortadan kaybolursa broker’ın kendi adına yayınlayacağı bir mesaj kaydedebilir — çevrimdışı cihazları tespit etmenin standart yolu budur. Last Will and Testament yazısına bakın.

Kalıcı oturumlar (persistent session)

Kalıcı bir oturumda (3.1.1’de cleanSession=false, MQTT 5’te cleanStart=false artı bir session expiry interval), broker client’ın aboneliklerini hatırlar ve client çevrimdışıyken QoS 1 ve 2 mesajlarını kuyruğa alır; client yeniden bağlandığında bunları teslim eder.

MQTT’yi iki dakikada deneyin

MQTT’yi anlamanın en hızlı yolu bir mesajın gidiş-dönüşünü izlemektir. Public bir broker’a bağlanın, benzersiz bir topic’e abone olun ve aynı topic’e yayın yapın:

1. Online client’ı açın ve public broker listesinden bir broker’a bağlanın.
2. testmqtt/your-name/# topic’ine abone olun.
3. hello mesajını testmqtt/your-name/greeting topic’ine yayınlayın ve gelişini izleyin.

Online MQTT istemcisinde deneyin

Ya da Mosquitto client’ları kurulu bir terminalden:

# terminal 1
mosquitto_sub -h test.mosquitto.org -t 'testmqtt/intro/#' -v

# terminal 2
mosquitto_pub -h test.mosquitto.org -t 'testmqtt/intro/greeting' -m 'hello'

MQTT ne zaman kullanılmalı (ve ne zaman kullanılmamalı)

MQTT şu durumlarda çok uygundur:

• Çok sayıda cihaz küçük ve sık mesajlar gönderiyorsa (telemetri, sensör okumaları, durum bilgisi).
• Ağlar güvenilmez ya da bant genişliği sınırlıysa ve otomatik yeniden bağlanma ile çevrimdışı kuyruğa almaya ihtiyacınız varsa.
• Verinin sorgulanarak (polling) çekilmek yerine client’lara gerçek zamanlı olarak itilmesi gerekiyorsa.
• Üreticileri tüketicilere tek tek bağlamadan bire-çok (fan-out) dağıtım istiyorsanız.

Şu durumlarda daha az uygundur:

• Zengin semantiğe sahip istek/yanıt (request/response) gerekiyorsa — düz HTTP API’leri daha basittir (MQTT 5 response topic’leri ekler, ancak yine de bir mesajlaşma protokolüdür).
• Tüm olay geçmişinin uzun süreli saklanması veya yeniden oynatılması gerekiyorsa — bu, Kafka gibi bir log’un ya da MQTT ile beslenen bir veritabanının işidir.
• Büyük dosyalar aktarıyorsanız; MQTT bunları taşıyabilir ama bunun için tasarlanmamıştır.

Yan yana bir karşılaştırma için MQTT ile HTTP karşılaştırması yazısını okuyun.

Sonraki adımlar

Artık MQTT’nin ne olduğunu bildiğinize göre, QoS seviyelerini nasıl seçeceğinizi, bir topic hiyerarşisini nasıl tasarlayacağınızı ve bir MQTT broker’ını uçtan uca nasıl test edeceğinizi öğrenin. Tüm rehberler MQTT öğrenme merkezinde bulunuyor.

Sıkça sorulan sorular