HTTPS Request Optimization Strategies for Mobile Video Streaming

Background: Video streaming services are highly latency‑sensitive, especially in overseas deployments where network conditions are worse. The iQIYI overseas project required "second‑level" start‑up times, prompting a series of HTTPS and backend optimizations.

Why focus on mobile? Mobile devices and variable network environments amplify connection‑setup and link‑reuse issues, making latency reductions critical.

HTTPS request latency: a fresh HTTPS connection without any cache can take about 10 RTTs (e.g., 10 × 50 ms = 500 ms) before any backend processing, which is unacceptable for video playback.

Typical caching mechanisms (local DNS cache, HTTPDNS, HSTS, CA certificate cache, OCSP stapling) can reduce the number of RTTs dramatically, often leaving only ~4 RTTs for a normal HTTPS request.

TLS handshake analysis and optimization points

Using WireShark captures of a TLS 1.2 handshake with ECDHE, the following stages were identified:

TLS Hello – version negotiation, cipher suites, extensions.

Server Certificate – server sends its certificate chain.

Client/Server Key Exchange – DH/ECDHE key exchange.

ChangeCipherSpec – symmetric key activation.

Key‑exchange algorithm improvement: replace RSA with DH/ECDHE (e.g., X25519) for faster computation and smaller certificates.

Configuration example:

ssl_ecdh_curve X25519:secp384r1;

Enable False Start so the client can send encrypted application data immediately after ChangeCipherSpec, saving one RTT.

Prioritize high‑performance cipher suites on the server:

ssl_prefer_server_ciphers on;

ssl_ciphers EECDH+ECDSA+AES128+SHA:RSA+AES128+SHA...

When security requirements allow, use 128‑bit AES instead of 256‑bit to reduce CPU load.

Certificate optimization

Use ECDSA certificates (smaller key size, lower verification cost) instead of RSA:

openssl ecparam -genkey -name prime256v1 -out key.pem

Enable OCSP Stapling to avoid client‑side OCSP lookups:

ssl_stapling on;

ssl_stapling_verify on;

ssl_trusted_certificate xx.pem;

Test OCSP stapling:

openssl s_client -connect ip:443 -status

Session reuse (link reuse)

Two mechanisms reduce handshake RTTs:

SessionID – server caches session keys.

SessionTicket – server encrypts session state and lets the client store it.

Server configuration for SessionID:

ssl_session_cache shared:SSL:50m;

ssl_session_timeout 1d;

Server configuration for SessionTicket:

ssl_session_tickets on;

ssl_session_ticket_key xx.key;

With session reuse, a resumed TLS connection requires only 1 RTT; TLS 1.3 can achieve 0‑RTT using pre‑shared keys.

Summary

From HTTP/1.0 to HTTP/2, TCP’s head‑of‑line blocking and handshake overhead keep latency high. HTTP/3, built on QUIC, eliminates TCP and enables 0‑RTT/1‑RTT connections. iQIYI overseas has begun experimenting with QUIC to further improve user experience.