Listener Overview

A listener checks requests from clients and routes requests to backend servers using the protocol, port, and load balancing algorithm you select. You need to add at least one listener to a load balancer.

Supported Protocols and Application Scenarios

ELB provides load balancing at both Layer 4 and Layer 7.

You can select TCP, TLS, or UDP for network load balancing and HTTP, QUIC, or HTTPS for application load balancing.

**Table 1** Protocols supported by ELB
Type	Protocol	Description	Application Scenario
Network listeners	TCP	Source IP address–based sticky sessions Fast data transfer	Scenarios that require high reliability and data accuracy, such as file transfer, email, and remote login Web applications that do not need to handle a large number of concurrent requests and do not require high performance
Network listeners	UDP	Relatively low reliability Fast data transfer	Scenarios that require quick response, such as video chat, gaming, and real-time financial news
Network listeners	TLS	An extension of HTTP for encrypted data transmission that can prevent unauthorized access Unidirectional/Bidirectional authentication	Scenarios that require ultra-high performance and large-scale TLS offloading
Application listeners	HTTP	Cookie-based sticky sessions X-Forward-For request header	Applications that require content identification, for example, web applications and mobile games
Application listeners	HTTPS	An extension of HTTP for encrypted data transmission that can prevent unauthorized access Encryption and decryption performed on load balancers Multiple versions of encryption protocols and cipher suites	Workloads that require encrypted transmission, such as e-commerce and financial services
Application listeners	QUIC	UDP-based low-latency internet transport layer protocol Multiplexing without head-of-line blocking Improved congestion control	Applications with a poor network environment and whose users have to switch between networks

TLS and QUIC listeners can be created in certain regions. You can see which regions support TLS and QUIC listeners on the console.

Frontend Protocols and Ports

Frontend protocols and ports are used by load balancers to receive requests from clients.

Load balancers use TCP, TLS, or UDP for network load balancing, and HTTP, QUIC, or HTTPS for application load balancing. Select protocols and ports that best suit your requirements.

The frontend protocols and ports cannot be changed once a listener is added. If you want to use a different protocol and port, add another listener.

**Table 2** Frontend protocols and ports
Frontend Protocol	TCP, UDP, TLS, HTTP, QUIC, or HTTPS
Frontend Port	Listeners using different protocols of a load balancer cannot use the same port. However, UDP and QUIC listeners can use the same port as those using other protocols. For example, if there is a UDP listener that uses port 88, you can add a TCP listener that also uses port 88. But UDP and QUIC listeners cannot use the same port. The port ranges from 1 to 65535. Common ports: TCP/80 and HTTPS/443

Backend Protocols and Ports

Backend protocols and ports are used by backend servers to receive requests from load balancers. If Windows servers have Internet Information Services (IIS) installed, the default backend protocol and port are HTTP and 80.

**Table 3** Backend protocols and ports
Backend Protocol	TCP, UDP, TLS, HTTP, HTTPS, QUIC, GRPC
Backend Port	Backend servers of a load balancer can use the same port. The port ranges from 1 to 65535. Common ports: TCP/80, HTTP/80, and HTTPS/443

Forwarding by Port Ranges

Forwarding by Port Ranges is available only when you select TCP or UDP as the frontend protocol.

If this option is enabled, the listener checks requests from all ports in the port ranges you specify and routes them to the corresponding ports on the backend servers.

Timeout Durations

You can configure and modify timeout durations for your listeners to meet varied demands. For example, if the size of a request from an HTTP or HTTPS client is large, you can prolong the request timeout duration to ensure that the request can be successfully routed.

Figure 1 Timeout durations at Layer 4

Figure 2 Timeout durations at Layer 7

**Table 4** Timeout durations for Layer 4 listeners
Protocol	Type	Description	Value Range	Default Timeout Duration
TCP UDP TLS	Idle Timeout	Specifies the length of time for a connection to keep alive, in seconds. If no request is received within this period, the load balancer closes the connection and establishes a new one with the client when the next request arrives.	10–4000s	300s

**Table 5** Timeout durations for Layer 7 listeners
Protocol	Type	Description	Value Range	Default Timeout Duration
HTTP HTTPS QUIC	Idle Timeout	Specifies the length of time for a connection to keep alive, in seconds. If no request is received within this period, the load balancer closes the connection and establishes a new one with the client when the next request arrives.	0–4000s	60s
	Request Timeout	Specifies the length of time (in seconds) that a load balancer is willing to wait for a client request to finish. The load balancer terminates the connection if a request takes too long to complete.	1–300s	60s
	Response Timeout	Specifies the length of time (in seconds) after which the load balancer sends a 504 Gateway Timeout error to the client if the load balancer receives no response from the backend server after routing a request to the backend server and receives no response after attempting to route the same request to other backend servers. If sticky session is enabled and the load balancer receives no response from the backend server within the response timeout duration, the load balancer returns a 504 Gateway Timeout error to the client directly.	1–300s	60s