MQTT Broker Bağlantı Kotaları: Bağlantılar, Mesaj Hızları ve Payload Limitleri

MQTT broker bağlantı kotaları, kaç istemci bağlayabileceğinizi, bu istemcilerin ne kadar hızlı yayın yapabileceğini ve her mesajın ne kadar büyük olabileceğini belirler. Bu rehber, managed bir broker'daki yaygın kotaların her birini, MQTT 3.1.1 ve MQTT 5 broker'larının bir limite ulaştığınızı nasıl bildirdiğini ve planınızın sınırları içinde rahatça kalan istemcileri nasıl yazacağınızı açıklıyor.

Managed Broker'lar Neden Kota Uygular?

Managed bir broker, size ayrılmış bir kümeniz olsa bile paylaşılan bir altyapıdır. Bellek, CPU, ağ bant genişliği ve dosya tanımlayıcıları sınırlıdır; dar bir yayın döngüsüne takılmış bir firmware ya da Wi-Fi kesintisinin ardından gelen bir yeniden bağlanma fırtınası gibi hatalı davranan tek bir istemci, aynı makinelerdeki herkesin hizmet kalitesini düşürebilir. Kotalar bu sınırlı kaynakları açık ve öngörülebilir limitlere dönüştürür.

Çok kiracılı (multi-tenant) bir hizmette izolasyon da pratikte kotalarla sağlanır. Örneğin ConnectMQ, bir kiracının sorununun yalnızca o kiracının sorunu olarak kalması için plan bazlı kotalar, flood koruması ve tekrarlanan başarısız girişlerin ardından IP engelleme uygular. Bu modelde yeniyseniz, bir MQTT broker'ın ne yaptığını anlatan yazımız istemcilerle broker'ların nasıl etkileştiğinin temellerini ele alıyor.

Yaygın MQTT Broker Kotaları

Çoğu sağlayıcı aşağıdakilerin bir kombinasyonunu uygular. Adlar farklı olsa da kavramlar her yerde aynıdır.

Örnek olarak gerçek plan limitleri

ConnectMQ limitlerini planlara göre şöyle belirler:

• Serverless (Free): 25'e kadar bağlantı, en fazla QoS 1, 256 KB'a kadar mesajlar.
• Serverless (Paid): 1.000'e kadar bağlantı, QoS 2, 1 MB'a kadar mesajlar, paylaşımlı abonelikler (shared subscriptions).
• Dedicated, BYOC ve Self Managed Enterprise: iş yükünüze göre boyutlandırılmış izole dağıtımlar.
• Public test broker (broker.connectmq.com): mesaj başına 64 KB, istemci başına saniyede 10 mesaj, istemci başına 10 abonelik, 8 topic seviyesi, QoS 0 ile 2 arası ve 30 dakikaya kadar oturum süresi.

Broker'lar Bir Kotaya Ulaştığınızı Nasıl Bildirir?

Protokol sürümü tam da burada büyük önem kazanır.

MQTT 3.1.1: bağlantı kesilmelerinden tahmin yürütmek

MQTT 3.1.1'de yalnızca birkaç CONNACK dönüş kodu vardır ve broker'ın bir bağlantı kesilmesini açıklamasının bir yolu yoktur. Bir 3.1.1 istemcisi bir limiti aştığında broker genellikle TCP bağlantısını kapatır. İstemci genel bir "bağlantı koptu" durumu görür ve yeniden bağlanır; çoğu zaman da aynı limite tekrar takılır. 3.1.1'de kota sorunlarını teşhis etmek, istemci loglarını sağlayıcının konsolunda görünen bilgilerle ilişkilendirmek demektir.

MQTT 5: açık reason code'lar

MQTT 5, CONNACK, PUBACK, SUBACK ve DISCONNECT paketlerine reason code ekledi; bu da kota sorunlarını istemci tarafından görülebilir hale getirir. En sık karşılaşacağınız kodlar OASIS MQTT 5.0 spesifikasyonunda tanımlanmıştır:

ConnectMQ, 0x97 quota exceeded dahil MQTT 5 reason code'larını destekler; böylece MQTT 5 kullanan bir istemci belirsiz bir bağlantı kesilmesi yerine kesin bir nedeni loglayabilir. Bu tek başına yeni projelerde MQTT 5 kullanmak için güçlü bir nedendir; diğer avantajlar için MQTT 5 özellikleri yazısına bakın.

MQTT 5 broker'ları ayrıca Maximum Packet Size, Receive Maximum, Topic Alias Maximum ve Maximum QoS gibi CONNACK özellikleriyle limitlerini baştan bildirebilir. İyi yazılmış bir istemci bunları okur ve kendini uyarlar.

Kotaların İçinde Kalan İstemciler Tasarlamak

En iyi kota stratejisi, limite hiç yaklaşmayan bir istemcidir. Aşağıdaki uygulamalar kota kaynaklı olayların çoğunu önler.

Bağlantı anında broker'ın limitlerini okuyun

Aşağıdaki Python örneği paho-mqtt 2.x ile TLS üzerinden bağlanır, broker'ın bildirdiği limitleri yazdırır ve bağlantı kesildiğinde reason code'ları loglar.

import paho.mqtt.client as mqtt

LIMIT_PROPS = ("MaximumPacketSize", "ReceiveMaximum",
               "TopicAliasMaximum", "MaximumQoS", "SharedSubscriptionAvailable")

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print("connect refused:", reason_code)
        return
    print("connected")
    for name in LIMIT_PROPS:
        value = getattr(properties, name, None)
        if value is not None:
            print(f"  broker limit {name} = {value}")

def on_disconnect(client, userdata, flags, reason_code, properties):
    print("disconnected:", reason_code)
    if reason_code == "Quota exceeded":
        print("plan quota hit; back off and alert an operator")

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id="YOUR_CLIENT_ID", protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.reconnect_delay_set(min_delay=1, max_delay=120)
client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()

Önce hesap açmadan denemek isterseniz aynı betiği benzersiz bir client ID ile ve kimlik bilgisi olmadan 1883 portundaki ücretsiz public MQTT broker'a yönlendirin.

Yayınları istemci tarafında sınırlayın

Sizi yavaşlatması için asla broker'a güvenmeyin. Küçük bir token bucket ani yükleri kontrol altında tutar; bu, özellikle bir cihaz yeniden bağlanıp biriken verileri göndermeye çalıştığında önemlidir.

const mqtt = require("mqtt");

const client = mqtt.connect("mqtts://broker.connectmq.com:8883", {
  clientId: "YOUR_CLIENT_ID",
  username: "YOUR_USERNAME",
  password: "YOUR_PASSWORD",
  protocolVersion: 5,
  reconnectPeriod: 5000,
});

// Token bucket: saniyede en fazla RATE mesaj, en fazla BURST kadar ani yük.
const RATE = 5;
const BURST = 10;
let tokens = BURST;
setInterval(() => { tokens = Math.min(BURST, tokens + RATE); }, 1000);

const queue = [];
function enqueue(topic, payload) { queue.push({ topic, payload }); }

setInterval(() => {
  while (tokens >= 1 && queue.length > 0 && client.connected) {
    const { topic, payload } = queue.shift();
    client.publish(topic, payload, { qos: 1 });
    tokens -= 1;
  }
}, 100);

client.on("connect", () => console.log("connected"));
client.on("disconnect", (packet) => console.log("broker disconnect, reason", packet.reasonCode));

// Bir kesintinin ardından biriken verilerin gönderilmesini simüle et.
for (let i = 0; i < 50; i++) enqueue("factory/line1/temp", JSON.stringify({ i, c: 20 + Math.random() }));

Yeniden bağlanırken jitter ile geri çekilin

Bir saha bağlantısını kaybettiğinde yüzlerce cihaz aynı saniye içinde yeniden bağlanabilir. Rastgele bir geri çekilme (backoff) olmadan hepsi bağlantı hızı kotasına birlikte takılır, birlikte başarısız olur ve birlikte yeniden dener. Her yeniden bağlanma gecikmesine rastgele jitter ekleyin ve maksimum gecikmeyi bir iki dakikayla sınırlayın.

Client ID'leri benzersiz ve sabit tutun

ConnectMQ'da olduğu gibi client ID'leri verilen kimlik bilgilerine bağlayan managed broker'larda yinelenen client ID'ler yaygın bir tuzaktır. Tek bir kimlik bilgisi setini iki cihaza kopyalarsanız her bağlantı diğerini düşürür; MQTT 5 bunu 0x8E session taken over olarak bildirir. Sonuç sürekli kopup bağlanan bir bağlantıdır ve bağlantı hızı limitlerini hızla tüketir. Her cihaz veya hizmet için ayrı bir kimlik bilgisi seti oluşturun.

Küçük ölçümleri toplu gönderin

Tek bir JSON mesajındaki on sensör değeri, on yerine tek bir yayına mal olur. Toplu gönderim, paketin planınızın payload limitinin oldukça altında kalması koşuluyla mesaj hızlarını düşük tutar ve genellikle bant genişliğini azaltır.

Daha az sayıda, daha geniş abonelik kullanın

site1/+/telemetry gibi tek bir wildcard, düzinelerce birebir abonelikten daha kolay yönetilir ve sizi istemci başına abonelik sınırlarından uzak tutar.

Kota Hazırlık Kontrol Listesi

Yayına almadan önce her istemci türü için bu listeyi gözden geçirin:

1. Dashboard'lar, betikler ve entegrasyonlar dahil eşzamanlı bağlantıları sayın.

2. Yalnızca ortalamayı değil, istemci başına saniyedeki en yüksek yayın sayısını hesaplayın.

3. Biriken veri gönderimleri ve hata dökümleri dahil en büyük payload'u ölçün.

4. Her topic'in ihtiyaç duyduğu QoS seviyesini ve planın bunu desteklediğini doğrulayın.

5. Her cihazın kendi client ID'sine ve kimlik bilgilerine sahip olduğunu kontrol edin.

6. Yeniden bağlanmalar için jitter'lı üstel geri çekilme (exponential backoff) uygulayın.

7. MQTT 5 reason code'larını loglayın ve arama yapabileceğiniz bir yere gönderin.

8. Pay bırakın: büyümenin sizi şaşırtmaması için beklenen yükün yaklaşık iki katına göre planlayın.

9. ve 3. maddelerin arkasındaki boyutlandırma hesapları için saniyedeki MQTT mesajlarını tahmin etme yazısını okuyun. Giriş seviyesi seçenekleri karşılaştırıyorsanız ücretsiz MQTT broker planı rehberimiz kotaların ücretsiz planlar arasında nasıl farklılaştığını gösteriyor; bulut MQTT broker ana rehberi ise barındırma seçeneklerini daha geniş bir perspektiften ele alıyor.

Kota Sorunlarını Giderme

• Bağlantılar birkaç saniyede bir kopuyor: her şeyden önce yinelenen client ID'leri kontrol edin.
• Büyük mesajlar kayboluyor: payload boyutunu plan limitiyle ve broker'ın Maximum Packet Size özelliğiyle karşılaştırın.
• Abonelikler sessizce hiçbir şey almıyor: SUBACK reason code'larını inceleyin; bir hata kodu, filtrenin kabul edilmediği anlamına gelir.
• Saha genelindeki bir kesintiden sonra her şey başarısız oluyor: yeniden bağlanma mantığınızda jitter yok ve bağlantı hızı korumasına takılıyorsunuz.
• MQTT 3.1.1'de açıklanamayan bağlantı kesilmeleri: bir reason code almak için istemciyi geçici olarak MQTT 5'e geçirin.

Managed Bir MQTT Planıyla Başlayın

ConnectMQ, plan limitlerini açıkça yayımlar ve kota sorunlarını MQTT 5 reason code'larıyla bildirir; böylece ilk günden bu limitlere göre tasarım yapabilirsiniz. Kredi kartı gerekmeden app.connectmq.com adresinde ücretsiz Serverless planıyla başlayın, ardından cihaz filonuz büyüdükçe ücretli Serverless, Dedicated veya BYOC planlarına geçin. Altyapıyı tamamen başkasının işletmesini tercih ediyorsanız, tamamen yönetilen bir MQTT hizmeti yamaları, TLS'i ve kapasiteyi sizin yerinize yönetir.

Sık Sorulan Sorular

MQTT reason code 0x97 ne anlama gelir?

0x97, MQTT 5'te "Quota exceeded" anlamına gelir. Broker, istemciye bir uygulama veya plan limitine ulaşıldığını bildirir; bu nedenle istemci hemen yeniden denemek yerine geri çekilmelidir.

Dashboard'lar ve betikler bağlantı kotalarına dahil mi?

Evet. Açık bir oturum tutan her MQTT istemcisi, ister bir sensör, ister bir Node-RED akışı, ister bir tarayıcı sekmesi olsun, bir bağlantı olarak sayılır.

Broker'ımın kabul ettiği maksimum mesaj boyutunu nasıl öğrenirim?

Plan dokümantasyonunu kontrol edin ve MQTT 5 kullanıyorsanız CONNACK içindeki Maximum Packet Size özelliğini okuyun. ConnectMQ'nun ücretsiz Serverless planı 256 KB'a, ücretli Serverless planı ise 1 MB'a izin verir.

Cihazım neden sürekli bir döngü içinde yeniden bağlanıyor?

En yaygın neden, iki istemcinin aynı client ID'yi paylaşmasıdır; bu durumda broker her seferinde eski oturumu düşürür. Her cihaza kendi kimlik bilgilerini ve client ID'sini verin.