What Is MQTT?
MQTT is a lightweight publish/subscribe protocol designed to minimize network bandwidth and device resource requirements. MQTT is commonly used in scenarios such as automotive, logistics, smart home, consumer electronics, and transportation. For more scenarios, see Use Cases. The OASIS organization provides three standard protocol specifications: v3.1, v3.1.1, and v5. Differences Between TDMQ for MQTT and Official OASIS standard for MQTT
TDMQ for MQTT is developed based on MQTT v3.1.1 and MQTT v5, but some features are not yet supported:
1. TDMQ for MQTT supports QoS Publish and Subscribe, but cannot guarantee Exactly Once semantics in extreme scenarios.
2. TDMQ for MQTT does not support AUTH control messages temporarily.
Which Regions Are Available for TDMQ for MQTT?
TDMQ for MQTT is currently available in regions such as Beijing, Shanghai, Guangzhou, Nanjing, Singapore, Frankfurt, Silicon Valley, Chengdu, Hong Kong (China), Tokyo, and the Shanghai Autonomous Driving Zone. Services will be launched in more regions in the future.
How Is TDMQ for MQTT Billed?
Go to the Purchase page from the console, then select the corresponding specification based on your actual business volume level. MQTT supports two billing modes: pay-as-you-go by hour and prepaid yearly/monthly subscription. How to Calculate the TPS Specification of TDMQ for MQTT?
When the MQTT protocol is used to send and receive messages, the sending or receiving action for each message is counted as one basic billing unit. The TPS specification is comprehensively calculated based on the sum of three dimensions: message service QoS, message storage resource usage, and message body size.
Message service QoS
Message service QoS=0 is calculated as 1 TPS.
Message service QoS=1 is calculated as 2 TPS.
Message service QoS=2 is calculated as 5 TPS.
Storage resource usage
When messages use the Will and Retain features, additional Broker storage resources are consumed. Therefore, when users configure and use the Will and Retain features, an additional 10 TPS is calculated for each feature.
Message body size
Each message is calculated in units of 4 KB. If the size is less than 4 KB, no additional TPS is calculated. For every additional 4 KB exceeded, an additional 1 TPS is calculated.
For example, a cluster has 3 clients connected at the same time. The cluster sends a QoS=1 message to the first client with a message body size of 64 KB. The corresponding cluster production TPS specification is calculated as 2+⌈64/4-1⌉=17 TPS. The cluster receives a QoS=2 message with the Retain feature enabled from the second client with a message body size of 32 KB. The corresponding cluster message TPS specification is calculated as 5+10+⌈32/4-1⌉=22 TPS. The third client connects to the cluster and enables the Will feature, with an additional 10 TPS calculated. At this point, the comprehensive cluster TPS specification is calculated as 17+22+10=49 TPS.
Usage Limitations of TDMQ for MQTT
TDMQ for MQTT is sold in different specifications, with each cluster specification supporting different TPS levels and client connection limits. For detailed quota limitations, see Product Constraints and Usage Quotas. Whether TDMQ for MQTT Supports Public Network Access?
Support. When purchasing a TDMQ for MQTT cluster, you can enable public network access. After purchasing the cluster, you can enable or disable public network connection at any time.
Which TLS Versions Are supported?
TDMQ supports SSLv1, TLSv1.1, TLSv1.2, and TLSv1.3. For Chinese cryptography, TLCPv1.1 is supported. For SSLv3, you can submit a ticket for specific consultation. Supported Authentication and Authorization Modes for Sending/Receiving Messages Using TDMQ for MQTT?
Authentication and authorization using the username and password: TDMQ for MQTT validates the username and password of the role used by the connected client. Different roles have different permissions (such as sending or consuming messages), which you can freely and flexibly define.
X.509 certificate authentication: Enable server-side authentication using the default certificate. You can also use your own certificate for mutual authentication between the client and server.
Custom JWT authentication and authorization: Supports the use of customers' own JWT services for authentication and authorization.
External HTTP authentication and authorization: Supports client authentication and authorization by integrating with external third parties or HTTP services within the user's VPC.
In the future, TDMQ for MQTT will also introduce more diverse authentication and authorization methods based on customer needs. For detailed information about authentication, see Configuring Authentication. Is One-Vehicle-One-Certificate Typically Used in IoV Scenarios Supported?
The TDMQ-MQTT product supports the one-device-one-certificate authentication method and can reuse users' PKI infrastructure. The product also supports activating, deactivating, and revoking device certificates through TencentCloud API to achieve the goals specified by the OCSP protocol. Low-Computing-Power Scenarios Cannot Use "One-Device-One-Certificate". Does It Support Independent Authentication and Authorization for Each Device?
The TDMQ-MQTT product supports the one-device-one-secret authentication method. Users can register each low-computing-power device in the cloud through Shared Access Token, and authenticate by issuing tokens with pre-shared keys. Users can also integrate existing methods such as JWT and HTTP Service to implement independent authentication and authorization per device. Is Global Acceleration (CDN) Supported for Multi-Region Client Access Scenarios?
The Content Delivery Network (CDN) publishes site content to a vast number of acceleration nodes distributed globally, allowing users to obtain the content they need from nearby nodes. CDN accelerates "content delivery" and is not suitable for MQTT application scenarios. If your devices are distributed with clear geographical attributes, we recommend deploying multiple MQTT instances in nearby regions, which is superior in terms of disaster recovery, reliability, and cost.
If you have similar global acceleration requirements, you can evaluate the following two approaches based on your business scenario: the network layer IP address solution AIA (a single global Anycast IP address that allows devices to access the nearest PoP and directly connect to the Tencent Cloud private network) or the application layer forwarding solution GAAP (an L4/L7 proxy forwarding network with 50+ global nodes for dedicated line origin-pull).