Rendimiento de MQTT sobre TLS frente a MQTT

Si bien MQTT es bastante versátil, tampoco está asegurado en sí mismo. Esto es por diseño.

Según Stanford-Clark, la seguridad se excluyó conscientemente del protocolo inicialmente porque él y Nipper sabían que los mecanismos de seguridad podrían estar envueltos alrededor de MQTT para aumentar la seguridad. Además, en ese momento, Stanford-Clark dijo que la información enviada a través de MQTT, como los datos de la velocidad del viento desde una estación meteorológica, no era particularmente necesaria. - Fuente

Uno de esos mecanismos de seguridad que pueden envolverse alrededor de MQTT es TLS. La mayoría de los corredores apoyan esto hoy en día. Por supuesto, cualquier medida de envoltura produce gastos generales. Esta sobrecarga puede ser insignificante (véase el blog de HiveMQ ).

Actualmente estoy buscando información (con suerte, una fuente autorizada) sobre la pérdida de rendimiento de MQTT sobre TLS frente a MQTT simple para evaluar la viabilidad de MQTT para mi proyecto. Especialmente cuando la tecnología escala a una gran cantidad de suscriptores.

¿Hay alguna forma además de la creación de prototipos para obtener datos válidos sobre el rendimiento de MQTT sobre TLS?

No esperaría que la diferencia fuera demasiado significativa, una vez que se establece la conexión .

Aquí puede encontrar un desglose de los gastos generales que produce TLS en general . Los bits importantes son:

• La sobrecarga total para establecer una nueva sesión TLS llega a aproximadamente 6.5k bytes en promedio
• La sobrecarga total para reanudar una sesión TLS existente llega a unos 330 bytes en promedio
• La sobrecarga total de los datos cifrados es de aproximadamente 40 bytes (20 + 15 + 5)
• Es fácil modificar los cálculos anteriores para reflejar con mayor precisión los detalles de un entorno, por lo que esto debe considerarse una base para la sobrecarga de TLS y no la respuesta autorizada a la pregunta planteada.

Vale la pena leerlo para ver cómo se calcularon estas cifras: debe comprender mejor cómo funciona TLS con todo eso. Como se señaló en otras respuestas, es probable que la transmisión de radio sea uno de los mayores usos de la energía, que a menudo es una restricción en el IoT, por lo que una vez que se establece la sesión, la sobrecarga no es demasiado significativa, especialmente si sus mensajes son no trivialmente corto.

Como señaló HiveMQ en el artículo ¿Cómo afecta TLS al rendimiento de MQTT? :

La buena noticia es que un cliente MQTT solo necesita establecer una conexión una vez por sesión, a diferencia de protocolos como HTTP, que necesita restablecer una conexión en cada solicitud (si no se utiliza keep-alive u otras técnicas como Long Las encuestas están en su lugar). Una vez conectado al intermediario, el cliente puede enviar y recibir mensajes sin ninguna sobrecarga adicional de protocolo de enlace. El uso de TLS necesita asignar buffers adicionales, por lo que el consumo de RAM también es ligeramente mayor por conexión MQTT.

También proporcionan un gráfico de la utilización de la CPU en el agente cuando se conectan 50,000 clientes:

^{Fuente de la imagen: HiveMQ (ver artículo vinculado anteriormente)}

Tenga en cuenta que esto casi seguro no es un patrón de uso típico, pero los datos son interesantes. Como puede ver, hay una gran sobrecarga mientras los apretones de manos están en progreso, pero después de eso, la sobrecarga de la CPU es casi idéntica. Esperaría algo similar en el cliente.

Aún así, el consejo general aquí es correcto: un punto de referencia artificial no le dará la información que realmente necesita; Para saber cómo TLS afectará su caso de uso, debe probarlo en ... ¡ su caso de uso !

En realidad no, tendrás que probar y comparar tu situación específica. Es probable que lo siguiente tenga un impacto directo en el rendimiento.

• ¿Qué hardware de cliente / corredor está utilizando? ¿Tiene alguna aceleración de hardware para criptografía?
• ¿Cuál es el tamaño de la carga útil que está enviando?
• ¿Cuál es el perfil de conexión / reconexión para su aplicación?

Hacer estimaciones de rendimiento útiles es difícil. Es probable que su aplicación requiera cifrado para al menos parte de su tráfico, por lo que es poco probable que haya algún costo de implementación para que la seguridad esté disponible para este subconjunto del tráfico.

Para una implementación con restricciones de energía, es probable que la transmisión sea inalámbrica. Incluso con un canal de radio adecuado, es probable que el costo energético de configurar el canal y negociar la conexión supere el costo de procesamiento para cifrar un mensaje simple, especialmente si algunos mensajes necesitan cifrado.

Si sus mensajes no son triviales, puede haber alguna justificación para realizar más procesamiento en el punto final para reducir el tráfico de red.

Finalmente, en un escenario en el que el canal está muy cargado, el rendimiento puede no ser tan bueno como anticipa de analizar una implementación más trivial de su sistema completo.

Incluso si puede encontrar una referencia para los datos que está buscando, es poco probable que responda suficiente de la pregunta como para basar las decisiones de diseño.