Fundamentals 15 min read

Mastering HTTP: From Basics to HTTP/2, TLS, QUIC and DNS Explained

This article provides a comprehensive overview of HTTP fundamentals, compares GET and POST, explains common status codes, details HTTPS and TLS mechanisms, introduces HTTP/2 features such as binary framing, header compression and server push, and walks through the full request‑response flow from DNS lookup to page rendering.

Efficient Ops
Efficient Ops
Efficient Ops
Mastering HTTP: From Basics to HTTP/2, TLS, QUIC and DNS Explained

1 HTTP

HTTP is a stateless protocol that does not retain state between requests.

2 Differences Between POST and GET

Introduce the concepts of side effects and idempotence.

Side effects modify server resources; searching is side‑effect‑free, while registration has side effects.

Idempotence means that sending the request multiple times results in the same server state; registering multiple accounts is not idempotent, while updating an article repeatedly is.

In practice, GET is used for side‑effect‑free, idempotent operations (e.g., keyword search), whereas POST is used for side‑effect, non‑idempotent operations (e.g., registration).

GET requests can be cached, POST cannot.

POST is slightly safer because GET parameters appear in the URL and are stored in browser history; POST data is not.

POST can transmit more data via the request body; GET cannot.

URL length limits affect GET requests; the limit is imposed by browsers, not the RFC.

POST supports more encoding types and imposes fewer data type restrictions.

3 Common Status Codes

2XX Success

200 OK – the request was successfully processed.

204 No Content – request succeeded but the response has no body.

205 Reset Content – request succeeded; the client should reset the document view.

206 Partial Content – used for range requests.

3XX Redirection

301 Moved Permanently – resource has a new permanent URL.

302 Found – temporary URL change.

303 See Other – resource available at another URL, should be fetched with GET.

304 Not Modified – resource not modified since last request.

307 Temporary Redirect – similar to 302 but the request method must not change.

4XX Client Errors

400 Bad Request – syntax error in the request.

401 Unauthorized – authentication required.

403 Forbidden – server refuses to fulfill the request.

404 Not Found – resource does not exist on the server.

5XX Server Errors

500 Internal Server Error – generic server failure.

501 Not Implemented – server does not support the requested functionality.

503 Service Unavailable – server overloaded or down for maintenance.

4 HTTP Headers

5 HTTPS

HTTPS still uses HTTP for transport, but the data is encrypted with TLS.

6 TLS

TLS sits above the transport layer and below the application layer. The initial handshake requires two round‑trips (RTTs); subsequent connections can use session resumption to reduce this to one RTT.

TLS employs both symmetric and asymmetric encryption.

Symmetric encryption: both parties share the same secret key for encryption and decryption.

Asymmetric encryption: a public key encrypts data, while a private key decrypts it.

The TLS handshake proceeds as follows:

Client sends a random value indicating the desired protocol and cipher suite.

Server replies with its own random value, selects a cipher suite, and sends its certificate.

Client validates the server certificate, generates a pre‑master secret, encrypts it with the server’s public key, and sends it to the server.

Server decrypts the pre‑master secret with its private key; both sides derive the session keys and begin encrypted communication.

During the handshake, asymmetric encryption secures the key exchange, after which symmetric encryption is used for data transfer because it is much faster.

Note: TLS 1.3 reduces the initial handshake to a single RTT and eliminates the need for a second RTT on session resumption.

7 HTTP 2.0

HTTP 2.0 dramatically improves web performance compared to HTTP 1.x.

In HTTP 1.x, browsers limit the number of concurrent connections per host, leading to head‑of‑line (HOL) blocking when many resources are requested.

HTTP 2.0 introduces multiplexing, binary framing, header compression, server push, and other optimizations to eliminate HOL blocking.

8 Binary Transport

HTTP 2.0 transmits data in binary frames instead of plain text, enabling more efficient parsing and compression.

9 Multiplexing

HTTP 2.0 uses frames and streams: a frame is the smallest unit of data, and a stream is a collection of frames belonging to a single request/response.

Multiple streams share a single TCP connection, allowing concurrent requests without HOL blocking.

10 Header Compression

HTTP 1.x sends headers as plain text, often repeating large cookie strings. HTTP 2.0 uses HPACK to compress headers and maintain an index table of previously seen header fields, reducing overhead.

11 Server Push

HTTP 2.0 allows the server to proactively push resources to the client after an initial request, reducing latency for assets the client is likely to need.

12 QUIC

QUIC is a Google‑originated transport protocol built on UDP, aiming to replace TCP.

Supports multiplexing without TCP’s head‑of‑line blocking.

Implements its own encryption and can achieve 0‑RTT handshakes.

Provides forward error correction to recover lost packets without retransmission, falling back to retransmission when multiple packets are lost.

13 DNS

DNS translates domain names to IP addresses, acting as a human‑friendly alias system.

The lookup process involves checking the local cache, querying the configured DNS server, and, if necessary, iterating through root, TLD, and authoritative servers.

DNS queries use UDP.

14 From URL Input to Page Load Completion

Perform DNS resolution (optionally using intelligent DNS for optimal IP).

Establish a TCP handshake, then a TLS handshake.

Optionally pass through a load balancer before reaching the backend server.

Server returns an HTTP status code; 200 proceeds, 3xx triggers redirects, 4xx/5xx result in errors.

Browser decompresses gzip if needed and decodes the response based on charset.

Browser builds the DOM tree, CSSOM tree, and processes

async

or

defer

scripts accordingly; scripts without these attributes block rendering.

When the initial HTML is fully parsed, the DOMContentLoaded event fires.

After DOM and CSSOM are ready, the render tree is constructed, layout is calculated, and the GPU paints the page.

web performancehttpNetworkingTLSHTTPSHTTP/2Web Protocols
Efficient Ops
Written by

Efficient Ops

This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.