Application Layer Protocols: HTTP and DNS
HTTP message structure, methods, status codes and caching, the DNS resolution flow, and the evolution of HTTP versions, viewed from the application layer.
Contents
The application layer is where the protocols that user programs handle directly live, and HTTP and DNS sit at its center.
What the application layer does
The internet protocol stack has four layers. The application layer sits at the top and holds the protocols that user programs such as web browsers and chat clients handle directly. HTTP, DNS, and FTP are the familiar members.
TCP and UDP in the transport layer below carry the data, and the application layer decides what is exchanged and in what format. Over the same TCP connection, HTTP exchanges web resources and FTP exchanges files, each by its own rules.
This article covers the two most widely used. HTTP (HyperText Transfer Protocol) is the protocol for exchanging web resources. DNS (Domain Name System) is the system that converts human-readable domain names into the IP addresses communication requires.
HTTP message structure
HTTP is a request-response protocol: the client sends a request and the server answers. Requests and responses share the same skeleton - start line, headers, blank line, body.
GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.comThe start line of a request consists of method + request target + HTTP version. The example above is a GET request for the path /search?q=hello&hl=ko. Headers carry side information such as the host or content type, and the body follows a blank line (CRLF).
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3423
<html>
<body>...</body>
</html>The start line of a response is HTTP version + status code + reason phrase. The exact syntax of a message is defined in RFC 9112 (HTTP/1.1 message format). Semantics such as methods and status codes are specified independently of version in RFC 9110 (HTTP semantics).
HTTP methods and idempotency
A method states what the client intends to do with a resource. The keys to understanding methods are safety and idempotency. A safe method does not change the resource when called. An idempotent method leaves the server in the same state no matter how many times the same request is sent.
| Method | Safe | Idempotent | Primary use |
|---|---|---|---|
| GET | Yes | Yes | Retrieve a resource |
| POST | No | No | Create a new resource |
| PUT | No | Yes | Replace a resource entirely |
| PATCH | No | No | Modify part of a resource |
| DELETE | No | Yes | Delete a resource |
POST is not idempotent because calling it twice can create the resource twice. The same PUT overwrites the resource with the same value every time, so the result is unchanged. PUT and PATCH also differ in that PUT replaces the whole resource while PATCH changes only part of it.
Idempotency becomes the criterion for deciding whether to retry. When the server times out without a response, GET, PUT, and DELETE can be resent as they are. Retrying a POST, by contrast, can cause problems such as duplicate payments and needs a separate defense. The classification above follows the method definitions in RFC 9110.
Status codes and caching
A status code is a three-digit number in the response that reports the outcome of the request. The leading digit divides them into five classes.
| Class | Meaning | Examples |
|---|---|---|
| 1xx | Request received, processing | 100 Continue |
| 2xx | Processed successfully | 200 OK, 201 Created |
| 3xx | Further action needed (redirect, cache) | 301, 302, 304 |
| 4xx | Client error | 401, 403, 404 |
| 5xx | Server error | 500, 503 |
A client that receives an unknown code interprets it by its leading digit. A 299 is treated as a 2xx success and a 451 as a 4xx error, so clients do not need changing when new codes are added. Frequently confused pairs include 401 (authentication failure) versus 403 (authorization failure), and 301 (moved permanently) versus 302 (moved temporarily).
Cache control centers on 304 Not Modified and the Cache-Control directives. no-cache permits storage but requires revalidation with the server before use, while no-store forbids storage entirely. Revalidation sends an ETag or Last-Modified in a conditional request. If the resource is unchanged, the server returns only a 304 and does not resend the body.
Statelessness and cookies
HTTP is a stateless protocol. The server does not remember information from previous requests, so each request must carry what it needs on its own. That property lets any server produce the same response, which helps horizontal scaling.
The difficulty comes when state is required, as with login. HTTP itself knows nothing about state, so a separate mechanism is layered on. Cookies are the standard device: the server sends a value in a Set-Cookie header, the browser stores it and returns it in the Cookie header of later requests. The mechanism is defined in RFC 6265.
Sensitive information is normally kept out of the cookie, which holds only a session identifier. The real user state lives in the server-side session, and the cookie carries only the key that points to it. The baseline cookie security attributes are HttpOnly, Secure, and SameSite. HttpOnly blocks JavaScript access, Secure permits transmission over HTTPS only, and SameSite limits cross-site transmission.
How DNS turns a name into an address
Entering a domain in the browser first requires converting the name into an IP address. Resolution starts with caches: the browser cache and the operating system cache (including the hosts file). If neither has it, the query goes to the local DNS, a recursive resolver. The resolver then walks down through the root, TLD (top-level domain), and authoritative servers to find the final IP.
Recursive and iterative queries are distinct here. The flow where the client asks the local DNS once and receives the final answer is a recursive query. The flow where the local DNS receives only "where to ask next" from an upper server and queries each in turn itself is an iterative query. Typically the leg between client and local DNS is recursive, and the leg between local DNS and upper servers is iterative.
| Record | What it points to |
|---|---|
| A | IPv4 address of the domain |
| AAAA | IPv6 address of the domain |
| CNAME | Another domain name (alias) |
| MX | Mail server |
| NS | Authoritative name server for the domain |
| TXT | Arbitrary text (ownership verification and similar) |
The resolver caches a response for the duration of its TTL (time to live). A short TTL propagates changes faster; a long one reduces lookup load. The two trade off against each other. Caching negative responses (NXDOMAIN) for names that do not exist is also recommended, and RFC 2308 explains this in terms of traffic and response time. The naming system and the protocol itself are defined in RFC 1034 and RFC 1035, and 13 root server addresses are in operation (per root-servers.org).
The evolution of HTTP versions
What changes between versions is which transport carries the same HTTP semantics and how. The cause of performance differences has shifted from message format to transport characteristics.
| Version | Transport | Core | Remaining bottleneck |
|---|---|---|---|
| HTTP/1.1 | TCP | Connection reuse via Keep-Alive | Head-of-line blocking from response ordering |
| HTTP/2 | TCP | Stream multiplexing, HPACK header compression | TCP-level head-of-line blocking on packet loss |
| HTTP/3 | QUIC (UDP) | Per-stream independent loss recovery, QPACK | Resolves TCP head-of-line blocking |
HTTP/1.1 reused connections, but head-of-line (HOL) blocking was severe: one slow response held up the ones behind it. HTTP/2 reduced the HTTP-level bottleneck with multiplexing, which processes several streams concurrently over a single TCP connection, and HPACK header compression (RFC 7541). It still sits on TCP, however, so TCP-level HOL blocking remains: lose one packet and every stream waits together.
HTTP/3 addresses this by running over QUIC on UDP. QUIC recovers loss per stream and integrates TLS 1.3, allowing 1-RTT connection establishment. Header compression uses QPACK (RFC 9204). The specifications are RFC 9113 for HTTP/2, RFC 9114 for HTTP/3, and RFC 9000 for QUIC.
Summary
The application layer decides what is exchanged and in what format on top of the transport layer, and HTTP and DNS are its core. HTTP builds rules on top of its request-response message structure: method idempotency, status codes, caching, statelessness and cookies. DNS converts domain names into IP addresses through caching and recursive and iterative queries, holding consistency loosely through TTL. The evolution of HTTP versions is the process of carrying the same semantics over better transports, reaching HTTP/3 where even TCP head-of-line blocking is reduced. For deeper verification, the RFCs cited in the text are the primary sources.