Application layer – the big picture
The application layer (Layer 7) defines how applications talk to each other. This is where meaning is assigned to data.
If:
- IP decides where packets go
- TCP decides how data reliably flows
Then:
- HTTP decides what the data means and how to interpret it
Analogy:
TCP is the phone call connection.
HTTP is the language and rules you follow once the call is connected.
Summary
The application layer is where developers spend most of their time and where system design decisions are most visible.
User space vs kernel space (important distinction)
- Application layer: runs in user space
- Easy to change
- Flexible
- Evolves quickly
- Lower layers (TCP/IP): run in kernel space
- Hard to modify
- Extremely optimized
- Stable over decades
Important
Higher layers trade performance for flexibility. Lower layers trade flexibility for efficiency.
HTTP – The Foundation of the Web
HTTP (HyperText Transfer Protocol) is the dominant application-layer protocol for the web.
Core properties:
- text-based (human readable)
- request–response model
- stateless by default
- runs on top of TCP (or QUIC in newer versions)
Summary
HTTP is a standardized way for clients to ask for resources and servers to respond with them.
The request–response cycle
Everything in HTTP follows this pattern:
client → request → server
client ← response ← server
There is no server push in basic HTTP.
The client always starts.
HTTP Request – What the Client Asks For
An HTTP request is a structured text message.
Request method (action)
Defines what you want to do.
Common methods:
- GET: fetch data (no side effects)
- POST: send data (create / trigger action)
- PUT: replace data
- PATCH: partially update data
- DELETE: remove data
Important
GET and DELETE should be idempotent (same request = same result).
Request path
- identifies the resource
- examples:
- /index.html
- /users/42
- /images/logo.png
Request headers
Metadata about the request.
Examples:
- User-Agent: browser info
- Accept-Language: preferred language
- Accept-Encoding: compression formats supported
- Authorization: credentials or tokens
Headers are key–value pairs and highly extensible.
Request body
- optional
- used mainly with POST, PUT, PATCH
- contains JSON, form data, etc.
HTTP Response – What the Server Sends Back
The server replies with another structured message.
Status codes – did it work?
Status codes are standardized and grouped.
success (2xx)
- 200 OK
- 201 Created
redirection (3xx)
- 301 Moved Permanently
- 302 Found
client errors (4xx)
- 401 Unauthorized
- 403 Forbidden
- 404 Not Found
- 429 Too Many Requests
server errors (5xx)
- 500 Internal Server Error
- 502 Bad Gateway
Summary
Status codes let clients react correctly without parsing response bodies.
Response headers
Metadata about the response.
Examples:
- Content-Type: text/html
- Content-Encoding: gzip
- Set-Cookie: session data
Response body
The actual content:
- HTML
- JSON
- images
- files
How HTTP Uses the Full Networking Stack
A single web request involves multiple layers.
Step-by-step flow:
-
DNS lookup (usually over UDP)
-
TCP 3-way handshake (SYN → SYN-ACK → ACK)
-
HTTP request sent over TCP
-
HTTP response sent back
-
TCP connection closed (FIN/ACK) unless reused
browser ↓ DNS (UDP) ↓ TCP handshake ↓ HTTP request/response ↓ TCP teardown
Important
HTTP does not replace TCP — it depends on it.
Statelessness – the “memory problem”
HTTP is stateless by default.
Meaning:
- each request is independent
- server does not remember previous requests
- no built-in user memory
Problem:
- user logs in
- clicks another page
- server forgets who they are
How Statelessness is Solved
Cookies
- server sends a cookie
- browser stores it
- browser sends it with every request
Tokens (JWT, session tokens)
- client includes token in headers
- server validates token
Analogy:
A cookie is a digital ID card shown at every request.
Important
Statelessness is good for scalability, but identity must be reintroduced explicitly.
Why Statelessness is Good (System Design View)
Benefits:
- easy horizontal scaling
- no per-user server memory
- simpler failure recovery
Summary
Stateless servers behave like pure functions: response = f(request).
HTTP Headers – A Design Lesson
Headers are:
- optional
- extensible
- backward-compatible
This allows:
- new features without breaking old clients
- graceful degradation
Content negotiation example
Client sends:
- Accept-Encoding: gzip, br
Server replies:
- Content-Encoding: gzip
Tip
HTTP headers are a great example of future-proof API design.
Http vs https
Http
- plain text
- vulnerable to:
- Eavesdropping
- Packet sniffing
- Man-in-the-middle attacks
Https
- HTTP + TLS/SSL
- encrypts data before it enters TCP
- protects confidentiality and integrity
Even if packets are intercepted:
- contents are unreadable
Important
Any public-facing service must use HTTPS.
A Critical Security Warning (Very Important)
HTTPS encrypts transport, not trust.
Meaning:
- attackers can still send valid HTTPS requests
- request contents are not automatically trustworthy
Common mistake:
- trusting user ID from request body
- using it directly in database queries
Warning
Never trust client input. Always validate and authorize on the server.
What HTTP Does NOT Guarantee
- authentication
- authorization
- correctness of data
- user honesty
Those are application responsibilities.
Why Application Layer Knowledge Matters
- defines API behavior
- impacts scalability
- shapes security model
- determines developer experience
Most system design:
- assume IP + TCP basics
- focus heavily on HTTP semantics
Revision checklist
- HTTP is request–response
- Client always initiates
- Methods define intent
- Status codes define outcome
- Headers are flexible metadata
- HTTP is stateless by default
- Cookies/tokens reintroduce identity
- HTTPS encrypts transport, not intent
Summary
Master HTTP and the application layer — it’s where networking meets real system design.