Sự phát triển của công nghệ trong lĩnh vực phần mềm và phần cứng, sự xuất hiện của các giao thức truyền thông mới đã dẫn đến sự mở rộng của Internet of Things (IoT). Số lượng thiết bị đang tăng lên từng ngày và chúng đang tạo ra một lượng dữ liệu khổng lồ. Vì vậy, cần có một kiến trúc hệ thống thuận tiện có khả năng xử lý, lưu trữ và truyền dữ liệu này.
Bây giờ các dịch vụ đám mây được sử dụng cho những mục đích này. Tuy nhiên, mô hình điện toán sương mù (Sương mù) ngày càng phổ biến có thể bổ sung cho các giải pháp đám mây bằng cách mở rộng quy mô và tối ưu hóa cơ sở hạ tầng IoT.
Đám mây có khả năng đáp ứng hầu hết các yêu cầu IoT. Ví dụ: để cung cấp khả năng giám sát các dịch vụ, xử lý nhanh mọi lượng dữ liệu do thiết bị tạo ra cũng như trực quan hóa chúng. Điện toán sương mù hiệu quả hơn khi giải quyết các vấn đề thời gian thực. Chúng cung cấp phản hồi nhanh cho các yêu cầu và độ trễ tối thiểu trong quá trình xử lý dữ liệu. Nghĩa là, Fog bổ sung cho “đám mây” và mở rộng khả năng của nó.
Tuy nhiên, câu hỏi chính lại khác: tất cả những điều này nên tương tác như thế nào trong bối cảnh IoT? Giao thức truyền thông nào sẽ hiệu quả nhất khi làm việc trong hệ thống IoT-Fog-Cloud kết hợp?
Bất chấp sự thống trị rõ ràng của HTTP, có một số lượng lớn các giải pháp khác được sử dụng trong các hệ thống IoT, Sương mù và Đám mây. Điều này là do IoT phải kết hợp chức năng của nhiều loại cảm biến thiết bị với tính bảo mật, khả năng tương thích và các yêu cầu khác của người dùng.
Nhưng đơn giản là không có một ý tưởng duy nhất nào về kiến trúc tham chiếu và tiêu chuẩn truyền thông. Do đó, việc tạo một giao thức mới hoặc sửa đổi giao thức hiện có cho các nhiệm vụ IoT cụ thể là một trong những nhiệm vụ quan trọng nhất mà cộng đồng CNTT phải đối mặt.
Những giao thức nào hiện đang được sử dụng và chúng có thể cung cấp những gì? Hãy tìm ra nó. Nhưng trước tiên, hãy thảo luận về các nguyên tắc của hệ sinh thái trong đó các đám mây, sương mù và Internet vạn vật tương tác với nhau.
Kiến trúc sương mù trên đám mây (F2C) của IoT
Bạn có thể đã nhận thấy bao nhiêu nỗ lực đang được đầu tư vào việc khám phá những lợi ích và lợi ích liên quan đến việc quản lý thông minh và phối hợp IoT, đám mây và sương mù. Nếu không, thì đây là ba sáng kiến tiêu chuẩn hóa: , и .
Nếu trước đây chỉ xem xét 2 cấp độ là đám mây và thiết bị đầu cuối thì kiến trúc được đề xuất sẽ giới thiệu một cấp độ mới - điện toán sương mù. Trong trường hợp này, mức độ sương mù có thể được chia thành nhiều cấp độ phụ, tùy thuộc vào đặc điểm cụ thể của tài nguyên hoặc một bộ chính sách xác định việc sử dụng các thiết bị khác nhau trong các cấp độ phụ này.
Sự trừu tượng này có thể trông như thế nào? Đây là một hệ sinh thái IoT-Fog-Cloud điển hình. Thiết bị IoT gửi dữ liệu đến các máy chủ và thiết bị điện toán nhanh hơn để giải quyết các vấn đề đòi hỏi độ trễ thấp. Trong cùng một hệ thống, các đám mây chịu trách nhiệm giải quyết các vấn đề đòi hỏi lượng lớn tài nguyên máy tính hoặc không gian lưu trữ dữ liệu.
Điện thoại thông minh, đồng hồ thông minh và các thiết bị khác cũng có thể là một phần của IoT. Nhưng những thiết bị như vậy, theo quy luật, sử dụng các giao thức liên lạc độc quyền của các nhà phát triển lớn. Dữ liệu IoT được tạo sẽ được chuyển đến lớp sương mù thông qua giao thức REST HTTP, mang lại sự linh hoạt và khả năng tương tác khi tạo các dịch vụ RESTful. Điều này rất quan trọng vì cần phải đảm bảo khả năng tương thích ngược với cơ sở hạ tầng điện toán hiện có chạy trên các máy tính cục bộ, máy chủ hoặc cụm máy chủ. Tài nguyên cục bộ, được gọi là “nút sương mù”, lọc dữ liệu nhận được và xử lý cục bộ hoặc gửi dữ liệu đó lên đám mây để tính toán thêm.
Các đám mây hỗ trợ các giao thức truyền thông khác nhau, phổ biến nhất là AMQP và REST HTTP. Vì HTTP nổi tiếng và được điều chỉnh cho phù hợp với Internet nên câu hỏi có thể đặt ra: “Chúng ta có nên sử dụng nó để làm việc với IoT và sương mù không?” Tuy nhiên, giao thức này có vấn đề về hiệu suất. Thêm về điều này sau.
Nhìn chung có 2 mô hình giao thức truyền thông phù hợp với hệ thống chúng ta cần. Đây là yêu cầu-phản hồi và xuất bản-đăng ký. Mô hình đầu tiên được biết đến rộng rãi hơn, đặc biệt là trong kiến trúc server-client. Máy khách yêu cầu thông tin từ máy chủ và máy chủ nhận được yêu cầu, xử lý yêu cầu đó và trả về thông báo phản hồi. Các giao thức REST HTTP và CoAP hoạt động trên mô hình này.
Mô hình thứ hai xuất phát từ nhu cầu cung cấp khả năng ghép nối không đồng bộ, phân tán, lỏng lẻo giữa các nguồn tạo dữ liệu và người nhận dữ liệu này.
Mô hình giả định có ba người tham gia: nhà xuất bản (nguồn dữ liệu), nhà môi giới (người điều phối) và người đăng ký (người nhận). Ở đây, máy khách đóng vai trò là người đăng ký không phải yêu cầu thông tin từ máy chủ. Thay vì gửi yêu cầu, nó đăng ký các sự kiện nhất định trong hệ thống thông qua một nhà môi giới, chịu trách nhiệm lọc tất cả các tin nhắn đến và định tuyến chúng giữa nhà xuất bản và người đăng ký. Và nhà xuất bản, khi một sự kiện xảy ra liên quan đến một chủ đề nhất định, sẽ xuất bản nó cho nhà môi giới, nhà môi giới này sẽ gửi dữ liệu về chủ đề được yêu cầu đến người đăng ký.
Về cơ bản, kiến trúc này dựa trên sự kiện. Và mô hình tương tác này rất thú vị đối với các ứng dụng trong IoT, đám mây, sương mù vì khả năng cung cấp khả năng mở rộng và đơn giản hóa kết nối giữa các thiết bị khác nhau, hỗ trợ giao tiếp nhiều-nhiều động và giao tiếp không đồng bộ. Một số giao thức nhắn tin tiêu chuẩn hóa nổi tiếng nhất sử dụng mô hình đăng ký xuất bản bao gồm MQTT, AMQP và DDS.
Rõ ràng, mô hình đăng ký xuất bản có rất nhiều ưu điểm:
- Nhà xuất bản và người đăng ký không cần biết về sự tồn tại của nhau;
- Một thuê bao có thể nhận thông tin từ nhiều ấn phẩm khác nhau và một nhà xuất bản có thể gửi dữ liệu đến nhiều thuê bao khác nhau (nguyên tắc nhiều-nhiều);
- Nhà xuất bản và người đăng ký không cần phải hoạt động cùng lúc để liên lạc, vì nhà môi giới (hoạt động như một hệ thống xếp hàng) sẽ có thể lưu trữ tin nhắn cho các máy khách hiện không kết nối với mạng.
Tuy nhiên, mô hình yêu cầu-đáp ứng cũng có những điểm mạnh của nó. Trong trường hợp khả năng xử lý nhiều yêu cầu của máy khách của phía máy chủ không phải là vấn đề thì việc sử dụng các giải pháp đáng tin cậy đã được chứng minh là điều hợp lý.
Ngoài ra còn có các giao thức hỗ trợ cả hai mô hình. Ví dụ: XMPP và HTTP 2.0, hỗ trợ tùy chọn “đẩy máy chủ”. IETF cũng đã phát hành CoAP. Trong nỗ lực giải quyết vấn đề nhắn tin, một số giải pháp khác đã được tạo ra, chẳng hạn như giao thức WebSockets hoặc sử dụng giao thức HTTP qua QUIC (Kết nối Internet UDP nhanh).
Trong trường hợp WebSockets, mặc dù nó được sử dụng để truyền dữ liệu theo thời gian thực từ máy chủ sang máy khách web và cung cấp các kết nối liên tục với giao tiếp hai chiều đồng thời, nhưng nó không dành cho các thiết bị có tài nguyên máy tính hạn chế. QUIC cũng đáng được quan tâm vì giao thức truyền tải mới mang lại rất nhiều cơ hội mới. Nhưng vì QUIC chưa được tiêu chuẩn hóa nên còn quá sớm để dự đoán ứng dụng và tác động có thể có của nó đối với các giải pháp IoT. Vì vậy, chúng tôi luôn lưu ý đến WebSockets và QUIC để hướng tới tương lai, nhưng hiện tại chúng tôi sẽ không nghiên cứu chi tiết hơn về vấn đề này.
Ai là người dễ thương nhất thế giới: so sánh các giao thức
Bây giờ hãy nói về điểm mạnh và điểm yếu của các giao thức. Nhìn về phía trước, chúng ta hãy khẳng định ngay rằng không có ai là người lãnh đạo rõ ràng. Mỗi giao thức đều có một số ưu điểm/nhược điểm.
Thời gian đáp ứng
Một trong những đặc điểm quan trọng nhất của giao thức truyền thông, đặc biệt là liên quan đến Internet of Things, là thời gian phản hồi. Nhưng trong số các giao thức hiện có, không có giao thức chiến thắng rõ ràng nào thể hiện được mức độ trễ tối thiểu khi làm việc trong các điều kiện khác nhau. Nhưng có rất nhiều nghiên cứu và so sánh về khả năng của giao thức.
Ví dụ, So sánh hiệu quả của HTTP và MQTT khi làm việc với IoT cho thấy thời gian phản hồi các yêu cầu đối với MQTT ít hơn so với HTTP. Và khi Thời gian khứ hồi (RTT) của MQTT và CoAP cho thấy RTT trung bình của CoAP thấp hơn 20% so với MQTT.
Khác với RTT cho giao thức MQTT và CoAP được thực hiện theo hai kịch bản: mạng cục bộ và mạng IoT. Hóa ra RTT trung bình cao hơn 2-3 lần trong mạng IoT. MQTT với QoS0 cho kết quả thấp hơn so với CoAP và MQTT với QoS1 cho thấy RTT cao hơn do ACK ở lớp ứng dụng và lớp vận chuyển. Đối với các mức QoS khác nhau, độ trễ mạng không bị tắc nghẽn là mili giây đối với MQTT và hàng trăm micro giây đối với CoAP. Tuy nhiên, cần nhớ rằng khi làm việc trên các mạng kém tin cậy hơn, MQTT chạy trên TCP sẽ hiển thị một kết quả hoàn toàn khác.
thời gian phản hồi cho các giao thức AMQP và MQTT bằng cách tăng tải trọng cho thấy rằng với tải nhẹ thì mức độ trễ gần như giống nhau. Nhưng khi truyền lượng lớn dữ liệu, MQTT thể hiện thời gian phản hồi ngắn hơn. trong một cái nữa CoAP được so sánh với HTTP trong kịch bản giao tiếp giữa máy với máy với các thiết bị được triển khai trên đầu phương tiện được trang bị cảm biến khí, cảm biến thời tiết, cảm biến vị trí (GPS) và giao diện mạng di động (GPRS). Thời gian cần thiết để truyền tin nhắn CoAP qua mạng di động ngắn hơn gần ba lần so với thời gian cần thiết để sử dụng tin nhắn HTTP.
Các nghiên cứu đã được tiến hành để so sánh không phải hai mà là ba giao thức. Ví dụ, hiệu suất của các giao thức IoT MQTT, DDS và CoAP trong kịch bản ứng dụng y tế bằng trình mô phỏng mạng. DDS vượt trội hơn MQTT về độ trễ đo từ xa được thử nghiệm trong nhiều điều kiện mạng kém. CoAP dựa trên UDP hoạt động tốt cho các ứng dụng yêu cầu thời gian phản hồi nhanh, tuy nhiên, do dựa trên UDP nên xảy ra hiện tượng mất gói đáng kể không thể đoán trước.
Băng thông
MQTT và CoAP về mặt hiệu quả băng thông được thực hiện dưới dạng tính toán tổng lượng dữ liệu được truyền trên mỗi tin nhắn. CoAP đã cho thấy thông lượng thấp hơn MQTT khi truyền các tin nhắn nhỏ. Nhưng khi so sánh hiệu quả của các giao thức về tỷ lệ giữa số byte thông tin hữu ích trên tổng số byte được truyền, CoAP hóa ra lại hiệu quả hơn.
Khi sử dụng MQTT, DDS (với TCP làm giao thức truyền tải) và băng thông CoAP, người ta thấy rằng CoAP thường cho thấy mức tiêu thụ băng thông tương đối thấp hơn, không tăng khi mất gói mạng tăng hoặc độ trễ mạng tăng, không giống như MQTT và DDS, nơi có sự gia tăng sử dụng băng thông trong các kịch bản được đề cập. Một tình huống khác liên quan đến một số lượng lớn thiết bị truyền dữ liệu đồng thời, điển hình là trong môi trường IoT. Kết quả cho thấy để có hiệu quả sử dụng cao hơn thì nên sử dụng CoAP.
Khi tải nhẹ, CoAP sử dụng ít băng thông nhất, tiếp theo là MQTT và REST HTTP. Tuy nhiên, khi kích thước của tải trọng tăng lên, REST HTTP có kết quả tốt nhất.
Điện năng tiêu thụ
Vấn đề tiêu thụ năng lượng luôn có tầm quan trọng rất lớn và đặc biệt là trong hệ thống IoT. Nếu như Trong khi MQTT và HTTP tiêu thụ điện thì HTTP tiêu thụ nhiều hơn thế. Và CoAP còn hơn thế nữa so với MQTT, cho phép quản lý năng lượng. Tuy nhiên, trong các tình huống đơn giản, MQTT phù hợp hơn để trao đổi thông tin trong mạng Internet of Things, đặc biệt nếu không có hạn chế về nguồn điện.
Một thử nghiệm so sánh khả năng của AMQP và MQTT trên nền tảng thử nghiệm mạng không dây di động hoặc không ổn định cho thấy AMQP cung cấp nhiều khả năng bảo mật hơn trong khi MQTT tiết kiệm năng lượng hơn.
Безопасность
Bảo mật là một vấn đề quan trọng khác được nêu ra khi nghiên cứu chủ đề Internet vạn vật và điện toán sương mù/đám mây. Cơ chế bảo mật thường dựa trên TLS trong HTTP, MQTT, AMQP và XMPP hoặc DTLS trong CoAP và hỗ trợ cả hai biến thể DDS.
TLS và DTLS bắt đầu bằng quá trình thiết lập liên lạc giữa phía máy khách và máy chủ để trao đổi các bộ và khóa mật mã được hỗ trợ. Cả hai bên đàm phán các bộ để đảm bảo rằng việc liên lạc tiếp theo diễn ra trên một kênh an toàn. Sự khác biệt giữa hai loại này nằm ở những sửa đổi nhỏ cho phép DTLS dựa trên UDP hoạt động trên một kết nối không đáng tin cậy.
Khi Một số cách triển khai TLS và DTLS khác nhau cho thấy TLS hoạt động tốt hơn. Các cuộc tấn công vào DTLS thành công hơn do khả năng chịu lỗi của nó.
Tuy nhiên, vấn đề lớn nhất với các giao thức này là ban đầu chúng không được thiết kế để sử dụng trong IoT và không nhằm mục đích hoạt động trong sương mù hoặc đám mây. Thông qua việc bắt tay, họ bổ sung thêm lưu lượng truy cập với mỗi cơ sở kết nối, điều này làm tiêu hao tài nguyên máy tính. Tính trung bình, chi phí hoạt động của TLS tăng 6,5% và DTLS tăng 11% so với thông tin liên lạc không có lớp bảo mật. Trong môi trường giàu tài nguyên, thường nằm trên Ở cấp độ này, đây sẽ không phải là vấn đề, nhưng trong mối liên hệ giữa IoT và cấp độ sương mù, điều này trở thành một hạn chế quan trọng.
Chọn cái gì? Không có câu trả lời rõ ràng. MQTT và HTTP dường như là các giao thức hứa hẹn nhất vì chúng được coi là giải pháp IoT tương đối hoàn thiện hơn và ổn định hơn so với các giao thức khác.
Giải pháp dựa trên giao thức truyền thông hợp nhất
Việc thực hiện giải pháp giao thức đơn có nhiều nhược điểm. Ví dụ: giao thức phù hợp với môi trường bị hạn chế có thể không hoạt động trong miền có yêu cầu bảo mật nghiêm ngặt. Với suy nghĩ này, chúng tôi buộc phải loại bỏ hầu hết tất cả các giải pháp giao thức đơn có thể có trong hệ sinh thái Fog-to-Cloud trong IoT, ngoại trừ MQTT và REST HTTP.
REST HTTP như một giải pháp giao thức đơn
Có một ví dụ điển hình về cách các yêu cầu và phản hồi REST HTTP tương tác trong không gian IoT-to-Fog: . Các con vật được trang bị cảm biến có thể đeo được (máy khách IoT, C) và được điều khiển thông qua điện toán đám mây bằng hệ thống canh tác thông minh (Máy chủ sương mù, S).
Tiêu đề của phương thức POST chỉ định tài nguyên cần sửa đổi (/farm/animals) cũng như phiên bản HTTP và loại nội dung, trong trường hợp này là đối tượng JSON đại diện cho trang trại chăn nuôi mà hệ thống sẽ quản lý (Dulcinea/bò) . Phản hồi từ máy chủ cho biết yêu cầu đã thành công bằng cách gửi mã trạng thái HTTPS 201 (tài nguyên đã được tạo). Phương thức GET chỉ được chỉ định tài nguyên được yêu cầu trong URI (ví dụ: /farm/animals/1), trả về bản trình bày JSON của động vật có ID đó từ máy chủ.
Phương thức PUT được sử dụng khi cần cập nhật một số bản ghi tài nguyên cụ thể. Trong trường hợp này, tài nguyên chỉ định URI cho tham số cần thay đổi và giá trị hiện tại (ví dụ: cho biết rằng con bò hiện đang đi bộ, /farm/animals/1? state=walk). Cuối cùng, phương thức DELETE được sử dụng tương tự như phương thức GET nhưng chỉ xóa tài nguyên do thao tác.
MQTT như một giải pháp giao thức đơn
Hãy lấy trang trại thông minh tương tự, nhưng thay vì REST HTTP, chúng tôi sử dụng giao thức MQTT. Một máy chủ cục bộ có cài đặt thư viện Mosquitto đóng vai trò là nhà môi giới. Trong ví dụ này, một máy tính đơn giản (được gọi là máy chủ trang trại) Raspberry Pi đóng vai trò là máy khách MQTT, được triển khai thông qua cài đặt thư viện Paho MQTT, hoàn toàn tương thích với nhà môi giới Mosquitto.
Máy khách này tương ứng với lớp trừu tượng IoT đại diện cho một thiết bị có khả năng cảm biến và tính toán. Mặt khác, bộ hòa giải tương ứng với mức độ trừu tượng cao hơn, đại diện cho một nút điện toán sương mù được đặc trưng bởi khả năng xử lý và lưu trữ lớn hơn.
Trong kịch bản trang trại thông minh được đề xuất, Raspberry Pi kết nối với cảm biến gia tốc, GPS và nhiệt độ rồi xuất dữ liệu từ các cảm biến này đến nút sương mù. Như bạn có thể biết, MQTT coi các chủ đề như một hệ thống phân cấp. Một nhà xuất bản MQTT có thể xuất bản thông báo tới một nhóm chủ đề cụ thể. Trong trường hợp của chúng tôi có ba trong số họ. Đối với cảm biến đo nhiệt độ trong chuồng động vật, khách hàng chọn một chủ đề (trang trại động vật/nhà kho/nhiệt độ). Đối với các cảm biến đo vị trí GPS và chuyển động của động vật thông qua gia tốc kế, khách hàng sẽ xuất bản các bản cập nhật cho (trang trại động vật/động vật/GPS) và (trang trại động vật/động vật/chuyển động).
Thông tin này sẽ được chuyển đến nhà môi giới, người này có thể tạm thời lưu trữ nó trong cơ sở dữ liệu cục bộ trong trường hợp người đăng ký quan tâm khác đến sau.
Ngoài máy chủ cục bộ, hoạt động như một nhà môi giới MQTT trong sương mù và Raspberry Pis, đóng vai trò là máy khách MQTT, gửi dữ liệu cảm biến, có thể còn có một nhà môi giới MQTT khác ở cấp độ đám mây. Trong trường hợp này, thông tin được truyền đến nhà môi giới địa phương có thể được lưu trữ tạm thời trong cơ sở dữ liệu cục bộ và/hoặc gửi lên đám mây. Nhà môi giới MQTT sương mù trong tình huống này được sử dụng để liên kết tất cả dữ liệu với nhà môi giới MQTT trên đám mây. Với kiến trúc này, người dùng ứng dụng di động có thể đăng ký cả hai nhà môi giới.
Nếu kết nối với một trong các nhà môi giới (ví dụ: đám mây) không thành công, người dùng cuối sẽ nhận được thông tin từ nhà môi giới kia (sương mù). Đây là một tính năng đặc trưng của hệ thống điện toán đám mây và sương mù kết hợp. Theo mặc định, ứng dụng di động có thể được định cấu hình để kết nối với nhà môi giới MQTT sương mù trước và nếu không thành công, hãy kết nối với nhà môi giới MQTT trên đám mây. Giải pháp này chỉ là một trong nhiều giải pháp trong hệ thống IoT-F2C.
Giải pháp đa giao thức
Các giải pháp giao thức đơn rất phổ biến do việc triển khai dễ dàng hơn. Nhưng rõ ràng là trong các hệ thống IoT-F2C, việc kết hợp các giao thức khác nhau là điều hợp lý. Ý tưởng là các giao thức khác nhau có thể hoạt động ở các cấp độ khác nhau. Lấy ví dụ, ba khái niệm trừu tượng: các lớp IoT, sương mù và điện toán đám mây. Các thiết bị ở cấp độ IoT thường được coi là hạn chế. Để có cái nhìn tổng quan này, hãy coi các cấp độ IoT là cấp độ bị hạn chế nhất, đám mây là cấp độ ít bị hạn chế nhất và điện toán sương mù là "đâu đó ở giữa". Hóa ra giữa IoT và trừu tượng hóa sương mù, các giải pháp giao thức hiện tại bao gồm MQTT, CoAP và XMPP. Mặt khác, giữa sương mù và đám mây, AMQP là một trong những giao thức chính được sử dụng, cùng với REST HTTP, do tính linh hoạt của nó cũng được sử dụng giữa các lớp IoT và sương mù.
Vấn đề chính ở đây là khả năng tương tác của các giao thức và sự dễ dàng truyền tải thông điệp từ giao thức này sang giao thức khác. Lý tưởng nhất là trong tương lai, kiến trúc của hệ thống Internet of Things với tài nguyên đám mây và sương mù sẽ độc lập với giao thức truyền thông được sử dụng và sẽ đảm bảo khả năng tương tác tốt giữa các giao thức khác nhau.
Vì hiện tại điều này không xảy ra nên việc kết hợp các giao thức không có sự khác biệt đáng kể là điều hợp lý. Để đạt được mục tiêu này, một giải pháp tiềm năng dựa trên sự kết hợp của hai giao thức có cùng kiểu kiến trúc là REST HTTP và CoAP. Một giải pháp được đề xuất khác dựa trên sự kết hợp của hai giao thức cung cấp giao tiếp đăng ký xuất bản, MQTT và AMQP. Việc sử dụng các khái niệm tương tự (cả MQTT và AMQP đều sử dụng trình môi giới, CoAP và HTTP sử dụng REST) làm cho các kết hợp này dễ triển khai hơn và yêu cầu ít nỗ lực tích hợp hơn.
Hình (a) hiển thị hai mô hình dựa trên phản hồi yêu cầu, HTTP và CoAP, cũng như vị trí có thể có của chúng trong giải pháp IoT-F2C. Vì HTTP là một trong những giao thức được biết đến và áp dụng nhiều nhất trên các mạng hiện đại nên khó có khả năng nó sẽ bị thay thế hoàn toàn bởi các giao thức nhắn tin khác. Trong số các nút đại diện cho các thiết bị mạnh mẽ nằm giữa đám mây và sương mù, REST HTTP là một giải pháp thông minh.
Mặt khác, đối với các thiết bị có tài nguyên điện toán hạn chế giao tiếp giữa lớp Sương mù và IoT, việc sử dụng CoAP sẽ hiệu quả hơn. Một trong những lợi thế lớn của CoAP thực sự là khả năng tương thích với HTTP, vì cả hai giao thức đều dựa trên nguyên tắc REST.
Hình (b) hiển thị hai mô hình truyền thông đăng ký xuất bản trong cùng một kịch bản, bao gồm MQTT và AMQP. Mặc dù theo giả thuyết, cả hai giao thức có thể được sử dụng để liên lạc giữa các nút ở mỗi lớp trừu tượng, nhưng vị trí của chúng phải được xác định dựa trên hiệu suất. MQTT được thiết kế như một giao thức nhẹ dành cho các thiết bị có tài nguyên máy tính hạn chế, do đó nó có thể được sử dụng cho giao tiếp IoT-Fog. AMQP phù hợp hơn với các thiết bị mạnh hơn, lý tưởng nhất là đặt nó giữa các nút sương mù và đám mây. Thay vì MQTT, giao thức XMPP có thể được sử dụng trong IoT vì nó được coi là nhẹ. Nhưng nó không được sử dụng rộng rãi trong những tình huống như vậy.
Những phát hiện
Không chắc rằng một trong các giao thức được thảo luận sẽ đủ để bao phủ tất cả thông tin liên lạc trong hệ thống, từ các thiết bị có tài nguyên máy tính hạn chế đến máy chủ đám mây. Nghiên cứu cho thấy hai tùy chọn hứa hẹn nhất được các nhà phát triển sử dụng nhiều nhất là MQTT và RESTful HTTP. Hai giao thức này không chỉ hoàn thiện và ổn định nhất mà còn bao gồm nhiều tài nguyên trực tuyến và triển khai thành công được ghi chép đầy đủ và thành công.
Do tính ổn định và cấu hình đơn giản, MQTT là giao thức đã chứng minh được hiệu suất vượt trội theo thời gian khi được sử dụng ở cấp độ IoT với số lượng thiết bị hạn chế. Trong các phần của hệ thống nơi giao tiếp hạn chế và mức tiêu thụ pin không phải là vấn đề, chẳng hạn như một số miền sương mù và hầu hết điện toán đám mây, RESTful HTTP là một lựa chọn dễ dàng. CoAP cũng cần được tính đến vì nó cũng đang phát triển nhanh chóng như một tiêu chuẩn nhắn tin IoT và có khả năng nó sẽ đạt đến mức độ ổn định và trưởng thành tương tự như MQTT và HTTP trong tương lai gần. Tuy nhiên, tiêu chuẩn này hiện đang phát triển và đi kèm với đó là các vấn đề về khả năng tương thích ngắn hạn.
Bạn có thể đọc gì khác trên blog?
→
→
→
→
→
Đăng ký của chúng tôi -channel để không bỏ lỡ bài viết tiếp theo nhé! Chúng tôi viết không quá hai lần một tuần và chỉ viết về công việc.
Nguồn: www.habr.com