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

1 HTTP

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

2 Difference between POST and GET

Introduce the concepts of side effects and idempotence.

Side effects modify server resources (e.g., registration), while searches have no side effects.

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

In practice, GET is used for side‑effect‑free, idempotent operations (e.g., searching), whereas POST is used for operations with side effects and non‑idempotent behavior (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 can transmit more data via the request body; GET cannot.

URL length limits affect GET requests (browser‑imposed, not RFC‑defined).

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

3 Common Status Codes

2XX Success

200 OK – request processed successfully.

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

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

206 Partial Content – partial response 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 must preserve the request method.

4XX Client Errors

400 Bad Request – syntax error in request.

401 Unauthorized – authentication required.

403 Forbidden – server refuses to fulfill the request.

404 Not Found – resource does not exist.

5XX Server Errors

500 Internal Server Error – generic server failure.

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

503 Service Unavailable – server overloaded or down for maintenance.

4 HTTP Headers

5 HTTPS

HTTPS uses HTTP over TLS to encrypt the transmitted data.

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.

TLS handshake steps:

Client sends a random value with supported protocols and cipher suites.

Server replies with its own random value, chosen cipher suite, and its certificate.

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

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 due to its lower overhead.

Note: The description refers to TLS 1.2; TLS 1.3 reduces the initial handshake to one RTT.

7 HTTP/2

HTTP/2 dramatically improves web performance compared to HTTP 1.x.

In HTTP 1.x, browsers limit concurrent connections per host, causing head‑of‑line blocking when many resources are requested.

HTTP/2 introduces multiplexing, allowing multiple streams over a single TCP connection, eliminating this bottleneck.

8 Binary Transport

HTTP/2 transmits data in binary frames rather than plain text, enabling efficient parsing and multiplexing.

9 Multiplexing

HTTP/2 uses frames and streams; a frame is the smallest unit of data, belonging to a stream. Multiple streams share a single TCP connection, allowing concurrent requests without head‑of‑line blocking.

10 Header Compression

HTTP/1.x sends headers as plain text, often repeating large cookie strings. HTTP/2 uses HPACK compression and an indexed header table to reduce header size.

11 Server Push

HTTP/2 allows the server to proactively push resources the client is likely to need after an initial request, reducing latency (alternatively, browsers can use prefetch).

12 QUIC

QUIC, developed by Google, is a UDP‑based transport protocol aiming to replace TCP.

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

Implements its own encryption and can achieve 0‑RTT similar to TLS 1.3.

Provides forward error correction: a parity packet allows recovery of a single lost packet without retransmission; multiple losses trigger retransmission.

13 DNS

DNS translates domain names to IP addresses. The resolution process involves local cache lookup, querying configured DNS servers, and if necessary, iterative queries to root and authoritative servers.

Both iterative (client performs queries) and recursive (DNS server performs queries on behalf of client) lookups exist; DNS operates over UDP.

14 From URL Input to Page Load Completion

DNS lookup (optionally using smart DNS for fastest IP).

TCP handshake establishing connection.

TLS handshake after TCP.

Request may pass through load balancers before reaching the server.

Browser checks the HTTP status code (200 proceeds, 3xx redirects, 4xx/5xx errors).

If response is compressed (e.g., gzip), the browser decompresses it and decodes according to charset.

Browser builds the DOM tree from HTML and the CSSOM tree from CSS.

When encountering script tags, the browser handles async (download and execute in parallel) or defer (download now, execute after parsing). Without these attributes, script execution blocks rendering.

After the initial HTML is parsed, the DOMContentLoaded event fires.

When DOM and CSSOM are ready, the render tree is constructed, layout and style are computed.

The GPU paints the render tree, compositing layers and displaying the page.

Source: Public account "运维军团"