๐Ÿ“ก CHAPTER 2: APPLICATION LAYER

Fundamental Concepts ยท Architectures ยท TCP vs UDP ยท HTTP ยท Email ยท DNS ยท Security ยท Throughput
๐Ÿ“„ Complete PDF: Pages 1โ€“13 | All Q&A + Essays + Comparisons
๐Ÿ“‘ Page 1-2๐Ÿ”‘ Core definitions: Application Layer, Processes, Sockets
๐Ÿ“Œ 1. Application Layer Fundamentals

โ“ Q1: What is Application Layer?

  • Top layer of Internet protocol stack
  • Provides network services to applications
  • Defines communication rules between apps
  • Runs on end systems (not routers)
  • Examples: Web, Email, File Transfer

โ“ Q2: Why apps developed only at end systems?

  • Routers only forward packets
  • Core network unchanged
  • Allows fast development & deployment
  • No need to modify Internet infrastructure

โš™๏ธ Q3: What is a Process?

  • A running program on a host
  • Processes communicate by sending messages
  • Same-host: OS communication (pipes, shared memory)
  • Different hosts: network communication
  • Client process initiates; Server process waits

๐Ÿšช Q4: What is a Socket?

  • Interface between application & transport layer
  • Acts like a communication "door"
  • Sending process writes to socket
  • Receiving process reads from socket
  • Developer controls app side; OS controls transport side
Socket API: socket(), bind(), listen(), accept()

๐Ÿ”ข Q5: How is a process identified?

  • By IP address (identifies host)
  • By Port number (identifies process)
  • Complete identification = (IP + Port)
  • Example: HTTP โ†’ port 80, SSH โ†’ port 22
๐Ÿ“Œ Summary: Application layer is topmost layer. Processes communicate via messages through sockets. Each process is uniquely identified by (IP address, Port number).
ุงู„ู…ูุงู‡ูŠู… ุงู„ุฃุณุงุณูŠุฉ: ุทุจู‚ุฉ ุงู„ุชุทุจูŠู‚ุงุช ู‡ูŠ ุฃุนู„ู‰ ุทุจู‚ุฉุŒ ุชู‚ุฏู… ุฎุฏู…ุงุช ุงู„ุดุจูƒุฉ ู„ู„ุชุทุจูŠู‚ุงุชุŒ ุชุนู…ู„ ุนู„ู‰ ุงู„ุฃู†ุธู…ุฉ ุงู„ุทุฑููŠุฉ ูˆู„ูŠุณ ุงู„ู…ูˆุฌู‡ุงุช. ุงู„ุนู…ู„ูŠุงุช ู‡ูŠ ุจุฑุงู…ุฌ ู‚ูŠุฏ ุงู„ุชุดุบูŠู„ ุชุชูˆุงุตู„ ุนุจุฑ ุฑุณุงุฆู„. ุงู„ู…ู‚ุจุณ (Socket) ู‡ูˆ ูˆุงุฌู‡ุฉ ุจูŠู† ุทุจู‚ุฉ ุงู„ุชุทุจูŠู‚ ูˆุทุจู‚ุฉ ุงู„ู†ู‚ู„. ุชูุนุฑู‘ู ุงู„ุนู…ู„ูŠุฉ ุนุจุฑ IP + ู…ู†ูุฐ.
๐Ÿ“‘ Page 2-3๐Ÿ›๏ธ Client-Server vs P2P Architectures
๐Ÿ” 2. Network Application Architectures

๐Ÿ–ฅ๏ธ Q6: Client-Server

  • Server always on, permanent IP address
  • Clients initiate communication
  • Clients may have dynamic IP
  • Clients do not communicate directly
  • Centralized control, easier management
  • Requires powerful servers, scales by adding servers

๐Ÿค Q7: Peer-to-Peer (P2P)

  • No always-on central server
  • Peers communicate directly
  • Each peer acts as client & server
  • Self-scalable (Q8: each new peer adds demand AND capacity)
  • Peers join and leave dynamically
  • Harder management but highly scalable
โ“ Q9: Compare Client-Server & P2P
โ€ข Client-Server: Centralized control, easier management, scales by adding servers.
โ€ข P2P: No central server, self-scalable, dynamic environment, harder management.
Client-Server: ุฎุงุฏู… ุฏุงุฆู…ุŒ ุนู…ู„ุงุก ูŠุจุฏุฃูˆู† ุงู„ุงุชุตุงู„. P2P: ู„ุง ูŠูˆุฌุฏ ุฎุงุฏู… ู…ุฑูƒุฒูŠุŒ ุงู„ุฃู‚ุฑุงู† ูŠุชุตู„ูˆู† ู…ุจุงุดุฑุฉุŒ ูƒู„ ู†ุธูŠุฑ ุฎุงุฏู… ูˆุนู…ูŠู„ุŒ ุฐุงุชูŠ ุงู„ุชูˆุณุน.
๐Ÿ“‘ Page 3-4๐Ÿ“ฆ Transport Services: Reliability, Throughput, Timing
๐Ÿšš 3. Transport Layer Services

๐Ÿ“‹ Q10: Required transport services

  • Reliable data transfer (no loss, no errors)
  • Throughput guarantee (bandwidth assurance)
  • Timing guarantee (delay bounds)
  • Security (encryption & integrity)

๐Ÿ”’ Q11: Data Integrity

  • Data arrives without errors
  • No loss during transmission
  • No duplication of packets
  • Ensured by checksums and ACKs in TCP

๐Ÿ“Š Q12: Elastic Application

  • Adapts to available bandwidth
  • No strict throughput requirement
  • Can work with "as much as available"
  • Example: Web browsing, email, file transfer
ุฎุฏู…ุงุช ุงู„ู†ู‚ู„: ู†ู‚ู„ ู…ูˆุซูˆู‚ุŒ ุถู…ุงู† ุงู„ุฅู†ุชุงุฌูŠุฉุŒ ุถู…ุงู† ุงู„ุชูˆู‚ูŠุชุŒ ุงู„ุฃู…ุงู†. ุณู„ุงู…ุฉ ุงู„ุจูŠุงู†ุงุช: ูˆุตูˆู„ ุจุฏูˆู† ุฃุฎุทุงุก ุฃูˆ ูู‚ุฏ ุฃูˆ ุชูƒุฑุงุฑ. ุงู„ุชุทุจูŠู‚ุงุช ุงู„ู…ุฑู†ุฉ: ุชุชูƒูŠู ู…ุน ุนุฑุถ ุงู„ู†ุทุงู‚ ุงู„ู…ุชุงุญ (ู…ุซู„ ุชุตูุญ ุงู„ูˆูŠุจ).
๐Ÿ“‘ Page 4-6โšก TCP vs UDP Comparison + Throughput
๐Ÿ“ก 4. TCP vs UDP & Throughput

๐Ÿ”ท Q13: TCP Features

  • Reliable data transfer (ACKs + retransmission)
  • Flow control (receiver doesn't get overwhelmed)
  • Congestion control (avoids network collapse)
  • Connection-oriented (3-way handshake)
  • Full-duplex communication
  • No built-in encryption

๐Ÿ”ถ Q14: UDP Features

  • Unreliable (no ACKs, no retransmission)
  • No congestion control
  • No flow control
  • Connectionless (no handshake)
  • Low delay, small header overhead (8 bytes)
  • Suitable for real-time apps
๐Ÿ“Œ Feature
โœ… TCP
โšก UDP
Reliability
โœ… Reliable (ACKs, retransmission)
โŒ Unreliable
Congestion Control
โœ… Yes
โŒ No
Connection
Connection-oriented
Connectionless
Speed
Slower (overhead)
Faster (low delay)
Use Cases
Web, Email, File transfer
VoIP, Streaming, DNS, Gaming
โ“ Q15: Why choose UDP? โ†’ Lower delay, no connection setup time, suitable for real-time applications, can tolerate some packet loss.
โ“ Q16: Throughput Definition โ†’ Rate of successful data transfer. End-to-end throughput = min(R1, R2, ..., Rn) (bottleneck link).
๐Ÿ“ End-to-End Throughput = min(R1, R2, R3, ..., Rn)
TCP: ู…ูˆุซูˆู‚ุŒ ุชุญูƒู… ุจุงู„ุงุฒุฏุญุงู…ุŒ ู…ูˆุฌู‡ ู„ู„ุงุชุตุงู„ุŒ ุฃุจุทุฃ. UDP: ุบูŠุฑ ู…ูˆุซูˆู‚ุŒ ุจุฏูˆู† ุชุญูƒู… ุจุงู„ุงุฒุฏุญุงู…ุŒ ุฃู‚ู„ ุชุฃุฎูŠุฑุŒ ู…ู†ุงุณุจ ู„ู„ุชุทุจูŠู‚ุงุช ุงู„ูˆู‚ุช ุงู„ุญู‚ูŠู‚ูŠ. ุงู„ุฅู†ุชุงุฌูŠุฉ = ุฃู‚ู„ ุณุฑุนุฉ ููŠ ุงู„ู…ุณุงุฑ.
๐Ÿ“‘ Page 6-8๐ŸŒ HTTP Protocol: Stateless, Methods, Response Codes
๐ŸŒ 5. HTTP โ€“ HyperText Transfer Protocol

โ“ Q17: What is HTTP?

  • Application-layer protocol of the Web
  • Uses TCP, default port 80
  • Client-server model
  • HTTPS uses port 443 with TLS

โ“ Q18: Why is HTTP stateless?

  • Server does NOT store client information
  • Simplifies server design
  • Easier crash recovery (no session state to lose)
  • Better scalability (add more servers easily)
  • Solution for state: Cookies

โฑ๏ธ Q19: Non-Persistent HTTP

  • One TCP connection per object
  • 2 RTT per object (TCP handshake + HTTP request/response)
  • Connection closed after each response
  • Higher delay, more overhead

๐Ÿ”„ Q20: Persistent HTTP

  • Single TCP connection for multiple objects
  • Connection remains open after response
  • Fewer RTTs, more efficient
  • Default in HTTP/1.1 and later
๐Ÿ“Œ Feature
๐Ÿ” Non-Persistent HTTP (HTTP/1.0)
๐Ÿ”„ Persistent HTTP (HTTP/1.1+)
TCP Connection
Separate connection for each object (HTML, images, CSS)
Single TCP connection for multiple objects
RTT Overhead
2 RTT per object
Only 1 initial RTT for handshake
Connection Close
Server closes after each response
Connection remains open (timeout or explicit close)
Delay
Higher delay, more network overhead
Lower delay, faster page loading
โ“ Q21: HTTP request parts: Request line (method + URL + version), header lines (Host, User-Agent, etc.), optional body.
โ“ Q22: GET vs POST: GET retrieves data (data in URL, limited size, cached); POST sends data in body (form submission, unlimited, not cached).
โ“ Q23: Common HTTP response codes: 200 OK, 301 Moved Permanently, 400 Bad Request, 404 Not Found, 505 HTTP Version Not Supported.
HTTP: ุจุฑูˆุชูˆูƒูˆู„ ู†ู‚ู„ ุงู„ู†ุต ุงู„ุชุดุนุจูŠุŒ ุนุฏูŠู… ุงู„ุญุงู„ุฉ (stateless). ุบูŠุฑ ุงู„ู…ุณุชู…ุฑ: ุงุชุตุงู„ ูˆุงุญุฏ ู„ูƒู„ ูƒุงุฆู† (2 RTT). ุงู„ู…ุณุชู…ุฑ: ุงุชุตุงู„ ูˆุงุญุฏ ู„ูƒู„ ุนุฏุฉ ูƒุงุฆู†ุงุชุŒ ูƒูุงุกุฉ ุฃูุถู„. GET ูŠุฌู„ุจ ุจูŠุงู†ุงุชุŒ POST ูŠุฑุณู„ ุจูŠุงู†ุงุช ููŠ ุงู„ุฌุณู….
๐Ÿ“‘ Page 8-9๐Ÿช Cookies & User State Management
๐Ÿช 6. Cookies โ€“ Maintaining State over Stateless HTTP

โ“ Q24: Why are cookies needed?

  • HTTP is stateless โ†’ cannot remember users
  • Cookies maintain user state across requests
  • Used for login sessions, shopping carts, personalization, tracking

โ“ Q25: Four components of cookies

  • 1. Cookie header in HTTP response (Set-Cookie)
  • 2. Cookie header in HTTP request (Cookie)
  • 3. Cookie file stored in browser
  • 4. Server-side database mapping cookie ID โ†’ user data
๐Ÿ“Œ How cookies work: Server sends Set-Cookie โ†’ Browser stores โ†’ Browser includes Cookie in future requests โ†’ Server identifies user via cookie ID.
๐Ÿ“‘ Page 9โšก Web Caching & Conditional GET
๐Ÿ—„๏ธ 7. Web Caching

โ“ Q26: Why is web caching used?

  • Reduce response time (cache closer to client)
  • Reduce network traffic (less bandwidth usage)
  • Improve performance (faster page loads)
  • Reduce load on origin server
โ“ Q27: What is Conditional GET? โ†’ Client asks server if object was modified using If-Modified-Since header. Server replies 304 Not Modified if unchanged โ†’ saves bandwidth and time.
ุงู„ุชุฎุฒูŠู† ุงู„ู…ุคู‚ุช: ูŠู‚ู„ู„ ุฒู…ู† ุงู„ุงุณุชุฌุงุจุฉ ูˆุญุฑูƒุฉ ุงู„ู…ุฑูˆุฑ. Conditional GET: ูŠุชุญู‚ู‚ ุฅุฐุง ุชู… ุชุนุฏูŠู„ ุงู„ูƒุงุฆู† ู‚ุจู„ ุฅุนุงุฏุฉ ุชุญู…ูŠู„ู‡.
๐Ÿ“‘ Page 9-11โœ‰๏ธ Email: SMTP, POP3, IMAP
๐Ÿ“ง 8. Electronic Mail System

โ“ Q28: Main email components

  • User agent (mail client: Outlook, Thunderbird)
  • Mail server (stores & forwards emails)
  • SMTP protocol (sending between servers)

โ“ Q29: What is SMTP?

  • Simple Mail Transfer Protocol
  • Uses TCP, port 25
  • Push protocol (sender pushes to server)
  • Persistent connection
  • Three phases: handshake โ†’ transfer โ†’ closure
๐Ÿ“Œ HTTP vs SMTP
๐Ÿ“Œ POP3 vs IMAP
HTTP: Pull protocol, stateless, each object separate
POP3: Downloads emails, can delete from server, stateless
SMTP: Push protocol, persistent, multi-part messages
IMAP: Emails remain on server, supports folders, maintains state, good for multiple devices
SMTP: ุจุฑูˆุชูˆูƒูˆู„ ู†ู‚ู„ ุงู„ุจุฑูŠุฏุŒ ุฏูุนุŒ ู…ูŠู†ุงุก 25. POP3 ูŠุญู…ู„ ุงู„ุจุฑูŠุฏ ูˆูŠู…ูƒู† ุญุฐูู‡ ู…ู† ุงู„ุฎุงุฏู…. IMAP ูŠุญุชูุธ ุจุงู„ุจุฑูŠุฏ ุนู„ู‰ ุงู„ุฎุงุฏู… ูˆูŠุฏุนู… ุงู„ู…ุฌู„ุฏุงุช ูˆุงู„ุฃุฌู‡ุฒุฉ ุงู„ู…ุชุนุฏุฏุฉ.
๐Ÿ“‘ Page 11-12๐ŸŒ DNS โ€“ Domain Name System
๐Ÿ” 9. DNS: The Internet's Directory

โ“ Q33: What is DNS?

  • Domain Name System
  • Translates hostname (www.google.com) โ†’ IP address (142.250.190.46)
  • Distributed database (not centralized)
  • Uses UDP (mostly) on port 53

โ“ Q34: Why is DNS distributed?

  • Avoid single point of failure
  • Handle massive traffic (billions of queries)
  • Easier maintenance and updates
  • Better scalability and reliability
โ“ Q35: DNS Hierarchy: Root servers โ†’ TLD servers (.com, .org, .net) โ†’ Authoritative servers (specific domain).
โ“ Q36: DNS Resource Record: (Name, Value, Type, TTL) โ€“ stored in DNS database.
โ“ Q37: Types of DNS records: A (hostname โ†’ IP), NS (name server), CNAME (alias domain), MX (mail server).
DNS: ุชุญูˆูŠู„ ุงู„ุฃุณู…ุงุก ุฅู„ู‰ ุนู†ุงูˆูŠู† IPุŒ ู‚ุงุนุฏุฉ ุจูŠุงู†ุงุช ู…ูˆุฒุนุฉ. ุงู„ุชุณู„ุณู„ ุงู„ู‡ุฑู…ูŠ: ุฎูˆุงุฏู… ุฌุฐุฑุŒ ุฎูˆุงุฏู… ู†ุทุงู‚ ุนู„ูŠุงุŒ ุฎูˆุงุฏู… ู…ูˆุซูˆู‚ุฉ. ุงู„ุณุฌู„ุงุช: A, NS, CNAME, MX.
๐Ÿ“‘ Security๐Ÿ”’ SSL/TLS & HTTPS
๐Ÿ” 10. Security in Application Layer: SSL/TLS

๐Ÿ” What is SSL/TLS?

  • Security layer between Application and Transport
  • Provides confidentiality (encryption)
  • Provides data integrity (no tampering)
  • Provides end-point authentication (certificates)
  • HTTPS = HTTP + SSL/TLS (port 443)
  • Protects against eavesdropping and MITM attacks

๐Ÿค SSL Handshake (simplified)

  • Client sends "ClientHello" (supported cipher suites)
  • Server responds with certificate + "ServerHello"
  • Client verifies certificate with CA
  • Both establish shared secret key
  • All subsequent HTTP messages encrypted
TLS 1.3 is current standard (faster & more secure)
โš ๏ธ Why important? Without SSL/TLS, all data (passwords, credit cards) sent over HTTP is plain text and vulnerable to sniffing. Banking, e-commerce, email all rely on TLS.
SSL/TLS: ุทุจู‚ุฉ ุฃู…ุงู† ุชูˆูุฑ ุงู„ุชุดููŠุฑ ูˆุงู„ุณู„ุงู…ุฉ ูˆุงู„ู…ุตุงุฏู‚ุฉ. HTTPS = HTTP + TLS. ุงู„ู…ุตุงูุญุฉ (Handshake) ุชุชุจุงุฏู„ ุงู„ุดู‡ุงุฏุงุช ูˆุงู„ู…ูุงุชูŠุญ ู„ุฅู†ุดุงุก ุงุชุตุงู„ ุขู…ู†.
๐Ÿ“‘ Page 12-13โœ๏ธ ESSAYS: Web Loading, DNS Resolution, Cookies State
๐Ÿ“ 11. Step-by-Step Essay Questions (Very Important)

โ“ Q38: How a web page loads from start to finish

  • 1. User enters URL in browser
  • 2. Browser checks cache, then queries DNS to resolve hostname โ†’ IP address
  • 3. Browser establishes TCP connection (3-way handshake) to server
  • 4. Browser sends HTTP GET request for the base HTML
  • 5. Server processes request and sends HTTP response with HTML
  • 6. Browser parses HTML, discovers referenced objects (CSS, JS, images)
  • 7. Browser requests each object (using persistent connection if available)
  • 8. Browser renders page and displays it to user

โ“ Q39: DNS resolution step-by-step (iterative)

  • 1. Client queries local DNS resolver (configured by ISP/network)
  • 2. Local DNS resolver queries a Root DNS server
  • 3. Root server responds with referral to TLD server (e.g., .com)
  • 4. Local DNS resolver queries TLD server
  • 5. TLD server responds with referral to Authoritative server
  • 6. Local DNS resolver queries Authoritative server
  • 7. Authoritative server returns IP address for the hostname
  • 8. Local resolver caches the result and returns IP to client

โ“ Q40: How cookies maintain state over stateless HTTP

  • 1. Server sends Set-Cookie header in HTTP response (first visit)
  • 2. Browser stores cookie (key-value pair) in cookie file/database
  • 3. For subsequent requests to same domain, browser automatically includes Cookie header
  • 4. Server reads cookie ID from request header
  • 5. Server looks up cookie ID in its database to retrieve user state (login, cart, preferences)
  • 6. Cookies can be persistent (with expiry date) or session-only (deleted after browser close)
```