tencent cloud

Multiple Network Acceleration

    문서Multiple Network Acceleration

    Dynamic Acceleration Configuration Reference

    다운로드
    포커스 모드
    폰트 크기
    마지막 업데이트 시간: 2026-06-12 16:48:40

    I. Overview

    Dynamic acceleration refers to the SDK continuously monitoring network quality and automatically recommending enabling acceleration only when the network deteriorates, and recommending disabling it after the network recovers. This approach saves acceleration traffic costs while ensuring a good user experience. The core questions for dynamic acceleration are only two: when to enable it and when to disable it. This document aims to help you understand the policy configuration logic for dynamic acceleration and the selection and adjustment of acceleration parameters in different scenarios.

    II. Core Concepts

    1. Three Key Dimensions

    Before configuring dynamic acceleration, you need to understand three dimensions that are independent of each other but have recommended pairing relationships:
    Dynamic acceleration is applicable to scenarios such as gaming, TRTC, and live streaming.
    You can select from the following modes: Multi-Send Single-Receive (Dual-Send), Real-Time (RTC), and Aggregation.
    Dynamic acceleration policies include the detection initiation policy, the fast start policy, the dynamic fallback-to-origin policy, and the recommended disable policy.

    2. Recommended Pairings of Scenarios and Modes

    The following are verified recommended pairings (not mandatory). Generally, using the recommended pairing yields the best results.
    Scenario
    Recommended Mode
    Reason
    Typical Customer
    Games (FPS/MOBA)
    Multi-Send and Selective Receive (Dual-Send)
    Small packet traffic, pursuing extremely low latency
    Mobile MOBA Games
    Real-time audio and video communication
    Real-time mode (RTC)
    Audio and video streams have high requirements for continuity.
    Audio Call
    Video Conference
    Live streaming
    Aggregation mode
    High bandwidth requirement, aggregating multiple channels
    Gaming
    Outdoor Live Streaming

    III. Policy Details

    The four policies cover the complete decision-making chain for dynamic acceleration, from enabling to disabling:
    Policy
    Problem to Solve
    Post-Trigger Action
    Network performance continues to degrade, requiring acceleration to be enabled.
    After the client is called back, the decision is made by the customer.
    Network performance deteriorates abruptly, requiring immediate acceleration.
    After the client is called back, the decision is made by the customer.
    The acceleration link performs worse than the direct connection.
    The SDK automatically falls back to a direct connection.
    Network recovers, and acceleration is no longer necessary.
    After the client is called back, the decision is made by the customer.
    Note:
    Policy configuration is independent of the mode. The difference between different scenarios and modes is mainly reflected in the recommended values for policy parameters, while the policy logic itself is universal.

    1. Probe Startup Policy

    The SDK continuously monitors network quality. When metrics consistently exceed thresholds over a period of time, it calls back to the client to recommend enabling acceleration. This is a progressive detection method, suitable for identifying trends of network deterioration. Decision logic: If, within the [Time Window], the average latency exceeds the threshold, or the jitter exceeds the threshold, or the packet loss rate exceeds the threshold (any one of the three conditions is met), a callback is triggered. In simple terms, if the latency is too high/the jitter is too large/packet loss is too severe over the past X seconds, enabling acceleration is recommended. The table below provides recommended parameter values.
    Parameter
    Meaning
    Gaming Scenarios
    Real-time audio and video communication
    Streaming Scenarios
    Time window
    Observation time window
    8s
    8s
    Enable at all times (no configuration required).
    Latency threshold
    Triggers when average latency exceeds this threshold.
    60ms
    80ms
    -
    Jitter threshold
    Triggers when latency jitter exceeds this threshold.
    15ms
    20ms
    -
    Packet loss threshold
    Triggers when packet loss rate exceeds this threshold.
    5%
    5%
    -
    Note:
    For gaming scenarios, thresholds are set lower because gaming is extremely sensitive to latency (lag can be perceived at 60ms), requiring earlier triggering. For live streaming scenarios, due to high and sustained bandwidth demands, it is recommended to enable acceleration at all times, eliminating the need for detection-based triggering.

    2. Quick Startup Policy

    Complementary to the detection initiation policy, the detection initiation policy is a trend judgment based on an 8-second window, while the fast start policy is an emergency judgment based on a 2-second window. When the network suddenly and severely deteriorates (such as entering an elevator and Wi-Fi disconnection), the fast start policy can trigger more quickly. Both policies are active simultaneously, and a callback is initiated if either one triggers. Decision logic: If, within the [Time Window], the latency exceeds the [Latency Threshold], a trigger is activated. Note that the fast start policy only monitors the latency metric (not jitter or packet loss), has a shorter window and a higher threshold, and is specifically designed to capture sudden deterioration. The table below provides recommended parameter values.
    Parameter
    Meaning
    Gaming Scenarios
    Real-time audio and video communication
    Streaming Scenarios
    Time window
    Detection window duration
    2s
    2s
    Enable at all times (recommended)
    Latency threshold
    Triggers when latency exceeds this threshold.
    80ms
    100ms
    -
    The comparison between the detection initiation policy and the fast start policy is as follows:
    Compare
    Probe Initiation
    Fast Startup
    Window / Metric
    8s / latency + jitter + packet loss
    2s / latency only
    Trigger Threshold
    Lower (sensitive)
    Higher (to prevent false triggers)
    Positioning
    Detect a continuously deteriorating trend.
    Detect sudden performance degradation events.

    3. Dynamic Fallback-to-Origin Policy

    Protection mechanism: After acceleration is enabled, if the acceleration link itself encounters severe issues (worse than a direct connection), the SDK automatically falls back traffic to the direct primary link to prevent acceleration from causing further lag. Difference from the recommended disable policy: Dynamic fallback-to-origin is a protection action automatically executed by the SDK (without waiting for customer decision), while recommended disable notifies the customer, who then makes the decision. The trigger conditions are as follows (if any one is met, automatic fallback-to-origin occurs).
    Condition
    Judgment Rule
    Plain Meaning
    Condition 1: Complete Disconnection
    Triggered when consecutive packet loss on the acceleration link reaches the [consecutive packet loss count] threshold, and the primary link is not simultaneously disconnected.
    The acceleration link is down, but the direct connection is still up. Fallback should be performed immediately.
    Condition 2: Extremely High Latency
    Triggered when the latency of [consecutive high-latency packet count] consecutive packets on the acceleration link is ≥ [single-packet latency upper limit] ms.
    The link is not down, but the latency is already too high to be acceptable.
    Condition 3: Persistently Worse Than Direct Connection
    Triggered when, within the [evaluation window], the average acceleration latency is greater than the primary link latency multiplied by [latency ratio threshold]%, and the average acceleration latency is greater than [minimum latency threshold] ms.
    Long-term observation shows that using the acceleration link is worse than using the direct connection, and the latency is indeed not low.
    Note:
    Why is a minimum latency threshold required in Condition Three? It is to avoid false positives. For example, if the primary link latency is 10ms and the accelerated link latency is 12ms, the 12ms latency exceeds 110% of the primary link. However, a 12ms latency itself is entirely acceptable and should not trigger a fallback-to-origin. Adding a minimum threshold (66ms) can filter out such cases.
    Recommended parameter values for each scenario are as follows.
    Condition
    Parameter
    Game (Multi-Send Selective-Receive)
    TRTC
    Condition 1
    Consecutive packet loss quantity
    4 packets
    4 packets
    Condition 2
    Consecutive high-latency packet quantity
    4 packets
    Disabled
    Maximum single-packet latency
    400ms
    -
    Condition 3
    Evaluation window duration
    60 seconds
    60 seconds
    Latency ratio threshold
    110%
    110%
    Minimum latency threshold
    66ms
    66ms
    Streaming/aggregation mode
    Enable only Condition 1 (number of consecutive packet losses = 4), and disable Condition 2 and Condition 3.
    Note:
    For real-time scenarios, Condition Two is not enabled because the RTC protocol has its own retransmission mechanism. For aggregation mode, latency-based conditions (Two and Three) are not enabled because aggregation inherently introduces higher latency.

    4. Recommended Disable Policy

    When acceleration is no longer necessary or physical conditions do not support it, the SDK calls back to the client to recommend disabling acceleration. The client can choose to accept or ignore the recommendation.
    The trigger conditions are as follows (if any one is met, a callback recommendation is issued).
    Condition
    Judgment Rule
    Plain Meaning
    Condition 1: Only One Network Interface Remaining.
    If only one network interface is available, it is recommended to disable the feature after [waiting duration] seconds have passed.
    Multipath transmission requires at least two network interfaces. Acceleration is meaningless when only one remains.
    Condition 2: No Network Available
    If no network interface is available, it is recommended to disable the feature immediately.
    Acceleration should be turned off when there is no network.
    Condition 3: Long-Term Poor Performance
    Triggered when, within the [quality evaluation window], the acceleration latency is greater than the primary link latency multiplied by [latency ratio threshold]%, and the jitter is greater than the primary link jitter multiplied by [jitter ratio threshold]%.
    Long-term acceleration performance is worse than that of the direct connection. Turning it off saves costs.
    Condition 4: All Secondary Links Down
    Triggered when all secondary links experience packet loss within [measurement window] seconds.
    All secondary network interfaces experience access timeout, making acceleration meaningless.
    Recommended parameter values for each scenario are as follows. (For live streaming/aggregation mode: Only enable Condition One (wait 10 seconds) and Condition Two (trigger immediately). Do not enable Condition Three or Four. For aggregation mode, it is not recommended to use latency-based conditions for disablement decisions.)
    Condition
    Parameter
    Game (Multi-Send Selective-Receive)
    TRTC
    Condition 1
    Wait duration
    10 seconds
    10 seconds
    Condition 2
    (Immediate trigger)
    -
    -
    Condition 3
    Quality evaluation window
    300 seconds
    300 seconds
    Latency ratio / Jitter ratio
    100% / 80%
    100% / 80%
    Condition 4
    Measurement window
    Disabled
    10 seconds

    IV. API Settings

    1. Probe Startup Policy

    The network measurement configuration object. By configuring this parameter, you can achieve dynamic acceleration performance.

    1.1 Android SDK

    API
    Description
    setRTT
    Set latency threshold
    setLoss
    Set packet loss rate threshold
    setJitter
    Set jitter threshold
    setTime
    Set sliding window measurement time
    setRTT
    Set the latency threshold. When the actual network latency of the terminal within the sliding window exceeds the set latency threshold, the onStartMpAcc API is called back.
    public MeasureConfig setRTT(int RTT)
    Parameter description:
    Parameter
    Type
    Description
    RTT
    int
    Latency threshold (ms)
    setLoss
    Set the packet loss rate threshold. When the actual network packet loss of the terminal within the sliding window exceeds the set packet loss threshold, the onStartMpAcc API is called back.
    public MeasureConfig setLoss(int loss)
    Parameter description:
    Parameter
    Type
    Description
    loss
    int
    Packet loss percentage threshold (0-100)
    setJitter
    Set the jitter threshold. When the actual network jitter of the terminal within the sliding window exceeds the set jitter threshold, the onStartMpAcc API is called back.
    public MeasureConfig setJitter(int jitter)
    Parameter description:
    Parameter
    Type
    Description
    jitter
    int
    Network jitter threshold (ms)
    setTime
    Set the sliding window measurement time.
    public MeasureConfig setTime(int time)
    Parameter description:
    Parameter
    Type
    Description
    time
    int
    Measurement duration, unit: ms

    1.2 iOS SDK

    Required
    Description
    time
    Sliding window measurement time, unit: ms
    rtt
    Latency threshold, unit: ms
    loss
    Packet loss percentage threshold (0-100)
    jitter
    Jitter threshold, unit: ms

    2. Quick Startup Policy

    Enable fast start by configuring the fast start window time and fast start latency threshold.

    2.1 Android SDK

    API
    Description
    setQuickTime
    Set quick start window time
    setQuickRtt
    Set quick start latency threshold
    setQuickRtt
    Set the fast start latency threshold. This interface is designed for scenarios with a sharp latency increase. When the actual network latency of the terminal within the fast start window exceeds the set fast start latency threshold, the onStartMpAcc API is called back.
    public MeasureConfig setQuickRtt(int quickRtt)
    Parameter description:
    Parameter
    Type
    Description
    quickRtt
    int
    Fast startup latency threshold, unit: ms
    setQuickTime
    Set the fast start window measurement time.
    public MeasureConfig setQuickTime(int quickTime)
    Parameter description:
    Parameter
    Type
    Description
    quickTime
    int
    Fast startup window time, unit: ms

    2.2 iOS SDK

    Required
    Description
    quickTime
    Fast startup window time, unit: ms
    quickRtt
    Fast startup latency threshold, unit: ms

    3. Dynamic Fallback-to-Origin Policy

    For the fallback-to-origin custom object, if the business does not set AdditionalOptions, the SDK adopts the default fallback logic (triggering onAccException). If the business has set AdditionalOptions, the SDK's fallback logic follows the business configuration.

    3.1 Android SDK

    API
    Description
    PacketLossEscape
    Triggered when the acceleration link is disconnected for [packetLossCount] consecutive times.
    MaxRttEscape
    Triggered when the ping value of the acceleration link is greater than or equal to [rttThreshold] ms for [maxRttCount] consecutive times.
    RttExceptionEscape
    Triggered when the average ping value of the acceleration link over [detectWindowTime] ms is greater than that of the primary link by [rttDiffThreshold]%, and the average latency of the acceleration link is greater than [accBenchmarkRtt] ms.
    StopAccRemind
    It is recommended to disable acceleration (which triggers onStopMpAcc) when the average latency of the acceleration link within [detectWindowTime] ms is greater than that of the primary link by [rttDiffThreshold]%, and the jitter is greater than that of the primary link by [jitterDiffThreshold]%.
    setAdditionalOptions
    Set custom options for fallback-to-origin escape.
    setAdditionalOptions
    Set the fallback-to-origin custom options.
    public MeasureConfig setAdditionalOptions(AdditionalOptions additionalOptions)

    3.2 iOS SDK

    Required
    Description
    packetLossEscape
    Triggered when the acceleration link is disconnected for [packetLossCount] consecutive times.
    maxRttEscape
    Triggered when the ping value of the acceleration link is greater than or equal to [rttThreshold] ms for [maxRttCount] consecutive times.
    rttExceptionEscape
    Triggered when the average ping value of the acceleration link over [detectWindowTime] ms is greater than that of the primary link by [rttDiffThreshold]%, and the average latency of the acceleration link is greater than [accBenchmarkRtt] ms.
    stopAccRemind
    It is recommended to disable acceleration (which triggers onStopMpAcc) when the average latency of the acceleration link within [detectWindowTime] ms is greater than that of the primary link by [rttDiffRate]%, and the jitter is greater than that of the primary link by [jitterRate]%.
    additionalOptions
    Set custom options for fallback-to-origin escape.

    4. Recommended Disable Policy

    This policy generally does not require configuration changes and uses the default value. If modifications are needed, make them in StopAccRemind.

    4.1 Android SDK

    API
    Description
    StopAccRemind
    It is recommended to disable acceleration (which triggers onStopMpAcc) when the average latency of the acceleration link within [detectWindowTime] ms is greater than that of the primary link by [rttDiffThreshold]%, and the jitter is greater than that of the primary link by [jitterDiffThreshold]%.
    setDisableSlaveLossDetect
    Disable packet loss detection on the secondary link.
    setDisableSlaveLossDetect
    Disable secondary path detection. For fast switching mode, it is not disabled by default. If 100% packet loss occurs on the secondary path latency within the measurement window, the onStopMpAcc API is called back to recommend disabling acceleration.
    public MeasureConfig setDisableSlaveLossDetect(boolean disableSlaveLossDetect)
    Parameter description:
    Parameter
    Type
    Description
    disableSlaveLossDetect
    boolean
    true: Disabled
    false: Not disabled

    4.2 iOS SDK

    Required
    Description
    stopAccRemind
    It is recommended to disable acceleration (which triggers onStopMpAcc) when the average latency of the acceleration link within [detectWindowTime] ms is greater than that of the primary link by [rttDiffRate]%, and the jitter is greater than that of the primary link by [jitterRate]%.
    disableSlaveLossDetect
    Disable packet loss detection on the secondary link.
    true: Disabled
    false: Not disabled

    V. Sample Code

    For details, see Dynamic Acceleration.
    

    도움말 및 지원

    문제 해결에 도움이 되었나요?

    피드백