IoT cihazlarında MQTT mi HTTP mi? Sahadan buluta veri taşımak

Sahadaki cihazdan buluta veri taşırken MQTT ile HTTP birbirinin rakibi değil; bağlantı modeli, güç bütçesi, buluttan cihaza komut ihtiyacı ve altyapı kısıtları kararı belirler. Bu yazıda iki yaklaşımı küçük ekiplerin gözünden karşılaştırıyor, sonunda da sade bir karar tablosu veriyoruz.

IoT projelerinde protokol tartışması genelde erken ve yanlış yerden başlar: “Herkes MQTT kullanıyor” ya da “Bizim backend zaten REST”. Oysa doğru soru, cihazın ne sıklıkla konuştuğu, buluttan cihaza ne kadar hızlı ulaşılması gerektiği ve bağlantının ne kadar güvenilir olduğudur.

TW Bilişim olarak gömülü donanım, firmware ve backend tarafını birlikte geliştirdiğimiz projelerde gördüğümüz tablo şu: protokol seçimi tek başına başarı ya da başarısızlık getirmez, ama yanlış seçim sahada pil, veri maliyeti ve gecikme olarak geri döner.

İki farklı model: kalıcı bağlantı ve istek/yanıt

MQTT, cihazın bir aracı sunucuya (broker) bağlanıp konu (topic) üzerinden yayın yaptığı ve abone olduğu bir yayınla/abone ol (publish/subscribe) protokolüdür. Bağlantı genelde açık kalır; cihaz hem veri gönderir hem de komut bekler.

HTTP ise istek/yanıt modelidir. Cihaz bir istek atar, sunucu yanıt verir, iş biter. Sunucu cihaza kendiliğinden ulaşamaz; cihaz sorana kadar bekler.

Bu fark, diğer tüm karşılaştırmaların temelidir.

MQTT'nin güçlü yanları

• Buluttan cihaza anlık komut: Cihaz bağlı olduğu sürece komut beklemeden ulaşır. Röle açma, ayar değiştirme, uzaktan teşhis gibi işler için doğal çözümdür.
• Hafif başlık yükü: Bağlantı kurulduktan sonra her mesajın protokol yükü çok küçüktür; sık ve küçük mesajlarda veri tasarrufu sağlar.
• QoS seviyeleri: QoS 0 (en fazla bir kez), QoS 1 (en az bir kez) ve QoS 2 (tam olarak bir kez) ile teslim garantisi mesaj bazında seçilir.
• Retained mesaj ve son vasiyet (LWT): Yeni bağlanan bir abone son durumu hemen alır; cihaz beklenmedik şekilde koptuğunda broker bunu diğer tarafa bildirir.

Bedeli: bir broker işletmek, bağlantıyı canlı tutmak (keepalive) ve topic yapısını, yetkileri iyi tasarlamak gerekir.

HTTP'nin güçlü yanları

• Her yerde çalışır: Kurumsal ağlar, proxy'ler ve güvenlik duvarları HTTPS'e genelde izin verir. Özel port açmak gerekmez.
• Mevcut backend ile uyum: Ekip zaten REST API geliştiriyorsa ek altyapı gerekmez; kimlik doğrulama, loglama ve ölçekleme bilinen araçlarla yapılır.
• Durumsuz (stateless): Sunucu tarafında açık bağlantı tutulmaz; seyrek veri gönderen binlerce cihaz için ölçeklemesi basittir.
• Basit hata ayıklama: İstekler bilinen araçlarla izlenir ve tekrar oynatılır.

Bedeli: her istekte başlık yükü vardır, buluttan cihaza komut için cihazın periyodik olarak sorması (polling) gerekir ve bağlantı her seferinde yeniden kuruluyorsa TLS el sıkışması pahalıdır.

Güç bütçesi açısından

Pille çalışan cihazlarda karar çoğu zaman burada verilir:

• Cihaz saatte bir ölçüm gönderiyor ve arada uyuyorsa, her uyanışta kısa bir HTTPS isteği atıp radyoyu kapatmak genelde daha verimlidir. MQTT bağlantısını açık tutmak için keepalive trafiği ve radyonun uyanık kalması gerekir.
• Cihaz sürekli besleniyorsa (şebeke, araç, güneş) ya da buluttan anlık komut alması gerekiyorsa, açık bir MQTT bağlantısı hem gecikmeyi hem toplam veri miktarını düşürür.
• Her iki durumda da en büyük maliyet çoğu zaman bağlantı kurmaktır: ağa kayıt ve TLS el sıkışması. Oturum sürdürme (session resumption) ve veriyi biriktirip toplu göndermek iki protokolde de işe yarar.

Güç bütçesini nasıl çıkaracağınızı düşük güç tasarımı yazımızda anlattık.

Bağlantı koptuğunda ne olacak?

Sahada bağlantı kopar; tasarım bunu varsaymalıdır:

• Cihaz tarafında yerel tampon: Gönderilemeyen ölçümler kalıcı bellekte sıraya alınmalı, bağlantı gelince sırayla gönderilmelidir.
• Zaman damgası cihazda atılmalı: Gecikmeli gelen veri, sunucuya ulaştığı ana göre değil, ölçüldüğü ana göre kaydedilmelidir.
• Tekrarlanan mesajlara dayanıklı backend: QoS 1 ve HTTP yeniden denemeleri aynı mesajı iki kez getirebilir. Mesaj kimliği ile tekrarları ayıklayın.
• Geri çekilme (backoff): Binlerce cihazın aynı anda yeniden bağlanmaya çalışması sunucuyu düşürebilir; rastgele gecikmeli yeniden deneme kullanın.

Cihazın kendisinin takılı kalmaması için watchdog tasarımı da bu resmin parçasıdır.

Güvenlik: protokolden bağımsız kurallar

• Trafik her zaman TLS ile şifrelenmeli; MQTT için 8883 portu standarttır.
• Her cihazın kendi kimliği olmalı: cihaz başına sertifika ya da anahtar. Tüm filoda paylaşılan tek parola, bir cihaz ele geçirildiğinde hepsini açar.
• MQTT'de topic bazlı yetki: Bir cihaz yalnızca kendi topic'lerine yazıp okuyabilmeli.
• Firmware güncellemesi bu kanaldan tetikleniyorsa imza doğrulaması şarttır; ayrıntılar OTA güncelleme yazımızda.

Veri formatı da maliyettir

JSON okunabilir ve hata ayıklaması kolaydır, ama hücresel veri ücretli olduğunda her bayt önemlidir. CBOR ya da Protocol Buffers gibi ikili formatlar mesaj boyutunu belirgin biçimde küçültür. Pratik yol: geliştirmede JSON ile başlayın, mesaj şemasını sabitleyin, veri maliyeti gerçekten önemliyse ikili formata geçin.

Karar tablosu

Durum	Öneri
Seyrek ölçüm, pille çalışan cihaz, komut ihtiyacı yok	HTTPS (toplu gönderim)
Sürekli beslenen cihaz, anlık komut ve durum takibi	MQTT
Kısıtlı kurumsal ağ, sadece 443 açık	HTTPS veya WebSocket üzerinden MQTT
Çok sayıda küçük ve sık mesaj	MQTT
Mevcut REST backend, küçük filo, hızlı başlangıç	HTTPS
Çok kısıtlı cihaz ve ağ (NB-IoT, UDP)	CoAP / LwM2M değerlendirin

Pek çok projede iki protokol birlikte kullanılır: telemetri ve komutlar MQTT ile, büyük dosya ve firmware indirmeleri HTTPS ile. Bu bir uzlaşma değil, her işe uygun aracı seçmektir.

SSS

MQTT her zaman daha az veri mi harcar?
Sık ve küçük mesajlarda genelde evet. Ancak cihaz seyrek konuşuyor ve bağlantıyı açık tutmak için keepalive gönderiyorsa, toplamda HTTPS'ten daha fazla trafik ve enerji harcayabilir.

Broker'ı kendimiz mi işletmeliyiz?
Küçük filolarda yönetilen bir broker hızlı başlangıç sağlar. Veri yerelliği, maliyet ya da özelleştirme gerekiyorsa açık kaynak bir broker kendi altyapınızda çalıştırılabilir; bu durumda izleme ve yedeklilik de sizin sorumluluğunuzdadır.

WebSocket bu resmin neresinde?
WebSocket, HTTP bağlantısını kalıcı ve çift yönlü hale getirir. Kısıtlı ağlarda MQTT'yi WebSocket üzerinden taşımak yaygın bir çözümdür.

Sonradan protokol değiştirmek zor mu?
Firmware'de iletişim katmanını soyutladıysanız yönetilebilir. Uygulama kodu doğrudan protokol kütüphanesine bağlıysa değişiklik pahalılaşır. Mesaj şemasını protokolden bağımsız tasarlamak bu riski azaltır.

TW Bilişim bu konuda ne yapıyor?
Cihaz firmware'i, iletişim katmanı ve backend'i birlikte tasarlıyoruz: güç bütçesine uygun protokol, cihaz başına kimlik, bağlantı kopmasına dayanıklı veri akışı ve izlenebilir bir altyapı. Amaç sahadaki cihazdan gelen verinin güvenilir ve sürdürülebilir şekilde akması.

Sonuç

Sıra basit: cihaz ne sıklıkla konuşuyor → buluttan cihaza komut gerekiyor mu → cihaz pille mi çalışıyor → ağ hangi portlara izin veriyor → bağlantı koptuğunda veri nereye yazılıyor. Bu beş sorunun cevabı netse, MQTT ile HTTP arasındaki seçim kendiliğinden ortaya çıkar.

IoT cihazınızın iletişim mimarisini birlikte planlamak isterseniz: iletişim veya [email protected].