MQTT TCP mi UDP mi? MQTT TCP üzerinde çalışır: ya doğrudan, ya TLS ile sarılmış olarak ya da kendisi de TCP üzerinde çalışan bir WebSocket bağlantısı içinde taşınarak. Bu yazı MQTT'nin neden TCP'nin garantilerine bağlı olduğunu, MQTT-SN gibi UDP tabanlı varyantların ve deneysel QUIC üzerinden MQTT'nin nereye oturduğunu ve bir bulut broker için güvenlik duvarınızda tam olarak hangi portları açmanız gerektiğini açıklıyor.
MQTT TCP mi UDP mi? Kısa Cevap
MQTT 3.1.1 ve 5.0 spesifikasyonları, sıralı, kayıpsız ve çift yönlü bir bayt akışı sağlayan bir alt taşıma gerektirir. TCP/IP tam olarak bunu sağlar; bu yüzden standart taşımadır. TCP üzerinde TLS ve TCP üzerinde WebSocket de bu özellikleri koruduğu için uygundur. Düz UDP bunları sağlamaz; bu yüzden standart MQTT hiçbir zaman doğrudan UDP üzerinde çalışmaz.
| Taşıma | Alttaki protokol | Tipik port | Standart MQTT mi? |
|---|---|---|---|
| TCP üzerinden MQTT | TCP | 1883 | Evet |
| TLS üzerinden MQTT | TCP üzerinde TLS | 8883 | Evet |
| WebSocket üzerinden MQTT | TCP üzerinde HTTP upgrade | 8083 (ws) |
Evet |
| Güvenli WebSocket üzerinden MQTT | TCP üzerinde TLS | 8084 (wss) |
Evet |
| MQTT-SN | UDP veya diğer datagram ağları | Gateway'e özgü | Ayrı protokol |
| QUIC üzerinden MQTT | UDP üzerinde QUIC | Broker'a özgü | OASIS standardının parçası değil |
MQTT Ağ Yığınında Nerede Durur
MQTT bir uygulama katmanı protokolüdür. Yığını yukarıdan aşağıya düşünün:
- Uygulama: sensör kodunuz, dashboard'unuz veya arka uç servisiniz.
- MQTT: CONNECT, PUBLISH, SUBSCRIBE ve onay paketleri.
- İsteğe bağlı WebSocket çerçeveleme: tarayıcılar ve bazı proxy'li ortamlar tarafından kullanılır.
- İsteğe bağlı TLS: şifreleme ve broker kimlik doğrulaması.
- TCP: yeniden iletim ve akış kontrolü ile güvenilir, sıralı teslimat.
- IP ve bağlantı katmanı: Wi-Fi, Ethernet, hücresel.
MQTT TCP'nin üzerinde durduğu için basit kalabilir. Sıralama için kendi sıra numaralarına ya da kaybolan segmentler için kendi yeniden iletim zamanlayıcılarına ihtiyaç duymaz; TCP bunu client ile broker arasında atlama atlama halleder.
MQTT Neden TCP'yi Seçti
Sıralama ve bütünlük
MQTT paketlerinin değişken uzunlukta bir başlığı vardır ve birden fazla TCP segmentine bölünebilir. Ayrıştırıcı, baytların eksiksiz ve sıralı gelmesini bekler. UDP ile paketler sırasız, yinelenmiş olarak gelebilir ya da hiç gelmeyebilir ve protokolün yeniden birleştirmeyi baştan icat etmesi gerekirdi.
Bağlantı durumu
MQTT bağlantı yönelimlidir. CONNECT/CONNACK alışverişi client'ın kimliğini doğrular ve broker açık bağlantıyı bir oturumla ilişkilendirir. Keep-alive, Last Will ve oturum devralma, TCP'nin sağladığı "bu bağlantı açık" veya "bu bağlantı koptu" kavramına dayanır.
QoS güvenilir bir bağlantı üzerine kurulur
QoS 1 ve 2, paket seviyesinde güvenilirlik değil, bağlantı arızaları boyunca ve client ile broker arasında garantiler ekler. Bağlantı ayaktayken güvenilir olduğunu varsayar ve yalnızca koptuğunda olanları ele alır. MQTT QoS seviyeleri rehberi bu akışları gösterir.
Güvenlik duvarları ve NAT
Bir cihaz tarafından dışarıya doğru başlatılan TCP bağlantıları, yönlendiriciler ve güvenlik duvarları tarafından iyi anlaşılır. Broker mesajları aynı bağlantı üzerinden geri itebilir; böylece cihazların hiçbir zaman açık bir gelen porta ihtiyacı olmaz.
TCP'nin Maliyetleri
TCP bedava değildir ve ödünleşimleri bilmek yerinde olur:
- Bağlantı kurulumu: TCP üç yönlü bir el sıkışma gerektirir ve TLS bunun üzerine kendi el sıkışmasını ekler. Uyanan, bağlanan, yayın yapan ve uyuyan cihazlar bunu her seferinde öder.
- Hat başı tıkanması (head-of-line blocking): Kaybolan bir segment, yeniden iletilene kadar aynı bağlantıda arkasındaki her şeyi geciktirir.
- Bellek: Bir TCP/IP yığını ve TLS kütüphanesi, en küçük mikrodenetleyicilerde bulunmayan RAM ve flash tüketir.
- Boşta kalma zaman aşımları: NAT cihazları boştaki TCP eşlemelerini düşürür; bu yüzden MQTT keep-alive süresi bu zaman aşımlarından kısa olmalıdır.
Çoğu Wi-Fi, Ethernet ve hücresel cihaz için bu maliyetler, özellikle bağlantılar saatlerce açık kaldığında, faydalarına kıyasla küçüktür. MQTT gecikme rehberi, etkiyi kendi ağınızda nasıl ölçeceğinizi gösterir.
UDP'nin Yeri: MQTT-SN
Zigbee düğümleri veya basit radyo ağlarındaki sensörler gibi TCP'si olmayan cihazlar için MQTT-SN (Sensör Ağları için MQTT) vardır. Yayınla/abone ol modelini korur ancak kompakt paketler, sayısal topic ID'ler ve uyuyan client desteği kullanır; UDP veya diğer datagram taşımaları üzerinde çalışır. MQTT-SN client'ları bir gateway ile konuşur; gateway onların trafiğini broker için TCP üzerinden normal MQTT'ye dönüştürür. Gateway kurulumu ve topic ID'ler için MQTT-SN açıklaması yazısını okuyun.
Önemli nokta şudur: MQTT-SN farklı bir kablo protokolüdür. Standart bir broker onu yalnızca bir gateway aracılığıyla kabul eder.
QUIC Üzerinden MQTT Ne Olacak?
QUIC, UDP üzerine kurulu modern bir taşımadır; TCP artı TLS'e göre daha hızlı bağlantı kurulumu ve daha az hat başı tıkanmasıyla güvenilir, şifreli akışlar sağlar. Bazı broker satıcıları MQTT'yi QUIC üzerinden taşımayı denedi; bu, sık sık ağ değiştiren mobil client'lara yardımcı olabilir. Bugün itibarıyla OASIS MQTT standardının parçası değildir, client kütüphanesi desteği sınırlıdır ve broker'ınız ile kütüphaneleriniz açıkça desteklemedikçe bir filoyu etrafında planlayacağınız bir şey değildir. Burada bile MQTT'nin güvenilir ve sıralı bir akış üzerinde durduğuna dikkat edin; QUIC bu akışı yalnızca UDP üzerinde sağlar.
Broker'ınız için Hangi Portlar Açılmalı
Her standart MQTT taşıması TCP olduğu için güvenlik duvarı kurallarının hepsi giden TCP'dir. broker.connectmq.com ve özel ConnectMQ broker'ları için:
- TLS üzerinden MQTT kullanan cihazlar, gateway'ler ve servisler için TCP 8883. İlk talep edilmesi gereken budur.
/mqttyolunda güvenli WebSocket kullanan tarayıcılar ve web uygulamaları için TCP 8084.- TCP 1883 yalnızca test veya izole ağlar için; şifresizdir.
- TCP 8083 yalnızca yerel WebSocket deneyleri için.
- Standart MQTT için hiçbir UDP portu gerekmez.
Ayrıntılar ve sorun giderme MQTT portları açıklaması yazısında.
Kendiniz Doğrulayın
MQTT'nin TCP olduğunu zaten sahip olduğunuz araçlarla doğrulayabilirsiniz. Önce TCP erişilebilirliğini kontrol edin:
nc -vz broker.connectmq.com 8883
Ardından genel MQTT test broker'ı üzerinde, TCP bağlantısı üzerinden gönderilen her MQTT paketini yazdıran hata ayıklama çıktısıyla TLS üzerinden bir MQTT oturumu açın:
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i tcp-check-62ab -t "connectmq/demo/62ab/#" -v -d
Çalışırken başka bir terminalden bağlantıyı listeleyin:
# Linux
ss -tnp | grep 8883
# macOS
netstat -an -p tcp | grep 8883
8883 portuna ESTABLISHED durumunda bir TCP bağlantısı ve her keep-alive aralığında hata ayıklama çıktısında PINGREQ ve PINGRESP göreceksiniz. Trafiği Wireshark ile yakalarsanız paketler önce TCP, sonra TLS olarak görünür; MQTT bunların içindedir.
Kodda taşıma seçimi yalnızca bir URL şemasıdır. MQTT.js'te mqtts://broker.connectmq.com:8883 TCP üzerinde TLS, wss://broker.connectmq.com:8084/mqtt ise TCP üzerinde güvenli WebSocket kullanır; kodunuzun geri kalanı aynıdır.
const mqtt = require("mqtt");
// Aynı MQTT oturum semantiği, TCP tabanlı iki taşıma
const url = process.env.USE_WSS
? "wss://broker.connectmq.com:8084/mqtt"
: "mqtts://broker.connectmq.com:8883";
const client = mqtt.connect(url, { clientId: "tcp-js-62ab", protocolVersion: 5 });
client.on("connect", () => {
console.log("Connected via", url);
client.publish("connectmq/demo/62ab/transport", url, { qos: 1 }, () => client.end());
});
Üretimde Dikkat Edilecekler
Genel broker'ın ötesine geçtiğinizde taşıma seçimi aynı kalır ama güvenlik sıkılaşır: Her yerde TLS, cihaz başına benzersiz kimlik bilgileri ve ağınıza göre ayarlanmış keep-alive. ConnectMQ gibi bir barındırılan MQTT broker, bir Let's Encrypt sertifikası hazır halde tam olarak bu TCP uç noktalarını sunar; böylece cihazlarınızın yalnızca 8883'e (ve web client'ları için 8084'e) giden erişime ihtiyacı olur. Protokolün tam bir anlatımı için MQTT eğitimi yazısına bakın.
ConnectMQ ile Başlayın
app.connectmq.com adresinde kredi kartı gerektirmeden ücretsiz bir Serverless broker oluşturun, ağınızda giden TCP 8883'ü açın ve oluşturulan kimlik bilgileriyle bağlanın. ConnectMQ'nun tarayıcı içi client'ı, herhangi bir cihazı devreye almadan önce bağlantıyı doğrulamanızı sağlar.
Sık Sorulan Sorular
MQTT TCP mi UDP mi?
Standart MQTT doğrudan ya da TLS veya WebSocket aracılığıyla TCP kullanır. UDP yalnızca ayrı bir protokol olan MQTT-SN ve deneysel QUIC üzerinden MQTT tarafından kullanılır.
Güç tasarrufu için MQTT'yi UDP üzerinden gönderebilir miyim?
Standart bir broker'a gönderemezsiniz. Bir gateway ile MQTT-SN kullanın ya da uzun ömürlü bir TCP bağlantısı tutun ve yalnızca değerler değiştiğinde yayın yapın.
WebSocket üzerinden MQTT hâlâ TCP kullanır mı?
Evet. WebSocket, TCP üzerinden bir HTTP isteği olarak başlar ve ardından MQTT paketlerini aynı TCP bağlantısı üzerinde taşır.
MQTT, OSI modelinin hangi katmanındadır?
MQTT, taşıma katmanında TCP'ye dayanan bir uygulama katmanı protokolüdür.
