Chapter 2: Application Layer

Below, I provide comprehensive definitions for the key terms and concepts from
the summary I shared earlier. These are drawn directly from the chapter's
content, expanding on each with precise explanations, components, and
implications. Definitions are structured by section for clarity, with bolded key
terms and supporting details.

Application Architectures
Client-Server Paradigm
- Key Characteristics:
- Server handles requests, processes them, and responds, enabling centralized
management and scalability through replication in data centers.
- Clients contact the server for services like data retrieval or computation, but
their connections are temporary and non-direct with peers.
- Examples**: Protocols such as HTTP for web browsing, IMAP for email retrieval,
Telnet for remote access, and FTP for file transfer.
- **Advantages**: Allows rapid application development and propagation on end
systems (e.g., using C++, Java, or Python), without needing to modify network-
core devices like routers, as they operate below the application layer.
- **Implications**: This model supports reliable, controlled environments but can
create bottlenecks at the server during high demand.

Peer-to-Peer (P2P) Paradigm

- **Key Characteristics**:
- Peers are intermittently connected, frequently change IP addresses, and are
not owned by the service provider, making management complex.
- **Self-Scalability**: Each new peer increases service capacity (e.g., upload
bandwidth) while also adding demand, resulting in cost-effective distribution
without central infrastructure overload.
- **Examples**: P2P file sharing systems like BitTorrent, video streaming
platforms such as KanKan, and VoIP applications like Skype.
- **Challenges**: Includes security vulnerabilities, performance inconsistencies,
and reliability issues due to the lack of central control and peers' variable
availability.
- **Implications**: Ideal for bandwidth-intensive, distributed applications but
requires robust handling of dynamic topologies.

---
## Processes, Sockets, and Addressing

### Process Communication

- **Key Components**:
- A **process** is an instance of a program executing within a host, capable of
multiple concurrent operations.
- **Inter-Process Communication (IPC)**: For same-host processes, defined by
the OS; for different hosts, relies on network protocols.
- **Client and Server Processes**: A **client process** initiates communication,
while a **server process** passively waits for incoming connections; P2P
applications incorporate both roles within the same process.
- **Implications**: Enables distributed computing but requires addressing
mechanisms to identify specific processes across hosts.

### Sockets
A **socket** is an application programming interface (API) that serves as a
doorway between an application process and the transport layer of the network
stack, allowing processes to send and receive messages by "shoving" data
through it, with the underlying transport infrastructure handling delivery to the
receiving socket.

- **Key Characteristics**:
- Analogous to a house door: The sending process pushes messages out, and
the receiving process pulls them in, involving two sockets—one per host—
controlled partly by the app developer and partly by the OS.
- Positioned between the application process and transport layers (TCP/UDP), it
abstracts network details for developers.
- **Usage**: Essential for network applications; e.g., a web browser uses a socket
to send HTTP requests.
- **Implications**: Simplifies programming by providing a uniform interface, but
reliability depends on the chosen transport protocol.

### Addressing Processes

**Addressing processes** involves uniquely identifying a process on a network
using a combination of the host's 32-bit IP address and a port number (a 16-bit
identifier), as an IP address alone cannot distinguish among multiple processes
running on the same host.
- **Key Components**:
- **IP Address**: Uniquely identifies the host device (e.g., [Link] for
[Link]).
- **Port Number**: Specifies the process (e.g., HTTP server uses port 80; SMTP
mail server uses port 25).
- **Example**: To reach an HTTP server, use IP [Link]:80; for SMTP, 25.
- **Implications**: Enables multiplexing—multiple applications sharing one IP—
critical for efficient network use, but dynamic IPs in P2P add complexity.

---

## Application-Layer Protocols

### Protocol Definition

An **application-layer protocol** defines the rules and formats for message
exchanges between processes, including message types (e.g., request/response),
syntax (structure and fields of messages), semantics (meanings of field values),
and timing rules for sending and responding.

- **Key Components**:
- **Message Types**: Specifies exchanges like requests for data or responses
with content.
- **Syntax**: Outlines fields (e.g., headers) and their delineation (e.g., via
carriage returns).
- **Semantics**: Interprets data in fields (e.g., a status code meaning
"success").
- **Open vs. Proprietary**: **Open protocols** are publicly defined in RFCs for
interoperability (e.g., HTTP, SMTP); **proprietary protocols** are private (e.g.,
Skype).
- **Implications**: Ensures consistent communication; open standards promote
widespread adoption.

### Transport Services for Apps

**Transport services available to applications** encompass the features provided
by protocols like TCP and UDP to meet app needs such as data integrity (reliable
delivery), timing (low delay), throughput (bandwidth guarantees), and security
(encryption/integrity).

- **Data Integrity**: Essential for apps like file transfers (100% reliable) but
tolerable for lossy ones like audio streaming.
- **Timing**: Critical for real-time apps (e.g., telephony/games need <10s ms
delay) to maintain effectiveness.
- **Throughput**: Minimum rates for multimedia (e.g., 5Kbps-5Mbps for video);
elastic apps adapt to available bandwidth.
- **Security**: Includes encryption and data integrity checks.
- **TCP Service**: Provides reliable, ordered delivery with flow and congestion
control; connection-oriented (requires setup); no timing/throughput guarantees.
- **UDP Service**: Unreliable datagram delivery; no reliability, flow/congestion
control, timing, throughput, security, or connection setup—suited for low-
overhead, real-time needs.
- **TLS (Transport Layer Security)**: Enhances TCP with encrypted connections,
data integrity, and endpoint authentication; implemented via application-layer
libraries.
- **Implications**: Apps choose TCP for reliability (e.g., web) or UDP for speed
(e.g., games); TLS secures vanilla sockets against cleartext risks.

---

## Web and HTTP

### HTTP Basics

**HTTP (Hypertext Transfer Protocol)** is the application-layer protocol for the
web, operating in a client-server model where a client (e.g., browser) requests
and displays web objects (e.g., HTML, images) from a server, using TCP on port
80 for message exchanges.

- **Key Characteristics**:
- **Stateless**: Server retains no information about past client requests,
simplifying implementation but requiring mechanisms like cookies for state.
- **Web Page Structure**: A base HTML file references objects via URLs (e.g.,
host/path like [Link]/someDept/[Link]).
- **Operation**: Client initiates TCP connection; exchanges HTTP messages;
closes connection.
- **Implications**: Enables distributed content but statelessness avoids
complexity from crashes or inconsistent state views.

### Connection Types

**Non-persistent HTTP** is a connection model where each TCP connection
handles at most one object transfer: the client opens a connection, sends a
request, receives the response, and closes it, requiring multiple connections for
multi-object pages and resulting in response time of 2RTT + file transmission
time per object.

- **Drawbacks**: High overhead from repeated TCP setups; browsers mitigate by

opening parallel connections.

**Persistent HTTP** (default in HTTP/1.1) keeps the TCP connection open after
sending a response, allowing multiple HTTP requests and responses over a single
connection to the same server, reducing latency to as little as one RTT for all
referenced objects in a page.

- **Benefits**: Cuts response time in half for multi-object fetches; server parses
requests sequentially.
- **Implications**: Improves efficiency but still prone to head-of-line (HOL)
blocking in HTTP/1.1.

### HTTP Messages

**HTTP request message** is an ASCII-formatted message from client to server,
consisting of a request line (method like GET/POST, URL, version), header lines
(e.g., Host, User-Agent, Accept), a blank line, and an optional entity body (e.g.,
for POST data).

- **Methods**:
- **GET**: Requests data; can embed parameters in URL (e.g.,?search=term).
- **POST**: Sends user input (e.g., form data) in the body to the server.
- **HEAD**: Requests only headers (no body), useful for metadata checks.
- **PUT**: Uploads/replaces a resource at the specified URL.

**HTTP response message** is an ASCII-formatted reply from server to client,

including a status line (version, status code like 200 OK, phrase), header lines
(e.g., Date, Content-Length, Server), a blank line, and the entity body (e.g.,
requested HTML).

- **Status Codes**:
- 200 OK: Success; object follows.
- 301 Moved Permanently: Resource relocated; new URL in Location header.
- 400 Bad Request: Server cannot understand request.
- 404 Not Found: Requested resource missing.
- 505 HTTP Version Not Supported: Client version incompatible.
- **Implications**: Human-readable format aids debugging; headers provide
metadata like content type.

### State Management: Cookies

**Cookies** are a mechanism to maintain stateful interactions over stateless
HTTP by having servers include a unique identifier in response headers (Set-
Cookie), which the client stores in a local file and returns in subsequent request
headers (Cookie), allowing the server to track user sessions via a backend
database.

- **Four Components**:
1. Cookie header in HTTP responses to set values.
2. Cookie header in subsequent requests to return values.
3. Client-side cookie file managed by the browser.
4. Server backend database linking IDs to user data.
- **Uses**: User identification, authorization, shopping carts, recommendations,
session tracking (e.g., web email).
- **Privacy Concerns**: Enables site-specific tracking; third-party persistent
cookies allow cross-site identity tracking.
- **Implications**: Balances stateless simplicity with needed persistence, but
raises privacy issues.

### Web Caches (Proxies)

A **web cache** (or proxy server) is an intermediary that satisfies client HTTP
requests by serving stored copies of objects if available, otherwise fetching from
the origin server, caching it, and forwarding to the client, acting as both a server
to clients and a client to origin servers.
- **Deployment**: Configured in browsers to route requests; often installed by
ISPs (e.g., universities, companies) for institutional benefits.
- **Benefits**:
- Reduces client response time (cache closer than origin).
- Lowers traffic on access links and enables poor providers to scale.
- **Conditional GET**: Cache sends If-modified-since header; server replies with
304 Not Modified if unchanged, avoiding full retransmission.
- **Implications**: Widespread in the Internet; dense caching reduces global load
but requires freshness checks.

### HTTP Evolutions

**HTTP/2** is an evolution of HTTP/1.1 (RFC 7540, 2015) that decreases multi-
object request delays by multiplexing requests over a single TCP connection,
using frames for object division and interleaved scheduling to mitigate head-of-
line (HOL) blocking, while retaining methods, status codes, and most headers.

- **Key Features**:
- Client-specified object priorities over FCFS ordering.
- Server-push of unrequested objects.
- Frame-based transmission interleaves data to avoid stalls from large objects
or losses.
- **Limitations**: Single TCP means packet loss stalls all; browsers use parallels
for throughput.

**HTTP/3** builds on HTTP/2 by using UDP instead of TCP, adding per-object

error/congestion control and pipelining for better loss recovery and security,
while maintaining HTTP semantics.
- **Implications**: Addresses TCP's HOL issues; details covered in transport layer
discussions.

---

## E-mail Protocols

### Components
**User agents** (or mail readers) are client software for composing, editing, and
reading email messages, such as Outlook or iPhone Mail, which store
outgoing/incoming messages locally or on servers.

**Mail servers** manage email storage and transfer, maintaining user mailboxes
for incoming messages and queues for outgoing ones, using SMTP to relay
messages between servers.

- **SMTP (Simple Mail Transfer Protocol)**: The core protocol for sending emails
between servers (or from agent to server) over TCP port 25, involving
handshaking, message transfer, and closure phases with ASCII
command/response interactions.

### Message Flow (Alice to Bob)

The **email sending process** involves: (1) Alice's user agent composing and
queuing the message on her mail server; (2) SMTP client on Alice's server
opening a TCP connection to Bob's server (port 25); (3) transferring the message
via SMTP; (4) Bob's server storing it in his mailbox; (5) Bob's user agent
retrieving it via an access protocol.

- **Phases**: Greeting (handshaking), message transfer (7-bit ASCII), closure.

- **Direct Transfer**: Sender's server acts as SMTP client to receiver's as server.

### Message Format (RFC 822)

An **email message format** consists of header lines (e.g., To:, From:, Subject:)
providing metadata, followed by a blank line and the ASCII body containing the
message content, distinct from SMTP's MAIL FROM:/RCPT TO: commands.

- **Header**: Multiple lines ending with [Link] to denote end.

- **Body**: Plain text; attachments handled via MIME extensions (not detailed
here).
- **Implications**: Ensures compatibility; SMTP enforces 7-bit ASCII for transport.

### Access Protocols

**Mail access protocols** enable retrieval of stored emails from servers,
contrasting SMTP's push for delivery.
- **IMAP (Internet Message Access Protocol, RFC 3501)**: Keeps messages on the
server, supporting retrieval, deletion, and folder management without
downloading everything to the client.
- **POP (Post Office Protocol)**: Downloads messages to the client, often deleting
from server; simpler but less flexible for multi-device access.
- **HTTP**: Web-based access (e.g., Gmail) layering over SMTP for sending and
IMAP/POP for retrieval.

**SMTP vs. HTTP**: SMTP is push-oriented (server-initiated transfer) with

multipart messages over persistent connections; HTTP is pull-oriented (client
requests) with per-object encapsulation.

---

## DNS: Domain Name System

### Purpose
The **Domain Name System (DNS)** is a distributed, hierarchical database and
application-layer protocol that maps human-readable hostnames (e.g.,
[Link]) to IP addresses (e.g., [Link]) and vice versa, enabling
name resolution for network communication.

- **Services**:
- Hostname-to-IP translation.
- **Host Aliasing**: Canonical names and aliases (e.g., [Link] as
[Link]).
- **Mail Server Aliasing**: MX records for email routing.
- **Load Distribution**: Multiple IPs per name for replicated servers.
- **Why Distributed?**: Avoids single-point failure, traffic overload, distant
access, and maintenance issues of centralization (e.g., Comcast handles 600B
queries/day).
- **Implications**: Core Internet function; implemented at the edge for scalability.

### Hierarchy
**DNS hierarchy** organizes name servers into levels: root (13 logical servers,
~200 replicas worldwide, managed by ICANN), TLD (.com/.org/etc., authoritative
for top domains), authoritative (organization-specific for host mappings), and
local (ISP caches acting as proxies).

- **Root Servers**: Contact-of-last-resort; support DNSSEC for security.

- **TLD Servers**: Handle country codes (e.g.,.uk) and generics (e.g.,.com by
Network Solutions).
- **Authoritative Servers**: Provide final hostname-IP mappings; can be self-
maintained or outsourced.
- **Local DNS Servers**: Default for hosts; cache recent translations (potentially
outdated) and forward unresolved queries up the hierarchy.
- **Implications**: Decentralized design scales globally; local caching speeds
common resolutions.

### Resolution
**Iterative DNS query** is a resolution method where the querying host (or local
server) contacts servers sequentially—starting from root, then TLD, then
authoritative—receiving referrals ("ask this server") until obtaining the IP.

**Recursive DNS query** offloads the full resolution burden to the contacted
name server, which queries higher levels on behalf of the client and returns the
final answer, potentially increasing load on upper hierarchy levels.

- **Example Flow (Iterative)**: For [Link], local DNS asks root (.com
server),.com ([Link] server), [Link] (IP).
- **Implications**: Iterative is client-driven (lighter on servers); recursive is
server-driven but scalable with caching.

### Records (RR)

**DNS resource records (RRs)** are database entries in the format (name, value,
type, ttl—time to live), storing mappings like hostnames to IPs.

- **Types**:
- **A (Address)**: Name=hostname, value=IP address.
- **NS (Name Server)**: Name=domain, value=authoritative server hostname
(e.g., [Link] → [Link]).
- **CNAME (Canonical Name)**: Name=alias, value=canonical hostname for
redirection.
 - **MX (Mail Exchange)**: Name=domain, value=mail server hostname (e.g.,
[Link] → [Link]).

### Protocol
**DNS protocol messages** are UDP-based (port 53) queries/replies with a
common format: 12-byte header (identification, flags like recursion
desired/authoritative, counts for sections), followed by questions (name/type),
answers (RRs), authority (server RRs), and additional info.

- **Header Flags**: Indicate query/reply, recursion needs/availability, authority.

- **Implications**: Efficient for short queries; supports caching via TTL.

### Security Issues

**DNS DDoS attacks** overwhelm servers with traffic, targeting roots (mitigated
by filtering/caching) or TLDs (more vulnerable); amplification uses spoofed
queries for larger responses.

- **Other Attacks**: **Redirect** (man-in-middle intercepts), **poisoning**

(bogus cached replies).
- **DNSSEC (RFC 4033)**: Adds digital signatures for authentication and integrity
to prevent tampering.
- **Implications**: Critical for Internet trust; exploits can disrupt global access.

### Inserting Records into DNS

**Inserting DNS records** for a new domain (e.g., [Link]) involves
registering with a DNS registrar (e.g., Network Solutions), providing authoritative
server details (NS/A records to TLD), and locally configuring the authoritative
server with A/MX records for hosts.

- **Steps**: Registrar adds TLD entries; org sets local authoritative mappings.
- **Implications**: Democratizes naming but vulnerable to registrar
compromises.

---

## P2P Applications
### File Distribution
**P2P file distribution** disseminates a file of size \( F \) from a server to \( N \)
peers, where each peer \( i \) has upload capacity \( u_i \) and download \( d_i \),
leveraging aggregate peer uploads for scalability over client-server models.

- **Client-Server Time**: \( D_{c-s} > \max\left\{ \frac{NF}{u_s}, \frac{F}{d_{\

min}} \right\} \), where \( u_s \) is server upload; scales linearly with \( N \).
- **P2P Time**: \( D_{P2P} > \max\left\{ \frac{F}{u_s}, \frac{F}{d_{\min}}, \
frac{NF}{u_s + \sum u_i} \right\} \); server uploads once, peers share, making it
sublinear in \( N \).
- **Example**: With peer \( u = 1 \) unit/hour, server \( u_s = 10u \), P2P
distribution time plateaus around 3.5 hours for large \( N \), vs. client-server's
linear rise.
- **Implications**: Efficient for large-scale sharing (e.g., BitTorrent) but assumes
abundant network bandwidth.

---

## Video Streaming and CDNs

### Video Basics

**Video encoding** represents a sequence of images (frames, e.g., 24/sec) as
pixel arrays compressed via **spatial coding** (redundancy within frames, e.g.,
repeating colors) and **temporal coding** (differences between frames) to
reduce bits.

- **Types**:
- **CBR (Constant Bit Rate)**: Fixed encoding rate.
- **VBR (Variable Bit Rate)**: Rate varies with content complexity.
- **Standards**: MPEG-1 (1.5 Mbps, CD-ROM), MPEG-2 (3-6 Mbps, DVD), MPEG-4
(64Kbps-12 Mbps, Internet).
- **Implications**: Compression enables streaming but requires adaptive rates
for variable networks.

### Streaming Stored Video

**Streaming stored video** delivers pre-recorded video from a server to clients
over the Internet, facing challenges like variable bandwidth, packet loss, jitter,
and interactivity (pause/rewind), necessitating client-side buffering to ensure
continuous playout matching original timing.

- **Constraints**: Playout begins after initial buffer; delays cause jitter (smoothed
by buffer), losses degrade quality.
- **Implications**: Dominates bandwidth (80% of ISP traffic, e.g.,
Netflix/YouTube); heterogeneity (wired vs. mobile) demands adaptation.

### DASH (Adaptive Streaming)

**DASH (Dynamic Adaptive Streaming over HTTP)** is a streaming technique
where the server divides video into chunks encoded at multiple rates, providing a
manifest file with URLs; the client measures bandwidth, requests optimal chunks
periodically, and adapts rates to avoid buffer starvation or overflow.

- **Client Intelligence**: Determines request timing (for buffer management),

encoding rate (higher for more bandwidth), and source URL (e.g., nearest CDN).
- **Implications**: Handles congestion dynamically; combines with encoding and
buffering for seamless playback.

### CDNs (Content Distribution Networks)

A **Content Distribution Network (CDN)** is a distributed system of servers
storing replicated content (e.g., videos) at geographically dispersed nodes to
serve users from nearby locations, reducing latency, congestion, and load on
origin servers for large-scale delivery to millions.

- **Deployment**: Deep edge servers in access networks (e.g., Akamai's 240K in

120+ countries) or POP clusters (e.g., Limelight's 10s per region).
- **Access Flow**: Client requests URL; DNS CNAME redirects to optimal CDN
node; manifest guides chunk fetches.
- **Challenges (OTT)**: Node selection amid congestion, viewer adaptation,
content placement.
- **Implications**: Scales "over-the-top" services; single mega-server fails due to
bottlenecks.

### Netflix Case

**Netflix's streaming architecture** uses AWS cloud for video upload (multiple
versions), registration/accounting servers, and Open Connect CDNs; clients
browse, receive manifests, and stream DASH chunks from selected CDN servers
based on location/bandwidth.

- **Flow**: Account management → manifest request → DASH server selection →

adaptive streaming.
- **Implications**: Exemplifies CDN+DASH for global scale.

---

## Socket Programming

### UDP Sockets

**UDP socket programming** implements unreliable datagram communication
without connections: the client creates a socket, attaches destination IP/port to
each message, and sends; the server binds a socket to a port and receives,
extracting sender details from packets, with no handshaking or order
guarantees.

- **Viewpoint**: Provides groups of bytes (datagrams) transfer; data may be lost

or out-of-order.
- **Example**: Echo app—client sends line from keyboard; server uppercases
and replies.
- **Implications**: Low overhead for real-time apps; programmer handles errors.

### TCP Sockets

**TCP socket programming** enables reliable, ordered byte-stream
communication via connections: the server creates a welcoming socket on a
port; the client creates a socket specifying server IP/port, triggering TCP
handshake; server spawns a new socket per client for ongoing pipe-like transfer.

- **Key Features**: Connection-oriented setup; in-order delivery; supports

multiple clients via source ports.
- **Example**: Same echo app, but with guaranteed delivery.
- **Implications**: Abstracts network as a reliable pipe; essential for apps like
web/email.

---
These definitions provide a thorough foundation for recall. Each builds from core
principles to applications, ensuring comprehensive understanding. If you'd like
examples, diagrams, or focus on a section, let me know!

Alright — I will explain the entire Chapter 2 fully, but in the simplest way
possible, step-by-step, like I’m teaching you from scratch.
I will cover everything in your slide:
✔ Network applications
✔ HTTP
✔ Email (SMTP/IMAP)
✔ DNS
✔ P2P
✔ Video streaming & CDNs
✔ Sockets (TCP & UDP)

⭐ CHAPTER 2 FULL EXPLANATION — APPLICATION LAYER

🔷 1. What is the Application Layer?

The application layer is the top layer in networking.
This is the layer where the apps you use send and receive data.
Examples of application layer apps:
 WhatsApp
 Instagram
 Google Chrome
 Gmail
 Netflix
 Online games
These apps run on end devices (phones, laptops, servers).
Routers and switches do NOT run application-layer software.

🔷 2. Two Ways Applications Are Built

Applications use architectures — how the app is designed.

A. Client-Server Architecture
The client-server paradigm is a model where two types of systems
communicate:
  Client: the device or program that requests a service.
 Server: the system that provides the service.
Examples:
 Browsing the web (HTTP)
 Email (IMAP)
 FTP
 Telnet

B. Peer-to-Peer (P2P)
The peer-to-peer (P2P) paradigm is a network model where all devices
(peers) are equal.
There is no central server controlling everything.
Advantages:
 Scales well: more users = more sharing
 Cheap (no data center needed)
Disadvantages:
 Security issues
 Hard to manage
 Peers can leave anytime
Examples:
 BitTorrent
 Skype (early versions)

🔷 3. Processes & Sockets

Process communication (usually called Inter-Process Communication –
IPC) is how two or more processes exchange data or signal each other while
running on the same system or across a network.
Socket = the door from the application to the network.

How to identify a process?

You need:
1. IP address of device
2. Port number of the process
Common port numbers:
 HTTP → 80
 HTTPS → 443
 SMTP → 25
 DNS → 53
Example:
[Link] : 80
= a web server running HTTP.

🔷 4. Application Layer Protocols

A protocol is simply rules for communication.
A protocol defines:
 The types of messages
 The format (headers, fields)
 The meaning of each field
 When messages should be sent
Examples:
 HTTP (web browsing)
 SMTP, IMAP (email)
 DNS (mapping names to IPs)

🔷 5. What Applications Need From the Network

Different applications need different service qualities.
Some require:
 Reliability (file transfer, email, web pages)
 Low delay (calls, gaming)
 High throughput (video streaming)

🔷 6. Internet Transport Protocols: TCP & UDP

TCP (Transmission Control Protocol)
✔ Reliable
✔ Orders packets
✔ No packet loss
✔ Connection-oriented
✔ Congestion control
✔ Flow control
Used by:
 Web browsing
 File downloads
 Email

UDP (User Datagram Protocol)

✔ No connection setup
✔ No reliability
✔ No ordering
✔ Very fast
Used by:
 Live streaming
 Gaming
 DNS
 VoIP
UDP is used when speed matters more than reliability.

🔷 7. HTTP – Hypertext Transfer Protocol

HTTP is the protocol used for the web.
HTTP uses TCP on port 80.
Process:
1. Client opens TCP connection
2. Sends request
3. Server sends response
4. Connection closes

HTTP is STATLESS
Meaning:
The server does NOT remember previous requests.
Every request is independent.

Types of HTTP Connections

1. Non-Persistent
 1 connection → 1 object
 If the page has 10 images → 10 connections
 Slow
2. Persistent (HTTP 1.1)
 One connection → many objects
 Faster
 Uses keep-alive

🔷 8. HTTP Message Formats

HTTP Request Example:
GET /[Link] HTTP/1.1
Host: [Link]
HTTP Response Example:
HTTP/1.1 200 OK
Content-Length: 512
Content-Type: text/html

Common Status Codes

 200 OK → success
 301 Moved Permanently → new URL
 400 Bad Request → client error
 404 Not Found → resource missing
 505 HTTP Version Not Supported

🔷 9. Cookies (Maintaining State)

Because HTTP is stateless, cookies add memory.
Cookies allow:
 Login sessions
 Shopping carts
 User tracking
 Preferences (language, theme, etc.)
Stored:
 In browser
 In server database
 Sent in HTTP headers

🔷 10. Web Caches (Proxy Servers)

A web cache stores copies of recently accessed web pages.
Benefits:
 Faster page load (cache is closer)
 Reduces Internet traffic
If the cached version matches → client gets it
If not → cache fetches from server

🔷 11. DNS – Domain Name System

DNS converts domain names → IP addresses
Example:
[Link] → [Link]
DNS is a distributed database.

DNS Hierarchy:
1. Root servers (13 logical groups)
2. Top Level Domain servers (TLD)
o .com, .edu, .org, .za, .uk

3. Authoritative servers
o Store actual IP for domains

Types of DNS Records:

A
name → IP address
[Link] → [Link]
NS
Domain name server
[Link] → [Link]
CNAME
Alias
[Link] → [Link]
MX
Mail server
[Link] → [Link]

🔷 12. Email Protocols

Email uses:
SMTP → sending (push)
IMAP/POP3 → receiving
SMTP uses TCP port 25.

How Email Works (Full Flow)

1. Alice writes email
2. Her email client sends it to her mail server
3. Her mail server uses SMTP to push email to Bob’s mail server
4. Bob uses IMAP to read the mail

🔷 13. Peer-to-Peer (P2P) File Distribution

In P2P:
 Server sends one copy of file
 Peers share pieces with each other
P2P is scalable because each peer adds:
 More download capacity
 More upload capacity
Client-server gets slower when many users join.
P2P gets faster.

🔷 14. Video Streaming & CDNs

Streaming video faces problems:
 Buffering
 Delay
  Packet loss
 Network congestion
Video Quality Challenges:
 Network speed changes
 Delay varies
 Different device types (TV, phone, laptop)

DASH – Adaptive Streaming

Video is split into chunks.
Client:
 Measures network speed
 Chooses best possible video quality
 Downloads chunk-by-chunk

CDNs – Content Delivery Networks

CDNs store multiple copies of content in many locations.
Examples:
 Netflix CDN
 Akamai
 Cloudflare
Advantages:
 Faster delivery
 Less congestion
 Lower latency

🔷 15. Socket Programming

To create your own network applications:
UDP socket
 No connection
 Fast
 Data may be lost
TCP socket
  Connection setup
 Reliable
 In-order delivery
Used in applications like:
 Chat apps
 Games
 Web services

🎉 FULL CHAPTER SUMMARY

By now, you understand:
✔ Client-Server vs P2P
✔ How sockets work
✔ TCP vs UDP
✔ HTTP (stateless, messages, cookies, caching)
✔ DNS (records, hierarchy)
✔ Email protocols (SMTP, IMAP)
✔ Video streaming, DASH
✔ CDNs
✔ Socket programming

⭐ Do you want me to:

📌 Make exam-ready notes (1 page)?
📌 Create practice questions & answers?
📌 Create a mock exam from this chapter?
Just tell me what you want next.