Hiệu suất của MQTT so với TLS so với MQTT

Mặc dù MQTT khá linh hoạt nhưng nó cũng không được bảo mật. Đây là do thiết kế.

Theo Stanford-Clark, ban đầu, an ninh đã bị loại bỏ khỏi giao thức vì anh và Nipper biết các cơ chế bảo mật có thể được bao bọc xung quanh MQTT để tăng cường bảo mật. Ngoài ra, vào thời điểm đó, Stanford-Clark cho biết thông tin được gửi qua MQTT, chẳng hạn như dữ liệu tốc độ gió từ trạm thời tiết, đặc biệt không cần bảo mật. - Nguồn

Một trong những cơ chế bảo mật có thể được bao bọc xung quanh MQTT là TLS. Hầu hết các nhà môi giới hỗ trợ này ngày nay. Tất nhiên bất kỳ biện pháp gói sản xuất trên đầu. Chi phí này có thể không đáng kể (xem blog HiveMQ ).

Hiện tại tôi đang tìm kiếm thông tin (hy vọng là một nguồn có thẩm quyền) về việc mất hiệu suất của MQTT so với TLS so với MQTT đơn giản để đánh giá khả năng tồn tại của MQTT cho dự án của tôi. Đặc biệt là khi công nghệ quy mô thành một số lượng lớn các thuê bao.

Có cách nào ngoài việc tạo mẫu để có được dữ liệu hợp lệ về hiệu suất của MQTT qua TLS không?

Tôi sẽ không mong đợi sự khác biệt là quá quan trọng, khi kết nối được thiết lập .

Một phân tích về các chi phí mà TLS sản xuất nói chung có thể được tìm thấy ở đây . Các bit quan trọng là:

• Tổng chi phí để thiết lập một phiên TLS mới trung bình khoảng 6,5 nghìn byte
• Tổng chi phí để tiếp tục một phiên TLS hiện tại trung bình khoảng 330 byte
• Tổng chi phí của dữ liệu được mã hóa là khoảng 40 byte (20 + 15 + 5)
• Thật dễ dàng để sửa đổi các tính toán ở trên để phản ánh chính xác hơn các chi tiết cụ thể của một môi trường, vì vậy đây nên được coi là cơ sở cho chi phí TLS và không phải là câu trả lời có thẩm quyền cho câu hỏi được đặt ra.

Thật đáng để đọc để xem những con số này được tính toán như thế nào, bạn sẽ hiểu rõ hơn về cách thức hoạt động của TLS với tất cả những điều đó. Như đã lưu ý trong các câu trả lời khác, truyền phát vô tuyến có thể là một trong những năng lượng sử dụng năng lượng lớn nhất, thường là một hạn chế trong IoT, vì vậy một khi phiên được thiết lập, chi phí không quá quan trọng, đặc biệt nếu tin nhắn của bạn là không tầm thường

Như HiveMQ đã lưu ý trong bài viết TLS ảnh hưởng đến hiệu suất MQTT như thế nào? :

Tin vui là, máy khách MQTT chỉ cần thiết lập kết nối một lần mỗi phiên - trái với các giao thức như HTTP, cần thiết lập lại kết nối theo mọi yêu cầu (nếu không sử dụng hoặc các kỹ thuật khác như Long Bỏ phiếu tại chỗ). Sau khi kết nối với nhà môi giới, khách hàng có thể gửi và nhận tin nhắn mà không cần thêm bất kỳ chi phí bắt tay nào. Việc sử dụng TLS cần phân bổ bộ đệm bổ sung, do đó mức tiêu thụ RAM cũng cao hơn một chút cho mỗi kết nối MQTT.

Họ cũng cung cấp một biểu đồ sử dụng CPU trên nhà môi giới khi 50.000 khách hàng kết nối:

^{Nguồn hình ảnh: HiveMQ (xem bài viết được liên kết ở trên)}

Xin lưu ý rằng điều này gần như chắc chắn không phải là một mô hình sử dụng thông thường, nhưng dữ liệu vẫn rất thú vị. Như bạn có thể thấy, có một chi phí lớn trong khi quá trình bắt tay đang diễn ra, nhưng sau đó, chi phí hoạt động của CPU gần như giống hệt nhau. Tôi sẽ mong đợi một điều tương tự trên máy khách.

Tuy nhiên, lời khuyên chung ở đây là chính xác: một điểm chuẩn có sẵn sẽ không cung cấp cho bạn thông tin bạn thực sự cần; để biết TLS sẽ ảnh hưởng đến trường hợp sử dụng của bạn như thế nào, bạn cần kiểm tra nó trong ... trường hợp sử dụng của bạn !

Không thực sự, khá nhiều bạn sẽ phải kiểm tra và đánh giá tình hình cụ thể của bạn. Những điều sau đây có khả năng có tác động trực tiếp đến hiệu suất.

• Bạn đang sử dụng phần cứng máy khách / nhà môi giới nào, nó có tăng tốc phần cứng cho tiền điện tử không?
• Kích thước của tải trọng bạn đang gửi là gì?
• Hồ sơ kết nối / kết nối lại cho ứng dụng của bạn là gì?

Làm ước tính hiệu suất hữu ích là khó. Có khả năng ứng dụng của bạn sẽ yêu cầu mã hóa cho ít nhất một số lưu lượng truy cập, do đó, không có khả năng có bất kỳ chi phí triển khai nào để đảm bảo an toàn cho tập hợp con lưu lượng này.

Đối với việc thực hiện hạn chế năng lượng, truyền dẫn có khả năng là không dây. Ngay cả với một kênh radio phù hợp, chi phí năng lượng để thiết lập kênh và đàm phán kết nối có khả năng cao hơn chi phí xử lý để mã hóa một tin nhắn đơn giản - đặc biệt nếu một số tin nhắn cần mã hóa.

Nếu tin nhắn của bạn không tầm thường, có thể có một số biện minh trong việc thực hiện xử lý nhiều hơn ở điểm cuối để giảm lưu lượng mạng.

Cuối cùng, trong một kịch bản mà kênh được tải rất nhiều, hiệu suất có thể không tốt như bạn dự đoán từ việc phân tích một triển khai tầm thường hơn của hệ thống đầy đủ của bạn.

Ngay cả khi bạn có thể tìm thấy một tài liệu tham khảo cho dữ liệu bạn đang tìm kiếm, không có khả năng trả lời đủ câu hỏi là đủ để đưa ra quyết định thiết kế.