MQTT Gecikme Süresi Açıklamalı: Gidiş-Dönüş Süresini Ne Etkiler ve Nasıl Ölçülür?

MQTT gecikme süresi (latency), bir yayıncının mesaj göndermesi ile bir abonenin onu alması arasında geçen süredir ve çoğu IoT sisteminde protokolün kendisi dışındaki etkenler tarafından belirlenir. Bu rehber gidiş-dönüş süresinin her bileşenini ayrıştırır, gerçekten önemli olan ayarları açıklar ve kendi ağınızdan canlı bir broker'a karşı gecikmeyi ölçmeniz için küçük bir Python betiği sunar.

MQTT'de "Gecikme" Ne Anlama Gelir

İnsanlar bu kelimeyi birkaç farklı ölçüm için kullanır; bu yüzden optimizasyona girişmeden önce net olun:

• Tek yönlü gecikme: yayıncıdan aboneye. İki saat farklı makinelerde olduğu için doğru ölçmek zordur.
• Gidiş-dönüş süresi (RTT): bir client kendisinin de abone olduğu bir topic'e yayın yapar ve mesajın geri gelmesinin ne kadar sürdüğünü ölçer. Tek saat olduğu için sayı güvenilirdir. Aşağıdaki betiğin ölçtüğü budur.
• Bağlanma gecikmesi: bir soket açmaktan CONNACK almaya kadar geçen süre. Uyanan, bağlanan, yayın yapan ve uyuyan cihazlar için önemlidir.
• Onay gecikmesi: QoS 1'de PUBLISH'ten PUBACK'e kadar geçen süre; broker'ın mesajın sorumluluğunu ne zaman üstlendiğini gösterir.

Bağlantıyı açık tutan cihazlar için (normal MQTT deseni) gidiş-dönüş süresi en kullanışlı tek sayıdır.

MQTT Gecikmesinin Bileşenleri

Bir sensörden dashboard'a giden mesaj birkaç aşamadan geçer. Her biri gecikme ekler:

Ağ mesafesi

Fiberdeki ışık hızlıdır ama anlık değildir ve gerçek rotalar düz çizgiler değildir. İstanbul'daki bir cihazın başka bir kıtadaki broker ile konuşması, kendi bölgesindeki bir broker ile konuşmasına göre her zaman daha yüksek bir taban gecikme görür. Hiçbir protokol ayarı bunu ortadan kaldıramaz; yalnızca broker'ın konumu kaldırabilir.

TLS ek yükü

TLS el sıkışması, bağlantı açılırken gidiş-dönüşler ekler. Sonrasında simetrik şifreleme modern CPU'larda çok az, ESP32 gibi çiplerde ise ılımlı bir maliyete sahiptir. MQTT client'ları normalde saatlerce veya günlerce bağlı kaldığı için TLS çoğunlukla kararlı durumdaki mesaj gecikmesini değil, bağlanma gecikmesini etkiler. Bu yüzden "TLS yavaş" nadiren 1883 portunu kullanmak için iyi bir gerekçedir; ödünleşimler için MQTT portları açıklaması yazısına bakın.

QoS seviyesi

En çok yanlış anlaşılan kısım budur. QoS 0'da broker hemen iletir. QoS 1'de de broker aldığı anda hemen iletir ve PUBACK paralel olarak geri döner; bu yüzden sağlıklı bir bağlantıda teslimat gecikmesi QoS 0'a benzer. QoS 2 dört adımlı bir el sıkışma ekler; broker uygulamasına bağlı olarak iletim birinci veya ikinci adımdan sonra gerçekleşebilir. Daha yüksek QoS'un asıl büyük etkisi verim üzerinde ve paket kaybı sırasında yaşananlar üzerindedir: Ağ sorun çıkardığında yeniden iletimler gecikme ekler. MQTT QoS seviyeleri rehberi akışları ayrıntılı olarak ele alır.

Nagle, tamponlama ve client döngüsü

Bazı yığınlar küçük yazmaları birleştirmek için geciktirir. Birçok MQTT kütüphanesi Nagle algoritmasını devre dışı bırakır, ancak gömülü yığınlar ve özel soketler bırakmayabilir. Mikrodenetleyicilerde client.loop() fonksiyonunu saniyede yalnızca bir kez çağıran bir ana döngü, ağ ne kadar hızlı olursa olsun gelen mesajlara bir saniyeye kadar gecikme ekler.

Keep-alive ve yeniden bağlanmalar

Keep-alive sağlıklı bir bağlantıda gecikmeyi etkilemez, ancak ölü bir bağlantının ne kadar hızlı tespit edileceğini belirler. 300 saniyelik keep-alive ile sessizce kopmuş bir bağlantı, client yeniden bağlanmadan önce dakikalar geçmesi anlamına gelebilir ve o aralıktaki her mesaj gecikir.

MQTT Gecikmesini Kendiniz Ölçün

Aşağıdaki betik broker.connectmq.com adresindeki genel MQTT test broker'ı'na bağlanır, benzersiz bir topic'e abone olur, bu topic'e zaman damgalı mesajlar yayınlar ve gidiş-dönüş istatistiklerini hesaplar. Saniyede iki mesaj göndererek genel broker'ın client başına saniyede 10 mesaj sınırının altında kalır.

# mqtt_rtt.py - MQTT gidiş-dönüş gecikmesini ölç
# pip install "paho-mqtt>=2.0"
import json
import statistics
import sys
import threading
import time
import uuid

import paho.mqtt.client as mqtt

HOST = "broker.connectmq.com"
USE_TLS = "--tls" in sys.argv
PORT = 8883 if USE_TLS else 1883
QOS = 1
SAMPLES = 50
INTERVAL = 0.5  # yayınlar arası saniye (2 msg/s)

run_id = uuid.uuid4().hex[:8]
topic = f"connectmq/demo/{run_id}/rtt"
rtts = []
subscribed = threading.Event()
done = threading.Event()


def on_connect(client, userdata, flags, reason_code, properties):
    print(f"Connected to {HOST}:{PORT} -> {reason_code}")
    client.subscribe(topic, qos=QOS)


def on_subscribe(client, userdata, mid, reason_code_list, properties):
    subscribed.set()


def on_message(client, userdata, msg):
    received = time.perf_counter()
    data = json.loads(msg.payload)
    rtts.append((received - data["t"]) * 1000.0)
    if len(rtts) >= SAMPLES:
        done.set()


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"rtt-{run_id}")
client.on_connect = on_connect
client.on_subscribe = on_subscribe
client.on_message = on_message
if USE_TLS:
    client.tls_set()  # sistem CA deposunu kullanır

t0 = time.perf_counter()
client.connect(HOST, PORT, keepalive=60)
client.loop_start()
if not subscribed.wait(10):
    sys.exit("Subscribe timed out")
print(f"Connect + subscribe took {(time.perf_counter() - t0) * 1000:.1f} ms")

for seq in range(SAMPLES):
    payload = json.dumps({"seq": seq, "t": time.perf_counter()})
    client.publish(topic, payload, qos=QOS)
    time.sleep(INTERVAL)

done.wait(10)
client.loop_stop()
client.disconnect()

if not rtts:
    sys.exit("No messages received")

rtts.sort()
p95 = rtts[int(len(rtts) * 0.95) - 1]
print(f"samples={len(rtts)} lost={SAMPLES - len(rtts)}")
print(f"min={rtts[0]:.1f} ms  median={statistics.median(rtts):.1f} ms  "
      f"p95={p95:.1f} ms  max={rtts[-1]:.1f} ms")

İki kez çalıştırın ve karşılaştırın:

python mqtt_rtt.py         # 1883 üzerinde düz TCP
python mqtt_rtt.py --tls   # 8883 üzerinde TLS

Sonuçları okumak

1. Minimum, en iyi durumdaki yolu yaklaşık olarak gösterir: Araya hiçbir şey girmeden ağ artı broker. Bu sizin tabanınızdır.
2. Medyan, kullanıcıların tipik olarak deneyimlediği değerdir.
3. p95 ve maksimum, Wi-Fi yeniden denemeleri, hücresel zamanlama veya tıkalı bağlantılardan kaynaklanan dalgalanmayı (jitter) ortaya çıkarır. Kontrol döngüleri ve alarmlar için bunlar medyandan daha önemlidir.
4. Connect + subscribe, TLS el sıkışma maliyetini gösterir. --tls ile belirgin şekilde daha yüksek olmasını beklerken mesaj başına medyanın düz TCP çalıştırmasına yakın kalmasını bekleyin.
5. QoS 1'deki kayıp örnekler genellikle betiğin geç gelen mesajlar ulaşmadan bittiği veya bağlantının koptuğu anlamına gelir. Konsolda bağlantı kopmalarını kontrol edin.

Testi yalnızca ofisinizden değil, cihazlarınızın gerçekten bulunduğu yerden (tesis ağı, hücresel modem, ev yönlendiricisi) çalıştırın. Aradaki fark genellikle en değerli bulgudur.

MQTT Gecikmesini Azaltmanın Pratik Yolları

1. Bağlantıları açık tutun. Bir kez bağlanın, çok kez yayın yapın. Her mesaj için yeniden bağlanmak her seferinde TCP ve TLS el sıkışmasının bedelini öder.
2. Cihazlarınıza yakın bir broker bölgesi seçin. Taban değeri mesafe belirler.
3. Veri türüne göre QoS seçin. Bir sonraki örneğin bir öncekinin yerini aldığı yüksek hızlı telemetri QoS 0 kullanabilir; komutlar ve alarmlar QoS 1'i hak eder.
4. Payload'ları kompakt tutun. Büyük JSON belgelerinin yavaş bağlantılarda gönderilmesi daha uzun sürer. Yüksek hızlı veriler için ikili kodlamaları ve tekrarlanan topic adlarını kısaltmak için MQTT 5 topic alias'larını düşünün.
5. Client döngüsüne sık hizmet verin. Arduino veya ESP32'de loop() fonksiyonunu her yinelemede çağırın ve bloklayan gecikmelerden kaçının.
6. Keep-alive'ı ayarlayın; ölü bağlantıları bant genişliğini israf etmeden hızla tespit edecek şekilde (30 ila 60 saniye yaygındır).
7. Gereksiz atlamalardan kaçının. Yoldaki her bridge, gateway veya Node-RED aktarıcısı kendi işleme ve kuyruklama süresini ekler.
8. Abone callback'lerini hızlı tutun. Ağ döngüsünün bloklanmaması için ağır işleri bir çalışan iş parçacığına veya kuyruğa devredin.

Yüksek veya Dalgalı Gecikmede Sorun Giderme

Ölçümden Üretime

Genel broker paylaşımlıdır; bu yüzden sayılarını bir kıyaslama (benchmark) olarak değil, ağ yolunuzun bir göstergesi olarak değerlendirin. Üretim trafiği için ConnectMQ gibi bir yönetilen MQTT broker, genel hız sınırları olmadan 8883 ve 8084 üzerinde özel ve kimliği doğrulanmış bir uç nokta sunar; plan ayrıntıları bulut MQTT broker rehberi içinde. Testi kendi ConnectMQ broker'ınıza karşı tekrarlamak için client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD") ekleyin, client ID'yi YOUR_CLIENT_ID olarak ayarlayın ve --tls ile çalıştırın. Daha geniş protokol arka planı için MQTT eğitimi ve MQTT nasıl çalışır yazılarına bakın.

ConnectMQ ile Başlayın

app.connectmq.com adresinde kredi kartı gerektirmeden ücretsiz bir Serverless broker oluşturun ve gecikme betiğini iki satırla ona yönlendirin. ConnectMQ'nun tarayıcı içi client'ı ve canlı topic gezgini, her mesajın tam olarak ne zaman geldiğini görmenize yardımcı olur.

Sık Sorulan Sorular

İyi bir MQTT gecikmesi ne kadardır?

Mesafeye ve erişim ağına bağlıdır. Minimum RTT'nizi broker ana bilgisayarına yapılan düz bir ağ ping'iyle karşılaştırın; MQTT bunun üzerine yalnızca biraz ekliyorsa darboğaz broker değildir.

QoS 1, MQTT'yi QoS 0'dan daha mı yavaş yapar?

Sağlıklı bir bağlantıda teslimat gecikmesi benzerdir, çünkü broker PUBACK tamamlanmadan önce iletir. QoS 1 esas olarak paketler kaybolup yeniden gönderilmesi gerektiğinde ek yük getirir.

TLS, MQTT gecikmesini artırır mı?

TLS bağlanırken el sıkışma süresi ekler, ancak uzun ömürlü bir bağlantıda mesaj başına ek yük küçüktür. Etkisini en aza indirmenin en iyi yolu bağlantıları açık tutmaktır.

Neden tek yönlü yerine gidiş-dönüş gecikmesi ölçülür?

Gidiş-dönüş tek bir saat kullanır; böylece yayıncı ve abone makinelerindeki senkronize olmayan saatlerden kaynaklanan hatalardan kaçınır.