ทำความรู้จักกับ MQTT และ CoAP โปรโทคอลสำหรับรับส่งข้อมูลบนเครือข่าย IoT
เนื่องจากผู้ใช้โซลูชัน IoT มักมีความคาดหวังว่าอุปกรณ์ IoT จะต้องมีขนาดเล็ก ราคาถูก แบตเตอรี่อยู่ได้นาน สามารถทำงานบนเครือข่ายที่มีข้อจำกัด ใช้ทรัพยากรบนเครือข่ายน้อยที่สุดเท่าที่จะเป็นไปได้ ด้วย Super Requirement บนทรัพยากรที่มีอยู่อย่างจำกัดจำเขี่ยที่ว่ามานี้จึงทำให้เกิดโปรโทคอลในการสื่อสารแบบใหม่ที่ถูกออกแบบมาให้ ‘Lightweight’ เหมาะสมที่จะนำไปใช้กับอุปกรณ์เซนเซอร์ขนาดที่มีหน่วยประมวลผลขนาดเล็กบนเครือข่ายที่ครอบคลุมในระยะไกล ใช้พลังงานต่ำและมีแบนด์วิธที่จำกัดมากๆ ท่ามกลางสงครามโปรโทคอลบนโลก IoT ที่เกิดขึ้นมากมาย ในบทความนี้เราจะกล่าวถึงโปรโทคอลที่ประสบความสำเร็จเนื่องจากได้รับความนิยมและถูกนำไปใช้อย่างแพร่หลายซึ่งได้แก่ MQTT และ CoAP นั่นเอง
MQTT (Message Queuing Telemetry Transport) เป็นโปรโทคอลที่ถูกออกแบบมาให้มีขนาดเล็กสำหรับการสื่อสารแบบ M2M ( Machine to Machine ) โดยถือกำเนิดจากวิศวกรจาก IBM และ Eurotech ในปี 1999 เพื่อนำไปใช้ในระบบ SCADA (Supervisory Control and Data Acquisition) สำหรับเชื่อมต่อท่อส่งน้ำมันบนเครือข่ายที่ไม่มีความเสถียรอย่างอินเตอร์เน็ตดาวเทียม ก่อนที่จะถูกบริจาคกลายเป็น Open Standard ในปี 2014 โดย OASIS
MQTT เป็นสถาปัตยกรรมแบบ Client/Server ซึ่งมี topology แบบ hub-and-spoke ค่ะ sensor ปลายทางจะทำหน้าที่เป็น client ซึ่งทำการสร้างเชื่อมต่อแบบ TCP ไปยัง Server ที่มีชื่อเรียกอีกชื่อว่า Broker ซึ่งมีหน้าที่เป็นเสมือนท่อส่งข้อมูลในการรับส่ง ‘Message’ ระหว่าง Client ที่เป็นได้ทั้ง Publisher และ Subscriberนั่นเอง
Client – หมายถึง Publisher หรือ Subscriber ที่เชื่อมต่อแบบรวมศูนย์ไปยัง Broker ซึ่งสามารถเชื่อมต่อได้ทั้งแบบ persistent ที่ทำการสร้าง session ค้างไว้เปิดตลอดเวลาเพื่อติดต่อกับ Broker ซึ่งตรงกันข้ามกับ client ที่เชื่อมต่อแบบ transient ซึ่ง Broker ไม่สามารถติดตามสถานะได้
Broker – เป็น software ที่ทำหน้ารับข้อความทั้งหมดที่ได้จาก Publisher แล้วจึงส่งต่อไปให้ Subscriber ตามแต่ Topic ที่ client ได้ทำการ subscribe ไว้
Topic – เป็นเหมือน address หรือ endpoint บน Broker ที่ client ทำการเชื่อมต่อเพื่อรับส่งข้อความระหว่างกันนั่นเอง
MQTT เป็นเหมือนสเปคของซอฟท์แวร์ที่มี API ไม่กี่ตัวในการเชื่อมต่อ client เข้าด้วยกัน จึงไม่สามารถใช้เป็นตัวกลางในการจัดเก็บและกระจายข้อมูล ( Store-and-Forward ) เหมือนเช่นในระบบ MoM (Message Oriented Middleware) ที่ทำหน้าที่ในการจัดการคิวในการกระจายข้อมูลในระบบที่ต้องการความน่าเชื่อถือและมีข้อความจำนวนมาก ดังนั้นจึงมีการนำ MQTT ไปประยุกต์ใช้ร่วมกับ MoM เช่น RabbitMQ หรือ Redis เพื่อให้สามารถใช้งานได้อย่างมีประสิทธิภาพในเชิงพาณิชย์
ข้อดีคือ MQTT คือเหมาะกับการนำไปใช้กับระบบคลาวด์ที่ให้บริการแบบรวมศูนย์เพราะถูกออกแบบให้เหมาะกับการกระจายข้อมูลแบบ many-to-many ตัวอย่างแอปพลิเคชันที่นำ MQTT ไปใช้อย่างแพร่หลายคงจะหนีไม่พ้น IoT Platform ที่มีอยู่ในท้องตลาดมากมาย แต่ก่อนหน้านี้ IoT Platform จะผุดขึ้นมาเป็นดอกเห็ด MQTT ก็ได้พิสูจน์ตัวเองโดยการถูกนำไปใช้กับ Facebook Messenger ด้วยเหตุนี้เองจึงทำให้เป็นตัวเลือกยอดนิยมในการให้บริการโซลูชันด้าน IoT บนคลาวด์ อีกทั้งยังเป็นมิตรกับ Network Engineer มากด้วยเนื่องจาก device สามารถทำการสร้าง session แลกเปลี่ยนข้อมูลกันได้โดยไม่ต้องทำการตั้งค่า NAT ให้วุ่นวาย อีกทั้งนักพัฒนาสามารถนำไปใช้กับร่วมกับ TLS/SSL เพื่อเพิ่มความปลอดภัยในการรับส่งข้อมูลได้ด้วย
แม้ MQTT จะถูกออกแบบมาให้มีขนาดเล็ก แต่ก็ยังมีข้อเสียสำหรับอุปกรณ์ที่มีทรัพยากรจำกัดเนื่องจาก clientทุกตัวต้องรองรับ TCP และทำการสร้างการเชื่อมต่อกับ broker ไว้ตลอดเวลา ซึ่งอาจเกิดปัญหาได้หากอยู่ในเครือข่ายที่ไม่เสถียร ( เน็ตหลุดบ่อยเป็นต้น)
CoAP (Constrained Application Protocol) เป็นมาตรฐานที่ถูกพัฒนาขึ้นมาใหม่โดย IETF ในปี 2014 โดยถูกออกแบบให้คล้ายกับ HTTP ซึ่งเป็น Document transfer protocol แต่มีขนาดเล็กกว่ามาก (มี header แบบคงที่ขนาด 4 byte) เพราะตัดส่วนที่ไม่จำเป็นทิ้งและรันบน UDP ซึ่งเป็น protocol ที่ไม่มีการสร้างการเชื่อมต่อระหว่างอุปกรณ์ปลายทาง จึงส่งข้อมูลได้เร็วมากแต่ไม่การันตีว่าข้อมูลจะถูกส่งไปยังปลายทางอย่างแน่นอนและถูกต้องตามลำดับ การส่งซ้ำและเรียงลำดับข้อมูลต้องไปทำบนระดับแอปพลิเคชัน
CoAP เป็นสถาปัตยกรรมแบบ Client/Server โดย client จะทำการร้องขอทรัพยากรไปที่ server โดยตรง จากนั้น server จะทำการตอบกลับคำร้องพร้อมกับออพชัน ‘Content-Type’ เพื่อว่าบอก client ว่ากำลังจะได้รับข้อมูลในรูปแบบไหนกลับไป (เช่น JSON, XML, CBOR เป็นต้น) โดย client สามารถ GET, PUT, POST และ DELETE ทรัพยากรบน Server ด้วย URL และ query string คล้ายกับ REST API ที่เราคุ้นเคยนั่นเอง
ในการสภาปัตยกรรมแบบ CoAP ที่มีการแลกเปลี่ยนทรัพยากรกันโดยตรง Sensor Node ทำหน้าที่เป็นทั้ง Server และ Client ในเวลาเดียวเพราะต้องทำการตอบรับ packets ที่ถูกส่งมาหา
ในมุมของนักพัฒนาแล้ว CoAP มีความคล้ายคลึงกับ HTTP มาก ซึ่งทำให้การดึงข้อมูลจากเซ็นเซอร์ไม่ต่างจากการดึงข้อมูลผ่าน Web API เท่าไหร่นัก บางคนอาจจะเปรียบ CoAP ได้ว่าเป็น REST API สำหรับ MCUนั่นเอง อีกทั้งยังเป็นโปรโทคอลที่มีความปลอดภัย เพราะมีการเข้ารหัสแบบ DTLS (เทียบเท่ากับ 3072-bit RSA key) ซึ่งสามารถรันบนอุปกรณ์ขนาดเล็กได้
CoAP เป็นโปรโทคอลใหม่ที่กำลังถูกพัฒนาอย่างต่อเนื่องแตกต่างจาก MQTT ที่เติบโตจนอยู่ในขั้นที่เสถียรแล้ว
CoAP ออกแบบมาสำหรับการแลกเปลี่ยนข้อมูลแบบ one-to-one เหมาะสำหรับแอปพลิเคชันแบบกระจายศูนย์ที่มีอุปกรณ์อยู่บนเครือข่ายเดียวกันสามารถติดต่อกันได้โดยตรง (ถ้าอยู่คนละเครือข่ายอาจต้องลำบากในการตั้งค่า NAT นั่นเอง) ตัวอย่างแอปพลิเคชันที่มีการนำ CoAP ไปใช้แพร่หลายคือระบบ Smart Home หรือระบบที่ต้องมีการควบคุมและสั่งงานโดยผู้ใช้เป็นต้น
จะเห็นได้ว่าแต่ละโปรโทคอลมีทั้งข้อดีและข้อเสียที่แตกต่างกัน สุดท้ายแล้วการตัดสินใจว่าจะนำแต่ละโปรโทคอลใดไปใช้ขึ้นอยู่กับสถานการณ์ สถาปัตยกรรมของระบบและข้อจำกัดทางด้านทรัพยากรทางด้านเครือข่ายของแต่ละคน เราจึงต้องเลือกเครื่องมือให้เหมาะสมกับงาน ในระบบที่มีความซับซ้อนมากๆ เราอาจจะประยุกต์ใช้พร้อมกันหลายๆ โปรโทคอลตามแต่ความเฉพาะเจาะจงของแอปพลิเคชันเพื่อให้บรรลุเป้าหมายในการทำงานได้อย่างมีประสิทธิภาพสูงสุดนั่นเอง
ที่มา:http://www.adslthailand.com/post/mqtt-coap-comparison-iot-protocol
