From DNS Hacks to QUIC: Six Years of Backend Engineering Lessons at Tencent

T3.1 to T3.2

In 2013, after joining the Application Store team, the author focused on business‑driven projects, notably the "3+1" project, which left little room for technical depth. Promotion to T3.2 relied on work done on the access layer, which introduced a cloud‑side IP scheduling capability that bypassed DNS resolution to reduce latency on mobile networks. Because DNS resolution could consume up to one‑third of the TCP three‑way handshake time, the solution avoided DNS entirely. A security channel, similar to a PSK‑based ticket system, was added to protect HTTP traffic before HTTPS became widespread.

The security design borrowed from QQ's simplified Kerberos mechanism and was implemented by the author on the server side, while a senior colleague designed the overall approach.

Despite the technical work, the first T3.2 promotion attempt failed because the review panel, mainly from the gaming BG, did not fully understand the solutions. The author’s leader emphasized that passing is not a guarantee of skill, but failing definitely indicates gaps.

T3.2 to T3.3

After promotion, the author maintained the Application Store’s core infrastructure, including the access layer, end‑to‑end protocols, and cross‑region disaster recovery. During the 3G era, six iterations of the access layer were performed, targeting three goals: speed, bandwidth efficiency, and stability.

Fast: ensure rapid connection under various network conditions.

Economical: minimize packet size between client and server.

Stable: guarantee scheduling and architectural reliability.

Two main evolution directions emerged:

Cloud scheduling: improve IP direct‑connect, DNS latency, and packet size.

Security channel: evolve from PSK to 1‑RTT RSA key exchange, then to ECDHE, extending protection to WebView authentication and preventing black‑market script abuse.

Key achievements included reaching a 99.7% end‑to‑end success rate, adopting ECDHE for forward secrecy, and implementing long‑connection management with epoll‑based session handling. The author also selected AES‑GCM over AES‑CBC to avoid padding oracle attacks.

A compression algorithm based on Facebook’s open‑source dictionary mode was adopted, achieving higher compression ratios than traditional gzip while keeping resource consumption low.

T3.3 to T4.1

Working on smart‑hardware products introduced strict latency requirements (e.g., a 100 ms delay in speaker prompts during gameplay is unacceptable). The team evaluated QUIC, which offered 0‑RTT/1‑RTT handshakes and better performance on weak networks, alongside HTTP/2.0. Since QUIC was not yet supported in mobile apps, the team extracted the QUIC implementation from Chrome’s source code and integrated it with the Tencent gateway.

The resulting HTTP/2.0 + QUIC access layer reduced code complexity, simplified security handling, and unified custom protocol layouts for long connections.

This upgrade, combined with smart‑hardware features such as automatic cloud video editing and a full‑stack tracing system built on open‑source Zipkin, helped the author achieve promotion to T4.1.

During this period, the NLP team also adopted Google BERT (the predecessor of GPT) for language processing.

Summary of Promotion Experiences

Meticulous technical design and continuous iteration aligned with business growth.

Resilience: never let a promotion outcome affect confidence.

Strong collaboration with teammates.

Personal technical philosophy solidified.

Promotion cycles were time‑consuming.

After reaching T4.1, further technical rank advancement was no longer possible as senior positions transitioned to the management track.