เหตุใด IoT จึงสนับสนุน MQTT

MQTT (Message Queuing Telemetry Transport) ในแง่มนุษย์หมายถึง Message Queuing Telemetry Transport เมื่อหลายปีก่อน เมื่อวิศวกรหลายคนแพร่หลายฝั่งพีซีไม่ได้ยินคำว่าวงเวียน แต่ด้วยการพัฒนาเทคโนโลยี Internet of Things (IoT) อย่างค่อยเป็นค่อยไป โปรโตคอลนี้ปรากฏบ่อยขึ้นเรื่อยๆ ในสายตาของวิศวกรรายใหญ่ ทำให้วิศวกรหลายคนรู้แค่ชื่อแต่ไม่รู้ความหมาย และหลายคนถึงกับคิดว่านี่เป็นโปรโตคอลประเภทหนึ่งที่พัฒนาขึ้นพร้อมกับการพัฒนา IoT ในความเป็นจริง โปรโตคอล MQTT ถูกประดิษฐ์ขึ้นครั้งแรกเมื่อกว่า 20 ปีที่แล้ว และในปี 1999 Andy Stanford Clark จาก IBM และ Alan Nippe จาก Cirrus Link ได้เขียนเวอร์ชันแรกของโปรโตคอล ตั้งแต่นั้นเป็นต้นมา โปรโตคอลดังกล่าวได้รับมาตรฐานระดับสากลในฐานะโปรโตคอลการรับส่งข้อความแบบเผยแพร่/สมัครสมาชิก-ภายใต้มาตรฐาน ISO (ISO/IEC PRF 20922) IBM ได้ส่งข้อกำหนด MQTT เวอร์ชัน 3.1 ไปยัง Structured Information Standards Facilitation Organisation ในปี 2013 พร้อมด้วยกฎบัตรเพื่อให้แน่ใจว่าสามารถเปลี่ยนแปลงข้อกำหนดได้เพียงเล็กน้อยเท่านั้น และตั้งแต่นั้นมา โปรโตคอล MQTT ก็ได้ถูก ใช้ในหลายๆ ช่องตั้งแต่นั้นเป็นต้นมา เมื่อโครงสร้างพื้นฐานทางเทคนิคของ IoT ได้รับการสรุปแล้ว โปรโตคอลโบราณนี้ก็เริ่มมีสปริงแรก

การขนส่งและเลเยอร์การใช้งานของเครือข่าย

ดังที่เราทุกคนทราบดีว่าการพัฒนาอย่างรวดเร็วของ Internet of Things ไม่สามารถละทิ้งโครงสร้างพื้นฐานเครือข่ายการสื่อสารได้ ตอนนี้คุณสามารถควบคุมมุมโลกใดก็ได้ในบ้านของสวิตช์ไฟในห้องหรือควบคุมทางอุตสาหกรรม คุณยังสามารถควบคุมการเคลื่อนไหวของหุ่นยนต์จากระยะไกลได้ ความสมบูรณ์ของเทคโนโลยีนี้จะขึ้นอยู่กับการสื่อสารผ่านเครือข่ายเป็นพื้นฐาน เทคโนโลยีหลักของเทคโนโลยีเครือข่ายในปัจจุบันคือโมเดล OSI เจ็ด-เลเยอร์ แน่นอนว่าแอปพลิเคชันจริงใช้โมเดลเครือข่าย TCP/IP สี่-เลเยอร์

TCP / IP สี่-โมเดลเครือข่ายเลเยอร์ของการขนส่งเลเยอร์ที่สามคือโปรโตคอล TCP / IP ที่มีชื่อเสียง เลเยอร์นี้ของจุดประสงค์หลักของโปรโตคอลใช้เพื่อส่งคอมพิวเตอร์บนเครือข่ายการส่งข้อมูลการสื่อสารไปยังที่อยู่ IP ที่ระบุของเครื่องอื่นด้านบน ตัวอย่างเช่น ที่อยู่ IP "192.168.137.19 ตัวอย่างเช่น ถ้าเครื่องที่มีที่อยู่ IP "192.168.137.19" ต้องการส่งแพ็กเก็ตไบนารี่ขนาด 16 ไบต์ไปยังเครื่องที่มีที่อยู่ IP "192.168.137.10" จากนั้นจึงสามารถใช้โปรโตคอล TCP/IP เพื่อส่งข้อมูลได้ เมื่อถ่ายโอนข้อมูลโดยใช้ TCP เรามักจะใช้ซ็อกเก็ตแทน

แต่เมื่อที่อยู่ IP ของเครื่อง "192.168.137.19" ส่งข้อมูลไปยังเครื่อง "192.168.137.10" แพ็กเก็ตนี้ของแพ็กเก็ต TCP ภายในข้อมูลนั้นแท้จริงแล้วในนามของความหมายของการสิ้นสุดการรับของที่อยู่ IP ของการสิ้นสุดการรับของเครื่อง "192.168.137.10" วิธีแยกวิเคราะห์แพ็กเก็ตข้อมูลนี้ปัญหานี้เหลืออยู่ที่เลเยอร์การขนส่งที่อยู่เหนือ เลเยอร์ของโปรโตคอลที่ต้องแก้ไขซึ่งเป็นโปรโตคอลเลเยอร์แอปพลิเคชัน แน่นอนหากโปรโตคอลของคุณไม่ต้องการให้เครือข่ายคอมพิวเตอร์ทั่วไปมีความละเอียดคุณสามารถไปพัฒนาโปรโตคอลเลเยอร์แอปพลิเคชันของตัวเองได้ซึ่งไม่สำคัญว่าจุดประสงค์ของเลเยอร์การขนส่งคือเพียงเพื่อส่งข้อมูลไปยังเครื่องเป้าหมายที่อยู่ด้านบนสุด

งานบันเทิงประจำวันของเรามักจะพบกับโปรโตคอลเลเยอร์แอปพลิเคชันที่หลากหลาย เช่น เมื่อคุณเปิดเว็บเพจรูปภาพจะแสดงในตำแหน่งนั้น ปุ่มชี้ลงคือ เพื่อให้บรรลุถึงฟังก์ชันใด ซึ่งเป็นไปตาม HTML HyperText Transfer Protocol (อังกฤษ: HyperTextTransferProtocol ตัวย่อ: HTTP) ที่ตกลงกันไว้ เพื่อให้แน่ใจว่าเมื่อมีการร้องขอหน้าในเว็บไซต์ของคุณโดยอุปกรณ์ใดๆ อุปกรณ์นั้นจะสามารถแสดงหน้าดังกล่าวได้อย่างเหมาะสม นอกเหนือจาก HTTP แล้ว ยังมีโปรโตคอลชั้นแอปพลิเคชันอื่นๆ อีกมากมาย เช่น DNS, FTP ฯลฯ และโปรโตคอล MQTT ซึ่งเป็นตัวเอกของเราในปัจจุบันก็เป็นหนึ่งในนั้น

เหตุใด IoT จึงสนับสนุน MQTT

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

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

ความยืดหยุ่นทำให้สามารถรองรับสถานการณ์การใช้งานที่หลากหลายสำหรับอุปกรณ์และบริการ IoT ได้

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

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

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

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

HTTP เป็นโปรโตคอลรุ่นเฮฟวี่เวทที่มีส่วนหัวและกฎมากมาย ไม่เหมาะสำหรับเครือข่ายที่มีข้อจำกัด

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

รูปแบบการสมัคร/เผยแพร่

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

ในโลกแห่งความเป็นจริง ฉันและคุณคล้ายกับมีอุปกรณ์ MQTT เชื่อมต่ออยู่กับเซิร์ฟเวอร์แบบรวม คุณสมัครรับข้อมูลจากเราโดยไม่สนใจหรือแสดงความรักต่อหมายเลขสาธารณะของเรา และเมื่อฉันส่งข้อความพุชทุกวัน คุณจะปรากฏในโทรศัพท์มือถือที่ฉันพุชข้อความ กระบวนการนี้ คุณได้รับข้อมูลของฉันในลักษณะที่เรียกว่า ในกระบวนการนี้ วิธีที่คุณได้รับข้อมูลของฉันเรียกว่า "สมัครสมาชิก" และพฤติกรรมการโพสต์ของฉันไปยังหมายเลขสาธารณะนี้คือ "การเผยแพร่" และทุกคนสามารถอ่านบทความของฉันได้ คุณสามารถฝากข้อความถึงฉันได้ตามใจชอบ พฤติกรรมนี้เป็นพฤติกรรม "เผยแพร่" ของทุกคน และฉันมักจะคอยผลักดันเพื่อดูข้อความของทุกคน นี่เป็นพฤติกรรม "สมัครสมาชิก" แบบหนึ่ง ในกระบวนการนี้ ข้อมูลภายนอกทั้งหมดไม่เกี่ยวข้องกับเรา เราเพียงสื่อสารกับการไหลของข้อมูลในสองทิศทาง กลไกการรับส่งข้อความใน MQTT ยังอิงตามโมเดลการสมัครสมาชิก Publish - กลไกการส่งข้อความ MQTT ยังขึ้นอยู่กับโมเดล "เผยแพร่" - "สมัครสมาชิก" อีกด้วย

ขั้นตอนเฉพาะของ MQTT คือ:

ขั้นตอนที่ 1:ใช้รายการแรกเพื่อรับเซิร์ฟเวอร์ MQTT จากนั้นสร้างผลิตภัณฑ์การสื่อสาร MQTT ใหม่

ขั้นตอนที่ 2:จากนั้นไปเชื่อมต่อกับเซิร์ฟเวอร์นี้ พารามิเตอร์ที่สำคัญสองตัวในการเชื่อมต่อกับเซิร์ฟเวอร์คือ หมายเลขโฮสต์ (ชื่อโดเมนหรือที่อยู่ IP) และหมายเลขพอร์ต

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

เมื่อทั้งสามขั้นตอนนี้เสร็จสิ้น คุณสามารถสมัครหรือโพสต์ข้อความในหัวข้อที่เกี่ยวข้องได้

ฉันจะรวบรวมเอกสารเพื่อแสดงวิธี "โสเภณี" แพลตฟอร์มการเข้าถึงแบบเปิดบนคลาวด์ของอุปกรณ์ China Mobile

สามขั้นตอนเหล่านี้ใช้ได้กับทั้งการพัฒนาซอฟต์แวร์แอปพลิเคชันและการพัฒนาไมโครคอนโทรลเลอร์ ในการพัฒนาไมโครคอนโทรลเลอร์ หากคุณใช้คำสั่ง AT และการสื่อสารโมดูล WIFI ภายนอก โมดูลทั่วไปจะมาพร้อมกับคำสั่ง AT + MQTT ซึ่งเป็นวิธีที่ดีที่สุดในการลดแรงกดดันต่อไมโครคอนโทรลเลอร์อย่างมาก หรือคุณสามารถเข้าถึงข้อมูลเลเยอร์การขนส่ง TCP/IP ได้โดยตรง จากนั้นแยกวิเคราะห์ MQTT ซึ่งกำหนดให้ผู้ใช้ต้องมีความเข้าใจอย่างลึกซึ้งเกี่ยวกับโปรโตคอล MQTT เพื่อแยกวิเคราะห์ข้อมูล Json ของตนเองด้วย ดังนั้นโดยทั่วไปเมื่อทำอุปกรณ์แบบฝัง โดยทั่วไปขอแนะนำให้เราใช้โมดูลสำเร็จรูป-โดยตรงกับโปรโตคอล MQTT การแยกวิเคราะห์คำสั่ง AT โดยตรงจะสะดวกกว่า

กรณีศึกษา:

การควบคุมระยะไกลของไฟและรับอุณหภูมิห้องปัจจุบัน

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

เพื่อให้การสื่อสารใช้งานได้ ขั้นแรกจะต้องเชื่อมต่อกับเซิร์ฟเวอร์ MQTT เดียวกัน

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

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