Product features

Enable public network access

BLB instances support enabling public network access:

• Intranet load balancer mode: Public network access is disabled by default, enabling private network traffic balancing through automatically assigned intranet IP addresses. This mode is ideal for internal system interactions such as API communications in microservice architectures or database cluster access scenarios.
• Public network access mode: Enables public network access to facilitate seamless purchase, binding, and security configuration of public IPs. By binding EIP resources, users can build a load balancer system for internet-facing applications. This mode is suitable for business scenarios requiring public network exposure, such as web portals, mobile app backends, and e-commerce platforms.

Forwarding rules

BLB supports three forwarding strategies: weighted round-robin, weighted least connections, and source IP-based forwarding.

• Weighted round-robin: Allocate traffic based on predefined server weight ratios, distributing incoming requests sequentially to real servers according to their weight values. This algorithm is ideal for scenarios with varying server hardware configurations, allowing optimized load distribution through weight settings.
• Weighted least connections: This scheduling algorithm combines predefined weights with real-time connection data to automatically direct new requests to the real server with the fewest active connections. It dynamically balances session load across nodes and is particularly suited for scenarios with a high number of long connections.
• Source IP: Utilize a consistent hashing algorithm to hash the client's source IP address, creating a fixed mapping to ensure requests from the same source IP are consistently directed to the designated real server. This approach effectively maintains session continuity and is ideal for applications requiring persistent client-server session states.

Type of listeners

BLB supports four types of listeners operating at both Layer 4 (TCP, UDP, SSL protocols) and Layer 7 (HTTP, HTTPS protocols). The BLB Layer 4/7 Load Balancer decides how to forward traffic based on Layer 4 or Layer 7 information when distributing loads across real servers.

A TCP listener monitors TCP connections sent to the service address and listener port. It selects a healthy real server according to forwarding rules for TCP connections and executes NAT processing for traffic. This setup establishes two TCP connections: one from the client to the listener and another from the listener to the real server. Subsequent traffic for this TCP connection is forwarded to the same real server.

An HTTP listener enhances application layer capabilities based on Layer 4 protocols, forwarding traffic at the HTTP request level. During this process, there are multiple TCP connections: one from the client to the listener and others from the listener to each healthy real server. This ensures each HTTP request is routed to the appropriate real server.

Get the visitor's real IP

• The TCP/UDP listener-type real server can directly retrieve the visitor's actual IP address without requiring additional configuration.
• The SSL listener currently does not support retrieving the actual IP address.

• The HTTP/HTTPS listener has the "Get Real IP" function enabled by default. With this feature, BLB adds an "X-Forwarded-For" field in the header of each request to indicate the real IP address.

  Note: If the http request sent by the client doesn't contain an request header: X-Forwarded-For, BLB will add a line of request header: X-Forwarded-For: client_ip; If the http request sent by the client already contains a request header: X-Forwarded-For, BLB will add client_ip at the end of the request header: X-Forwarded-For.

Session persistence

Baidu Load Balance (BLB) supports a session persistence mechanism that ensures user requests are consistently forwarded to the same real server instance. This functionality offers several implementation methods depending on the network protocol layer:

• For Layer 4 listeners (TCP, UDP, and SSL protocols), users can enable session persistence by configuring the listener's forwarding rules to use source IP forwarding, ensuring requests from the same client IP are always routed to the same real server.

• For Layer 7 listeners (HTTP and HTTPS protocols), users can achieve session persistence through two Cookie management methods:

  • Insert cookie (recommended method): Session persistence is achieved by adding a cookie entry to the user's request that identifies the real server address.
  • Rewrite cookie: Session persistence is achieved by detecting and overwriting a specified client cookie entry to identify the real server address.

Health check

BLB actively monitors the status of real servers, removing instances from the internal forwarding list when they are detected as malfunctioning. When the server resumes normal operation, BLB automatically reintegrates it into the forwarding list to continue providing services. The health check feature supports four probe protocols: TCP, HTTP, UDP, and ICMP.

• TCP/SSL listeners support health checks using the TCP protocol.

  • If the TCP protocol is used for health checks, a real server is considered normal if port access is functioning correctly; otherwise, it is deemed abnormal.

• UDP listeners support health checks using the UDP and ICMP protocols.

  • If the UDP protocol is selected for health checks, the instance sends specific characters to the real servers as configured. The real server is deemed normal if it receives the request and responds with a UDP packet; otherwise, it is considered abnormal.
  • If the ICMP protocol is used for health checks, the instance sends an ICMP message to the real servers as configured. A real server is considered normal if the cloud server is functional and the network is accessible; otherwise, it is marked as abnormal.

• HTTP/HTTPS listeners support health checks using both HTTP and TCP protocols.

  • When the health check protocol is set to HTTP, the instance sends HTTP GET requests to the real servers based on the configuration. A real server is deemed normal if it returns a 2xx or 3xx status code; otherwise, it is considered abnormal.
  • If the TCP protocol is used for health checks, a real server is considered normal if port access is functioning correctly; otherwise, it is deemed abnormal.

Note: You can set the normal status code of the HTTP health check. It is normal if 2xx and 3xx are returned by default.

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

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

Real-time data monitoring

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

• Instance monitor:

  • Active connections
  • Egress/ingress traffic
  • Count of egress/ingress packets
  • Egress/ingress bandwidth
  • New connection utilization
  • Concurrent connection utilization
  • Utilization of egress/ingress traffic

• Port monitor

  • Health check
  • Network traffic
  • Network packet
  • Concurrent connections
  • New connections
  • Egress/ingress bandwidth
  • Count of ingress packets
  • Count of egress packets
  • Rate-limited traffic
  • Rate-limited data packets
  • Traffic dropped
  • Packets dropped
  • Dropped connections
  • Count of requests (available only for Layer 7 listeners)
  • Queries-per-second (available only for Layer 7 listeners)
  • Response time (available only for Layer 7 listeners)
  • Response status code (available only for Layer 7 listeners)
  • Response status ratio (available only for Layer 7 listeners)
  • Real server response status codes (available only for Layer 7 listeners)
  • Real server response time (available only for Layer 7 listeners)

Additionally, BLB provides SMS and email notification services to promptly alert users when the data deviates from the value they have set.