The Application Layer — Where Humans Meet the Network
The Application Layer is exactly these services. DNS is the postal address directory — turning names into delivery addresses. HTTP is the standard letter service. FTP is the parcel service for large packages. SMTP is the outgoing letter department. SSH is the secure courier service for sensitive documents. Telnet is the old unsecured telegraph — fast but anyone can read it.
Each protocol defines its own language — the format of the envelope, the rules for the conversation, and what to do when something goes wrong.
The Application Layer (Layer 7 in the OSI model, the top of the TCP/IP stack) is where network-aware applications live. It is the only layer that end users and application developers directly interact with. Every URL you type, every email you send, every file you download, every SSH session you open — all of these are Application Layer protocols doing their work, invisibly, on top of the transport layer below.
Client-Server — one side always listens (server), the other
always initiates (client). HTTP, HTTPS, FTP, SMTP, DNS, and SSH all use this
model. Servers bind to well-known ports (80, 443, 21, 25, 53, 22). Clients
connect from random ephemeral ports.
Peer-to-Peer — every node can be both client and server.
BitTorrent, WebRTC (video calls), and blockchain networks use P2P. Less common
for the protocols in this tutorial, but critical for modern Internet architecture.
💡 Every protocol shown here operates above TCP or UDP — it relies on the transport layer for delivery and uses port numbers to identify itself to the OS. The protocol defines the language spoken over those sockets.
DNS — Domain Name System
DNS (RFC 1034/1035, 1987) is the Internet's phone book. Every device on the Internet communicates using IP addresses (e.g. 142.250.80.46), but humans use names (google.com). DNS translates between the two — a critical service so fundamental that without it, the entire web effectively ceases to function.
DNS Record Types
🏭 Animated: DNS Resolution — Full Recursive Query
💡 This full recursive resolution only happens on a cache miss. If your resolver already has the answer cached (within TTL), it answers immediately from cache — no queries to root or TLD servers. This is why popular domains like google.com resolve in <1ms locally but 50–200ms on first query.
On 21 October 2016, a Mirai botnet of 100,000+ IoT devices (cameras, routers, DVRs) launched a 1.2 Tbps DDoS attack against Dyn, a major DNS provider. Because DNS is hierarchical and centralised through managed providers, Dyn's outage meant that Twitter, Reddit, Netflix, GitHub, Spotify, and CNN became unreachable — not because their servers failed, but because their domain names could not be resolved. Without DNS, IP addresses are useless to end users who only know domain names. Source: Dyn post-mortem; Wired Magazine "The Botnet that Broke the Internet," Oct 2016.
HTTP & HTTPS — The Language of the Web
HTTP (HyperText Transfer Protocol), defined in RFC 9110 (2022), is the request-response protocol that powers every web page. A client (browser) sends an HTTP request; the server sends an HTTP response. That's it — deceptively simple, yet powerful enough to run the entire World Wide Web. HTTPS is HTTP tunnelled through TLS (Transport Layer Security) — identical in behaviour, but every byte is encrypted so no intermediate party can read or modify the content.
| Part | Example | Purpose |
|---|---|---|
| Request Line | GET /index.html HTTP/1.1 | Method + path + version |
| Host header | Host: www.example.com | Target domain (virtual hosting) |
| Accept | Accept: text/html | What formats client accepts |
| Cookie | Cookie: session=abc123 | Session state from prior response |
| Connection | Connection: keep-alive | Reuse TCP connection |
| Blank line | (CRLF) | End of headers |
| Body | JSON / form data | POST/PUT payload (optional) |
| Part | Example | Meaning |
|---|---|---|
| Status Line | HTTP/1.1 200 OK | Version + status code + phrase |
| Content-Type | Content-Type: text/html | Format of response body |
| Content-Length | Content-Length: 1234 | Body size in bytes |
| Set-Cookie | Set-Cookie: session=abc123 | Store cookie on client |
| Cache-Control | max-age=3600 | Browser caching instructions |
| Blank line | (CRLF) | End of headers |
| Body | HTML / JSON / image bytes | The actual content |
HTTP Status Codes — What Every Number Means
201 Created — resource created (POST).
204 No Content — success, no body (DELETE).
206 Partial Content — range request (video streaming).
302 Found — temporary redirect.
304 Not Modified — use your cache (ETags).
307/308 — preserve HTTP method on redirect.
401 Unauthorised — need to authenticate.
403 Forbidden — authenticated but no permission.
404 Not Found — resource does not exist.
HTTP Versions — Evolution of the Web Protocol
| Version | Year | Key Change | Transport | Status |
|---|---|---|---|---|
| HTTP/0.9 | 1991 | GET only, no headers, no status codes | TCP | Obsolete |
| HTTP/1.0 | 1996 | Headers, status codes, methods — new TCP per request | TCP | Obsolete |
| HTTP/1.1 | 1997 | Persistent connections, pipelining, chunked encoding | TCP | Still widely used |
| HTTP/2 | 2015 | Binary framing, multiplexing, header compression (HPACK) | TCP | Dominant (~65%) |
| HTTP/3 | 2022 | No head-of-line blocking, 0-RTT, encrypted by default | QUIC/UDP | Growing (~30%) |
🏭 Animated: HTTP Request-Response Cycle
💡 HTTP/1.1 can only send one request per TCP connection at a time (pipelining rarely works in practice). Browsers open 6 parallel TCP connections to work around this. HTTP/2 multiplexes all requests over one TCP connection, eliminating the bottleneck.
FTP — File Transfer Protocol
FTP (RFC 959, 1985) is one of the oldest application layer protocols still in use. It transfers files between a client and server using two separate TCP connections — a design peculiarity that causes endless firewall headaches but was revolutionary in the 1970s when it was designed.
FTP sends usernames, passwords, and all file data in plain text. Anyone on the same network can read every byte using Wireshark. This is why FTP has been replaced in almost all production environments by SFTP (SSH File Transfer Protocol — encrypted over SSH) or FTPS (FTP over TLS/SSL). SFTP runs over a single TCP connection on port 22 and has none of FTP's dual-channel complexity.
| Channel | Port | Purpose |
|---|---|---|
| Control | 21 (server) | Commands and responses: LOGIN, LIST, RETR, STOR, QUIT — persists for the session |
| Data | 20 (active) or ephemeral (passive) | Actual file data — opened per transfer, then closed |
Active mode: server connects back to client (breaks NAT). Passive mode: client opens data connection to server (works with NAT/firewalls). Always use passive mode behind a firewall.
| Protocol | Port | Encryption | Use Today |
|---|---|---|---|
| FTP | 21 | None — plain text | Legacy only |
| FTPS | 990/21 | TLS optional/implicit | Some legacy systems |
| SFTP | 22 | Always (SSH) | Preferred standard |
| SCP | 22 | Always (SSH) | Simple file copies |
SMTP — Simple Mail Transfer Protocol
SMTP (RFC 5321, 2008) is the protocol that transfers email between mail servers — and from your mail client to your outgoing mail server. It operates on a store-and-forward model: if the destination server is unreachable, the sending server queues the message and retries for up to 5 days before returning a bounce. Unlike most protocols, SMTP is human-readable plain text — you can manually conduct an SMTP session using telnet.
Port 587 (Submission) — email client to outgoing mail server. Requires authentication. The correct port for your email app's outgoing server setting.
Port 465 (SMTPS) — SMTP over implicit TLS (SSL). Older deprecated standard now seeing a revival.
Port 993 (IMAPS) — receive email over TLS (IMAP). Port 143 = unencrypted IMAP.
Port 995 (POP3S) — receive email over TLS (POP3). Port 110 = unencrypted POP3.
SPF (Sender Policy Framework) — a TXT DNS record listing which IP addresses may send email for your domain. Receiving servers reject others.
DKIM (DomainKeys Identified Mail) — the sending server cryptographically signs each message. Public key published in DNS. Receiving server verifies the signature.
DMARC — policy that tells receiving servers what to do with failures (reject, quarantine, or monitor) and where to send abuse reports.
Telnet & SSH — Remote Shell Access
Both Telnet and SSH allow a user to remotely control a machine over a network — typing commands as if physically present at the terminal. The difference is fundamental: Telnet sends everything in plain text — including passwords — visible to anyone on the network. SSH encrypts everything from the initial handshake onwards. Telnet is from 1969; SSH replaced it in 1995.
🏭 Animated: Telnet vs SSH — What Each Reveals to an Eavesdropper
💡 Telnet (port 23) transmits each keystroke as a separate TCP segment — in plain text. A network observer sees every character as you type, including your password. SSH (port 22) establishes a Diffie-Hellman key exchange before any data flows — the observer sees only random ciphertext. Telnet should never be used on any production system.
Public key auth: the server stores your public key; you prove ownership of the private key by signing a challenge. The private key never leaves your machine. Gold standard for server access.
SCP: Simple secure copy command.
Port forwarding: Forward a remote port to local (
ssh -L 8080:localhost:80 server) — tunnel any TCP service through SSH encryption. Used to bypass restrictive firewalls securely.Protocol Comparison & Real-World Cases
| Protocol | Port | Transport | Encrypted | Stateful | Primary Use |
|---|---|---|---|---|---|
| DNS | 53 | UDP (TCP for large) | Optional (DoH/DoT) | Stateless | Name resolution — every Internet service depends on it |
| HTTP | 80 | TCP | No — plain text | Session cookies | Web content delivery — declining, 443 preferred |
| HTTPS | 443 | TCP (or QUIC) | TLS 1.3 | TLS session + cookies | Secure web — 95%+ of web traffic |
| FTP | 21/20 | TCP (2 channels) | No — deprecated | Stateful session | Legacy file transfer — replaced by SFTP |
| SMTP | 25/587 | TCP | STARTTLS optional | Stateful session | Email delivery between servers and to MTA |
| SSH | 22 | TCP | Always (Diffie-Hellman) | Stateful session | Secure remote shell, SFTP, tunnelling |
| Telnet | 23 | TCP | No — plain text | Stateful session | Legacy remote shell — never use in production |
Golden Rules — Application Layer Protocols
~/.ssh/authorized_keys, then set PasswordAuthentication no
in sshd_config. Change SSH from the default port 22 to reduce automated scan noise.
p=reject
provides the strongest protection. Monitor DMARC reports for unauthorized senders
before setting the policy to reject — a gradual rollout prevents legitimate mail
being blocked.
The Application Layer is where networking becomes useful to
humans. Every protocol in this tutorial solves a specific problem that existed
before it:
DNS — humans cannot memorise IP addresses, so we invented
a distributed database of names. HTTP/HTTPS — we needed a
universal language for sharing hyperlinked documents, and a secure version of
it for the modern privacy-conscious web. FTP — files needed
to move between machines before the web existed. SMTP — email
needed a store-and-forward delivery system that worked even when the recipient
server was offline. SSH — Telnet was showing our passwords
to the world, so we built an encrypted replacement in 1995 and never looked back.
These seven protocols — DNS, HTTP, HTTPS, FTP, SMTP, Telnet, SSH — underpin
virtually every networked application you have ever used. Understanding their
mechanics, their security properties, and their failure modes is the foundation
of any serious career in networking, security, or software development.