Enable Public Network Access

The BLB instance supports enabling/disabling public network access:

• If public network access is not enabled, the intranet IP will be provided by default to balance the intranet traffic;
• If public network access is enabled, it will purchase and bind the public network IP for you to achieve a balanced service for public network access traffic.

Forwarding Rules

BLB supports three forwarding rules: Weighted round-robin ,Source IP and least connection.

• Weighted round-robin mode: External requests are forwarded to the backend cloud server in sequence according to a weighted ratio.
• Least connection mode: Forward new requests to the cloud server with the least connection according to the current number of connections on the backend cloud server.
• Source IP: send the request to a matching server after hashing the requested source IP, which can ensure that requests from the same client IP are always dispatched to a specific server.

Listener Type

BLB supports four listener types: 4-layer (TCP ,SSL and UDP protocols) and 7-layer (HTTP and HTTPS protocols). BLB's 4/7-layer load balancing is to determine how to forward traffic based on the information about 4/7-layer when load balancing backend servers.

The TCP listener is responsible for listening to TCP connections sent to the service address and listening port. The listener selects a healthy backend server to establish a TCP connection according to the forwarding rules, and performs NAT processing on the traffic. During this process, there will be two TCP connections: one from the client to the listener and the other from the listener to the backend server. All subsequent traffic of the TCP connections will be forwarded to the same backend server.

The HTTP listener adds application layer features based on the 4-layer protocol and forwards HTTP requests as granularity. There will be multiple TCP connections during this process: one connection from the client to the listener and other connections from the listener to each healthy backend server. In this way, the HTTP listener ensures that each HTTP request can be forwarded to the corresponding backend server.

Get the Visitor's eal IP

• The TCP/UDP listener-type backend server can directly obtain the visitor's real IP and does not need to be set separately.
• The SSL listener does not currently support obtaining a real IP.

• The HTTP/HTTPS listener has the "Get Real IP" feature enabled by default. After the "Get Real IP" feature is enabled, BLB will insert an "X-Forwarded-For" field in the header of each request to identify the real IP address.

  Note: If the request header sent by the client to BLB already contains an HTTP Header: X-Forwarded-For, the current processing logic of BLB will add a new HTTP Header: X-Forwarded-For in the request header. Therefore, there will be two HTTP headers: X-Forwarded-For in the request header with the latter one being added by BLB.

keep Session

BLB supports keep session in which requests from the same user can be always forwarded to the same backend server instance.

• For 4-layer listeners (TCP and UDP protocols), users can achieve keep session by setting the listener's forwarding rules to be source IP forwarding rules (requests from the same client IP are always forwarded to the same backend server).

• For 7-layer listeners (HTTP and HTTPS protocols), BLB supports two keep session methods:

  • Insert cookie: Recommended, the load balancing service inserts a cookie entry identifying the backend server address in the user's request.
  • Rewrite cookie: The load balancing service overwrites the specified cookie entry to identify the backend server address.

Health Check

BLB actively checks the running status of the backend server and automatically discards the server when BLB detects that the backend server is working abnormally; when the abnormal server returns to normal, BLB automatically adds it to the load-balanced backend server list and continues to provide services. There are two methods to determine whether the backend server is healthy: TCP request check and HTTP request check.

• The TCP/SSL listener initiates a TCP request to the backend server port configured by the service listener . The backend server is considered normal if the port access is normal, otherwise it is considered abnormal.
• The UDP listener sends a UDP packet to the backend server port configured by the service listener. The backend server is considered normal if it receives the request and returns a UDP packet, otherwise it is considered abnormal.
• The HTTP/HTTPS listener initiates an HTTP GET request to the backend server port configured by the service listener. If it returns 2xx or 3xx, the backend cloud server is running normally, otherwise it is an abnormal.

Note: You can set the normal status code of the health check. By default, 2xx and 3xx are returned.

The recommended parameters for the health check provided by BLB are as follows:

• Response timeout time: 3s
• Health check interval: 3s
• Unhealthy threshold: 3 times
• Healthy threshold: 3 times

Real-time Data Monitoring

BLB provides you with real-time status information of load balancing instances and backend servers to help users understand the working status of the service, including:

• Number of normal instances
• Number of abnormal instances
• Incoming traffic
• Outgoing traffic
• Number of active connections
• Number of incoming packets
• Number of outgoing packets
• Number of requests (available only in 7-layer)

Moreover, BLB provides SMS and email alarm services to promptly remind the user if the data does not meet the user's set value.