HTTP: Complete Guide | HTTP/1.1· HTTP/2

Introduction

HTTP (HyperText Transfer Protocol) is the application-layer protocol behind most websites and public APIs. Tabs, mobile backends, and synchronous microservice calls share the pattern: send a request, get a response—usually over HTTPS. Versions evolved from HTTP/1.1 simplicity to HTTP/2 multiplexing and HTTP/3 over QUIC. TLS 1.3, HSTS, and CSP are baseline security. This article connects spec mechanics to curl, REST, caches, and CDNs.

After reading this post

• Read and design request lines, methods, status codes, and headers
• Contrast HTTP/1.1 pipelining limits, HTTP/2 streams, and HTTP/3 over QUIC
• Validate behavior with curl and apply RESTful and caching patterns
• Use a security checklist covering HTTPS, HSTS, CSP, and API auth

---

Table of contents

1. Protocol overview
2. How it works
3. Hands-on usage
4. Security considerations
5. Real-world use cases
6. Optimization tips
7. Common problems
8. Wrap-up

---

Protocol overview

History and background

HTTP began at CERN in the early 1990s; RFC 1945 (HTTP/1.0) and RFC 2616 (HTTP/1.1) popularized it. HTTP/2 added multiplexing on one TCP connection; HTTP/3 (RFC 9114) runs QUIC over UDP with integrated TLS 1.3, stream-level loss isolation, and connection migration—widely supported by CDNs and browsers in 2026.

OSI placement

HTTP is layer 7. Traditionally TCP carries HTTP/1.1 and HTTP/2; QUIC (UDP) carries HTTP/3. TLS encrypts bytes on the wire. After DNS, clients speak 443/tcp or 443/udp (QUIC).

Core properties

Property	Description
Stateless	Servers do not remember prior requests by default—sessions use cookies, tokens, server-side stores.
Request–response	Client initiates; server returns status, headers, optional body.
Resource-oriented	URLs identify resources; methods express intent (GET read, POST create, …).
Content negotiation	Accept, Accept-Encoding, Accept-Language, …
Cache-friendly	ETag and Cache-Control reduce bandwidth and latency.

---

How it works

Request / response

Messages have a start line, header fields, blank line, optional body. Request (HTTP/1.1)

GET /api/users/42 HTTP/1.1
Host: api.example.com
Accept: application/json

Response

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Cache-Control: private, max-age=60

Methods (safe and idempotent)

Method	Typical use	Safe	Idempotent (ideal)
GET	Read	Yes	Yes
HEAD	Metadata only	Yes	Yes
POST	Create / process	No	Not guaranteed
PUT	Replace whole	No	Yes
PATCH	Partial update	No	Varies
DELETE	Delete	No	Yes
Idempotent: repeating the request leaves server state the same—important for retries.

Status codes

• 2xx: Success (200, 201, 204)
• 3xx: Redirects (301, 302, 307, 308—method preservation differs)
• 4xx: Client errors (400, 401, 403, 404, 429)
• 5xx: Server errors (500, 502, 503, 504)

Important headers

Header	Role
Host	Virtual hosting with SNI on shared IPs.
Authorization	Bearer, Basic, …
Content-Type	Body MIME type.
Cache-Control	Caching policy (max-age, no-store, …).
ETag / Last-Modified	Validation and conditional GET.

HTTP/2: multiplexing

One TCP connection, many streams, HPACK header compression. Reduces application-level HOL blocking (TCP HOL can remain). Server push declined in favor of hints and priorities.

HTTP/3: HTTP over QUIC

TLS 1.3 integrated with QUIC; loss affects one stream more often than the whole connection—helps Wi‑Fi and lossy links.

flowchart TB
  subgraph app [Application]
    H3[HTTP/3]
  end
  subgraph quic [Transport & crypto]
    Q[QUIC + TLS 1.3]
  end
  subgraph net [Network]
    U[UDP]
    IP[IP]
  end
  H3 --> Q --> U --> IP

sequenceDiagram
  participant C as Client
  participant S as Server
  C->>S: HTTP Request (method, path, headers)
  S->>C: HTTP Response (status, headers, body)

---

Hands-on usage

curl

curl -sI https://example.com
curl -sS -X POST 'https://api.example.com/items' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_TOKEN' \
  -d '{"name":"demo"}'
curl -L -v 'https://example.com/path'
curl --http2 -sI https://example.com
curl --http3-only -sI https://cloudflare-quic.com/

REST API design

• Resource URLs: /users/42/orders with nouns and hierarchy.
• Status codes: 201 + Location for creates; 400/422 bad input; 401 vs 403.
• Versioning: /v1/ prefix or Accept versioning.
• Pagination: cursor or offset/limit; Link headers for next pages.
• Idempotency: Idempotency-Key for payments and orders.

Caching

• Static assets: hashed filenames + Cache-Control: public, max-age=31536000, immutable.
• HTML shell: short max-age; versioned JS/CSS long-lived.
• APIs: private or no-store for personal data; ETag + max-age for safe public reads.
• Vary: when responses differ by Accept-Encoding or Accept-Language.

---

Security considerations

HTTPS and TLS 1.3

Plain HTTP exposes credentials, cookies, and payloads. TLS 1.3 shortens handshakes and modernizes ciphers—manage chains, expiry, and SANs.

HSTS

Strict-Transport-Security forces HTTPS for the domain. Preload is a policy decision.

CSP

Content-Security-Policy mitigates XSS—tighten script-src with nonces/hashes; use frame-ancestors against clickjacking.

API security

• OAuth 2.0 / OIDC, short-lived access tokens, refresh flows.
• CORS protects browsers—not server-to-server calls; still authenticate backends.

---

Real-world use cases

Area	Notes
Web	HTML, JS, media, CDN edge caching.
APIs	JSON, OpenAPI, gateway rate limits and auth.
Microservices	HTTP/gRPC mix; retries, timeouts, circuit breakers.
Webhooks	HMAC signatures, idempotent storage.

---

Optimization tips

• HTTP/1.1 keep-alive: reuse TCP (default today); many small requests favor h2/h3.
• Compression: br / gzip for text—not much gain on already compressed media.
• CDN: edge TLS, caching, purge APIs for invalidation.
• HTTP/3: ensure UDP 443 on load balancers and firewalls when enabling QUIC.

---

Common problems

Symptom	Check
CORS errors	Access-Control-Allow-Origin, preflight method/header allowlists, credentials.
Timeouts	Client/LB/server idle and read timeouts, downstream latency, DNS.
Redirect loops	301/302 chains, http↔https, www normalization, cached 301.
Stale cache	Cache-Control, CDN purge, URL versioning.

---

Wrap-up

HTTP standardizes stateless request–response with rich semantics. HTTP/2 improves multiplexing; HTTP/3 improves lossy and mobile networks. HTTPS, HSTS, and CSP are baseline security. Use this checklist for public sites, REST APIs, and gateways: performance = cache + CDN + protocol version, safety = TLS + headers + least privilege.

References

• IETF HTTPbis (RFC 9110–9114 family)
• MDN: HTTP, CORS, CSP
• OWASP: API Security, Transport Layer Protection

---

Frequently Asked Questions (FAQ)

Q. When would I use this in practice?

A. HTTP requests and responses, methods and status codes, HTTP/2 multiplexing and HTTP/3 over QUIC, HTTPS, caching, and.

Q. What should I read before this?

A. Follow the previous article or related articles links at the bottom of each post to learn in sequence.

Q. Where can I study this more deeply?

A. Check cppreference and the relevant library’s official documentation. The reference links at the end of the article are also worth using.

---

Related Articles (Internal Links)

Other articles related to this topic.

• TCP 프로토콜 완전 가이드 | 3-way handshake·흐름·혼잡 제어·소켓 실전
• SSH 프로토콜 보안 원격 접속 | 공개키·ProxyJump·포트 포워딩·OpenSSH 실전
• HTTP 프로토콜 완전 가이드 | HTTP/1.1·HTTP/2·HTTP/3·REST·HTTPS·캐시 실전

---

Keywords Covered in This Article (Related Search Terms)

This article covers Network, HTTP, HTTP/1.1, HTTP/2, HTTP/3, REST API, HTTPS, TLS.