虽然 MQTT 非常通用，但它本身也没有安全保障。这是设计使然。
根据斯坦福-克拉克的说法，最初有意识地将安全排除在协议之外，因为他和 Nipper 知道可以围绕 MQTT 包裹安全机制以提高安全性。此外，当时斯坦福-克拉克表示，通过 MQTT 发送的信息（例如来自气象站的风速数据）并不是特别需要保护。-来源
可以围绕 MQTT 包装的安全机制之一是 TLS。现在大多数经纪人都支持这一点。当然，任何包装措施都会产生开销。这种开销可能可以忽略不计（参见HiveMQ 博客）。
目前，我正在寻找有关 MQTT over TLS 与普通 MQTT 性能损失的信息（希望是权威来源），以评估 MQTT 对我的项目的可行性。尤其是当该技术扩展到大量订阅者时。
除了原型设计之外，还有其他方法可以获取有关基于 TLS 的 MQTT 性能的有效数据吗？
一旦建立连接，我不希望差异太大。
可以在此处找到TLS 产生的一般开销细目。重要的位是：
- 建立新 TLS 会话的总开销平均约为 6.5k 字节
- 恢复现有 TLS 会话的总开销平均约为 330 字节
- 加密数据的总开销约为 40 字节（20 + 15 + 5）
- 很容易修改上述计算以更准确地反映环境的具体情况，因此这应该被视为 TLS 开销的基础，而不是所提出问题的权威答案。
值得一读，看看这些数字是如何计算的——您应该对 TLS 如何处理所有这些数据有更深入的了解。正如其他答案中所述，无线电传输可能是能源的最大用途之一，这通常是物联网中的一个限制因素，因此一旦建立会话，开销就不会太大，特别是如果您的消息是不是很短。
正如HiveMQ 在文章中指出的TLS 如何影响 MQTT 性能？：
好消息是，MQTT 客户端每个会话只需要建立一次连接——这与 HTTP 等协议相反，它需要在每次请求时重新建立连接（如果没有使用 keep-alive 或其他技术，如 Long投票到位）。一旦连接到代理，客户端就可以发送和接收消息，而无需任何额外的握手开销。使用 TLS 需要分配额外的缓冲区，因此每个 MQTT 连接的 RAM 消耗也略高。
它们还提供了当 50,000 个客户端连接时代理上的 CPU 利用率图：
图片来源：HiveMQ（见上面链接的文章）
请注意，这几乎肯定不是典型的使用模式，但数据仍然很有趣。如您所见，握手过程中的开销很大，但之后，CPU 开销几乎相同。我希望在客户端有类似的事情。
不过，这里的一般建议是正确的：人为的基准不会为您提供真正需要的信息；要了解 TLS 将如何影响您的用例，您需要在...您的用例中对其进行测试！
并非如此，您几乎必须对您的特定情况进行测试和基准测试。以下内容可能会对性能产生直接影响。
做出有用的性能估计是很困难的。您的应用程序很可能至少需要对其部分流量进行加密，因此不太可能需要任何实施成本来为该流量子集提供安全性。
对于能量受限的实现，传输很可能是无线的。即使有合适的无线电信道，建立信道和协商连接的能量成本也可能超过加密简单消息的处理成本——特别是如果某些消息需要加密。
如果您的消息不重要，则可能有理由在端点执行更多处理以减少网络流量。
最后，在通道负载很重的情况下，性能可能不如您通过分析整个系统的更琐碎的实现而预期的那么好。
即使您可以找到您正在寻找的数据的参考，也不太可能回答足够多的问题，足以作为设计决策的基础。
