MQTT kontrol paketleri, istemcilerin ve broker'ların birbirleriyle değiş tokuş ettiği, CONNECT'ten AUTH'a uzanan 15 mesaj türüdür ve her MQTT etkileşimi bu paketlerden oluşur. Bu başvuru kaynağı her paketin ne yaptığını, kimin gönderdiğini, ilk baytından nasıl tanınacağını ve istemci debug loglarında nasıl göründüğünü açıklar; böylece broker ile yapılan bir konuşmayı adım adım izleyebilir ve sorunun tam olarak nerede çıktığını tespit edebilirsiniz.
Bir Bakışta MQTT Kontrol Paketleri
Paket türü, her paketin ilk baytının üst dört bitinde yer alır. MQTT 3.1.1, 1'den 14'e kadar olan türleri tanımlar; MQTT 5 ise 15 numaralı AUTH türünü ekler. Tür 0 ayrılmıştır ve hiçbir zaman geçerli değildir.
| Tür | Ad | Yön | İlk bayt | Amaç |
|---|---|---|---|---|
| 1 | CONNECT | İstemciden broker'a | 0x10 | Oturum açmak |
| 2 | CONNACK | Broker'dan istemciye | 0x20 | Bağlantıyı kabul etmek veya reddetmek |
| 3 | PUBLISH | Her iki yön | 0x30-0x3F | Uygulama mesajını iletmek |
| 4 | PUBACK | Her iki yön | 0x40 | QoS 1 publish'i onaylamak |
| 5 | PUBREC | Her iki yön | 0x50 | QoS 2 adım 1: publish alındı |
| 6 | PUBREL | Her iki yön | 0x62 | QoS 2 adım 2: serbest bırakma |
| 7 | PUBCOMP | Her iki yön | 0x70 | QoS 2 adım 3: tamamlandı |
| 8 | SUBSCRIBE | İstemciden broker'a | 0x82 | Abonelik istemek |
| 9 | SUBACK | Broker'dan istemciye | 0x90 | Abonelikleri onaylamak veya reddetmek |
| 10 | UNSUBSCRIBE | İstemciden broker'a | 0xA2 | Abonelikleri kaldırmak |
| 11 | UNSUBACK | Broker'dan istemciye | 0xB0 | Abonelikten çıkmayı onaylamak |
| 12 | PINGREQ | İstemciden broker'a | 0xC0 | Keep alive yoklaması |
| 13 | PINGRESP | Broker'dan istemciye | 0xD0 | Keep alive yanıtı |
| 14 | DISCONNECT | İstemciden broker'a (MQTT 5'te her iki yön) | 0xE0 | Bağlantıyı düzgün şekilde kapatmak |
| 15 | AUTH | Her iki yön (yalnızca MQTT 5) | 0xF0 | Gelişmiş kimlik doğrulama değişimi |
İlk baytı bilmek, ham bir hex dökümünü okurken işe yarar: 0xC0 0x00 bir PINGREQ'tir, 0x82 ise bir SUBSCRIBE'ı başlatır. Başlıkların ve payload'ların bayt düzeyindeki yapısı MQTT paket yapısı rehberinde ele alınıyor.
Kontrol Paketlerini Debug Logunda İzlemek
Bu paketleri görmenin en kolay yolu, Mosquitto istemcilerinin -d bayrağıdır. Herkese açık MQTT test broker'ına karşı:
mosquitto_sub -h broker.connectmq.com -p 1883 -i pkt-demo-e41f \
-t "connectmq/demo/e41f/#" -q 1 -k 10 -d
İkinci bir terminalde bir mesaj publish edin:
mosquitto_pub -h broker.connectmq.com -p 1883 -i pkt-pub-e41f \
-t "connectmq/demo/e41f/temp" -m "22.1" -q 1 -d
Subscriber'ın çıktısı buna benzer görünecektir:
Client pkt-demo-e41f sending CONNECT
Client pkt-demo-e41f received CONNACK (0)
Client pkt-demo-e41f sending SUBSCRIBE (Mid: 1, Topic: connectmq/demo/e41f/#, QoS: 1, Options: 0x00)
Client pkt-demo-e41f received SUBACK
Subscribed (mid: 1): 1
Client pkt-demo-e41f received PUBLISH (d0, q1, r0, m1, 'connectmq/demo/e41f/temp', ... (4 bytes))
Client pkt-demo-e41f sending PUBACK (m1, rc0)
22.1
Client pkt-demo-e41f sending PINGREQ
Client pkt-demo-e41f received PINGRESP
-k 10 keep alive değeri, on saniyelik boşta kalma süresinin ardından PINGREQ'in görünmesini sağlar. PUBLISH satırındaki d0, q1, r0, m1 ifadesi DUP 0, QoS 1, retain 0 ve mesaj kimliği 1 anlamına gelir. Paho Python, client.enable_logger() ile benzer satırlar yazdırır; MQTT.js ise bunu DEBUG=mqttjs* ortam değişkeniyle yapar.
Bağlantı Paketleri: CONNECT, CONNACK, DISCONNECT
CONNECT, bir istemcinin gönderdiği ilk pakettir. Protokol sürümünü, clean session veya clean start bayrağını, keep alive değerini, client ID'yi, isteğe bağlı Last Will mesajını ve isteğe bağlı kullanıcı adı ile parolayı taşır. MQTT 5'te ayrıca Session Expiry Interval, Receive Maximum ve Topic Alias Maximum gibi özellikleri (property) de taşır. Aynı bağlantı üzerinden ikinci bir CONNECT göndermek protokol hatasıdır.
CONNACK, broker'ın yanıtıdır. Session Present bayrağını ve bir dönüş kodunu (3.1.1) veya reason code'u (MQTT 5) içerir. MQTT 5 broker'ları, CONNACK özelliklerini istemciye kendi sınırlarını bildirmek için de kullanır: Maximum QoS, Maximum Packet Size, Topic Alias Maximum, retain, wildcard veya paylaşımlı aboneliklerin kullanılıp kullanılamayacağı ve istemci boş bir kimlik gönderdiyse atanan client ID. Bir bağlantı başarısız olduğunda ilk bakılacak yer CONNACK'tir; ayrıntılar için MQTT CONNACK dönüş kodları yazısına göz atın.
DISCONNECT, bağlantıyı düzgün şekilde kapatır. Soketi kapatmadan önce DISCONNECT gönderen bir istemci, Last Will mesajının yayınlanmasını engeller (MQTT 5'te 0x04 reason code'u kullanıldığında hariç). MQTT 3.1.1'de DISCONNECT'i yalnızca istemci gönderir; MQTT 5'te broker da 0x8E Session taken over veya 0x97 Quota exceeded gibi nedenini açıklayan bir reason code ile DISCONNECT gönderebilir. Bir yeniden bağlanma döngüsü görüyorsanız broker'ın gönderdiği DISCONNECT paketlerine bakın; MQTT istemcisinin neden sürekli bağlantısının koptuğunu anlatan rehber olası nedenleri tek tek ele alıyor.
Yayınlama Paketleri: PUBLISH ve Onaylar
PUBLISH, uygulama mesajını her iki yönde de taşır: publish yaptığınızda istemciden broker'a, mesaj aldığınızda broker'dan istemciye. Sabit başlıktaki bayraklar DUP, QoS ve RETAIN değerlerini tutar.
Onaylar QoS seviyesine bağlıdır; bu konu MQTT QoS seviyeleri yazısında ayrıntılı olarak açıklanıyor:
| QoS | Paket akışı | Mesaj başına toplam paket |
|---|---|---|
| 0 | PUBLISH | 1 |
| 1 | PUBLISH, PUBACK | 2 |
| 2 | PUBLISH, PUBREC, PUBREL, PUBCOMP | 4 |
- PUBACK, bir QoS 1 mesajını onaylar. Bu paket gelene kadar gönderen taraf mesajı saklar ve yeniden bağlandıktan sonra DUP bayrağı ayarlanmış şekilde tekrar gönderebilir.
- PUBREC, alıcının QoS 2 için "mesaj bende" demesidir. Gönderen taraf artık mesajın payload'ını silebilir.
- PUBREL, alıcıya mesajı subscriber'lara iletebileceğini ve paket kimliğinin yakında yeniden kullanılabileceğini bildirir.
- PUBCOMP, QoS 2 değişimini sonlandırır.
Her atlamanın (hop) birbirinden bağımsız olduğunu unutmayın. Bir sensörden broker'a yapılan QoS 1 publish ile broker'dan bir subscriber'a yapılan QoS 2 teslimat ayrı değişimlerdir. MQTT 5'te bu onaylar reason code taşır; böylece PUBACK 0x10 No matching subscribers veya 0x87 Not authorized diyebilir.
Abonelik Paketleri: SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK
SUBSCRIBE, bir paket kimliği ve her biri istenen bir QoS değerine sahip bir veya daha fazla topic filtresi içerir. MQTT 5; No Local, Retain As Published ve Retain Handling gibi abonelik seçeneklerini ve isteğe bağlı bir Subscription Identifier'ı ekler.
SUBACK, her filtre için aynı sırayla bir kod döndürür. Her girdiyi okuyun: üç filtre içeren tek bir SUBSCRIBE, ikisi için başarılı olup biri için başarısız olabilir. 3.1.1'de başarısızlık değeri 0x80'dir; MQTT 5 ise 0x8F Topic Filter invalid veya 0x9E Shared Subscriptions not supported gibi özel nedenler verir.
UNSUBSCRIBE ve UNSUBACK, aboneliklerin kaldırılması için aynı yapıyı yansıtır. MQTT 5, UNSUBACK'e 0x11 No subscription existed dahil filtre başına reason code'lar ekler.
Keep Alive Paketleri: PINGREQ ve PINGRESP
PINGREQ ve PINGRESP, başka bir trafik akmadığında bağlantının canlı olduğunu kanıtlayan iki baytlık paketlerdir. İstemci, keep alive aralığı içinde hiçbir şey göndermediyse PINGREQ gönderir; broker da PINGRESP ile yanıt vermek zorundadır. Broker, keep alive süresinin 1,5 katı boyunca hiçbir şey duymazsa bağlantıyı kapatır. İstemci makul bir sürede PINGRESP almazsa bağlantıyı ölü kabul etmelidir. MQTT keep alive aralığı rehberi bu değerin nasıl seçileceğini açıklıyor.
AUTH: MQTT 5 ile Gelen Ekleme
AUTH, Authentication Method ve Authentication Data özellikleri aracılığıyla challenge-response mekanizmaları gibi gelişmiş kimlik doğrulamayı destekler. Çok adımlı değişimler için CONNECT'ten sonra kullanılır ve mevcut bir bağlantıda yeniden kimlik doğrulamayı da başlatabilir. Kullanıcı adı ve parola ile giriş dahil çoğu kurulum hiçbir zaman AUTH göndermez; bu nedenle gelişmiş bir yöntem yapılandırmadıysanız bir yakalamada AUTH görmeniz olağan dışıdır.
Pakete Göre Hata Ayıklama Kontrol Listesi
- CONNACK gelmiyor mu? Sorun MQTT'de değil; ağda, portta veya TLS'tedir.
- CONNACK sıfır dışında bir kod mu döndürüyor? Kimlik bilgileri, client ID veya protokol sürümü.
- SUBACK 0x80 veya daha yüksek mi? Hatalı filtre, yetki veya desteklenmeyen özellik.
- PUBLISH gönderildi ama PUBACK yok mu? QoS desteğini ve bağlantı durumunu kontrol edin.
- PINGRESP gelmeden tekrarlanan PINGREQ mi? Bağlantı yarı ölü; yeniden bağlanın.
- Broker'dan beklenmedik bir DISCONNECT mi? Reason code'unu okuyun.
ConnectMQ'da Her Paketi Görün
ConnectMQ MQTT 3.1.1 ve 5.0'ı destekler; böylece hem klasik paket akışını hem de MQTT 5 reason code'larını ve özelliklerini aynı broker üzerinde izleyebilirsiniz. Daha geniş bir bakış için bu paketlerle bir MQTT broker'ının ne yaptığını okuyun veya kapsamlı MQTT eğitimini takip edin.
ConnectMQ ile Geliştirin
Denemelerden cihazlara geçtiğinizde yönetilen bir MQTT broker TLS, kimlik bilgileri ve çalışma süresiyle sizin yerinize ilgilenir. app.connectmq.com adresinde kredi kartı gerektirmeden ücretsiz bir Serverless broker oluşturun, ardından hata ayıklarken portalın tarayıcı içi istemcisini ve canlı topic gezginini kullanın. Seçenekleri bulut MQTT broker pazarı rehberimizde de karşılaştırabilirsiniz.
Sık Sorulan Sorular
Kaç tane MQTT kontrol paketi türü vardır?
MQTT 5, 1'den 15'e kadar numaralandırılmış 15 kontrol paketi türü tanımlar. AUTH paketi MQTT 5 ile eklendiği için MQTT 3.1.1'de 14 tür vardır.
Bir QoS 2 mesajı hangi paketleri kullanır?
PUBLISH, PUBREC, PUBREL ve PUBCOMP. Dört adımlı el sıkışma, mesajın o gönderici ile alıcı arasında tam olarak bir kez teslim edilmesini sağlar.
Broker DISCONNECT paketi gönderebilir mi?
Yalnızca MQTT 5'te. MQTT 3.1.1'de broker ağ bağlantısını doğrudan kapatır; MQTT 5 ise önce bir reason code ile DISCONNECT göndermesine izin verir.
Loglarımda neden PINGREQ görüyorum?
PINGREQ, istemcinin keep alive yoklamasıdır ve istemci keep alive aralığı boyunca boşta kaldığında gönderilir. Düzenli PINGREQ ve PINGRESP çiftleri normaldir ve bağlantının sağlıklı olduğunu gösterir.
