Unlocking the Secrets of HTTP: From Requests to QUIC and Beyond

HTTP Request Preparation

Browsers resolve the domain name (e.g., www.163.com) to an IP address via DNS. After DNS resolution, a TCP connection is established using the three‑way handshake before any HTTP request is sent.

HTTP/1.1 typically enables Keep‑Alive, allowing the same TCP connection to be reused for multiple requests, reducing the overhead of repeated handshakes.

HTTP Request Construction

After the TCP connection is ready, the browser sends an HTTP request whose format consists of three parts: the request line, request headers, and the message body.

The request line includes the method (GET, POST, PUT, DELETE, etc.), the URL, and the HTTP version. GET retrieves resources, POST sends data (often JSON) to the server, PUT updates existing resources, and DELETE removes them.

Header Fields

Headers are key‑value pairs that convey important metadata, such as

Accept-Charset

(client’s supported character sets) and

Content-Type

(format of the body, e.g., JSON). Caching headers like

Cache-Control

and

If-Modified-Since

help reduce bandwidth by reusing unchanged resources.

Sending the HTTP Request

HTTP runs over TCP, which provides a reliable, ordered byte stream. TCP segments are encapsulated in IP packets, routed through MAC addresses, and finally delivered to the server process listening on the HTTP port.

HTTP Response Construction

The server replies with a status line (e.g., 200 OK or 404 Not Found), response headers (e.g.,

Retry-After

,

Content-Type

), and an optional body containing HTML, JSON, etc.

HTTP/2.0

HTTP/2 improves performance by compressing headers, splitting messages into binary frames, and multiplexing multiple streams over a single TCP connection, eliminating head‑of‑line blocking.

QUIC – The “Playful” UDP‑Based Protocol

QUIC replaces TCP with a UDP‑based connection that uses a 64‑bit random connection ID, allowing seamless migration across IP or port changes without a new handshake.

Custom Retransmission

QUIC assigns incremental packet numbers and acknowledges them based on offsets, providing more accurate RTT measurements and avoiding TCP’s cumulative ACK delays.

Non‑Blocking Multiplexing

Multiple streams share a single QUIC connection; loss on one stream does not stall others, unlike HTTP/2 over TCP.

Custom Flow Control

QUIC uses per‑stream and connection‑wide window updates based on received offsets, allowing finer‑grained and more efficient flow control.

Remember the key HTTP methods: GET, POST, PUT, DELETE.

HTTP/2 boosts performance with header compression, binary framing, and multiplexing.

QUIC further improves latency and reliability by using UDP, custom retransmission, multiplexing, and flow control.