การพัฒนาเทคโนโลยีในด้านซอฟต์แวร์และฮาร์ดแวร์ การเกิดขึ้นของโปรโตคอลการสื่อสารใหม่ได้นำไปสู่การขยายตัวของ Internet of Things (IoT) จำนวนอุปกรณ์เพิ่มขึ้นทุกวันและกำลังสร้างข้อมูลจำนวนมหาศาล ดังนั้นจึงจำเป็นต้องมีสถาปัตยกรรมระบบที่สะดวกซึ่งสามารถประมวลผล จัดเก็บ และส่งข้อมูลนี้ได้
ปัจจุบันมีการใช้บริการคลาวด์เพื่อวัตถุประสงค์เหล่านี้ อย่างไรก็ตาม กระบวนทัศน์การประมวลผลหมอก (Fog) ที่ได้รับความนิยมเพิ่มมากขึ้นสามารถเสริมโซลูชันระบบคลาวด์โดยการปรับขนาดและเพิ่มประสิทธิภาพโครงสร้างพื้นฐาน IoT
คลาวด์สามารถครอบคลุมคำขอ IoT ส่วนใหญ่ได้ ตัวอย่างเช่น เพื่อจัดให้มีการตรวจสอบบริการ การประมวลผลข้อมูลจำนวนเท่าใดก็ได้ที่สร้างโดยอุปกรณ์อย่างรวดเร็ว ตลอดจนการแสดงภาพข้อมูล การประมวลผลหมอกมีประสิทธิภาพมากกว่าเมื่อแก้ไขปัญหาแบบเรียลไทม์ ให้การตอบสนองต่อคำขอที่รวดเร็วและมีเวลาแฝงน้อยที่สุดในการประมวลผลข้อมูล นั่นคือหมอกช่วยเสริม "เมฆ" และขยายขีดความสามารถของมัน
อย่างไรก็ตาม คำถามหลักนั้นแตกต่างออกไป: ทั้งหมดนี้ควรโต้ตอบอย่างไรในบริบทของ IoT โปรโตคอลการสื่อสารใดจะมีประสิทธิภาพมากที่สุดเมื่อทำงานในระบบ IoT-Fog-Cloud แบบรวม
แม้ว่า HTTP จะครอบงำอย่างเห็นได้ชัด แต่ก็มีโซลูชันอื่นๆ จำนวนมากที่ใช้ในระบบ IoT, Fog และ Cloud เนื่องจาก IoT ต้องรวมฟังก์ชันการทำงานของเซ็นเซอร์อุปกรณ์ต่างๆ เข้ากับความปลอดภัย ความเข้ากันได้ และข้อกำหนดอื่นๆ ของผู้ใช้
แต่ไม่มีแนวคิดเดียวเกี่ยวกับสถาปัตยกรรมอ้างอิงและมาตรฐานการสื่อสาร ดังนั้น การสร้างโปรโตคอลใหม่หรือแก้ไขโปรโตคอลที่มีอยู่สำหรับงาน IoT เฉพาะเจาะจงจึงเป็นหนึ่งในงานที่สำคัญที่สุดที่ชุมชนไอทีต้องเผชิญ
ปัจจุบันมีการใช้งานโปรโตคอลอะไรบ้างและสามารถเสนออะไรได้บ้าง? ลองคิดดูสิ แต่ก่อนอื่น เรามาพูดถึงหลักการของระบบนิเวศที่เมฆ หมอก และอินเทอร์เน็ตของสรรพสิ่งมีปฏิสัมพันธ์กัน
สถาปัตยกรรม IoT Fog-to-Cloud (F2C)
คุณอาจสังเกตเห็นว่ามีความพยายามมากเพียงใดในการสำรวจข้อดีและคุณประโยชน์ที่เกี่ยวข้องกับการจัดการ IoT ระบบคลาวด์ และหมอกที่ชาญฉลาดและประสานงานกัน ถ้าไม่เช่นนั้น ต่อไปนี้เป็นความคิดริเริ่มสามประการในการกำหนดมาตรฐาน: , и .
หากก่อนหน้านี้มีเพียง 2 ระดับเท่านั้นที่ได้รับการพิจารณา นั่นคือคลาวด์และอุปกรณ์ปลายทาง สถาปัตยกรรมที่เสนอจะแนะนำระดับใหม่ - การประมวลผลแบบหมอก ในกรณีนี้ ระดับหมอกสามารถแบ่งออกเป็นหลายระดับย่อย ขึ้นอยู่กับลักษณะเฉพาะของทรัพยากรหรือชุดนโยบายที่กำหนดการใช้อุปกรณ์ต่างๆ ในระดับย่อยเหล่านี้
สิ่งที่เป็นนามธรรมนี้อาจมีลักษณะเป็นอย่างไร นี่คือระบบนิเวศ IoT-Fog-Cloud ทั่วไป อุปกรณ์ IoT ส่งข้อมูลไปยังเซิร์ฟเวอร์และอุปกรณ์ประมวลผลที่เร็วขึ้นเพื่อแก้ไขปัญหาที่ต้องใช้เวลาแฝงต่ำ ในระบบเดียวกัน คลาวด์มีหน้าที่แก้ไขปัญหาที่ต้องใช้ทรัพยากรคอมพิวเตอร์หรือพื้นที่จัดเก็บข้อมูลจำนวนมาก
สมาร์ทโฟน นาฬิกาอัจฉริยะ และอุปกรณ์อื่นๆ ก็สามารถเป็นส่วนหนึ่งของ IoT ได้เช่นกัน แต่ตามกฎแล้วอุปกรณ์ดังกล่าวจะใช้โปรโตคอลการสื่อสารที่เป็นกรรมสิทธิ์ของนักพัฒนารายใหญ่ ข้อมูล IoT ที่สร้างขึ้นจะถูกถ่ายโอนไปยังชั้นหมอกผ่านโปรโตคอล REST HTTP ซึ่งให้ความยืดหยุ่นและความสามารถในการทำงานร่วมกันเมื่อสร้างบริการ RESTful นี่เป็นสิ่งสำคัญในแง่ของความจำเป็นในการรับรองความเข้ากันได้แบบย้อนหลังกับโครงสร้างพื้นฐานการประมวลผลที่มีอยู่ซึ่งทำงานบนเครื่องคอมพิวเตอร์ เซิร์ฟเวอร์ หรือคลัสเตอร์เซิร์ฟเวอร์ ทรัพยากรท้องถิ่นที่เรียกว่า "โหนดหมอก" จะกรองข้อมูลที่ได้รับและประมวลผลภายในเครื่องหรือส่งไปยังระบบคลาวด์เพื่อการคำนวณเพิ่มเติม
คลาวด์รองรับโปรโตคอลการสื่อสารที่แตกต่างกัน โดยทั่วไปคือ AMQP และ REST HTTP เนื่องจาก HTTP เป็นที่รู้จักและได้รับการปรับแต่งให้เหมาะกับอินเทอร์เน็ต คำถามจึงอาจเกิดขึ้น: “เราไม่ควรใช้มันเพื่อทำงานกับ IoT และ Fog หรือไม่?” อย่างไรก็ตาม โปรโตคอลนี้มีปัญหาด้านประสิทธิภาพ เพิ่มเติมเกี่ยวกับเรื่องนี้ในภายหลัง
โดยทั่วไปโปรโตคอลการสื่อสารจะมี 2 รุ่นที่เหมาะกับระบบที่เราต้องการ สิ่งเหล่านี้คือการตอบสนองคำขอและเผยแพร่และสมัครรับข้อมูล รุ่นแรกเป็นที่รู้จักอย่างกว้างขวางมากขึ้น โดยเฉพาะในสถาปัตยกรรมเซิร์ฟเวอร์ไคลเอ็นต์ ลูกค้าร้องขอข้อมูลจากเซิร์ฟเวอร์ และเซิร์ฟเวอร์ได้รับคำขอ ประมวลผล และส่งกลับข้อความตอบกลับ โปรโตคอล REST HTTP และ CoAP ทำงานบนโมเดลนี้
โมเดลที่สองเกิดขึ้นจากความจำเป็นในการจัดให้มีการเชื่อมต่อแบบอะซิงโครนัส กระจาย และหลวมระหว่างแหล่งข้อมูลที่สร้างข้อมูลและผู้รับข้อมูลนี้
แบบจำลองนี้ถือว่าผู้เข้าร่วมสามคน ได้แก่ ผู้จัดพิมพ์ (แหล่งข้อมูล) นายหน้า (ผู้จัดส่ง) และผู้สมัครสมาชิก (ผู้รับ) ที่นี่ ลูกค้าที่ทำหน้าที่เป็นสมาชิกไม่จำเป็นต้องขอข้อมูลจากเซิร์ฟเวอร์ แทนที่จะส่งคำขอ ระบบจะสมัครรับข้อมูลกิจกรรมบางอย่างในระบบผ่านนายหน้า ซึ่งมีหน้าที่กรองข้อความขาเข้าทั้งหมดและกำหนดเส้นทางระหว่างผู้เผยแพร่และสมาชิก และผู้จัดพิมพ์เมื่อเกิดเหตุการณ์เกี่ยวกับหัวข้อใดหัวข้อหนึ่ง จะเผยแพร่ไปยังนายหน้าซึ่งจะส่งข้อมูลในหัวข้อที่ร้องขอไปยังสมาชิก
โดยพื้นฐานแล้ว สถาปัตยกรรมนี้อิงตามเหตุการณ์ และโมเดลการโต้ตอบนี้น่าสนใจสำหรับแอปพลิเคชันใน IoT, คลาวด์, หมอก เนื่องจากความสามารถในการขยายขนาดและลดความซับซ้อนของการเชื่อมต่อระหว่างอุปกรณ์ต่าง ๆ รองรับการสื่อสารแบบหลายต่อหลายแบบไดนามิกและการสื่อสารแบบอะซิงโครนัส โปรโตคอลการส่งข้อความมาตรฐานที่เป็นที่รู้จักมากที่สุดบางส่วนซึ่งใช้รูปแบบการเผยแพร่และสมัครสมาชิก ได้แก่ MQTT, AMQP และ DDS
แน่นอนว่าโมเดลการเผยแพร่และสมัครสมาชิกมีข้อดีมากมาย:
- ผู้จัดพิมพ์และสมาชิกไม่จำเป็นต้องรู้เกี่ยวกับการมีอยู่ของกันและกัน
- สมาชิกรายหนึ่งสามารถรับข้อมูลจากสิ่งพิมพ์ต่างๆ มากมาย และผู้จัดพิมพ์รายหนึ่งสามารถส่งข้อมูลไปยังสมาชิกที่แตกต่างกันจำนวนมาก (หลักการแบบกลุ่มต่อกลุ่ม)
- ผู้เผยแพร่และผู้สมัครสมาชิกไม่จำเป็นต้องใช้งานในเวลาเดียวกันเพื่อสื่อสาร เนื่องจากนายหน้า (ทำงานเป็นระบบคิว) จะสามารถจัดเก็บข้อความสำหรับลูกค้าที่ไม่ได้เชื่อมต่อกับเครือข่ายในปัจจุบัน
อย่างไรก็ตาม โมเดลการตอบกลับคำขอก็มีจุดแข็งเช่นกัน ในกรณีที่ความสามารถของฝั่งเซิร์ฟเวอร์ในการจัดการคำขอของลูกค้าหลายรายการไม่เป็นปัญหา ก็สมเหตุสมผลที่จะใช้โซลูชันที่ได้รับการพิสูจน์แล้วและเชื่อถือได้
นอกจากนี้ยังมีโปรโตคอลที่รองรับทั้งสองรุ่น ตัวอย่างเช่น XMPP และ HTTP 2.0 ซึ่งรองรับตัวเลือก “server push” IETF ยังได้ออก CoAP ด้วย ในความพยายามที่จะแก้ไขปัญหาการส่งข้อความ ได้มีการสร้างวิธีแก้ปัญหาอื่นๆ หลายอย่าง เช่น โปรโตคอล WebSockets หรือการใช้โปรโตคอล HTTP บน QUIC (การเชื่อมต่ออินเทอร์เน็ต UDP ด่วน)
ในกรณีของ WebSockets แม้ว่าจะใช้เพื่อถ่ายโอนข้อมูลแบบเรียลไทม์จากเซิร์ฟเวอร์ไปยังเว็บไคลเอ็นต์และให้การเชื่อมต่อแบบถาวรด้วยการสื่อสารสองทิศทางพร้อมกัน แต่ก็ไม่ได้มีไว้สำหรับอุปกรณ์ที่มีทรัพยากรการประมวลผลที่จำกัด QUIC ยังสมควรได้รับความสนใจ เนื่องจากโปรโตคอลการขนส่งใหม่ให้โอกาสใหม่ๆ มากมาย แต่เนื่องจาก QUIC ยังไม่เป็นมาตรฐาน จึงยังเร็วเกินไปที่จะคาดการณ์การใช้งานที่เป็นไปได้และผลกระทบต่อโซลูชัน IoT ดังนั้นเราจึงคำนึงถึง WebSockets และ QUIC โดยคำนึงถึงอนาคต แต่เราจะไม่ศึกษารายละเอียดเพิ่มเติมในตอนนี้
ใครน่ารักที่สุดในโลก: เปรียบเทียบโปรโตคอล
ตอนนี้เรามาพูดถึงจุดแข็งและจุดอ่อนของโปรโตคอลกัน มองไปข้างหน้าให้เราจองทันทีว่าไม่มีผู้นำที่ชัดเจน แต่ละโปรโตคอลมีข้อดี/ข้อเสียบางประการ
เวลาตอบสนอง
ลักษณะที่สำคัญที่สุดประการหนึ่งของโปรโตคอลการสื่อสาร โดยเฉพาะอย่างยิ่งที่เกี่ยวข้องกับ Internet of Things คือเวลาตอบสนอง แต่ในบรรดาโปรโตคอลที่มีอยู่ ไม่มีผู้ชนะที่ชัดเจนซึ่งแสดงให้เห็นระดับเวลาแฝงขั้นต่ำเมื่อทำงานภายใต้เงื่อนไขที่แตกต่างกัน แต่มีการวิจัยและการเปรียบเทียบความสามารถของโปรโตคอลมากมาย
ตัวอย่างเช่น การเปรียบเทียบประสิทธิภาพของ HTTP และ MQTT เมื่อทำงานกับ IoT แสดงให้เห็นว่าเวลาตอบสนองสำหรับคำขอสำหรับ MQTT นั้นน้อยกว่า HTTP และเมื่อ ระยะเวลาไปกลับ (RTT) ของ MQTT และ CoAP เปิดเผยว่า RTT เฉลี่ยของ CoAP นั้นน้อยกว่า MQTT ถึง 20%
อื่น ๆ ด้วย RTT สำหรับโปรโตคอล MQTT และ CoAP ดำเนินการในสองสถานการณ์: เครือข่ายท้องถิ่นและเครือข่าย IoT ปรากฎว่า RTT เฉลี่ยสูงกว่า 2-3 เท่าในเครือข่าย IoT MQTT ที่ใช้ QoS0 แสดงผลลัพธ์ที่ต่ำกว่าเมื่อเทียบกับ CoAP และ MQTT ที่ใช้ QoS1 แสดง RTT ที่สูงกว่าเนื่องจาก ACK ที่เลเยอร์แอปพลิเคชันและการขนส่ง สำหรับระดับ QoS ที่แตกต่างกัน เวลาแฝงของเครือข่ายที่ไม่มีความแออัดคือมิลลิวินาทีสำหรับ MQTT และหลายร้อยไมโครวินาทีสำหรับ CoAP อย่างไรก็ตาม ควรจำไว้ว่าเมื่อทำงานบนเครือข่ายที่เชื่อถือได้น้อยกว่า MQTT ที่ทำงานบน TCP จะแสดงผลลัพธ์ที่แตกต่างไปจากเดิมอย่างสิ้นเชิง
เวลาตอบสนองสำหรับโปรโตคอล AMQP และ MQTT โดยการเพิ่มเพย์โหลดแสดงให้เห็นว่าด้วยโหลดที่ไม่มาก ระดับเวลาในการตอบสนองก็เกือบจะเท่ากัน แต่เมื่อถ่ายโอนข้อมูลจำนวนมาก MQTT จะแสดงเวลาตอบสนองที่สั้นลง ในอีกอันหนึ่ง CoAP ถูกเปรียบเทียบกับ HTTP ในสถานการณ์การสื่อสารระหว่างเครื่องกับอุปกรณ์ที่ติดตั้งบนยานพาหนะที่ติดตั้งเซ็นเซอร์ก๊าซ เซ็นเซอร์สภาพอากาศ เซ็นเซอร์ตำแหน่ง (GPS) และอินเทอร์เฟซเครือข่ายมือถือ (GPRS) เวลาที่ใช้ในการส่งข้อความ CoAP ผ่านเครือข่ายมือถือนั้นสั้นกว่าเวลาที่ใช้ข้อความ HTTP เกือบสามเท่า
มีการศึกษาที่เปรียบเทียบไม่ใช่สอง แต่มีสามโปรโตคอล ตัวอย่างเช่น, ประสิทธิภาพของโปรโตคอล IoT MQTT, DDS และ CoAP ในสถานการณ์การใช้งานทางการแพทย์โดยใช้โปรแกรมจำลองเครือข่าย DDS มีประสิทธิภาพเหนือกว่า MQTT ในแง่ของเวลาแฝงของการวัดและส่งข้อมูลทางไกลที่ได้รับการทดสอบภายใต้สภาพเครือข่ายที่ไม่ดีหลายประการ CoAP ที่ใช้ UDP ทำงานได้ดีสำหรับแอปพลิเคชันที่ต้องใช้เวลาตอบสนองที่รวดเร็ว อย่างไรก็ตาม เนื่องจากเป็นแบบ UDP จึงมีการสูญเสียแพ็กเก็ตที่คาดเดาไม่ได้อย่างมีนัยสำคัญ
แบนด์วิดท์
MQTT และ CoAP ในแง่ของประสิทธิภาพแบนด์วิธดำเนินการโดยการคำนวณจำนวนข้อมูลทั้งหมดที่ส่งต่อข้อความ CoAP แสดงปริมาณงานต่ำกว่า MQTT เมื่อส่งข้อความขนาดเล็ก แต่เมื่อเปรียบเทียบประสิทธิภาพของโปรโตคอลในแง่ของอัตราส่วนจำนวนไบต์ข้อมูลที่เป็นประโยชน์ต่อจำนวนไบต์ทั้งหมดที่ถ่ายโอน CoAP กลับกลายเป็นว่ามีประสิทธิภาพมากกว่า
ที่ การใช้ MQTT, DDS (โดยมี TCP เป็นโปรโตคอลการขนส่ง) และแบนด์วิดท์ CoAP พบว่าโดยทั่วไป CoAP แสดงการใช้แบนด์วิธที่ต่ำกว่าเมื่อเปรียบเทียบ ซึ่งไม่ได้เพิ่มขึ้นเมื่อแพ็กเก็ตเครือข่ายสูญหายหรือเวลาแฝงของเครือข่ายเพิ่มขึ้น ซึ่งแตกต่างจาก MQTT และ DDS ซึ่งมี การเพิ่มขึ้นของการใช้แบนด์วิธในสถานการณ์ดังกล่าว อีกสถานการณ์หนึ่งเกี่ยวข้องกับอุปกรณ์จำนวนมากที่ส่งข้อมูลพร้อมกัน ซึ่งเป็นเรื่องปกติในสภาพแวดล้อม IoT ผลการวิจัยพบว่าสำหรับการใช้งานที่สูงขึ้น ควรใช้ CoAP จะดีกว่า
ภายใต้ภาระที่เบา CoAP จะใช้แบนด์วิดท์น้อยที่สุด ตามด้วย MQTT และ REST HTTP อย่างไรก็ตาม เมื่อขนาดของเพย์โหลดเพิ่มขึ้น REST HTTP ก็ได้ผลลัพธ์ที่ดีที่สุด
การใช้พลังงาน
ปัญหาการใช้พลังงานมีความสำคัญอย่างยิ่งเสมอ โดยเฉพาะอย่างยิ่งในระบบ IoT ถ้า แม้ว่า MQTT และ HTTP จะใช้พลังงานไฟฟ้า แต่ HTTP จะสิ้นเปลืองพลังงานมากกว่ามาก และ CoAP ก็มากกว่านั้น เมื่อเทียบกับ MQTT ทำให้สามารถจัดการพลังงานได้ อย่างไรก็ตาม ในสถานการณ์ทั่วไป MQTT จะเหมาะสมกว่าสำหรับการแลกเปลี่ยนข้อมูลในเครือข่าย Internet of Things โดยเฉพาะอย่างยิ่งหากไม่มีข้อจำกัดด้านพลังงาน
การทดลองที่เปรียบเทียบความสามารถของ AMQP และ MQTT บนเครือข่ายมือถือหรือเครือข่ายไร้สายที่ไม่เสถียร พบว่า AMQP มีความสามารถด้านความปลอดภัยมากกว่า ในขณะที่ MQTT ประหยัดพลังงานมากกว่า
ความปลอดภัย
ความปลอดภัยเป็นอีกประเด็นสำคัญที่ถูกหยิบยกขึ้นมาเมื่อศึกษาหัวข้อ Internet of Things และการประมวลผลแบบหมอก/คลาวด์ โดยทั่วไปกลไกการรักษาความปลอดภัยจะขึ้นอยู่กับ TLS ใน HTTP, MQTT, AMQP และ XMPP หรือ DTLS ใน CoAP และรองรับ DDS ทั้งสองรูปแบบ
TLS และ DTLS เริ่มต้นด้วยกระบวนการสร้างการสื่อสารระหว่างฝั่งไคลเอ็นต์และเซิร์ฟเวอร์เพื่อแลกเปลี่ยนชุดการเข้ารหัสและคีย์ที่รองรับ ทั้งสองฝ่ายเจรจาชุดเพื่อให้แน่ใจว่าการสื่อสารเพิ่มเติมเกิดขึ้นบนช่องทางที่ปลอดภัย ความแตกต่างระหว่างทั้งสองอยู่ที่การปรับเปลี่ยนเล็กๆ น้อยๆ ที่ทำให้ DTLS ที่ใช้ UDP ทำงานผ่านการเชื่อมต่อที่ไม่น่าเชื่อถือ
ที่ การใช้งาน TLS และ DTLS ที่แตกต่างกันหลายประการพบว่า TLS ทำงานได้ดีกว่า การโจมตี DTLS ประสบความสำเร็จมากขึ้นเนื่องจากมีความทนทานต่อข้อผิดพลาด
อย่างไรก็ตาม ปัญหาใหญ่ที่สุดของโปรโตคอลเหล่านี้ก็คือ เดิมทีโปรโตคอลเหล่านี้ไม่ได้ออกแบบมาเพื่อใช้ใน IoT และไม่ได้ตั้งใจให้ทำงานในสายหมอกหรือเมฆ ด้วยการจับมือกัน พวกมันจะเพิ่มการรับส่งข้อมูลเพิ่มเติมในแต่ละการเชื่อมต่อ ซึ่งจะทำให้ทรัพยากรการประมวลผลหมดไป โดยเฉลี่ยแล้ว TLS และ DTLS มีค่าใช้จ่ายเพิ่มขึ้น 6,5% และ 11% เมื่อเทียบกับการสื่อสารที่ไม่มีชั้นความปลอดภัย ในสภาพแวดล้อมที่อุดมด้วยทรัพยากรซึ่งโดยทั่วไปจะตั้งอยู่บน ระดับนี้จะไม่เป็นปัญหา แต่ในการเชื่อมโยงระหว่าง IoT และระดับหมอก นี่กลายเป็นข้อจำกัดที่สำคัญ
จะเลือกอะไรดี? ไม่มีคำตอบที่ชัดเจน MQTT และ HTTP ดูเหมือนจะเป็นโปรโตคอลที่มีแนวโน้มมากที่สุด เนื่องจากถือว่ามีโซลูชัน IoT ที่เติบโตและมีเสถียรภาพมากกว่าเมื่อเปรียบเทียบกับโปรโตคอลอื่นๆ
โซลูชันที่ใช้โปรโตคอลการสื่อสารแบบครบวงจร
แนวทางปฏิบัติของโซลูชันโปรโตคอลเดียวมีข้อเสียหลายประการ ตัวอย่างเช่น โปรโตคอลที่เหมาะกับสภาพแวดล้อมที่จำกัดอาจไม่ทำงานในโดเมนที่มีข้อกำหนดด้านความปลอดภัยที่เข้มงวด ด้วยเหตุนี้ เราจึงทิ้งโซลูชันโปรโตคอลเดียวที่เป็นไปได้เกือบทั้งหมดในระบบนิเวศ Fog-to-Cloud ใน IoT ยกเว้น MQTT และ REST HTTP
REST HTTP เป็นโซลูชันโปรโตคอลเดียว
มีตัวอย่างที่ดีของการโต้ตอบคำขอและการตอบกลับ REST HTTP ในพื้นที่ IoT-to-Fog: . สัตว์เหล่านี้ได้รับการติดตั้งเซ็นเซอร์ที่สวมใส่ได้ (ไคลเอนต์ IoT, C) และควบคุมผ่านคอมพิวเตอร์คลาวด์โดยระบบการทำฟาร์มอัจฉริยะ (เซิร์ฟเวอร์ Fog, S)
ส่วนหัวของวิธีการ POST ระบุทรัพยากรที่จะแก้ไข (/farm/animals) รวมถึงเวอร์ชัน HTTP และประเภทเนื้อหา ซึ่งในกรณีนี้คือออบเจ็กต์ JSON ที่แสดงถึงฟาร์มเลี้ยงสัตว์ที่ระบบจะจัดการ (Dulcinea/วัว) . การตอบสนองจากเซิร์ฟเวอร์ระบุว่าคำขอสำเร็จโดยการส่งรหัสสถานะ HTTPS 201 (สร้างทรัพยากรแล้ว) เมธอด GET จะต้องระบุเฉพาะทรัพยากรที่ร้องขอใน URI (เช่น /farm/animals/1) ซึ่งส่งคืนการแสดง JSON ของสัตว์ด้วย ID นั้นจากเซิร์ฟเวอร์
วิธีการ PUT จะใช้เมื่อจำเป็นต้องอัปเดตบันทึกทรัพยากรเฉพาะบางอย่าง ในกรณีนี้ ทรัพยากรจะระบุ URI สำหรับพารามิเตอร์ที่จะเปลี่ยนแปลงและค่าปัจจุบัน (เช่น การระบุว่าวัวกำลังเดิน /farm/animals/1? state=walking) สุดท้ายนี้ วิธี DELETE ถูกใช้อย่างเท่าเทียมกันกับวิธี GET แต่จะลบทรัพยากรอันเป็นผลจากการดำเนินการเท่านั้น
MQTT เป็นโซลูชันโปรโตคอลเดียว
ลองใช้ฟาร์มอัจฉริยะแบบเดียวกัน แต่แทนที่จะใช้ REST HTTP เราใช้โปรโตคอล MQTT เซิร์ฟเวอร์ภายในที่ติดตั้งไลบรารี Mosquitto ทำหน้าที่เป็นนายหน้า ในตัวอย่างนี้ คอมพิวเตอร์ธรรมดา (เรียกว่าเซิร์ฟเวอร์ฟาร์ม) Raspberry Pi ทำหน้าที่เป็นไคลเอ็นต์ MQTT ซึ่งใช้งานผ่านการติดตั้งไลบรารี Paho MQTT ซึ่งเข้ากันได้กับโบรกเกอร์ Mosquitto โดยสมบูรณ์
ไคลเอนต์นี้สอดคล้องกับเลเยอร์นามธรรมของ IoT ซึ่งเป็นตัวแทนของอุปกรณ์ที่มีความสามารถในการรับรู้และการประมวลผล ในทางกลับกัน ผู้ไกล่เกลี่ยจะสอดคล้องกับระดับนามธรรมที่สูงกว่า ซึ่งแสดงถึงโหนดการประมวลผลแบบหมอกที่โดดเด่นด้วยความสามารถในการประมวลผลและการจัดเก็บที่มากขึ้น
ในสถานการณ์สมมติฟาร์มอัจฉริยะที่นำเสนอ Raspberry Pi เชื่อมต่อกับมาตรความเร่ง, GPS และเซ็นเซอร์อุณหภูมิ และเผยแพร่ข้อมูลจากเซ็นเซอร์เหล่านี้ไปยังโหนดหมอก ดังที่คุณคงทราบแล้ว MQTT ถือว่าหัวข้อเป็นลำดับชั้น ผู้เผยแพร่ MQTT รายเดียวสามารถเผยแพร่ข้อความไปยังชุดหัวข้อเฉพาะได้ ในกรณีของเรามีสามคน สำหรับเซ็นเซอร์ที่วัดอุณหภูมิในโรงเลี้ยงสัตว์ ลูกค้าจะเลือกธีม (ฟาร์มเลี้ยงสัตว์/โรงเรือน/อุณหภูมิ) สำหรับเซ็นเซอร์ที่วัดตำแหน่ง GPS และการเคลื่อนไหวของสัตว์ผ่านมาตรความเร่ง ลูกค้าจะเผยแพร่การอัปเดตไปยัง (ฟาร์มสัตว์/สัตว์/GPS) และ (ฟาร์มสัตว์/สัตว์/การเคลื่อนไหว)
ข้อมูลนี้จะถูกส่งต่อไปยังนายหน้าซึ่งสามารถจัดเก็บไว้ชั่วคราวในฐานข้อมูลท้องถิ่นได้ ในกรณีที่มีสมาชิกที่สนใจรายอื่นเข้ามาในภายหลัง
นอกเหนือจากเซิร์ฟเวอร์ในเครื่องซึ่งทำหน้าที่เป็นนายหน้า MQTT ท่ามกลางสายหมอก และที่ Raspberry Pis ซึ่งทำหน้าที่เป็นไคลเอนต์ MQTT ส่งข้อมูลเซ็นเซอร์ อาจมีนายหน้า MQTT อีกรายหนึ่งในระดับคลาวด์ ในกรณีนี้ ข้อมูลที่ส่งไปยังนายหน้าในพื้นที่สามารถจัดเก็บไว้ชั่วคราวในฐานข้อมูลท้องถิ่นและ/หรือส่งไปยังระบบคลาวด์ นายหน้า fog MQTT ในสถานการณ์นี้ใช้เพื่อเชื่อมโยงข้อมูลทั้งหมดกับนายหน้า MQTT บนคลาวด์ ด้วยสถาปัตยกรรมนี้ ผู้ใช้แอปพลิเคชันมือถือสามารถสมัครรับข้อมูลจากโบรกเกอร์ทั้งสองได้
หากการเชื่อมต่อกับโบรกเกอร์รายใดรายหนึ่ง (เช่น คลาวด์) ล้มเหลว ผู้ใช้จะได้รับข้อมูลจากอีกรายหนึ่ง (หมอก) นี่เป็นคุณลักษณะเฉพาะของระบบหมอกและคลาวด์คอมพิวติ้งที่รวมกัน ตามค่าเริ่มต้น แอปมือถือสามารถกำหนดค่าให้เชื่อมต่อกับโบรกเกอร์ MQTT ของหมอกก่อน และหากล้มเหลว ให้เชื่อมต่อกับโบรกเกอร์ MQTT บนคลาวด์ โซลูชันนี้เป็นเพียงหนึ่งในหลายระบบในระบบ IoT-F2C
โซลูชันหลายโปรโตคอล
โซลูชันโปรโตคอลเดี่ยวได้รับความนิยมเนื่องจากมีการใช้งานง่ายกว่า แต่เป็นที่ชัดเจนว่าในระบบ IoT-F2C เหมาะสมที่จะรวมโปรโตคอลที่แตกต่างกัน แนวคิดก็คือโปรโตคอลที่แตกต่างกันสามารถทำงานในระดับที่แตกต่างกันได้ ยกตัวอย่างเช่น สามสิ่งที่เป็นนามธรรม: เลเยอร์ของ IoT, หมอก และการประมวลผลแบบคลาวด์ อุปกรณ์ในระดับ IoT โดยทั่วไปถือว่ามีข้อจำกัด สำหรับภาพรวมนี้ ลองพิจารณาระดับ IoT ว่ามีข้อจำกัดมากที่สุด คลาวด์มีข้อจำกัดน้อยที่สุด และการประมวลผลหมอกเป็น "ตรงกลาง" ปรากฎว่าระหว่าง IoT และ Fog Abstractions โซลูชันโปรโตคอลในปัจจุบัน ได้แก่ MQTT, CoAP และ XMPP ในทางกลับกัน ระหว่างหมอกและเมฆ AMQP เป็นหนึ่งในโปรโตคอลหลักที่ใช้ร่วมกับ REST HTTP ซึ่งใช้ระหว่าง IoT และชั้นหมอกเนื่องจากความยืดหยุ่น
ปัญหาหลักที่นี่คือการทำงานร่วมกันของโปรโตคอลและความสะดวกในการถ่ายโอนข้อความจากโปรโตคอลหนึ่งไปยังอีกโปรโตคอลหนึ่ง ตามหลักการแล้ว ในอนาคต สถาปัตยกรรมของระบบ Internet of Things ที่มีทรัพยากรคลาวด์และหมอกจะไม่ขึ้นอยู่กับโปรโตคอลการสื่อสารที่ใช้ และจะรับประกันความสามารถในการทำงานร่วมกันที่ดีระหว่างโปรโตคอลต่างๆ
เนื่องจากปัจจุบันไม่เป็นเช่นนั้น จึงเหมาะสมที่จะรวมโปรโตคอลที่ไม่มีความแตกต่างที่มีนัยสำคัญ ด้วยเหตุนี้ โซลูชันหนึ่งที่เป็นไปได้จึงอิงจากการรวมกันของสองโปรโตคอลที่เป็นไปตามรูปแบบสถาปัตยกรรมเดียวกัน นั่นคือ REST HTTP และ CoAP โซลูชันที่นำเสนออีกวิธีหนึ่งใช้การผสมผสานระหว่างสองโปรโตคอลที่นำเสนอการสื่อสารแบบเผยแพร่และสมัครสมาชิก นั่นคือ MQTT และ AMQP การใช้แนวคิดที่คล้ายกัน (ทั้ง MQTT และ AMQP ใช้นายหน้า CoAP และ HTTP ใช้ REST) ทำให้ชุดค่าผสมเหล่านี้นำไปใช้ได้ง่ายขึ้นและต้องใช้ความพยายามในการบูรณาการน้อยลง
รูปที่ (a) แสดงแบบจำลองที่ตอบสนองต่อคำขอสองแบบ ได้แก่ HTTP และ CoAP และตำแหน่งที่เป็นไปได้ในโซลูชัน IoT-F2C เนื่องจาก HTTP เป็นหนึ่งในโปรโตคอลที่เป็นที่รู้จักและนำมาใช้มากที่สุดในเครือข่ายสมัยใหม่ จึงไม่น่าเป็นไปได้ที่โปรโตคอลการรับส่งข้อความอื่นๆ จะถูกแทนที่ด้วยโปรโตคอลนี้โดยสิ้นเชิง ในบรรดาโหนดที่เป็นตัวแทนของอุปกรณ์อันทรงพลังที่อยู่ระหว่างคลาวด์และหมอก REST HTTP เป็นโซลูชันที่ชาญฉลาด
ในทางกลับกัน สำหรับอุปกรณ์ที่มีทรัพยากรการประมวลผลจำกัดซึ่งสื่อสารระหว่างชั้น Fog และ IoT การใช้ CoAP จะมีประสิทธิภาพมากกว่า ข้อดีอย่างหนึ่งที่สำคัญของ CoAP ก็คือความเข้ากันได้กับ HTTP เนื่องจากทั้งสองโปรโตคอลใช้หลักการ REST
รูปที่ (b) แสดงโมเดลการสื่อสารสองแบบที่เผยแพร่และสมัครสมาชิกในสถานการณ์เดียวกัน รวมถึง MQTT และ AMQP แม้ว่าโปรโตคอลทั้งสองสามารถนำมาใช้ในการสื่อสารระหว่างโหนดในแต่ละเลเยอร์นามธรรมได้ตามสมมุติฐาน แต่ตำแหน่งของโหนดควรถูกกำหนดตามประสิทธิภาพ MQTT ได้รับการออกแบบให้เป็นโปรโตคอลน้ำหนักเบาสำหรับอุปกรณ์ที่มีทรัพยากรการประมวลผลจำกัด จึงสามารถใช้สำหรับการสื่อสาร IoT-Fog AMQP เหมาะสำหรับอุปกรณ์ที่มีประสิทธิภาพมากกว่า ซึ่งจะวางตำแหน่งระหว่างหมอกและโหนดคลาวด์อย่างเหมาะสม แทนที่จะเป็น MQTT สามารถใช้โปรโตคอล XMPP ใน IoT ได้เนื่องจากถือว่ามีน้ำหนักเบา แต่ไม่ได้ใช้กันอย่างแพร่หลายในสถานการณ์เช่นนี้
ผลการวิจัย
ไม่น่าเป็นไปได้ที่หนึ่งในโปรโตคอลที่กล่าวถึงจะเพียงพอที่จะครอบคลุมการสื่อสารทั้งหมดในระบบ ตั้งแต่อุปกรณ์ที่มีทรัพยากรการประมวลผลที่จำกัดไปจนถึงเซิร์ฟเวอร์คลาวด์ การศึกษาพบว่าสองตัวเลือกที่มีแนวโน้มมากที่สุดที่นักพัฒนาใช้มากที่สุดคือ MQTT และ RESTful HTTP โปรโตคอลทั้งสองนี้ไม่เพียงแต่มีความสมบูรณ์และเสถียรที่สุดเท่านั้น แต่ยังรวมถึงการใช้งานและแหล่งข้อมูลออนไลน์ที่มีการจัดทำเอกสารไว้เป็นอย่างดีและประสบความสำเร็จอีกด้วย
เนื่องจากความเสถียรและการกำหนดค่าที่เรียบง่าย MQTT จึงเป็นโปรโตคอลที่ได้รับการพิสูจน์ประสิทธิภาพที่เหนือกว่าเมื่อเวลาผ่านไปเมื่อใช้ในระดับ IoT กับอุปกรณ์ที่จำกัด ในบางส่วนของระบบที่การสื่อสารที่จำกัดและการใช้แบตเตอรี่ไม่เป็นปัญหา เช่น โดเมนหมอกบางส่วนและการประมวลผลบนคลาวด์ส่วนใหญ่ RESTful HTTP เป็นตัวเลือกที่ง่าย ควรคำนึงถึง CoAP เนื่องจากมีการพัฒนาอย่างรวดเร็วในฐานะมาตรฐานการส่งข้อความ IoT และมีแนวโน้มว่าจะมีระดับความเสถียรและวุฒิภาวะคล้ายกับ MQTT และ HTTP ในอนาคตอันใกล้นี้ แต่มาตรฐานกำลังพัฒนาอยู่ในขณะนี้ ซึ่งมาพร้อมกับปัญหาความเข้ากันได้ในระยะสั้น
คุณสามารถอ่านอะไรได้อีกในบล็อก
→
→
→
→
→
สมัครสมาชิกของเรา -channel เพื่อให้คุณไม่พลาดบทความถัดไป! เราเขียนไม่เกินสัปดาห์ละสองครั้งและเขียนเกี่ยวกับธุรกิจเท่านั้น
ที่มา: will.com