Deep dive: MQTT and Eclipse Mosquitto for drone and IoT systems

เอกสารฉบับนี้ต่อยอดจากประเด็นความปลอดภัยที่กล่าวไว้ในเอกสาร “เนื้อหาเจาะลึก: การประสานฝูงโดรนผ่านโครงข่าย LoRa Mesh Network” ซึ่งชี้ว่าในชั้นแอปพลิเคชัน (Application Layer) ของระบบฝูงโดรน “MQTT ที่ไม่เข้ารหัสเป็นช่องโหว่สำคัญ” เนื่องจากกรอบงานหุ่นยนต์อย่าง ROS ถูกออกแบบมาเพื่องานวิจัยเป็นหลัก ไม่ได้เน้นความปลอดภัยตั้งแต่ต้น ตามคำขอให้ตรวจสอบและนำ Eclipse Mosquitto (ที่ github.com/eclipse-mosquitto/mosquitto) มาประกอบเนื้อหา เอกสารฉบับนี้จึงอธิบายว่า MQTT คืออะไร Mosquitto ทำหน้าที่อะไรในระบบนิเวศนี้ และที่สำคัญคือมันช่วยแก้ช่องโหว่ที่เคยระบุไว้ได้อย่างไร

1. MQTT คืออะไร: สถาปัตยกรรม Publish-Subscribe

MQTT (Message Queuing Telemetry Transport) เป็นโพรโทคอลส่งข้อความน้ำหนักเบาที่ออกแบบมาสำหรับอุปกรณ์ IoT และเครือข่ายที่มีแบนด์วิดท์จำกัด หัวใจสำคัญคือรูปแบบการสื่อสารแบบ Publish-Subscribe ซึ่งต่างจากการเชื่อมต่อแบบจุดต่อจุด (point-to-point) ที่ใช้กันทั่วไป

ในระบบนี้มีตัวกลางเรียกว่า Broker ทำหน้าที่รับข้อความจากผู้เผยแพร่ (Publisher) แล้วกระจายต่อไปยังผู้รับที่สมัครสมาชิก (Subscriber) โดยทั้งสองฝ่ายไม่จำเป็นต้องรู้จักหรือเชื่อมต่อกันโดยตรงเลย ข้อความแต่ละชิ้นถูกส่งไปยัง “หัวข้อ” (topic) ซึ่งมีโครงสร้างเป็นลำดับชั้นคล้ายเส้นทางไฟล์ เช่น drone/1/telemetry หรือ drone/3/battery ผู้สมัครสมาชิกสามารถใช้ไวลด์การ์ดอย่าง + (แทนหนึ่งระดับ) หรือ # (แทนทุกระดับที่เหลือ) เพื่อรับข้อมูลจากโดรนหลายลำพร้อมกันโดยไม่ต้องเขียนโค้ดแยกทีละลำ ตัวโพรโทคอลยังกำหนดระดับคุณภาพการส่ง (QoS) ได้สามระดับ ตั้งแต่ส่งครั้งเดียวไม่รับประกัน ไปจนถึงรับประกันว่าข้อความจะถึงปลายทางเพียงครั้งเดียวเท่านั้น ซึ่งสำคัญมากสำหรับคำสั่งควบคุมที่ห้ามซ้ำหรือห้ามหาย

2. Eclipse Mosquitto: ตัวกลางอ้างอิงของโลก MQTT

Eclipse Mosquitto คือซอฟต์แวร์ Broker แบบโอเพนซอร์สที่ได้รับการยอมรับกว้างขวางที่สุดตัวหนึ่งในโลก MQTT พัฒนาภายใต้มูลนิธิ Eclipse รองรับ MQTT ทั้งเวอร์ชัน 5.0, 3.1.1 และ 3.1 มีผู้ติดตามบน GitHub กว่า 11,200 ดาว และถูก fork ต่อกว่า 2,600 ครั้ง สะท้อนการใช้งานจริงในอุตสาหกรรมอย่างแพร่หลาย นอกจากตัว Broker หลักแล้ว โครงการยังมีชุดเครื่องมือประกอบที่ครบเครื่อง ทั้งไลบรารีไคลเอนต์สำหรับภาษา C/C++ และเครื่องมือบรรทัดคำสั่งอย่าง mosquitto_pub และ mosquitto_sub สำหรับทดสอบส่ง-รับข้อความอย่างรวดเร็ว รวมถึง mosquitto_ctrl และ mosquitto_passwd สำหรับบริหารจัดการผู้ใช้และสิทธิ์การเข้าถึง (eclipse-mosquitto/mosquitto)

ภาพที่ 4b: Eclipse Mosquitto Broker พร้อมไลบรารีไคลเอนต์และเครื่องมือบรรทัดคำสั่งสี่ตัวที่มาด้วยกัน

3. ปิดช่องโหว่ที่เคยระบุไว้: TLS และ Dynamic Security Plugin

จุดที่สำคัญที่สุดสำหรับเอกสารฉบับนี้คือการตอบคำถามว่า Mosquitto แก้ปัญหา “MQTT ไม่เข้ารหัส” ที่เคยระบุไว้ได้อย่างไรในทางปฏิบัติ

ในสถานะเริ่มต้นที่ไม่ได้ตั้งค่าเพิ่มเติม MQTT มักถูกใช้งานผ่านพอร์ต 1883 แบบข้อความธรรมดา (plaintext) ที่ใครก็สามารถดักฟังได้หากอยู่ในเครือข่ายเดียวกัน และหากไม่บังคับการยืนยันตัวตน ไคลเอนต์ใดก็ตามที่รู้ที่อยู่ของ Broker ก็สามารถเชื่อมต่อ ส่งคำสั่งปลอม หรือแอบฟังข้อมูลได้ทันที ซึ่งในบริบทฝูงโดรนอาจหมายถึงการที่ผู้ไม่ประสงค์ดีปลอมตัวเป็นโดรนลำหนึ่งแล้วส่งข้อมูลเท็จเข้าสู่ระบบ หรือแอบฟังพิกัดและสถานะภารกิจได้ทั้งหมด

Mosquitto แก้ปัญหานี้ผ่านมาตรการหลักสองชั้น ชั้นแรกคือการเข้ารหัสด้วย TLS ผ่านพอร์ต 8883 ซึ่งเข้ารหัสทุกข้อความระหว่างทางเหมือนเว็บไซต์ที่ใช้ HTTPS พร้อมรองรับการยืนยันตัวตนด้วยใบรับรองดิจิทัล (client certificate) สำหรับกรณีที่ต้องการความเข้มงวดสูงสุด ชั้นที่สองคือ Dynamic Security Plugin ซึ่งเป็นระบบจัดการสิทธิ์แบบละเอียดที่กำหนดได้ว่าผู้ใช้แต่ละรายเชื่อมต่อได้จากที่ใด และมีสิทธิ์ publish หรือ subscribe topic ใดได้บ้าง เมื่อผสานทั้งสองมาตรการเข้าด้วยกัน ระบบสามารถกำหนดได้ว่าโดรนแต่ละลำมีบัญชีของตัวเอง เชื่อมต่อผ่าน TLS เท่านั้น และ publish ข้อมูลได้เฉพาะ topic ของตัวเองเท่านั้น เช่น โดรนลำที่ 1 จะไม่สามารถปลอมตัวส่งข้อมูลในนาม drone/2/telemetry ได้อีกต่อไป ซึ่งปิดช่องโหว่ spoofing ที่เอกสารก่อนหน้าระบุไว้ได้โดยตรง (eclipse-mosquitto/mosquitto)

4. MQTT ในระบบหุ่นยนต์และฝูงโดรนที่ใช้ ROS 2 จริง

MQTT ไม่ได้เป็นเพียงแนวคิดทางทฤษฎี แต่มีสะพานเชื่อมที่ใช้งานจริงระหว่างกรอบงานหุ่นยนต์ ROS 2 กับโลก MQTT แล้ว

โครงการ mqtt_client ที่พัฒนาโดยสถาบัน RWTH Aachen เป็นโหนด ROS 2 ที่ทำหน้าที่เป็นสะพานสองทิศทางระหว่างข้อความ ROS กับ MQTT Broker โดยรองรับทั้งการแปลงข้อความ ROS แบบเต็มรูปแบบ และรองรับชนิดข้อมูลพื้นฐาน (จำนวนเต็ม, ทศนิยม, ข้อความ, บูลีน) เพื่อให้สื่อสารกับอุปกรณ์ MQTT ที่ไม่ได้ใช้ ROS ได้ด้วย โครงการนี้ยังมีฟีเจอร์วัดความหน่วงเวลา (latency) แบบอัตโนมัติ และรองรับ QoS, TLS และการยืนยันตัวตนระดับที่ใช้งานจริงในอุตสาหกรรมได้ สถาบันที่พัฒนาคือหน่วยงานด้านวิศวกรรมยานยนต์ จึงเน้นกรณีใช้งานอย่างการสื่อสารระหว่างยานพาหนะกับโครงสร้างพื้นฐาน (V2X) และเครือข่ายยานพาหนะอัตโนมัติแบบกระจายตัว (ika-rwth-aachen/mqtt_client)

ในระดับอุตสาหกรรม แพลตฟอร์ม MQTT อย่าง EMQX ได้ขยายแนวคิดนี้ไปสู่ “แกนหลักข้อมูลเรียลไทม์” ที่เชื่อมระบบ ROS/DDS ในพื้นที่เข้ากับบริการคลาวด์ รูปแบบ publish-subscribe ช่วยแยกส่วนฮาร์ดแวร์หุ่นยนต์ออกจากศูนย์ควบคุม ทำให้ผู้ปฏิบัติงานบริหารจัดการฝูงหุ่นยนต์จากระยะไกลได้โดยไม่ต้องรักษาการเชื่อมต่อแบบจุดต่อจุดที่เปราะบาง และรองรับการขยายขนาดจากหุ่นยนต์ตัวเดียวไปจนถึงฝูงเชิงพาณิชย์ขนาดใหญ่ได้ในสถาปัตยกรรมเดียวกัน พร้อมมาตรการความปลอดภัยระดับองค์กรทั้งการเข้ารหัส TLS/SSL การยืนยันตัวตนด้วยใบรับรอง X.509 และการควบคุมการเข้าถึงระดับหัวข้อ (EMQX — Unified MQTT Platform for Connected Robots) แนวคิดเดียวกันนี้ยังปรากฏในงานวิจัยเชิงวิชาการที่เสนอสถาปัตยกรรมผสาน Software-Defined Networking (SDN) เข้ากับ MQTT สำหรับการสื่อสารของฝูงโดรนในสมรภูมิรบโดยเฉพาะ ตีพิมพ์ใน IEEE Communications Magazine ปี 2019 ซึ่งชี้ให้เห็นว่าแนวคิด MQTT สำหรับฝูงโดรนด้านความมั่นคงไม่ใช่เรื่องใหม่ แต่เป็นทิศทางที่มีการศึกษาอย่างจริงจังมาระยะหนึ่งแล้ว (An SDN-MQTT Based Communication System for Battlefield UAV Swarms — IEEE Communications Magazine)

5. จุดเชื่อมที่มองไม่เห็น: Mosquitto ซ่อนอยู่ใน ChirpStack อยู่แล้ว

ส่วนที่น่าสนใจที่สุดเมื่อย้อนกลับไปดูเอกสาร Swarm+LoRa ฉบับก่อนหน้าคือ ระบบเฝ้าระวังฉุกเฉินที่ใช้ ChirpStack เป็น Network Server นั้น แท้จริงแล้วใช้ MQTT เป็นกลไกเผยแพร่ข้อมูลภายในอยู่แล้วโดยดีฟอลต์ เพียงแต่เอกสารก่อนหน้ายังไม่ได้ลงรายละเอียดจุดนี้

เมื่ออุปกรณ์ LoRaWAN ส่งข้อมูลขึ้นมา (uplink) ChirpStack Network Server จะถอดรหัสและยืนยันตัวตนอุปกรณ์ก่อน แล้ว “เผยแพร่ข้อมูลทุกอย่างที่ได้รับจากอุปกรณ์เป็น JSON ผ่าน MQTT” โดยใช้โครงสร้าง topic แบบลำดับชั้น เช่น application/APPLICATION_ID/device/DEV_EUI/event/up สำหรับข้อมูลขาขึ้น และ application/APPLICATION_ID/device/DEV_EUI/command/down สำหรับส่งคำสั่งขาลงกลับไปยังอุปกรณ์ เอกสารทางการของ ChirpStack เองระบุ Mosquitto ไว้เป็น “reference implementation” หรือ Broker อ้างอิงสำหรับการทดสอบและใช้งานจริง (ChirpStack — MQTT Integration)

ความหมายเชิงปฏิบัติของจุดนี้คือ หากวางระบบเฝ้าระวังฉุกเฉินที่กล่าวถึงในเอกสารก่อนหน้าจริง Mosquitto จะทำหน้าที่เป็นจุดกระจายข้อมูลกลางที่ทำให้ระบบปลายทางหลายระบบรับข้อมูลชุดเดียวกันพร้อมกันได้ในทันที ทั้ง InfluxDB/Grafana สำหรับแสดงผลแผนที่ ROS 2 ผ่าน mqtt_client สำหรับให้หุ่นยนต์ภาคพื้นตอบสนองต่อข้อมูลอัตโนมัติ และเครื่องมือตรวจสอบด้วยมืออย่าง MQTT.fx สำหรับผู้ดูแลระบบ โดยไม่ต้องแก้ไขโค้ดของ ChirpStack เองแม้แต่บรรทัดเดียว เพราะทุกฝ่ายเพียงสมัครสมาชิก topic ที่ต้องการจาก Broker ตัวเดียวกัน

6. เครื่องมือสำหรับทดสอบและตรวจสอบ: MQTT.fx

เมื่อวางระบบ Broker ไม่ว่าจะเป็น Mosquitto หรือ ChirpStack ที่ฝัง MQTT ไว้ภายใน ผู้พัฒนาและผู้ดูแลระบบมักต้องการเครื่องมือสำหรับตรวจสอบข้อความที่ไหลผ่านไปมาแบบเห็นภาพ MQTT.fx คือไคลเอนต์ MQTT แบบกราฟิก (GUI) ที่พัฒนาด้วย JavaFX โดยอิงจากไลบรารี Eclipse Paho ทำหน้าที่คล้ายกับ mosquitto_pub/mosquitto_sub ของ Mosquitto แต่มีหน้าต่างโต้ตอบให้ใช้งานง่ายกว่าสำหรับผู้ที่ไม่ถนัดบรรทัดคำสั่ง ไฟล์ mqttfx-1.7.1-windows-x64 ที่พบเป็นตัวติดตั้งเวอร์ชัน 1.7.1 สำหรับระบบปฏิบัติการ Windows 64 บิตโดยเฉพาะ (MQTT.fx 1.7.1 — jensd.de)

ในบริบทของงานที่ทำอยู่ เครื่องมือนี้เหมาะสำหรับการตรวจสอบระบบก่อนใช้งานจริงหลายกรณี เช่น เชื่อมต่อไปยัง Mosquitto Broker ที่ตั้งค่า TLS/ACL แล้วเพื่อยืนยันว่าการเชื่อมต่อและสิทธิ์การเข้าถึงทำงานถูกต้องตามที่ออกแบบไว้ สมัครสมาชิก topic ของ ChirpStack อย่าง application/# เพื่อดูข้อมูล LoRaWAN uplink แบบเรียลไทม์โดยไม่ต้องเขียนโค้ดใดๆ ก่อน หรือจำลองการส่งคำสั่งควบคุมไปยัง topic ของโดรนแต่ละลำเพื่อทดสอบพฤติกรรมของระบบก่อนเชื่อมต่อกับฮาร์ดแวร์จริง กล่าวโดยสรุปคือ MQTT.fx เป็นเครื่องมือฝั่งไคลเอนต์สำหรับ “มองเห็น” สิ่งที่เกิดขึ้นในระบบ MQTT ที่ Mosquitto เป็นผู้ดูแลอยู่เบื้องหลัง ไม่ใช่ส่วนประกอบที่ต้องติดตั้งถาวรในระบบการทำงานจริง แต่เป็นเครื่องมือพัฒนาและตรวจสอบที่มีประโยชน์ตลอดวงจรชีวิตของระบบ

ภาพที่ 5b: สามกรณีใช้งานหลักของ MQTT.fx — ตรวจสอบ TLS/ACL, ดู LoRaWAN uplink ของ ChirpStack, และจำลองคำสั่งควบคุมโดรน

F28: อายุข้อมูลและคิวที่โตขึ้น

ระดับประยุกต์ · คำถาม: แม้ข้อความส่งถึง ผู้ใช้ได้รับข้อมูลใหม่พอหรือไม่ และ consumer ตาม producer ทันหรือยัง?

age = tnow − tmeasure

g = λ − μ; Q(t) ≈ max(0, Q₀ + (λ − μ)t)

สูตรคิวนี้เป็นบัญชีเข้าออกแบบ fluid ที่ผู้เรียบเรียงกำหนดเพื่อการเรียนรู้ ไม่ใช่ข้อกำหนด MQTT สมมติอัตราคงที่ คิวไม่จำกัด ไม่มีการ drop/expire/retry เพิ่มข้อความ และ μ คือกำลังให้บริการซึ่งหยุดใช้เมื่อคิวว่าง ถ้า λ มากกว่า μ จะเพิ่มประมาณ λ − μ message/s ไม่สามารถอนุมาน latency percentile จากค่าเฉลี่ยนี้ได้

ตัวอย่าง: ข้อความถึงแล้วแต่ยังค้างในคิว

1. timestamp หลังจัด clock ให้ตรงกันคือ tmeasure = 100.00 s และ tnow = 100.35 s จึง age = 0.35 s = 350 ms
2. λ = 20 message/s และ μ = 15 message/s ให้ g = 5 message/s
3. เริ่ม Q₀ = 0 และสังเกต 12 s ได้ Q ≈ 0 + 5 × 12 = 60 message ที่ยังค้างในแบบจำลอง

ภาพแยกเส้นเวลาออกจากคิว เพราะ age ของหนึ่งข้อความกับจำนวนข้อความค้างเป็นคนละปริมาณ การวัด age ข้ามเครื่องต้องระบุวิธี synchronize, offset และความไม่แน่นอนของ clock; ถ้า clock ต่างกัน 0.1 s อายุที่ลบได้อาจผิด 0.1 s อย่าใช้ absolute value กลบ age ติดลบ และอย่าแทนเวลาวัดด้วยเวลารับจาก broker

QoS และ deadline ต้องตรวจแยกกัน

OASIS MQTT 5.0, §4.3 (P2C04, ตรวจ 26 กันยายน 2569) กำหนด QoS เป็นระดับการส่งข้อความ ไม่ได้ให้ขอบเขตเวลาประมวลผลปลายทาง QoS 1 อาจมีข้อความซ้ำ จึงต้องกำหนดว่าจะนับ λ ก่อนหรือหลัง deduplicate ส่วน Message Expiry Interval ใน §3.3.2.3.3 จำกัดอายุระหว่างขั้นการส่งตาม protocol ไม่ได้รับรองว่า application ประมวลผลทัน deadline ควรตรวจ age และนโยบายรับ/ทิ้งข้อมูลเก่าที่ application ด้วย

สำหรับ latency percentiles ให้เก็บเวลาวัดจนถึงเวลาที่ application ใช้ข้อมูลจริงเป็นรายข้อความ แล้วใช้ สถิติ F37 พร้อมวิธี percentile เดียวกัน รายงานจำนวนตัวอย่างและข้อความที่ตกหล่น ไม่สรุป p95 จากเพียง λ และ μ ส่วน QoS ของ ROS 2 ต้องศึกษาข้อกำหนดแยกต่างหาก บทนี้ไม่ใช้ MQTT แทนความหมายของ ROS QoS

ลองทำด้วยตนเอง

คง λ = 20, Q₀ = 0, t = 12 s แต่เพิ่ม μ เป็น 18 message/s จงหา g และ Q ส่วนข้อมูลวัดเวลา 200.00 s ประเมินเวลา 200.12 s มี age เท่าใด? ยอมรับคลาดเคลื่อน 0.000001 ในหน่วยของผลลัพธ์

อ่านร่วมกับ bandwidth และ packet loss F27 เพื่อรายงานทั้งปริมาณ ความครบ และอายุข้อมูล

บทสรุป

เมื่อประกอบทั้งหมดเข้าด้วยกัน จะเห็นว่า MQTT และ Eclipse Mosquitto ไม่ใช่เทคโนโลยีใหม่ที่แยกขาดจากเนื้อหาที่ทำมาก่อนหน้า แต่เป็นชิ้นส่วนที่ขาดหายไปซึ่งเติมเต็มภาพให้สมบูรณ์ขึ้น ทั้งในแง่การปิดช่องโหว่ความปลอดภัยชั้นแอปพลิเคชันที่เคยระบุไว้ในเอกสาร Swarm+LoRa และในแง่การเผยให้เห็นว่า ChirpStack ที่ใช้ในระบบเฝ้าระวังฉุกเฉินนั้น แท้จริงแล้วมี MQTT ทำงานอยู่เบื้องหลังอยู่แล้ว การเข้าใจ Mosquitto จึงไม่ใช่แค่การเพิ่มเทคโนโลยีใหม่เข้ามา แต่คือการเข้าใจกลไกที่มีอยู่จริงในสถาปัตยกรรมที่ออกแบบไว้แล้วอย่างลึกซึ้งขึ้น พร้อมเครื่องมืออย่าง MQTT.fx ที่ช่วยให้ผู้ปฏิบัติงานตรวจสอบและทดสอบระบบทั้งหมดนี้ได้อย่างเป็นรูปธรรมก่อนนำไปใช้จริง

บรรณานุกรม

1. Eclipse Foundation. eclipse-mosquitto/mosquitto: Eclipse Mosquitto - An open source MQTT broker. GitHub. https://github.com/eclipse-mosquitto/mosquitto
2. ika-rwth-aachen. mqtt_client: ROS 2 C++ Node for bi-directionally bridging messages between ROS and MQTT. GitHub. https://github.com/ika-rwth-aachen/mqtt_client
3. “The Unified MQTT Platform for Connected Robots.” EMQX. https://www.emqx.com/en/solutions/cloud-robotics
4. Xiong, et al. “An SDN-MQTT Based Communication System for Battlefield UAV Swarms.” IEEE Communications Magazine, 2019. อ่านบทความใน IEEE Xplore
5. “MQTT Integration.” ChirpStack Documentation. เอกสาร MQTT Integration ของ ChirpStack
6. “MQTT.fx 1.7.1 is released!” JavaFX Delight. https://www.jensd.de/wordpress/?p=2746

หมายเหตุ: เอกสารนี้จัดทำขึ้นตามคำขอให้ตรวจสอบ github.com/eclipse-mosquitto/mosquitto และพิจารณานำมาประกอบเนื้อหา โดยเชื่อมโยงกับช่องโหว่ด้านความปลอดภัยของ MQTT ที่เคยระบุไว้ในเอกสาร “เนื้อหาเจาะลึก: การประสานฝูงโดรนผ่านโครงข่าย LoRa Mesh Network” และระบบ ChirpStack ที่กล่าวถึงในเอกสารเดียวกัน เนื้อหาทั้งหมดมาจากการค้นคว้าเพิ่มเติม เป็นเอกสารวิจัยอิสระ

ดาวน์โหลดชุดฝึกสูตรประยุกต์ (CSV/JSON พร้อมเฉลย) · ข้อมูลสังเคราะห์สำหรับฝึกคำนวณและตรวจหน่วย