CHƯƠNG 2 : CÁC GIAO THỨC TỪ THIẾT BỊ CẠNH BIÊN ĐẾN CLOUD
2.2 CÁC GIAO THỨC ỨNG DỤNG CHO IOT:
2.2.3 Giao thức CoAP:
Constrained Application Protocol (CoAP) là sản phẩm của IETF (RFC7228), là giao thức được sử dụng trong giao tiếp giữa các thiết bị có tài nguyên hạn chế. Nó cũng hỗ trợ ánh xạ sang HTTP thông qua việc sử dụng các proxy, điều này giúp thiết bị có khả năng lấy dữ liệu từ internet.
CoAp cung cấp chức năng tương tự như HTTP nhưng với mào đầu gói tin và điện năng được giảm thiểu đáng kể, Bảng 2.4 thể hiện kết quả so sánh giữa CoAP và HTTP được thử nghiệm trên cùng phần cứng và các hoạt động thông tin:
2.2.3.1Kiến trúc CoAP:
Các tính năng CoAP được tóm gọn như sau: - Giống HTTP.
- Là giao thức không kết nối. - Bảo mật dùng DTLS.
- Mào đầu gói tin được tối giản để tiết kiệm tài nguyên. - Hỗ trợ URI và content-types.
- Giao thức sử dụng là UDP.
- Cơ chế ánh xạ HTTP cho phép chuyển tiếp đến các phiên HTTP. CoAP có hai lớp cơ bản:
- Lớp Request/Response: Chịu trách nhiệm gửi và nhận các truy vấn RESTful.
- LớpTransaction: Kiểm soát thông điệp đơn lẻ được trao đổi giữa các đầu cuối sử dụng 4 loại thông điệp cơ bản.
Cũng như HTTP, CoAP sử dụng URI và các request như GET, PUT, POST và DELETE. Tương tự, mã reponse cũng được bắt chước:
- 2.01: Đã tạo - 2.02: Đã xóa - 2.04: Đã thay đổi - 2.05: Nội dung
- 4.04: Không tìm thấy trang - 4.05: Không hỗ trợ method
Định dạng của một URI trong CoAP: coap://host[:port]/[path][?query]
Các thành phần trong một hệ thống CoAP:
- Endpoints: Điểm cuối, có thể là nơi gửi hoặc nơi nhận một thông điệp CoAP.
- Proxies: Một điểm cuối được client ủy quyền thực hiện các request cho client. Điều này giảm tải đồng thời cung cấp một lớp bảo mật cho client. Một proxy cũng có thể ánh xạ một CoAP request sang một CoAP request khác hoặc sang một giao thức khác (như HTTP).
- Intermediary: Một client hoạt động với vai trò như một server và client đối với một origin server.
- Origin server: Các server có chứa một số tài nguyên nhất định.
- Observer: Một client giám sát có thể đăng ký chính nó bằng một thông điệp GET. Nó sau đó được kết nối vào một nguồn tài nguyên và nếu tài nguyên có sự thay đổi nào đó thì server sẽ gửi một thông báo về cho observer.
Hình 2.6 minh họa một hệ thống HTTP cho phép các client CoAP liên lạc với nhau hoặc với các dịch vụ trên cloud.
Hình 2.6: Mô hình giao tiếp của CoAP
2.2.3.2Các định dạng thông điệp CoAP:
Các giao thức dựa trên UDP thường không có cơ chế kiểm tra độ tin cậy. Để bù lại khiếm khuyết này, CoAP có hai loại thông điệp có và không có sự xác nhận. Đồng thời có thêm tính năng là truyền thông bất đồng bộ. Có tổng cộng 4 loại thông điệp trong CoAP:
- Confirmable (CON): Một thông điệp có yêu cầu ACK (xác nhận). Nếu một thông điệp CON được gửi đi thì yêu cầu một ACK phải nhận được trong khoảng
thời gian từ ACK_TIMEOUT đến (ACKTIMEOUT x
ACK_RANDOM_FACTOR). Nếu không nhận được ACK trong khoảng thời gian trên, thiết bị gửi sẽ gửi lặp lại các thông điệp CON đó theo các khoảng thời gian tăng lên theo cấp số nhân cho đến khi nhận được gói ACK hoặc RST. Số lần thử gửi lại tối đa cho gói CON được đặt bởi biến MAX_RETRANSMIT. Đây là cơ chế phục hồi bù lại cho việc khiếm khuyết cơ chế phục hồi của giao thức lớp 4, UDP (Hình 2.7).
Hình 2.7: Quá trình gửi lại gói CON trong CoAP
- Non-confirmable (NON): Một thông điệp không yêu cầu ACK.
- Acknowledgment (ACK): Thông điệp xác nhận cho gói tin CON. Một gói tin ACK có thể mang theo dữ liệu khác.
- Reset (RST): Cho biết rằng một thông điệp CON vừa nhận được nhưng không đúng hoàn cảnh. Gói tin RST cũng có thể mang theo dữ liệu khác.
Hình 2.8 minh họa các trường hợp gửi và có thể nhận phản hồi của các gói CON và NON
Hình 2.8: RESTful request/reponse nằm trong nội dung của thông điệp CoAP
Trong khi các kiến trúc thông điệp khác yêu cầu server trung tâm để phân phối các thông điệp giữa các client, CoAP cho phép các thông điệp được gửi giữa bất kỳ CoAP client nào bao gồm cả các cảm biến và server. CoAP bao gồm một mô hình bộ nhớ đệm đơn giản. Bộ nhớ đệm được điều khiển bởi các mã phản hồi trong mào đầu của thông điệp. Tùy chọn Max_Age được sử dụng để điều khiển các tuổi thọ của các bộ nhớ đệm và đảm bảo độ mới của dữ liệu. Max_Age mặc định là 60 giây và giá trị tối đa có thể thiết lập lên đến 136.1 năm. Các proxy đóng vai trò là một bộ nhớ đệm; ví dụ, khi một cảm biến ở trạng thái nghỉ, nó có thể sử dụng một proxy để lưu tạm dữ liệu.
Tiêu đề thông điệp CoAP được thiết kế tinh giảm có độ dài 4 byte, với một thông điệp request thông thường thì tổng chiều dài header chiếm khoảng 10-20 byte. Cấu trúc bao
liên kết với trường Message-ID duy nhất. Trường Code được sử dụng để thông tin các lỗi hay các trạng thái thành công. Sau header, các trường còn lại là tùy chọn và có độ dài thay đổi là các Token, Option, và Payload (Hình 2.9).
Hình 2.9: Cấu trúc gói tin CoAP
UDP có thể gây nên các gói tin trùng lặp cho cả hai loại thông điệp CON và NON. Nhờ vào trường Message ID trong tiêu đề, nếu có một thông điệp với cùng Message ID được gửi lại trong khoảng thời gian định trước EXCHANGE_LIFETIME, bên nhận sẽ biết được thông điệp bị trùng.
Tôi xét vai trò của Observer trong một hệ thống, điều này cho phép CoAP hành xử tương tự như MQTT. Quy trình giám sát cho phép một client đăng ký làm giám sát viên và server sẽ thông tin cho client mỗi khi tài nguyên giám sát có sự thay đổi trạng thái. Thời hạn giám sát có thể được định nghĩa trong quá trình đăng ký. Ngoài ra, quá trình giám sát có thể kết thúc khi client gửi thông điệp RST hay một thông điệp GET khác (Hình
2.10).
Hình 2.10: Ví dụ CoAP Observer
Khi CoAP dựa vào DTLS để tăng cấp độ bảo mật dữ liệu truyền thông thì URI sẽ thay đổi tương tự như HTTP thông qua TLS là thêm "s" đằng sau giao thức, URI:
coap://host[:port]/[path][?query] //Có mã hóa
coaps://host[:port]/[path][?query]
CoAP cũng cung cấp cơ chế khám phá tài nguyên. Chỉ cần gửi một GET request đến /.Well-known/core sẽ tiết lộ danh sách các tài nguyên đã biết trên thiết bị. Ngoài ra, các chuỗi truy vấn có thể được sử dụng trong request để áp dụng các bộ lọc xác định.