据Stanford-Clark所说，安全性最初被有意识地排除在协议之外，因为他和Nipper知道安全性机制可以围绕MQTT来增强安全性。同样，当时，斯坦福-克拉克（Stanford-Clark）说，通过MQTT发送的信息（例如来自气象站的风速数据）并不需要特别安全。 -来源
TLS是可封装在MQTT周围的安全机制之一。如今，大多数经纪人都支持。当然，任何包装措施都会产生开销。此开销可以忽略不计（请参阅HiveMQ博客）。
当前，我正在寻找有关TLS与普通MQTT相比MQTT性能损失的信息（希望是权威来源），以评估MQTT的可行性为我的项目。尤其是当技术扩展到大量订户时。
除了原型制作之外，还有其他方法可以通过TLS获得有关MQTT性能的有效数据吗？
#1 楼
建立连接后，我不希望两者之间的差异太大。此处可以找到TLS通常产生的开销的细分。重要的位是：
建立新的TLS会话的总开销平均约为6.5k字节
恢复现有TLS的总开销会话平均大约需要330个字节
加密数据的总开销约为40个字节（20 + 15 + 5）
修改上述计算很容易，以更准确地反映特定的环境，因此应该将其视为TLS开销的基础，而不是提出的问题的权威性答案。
值得一读以了解这些数字是如何计算的—您应该更加了解TLS如何与所有这些一起工作。如其他答案所述，无线电传输可能是能源的最大用途之一，这通常是物联网的一个限制，因此，一旦建立会话，开销就不会太大，尤其是当您的消息是
正如HiveMQ在TLS如何影响MQTT性能上所指出的那样：每个会话一次建立连接–与HTTP之类的协议相反，HTTP需要在每个请求上重新建立连接（如果未使用保持活动状态或采用了诸如Long Polling之类的其他技术）。连接到代理后，客户端可以发送和接收消息，而无需任何额外的握手开销。 TLS的使用需要分配更多的缓冲区，因此每个MQTT连接的RAM消耗也略高。 br />
图片来源：HiveMQ（请参见上面的链接文章）
请注意，这几乎肯定不是典型的使用模式，但是数据仍然很有趣。如您所见，握手过程中开销很大，但是在那之后，CPU开销几乎相同。我希望客户也有类似的事情。
不过，这里的一般建议是正确的：人为的基准测试不会提供您真正需要的信息；要了解TLS将如何影响您的用例，您需要在您的用例中对其进行测试！
#2 楼
并非如此，您几乎必须测试并确定特定情况的基准。以下内容可能会对性能产生直接影响。您使用的是什么客户端/经纪人硬件，它对加密有什么硬件加速吗？
大小是多少您要发送的有效负载中的什么？
您的应用程序的连接/重新连接配置文件是什么？
#3 楼
做出有用的性能估算很困难。您的应用程序可能至少需要对部分流量进行加密，因此为该流量的此子集提供安全性的可能性不大。 ，传输可能是无线的。即使有合适的无线电信道，建立信道和协商连接的能量成本也可能超过加密简单消息的处理成本-尤其是在某些消息需要加密的情况下。如果您的消息不平凡，在端点执行更多处理以减少网络流量可能有一定道理。
最后，在信道负载较重的情况下，性能可能不如您可以通过分析整个系统的更为琐碎的实现来期望。决定。
评论
在SO上检查以下答案：stackoverflow.com/questions/1615882/…