Repository navigation
EN_Net_HTTP
somaz edited this page Sep 22, 2026
·
2 revisions
How HTTP works:
- ① The client sends an HTTP request message (a method such as GET or POST + a URI)
- ② The server processes the request and returns an HTTP response message (status code + response body)
- ③ The client interprets the response and may issue further requests (HTML, CSS, JavaScript, etc.)
- ④ Plaintext transmission leaves it vulnerable to man-in-the-middle attacks
How HTTPS works (TLS Handshake, based on TLS 1.2 RSA key exchange):
- ① The client connects to the HTTPS server and sends a ClientHello message (list of supported cipher suites)
- ② The server sends ServerHello + its SSL/TLS certificate (including the public key)
- ③ The client verifies the certificate (checks the signature with the CA's public key)
- ④ The client generates a session key (symmetric key), encrypts it with the server's public key, and sends it
- ⑤ The server decrypts the session key with its private key
- ⑥ The Handshake completes with the exchange of Finished messages
- ⑦ From then on, communication uses symmetric encryption with the session key
Key differences:
- HTTP: port 80, plaintext transmission, fast, insecure
- HTTPS: port 443, encrypted transmission, TLS Handshake overhead, guarantees confidentiality/integrity/authentication
Safe Methods:
- Read-only methods that do not change server state
- GET, HEAD, OPTIONS, TRACE
- Calling them many times has no effect on server resources
Idempotent Methods:
- Performing the same request many times yields the same result
- GET, HEAD, PUT, DELETE, OPTIONS, TRACE
- POST and PATCH are not guaranteed to be idempotent: POST creates a new resource every time, and PATCH can produce different results depending on the operation
Practical examples:
GET /users/123 → safe + idempotent (same result no matter how many times it is read)
POST /users → not safe + not idempotent (creates a new user every time)
PUT /users/123 → not safe + idempotent (overwrites with the same content)
DELETE /users/123 → not safe + idempotent (deleting an already-deleted resource returns 404, but the state is the same)
PATCH /users/123 → not safe + not idempotent (increment operations and the like can accumulate)
Network retry strategy:
- Idempotent methods are safe to retry automatically
- Non-idempotent methods use an Idempotency Key (payment APIs, etc.)
Q3. What are the main differences between HTTP/1.1, HTTP/2, and HTTP/3, and how do they improve performance?
HTTP/1.1 (1997):
- Connection per Request: HTTP/1.0 opened a new TCP connection for every request; HTTP/1.1 uses Keep-Alive (persistent connections) by default
- Head-of-Line Blocking: waits until the previous request completes
- Text-based protocol: parsing overhead
- Workarounds: Pipelining (limited support), Domain Sharding (multiple domains)
HTTP/2 (2015):
- Multiplexing: multiple streams sent concurrently over a single TCP connection
- Header Compression (HPACK): removes duplicate headers and compresses them
- Server Push: sends resources proactively before the client requests them
- Binary Framing: efficient parsing with binary frames
- Limitation: TCP-level Head-of-Line Blocking still exists (on packet loss, all streams wait)
HTTP/3 (2022):
- QUIC over UDP: uses the QUIC protocol instead of TCP
- Stream-level independence: packet loss on one stream does not affect other streams
- 0-RTT Connection: skips the Handshake by reusing previous connection information
- Connection Migration: keeps the connection alive even when the IP changes (mobile environments)
- Built-in TLS 1.3: encryption is mandatory
Performance comparison:
HTTP/1.1: 6 parallel connections → requests serialized per connection
HTTP/2: single-connection Multiplexing → 2-3x faster
HTTP/3: QUIC-based → an additional 10-30% improvement in lossy networks
Full TLS 1.2 Handshake (2-RTT):
Client Server
| |
|-------- ClientHello --------------->| (supported cipher suites, random value)
| |
|<------- ServerHello ----------------| (selected cipher suite, certificate, random value)
|<------- Certificate ----------------| (server public key)
|<------- ServerHelloDone ------------|
| |
|-------- ClientKeyExchange --------->| (sends the encrypted Pre-Master Secret)
|-------- ChangeCipherSpec ---------->|
|-------- Finished ------------------>|
| |
|<------- ChangeCipherSpec -----------|
|<------- Finished -------------------|
| |
|======== Application Data ==========| (encrypted HTTP data)
TLS 1.3 Handshake (1-RTT):
Client Server
|-------- ClientHello + KeyShare ---->| (key exchange sent at the same time)
| |
|<------- ServerHello + KeyShare -----| (key + certificate)
|<------- {EncryptedExtensions} ------|
|<------- {Certificate} --------------|
|<------- {Finished} -----------------|
| |
|-------- {Finished} ---------------->|
|======== Application Data ==========|
Performance optimization methods:
1. TLS Session Resumption:
Session ID: the server stores session state (memory cost)
Session Ticket: the client stores an encrypted ticket (stateless)
2. TLS 1.3 0-RTT (Zero Round Trip Time):
- Reuses the PSK (Pre-Shared Key) from a previous connection
- Sends data immediately along with the first Handshake message
- Security trade-off: risk of Replay Attacks (use only for idempotent requests)
3. OCSP Stapling:
- The server checks the certificate status in advance and includes it in the response
- Saves the client the time of querying the CA
4. HTTP/3 (QUIC):
- 0-RTT Connection supported by default
- TLS 1.3 built in
Production configuration (Nginx):
ssl_protocols TLSv1.3 TLSv1.2;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets on;
ssl_stapling on;
ssl_stapling_verify on;2xx Success:
- 200 OK: GET succeeded, response body included
- 201 Created: resource created via POST, new URI in the Location header
- 204 No Content: the request succeeded but there is no response body (on successful DELETE, PUT)
- 206 Partial Content: partial response to a Range request (video streaming)
3xx Redirection:
- 301 Moved Permanently: permanent move, search engines index the new URL
- 302 Found: temporary move, the original URL is kept
- 304 Not Modified: the cached resource is still valid, no body sent (uses If-Modified-Since, ETag)
- 307 Temporary Redirect: similar to 302 but the method must not change (POST → POST)
- 308 Permanent Redirect: similar to 301 but the method must not change
4xx Client Error:
- 400 Bad Request: malformed request syntax
- 401 Unauthorized: authentication required (WWW-Authenticate header)
- 403 Forbidden: authenticated but not authorized
- 404 Not Found: the resource does not exist
- 405 Method Not Allowed: the method is not allowed
- 429 Too Many Requests: rate limit exceeded (Retry-After header)
5xx Server Error:
- 500 Internal Server Error: internal server error
- 502 Bad Gateway: gateway/proxy error
- 503 Service Unavailable: server overloaded or under maintenance (Retry-After header)
- 504 Gateway Timeout: gateway/proxy timeout
Caching strategy (Cache-Control):
Cache-Control: public, max-age=31536000, immutable
→ static resources (CSS, JS), cached for 1 year, no browser revalidation needed
Cache-Control: private, max-age=3600
→ per-user data, cached for 1 hour, not cacheable by a CDN
Cache-Control: no-cache
→ cacheable, but must be revalidated before use (ETag, Last-Modified)
Cache-Control: no-store
→ caching forbidden (sensitive information)
Conditional requests:
Request:
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
If-Modified-Since: Wed, 21 Oct 2023 07:28:00 GMT
Response (cache still valid):
304 Not Modified
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
(no body, saves bandwidth)
💡 Term Explanation:
- For detailed explanations of the terms used in the HTTP/HTTPS questions (Q1-Q5) — TLS Handshake, idempotency, HTTP/2 Multiplexing, Cache-Control, ETag, etc. —
- refer to the Glossary > Protocols & Communication section.