From SPDY to QUIC: How Google’s Innovations Reshaped Web Protocols

In the previous article we summarized the evolution of HTTP from 1.0 to 2.0. This article focuses on SPDY, the pioneering protocol that preceded HTTP/2, and QUIC, a disruptive protocol that challenges TCP.

1. Pioneer: SPDY

1. Introduction

SPDY is a Google‑initiated improvement over HTTP/1.1 (before HTTP/2 existed). It runs on TCP and addresses many pain points of HTTP/1.x, dramatically increasing web page loading speed. HTTP/2 later adopted many SPDY features.

2. Features

Multiplexing

Header compression

Server push

Request priority

SPDY architecture diagram:

3. Current Status

Before HTTP/2 was released, SPDY already had a notable market share, and for a long time both SPDY and HTTP/2 could be seen in use simultaneously.

2. Disruptor: QUIC

1. Prerequisite Knowledge

TCP and UDP

TCP (Transmission Control Protocol) is a connection‑oriented, reliable, byte‑stream transport protocol. It provides reliable data transfer, flow control, full‑duplex operation, and multiplexing.

Key characteristics of TCP:

Connection‑oriented: a handshake is required before data exchange.

Supports applications such as Telnet, FTP, SMTP.

Suitable for large‑volume, high‑reliability data transfer.

UDP (User Datagram Protocol) is a connection‑less transport protocol that offers simple, unreliable message delivery.

Key characteristics of UDP:

Connection‑less: data is sent without a prior handshake.

No reliability, flow control, or error recovery.

Used for low‑volume, latency‑sensitive applications such as DNS, NFS, SNMP.

In summary, TCP provides reliable, ordered delivery at the cost of higher latency, while UDP offers faster, unordered delivery with no reliability guarantees.

Diffie‑Hellman Algorithm

The security of the Diffie‑Hellman (DH) algorithm relies on the difficulty of the discrete logarithm problem. The exchange proceeds as follows:

Both client and server agree on two large primes

n

and

g

(public).

Client picks a random secret

x

and computes

A = g^x mod n

, then sends

A

to the server.

Server picks a random secret

y

and computes

B = g^y mod n

, then sends

B

to the client.

Both sides compute the shared secret: client calculates

K = B^x mod n

, server calculates

K = A^y mod n

. The values are equal, providing a secret key for encryption.

An eavesdropper knows

n

,

g

,

A

, and

B

, but cannot feasibly compute the shared secret when the numbers are sufficiently large.

2. What is QUIC?

QUIC is a Google‑developed, UDP‑based high‑efficiency reliable protocol. It implements many TCP features on top of UDP, achieving higher transmission efficiency than TCP.

3. Features

a. Connection built on UDP TCP‑based protocols like HTTP/2 require a three‑way handshake and additional TLS handshakes, adding latency especially for short‑lived connections. QUIC, using UDP, reduces the handshake to one or two round‑trips, dramatically lowering latency.

b. Diffie‑Hellman based encryption While HTTPS (TLS/SSL) typically requires two round‑trips for key exchange, QUIC leverages Diffie‑Hellman to establish a secure link with a single round‑trip.

Client sends an Inchoate Client Hello.

Server replies with a Rejection containing public key, algorithm, and certificate info (server config).

Client sends a Client Hello with its public key.

c. Improved multiplexing Both HTTP/2 and SPDY achieve multiplexing over TCP but still suffer from head‑of‑line blocking due to TCP’s strict ordering. QUIC’s UDP foundation eliminates this issue, allowing independent streams without blocking each other.

d. Connection migration Traditional TCP connections are identified by a 4‑tuple (source IP, source port, destination IP, destination port). Any change forces a new connection. QUIC uses a connection ID, enabling seamless migration when network conditions change (e.g., switching from Wi‑Fi to 4G).

e. Negotiation upgrade When a client initiates a request, it simultaneously attempts TCP and QUIC connections. If QUIC wins the race, the request proceeds over QUIC; otherwise, it falls back to TCP. The process includes:

Client sends a TCP request.

Server, if QUIC‑capable, signals this via the Alt‑Svc header.

Client initiates both TCP and QUIC connections.

Whichever connection succeeds first is used.

If QUIC fails, it is marked as broken and retried after a back‑off period.

Failed QUIC attempts are retried with increasing intervals (5 min, then 10 min).

Successful QUIC restores normal operation and clears the broken flag.

Other Features

Improved congestion control

Packet loss recovery

Persistent underlying connections

Head‑stream ordering guarantees

Two‑level flow control

3. Summary and Reflection

In the evolution of web communication protocols, SPDY played an indispensable role by dramatically speeding up page loads before HTTP/2 existed, and many of its innovations were incorporated into HTTP/2. Today, QUIC represents a radical shift from TCP, leveraging UDP for higher efficiency while preserving TCP‑like features, allowing seamless adoption without changing application‑layer protocols. Both technologies originated from Google, underscoring its significant influence on modern web performance.