TLS와 MQTT 간의 MQTT 성능

MQTT는 매우 다양하지만 자체적으로 보안되지는 않습니다. 이것은 의도적으로 설계된 동작입니다.

Stanford-Clark에 따르면, 보안을 강화하기 위해 MQTT에 보안 메커니즘을 감쌀 수 있다는 사실을 알고 있었기 때문에 처음에는 보안이 의도적으로 프로토콜에서 제외되었다고합니다. 또한 Stanford-Clark는 기상 관측소의 풍속 데이터와 같은 MQTT를 통해 전송 된 정보는 특별히 보안이 필요하지 않다고 말했다. - 출처

MQTT를 감쌀 수있는 보안 메커니즘 중 하나는 TLS입니다. 오늘날 대부분의 중개인이이를 지원합니다. 물론 모든 포장 단위는 오버 헤드를 발생시킵니다. 이 오버 헤드는 무시해도됩니다 ( HiveMQ 블로그 참조 ).

현재 프로젝트에 대한 MQTT의 실행 가능성을 평가하기 위해 TLS와 일반 MQTT를 통한 MQTT의 성능 손실에 대한 정보 (권장 소스)를 찾고 있습니다. 특히 기술이 많은 가입자로 확장 될 때.

프로토 타이핑 외에 TLS를 통한 MQTT의 성능에 대한 유효한 데이터를 얻는 방법이 있습니까?

연결이 설정되면 차이가 너무 클 것으로 기대하지 않습니다 .

TLS가 일반적으로 생성하는 오버 헤드의 내역은 여기 에서 확인할 수 있습니다 . 중요한 부분은 다음과 같습니다.

• 새로운 TLS 세션을 설정하기위한 총 오버 헤드는 평균 약 6.5k 바이트입니다.
• 기존 TLS 세션을 재개하기위한 총 오버 헤드는 평균 약 330 바이트입니다.
• 암호화 된 데이터의 총 오버 헤드는 약 40 바이트 (20 + 15 + 5)입니다.
• 환경의 세부 사항을보다 정확하게 반영하기 위해 위의 계산을 쉽게 수정할 수 있으므로, 이는 제기 된 질문에 대한 권위있는 답변이 아닌 TLS 오버 헤드의 기초로 간주되어야합니다.

이 수치들이 어떻게 계산되었는지를 읽어 볼 가치가 있습니다. TLS가이 모든 것들과 어떻게 작동하는지 더 잘 이해해야합니다. 다른 답변에서 언급했듯이, 무선 전송은 종종 IoT의 제약 인 가장 큰 에너지 사용 중 하나 일 수 있습니다. 따라서 세션이 설정되면 오버 헤드는 특히 중요하지 않습니다. 사소하게 짧지 않습니다.

언급 한 바와 같이 기사에서 HiveMQ에 의해 TLS가 MQTT 실적에 어떤 영향이 있나요? :

좋은 소식은 MQTT 클라이언트가 HTTP와 같은 프로토콜과 달리 세션마다 한 번만 연결을 설정하면된다는 것입니다. HTTP와 같은 프로토콜은 모든 요청에서 연결을 다시 설정해야합니다 (keep-alive가 사용되지 않거나 Long과 같은 다른 기술이있는 경우) 설문 조사가 진행 중입니다). 브로커에 연결되면 클라이언트는 추가 핸드 셰이크 오버 헤드없이 메시지를 보내고받을 수 있습니다. TLS를 사용하려면 추가 버퍼를 할당해야하므로 MQTT 연결마다 RAM 소비가 약간 더 높습니다.

또한 50,000 명의 클라이언트가 연결할 때 브로커의 CPU 사용률 그래프를 제공 합니다.

^{이미지 출처 : HiveMQ (위의 링크 된 기사 참조)}

이 거의 확실 유의를 수행 하지 일반적인 사용 패턴,하지만 데이터가 그럼에도 불구하고 재미있다. 보시다시피 핸드 셰이크가 진행되는 동안 오버 헤드가 크지 만 CPU 오버 헤드는 거의 동일합니다. 나는 클라이언트에서 비슷한 것을 기대할 것입니다.

그럼에도 불구하고 일반적인 조언은 정확합니다. 검증 된 벤치 마크는 실제로 필요한 정보를 제공하지 않습니다. TLS가 유스 케이스에 어떤 영향을 미치는지 알기 위해서는 테스트해야 합니다. 유스 케이스 !

실제로는 특정 상황을 테스트하고 벤치마킹해야 할 것입니다. 다음은 성능에 직접적인 영향을 줄 수 있습니다.

• 어떤 클라이언트 / 브로커 하드웨어를 사용하고 있으며 암호화에 대한 하드웨어 가속 기능이 있습니까?
• 전송하는 페이로드의 크기는 얼마입니까?
• 응용 프로그램의 연결 / 재 연결 프로파일은 무엇입니까?

유용한 성능 평가는 어렵습니다. 응용 프로그램에서 최소한 일부 트래픽에 대해서는 암호화가 필요할 수 있으므로이 트래픽의 하위 집합에 보안을 적용하기위한 구현 비용은 거의 없습니다.

에너지 제한적인 구현의 경우 전송이 무선 일 가능성이 높습니다. 적절한 무선 채널이 있더라도 채널을 설정하고 연결을 협상하는 데 드는 에너지 비용은 간단한 메시지를 암호화하는 데 드는 처리 비용을 능가 할 수 있습니다 (특히 일부 메시지는 암호화가 필요한 경우) .

메시지가 사소하지 않은 경우 , 네트워크 트래픽을 줄이기 위해 엔드 포인트에서 더 많은 처리를 수행하는 데 약간의 정당성이있을 수 있습니다 .

마지막으로, 채널이 과도하게로드되는 시나리오에서는 전체 시스템의보다 사소한 구현을 분석하는 것보다 성능이 좋지 않을 수 있습니다.

찾고있는 데이터에 대한 참조를 찾을 수 있다고해도 디자인 결정의 기반이되기에 충분한 질문에 대답 할 가능성은 거의 없습니다.