THIẾT KẾ VÀ TRIỂN KHAI HỆ THỐNG IOT
SỬ DỤNG CÁC GIAO THỨC
MQTT, HTTP VÀ WEBSOCKET
LUẬN VĂN KỸ SƯ
Trần Phương Tùng - 1810646
Giảng viên hướng dẫn
TS. Võ Quế Sơn
ĐẠI HỌC QUỐC GIA THÀNH PHỐ HÒ CHÍ MINH
TRƯỜNG ĐẠI HỌC BÁCH KHOA
KHOA ĐIỆN – ĐIỆN TỬ, BỘ MÔN VIỄN THÔNG
6 – 2022
THIẾT KẾ VÀ TRIỂN KHAI HỆ THỐNG IOT
SỬ DỤNG CÁC GIAO THỨC
MQTT, HTTP VÀ WEBSOCKET
LUẬN VĂN KỸ SƯ
Trần Phương Tùng - 1810646
Giảng viên hướng dẫn
TS. Võ Quế Sơn
ĐẠI HỌC QUỐC GIA THÀNH PHỐ HÒ CHÍ MINH
TRƯỜNG ĐẠI HỌC BÁCH KHOA
KHOA ĐIỆN – ĐIỆN TỬ, BỘ MÔN VIỄN THÔNG
6 – 2022
i
ĐẠI HỌC QUỐC GIA TP.HỒ CHÍ MINH
CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM
TRƯỜNG ĐẠI HỌC BÁCH KHOA
Độc lập – Tự do – Hạnh phúc
Số: ______ /BKĐT
Khoa: Điện – Điện tử
Bộ Môn: Viễn Thông
NHIỆM VỤ LUẬN VĂN TỐT NGHIỆP
1.
Họ và tên: Trần Phương Tùng
MSSV: 1810646
2.
Ngành:
Chuyên ngành: Kỹ thuật Điện tử -
Điện – Điện tử
Truyền thông
3.
Đề tài: Thiết kế và triển khai hệ thống IoT sử dụng các giao thức MQTT, HTTP và
WebSocket.
4.
Nhiệm vụ:
-
Tìm hiểu các giao thức MQTT, HTTP, WebSocket
-
Thiết kế hệ thống IoT sử dụng EPS32/8266 với các giao thức trên
-
Xây dựng hoàn chỉnh hệ thống với đầy đủ các cấu hình cần thiết
-
Phân tích và đánh giá kết quả đề tài
-
Hoàn thiện demo và báo cáo kết quả
5.
Ngày giao nhiệm vụ luận văn:
20/02/2022
6.
Ngày hoàn thành nhiệm vụ:
01/6/2022
7.
Họ và tên người hướng dẫn: TS. Võ Quế Sơn, bộ môn Viễn Thông, Khoa Điện – Điện
tử
Nội dung và yêu cầu LVTN đã được thông qua Bộ Môn.
TP.HCM, ngày 31 tháng 05 năm 2022
CHỦ NHIỆM BỘ MÔN
NGƯỜI HƯỚNG DẪN CHÍNH
PSG. TS. Hà Hoàng Kha
TS. Võ Quế Sơn
ii
PHẦN DÀNH CHO KHOA, BỘ MÔN:
Người duyệt (chấm sơ bộ): ............................
Đơn vị: ...........................................................
Ngày bảo vệ : .................................................
Điểm tổng kết: ...............................................
Nơi lưu trữ luận văn: ......................................
i
LỜI CẢM ƠN
Lời đầu tiên, em xin chân thành cảm ơn đến Khoa Điện - Điện Tử trường Đại học Bách
Khoa - ĐHQG-HCM đã tạo điều kiện cho em học tập và thực hiện luận văn tốt nghiệp này.
Em xin gửi lời cảm ơn chân thành đến Tiến Sĩ Võ Quế Sơn, người đã tận tình hướng
dẫn em trong suốt quá trình học tập cũng như thực hiện luận văn tốt nghiệp này.
Em xin chân thành cảm ơn tất cả quý Thầy Cô đã nhiệt tình giảng dạy cho em trong
suốt những năm học vừa qua.
Em xin chân thành cảm ơn anh Phan Bảo Nguyên, Co-founder của công ty Pyroject
đã hướng dẫn và chỉ bảo em rất nhiều trong quá trình thực tập hè và định hướng cho luận
văn.
Em xin cảm ơn các anh chị, bạn bè đã luôn bên cạnh ủng hộ giúp đỡ khi em cần. Cảm
ơn anh Tường Huỳnh giúp em format báo cáo luận văn, cảm ơn anh Đạt Du giúp em làm
mạch nguồn cho mô hình. Cảm ơn Tiểu Bảo đã giúp mình thực hiện testbed. Cảm ơn Tường
Vy hay cùng mình đi làm luận văn và nghe mình than thở. Cảm ơn những người anh em
phòng 424 KTX Bách Khoa cũng đã giúp đỡ mình rất nhiều trong quá trình làm luận văn.
Cảm ơn cha, mẹ đã luôn quan tâm chăm sóc con, luôn tạo điều kiện tốt nhất để con
được học tập. Cảm ơn chế hai đã hỗ trợ tận tình giúp em trong nhiều việc để luận văn có thể
hoàn thiện hơn.
Cuối cùng, em xin được gửi lời cảm ơn chân thành đến những bạn bè, người thân đã
luôn ủng hộ, động viên em để em có thể có điều kiện tốt nhất cả về vật chất lẫn tinh thần để
học tập và nghiên cứu.
Tp. Hồ Chí Minh, ngày 31 tháng 05 năm 2022.
Sinh viên thực hiện
Trần Phương Tùng
ii
LỜI CAM ĐOAN
Tôi tên: Trần Phương Tùng, là sinh viên chuyên ngành Kỹ thuật Điện tử - Truyền
thông, khóa 2018, tại Đại học Quốc gia thành phố Hồ Chí Minh – Trường Đại học Bách
Khoa. Tôi xin cam đoan những nội dung sau đều là sự thật: (i) Công trình nghiên cứu này
hoàn toàn do chính tôi thực hiện; (ii) Các tài liệu và trích dẫn trong luận văn này được tham
khảo từ các nguồn thực tế, có uy tín và độ chính xác cao; (iii) Các số liệu và kết quả của
công trình này được tôi tự thực hiện một cách độc lập và trung thực.
Tp. Hồ Chí Minh, ngày 31 tháng 05 năm 2022
Trần Phương Tùng
iii
TÓM TẮT LUẬN VĂN
Luận văn với đề tài "Thiết kế và triển khai hệ thống IoT sử dụng các giao thức MQTT,
HTTP và WebSocket" thực hiện việc xây dựng một hệ thống IoT gồm đầy đủ các thành phần
cơ bản, thu thập dữ liệu từ các cảm biến ánh sáng, nhiệt độ, độ ẩm gắn trên các vi điều khiển
NodeMCU ESP32/8266 và gửi dữ liệu về server thông qua giao thức MQTT, app di động
của người dùng có thể hiển thị dữ liệu và gửi lệnh về các node. Với giao thức WebSocket,
hệ thống sử dụng ESP32CAM để stream video realtime về server và gửi đến mobile app để
hiển thị.
Nội dung luận văn gồm có các phần:
Phần 1: Cơ sở lý thuyết
Tổng quan về các giao thức được sử dụng trong hệ thống như MQTT, HTTP và
WebSocket. Cùng với đó là các kiến thức quan trọng khác được sử dụng trong luận văn như
chuẩn giao tiếp WiFi, giao thức bảo mật SSL/TLS, cơ sở dữ liệu, hàm băm…
Phần 2: Thiết kế và thực hiện
Triển khai hệ thống IoT với những công việc như sau:
-
Thiết lập EMQ X Broker trên AWS EC2 để làm server cho hệ thống, cấu hình đầy
đủ các tác vụ khác như IP tĩnh, tên miền, proxy server, CA certificate,…
-
Cấu hình mạng mesh wifi gồm các NodeMCU có kết nối cảm biến để thu thập và
gửi dữ liệu về server
-
Lập trình Web Server nhúng trên NodeMCU để cấu hình các thông số như WiFi,
MQTT và hiển thị dữ liệu nhận được.
-
Cấu hình hệ thống theo cấu trúc ACL, phân quyền các thiết bị trong hệ thống để đảm
bảo tính bảo mật và linh hoạt khi cần thay đổi hay mở rộng.
-
Lập trình ESP32CAM stream video realtime dùng giao thức WebSocket
-
Lập trình App di động để giúp người dùng kết nối với EMQ X Broker, nhận và hiển
thị dữ liệu thu được từ cảm biến, gửi lệnh bằng giọng nói và hiển thị video stream từ
ESP32CAM.
iv
Phần 3: Kết quả thực hiện và hướng phát triển
-
Xây dựng được hệ thống IoT cơ bản với các giao thức MQTT, HTTP và WebSocket.
Đánh giá kết quả thu được về các mặt chức năng, bảo mật, hiệu năng, tính ứng dụng
trong thực tiễn của hệ thống.
-
Đề ra hướng phát triển đề tài cho các dự án lớn hơn hoặc ứng dụng trong sản xuất,
thương mại hóa.
v
ABSTRACT
Thesis "Design and implementation of IoT System using MQTT, HTTP and
WebSocket" implements the construction of an IoT system including full basic components,
collecting light, temperature, humidity data from sensors to the NodeMCU ESP32/8266
microcontrollers and send data to server via MQTT protocol, user's mobile app can display
data and send commands to nodes by text or voice. With WebSocket, we uses ESP32CAM
to stream real-time video to the server and send it to the mobile app for display.
The content of the thesis includes the following parts:
Part 1: Theoretical background
Overview of the protocols used in the system such as MQTT, HTTP and WebSocket.
Along with that, there are other important knowledge used in the thesis such as WiFi
communication standards, SSL/TLS security protocols, databases, hash functions, etc.
Part 2: Design and Implementation
Deploy IoT system with the following tasks:
- Set up EMQ X Broker on AWS EC2 to serve as a server for the system, fully
configure other tasks such as static IP, domain name, proxy server, CA certificate, etc.
- Configure a wifi mesh network including NodeMCUs with sensor connections to
collect and send data to the server
- Programming embedded Web Server on NodeMCU to configure parameters such as
WiFi, MQTT and display received data.
- Configure the system according to the ACL structure, decentralize devices in the
system to ensure security and flexibility when changing or expanding.
- Programming ESP32CAM to stream realtime video using WebSocket protocol
- Programming mobile App to help users connect with EMQ X Broker, receive and
display data obtained from sensors, send voice commands turn on/off lights in mesh and
display video stream from ESP32CAM.
Part 3: Results and development
- Build basic IoT system with MQTT, HTTP and WebSocket protocols. Evaluate the
results obtained in terms of functionality, security, performance, practical applicability of
the system.
vi
- Propose a direction to develop topics for larger projects or applications in
production and commercialization.
vii
MỤC LỤC
LỜI CẢM ƠN ......................................................................................................................... I
LỜI CAM ĐOAN................................................................................................................... II
TÓM TẮT LUẬN VĂN........................................................................................................ III
ABSTRACT........................................................................................................................... V
DANH SÁCH BẢNG ............................................................................................................ X
DANH SÁCH HÌNH VẼ....................................................................................................... XI
DANH SÁCH TỪ VIẾT TẮT............................................................................................ XIV
CHƯƠNG 1: GIỚI THIỆU ĐỀ TÀI ...................................................................................... 1
1.1. Đặt vấn đề.................................................................................................................... 1
1.2. Phạm vi và phương pháp nghiên cứu .......................................................................... 2
1.3. Nhiệm vụ của luận văn ................................................................................................ 2
CHƯƠNG 2: CƠ SỞ LÝ THUYẾT ....................................................................................... 3
2.1. Công nghệ wifi ............................................................................................................ 3
Kiến trúc chuẩn 802.11 ......................................................................................... 3
Mesh Wifi ............................................................................................................. 4
2.2. Giao thức MQTT ......................................................................................................... 6
Tổng quan ............................................................................................................. 6
Cơ chế hoạt động và các thông số quan trọng ...................................................... 6
2.3. Giao thức HTTP và WebSocket ................................................................................ 10
Giao thức HTTP ................................................................................................. 10
Giao thức WebSocket ......................................................................................... 13
2.4. SSL/TLS .................................................................................................................... 14
Sơ lược về SSL/TLS ........................................................................................... 14
Cơ chế hoạt động ................................................................................................ 15
viii
2.5. Một số kiến thức liên quan ........................................................................................ 17
Hàm băm............................................................................................................. 17
MySQL ............................................................................................................... 19
CHƯƠNG 3: THIẾT KẾ VÀ THỰC HIỆN ......................................................................... 21
3.1. Triển khai EMQ X Broker ........................................................................................ 21
Sơ lược về EMQ X Broker ................................................................................. 21
Thiết lập EMQ X Broker .................................................................................... 21
Tích hợp giao thức SSL/TLS vào hệ thống EMQ X .......................................... 26
3.2. Mạng mesh wifi ......................................................................................................... 29
Phần cứng ........................................................................................................... 29
Phần mềm ........................................................................................................... 32
3.3. Camera Streaming qua giao thức WebSocket ........................................................... 33
Phần cứng ........................................................................................................... 33
Phần mềm ........................................................................................................... 34
3.4. Web Server nhúng trên ESP32 .................................................................................. 35
Yêu cầu thiết kế .................................................................................................. 35
Thực hiện Web Server ESP32 ............................................................................ 36
3.5. App di động ............................................................................................................... 39
Yêu cầu thiết kế .................................................................................................. 39
Sản phẩm android app ........................................................................................ 41
3.6. Hệ thống IoT sử dụng ACL và multiple users .......................................................... 46
ACL là gì, vì sao cần ACL trong hệ thống IoT .................................................. 46
Sử dụng ACL và Rule Engine Republish với EMQ X Broker ........................... 46
CHƯƠNG 4: KẾT QUẢ THỰC HIỆN ................................................................................ 50
4.1. Mô hình thiết kế hệ thống ......................................................................................... 50
4.2. Sản phẩm mô hình thực tế ......................................................................................... 51
ix
4.3. Camera streaming...................................................................................................... 53
4.4. Kiểm tra đánh giá hệ thống ....................................................................................... 54
Multihop test ....................................................................................................... 54
Range test ........................................................................................................... 57
CHƯƠNG 5: KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN ...................................................... 60
5.1. Nhận xét chung.......................................................................................................... 60
5.2. Ưu điểm ..................................................................................................................... 60
5.3. Nhược điểm ............................................................................................................... 61
5.4. Hướng phát triển ....................................................................................................... 61
TÀI LIỆU THAM KHẢO .................................................................................................... 63
x
DANH SÁCH BẢNG
Bảng 3.1 So sánh throughput và lantency giữa các nhà cung cấp dịch vụ MQTT .............. 21
Bảng 3.2 Memory test giữa svelte và các framework phổ biến [6] ..................................... 36
Bảng 4.1 Kết quả multihop test ........................................................................................... 56
Bảng 4.2 Kết quả range test ................................................................................................. 58
xi
DANH SÁCH HÌNH VẼ
Hình 2.1 Kiến trúc mạng LAN chuẩn IEEE 802.11 .............................................................. 3
Hình 2.2 Sơ đồ mạng mesh cơ bản ........................................................................................ 5
Hình 2.3 Sơ đồ cấu trúc mạng mesh cơ bản .......................................................................... 5
Hình 2.4 Mô hình cơ chế hoạt động của giao thức MQTT.................................................... 7
Hình 2.5 QoS mức 2 trải qua 4 bước bắt tay ......................................................................... 8
Hình 2.6 Mô hình giao tiếp giữa client và server qua giao thức HTTP ............................... 10
Hình 2.7 Cấu trúc header HTTP dùng để "upgrade" lên WebSocket .................................. 14
Hình 2.8 Giao thức SSL nằm ở vị trí giao giữa Application layer và Transport layer ........ 15
Hình 2.9 Cipher suite của phiên bản TLS 1.2 ...................................................................... 16
Hình 2.10 Sơ đồ hoạt động của hàm băm ............................................................................ 18
Hình 3.1 Instance server Ubuntu được tạo trên đám mây của Amazon EC2 ...................... 22
Hình 3.2 Dashboard EMQ X Broker ................................................................................... 22
Hình 3.3 Sơ đồ thuật toán xác thực của EMQ X Broker ..................................................... 24
Hình 3.4 Cấu hình MySQL plugin sử dụng xác thực của EMQ X Broker .......................... 24
Hình 3.5 Table MySQL tham chiếu cho quá trình xác thực của EMQ X Broker ............... 25
Hình 3.6 Sơ đồ mô hình xác thực client của EMQ X Broker .............................................. 25
Hình 3.7 Cấu hình tên miền cho server EMQ X Broker...................................................... 26
Hình 3.8 Certificate được cấp bởi LetsEncrypt ................................................................... 27
Hình 3.9 Gán các key và certificate vừa tạo vào trong file cấu hình của EMQ X............... 28
Hình 3.10 Cảm biến ánh sáng photodiode ........................................................................... 29
Hình 3.11 Cảm biến độ ẩm, nhiệt độ DHT11 ...................................................................... 30
Hình 3.12 Sơ đồ chân NodeMCU ESP8266 ........................................................................ 31
Hình 3.13 Sơ đồ chân NodeMCU ESP32 ............................................................................ 32
xii
Hình 3.14 Sơ đồ mạng mesh các node ESP32/8266 thu thập dữ liệu từ cảm biến .............. 32
Hình 3.15 Dữ liệu nhận được từ các node trong mạng mesh .............................................. 33
Hình 3.16 Sơ đồ chân ESP32-CAM .................................................................................... 34
Hình 3.17 Sơ đồ giao tiếp video streaming thông qua WebSocket ..................................... 34
Hình 3.18 Màn hình landing page của web server .............................................................. 37
Hình 3.19 Màn hình đăng nhập của web server .................................................................. 38
Hình 3.20 Giao diện dashboard của web server .................................................................. 38
Hình 3.21 Giao diện setting của web server ........................................................................ 39
Hình 3.22 Màn hình connect MQTT trên Flutter app.......................................................... 42
Hình 3.23 Màn hình thêm topic trên Flutter app ................................................................. 43
Hình 3.24 Màn hình hiển thị gói tin nhận được trên app Flutter ......................................... 43
Hình 3.25 Màn hình gửi gói tin trên Flutter app .................................................................. 44
Hình 3.26 Màn hình hiển thị thông số cảm biến trên app Flutter ........................................ 45
Hình 3.27 Màn hình stream video từ server WebSocket ..................................................... 45
Hình 3.28 Các câu lệnh Erlang khi cấu hình ACL trên EMQ X ......................................... 47
Hình 3.29 Chuỗi xác thực ACL của EMQ X Broker........................................................... 48
Hình 3.30 Lưu đồ mô tả hệ thống giao tiếp MQTT với EMQ X Broker............................. 48
Hình 3.31 Cấu hình Rule Engine bằng lệnh SQL ................................................................ 49
Hình 3.32 Action Handler của Rule Engine ........................................................................ 49
Hình 4.1 Sơ đồ khối toàn bộ hệ thống ................................................................................. 50
Hình 4.2 Mặt trước của mô hình nhà thông minh................................................................ 51
Hình 4.3 Mặt bên của mô hình nhà thông minh .................................................................. 52
Hình 4.4 Mặt trên của mô hình nhà thông minh .................................................................. 52
Hình 4.5 Giao diện config camera trên web local ............................................................... 53
Hình 4.6 FPS khi stream camera dao động từ 12 – 17FPS .................................................. 54
xiii
Hình 4.7 Video được stream về app Flutter ......................................................................... 54
Hình 4.8 Minh họa multihiop test ........................................................................................ 55
Hình 4.9 PDR theo số chặng ................................................................................................ 56
Hình 4.10 RTT theo số chặng .............................................................................................. 57
Hình 4.11 Minh họa range test............................................................................................. 58
Hình 4.12 PDR theo khoảng cách ........................................................................................ 59
Hình 4.13 RTT theo khoảng cách ........................................................................................ 59
xiv
DANH SÁCH TỪ VIẾT TẮT
ACL
Access-control list
ACK
Acknowledgement
AES
Advanced Encryption Standard
API
Application programming interface
CA
Certificate authority
CHACHA20
ChaCha with 20 rounds and a 256 bit key
DH
Diffie–Hellman
DHE
Diffie-Hellman Ephemeral
DSA
Digital Signature Algorithm
ECDH
Elliptic-curve Diffie–Hellman
ECDHE
Elliptic Curve Diffie-Hellman Ephemeral
FPS
Frame per second
GPIO
General-purpose input/output
HTTP
Hypertext Transfer Protocol
HTTPS
Hypertext Transfer Protocol Secure
IoT
Internet of things
IP
Internet Protocol
JWT
Json web token
LWT
Last Will and Testament
MAC
Media access control
MCU
Microcontroller unit
MD
Message Digest
MQTT
Message Queuing Telemetry Transport
MQTTS
Message Queuing Telemetry Transport Secure
xv
PDR
Packet Delivery Rate
PSK
Pre-shared key
QQVGA
Quarter Quarter Video Graphics Array
QoS
Quality of Service
RSA
Rivest-Shamir-Adleman
RSSI
Received signal strength indication
RTT
Round-trip time
SHA256
Secure Hash Algorithm 256-bit
SDK
Software development kit
SQL
Structured Query Language
SSL
Secure Sockets Layer
TLS
Transport Layer Security
UI
User interface
UXGA
Ultra Extended Graphics Array
VGA
Video Graphics Array
1
GIỚI THIỆU
CHƯƠNG 1:
GIỚI THIỆU ĐỀ TÀI
1.1. Đặt vấn đề
Trong những năm gần đây, công nghệ phát triển vượt bậc, nhu cầu được kết nối ở mọi
nơi, mọi lĩnh vực của con người đang cao hơn bao giờ hết. Từ đó khái niệm Internet of
Things (IoT) và những ứng dụng của nó đã được hình thành và ngày càng phát triển. Những
mô hình IoT được xây dựng ở nhiều nơi như smart home, smart city, smart manufacturing,…
đã và đang mang lại nhiều lợi ích cho con người. Để có thể ứng dụng được công nghệ IoT
trong thực tiễn, chúng ta cần hiểu được cách mà các giao thức hoạt động trong hệ thống và
lựa chọn đúng giao thức cho từng nhu cầu tích hợp IoT cụ thể để vừa đảm bảo được yêu cầu
đặt ra cũng như dễ dàng giao tiếp và chỉnh sửa. Nổi bật trong các giao thức được sử dụng
trong các hệ thống IoT là giao thức MQTT bởi tính đơn giản, hiệu quả, gọn nhẹ và dễ tùy
chỉnh tùy theo mục đích sử dụng của nó, bên cạnh đó còn có các giao thức khác rất phổ biến
và không kém phần quan trọng như HTTP, Websocket…
Để có thể sử dụng được các giao đó và thiết kế nên một hệ thống IoT hoàn chỉnh thì
cần rất nhiều kiến thức về phần cứng, phần mềm và lập trình. Trên thị trường hiện nay có rất
nhiều các cloud service có sẵn, người dùng có thể mua/thuê để sử dụng cho các hệ thống IoT
của mình, điều này giúp cho mọi việc trở nên đơn giản hơn, không cần phải hiểu quá sâu về
bản chất bên trong của hệ thống mà vẫn có thể hiện thực một hệ thống IoT hoàn chỉnh phù
hợp với yêu cầu. Tuy nhiên điều này vô hình trung sẽ khiến cho chúng ta khó nắm bắt được
công nghệ thực sự tạo nên các hệ thống IoT đó, dẫn tới việc gặp rất nhiều khó khăn khi muốn
mở rộng quy mô hệ thống, sử dụng thêm các giao thức khác, xây dựng UI mới… Vì vậy với
công việc của một kỹ sư IoT, hiểu rõ bản chất và xây dựng được một hệ thống IoT từ những
nền tảng căn bản là điều rất cần thiết.
Với vấn đề nêu trên, mục tiêu của luận văn là xây dựng một hệ thống IoT dựa trên nền
tảng của giao thức MQTT, HTTP và WebSocket từ những bước căn bản như cấu hình một
MQTT Broker, cấu hình các tính năng như bảo mật, cơ sở dữ liệu, kiểm soát luồng dữ liệu,
cấu hình các node, xây dựng UI để tùy chỉnh sau khi chạy hệ hống,... để có thể tạo nên một
hệ thống IoT (tập trung chủ yếu vào giao thức MQTT, HTTP và WebSocket) tương đối hoàn
chỉnh và có thể dễ dàng mở rộng khi cần thiết.
GIỚI THIỆU
1.2.
2
Phạm vi và phương pháp nghiên cứu
-
Hệ thống IoT trong thực tế có thể được xây dựng từ nền tảng rất nhiều giao thức khác
nhau, mỗi giao thức có những ưu nhược điểm nhất định, phù hợp với từng yêu cầu
cụ thể của người dùng. Ở phạm vi luận văn này em tập trung tìm hiểu giao thức
MQTT và HTTP/WebSocket để xây dựng hệ thống IoT.
-
Sử dụng các nền tảng phần cứng có sẵn của các hãng, chủ yếu là ESP32 cùng với các
SDK, API của nhà phát triển để lập trình triển khai các ứng dụng.
-
Lập trình app di động để kết nối và đọc dữ liệu từ hệ thống.
1.3. Nhiệm vụ của luận văn
-
Xây dựng một mạng mesh wifi gồm các ESP32/8266 kết nối với nhau để gửi dữ liệu
đọc từ cảm biến nhiệt độ, ánh sáng, độ ẩm về MQTT Broker. Các node có khả năng
tự tham gia vào mạng khi được cấp nguồn, server có khả năng kiểm tra số lượng
node tham gia vào mạng và nhận dữ liệu từ tất cả các node.
-
Cấu hình một MQTT Broker dựa trên source code của nhà phát triển. Deploy lên
internet với đầy đủ các cấu hình về tên miền, IP tĩnh, điều hướng request, đường
truyền bảo mật SSL/TLS, cơ sở dữ liệu, kiểm soát luồng dữ liệu, phân quyền ACL.
Giao tiếp MQTT với root node truyền lệnh xuống điều khiển thiết bị trong mesh.
-
Cấu hình Camera IP stream video về ứng dụng của người dùng.
-
Thiết kế ứng dụng trên smartphone có tính năng kết nối MQTT đến hệ thống và nhận
dữ liệu từ các client khác để hiển thị lên dashboard, nhận video stream, có tính năng
cập nhật realtime, tối ưu về hiệu năng của app. Đặc biệt App có tính năng ra lệnh
bằng giọng nói để điều khiển các thiết bị trong hệ thống.
-
Thiết kế giao diện Web Server local để config ESP32 với các thông số như: wifi,
MQTT, mesh, hiển thị thông tin user và các gói tin MQTT,… tạo sự linh hoạt, dễ sử
dụng, không cần chỉnh sửa source code mỗi lần thay đổi cấu hình hệ thống.
-
Hoàn thiện hệ thống bằng ứng dụng vào nhà thông minh, điều khiển relay đèn, cảm
biến và các thiết bị khác.
3
CƠ SỞ LÝ THUYẾT
CHƯƠNG 2:
CƠ SỞ LÝ THUYẾT
2.1. Công nghệ wifi
2.1.1. Kiến trúc chuẩn 802.11
Hình bên dưới minh họa các thành phần chính của kiến trúc mạng LAN không dây
802.11. Khối xây dựng cơ bản của kiến trúc 802.11 là bộ dịch vụ cơ bản (basic
service set - BSS).
Hình 2.1 Kiến trúc mạng LAN chuẩn IEEE 802.11
Một BSS chứa một hoặc nhiều trạm không dây và một trạm trung tâm được gọi là
access point (AP). Hình 2.1 cho thấy AP trong mỗi hai BSS kết nối với một thiết bị kết nối
(chẳng hạn như bộ chuyển mạch hoặc bộ định tuyến), từ đó dẫn đến Internet. Trong một
mạng gia đình điển hình, có một AP và một bộ định tuyến (thường được tích hợp với nhau
thành một thiết bị gọi là modem) kết nối BSS với Internet.
Như với các thiết bị Ethernet, mỗi trạm không dây 802.11 có một địa chỉ MAC 6 byte
được lưu trữ trong fireware của adapter của trạm (tức là thẻ giao diện mạng 802.11). Mỗi
AP cũng có một địa chỉ MAC cho giao diện không dây của nó. Như với Ethernet, các địa
chỉ MAC này được quản lý bởi IEEE và (về lý thuyết) là duy nhất trên toàn cầu.
Trong 802.11, mỗi trạm không dây cần liên kết với một AP trước khi nó có thể gửi
hoặc nhận dữ liệu lớp mạng. Mặc dù tất cả các tiêu chuẩn 802.11 đều sử dụng liên kết, chúng
4
CƠ SỞ LÝ THUYẾT
ta sẽ thảo luận cụ thể về chủ đề này trong ngữ cảnh của IEEE 802.11b / g.
Khi quản trị
viên mạng cài đặt AP, quản trị viên sẽ chỉ định một "Mã định danh nhóm dịch vụ" (Service
Set Identifier - SSID) đến AP. (Ví dụ: khi bạn “xem các mạng khả dụng” trong Microsoft
Windows, một danh sách được hiển thị cho biết SSID của từng AP trong phạm vi quét của
máy tính.) Quản trị viên cũng phải gán số kênh cho AP. Để hiểu số kênh, hãy nhớ lại rằng
802.11 hoạt động trong dải tần từ 2,4 GHz đến 2,485 GHz. Trong băng tần 85 MHz này,
802.11 xác định 11 kênh chồng chéo một phần. Hai kênh bất kỳ đều không chồng chéo khi
và chỉ khi chúng được phân tách bởi bốn kênh trở lên. Trong đó, bộ kênh 1, 6 và 11 là bộ ba
kênh không trùng lặp. Điều này có nghĩa là quản trị viên có thể tạo một mạng LAN không
dây với tốc độ truyền tối đa tổng hợp là 33 Mbps bằng cách cài đặt ba AP 802.11b tại cùng
một vị trí thực, gán các kênh 1, 6 và 11 cho các AP, và kết nối các AP đó bằng Switch.
Để tạo liên kết với một AP cụ thể, trạm không dây có thể được yêu cầu xác thực chính
nó với AP. Mạng LAN không dây 802.11 cung cấp một số lựa chọn thay thế để xác thực và
truy cập. Một cách tiếp cận được nhiều công ty sử dụng là cho phép truy cập vào mạng không
dây dựa trên địa chỉ MAC của trạm. Cách tiếp cận thứ hai, được nhiều quán cà phê Internet
sử dụng, sử dụng tên người dùng và mật khẩu. Trong cả hai trường hợp, AP thường giao tiếp
với máy chủ xác thực, chuyển tiếp thông tin giữa trạm không dây và máy chủ xác thực bằng
giao thức như RADIUS [RFC 2865] hoặc DIAMETER [RFC 3588]. Việc tách máy chủ xác
thực khỏi AP cho phép một máy chủ xác thực phục vụ nhiều AP, tập trung các tác vụ (thường
nhạy cảm) về xác thực và truy cập trong máy chủ duy nhất, và giữ cho chi phí và độ phức
tạp của AP thấp.
2.1.2. Mesh Wifi
2.1.2.1. Giới thiệu về mạng mesh wifi
Trong quá trình phát triển IoT thường đòi hỏi việc tăng số lượng node kết nối với
Internet. Các kết nối thông thường dùng cơ chế Client - Server. Nhược điểm lớn nhất là số
lượng node có thể trực tiếp kết nối tới router/server bị giới hạn về cả số lượng và hiệu suất.
Để khắc phục điểm này thì giao thức MESH đã ra đời. Trong giao thức này node có
thể tạo ra mạng để chuyển tiếp gói tin cho nhau, nhờ đó mà một số lượng lớn node có thể
kết nối với Server/Internet mà không cần phải cải tiến, nâng cấp router/server.
5
CƠ SỞ LÝ THUYẾT
Hình 2.2 Sơ đồ mạng mesh cơ bản
2.1.2.2. Cấu trúc mạng
Các node: sẽ kết nối trực tiếp tới router được gọi là root node, các node khác thì được
gọi là non-root node.
Online-Mesh : Khi router kết nối với internet thì ta có thể dùng IOT App để điều
khiển từ xa ở bất kỳ đâu
Local-Mesh: Bạn chỉ có thể điều khiển Local Device trong mạng thông qua router.
Root Node:
-
Nhận và gửi gói tin
-
Chuyển tiếp gói tin từ server, ứng dụng mobile và các node con của nó
None-root Node:
-
Non-leaf node: Nhận và gửi gói tin, chuyển tiếp gói tin từ node cha và các
node con khác
-
Leaf node: Chỉ được nhận và gửi gói tin, không có chức năng chuyển tiếp.
Hình 2.3 Sơ đồ cấu trúc mạng mesh cơ bản
CƠ SỞ LÝ THUYẾT
6
2.2. Giao thức MQTT
2.2.1. Tổng quan
“MQTT (The Message Queuing Telemetry Transport) là một dạng giao thức client server
theo cơ chế publish/subscribe gói tin. Nó là một giao thức mở, đơn giản và dễ dàng để sử
dụng trong nhiều tình huống cũng như môi trường ràng buộc khác nhau. MQTT được sử
dụng trong các ứng dụng phổ biến như giao tiếp Machine to Machine (M2M) và Internet of
Things (IoT).” – Theo MQTT 3.1.1 specification.
Giao thức MQTT được phát minh vào năm 1999 bởi Andy Stanford-Clark (IBM) và
Arlen Nipper (Arcom, nay là Cirrus Link). Họ cần một giao thức để giảm thiểu tiêu tốn năng
lượng và băng thông để kết nối các đường ống dẫn dầu thông qua vệ tinh. Hai nhà phát minh
đã chỉ ra những yêu cầu cho giao thức mà họ phát triển bao gồm:
-
Sử dụng đơn giản
-
Có chức năng gửi dữ liệu theo Quality of Service
-
Ít tốn băng thông
Đó là những đặc tính cốt lõi của MQTT. Tuy nhiên nhu cầu sử dụng giao thức đã dần
chuyển từ các hệ thống nhúng kín sang Internet vạn vật kết nối (IoT). Thay đổi này tạo ra
nhiều nhầm lẫn rằng MQTT là viết tắt của từ gì. Câu trả lời là MQTT không còn được coi là
một từ viết tắt nữa, mà nó đơn giản là tên của giao thức.
2.2.2. Cơ chế hoạt động và các thông số quan trọng
2.2.2.1. Cơ chế publish/subscribe
Cơ chế publish/subscribe (pub/sub) cung cấp một giải pháp thay thế cho cơ chế client
server truyền thống. Ở client – server, server kết nối trực tiếp đến các endpoint, còn đối với
pub/sub, cơ chế này tách riêng client gửi tin (pubslisher) và client nhận tin (subscriber).
Publisher và subscriber không bao giờ kết nối trực tiếp với nhau, thậm chí hai bên còn không
cần biết đến sự tồn tại của đối phương. Kết nối giữa chúng sẽ được một bên thứ ba thiết lập,
gọi là Broker. Nhiệm vụ của Broker là nhận gói tin từ publisher và phân phối đến các
subscriber. Dựa theo “topic” mà publisher gửi gói tin đến và subsriber đăng ký. Như hình
minh họa bên dưới, Speed Meter publish message vào topic “70 mph”, Broker nhận gói tin
ở topic đấy và gửi nó đến các subscriber là Mobile Device và Backend đã subscribe vào
topic “70 mph”.
CƠ SỞ LÝ THUYẾT
7
Hình 2.4 Mô hình cơ chế hoạt động của giao thức MQTT
Khía cạnh quan trọng nhất của cơ chế này đó là sự tách biệt giữa publisher và subsriber.
Sự tách biệt này thể hiện ở 3 khía cạnh:
-
Tách biệt về không gian: Publisher và subscriber không cần biết địa chỉ IP hay port
của nhau.
-
Tách biệt về thời gian: Publisher và subscriber không cần phải chạy cùng lúc.
-
Tách biệt về đồng bộ hóa: Các hoạt động ở cả hai bên không cần phải bị gián đoạn
trong quá trình publish/subsribe.
Sự khác biệt với hàng đợi gói tin (message queues):
Có rất nhiều bối rối với cái tên MQTT rằng liệu nó có phải là một dạng giao thức có
chức năng của một hàng đợi gói tin hay không. Giờ chúng ta sẽ làm rõ điều đó, có một số
điểm khác nhau cơ bản như sau:
- Một hàng chờ gói tin lưu trữ gói tin ở đó cho đến khi nó được nhận bởi một client. Nếu
không có client nào nhận gói tin, nó sẽ mắc kẹt ở hàng đợi và chờ được nhận. Trái
ngược với MQTT, khi gói tin không được nhận (không có client nào subscribe vào
topic) thì Broker sẽ hủy bỏ gói tin ấy sau một khoảng thời gian nhất định.
- Gói tin của hàng chờ gói tin chỉ có thể được nhận bởi một client nhất định. Còn với
MQTT thì khác, bất kỳ subscriber nào cũng sẽ nhận được gói tin của topic mà mình
subscribe.
8
CƠ SỞ LÝ THUYẾT
2.2.2.2. Quality of Service
Khái niệm: Quality of Service (QoS) là thông số quy ước giữa bên gửi và nhận về cách
mà gói tin được gửi đi. Trong MQTT có 3 loại QoS:
-
At most once (0): Cách gửi gói tin ít tốn công nhất. Không hề có sự đảm bảo rằng
gói tin được gửi sẽ đi đến nơi nhận.
-
At least once (1): Sau khi gửi gói tin, bên gửi sẽ lưu lại gói tin cho đến khi nào nhận
được tin phản hồi (PUBACK) từ bên nhận trong một khoảng thời gian nhất định, nếu
không nó sẽ gửi lại gói tin thêm một lần nữa. Điều này đảm bảo bảo rằng sẽ có ít
nhất một lần gói tin được gửi đến bên nhận.
-
Exactly once (2): Mức QoS cao nhất, an toàn nhất và cũng là chậm nhất trong các
mức QoS. Gói tin được gửi với QoS mức 2 sẽ trải qua quá trình “4 bước bắt tay” như
hình minh họa. Điều này đảm bảo rằng gói tin sẽ chắc chắn gửi đến nơi và không bị
lặp như QoS mức 1.
Hình 2.5 QoS mức 2 trải qua 4 bước bắt tay
Cần chú ý rằng giữa hai bên publish và subscribe có thể có định nghĩa QoS khác nhau.
Nếu như QoS bên subscribe thấp hơn QoS của bên publish thì Broker sẽ gửi gói tin với mức
QoS thấp hơn.
Trường hợp ứng dụng:
-
QoS mức 0: Có đường dây kết nối ổn định, không bị ảnh hưởng nhiều khi một vài
gói tin bị mất (ví dụ như data từ sensor gửi đến liên tục trong khoảng thời gian ngắn).
-
QoS mức 1: Cần đảm bảo nhận được tất cả gói tin và không ngại việc gửi trùng gói
tin, cần độ tin cậy nhưng tốc độ không chậm như QoS mức 2.
-
QoS mức 2: Cần đảm bảo nhận được chính xác tất cả gói tin (không bị trùng), không
cần truyền tin với tốc độ cao.
CƠ SỞ LÝ THUYẾT
9
2.2.2.3. Retain
Trong giao thức MQTT, có những trường hợp publisher mất vài giây, vài phút hoặc
thậm chí vài giờ đồng hồ để gửi gói tin lên topic và subscriber trong khoảng thời gian ấy nếu
subsribe vào topic ấy sẽ không nhận được thông tin (như trạng thái online/offline của sensor
chẳng hạn) ngay tức thì mà phải đợi gói tin tiếp theo được gửi. Chức năng retain được sinh
ra để giải quyết vấn đề này.
Gói tin retain về cơ bản cũng giống như tất cả gói tin MQTT khác, với cờ retain được
set true. Broker sẽ lưu trữ gói tin retain của topic tương ứng và gửi ngay tức thì cho bất kì
client nào subscribe vào topic đấy. Điều này giúp client ngay lập tức cập nhật được tình hình
khi kết nối mà không cần phải chờ đợi. Để xóa gói tin retain, ta gửi gói tin có payload bằng
0 với retain true lên topic. Thông thường thì không cần phải xóa nó vì gói tin retain sau sẽ
ghi đè lên gói trước.
2.2.2.4. Last Will and Testament
Trong quá trình hệ thống sử dụng giao thức MQTT hoạt động, sẽ có thể xảy ra trường
hợp client bị mất kết nối đột ngột, lúc này để người dùng có thể cập nhật nhanh tình hình
của client, ta có thể sử dụng chức năng Last Will and Testament (LWT).
Tương tự như gói tin bình thường, gói tin LWT cũng giống như các gói tin MQTT
khác với những topic, retain flag, QoS và payload. Tuy nhiên gói tin LWT sẽ được Broker
lưu lại trong topic của nó (ví dụ như topic tên Status), khi client đột ngột ngắt kết nối, Broker
sẽ gửi gói tin LWT (ví dụ: disconnected) đến tất cả subscriber của topic Status để thông báo
tình hình. Nhưng như vậy thì client sẽ luôn nhận được thông báo disconnected khi subscribe
vào topic LWT, để giải quyết vấn đề này đơn giản chỉ cần cho thiết bị publish vào topic
LWT trạng thái đã kết nối (ví dụ connected) khi kết nối thành công, set retain lên 1. Như vậy
khi thiết bị kết nối thành công thì broker sẽ gửi đến client gói tin "connected" của topic LWT,
khi thiết bị ngắt kết nối thì thì broker sẽ gửi đến client gói tin "disconnected" của topic LWT,
giúp người dùng có thể cập nhật nhanh chóng trạng thái hệ thống của mình, thông qua một
app di động kết nối MQTT chẳng hạn.
2.2.2.5. Keep Alive
MQTT hoạt động dựa trên giao thức TCP. Giao thức này đảm bảo rằng gói tin được
truyền qua Internet một cách an toàn, đúng trình tự và được check lỗi. Tuy nhiên có những
lúc client có thể bị mất đồng bộ khỏi kết nối TCP. Ví dụ như một bên bị lỗi đường truyền và
CƠ SỞ LÝ THUYẾT
10
bên còn lại thì không hay biết gì, vẫn tiếp tục gửi gói tin ACK và đợi phản hồi, tình huống
này gọi là “half-open connection”.
MQTT có tích hợp một chức năng gọi là Keep Alive, tức khoảng thời gian mà client
và Broker quy ước sẵn sàng để kết nối lại nếu có bên nào bị mất kết nối giữa chừng. Khoảng
Keep Alive mặc định là 60s và người dùng có thể tùy chỉnh. Khi client ngắt kết nối, Broker
vẫn đang giữ đường kết nối đó. Đến khi client kết nối trở lại trong khoảng Keep Alive cho
phép, Broker sẽ nhận biết được đó là client của đường kết nối trước đó thông qua client
Identifier và xóa bỏ kết nối cũ, thiết lập một kết nối mới với client. Hoạt động này gọi là
Client Take-Over.
2.3. Giao thức HTTP và WebSocket
2.3.1. Giao thức HTTP
2.3.1.1. Giới thiệu về giao thức HTTP
HTTP là giao thức ở lớp ứng dụng trong mô hình TCP/IP được dùng để nhận/gửi tài
nguyên (phổ biến nhất là HTML) thông qua internet, hoạt động trên đường truyền giao thức
TCP hoặc đường truyền TCP mã hóa TLS. Nó là cơ chế trao đổi dữ liệu giữa client và server,
nghĩa là bên khởi tạo quá trình giao tiếp client-server thường là client, cụ thể là Web browser
để nhận web document từ server. Document có thể được tạo thành từ nhiều thành phần khác
nhau, như text, hình ảnh, videos, scripts… Về cơ bản, HTTP là quá trình client và server trao
đổi gói tin cho nhau. Gói tin được gửi bởi client (thường là browser) được gọi là request còn
gói tin được gửi bởi server được gọi là response.
Mỗi request được gửi đến server sẽ được xử lý và nhận được gói tin phản hồi response.
Ở giữa client và server thường có nhiều thiết bị khác, được gọi là proxy dùng để thực hiện
các chức năng như tường lửa, cache,… và các thiết bị ở lớp thấp hơn như router, modem,
switch,… có những chức năng riêng biệt, dùng để forward gói tin giữa client và server.
Thông thường khi cấu hình HTTP ở lớp ứng dụng, ta ít khi quan tâm tới các thiết bị này.
Hình 2.6 Mô hình giao tiếp giữa client và server qua giao thức HTTP
CƠ SỞ LÝ THUYẾT
11
User-agent: thực hiện các tác vụ của client, thường là web browser. Trong hầu hết mọi
tình huống, browser luôn luôn là bên khởi tạo request. Để hiển thị một trang web, browser
sẽ gửi request đến server yêu cầu nhận file HTML gốc của web page đó. Trong file HTML
này, có thể có các trường bổ sung như CSS, javascript, image,… được gán vào, browser sẽ
đọc file HTML và thực hiện tiếp các request bổ sung để fetch về các file này, tạo thành một
trang web hoàn chỉnh và hiển thị ra cho user. Ở phía đối diện là server, bên sẽ xử lý request
của client và gửi trả response tương ứng. Server có thể là một máy riêng rẻ, hoặc rất nhiều
máy tính liên kết với nhau để giải quyết các tác vụ lớn (load balancing) và có thể gồm các
chức năng tích hợp khác như database.
Nhìn chung, HTTP là một giao thức đơn giản, được viết bằng ngôn ngữ con người có
thể hiểu được, giúp cho việc cấu hình, testing trở nên thuận tiện hơn. Có một điều đáng lưu
ý đó là HTTP là một giao thức stateless, tức nó sẽ không lưu lại trạng thái của client sau mỗi
connection được thiết lập, nghĩa là mỗi khi client tạo connection mới thì trạng thái trước đó
sẽ được xóa hoàn toàn, điều này gây ra sự bất tiện khi cần lưu lại thông tin client để dùng
cho các kết nối tiếp theo, ví dụ như giỏ hàng khi mua sắm online. Tuy nhiên vấn đề này có
thể được khắc phục thông qua session và cookie, một trường mở rộng trong HTTP header,
có thể dùng để chứa thông tin của client trong phiên request trước đó và được tái sử dụng
cho các phiên request tiếp theo.
2.3.1.2. Luồng hoạt động của HTTP:
Khi client muốn giao tiếp với server, nó sẽ thực hiện những bước cơ bản như sau:
a) Mở một kết nối TCP, được thiết lập sau khi trải qua quá trình bắt tay ba bước, kết nối này
dùng để gửi request và nhận response. Client có thể gửi và nhận gói tin thông qua kết nối
này, sau đó đóng nó lại khi kết thúc quá trình, hoặc tiếp tục giữ kết nổi mở và dùng nó để
nhận gửi các gói tin tiếp theo.
b) Gửi gói tin HTTP: Trước HTTP/2 thì gói tin HTTP được viết dưới dạng con người có thể
đọc được. Với HTTP/2 thì gói tin này được đóng gói vào một frame không thể đọc được,
nhưng về nguyên tắc cơ bản vẫn giữ nguyên. Header của gói HTTP có thể có các trường cơ
bản như ví dụ dưới đây:
GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: en
c) Đọc gói tin HTTP response được gửi từ server. Ví dụ header của một HTTP response:
CƠ SỞ LÝ THUYẾT
12
HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html
Các trường trong header của gói tin HTTP rất đa dạng, tùy thuộc vào yêu cầu sử dụng
mà server sẽ gửi HTTP response có các trường tương ứng. Ví dụ khi server response một
file HTML nén bằng gzip, thì nó phải có một trường trong header là Content-Encoding: gzip
để chỉ định điều đó thì browser mới có thể đọc được gói tin.
2.3.1.3. Các phiên bản
Được tạo ra ở đầu thập niên 90, HTTP là một giao thức có thể mở rộng và đã phát triển
qua rất nhiều phiên bản theo thời gian, càng lúc càng cải thiện những nhược điểm của phiên
bản trước đó.
HTTP/0.9 – Giao thức một dòng: Phiên bản đầu tiên của HTTP lúc đầu không có số
version, về sau nó được thêm số 0.9 để phân biệt với các phiên bản tiếp theo. HTTP/0.9 cực
kì đơn giản, request chỉ gồm 1 hàng duy nhất thể hiện cú pháp request và đường dẫn đế tài
nguyên. Ví dụ: GET /mypage.html. Gói tin response cũng rất đơn giản, chỉ bao gồm mỗi
HTML file mà client yêu cầu. Đến phiên bản tiếp theo HTTP/1.0 thì đã có những cải tiến
nhất định: thêm vào status code, header ở cả request và response, có thể gửi những dạng file
khác ngoài HTML nhờ vào trường content-type ở header. Tiếp đến là phiên bản HTTP/1.1
ra đời và đưa ra nhiều cải tiến đáng kể, đây cũng là phiên bản HTTP được sử dụng phổ biến
nhất:
-
Một kết nối TCP có thể được tái sử dụng cho nhiều phiên request/response khác
nhau, điều này giúp tiết kiệm được thời gian rất nhiều.
-
Có thêm tính năng pipelining, cho phép request tiếp theo được gửi trước khi nhận
response của request trước đó, cải thiện độ trễ.
-
Thêm vào các trường thiết lập quy ước giao tiếp giữa clien và server như: ngôn ngữ,
dạng mã hóa.
CƠ SỞ LÝ THUYẾT
13
Trải qua hơn một thập kỷ "tiến hóa", HTTP đã ngày càng hoàn thiện về cả độ tin cậy
và hiệu quả. Hiện tại HTTP đã có các phiên bản HTTP/2 và HTTP/3 với nhiều cải tiến khác,
nổi bật là chuyển từ text based protocol thành binary based protocol, các gói tin lúc này được
cấu trúc thành các frame nối tiếp nhau, bản chất các trường của HTTP/1.1 vẫn giữ nguyên
nhưng được cấu trúc thành dạng frame chứ không còn là dạng từng dòng text riêng rẽ, giúp
tăng tốc độ đường truyền nhanh hơn. Vì có những cải tiến nổi bật mà HTTP/2 và thậm chí
HTTP/3 đang ngày càng được tích hợp vào internet và sử dụng rộng rãi ở hiện tại và tương
lai.
2.3.2. Giao thức WebSocket
2.3.2.1. Giới thiệu về WebSocket
WebSockets được mô tả lần đầu tiên vào năm 2008 và đã được hỗ trợ nhiều trình duyệt
từ khoảng năm 2010. Trước khi WebSockets ra đời, web “thời gian thực” đã tồn tại, nhưng
rất khó đạt được, thường chậm hơn và được cung cấp bằng cách điều chỉnh và sử dụng các
công nghệ web hiện có vốn không được thiết kế cho các ứng dụng thời gian thực. Đó là bởi
vì web đã được xây dựng dựa trên giao thức HTTP, giao thức này ban đầu được thiết kế
hoàn toàn dưới dạng cơ chế request/response. Mở kết nối, mô tả những gì bạn muốn, nhận
lại phản hồi, sau đó đóng kết nối. Điều này là ổn trong những ngày đầu của web bởi vì, hồi
đó, thực sự chỉ xử lý một tài liệu văn bản và có thể một vài nội dung bổ sung (thường là hình
ảnh). Về sau HTTP có cải tiến hơn, cho phép sử dụng một kết nối TCP cho nhiều
request/response liên tiếp (persistent connection) nhưng nhìn chung HTTP vẫn là dạng halfduplex, khi nói đến các ứng dụng đòi hỏi real time thì người ta cần một chuẩn giao tiếp
nhanh và hiệu quả hơn, vì vậy WebSocket ra đời để giải quyết vấn đề đó.
2.3.2.2. Cơ chế hoạt động của WebSocket
WebSocket cho phép client và server giao tiếp trên đường kết nối TCP duy trì, truyền
ful-duplex. Về cơ bản người ta thường nhìn nhận WebSocket như là một giao thức lớp ứng
dụng, tương tự như HTTP, nhưng thật ra điều này chưa chính xác lắm. Về bản chất
WebSocket giống như một "đường ống" vận chuyển, cho phép client và server giao tiếp fulduplex với nhau, nhưng bản thân WebSocket không định nghĩa cách mà gói tin được tổ chức
như HTTP hay MQTT, vì vậy gọi WebSocket là một giao thức thì chưa hoàn toàn chính xác.
Thực tế, WebSocket như một đường ống, và người ta có thể bỏ giao thức mà mình muốn
dùng vào đó, thông qua trường "Sec-WebSocket-Protocol", ở đây ta có thể định nghĩa giao
CƠ SỞ LÝ THUYẾT
14
thức, tức cách mà gói tin được tổ chức bên trong WebSocket. Để tránh nhầm lẫn về danh
pháp thì người ta gọi những giao thức được định nghĩa bên trong WebSocket là các
"subprotocol", ví dụ như XML, MQTT, WAMP…
Thông thường WebSocket được sử dụng bằng cách chuyển từ HTTP sang WebSocket
sau quá trình handshake. Ở HTTP/1.1, điều này được thực hiện bằng cách thêm trường
"Connection" và "Upgrade" ở trong handshake header của client để báo cho server biết là
client muốn upgrade lên WebSocket. Nếu server đồng ý, nó sẽ trả về status 101 Switching
Protocols, nếu không thì nó sẽ bỏ qua trường Upgrade và gửi trả status bình thường ví dụ
như 200 OK. Nếu sử dụng WebSocketAPI thì API nó sẽ đảm nhận phần handshake cho
chúng ta luôn, còn khi tự xây dựng cơ chế WebSocket từ các bước cơ bản thì ta cần phải
thực hiện handshake qua HTTP header "Connection" và "Upgrade".
Hình 2.7 Cấu trúc header HTTP dùng để "upgrade" lên WebSocket
Ở hệ thống MQTT xây dựng trong luận văn này, WebSocket cũng sẽ được sử dụng để giao
tiếp MQTT qua browser và giao tiếp với ESP32 thông qua Web Server nhúng.
2.4. SSL/TLS
2.4.1. Sơ lược về SSL/TLS
Trong giao tiếp ở môi trường Internet, để đảm bảo tính an toàn thì cần phải thỏa mãn
các yếu tố:
-
Confidentiality: tính bảo mật nội dung tin nhắn. Nội dung tin nhắn phải được encrypt
để bên thứ ba không thể đọc được.
-
Message integrity: đảm bảo tin nhắn không bị tác động, thay thế, làm giả nội dung.
Thường người ta dùng checksum để đảm bảo yếu tố này.
-
End-point authentication: cả bên gửi và bên nhận cần xác thực nhân dạng của nhau.
-
Operational security: đường truyền của các tổ chức hiện tại đa phần đều dẫn kết
nối đến internet, và có thể dễ bị xâm phạm, atk có thể gửi mã độc vào đường truyền
CƠ SỞ LÝ THUYẾT
15
tin và thực hiện tấn công, đánh cắp dữ liệu công ty,.. Điều này có thể được hạn chế
bằng các thiết bị tường lửa, được đặt ở giữa client và server, quản lý luồng dữ liệu ra
vào client.
Để đáp ứng được những yêu cầu về bảo mật và toàn vẹn thông tin như trên thì chỉ mình
cơ chế của TCP là chưa đủ, vì vậy một cách thức bảo mật khác dựa trên mã hóa ra đời, gọi
là SSL (Secure Sockets Layer), và bản cải tiến của SSL version 3, gọi là TLS (Transport
Layer Security), được định nghĩa tiêu chuẩn bởi IETF (RFC 4346).
Hiện nay hầu hết các website trên internet đều có sử dụng SSL/TLS, được thể hiện
bằng biểu tượng cái khóa trên thanh địa chỉ của trình duyệt. Hầu hết các trình duyệt lớn như
Google, Firefox hay Mircrosoft Edge sẽ tự hiển thị những site nào họ truy cập có an toàn
không, nếu website không có SSL/TLS thì sẽ bị trình duyệt đánh dấu là "Not Secure" để
thông báo cho người dùng.
Vị trí của SSL/TLS trong mô hình TCP/IP nằm ở khoảng giao giữa lớp Application và
lớp Transport. Ở góc nhìn của nhà phát triển thì thường xem SSL/TLS là giao thức nằm ở
lớp Transport.
Hình 2.8 Giao thức SSL nằm ở vị trí giao giữa Application layer và Transport layer
2.4.2. Cơ chế hoạt động
SSL/TLS hoạt động dựa trên cơ chế sử dụng key và các thuật toán mã hóa để tạo ra
mật mã (cipher). Mật mã là các thuật toán, cụ thể hơn chúng là một tập hợp các bước để thực
hiện một chức năng mật mã - nó có thể là mã hóa, giải mã, băm hoặc chữ ký số. Ở đây chúng
ta không đi sâu vào nguyên lý toán học đằng sau những giải thuật mã hóa đó mà chỉ quan
tâm đến cơ chế mà SSL/TLS sử dụng chúng trong việc tạo kết nối an toàn. Xét phiên bản
TLS 1.2 sẽ có cipher suite như sau:
16
CƠ SỞ LÝ THUYẾT
Hình 2.9 Cipher suite của phiên bản TLS 1.2
Cipher suite là sự kết hợp của các thuật toán được sử dụng để "thương lượng" cài đặt
bảo mật trong quá trình handshake SSL / TLS. Khi các thông điệp ClientHello và
ServerHello được trao đổi, client sẽ gửi một danh sách ưu tiên các cipher suite mà nó hỗ trợ.
Sau đó, server sẽ phản hồi với cipher suite mà nó đã chọn từ danh sách.
Cipher suite là sự kết hợp của:
-
Các thuật toán trao đổi key (RSA, DH, ECDH, DHE, ECDHE, PSK)
-
Xác thực / Thuật toán chữ ký số (RSA, ECDSA, DSA)
-
Thuật toán mã hóa hàng loạt (AES, CHACHA20, Camellia, ARIA)
-
Thuật toán mã xác thực tin nhắn (SHA-256, POLY1305)
Ở hình trên, TLS là giao thức. Bắt đầu với ECDHE, chúng ta có thể thấy rằng trong
quá trình bắt tay, các key sẽ được trao đổi thông qua Elliptic Curve Diffie Hellman
(ECDHE). RSA là thuật toán xác thực. AES_128_GCM là thuật toán mã hóa hàng loạt: AES
chạy Chế độ bộ đếm Galois với kích thước key 128 bit. Cuối cùng, SHA-256 là thuật toán
băm.
Symmetric key
Symmetric key là khóa được sử dụng để mã hóa và giải mã thông tin. Điều này có
nghĩa là để giải mã thông tin, người ta phải có cùng một khóa đã được sử dụng để mã hóa
thông tin đó. Trên thực tế, các khóa đại diện cho bí mật được chia sẻ giữa hai hoặc nhiều bên
có thể được sử dụng để duy trì liên kết thông tin riêng tư. Yêu cầu cả hai bên đều có quyền
truy cập vào khóa bí mật là một trong những nhược điểm chính của mã hóa khóa đối xứng,
so với mã hóa khóa public. Thuật toán mã hóa sử dụng Symmetric key phổ biến nhất và
được sử dụng trong SSL/TLS là AES (Advanced Encryption Standard).
Asymmetric key
Mật mã không đối xứng, còn được gọi là mật mã khóa public, là một quá trình sử dụng
một cặp khóa - một khóa public và một khóa private - để mã hóa và giải mã một tin nhắn và
bảo vệ nó khỏi bị truy cập hoặc sử dụng trái phép.
Public key là một khóa mật mã có thể được sử dụng bởi bất kỳ người nào để mã hóa
một tin nhắn để nó chỉ có thể được giải mã bởi người nhận bằng khóa riêng của họ. Khóa
CƠ SỞ LÝ THUYẾT
17
riêng tư - còn được gọi là khóa bí mật - chỉ được chia sẻ với người khởi tạo khóa. Nếu người
gửi mã hóa thư bằng khóa riêng của họ, thì thư chỉ có thể được giải mã bằng khóa public của
người gửi đó, do đó xác thực người gửi. Các quá trình mã hóa và giải mã này diễn ra tự
động; người dùng không cần phải khóa và mở khóa tin nhắn một cách vật lý. Thuật toán mã
hóa sử dụng Asymmetric key phổ biến được dùng trong SSL/TLS là RSA (Rivest–Shamir–
Adleman).
Quá trình handshake
Ở phiên bản TLS 1.2 thì quá trình bắt tay sẽ diễn ra như sau:
-
Client và Server xác định một cipher suite được hỗ trợ lẫn nhau.
-
Server gửi chứng chỉ và key public của nó.
-
Ứng dụng khách xác thực chứng chỉ và chữ ký điện tử.
-
Các chức năng trao đổi key được thực hiện để tạo ra các symmetric key.
-
Mã hóa bắt đầu, HMAC được sử dụng để đảm bảo bắt tay không bị giả mạo.
Tóm lại, công việc của TLS sẽ là giúp client và server có thể giao tiếp với nhau thông
qua mã hóa bằng symmetric key. Nhưng làm sao để đưa key cho client? Server sẽ sử dụng
cơ chế của asymmetric key trong quá trình trao đổi key để có thể gửi symmetric key cho
client, sau khi nhận được key thì cả hai bên có thể thoải mái giao tiếp mà không sợ bị bên
thứ ba dòm ngó. Còn một vấn đề nữa cần quan tâm đó là làm sao client biết được mình đang
giao tiếp với server thật mà không phải là giả mạo? Lúc này thì cần vai trò của bên chứng
thực thứ ba cung cấp một chứng chỉ xác thực CA certificate cho server, chứng minh rằng
các key asymmetric và symmetric của server là đáng tin cậy, để server gửi CA này cho client
kèm theo các key của nó. Client nhìn thấy key của server đã có xác thực CA bởi bên thứ ba
thì nó có thể tin tưởng mà giao tiếp với server. Có 2 dạng CA certificate có thể sử dụng, một
là chính server sẽ tạo CA certificate và tạo các key khác bằng CA certificate đó (sẽ trình bày
ở phần thiết kế) hoặc sử dụng CA certificate của bên thứ ba, cách này thì thường sẽ phải tốn
phí.
2.5. Một số kiến thức liên quan
2.5.1. Hàm băm
Hàm băm cực kỳ hữu ích và xuất hiện trong hầu hết các ứng dụng bảo mật thông tin.
Hàm băm là một hàm toán học chuyển đổi một giá trị số đầu vào thành một giá trị số nén
18
CƠ SỞ LÝ THUYẾT
khác. Đầu vào cho hàm băm có độ dài tùy ý nhưng đầu ra luôn có độ dài cố định. Các giá trị
được trả về bởi một hàm băm được gọi là message digest hoặc đơn giản là hash values.
Hình 2.10 Sơ đồ hoạt động của hàm băm
Một đặc điểm nổi bật của hàm băm đó là chuyển một chuỗi dữ liệu có độ dài bất kỳ
thành một chuỗi độ dài cố định, thường tầm 160 đến 512 bits, dẫn đến chuỗi đầu ra thường
có dung lượng nhỏ hơn nhiều so với chuỗi gốc, nên hàm băm đôi khi còn được gọi là hàm
nén dữ liệu. Quá trình thực hiện thuật toán băm là rất nhanh nên rất phù hợp với các ứng
dụng cần xử lý tốc độ cao. Một tính chất quan trọng của hàm băm đó là đây là dạng thuật
toán một chiều, nghĩa là rất khó để tìm được hàm ngược, nếu hàm băm h tạo ra chuỗi băm z
thì rất khó để có thể tìm ra x, đầu vào của z. Tính chất này ngăn chặn kẻ tấn công khi họ có
giá trị z mà muốn tìm được dạng dữ liệu gốc x. Mặt khác, với hàm băm h cho trước, chuỗi x
tạo thành chuỗi băm z, rất khó có thể tìm được chuỗi y với h(y) = h(x) = z. Thuộc tính này
của hàm băm bảo vệ chống lại kẻ tấn công có giá trị đầu vào và giá trị băm của nó và muốn
thay thế giá trị khác làm giá trị thay cho giá trị đầu vào ban đầu.
Những hàm băm thường dùng:
Message Digest (MD): MD5 là hàm băm phổ biến nhất và được sử dụng rộng rãi trong
nhiều năm. Họ MD bao gồm các hàm băm MD2, MD4, MD5 và MD6. Nó đã được chấp
nhận là Chuẩn Internet RFC 1321. MD5 là một hàm băm 128-bit. Các tiêu chuẩn MD5 đã
được sử dụng rộng rãi trong thế giới phần mềm để cung cấp sự đảm bảo về tính toàn vẹn của
tệp được truyền. Ví dụ: tệp server thường cung cấp tổng kiểm tra MD5 được tính toán trước
cho các tệp, để người dùng có thể dùng checksum để kiểm tra tệp đã tải xuống với nó.
Năm 2004, các collision (2 đầu vào khác nhau cho ra cùng kết quả băm) đã được tìm
thấy trong MD5. Một cuộc tấn công đã được báo cáo là thành công chỉ trong một giờ bằng
cách sử dụng cluster. Cuộc tấn công collision này đã dẫn đến MD5 bị xâm phạm và do đó
nó không còn được khuyến khích sử dụng.
CƠ SỞ LÝ THUYẾT
19
Secure Hash Function (SHA): Họ SHA bao gồm bốn thuật toán SHA; SHA-0, SHA1, SHA-2 và SHA-3. Mặc dù cùng một họ, nhưng có cấu trúc khác nhau.
-
Phiên bản gốc là SHA-0, một hàm băm 160-bit, được xuất bản bởi Viện Tiêu chuẩn
và Công nghệ Quốc gia (NIST) vào năm 1993. Nó có một số điểm yếu và không trở
nên phổ biến. Sau đó vào năm 1995, SHA-1 được thiết kế để sửa chữa những điểm
yếu được cho là của SHA-0.
-
SHA-1 được sử dụng rộng rãi nhất trong số các hàm băm SHA hiện có. Nó được sử
dụng trong một số ứng dụng và giao thức được sử dụng rộng rãi bao gồm bảo mật
Lớp cổng bảo mật (SSL). Vào năm 2005, một phương pháp đã được tìm thấy để phát
hiện ra các vụ collision đối với SHA-1 trong khung thời gian thực tế, làm cho khả
năng sử dụng lâu dài của SHA-1 bị nghi ngờ.
-
Họ SHA-2 có bốn biến thể SHA khác là SHA-224, SHA-256, SHA-384 và SHA-512
tùy thuộc vào số lượng bit trong giá trị băm của chúng. Chưa có cuộc tấn công thành
công nào được báo cáo về hàm băm SHA-2. Mặc dù SHA-2 là một hàm băm mạnh,
nhưng thiết kế cơ bản của nó vẫn theo thiết kế của SHA-1. Do đó, NIST đã kêu gọi
các thiết kế hàm băm mới.
-
Vào tháng 10 năm 2012, NIST đã chọn thuật toán Keccak làm tiêu chuẩn SHA-3
mới. Keccak cung cấp nhiều lợi ích, chẳng hạn như hiệu suất hiệu quả và khả năng
chống lại các cuộc tấn công tốt.
2.5.2. MySQL
MySQL là một hệ quản trị cơ sở dữ liệu quan hệ dựa trên Ngôn ngữ truy vấn có cấu
trúc (Structured Query Language), là ngôn ngữ phổ biến để truy cập và quản lý các bản ghi
(records) trong cơ sở dữ liệu. MySQL là phần mềm mã nguồn mở và miễn phí theo giấy
phép GNU. Nó được hỗ trợ bởi Công ty Oracle.
Vậy thì cơ sở dữ liệu (database) là gì? Cơ sở dữ liệu là một ứng dụng lưu trữ có tổ
chức các bản ghi (records). Nó có thể được người dùng truy cập và quản lý rất dễ dàng. Nó
cho phép chúng ta tổ chức dữ liệu thành các bảng, hàng, cột và chỉ mục để tìm kiếm thông
tin liên quan rất nhanh chóng. Mỗi cơ sở dữ liệu chứa API riêng biệt để thực hiện các hoạt
động như tạo, quản lý, truy cập và tìm kiếm dữ liệu mà nó lưu trữ. Ngày nay, nhiều cơ sở dữ
liệu có sẵn như MySQL, Sybase, Oracle, MongoDB, PostgreSQL, SQL Server, v.v. Dựa vào
cách mà dữ liệu được tổ chức thì có thể phân database ra làm hai loại: SQL và NoSQL.
MySQL là một dạng database thuộc loại SQL.
CƠ SỞ LÝ THUYẾT
20
MySQL hiện là phần mềm hệ quản trị cơ sở dữ liệu phổ biến nhất được sử dụng để
quản lý cơ sở dữ liệu có liên hệ, nghĩa là giữa các bảng dữ liệu có thể liên kết với nhau, một
đặc trưng của kiểu SQL. Đây là hệ quản trị cơ sở dữ liệu nhanh, có thể mở rộng và dễ sử
dụng so với Microsoft SQL Server và Oracle Database.
Trong luận văn này ta sẽ dùng MySQL để làm nhiệm vụ lưu trữ dữ liệu và
authentication cho kết nối với EMQ X Broker.
21
THIẾT KẾ VÀ THỰC HIỆN
CHƯƠNG 3:
THIẾT KẾ VÀ THỰC HIỆN
3.1. Triển khai EMQ X Broker
3.1.1. Sơ lược về EMQ X Broker
EMQ X là Broker MQTT mã nguồn mở được phát triển trên nền tảng Erlang/OTP.
EMQ X bắt đầu như một dự án mã nguồn mở ở Trung Quốc vào năm 2013. Các nhà phát
triển đã thành lập công ty EMQ Technologies Co., Ltd. vào năm 2017 để hỗ trợ thương mại
và dịch vụ. Công ty tuyên bố có hơn 5.000 người dùng doanh nghiệp và client từ các lĩnh
vực ứng dụng khác nhau. EMQ X hiện có sẵn trong nhiều phiên bản, dưới dạng Broker mã
nguồn mở thuần túy, bản trả phí Broker enterprise với nhiều tính năng hơn và dưới dạng
cloud. Ngoài ra còn có một biến thể nhẹ (cài đặt 15 MB) được gọi là “EMQ X Edge” cho
các IoT Gateway hạn chế tài nguyên, có thể giao tiếp với KubeEdge3.
Hiệu năng
Thông lượng tối đa (msg/s)
Độ trễ trung bình ở mức 1000msg/s (ms)
EMQX
28,000
6.4
HiveMQ
8,000
119.4
VerneMQ
10,000
8.7
Bảng 3.1 So sánh throughput và lantency giữa các nhà cung cấp dịch vụ MQTT
EMQ X được thiết kế có thể phục vụ lượng lớn client traffic với độ trễ thấp. Ngoài ra
còn rất nhiều tính năng khác có thể được người dùng config thông qua cơ chế mã nguồn mở
của nó, dễ dàng mở rộng quy mô hệ thống khi cần. Ở giới hạn luận văn này em sẽ sử dụng
EMQ X Broker mã nguồn mở được thiết lập trên server chạy hệ điều hành Ubuntu, sử dụng
tính năng mqtt Broker cùng với đó là khả năng connect với database, thiết lập rule engine để
kiểm soát luồng dữ liệu phục vụ việc liên kết database, bảo bật và phân quyền kiểm soát
thiết bị, người dùng ACL.
3.1.2. Thiết lập EMQ X Broker
3.1.2.1. Sử dụng dịch vụ Amazon Elastic Compute Cloud
Amazon Elastic Compute Cloud (Amazon EC2) là một dịch vụ web cung cấp khả năng
tính toán an toàn, có thể thay đổi kích thước trên đám mây. Nó được thiết kế để làm cho điện
toán đám mây quy mô web trở nên dễ dàng hơn cho các nhà phát triển. Giao diện dịch vụ
web đơn giản của Amazon EC2 cho phép ta lấy và định cấu hình dung lượng với mức tối
THIẾT KẾ VÀ THỰC HIỆN
22
thiểu. Nó cung cấp cho ta quyền kiểm soát hoàn toàn các tài nguyên máy tính của mình và
cho phép chạy trên môi trường máy tính đã được chứng thực của Amazon.
Ở đề tài luận văn này, ta sẽ sử dụng dịch vụ Amazon EC2 để tạo một server chạy trên
OS Ubuntu, cài đặt EMQ X Broker lên đó và tiến hành cấu hình các feature để tạo nên một
server MQTT hoạt động ổn định và bảo mật.
Hình 3.1 Instance server Ubuntu được tạo trên đám mây của Amazon EC2
Sau khi cài đặt EMQ X Broker, ta có thể truy cập vào dashboard của nó thông qua
public IP và port 18083. Ta có thể thiết lập username và password cho dashboard này, sẽ nói
ở phần tiếp theo.
Hình 3.2 Dashboard EMQ X Broker
3.1.2.2. EMQ X Broker authentication
Bảo mật là một phần quan trọng không thể thiếu trong bất kỳ hệ thống IoT nào. Giao
thức MQTT có hỗ trợ phương thức bảo mật thông qua username và password. Sử dụng bảo
THIẾT KẾ VÀ THỰC HIỆN
23
mật để ngăn chặn kết nối từ những client không mong muốn. Đối với EMQ X Broker, có hai
mức bảo mật được hỗ trợ:
-
Giao thức MQTT có định nghĩa trường username và password ở trong gói
CONNECT. EMQ X Broker hỗ trợ nhiều hình thức xác thực dựa trên username,
ClientID, HTTP, JWT, LDAP và các cơ sở dữ liệu khác nhau như MongoDB,
MySQL, PostgreSQL, Redis thông qua các plugin.
-
Tại lớp transport, TLS đảm bảo xác thực từ client đến server bằng cách sử dụng client
certificate và đảm bảo rằng server xác minh server certificate cho client. Xác thực
TLS / DTLS dựa trên PSK cũng được hỗ trợ.
Phương thức xác thực: EMQ X hỗ trợ việc sử dụng các nguồn dữ liệu tích hợp sẵn
(file, cơ sở dữ liệu tích hợp), JWT, cơ sở dữ liệu bên ngoài và API HTTP tùy chỉnh làm
nguồn dữ liệu xác thực. Kết nối nguồn dữ liệu và logic xác thực được thực hiện thông qua
các plugin. Mỗi plugin tương ứng với một phương thức xác thực và plugin tương ứng cần
được bật trước khi sử dụng. Khi client kết nối, plugin sẽ triển khai xác thực danh tính của
client bằng cách kiểm tra xem username/ clientid và password của nó có nhất quán với thông
tin của nguồn dữ liệu được chỉ định hay không. Ở giới hạn luận văn này sẽ sử dụng phương
thức kết nối với cơ sở dữ liệu ngoài, cụ thể là MySQL để làm nguồn dữ liệu xác thực.
Sau khi thực hiện xong quá trình xác thực sẽ có thể trả về các kết quả như sau:
-
Xác thực thành công: client được xác thực sau khi so sánh với dữ liệu nguồn và được
phép kết nối vào hệ thống.
-
Xác thực thất bại: client không được xác thực, nguyên nhân do dữ liệu nguồn khác
với dữ liệu mà client cung cấp, kết quả client không được kết nối vào hệ thống.
-
Bỏ qua: dữ liệu xác thực không được tìm thấy với phương pháp xác thực hiện tại và
không thể xác định kết quả một cách rõ ràng. Phương thức xác thực kế tiếp sẽ được
áp dụng (nếu có) hoặc chế độ anonymous sẽ được sử dụng để quyết định kết quả, tùy
thuộc vào cấu hình server mà sẽ cho phép client kết nối hay không.
THIẾT KẾ VÀ THỰC HIỆN
24
Chuỗi xác thực:
Hình 3.3 Sơ đồ thuật toán xác thực của EMQ X Broker
Khi nhiều phương thức xác thực được bật cùng lúc, EMQ X sẽ thực hiện xác thực
chuỗi theo thứ tự mở các plugin. Sau khi xác thực thành công, chấm dứt chuỗi xác thực và
cho phép client truy cập. Nếu xác thực không thành công, chấm dứt chuỗi xác thực và cấm
client truy cập. Nếu không vượt qua được cho đến phương thức xác thực cuối cùng, nó được
xác định theo cấu hình xác thực ẩn danh: Cho phép client truy cập khi xác thực ẩn danh được
bật hoặc từ chối quyền truy cập của client khi xác thực ẩn danh bị vô hiệu hóa.
Để sử dụng MySQL làm nguồn dữ liệu xác thực cho EMQ X Broker, ta cần cài đặt
MySQL vào server Ubuntu, liên kết với EMQ X Broker thông qua plugin, cấu hình file EMQ
X_auth_mysql.conf kết nối với MySQL và chọn phương thức băm. Trong luận văn này ta
dùng phương thức băm SHA256.
Hình 3.4 Cấu hình MySQL plugin sử dụng xác thực của EMQ X Broker
Về phía MySQL, ta sẽ tạo một database và tạo một table trong database đó để lưu
thông tin client bao gồm username và password, lưu ý password lưu trong table là password
đã băm bằng hàm MD5 và SHA256.
THIẾT KẾ VÀ THỰC HIỆN
25
Hình 3.5 Table MySQL tham chiếu cho quá trình xác thực của EMQ X Broker
Dưới đây sẽ mô tả quá trình xác thực của EMQ X dựa trên nguồn dữ liệu được lưu
trong MySQL.
Hình 3.6 Sơ đồ mô hình xác thực client của EMQ X Broker
-
Dữ liệu xác thực như mật khẩu (ciphertext) và salt được truy vấn theo quá trình SQL
xác thực kết hợp với thông tin do client chuyển vào. Nếu không có kết quả truy vấn,
xác thực sẽ kết thúc và kết quả "ignore" sẽ được trả về.
-
Chuỗi password mã hóa được tính toán theo quy tắc salting và phương pháp băm đã
được cấu hình từ trước. Nếu không có phương thức băm nào được bật, bước này sẽ
bị bỏ qua.
-
So sánh chuỗi password mã hóa được lưu trữ trong cơ sở dữ liệu với chuỗi password
mã hóa được tính từ password mà client hiện tại cung cấp. Nếu so sánh thành công,
xác thực thành công. Nếu không, xác thực không thành công.
THIẾT KẾ VÀ THỰC HIỆN
26
Với cách cấu hình bảo mật này, bất kì client nào muốn kết nối với EMQ X Broker
cũng sẽ phải cung cấp đúng username và password đã được lưu trong MySQL phía server.
Lưu ý một cặp username password có thể được nhiều client khác nhau sử dụng cùng lúc.
3.1.3. Tích hợp giao thức SSL/TLS vào hệ thống EMQ X
3.1.3.1. Thiết lập kết nối bảo mật trên Web Server EMQ X Broker
Để thuận tiện cho việc truy cập vào dashboard mà không cần phải nhớ IP, ta sẽ đăng
ký một tên miền (miễn phí trong 12 tháng) tại freenom.com. Tuy nhiên lúc này ta vẫn phải
nhập port khi truy cập vào Broker tại địa chỉ phuongtung08081.tk (port 18083). Mặc định
HTTP request sẽ trỏ đến port 80 của server, vì vậy ta cần một cơ chế chuyển tiếp port, để
khi nhập địa chỉ dashboard, tức đang truy cập port 80, server sẽ hiểu ta đang truy cập vào
dashboard ở port 18083. Lúc này ta cần dùng đến Proxy Server.
Hình 3.7 Cấu hình tên miền cho server EMQ X Broker
Proxy server
Proxy server là thiết bị trung gian giữa clien và server, nó hoạt động như một gateway
để xử lý dữ liệu, thiết lập tường lửa,… trước khi dữ liệu được server nhận/gửi. Ở đây ta sẽ
dùng proxy server NGINX.
Thực hiện cài đặt NGINX thông qua lệnh linux:
sudo apt install nginx
sudo nano /etc/nginx/sites-available/default
Thêm vào trường "location" trong file cấu hình:
server_name phuongtung08081.tk www. phuongtung08081.tk;
location / {
proxy_pass http://localhost:18083; #port của dashboard EMQ X
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
THIẾT KẾ VÀ THỰC HIỆN
27
proxy_cache_bypass $http_upgrade;
}
Sau khi cài đặt và cấu hình thành công NGINX proxy server thì ta đã có thể truy cập
vào dashboard qua địa chỉ phuongtung08081.tk.
Kết nối TLS/SSL trên dashboard EMQ X
Bước tiếp theo cần làm đó là thiết lập kết nối TLS/SSL trên dashboard (biểu hiện bằng
biểu tượng ổ khóa trên thanh địa chỉ browser). Ta sẽ sử dụng certificate của third party là
LetsEncrypt, một loại certificate miễn phí được cung cấp bởi Internet Security Research
Group (ISRG). Cerbot của LetsEncrypt sẽ làm thay ta các công việc cấu hình certificate như
tạo public/private key, asymetric key, CA certificate. Ta chỉ cần cấu hình bằng các lệnh như
sau:
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install python-certbot-nginx
sudo certbot --nginx -d phuongtung08081.tk www. phuongtung08081.tk
Hạn sử dụng certbot là 90 ngày, sau khi hết hạn ta có thể cấu hình gia hạn để tiếp tục
sử dụng.
Hình 3.8 Certificate được cấp bởi LetsEncrypt
3.1.3.2. Thiết lập kết nối bảo mật giữa EMQ X Broker và Client
Ở phần trên ta đã thiết lập kết nối bảo mật khi truy cập vào dashboard từ browser. Bây
giờ ta sẽ thiết lập SSL/TLS cho kết nối giữa Client, cụ thể là các ESP32 và EMQ X Broker.
THIẾT KẾ VÀ THỰC HIỆN
28
Thông thường để xác minh certificate của server thì cần dùng CA của third party, đa phần
phải trả phí. Nhưng ở đây để tiết kiệm ta sẽ tạo CA certifiate bằng OpenSSL, sau đó dùng
CA certificate để tạo các certificate khác cho server EMQ X (gọi là self-signed certificate).
Ta sử dụng các lệnh sau:
-
openssl genrsa -out ca.key 2048. Lệnh này sẽ tạo ra key có chiều dài 2048 và được
lưu trong ca.key, sau đó ta dùng key này để tạo root certificate.
-
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.pem.
-
Root certificate là điểm khởi đầu của quá trình xác thực. Bên cạnh đó ta sẽ cần tạo
private key cho EMQ X: openssl genrsa -out emqx.key 2048
-
Tiếp theo ta dùng key này để tạo certificate request: openssl req -new -key ./emqx.key
-config openssl.cnf -out emqx.csr
-
Sau đó ta sẽ dùng root certificate để tạo certificate: openssl x509 -req -in ./emqx.csr
-CA ca.pem -CAkey ca.key -CAcreateserial -out emqx.pem -days 3650 -sha256 extensions v3_req -extfile openssl.cnf
-
Verify bằng lệnh: openssl verify -CAfile ca.pem emqx.pem. Nếu trả về emqx.pem:
OK thì các certificate đã được tạo thành công.
Tiếp theo ta sẽ dùng các key và ceritificate này để cấu hình cho EMQ X Broker.
Hình 3.9 Gán các key và certificate vừa tạo vào trong file cấu hình của EMQ X
Lúc này EMQ X đã được cấu hình SSL/TLS thành công. Để client có thể kết nối
SSL/TLS với Broker, client sẽ phải mang theo CA certificate ca.pem được tạo lúc nãy và
connect vào port của mqqts là 8883. Một lưu ý là sau khi cấu hình Broker có SSL/TLS thì
THIẾT KẾ VÀ THỰC HIỆN
29
sẽ không thể kết nối với Broker qua websocket (ws) được nữa mà phải dùng websocket
secure (wss).
3.2. Mạng mesh wifi
3.2.1. Phần cứng
3.2.1.1. Các loại cảm biến
Trong các ứng dụng IoT, cảm biến là linh kiện rất quan trọng để người dùng có thể thu
thập dữ liệu từ môi trường, từ đó đưa ra những tính năng phù hợp trong hệ thống của mình.
Ở đồ án môn học này, chúng em sử dụng hai loại cảm biến là cảm biến cường độ ánh sáng
Photodiode và cảm biến nhiệt độ & độ ẩm DHT11.
a) Cảm biến cường độ ánh sáng Photodiode
Cảm biến ánh sáng Photodiode là một module rất nhạy cảm với cường độ ánh sáng
môi trường xung quanh, thường được sử dụng để phát hiện độ sáng môi trường xung quanh
và cường độ ánh sáng, định hướng, gây ra chỉ có ánh sáng trực tiếp ở phía trước của bộ cảm
biến, tìm kiếm cho các hiệu ứng ánh sáng tốt hơn, chính xác hơn.
Thông số kỹ thuật:
Điện áp hoạt động: 3V - 5V (DC)
Dải độ ẩm hoạt động: 20% - 90% RH, sai số 5%RH
Dải nhiệt độ hoạt động: 0C 50C, sai số 2C
Khoảng cách truyền tối đa: 20m
Hình 3.10 Cảm biến ánh sáng photodiode
THIẾT KẾ VÀ THỰC HIỆN
30
b) Cảm biến nhiệt độ & độ ẩm DHT11
DHT11 Là cảm biến rất thông dụng hiện nay vì chi phí rẻ và rất dễ lấy dữ liệu thông
qua giao tiếp 1-wire (giao tiếp digital 1-wire truyền dữ liệu duy nhất). Cảm biến được tích
hợp bộ tiền xử lý tín hiệu giúp dữ liệu nhận về được chính xác mà không cần phải qua bất
kỳ tính toán nào.
Thông số kỹ thuật:
Điện áp hoạt động: 3V - 5V (DC)
Dải độ ẩm hoạt động: 20% - 90% RH, sai số 5%RH
Dải nhiệt độ hoạt động: 0C 50C, sai số 2C
Khoảng cách truyển tối đa: 20m
Hình 3.11 Cảm biến độ ẩm, nhiệt độ DHT11
3.2.1.2. NodeMCU 8266
NodeMCU được phát triển dựa trên Chip WiFi ESP8266EX bên trong Module
ESP-12E dễ dàng kết nối WiFi với một vài thao tác.Board còn tích hợp IC CP2102,
giúp dễ dàng giao tiếp với máy tính thông qua Micro USB để thao tác với board. Và
có sẳn nút nhấn, led để tiện qua quá trình học, nghiên cứu. Ở đồ án này chúng em sử dụng
phiên bản ESP8266 NodeMCU Lua CP2102.
Thông số kỹ thuật:
-
IC chính: ESP8266
-
Phiên bản firmware: NodeMCU Lua
-
Chip nạp và giao tiếp UART: CP2102.
-
GPIO tương thích hoàn toàn với firmware Node MCU.
-
Cấp nguồn: 5VDC MicroUSB hoặc Vin.
-
GIPO giao tiếp mức 3.3VDC
-
Tích hợp Led báo trạng thái, nút Reset, Flash.
THIẾT KẾ VÀ THỰC HIỆN
-
Tương thích hoàn toàn với trình biên dịch Arduino.
-
Kích thước: 25 x 50 mm
31
Hình 3.12 Sơ đồ chân NodeMCU ESP8266
3.2.1.3. NodeMCU-32
Kit RF thu phát Wifi ESP32 NodeMCU LuaNode32 có 30 chân được phát triển trên
nền module trung tâm là ESP32 với công nghệ Wifi, BLE và nhân ARM SoC tích hợp mới
nhất hiện nay, kit có thiết kế phần cứng, firmware và cách sử dụng tương tự Kit NodeMCU
ESP8266, với ưu điểm là cách sử dụng dễ dàng, ra chân đầy đủ. Mạch WiFi này là sự lựa
chọn hàng đầu trong các nghiên cứu, ứng dụng về Wifi, BLE, IoT và điều khiển, thu thập dữ
liệu qua mạng.
Thông số kỹ thuật:
-
Nguồn vào: 5VDC cấp từ cổng micro USB.
-
Tích hợp mạch nạp và giao tiếp UART CP2102.
-
Tích hợp Led Status, nút BOOT và UNABLE
-
Kích thước: 28.33x51.45 mm
THIẾT KẾ VÀ THỰC HIỆN
32
Hình 3.13 Sơ đồ chân NodeMCU ESP32
Ở đây gồm 3 NodeMCU ESP8266: một server và 2 node có gắn cảm biến (nhiệt độ,
độ ẩm và ánh sáng). Node con sẽ gửi dữ liệu thu thập từ cảm biến đến server thông qua cơ
chế mạng mesh, được tạo nên nhờ sử dụng thư viện Painless Mesh của arduino. Thực tế thì
luận văn sử dụng tổng cộng 6 node trong mạng mesh để đọc cảm biến và bật tắt relay.
Hình 3.14 Sơ đồ mạng mesh các node ESP32/8266 thu thập dữ liệu từ cảm biến
3.2.2. Phần mềm
Để cấu hình mạng mesh trên ESP32/8266, ta sử dụng thư viện painlessMesh.
PainlessMesh là một mạng ad-hoc, có nghĩa là không cần bộ điều khiển trung tâm hoặc
router. Bất kỳ hệ thống nào gồm 1 hoặc nhiều nút sẽ tự tổ chức thành lưới đầy đủ chức năng.
THIẾT KẾ VÀ THỰC HIỆN
33
Kích thước tối đa của lưới bị giới hạn bởi dung lượng bộ nhớ trong heap có thể được
phân bổ cho bộ đệm kết nối phụ và do đó sẽ thực sự khá cao.
Mạng mesh trong hệ thống được xây dựng với 6 node ESP32/8266. Các loại node
trong mạng mesh của hệ thống gồm:
-
Non-root node được gắn với cảm biến ánh sáng hoặc cảm biến nhiệt độ độ ẩm
DHT11. Các node cảm biến này định kì sẽ gửi dữ liệu thu thập được về node root
thông qua mạng mesh.
-
Các non-root node khác sẽ kết nối với relay để điều khiển đèn. Nhận lệnh từ App di
động thông qua nhập text hoặc gửi lệnh bằng giọng nói.
-
Node root có chức năng quét định kỳ để kiểm tra các thiết bị kết nối vào mạng mesh,
thu nhận giá trị được các node cảm biến gửi về và publish lên EMQ X Broker thông
qua topic "painlessMesh/from/ID" với ID của từng node cảm biến riêng biệt. Ngoài
ra node root có tính năng tự connect với WiFi và mesh sau một khoảng thời gian nhất
định nếu bị ngắt kết nối đột ngột. Có sử dụng chức năng LWT và Retain trong MQTT
để thông báo cho người dùng về trạng thái kết nối của node.
Hình 3.15 Dữ liệu nhận được từ các node trong mạng mesh
3.3. Camera Streaming qua giao thức WebSocket
3.3.1. Phần cứng
Trong luận văn này ta sẽ dùng camera trên ESP32-CAM do giá thành rẻ, dễ sử dụng
và chất lượng ở mức ổn.
Thông số kỹ thuật
Module trung tâm: Ai-Thinker ESP32-S
Power Supply: 5VDC (nguồn từ 2A trở lên)
Điện áp giao tiếp GPIO: 3.3VDC
THIẾT KẾ VÀ THỰC HIỆN
34
RAM: 520KB SRAM +4M PSRAM
Image Output Format: JPEG( OV2640 support only ),BMP,GRAYSCALE
Hình 3.16 Sơ đồ chân ESP32-CAM
3.3.2. Phần mềm
ESP32-CAM có hỗ trợ thư viện esp_camera.h để sử dụng camera gắn trên board, có
hỗ trợ webUI để thu video streaming, ESP32-CAM có thể là server hoặc client đều được. Ở
đây để có thể nhận video stream ở bất cứ đâu có internet, ta sẽ dùng ESP32-CAM làm client
gửi frame lên server đã được config trên Amazon EC2 thông qua giao thức WebSocket.
Server EC2 sẽ forward gói tin đến listener là Flutter App để hiển thị cho người dùng.
Hình 3.17 Sơ đồ giao tiếp video streaming thông qua WebSocket
THIẾT KẾ VÀ THỰC HIỆN
35
3.4. Web Server nhúng trên ESP32
3.4.1. Yêu cầu thiết kế
Thông thường, để cấu hình thông số cho các loại kết nối WiFi, MQTT trên ESP32, ta
sẽ phải vào source code và chỉnh sửa. Điều này gây rất nhiều bất tiện khi ta muốn thay đổi
thông số cấu hình cho những trường hợp sử dụng khác nhau, chẳng hạn như thay đổi địa
điểm dẫn đến cần thay đổi kết nối WiFi, kết nối với một Broker khác, sử dụng ID client khác
hoặc quan trọng nhất là sự tùy biến trong việc publish và subscribe vào các topic khác nhau
để thiết lập một hệ thống theo cấu trúc ACL (sẽ nói ở phần sau). Bên cạnh đó thì việc có
giao diện web sẽ giúp hiển thị các kết quả dữ liệu thu thập trên ESP32 một cách trực quan
hơn nhiều so với khi nhìn trong console. Do đó, việc xây dựng một Web Server nhúng trên
ESP32 để phục vụ cho các mục đích trên là rất cần thiết.
Để hiện thực được Web Server ESP32 thì cần phải sử dụng các công cụ khác nhau. Về
phía back end của web được code bằng framework Arudino trên ESP32, để có thể lưu được
các file HTML, CSS, Javascript để gửi response cho client, ta sẽ cần lưu các file ấy vào bộ
nhớ flash của ESP32, mục đích là để dữ liệu không bị mất mỗi lần ta nạp lại code. Ở đây ta
sử dụng SPIFFS (SPI Flash File System), một cơ chế giao tiếp file system dùng cho ESP32.
Với bộ nhớ flash 4MB của ESP32 thì ta có thể dùng nó để lưu các file HTML, CSS và
Javascript.
Các thư viện cần sử dụng
Để có thể giao tiếp giữa client và server thông qua giao thức HTTP, ta cần sử dụng thư
viện ESPAsyncWeb Server.h, đây là thư viện được viết để xây dựng server bất đồng bộ cho
ESP32, nghĩa là nó có thể giải quyết nhiều tác vụ khác nhau cùng lúc. Chẳng hạn như khi
đang xử lý response cho request A thì server đã sẵn sàng để nhận và handle request B, điều
này giúp tăng tốc độ phản hồi của Web Server.
Ngoài ra do có sử dụng cơ chế authentication thông qua JWT token, nên ta sẽ cần sử
dụng thư viện mã hóa dùng cho các thiết bị nhúng, cụ thể ở đây ta sẽ dùng mbedtls/md.h để
thực hiện quá trình xác thực bằng JWT token.
Ngôn ngữ xây dựng front end
Vì dung lượng bộ nhớ của flash ESP32 là rất giới hạn (4MB trong đó dung lượng khả
dụng còn thấp hơn), cho nên để xây dựng front end của web ta cần lựa chọn công cụ giúp
build ra sản phẩm có dung lượng càng nhỏ càng tốt. Có rất nhiều lựa chọn cho chúng ta như
viết thuần HTML, CSS, Javascipt, dùng framework như React, Svelte. Ở đây em chọn dùng
THIẾT KẾ VÀ THỰC HIỆN
36
Svelte lí do vì đây là một framework mới, có nhiều cải tiến, nó không sử dụng cơ chế virtual
DOM để build front end, vì vậy dung lượng file build bằng Svelte là nhỏ hơn nhiều so với
các framework như React, VueJS,… Với khối lượng của website trong giới hạn luận văn
này khi build bằng Svelte thì dung lượng chỉ tầm 300KB nhưng vẫn có đầy đủ các tính năng
của một website bình thường. Hơn nữa Svelte sử dụng cơ chế client side rendering nên việc
gửi nhận gói tin giữa server và client sẽ được tối ưu hơn nhiều do không cần phải gửi quá
nhiều file, phần việc của server sẽ nhẹ nhàng hơn do client browser đã đảm nhận khá nhiều
công việc.
Svelte dù là một framework khá mới và không phổ biến, nhưng lại vô cùng phù hợp
cho những ứng dụng trong hệ thống nhúng, vì sự gọn nhẹ và tốc độ cao của nó. Dưới đây là
bản so sánh về memory giữa 4 framework khác nhau là react, vue, angular và svelte.
Bảng 3.2 Memory test giữa svelte và các framework phổ biến [6]
Có thể thấy svelte hoàn toàn vượt trội so với các framework còn lại. Vì vậy đây sẽ là
framework mà ta sử dụng để lập trình web nhúng trên ESP32.
3.4.2. Thực hiện Web Server ESP32
Web Server sẽ có các tính năng chính sau đây:
-
Đăng ký, đăng nhập, xác thực người dùng thông qua cơ chế JWT token.
THIẾT KẾ VÀ THỰC HIỆN
-
Giao diện kết nối WiFi.
-
Giao diện kết nối MQTT và hiển thị các thông tin user, topic, message.
37
Cơ chế hoạt động của Web Server:
-
Giao diện được build bằng Svelte, một framework của javascript cho phép thiết kế
front end với dạng client side rendering. Svelte sau khi build ra sẽ gom hết tất cả các
file về một file HTML duy nhất và các bunle css và javascipt để add vào file HTML.
-
Khi browser request thì server ESP32 sẽ gửi cho browser một file HTML duy nhất
và các file css, javascript tương ứng (được gửi khi browser chạy file HTML và
HTML request các file sau đó). Lúc này Web Server sẽ được hiển thị lên browser.
-
Website khi thực hiện các chức năng như kết nối WiFi, MQTT sẽ gửi POST request
đến cho server và server sẽ nhận và xử lý, gửi trả về client các status, client dựa vào
các status đó để chuyển qua các route (trang) khác nhau. Tức là về bản chất tất cả các
trang đã được server gửi cho client ở lần response đầu tiên, chứ không phải gửi lần
lượt ở các response khác nhau. Cơ chế này giúp giảm nhẹ khối lượng gói tin server
gửi cho client trong mỗi HTTP request/ response.
Hình 3.18 Màn hình landing page của web server
Khi mở web server bằng cách nhập IP local của node root vào trình duyệt, ta sẽ thấy
trang langding page như trên. Click vào nút "Start Now" sẽ đưa ta chuyển đến tab đăng
nhập.
THIẾT KẾ VÀ THỰC HIỆN
38
Hình 3.19 Màn hình đăng nhập của web server
Username và password được lập trình sẵn trong firmware của node root. Hạn chế của
web server hiện tại là chưa có chức năng đăng ký cho lần đăng nhập đầu. Khi người dùng
nhập đúng username và password thì server sẽ nhận gói tin POST request từ browser, lấy
username và password từ đó ra và so sánh với thông tin trong firmware, nếu đúng thì người
dùng được xác thực thành công, được phép truy cập vào web. Server sẽ dùng username và
password đấy để tạo ra một JWT và response về client, browser sẽ lưu JWT vào cookie để
các lần truy cập sau không cần phải đăng nhập nữa do server có cơ chế authenticate bằng
JWT. Cơ chế này hiệu quả hơn authenticate bằng session ID ở chỗ thông tin xác thực được
lưu trong JWT phía client, server sẽ không phải chịu thêm phần lưu thông tin, dễ mở rộng
hệ thống với nhiều client.
Hình 3.20 Giao diện dashboard của web server
THIẾT KẾ VÀ THỰC HIỆN
39
Sau khi authenticate thành công người dùng sẽ được chuyển đến trang dashboard. Ở
đây web sẽ hiển thị thông tin của broker hiện tại như địa chỉ broker, username, client ID, còn
trạng thái kết nối được hiện ở card "STATUS". Ở dưới sẽ có hiển thị các gói tin mà node
root publish hoặc gói tin nhận được từ topic mà nó subscribe dưới dạng các card gồm các
trường topic, message, QoS,… được update realtime liên tục qua giao thức WebSocket. Ở
đây không dùng HTTP mà dùng WebSocket là vì cần update hiển thị liên tục, nếu dùng
HTTP thì sẽ phải mở request liên tục ứng với mỗi gói tin nhưng với WebSocket chỉ cần mở
connection một lần và server và client sẽ giao tiếp qua kênh đó luôn nên tiện cho việc update
realtime.
Hình 3.21 Giao diện setting của web server
Khi chuyển qua tab setting ta có thể config các thông số như thay đổi broker, subsribe
vào topic mới, publish vào topic. Cơ chế này hoạt động bằng cách gửi HTTP POST request
chứ thông tin cần thay đổi đến web server, server sẽ có API handle gói tin POST và thực
hiện các lệnh cần thiết. Tuy nhiên cơ chế này vẫn đang còn khá nhiều exception và cần được
cải tiến thêm.
3.5. App di động
3.5.1. Yêu cầu thiết kế
Với nhu cầu cần có một ứng dụng để thu thập dữ liệu về smartphone của người dùng
để tiện cho việc điều chỉnh, theo dõi hoạt động của các thiết bị, nên ta sẽ viết một ứng dụng
di động để phục vụ cho công việc trên.
THIẾT KẾ VÀ THỰC HIỆN
40
Để hiện thực app di động, ở đây ta sẽ sử dụng ngôn ngữ lập trình dart trên framework
flutter.
Flutter
Flutter là một framework dùng để phát triển App di động trên cả nền tảng Android và
IOS. Thông thường với các framework khác để phát triển ứng dụng trên Android và IOS ta
phải dùng nhiều ngôn ngữ khác nhau (Java với Android hoặc Swift với IOS), nhưng với
Flutter ta chỉ cần sử dụng duy nhất một ngôn ngữ gọi là Dart, render UI trực tiếp mà không
cần phải thông qua framework đặc thù của từng platform.
Với Flutter, tất cả mọi thứ đều là Widget, tức các thành phần tạo nên UI của App di
động, được Flutter đóng gói sẵn thành một thư viện rộng lớn đủ để ta tạo ra App phù hợp
với nhu cầu sử dụng. Không như các framework khác, Flutter xây dựng UI trực tiếp trên
code dart chứ không cần thông qua ngôn ngữ giao diện khác như HTML.
Ngôn ngữ lập trình Dart
Dart là ngôn ngữ lập trình hướng đối tượng (object-oriented programming language)
được phát triển bởi Google. Dart có một hệ thống thư viện phong phú phục vụ nhu cầu người
dùng. Các nhà phát triển tại Google và các nơi khác sử dụng Dart để tạo các ứng dụng chất
lượng cao cho iOS, Android và web. Dart giúp bạn tạo ra những trải nghiệm đẹp, chất lượng
cao trên tất cả các màn hình với bộ công cụ linh hoạt và framework mạnh mẽ của mình.
Ưu điểm của Dart:
-
Cú pháp Dart rõ ràng và súc tích, có các thư viện hữu ích và một hệ sinh thái gồm
hàng ngàn package.
-
Dart cung cấp tối ưu hóa việc biên dịch để có được hiệu suất cao và khởi động nhanh
trên các thiết bị di động và web.
-
Dart rất dễ để làm quen nhờ vào cú pháp quen thuộc. Nếu bạn đã biết C ++, C # hoặc
Java, bạn có thể làm việc hiệu quả với Dart chỉ sau vài ngày.
Nhược điểm:
-
Cần có kiến thức về quản lý components, quản lý state trong project
-
Nếu chưa từng code ứng dụng mobile bao giờ thì tự học Dart và Flutter sẽ khá thử
thách.
Yêu cầu thiết kế app di động
-
Có chức năng authenticate
THIẾT KẾ VÀ THỰC HIỆN
-
41
App có chức năng kết nối với Broker thông qua giao thức MQTT, có trường input
để nhập thông tin về Broker, username, password, clientID, port, có thể
publish/subscribe vào nhiều topic cùng lúc.
-
Có giao diện gửi/nhận tin nhắn với chức năng tùy chọn Retain và các mức QoS khác
nhau.
-
Có giao diện hiển thị bằng gauge chart các dữ liệu ánh sáng, nhiệt độ, độ ẩm thu thập
bởi các node ESP32/8266.
-
Có thể kết nối lên server thông qua giao thức WebSocket và nhận về video stream
realtime.
3.5.2. Sản phẩm android app
Với những yêu cầu trên, ta sẽ dùng ngôn ngữ Flutter để lập trình. App sau khi hoàn
thiện sẽ gồm có 5 tab:
-
Kết nối MQTT
-
Subscribe topic
-
Hiển thị và gửi gói tin
-
Hiển thị dữ liệu thu thập từ cảm biến thông qua gauge chart
-
Hiển thị video streaming realtime.
App có sử dụng cơ chế quản lý state dữ liệu một cách hiệu quả để khi load tab mới thì
không phải load lại toàn bộ widget tree và dữ liệu, đây là một cải tiến so với phiên bản app
di động đã sử dụng trong đồ án. Cụ thể ta sẽ dùng cơ chế Provider và Listener để xây dựng
hệ thống quản lý state cho app. Ở phiên bản app đồ án, tuy có nhiều tab nhưng app được viết
thẳng trên một source duy nhất, tức là chỉ có 1 stateful widget duy nhất và render ra từng
screen tương ứng khi người dùng chọn và không sử dụng quản lý state. Dẫn đến việc mỗi
lần người dùng chuyển tab thì toàn bộ app sẽ phải rebuild lại, kể cả những tab chẳng có thay
đổi gì so với trạng thái trước cũng được rebuild toàn bộ. Điều này gây lãng phí tài nguyên
và không hiệu quả về mặt hiệu năng.
Phiên bản app này cải tiến hơn ở chỗ đã tách các screen ra thành từng widget riêng
biệt, stateful hay stateless tùy thuộc tab đó có cần thay đổi state từ bên trong widget hay
không. Ví dụ như tab hiển thị dữ liệu nhiệt độ, độ ẩm, ánh sáng lên gauge chart thì chỉ cần
dùng stateless, còn tab gửi tin nhắn thì bắt buộc phải là stateful widget. App cũng sẽ sử dụng
cơ chế quản lý state để tránh tình trạng rebuild khi không cần thiết. Tức state dữ liệu dùng
THIẾT KẾ VÀ THỰC HIỆN
42
cho các tab giao tiếp MQTT sẽ được lưu ở một class có tính chất của Provider, truyền dữ
liệu cho các tab được gán Listener. Điều này cho phép các tab chỉ được rebuild khi phần dữ
liệu mà tab đó đang listen thay đổi, còn không thì khi app rebuild nó vẫn giữ nguyên, giúp
cho hiệu năng của app tăng lên đáng kể so với việc không dùng quản lý state.
Đối với tab stream video giao tiếp qua WebSocket, tab này không dùng chung Provider
với các tab giao tiếp MQTT mà sẽ dùng cơ chế StreamBuilder để liên tục stream dữ liệu từ
server về bằng giao thức WebSocket.
Các cơ chế quản lý state như Provider, StreamBuilder, Stateful Stateless Widget đều
là các feature được xây dựng sẵn trong flutter và các gói thư viện của nó. Còn rất nhiều tính
năng hữu ích khác flutter cung cấp để người dùng có thể build app hiệu quả hơn nhưng ở
mức độ app của luận văn chỉ cần sử dụng hai tính năng trên là đã đủ để build một app giao
tiếp MQTT và WebSocket chạy ổn định.
Ở phần dưới ta sẽ đi qua từng tab và tính năng cụ thể của app.
Hình 3.22 Màn hình connect MQTT trên Flutter app
Khi mở app thì màn hình connect mặc định sẽ được chọn. Ở đây người dùng có thể
nhập các thông số của broker và bấm connect để kết nối. Dấu tích ở trên biểu tượng đám
mây cạnh tên tab biểu hiện trạng thái kết nối. App mặc định đã kết nối đến broker EMQX
nên ta không cần nhập thủ công nếu như không có nhu cầu thay đổi broker.
THIẾT KẾ VÀ THỰC HIỆN
43
Hình 3.23 Màn hình thêm topic trên Flutter app
Màn hình kế tiếp dùng để thêm topic vào app. Để sử dụng app cho việc publish hoặc
subscribe gói tin vào topic nào thì ta cần phải add topic đó ở màn hình này trong khung nhập
text sau đó bấm add topic. Các topic hiện đang available sẽ hiển thị ở dưới. Muốn bỏ topic
nào thì chỉ cần click vào dấu x bên cạnh khung tên topic.
Hình 3.24 Màn hình hiển thị gói tin nhận được trên app Flutter
THIẾT KẾ VÀ THỰC HIỆN
44
Ở tab Messages ta sẽ quan sát được những gói tin mà app nhận được qua những topic
chúng ta đã add ở tab Topic. Các gói tin hiển thị dưới dạng các card widget gồm tên topic
và payload. Để xóa các gói tin hiện tại thì ta bấm vào nút "CLEAR" ở bên dưới, app sẽ xóa
các gói tin đó trong global state và rebuild những phần cần thiết của UI update lại giao diện.
Góc dưới bên phải có floating button biểu tượng dấu cộng, click vào đó ta sẽ chuyển sang
tab gửi gói tin MQTT.
Hình 3.25 Màn hình gửi gói tin trên Flutter app
Màn hình dùng để gói tin bằng giao thức MQTT bằng text hoặc ra lệnh bằng giọng
nói. Với gửi lệnh bằng text ta nhập payload vào ô Message và nhập topic vào ô Topic, lưu
ý chỉ có thể gửi đến những topic được add ở tab topic trước đó. Có thể chọn mức QoS ở các
nút bên dưới cũng như chọn bật tắt cờ retain.
Để gửi lệnh bằng giọng nói ta nhấn vào floating button biểu tượng chữ A ở góc trái
bên dưới màn hình. Đây là nút bật API nhận diện giọng nói của Alan Voice, ta có thể dùng
nó để gửi các lệnh đến hệ thống qua giao thức MQTT với những câu lệnh đã được lập trình
sẵn. Luận văn sẽ demo chức năng này bằng cách gửi lệnh giọng nói để điều khiển bật tắt đèn
trong mô hình smart home từ xa.
THIẾT KẾ VÀ THỰC HIỆN
45
Hình 3.26 Màn hình hiển thị thông số cảm biến trên app Flutter
Ở màn hình Monitor ta sẽ có các gauge chart để hiện thông số nhiệt độ, độ ẩm và ánh
sáng nhận được từ các cảm biến gắn trên NodeMCU. Dữ liệu gửi đến app dưới dạng json
text sẽ được tách ra và đưa lên hiển thị trên gauge chart, update realtime mỗi lần nhận được
gói tin có giá trị mới thì kim hiển thị sẽ thay đổi do app được rebuild ở phần widget hiển thị
gauge chart, còn các phần khác vẫn giữ nguyên.
Hình 3.27 Màn hình stream video từ server WebSocket
THIẾT KẾ VÀ THỰC HIỆN
46
Màn hình cuối cùng của app không dùng giao thức MQTT mà dùng giao thức
websocket để kết nối đến server chạy trên máy ảo aws. Mặc định màn hình sẽ chỉ hiện
loading circle, khi có stream từ server thì app sẽ tự động update thông qua StreamBuilder để
hiện video được Stream về. Một bất tiện về UI ở đây là icon đám mây connect ở tab này
không biểu thị cho trạng thái websocket mà là của MQTT.
3.6. Hệ thống IoT sử dụng ACL và multiple users
3.6.1. ACL là gì, vì sao cần ACL trong hệ thống IoT
Access control list (ACL) là một bộ lọc được cấu hình với nhiều rule cho phép hoặc
từ chối truy cập vào môi trường nhất định. Thông thường có thể chia ACL thành 2 loại:
-
Filesystem ACL: một dạng bộ lọc truy cập vào các file hoặc directory trong thiết bị.
Filesystem ACL sẽ nói cho máy chủ biết là user nào có thể truy cập vào hệ thống và
được phép truy cập ở mức nào. Điều này giúp tăng độ bảo mật cho hệ thống. Ví dụ
user A chỉ được phép truy cập vào một table trong MySQL thì khi user A bị chiếm,
thì kẻ xâm nhập cũng chỉ được quyền truy cập vào một table mà không làm ảnh
hưởng đến các table dữ liệu khác, hạn chế sự nguy hại cho hệ thống.
-
Networking ACL: dạng bộ lọc các truy cập vào hệ thống. Ví dụ router hay switch có
thể lọc ra traffic nào được phép truy cập vào hệ thống mạng LAN và được thực hiện
hành động gì trong hệ thống. ACL của EMQ X Broker thuộc dạng này.
Những lý do cần sử dụng ACL:
-
Điều khiển luồn dữ liệu
-
Cấm một số traffic không cần thiết từ đó cải thiện hiệu năng của hệ thống
-
Tăng độ bảo mật cho hệ thống. Những thiết bị chỉ được cấp quyền truy cập và thực
hiện một số chức năng nhất định cần thiết mà không được can thiệp sâu vào các phần
khác của hệ thống.
-
Tạo sự linh hoạt, dễ điều chỉnh, chuyển đổi giữa các thiết bị do mỗi thiết bị trong hệ
thống.
3.6.2. Sử dụng ACL và Rule Engine Republish với EMQ X Broker
3.6.2.1. Cơ chế hoạt động của ACL trong EMQ X Broker
Trong EMQ X Broker, ACL được áp dụng để kiểm soát quá trình publish/subscribe
của client. Sự kiểm soát này có thể được thực hiện thông qua username, client ID, địa chỉ IP
của client. Ví dụ ACL thiết lập client có tên là "tung" sẽ không thể publish vào topic
THIẾT KẾ VÀ THỰC HIỆN
47
device/thy/temperature. EMQ X có hỗ trợ sử dụng ACL với nhiều cơ chế khác nhau như
HTTP, MySQL, MongoDB,… Ở đây ta sẽ sử dụng ACL built in của EMQ X cho tiện.
Câu lệnh cấu hình ACL sẽ có cấu trúc như sau: "Allow/Deny" "Who"
"Subscribe/Publish" "Topics". Các câu lệnh ACL được viết bằng cú pháp của ngôn ngữ
Erlang. Có thể cấu hình nhiều câu lệnh ACL cùng lúc, EMQ X sẽ gộp các câu lệnh đó lại để
thực thi. Như ví dụ hình bên dưới thì nó sẽ thực thi các câu lệnh theo thứ tự từ trên xuống
dưới.
Hình 3.28 Các câu lệnh Erlang khi cấu hình ACL trên EMQ X
Rule đầu tiên cho phép client publish và subscribe tất cả các topic.
Rule thứ hai cấm tất cả client subscribe các topic $ SYS / # và #.
Rule thứ ba cho phép client có địa chỉ IP 127.0.0.1 publish / subscribe các topic $ SYS / #
và #, điều này tạo nên một trường hợp đặc biệt cho rule thứ hai.
Rule thứ tư cho phép client có bảng điều khiển tên người dùng subscribe topic $ SYS / #,
điều này tạo nên một trường hợp đặc biệt cho rule thứ hai.
Sau khi quá trình ACL hoàn tất có thể trả về các kết quả như sau:
-
Allow: client được phép truy cập vào hệ thống.
-
Deny: client bị cấm truy cập vào hệ thống.
-
Ignore: Không có lệnh ACL nào được tìm thấy, và kết quả sẽ được trả về hoặc là
allow hoặc là deny, tùy thuộc vào cấu hình mặc định của ACL. Cấu hình này có thể
được cài đặt ở file emqx.conf: "acl_nomatch = allow" thì mặc định thiết bị nào không
match với ACL rule đều được truy cập.
Chú ý là đối với client được xác định là "SuperUser", nó sẽ được skip toàn bộ quá trình
ACL.
THIẾT KẾ VÀ THỰC HIỆN
48
Hình 3.29 Chuỗi xác thực ACL của EMQ X Broker
Chuỗi xác thực ACL được minh họa như hình bên trên. Client khi truy cập vào hệ
thống sẽ được plugin ACL xác thực dựa theo file cấu hình acl.conf, các rule sẽ được xét theo
thứ tự từ dưới lên trên. Một khi client pass một rule, thì các rule phía sau sẽ được bỏ qua,
khi client fail một rule thì sẽ xét các rule kế tiếp cho đến hết chuỗi mà vẫn fail thì client sẽ
bị deny (nếu ACL mặc định là deny) hoặc allow (nếu ACL mặc định là allow).
3.6.2.2. Tiến hành triển khai ACL trên hệ thống
Khi xây dựng hệ thống pub/sub trên MQTT, các thiết bị đều sẽ có topic riêng biệt để
đảm bảo việc bảo mật và dễ dàng khi chuyển đổi. Ví dụ mô hình pub/sub vào các topic của
hệ thống IoT được xây dựng trong hệ thống của luận văn này như sau:
Hình 3.30 Lưu đồ mô tả hệ thống giao tiếp MQTT với EMQ X Broker
Ở minh họa này ta sẽ có 2 thiết bị: một smartphone để user nhận dữ liệu và control hệ
thống (user) và một ESP32 (device) được dùng để gửi dữ liệu thu thập được từ các node cảm
biến trong mạng mesh và đưa lên EMQ X Broker. Thông thường thì ESP32 gửi dữ liệu qua
topic nào thì user nếu muốn nhận được dữ liệu thì cứ subscribe vào topic đó, nhưng điều này
là không ổn trong hệ thống thực. Ở đây user và device đều sẽ subscribe và publish vào các
topic riêng biệt như trên hình, và chỉ duy nhất các topic đó. Ví dụ nếu có thêm thiết bị B
khác trong hệ thống thì ESP32 sẽ không được phép publish hay subscribe vào topic của thiết
bị B, tương tự đối với user. Luồng dữ liệu sẽ được control thông qua Rule Engine của EMQ
X, một plugin cho phép ta cấu hình các rule để republish dữ liệu vào các topic khác nhau.
THIẾT KẾ VÀ THỰC HIỆN
49
Ví dụ khi có dữ liệu đến topic device/deviceID/status thì Rule Engine sẽ republish dữ liệu
đó vào topic mà user subscribe đó là user/userID/control.
Hình 3.31 Cấu hình Rule Engine bằng lệnh SQL
Ở hình trên ta sẽ thực hiện việc cấu hình rule engine chọn hết payload nhận được từ
topic device/esp32root/status, sau đó broker sẽ thực hiện việc republish đến topic
user/flutter/status. Ngược lại khi nhận lệnh từ app Flutter, broker sẽ có rule engine chọn
payload từ topic user/flutter/control để republish đến topic device/esp32root/control.
Hình 3.32 Action Handler của Rule Engine
Mỗi rule được cấu hình sẽ có thể chọn action handler tùy theo yêu cầu người dùng
như republish, gửi đến HTTP server khác, gửi lên MySQL,… ở đây ta sẽ cấu hình type là
republish để thực hiện quá trình ACL như trên.
50
KẾT QUẢ THỰC HIỆN
CHƯƠNG 4:
KẾT QUẢ THỰC HIỆN
4.1. Mô hình thiết kế hệ thống
Đầu tiên hãy cùng nhìn lại sơ đồ khối của toàn bộ hệ thống:
Hình 4.1 Sơ đồ khối toàn bộ hệ thống
KẾT QUẢ THỰC HIỆN
51
Hệ thống sử dụng các giao thức phổ biến, dễ tích hợp vào trong các ứng dụng thực
tiễn. Để minh họa cho tính ứng dụng của luận văn, cũng như dễ dàng quan sát và đánh giá
đề tài, em sẽ sử dụng mô hình nhà thông minh rất phổ biến hiện nay.
Ngôi nhà bố trí gồm 2 phòng ngủ, một phòng khách và một bếp. Các node ESP32/8266
sẽ được gắn ở các phòng để điều khiển đèn theo ý người dùng thông qua app di động, có thể
ra lệnh bằng giọng nói. Có node thu thập data từ cảm biến nhiệt độ, độ ẩm và ánh sáng trong
nhà để gửi về App cho người dùng theo dõi. Nếu người dùng muốn thay đổi cấu hình hệ
thống thì có thể sử dụng web nhúng trên root node để dễ dàng cấu hình mà không cần phải
code lại. Trước cửa nhà có gắn ESP32-CAM để stream video gửi về App di động, đóng vai
trò như camera an ninh của ngôi nhà.
4.2. Sản phẩm mô hình thực tế
Mô hình nhà thông minh gồm có 4 phòng: một phòng khách, một bếp và hai phòng
ngủ, có một ngăn phòng nhỏ dùng để gắn relay điều khiển các đèn AC. Các node trong mạng
mesh được bố trí như hình bên dưới. Riêng ESP32CAM không thuộc mạng mesh mà giao
tiếp thẳng đến server qua giao thức WebSocket. Các dây dẫn đấu nối sẽ được đi ngầm xuống
đế để tăng tính thẩm mĩ. Các node hoạt động bằng nguồn 5V được cấp từ adapter thông qua
mạch chia áp nguồn song song.
Hình 4.2 Mặt trước của mô hình nhà thông minh
Phía trước nhà gồm có node gắn cảm biến dht đọc nhiệt độ, độ ẩm và ESP32CAM
đóng vai trò như camera an ninh stream trực tiếp video về server. Ở trước có bộ chia nguồn
5V tự thiết kế để chia ra 7 cặp chân V+ và GND để cấp nguồn cho các vi điều khiển sử dụng
trong mạng.
KẾT QUẢ THỰC HIỆN
52
Hình 4.3 Mặt bên của mô hình nhà thông minh
Mặt bên của mô hình có chừa một khoảng trống ở đế để đưa dây nguồn các bóng đèn
AC ra cũng như để dễ thao tác nối dây.
Hình 4.4 Mặt trên của mô hình nhà thông minh
Phía trong nhà gồm 5 ESP32/8266 trong mạng mesh. Một node root giao tiếp mesh
wifi và MQTT, các node còn lại phát tín hiệu điều khiển relay bật tắt đèn theo lệnh nhận
được từ root cũng như đọc cảm biến ánh sáng. Có thể bật tắt đèn bằng giọng nói thông qua
app di động, gửi lệnh xuống node root và node root forward đến các node leaf trong mesh.
KẾT QUẢ THỰC HIỆN
53
Hệ thống được cấu hình để khi nhận lệnh điều khiển từ người dùng sẽ bật, tắt đèn ở
các phòng tương ứng. Đặc biệt nếu node root nhận lệnh "all lamp on" hoặc "all lamp off" thì
toàn bộ đèn sẽ bật, tắt cùng lúc.
4.3. Camera streaming
Phần này ta sẽ đánh giá chất lượng của hệ thống stream camera được sử dụng trong hệ
thống. Với camera của ESP32CAM, là một loại camera giá rẻ nên không thể cho chất lượng
quá tốt được. Thực nghiệm cho thấy ở chế độ độ phân giải thấp nhất thì tỉ lệ khung hình trên
giấy fps cũng chỉ đạt tối đa khoảng 17fps.
Hình 4.5 Giao diện config camera trên web local
Firmware của ESP32CAM có tích hợp giao diện web local để config các thông số của
camera như tỉ lệ khung hình, chất lượng hình ảnh, xoay màn hình,… Sau nhiều lần test nhận
thấy chọn Resulution VGA và Quality ở mức thấp nhất sẽ cho chất lượng stream với fps khá
ổn để sử dụng làm camera an ninh.
Khi stream video lên server và chuyển tiếp đến app Flutter thì fps hơi tụt một chút.
Hình ảnh thu được có chất lượng không khác so với local web nhưng hơi lag hơn. Lí do vì
các gói tin chuyển tiếp qua internet đến server host ở singapore nên sẽ có độ trễ. Thực nghiệm
cho thấy nếu stream ở chế độ hình ảnh HD 1920x1080 thì video ở local vẫn xem được dù
fps tụt xuống tầm 10fps nhưng video stream qua websocket lên app thì rất lag và hầu như
không xem được realtime.
KẾT QUẢ THỰC HIỆN
54
Hình 4.6 FPS khi stream camera dao động từ 12 – 17FPS
Hình 4.7 Video được stream về app Flutter
Nhìn chung mặc dù ESP32CAM có thể stream với nhiều chế độ hình ảnh từ QQVGA
cho đến UXGA nhưng để có được tốc độ stream tốt nhất có thể thì chỉ nên stream từ chất
lượng VGA trở xuống.
4.4. Kiểm tra đánh giá hệ thống
4.4.1. Multihop test
Bài thử nghiệm multihop (Multihop Test) nhằm đánh giá hiệu suất truyền tin của mạng
mesh trên thay đổi như thế nào theo số chặng. Các thông số được thu thập trong bài thử
55
KẾT QUẢ THỰC HIỆN
nghiệm bao gồm RTT min, RTT max, RTT trung bình, RSSI trung bình và đặc biệt quan
trọng là PDR theo số chặng. Ta sẽ gửi liên tục 300 gói tin 32 byte trong vòng 5 phút từ node
root đến node leaf với số lượng hop từ 1 đến 3 để thu thập dữ liệu và đánh giá.
4.4.1.1. Kịch bản
Thiết bị: NodeMCU ESP8266
Firmware: thư viện painless mesh dùng cho ESP32/8266 và function tự viết để tính
toán các thông số cần thiết.
Tổng số node: 4 node ESP32/8266
Địa điểm: sân bóng đá Trường Đại học Bách Khoa. Các node cách nhau 10m.
Hình 4.8 Minh họa multihiop test
Số lượng hop trong các lần test sẽ thay đổi từ 1 đến 3 và đánh giá kết quả thu được
trong từng trường hợp.
56
KẾT QUẢ THỰC HIỆN
4.4.1.2. Kết quả
Số hop
PDR (%)
1
2
3
95.52
94.52
92.67
Av. RSSI
RTT max
(dBm)
(ms)
-78
990
-83
921
-76
977
Bảng 4.1 Kết quả multihop test
RTT min
(ms)
14
32
26
Av. RTT
(ms)
62.67
93.78
118.74
Nhìn vào bảng số liệu thu được ta có thể thấy số lượng hop có ảnh hưởng đến các
thông số được đo. Cụ thể ta quan sát các đồ thị bên dưới để có cái nhìn trực quan hơn.
PDR (%)
PDR theo số chặng
96
95.5
95
94.5
94
93.5
93
92.5
92
91.5
91
1
2
3
Số chặng
Hình 4.9 PDR theo số chặng
PDR của chặng một là 95.52, số lượng gói tin bị mất khoảng 14 gói. Đến chặng hai thì
mất khoảng 17 gói. Chặng ba thì mất khoảng 22 gói. Tỉ lệ PDR giảm dần theo số chặng như
dự kiến do càng nhiều chặng thì các node sẽ càng dễ mất gói trong quá trình chuyển tiếp gói
tin. Bài test thực hiện với số chặng tối đa là 3, đa phần các hệ thống smart home chỉ dùng
khoảng bấy nhiêu chặng thôi và với tỉ lệ PDR 92.67% là một tỉ lệ chấp nhận được, phù hợp
với các ứng dụng giám sát điều khiển từ xa.
57
KẾT QUẢ THỰC HIỆN
RTT theo số chặng
1200
Thời gian (ms)
1000
800
600
400
200
0
1
2
3
Số chặng
RTT max (ms)
RTT min (ms)
Av. RTT (ms)
Hình 4.10 RTT theo số chặng
Ta có thể thấy rằng giao tiếp với càng nhiều chặng thì RTT trung bình sẽ càng tăng
lên, đồng nghĩa với chất lượng truyền thông giảm đi sau mỗi chặng. RTT max luôn đạt giá
trị vọt lố là do các node sử dụng firmware painlessMesh, được mặc định là cần scan thiết bị
kết nối vào mạng mỗi 5 giây nên trong lúc đó thời gian xử lý gói tin sẽ lâu hơn dẫn đến việc
tăng RTT. Nhìn chung RTT trung bình đạt ở mức tầm 0.1s với kết nối ba chặng cũng là khá
ổn cho các ứng dụng soft realtime như giám sát, đọc dữ liệu từ cảm biến, điều khiển thiết bị
từ xa, có thể sử dụng tốt trong các ứng dụng nông nghiệp hay smart home, smart building,…
4.4.2. Range test
Bài thử nghiệm khoảng cách (Range Test) nhằm đánh giá hiệu suất truyền tin của mạng
mesh trên một chặng thay đổi như thế nào theo khoảng cách. Các thông số được thu thập
trong bài thử nghiệm bao gồm RTT min, RTT max, RTT trung bình, RSSI trung bình và đặc
biệt quan trọng là PDR theo khoảng cách. Ta sẽ gửi liên tục 300 gói tin 32 byte trong vòng
5 phút từ node root đến node leaf để thu thập dữ liệu và đánh giá.
4.4.2.1. Kịch bản
Thiết bị: NodeMCU ESP8266
Firmware: thư viện painless mesh dùng cho ESP32/8266 và function tự viết để tính
toán các thông số cần thiết.
Tổng số node: 2 node ESP32/8266
Địa điểm: sân bóng đá Trường Đại học Bách Khoa.
58
KẾT QUẢ THỰC HIỆN
Hình 4.11 Minh họa range test
4.4.2.2. Kết quả
Khoảng
cách (m)
5
10
15
20
25
30
PDR (%)
98.33
98.33
95.00
96.00
94.33
91.67
Av. RSSI
RTT max
(dBm)
(ms)
-77
963
-78
786
-80
933
-80
861
-78
961
-83
1053
Bảng 4.2 Kết quả range test
RTT min
(ms)
12
12
11
12
11
12
Av. RTT
(ms)
27.34
46.15
28.30
59.46
71.51
38.42
Kết quả thực nghiệm cho thấy kết nối chỉ ổn định trong khoảng 30m, nếu xa hơn thì
node sẽ liên tục bị disconnect và reconnect dẫn đến tỉ lệ gửi gói tin thành công rất thấp. Đến
khoảng 35 – 40m thì không thể kết nối được nữa. Nhìn vào bảng số liệu ta thấy PDR của
mạng ở khoảng cách tầm 20m trở lại khá ổn định, không bị mất gói nhiều. Bài test được thực
hiện trong lúc có người qua lại sân bóng nên RTT cho ra kết quả không thực sự như dự kiến
(tăng dần theo khoảng cách). Với các ứng dụng trong các hệ thống Smart Home, khoảng
cách giữa các node thường chỉ tầm 20m trở lại thì mạng mesh wifi có thể được sử dụng với
mức ổn định khá tốt.
59
KẾT QUẢ THỰC HIỆN
PDR theo khoảng cách
100
PDR (%)
98
96
94
92
90
88
5
10
15
20
Khoảng cách (m)
25
30
Hình 4.12 PDR theo khoảng cách
RTT theo khoảng cách
1200
Thời gian (ms)
1000
800
600
RTT max (ms)
400
RTT min (ms)
Av. RTT (ms)
200
0
5
10
15
20
25
30
Khoảng cách (m)
Hình 4.13 RTT theo khoảng cách
Nhìn vào đồ thị ta thấy xu hướng tỉ lệ PDR giảm dần theo khoảng cách. Điều này cũng
là dễ hiểu do khoảng cách càng xa thì sóng wifi phát từ access point càng yếu. Kết nối ổn
định nhất trong khoảng 20m trở lại. Khi tiến dần ra xa đến khoảng 30m thì sóng rất yếu và
hay bị mất kết nối, ra xa hơn nữa thì hoàn toàn không kết nối được. Đối với thông số RTT,
ta nhận thấy rằng RTT có xu hướng tăng theo khoảng cách tuy nhiên vẫn giữ ở mức ổn định
trung bình tầm vài chục ms. Tương tự như bài multihop test, trong quá trình gửi sẽ có lúc
mesh bị ngưng đột ngột để tiến hành scan thiết bị mỗi 5s một lần, dẫn đến gói tin lúc đó bị
xử lí chậm, đây là lí do mà RTT max luôn cao bất thường so với RTT min và trung bình.
KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN
CHƯƠNG 5:
60
KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN
5.1. Nhận xét chung
Nhìn chung luận văn đã giải quyết được phần lớn các vấn đề đặt ra ở đầu đề tài.
Xây dựng được mạng mesh wifi với số lượng node tham gia mạng đủ để ứng dụng vào
các hệ thống smart home, firmware có các chức năng tự động kết nối lại vào mạng khi bị
mất kết nối và hoạt động tương đối ổn định. Đối với phần giao tiếp MQTT của node root với
server, node root mặc dù phải tải một lượng công việc khá nhiều bao gồm mesh wifi, MQTT
client, embedded webserver nhưng vẫn hoạt động bình thường mà không gặp tình trạng
exception cũng như có config thông minh tự động kết nối lại khi bị ngắt kết nối đột ngột.
Đối với phần App di động Flutter cũng hoạt động tốt với đầy đủ các tính năng như gửi
nhận gói tin qua MQTT, stream video realtime qua WebSocket và cả điều khiển bằng giọng
nói, đạt được hiệu năng cao do có sử dụng quản lý state trong quá trình lập trình, mặc dù bên
cạnh đó còn nhiều hạn chế về trải nghiệm người dùng.
5.2. Ưu điểm
Luận văn đã đạt được những ưu điểm đáng kể trong quá trình xây dựng hệ thống IoT
với ba giao thức chính là MQTT, HTTP và WebSocket. Mỗi giao thức có một thế mạnh
riêng và luận văn đã sử dụng chúng vào từng ứng dụng phù hợp cụ thể. MQTT dùng để giao
tiếp gửi nhận gói tin, HTTP để giao tiếp Web Server và WebSocket phù hợp với các ứng
dụng realtime nên được dùng cho video stream.
Một ưu điểm khác nữa của luận văn là phần cấu hình cloud server. Luận văn không sử
dụng dịch vụ cloud có sẵn mà tự cấu hình máy ảo và MQTT broker cũng như WebSocket
server trên đấy với đầy đủ các cấu hình về Elastic IP, domain name, proxy server, CA
certificate, firewall… mặc dù điều này khiến người thực hiện cần làm nhiều tác vụ hơn so
với dịch vụ cloud có sẵn nhưng đổi lại nó cho phép nhà phát triển nhiều quyền kiểm soát hệ
thống của mình hơn cũng như có thể tùy chỉnh theo ý muốn mà không bị ràng buộc như các
gói cloud có sẵn. Với broker mã nguồn mở của EMQX, ta có thể tùy chỉnh theo ý muốn của
mình cho phù hợp với mục đích sử dụng như thay đổi giao diện, icon, thay đổi public/private
key, ACL,…
KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN
61
Luận văn cũng sử dụng cơ chế giao tiếp MQTTS sử dụng public/private key để tạo
certificate nhằm tăng độ bảo mật cả phía server lẫn phía thiết bị, cũng với đó là cấu hình
ACL để tăng sự linh hoạt trong quá trình thiết lập thông số hệ thống và dễ dàng chỉnh sửa
khi thay đổi, đây cũng là cách mà các hệ thống IoT trong thực tế hoạt động.
5.3. Nhược điểm
Luận văn vẫn còn tồn đọng một số khuyết điểm như:
-
Mạng mesh đôi khi bị ngắt kết nối, phải đợi reconnect làm trễ hệ thống trong khoảng
5s.
-
Giao tiếp MQTTS chỉ mới được triển khai ở phần thiết bị giao tiếp với server, còn
giữa app di động và server thì vẫn đang sử dụng MQTT thông thường.
-
WebServer giúp cấu hình WiFi, MQTT, hiển thị các gói tin pub/sub vẫn chưa hoàn
thiện và chưa có tính ứng dụng cao (do phần hiển thị cũng đã có app di động làm
rồi). Về mặt sản phẩm thực tế thì WebServer nhúng là cần thiết để khách hàng có thể
dễ dàng sử dụng nhưng ở mức độ luận văn thì tính ứng dụng của phần WebServer
này chưa nhiều mặc dù mất khá nhiều công sức để thực hiện do lập trình Web trên
thiết bị nhúng khá khó.
-
Phần app di động Flutter vẫn còn nhiều lỗi mang lại trải nghiệm người dùng không
tốt như: tự ngắt kết nối MQTT khi điện thoại có cuộc gọi hoặc khi chạy nền, video
stream không có chức năng tùy chỉnh kích thước video, cách gửi gói tin bằng text
còn cồng kềnh và lâu, gửi lệnh bằng giọng nói thì cần thời gian để xử lý khoảng 2s
mới gửi được lệnh.
-
Phần cứng thiết kế còn cồng kềnh thiếu tính thẩm mĩ.
5.4. Hướng phát triển
Với những nhận xét đã nêu, sau đây là những hướng có thể triển khai để cải thiện
chất lượng của hệ thống được xây dựng trong luận văn:
-
Cải thiện lại giao tiếp MQTTS: cấu hình giao tiếp MQTTS cho cả app di động và các
thiết bị khác nếu có mở rộng hệ thống.
-
Ngoài MQTT và mesh ta có thể sử dụng linh hoạt thêm các giao thức khác cho hệ
thống tùy thuộc vào mục đích sử dụng. Ví dụ như ModBus RTU hoặc Modbus TCP
KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN
62
dùng để giao tiếp với các thiết bị end node điều khiển nhiệt độ, điều khiển động cơ,
máy bơm, điều khiển dimmer đèn,…
-
Nâng cấp Embedded WebServer: Hiện tại chức năng của WebServer nhúng còn chưa
rõ ràng. Ta có thể nâng cấp nó trở nên hữu ích và thực tế hơn như chức năng hiển thị
các thông số khi node chạy đa giao thức (MQTT message, ModBus Register,…), kết
nối ethernet, scan kết nối wifi ở bất cứ đâu, thay đổi cấu hình IP, thay đổi cấu hình
phân quyền người dùng.
-
Nâng cấp UI/UX của app di động để mang lại trải nghiệm tốt hơn khi sử dụng.
-
Sử dụng thêm nhiều các tính năng khác trên cloud server như cơ sở dữ liệu, phân tích
dữ liệu, cân bằng tải,… cho các ứng dụng IoT quy mô lớn hơn.
63
TÀI LIỆU THAM KHẢO
TÀI LIỆU THAM KHẢO
[1]. James F. Kurose, Keith W. Ross (2013). Computer Networking, a top-down approach.
Pearson Education, In, Addison-Wesley.
[2]. Emil Gatial, Zoltan Balogh, Ladislav Hluchy (2020). Concept of Energy Efficient
ESP32 Chip for Industrial Wireless Sensor Network. IEEE 24th International Conference on
Intelligent Engineering Systems (INES).
[3]. Adrien van den Bossche , Nicolas Gonzalez , Thierry Val , Damien Brulin, Frédéric
Vella, Nadine Vigouroux, and Eric Camp (2018). Specifying an MQTT Tree for a Connected
Smart Home. International Conference On Smart homes and health Telematics.
[4]. Dan Dinculeană và Xiaochun Cheng (2019). Vulnerabilities and Limitations of MQTT
Protocol Used between IoT Devices. Faculty of Science and Technology, Middlesex
University, London.
[5]. Henry Boisdequin. React vs Vue vs Angular vs Svelte. Từ https://dev.to/hb/react-vsvue-vs-angular-vs-svelte-1fdm, truy cập ngày 20/11/2021
[6]. Yoppy, R Harry Arjadi, Endah Setyaningsih, Priyo Wibowo, M I Sudrajat (2019).
Performance Evaluation of ESP8266 Mesh Networks. IOP Conf. Series 1230: Journal of
Physics.
[7]. Trần Nho Đức (2020). Thiết kế và triển khai Dynamic Multiprotocol trên đa nền tảng
phần cứng IoT. Luận văn tốt nghiệp Trường Đại học Bách Khoa TPHCM.
[8]. Mr.Jyoti Morai, Prof.Sunil Vasant Kuntawar (2021). Performing open source wifi
mesh sensor network using esp32. Journal of Emerging Technologies and Innovative
Research, Volume 8, issue 3.
[9]. Manuel Suarez-Albela, Tiago M. Fern ´ andez-Caram ´ es, Paula Fraga-Lamas, Luis
Castedo (2018). Impact of Clock Frequency on the Performance and Consumption of a
Secure IoT Node. Dpt. Computer Engineering, Faculty of Computer Science, Universidade
da Coruna, 15071, A Coruna, Spain.
[10]. Introducing the MQTT Protocol - MQTT Essentials. Từ hivemq.com/blog/mqttessentials-part-1-introducing-mqtt/, truy cập ngày 20/11/2021.
[11]. Anton Jansen, Ivano Malavolta, Henry Muccini, Ipek Ozkaya, Olaf Zimmermann
(2020). Software Architecture. Springer Nature Switzerland AG.
64
TÀI LIỆU THAM KHẢO
[12]. Jakubek,
R.R..
Nonequivalent
Quasi-Experimental
Study
of
Wireless
Telecommunication Traffic During Severe Winter Storms. IEEE Access, 2015. 3: p. 10361041.
[13]. Md. Humayun Kabir (2021). Securing IoT Networks by Applying Policy Based Access
Control List (ACL) Configuration. International Islamic University Chittagong.
[14]. Bossche, A. V. D., Gonzalez, N., Val, T., Brulin, D., Vella, F., Vigouroux, N., &
Campo, E. (2018). Specifying an MQTT tree for a connected smart home. In International
Conference on Smart Homes and Health Telematics (pp. 236-246). Springer, Cham.
[15]. WANG, Tao, Yaokai FENG, và Kouichi SAKURAI. Construction of An Environment
of Edging System for IoT devices.
[16]. Koziolek, H., Grüner, S., & Rückert, J. (2020). A comparison of mqtt brokers for
distributed iot edge computing. European Conference on Software Architecture (pp. 352368). Springer, Cham.
[17]. Bender, M., Kirdan, E., Pahl, M. O., & Carle, G. (2021). Open-Source MQTT
Evaluation. 2021 IEEE 18th Annual Consumer Communications & Networking Conference
(CCNC) (pp. 1-4). IEEE.
[18]. Levlin, M. (2020). DOM benchmark comparison of the front-end JavaScript
frameworks React, Angular, Vue, and Svelte.
[19]. Arjadi, R. H., Setyaningsih, E., Wibowo, P., & Sudrajat, M. I. (2019). Performance
Evaluation of ESP8266 Mesh Networks. Journal of Physics: Conference Series (Vol. 1230,
No. 1, p. 012023). IOP Publishing.