MQTT 5 ve MQTT 3.1.1: Neler Değişti, Yükseltmeli misiniz?

MQTT 3.1.1, 2014’te bir OASIS standardı, daha sonra da bir ISO standardı (ISO/IEC 20922) oldu. MQTT 5 ise 2019’da OASIS standardı olarak geldi. Temel model — üç QoS seviyesiyle topic’ler üzerinden publish/subscribe — değişmedi, ancak MQTT 5 insanların sürekli geçici çözümler ürettiği özellikleri ekliyor: düzgün hata raporlama, expiry, metadata, yük dengeli abonelikler ve akış kontrolü. İşte gerçekte nelerin farklı olduğu ve ne zaman önemli olduğu.

Özet tablo

Her yerde reason code’lar

3.1.1’de başarısız bir CONNECT altı koddan birini döndürür ve diğer hataların çoğu sessizdir: bir publish yetkili değilse broker onu düşürebilir veya bağlantıyı kapatabilir. MQTT 5; CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK, DISCONNECT ve AUTH paketlerine, isteğe bağlı olarak insan tarafından okunabilir bir reason string ile birlikte bir reason code ekler. Broker ayrıca bir bağlantıyı neden kapattığını açıklamak için DISCONNECT gönderebilir; örneğin 0x8E Session taken over. Yaygın kodların tam listesi MQTT bağlantı hataları rehberimizde.

Session expiry ve message expiry

Session Expiry Interval

MQTT 3.1.1 tek bir anahtar sunar: Clean Session. cleanSession=false ile broker aboneliklerinizi ve kuyruktaki mesajlarınızı sonsuza kadar tutar; bu da hiç geri dönmeyen cihazlar için birikmeye yol açabilir. MQTT 5 bunu Clean Start (bağlanırken mevcut oturum silinsin mi?) ve Session Expiry Interval (bağlantı kesildikten sonra oturum kaç saniye tutulsun?) olarak ikiye ayırır. Artık bir cihaz şunu söyleyebilir: oturumumu bir saat tut, sonra temizle.

Message Expiry Interval

Bir publisher her mesaja saniye cinsinden bir ömür atayabilir. Mesaj o süreye kadar teslim edilmemişse — örneğin subscriber çevrimdışı olduğu için — broker onu siler. Bu, çevrimdışı bir aktüatörün saatler sonra eskimiş bir komut almasını önler ve retained mesajlar için de geçerlidir.

User properties ve içerik metadata’sı

MQTT 5 paketleri user properties taşıyabilir: HTTP header’larına benzer, rastgele UTF-8 anahtar/değer çiftleri. Payload’u bir zarfa sarmadan trace ID’leri, şema sürümleri veya kaynak tanımlayıcıları için kullanın. İlgili iki özellik payload’un kendisini tanımlar: Payload Format Indicator (binary veya UTF-8) ve Content Type (örneğin application/json).

client.publish('factory/line-1/temp', JSON.stringify({ c: 21.4 }), {
  qos: 1,
  properties: {
    messageExpiryInterval: 60,
    contentType: 'application/json',
    userProperties: { traceId: 'a1b2c3', schema: 'v2' },
  },
});

Paylaşımlı abonelikler

Normalde her subscriber eşleşen her mesajı alır. Shared subscription (paylaşımlı abonelik) ise mesajları bir grup içinde dağıtır; böylece bir backend’i yatay olarak ölçekleyebilirsiniz. Üç instance’tan $share/workers/orders/# filtresine abone olun; her mesaj bunlardan yalnızca birine gider. Birçok 3.1.1 broker’ı bunu özel bir uzantı olarak sunuyordu; MQTT 5 sözdizimini standartlaştırır. Filtreler hakkında daha fazla bilgi için MQTT topic’leri ve joker karakterler yazısına bakın.

Topic alias’ları

Uzun topic adları her publish ile birlikte gönderilir. Topic alias’larıyla bir client, bir topic’i bir kez küçük bir tamsayıya eşler ve sonra yalnızca bu tamsayıyı gönderir. Her taraf kaç alias kabul ettiğini Topic Alias Maximum ile bildirir. Bu, ücretli bağlantılar üzerinden uzun topic’lere sık publish eden cihazlar için bant genişliği tasarrufu sağlar.

İstek/yanıt

MQTT tasarım gereği tek yönlüdür, ancak birçok uygulama yanıta ihtiyaç duyar. MQTT 5, publish paketine bir Response Topic (yanıtın nereye gönderileceği) ve Correlation Data (yanıtın hangi isteğe ait olduğu) ekler. Yanıtlayan taraf ikisini de okur ve yanıtını buna göre publish eder; böylece artık kendi zarf formatınızı icat etmeniz gerekmez.

Akış kontrolü ve sınırlar

• Receive Maximum: bir tarafın aynı anda kaç onaylanmamış QoS 1 ve QoS 2 mesajını işlemeye razı olduğu. Hızlı bir broker’ın yavaş bir cihazı boğmasını engeller. Bkz. MQTT QoS seviyeleri.
• Maximum Packet Size: her taraf, bildirdiği boyutun üzerindeki paketleri reddedebilir.
• Server Keep Alive: broker, client’ın keep-alive değerini geçersiz kılabilir.
• Assigned Client Identifier: boş bir client ID ile bağlanırsanız broker size ürettiği ID’yi bildirir.

Enhanced authentication

MQTT 3.1.1’de kimlik doğrulama, CONNECT içindeki bir kullanıcı adı ve parolayla (artı aktarım katmanında TLS client sertifikalarıyla) sınırlıdır. MQTT 5 bir AUTH paketi ile Authentication Method ve Authentication Data özelliklerini ekler; bu da SCRAM veya Kerberos gibi challenge/response şemalarını ve canlı bir bağlantıda bağlantıyı kesmeden yeniden kimlik doğrulamayı mümkün kılar. Broker desteği değişkendir; ona güvenmeden önce kontrol edin.

Küçük ama kullanışlı eklemeler

• Abonelik seçenekleri: No Local (kendi mesajlarımı bana geri gönderme), Retain As Published ve Retain Handling.
• Subscription identifier’lar: teslim edilen bir mesajla hangi aboneliğin eşleştiğini söyler.
• Will Delay Interval: hızlı bir yeniden bağlanmanın tetiklememesi için Last Will mesajını geciktirir.

Yükseltmeli misiniz?

Yeni projelerde varsayılan olarak MQTT 5’i seçin: yalnızca daha iyi hata mesajları bile saatlerce hata ayıklamadan tasarruf ettirir. Firmware’in veya kütüphanelerin güncellenemediği yerlerde 3.1.1’de kalın; sizi geçişe zorlayan hiçbir şey yoktur ve iki sürüm aynı broker’da bir arada yaşar. Yükseltirken client’ınızda sürümü etkinleştirin (MQTT.js için protocolVersion: 5) ve broker’ın bunu kabul ettiğini doğrulayın.

Tarayıcıda MQTT 5 ile bağlanın

Protokolde genel olarak yeni misiniz? MQTT nedir yazısıyla başlayın veya iki sürümü de hemen online MQTT client’ta deneyin.

Sıkça sorulan sorular