Mastering HTTP: From Basics to HTTP/2, TLS, and Beyond

1 HTTP

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

2 Differences Between POST and GET

First, introduce the concepts of side effects and idempotence.

A side effect changes resources on the server; searching is side‑effect‑free, while registration causes a side effect.

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 scenarios such as keyword search, whereas POST is used for side‑effect, non‑idempotent scenarios like 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, while POST data is not, though both are visible in packet captures.

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

GET URLs have length limits imposed by browsers, not by the RFC.

POST supports more encoding types and does not restrict data types.

3 Common Status Codes

2XX Success

200 OK – the request was processed correctly.

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

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

206 Partial Content – used for range requests.

3XX Redirection

301 Moved Permanently – the resource has a new permanent URL.

302 Found – temporary redirection to a new URL.

303 See Other – the resource can be retrieved with a GET request at another URL.

304 Not Modified – the cached version is still valid.

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

4XX Client Errors

400 Bad Request – syntax error in the request.

401 Unauthorized – authentication is required.

403 Forbidden – the server refuses to fulfill the request.

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

5XX Server Errors

500 Internal Server Error – the server encountered an unexpected condition.

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

503 Service Unavailable – the server is overloaded or under maintenance.

4 HTTP Headers

5 HTTPS

HTTPS also uses HTTP for transport, but the information is encrypted with TLS.

6 TLS

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

TLS uses 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 only the private key can decrypt it.

TLS handshake steps:

The client sends a random value together with the desired protocol and cipher suite.

The server receives the client’s random value, generates its own, selects the appropriate protocol and cipher suite, and sends its certificate.

The client validates the server certificate, encrypts a new random value with the server’s public key, and sends it back (optionally sending its own certificate).

The server decrypts the encrypted random value with its private key, now both sides have three random values and derive a shared secret key for subsequent symmetric encryption.

During the handshake, asymmetric encryption is used; after the handshake, symmetric encryption secures the data because it is much faster.

Note: the description above refers to TLS 1.2; TLS 1.3 reduces the initial handshake to a single RTT.

7 HTTP 2.0

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

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

HTTP 2.0 introduces multiplexing, allowing multiple streams over a single TCP connection, eliminating head‑of‑line blocking.

8 Binary Transfer

HTTP 2.0 encodes all transferred data in binary frames instead of the plain‑text format used by earlier versions.

9 Multiplexing

HTTP 2.0 introduces two key concepts: frames and streams. A frame is the smallest unit of data and indicates which stream it belongs to; a stream is a sequence of frames that together form a logical request/response.

Multiplexing allows many streams to share a single TCP connection, preventing the head‑of‑line blocking of earlier HTTP versions and greatly improving throughput.

10 Header Compression

HTTP 1.x transmits headers as plain text, which can be large when cookies are involved. HTTP 2.0 uses the HPACK compression format, maintaining an index table of previously seen header fields to send only indexes instead of full header names.

11 Server Push

With HTTP 2.0, the server can proactively push resources to the client after an initial request, reducing latency for resources that are known to be needed.

12 QUIC

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

It supports multiplexing without TCP’s head‑of‑line blocking because UDP lacks retransmission at the transport layer.

It includes its own encryption and can achieve 0‑RTT handshakes (TLS 1.3 already provides 0‑RTT).

It implements forward error correction: an XOR‑based parity packet can recover a single lost packet without retransmission; loss of two or more packets triggers normal retransmission.

13 DNS

DNS translates domain names to IP addresses, making them human‑readable.

Before a TCP handshake, the operating system performs DNS resolution, first checking the local cache, then the configured DNS server, and finally the root servers if needed.

Check local cache.

Query the configured DNS server.

If unresolved, query the root server to find the authoritative server for the top‑level domain.

Query the TLD server for the second‑level domain.

Query the authoritative server for the final host record.

DNS can use iterative queries (client performs each step) or recursive queries (the DNS server performs the full lookup on behalf of the client). DNS operates over UDP.

14 From URL to Page Load Completion

Perform DNS resolution (optionally using intelligent DNS for the fastest IP).

Establish a TCP handshake, which involves the application layer passing data to the transport layer, the transport layer adding port numbers, the network layer adding IP addresses, and finally encapsulating into frames for physical transmission.

After TCP, perform the TLS handshake, then begin data transfer.

Requests may pass through a load balancer before reaching the server, which returns an HTML response.

The browser checks the HTTP status code: 200 proceeds, 3xx triggers redirection, 4xx/5xx report errors.

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

During HTML parsing, the browser builds the DOM tree and, if CSS is present, the CSSOM tree. When encountering script tags, it checks for async (download and execute in parallel) or defer (download now, execute after parsing). Without these attributes, script execution blocks rendering. HTTP 2.0 can greatly improve parallel resource downloads.

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

After the DOM and CSSOM trees are complete, the render tree is constructed, determining layout and styles.

The browser then uses the GPU to paint layers and display the page on the screen.