สรุปโดยย่อ
ใช้ MQTT สำหรับอุปกรณ์ IoT ที่มีแบตเตอรี่จำกัด, เครือข่ายไม่เสถียร, หรือรูปแบบการรับส่งข้อความแบบ Pub-Sub ใช้ HTTP สำหรับ API เว็บ/มือถือมาตรฐาน MQTT ใช้เฮดเดอร์ขนาด 2 ไบต์ เทียบกับ HTTP ที่มีขนาด 100+ ไบต์ ทำให้เหมาะสำหรับอุปกรณ์ที่มีข้อจำกัด Modern PetstoreAPI ใช้ MQTT สำหรับปลอกคอติดตามสัตว์เลี้ยงและเครื่องให้อาหารอัจฉริยะ
บทนำ
ปลอกคอติดตามสัตว์เลี้ยงของคุณจำเป็นต้องส่งข้อมูลอัปเดตตำแหน่งทุก 5 นาที มันทำงานด้วยแบตเตอรี่แบบกระดุมที่ควรใช้งานได้ 6 เดือน หากใช้ HTTP แบตเตอรี่จะหมดใน 2 สัปดาห์ หากใช้ MQTT แบตเตอรี่จะใช้งานได้เต็ม 6 เดือน
HTTP เป็นมาตรฐานสำหรับ API แต่ถูกออกแบบมาสำหรับเว็บเบราว์เซอร์ ไม่ใช่อุปกรณ์ IoT MQTT (Message Queuing Telemetry Transport) ถูกสร้างขึ้นมาสำหรับอุปกรณ์ที่มีข้อจำกัด ซึ่งมีแบนด์วิธจำกัดและเครือข่ายไม่เสถียร
Modern PetstoreAPI ใช้ HTTP สำหรับแอปพลิเคชันเว็บและมือถือ แต่ใช้ MQTT สำหรับอุปกรณ์ IoT: ปลอกคอติดตามสัตว์เลี้ยง, เครื่องให้อาหารอัจฉริยะ และเครื่องติดตามสุขภาพ
ในคู่มือนี้ คุณจะได้เรียนรู้ว่าเมื่อใดที่ MQTT เหนือกว่า HTTP, ดูตัวอย่างจริงจาก Modern PetstoreAPI และค้นพบวิธีเลือกโปรโตคอลที่เหมาะสมสำหรับกรณีการใช้งานของคุณ
MQTT คืออะไร?
MQTT คือโปรโตคอลการรับส่งข้อความแบบ Pub-Sub ที่มีน้ำหนักเบา ซึ่งออกแบบมาสำหรับ IoT
MQTT ทำงานอย่างไร
อุปกรณ์เผยแพร่ข้อความไปยังหัวข้อ (topics) อุปกรณ์อื่นสมัครรับข้อมูลจากหัวข้อนั้น:
Publisher (Pet Collar):
Topic: pets/019b4132/location
Payload: {"lat":37.7749,"lng":-122.4194,"battery":85}
Subscriber (Mobile App):
Subscribe to: pets/019b4132/location
Receives: {"lat":37.7749,"lng":-122.4194,"battery":85}
MQTT Broker ทำหน้าที่เป็นตัวกลางในการส่งข้อความจากผู้เผยแพร่ไปยังผู้สมัครรับข้อมูล
คุณสมบัติหลักของ MQTT
1. เฮดเดอร์ขนาดเล็ก - MQTT: 2 ไบต์, HTTP: 100-500 ไบต์
2. การเชื่อมต่อแบบต่อเนื่อง - MQTT รักษาการเชื่อมต่อให้เปิดอยู่ตลอด
3. Quality of Service (QoS) - QoS 0/1/2 สำหรับการรับประกันการส่งมอบ
4. Last Will - ข้อความที่ถูกส่งหากอุปกรณ์ตัดการเชื่อมต่อโดยไม่คาดคิด
5. ข้อความที่ถูกเก็บไว้ (Retained messages) - Broker เก็บข้อความล่าสุดสำหรับผู้สมัครรับข้อมูลใหม่
การเปรียบเทียบ MQTT กับ HTTP
| คุณสมบัติ | MQTT | HTTP |
|---|---|---|
| ขนาดเฮดเดอร์ | 2 ไบต์ | 100-500 ไบต์ |
| รูปแบบ | Pub-Sub | Request-Response |
| การเชื่อมต่อ | ต่อเนื่อง | ต่อคำขอ |
| แบนด์วิธ | ต่ำมาก | สูงกว่า |
| ผลกระทบต่อแบตเตอรี่ | น้อยที่สุด | มาก |
| การรองรับเบราว์เซอร์ | ผ่าน WebSocket | ในตัว |
ตัวอย่างแบนด์วิธ
การอัปเดตตำแหน่ง 1000 ครั้งต่อวัน:
- HTTP: 420 KB ต่อวัน, 12.6 MB ต่อเดือน
- MQTT: 52 KB ต่อวัน, 1.56 MB ต่อเดือน
MQTT ใช้แบนด์วิธน้อยกว่า 8 เท่า
เมื่อ MQTT เหนือกว่า
1. อุปกรณ์ IoT ที่มีแบตเตอรี่จำกัด
ปลอกคอติดตามสัตว์เลี้ยง:
- MQTT: อายุการใช้งานแบตเตอรี่ 6 เดือน
- HTTP: อายุการใช้งานแบตเตอรี่ 2 สัปดาห์
เหตุผล: การเชื่อมต่อแบบต่อเนื่อง, เฮดเดอร์ขนาดเล็ก, ใช้เวลาในการรับส่งสัญญาณวิทยุน้อยลง
2. เครือข่ายที่ไม่เสถียร
อุปกรณ์ IoT ที่ใช้เซลลูลาร์ซึ่งมีสัญญาณครอบคลุมไม่สม่ำเสมอ:
- QoS สำหรับการรับประกันการส่งมอบ
- การเชื่อมต่อใหม่โดยอัตโนมัติ
- การคงสถานะเซสชัน
3. การสื่อสารแบบ Many-to-Many
สถานการณ์เครื่องให้อาหารสัตว์เลี้ยงอัจฉริยะ:
Feeder 1 → pets/019b4132/feeding
Feeder 2 → pets/019b4127/feeding
App 1 → subscribes to pets/+/feeding (all pets)
App 2 → subscribes to pets/019b4132/feeding (one pet)
4. ข้อมูลเซ็นเซอร์แบบเรียลไทม์
เครื่องติดตามสุขภาพสัตว์เลี้ยงส่งข้อมูลอัปเดตทุกวินาที:
- การเชื่อมต่อแบบต่อเนื่อง (ไม่มีค่าใช้จ่ายเพิ่มเติม)
- ความหน่วงต่ำที่สุด
- มีประสิทธิภาพสำหรับการอัปเดตที่มีความถี่สูง
เมื่อ HTTP เหนือกว่า
1. แอปพลิเคชันเว็บ/มือถือมาตรฐาน
HTTP เป็นสากล:
- ทุกภาษามีไลบรารี HTTP
- เบราว์เซอร์รองรับโดยธรรมชาติ
- พรอกซีและไฟร์วอลล์อนุญาตให้ใช้งาน
2. รูปแบบการร้องขอ-ตอบกลับ (Request-Response)
การรับรายละเอียดสัตว์เลี้ยง:
GET /pets/019b4132
200 OK
{"name":"Fluffy","species":"CAT"}
HTTP เรียบง่ายกว่าสำหรับการร้องขอ-ตอบกลับ
3. ข้อกำหนดด้านการแคช
การแคชของ HTTP ทำงานได้ทันที:
- การแคชของเบราว์เซอร์
- การแคชของ CDN
- การแคชของพรอกซี
MQTT ไม่มีการแคช
4. RESTful API
รหัสสถานะ, เมธอด และความหมายของ HTTP:
- 200 OK, 404 Not Found, 201 Created
- GET, POST, PUT, DELETE
- การจัดการข้อผิดพลาดมาตรฐาน
Modern PetstoreAPI ใช้ MQTT อย่างไร
Modern PetstoreAPI ใช้ MQTT สำหรับอุปกรณ์ IoT
ปลอกคอติดตามสัตว์เลี้ยง
ปลอกคอเผยแพร่ตำแหน่ง:
Topic: pets/019b4132/location
QoS: 1 (at least once)
Payload: {
"lat": 37.7749,
"lng": -122.4194,
"battery": 85,
"timestamp": "2026-03-13T10:30:00Z"
}
แอปพลิเคชันมือถือสมัครรับข้อมูล:
const mqtt = require('mqtt');
const client = mqtt.connect('mqtts://mqtt.petstoreapi.com');
client.subscribe('pets/019b4132/location');
client.on('message', (topic, message) => {
const location = JSON.parse(message);
updateMap(location.lat, location.lng);
});
เครื่องให้อาหารอัจฉริยะ
เครื่องให้อาหารสมัครรับตารางเวลา:
Topic: pets/019b4132/feeding-schedule
Retained: true
Payload: {
"times": ["08:00", "18:00"],
"amount": 100
}
เครื่องให้อาหารเผยแพร่เหตุการณ์การให้อาหาร:
Topic: pets/019b4132/feeding-events
Payload: {
"timestamp": "2026-03-13T08:00:15Z",
"amount": 100,
"dispensed": true
}
เครื่องติดตามสุขภาพ
เครื่องติดตามเผยแพร่ข้อมูลชีพจร:
Topic: pets/019b4132/health
QoS: 0 (fire and forget, high frequency)
Payload: {
"heartRate": 120,
"temperature": 38.5,
"activity": "resting"
}
การทดสอบ MQTT ด้วย Apidog
Apidog รองรับการทดสอบ MQTT ควบคู่ไปกับ HTTP และโปรโตคอลอื่นๆ
ทดสอบ MQTT Pub-Sub
- เชื่อมต่อกับ MQTT broker
- สมัครรับหัวข้อต่างๆ
- เผยแพร่ข้อความทดสอบ
- ตรวจสอบความถูกต้องของรูปแบบข้อความ
- ทดสอบระดับ QoS
จำลองความล้มเหลวของเครือข่าย
- ทดสอบตรรกะการเชื่อมต่อใหม่
- ตรวจสอบการส่งมอบ QoS 1/2
- ตรวจสอบข้อความ Last Will
- ตรวจสอบความถูกต้องของการคงสถานะเซสชัน
เปรียบเทียบกับ HTTP
ทดสอบฟังก์ชันเดียวกันด้วยโปรโตคอลทั้งสอง:
- วัดการใช้งานแบนด์วิธ
- เปรียบเทียบความหน่วง
- ตรวจสอบความสอดคล้องของข้อมูล
สรุป
MQTT และ HTTP มีวัตถุประสงค์ที่แตกต่างกัน ใช้ MQTT สำหรับอุปกรณ์ IoT ที่มีทรัพยากรจำกัด ใช้ HTTP สำหรับ API เว็บ/มือถือมาตรฐาน
Modern PetstoreAPI แสดงให้เห็นถึงวิธีการใช้ทั้งสอง: HTTP สำหรับ API ที่ผู้ใช้โต้ตอบด้วย, MQTT สำหรับอุปกรณ์ IoT โปรโตคอลที่เหมาะสมขึ้นอยู่กับข้อจำกัดของคุณ ไม่ใช่ว่าอันไหน "ดีกว่า"
ทดสอบทั้งสองโปรโตคอลด้วย Apidog เพื่อค้นหาสิ่งที่เหมาะสมที่สุดสำหรับกรณีการใช้งานของคุณ
คำถามที่พบบ่อย
MQTT สามารถทำงานผ่าน HTTP ได้หรือไม่?
MQTT สามารถทำงานผ่าน WebSocket ซึ่งทำงานผ่าน HTTP ได้ สิ่งนี้ช่วยในการทะลุผ่านไฟร์วอลล์แต่จะสูญเสียประโยชน์ด้านประสิทธิภาพบางส่วนของ MQTT ไป
ระดับ QoS ของ MQTT คืออะไร?
- QoS 0: อย่างมากที่สุดหนึ่งครั้ง (ไม่มีการยืนยัน)
- QoS 1: อย่างน้อยที่สุดหนึ่งครั้ง (มีการยืนยัน, อาจซ้ำกันได้)
- QoS 2: เพียงหนึ่งครั้งแน่นอน (รับประกัน, ไม่ซ้ำกัน)
MQTT ปลอดภัยหรือไม่?
ใช่, MQTT รองรับการเข้ารหัส TLS (MQTTS) และการยืนยันตัวตนด้วยชื่อผู้ใช้/รหัสผ่าน Modern PetstoreAPI ใช้ MQTTS สำหรับอุปกรณ์ IoT ทั้งหมด
เบราว์เซอร์สามารถใช้ MQTT ได้หรือไม่?
เบราว์เซอร์สามารถใช้ MQTT ผ่าน WebSocket ได้ ไลบรารีอย่าง MQTT.js รองรับสภาพแวดล้อมของเบราว์เซอร์
MQTT เปรียบเทียบกับ WebSocket อย่างไร?
MQTT เป็นโปรโตคอลที่สามารถทำงานผ่าน WebSocket ได้ WebSocket เป็นเลเยอร์การขนส่ง MQTT เพิ่มคุณสมบัติ Pub-Sub, QoS และคุณสมบัติเฉพาะสำหรับ IoT บน WebSocket
