MQTT là gì? Giao thức nhẹ cho thiết bị IoT và hệ thống nhúng

MQTT (Message Queuing Telemetry Transport) là một giao thức truyền thông nhẹ, dựa trên TCP/IP, được thiết kế đặc biệt cho các kết nối có độ trễ cao, bandwidth thấp và nguồn năng lượng hạn chế – những đặc điểm phổ biến trong Internet of Things (IoT) và các hệ thống nhúng (embedded systems). Với mô hình publish/subscribe (pub/sub) đơn giản nhưng mạnh mẽ, MQTT đã trở thành tiêu chuẩn thực tế cho giao tiếp giữa các thiết bị cảm biến, bộ điều khiển và nền tảng đám mây, đặc biệt trong các trường hợp như cảm biến môi trường, hệ thống nhà thông minh và xe nối kết.

Minh hoá mô hình publish/subscribe của MQTT: publisher gửi tới topic trên broker, broker phân phối tới tất cả subscriber

Mô hình publish/subcribe và cấu trúc topic

Trong MQTT, publisher không cần biết ai là subscriber; nó chỉ cần gửi một tin nhắn PUBLISH kèm theo một tên topic (ví dụ: `home/temperature/livingroom`) tới broker. Broker chịu trách nhiệm lưu trữ (nếu tin nhắn được đánh dấu là retained) và phân phối (fan‑out) tin nhắn tới mọi subscriber đã đăng ký (subscribe) topic đó. Topic trong MQTT được cấu trúc phân cấp dùng dấu gạch ngang ‘/’ để tạo thành hệ thống phân loại logic (ví dụ: `factory/floor1/machine2/vibration`), đồng thời hỗ trợ hai loại wildcard: single-level ‘+’ thay đổi đúng một level (ví dụ: `home/+/temperature`) và multi-level ‘#’ phải xuất hiện ở cuối chuỗi và có thể thay đổi nhiều levels (ví dụ: `home/#` khớp với tất cả topic bắt đầu bằng `home/`).

Chất lượng Dịch vụ (QoS): mức độ tin cậy và chi phí giao tiếp

Một trong những tính năng then chốt của MQTT là hệ thống Chất lượng Dịch vụ (QoS) cho phép người dùng cân bằng giữa độ tin cậy vàภาระ giao tiếp. QoS xác định mức độ đảm bảo khi truyền tải một tin nhắn từ publisher tới subscriber qua broker. Bảng dưới đây tóm tắt ba mức QoS chính trong MQTT 3.1.1 và 5.0.

QoS level Mô tả Cơ chế Ưu điểm Nhược điểm
QoS 0 “At most once” Broker gửi tin nhắn một lần mà không chờ xác nhận Thấp nhất về độ trễ, tối ưu cho kết nối ổn định, dữ liệu không quan trọng Có thể mất tin nhắn nếu kết nối đứt ngay sau khi gửi
QoS 1 “At least once” Broker lưu tin nhắn và gửi lại cho đến khi nhận được PUBACK từ subscriber; nếu không có ACK, gửi lại sau timeout Đảm bảo nhận được ít nhất một lần, phù hợp cho hầu hết ứng dụng IoT Có thể nhận được tin nhắn trùng lặp (duplicate)
QoS 2 “Exactly once” Quy trình bốn bước handshake (PUBLISH → PUBREC → PUBREL → PUBCOMP) – mỗi tin nhắn được xử lý đúng một lần Mức độ tin cậy cao nhất, không trùng lặp và không mất mát Độ trễ cao nhất vì cần ba lượt trao đổi gói tin
Minh hoá kiến trúc hệ thống MQTT đầy đủ: broker, client, thiết bị, cloud bridge

Các tính năng quan trọng khác

Ngoài QoS, MQTT cung cấp một số tính năng thiết thực để tăng độ tin cậy và quản lý kết nối:

  • Keep Alive: tham số trong gói CONNECT xác định thời gian tối đa (giây) mà broker chờ đợi trước khi kiểm tra trạng thái kết nối. Nếu broker không nhận được bất kỳ gói tin điều khiển nào (PINGREQ hoặc bất kỳ PUBLISH/SUBSCRIBE/UNSUBSCRIBE nào) trong khoảng thời gian này, broker sẽ giả định client đã ngắt kết nối và sẽ dọn dẹp trạng thái liên quan. Gói tin PINGREQ/PINGRESP được sử dụng để kiểm tra sự còn sống của kết nối mà không truyền tải dữ liệu thực chất.
  • Retained message: broker lưu trữ tin nhắn cuối cùng cho mỗi topic và gửi ngay khi một subscriber mới đăng ký vào topic đó – rất hữu ích để cung cấp trạng thái ban đầu (ví dụ: nhiệt độ mới nhất đã biết) cho những thiết bị kết nối muộn.
  • Last Will and Testament (LWT): client đăng ký trước một topic và nội dung tin nhắn sẽ được broker tự động phát hành nếu client ngắt kết nối bất thường (mất nguồn điện, mất kết nối mạng) thay vì phải chờ hết thời gian Keep Alive; đây là cách hiệu quả để các subscriber biết ngay khi một thiết bị dies.
  • Persistent session (Clean Session = 0): broker giữ lại trạng thái của client (ví dụ: subscriptions, các tin nhắn chưa được gửi do network outage) để khi client kết nối lại sau một gián đoạn ngắn, nó có thể ngay lập tức tiếp nhận các tin nhắn trong hàng đợi và không phải thực hiện lại quá trình subscribe từ đầu.

MQTT 5.0: các nâng cấp quan trọng

MQTT 5.0 là phiên bản mở rộng của chuẩn kể từ năm 2019, mang lại nhiều tính năng nâng cao nhằm cải thiện khả năng tương tác, kiểm soát và debug. Một số tính năng nổi bật bao gồm:

  • Shared Subscriptions: cho phép nhiều client chia sẻ một subscription để cân bằng tải (ví dụ: hai instance của một service xử lý dữ liệu từ cùng một topic) bằng cách sử dụng tiền tố `$share/` trước tên topic.
  • Subscription Identifiers: cho phép broker biết subscription nào đã gửi một tin nhắn khi có nhiều subscription đến cùng một topic.
  • Maximum Packet Size: giới hạn kích thước gói tin gửi và nhận để tránh tấn công bộ nhớ.
  • Receive Maximum / Flow Control: cho phép subscriber điều chỉnh tốc độ nhận gói tin từ broker, tránh quá tải khi kết nối mạng yếu.
  • Topic Alias: giảm kích thước gói tin bằng cách thay thế tên topic dài bằng một số nguyên ngắn (ví dụ: thay vì gửi chuỗi `very/long/topic/name` mỗi lần, client gửi số nguyên 5 và broker sẽ tra cứu từ bảng tra cứu).
  • User Property: gắn thông tin metadata tùy chỉnh vào mỗi gói tin dưới dạng cặp key‑value (ví dụ: `device_id=12345`, `firmware_version=v2.1`).
  • Reason String: cung cấp lý do dễ đọc được khi ngắt kết nối hoặc lỗi xảy ra (ví dụ: `Connection Timeout`, `Bad Authentication`).
Minh hoá luong publish cua MQTT qua may broker va cac subscriber

Ứng dụng thực tế trong IoT và hệ thống nhúng

MQTT được triển khai rộng rãi trên hàng chục triệu thiết bị từ cảm biến đơn giản đến bộ điều khiển PLC trong nhà máy, từ những dự án DIY trên ESP32 hoặc Raspberry Pi đến các giải pháp công nghiệp như Siemens SIMATIC hoặc Rockwell Automation. Dưới đây là một số ví dụ cụ thể:

  • Cảm biến môi trường: thiết bị đo nhiệt độ, độ ẩm, áp lực gửi dữ liệu định kỳ tới broker qua topic như `sensors/temperature/building1/floor2`.
  • Điều khiển từ xa: bật/tắt relay, đèn, hoặc mở cửa cửa hàng qua các lệnh trên topic như `commands/relay/kitchen` hoặc `commands/door/garage`.
  • OTA firmware upgrade: gửi file nhúng qua các chunk size nhỏ (ví dụ: 256 byte) để tránh vượt quá bộ nhớ RAM trên thiết bị nhúng.
  • Tích hợp với nền tảng đám mây: kết nối broker local với các dịch vụ như AWS IoT Core (mqtts://), Azure IoT Hub hoặc Google Cloud IoT Core qua bridge, cho phép thiết bị trao đổi với cả hai môi trường local và cloud.

Kết luận, MQTT không chỉ là một giao thức truyền thông nhẹ mà là một giải pháp hoàn chỉnh cho các thiết bị có nguồn năng lượng hạn chế và yêu cầu độ tin cậy cao. Với thiết kế đơn giản, tính năng phong phú và thư viện client mature trên hầu hết các ngôn ngữ lập trình (C, C++, Java, Python, JavaScript qua WebSocket), MQTT tiếp tục là lựa chọn ideal khi cần một giải pháp truyền thông nhẹ, tin cậy và dễ tích hợp cho thiết bị IoT và hệ thống nhúng.

Nguồn tham khảo

Tôi là một lập trình viên IOS. Code chính là IOS nhưng thỉnnh thoảng vẫn đá sang Android hoặc web. Mặc dù không quá thông thạo nhưng tôi sẽ chia sẻ những kiến thức mà mình đã tìm hiểu, áp dụng qua.

Bài viết liên quan

NPU là gì: bộ xử lý AI chuyên dụng và cách đọc chỉ số TOPS

NPU là gì và vì sao con số TOPS trên hộp điện thoại ngày càng phóng đại. Neural Processing Unit là bộ xử lý chuyên dụng cho mô hình AI,…

Xem thêm

Gallium nitride GaN là gì: vì sao sạc nhanh nhỏ hơn silicon

Gallium nitride, viết tắt GaN, là một chất dẫn bán đồng nhất III-V có cấu trúc tinh thể Wurtzite và khe hở năng lượng khoảng 3,4 eV. Chính khe hở…

Xem thêm
Biểu đồ đường cong tốc độ nén theo tỷ lệ nén, so sánh zstd với zlib: zstd nén nhỏ hơn ở cùng tốc độ và nhanh hơn nhiều ở cùng tỷ lệ nén

Zstandard là gì? Thuật toán nén nhanh thay thế zlib và gzip

Zstandard (thường gọi tắt là zstd) là thuật toán nén dữ liệu do Yann Collet phát triển tại Facebook và phát hành mã nguồn mở năm 2016. Điểm mạnh của…

Xem thêm
0 0 đánh giá
Article Rating
Theo dõi
Thông báo của
guest
0 Comments
Cũ nhất
Mới nhất Được bỏ phiếu nhiều nhất