Application Layer Protocols
641 words
3 min read
Visual companion
Python
Type and operator map
Python Week 1: the first filter for runtime behavior
View
Revision summary
What this note is really saying
Short form
# Application Layer Protocols ## 🎯 Learning Objectives - Explain HTTP request/response cycle and methods - Trace DNS resolution from browser to root server - Understand email delivery via SMTP, POP3, IMAP - Compare HTTP/1.1, HTTP/2, and HTTP/3 - Analyze protocol message formats * * * ## 1. HTTP Protocol ### 1.1 Req...

Application Layer Protocols
🎯 Learning Objectives
- Explain HTTP request/response cycle and methods
- Trace DNS resolution from browser to root server
- Understand email delivery via SMTP, POP3, IMAP
- Compare HTTP/1.1, HTTP/2, and HTTP/3
- Analyze protocol message formats
1. HTTP Protocol
1.1 Request-Response Cycle
(Diagram)
1.2 HTTP Methods
| Method | Purpose | Safe? | Idempotent? |
|---|---|---|---|
| GET | Retrieve resource | Yes | Yes |
| HEAD | Get headers only | Yes | Yes |
| POST | Submit data | No | No |
| PUT | Replace resource | No | Yes |
| DELETE | Remove resource | No | Yes |
| PATCH | Partial update | No | No |
1.3 Status Codes
| Code | Meaning | Example |
|---|---|---|
| 1xx | Informational | 101 Switching Protocols |
| 2xx | Success | 200 OK, 201 Created |
| 3xx | Redirection | 301 Moved, 304 Not Modified |
| 4xx | Client Error | 404 Not Found, 403 Forbidden |
| 5xx | Server Error | 500 Internal Error, 503 Unavailable |
1.4 HTTP Versions
| Version | Year | Features |
|---|---|---|
| HTTP/1.0 | 1996 | Basic, one request per TCP |
| HTTP/1.1 | 1997 | Persistent connections, pipelining |
| HTTP/2 | 2015 | Multiplexing, header compression, server push |
| HTTP/3 | 2022 | QUIC (UDP-based), no head-of-line blocking |
2. DNS (Domain Name System)
2.1 Hierarchy
(Diagram)
2.2 Resolution Steps
| Step | Server | Query | Response |
|---|---|---|---|
| 1 | Local cache | www.example.com? | Miss |
| 2 | Recursive resolver | www.example.com? | — |
| 3 | Root server | .com nameserver? | a.gtld-servers.net |
| 4 | TLD server | example.com nameserver? | ns1.example.com |
| 5 | Authoritative | www.example.com? | 93.184.216.34 |
| 6 | Local resolver | — | Cache: 93.184.216.34 |
2.3 Record Types
| Type | Purpose | Example |
|---|---|---|
| A | IPv4 address | example.com → 93.184.216.34 |
| AAAA | IPv6 address | example.com → 2606:2800:220:1:... |
| CNAME | Canonical name (alias) | www → example.com |
| MX | Mail server | @example.com → mail.example.com |
| NS | Nameserver | example.com → ns1.example.com |
| TXT | Arbitrary text | SPF, DKIM verification |
| SOA | Start of Authority | Zone transfer info |
3. Email: SMTP, POP3, IMAP
3.1 SMTP Delivery
(Diagram)
3.2 Full Email Flow
- Alice composes email → MUASender (User Agent)
- MUA sends to MTA (Message Transfer Agent) via SMTP (port 25/587)
- MTA queries DNS for MX record of recipient domain
- MTA relays to recipient's MTA via SMTP
- Recipient MTA stores in mailbox
- Bob retrieves via POP3 (download) or IMAP (sync)
3.3 POP3 vs IMAP
| Feature | POP3 | IMAP |
|---|---|---|
| Port | 110 (SSL: 995) | 143 (SSL: 993) |
| Storage | Local | Server |
| Multiple devices | No | Yes |
| Server folders | No | Yes |
| Offline access | Yes (downloaded) | Optional |
4. FTP (File Transfer Protocol)
| Mode | Description |
|---|---|
| Active | Client: random port → server:21 (control). Server:20 → client:random (data) |
| Passive | Client: random → server:21 (control). Client: random → server:random (data) |
Passive mode works through firewalls (client initiates both connections).
5. Common Pitfalls
Pitfall: Confusing DNS Caching Levels
The mistake: Not understanding that changes to DNS records take time to propagate.
Correct approach: Browser (seconds-minutes), OS (minutes), resolver (hours-days), TLD cache (days). TTL values determine caching duration. Lower TTL for planned changes.
6. Key Concepts Reference
| Protocol | Port | Transport | Use Case |
|---|---|---|---|
| HTTP | 80 | TCP | Web browsing |
| HTTPS | 443 | TCP/TLS | Secure web |
| DNS | 53 | UDP/TCP | Name resolution |
| SMTP | 25/587 | TCP | Email sending |
| POP3 | 110 | TCP | Email receiving |
| IMAP | 143 | TCP | Email sync |
| FTP | 20/21 | TCP | File transfer |
| SSH | 22 | TCP | Secure shell |
7. 📝 Practice Questions
Q1: Trace DNS resolution for www.iitm.ac.in from a browser.Answer:
- Browser checks local DNS cache
- OS checks resolver cache (usually your ISP or 8.8.8.8)
- Resolver queries root server → .in TLD server
- .in TLD → ac.in nameserver
- ac.in → iitm.ac.in authoritative nameserver
- iitm.ac.in returns 103.xxx.xxx.xxx (A record)
- Cache the result (respecting TTL) Q2: A POST request returned 301. What happened?
Answer: 301 Moved Permanently means the resource URL changed. Browser should follow the Location header redirect. For POST, browser typically converts to GET for the redirected request (unless 307/308 status). This is a common issue with API design. Q3: Why does HTTP/3 use UDP instead of TCP?Answer: HTTP/3 runs over QUIC, which uses UDP. Benefits: (1) Zero round-trip connection establishment (vs. TCP's 3-way handshake + TLS). (2) No head-of-line blocking (one lost packet doesn't block all streams). (3) Connection migration (survives IP address changes). (4) Built-in encryption. QUIC is a transport protocol implemented in userspace, allowing faster deployment. Q4: Calculate time to resolve a DNS query with 4 levels of recursion, each taking 50ms RTT.Answer: Total = 4 × 50ms = 200ms for the first query. Subsequent queries are cached: browser cache (instant if cached), OS cache (~ms), resolver cache (instant). First query is slow; subsequent queries are fast due to negative caching too.
8. 🔗 Cross-References
- Week 2 - TCP/UDP: Transport layer foundation
- Week 3 - IP Routing: Network layer
- BSCS4003 (Privacy & Security): HTTPS/TLS Join Discord PreviousData Link & PhysicalNextNetwork Security