场景
IoT 设备（当前为 IPv4 设备），每天通过 TCP 套接字向服务器发送一次有效负载。服务器有一个公共 IP 地址，设备位于路由器/NAT 后面。我将使用基于 ESP8266 的模块（即 Olimex 一个）
目标
的服务器应该能够将数据发送到任何客户端，只要它需要。我对直接客户端到客户端的通信（即从我的智能手机连接到设备）不感兴趣，就像打孔应该做的那样。
其他要求
IoT 设备可能会增长到数千个。他们的互联网连接由许多支持 4G 的路由器/调制解调器提供。每个将处理 10-20 个客户。
建议的解决方案
据我了解，一个常见的解决方案是 MQTT。客户端定期将数据发送到代理（即运行在托管服务器上的 Mosquitto），然后更新运行在同一服务器上的主 Web 应用程序。
问题
MQTT 方法是否适用于“大量”设备（1000 多个），其中大部分设备位于 4G 路由器后面？
任何体面的 MQTT 代理都可以轻松处理 1,000 个客户端；Scalagent的基准测试表明，PC 具有：
可以处理 60,000 个运行 Mosquitto 的发布商。这远远超过了您所需的 1,000 个发布者，因此即使在相对较弱的服务器上，您仍然应该能够处理所需的数量。
其他一些代理声称性能更好（当然，服务器能力也相应更强），例如HiveMQ，它声称可以处理1000 万个发布者。
MQTT 代理通常期望持久连接，并且会使不定期发送 ping 响应（或其他活动）的客户端超时。您可以在发布后断开网络连接，但很明显，如果断开连接，您将无法接收任何信息。
MQTT 确实支持可能有用的“保留”消息的概念。Web 客户端可以将某些内容发布到具有保留标志的主题，然后该消息将由代理存储。每当您的客户重新连接并订阅主题时，他们就会收到保留的消息（即使它是在几个小时前发布的）。每次客户端订阅该主题时都会发布保留的消息，因此如果您的连接不完整并且需要存储消息直到客户端重新连接，这可能会对您有所帮助。
您可以使用来自客户端的持久会话，例如在连接时将 clean 标志设置为 false。在这种情况下，当您的客户端处于离线状态时，代理会将消息缓冲到自己的缓存中，并在设备连接后传送。
关于数量 - 即使对于一台服务器来说，10K 也是一个相对较低的数量。您可以将 Linux 服务器配置为保持 50 万个活动连接，如果您的代理是基于云的，例如由某些提供商作为服务提供，那么您甚至可以保持数百万个活动连接。
顺便说一句，我认为 Mosquitto 或任何其他本地安装是开发和测试的完美选择，但是当您投入生产时，您需要具有 HA、冗余、故障转移等所有功能的 SaaS MQTT 代理。