Protocol Category | Protocol | Description | Scenario |
Layer-4 protocol | TCP | A connection-oriented and reliable transport layer protocol. The source and destination of the transmission need to perform a three-way handshake to establish a connection before data transmission. It supports session persistence based on the client IP address (the source IP address). It allows you to obtain the client source IP address. | It is suitable for scenarios that require high reliability and data accuracy but have lower requirements for transmission speed, such as file transfer, email sending and receiving, and remote login. For details, see Configuring TCP and UDP Listeners. |
| UDP | A connectionless transport layer protocol. The source and destination of the transmission do not establish a connection and do not need to maintain the connection status. Each UDP connection can only be point-to-point. It supports one-to-one, one-to-many, many-to-one and many-to-many interactive communications. It supports session persistence based on the client IP address (the source IP address). | It is suitable for scenarios that require high transmission efficiency but have relatively lower requirements for accuracy, such as instant messaging and online video. For details, see Configuring TCP and UDP Listeners. |
Layer-7 protocol | HTTP | An application layer protocol. It supports forwarding based on the request domain name and URL. | Applications that need to identify the content of requests, such as Web applications, App services. |
| HTTPS | An encrypted application layer protocol. It supports forwarding based on the request domain name and URL. With the unified certificate management service, you can upload and replace a certificate in the GA2.0 console. It supports one-way authentication and mutual authentication. | HTTP applications that require encrypted transmission. |
Port Type | Description | Limit |
Listening port (frontend port) | The listening port is the port through which GA2.0 receives requests and forwards them to endpoints. The configurable port range is 1–65499. | For one GA2.0 instance: A listening port of the UDP protocol category can be duplicated with a listening port of the TCP protocol category. For example, you can create the listener TCP: 80 and the listener UDP: 80 at the same time. Listening ports of the same protocol category cannot be duplicated. TCP/TCP SSL/HTTP/HTTPS are all in the TCP category. For example, you are not allowed to create the listener TCP: 80 and the listener HTTP: 80 at the same time. |
Endpoint port (backend port) | The endpoint port can be configured for a layer-7 listener. It is the port through which the real server provides services, and it receives and handles traffic from GA2.0. The configurable endpoint port range is 1–65499. | For one GA2.0 instance: Service ports of different listening protocols can be duplicated. For example, the listener HTTP: 80 and the listener HTTPS: 443 can be bound to the same port of a real server at the same time. |
Health check port | The health check port is used by GA2.0 to send probe requests to real servers to confirm whether the servers are running normally. If the port responds normally, the servers are considered healthy. The configurable endpoint port range is 1–65499. | - |
Configuration Type | Configuration Item | Description |
Basic Configuration | Listener Name | It starts with an uppercase or lowercase letter. It supports 2 to 128 characters in length. It supports digits, periods (.), hyphens (-), and underscores (_). |
| Routing Type | Currently, intelligent routing is supported. GA2.0 selects the nearest endpoint group based on latency for forwarding. |
| Protocol | You can select TCP, UDP, HTTP, and HTTPS. HTTP: An application layer protocol, with plaintext transmission and no encryption. It is suitable for non-sensitive information transmission scenarios, such as ordinary web page browsing and data scraping. HTTPS: With HTTP+SSL/TLS encryption, it provides data encryption and identity authentication. It is suitable for scenarios that require secure transmission, such as online payment and login authentication. |
| Port | The supported port range is 1–65499. |
| SSL Parsing Method | Authentication methods for HTTPS listeners and clients. One-way authentication: The client verifies the server's identity, but the server does not verify the client's identity. If you select this authentication method, you only need to upload the server certificate to GA2.0. Mutual authentication: The client and server verify each other's identities, and the client needs to provide a certificate for the server to verify. If you select this authentication method, you need to upload both the server certificate and the certificate authority (CA) certificate to GA2.0. |
| Server Certificate | A digital certificate issued by a CA to a website. It is used to verify the server's identity and establish an encrypted connection. After you select one-way authentication and complete the upload, GA2.0 returns this certificate to the client for establishing an encrypted connection. |
| Client CA Certificate | A certificate held by a root CA or an intermediate CA. It is used to issue and verify the legitimacy of the server certificate. After you upload the certificate, GA2.0 uses it to verify the legitimacy of the client. Note: You only need to upload the client CA certificate when you select mutual authentication as the authentication mode. |
| TLS Security Policy Group | When creating an HTTPS listener, you can select different TLS security policy groups (tls_policy_1.0-2, tls_policy_1.1-2, tls_policy_1.2, tls_policy_1.2_strict,tls_policy_1.2_strict-1.3) as needed. Different policy groups contain different TLS versions and encryption algorithm suites. For details, see TLS Security Policy Groups. |
Advanced Configuration | Obtain Client Source IP | After it is enabled, the X-Forwarded-For, X-Forwarded-lP, X-Forwarded-Proto, and X-Real-IP fields are carried by default. |
| Idle Connection Timeout Period | Specify the idle connection timeout period. If no data interaction occurs during the timeout period, GA2.0 terminates the current connection and establish a new connection when the next request arrives. Default value: 15 (in seconds). Configurable range: 1–60 (in seconds). |
| Connection Request Timeout Period | Specify the connection request timeout period. It is the maximum waiting time required for a client to establish a connection with a server. If no connection is established after the timeout period ends, the connection request is considered timed out. Default value: 60 (in seconds). Configurable range: 1–180 (in seconds). |
Configuration Type | Configuration Item | Description |
Endpoint Group | Endpoint Group Name | It starts with an uppercase or lowercase letter. It supports 2 to 128 characters in length. It supports digits, periods (.), hyphens (-), and underscores (_). |
| Region | The region of the endpoint group. GA2.0 forwards traffic from the acceleration region to the region of the endpoint group. Attention: If the acceleration region and the region of the endpoint group are the same, it might cause poor acceleration. |
| Backend Service Type | The endpoint, which functions as the backend origin server and eventually provides services. The endpoint type can be a custom domain name or a custom IP address. |
| Backend Service | The backend origin server that eventually provides services. You can add up to 4 endpoints to an endpoint group. You can enter custom IP addresses or custom domain names. Example: 117.89.1.1example.com |
| Weight | The endpoint weight. The value range of the weight is 1–100. GA2.0 distributes business traffic to real servers based on the endpoint weight you configure. |
| Origin-Pull Protocol | The protocol used when GA2.0 performs origin-pull to an endpoint. HTTP as the listening protocol: Only HTTP can be selected as the origin-pull protocol. HTTPS as the listening protocol: HTTP or HTTPS can be selected as the origin-pull protocol. |
| Port Mapping | You can configure the mapping relationship between the listening port and the backend service port. Based on the configuration, GA2.0 forwards data packets to the port corresponding to the endpoint. Listening port: It cannot be modified. It is consistent with the listener port. Endpoint port: The configurable range is 1–65499. |
| Health Check | Enabled: GA2.0 checks the availability of the backend origin server based on the configured health check parameters. Disabled: GA2.0 does not perform health check probes on the origin server. |
| Protocol Check | The network protocol used by GA2.0 to check whether the real server is available. For HTTP and HTTPS listeners, only the HTTP protocol can be used for health checks. |
| Response Timeout Period | The maximum time that GA2.0 waits for the server to respond after sending a health check request to the real server. If no response is received after the timeout period ends, this check is determined as failed. Default value: 2 (in seconds). Configurable range: 2–60 (in seconds). |
| Health Check Interval | The time interval between two health checks. Default value: 30 (in seconds). Configurable range: 5–300 (in seconds). |
| Unhealthy Threshold | After the number of consecutive health check failures reaches the threshold, the real server is marked as unhealthy and removed from the traffic distribution pool. Default value: 3 (in counts). Configurable range: 1–10 (in counts). |
| Healthy Threshold | After the number of consecutive health check successes reaches the threshold, an unhealthy server is re-marked as healthy and its traffic distribution is restored. Default value: 3 (in counts). Configurable range: 1–10 (in counts). |
| Check Domain Name | The domain name of the request during a health check. |
| Check Path | Specify the URL path for health checks (for example, /checkHealth). GA2.0 sends an HTTP request to this path and determine whether the service is healthy based on the returned status code. |
| Request Method | It can be the HEAD method or the GET method: HEAD: Only request the response header. It is lightweight and efficient. GET: Obtain the full response. It is suitable for scenarios where content integrity needs to be checked. |
| Status Code for Monitoring | Health checks access the specified path (for example, /health) through HEAD or GET requests. If the returned status code is within the preset range and no timeout error occurs, the service is marked as healthy. Otherwise, the isolation mechanism is triggered. You can configure the following status codes for monitoring: http_2xx, http_3xx, http_4xx, and http_5xx |
Was this page helpful?
You can also Contact sales or Submit a Ticket for help.
Help us improve! Rate your documentation experience in 5 mins.
Feedback