Application Layer

The application layer provides network services directly to end users and applications. This file covers the major application-layer protocols.

DNS (Domain Name System)

DNS translates human-readable names (www.example.com) to IP addresses (93.184.216.34).

Hierarchy

Root (.)
├── com.
│   ├── google.com.
│   │   ├── www.google.com.
│   │   └── mail.google.com.
│   └── example.com.
├── org.
│   └── wikipedia.org.
├── net.
├── io.
└── uk.
    └── co.uk.

Resolution Process

DNS resolution flow — client to resolver to root to TLD to authoritative

1. Client queries local resolver (recursive resolver, typically ISP or 8.8.8.8)
2. Resolver checks cache → if cached, return immediately
3. Resolver queries root name server → "Ask .com TLD server"
4. Resolver queries .com TLD server → "Ask ns1.example.com"
5. Resolver queries ns1.example.com (authoritative) → "93.184.216.34"
6. Resolver caches the result (TTL-based) and returns to client

Iterative: Resolver does the walking. Recursive: Each server queries the next.

Record Types

Type	Purpose	Example
A	IPv4 address	example.com → 93.184.216.34
AAAA	IPv6 address	example.com → 2606:2800:220:1:248:...
CNAME	Canonical name (alias)	www.example.com → example.com
MX	Mail exchange	example.com → mail.example.com (priority 10)
NS	Name server	example.com → ns1.example.com
TXT	Text (SPF, DKIM, verification)	"v=spf1 include:_spf.google.com ~all"
SRV	Service location	_sip._tcp.example.com → sipserver.example.com:5060
SOA	Start of authority	Zone metadata (serial, refresh, retry)
PTR	Reverse lookup (IP → name)	34.216.184.93.in-addr.arpa → example.com

Caching and TTL

Each record has a Time-To-Live (TTL). Resolvers cache records until TTL expires. Lower TTL = faster propagation of changes but more queries. Typical: 300s - 86400s.

DNSSEC

Cryptographic signing of DNS records. Prevents DNS spoofing/cache poisoning.

Chain of trust: Root → TLD → domain. Each level signs the next level's keys. Client can verify the entire chain.

HTTP (HyperText Transfer Protocol)

The protocol of the World Wide Web.

HTTP/1.1

Request:

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
Connection: keep-alive

Response:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1234
Cache-Control: max-age=3600

<!DOCTYPE html>...

Methods: GET (read), POST (create), PUT (replace), PATCH (update), DELETE, HEAD, OPTIONS.

Status codes:

Range	Meaning	Examples
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 Unauthorized, 403 Forbidden, 404 Not Found
5xx	Server error	500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable

Persistent connections (keep-alive): Reuse TCP connection for multiple requests. Default in HTTP/1.1.

Pipelining: Send multiple requests without waiting for responses. Limited adoption due to head-of-line blocking (responses must be in order).

Cookies: Server sets cookies (Set-Cookie header). Client sends them back on subsequent requests (Cookie header). Used for session management, personalization, tracking.

HTTP/2

Binary framing: Requests/responses split into binary frames (not text). More efficient parsing.

Multiplexing: Multiple streams (requests/responses) over a single TCP connection. No head-of-line blocking at the HTTP level (but still at TCP level).

Server push: Server proactively sends resources the client hasn't requested yet (e.g., CSS after receiving an HTML request).

Header compression (HPACK): Compresses HTTP headers using a shared dictionary and Huffman encoding. Significant savings (headers can be 500+ bytes).

Stream prioritization: Client indicates priority of streams. Server can serve important resources first.

HTTP/3

Built on QUIC (UDP-based). Eliminates TCP's head-of-line blocking.

Benefits over HTTP/2:

No TCP head-of-line blocking (QUIC streams are independent)
0-RTT connection setup (for repeat connections)
Connection migration (survives network changes)
Mandatory encryption

HTTPS / TLS

HTTPS = HTTP over TLS (Transport Layer Security).

TLS 1.3 handshake (1-RTT):

Client                          Server
  │── ClientHello ─────────────→│  (supported ciphers, key share)
  │                              │
  │←── ServerHello, Certificate──│  (selected cipher, key share, cert)
  │    Finished                  │
  │                              │
  │── Finished ────────────────→│
  │                              │
  │  Application data (encrypted) │

Certificate validation: Server presents X.509 certificate signed by a Certificate Authority (CA). Client verifies the chain to a trusted root CA.

Cipher suites (TLS 1.3): TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256.

IMAP (port 143/993): Access email on server. Sync across devices. Folders, search, flags.

SSH (Secure Shell)

Encrypted remote access. Port 22. Key-based or password authentication.

Uses: Remote shell, file transfer (SCP/SFTP), port forwarding (tunneling), Git transport.

WebSocket

Full-duplex communication over a single TCP connection. Upgrade from HTTP.

Client: GET /chat HTTP/1.1
        Upgrade: websocket
        Connection: Upgrade

Server: HTTP/1.1 101 Switching Protocols
        Upgrade: websocket

After handshake: bidirectional message passing. No HTTP overhead per message.

Use cases: Chat, real-time notifications, live dashboards, multiplayer games, collaborative editing.

Applications in CS

Web development: Understanding HTTP methods, status codes, headers, cookies is essential for building web APIs.
System design: DNS for service discovery. HTTP for APIs. WebSocket for real-time. TLS for security.
Performance: HTTP/2 multiplexing, HTTP/3 (QUIC), DNS prefetch, CDN cache headers.
Security: HTTPS everywhere. HSTS headers. Certificate management. DNSSEC.
DevOps: DNS configuration, certificate management (Let's Encrypt), reverse proxy setup (nginx).
Debugging: curl, httpie, Wireshark, browser DevTools network tab.