Ctrip Mobile App Network Service Architecture and Performance Optimizations

Editor note: The author, Chen Haoran, Ctrip's Wireless Development Director, holds a Ph.D. in Computer Science and has extensive experience developing mobile apps with billions of users.

High reliability and low latency of app network services are crucial for stable wireless business growth. Over the past two years, Ctrip continuously optimized its app network services, completing major channel governance and performance goals by the end of Q2.

1. Ctrip App Wireless Network Service Architecture – In 2014, Ctrip built a Mobile Gateway with two types: TCP Gateway for native app services and HTTP Gateway for hybrid/H5 sites. The TCP Gateway, built on Netty and Zuul, handles client TCP connections and dynamic routing, forwarding requests to backend services via HTTP payloads. The HTTP Gateway provides simple RESTful services with dynamic forwarding.

2. Why TCP for App Network Services – TCP offers better control over bandwidth and latency, especially in weak networks, avoids DNS failures (2‑3% failure rate), and allows custom optimizations not possible with HTTP, such as connection management and fine‑grained timeout handling.

TCP implementation enables full control of the service lifecycle: obtaining server IP, establishing connections, serializing requests, sending, receiving responses, and deserializing.

3. TCP Network Service Channel Governance and Performance Optimization

3.1 DNS Bypass – Ctrip embeds a weighted server IP list in the app, selects the best IP based on ping latency, and updates the list via a Mobile Config service, eliminating DNS resolution delays and failures.

3.2 Socket Connection Optimization – Long‑connection pools maintain multiple TCP connections; idle connections are reused, reducing handshake latency (100‑300 ms). A simple FIFO request handling avoids pipeline or multiplexing complexity, and short connections are used when the pool is exhausted.

3.3 Weak‑Network and Network Jitter Optimization – Network quality parameters (type and end‑to‑end ping) adjust pool size, timeouts, and trigger reconnections when network type changes.

3.4 Data Format Optimization – Migrating from a custom format to Google Protocol Buffers reduced payload size by 20‑30 % and serialization time by 10‑20 %.

3.5 Retry Mechanism – Application‑level retries are added for connection failures, improving overall service success from 95.3 % to over 99.5 %.

3.6 Additional Mechanisms – Priority handling, dependency‑based cancellation, and various iOS socket tricks (e.g., SO_KEEPALIVE, SO_NOSIGPIPE, TCP_NODELAY, IPv6 support) are employed.

4. Hybrid Network Service Optimization – A "TCP Tunnel for Hybrid" forwards hybrid HTTP requests through the native TCP layer, achieving >99 % success and 30 % latency reduction.

5. Overseas Network Service Optimization – "TCP Bypass for Oversea" uses an Akaima dedicated channel and fallback to the Internet, cutting average latency by 33 % while maintaining success rates.

6. Exploration of Other Protocols – SPDY/HTTP‑2 and QUIC are evaluated; HTTP‑2 offers header compression, multiplexing, and better connection reuse, while QUIC provides UDP‑based low‑latency transport, though adoption is still under testing.

In summary, Ctrip unified most app network services onto a TCP channel, enabling fine‑grained performance tuning and monitoring, and the presented practices aim to provide valuable references for domestic wireless engineers.