MQTT Keep Alive Süresi: Doğru Değer Nasıl Seçilir?

MQTT keep alive süresi, bir istemcinin hiçbir zaman daha uzun süre sessiz kalmayacağına söz verdiği saniye sayısıdır ve broker'ın ölü bağlantıları tespit etmek için sahip olduğu temel araçtır. Bu rehberde PINGREQ, PINGRESP ve 1,5 kat zaman aşımı kuralının tam olarak nasıl çalıştığını, keep alive'ın NAT yönlendiricileri, hücresel bağlantılar ve pil ömrüyle nasıl etkileştiğini ve cihazlarınız için hangi değerlerle başlamanız gerektiğini öğreneceksiniz.

MQTT Keep Alive Süresi Aslında Ne Yapar?

Bir istemci CONNECT gönderdiğinde, saniye cinsinden ölçülen iki baytlık bir Keep Alive alanı ekler. Bu değer bir sözleşmedir: "Bu süre içinde sana en az bir kez herhangi bir kontrol paketi göndereceğim." PUBLISH, SUBSCRIBE veya PUBACK fark etmeksizin her paket sayılır. İstemci yalnızca gönderecek başka bir şeyi olmadığında küçük bir PINGREQ paketine başvurur ve broker da PINGRESP ile yanıt verir.

Keep alive'ın var olma nedeni, TCP'nin ölü karşı tarafları fark etmekte kendi başına kötü olmasıdır. Bir cihazın gücü kesilirse veya hücresel modemi ağdan düşerse hiçbir FIN ya da RST paketi gönderilmez. Broker'ın bakış açısından soket sonsuza kadar "açık" kalır ve cihazın Last Will and Testament mesajını bekleyen herhangi bir subscriber da sonsuza kadar bekler. Keep alive her iki tarafa da bir son tarih verir.

1,5 Kat Zaman Aşımı Kuralı

MQTT spesifikasyonu, broker'ın bir istemciden keep alive süresinin bir buçuk katı içinde hiçbir şey almaması durumunda, ağ bağlantısını başarısız olmuş gibi kapatması gerektiğini söyler. Bu şu anlama gelir:

İstemcinin de anlaşmada kendi payına düşen bir rol vardır. PINGREQ gönderip "makul bir süre" içinde PINGRESP alamazsa (çoğu kütüphane keep alive değerini veya sabit bir zaman aşımını kullanır), bağlantıyı kopmuş kabul edip yeniden bağlanmalıdır. İstemci kendi tarafındaki yarı açık bir soketi bu şekilde keşfeder.

Zaman Aşımı Tetiklendiğinde Ne Olur?

Broker bir bağlantıyı keep alive nedeniyle kapattığında bunu anormal bir bağlantı kesilmesi olarak değerlendirir. Pratik sonuçları:

1. İstemcinin will mesajı publish edilir (MQTT 5'te bir will gecikmesi ayarladıysanız bu gecikmeden sonra; bkz. MQTT will gecikme süresi).
2. İstemcinin kalıcı bir oturumu varsa broker aboneliklerini korur ve onun için QoS 1 ve QoS 2 mesajlarını kuyruğa almaya başlar.
3. Çevrimiçi durum topic'leri ve dashboard'lar "çevrimdışı" durumuna geçer.

Dolayısıyla keep alive, sisteminizin bir şeylerin ters gittiğini ne kadar hızlı öğreneceğini doğrudan kontrol eder.

MQTT Keep Alive Değerini Seçmek

Evrensel olarak doğru bir sayı yoktur. Tespit hızını trafik ve güç tüketimiyle takas edersiniz.

Tespit Hızı

Daha kısa bir aralık, broker'ın ve subscriber'ların arızaları daha hızlı öğrenmesi demektir. Bir operatör dashboard'unun bir makineyi yarım dakika içinde çevrimdışı göstermesi gerekiyorsa 60 saniyelik keep alive (90 saniyelik tespit) bu gereksinimi karşılamaz; 15 veya 20 saniye ise karşılar.

NAT ve Güvenlik Duvarı Boşta Kalma Zaman Aşımları

Ekiplerin çoğunun düştüğü tuzak budur. Ev yönlendiricileri, kurumsal güvenlik duvarları, bulut yük dengeleyicileri ve özellikle mobil operatör NAT gateway'leri, bir süre boşta kalan TCP eşlemelerini düşürür. Eşleme kaybolduğunda istemcinin bir sonraki paketi hiçbir yere ulaşmaz ve broker bunu ancak 1,5 katlık son tarihte fark eder. Keep alive süreniz yol üzerindeki en kısa NAT boşta kalma zaman aşımından uzunsa birkaç dakikada bir gizemli bağlantı kopmaları yaşarsınız. Operatör NAT zaman aşımları büyük farklılık gösterir ve her zaman belgelenmez; bu nedenle hücresel bağlantılarda birkaç dakikanın epey altında kalmak daha güvenlidir.

Pil ve Veri Kullanımı

Her PINGREQ/PINGRESP gidiş dönüşü, her yönde yalnızca 2 baytlık MQTT verisi artı TCP/IP (ve TLS kaydı) ek yüküdür. Wi-Fi'da bu önemsizdir. Pille çalışan hücresel bir cihazda ise maliyet çoğunlukla baytlardan değil, radyonun uyanmasından kaynaklanır: her ping, modemi saniyelerce yüksek güç durumunda tutabilir. Bu tür cihazlar için kalıcı bir bağlantıya gerçekten ihtiyaç olup olmadığını ya da uyanıp publish edip kalıcı bir oturumla bağlantıyı kesmenin daha iyi olup olmadığını değerlendirin.

Pratik Bir Başlangıç Noktası

• Wi-Fi veya Ethernet'teki şebeke beslemeli cihazlar: 60 saniye.
• WebSocket üzerinden dashboard'lar ve tarayıcı istemcileri: 30 saniye.
• Hücresel gateway'ler: 60 ila 120 saniye, açıklanamayan kopmalar görürseniz kısaltın.
• Aynı bulut bölgesindeki backend servisleri: 30 ila 60 saniye.
• Üretimde asla 0 kullanmayın; ölü bağlantı tespitini tamamen ortadan kaldırır.

Yaygın İstemcilerde Keep Alive Süresini Ayarlamak

Bunların hepsini broker.connectmq.com adresindeki herkese açık MQTT test broker'ında deneyebilirsiniz. Benzersiz bir client ID ve benzersiz bir topic öneki kullanın ve herkese açık alanın herkes tarafından okunabildiğini unutmayın.

mosquitto_sub ve mosquitto_pub

# PINGREQ/PINGRESP'i görebilmek için 30 saniyelik keep alive ve debug çıktısıyla abone olun
mosquitto_sub -h broker.connectmq.com -p 1883 -i ka-demo-7f3a \
  -k 30 -d -t 'connectmq/demo/7f3a/#'

-d ile topic sessizken her 30 saniyede bir Client ka-demo-7f3a sending PINGREQ ve received PINGRESP gibi satırlar görürsünüz.

Python (paho-mqtt 2.x)

import paho.mqtt.client as mqtt

def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe("connectmq/demo/7f3a/#", qos=1)

def on_disconnect(client, userdata, flags, reason_code, properties):
    print("Disconnected:", reason_code)

client = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id="ka-python-7f3a",
    protocol=mqtt.MQTTv5,
)
client.on_connect = on_connect
client.on_disconnect = on_disconnect

# keepalive üçüncü argümandır, saniye cinsinden
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()

paho, PINGREQ'i ağ döngüsünden otomatik olarak gönderir. Döngüyü bloke ederseniz (örneğin bir callback içinde uzun bir time.sleep ile) ping'ler durur ve broker sürenin 1,5 katından sonra bağlantınızı keser.

Node.js (MQTT.js v5)

const mqtt = require("mqtt");

const client = mqtt.connect("mqtts://broker.connectmq.com:8883", {
  clientId: "ka-node-7f3a",
  protocolVersion: 5,
  keepalive: 45,          // saniye
  reconnectPeriod: 5000,  // yeniden bağlanma denemeleri arasındaki ms
});

client.on("connect", () => console.log("connected"));
client.on("close", () => console.log("connection closed"));
client.on("error", (err) => console.error(err.message));

ESP32 (PubSubClient)

PubSubClient varsayılan olarak 15 saniye kullanır. connect() çağrısından önce client.setKeepAlive(60); ile değiştirin ve ping'ler yalnızca loop() içinden gönderildiği için sketch'inizde client.loop() fonksiyonunun sık çalıştığından emin olun. Uzun delay() çağrıları, ESP32 kartlarının düzenli aralıklarla bağlantıdan düşmesinin en yaygın nedenidir. İyi yapılandırılmış bir ESP32 sketch'i, bunu önlemek için millis() zamanlayıcılarıyla bloke etmeyen bir döngü kullanır.

MQTT 5'te Server Keep Alive

MQTT 5, broker'ın istemcinin isteğini geçersiz kılmasına izin verir. CONNACK bir Server Keep Alive özelliği içeriyorsa istemci kendi değeri yerine bu değeri kullanmak zorundadır. Broker'lar bunu, paylaşılan bir platformda minimum veya maksimum bir aralığı zorunlu kılmak için yapar. Çoğu kütüphane bunu sessizce uygular; bu nedenle ping'lerin yapılandırdığınızdan farklı bir hızda gönderildiğini fark ederseniz CONNACK özelliklerini loglayın. paho'da on_connect içinde properties değerini yazdırabilirsiniz; MQTT.js ise bunları connect olayına iletilen connack paketinde sunar.

Keep Alive Sorunlarını Gidermek

İstemcilerin şüpheli derecede düzenli aralıklarla bağlantısı koptuğunda bu kontrol listesini kullanın:

1. Aralığı ölçün. Kopmalar son etkinlikten keep alive süresinin yaklaşık 1,5 katı sonra oluyorsa istemci ping göndermiyordur. Bloke olmuş bir ağ döngüsü arayın.
2. Sabit bir boşta kalma düşüşü olup olmadığını kontrol edin. Kopmalar keep alive'dan bağımsız olarak sabit sayıda dakika sonra oluyorsa bir NAT veya güvenlik duvarı zaman aşımına uğruyordur. Aralığı bu değerin altına düşürün.
3. Yinelenen client ID'lere bakın. Aynı kimliğe sahip iki istemci birbirini bağlantıdan atar; bu bir keep alive sorunu gibi görünür ama değildir. Bkz. MQTT client ID en iyi uygulamaları.
4. Tek thread'li callback'lere dikkat edin. on_message içindeki ağır işler PINGREQ'i geciktirir. İşlemeyi bir worker thread'ine veya kuyruğa taşıyın.
5. TLS el sıkışmalarının tamamlandığını doğrulayın. Kısıtlı cihazlarda yavaş bir TLS yeniden bağlanması bir sonraki ping'i son tarihin ötesine itebilir.
6. Kütüphanenizde debug loglamayı etkinleştirin ve istemci zaman damgalarını broker bağlantı olaylarıyla karşılaştırın.

Bir ConnectMQ broker'ında, broker'ın bir istemciyi tam olarak ne zaman bağlı veya bağlantısı kesilmiş kabul ettiğini görmek için $SYS/broker/connection/{clientId}/state topic'ini de izleyebilirsiniz; bu, cihaz loglarınızla ilişkilendirmeyi kolaylaştırır. Portalın tarayıcı içi MQTT istemcisi, hiçbir şey kurmadan bu topic'e abone olmanın hızlı bir yoludur.

Keep Alive, Oturumlar ve Last Will'in Birlikte Çalışması

Keep alive, daha büyük bir güvenilirlik tasarımının bir parçasıdır. Makul bir üretim kalıbı şöyledir:

• NAT zaman aşımlarını aşacak ve tespit hedefinizi karşılayacak kadar kısa bir keep alive.
• Bağlanırken publish edilen retained bir "online" mesajı ve retained bir "offline" will mesajı.
• Cihaz yeniden bağlanırken publish edilen QoS 1 mesajlarının kaybolmaması için kalıcı bir oturum.
• Bir broker yeniden başlatmasının ani bir yük patlamasına (thundering herd) dönüşmemesi için yeniden bağlanmada üstel geri çekilme (exponential backoff).

Daha geniş bir bağlam istiyorsanız MQTT eğitimi bu yapı taşlarını en baştan ele alıyor.

ConnectMQ ile Başlayın

ConnectMQ, TCP, TLS, WebSocket ve güvenli WebSocket üzerinden MQTT 3.1.1 ve 5.0'ı destekleyen tamamen yönetilen bir MQTT servisidir; böylece herhangi bir keep alive stratejisini üretimde kullanacağınız uç noktaların aynısında test edebilirsiniz. Herkese açık test broker'ının ötesine geçmeye hazır olduğunuzda kredi kartı gerektirmeden ücretsiz bir Serverless broker oluşturun, oluşturulan kimlik bilgilerini kopyalayın ve bağlantı durumunu portalda canlı olarak izleyin. Hâlâ seçenekleri karşılaştırıyorsanız bulut MQTT broker seçme rehberimiz avantaj ve dezavantajları tek tek ele alıyor.

Sık Sorulan Sorular

İyi bir varsayılan MQTT keep alive süresi nedir?

60 saniye, şebeke beslemeli cihazların çoğu için iyi bir varsayılandır. Daha hızlı çevrimdışı tespiti gerekiyorsa veya yol üzerindeki bir NAT cihazı boştaki bağlantıları daha erken düşürüyorsa bu değeri 15 ila 30 saniyeye kısaltın.

Herhangi bir MQTT paketi keep alive zamanlayıcısını sıfırlar mı?

Evet. İstemcinin gönderdiği, PUBLISH ve PUBACK dahil her kontrol paketi etkinlik olarak sayılır. PINGREQ yalnızca istemci tüm aralık boyunca başka bir şekilde boşta kaldığında gönderilir.

Keep alive'ı 0 yaparsam ne olur?

Keep alive devre dışı kalır, yani broker sessiz bir bağlantıyı kendiliğinden hiçbir zaman kapatmaz. Ölü cihazlar süresiz olarak bağlı görünebilir ve will mesajları hiç gönderilmeyebilir; bu nedenle üretimde 0 kullanmaktan kaçının.

İstemcimin bağlantısı neden tam olarak her birkaç dakikada bir kopuyor?

Keep alive ayarınızdan bağımsız sabit bir aralık genellikle bir NAT veya güvenlik duvarı boşta kalma zaman aşımına işaret eder. Ping'lerin eşlemeyi canlı tutması için keep alive'ı bu zaman aşımının altına ayarlayın.

Broker keep alive değerimi değiştirebilir mi?

MQTT 5'te evet. Broker, CONNACK içinde bir Server Keep Alive özelliği döndürebilir ve istemci talep ettiği değer yerine bu değeri kullanmak zorundadır.