TCP Listener Introduction
You can add a TCP listener on the CLB instance to forward TCP protocol requests from the client's end. The TCP protocol is suitable for scenes that have high requirements for reliability and data accuracy but low requirements for transmission speed, such as file transfer, email sending and receiving, remote login, etc. For the listener of TCP protocol, its backend server can directly obtain the real IP of the client.
Configuring TCP Listener
Step 1: Open the Listener Management page
- Log in to the CLB console.
- In the left sidebar, select LB Instance List.
- On the CLB Instance List page, click the instance ID that needs to be configured to enter the Instance Details page.
- Click Listener Management to go to the page.
Step 2: Configure the listener
Under TCP/UDP Listeners, click Create, and configure a TCP listener in the dialog box.
1. Basic Configuration
| Basic Configuration of Listener | Description | Example |
|---|---|---|
| Name | The Name of the Listener | test-tcp-80 |
| Listen Protocol Port | The Listener's Protocol and Listening Port - Listening protocol: The protocols supported by CLB under this listener include TCP and UDP. In this example, TCP is selected. - Listening port: The port is used to receive requests and forward them to the backend server. The port range is 1-65535. - The listening ports in the same CLB instance cannot be repeated. |
TCP:80 |
| Balance Mode | In the TCP listener, the CLB supports two scheduling algorithms: Weighted Round-Robin (WRR) and Weighted Least Connections (WLC). - Polling by Weight: Distribute requests to different servers in turn according to the weight of the backend servers. The weighted round-robin algorithm is based on the number of newly created connections to schedule. The servers with a higher weight are more often (probably) to be polled, and servers with the same weight handle the same number of connections. - Min. Weighted Connections: The server load is estimated based on the number of active connections currently on the server. For the weighted least connections algorithm, comprehensive scheduling is realized based on the server load and weight. When the weight values are the same, the backend server with fewer current connections will be selected more often (has a higher probability of being selected) in the round-robin scheduling. |
Polling by Weight. |
The basic configuration of creating a TCP listener is shown in the figure below.
2. Health Check
| Health Check Configuration | Description | Example |
|---|---|---|
| Health Check Status | Enable or disable health check. In the TCP listener, the CLB instance sends SYN packets to the specified server port to perform a health check. | Enable |
| Check Protocol | Selecting TCP indicates the configuration of a TCP health check. | TCP |
| Check port | Port number is not required. If it is not filled in, the backend server port will be used by default. It is recommended not to fill in the port number unless a specific port needs to be specified. | |
| Response Timeout | - The maximum timeout for health check responses. - If the backend CVM does not respond correctly within the timeout period, it is considered a health check exception. - Configurable range: 2 - 60 seconds. The default value is 2 seconds. |
2s |
| Detection Interval | - Interval between CLB health checks. - Configurable range: 5-300 seconds, default value is 5 seconds. |
5s |
| Unhealthy Threshold | - If the health check results received for n consecutive times (n is the filled value) are failed, it is identified as unhealthy, and the console displays as Abnormal. - Configurable range: 2-10 times, default value is 3 times. |
3 times |
| Health Threshold | - If the health check results received for n consecutive times (n is the filled value) are successful, it is identified as healthy, and the console displays as Healthy. - Configurable range: 2-10 times, default value is 3 times. |
3 times |
The specific configuration of the health check is shown in the following figure:
3. Session Persistence
| Session Persistence Configuration | Description | Example |
|---|---|---|
| Session Affinity Status | Enable or disable session persistence. - After session persistence is enabled, the CLB listener will distribute access requests from the same client to the same backend server. - The TCP protocol is session persistence based on the client IP address, that is, access requests from the same IP address are forwarded to the same backend server. - WRR scheduling supports session persistence, but WLC scheduling does not support enabling the session persistence feature. |
Enable |
| Session Held Time | Session Held Time - When the hold time is exceeded and there is no new request in the connection, the session will be automatically disconnected. - Configurable range 30-3,600 seconds. |
30s |
The specific configuration of session persistence is shown in the following figure.
Step 3: Bind the backend CVM
- On the Listener Management page, click the successfully created listener, such as the aforementioned
TCP:80listener, to view the bound backend service on the right side of the listener. - Click Bind, select the backend server to be bound in the pop-up, and configure the service port and weight.
- Add Port Features: In the "Selected" Cloud Virtual Machine box on the right, click Add Port to add multiple ports of the same Cloud Virtual Machine, such as adding ports 80, 81, and 82 of CVM at the same time.
- Default port feature: Fill in Default Port first, then select the CVM. The port of each CVM is the default port.
After completing Step 1 to Step 3, the TCP listener rules are configured.
Step 4: Modify/delete listeners (optional)
If you need to modify or delete a created listener, click the created listener on the Listener Management page, and then click the modify or delete icon to complete the operation.