常规开发问题
支持哪些协议连接？
EMQX Platform 部署目前支持 MQTT over TLS/SSL, WebSockets over TLS/SSL 协议连接。
如需其他协议支持，您可以提工单或发送邮件(cloud-support@emqx.io)与我们取得联系。
如何绑定域名？
在 EMQX Platform 建立专有版部署后，您会获得一个 MQTT 连接地址，该地址在专有版部署里以域名形式显示。您或许已经拥有自己的域名，希望可以将部署地址绑定到自己拥有的域名，通过您的域名使用 MQTT 服务。
操作步骤
这里假设您有顶级域名 abc.com， 希望以 mqtt.abc.com 访问 mqtt 服务，您在 EMQX Platform 上的部署的连接地址为 xxx.ala.dedicated.aliyun.emqxcloud.cn。
那么只需要在您的域名提供商的操作面板上，将 mqtt.abc.com 的 CNAME 记录指向 xxx.ala.dedicated.aliyun.emqxcloud.cn 即可。
等待 DNS 解析生效后，您便可通过 mqtt.abc.com 连接 mqtt 服务。
TIP
Serverless 版不支持使用 CNAME 绑定自定义域名。建议使用 EMQX Platform 提供的默认域名连接地址，以确保正确分配和管理连接。
如何设置 NAT 网关？
仅支持专有版/旗舰版，可以在创建好的部署中开通 NAT 网关。
建了 VPC 对等连接，自己的服务如何通过内网去连接 MQTT 服务？
专有版/旗舰版部署在创建内部接入点后可以通过内网连接地址进行连接。
是否支持 API 调用？
支持。我们提供了 HTTP API 以实现与外部系统的集成，例如查询客户端信息、发布消息和创建规则等。
更多关于 API 的使用方法，可以前往指南 —— REST API。
支持什么样的 TLS/SSL 认证？
如何与自己现有的系统对接？
可以使用数据集成与您现有资源做对接，详情查看数据集成。
设备的认证信息存储在自己的数据库中，是否支持通过我自己的数据库做 MQTT 连接的认证？
EMQX Platform 专有版/旗舰版支持从用户自己的数据库中获取到认证信息，请查看文档扩展认证。
控制台的设备日志可以保存多久？
EMQX Platform 不会保存设备通讯日志，只会保存部署日志，部署日志默认保存 7 天。
设备事件可以保存多久？
设备事件数据可以永久存储以转发到第三方服务。
如何订阅设备上线下线消息？
通过数据集成中的事件订阅。设备上线、设备下线的事件可以通过数据集成中的事件订阅来获取。如果标准版的用户，可以将事件数据通过 Webhook 转发到自己的 Web 服务，也可以将上线下线事件消息转发到消息队列或者数据库中。
除了设备的上下线事件，还可以订阅消息投递、确认、丢弃，以及设备订阅、取消订阅的事件。
单条消息的大小有什么限制？是否可以增加上限？
目前单条消息最大为 1MB，如果您需要增加上限，可以通过工单联系技术支持由我们协助修改配置。需要注意的是修改之后，会对部署所支持的最大 TPS 有所影响，以及部署相对应的 SLA的等级也会收到影响。具体会在工单中进行告知。
是否可以使用离线消息？
一般情况下 MQTT 客户端仅在连接到消息服务器的时候，如果客户端离线将收不到消息。但是在客户端有固定的 ClientID，clean_session 为 false，且 QoS 设置满足服务器端的配置要求时，在客户端离线时，服务器可以为客户端保持一定量的离线消息，并在客户端再次连接时发送给客户端。
离线消息在网络连接不是很稳定时，或者对 QoS 有一定要求时非常有用。
离线消息暂存多长时间？
对于 MQTT v3 的协议默认配置为 2 小时，对于 MQTT v5 的协议，根据客户端中 session_expiry_interval的值设定。过期之后队列中的消息会丢失。
如何进行离线消息的存储？
鉴于消息暂存的不稳定性，我们推荐将离线消息进行存储。我们推荐将离线消息进行落盘存储。这里我们需要使用到专业版的数据集成服务，可以将离线消息保存到像 Redis 这样的数据库中。设备上线消费了消息之后，对应的离线消息也会被删除。
如何计算连接数？
连接数的定义为：在线的客户端和保留会话的离线客户端数量之和。在线客户端是指 CONNECT 之后连接到服务器的客户端，包括 keepAlive 时间范围内没有断开的客户端。 保留会话的离线客户是指客户端虽然离线了，但是设置了 CleanSession 为 false，这样的客户端也会被计算在连接数之内。当设备 DISCONNECT 下线，或者超过了 keep alive 的时间，没有通信，设备都会下线，不会计算在连接数当中。
TPS 是如何计算的？
TPS - Transaction Per Second， 用来计量部署每秒钟处理的消息的数量。以下的 MQTT 消息和 HTTP 消息会计入 TPS 中。
| 消息类型 | 消息流向 | 描述 |
|---|---|---|
| MQTT PUBLISH | 从设备或服务发送 | 从设备或应用服务发送消息到部署，部署接收到消息 |
| MQTT PUBLISH | 从部署发送 | 从部署发送消息到订阅端（设备或应用服务），订阅端接收到消息 |
| MQTT RETAINED | 从设备或服务发送或从部署发送 | 保留消息的发布和接收 |
| HTTP PUBLISH | 从服务发送 | 通过 POST /mqtt/publish 以及 POST /mqtt/publish_batch API 发送的消息 |
以下的 MQTT 消息不会计入 TPS 中
| 消息类型 | 描述 |
|---|---|
| MQTT CONNECT | 连接服务端 |
| MQTT CONNACK | 确认连接请求 |
| MQTT PUBACK | 发布确认 |
| MQTT PUBREC | 发布收到（QoS2，第一步） |
| MQTT PUBREL | 发布释放（QoS2，第二步） |
| MQTT PUBCOMP | 发布完成（QoS2，第三步） |
| MQTT SUBSCRIBE | 订阅主题 |
| MQTT SUBACK | 订阅确认 |
| MQTT UNSUBSCRIBE | 取消订阅 |
| MQTT UNSUBACK | 取消订阅确认 |
| MQTT PINGREQ | 心跳请求 |
| MQTT PINGRESP | 心跳响应 |
| MQTT DISCONNECT | 断开连接 |
流量统计为何会存在差异？
部署的流量统计和指标中报文流量的计算总和如果存在差异，主要是因为指标中的报文流量只会统计 MQTT 协议（包含 mqtt、ws）应用层的客户端消息发布、连接、订阅流量，不会统计数据集成产生的流量以及 TLS 处理、TCP 层面等流量。而由于 TLS、数据集成产生的流量造成很大的差异。