Edge Acceleration

Site Acceleration
- Overview
- Access Control
  - Token Authentication
- File Optimization
  - Smart Compression
- Network Optimization
  - HTTP/2
  - HTTP/3(QUIC)
    - Overview
    - Enable HTTP/3
    - QUIC SDK
      - SDK Overview
      - SDK Download and Integration
      - Sample Code
        Android
        iOS
      - API Documentation
        Android
        iOS
  - IPv6 Access
  - Maximum Upload Size
  - WebSocket
  - Client IP Geolocation Header
  - Client IP Geographical Location
  - gRPC
- URL Rewrite
  - Access URL Redirection
  - Origin-Pull URL Rewrite
- Modifying Header
  - Modifying HTTP Response Headers
  - Modifying HTTP Request Headers
- Custom Error Page
- Request and Response Actions
  - Processing order
  - Default HTTP Headers of Origin-Pull Requests
  - Default HTTP Response Headers
Smart Acceleration
L4 Proxy
- Overview
- Creating an L4 Proxy Instance
- Modifying an L4 Proxy Instance
- Disabling or Deleting an L4 Proxy Instance
- Batch Configuring Forwarding Rules
- Obtaining Real Client IPs
  - Obtaining Real TCP Client IPs via TOA
  - Obtaining Real Client IPs Through Protocol V1/V2
    - Overview
    - Method 1: Obtaining Real Client IPs Through Nginx
    - Method 2: Parsing Real Client IPs on Application Server
    - Format of Real Client IPs Obtained Through Proxy Protocol V1/V2
  - Transmitting Client Real IP via SPP Protocol
Edge DNS
- Hosting DNS Records
  - Modifying DNS Servers
  - Configuring DNS Records
  - Advanced DNS Configuration
- Domain Connection
  - Adding A Domain Name for Acceleration
  - Ownership Verification
  - Modifying CNAME Records
- Domain alias
  - Overview
  - Configuration Guide
  - Batch Connecting SaaS Domain Names
  - Configuring Alias Domain Names for Disaster Recovery
- Traffic Scheduling
  - Traffic Scheduling Management
- Origin Configuration
  - Load Balancing
    - Overview
    - Quickly Create Load Balancers
    - Health Check Policies
    - Viewing the Health Status of Origin Server
    - Related References
      - Load Balancing-Related Concepts
      - Introduction to Request Retry Strategy
  - Origin Group Configuration
  - Origin-pull configuration
    - Configuring Origin-Pull HTTPS
    - Host Header Rewrite
    - Controlling Origin-pull Requests
    - Redirect Following During Origin-Pull
    - HTTP/2 Origin-Pull
    - Range GETs
  - Related References
    - ld Version Origin Group Compatible Related Issues
    - VOD Origin Server Details
  - Collect EdgeOne origin-pull node IP
Edge Cache
- Overview
- EdgeOne Cache Rules
  - Content Cache Rules
  - Cache Key Introduction
  - Vary Feature
- Cache Configuration
  - Custom Cache Key
  - Node Cache TTL
  - Status Code Cache TTL
  - Browser Cache TTL
  - Offline Caching
  - Cache Prefresh
- Clear and Preheat Cach
  - Cache Purge
  - URL Pre-Warming
- How to improve the Cache Hit Rate of EdgeOne
Rules Engine
- Overview
- Supported Matching Types and Actions
- Rule Management
- variables
Image Processing

Introduction to Request Retry Strategy

 Load Balancing is capable of redirecting a request to an alternative origin for retrial when a request to an initially designated server fails, in accordance with the retry policy. This reduces business request failures caused by network issues or origin fails.
Note:
EdgeOne Load Balancing feature is in beta testing. If you want to use it, you can Contact Us.
Actual business requests may fail due to the following reasons:
1. Origin Failure and Have Not Actively Probe to Disable: After health check policies are configured, active probe is conducted periodically. Traffic is directed based on the results of the previous probe until new results are available. If an origin becomes unhealthy between two probes, business traffic might still be directed to the unhealthy origin. This leads to business request failure.
﻿
2. Network Jitter: The origin is healthy, but network issues occur during the access. This leads to business request failure.
Note:
Request failures include origin connection establishment failures and origin response reception failures.
﻿
For the situations mentioned above, EdgeOne provides the following two fallback request retry policies:
Policy 1: When a real business request fails to access a certain origin, it directly retries with another origin within the next lower priority origin group. This is suitable for scenarios where the performance of both higher and lower priority origin groups is similar.
Policy 2: When a real business request fails to access a certain origin, it directly retries with another origin within the same priority origin group. This is suitable for scenarios where the performance of the higher priority origin group is significantly better than that of the lower priority origin group.
﻿
﻿