Application Layerb

Chapter 2: Application Layer

🔹 1. Key Concepts: Application Layer Overview

✅ What Is the Application Layer?

• Main Role: Enables network applications (e.g., web browsers, email, video streaming).

• Not part of network core: Runs only on end systems (hosts), not on routers/switches.

• Design Goal: Understand how apps use transport protocols to communicate.

✅ Two Architectures

💡 Key Insight: P2P = "Everyone is both client AND server." 💡 Tradeoff: P2P scales well, but hard to manage; client-server is simpler but bottlenecked at server.

🔹 2. Processes & Sockets

✅ Process Communication

• Same host: Use inter-process communication (IPC).

• Different hosts: Communicate via messages over network.

• Client process: Initiates communication.

• Server process: Waits to be contacted.

✅ Sockets: The “Door” to the Network

• Socket = interface between app and transport layer (TCP/UDP).

• Analogy: Like a mailbox or door — app pushes data out, transport delivers it.

• Two sockets per connection: One on client, one on server.

✅ Process Addressing: IP + Port

• IP address: Identifies host.

• Port number: Identifies process on that host.

• Example: gaia.cs.umass.edu:80 → Web server at IP 128.119.245.12, port 80.

• Well-known ports:
• HTTP → 80
• HTTPS → 443
• SMTP → 25
• DNS → 53
• FTP → 21
• POP3 → 110
• IMAP → 143

❗ Exam Tip: IP address alone is NOT enough — you need IP + port to identify a process.

🔹 3. Application-Layer Protocols: Requirements

✅ What Defines a Protocol?

1. Message types: Request, response, etc.

2. Syntax: Field structure, delimiters (e.g., CRLF).

3. Semantics: Meaning of fields (e.g., GET = request object).

4. Rules: When and how to send/respond.

✅ Transport Service Requirements by App

✅ Transport Protocols: TCP vs UDP

⚠️ Why UDP?

• Low latency (e.g., live video)

• No connection setup (e.g., DNS queries)

• App handles reliability (e.g., RTSP, QUIC)

🔹 4. Web & HTTP (CORE TOPIC)

✅ HTTP Basics

• HyperText Transfer Protocol

• Client-Server: Browser (client) ↔ Web server (server)

• Uses TCP: Port 80 (HTTP), 443 (HTTPS)

• Stateless: Server remembers nothing between requests.

✅ HTTP Connection Types

📌 Example: A webpage with 10 images =

• Non-persistent: 22 RTTs (2 RTT × 11 objects)

• Persistent: 2 RTTs (1 to open + 1 for all)

✅ HTTP Messages: Request & Response

➤ HTTP Request Format (GET example):

• Request Line: Method URI Version

• Headers: Key-value pairs

• Blank line ends headers

• Body: Optional (for POST/PUT)

➤ HTTP Response Format:

• Status Line: Version Code Phrase

• Headers

• Body: HTML, image, etc.

📌 HTTP Status Codes (Must Know!)

✅ HTTP Methods (Commands)

💡 GET can send data via URL (?key=value) — but only for small data.

🔹 5. Keeping State: Cookies

✅ Why Need Cookies?

• HTTP is stateless → server can’t remember who you are.

• Solution: Cookies → track user state across requests.

✅ Cookie Process (4 Components)

1. Server sends Set-Cookie: session_id=12345 in response.

2. Browser saves cookie in cookie file.

3. Browser includes Cookie: session_id=12345 in next request.

4. Server uses cookie to identify user → accesses backend DB.

✅ Cookie Uses

• Authentication (login sessions)

• Shopping carts

• Personalization (recommendations)

• User tracking

✅ Privacy & Third-Party Cookies

• First-party cookie: From site you visited (e.g., amazon.com)

• Third-party cookie: From tracker site (e.g., adX.com embedded in nytimes.com)
• Tracks you across multiple sites
• Used for targeted ads
• Disabled by default in Safari, Firefox; being phased out in Chrome

• GDPR (EU): Requires user consent → cookies = personal data if can identify you.

🔹 6. Web Caching (Proxy Servers)

✅ Purpose

• Reduce latency + reduce bandwidth on access link.

• Store copies of objects closer to user.

✅ How It Works

• Client → requests → web cache

• Cache → if object exists → deliver it (cache hit)

• Cache → if not → fetch from origin server, cache, deliver (cache miss)

✅ Cache Hit Rate = % requests served from cache

• Example: Hit rate = 0.4 → 40% hits, 60% misses

✅ Performance Improvement Example:

💡 Caching is cheaper & more effective than upgrading bandwidth!

✅ Conditional GET (Efficiency!)

• Client sends: If-Modified-Since: Tue, 01 Mar 2016 18:57:50 GMT

• Server responds with:
• 304 Not Modified → client uses cached copy (no data transfer)
• 200 OK + data → object updated

🔹 7. HTTP/2 & HTTP/3 / QUIC

✅ HTTP/1.1 Issue: HOL Blocking

• One large object blocks smaller ones (First-Come-First-Served).

• 1 TCP connection → packet loss stalls all.

✅ HTTP/2 (2015) Fixes:

• Multiplexing: Objects split into frames, interleaved → no HOL blocking.

• Server Push: Server sends resources it thinks client will need (e.g., CSS, JS).

• Header Compression: Reduces overhead.

• Still uses TCP.

✅ HTTP/3 (2022) → QUIC

• Over UDP, not TCP.

• Built-in encryption + authentication (TLS 1.3).

• 0-RTT or 1-RTT connection setup.

• Per-flow congestion control → no HOL blocking between streams.

• Better for mobile & unstable networks.

• Used by Google, YouTube, Chrome.

🔁 QUIC = UDP + TLS + Reliable Transport (TCP-like) in App Layer

🔹 8. Email: SMTP, POP3, IMAP

✅ 3 Components of Email System

1. User Agent (UA): Mail client (Outlook, iPhone Mail)

2. Mail Server: Stores inbox/outbox

3. SMTP: Protocol to send mail

✅ SMTP (Simple Mail Transfer Protocol)

• Reliable transfer via TCP (port 25)

• Three Phases:
1. Handshake (HELO)
2. Transfer (MAIL FROM, RCPT TO, DATA)
3. Closure (QUIT)

• ASCII only → binary data must be base64 encoded.

• Push protocol: Client pushes mail to server.

✅ SMTP Interaction Example:

✅ Email Message Format (RFC 2822)

• Headers (To, From, Subject)

• Blank line

• Body (ASCII text)

✅ SMTP vs HTTP:

• SMTP: Push → client sends to server

• HTTP: Pull → client requests from server

✅ Retrieving Mail: IMAP vs POP3

✅ Modern Use: IMAP (Gmail, Outlook) — emails synced across phones/computers.

🔹 9. DNS: Domain Name System

✅ Why DNS?

• Humans: www.amazon.com

• Machines: 54.240.10.10

• DNS = Translator (name ↔ IP)

✅ Why Distributed & Hierarchical?

• ❌ Centralized → Single point of failure, traffic overload

• ✅ Decentralized = scalable, reliable

✅ DNS Hierarchy (Top to Bottom)

✅ DNS Servers Types

✅ DNS Query Types

✅ Most DNS queries use recursion at local server → it does iterative on your behalf.

✅ DNS Record Types (RR) — MUST KNOW!

✅ DNS Caching & TTL

• DNS servers cache entries for TTL (Time To Live) seconds.

• Problems:
• Changes (e.g., IP change) take time to propagate.
• Outdated records → misrouting.

✅ DNS is best-effort → can be inaccurate.

✅ DNS Security (DNSSEC)

• Adds digital signatures → prevents spoofing & cache poisoning.

• Authenticates DNS responses.

✅ DNS Attack: DDoS

• Flooding root/TLD servers → disrupt Internet.

• Defenses:
• Local caching of TLD IPs
• Filtering
• Replication

🔹 10. Video Streaming & CDNs

✅ Challenges

• Scalability: 1B+ viewers

• Heterogeneity: Different bandwidths (mobile, wired)

• Jitter: Variable delays →_irq=planning playout

• Loss: Video packets may drop

✅ Video Coding

• Spatial coding: Compress within frame (e.g., repeated colors)

• Temporal coding: Compress between frames (e.g., only send changes)

• CBR: Constant Bitrate → Film

• VBR: Variable Bitrate → Internet → adaptive streaming

✅ Streaming Architecture

1. Video recorded → encoded → divided into chunks

2. Each chunk encoded at multiple bitrates

3. Client requests chunks via HTTP

4. Client chooses bitrate based on current bandwidth

✅ DASH: Dynamic Adaptive Streaming over HTTP

• Client:
• Estimates bandwidth
• Requests highest sustainable bitrate chunk
• Can change per chunk (e.g., from 1080p → 720p)

💡 DASH = Adaptation + HTTP + Chunking = Standard today (Netflix, YouTube)

✅ Content Distribution Networks (CDNs)

• Problem: Single server can’t handle 1M users → overload, latency.

• Solution: Replicate content across thousands of geographically distributed servers.

✅ CDN Example: Netflix

1. Netflix uploads movie to CDN nodes globally.

2. User requests video → DNS returns CDN URL (CNAME)

3. Client gets manifest file → picks closest/server with good bandwidth

4. Downloads chunk-by-chunk via HTTP (DASH)

🔥 Akamai: 240,000 servers → 1/4 of Internet traffic

💡 CDNs = Edge Computing → move content as close as possible to users.

🔹 11. Socket Programming (Python)

✅ Two Types of Sockets

✅ UDP Client-Server (Unreliable)

⚠️ No connection → address must be included in sendto().

✅ TCP Client-Server (Reliable)

⚠️ Key difference:

• TCP: Use connect() + accept() → connection established

• UDP: Send/receive without connection

✅ Handling Timeouts (Critical for Labs!)

• Used in RDT programming assignments (Chapter 3) — essential for timeouts!

🚨 Chapter 2: Exam Checklist (Must Know!)

🔚 Final Thoughts: Key Themes of Chapter 2

• Client-Server: Simple, centralized, brittle

• P2P: Scalable, decentralized, complex

• Stateless vs Stateful: HTTP vs Cookies

• Reliability: TCP vs UDP tradeoffs

• Scalability: CDNs, Caching, DASH

• Complexity at Edge: Everything real happens in apps (DNS, codecs, security)

• Use the Interface: Sockets abstract away network complexity

💬 “The Internet is designed to run on end systems—it’s not about infrastructure, it’s about applications.”

📘 Practice & Labs

• Use Wireshark → capture HTTP, DNS, SMTP traffic.

• Run the Python socket code examples.

• Try telnet gaia.cs.umass.edu 80 → send GET / HTTP/1.1\\r\\nHost: gaia.cs.umass.edu\\r\\n\\r\\n

• Practice traceroute + dig/nslookup for DNS.

✅ You now have a complete, exam-ready understanding of the Application Layer. Dig deeper into protocols — you’re ready for Chapter 3 (Transport Layer).