Network Connection Instructions
Last updated:2026-01-20 16:52:40
TDMQ for CKafka (CKafka) supports both private and public network access, with connection requirements varying depending on the network type.
Connection Method Description
Connection Method | Connection Description | Reference Documentation |
Private network connection | If the client and the CKafka instance are deployed in the same Virtual Private Cloud (VPC) network, they are interconnected by default, and no additional configuration is required. | |
| If the client and the CKafka instance are deployed in different VPC networks, they cannot communicate with each other directly because different VPC networks are logically isolated. To enable VPC networks in different regions under the same account to communicate with each other, use Cloud Connect Network (CCN). | |
Public network connection | A dedicated public network route needs to be enabled, allowing clients to connect to the CKafka instance via the public network. Since public networks are accessible from any network environment, the access control list (ACL) policies shall be configured to manage user access permissions and ensure connection security. | |
Normally, it is recommended that you prioritize private network access to achieve lower network latency, higher transmission bandwidth, and better security isolation, especially for core businesses in production environments. Public network access can be enabled when your businesses need to provide services or conduct development and debugging through the public network. When the public network access is enabled, you shall configure ACL policies to control user access permissions and ensure data security.
Security Protocol Type Description
To ensure security, CKafka provides multiple security authentication mechanisms. Select an appropriate authentication method based on the security requirements for message transmission when adding network routing policies.
Basic Concepts
Simple Authentication and Security Layer (SASL): is a security protocol used for identity authentication, supporting two authentication mechanisms:
PLAIN mechanism: uses simple authentication where usernames and passwords are transmitted in plain text.
SCRAM mechanism: uses hash algorithms to securely authenticate usernames and passwords between the server and client. CKafka supports two SCRAM encryption algorithms with different security strengths: SCRAM-SHA-256 and SCRAM_SHA_512.
Secure Sockets Layer (SSL): is a security protocol for data transmission that uses encryption technology to prevent data from being stolen or tampered with during transmission, effectively enhancing communication security.
Protocol Comparison
Protocol Type | Protocol Description | Supported by the VPC Network or Not | Supported by the Public Network or Not |
PLAINTEXT | Authentication is not required for message sending and receiving, and data is transmitted in plaintext. | ✓ | × |
SASL_PLAINTEXT | SASL authentication is required for message sending and receiving, and data is transmitted in plaintext, showing higher performance. | ✓ | ✓ |
SASL_SSL | SASL authentication is required for message sending and receiving, and data is encrypted using SSL certificates for transmission to prevent interception or eavesdropping, showing higher security. | ✓ (Only supported by Pro Edition, and not supported by version 3.2.3 currently) | ✓ (Only supported by Pro Edition, and not supported by version 3.2.3 currently) |
SASL_SCRAM_SHA_256 | SASL authentication is required for message sending and receiving. Passwords are stored using a hash algorithm (SHA-256) and not transmitted in plaintext. Data is transmitted in plaintext. | ✓ (Only supported by instances of versions 1.1.1, 2.4.1, and 2.8.1. For existing instances, you need to upgrade the broker minor version or submit a ticket to apply for the upgrade.) | × |
SASL_SCRAM_SHA_512 | SASL authentication is required for message sending and receiving. Passwords are stored using a hash algorithm (SHA-512) and not transmitted in plaintext. Data is transmitted in plaintext. Compared to SHA-256, SHA-512 provides higher security but consumes more computing resources. | ✓ (Only supported by instances of versions 1.1.1, 2.4.1, and 2.8.1. For existing instances, you need to upgrade the broker minor version or submit a ticket to apply for the upgrade.) | × |
Security Group Requirements
Since ports may change after cluster configuration changes or migrations, if your server has access restrictions (security groups) configured, allow the following port range on the server to avoid read/write exceptions of messages after configuration changes or migrations.
Port range for VPC routes: 9092–60000.
Port range for public network routes: 50000–53000.
Port range for supporting routes: 6000–12000.
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No
Feedback