MQTT (Message Queuing Telemetry Transport)

1. Tổng quan

Định nghĩa: MQTT là giao thức nhắn tin nhẹ dựa trên mô hình xuất bản/đăng ký (Publish/Subscribe), một giao thức tầng ứng dụng được thiết kế để nhiều thiết bị giao tiếp bất đồng bộ thông qua trung gian là broker trong môi trường hạn chế về băng thông·điện năng·tài nguyên tính toán. Nó được chuẩn hóa thành OASIS MQTT 3.1.1 (2014), cùng đặc tả được chấp nhận thành ISO/IEC 20922:2016, và năm 2019 được mở rộng chức năng mạnh mẽ thành OASIS MQTT 5.0.

Bối cảnh ra đời của MQTT nằm ở thực tế công nghiệp năm 1999, khi IBM và Arcom (nay là Eurotech) cần thu thập ổn định dữ liệu cảm biến để giám sát từ xa đường ống dẫn dầu (SCADA) ngay cả trên đường truyền băng thông hẹp, thường xuyên trễ·gián đoạn như liên kết vệ tinh. HTTP — tiêu chuẩn lúc bấy giờ — do cấu trúc yêu cầu/phản hồi (Request/Response) nên header nặng, server không thể chủ động đẩy dữ liệu tới client (cần polling), và chi phí thiết lập lại kết nối cho mỗi yêu cầu lớn, nên không phù hợp để xử lý thời gian thực hàng nghìn nút cấu hình thấp. MQTT giải quyết vấn đề này bằng sự tinh gọn cực độ với header cố định 2 byte, phiên thường trực hướng kết nối và tách biệt xuất bản/đăng ký lấy broker làm trung tâm.

Giá trị cốt lõi của mô hình xuất bản/đăng ký nằm ở việc tách rời (decoupling) sự ràng buộc về thời gian·không gian·đồng bộ giữa bên gửi và bên nhận. Bên xuất bản không cần biết bên nhận là ai, có bao nhiêu, hiện có đang kết nối hay không. Bên xuất bản ném thông điệp vào một chủ đề (Topic) cụ thể, và mọi client đã đăng ký chủ đề đó nhận thông điệp thông qua broker. Nhờ cấu trúc này, dù thêm·bớt cảm biến hay máy chủ phân tích mới cũng không cần sửa mã của các nút hiện có, nên MQTT đã trở thành giao thức tiêu chuẩn trên thực tế của môi trường IoT·nhà máy thông minh·xe kết nối mở rộng tới quy mô hàng trăm nghìn thiết bị.

Tóm tắt đặc điểm: ① siêu nhẹ (header cố định tối thiểu 2 byte, khung nhị phân không có chi phí văn bản), ② giao tiếp bất đồng bộ·nhiều-nhiều dựa trên xuất bản/đăng ký, ③ điều chỉnh độ tin cậy bằng ba mức chất lượng dịch vụ (QoS 0/1/2), ④ hỗ trợ server push trên kết nối TCP thường trực, ⑤ có các chức năng quản lý phiên cho đường truyền không ổn định như thông điệp di chúc (LWT)·thông điệp lưu giữ (Retain)·Keep Alive.

Tổ hợp các đặc điểm này quan trọng vì ràng buộc của môi trường IoT không phải là một yếu tố đơn lẻ mà là ràng buộc phức hợp khi băng thông·điện năng·tính toán·độ ổn định kết nối đồng thời thiếu hụt. Giao thức chỉ giảm header hoặc chỉ nâng cao độ tin cậy không thể thỏa mãn ràng buộc phức hợp này. MQTT cung cấp cân bằng trong một giao thức duy nhất giữa tính nhẹ (băng thông·điện năng), quyền lựa chọn QoS (độ tin cậy), tách biệt xuất bản/đăng ký (khả năng mở rộng) và quản lý phiên (độ ổn định kết nối), qua đó trở thành giải pháp thực dụng nối từ thiết bị đầu cuối cấu hình thấp tới tầng thu thập trên đám mây. Sự cân bằng này chính là lý do căn bản khiến MQTT giữ vị thế tiêu chuẩn IoT suốt hơn 20 năm.

2. Kiến trúc MQTT và mô hình xuất bản/đăng ký

Giao tiếp MQTT gồm bên xuất bản (Publisher) tạo thông điệp, bên đăng ký (Subscriber) nhận thông điệp và broker trung chuyển giữa hai bên, chịu trách nhiệm định tuyến·phiên·QoS. Bên xuất bản và bên đăng ký được gọi chung là client, và một client có thể đồng thời là bên xuất bản lẫn bên đăng ký. Mọi thông điệp bắt buộc phải đi qua broker nên broker là xương sống của hệ thống và có thể trở thành điểm lỗi đơn (SPOF), vì vậy trong thực tiễn việc phân cụm và dự phòng broker là bắt buộc.

graph LR
    P1["Cảm biến nhiệt độ (Publisher)"] -->|"publish: home/room1/temp"| B["MQTT Broker (trung chuyển·định tuyến)"]
    P2["Cảm biến cửa (Publisher)"] -->|"publish: home/door"| B
    B -->|"deliver"| S1["Ứng dụng di động (Subscriber)"]
    B -->|"deliver"| S2["Máy chủ phân tích (Subscriber)"]
    B -->|"deliver"| S3["Bộ điều khiển tự động (Subscriber)"]
    S1 -.->|"subscribe: home/#"| B
    S2 -.->|"subscribe: home/+/temp"| B
    S3 -.->|"subscribe: home/door"| B

Trong cấu trúc trên, bên xuất bản và bên đăng ký hoàn toàn không biết nhau mà chỉ gặp nhau qua tên chủ đề. Ví dụ, cảm biến nhiệt độ chỉ xuất bản 25.3℃ vào home/room1/temp, còn việc giá trị này được chuyển tới ai trong số ứng dụng di động·máy chủ phân tích·bộ điều khiển và bao nhiêu bản do broker quyết định bằng cách tham chiếu bảng đăng ký. Điểm trung tâm của quan hệ là chủ đề chứ không phải nút khác căn bản với tư duy lấy endpoint làm trung tâm của REST API, và kết hợp tự nhiên với kiến trúc hướng sự kiện (EDA).

A. Chủ đề (Topic) và ký tự đại diện

Chủ đề là địa chỉ đồng thời là hệ thống phân loại của thông điệp, là chuỗi phân tách các cấp bằng dấu gạch chéo (/) (ví dụ: factory/line2/machine5/vibration). Chủ đề không cần định nghĩa hay đăng ký trước mà được tạo động tại thời điểm xuất bản nên rất linh hoạt, nhưng ngược lại, nếu không chuẩn hóa quy tắc đặt tên (naming convention) ở cấp tổ chức thì chủ đề sẽ tràn lan khiến vận hành khó khăn. Trong thực tiễn, người ta lập tài liệu thiết kế phân cấp thu hẹp dần từ trên xuống như country/factory/line/device/metric, cùng các quy ước như cấm dấu gạch chéo đầu (/) hay khoảng trắng.

Bên đăng ký dùng hai ký tự đại diện để đăng ký nhiều chủ đề cùng lúc. Ký tự đại diện một cấp + thay thế đúng một cấp, nên home/+/temp khớp với home/room1/temp·home/room2/temp; ký tự đại diện nhiều cấp # bao trùm mọi cấp bên dưới, nên home/# đăng ký toàn bộ cấp dưới home (bắt buộc nằm ở cuối chủ đề). Ký tự đại diện chỉ dùng được khi đăng ký, không dùng được trong chủ đề xuất bản. Ví dụ, dashboard giám sát nhà máy có thể chỉ thu thập có chọn lọc giá trị rung của mọi dây chuyền·thiết bị bằng factory/+/+/vibration, nên thiết kế chủ đề chính là thiết kế lọc dữ liệu.

B. Ba mức QoS (chất lượng dịch vụ)

Chức năng đặc trưng nhất của MQTT là QoS — lựa chọn mức độ tin cậy theo từng thông điệp. Bản thân TCP đã cung cấp độ tin cậy, nhưng để bảo đảm cả kịch bản kết nối lại·trùng lặp·thất lạc từ góc nhìn ứng dụng, giao thức đặt thêm thủ tục xác nhận riêng ở tầng giao thức. Ở mỗi mức, độ tin cậy và chi phí tỷ lệ nghịch chính xác với nhau, nên người thiết kế phải quyết định đánh đổi phù hợp với tính chất dữ liệu.

sequenceDiagram
    participant Pub as Publisher
    participant Brk as Broker
    Note over Pub,Brk: QoS 0 - tối đa 1 lần (Fire and Forget)
    Pub->>Brk: PUBLISH
    Note over Pub,Brk: QoS 1 - ít nhất 1 lần (có thể trùng)
    Pub->>Brk: PUBLISH
    Brk-->>Pub: PUBACK
    Note over Pub,Brk: QoS 2 - chính xác 1 lần (4-way)
    Pub->>Brk: PUBLISH
    Brk-->>Pub: PUBREC
    Pub->>Brk: PUBREL
    Brk-->>Pub: PUBCOMP

QoS 0 (At most once) là phương thức gửi một lần không cần phản hồi rồi quên, chấp nhận thất lạc nhưng chi phí nhỏ nhất. Phù hợp với dữ liệu đo từ xa tần suất cao mà thiếu một hai bản ghi cũng không sao, như nhiệt độ·độ sáng cập nhật hàng chục lần mỗi giây. QoS 1 (At least once) gửi lại cho tới khi nhận được PUBACK từ phía nhận nên không thất lạc, nhưng trong quá trình gửi lại có thể phát sinh nhận trùng lặp, nên ứng dụng phải bảo đảm tính lũy đẳng (idempotency). QoS 2 (Exactly once) loại bỏ cả trùng lặp lẫn thất lạc bằng bắt tay 4 bước PUBLISH→PUBREC→PUBREL→PUBCOMP, nhưng cần hai vòng khứ hồi nên độ trễ và tải lớn nhất. Chỉ dùng có giới hạn khi bắt buộc phải truyền chính xác đúng một lần như thanh toán·tính cước·truyền lệnh. Ví dụ, thiết kế thực tiễn điển hình là dùng lẫn: giá trị đọc công tơ 15 phút của đồng hồ thông minh gắn trực tiếp với tính cước nên dùng QoS 2, còn biểu đồ giám sát điện năng thời gian thực dùng QoS 0.

C. Chức năng quản lý phiên: LWT · Retain · Keep Alive

MQTT lấy môi trường không dây·di động không ổn định làm tiền đề nên có ba cơ chế quản lý trạng thái kết nối. Thứ nhất, thông điệp di chúc (LWT, Last Will and Testament) là thông điệp client đăng ký trước khi kết nối; nếu client đó mất kết nối bất thường, broker sẽ xuất bản thay. Ví dụ, nếu cảm biến đăng ký di chúc status/sensor7 = offline thì dù đột ngột biến mất do hết pin, hệ thống giám sát vẫn lập tức nhận biết sự cố. Thứ hai, thông điệp lưu giữ (Retained Message) là chức năng broker lưu 1 thông điệp mới nhất theo từng chủ đề và chuyển ngay cho client mới đăng ký, nhờ đó nút kết nối sau cũng biết ngay giá trị trạng thái cuối cùng mà không cần polling. Thứ ba, Keep Alive là cơ chế client gửi PINGREQ trong chu kỳ đã chỉ định để báo kết nối còn sống; nếu không có tín hiệu trong khoảng 1,5 lần thời gian đó, broker coi kết nối đã mất và xuất bản LWT khi cần. Kết hợp ba chức năng này, MQTT duy trì tính nhất quán trạng thái ngay cả trong môi trường hàng chục nghìn nút liên tục kết nối·rời đi.

3. Quy trình truyền thông và ngăn xếp giao thức

MQTT hoạt động trên TCP/IP, cổng mặc định là 1883 cho văn bản rõ và 8883 khi mã hóa TLS. Giao tiếp luôn bắt đầu bằng thiết lập kết nối: client gửi CONNECT tới broker và broker phản hồi bằng CONNACK. Gói CONNECT chứa định danh client (Client ID), thông tin xác thực (username/password), chu kỳ Keep Alive, cờ Clean Session, thiết lập LWT. Sau đó client tự do trao đổi SUBSCRIBE/PUBLISH và gửi DISCONNECT khi kết thúc.

Xem toàn bộ vòng đời kết nối dưới dạng tuần tự như sau. Có thể thấy cấu trúc trong đó sau khi thiết lập kết nối, đăng ký và xuất bản diễn ra đan xen, còn Keep Alive duy trì kết nối ở nền.

sequenceDiagram
    participant C as Client
    participant B as Broker
    C->>B: CONNECT(ClientID·xác thực·LWT·KeepAlive)
    B-->>C: CONNACK(có phiên hay không·Reason Code)
    C->>B: SUBSCRIBE(topic, QoS)
    B-->>C: SUBACK(QoS được chấp thuận)
    Note over C,B: Sau đó trao đổi PUBLISH hai chiều
    B-->>C: PUBLISH(đẩy thông điệp của chủ đề đã đăng ký)
    C->>B: PINGREQ(chu kỳ KeepAlive)
    B-->>C: PINGRESP
    C->>B: DISCONNECT(kết thúc bình thường)
    Note over C,B: Khi kết thúc bất thường Broker xuất bản LWT

Xem luồng lệnh MQTT cùng với các tầng như sau.

Tầng	Giao thức/Công nghệ	Vai trò
Ứng dụng	MQTT	Xuất bản/đăng ký, QoS, quản lý phiên
Bảo mật	TLS/SSL	Bí mật·toàn vẹn·xác thực server/client
Giao vận	TCP(1883/8883)	Luồng tin cậy bảo đảm thứ tự
Mạng	IP	Định tuyến·đánh địa chỉ

Cờ Clean Session (3.1.1)/Clean Start·Session Expiry (5.0) quyết định có tiếp tục phiên trước khi kết nối lại hay không. Nếu đặt Clean Session là false, broker giữ thông điệp QoS 1·2 trong hàng đợi trong thời gian ngoại tuyến rồi chuyển khi kết nối lại, nên các nút di động·công suất thấp kết nối không liên tục không bỏ lỡ thông điệp. Ngược lại, nếu đặt true thì mỗi lần bắt đầu phiên mới và không để lại trạng thái.

Ngoài ra, với mạng cảm biến siêu tiết kiệm điện mà ngay cả TCP cũng là gánh nặng, tồn tại biến thể MQTT-SN (MQTT for Sensor Networks). MQTT-SN hoạt động trên các phương tiện không phải TCP như UDP·ZigBee, dùng ID chủ đề 2 byte thay cho chuỗi chủ đề dài, và gateway chuyển đổi giữa MQTT-SN với MQTT chuẩn. Đây là thiết kế phản ánh ràng buộc thực tế của nút cảm biến không dây phải chạy bằng pin trong nhiều năm.

Xem cụ thể tính nhẹ của MQTT từ góc độ cấu trúc gói: mọi gói điều khiển bắt đầu bằng header cố định (Fixed Header) tối thiểu 2 byte. 4 bit cao của byte đầu biểu thị loại gói (14 loại như CONNECT·PUBLISH), 4 bit thấp biểu thị cờ (DUP·QoS·RETAIN), và trường độ dài biến đổi tiếp theo mã hóa độ dài còn lại. Sau đó chỉ khi cần mới gắn header biến đổi và payload. Khác với HTTP tiêu tốn hàng trăm byte header văn bản cho một yêu cầu, lý do chi phí của MQTT PUBLISH chỉ vài byte nằm chính ở thiết kế khung nhị phân nén cực độ này. Trong môi trường hàng trăm nghìn nút xuất bản hàng nghìn bản ghi mỗi giây, khác biệt này dẫn tới chênh lệch lớn về băng thông·điện năng·chi phí tiếp nhận trên đám mây.

4. So sánh với các giao thức tương tự

Để hiểu vị trí của MQTT, cần xem sự khác biệt với các giao thức cạnh tranh·bổ trợ cùng với lý do tạo ra khác biệt. So với HTTP, HTTP dựa trên yêu cầu/phản hồi nên server khó chủ động đẩy dữ liệu tới client và header lớn tiêu hao pin·băng thông, trong khi MQTT bảo đảm tính thời gian thực và hiệu quả bằng kết nối thường trực và server push. Tuy nhiên HTTP đi trước về khả năng qua tường lửa·caching·độ trưởng thành hệ sinh thái, nên với truyền tệp dung lượng lớn hay API công khai thì HTTP/REST vẫn có lợi hơn.

CoAP (Constrained Application Protocol) là kiểu REST yêu cầu/phản hồi dựa trên UDP, mạnh ở giao tiếp trực tiếp giữa các nút không cần broker và chi phí còn nhỏ hơn, nhưng trong kịch bản cần xuất bản/đăng ký nhiều-nhiều và duy trì trạng thái thì MQTT chiếm ưu thế. AMQP là tiêu chuẩn nhắn tin doanh nghiệp nặng cung cấp giao dịch·định tuyến·hàng đợi ở cấp ngành tài chính, độ tin cậy cao nhưng quá nặng cho thiết bị đầu cuối IoT. Trong khi đó Kafka chuyên về lưu giữ·phát lại trên đĩa luồng log·sự kiện hàng triệu bản ghi mỗi giây, nên mô hình lai MQTT+Kafka — chuyển dữ liệu đầu cuối do MQTT thu thập sang Kafka tại gateway để nối với pipeline phân tích quy mô lớn — là cách làm chuẩn trong thực tiễn.

Phân loại	MQTT	CoAP	HTTP	AMQP
Mô hình giao tiếp	Pub/Sub	Req/Resp(REST)	Req/Resp	Pub/Sub·hàng đợi
Giao vận	TCP	UDP	TCP	TCP
Chi phí header	Rất nhỏ (2B~)	Nhỏ (4B~)	Lớn	Trung bình
QoS	0/1/2	Confirmable/Non	Không có	Giao dịch
Broker	Bắt buộc	Không cần	Không cần	Bắt buộc
Mục đích chính	Thu thập IoT thời gian thực	REST cho nút hạn chế	Web·API công khai	Tài chính doanh nghiệp

Xét áp dụng công nghiệp thực tế, AWS IoT Core·Azure IoT Hub·Google Cloud IoT đều chọn MQTT làm giao thức mặc định cho kết nối thiết bị; xe kết nối dùng MQTT rộng rãi cho đo từ xa xe-đám mây, nhà máy thông minh dùng cho thu thập dữ liệu thiết bị kết hợp OPC-UA. Ví dụ, trường hợp phiên bản đầu của Facebook Messenger chọn MQTT để tiết kiệm pin di động cho thấy giao thức này hữu hiệu cả với giao tiếp thời gian thực di động vượt ra ngoài IoT.

Xem ví dụ về lợi ích định lượng: giả sử cảm biến từ xa chạy pin báo trạng thái về server mỗi 30 giây, phương thức polling HTTPS phải lặp lại bắt tay TCP 3 bước, thương lượng TLS, hàng trăm byte header yêu cầu·phản hồi ở mỗi chu kỳ, còn MQTT chỉ thiết lập kết nối một lần đầu rồi chỉ gửi PUBLISH vài byte trên phiên thường trực. Trong các trường hợp đo thực tế của nhiều nhà cung cấp, phương thức này được báo cáo giảm lưu lượng mạng và điện năng tiêu thụ vài lần trở lên trên cùng lượng dữ liệu truyền, và ở quy mô hàng chục nghìn thiết bị, điều này dẫn trực tiếp tới chênh lệch tổng chi phí sở hữu (TCO) về cước truyền thông và chu kỳ thay pin. Tuy nhiên, mức tiết kiệm chính xác thay đổi theo kích thước payload·chu kỳ·chất lượng đường truyền nên cần thận trọng khi khái quát hóa.

5. Chuyên sâu: sự tiến hóa của MQTT 5.0 và xu hướng mới nhất

MQTT 5.0 được chuẩn hóa năm 2019 đã bổ sung hàng loạt chức năng doanh nghiệp, khắc phục các giới hạn của 3.1.1 bộc lộ trong vận hành IoT quy mô lớn. Thứ nhất, đưa vào Reason Code và User Property để trả về chi tiết nguyên nhân thất bại kết nối·xuất bản và cho phép gắn siêu dữ liệu tùy ý (khóa-giá trị) vào thông điệp, tách ngữ cảnh vốn bị nhét gượng ép vào payload ứng dụng ra thành header giao thức. Thứ hai, đăng ký chia sẻ (Shared Subscription) theo dạng $share/group/topic cho phép nhiều bên đăng ký cùng nhóm chia nhau nhận thông điệp, giải quyết vấn đề tải dồn vào một bên đăng ký duy nhất và hỗ trợ mở rộng ngang phía tiêu thụ (cân bằng tải) ở cấp giao thức. Thứ ba, bí danh chủ đề (Topic Alias) thay chuỗi chủ đề dài bằng số nguyên 2 byte để tiết kiệm băng thông khi gửi lặp lại, và hết hạn thông điệp (Message Expiry Interval) ngăn lệnh cũ được chuyển muộn gây vận hành sai. Thứ tư, chính thức hỗ trợ mẫu yêu cầu/phản hồi (Response Topic·Correlation Data), chuẩn hóa tương tác kiểu RPC trên nền xuất bản/đăng ký, và bằng điều khiển luồng (Receive Maximum) giúp bên đăng ký chậm không bị broker áp đảo.

Về xu hướng mới nhất, các tổ chức tiêu chuẩn công nghiệp đã chấp nhận đặc tả Sparkplug B — đặt quy ước cấu trúc dữ liệu và quản lý trạng thái lên trên MQTT — để nâng cao khả năng tương tác của nhà máy thông minh; MQTT qua WebSocket (kết nối trực tiếp từ trình duyệt), cùng mở rộng siêu quy mô thông qua phân cụm broker·bridging edge-đám mây đang được áp dụng sôi nổi. Tại Hàn Quốc, MQTT cũng được dùng như tiêu chuẩn trên thực tế của tầng thu thập dữ liệu trong hạ tầng thành phố thông minh·bản sao số (digital twin)·AMI điện lực (đọc công tơ từ xa), nên từ góc nhìn Kỹ sư chuyên nghiệp Quản lý Thông tin cần hiểu MQTT không chỉ là giao thức đơn thuần mà là xương sống thu thập·liên kết dữ liệu của kiến trúc nền tảng IoT.

6. Lưu ý và hàm ý

Khi áp dụng MQTT vào hệ thống thực tế, Kỹ sư chuyên nghiệp cần xem xét tổng hợp các góc nhìn sau.

Thứ nhất, tăng cường bảo mật là bắt buộc chứ không phải lựa chọn. Bản thân MQTT là giao thức văn bản rõ nên bắt buộc phải mã hóa đoạn truyền bằng TLS (8883), và ngoài xác thực dựa trên Client ID·username/password cần áp dụng xác thực lẫn nhau dựa trên chứng chỉ X.509·token OAuth. Ngoài ra, nếu không giới hạn chủ đề mà một client cụ thể được xuất bản·đăng ký bằng kiểm soát truy cập theo chủ đề (ACL), chỉ một nút bị chiếm quyền có thể nghe lén·làm ô nhiễm toàn bộ chủ đề. Bỏ qua bảo mật với lý do tính nhẹ là nguyên nhân sự cố phổ biến nhất.

Thứ hai, phải bảo đảm tính sẵn sàng và khả năng mở rộng của broker ngay từ đầu thiết kế. Do cấu trúc mọi lưu lượng đều đi qua broker, broker vừa là SPOF vừa là nút cổ chai hiệu năng, nên phải lên kế hoạch mở rộng ngang bằng phân cụm·dự phòng broker cùng với mở rộng phía tiêu thụ nhờ đăng ký chia sẻ, và topology bridging nối broker edge với broker trung tâm.

Thứ ba, lựa chọn thận trọng chính sách QoS và phiên quyết định chi phí và độ tin cậy. Nếu lạm dụng QoS 2 và Clean Session=false cho mọi thông điệp, tải lưu trữ·gửi lại của broker sẽ bùng nổ. Cần thiết kế chính sách phân loại mức quan trọng và mức chấp nhận thất lạc của dữ liệu, áp dụng phân biệt QoS 0 cho dữ liệu đo từ xa, QoS 1~2 cho trạng thái·lệnh, và quyết định duy trì phiên hay không theo đặc tính nút.

Thứ tư, chuẩn hóa đặt tên chủ đề và quản trị quyết định khả năng vận hành dài hạn. Sự linh hoạt cho phép tạo chủ đề tự do sẽ dẫn tới hỗn loạn không thể quản lý nếu không có tiêu chuẩn, nên phải lập tài liệu ở cấp tổ chức về quy tắc đặt tên phân cấp·không gian tên·quản lý phiên bản và liên kết với hệ thống quản trị dữ liệu.

Thứ năm, phải vạch ra đồng thời chiến lược tích hợp với công nghệ liên kết. MQTT là giao thức tối ưu cho thu thập ở đầu cuối, nên chỉ khi thiết kế kiến trúc từ góc nhìn pipeline dữ liệu đầu-cuối (End-to-End) bao gồm liên kết với xử lý luồng (Kafka)·lưu trữ chuỗi thời gian (TSDB)·phân tích thời gian thực·bản sao số sau khi thu thập thì mới tạo ra giá trị thực chất.

Tổng hợp lại, MQTT phải được hiểu là tiêu chuẩn tầng thu thập của kiến trúc dữ liệu IoT, vượt ra ngoài một quy ước giao tiếp đơn thuần, và không được bỏ qua rằng ưu điểm tính nhẹ của giao thức luôn gắn liền với các bài toán vận hành là bảo mật·tính sẵn sàng·quản trị. Đặc biệt, trong thời đại siêu kết nối (Hyper-connectivity), khi số thiết bị tăng theo cấp số nhân, mức độ trưởng thành của hệ thống vận hành quy mô lớn (mở rộng·bảo mật·khả năng quan sát) quyết định thành bại của dự án hơn là việc chọn giao thức. Trong tương lai, dự kiến MQTT sẽ kết hợp với 5G·điện toán biên để mở rộng sang điều khiển siêu độ trễ thấp, và điều khiển thông minh hai chiều tận dụng chức năng yêu cầu/phản hồi·đăng ký chia sẻ của MQTT 5.0 sẽ lan rộng; Kỹ sư chuyên nghiệp phải có khả năng phán đoán định lượng đánh đổi giữa độ tin cậy yêu cầu·chi phí·khả năng mở rộng trong dòng chảy này để đề xuất kiến trúc tối ưu.

Tài liệu tham khảo

OASIS, "MQTT Version 5.0 Specification" (2019). https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
OASIS, "MQTT Version 3.1.1" / ISO/IEC 20922:2016. https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html
MQTT.org, "MQTT: The Standard for IoT Messaging". https://mqtt.org/
HiveMQ, loạt bài "MQTT Essentials". https://www.hivemq.com/mqtt-essentials/

Tóm tắt một câu: MQTT là tiêu chuẩn nhắn tin IoT cung cấp giao tiếp nhẹ·tin cậy trong môi trường hạn chế bằng xuất bản/đăng ký dựa trên broker cùng QoS 0/1/2·LWT·Retain, và là xương sống thu thập dữ liệu có khả năng mở rộng cấp doanh nghiệp nhờ đăng ký chia sẻ·User Property của phiên bản 5.0.