Application Layer Protocols
Above the transport layer, protocols are designed rather than derived, and the design space is small enough to characterise.
The organising fact is that every application protocol answers three questions: what messages exist, who speaks first, and what state is kept between messages.
DNS, HTTP, SMTP and FTP are four different answers. HTTP keeps no state and the client always speaks first. SMTP pushes rather than pulls. FTP keeps a control connection open across many transfers. DNS caches aggressively because its data changes rarely.
The second organising fact is that a protocol's transport choice follows from its message pattern. DNS uses UDP because a query and a reply each fit in one datagram and a handshake would triple the cost. Everything that transfers bulk data uses TCP.
The third is that statelessness is a deliberate scalability decision, not an oversight. HTTP servers can be replaced, load-balanced and restarted between any two requests precisely because no request depends on the last, and cookies exist to add back exactly as much state as an application needs.
1. Architectures
The client-server model has a always-on server at a known address and clients that initiate. It is simple, and the server is a bottleneck and a single point of failure.
Peer-to-peer has no always-on infrastructure, with peers serving each other directly. It scales with participation, because each new peer brings capacity as well as demand.
A hybrid uses a server for lookup and peers for transfer, which is how most practical file-sharing systems work.
The distribution time argument makes the difference concrete. Under client-server, the time to deliver a file to clients grows linearly with , because the server's upload capacity is divided among them.
Under peer-to-peer it grows far more slowly, since every peer that finishes becomes an additional source, so aggregate capacity rises with the number of participants rather than staying fixed.
2. DNS
DNS translates names to addresses, using a distributed hierarchical database with no single server holding everything.
The hierarchy has three tiers. Root servers know the top-level domain servers. Top-level domain servers know authoritative servers for each domain. Authoritative servers hold the actual records.
A local or recursive resolver does the work on a host's behalf and is the component that caches.
| Record | Purpose |
|---|---|
| A | Name to IPv4 address |
| AAAA | Name to IPv6 address |
| NS | Name of an authoritative server for a zone |
| CNAME | Alias to another name |
| MX | Mail exchanger for a domain, with a preference |
| PTR | Address to name, for reverse lookup |
| SOA | Zone parameters including timers |
An iterative query returns a referral: the server answers with the next server to ask rather than resolving it itself.
A recursive query asks the server to obtain the final answer, which is what a host asks its local resolver and what resolvers generally refuse to do for strangers.
Queries between servers are iterative in practice, which keeps load off the root.
Caching is what makes DNS work at all. Each record carries a time to live, and a cached entry answers immediately without any network traffic, which is why the root servers handle a manageable load despite naming the whole internet.
DNS uses UDP on port 53, falling back to TCP for responses exceeding the datagram limit and for zone transfers.
3. HTTP
HTTP is a request-response protocol over TCP, on port 80 or 443 with TLS.
It is stateless: the server retains nothing between requests.
Methods include GET to retrieve, POST to submit, PUT to store, DELETE to remove, and HEAD to fetch headers alone.
Status codes fall into five classes: 1xx informational, 2xx success, 3xx redirection, 4xx client error, 5xx server error. The ones worth knowing are 200, 301, 304, 400, 401, 403, 404 and 500.
HTTP/1.0 used a non-persistent connection per object, so each object cost a fresh TCP handshake.
HTTP/1.1 made connections persistent by default, reusing one connection for many objects, and added pipelining, which sends requests without waiting for replies.
Head-of-line blocking limits pipelining, since responses must return in order, and that limitation is what HTTP/2's multiplexed streams were designed to remove.
Cookies add state to a stateless protocol. The server sends a Set-Cookie header, the browser returns it on subsequent requests, and the server keys its own stored state on the value.
Conditional GET avoids re-transferring unchanged content. The client sends If-Modified-Since with its cached copy's date, and the server replies 304 Not Modified with no body if nothing changed.
A web cache or proxy serves requests on behalf of many clients, reducing both response time and upstream traffic, and uses conditional GET to stay fresh.
HTTP/2 and HTTP/3
HTTP/2 keeps the same semantics and changes the encoding. Methods, status codes and headers are unchanged; what differs is that the connection carries many interleaved streams and headers are compressed.
Multiplexing removes application-level head-of-line blocking, since a slow response no longer holds up the ones behind it on the same connection.
But TCP's own head-of-line blocking remains, because a single lost segment stalls delivery of every stream sharing that connection.
HTTP/3 solves that by moving to QUIC over UDP, where each stream is independently ordered, so a loss affecting one stream leaves the others untouched. It also folds the cryptographic handshake into the transport handshake, cutting a round trip from connection setup.
4. Electronic Mail
Three components exist: user agents, mail servers, and the protocols between them.
SMTP transfers mail between servers, on port 25, and it is a push protocol: the sending server connects to the receiving one and pushes.
SMTP is a persistent, command-response protocol using 7-bit ASCII, which is why anything else must be encoded.
MIME extends it with headers declaring content type and encoding, so images and non-English text travel as base64 or quoted-printable text.
Retrieval is a separate problem, because a recipient's machine is not always on and cannot receive a push.
POP3, on port 110, downloads and typically deletes. It is simple, stateless between sessions, and awkward across multiple devices, since messages live wherever they were downloaded.
IMAP, on port 143, keeps messages on the server with folders and server-side state, so every device sees the same mailbox. It is more complex and is what almost everything uses now.
HTTP-based webmail replaces the retrieval protocol entirely while still using SMTP between servers.
5. FTP
FTP uses two TCP connections, which is its defining and most examined feature.
The control connection on port 21 stays open for the whole session, carrying commands and replies.
A separate data connection carries each file transfer and is opened and closed per transfer.
This is called out-of-band control, and it contrasts with HTTP, which sends commands and data over one connection.
In active mode the server opens the data connection back to the client from port 20, which fails whenever the client is behind NAT or a firewall, since the inbound connection has nothing to match.
In passive mode the server listens and the client connects, which works through NAT and is now the default.
FTP maintains state across commands, including the current directory and transfer mode, which is why it needs the persistent control connection at all.
6. Worked Examples
Example 1. A host with a cold cache resolves www.example.co.in using iterative queries between servers. Count the messages.
The host sends a recursive query to its local resolver. That is 1 message.
The resolver queries a root server, which does not know the answer but returns a referral to the .in top-level domain servers. That is 2 more, a query and a reply.
The resolver queries the .in server, receiving a referral to the co.in servers. 2 more.
The resolver queries the co.in server, receiving a referral to example.co.in's authoritative servers. 2 more.
The resolver queries the authoritative server, which returns the A record. 2 more.
The resolver replies to the host. 1 more.
Total is messages, of which 8 are between servers.
Now repeat with a warm cache. If the resolver has cached the .in and co.in referrals, it queries only the authoritative server, giving messages.
If the A record itself is cached and unexpired, the answer costs 1 query and 1 reply, with no network traffic beyond the resolver.
That reduction from 10 to 2 is why DNS scales. The root servers would be unable to handle the internet's query volume without it, and record time to live values are chosen precisely to balance freshness against this load.
Example 2. A web page has a base HTML file and 8 embedded objects, all on one server. The round-trip time is 100 milliseconds and transmission time is negligible. Compare non-persistent HTTP with persistent HTTP.
Non-persistent HTTP opens a fresh TCP connection per object.
Each object costs 2 round trips: one for the TCP handshake and one for the request and response.
There are 9 objects in total, the base file plus 8.
But the base file must be fetched first, since its content names the others, so the fetches are sequential in that respect.
Total is milliseconds.
With 5 parallel connections, the 8 objects need 2 batches, so the cost is 2 round trips for the base plus 2 batches at 2 round trips each, giving round trips, or 600 milliseconds.
Persistent HTTP opens one connection and reuses it.
The handshake costs 2 round trips once, one for the TCP handshake and one for the first request and response of the base file.
Each subsequent object costs 1 round trip if requests are sent one at a time.
Total is round trips, which is 1000 milliseconds.
With pipelining, all 8 requests go out together, so they cost 1 round trip in total, giving round trips, or 300 milliseconds.
The ranking is instructive. Persistent with pipelining beats parallel non-persistent, and both crush plain non-persistent, which is exactly why HTTP/1.1 made persistence the default.
Example 3. Explain how cookies add state to a stateless protocol, and state what statelessness buys.
HTTP itself retains nothing between requests. Two requests from the same browser are, to the protocol, entirely unrelated.
On the first response, the server includes a Set-Cookie header carrying an identifier it has generated.
The browser stores it and returns it in a Cookie header on every subsequent request to that domain.
The server keeps the real state in its own database, keyed by that identifier.
So the state is not in the protocol. The cookie is only a key, and the protocol remains stateless in the sense that matters.
What statelessness buys is operational freedom. Any server in a pool can handle any request, since none depends on what a particular machine remembers, so servers can be added, removed or restarted between requests with no disruption.
The moment session state lives in server memory, that freedom is lost, which is why sticky sessions are considered a design problem and why session data is pushed into a shared store or into a signed cookie.
The privacy cost is the third-party cookie, where an identifier set by an advertising domain embedded in many sites lets that domain link a user's activity across all of them.
Example 4. Why does FTP use two connections, and what breaks when the client is behind NAT?
The control connection carries commands and replies for the whole session and stays open.
A separate data connection carries each transfer and closes when it completes.
The benefit is that control remains responsive during a transfer, so an abort command can be sent and acted on while a large file is in flight, which a single connection could not do without message framing.
The cost appears with NAT. In active mode, the client tells the server which port to connect to, and the server opens the data connection inbound.
A NAT device has no table entry for that inbound connection, since the client never sent anything from that port, so the connection attempt is dropped.
A firewall rejects it for the same reason, since it looks like an unsolicited inbound connection.
Passive mode inverts the direction. The server listens on a port, tells the client which one, and the client connects outbound.
Now NAT creates the table entry naturally, because the client initiated, and the transfer works.
A second NAT problem is specific to FTP's design. The port command carries an IP address inside the payload as text, and that address is the client's private one, which the server cannot reach.
Fixing it requires NAT to inspect and rewrite the payload, which is exactly the kind of protocol-specific special handling that layering was supposed to avoid.
Example 5. Why does email need both SMTP and IMAP rather than one protocol?
SMTP is a push protocol. The sending server opens a connection to the receiving server and pushes the message.
That works between servers because both are always on, with known addresses and mail exchanger records naming them.
It cannot work for the final delivery to a person. A laptop is off, asleep, behind NAT, and on a changing address, so no sending server could ever push to it.
So the message stops at the recipient's mail server, and retrieval must be a pull.
A pull is a fundamentally different interaction, initiated by the recipient at an arbitrary later time, so it needs its own protocol.
POP3 pulls by downloading and usually deleting, treating the server as a temporary holding area.
IMAP pulls by synchronising, leaving messages and folder structure on the server so several devices see one consistent mailbox.
The general principle is worth stating. Push suits always-on infrastructure with stable addresses, and pull suits intermittently connected clients, and no single protocol serves both well.
Example 6. A proxy cache holds a copy of a page fetched at 10:00. A client requests it at 10:30. Describe the exchange and its cost.
The cache checks whether its copy is still fresh by comparing the elapsed time against the response's cache-control or expiry headers.
If the copy is fresh, the cache returns it immediately with no upstream traffic at all, and the cost is one local round trip.
If it may be stale, the cache sends a conditional GET to the origin server with an If-Modified-Since header naming 10:00.
If nothing changed, the server replies 304 Not Modified with no body. The cache serves its stored copy.
The saving is the body, not the round trip. The upstream exchange still happens, so latency improves only slightly, while bandwidth improves enormously for large objects.
If the content did change, the server replies 200 with the full body, and the cache stores and forwards it.
The general effect of caching is to reduce upstream traffic and average latency, with the hit rate determined by how much content is shared between users and how aggressively time to live values are set.
Summary
Every application protocol answers what messages exist, who speaks first, and what state survives between messages, and the transport choice follows from the message pattern.
DNS is a hierarchical distributed database over UDP port 53, with root, top-level domain and authoritative tiers. Queries between servers are iterative; a host's query to its resolver is recursive. Caching with time to live values is what makes the system scale, cutting a ten-message cold resolution to two.
Records to know are A, AAAA, NS, CNAME, MX, PTR and SOA.
HTTP is stateless over TCP. Non-persistent connections cost two round trips per object; persistent connections cost two for the first and one per object thereafter; pipelining collapses the remainder into one. Head-of-line blocking limits pipelining, which HTTP/2 addressed with multiplexed streams.
Cookies add state without making the protocol stateful, and statelessness is what lets any server in a pool handle any request.
Conditional GET returns 304 with no body, saving bandwidth rather than round trips.
SMTP pushes mail between always-on servers using 7-bit ASCII, with MIME encoding everything else. Final delivery must be a pull, since a client machine is intermittently connected, which is why POP3 or IMAP exists. POP3 downloads and deletes; IMAP synchronises server-side folders.
FTP separates a persistent control connection on port 21 from a per-transfer data connection, giving out-of-band control. Active mode fails behind NAT because the server initiates inbound; passive mode inverts the direction and works. FTP also embeds an address in its payload, forcing NAT devices into protocol-specific rewriting.
HTTP/2 keeps HTTP's semantics and changes the encoding, multiplexing streams over one connection and compressing headers, which removes application-level head-of-line blocking but not TCP's. HTTP/3 removes that too by running over QUIC, where streams are independently ordered and the cryptographic handshake is folded into the transport handshake.
