Weak Network Optimization and Detection in Baidu App

The article introduces the three core problems of network optimization—security, speed, and weak network—focusing on the third, which is the most complex and requires repeated verification and analysis.

It outlines two key questions for weak‑network optimization: how to identify a weak‑network environment in mobile scenarios, and how to improve success rate and reduce latency under weak‑network conditions.

Metrics that affect network quality are listed, including httprtt, tcprtt, throughput, signal strength, and bandwidth‑delay product. Detailed explanations are provided:

httprtt (HTTP Round‑Trip Time) measures the time from the client’s first byte request to receiving the first byte of the HTTP header. A long httprtt may indicate client network quality issues or server latency.

tcprtt (TCP Round‑Trip Time) measures the time from the first byte sent on a TCP channel to the first byte received. Since HTTP runs over TCP, httprtt generally includes tcprtt.

throughput (吞吐量) quantifies the amount of data successfully transmitted per unit time. It is calculated as (bits_end − bits_start) / (time_end − time_start). When httprtt is low but the network feels slow, throughput helps assess quality.

signal strength refers to wireless signal strength, obtainable on Android via PhoneStateListener.onSignalStrengthsChanged (Android M+ only). No reliable iOS method is currently available.

bandwidth‑delay product (带宽时延乘积) is the product of throughput and RTT, expressed in bits. It reflects the maximum capacity of the network pipe and influences socket buffer sizes (SO_RCVBUF, SO_SNDBUF).

The article then describes how to establish weak‑network standards in three stages: offline testing (using tools like Network Link Conditioner and Facebook ATC), online verification (collecting weak‑network ratios for specific scenarios), and iterative online experiments (adjusting thresholds based on success rate, latency, and connection reuse).

Network detection is divided into active probing and passive collection.

Active probing triggers network checks based on conditions and includes a strategy layer, capability layer, and interface layer. The strategy layer defines thresholds for entering/exiting weak‑network states (e.g., weakhttprtt, goodhttprtt) with time‑interval safeguards. Once a weak state is detected, DNS queries and ping tests are performed.

The capability layer implements DNS query (to mbd.baidu.com ) and ping (two attempts, 1 s timeout each) using C++.

The interface layer reports four states: GOOD, BAD, UNKNOWN, and OFFLINE, with detailed criteria for each.

Passive collection records detailed request data (tcprtt, httprtt, throughput) via a customized Network Quality Estimator (NQE) built on Cronet. Data is gathered at socket connection, read/write completion, and request finish, then filtered by strategy rules before reporting.

Thresholds for classifying network quality are provided (e.g., GOOD: httprtt ≥ 273 ms, tcprtt ≥ 204 ms for 3G; BAD: httprtt ≥ 2.01 s for 2G, etc.).

To improve user experience under weak‑network conditions, the article discusses two best‑practice techniques:

QUIC is enabled for Baidu App requests in weak networks. The QUIC upgrade relies on HTTP Alternative Services (Alt‑Svc) headers such as Alt-Svc: quic="alt.example.com:443", quic=":443"; ma=2592000 or Alt-Svc: clear . An exponential back‑off mechanism controls retry intervals, up to two days.

QUIC pre‑connection is performed before entering a weak network to fetch the server config, increasing the chance of successful 0‑RTT connections.

Composite connections are used for image requests, leveraging multiple IPs to improve success rates under weak conditions.

The overall Baidu App network architecture is presented, featuring a network façade that isolates best‑practice logic from the underlying network libraries, including interceptors, priority queues, detection components, diagnostics, HTTPDNS, monitoring, and both Cronet‑based unified libraries and WebSocket libraries.

Benefits of weak‑network optimization are quantified: QUIC activation raises connection success by 0.01 % and reduces latency by 23.5 %; QUIC pre‑connection increases QUIC PV from 370 k to 900 k; composite connections reduce BAD‑state latency by 2.5 % and OFFLINE‑state latency by 7.7 %.

The series concludes by summarizing the three‑part series on DNS, connection, and weak‑network optimization, emphasizing continuous improvement.

References to external documents and source code repositories are listed at the end.