Network & Security

MQTT 5.0 คืออะไร? คู่มือ IoT Messaging Protocol สำหรับ SME ไทย 2026

เจาะลึก MQTT 5.0 โปรโตคอล Pub/Sub สำหรับ IoT ที่กินแบนด์วิดท์ต่ำและ scale ได้ระดับล้านดีไวซ์ พร้อมเปรียบเทียบ Broker และตัวอย่างใช้งานจริงสำหรับ SME ไทย

AF
ADS FIT Team
·8 นาที
Share:
🌐

# MQTT 5.0 คืออะไร? คู่มือ IoT Messaging Protocol สำหรับ SME ไทย 2026

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

MQTT (Message Queuing Telemetry Transport) จึงกลายเป็นโปรโตคอลมาตรฐานของโลก IoT ในปี 2026 เพราะออกแบบมาเพื่ออุปกรณ์ที่มีข้อจำกัดเรื่องพลังงานและแบนด์วิดท์โดยเฉพาะ และ MQTT 5.0 ที่เป็นเวอร์ชันล่าสุดยังเพิ่มฟีเจอร์ระดับองค์กรเข้ามาอีกหลายตัว

บทความนี้จะพา SME ไทยทำความรู้จัก MQTT 5.0 ตั้งแต่พื้นฐาน Pub/Sub, ระดับ QoS, การเลือก Broker ที่เหมาะ, การทำ Security ด้วย TLS, ไปจนถึงตัวอย่างใช้งานจริงในธุรกิจ

MQTT คืออะไร และทำไมถึงเหมาะกับ IoT

MQTT เป็นโปรโตคอลแบบ Publish/Subscribe (Pub/Sub) ที่วางอยู่บน TCP/IP โดยมี Broker เป็นตัวกลางในการส่งข้อความระหว่างอุปกรณ์ จุดเด่นที่ทำให้ MQTT ครองตลาด IoT คือ Header ขนาดเล็กเพียง 2 bytes, รองรับเครือข่ายไม่เสถียรผ่านระบบ QoS, มี Last Will & Testament สำหรับแจ้งเตือนเมื่ออุปกรณ์หลุด และเปิดการเชื่อมต่อค้างไว้ (Persistent Connection) ช่วยลดการ Handshake ซ้ำ

| คุณสมบัติ | MQTT | HTTP/REST |

|---|---|---|

| Header overhead | 2 bytes | 200-800 bytes |

| Connection model | Persistent (long-lived) | Request-Response |

| Broadcast 1-to-many | ในตัว | ต้อง Poll หรือ WebSocket |

| Battery friendly | สูง | ต่ำ |

| QoS guarantees | 3 ระดับ | ไม่มี |

| Suitable for unreliable network | เหมาะมาก | ไม่ดี |

MQTT 5.0 มีอะไรใหม่จาก 3.1.1

MQTT 5.0 ออกตั้งแต่ปี 2019 แต่ปี 2026 พึ่งจะถูกใช้งานในระดับ Production อย่างแพร่หลาย ฟีเจอร์เด่นที่ SME ควรรู้ ได้แก่ Reason Codes ที่บอกสาเหตุที่ Server ปฏิเสธการเชื่อมต่อหรือส่งข้อความได้ละเอียด, User Properties ที่ให้แนบ metadata แบบ key-value ในข้อความได้, Shared Subscriptions ที่ทำ Load Balancing ระหว่าง Subscriber หลายตัว, Message Expiry Interval ที่ตั้งอายุข้อความได้, และ Topic Aliases ที่ลดขนาดข้อความเมื่อใช้ Topic ยาวซ้ำ ๆ

QoS Levels: เลือกอย่างไรให้เหมาะกับงาน

MQTT มี Quality of Service 3 ระดับที่ต้องเลือกให้เหมาะกับธรรมชาติของข้อมูล

  • **QoS 0 — At most once**: ส่งข้อความครั้งเดียว ไม่การันตี ใช้กับข้อมูลที่ส่งบ่อยและรับได้ที่จะหายบ้าง เช่น เซ็นเซอร์อุณหภูมิที่ส่งทุก 1 วินาที
  • **QoS 1 — At least once**: การันตีว่าข้อความถึงปลายทางอย่างน้อยหนึ่งครั้ง แต่อาจซ้ำได้ เหมาะกับ Event ทั่วไป เช่น ปุ่มกด แจ้งเตือน
  • **QoS 2 — Exactly once**: การันตีว่าถึงครั้งเดียวเท่านั้น มี Overhead สูงสุด เหมาะกับข้อมูลทางการเงิน คำสั่งควบคุมเครื่องจักร
  • Broker ยอดนิยม: เลือกตัวไหนดี

    | Broker | License | จุดเด่น | เหมาะกับ |

    |---|---|---|---|

    | Mosquitto | EPL/EDL (Open) | Lightweight, รันบน Raspberry Pi ได้ | SME, Lab, PoC |

    | EMQX | Apache 2.0 + Enterprise | รองรับล้าน Connection, Cluster | Production scale ใหญ่ |

    | HiveMQ | Commercial + CE | Enterprise SLA, Kafka bridge | Enterprise, IIoT |

    | VerneMQ | Apache 2.0 | Distributed by design | Multi-region |

    | AWS IoT Core | Managed | ไม่ต้องดูแล Server | Cloud-native บน AWS |

    สำหรับ SME ไทยส่วนใหญ่ Mosquitto ก็เพียงพอสำหรับการเริ่มต้น และเมื่อโตถึงจุดที่ต้องรองรับเกิน 50,000 Connection พร้อมกัน จึงค่อยพิจารณาย้ายไป EMQX หรือ HiveMQ

    How-To: ติดตั้ง Mosquitto + เชื่อมต่อด้วย Node.js ใน 5 ขั้นตอน

  • ติดตั้ง Mosquitto บน Ubuntu: รันคำสั่ง `sudo apt install mosquitto mosquitto-clients` แล้ว `sudo systemctl enable --now mosquitto`
  • เปิด TLS Port 8883: สร้าง Certificate ด้วย Let's Encrypt หรือ self-signed แล้วแก้ `/etc/mosquitto/conf.d/tls.conf` ให้ระบุไฟล์ Cert/Key
  • สร้าง Username/Password: รัน `sudo mosquitto_passwd -c /etc/mosquitto/passwd iotuser` แล้วเปิด `allow_anonymous false` ในไฟล์ Config
  • เขียน Publisher ด้วย Node.js: ติดตั้ง `npm install mqtt` แล้วเรียก `mqtt.connect("mqtts://broker.example.com", { username, password })` และ `client.publish("factory/sensor1/temp", "28.5", { qos: 1 })`
  • เขียน Subscriber: เรียก `client.subscribe("factory/+/temp")` โดย `+` เป็น wildcard 1 level สำหรับรับข้อมูลจากทุก Sensor
  • Security: 5 มาตรฐานที่ต้องทำ

  • **เปิด TLS 1.3** ใน Port 8883 ห้ามใช้ Port 1883 แบบ Plain text บนอินเทอร์เน็ต
  • **บังคับ Authentication** ด้วย Username/Password หรือ X.509 Client Certificate
  • **กำหนด ACL (Access Control List)** ว่า Topic ไหนใครเข้าถึงได้บ้าง เพื่อป้องกัน Device หนึ่งดูข้อมูลของอีก Device
  • **ตั้งค่า Rate Limit** ป้องกัน Device ที่เสียส่งข้อมูลถล่ม Broker
  • **เก็บ Audit Log** ทั้ง Connect, Subscribe, Publish เพื่อสืบสวนเมื่อมีเหตุการณ์ผิดปกติ
  • Use Cases ที่ SME ไทยใช้ MQTT ได้จริง

  • **Smart Factory**: เก็บข้อมูล Sensor อุณหภูมิ, ความสั่นสะเทือน, การกินไฟของเครื่องจักร เพื่อทำ Predictive Maintenance
  • **Cold Chain Logistics**: ติดตามอุณหภูมิตู้ขนส่งห้องเย็นแบบ Real-time ตามมาตรฐาน GMP/HACCP
  • **Smart Building**: ควบคุมแอร์ ไฟ ม่าน ระบบรักษาความปลอดภัยรวมศูนย์
  • **Retail / Vending Machine**: รายงานสต็อกและยอดขายจากตู้กดสินค้าอัตโนมัติทุกสาขา
  • **Agriculture / Smart Farm**: เก็บค่าความชื้นในดิน อุณหภูมิเรือนเพาะปลูก เพื่อสั่งระบบน้ำหยดอัตโนมัติ
  • เปรียบเทียบ MQTT กับโปรโตคอล IoT อื่น

    | โปรโตคอล | Transport | Pattern | จุดเด่น | จุดด้อย |

    |---|---|---|---|---|

    | MQTT | TCP | Pub/Sub | Header เล็ก, QoS 3 ระดับ | ต้องมี Broker |

    | CoAP | UDP | Request/Response | เบามาก, ใช้ใน 6LoWPAN | ไม่มี Pub/Sub แท้ |

    | AMQP | TCP | Pub/Sub + Queue | Routing ซับซ้อน | Header ใหญ่ |

    | HTTP/2 + SSE | TCP | Server Push | ผ่าน Firewall ง่าย | กิน Bandwidth |

    | WebSocket | TCP | Bi-directional | ใช้ใน Browser ได้ | ไม่มี QoS ในตัว |

    สรุป + Call to Action

    MQTT 5.0 เป็นโปรโตคอลที่ SME ไทยควรนำมาใช้สำหรับโปรเจกต์ IoT ทุกประเภท เพราะกินทรัพยากรน้อย รองรับเครือข่ายที่ไม่เสถียร มี Broker Open Source ฟรีอย่าง Mosquitto ให้ใช้ และมี Ecosystem ไลบรารีรองรับเกือบทุกภาษา ตั้งแต่ Python, Node.js, Go, ไปจนถึงไมโครคอนโทรลเลอร์อย่าง ESP32

    Key Takeaways:

  • เริ่มด้วย Mosquitto + TLS + Authentication เป็นพื้นฐานบังคับก่อนขึ้น Production
  • เลือก QoS ตามธรรมชาติของข้อมูล อย่าใช้ QoS 2 กับทุก Topic เพราะกิน Overhead
  • ออกแบบ Topic Hierarchy ให้ดี เช่น `factory/{site}/{machine}/{sensor}` เพื่อใช้ ACL และ Wildcard ได้สะดวก
  • ติดตามเมตริก Connection, Message Rate, Queue Depth ของ Broker เสมอ
  • หากธุรกิจของคุณกำลังจะเริ่มต้นโครงการ IoT หรือกำลังเปลี่ยนจาก HTTP Polling มาเป็น MQTT แต่ไม่แน่ใจว่าจะออกแบบสถาปัตยกรรมและเลือก Broker อย่างไร [ติดต่อทีม ADS FIT](https://www.adsfit.co.th/contact) เพื่อรับคำปรึกษาและออกแบบระบบ IoT ที่ปลอดภัย ขยายตัวได้ และคุ้มค่าการลงทุน หรืออ่านบทความที่เกี่ยวข้องอย่าง NetFlow vs sFlow vs IPFIX และคู่มือ Network Security ของเราเพื่อต่อยอดความเข้าใจระบบเครือข่าย

    Tags

    #MQTT#IoT#Pub/Sub#Mosquitto#EMQX#Network

    สนใจโซลูชันนี้?

    ปรึกษาทีม ADS FIT ฟรี เราพร้อมออกแบบระบบที่ฟิตกับธุรกิจของคุณ

    ติดต่อเรา →

    บทความที่เกี่ยวข้อง