IoT için MQTT ve HTTP: Hangi Protokolü Kullanmalısınız?

HTTP web’i çalıştırır; MQTT ise güvenilmez ağlardaki makineler için tasarlandı. İkisi de TCP üzerinde çalışır, ikisi de TLS ile güvence altına alınabilir ve ikisi de JSON taşıyabilir. Fark iletişim modelindedir — ve IoT iş yükünüze hangisinin uyduğunu bu model belirler. Bu yazı ikisini, HTTP’nin daha iyi seçim olduğu durumlar dahil, dürüstçe karşılaştırıyor.

İki farklı iletişim modeli

HTTP istek/yanıt (request/response) modelidir. Bir client belirli bir sunucudan belirli bir kaynağı ister ve yanıtı bekler. Sunucu ilk konuşan taraf olamaz: bir cihazın bir değişiklikten haberdar olması gerekiyorsa polling yapmalı, uzun bir isteği açık tutmalı veya server-sent events ya da WebSocket gibi ek bir mekanizma kullanmalıdır.

MQTT publish/subscribe modelidir. Client’lar bir broker’a bağlanır ve bağlantıyı açık tutar. Publisher’lar topic’lere mesaj gönderir; broker bunları o topic’in tüm subscriber’larına iletir (push). Gönderen ve alanların birbirinden haberdar olması gerekmez. Modelde yeniyseniz önce MQTT nedir yazısını okuyun.

MQTT ve HTTP karşılaştırması

Ek yük ve pil ömrü

PINGREQ gibi minimal bir MQTT paketi yalnızca 2 bayttır ve bir publish küçük bir header’a sadece topic adını ve payload’u ekler. Bir HTTP isteği ise bir method satırı, bir host header’ı ve çoğu zaman user-agent, content-type, authorization ve cookie header’larını — metin olarak, her istekte — taşır. Bir sensör birkaç saniyede bir 20 baytlık bir ölçüm gönderdiğinde bu çerçeveleme trafiğe hâkim olur.

Bağlantı kurulumu daha da önemlidir. Her yeni HTTPS bağlantısı bir TCP ve TLS el sıkışmasına mal olur; bu da hücresel bir cihazda radyo süresi ve pil demektir. MQTT bu bedeli bir kez öder ve sonra bağlantıyı iki yön için de yeniden kullanır. HTTP keep-alive ve HTTP/2 aradaki farkı daraltır, ancak sunucuya cihaza push yapma imkânı vermez.

Kötü ağlarda güvenilirlik

MQTT’nin teslimat semantiği protokolün içindedir. QoS 1 ve 2 mesajları onaylar ve yeniden dener, kalıcı oturumlar bağlantısı kopan client’lar için mesajları kuyruğa alır, retained mesajlar yeni bir subscriber’a bilinen son değeri anında verir ve bir Last Will bir cihaz veda etmeden ortadan kaybolduğunda herkese haber verir. HTTP ile bunların her birini kendiniz kurarsınız: yeniden denemeler, idempotency anahtarları, bir durum deposu ve bir heartbeat uç noktası.

Güvenlik

İki protokol de şifreleme için TLS’e dayanır; dolayısıyla hiçbiri doğası gereği daha güvenli değildir. Fark, yetkilendirmenin nerede yapıldığındadır. Bir HTTP API’si her isteğin kimliğini, genellikle bir token ile doğrular ve uç nokta bazında yetkilendirir. Bir MQTT broker’ı ise kimliği bir kez CONNECT sırasında doğrular (kullanıcı adı/parola, client sertifikaları veya MQTT 5’te enhanced authentication) ve ardından her publish ve subscribe işlemini topic seviyesindeki erişim kurallarına göre yetkilendirir. Bu yüzden iyi tasarlanmış bir topic hiyerarşisi güvenlik modelinizin bir parçasıdır: topic’ler cihaz ID’sini içerdiğinde bu cihaz yalnızca kendi alt ağacına publish edebilir gibi bir kuralı ifade etmek kolaydır.

Ölçekleme

HTTP servisleri bir load balancer arkasında yatay olarak ölçeklenir, çünkü her istek bağımsızdır. MQTT broker’ları ise bağlı her client için durum tutar — abonelikler, oturumlar, yoldaki mesajlar — bu yüzden büyük filolara ölçeklemek broker’ı kümelemek (clustering) veya bunu yapan bir sağlayıcı kullanmak anlamına gelir. Tüketici tarafında MQTT 5 paylaşımlı abonelikleri mesajları birden fazla backend worker’ına dağıtır. Genel olarak hiçbir yaklaşım daha zor değildir; yalnızca karmaşıklığı farklı yerlere koyarlar.

Aynı ölçüm, iki yol

curl -X POST https://api.example.com/devices/sensor-17/readings \
  -H 'Content-Type: application/json' \
  -d '{"temp":21.4}'

mosquitto_pub -h broker.emqx.io -t 'testmqtt/sensor-17/temp' -q 1 -m '{"temp":21.4}'

HTTP’de ölçümü daha sonra kimin alacağına API karar verir. MQTT’de ise bir pano, bir veritabanı yazıcısı ve bir alarm servisi, cihaz onların varlığından haberdar olmadan testmqtt/+/temp filtresine abone olabilir.

Canlı ölçümlere tarayıcıda abone olun

MQTT ne zaman kullanılmalı?

• Çok sayıda cihazdan sık gelen telemetri.
• NAT veya firewall arkasındaki cihazlara komut göndermek — cihazlar dışarı bağlanır, broker içeri push eder.
• Polling değil push gerektiren gerçek zamanlı panolar ve alarmlar.
• Kısıtlı donanım, ücretli bağlantılar veya pille çalışan cihazlar.
• Birden fazla bağımsız servis tarafından tüketilen tek bir olay.

HTTP ne zaman kullanılmalı?

• Bir REST API ile kaynakları sorgulamak ve yönetmek (cihaz kaydı, ayarlar, kullanıcı hesapları).
• Firmware imajları, log’lar veya kamera görüntüleri gibi büyük dosya aktarımları.
• Bağlantıyı açık tutmaya değmeyecek seyrek, tek seferlik yüklemeler.
• Standart web araçları, önbellekleme ve kimlik doğrulama bekleyen üçüncü taraflar için genel API’ler.

Peki ya tarayıcılar?

Tarayıcılar ham MQTT bağlantıları açamaz, ancak MQTT, hayata bir HTTP upgrade isteği olarak başlayan WebSocket’ler üzerinde sorunsuz çalışır. Bu, web panolarına cihazlarınızın kullandığı topic’lerle canlı push imkânı verir. Portlar ve kurulum için WebSocket üzerinden MQTT yazısına bakın.

Sonuç

Olay odaklı, çok cihazlı, çift yönlü iletişim için MQTT’yi; kaynak odaklı API’ler ve toplu aktarımlar için HTTP’yi seçin. Emin değilseniz karar vermeden önce MQTT tarafını online MQTT client ve bir genel test broker’ı ile birkaç dakikada prototipleyin.

Sıkça sorulan sorular