Desempenho do MQTT sobre TLS vs. MQTT

Embora o MQTT seja bastante versátil, ele também não é protegido por si próprio. Isso ocorre por design.

De acordo com Stanford-Clark, a segurança foi conscientemente deixada de fora do protocolo inicialmente porque ele e Nipper sabiam que os mecanismos de segurança poderiam ser envolvidos no MQTT para aumentar a segurança. Além disso, na época, Stanford-Clark disse que as informações enviadas via MQTT, como dados de velocidade do vento de uma estação meteorológica, não precisavam particularmente de segurança. - Fonte

Um desses mecanismos de segurança que podem ser envolvidos no MQTT é o TLS. A maioria dos corretores suporta isso hoje em dia. É claro que qualquer medida de empacotamento produz sobrecarga. Essa sobrecarga pode ser insignificante ( consulte o blog do HiveMQ ).

Atualmente, estou procurando informações (espero uma fonte autorizada) sobre a perda de desempenho do MQTT sobre TLS vs. MQTT simples para avaliar a viabilidade do MQTT para o meu projeto. Especialmente quando a tecnologia se transforma em um grande número de assinantes.

Existe uma maneira além da prototipagem para obter dados válidos sobre o desempenho do MQTT sobre TLS?

Eu não esperaria que a diferença fosse muito significativa assim que a conexão estiver configurada .

Um detalhamento da sobrecarga que o TLS produz em geral pode ser encontrado aqui . Os bits importantes são:

• A sobrecarga total para estabelecer uma nova sessão TLS chega a cerca de 6,5k bytes, em média
• A sobrecarga total para retomar uma sessão TLS existente chega a cerca de 330 bytes, em média
• A sobrecarga total dos dados criptografados é de cerca de 40 bytes (20 + 15 + 5)
• É fácil modificar os cálculos acima para refletir com mais precisão as especificidades de um ambiente, portanto, isso deve ser considerado uma base para a sobrecarga do TLS e não a resposta autorizada à pergunta colocada.

Vale a pena ler para ver como esses números foram calculados - você deve entender melhor como o TLS funciona com tudo isso. Conforme observado em outras respostas, a transmissão por rádio provavelmente é um dos maiores usos de energia, o que geralmente é uma restrição na IoT; portanto, uma vez que a sessão é estabelecida, a sobrecarga não é muito significativa, principalmente se suas mensagens são não é trivialmente curto.

Conforme observado pelo HiveMQ no artigo Como o TLS afeta o desempenho do MQTT? :

A boa notícia é que um cliente MQTT só precisa estabelecer uma conexão uma vez por sessão - ao contrário de protocolos como HTTP, que precisam restabelecer uma conexão em cada solicitação (se nenhum keep-alive for usado ou outras técnicas como Long Sondagens). Uma vez conectado ao broker, o cliente pode enviar e receber mensagens sem sobrecarga adicional de handshake. O uso do TLS precisa alocar buffers adicionais, portanto, o consumo de RAM também é um pouco maior por conexão MQTT.

Eles também fornecem um gráfico da utilização da CPU no broker quando 50.000 clientes se conectam:

^{Fonte da imagem: HiveMQ (veja o artigo acima)}

Observe que esse certamente não é um padrão de uso típico, mas os dados são interessantes. Como você pode ver, há uma grande sobrecarga enquanto os handshakes estão em andamento, mas depois disso, a sobrecarga da CPU é quase idêntica. Eu esperaria uma coisa semelhante no cliente.

Ainda assim, o conselho geral aqui está correto: uma referência artificial não fornecerá as informações que você realmente precisa; para saber como o TLS afetará seu caso de uso, você deve testá-lo em ... seu caso de uso !

Na verdade não, você terá que testar e comparar sua situação específica. É provável que o seguinte tenha um impacto direto no desempenho.

• Qual hardware de cliente / broker você está usando, ele tem alguma aceleração de hardware para criptografia?
• Qual é o tamanho da carga útil que você está enviando?
• Qual é o perfil de conexão / reconexão para seu aplicativo?

Fazer estimativas de desempenho úteis é difícil. É provável que seu aplicativo exija criptografia para pelo menos parte do tráfego, portanto é improvável que exista algum custo de implementação para disponibilizar a segurança para esse subconjunto do tráfego.

Para uma implementação com restrição de energia, é provável que a transmissão seja sem fio. Mesmo com um canal de rádio adequado, o custo de energia para configurar o canal e negociar a conexão provavelmente superará o custo de processamento para criptografar uma mensagem simples - principalmente se algumas mensagens precisarem de criptografia.

Se suas mensagens não forem triviais, pode haver alguma justificativa para executar mais processamento no terminal para reduzir o tráfego de rede.

Finalmente, em um cenário em que o canal está muito carregado, o desempenho pode não ser tão bom quanto o esperado, analisando uma implementação mais trivial do seu sistema completo.

Mesmo que você possa encontrar uma referência para os dados que está procurando, é improvável que você responda o suficiente à pergunta para basear as decisões de design.