MQTT Nedir? Nerede Kullanılır, Ne İşe Yarar? Kapsamlı IoT ve IIoT Rehberi

1. Giriş: MQTT Nedir ve Neden Hayatımıza Girdi?

MQTT (Message Queuing Telemetry Transport), kısıtlı donanım kaynaklarına sahip cihazlar, yüksek gecikmeli veya kesintili ağlar ve düşük bant genişliğine sahip iletişim kanalları için özel olarak tasarlanmış son derece hafif, açık standartlı bir mesajlaşma protokolüdür. İlk olarak 1999 yılında Andy Stanford-Clark (IBM) ve Arlen Nipper (Arcom, günümüzde Cirrus Link) tarafından geliştirilmiştir. Protokolün ilk tasarım amacı; çöl veya okyanus ortasındaki petrol boru hatları üzerinde bulunan sensörlerin, pahalı ve sınırlı bant genişliği sunan uydu bağlantıları üzerinden merkezi SCADA (Supervisory Control and Data Acquisition) sistemleri ile güvenilir, düşük maliyetli ve kesintisiz bir şekilde haberleşmesini sağlamaktı.

Günümüzde ise MQTT, ISO/IEC 20922 ve OASIS standartları altında Nesnelerin İnterneti (IoT - Internet of Things), Endüstriyel Nesnelerin İnterneti (IIoT - Industrial Internet of Things), akıllı şehirler, akıllı binalar, otomotiv ve enerji yönetim sistemlerinin vazgeçilmez bir iletişim omurgası haline gelmiştir. Geleneksel web mimarilerinde yaygın olarak kullanılan HTTP (Hypertext Transfer Protocol) gibi istemci-sunucu (client-server) ve istek-yanıt (request-response) modeline dayalı protokoller, her bir veri paketi gönderiminde ciddi bir başlık (header) yükü oluşturur. Ayrıca bağlantı yönetimi ve sunucuyu sürekli sorgulama (polling) gereksinimleri nedeniyle pil ile çalışan sensörlerin ve sınırlı bant genişliğine sahip saha cihazlarının kaynaklarını hızla tüketirler. MQTT ise sadece 2 baytlık minimum sabit başlık (fixed header) boyutu ile veri paketlerini ileterek ağ üzerindeki yükü, gecikmeyi ve enerji tüketimini en aza indirir.

2. MQTT Protokolünün Mimarisi ve Çalışma Prensibi

MQTT protokolü, istemcilerin birbiriyle doğrudan haberleştiği noktadan noktaya (peer-to-peer) mimari yerine, tüm mesaj trafiğini yöneten merkezi bir yönlendiriciye dayanan Yayınla-Abone Ol (Publish-Subscribe) mimarisini kullanır. Bu mimari, veriyi üreten taraf ile veriyi tüketen tarafı birbirinden hem zamansal hem de mekansal olarak tamamen ayırır (decoupling). Mimarinin temel bileşenleri şunlardır:

2.1. İstemci (MQTT Client)

MQTT ekosisteminde bir istemci, bir MQTT Broker'ına TCP/IP veya WebSocket üzerinden bağlanabilen, veri gönderme (yayınlama) veya veri alma (abone olma) yeteneğine sahip herhangi biryazılım ya da donanım cihazıdır. İstemciler rollerine göre iki temel fonksiyon üstlenebilir ve duruma göre her iki işlevi aynı anda yürütebilirler:

• Yayıncı (Publisher): Sahadaki fiziksel parametreleri (sıcaklık, basınç, akım, voltaj, nem, vb.) okuyan sensörler, PLC'ler (Programlanabilir Lojik Kontrolörler), RTU'lar (Uzak Terminal Üniteleri) veya akıllı sayaçlar gibi cihazlardır. Topladıkları verileri belirli bir konu (Topic) başlığı altında Broker'a gönderirler.
• Abone (Subscriber): Belirli bir konu hiyerarşisine kaydolan ve Broker üzerinden bu konulara ait yeni bir mesaj yayınlandığında veriyi anında teslim alan istemcilerdir. Örnek olarak merkezi SCADA sistemleri, veri tabanı sunucuları, bulut analitik platformları, mobil uygulamalar veya web panelleri verilebilir.

2.2. Broker (Merkezi Sunucu)

MQTT Broker, tüm mesajlaşma ekosisteminin kalbinde yer alan akıllı dağıtım sunucusudur. Yayıncı istemcilerden gelen mesajları kabul eder, mesajın konu başlığını ve başlık verilerini analiz eder, yetkilendirmeleri kontrol eder ve ilgili konuya abone olmuş tüm istemcilere veriyi anında iletir. Bir MQTT Broker'ın temel sorumlulukları şunlardır:

• Tüm istemci bağlantılarını kabul etmek, kimlik doğrulama (Authentication) ve yetkilendirme (Authorization) süreçlerini yürütmek.
• Konu hiyerarşisini (Topic Tree) ve aktif abonelik listelerini canlı tutmak.
• Seçilen Hizmet Kalitesi (QoS - Quality of Service) seviyelerine göre mesajların eksiksiz teslimatını garanti etmek.
• Bağlantısı kopan istemciler için Last Will and Testament (LWT - Son İrade) mesajlarını yönetmek ve yayınlamak.
• Retained (saklı) mesajları hafızada tutarak yeni bağlanan abonelere en son güncel durumu anında sunmak.

2.3. Konu Hiyerarşisi (Topic Architecture) ve Joker Karakterler

MQTT mesajlarının hedefini ve kategorisini belirleyen mantıksal adresleme yapısına "Topic" denir. Konular, eğik çizgi (/) karakteri ile ayrılan, büyük/küçük harfe duyarlı UTF-8 metin dizileridir. Bu esnek hiyerarşik yapı sayesinde binlerce saha cihazından gelen veriler düzenli bir ağaç mimarisinde gruplanabilir. Örnek bir endüstriyel konu yapısı şu şekildedir:

fabrika/bolum1/hat3/plc01/sicaklik

İstemciler konulara abone olurken tüm alt başlıkları tek tek tanımlamak yerine joker (wildcard) karakterler kullanarak geniş kapsamlı dinleme yapabilirler:

• Tek Seviyeli Joker (+): Bulunduğu hiyerarşik seviyedeki tam olarak tek bir dize yerine geçer. Örneğin; fabrika/+/hat3/plc01/sicaklik konusu, fabrikadaki tüm bölümlerde bulunan Hat 3 altındaki PLC01 sıcaklık verilerini dinler.
• Çok Seviyeli Joker (#): Tanımlandığı seviyeden sonraki tüm alt hiyerarşik seviyeleri kapsar ve konu tanımının en sonunda yer almak zorundadır. Örneğin; fabrika/bolum1/# konusu, Bölüm 1 altındaki tüm cihazların ürettiği bütün veri akışlarına abone olur.

3. MQTT Protokolünün Temel Teknolojik Özellikleri

3.1. Clean Session (Temiz Oturum Yönetimi)

Bir MQTT istemcisi Broker'a TCP bağlantısı kurarken bir Clean Session bayrağı (flag) iletir. Bu parametre, bağlantı koptuğunda ve tekrar sağlandığında oturumun nasıl yönetileceğini belirler:

• Clean Session = True (1): İstemci bağlandığında Broker, bu istemciye ait önceki tüm oturum verilerini, abonelik listelerini ve henüz iletilmemiş mesajları siler. Bağlantı kesildiğinde de istemcinin izleri temizlenir. Geçici, anlık veri izleme uygulamalarında tercih edilir.
• Clean Session = False (0): İstemci bağlantısı koptuğunda dahi Broker, istemcinin aboneliklerini ve iletilemeyen QoS 1/QoS 2 mesajlarını hafızasında korur. İstemci aynı Client ID ile tekrar bağlandığında, kaçırdığı tüm kritik mesajlar sırasıyla kendisine iletilir. Hücresel ağlarda kesintisiz veri akışı için kritik önem taşır.

3.2. QoS (Quality of Service - Hizmet Kalitesi Seviyeleri)

MQTT, ağ bant genişliği ve mesaj teslimat güvenilirliği arasında esnek bir denge kurabilmek adına 3 farklı QoS seviyesi sunar:

QoS 0: En Fazla Bir Kez (At Most Once - Fire and Forget)

Mesaj gönderici tarafından alıcıya iletilir ve herhangi bir onay mesajı (PUBACK) beklenmez. Mesaj ağdaki aksaklıklar nedeniyle kaybolabilir; ancak kesinlikle mükerrer (tekrar) iletilmez. Minimum bant genişliği ve en hızlı iletim seçeneğidir. Anlık hava durumu verileri veya saniyede onlarca kez okunan kritik olmayan sensör değerleri için uygundur.

QoS 1: En Az Bir Kez (At Least Once)

Mesajın alıcıya ulaştığı, alıcının göndericiye PUBACK (Yayın Onay) paketi dönmesiyle garanti edilir. Gönderici belirli bir süre içinde PUBACK alamazsa mesajı tekrar iletir. Bu seviyede mesajın kaybolmama garantisi vardır; ancak ağ gecikmelerinde aynı mesajın alıcıya birden fazla kez ulaşma ihtimali (mükerrer veri) mevcuttur. Sayaç okuma, alarm sistemleri ve saha durum izlemelerinde en yaygın kullanılan seviyedir.

QoS 2: Kesinlikle Bir Kez (Exactly Once)

Mesajın ne kaybolmasını ne de tekrar iletilmesini kabul eden kritik uygulamalar için tasarlanmış dört adımlı bir el sıkışma (handshake) mekanizmasıdır (PUBLISH → PUBREC → PUBREL → PUBCOMP). Bant genişliği ve işlemci yükü en yüksek seviyedir; fakat mesaj kesinlikle tam bir kez teslim edilir. Bankacılık işlemleri, faturalandırma sistemleri ve kritik PLC kontrol komutları için tercih edilir.

3.3. LWT (Last Will and Testament - Son İrade Mesajı)

Saha cihazlarının ağ durumunu canlı izlemek için geliştirilmiş benzersiz bir özelliktir. Bir istemci Broker'a bağlanırken bir LWT konusu, LWT mesajı ve QoS seviyesi tanımlar. Eğer istemci bağlantısını düzgün bir DISCONNECT paketi göndermeden kaybederse (örneğin güç kesintisi, kablo kopması veya sinyal kaybı yaşanırsa), Broker bu LWT mesajını otomatik olarak ilgili konunun abonelerine yayınlar. Böylece merkezi sistem sahadaki cihazın çevrimdışı olduğunu milisaniyeler içinde tespit eder.

3.4. Retain Message (Saklı Mesaj)

Yayınlanan bir mesajda Retain = True olarak işaretlendiğinde, Broker bu mesajı o konunun "son bilinen doğru durumu" olarak belleğinde saklar. İleride o konuya yeni bir istemci abone olduğunda, yayıncı cihazın yeni bir mesaj göndermesini beklemeden, saklanan bu en güncel mesajı yeni aboneye anında teslim eder. Cihaz konfigürasyon parametreleri ve son çalışma durumlarının saklanmasında son derece etkilidir.

3.5. Zaman Etiketleme ve Backfilling (Geçmiş Veri Tamamlama)

Endüstriyel RTU ve PLC sistemlerinde (örneğin Mikrodev otomasyon çözümlerinde), sahadan toplanan verilerin payload içerisine hassas zaman etiketleri (timestamp) eklenir. Şebeke veya GSM bağlantısı koptuğunda, saha cihazı topladığı verileri dahili hafızasına (Flash/RAM) kaydeder. Bağlantı tekrar kurulduğunda, biriken tüm geçmiş veriler zaman etiketli MQTT paketleri halinde merkezi SCADA veya veritabanı sunucularına aktarılır (Backfilling). Bu mekanizma sayesinde veri kaybı yaşanmaz ve SCADA sistemleri geçmişe dönük doğru analizler üretebilir.

4. MQTT Nerede Kullanılır ve Ne İşe Yarar? (Kullanım Alanları)

MQTT; esnek yapısı, düşük kaynak tüketimi ve yüksek ölçeklenebilirliği sayesinde günümüzde çok geniş bir endüstriyel ve ticari yelpazede ana iletişim protokolü olarak görev yapmaktadır:

4.1. Endüstriyel Otomasyon ve Akıllı Fabrikalar (IIoT)

Modern üretim tesislerinde sahadaki Modbus RTU/TCP, Profinet, EtherNet/IP veya CANbus protokolleri ile çalışan cihaz verileri, IoT Gateway'ler ve PLC'ler aracılığıyla MQTT formatına dönüştürülür. Üretim miktarı, makine çalışma süreleri, duruş nedenleri ve OEE (Toplam Ekipman Etkinliği) verileri merkezi MES (Manufacturing Execution System) ve ERP sistemlerine aktarılır.

4.2. Enerji Yönetimi ve Güç SCADA Sistemleri

Elektrik iletim/dağıtım şebekelerinde, trafo merkezlerinde, güneş (GES) ve rüzgar (RES) santrallerinde enerji analizörlerinin, koruma rölelerinin ve eviricilerin (inverter) uzaktan anlık izlenmesinde kullanılır. Yüksek gecikmesizlik sayesinde güç kalitesi ve arıza durumları anında tespit edilir.

4.3. İçme Suyu, Atıksu ve Su Deposu Otomasyonu

Geniş coğrafi alanlara yayılmış su depoları, terfi istasyonları, vana odaları ve arıtma tesislerinde bulunan bataryalı veya güneş enerjili RTU cihazları GSM/GPRS üzerinden haberleşir. MQTT'nin değişimde gönderim (on-change) ve düşük paket başlığı avantajı sayesinde SIM kart veri kullanımı minimum seviyeye indirilir.

4.4. Akıllı Şehirler ve Altyapı Yönetimi

Akıllı sokak aydınlatmaları, otopark doluluk sensörleri, hava kalitesi ölçüm istasyonları, atık yönetim sistemleri ve akıllı kavşak sinyalizasyonları MQTT altyapısı üzerinden tek bir merkezi akıllı şehir yönetim platformuna bağlanır.

4.5. Otomatik Sayaç Okuma Sistemleri (OSOS)

Elektrik, su ve doğalgaz sayaçlarının uzaktan periyodik olarak okunduğu projelerde, DLMS/COSEM veya M-Bus protokollerindeki sayaç verileri MQTT paketlerine dönüştürülerek binlerce sayacın tek bir Broker üzerinden veritabanlarına güvenle aktarılması sağlanır.

5. MQTT Güvenliği ve Sparkplug B Standardı

5.1. MQTT Güvenlik Mekanizmaları

MQTT doğası gereği hafif bir protokol olsa da endüstriyel seviyede güvenlik standartlarını tam olarak destekler:

• Ağ Katmanı Güvenliği (TLS/SSL): TCP bağlantısı TLS/SSL şifreleme katmanı ile koruma altına alınarak verilerin dinlenmesi (eavesdropping) ve değiştirilmesi engellenir.
• Kimlik Doğrulama (Authentication): İstemciler Broker'a bağlanırken kullanıcı adı/parola veya TLS X.509 istemci sertifikaları ile kimlik doğrulaması yaparlar.
• Erişim Kontrol Listeleri (ACL - Authorization): Broker üzerinde hangi istemcinin hangi konulara mesaj yayınlayabileceği veya abone olabileceği ince detaylı olarak yetkilendirilir.

5.2. Sparkplug B Standardı

Standart MQTT, payload içeriği konusunda özgür bir yapı sunar (JSON, XML, Binary, vb.). Ancak endüstriyel otomasyonda standartlaşmayı sağlamak amacıyla Eclipse Foundation bünyesinde Sparkplug B spesifikasyonu geliştirilmiştir. Sparkplug B; konu yapısını, Google Protocol Buffers (Protobuf) tabanlı sıkıştırılmış binary payload formatını, cihazların tak-çalıştır (plug-and-play) mantığıyla SCADA sistemlerine otomatik tanımlanmasını (STATE, BIRTH, DEATH mesajları) standardize eder.

5.3. Popular MQTT Brokers (Popüler MQTT Broker Yazılımları)

Endüstriyel ve kurumsal projelerde kullanılan en popüler açık kaynaklı ve ticari MQTT Broker çözümleri şunlardır:

• Eclipse Mosquitto: Hafif yapısı, düşük kaynak tüketimi ve C dili ile yazılmış olması sayesinde Raspberry Pi ve gömülü sistemlerden küçük ölçekli sunuculara kadar en yaygın kullanılan açık kaynaklı MQTT Broker'dır.
• EMQX (EMQ X): Erlang/OTP üzerinde geliştirilmiş, saniyede milyonlarca eşzamanlı mesajı ve istemci bağlantısını işleyebilen, yüksek kullanılabilirlik (High Availability) ve kümeleme (Clustering) desteği sunan kurumsal ölçekli bir broker'dır.
• HiveMQ: Kurumsal IoT projeleri, otomotiv sektörü ve büyük ölçekli sanayi tesisleri için tasarlanmış; gelişmiş izleme panelleri, Kafka ve veritabanı entegrasyonları olan yüksek performanslı Java tabanlı bir broker platformudur.
• VerneMQ: Erlang tabanlı, yatayda kolayca büyütülebilen (horizontal scaling) ve distributed (dağıtık) mimariler için optimize edilmiş yüksek güvenilirlikli bir diğer açık kaynak seçeneğidir.

5.4. Konu İsimlendirme ve Mimari Tasarım En İyi Uygulamaları (Best Practices)

Büyük ölçekli IoT ve otomasyon projelerinde MQTT konu yapısının doğru kurgulanması, sistemin sürdürülebilirliği ve performansı açısından kritik önem taşır. İşte en iyi uygulamalar:

• Küçük Harf ve Anlaşılır İsimler Kullanın: Konu isimlerinde Türkçe karakterler, boşluklar veya özel semboller yerine küçük harf ve alt çizgi (_) tercih edilmelidir.
• Genelden Özele Hiyerarşi Oluşturun: Konu yapısı her zaman lokasyon, tesis, cihaz tipi, cihaz kimliği ve parametre sırasını takip etmelidir (Örn: turkiye/istanbul/tesis1/pompa_02/akim).
• Başta veya Sonda Eğik Çizgi Kullanmayın: Konu adının en başına veya en sonuna / koymak gereksiz boş seviyeler oluşturur (Örn: /fabrika/sicaklik/ yerine fabrika/sicaklik kullanılmalıdır).
• Cihaz Özgü Konular ile Komut İletimi: Cihaza komut gönderirken ve cihazdan yanıt alırken ayrı konular tanımlanmalıdır (Örn: tesis/cihaz01/command ve tesis/cihaz01/telemetry).

6. MQTT ile HTTP/REST Protokollerinin Detaylı Karşılaştırması

Karşılaştırma Kriteri	MQTT	HTTP / REST
Mimari Yapı	Yayınla-Abone Ol (Publish-Subscribe)	İstemci-Sunucu (Request-Response)
Sabit Başlık Boyutu	2 Bayt (Çok Düşük)	200 - 800 Bayt (Yüksek)
İletişim Tipi	Asenkron (Çift yönlü)	Senkron (İstek tabanlı)
Veri Formatı	İkili (Binary), JSON, Protobuf, Metin	Ağırlıklı olarak JSON, XML, HTML
Bant Genişliği & Güç Tüketimi	Çok Düşük (Pil ve GSM Dostu)	Yüksek (Sürekli Polling yükü)
Teslimat Güvencesi (QoS)	Var (QoS 0, QoS 1, QoS 2)	Yok (Uygulama katmanında geliştirilmeli)
Bağlantı Durum İzleme	Var (LWT ve Keep-Alive)	Yok (Sadece istek anında kontrol)

7. Sonuç ve Genel Değerlendirme

MQTT (Message Queuing Telemetry Transport), sunduğu mimari esneklik, düşük veri maliyeti, yüksek güvenilirlik ve ölçeklenebilirlik sayesinde günümüz IoT ve IIoT dünyasının standart iletişim protokolü haline gelmiştir. Sahadaki en küçük sensörden buluttaki devasa yapay zeka analitik sistemlerine kadar kesintisiz bir köprü kuran MQTT; doğru Broker seçimi, uygun QoS yapılandırması ve sağlam güvenlik katmanları ile entegre edildiğinde endüstriyel tesislerin dijital dönüşüm süreçlerini ivmelendiren en kritik teknolojik bileşendir.