Application Layer Protocols – DNS, HTTP, FTP, SMTP and Email Protocols Explained
What You Will Learn
- What the application layer is and how it interfaces with transport
- DNS — hierarchical name resolution, step by step
- HTTP/HTTPS — request/response model, methods, status codes
- FTP — active vs passive mode, how file transfer works
- Email protocols — SMTP, POP3, IMAP and how they differ
- DHCP, SNMP, and other important application protocols
- Socket programming: client-server model basics
1. Application Layer Overview
The application layer (Layer 7 in OSI, the topmost layer in both OSI and TCP/IP models) is where network-enabled applications and services live. It provides the interface between the software applications you use every day and the network stack below.
When your browser loads a webpage, it uses HTTP (application layer). When you send an email, your client uses SMTP. When you type a domain name, DNS resolves it. These are all application layer protocols — they define the rules (syntax, semantics, timing) for specific types of communication between applications.
Application layer protocols rely on the transport layer (TCP or UDP) for actual data delivery. The application protocol defines what to communicate; the transport protocol handles how to get it there reliably (or quickly).
Two Application Architectures
| Architecture | Description | Examples |
|---|---|---|
| Client-Server | Always-on server with fixed IP; clients connect on demand. Server provides services; client consumes them. | HTTP, FTP, SMTP, DNS |
| Peer-to-Peer (P2P) | No dedicated server; every host can be both client and server. Highly scalable; no central bottleneck. | BitTorrent, Skype (original), blockchain |
2. DNS – Domain Name System
DNS translates human-readable domain names (www.google.com) into IP addresses (142.250.190.78) that computers use to communicate. Without DNS, you’d have to memorise IP addresses to visit any website.
DNS is a hierarchical, distributed database. No single server knows all domain-to-IP mappings — the knowledge is distributed across thousands of servers worldwide, organised in a tree structure.
DNS Hierarchy
- Root DNS servers (13 sets): Know the addresses of all Top-Level Domain (TLD) nameservers. There are 13 root server IP addresses (actually hundreds of physical servers using anycast).
- TLD nameservers: Responsible for a top-level domain (.com, .org, .in, .uk). Know the addresses of authoritative nameservers for domains within their TLD.
- Authoritative nameservers: Know the actual IP addresses for a specific domain (e.g., google.com’s nameservers know the IP of www.google.com).
- Local DNS resolver: Your device’s configured DNS server (often from your ISP or a public DNS like 8.8.8.8). Caches results and queries other servers on your behalf.
DNS Resolution — Step by Step
1. Browser → Local DNS Resolver: “What’s the IP of www.example.com?”
2. Resolver (cache miss) → Root server: “Who handles .com?”
3. Root → Resolver: “Ask the .com TLD server at 192.5.6.30”
4. Resolver → .com TLD server: “Who handles example.com?”
5. .com TLD → Resolver: “Ask example.com’s authoritative server at 205.251.196.1”
6. Resolver → Authoritative server: “What’s the IP of www.example.com?”
7. Authoritative → Resolver: “It’s 93.184.216.34 (TTL: 3600s)”
8. Resolver (caches result) → Browser: “93.184.216.34”
9. Browser connects to 93.184.216.34 on port 80/443
DNS Record Types
| Record | Full Name | Purpose | Example |
|---|---|---|---|
| A | Address | Domain → IPv4 address | www.example.com → 93.184.216.34 |
| AAAA | IPv6 Address | Domain → IPv6 address | www.example.com → 2606:2800::1 |
| CNAME | Canonical Name | Alias → canonical domain name | mail.example.com → example.com |
| MX | Mail Exchange | Domain → mail server(s) for email | example.com → mail.example.com |
| NS | Nameserver | Domain → authoritative nameservers | example.com → ns1.example.com |
| TXT | Text | Arbitrary text data (SPF, DKIM, domain verification) | example.com → “v=spf1 …” |
| PTR | Pointer | IP address → domain (reverse DNS) | 34.216.184.93.in-addr.arpa → www.example.com |
Recursive: The resolver does all the work — client asks once and gets the final answer. (Client → Resolver is typically recursive.)
Iterative: Each server refers the querier to the next server — the resolver makes each query itself. (Resolver → Root/TLD/Authoritative is typically iterative.)
3. HTTP and HTTPS
HTTP (HyperText Transfer Protocol) is the foundation of the World Wide Web. It defines how browsers (clients) request resources and how web servers respond.
HTTP Request-Response Model
HTTP follows a simple request-response cycle:
- Client opens a TCP connection to the server (port 80 for HTTP, 443 for HTTPS)
- Client sends an HTTP request (method, URL, headers, optional body)
- Server processes the request and sends an HTTP response (status code, headers, body)
- Connection is closed (HTTP/1.0) or kept alive for more requests (HTTP/1.1 persistent)
HTTP Methods
| Method | Purpose | Body? | Idempotent? |
|---|---|---|---|
| GET | Retrieve a resource | No | Yes |
| POST | Submit data to create a resource | Yes | No |
| PUT | Replace a resource entirely | Yes | Yes |
| PATCH | Partially update a resource | Yes | No |
| DELETE | Delete a resource | No | Yes |
| HEAD | Same as GET but returns only headers (no body) | No | Yes |
| OPTIONS | Query supported methods for a URL | No | Yes |
HTTP Status Codes
| Range | Category | Common Codes |
|---|---|---|
| 1xx | Informational | 100 Continue, 101 Switching Protocols |
| 2xx | Success | 200 OK, 201 Created, 204 No Content |
| 3xx | Redirection | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 4xx | Client Error | 400 Bad Request, 401 Unauthorised, 403 Forbidden, 404 Not Found |
| 5xx | Server Error | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable |
HTTP Versions
| Version | Key Feature | Transport |
|---|---|---|
| HTTP/1.0 | New TCP connection per request | TCP |
| HTTP/1.1 | Persistent connections, pipelining | TCP |
| HTTP/2 | Multiplexing (multiple requests on one connection), header compression, server push | TCP (TLS) |
| HTTP/3 | Same as HTTP/2 but over QUIC (UDP-based), eliminates TCP head-of-line blocking | QUIC (UDP) |
HTTPS
HTTPS = HTTP + TLS. The TLS handshake happens before any HTTP data is exchanged:
- Client sends TLS ClientHello (supported cipher suites, TLS version)
- Server responds with ServerHello + its digital certificate
- Client verifies certificate against trusted Certificate Authorities (CAs)
- Key exchange (e.g., Diffie-Hellman) — both sides derive a shared session key
- All subsequent HTTP messages are encrypted with the session key
4. FTP – File Transfer Protocol
FTP transfers files between a client and server using two separate TCP connections: a control connection and a data connection.
- Control connection (port 21): Always open during the FTP session; carries commands (STOR, RETR, LIST, QUIT) and responses
- Data connection: Opened only when transferring files or directory listings; closed after each transfer
Active vs Passive Mode
| Feature | Active Mode | Passive Mode |
|---|---|---|
| Data connection initiated by | Server → Client | Client → Server |
| Server port for data | Port 20 | Random high port (server chosen) |
| Client sends | PORT command (with client IP + port) | PASV command |
| Firewall compatibility | Poor (client firewall blocks inbound) | Good (client initiates both connections) |
| Use case | Old server-side setups | Standard modern FTP |
5. Email Protocols: SMTP, POP3, IMAP
Email uses different protocols for sending vs receiving:
SMTP – Simple Mail Transfer Protocol
- Purpose: Sending email — from client to mail server, and from mail server to mail server
- Port: 25 (server-to-server), 587 (client-to-server, with authentication), 465 (SMTPS, deprecated)
- Transport: TCP
- How it works: Client establishes TCP connection → exchanges EHLO greeting → authenticates → sends commands (MAIL FROM, RCPT TO, DATA) → sends message body → QUIT
POP3 – Post Office Protocol 3
- Purpose: Downloading emails from server to client
- Port: 110 (plain), 995 (POP3S with TLS)
- Behaviour: Downloads all emails to the local device; deletes from server by default; not designed for multi-device access
- Use today: Legacy; mostly replaced by IMAP
IMAP – Internet Message Access Protocol
- Purpose: Synchronised email access across multiple devices
- Port: 143 (plain), 993 (IMAPS with TLS)
- Behaviour: Messages stay on the server; client syncs state (read/unread/deleted/folders); works across phone, laptop, tablet simultaneously
- Use today: Standard for modern email (Gmail, Outlook, Yahoo)
| Feature | POP3 | IMAP |
|---|---|---|
| Message storage | Local device (deleted from server) | Server (synced to devices) |
| Multi-device | Poor (messages downloaded once) | Excellent (all devices in sync) |
| Offline access | Yes (local copy) | Yes (with caching) |
| Server storage used | Minimal (messages removed) | Yes (messages stay on server) |
| Folders/organisation | Local only | Server-side (synced) |
Email Flow
1. Alice’s email client → Alice’s mail server (smtp.example.com) via SMTP
2. alice’s mail server → Google’s mail server (smtp.gmail.com) via SMTP (DNS MX lookup for gmail.com)
3. Email stored in Bob’s mailbox on Google’s server
4. Bob’s email client → Google’s server via IMAP (downloads/syncs the email)
5. Bob reads the email
6. Other Important Application Protocols
| Protocol | Port | Transport | Purpose |
|---|---|---|---|
| DHCP | 67/68 | UDP | Automatically assigns IP addresses to network devices (DORA process) |
| SNMP | 161/162 | UDP | Network management — monitors and manages network devices (routers, switches) |
| SSH | 22 | TCP | Encrypted remote shell access; replaces Telnet |
| Telnet | 23 | TCP | Legacy unencrypted remote shell (insecure — replaced by SSH) |
| NTP | 123 | UDP | Network Time Protocol — synchronises clocks across network devices |
| TFTP | 69 | UDP | Trivial FTP — simple file transfer with no authentication; used for booting network devices |
| LDAP | 389 | TCP | Lightweight Directory Access Protocol — queries directory services (Active Directory) |
| SIP | 5060 | UDP/TCP | Session Initiation Protocol — sets up VoIP calls |
7. Socket Programming Basics
A socket is the interface between an application and the network — the endpoint for communication. It’s identified by an IP address + port number + protocol. Socket programming is how applications actually use transport layer services.
TCP Socket Communication
1. socket() — create a socket
2. bind() — associate socket with a local IP + port
3. listen() — mark socket as passive (accepting connections)
4. accept() — block until a client connects; returns new socket for that client
5. read()/write() — exchange data
6. close() — close the connection
Client side:
1. socket() — create a socket
2. connect() — initiate connection to server IP + port (triggers three-way handshake)
3. write()/read() — exchange data
4. close() — close the connection
UDP Socket Communication
UDP sockets are simpler — no connection establishment. The server binds to a port; both sides use sendto()/recvfrom() which include the destination/source address in each call. No accept() or connect() needed.
Client-Server vs P2P
In the client-server model, servers have fixed, well-known addresses and are always listening. Clients initiate connections. In P2P, each peer can act as both client and server — it can both request and provide files, for example. BitTorrent uses a hybrid: a central tracker (client-server for coordination) with P2P data exchange between peers.
8. Common Misconceptions
- “SFTP is secure FTP”: SFTP is NOT FTP over SSH. SFTP (SSH File Transfer Protocol) is a completely different protocol that uses SSH for secure file transfer. FTPS is FTP with TLS — the actual secured version of FTP. They are unrelated protocols that happen to have similar names and similar purposes.
- “DNS only uses UDP”: DNS primarily uses UDP (faster, 53 byte max query fits in one UDP datagram), but switches to TCP when responses exceed 512 bytes (e.g., zone transfers between DNS servers, DNSSEC responses). DNS uses BOTH UDP and TCP on port 53.
- “HTTPS means the website is trustworthy”: HTTPS means the connection is encrypted and the server’s identity is verified by a certificate. It does NOT mean the website is legitimate or safe. Phishing sites routinely use HTTPS. The padlock means your communication is private; it says nothing about the site’s intentions.
- “POP3 and IMAP do the same thing”: Both are email retrieval protocols, but they work completely differently. POP3 downloads and removes emails from the server — once retrieved, they’re gone from the server. IMAP keeps emails on the server and syncs state across all devices. Using POP3 on your phone means those emails won’t be on your laptop.
- “HTTP/2 requires HTTPS”: The HTTP/2 specification does not require TLS. However, all major browsers only implement HTTP/2 over TLS in practice. So effectively, to use HTTP/2 in a browser, you need HTTPS — but this is a browser policy choice, not a protocol requirement.
9. Frequently Asked Questions
How does DNS work step by step?
When you type a domain name: (1) Browser checks its cache; (2) OS checks local DNS cache and /etc/hosts; (3) Local DNS resolver is queried; (4) Resolver queries root nameserver → gets TLD nameserver address; (5) Resolver queries TLD nameserver → gets authoritative nameserver address; (6) Resolver queries authoritative nameserver → gets actual IP; (7) Resolver caches the result per TTL and returns IP to browser; (8) Browser connects to the IP. This entire process typically takes under 100ms, and most subsequent queries hit the cache.
What is the difference between HTTP and HTTPS?
HTTP sends data in plain text — readable by anyone intercepting the traffic. HTTPS encrypts HTTP with TLS: a TLS handshake verifies the server’s identity via digital certificates, then establishes an encrypted session key. All HTTP requests and responses are encrypted. HTTPS uses port 443; HTTP uses port 80. Modern browsers require HTTPS for sensitive features (camera, location, notifications) and display security warnings for HTTP sites. HTTPS protects against eavesdropping and man-in-the-middle attacks, but does not guarantee the website is trustworthy.
What is the difference between POP3, IMAP, and SMTP?
SMTP (port 25/587) sends email — from your client to your mail server, and between mail servers. POP3 (port 110) receives email — downloads messages to your device and typically deletes them from the server; one-device design. IMAP (port 143) receives email — keeps messages on the server and syncs across all your devices; changes reflected everywhere. Modern email systems use SMTP for sending and IMAP for receiving. POP3 is legacy and only appropriate if you only use one device for email.
What is the difference between FTP active and passive mode?
Both modes use port 21 for control commands. In Active Mode, the client tells the server its IP+port via PORT command; the server initiates the data connection from its port 20 to the client — fails through most client firewalls. In Passive Mode, the client sends PASV; the server replies with its IP+port; the client initiates the data connection to the server — works through firewalls since the client initiates both connections. Passive mode is the standard choice for modern FTP clients.