๐ 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
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 vs UDP ุจุงูุนุฑุจูุฉ
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 HTTPOne TCP connection per object 2 RTT per object (TCP handshake + HTTP request/response) Connection closed after each response Higher delay, more overhead
๐ Q20: Persistent HTTPSingle TCP connection for multiple objects Connection remains open after response Fewer RTTs, more efficient Default in HTTP/1.1 and later
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
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.
๐ ุขููุฉ ุงูููููุฒ
ุงูููููุฒ: ุชุนูุถ ุนุฏูู
ุงูุญุงูุฉ ูู HTTP. ุงูู
ูููุงุช: ุฑุฃุณ cookie ูู ุงูุงุณุชุฌุงุจุฉ ูุงูุทูุจุ ู
ูู cookie ูู ุงูู
ุชุตูุญุ ูุงุนุฏุฉ ุจูุงูุงุช ู
ู ุฌุงูุจ ุงูุฎุงุฏู
.
๐ 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: 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 ุจุงูุนุฑุจูุฉ
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 ูุงูุฃู
ุงู
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)