อะไรคือข้อดีของ MQTT เมื่อเปรียบเทียบกับโปรโตคอล HTTP แบบเดิม

HTTP เป็นโปรโตคอลที่ใช้กันอย่างแพร่หลายและได้รับความนิยมมากที่สุด แต่ MQTT ได้รับความนิยมอย่างรวดเร็วในช่วงไม่กี่ปีที่ผ่านมา เมื่อพูดถึงการพัฒนา IoT นักพัฒนาจะต้องเลือกระหว่างสองสิ่งนี้

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

ยังมีข้อดีหลายประการของ MQTT ดังนี้:

1. โอเวอร์เฮดของโปรโตคอลต่ำ MQTT มีลักษณะเฉพาะตรงที่ส่วนหัวต่อข้อความสามารถสั้นได้ถึง 2 ไบต์ ทั้ง MQ และ HTTP มีค่าใช้จ่ายต่อข้อความที่สูงกว่ามาก เมื่อใช้ HTTP การสร้างการเชื่อมต่อ HTTP ใหม่สำหรับข้อความคำขอใหม่แต่ละรายการจะมีค่าใช้จ่ายจำนวนมาก การเชื่อมต่อแบบถาวรที่ใช้โดย MQ และ MQTT ช่วยลดค่าใช้จ่ายนี้ลงอย่างมาก

2. ความทนทานต่อเครือข่ายที่ไม่เสถียร MQTT และ MQ สามารถกู้คืนจากความล้มเหลว เช่น การขาดการเชื่อมต่อ และไม่มีข้อกำหนดโค้ดเพิ่มเติม อย่างไรก็ตาม HTTP ไม่สามารถดำเนินการนี้ได้ตามปกติ โดยกำหนดให้ไคลเอ็นต์ลองเข้ารหัสอีกครั้ง ซึ่งอาจเพิ่มปัญหาด้าน idempotence ได้

3. การใช้พลังงานต่ำ MQTT ได้รับการออกแบบมาเป็นพิเศษสำหรับการใช้พลังงานต่ำ HTTP ไม่ได้ออกแบบมาเพื่อคำนึงถึงสิ่งนี้ จึงทำให้สิ้นเปลืองพลังงานมากขึ้น

4. ไคลเอนต์ที่มีการเชื่อมต่อนับล้านบนสแต็ก HTTP การรักษาการเชื่อมต่อพร้อมกันหลายล้านรายการต้องใช้ความพยายามอย่างมากในการให้การสนับสนุน แม้ว่าการสนับสนุนนี้จะเป็นไปได้ แต่ผลิตภัณฑ์เชิงพาณิชย์ส่วนใหญ่ได้รับการปรับให้เหมาะสมเพื่อรองรับการเชื่อมต่อแบบถาวรตามลำดับความสำคัญนี้ IBM นำเสนอ IBM MessageSight ซึ่งเป็นเซิร์ฟเวอร์แบบติดตั้งบนชั้นวางเดียวที่ผ่านการทดสอบว่าสามารถรองรับอุปกรณ์ที่เชื่อมต่อพร้อมกันได้มากถึง 1 ล้านเครื่องผ่าน MQTT ในทางตรงกันข้าม MQTT ไม่ได้ออกแบบมาสำหรับไคลเอนต์จำนวนมากพร้อมกัน

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

ธุรกิจของเราอาจจำเป็นต้องส่งข้อมูลที่ละเอียดอ่อนโดยไม่ต้องมีคนกลางของบุคคลที่สาม ซึ่งจะลดค่าของโซลูชันเฉพาะระบบปฏิบัติการ (เช่น Apple iOS, การแจ้งเตือนของ Google Play) เป็นกลไกการขนส่งหลัก

HTTP อนุญาตเพียงวิธีเดียวที่เรียกว่า COMET โดยใช้คำขอ HTTP แบบถาวรเพื่อดำเนินการพุช วิธีการนี้มีราคาแพงจากทั้งมุมมองของไคลเอนต์และเซิร์ฟเวอร์ ทั้ง MQ และ MQTT รองรับการผลักดันเป็นคุณสมบัติพื้นฐานของทั้งสอง

6. ความแตกต่างของแพลตฟอร์มไคลเอ็นต์ ทั้งไคลเอ็นต์ HTTP และ MQTT ได้รับการปรับใช้บนแพลตฟอร์มจำนวนมาก ความเรียบง่ายของ MQTT ช่วยให้นำ MQTT ไปใช้กับไคลเอนต์เพิ่มเติมได้โดยใช้ความพยายามเพียงเล็กน้อย

7. ความทนทานต่อข้อผิดพลาดของไฟร์วอลล์ ไฟร์วอลล์ขององค์กรบางตัวจะจำกัดการเชื่อมต่อขาออกไปยังพอร์ตที่กำหนดบางพอร์ต โดยทั่วไปพอร์ตเหล่านี้จะถูกจำกัดไว้ที่ HTTP (พอร์ต 80), HTTPS (พอร์ต 443) ฯลฯ HTTP สามารถทำงานได้อย่างชัดเจนในสถานการณ์เหล่านี้ MQTT สามารถรวมเข้ากับการเชื่อมต่อ WebSockets ที่ปรากฏเป็นคำขออัปเกรด HTTP ได้ ซึ่งช่วยให้ดำเนินการได้ในกรณีเหล่านี้ MQTT ไม่อนุญาตรูปแบบนี้

เมื่อเทียบกับ HTTP โปรโตคอล MQTT รับประกันอัตราการถ่ายโอนที่สูง คุณภาพการบริการมีสามระดับ:

A. มากที่สุด: พยายามให้แน่ใจว่ามีการจัดส่ง

B. อย่างน้อยหนึ่งครั้ง: ตรวจสอบให้แน่ใจว่าได้ส่งอีเมลอย่างน้อยหนึ่งครั้ง แต่สามารถส่งข้อความได้มากกว่าหนึ่งครั้ง

C. เพียงครั้งเดียว: ตรวจสอบให้แน่ใจว่าอีกฝ่ายได้รับข้อความแต่ละข้อความเพียงครั้งเดียว

อันที่จริง MQTT มีการใช้กันอย่างแพร่หลาย คุณสามารถค้นหา MQTT ได้ในบริษัทฮาร์ดแวร์และอินเทอร์เน็ตขนาดใหญ่เกือบทุกแห่ง เช่น Facebook, BP, alibaba, baidu ฯลฯ

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

1. ไม่มี SDK ที่สมบูรณ์ และเทอร์มินัลที่ต่างกันต่างกันจำเป็นต้องมีแพ็คเกจ SDK ซอฟต์แวร์ที่เกี่ยวข้องเพื่อสื่อสารกับเซิร์ฟเวอร์ MQTT ตัวอย่างเช่น เพื่อให้เกิดการเชื่อมต่อระหว่าง MCU, Linux, Android, IOS, WEB ฯลฯ จะต้องจำเป็นต้องมีแพ็คเกจ SDK ที่แตกต่างกัน

2. ไม่รองรับไฟล์และ AV ในบางสถานการณ์ของแอปพลิเคชัน ข้อมูลที่จะส่งอาจไม่จำกัดอยู่เพียงคำแนะนำ เช่น สัญญาณเสียงและสัญญาณวิดีโอ ซึ่งจำเป็นต้องสื่อสารผ่านไฟล์และ AV

3. ไม่รองรับการรวมเข้ากับ HTTP ของบุคคลที่สาม แม้ว่าh โปรโตคอล MQTT นั้นเหนือกว่าโปรโตคอล HTTP ทั่วไป โดยเว็บเซิร์ฟเวอร์ที่ใช้โปรโตคอล HTTP แบบดั้งเดิมยังคงครองตลาดหลัก ดังนั้นเซิร์ฟเวอร์เหล่านี้จะต้องตระหนักถึงการเชื่อมต่อโครงข่ายกับโปรโตคอล MQTT เพื่อลดต้นทุนการอัพเกรดก็มีความสำคัญเช่นกัน
< br/>4. ไม่รองรับการปรับสมดุลโหลด เพื่อป้องกันการทำงานพร้อมกันสูงและการโจมตีที่เป็นอันตราย เซิร์ฟเวอร์การปรับสมดุลโหลดก็เป็นสิ่งจำเป็นเช่นกัน

5. ไม่รองรับอินเทอร์เฟซการจัดการผู้ใช้ เป็นสิ่งสำคัญอย่างยิ่งสำหรับผู้ใช้ในการวิเคราะห์ข้อมูลพฤติกรรมของอุปกรณ์ ซึ่งเป็นข้อกำหนดที่หลีกเลี่ยงไม่ได้ของอุตสาหกรรม 4.0 และยุคของข้อมูลขนาดใหญ่

6. ไม่รองรับข้อความออฟไลน์ และชดเชยปัญหาที่เซิร์ฟเวอร์ MQTT สูญเสียข้อมูลการควบคุมของอุปกรณ์หลังจากที่อุปกรณ์ออฟไลน์

7. ไม่รองรับการสื่อสารแบบจุดต่อจุด และใช้โปรโตคอล MQTT มาตรฐาน ตามทฤษฎีแล้ว การสื่อสารแบบจุดต่อจุดสามารถทำได้ผ่านการสมัครสมาชิกร่วมกัน แต่ตรรกะค่อนข้างซับซ้อน และมีข้อกังวลเกี่ยวกับความปลอดภัยของอุปกรณ์ เมื่ออุปกรณ์ B และอุปกรณ์ C อยู่ในหัวข้อเดียวกัน อุปกรณ์ A จะไม่ทราบว่าเป็นอุปกรณ์ B หรืออุปกรณ์ C ที่ส่งข้อความ และอาจเป็นไปได้ด้วยว่าข้อความนั้นถูกดักฟังโดยอุปกรณ์ D

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