4 min read
On this page

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.

Other Protocols

FTP (File Transfer Protocol)

Two connections: control (port 21) and data (port 20 or ephemeral). Active vs passive mode. Being replaced by SFTP/SCP.

SMTP / POP3 / IMAP (Email)

SMTP (port 25/587): Send email. Push protocol.

POP3 (port 110/995): Download and delete email from server.

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.