ประสิทธิภาพของ MQTT ผ่าน TLS เทียบกับ MQTT


10

ในขณะที่ MQTT นั้นค่อนข้างหลากหลาย แต่ก็ไม่ปลอดภัย นี่คือโดยการออกแบบ

สแตนฟอร์ด - คลาร์กกล่าวว่าการรักษาความปลอดภัยได้ถูกละทิ้งโปรโตคอลไว้ตั้งแต่แรกเพราะเขาและก้ามรู้ว่ากลไกความปลอดภัยนั้นถูกห่อหุ้มรอบ MQTT เพื่อเพิ่มความปลอดภัย นอกจากนี้ในเวลานั้น Stanford-Clark กล่าวว่าข้อมูลที่ส่งผ่าน MQTT เช่นข้อมูลความเร็วลมจากสถานีตรวจอากาศไม่ได้ต้องการความปลอดภัยเป็นพิเศษ - ที่มา

หนึ่งในกลไกความปลอดภัยที่สามารถล้อมรอบ MQTT คือ TLS โบรกเกอร์ส่วนใหญ่สนับสนุนในปัจจุบันนี้ แน่นอนว่ามาตรการห่อหุ้มจะทำให้เกิดค่าใช้จ่าย ค่าใช้จ่ายนี้อาจจะเล็กน้อย (cf. HiveMQ blog )

ขณะนี้ฉันกำลังมองหาข้อมูล (หวังว่าจะเป็นแหล่งข้อมูลที่เชื่อถือได้) เกี่ยวกับการสูญเสียประสิทธิภาพของ MQTT ผ่าน TLS และ MQTT ธรรมดาเพื่อประเมินความมีชีวิตของ MQTT สำหรับโครงการของฉัน โดยเฉพาะอย่างยิ่งเมื่อเทคโนโลยีปรับขนาดเป็นสมาชิกจำนวนมาก

มีวิธีอื่นนอกเหนือจากการสร้างต้นแบบเพื่อรับข้อมูลที่ถูกต้องเกี่ยวกับประสิทธิภาพของ MQTT ผ่าน TLS หรือไม่


1
ตรวจสอบคำตอบนี้ได้ที่ SO: stackoverflow.com/questions/1615882/…
Fraser

คำตอบ:


10

ฉันจะไม่คาดหวังที่แตกต่างกันจะมีความสำคัญมากเกินไปเมื่อการเชื่อมต่อการตั้งค่า

รายละเอียดของค่าใช้จ่ายที่ TLS ผลิตทั่วไปสามารถพบได้ที่นี่ บิตที่สำคัญคือ:

  • ค่าใช้จ่ายโดยรวมในการสร้างเซสชัน TLS ใหม่มีค่าเฉลี่ยประมาณ 6.5k ไบต์
  • ค่าใช้จ่ายโดยรวมเพื่อดำเนินการเซสชัน TLS ที่มีอยู่ต่อมาโดยเฉลี่ยประมาณ 330 ไบต์
  • ค่าใช้จ่ายทั้งหมดของข้อมูลที่เข้ารหัสมีค่าประมาณ 40 ไบต์ (20 + 15 + 5)
  • เป็นการง่ายที่จะแก้ไขการคำนวณข้างต้นเพื่อสะท้อนถึงความเฉพาะเจาะจงของสภาพแวดล้อมได้อย่างแม่นยำมากขึ้นดังนั้นสิ่งนี้จึงควรพิจารณาเป็นพื้นฐานสำหรับค่าใช้จ่าย TLS และไม่ใช่คำตอบที่เชื่อถือได้สำหรับคำถามที่วางไว้

มันควรค่าแก่การอ่านเพื่อดูว่าตัวเลขเหล่านี้ถูกคำนวณอย่างไร - คุณควรเข้าใจอย่างถ่องแท้ว่า TLS ทำงานอย่างไร ดังที่ระบุไว้ในคำตอบอื่น ๆ การส่งสัญญาณวิทยุน่าจะเป็นหนึ่งในการใช้พลังงานที่ยิ่งใหญ่ที่สุดซึ่งมักจะเป็นข้อ จำกัด ใน IoT ดังนั้นเมื่อมีการสร้างเซสชันค่าใช้จ่ายจะไม่สำคัญเกินไปโดยเฉพาะถ้าข้อความของคุณ ไม่สั้นนิดหน่อย

ตามที่ระบุไว้โดย HiveMQ ในบทความTLS มีผลต่อประสิทธิภาพการทำงานของ MQTT อย่างไร :

ข่าวดีก็คือว่าลูกค้า MQTT เพียงแค่ต้องสร้างการเชื่อมต่อหนึ่งครั้งต่อเซสชั่น - ในทางตรงกันข้ามกับโปรโตคอลเช่น HTTP ซึ่งจะต้องสร้างการเชื่อมต่อใหม่ในทุกคำขอ (ถ้าไม่มีการรักษาไว้ใช้หรือเทคนิคอื่น ๆ เช่นลอง มีการลงคะแนนเลือกตั้งแล้ว) เมื่อเชื่อมต่อกับนายหน้าลูกค้าสามารถส่งและรับข้อความโดยไม่มีการจับมือกันเพิ่มเติม การใช้ TLS ต้องจัดสรรบัฟเฟอร์เพิ่มเติมดังนั้นปริมาณการใช้ RAM จึงสูงขึ้นเล็กน้อยต่อการเชื่อมต่อ MQTT

พวกเขายังให้กราฟของการใช้งาน CPU บนนายหน้าเมื่อ 50,000 ลูกค้าเชื่อมต่อ:

รูปภาพของการใช้งาน CPU

แหล่งที่มาของรูปภาพ: HiveMQ (ดูบทความที่เชื่อมโยงด้านบน)

ทำบันทึกที่ว่านี้เป็นเกือบแน่นอนไม่ได้มีรูปแบบการใช้งานทั่วไป แต่ข้อมูลที่เป็นที่น่าสนใจ แต่อย่างไรก็ตาม อย่างที่คุณเห็นมีค่าใช้จ่ายจำนวนมากในขณะที่การจับมือกำลังดำเนินการอยู่ แต่หลังจากนั้นโอเวอร์เฮดของ CPU เกือบจะเหมือนกัน ฉันคาดหวังสิ่งที่คล้ายกันกับลูกค้า

ยังคงคำแนะนำทั่วไปที่นี่ถูกต้อง: มาตรฐานที่วางแผนไว้จะไม่ให้ข้อมูลที่คุณต้องการจริงๆ เพื่อทราบว่า TLS จะส่งผลต่อกรณีการใช้งานของคุณอย่างไรคุณต้องทดสอบใน ... กรณีการใช้งานของคุณ !


7

ไม่จริง ๆ แล้วคุณต้องทดสอบและกำหนดมาตรฐานสถานการณ์ของคุณ ต่อไปนี้น่าจะมีผลกระทบโดยตรงกับประสิทธิภาพ

  • คุณใช้ฮาร์ดแวร์ไคลเอนต์ / โบรคเกอร์มันมีการเร่งความเร็วฮาร์ดแวร์สำหรับ crypto หรือไม่?
  • ขนาดของเพย์โหลดที่คุณส่งมีขนาดเท่าใด
  • โปรไฟล์การเชื่อมต่อ / เชื่อมต่อใหม่สำหรับแอปพลิเคชันของคุณคืออะไร

4

การประเมินประสิทธิภาพที่มีประโยชน์นั้นยาก อาจเป็นไปได้ว่าแอปพลิเคชันของคุณจะต้องมีการเข้ารหัสสำหรับการรับส่งข้อมูลอย่างน้อยบางส่วนดังนั้นจึงไม่มีค่าใช้จ่ายในการดำเนินการใด ๆ ที่จะทำให้การรักษาความปลอดภัยพร้อมใช้งานสำหรับชุดย่อยของทราฟฟิก

สำหรับการใช้งานที่ จำกัด พลังงานการส่งสัญญาณมีแนวโน้มที่จะไร้สาย แม้ว่าจะมีช่องสัญญาณวิทยุที่เหมาะสม แต่ค่าใช้จ่ายด้านพลังงานในการตั้งค่าช่องสัญญาณและการต่อรองการเชื่อมต่อนั้นมีแนวโน้มที่จะมีค่าเกินกว่าค่าใช้จ่ายในการประมวลผลสำหรับการเข้ารหัสข้อความธรรมดา - โดยเฉพาะอย่างยิ่งถ้าบางข้อความต้องการการเข้ารหัส

ถ้าข้อความของคุณยังไม่น่ารำคาญอาจจะมีเหตุผลบางอย่างในการดำเนินการมากขึ้นในการประมวลผลที่ endpoint เพื่อลดการจราจรเครือข่าย

ในที่สุดในสถานการณ์ที่มีการโหลดช่องสัญญาณอย่างหนักประสิทธิภาพอาจไม่ดีเท่าที่คุณคาดหวังจากการวิเคราะห์การใช้งานระบบเล็กน้อยของคุณ

แม้ว่าคุณจะสามารถหาข้อมูลอ้างอิงสำหรับข้อมูลที่คุณต้องการได้ แต่ก็ไม่น่าจะตอบคำถามได้มากพอที่จะเพียงพอในการตัดสินใจออกแบบฐาน

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.