Giao thức MQTT trong IoT là gì ? Những ứng dụng của MQTT như thế nào!

MQTT là gì ?

MQTT = Message Queue Telemetry Transport

Đây là một giao thức truyền thông điệp (message) theo mô hình publish/subscribe (xuất bản – theo dõi), sử dụng băng thông thấp, độ tin cậy cao và có khả năng hoạt động trong điều kiện đường truyền không ổn định.

MQTT là một giao thức nhắn tin gọn nhẹ được thiết kế để liên lạc nhẹ giữa các thiết bị và hệ thống máy tính. MQTT được thiết kế ban đầu cho các mạng SCADA, các kịch bản sản xuất và băng thông thấp, MQTT đã trở nên phổ biến gần đây do sự phát triển của Internet-of-Things (IoT).

Kiến trúc mức cao (high-level) của MQTT gồm 2 phần chính là Broker và Clients.

Trong đó, broker được coi như trung tâm, nó là điểm giao của tất cả các kết nối đến từ client. Nhiệm vụ chính của broker là nhận mesage từ publisher, xếp các message theo hàng đợi rồi chuyển chúng tới một địa chỉ cụ thể. Nhiệm vụ phụ của broker là nó có thể đảm nhận thêm một vài tính năng liên quan tới quá trình truyền thông như: bảo mật message, lưu trữ message, logs,…

Client thì được chia thành 2 nhóm là publisher và subscriber. Client là các software components hoạt động tại edge device  nên chúng được thiết kế để có thể hoạt động một cách linh hoạt (lightweight). Client chỉ làm ít nhất một trong 2 việc là publish các message lên một topic cụ thể hoặc subscribe một topic nào đó để nhận message từ topic này.

MQTT Broker

MQTT Clients tương thích với hầu hết các nền tảng hệ điều hành hiện có: MAC OS, Windows, LInux, Androids, iOS…

Các bạn có thể tưởng tượng broker giống như một sạp báo. Publisher là các tòa soạn báo. Tòa soạn in báo và chuyển cho sạp báo. Người đọc báo đến sạp báo, chọn tờ báo mình cần đọc (subscriber).

Bởi vì giao thức này sử dụng băng thông thấp trong môi trường có độ trễ cao nên nó là một giao thức lý tưởng cho các ứng dụng M2M (Machine to machine)

Ưu điểm của MQTT là gì?

Giao thức MQTT cho phép hệ thống SCADA của bạn truy cập dữ liệu IIoT. MQTT mang lại nhiều lợi ích mạnh mẽ cho quy trình của bạn:

• Chuyển thông tin hiệu quả hơn
• Tăng khả năng mở rộng
• Giảm đáng kể tiêu thụ băng thông mạng
• Giảm tốc độ cập nhật xuống giây
• Rất phù hợp cho điều khiển và do thám
• Tối đa hóa băng thông có sẵn
• Chi phí cực nhẹ
• Rất an toàn với bảo mật dựa trên sự cho phép
• Được sử dụng bởi ngành công nghiệp dầu khí, Amazon, Facebook và các doanh nghiệp lớn khác
• Tiết kiệm thời gian phát triển
• Giao thức publish/subscribe thu thập nhiều dữ liệu hơn với ít băng thông hơn so với giao thức cũ.

Publish, subscribe

Trong một hệ thống sử dụng giao thức MQTT, nhiều node trạm (gọi là mqtt client – gọi tắt là client) kết nối tới một MQTT server (gọi là broker). Mỗi client sẽ đăng ký một vài kênh (topic), ví dụ như “/client1/channel1”, “/client1/channel2”. Quá trình đăng ký này gọi là “subscribe”, giống như chúng ta đăng ký nhận tin trên một kênh Youtube vậy. Mỗi client sẽ nhận được dữ liệu khi bất kỳ trạm nào khác gởi dữ liệu và kênh đã đăng ký. Khi một client gởi dữ liệu tới kênh đó, gọi là “publish”.

QoS

Ở đây có 3 tuỳ chọn QoS (Qualities of service) khi “publish” và “subscribe”:

• QoS0 Broker/client sẽ gởi dữ liệu đúng 1 lần, quá trình gởi được xác nhận bởi chỉ giao thức TCP/IP, giống kiểu đem con bỏ chợ.
• QoS1 Broker/client sẽ gởi dữ liệu với ít nhất 1 lần xác nhận từ đầu kia, nghĩa là có thể có nhiều hơn 1 lần xác nhận đã nhận được dữ liệu.
• QoS2 Broker/client đảm bảm khi gởi dữ liệu thì phía nhận chỉ nhận được đúng 1 lần, quá trình này phải trải qua 4 bước bắt tay.

Một gói tin có thể được gởi ở bất kỳ QoS nào, và các client cũng có thể subscribe với bất kỳ yêu cầu QoS nào. Có nghĩa là client sẽ lựa chọn QoS tối đa mà nó có để nhận tin. Ví dụ, nếu 1 gói dữ liệu được publish với QoS2, và client subscribe với QoS0, thì gói dữ liệu được nhận về client này sẽ được broker gởi với QoS0, và 1 client khác đăng ký cùng kênh này với QoS 2, thì nó sẽ được Broker gởi dữ liệu với QoS2.

Một ví dụ khác, nếu 1 client subscribe với QoS2 và gói dữ liệu gởi vào kênh đó publish với QoS0 thì client đó sẽ được Broker gởi dữ liệu với QoS0. QoS càng cao thì càng đáng tin cậy, đồng thời độ trễ và băng thông đòi hỏi cũng cao hơn.

Retain

Retain là một cờ (flag) được gắn cho một message của giao thức MQTT. Retain chỉ nhận giá trị 0 hoặc 1 (tương ứng 2 giá trị logic false hoặc true). Nếu retain = 1, broker sẽ lưu lại message cuối cùng của 1 topic kèm theo mức QoS tương ứng. Khi client bắt đầu subscribe topic có message được lưu lại đó, client ngay lập tức nhận được message.

MQTT Bridge

MQTT Bridge là một tính năng của MQTT Broker cho phép các MQTT Broker có thể kết nối và trao đổi dữ liệu với nhau. Để sử dụng tính năng này, ta cần tối thiểu 2 Broker, trong đó, một Broker bất kỳ sẽ được cấu hình thành Bridge. Khi cấu hình MQTT bridge, ta cần lưu ý tới các thông số sau:

• address: địa chỉ của broker cần kết nối
• bridge_protocol_version: phiên bản của giao thức MQTT đang sử dụng chung cho 2 broker
• topic: phần này định nghĩa 3 thong số: tên topic được trao đổi giữa 2 broker, chiều trao đổi (1 chiều hay 2 chiều) và topic mapping giữa 2 broker

MQTT Bridge

Bảo mật

MQTT được thiết kế một cách nhẹ và linh hoạt nhất có thể. Do đó nó chỉ có 1 lớp bảo mật ở tầng ứng dụng: bảo mật bằng xác thực (xác thực các client được quyền truy cập tới broker).

Tuy vậy, MQTT vãn có thể được cài đặt kết hợp với các giải pháp bảo mật đa tầng khác như kết hợp với VPN ở tầng mạng hoặc SSL/TLS ở tầng transport.

MQTT được thiết kế nhằm phục vụ truyền thông machine-to-machine nhưng thực tế chứng minh nó lại linh hoạt hơn mong đợi. Nó hoàn toàn có thể áp dụng cho các kịch bản truyền thông khác như: machine-to-cloud, cloud-to-machine, app-to-app. Chỉ cần có một broker phù hợp và MQTT client được cài đặt đúng cách, các thiết bị xây dựng trên nhiều nền tảng khác nhau có thể giao tiếp với nhau một cách dễ dàng.

Giao thức MQTT ra đời năm 1999 và tính đến thời điểm hiện tại, MQTT phiên bản 3.1.1 được công nhận chuẩn OASIS.

Ứng dụng của MQTT

Có một số dự án thực hiện MQTT. Ví dụ là:

• Facebook Messenger . Facebook đã sử dụng các khía cạnh của MQTT trong Facebook Messenger để trò chuyện trực tuyến . Tuy nhiên, không rõ MQTT được sử dụng bao nhiêu hoặc để làm gì.
• IECC Scalable , DeltaRail phiên bản mới nhất của hệ thống kiểm soát hiệu IECC của họ ‘s sử dụng MQTT cho thông tin liên lạc trong các phần khác nhau của hệ thống và các thành phần khác của hệ thống báo hiệu. Nó cung cấp khung truyền thông cơ bản cho một hệ thống tuân thủ các tiêu chuẩn CENELEC cho các thông tin liên lạc quan trọng về an toàn.
• Amazon Web Services đã công bố Amazon IoT dựa trên MQTT vào năm 2015. ^[17] [18]
• Các tổ chức không gian địa lý SensorThings API đặc điểm kỹ thuật tiêu chuẩn có một phần mở rộng MQTT trong tiêu chuẩn như một giao thức thông báo bổ sung ràng buộc. Nó đã được chứng minh trong một thí điểm IoT của Bộ An ninh Nội địa Hoa Kỳ.
• Các dịch vụ của Cơ sở hạ tầng thượng nguồn OpenStack được kết nối bằng một bus tin nhắn hợp nhất MQTT với Mosquitto là broker MQTT.
• Adafruit đưa ra một MQTT miễn phí dịch vụ đám mây cho thí nghiệm IOT và người học gọi Adafruit IO trong năm 2015.
• Microsoft Azure IoT Hub sử dụng MQTT làm giao thức chính cho các tin nhắn từ xa .
• XIM, Inc. đã ra mắt ứng dụng khách MQTT có tên MQTT Buddy vào năm 2017. Đây là ứng dụng MQTT dành cho Android và iOS , nhưng không phải là F-Droid , người dùng có sẵn bằng tiếng Anh, tiếng Nga và tiếng Trung Quốc.
• Node-RED hỗ trợ các nút MQTT kể từ phiên bản 0.14, để định cấu hình đúng các kết nối TLS . ^[26]
• Nền tảng tự động hóa phần mềm nguồn mở Home Assistant được bật MQTT và cung cấp bốn tùy chọn cho các broker MQTT.

Apache Kafka là gì? Tìm hiểu và ứng dụng Apache Kafka cho hệ thống IoT

Case Studies Giao tiếp giữa iOS và Raspberry Pi bằng MQTT

Giả sử bạn có đèn LED được kết nối với pin GPIO của Raspberry và bạn muốn bật và tắt. Một cách để giải quyết vấn đề này là sử dụng một nút. Bạn kết nối một nút với một pin GPIO khác. Từ đây, bạn sẽ tạo một chương trình phát hiện các thay đổi trong trạng thái của nút và xác định nên bật hay tắt đèn LED. Điều này sẽ dễ dàng thực hiện được. Tuy nhiên, nếu bạn ở xa nút bấm đó thì sao? Sẽ thật rắc rối khi quay trở lại Raspberry Pi và nhấn nút để bật hoặc tắt đèn LED. Sẽ không hay chút nào nếu bạn có thể bật hoặc tắt đèn LED từ xa từ một thiết bị di động như iPhone hoặc iPad ?

Đối với hướng dẫn này, một thiết bị iOS và Raspberry Pi sẽ là client. Những client này sẽ kết nối với máy chủ MQTT. Câu hỏi là, máy chủ MQTT ở đâu ?

Điều này nghe có vẻ lạ, nhưng Raspberry Pi là máy chủ MQTT. Nói cách khác, Raspberry Pi là máy khách và là máy chủ MQTT cùng một lúc. Nó sẽ giao tiếp với chính nó.

Để rõ ràng hơn, máy chủ MQTT chỉ đơn giản là một chương trình sẽ chạy trong nền trên Raspberry Pi. Máy chủ MQTT sẽ nhận các tin nhắn được gửi bởi các máy khách và gửi chúng đến các máy khách khác được kết nối với máy chủ MQTT. Một client gửi tin nhắn được gọi là một publisher . Một client nhận được tin nhắn được gọi là một thuê bao. Mỗi tin nhắn được gửi bởi một publisher có chứa một threads. Một thuê bao được đăng ký (hoặc đăng ký) vào threads đó sẽ nhận được tin nhắn. Trong ví dụ này, giả sử rằng publisher là thiết bị iOS và subscriberlà Raspberry Pi. Thông báo được tạo bởi publisher có threads “resetGPIO” và Raspberry Pi được đăng ký với threads “resetGPIO”.

Như bạn có thể thấy từ hình ảnh trên cùng, thiết bị iOS là publisher . Nó sẽ gửi một tin nhắn với threads “resetGPIO”. Thông báo này được nhận bởi máy chủ MQTT. Máy chủ MQTT tìm kiếm thuê bao được đăng ký theo threads của tin nhắn. Vì Raspberry Pi được đăng ký vào threads “resetGPIO”, máy chủ MQTT sẽ gửi tin nhắn đến chính Raspberry Pi và tin nhắn được gửi thành công. Bây giờ, điều gì xảy ra nếu publisher gửi tin nhắn có threads mà không có subscribernào được đăng ký?

Thông điệp chỉ đơn giản là bị ném ra ngoài vì không có đích đến cho nó.

Vì chúng ta đang thảo luận về việc gửi tin nhắn từ publisher đến một thuê bao, client có thể là publisher và thuê bao cùng một lúc không? Câu trả lời là có! Giả sử rằng một thiết bị iOS xuất bản đến threads “resetGPIO” và được đăng ký vào threads “sensorData”. Raspberry Pi xuất bản đến threads “sensorData” và được đăng ký vào threads “resetGPIO”.

Từ hình ảnh trên cùng, thiết bị iOS sẽ gửi một tin nhắn với threads “resetGPIO” và được máy chủ MQTT nhận được. Vì bản thân Raspberry Pi đã được đăng ký vào threads “resetGPIO”, máy chủ MQTT sẽ gửi tin nhắn đến chính nó và tin nhắn được gửi thành công. Raspberry Pi gửi một tin nhắn với threads “sensorData” và vì máy chủ MQTT đang chạy trên chính Raspberry Pi, nó sẽ gửi tin nhắn đến chính nó. Vì thiết bị iOS được đăng ký threads “sensorData”, máy chủ MQTT sẽ gửi tin nhắn đến thiết bị iOS và tin nhắn được gửi thành công.

Nghe có vẻ khó hiểu? Nếu vậy, điều đó tốt vì bây giờ chúng ta sẽ xem những gì đang xảy ra đằng sau hậu trường. Điều này sẽ làm sáng tỏ mọi thứ. Trong ví dụ này, chúng tôi có hai client sẽ liên lạc với nhau. Hai client là một thiết bị iOS và Raspberry Pi. Thiết bị iOS sẽ chạy một ứng dụng thực hiện giao thức MQTT trong khi Raspberry Pi sẽ chạy một chương trình thực hiện giao thức MQTT.

Ứng dụng iOS sẽ chứa code thực hiện mô hình publisher và / hoặc người đăng ký. Điều tương tự cũng xảy ra với Raspberry Pi. Chương trình Raspberry Pi thực hiện mô hình publisher và / hoặc thuê bao. Tất cả những gì còn lại là chương trình máy chủ MQTT. Raspberry Pi cũng có thể chạy chương trình máy chủ MQTT vì nó thực sự dễ dàng để khởi động và chạy trên nền tảng Raspberry Pi.

Raspberry Pi hiện đang chạy hai chương trình, máy chủ MQTT và chương trình thực hiện mô hình publisher và / hoặc thuê bao. Để giao thức MQTT hoạt động, mỗi máy khách sẽ tự đăng ký với chương trình máy chủ MQTT. client sẽ cung cấp tên, địa chỉ mạng và các threads được đăng ký, nếu có. Khi publisher (ứng dụng khách gửi tin nhắn) gửi tin nhắn, tin nhắn sẽ đến Raspberry Pi nơi máy chủ MQTT sẽ chặn tin nhắn. Máy chủ MQTT sẽ xác định threads của tin nhắn nhận được và tìm kiếm những người đăng ký đã đăng ký (client đăng ký một threads cụ thể) đã đăng ký threads đó. Nếu chính Raspberry Pi được đăng ký vào threads đó, thì máy chủ MQTT sẽ gửi tin nhắn đến chính Raspberry Pi nhưng bây giờ tin nhắn sẽ được nhận bởi chương trình Raspberry Pi. Điều này giải thích tại sao Raspberry Pi gửi tin nhắn đến chính nó. Đó là để gửi tin nhắn đến chương trình máy chủ MQTT hoặc cho chương trình Raspberry Pi để nhận tin nhắn được gửi bởi máy chủ MQTT.

Điều cuối cùng mà bạn có thể tự hỏi là, chính xác thì một tin nhắn chứa gì? Rất đơn giản, một threads và một thông điệp! Nhưng từ góc độ code hóa, threads và thông điệp chỉ đơn giản là các chuỗi như “1234567890” hoặc “on-off” hoặc “true” hoặc “tv đang bật”.

Nguồn tham khảo smartfactoryvn.com