MQTT'nin TLS'ye kıyasla MQTT'ye karşı performansı


10

MQTT oldukça çok yönlü olmasına rağmen kendi başına da güvenli değildir. Bu tasarım gereğidir.

Stanford-Clark'a göre, güvenlik ilk başta bilinçli olarak protokolün dışında bırakıldı çünkü Nipper ile güvenlik mekanizmaları güvenliği artırmak için MQTT'nin etrafına sarılabileceğini biliyorlardı. Ayrıca, o zamanlar Stanford-Clark, bir hava istasyonundan rüzgar hızı verileri gibi MQTT aracılığıyla gönderilen bilgilerin özellikle güvenliğe ihtiyaç duymadığını söyledi. - Kaynak

MQTT'nin etrafına sarılabilen bu güvenlik mekanizmalarından biri TLS'dir. Günümüzde çoğu broker bunu desteklemektedir. Tabii ki herhangi bir sarma önlemi ek yük üretir. Bu ek yük ihmal edilebilir (bkz. HiveMQ blogu ).

Şu anda MQTT'nin projem için uygunluğunu değerlendirmek için MQTT'nin TLS'ye kıyasla düz MQTT'ye karşı performans kaybı hakkında bilgi (umarım yetkili bir kaynak) arıyorum. Özellikle teknoloji çok sayıda aboneye ölçeklendiğinde.

MQTT'nin TLS üzerinden performansı hakkında geçerli veri elde etmenin yanı sıra prototiplemenin bir yolu var mı?


1
SO üzerinde şu yanıtı kontrol edin: stackoverflow.com/questions/1615882/…
Fraser

Yanıtlar:


10

Bağlantı kurulduktan sonra farkın çok önemli olmasını beklemiyordum .

TLS'nin genel olarak ürettiği ek yükün dökümü burada bulunabilir . Önemli bitler:

  • Yeni bir TLS oturumu oluşturmak için toplam ek yük ortalama 6,5 ​​bin bayta geliyor
  • Mevcut bir TLS oturumuna devam etmek için gereken genel masraf ortalama 330 bayta ulaşıyor
  • Şifrelenmiş verilerin toplam yükü yaklaşık 40 bayttır (20 + 15 + 5)
  • Yukarıdaki hesaplamaları, bir ortamın özelliklerini daha kesin bir şekilde yansıtacak şekilde değiştirmek kolaydır, bu nedenle, sorulan sorunun yetkili cevabı için değil, TLS ek yükü için bir temel olarak düşünülmelidir.

Bu rakamların nasıl hesaplandığını görmek önemlidir - TLS'nin tüm bunlarla nasıl çalıştığını daha iyi anlamanız gerekir. Diğer cevaplarda belirtildiği gibi, radyo iletiminin muhtemelen IoT'de bir kısıtlama olan enerjinin en büyük kullanımlarından biri olması muhtemeldir, bu nedenle oturum bir kez kurulduktan sonra, özellikle mesajlarınız hiç de kısa değil.

HiveMQ tarafından makalede belirtildiği gibi TLS, MQTT performansını nasıl etkiler? :

İyi haber şu ki, bir MQTT istemcisinin her oturumda yalnızca bir kez bağlantı kurması gerekir - HTTP gibi protokollerin aksine, her istekte yeniden bağlantı kurması gerekir (canlı tutma yoksa veya Long gibi diğer teknikler) Yoklama yerinde). Aracıya bağlandıktan sonra, istemci herhangi bir ek el sıkışma yükü olmadan ileti gönderip alabilir. TLS kullanımının ek tamponlar tahsis etmesi gerekir, bu nedenle MQTT bağlantısı başına RAM tüketimi de biraz daha yüksektir.

Ayrıca , 50.000 istemci bağlandığında aracıda CPU kullanımının bir grafiğini sağlar :

CPU kullanımının görüntüsü

Görüntü Kaynağı: HiveMQ (yukarıdaki bağlantılı makaleye bakın)

Bu neredeyse kesin olduğunu not Do not tipik bir kullanım deseni, ancak veri yine de ilginç. Gördüğünüz gibi, el sıkışmaları devam ederken büyük bir ek yük var, ancak bundan sonra CPU ek yükü neredeyse aynı. İstemcide benzer bir şey beklerdim.

Yine de, buradaki genel tavsiye doğrudur: onaylanmış bir kıyaslama size gerçekten ihtiyacınız olan bilgileri vermeyecektir; TLS'nin kullanım durumunuzu nasıl etkileyeceğini bilmek için, onu kullanmanız gerekir ... kullanım durumunuz !


7

Gerçekten değil, hemen hemen özel durumunuzu test etmek ve karşılaştırmak zorunda kalacaksınız. Aşağıdakilerin performans üzerinde doğrudan bir etkisi olacaktır.

  • Hangi istemci / aracı donanımını kullanıyorsunuz, kripto için herhangi bir donanım hızlandırması var mı?
  • Gönderdiğiniz yükün boyutu nedir?
  • Uygulamanız için bağlantı / yeniden bağlanma profili nedir?

4

Yararlı performans tahminleri yapmak zordur. Uygulamanızın trafiğinin en azından bir kısmı için şifreleme gerektirmesi muhtemeldir, bu nedenle trafiğin bu alt kümesi için güvenliği sağlamak için herhangi bir uygulama maliyeti olması olası değildir.

Enerji kısıtlamalı bir uygulama için iletimin kablosuz olması muhtemeldir. Uygun bir radyo kanalıyla bile, kanalı kurma ve bağlantıyı müzakere etme enerji maliyeti, basit bir mesajı şifrelemek için işlem maliyetinden daha ağır basacaktır - özellikle de bazı mesajların şifrelemeye ihtiyacı varsa .

İletileriniz önemsiz değilse , ağ trafiğini azaltmak için uç noktada daha fazla işlem gerçekleştirmenin bazı gerekçeleri olabilir .

Son olarak, kanalın yoğun bir şekilde yüklendiği bir senaryoda, performans, tüm sisteminizin daha önemsiz bir uygulamasını analiz etmeyi beklediğiniz kadar iyi olmayabilir.

Aradığınız veriler için bir referans bulabilseniz bile, tasarım kararlarını dayandıracak kadar yeterli soruya cevap vermek olası değildir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.