MQTT görsel rehber
IoT iletişiminin ortak dili

MQTT nedir?

MQTT, cihazların ve yazılımların birbiriyle düşük bant genişliği kullanarak, hızlı ve esnek biçimde mesajlaşmasını sağlayan hafif bir yayınla–abone ol protokolüdür.

Pub/SubMesajlaşma modeli
1883 / 8883Yaygın TCP / TLS portları
QoS 0–2Üç teslimat seviyesi
fabrika/hat-1/canlı-veri TLS
Cihazlar, MQTT broker ve uygulamalar Sensör ve kontrolcü mesajları merkezi broker üzerinden panel, telefon ve bulut uygulamasına aktarılır. Sensör PLC / ESP32 Saha cihazı BROKER Panel Mobil Bulut
Yayıncılar veriyi topic’e gönderirAboneler yalnızca ilgilendiği veriyi alır
Temel tanım

Az veriyle çok cihazı konuşturur.

Açılımı tarihsel olarak “Message Queuing Telemetry Transport” şeklinde kullanılsa da bugün MQTT, OASIS standardı olan bağımsız bir protokol adıdır. Özellikle IoT, telemetri, bina otomasyonu ve uzaktan izleme sistemlerinde tercih edilir.

MQTT’nin özü

Bir cihazın, karşı taraftaki uygulamayı doğrudan tanımasına gerek kalmadan mesaj yayımlamasını; diğer istemcilerin ise ilgilendikleri mesajlara abone olmasını sağlar.

İletişimin merkezinde broker bulunur. Broker; bağlantıları kabul eder, topic aboneliklerini izler, gelen mesajları uygun alıcılara yönlendirir ve yapılandırmaya göre oturum, retained mesaj ve çevrimdışı kuyruk yönetimi yapar.

Bu ayrıştırılmış yapı sayesinde sensör, mobil uygulama, web paneli, PLC, veri tabanı ve bulut servisi birbirinden bağımsız geliştirilebilir.

Çalışma mantığı

Yayıncı → Broker → Abone

İstemciler birbirine doğrudan bağlanmaz. Her istemci broker’a bağlanır; mesajlar topic adı verilen mantıksal kanallar üzerinden yönlendirilir.

Örnek akış: sıcaklık sensörü fabrika/hat1/sicaklik topic’ine 23.7 yayımlar.

MQTT yayıncı, broker ve aboneler diyagramı Sensörden broker'a giden mesaj, broker tarafından kontrol paneli ve alarm servisine iletilir. Sıcaklık sensörü PUBLISH • 23.7 °C MQTT BROKER Topic yönlendirme Kontrol paneli SUBSCRIBE Veri kaydı SUBSCRIBE Alarm servisi SUBSCRIBE
01 • İSTEMCİ

Client

Broker’a bağlanan her yazılım veya cihazdır. Aynı istemci hem yayıncı hem abone olabilir.

02 • YAYINCI

Publisher

Bir topic’e mesaj gönderir. Mesajın kimin tarafından okunacağını bilmez.

03 • ARACI

Broker

Bağlantı, kimlik doğrulama, abonelik ve mesaj yönlendirme merkezidir.

04 • ABONE

Subscriber

Bir topic veya filtreye abone olur; eşleşen mesajları broker’dan alır.

Adresleme sistemi

Topic, verinin yol adresidir.

Topic’ler genellikle eğik çizgiyle ayrılan hiyerarşik seviyelerden oluşur. Broker, yayınlanan topic’i abonelik filtreleriyle karşılaştırır.

Örnek topic ağacı

Büyük/küçük harfe duyarlı
fabrika
hat1
sicaklik
nem
hat2
sicaklik
enerji
anlik-guc

Topic filtre deneme alanı

+ bir seviyeyi, # kalan tüm seviyeleri eşleştirir.

EşleşiyorMesaj bu aboneye iletilir.
fabrika/+/sicaklik → her hattın sıcaklığı  •  fabrika/# → fabrikanın tüm alt topic’leri
Teslimat güvencesi

QoS, hız ile güvenceyi dengeler.

Quality of Service seviyesi, mesajın yayıncıdan broker’a ve broker’dan aboneye aktarımındaki teslimat davranışını belirler. Her bağlantı ayağında farklı QoS sonucu oluşabilir.

QoS 0

En fazla bir kez

Mesaj gönderilir, onay beklenmez. En hızlı ve en düşük yükte seçenektir; kayıp ihtimali kabul edilir.

Gönderici
PUBLISH
Alıcı
En az trafikTelemetriOnay yok
QoS 1

En az bir kez

Alıcı PUBACK gönderir. Mesajın ulaşması hedeflenir; yeniden gönderim nedeniyle aynı mesaj birden fazla kez görülebilir.

Gönderici
PUBLISH
Alıcı
Gönderici
PUBACK
Alıcı
DengeliKomut / alarmTekrar olabilir
QoS 2

Tam bir kez

Dört adımlı el sıkışma ile protokol seviyesinde yinelenmeyen teslimat sağlar. En yüksek güvence, en fazla trafik ve gecikme.

Gönderici
PUBLISH
Alıcı
Gönderici
PUBREC
Alıcı
Gönderici
PUBREL
Alıcı
Gönderici
PUBCOMP
Alıcı
En yüksek güvenceKritik işlemDaha fazla yük
Önemli yetenekler

MQTT yalnızca veri göndermek değildir.

Bağlantı durumu, son değer, çevrimdışı mesajlar ve yaşam sinyali gibi mekanizmalar gerçek saha sistemlerinde dayanıklılığı artırır.

Retained Message

Broker, topic’in son retained mesajını saklar. Yeni abone bağlandığında güncel değeri bir sonraki yayını beklemeden alır. Durum bilgileri için çok kullanışlıdır.

Last Will & Testament

İstemci beklenmedik biçimde koparsa broker, önceden tanımlanan “çevrimdışı” mesajını yayımlar. Arıza ve bağlantı kaybı tespiti sağlar.

Kalıcı oturum

Abonelik ve uygun QoS mesajları bağlantı kesintileri boyunca korunabilir. MQTT 5.0’da bu süre Session Expiry ile ayrıntılı yönetilir.

Keep Alive

Veri akışı yokken PINGREQ / PINGRESP paketleriyle bağlantının canlılığı kontrol edilir. Broker, sessiz kalan istemciyi belirli sürede kopmuş kabul eder.

Shared Subscription

$share/grup/filtre yapısıyla aynı abonelik grubundaki tüketiciler arasında yük dağıtımı yapılabilir.

Payload bağımsızlığı

MQTT payload’ı metin, JSON, CBOR, protobuf veya ikili veri olabilir. Veri şemasını uygulama mimarisi belirler.

Modern sürüm

MQTT 5.0 ne kazandırır?

MQTT 5.0; büyük sistemlerin gözlemlenebilirliğini, hata yönetimini, akış kontrolünü ve istek–yanıt benzeri kalıpları geliştiren ek özellikler sunar.

5.0Daha açıklayıcı, yönetilebilir, ölçeklenebilir

Mesajlara ve bağlantılara daha fazla bağlam

Reason Code’lar başarısız işlemin nedenini açıklar; User Properties uygulamaya özel meta veri taşır; Topic Alias uzun topic adlarının tekrarını azaltır. Message Expiry, Receive Maximum ve Maximum Packet Size gibi alanlar kaynak yönetimini kolaylaştırır.

Reason CodesBağlantı ve işlem sonucunu ayrıntılı açıklar.
User PropertiesAnahtar–değer biçiminde ek meta veri.
Topic AliasUzun topic adlarının ağ yükünü azaltır.
Message ExpiryEskiyen mesajın teslim edilmesini engeller.
Response Topicİstek–yanıt kalıbını standartlaştırmaya yardımcı olur.
Flow Controlİstemci ve broker kapasitesini korur.
Güvenli kurulum

Protokol hafif; güvenlik hafife alınmamalı.

MQTT güvenliği yalnızca parola eklemek değildir. Taşıma şifreleme, istemci kimliği, topic yetkileri, sertifika yönetimi ve ağ segmentasyonu birlikte ele alınmalıdır.

Katmanlı güvenlik modeli

Her katman farklı bir riski azaltır.

1
TLSVeriyi aktarım sırasında şifreler ve broker kimliğini doğrular.
8883
2
Kimlik doğrulamaKullanıcı/parola, istemci sertifikası veya harici kimlik sistemi.
AUTH
3
ACL / YetkilendirmeHangi istemcinin hangi topic’e publish veya subscribe yapacağını sınırlar.
TOPIC
4
Ağ ve cihaz güvenliğiFirewall, VPN, güvenli anahtar saklama, güncelleme ve kayıt izleme.
OPS

Üretim ortamı kontrol listesi

  • Anonim erişimi kapatın. Her cihaz için benzersiz kimlik kullanın.
  • TLS doğrulamasını zorunlu tutun. Sertifika süresi ve saat doğruluğunu izleyin.
  • En az yetki ilkesini uygulayın. Cihazı yalnızca gerekli topic’lerle sınırlandırın.
  • Client ID çakışmalarını önleyin. Aynı kimliğe sahip istemciler birbirini düşürebilir.
  • Hız ve paket limitleri koyun. Yanlış çalışan cihazın broker’ı yormasını engelleyin.
  • Log ve metrikleri izleyin. Bağlantı sayısı, gecikme, kuyruk ve red nedenlerini takip edin.
Doğru araç seçimi

MQTT ve HTTP aynı işi farklı şekilde çözer.

MQTT, sürekli bağlantılı ve olay odaklı cihaz haberleşmesinde; HTTP ise kaynak isteme, web API ve klasik istemci–sunucu işlemlerinde öne çıkar. Bir sistem ikisini birlikte kullanabilir.

ÖlçütMQTTHTTP / REST
ModelPublish / SubscribeRequest / Response
BağlantıGenellikle uzun süre açıkİstek bazlı veya keep-alive
Sunucudan cihaza veriDoğal ve anlıkPolling, SSE veya WebSocket gerekebilir
Protokol yüküDüşükBaşlıklar nedeniyle genellikle daha yüksek
Birden çok tüketiciBroker abonelere dağıtırHer tüketici ayrı istek / entegrasyon kurar
Önbellek / web uyumuÖzel altyapı gerekirWeb ekosistemiyle doğal uyum
Tipik kullanımIoT, telemetri, otomasyon, alarmWeb API, dosya, form, CRUD işlemleri
Not: “MQTT her zaman HTTP’den hızlıdır” genellemesi doğru değildir. Sonuç; ağ, broker, QoS, payload, bağlantı yönetimi ve uygulama mimarisine bağlıdır.
Kullanım alanları

Fiziksel dünyadan buluta kadar.

MQTT, az veri üreten tek bir sensörden yüz binlerce bağlantının bulunduğu platformlara kadar ölçeklenebilir.

Bina otomasyonu

HVAC ve enerji izleme

Sıcaklık, CO₂, fan durumu, alarm ve set değeri iletişimi.

bina/kat2/ahu3/fan/durum
Endüstri

Makine ve hat telemetrisi

Çalışma saati, titreşim, üretim sayısı ve kestirimci bakım verileri.

fabrika/hat1/motor7/titresim
Tarım

Akıllı sera ve sulama

Toprak nemi, vana komutu, hava durumu ve gübreleme takibi.

sera/bolge4/toprak/nem
Mobilite

Filo ve araç takibi

Konum, hız, yakıt, sürüş olayı ve uzaktan teşhis verileri.

filo/arac42/telemetri
Akıllı ev

Sensör ve cihaz kontrolü

Aydınlatma, termostat, güvenlik sensörü ve enerji ölçümü.

ev/salon/termostat/set
Altyapı

Uzaktan sayaç okuma

Elektrik, su, gaz ve çevresel ölçümlerin merkezde toplanması.

sehir/sayac/10384/tuketim
Somut örnek

Bir sensör verisi nasıl taşınır?

Aşağıdaki yapı, ESP32 gibi bir cihazın JSON telemetri yayımlaması ve kontrol komutuna abone olması için sade bir örnektir.

Topic ve payload tasarımı
// Yayın topic'i
fabrika/hat1/motor7/telemetri

// JSON payload
{
  "sicaklik": 46.2,
  "akim": 3.84,
  "calisiyor": true,
  "zaman": "2026-07-30T06:20:00Z"
}

// Komut aboneliği
fabrika/hat1/motor7/komut/+
ESP32 / C++ kavramsal kullanım
// Broker'a bağlan
client.connect(
  "motor7",
  mqttUser,
  mqttPassword,
  "fabrika/hat1/motor7/durum",
  1,
  true,
  "offline"
);

// Komutlara abone ol
client.subscribe(
  "fabrika/hat1/motor7/komut/+", 1
);

// Son durumu retained olarak yayımla
client.publish(
  "fabrika/hat1/motor7/durum",
  "online",
  true
);
Tasarım sırası

Sağlam bir MQTT sistemi dört kararla başlar.

ADIM 1Topic ağacıCihaz, konum, işlev ve veri yönünü tutarlı biçimde adlandırın.
ADIM 2Payload şemasıBirim, veri tipi, zaman damgası ve sürüm alanlarını tanımlayın.
ADIM 3QoS / retain / LWTHer mesaj türü için teslimat ve durum politikasını seçin.
ADIM 4Güvenlik ve ölçekTLS, ACL, limitler, gözlemleme ve yedeklilik planını kurun.
Sık sorulanlar

Kısa cevaplarla MQTT.

Sahada en çok karşılaşılan kavram karışıklıkları ve tasarım soruları.

MQTT bir haberleşme kablosu veya fiziksel katman mıdır?

Hayır. MQTT uygulama katmanı protokolüdür. Genellikle TCP/IP üzerinde çalışır; Ethernet, Wi‑Fi, hücresel ağ veya IP taşıyan başka bir altyapı kullanılabilir.

Broker olmadan MQTT kullanılabilir mi?

Standart MQTT publish/subscribe mimarisinde broker merkezî bileşendir. Doğrudan cihazdan cihaza iletişim için farklı protokoller veya arada gömülü broker yaklaşımı gerekir.

Her mesajı QoS 2 yapmak daha güvenli midir?

Daha yüksek teslimat güvencesi verir; ancak daha fazla paket, durum takibi, bellek ve gecikme oluşturur. Çoğu telemetri için QoS 0; önemli olay ve komutlar için QoS 1 daha dengeli olabilir.

Retained mesaj ile kalıcı oturum aynı şey midir?

Hayır. Retained mesaj topic’in son değeridir ve yeni abonelere verilir. Kalıcı oturum ise istemcinin abonelikleri ve uygun çevrimdışı mesajlarıyla ilgilidir.

MQTT mesajı mutlaka JSON olmak zorunda mı?

Hayır. Payload bayt dizisidir. JSON okunabilirlik sağlar; ikili biçimler ise daha küçük ve hızlı olabilir. Şema, cihaz ve sunucu arasında ayrıca tanımlanmalıdır.

MQTT internete bağlı olmadan çalışır mı?

Evet. Broker yerel ağda, endüstriyel bilgisayarda veya cihaz üzerinde çalışabilir. İnternet yalnızca uzaktan erişim ya da bulut entegrasyonu gerekiyorsa zorunlu olur.