Application Layer¶

Principles of network applications¶

Creating Network Applications¶

Location: Network applications are written to run on end systems (like your laptop or phone), not on network-core devices (like routers).
Benefit: Since network-core devices do not run user code, developers can create and deploy applications rapidly without needing to upgrade the internet's infrastructure.

Application Architectures¶

There are two main ways to structure how applications communicate:

Client-Server Paradigm¶

Server: An always-on host with a permanent IP address, often housed in a data center for scaling.
Client: Communicates with the server, may be intermittently connected, and often has a dynamic IP address. Clients do not communicate directly with each other.
Examples: Web (HTTP), Email (IMAP), File Transfer (FTP).

Peer-to-Peer (P2P) Architecture¶

Structure: No always-on server. Arbitrary end systems (peers) communicate directly with one another.
Self-Scalability: New peers bring new service capacity (processing/storage) to the system, not just new demand.
Challenges: Peers are intermittently connected and change IP addresses frequently, making management complex.
Example: P2P file sharing.

Peer-to-peer (P2P) means there is no central server. Computers talk directly to each other, and each one both uses the service and helps provide it. When more people join, the system gets more capacity, but it’s harder to manage because peers can come and go and change IP addresses.

The system gets more capacity because in a P2P network, every new computer (peer) that joins acts as both a consumer and a supplier.

They Bring Resources: When a new peer joins, they don't just ask for files; they also bring their own upload bandwidth, storage, and processing power to the table.
Self-Scalability:
- In Client-Server: New users only add load (demand). The server stays the same size, so it gets slower.
- In P2P: The "server capacity" grows automatically because every user effectively becomes a mini-server for everyone else.

Example:

In a Peer-to-Peer (P2P) system like BitTorrent, every user acts as both a client and a server, meaning they contribute resources back to the network at the same time they are consuming them. Instead of everyone waiting in line for a central server, your computer immediately begins uploading the specific pieces of the file you have already downloaded to other peers who still need them. This creates a self-scaling effect where adding 1,000 new users actually improves the system's performance, as those users bring 1,000 new upload connections to help distribute the load.

Processes & Communication¶

Process: A program running within a host.
- Same Host: Two processes communicate using Inter-Process Communication (IPC) (controlled by the OS).
- Different Hosts: Processes communicate by exchanging messages across the network.
Roles:
- Client Process: Initiates the communication.
- Server Process: Waits to be contacted.

Applications with P2P architectures have client processes & server processes

Sockets (The "Door")¶

Definition: A socket is the software interface between the application process and the transport layer.
Analogy: It acts like a door.
- The sending process "shoves" the message out the door.
- It relies on the transport infrastructure (outside the door) to deliver the message to the receiving socket.
Control: The Application developer controls everything inside the door (Application Layer); the OS controls everything outside (Transport/Network layers).

Addressing Processes¶

To send a message to a specific process running on a specific host, you need two identifiers:

IP Address: Identifies the Host (e.g., 129.97.208.23).
Port Number: Identifies the Process on that host (e.g., Port 80 for a Web Server, 25 for a Mail Server).

Application Layer Protocols¶

Definition & Components An application-layer protocol acts as the blueprint for how applications communicate over the network. It strictly defines:

Message Types: Categorizes exchanges (e.g., request vs. response messages).
Message Syntax: Specifies the structure of the data, including what fields exist and how they are separated (delineated).
Message Semantics: Defines the meaning of the information contained within the fields (how the receiver should interpret the data).
Rules: Dictates when and how processes send messages and respond to them.

Types of Protocols

Open Protocols: Defined in public RFCs (Request for Comments). These allow for interoperability (any vendor can implement them).
- Examples: HTTP (Web), SMTP (Email).
Proprietary Protocols: Owned by a specific entity; internal workings are not public.
- Examples: Skype, Zoom.

Transport Service Requirements¶

Different applications prioritize different aspects of network performance. An application generally assesses its needs based on four pillars:

Data Integrity (Reliability)

Reliable Data Transfer: Some apps (File transfer, Web transactions) require 100% data integrity. Zero data loss is acceptable.
Loss-Tolerant: Other apps (Real-time audio/video) can tolerate some packet loss without failing (e.g., a glitch in a video call is acceptable, a missing character in a generic text file is not).

Throughput (Bandwidth)

Guaranteed Throughput: Bandwidth-sensitive apps (Multimedia) need a minimum amount of throughput to be effective.
Elastic Apps: These can adapt to whatever throughput is currently available. They utilize as much or as little bandwidth as the network provides (e.g., File transfers, Email).

Timing (Latency)

Certain interactive apps (Internet telephony, FPS games) require low delay to function correctly. High latency renders them unusable.

Security

Requirements for encryption, data integrity checks, and authentication to prevent eavesdropping or tampering.

Internet Transport Protocols Services¶

The Internet primarily offers two transport protocols, each serving different application needs.

TCP Service (Transmission Control Protocol)¶

TCP is the "heavyweight," reliable option.

Reliable Transport: Guarantees data delivery between sending and receiving processes.
Flow Control: Prevents the sender from overwhelming the receiver's buffer.
Congestion Control: Throttles the sender when the network core is overloaded.
Connection-Oriented: Requires a handshake setup between client and server before data transfer.
Note: TCP does not provide timing guarantees, minimum throughput guarantees, or security (by default).

The core difference between flow control and congestion control lies in who is being protected:

Flow Control protects the Receiver (so the sender doesn't send faster than the receiver can read).
Congestion Control protects the Network (so the sender doesn't clog the routers and cables in between).

Flow Control (Protecting the End-Point)

Goal: To prevent a fast sender from overwhelming a slow receiver.
The Problem: If a server sends data faster than your computer can process it (e.g., while you are saving it to a disk), your RAM buffer will fill up. Any extra packets arriving after that will be dropped and lost.
The Mechanism: The receiver explicitly tells the sender how much free space it has left in its buffer. This is called the Advertised Window or Receiver Window (rwnd).
Analogy: You are pouring water into a glass. You watch the water level (feedback). If the glass is nearly full, you stop pouring so it doesn't spill. The limitation is the capacity of the glass (the receiver).

Congestion Control (Protecting the Traffic)

Goal: To prevent the sender from overwhelming the intermediate network (routers, switches, cables).
The Problem: If many computers send data at once, the routers in the internet backbone get overloaded. Their queues fill up, and they start dropping packets. This causes a "traffic jam" where everyone's connection slows down.
The Mechanism: The sender guesses the network's capacity. It maintains a Congestion Window (cwnd). It starts sending slowly (Slow Start) and speeds up until it detects packet loss (which implies the network is full), then it backs off immediately.
Analogy: You are driving on a highway. You don't know the exact traffic conditions ahead. If traffic moves smoothly, you speed up. If you see brake lights (packet loss/delay), you slow down to avoid a crash. The limitation is the capacity of the road (the network).

UDP Service (User Datagram Protocol)¶

UDP is the "lightweight," fast option.

Unreliable Data Transfer: Best-effort delivery; packets may be lost or arrive out of order.
No "Frills": Does not provide reliability, flow control, congestion control, timing, throughput guarantees, or connection setup.
Why use UDP? It is useful for time-sensitive applications (like streaming or VoIP) where waiting for retransmission (TCP) is worse than losing a frame, or for simple query-response protocols (like DNS) where connection overhead is unnecessary.

Many modern high-performance applications feel that TCP is too "nannying." TCP forces everyone to use its specific style of error recovery and slowing down, which doesn't fit every use case. By using UDP, developers start with a blank slate. They can build their own custom "TCP-like" features in the Application Layer only where they need them.

Securing TCP (TLS)¶

Standard TCP and UDP sockets are inherently insecure.

Vanilla TCP & UDP sockets: Sends cleartext passwords and data. Anyone sniffing packets can read the content. No encryption.
TLS (Transport Layer Security): Since TCP doesn't provide security, TLS is implemented in the Application Layer using libraries.
- The application uses TLS libraries which then use TCP.
- Data is encrypted before it enters the socket.
- Provides: Encryption, Data Integrity, and End-point Authentication (The protocol demands proof of identity before sending data. The server sends its Certificate to you. Your computer checks if it is valid. If it is, you proceed. If not, your browser warns: "This connection is not private.”).

Web and HTTP¶

Web and HTTP Basics¶

Objects: A web page consists of objects (HTML files, JPEG images, Java applets, audio files). Each of which can be stored on different Web servers.
Structure: A page has a Base HTML file which references other objects by URL.
HTTP (HyperText Transfer Protocol): The Web's application-layer protocol. Uses a Client/Server model.
- Client: Browser requests, receives, (using HTTP protocol) and displays Web objects.
- Server: Sends objects (using HTTP protocol) in response to requests.
Statelessness: The server maintains no information about past client requests. (Stateful protocols are complex because they must reconcile state if a crash occurs).

HTTP Connection Procedure¶

HTTP relies on TCP for transport. The standard procedure is:

Client initiates TCP connection (creates socket) to server, port 80.
Server accepts TCP connection from client.
HTTP messages (application-layer messages) are exchanged between browser and Web server.
TCP connection closed.

HTTP Connection Types¶

Non-Persistent HTTP (HTTP/1.0)
1. TCP connection opened.
2. At most one object sent over the connection.
3. TCP connection closed.
Issue: Requires 2 RTTs per object (high latency) and significant OS overhead for repeatedly opening connections. Downloading multiple objects required multiple connections.
Persistent HTTP (HTTP/1.1)
- Server leaves the connection open after sending a response.
- Subsequent messages between the same client/server use the existing connection (single TCP connection).
- Client sends requests as soon as it encounters a referenced object.
- The default mode of HTTP uses persistent connections with pipelining.
- Pipelining is a technique used in Persistent HTTP where the client sends multiple requests back-to-back without waiting for the server to reply to the first one.

RTT Calculation & Comparison¶

RTT (Round Trip Time):

Time for a small packet to travel from client to server and back.

1. Non-Persistent HTTP (Serial)

Process:
1. Initiate TCP Connection (1 RTT).
2. Request Object + Receive first few bytes (1 RTT).
  
  Why first few bytes?
  
  The "1 RTT" measures only the delay
  
  The Round Trip Time (RTT) is the time it takes for a signal to go there and back.
  - The Clock Starts: When you finish sending your request.
  - The Clock Stops: The exact moment the very first byte of the response hits your computer.
  This 1 RTT represents the pure "wait time" for the signal to travel through the wires and routers. It does not matter if the file is 1 KB or 10 GB; the time it takes for the first byte to arrive is roughly the same.
  
  The rest of the bytes are "Transmission Time"
  
  Once that first byte arrives, the "RTT" part is over. Now your computer is just downloading the rest of the stream.
  - This duration depends entirely on the size of the file and your bandwidth speed.
  - If the formula included the time for all bytes in the RTT, it would be incorrect because RTT is a measure of distance/lag, not file size.
    1. Result: Connection closes. Repeat for every single object.
  - Total Time: (2 RTT + File Transmission Time) x Number of Objects
    - File Transmission Time is the SUM of each object transmission time

2. Non-Persistent HTTP (Parallel Connections)

Process (Full Page Load):
1. Phase 1 (Base HTML): Client opens a TCP connection and requests the base HTML file. (2 RTT).
2. Phase 2 (Referenced Objects): Client parses the HTML, finds referenced objects (e.g., images), and opens multiple TCP connections simultaneously to fetch them. (2 RTT).
Total Time: 2 RTT (Base HTML) + 2 RTT (Parallel Objects) + File Transmission Time = 4 RTT + Transmission Time.
- Note that the File Transmission Time is still the SUM of each object transmission time. The "Transmission Time" for the whole batch is determined by the Total Size of all objects divided by the Link Bandwidth. Even though parallel connections allow you to perform the setup handshakes simultaneously (saving latency), the total file transmission time remains the sum of all object times because your internet bandwidth is a fixed "pipe" that gets split between the connections, slowing each individual download down proportionally.
  
  Imagine you have a 10 Mbps internet connection (the pipe).
  
  Serial: You download a 5MB file (takes 4s), then another 5MB file (takes 4s). Total Transmission Time = 8s.
  
  Parallel: You download both at the same time. Your bandwidth splits in half (5 Mbps for each). Both files download simultaneously, but each takes twice as long (8s) to finish. Total Transmission Time = 8s.
Note: This significantly reduces latency compared to serial fetching, but it increases overhead on the OS and network due to managing multiple sockets at once.

This non-persistent HTTP requires 2 RTTs per object. Browsers often open multiple parallel TCP connections to fetch referenced objects in parallel

3. Persistent HTTP (HTTP/1.1)

Let:

N = total number of objects to fetch (1 HTML + (N−1) referenced objects)
RTT = round-trip time
Tx = total transmission time of all objects (i.e., sum of object sizes / bottleneck rate)

Serial (no pipelining)

TCP handshake: 1 RTT
Request/response per object: N RTT
Total time: T = (1 + N)·RTT + Tx

“Parallel” (HTTP/1.1 using multiple persistent TCP connections, no pipelining) - CAN BE IGNORED I GUESS?

Assume the browser opens K parallel persistent connections (typical browser behavior; K ≥ 2):

First connection setup: 1 RTT
Fetch base HTML: 1 RTT
Setup remaining K−1 connections in parallel: 1 RTT (amortized)
Fetch remaining N−1 objects over K connections in rounds:
- rounds = ceil((N−1)/K), each round costs 1 RTT
Total time:T = (2 + 1 + ceil((N−1)/K))·RTT + Tx= (3 + ceil((N−1)/K))·RTT + Tx

With pipelining (single persistent connection)

TCP handshake: 1 RTT
Fetch base HTML: 1 RTT
Pipeline requests for remaining N−1 objects: 1 RTT (As Little As 1 RTT for All Reference Objects)
Total time (idealized): T = 3·RTT + Tx

Mechanism vs. Stop-and-Wait

Without Pipelining: Client sends Request 1, stops and waits for Response 1, then sends Request 2. This introduces latency between every object.
With Pipelining: Client sends Request 1, Request 2, and Request 3 immediately after one another. The server processes them and streams the responses back in order.

Why "As Little As 1 RTT"? The 1 RTT calculation refers to fetching the batch of referenced objects (e.g., images found in the HTML) once the connection is already established.

Connection Setup: 0 RTT (Connection is already open from the base HTML request).
Request Flight: Client fires all requests (e.g., 10 images) into the connection simultaneously. They travel to the server (0.5 RTT).
Response Flight: Server sends responses back immediately. The first bytes arrive at the client (0.5 RTT).
Total Latency: 1 RTT is spent waiting for the first response of the batch to arrive. The rest is just transmission time (downloading).

HTTP Request Message Structure¶

HTTP request messages are ASCII (human-readable) and follow a strict general format.

Two types of HTTP messages: request, response
Request Line: The first line of the message. It contains three fields:
- Method: The command being issued (e.g., GET, POST, HEAD).
- URL: The specific resource being requested (e.g., /index.html).
- Version: The HTTP version being used (e.g., HTTP/1.1).
Header Lines: Subsequent lines that define metadata about the request.
- Format: Header-Field-Name: Value.
- Examples: Host: (required in 1.1), User-Agent: (browser type), Accept-Language:.
- Termination: An extra carriage return and line feed (\r\n) at the start of a line indicates the end of the headers.
Entity Body: The final section, separated from headers by a blank line. It contains data being sent to the server (used in POST/PUT methods).

Line Endings in HTTP/1.x¶

All HTTP/1.x request and response lines must end with \r\n (CRLF).
This includes:
- The request/status line
- Each header line
- The blank line separating headers from the body (\r\n)
Reason: HTTP is a text-based protocol that inherited CRLF line endings from earlier Internet protocols (e.g., SMTP, FTP).
Using only \n is technically invalid and may cause parsing errors or security issues (e.g., request smuggling).

HTTP Request Methods¶

GET Method:
- Used to request an object.
- If data needs to be sent to the server (e.g., a search term), it is included in the URL field after a ? (e.g., /search?q=networks).
  - In a GET request, parameters are key–value pairs. The key (parameter name) tells the server what the value means. GET parameters do not have to be in a specific order.
POST Method:
- Used when a web page includes form input.
- The user input is sent to the server inside the Entity Body of the message, rather than the URL.
HEAD Method:
- Similar to GET, but requests only the headers.
- The server returns the exact response it would have sent for a GET request, but omits the actual object (body). Useful for debugging or checking if a file exists/has changed.
PUT Method:
- Used to upload objects to a specific path.
- Completely replaces the file that exists at the specified URL with the content in the entity body.

HTTP Response Message Structure¶

Response messages follow a similar structure to requests.

Status Line: The first line, indicating the result of the request.
- Protocol: e.g., HTTP/1.1
- Status Code: A numeric code indicating success or failure (e.g., 200, 404).
- Status Phrase: A human-readable explanation (e.g., OK, Not Found).
Header Lines: Metadata about the server and the object returned.
- Examples: Date:, Server: (e.g., Apache), Content-Length: (size of file), Content-Type: (e.g., text/html).
Entity Body (Data): The actual requested object (e.g., the HTML file or image data).

The \r\n rules only apply to the Protocol Metadata (Status and Headers). The Entity Body (the actual file) is just a stream of raw bytes; it does not add \r\n unless those characters are actually part of the file (e.g., inside a .txt file).

Status code appears in 1st line in server-to-client response message.

Maintaining State: Cookies¶

Because HTTP is stateless, websites use cookies to identify users and maintain state across multiple transactions.

Four Components of the Cookie System
- Response Header: The server includes a Set-cookie: line in its HTTP response message.
- Request Header: The browser includes a Cookie: line in subsequent requests to that server.
- Cookie File: Kept on the user's device and managed by the browser.
- Backend Database: The website stores the actual user data (like cart contents) linked to the cookie ID.
Uses: Authorization, shopping carts, recommendations, and maintaining user sessions (e.g., webmail).
Privacy Concerns: Cookies allow third parties to track browsing habits across multiple sites for identity and ad targeting.
How to Keep States:
- at protocol endpoints: maintain state at sender/receiver over multiple transactions
- in messages: cookies in HTTP messages carry state

Web Caches (Proxy Servers)¶

Concept & Goal

A Web cache satisfies client requests without involving the origin server. The browser is configured to send all requests through the cache first.

Note that a cache is both a server and a client at the same time. When it receives requests from and sends responses to a browser, it is a server. When it sends requests to and receives responses from an origin server, it is a client.

Mechanism: The user configures their browser to route all access through the cache.
- Hit: If the object is in the cache, it is returned immediately to the client.
- Miss: If not, the cache requests the object from the origin server, stores a copy locally, and then sends it to the client.
Benefits
- Reduces response time (the cache is usually closer to the client than the server).
- Reduces traffic on the institution's access link (saving money/bandwidth).
- Enables "poor" content providers to deliver content effectively by leveraging the dense infrastructure of caches in the Internet.
Note: Servers control caching via headers like Cache-Control: max-age=<seconds> or Cache-Control: no-cache.

Conditional GET¶

Goal:

To prevent the server from sending an object if the cache already has an up-to-date version, saving bandwidth and transmission time.

No object transmission delay
No use of internet resources
Client Action: When requesting a cached object, the client adds the header If-modified-since: <date> (the date of the cached copy).
Server Response:
- If modified: Server sends 200 OK with the new data.
- If NOT modified: Server sends 304 Not Modified. The response body is empty, telling the cache to use its existing copy.

Caching Example: Performance Calculation¶

This example demonstrates why caching is often a better solution than simply buying more bandwidth.

The Scenario (The Problem) An institution is connected to the public Internet.

Access Link Capacity: 1.54 Mbps.
Avg Object Size: 100K bits.
Avg Request Rate: 15 requests/sec.
RTT (Router to Origin): 2 seconds.
- This is internet delay: The time it takes for data to travel from your institution's router, across the public Internet, to the origin server (e.g., Google or Facebook) and back.

Step 1: Calculate Traffic Load First, determine how much data the users are trying to pull through the link.

Data Rate = Request Rate × Object Size
Data Rate = 15 req/sec × 100 kbits = 1,500 kbits/sec = 1.50 Mbps.
LAN utilization: 1.50 Mbps / 1000 Mbps = 0.0015
- The internal network uses a standard 1 Gbps (Gigabit) Ethernet line.

Step 2: Calculate Link Utilization

Utilization = Traffic Demand / Link Capacity
Utilization = 1.50 Mbps / 1.54 Mbps ≈ 0.97 (97%).
The Issue: In networking queueing theory, as utilization approaches 1.0 (100%), delay approaches infinity because packets get stuck in the queue.
Result: The total delay is 2 sec (Internet) + Minutes (Queueing/Access Link Delay). The connection is unusable.
- End-end delay = Internet delay + access link delay + LAN delay
  - LAN delay: The time it takes for data to move inside your school or office network (Local Area Network).
  - Access Link Delay: The time spent waiting to get through the "bottleneck" link that connects the institution to the outside world

Solution Option 1: Buy Faster Link

Action: Upgrade access link to 154 Mbps.
New Utilization: 1.50 Mbps / 154 Mbps = 0.0097 (< 1%).
Result: Queueing delay becomes negligible. Total delay ≈ 2 seconds.
Downside: This is a very expensive hardware upgrade.

Solution Option 2: Install Web Cache

Action: Install a local cache. Assume a Hit Rate of 0.4 (40% of requests are found in the cache).
Impact on Traffic:
- 40% of requests are served locally (negligible delay).
- 60% of requests still go to the origin server.
New Link Utilization:
- Traffic on link: 0.6 × 1.50 Mbps = 0.9 Mbps.
- Utilization: 0.9 Mbps / 1.54 Mbps = 0.58.
- At 58% utilization, queueing delay is low (milliseconds), so we ignore it.
New Average Delay:
- We calculate the weighted average of the two paths:
- Avg Delay = (Fraction Cached × Cache Delay) + (Fraction Origin × Origin Delay)
- Avg Delay = (0.4 × ~0s) + (0.6 × 2.01s)
  - 0.01s in 2.01s is the queueing delay at access link, the calculation adds roughly 0.01 seconds (10 milliseconds) to account for this small wait at the router.
- Avg Delay ≈ 1.2 seconds.
Conclusion: The cache makes the internet faster (1.2s vs 2s) and is significantly cheaper than upgrading the link.

HTTP/2: Mitigating Head-of-Line Blocking¶

The primary goal of HTTP/2 is to decrease delay in multi-object requests.

The Problem (HTTP/1.1):
- Uses FCFS (First-Come-First-Served) scheduling.
- Head-of-Line (HOL) Blocking: A small object trapped behind a large object must wait for the large one to finish transmitting before it can start. This delays page rendering.
The Solution (HTTP/2):
- Framing: Objects are divided into small pieces called "frames".
- Interleaving: The server interleaves frames from multiple objects. A large video file and a small icon can be sent "simultaneously" (mixed together) rather than sequentially.
Additional Features:
- Prioritization: Clients can request higher priority for certain objects.
- Server Push: Server can send unrequested objects it knows the client will need (e.g., sending CSS along with HTML).

Evolution to HTTP/3¶

HTTP/2 Limitation: Since it still runs on a single TCP connection, a single lost packet triggers TCP congestion control and stalls all object transmissions (even the ones that weren't lost).
- "Stalling all object transmissions" in HTTP/2 refers to a problem known as TCP Head-of-Line (HOL) Blocking, where a single lost packet causes the entire connection to freeze. Because HTTP/2 multiplexes all data (images, scripts, CSS) over a single TCP connection, the TCP protocol treats the mix as one continuous stream that must be delivered to the browser in strict order. Consequently, if a packet belonging to just one small object is lost, TCP refuses to deliver the successfully received packets for any other object until that missing piece is retransmitted, causing the entire page load to stall. This limitation is the primary reason HTTP/3 moved to UDP, which allows independent streams to continue loading even if one drops a packet.
HTTP/3: Moves to UDP to fix this. It adds security and reliability in the application layer (QUIC), allowing for per-object error control so one lost packet doesn't block the entire stream.

E-mail, SMTP, IMAP¶

Electronic Mail Components¶

The email system consists of three major components:

User Agents (UA): The software users interact with ("mail readers") to compose, edit, and read messages (e.g., Outlook, Apple Mail).
Mail Servers: The core infrastructure that maintains:
- Mailbox: Contains incoming messages for the user.
- Message Queue: Holds outgoing messages waiting to be sent.
SMTP (Simple Mail Transfer Protocol): The application-layer protocol used to move mail between servers.

SMTP Architecture & Protocol¶

Role: SMTP is used for the delivery/storage of messages to the receiver's server.
Transport: Uses TCP on port 25 to reliably transfer email.
Direct Transfer: The sending server acts as a TCP client and connects directly to the receiving server (TCP server).
Three Phases of Transfer:
1. Handshaking: The client and server introduce themselves (e.g., HELO command).
2. Transfer of Messages: The actual email content is sent.
3. Closure: The connection is terminated (QUIT).
Command Style: Like HTTP, it uses ASCII text commands (MAIL FROM, RCPT TO, DATA) and status codes (220, 250, 404). The response includes status code and phrase.

Once the TCP connection is open, the Server (not the client!) speaks first by sending code 220 (Service Ready). The Client responds with HELO (Hello) to introduce itself. The Server replies with 250 Hello (Pleased to meet you).

E-mail Workflow (Alice to Bob)¶

Alice (UA): Composes a message to bob@someschool.edu and sends it to her mail server.
Alice's Server: Places the message in a queue. It opens a TCP connection to Bob's mail server.
Transmission: Alice's server (Client) sends the message over the TCP connection using SMTP.
Bob's Server: Receives the message and places it in Bob's mailbox.
Bob (UA): Later invokes his user agent to read the message.

SMTP vs. HTTP¶

Push vs. Pull:
- HTTP is a Pull Protocol: The user (client) requests data from the server.
- SMTP is a Push Protocol: The sending server "pushes" the file to the receiving server.
Connections: Both use persistent connections, but SMTP is designed to send multiple messages in one go.
Message Format:
- HTTP: Each object is encapsulated in its own response message. SMTP requires message (header & body) to be in 7-bit ASCII.
- SMTP: Multiple objects (like attachments) are sent in a single multipart message.
Termination: SMTP uses a specific sequence CRLF.CRLF (a dot on a line by itself) to signal the end of a message body.

Mail Message Format (RFC 2822)¶

There is a distinction between the SMTP Commands (used by servers to route mail) and the Mail Message itself (what the user reads).

Header Lines: To:, From:, Subject:.
- Note: These are part of the file content, distinct from the SMTP RCPT TO command.
Body: The actual message content (must be ASCII characters).
Separation: A single blank line separates the headers from the body.

Mail Access Protocols (Retrieving Email)¶

Since SMTP is a "Push" protocol, it cannot be used by the receiver (Bob) to "pull" mail from his server. Special access protocols are needed.

IMAP (Internet Mail Access Protocol):
- Allows users to organize messages in folders stored on the server.
  - Messages stored on server, IMAP provides retrieval, deletion, folders of stored messages on servers
- Maintains state (which emails are read/unread) across multiple devices.
HTTP (Webmail):
- Services like Gmail or Yahoo use HTTP for the user interaction (browser to server).
- However, the servers still use SMTP to send mail to other servers behind the scenes.

The Domain Name System DNS¶

The Core Function While humans prefer using mnemonic identifiers like www.uwaterloo.ca, routers and internet hosts rely on fixed-length, 32-bit IP addresses for addressing datagrams. To bridge this gap, the Internet uses the Domain Name System (DNS), which acts as a directory service to translate between human-readable hostnames and machine-readable IP addresses.

Architecture and Implementation DNS is not a single, massive server. Instead, it is implemented as a distributed database spread across a hierarchy of many name servers.

Application-Layer Implementation: Although DNS is a core Internet function, it is implemented as an application-layer protocol.
Complexity at the Edge: This design philosophy pushes the complexity to the "network's edge" rather than burdening the core routers.

Additional Services Beyond simple translation, DNS provides critical infrastructure services:

Host Aliasing: Allows a server to have a complex "canonical" name while offering users simpler alias names.
- A canonical name is the true, official name of a host — the name that actually owns the IP address.
Mail Server Aliasing: Ensures email routing works correctly even if the mail server has a complex internal name.
Load Distribution: For high-traffic sites (like CNN or Google), DNS can return different IP addresses for the same name, rotating the load among a set of replicated web servers.

The Necessity of Decentralization¶

A centralized design (one single DNS server for the whole world) is considered impossible because it "doesn't scale".

Single Point of Failure: If the central server crashes, the entire Internet fails.
Traffic Volume: A single server cannot handle billions of queries simultaneously.
Latency: A centralized database would be physically distant from most users, causing unacceptable delays.

The DNS Server Hierarchy¶

To solve the scaling problem, DNS is organized into a tree-like hierarchy.

1. Root Name Servers These are the "contacts-of-last-resort" used when a name cannot be resolved locally.

Management: The root domain is managed by ICANN (Internet Corporation for Assigned Names and Numbers).
Infrastructure: There are 13 logical root name "servers" worldwide, though each is replicated physically many times (e.g., ~200 servers in the US) to ensure reliability and security.

2. Top-Level Domain (TLD) Servers These servers are responsible for domains such as .com, .org, .net, .edu, and country codes like .ca or .fr.

Registry Examples: Network Solutions maintains the authoritative registry for .com TLDs, while Educause manages .edu.
- They’re organizations involved in managing Internet names, but at different levels and for different audiences.

3. Authoritative DNS Servers These belong to specific organizations (like a university or company) and provide the final, authoritative mapping of hostnames to IP addresses for that organization's named hosts. Organizations can maintain their own or pay a service provider to do it.

The Local DNS Name Server¶

The Local DNS server does not strictly belong to the global hierarchy but is central to the operation.

The Middleman: When a host makes a DNS query, the request is sent to its configured Local DNS server first.
Caching Proxy: The local server attempts to answer from its cache of recent translations. If the answer is not cached, it acts as a proxy, forwarding the request into the hierarchy to find the answer.
- “proxy” means the local server is acting as an intermediary on your behalf.

DNS Resolution Methods¶

There are two primary ways a query can travel through the hierarchy:

Iterated Query ("I don't know, ask him") The burden of resolution is placed on the local DNS server.

Request: The local server asks the Root server.
Referral: The Root server replies, "I don't know, but here is the IP for the .com TLD server".
Next Step: The local server then asks the TLD server, which refers it to the Authoritative server.
Final Answer: The Authoritative server returns the actual IP address to the local server.

Recursive Query ("Let me find that for you") The burden of resolution is passed up the chain.

Handoff: The local server asks the Root, which then asks the TLD, which then asks the Authoritative server.
Return: The answer flows all the way back down the chain.
Drawback: This places a heavy load on the upper levels of the hierarchy (Root/TLD servers), as they must maintain state for every waiting request.

The real-world implementation is effectively a hybrid of both methods, used at different stages of the process.

Client → Local DNS Server: Recursive
Local DNS Server → The Internet: Iterative

DNS Hierarchy Definitions¶

1. Top-Level Domain (TLD)

Definition: The highest level of the hierarchy immediately below the root. These are responsible for the broad categories of the Internet.
Examples: .com, .org, .edu, and country codes like .ca or .fr.

2. Domain & Subdomain

Definition: These represent specific branches within the TLD. The hierarchy allows an organization to subdivide its namespace into smaller, manageable parts.
Authoritative Domain: An organization (like UMass) registers a domain (e.g., umass.edu) under a TLD. This organization is then authoritative for creating any subdomains beneath it.
Subdomain: A subdivision of a domain used to organize hosts by department or location.
- Example: cs.umass.edu is a subdomain of umass.edu (specifically for the Computer Science department).
A domain is not automatically a hostname; it becomes a hostname only if it identifies a specific host by having address records.

3. Hostname

Definition: The specific, full identifier for a single machine (host) on the network. This is the label that DNS translates into a 32-bit IP address.
Structure: It combines the specific machine name with the domain path.
- Example: In gaia.cs.umass.edu, "gaia" is the specific machine name, and the full string is the hostname.
- Example: www.uwaterloo.ca identifies the web server host "www" within the "uwaterloo.ca" domain.

Canonical name ⊆ hostnames

DNS Design Challenges and Scalability¶

The DNS is a humongous distributed database that must handle billions of records and trillions of queries every day. The design prioritizes performance because almost every Internet transaction interacts with DNS, making milliseconds count. To achieve "bulletproof" reliability and security, the system is decentralized both organizationally and physically, with millions of different organizations responsible for maintaining their own records.

Caching Strategies¶

To improve delay and reduce traffic, DNS extensively uses caching. Once a name server learns a mapping, it caches that information and immediately returns the cached mapping for subsequent queries.

Time To Live (TTL): Cache entries are not permanent; they timeout and disappear after a specific duration known as the TTL.
Root Bypass: Because TLD server addresses are typically cached in local name servers, root name servers are often bypassed in practice, reducing the load on the root infrastructure.
Consistency Issues: A limitation of this approach is that cached entries may become out-of-date. If a host changes its IP address, the rest of the Internet may not know until the old TTLs expire, meaning DNS provides only "best-effort" translation.

Resource Records (RR)¶

The distributed database stores information in the form of Resource Records (RR), formatted as (name, value, type, ttl). The meaning of the name and value fields depends on the type:

Type=A: Provides the standard mapping where name is a hostname and value is its IP address.
- If a hostname has a Type A record, then that hostname is a canonical name.
Type=NS: Used for routing within the hierarchy. name is a domain (e.g., foo.com) and value is the hostname of the authoritative name server that knows how to resolve that domain.
Type=CNAME: Handles aliasing. name is the alias (e.g., www.ibm.com) and value is the canonical (real) name (e.g., servereast.backup2.ibm.com).
Type=MX: Directs email traffic. value is the name of the mail server associated with the name.

DNS Protocol Message Format¶

The DNS protocol uses a unified format for both query and reply messages.

Header Section: Contains a 16-bit identification number that allows the client to match a reply to its original query. It also contains flags to indicate if the message is a query or reply, if recursion is desired, and if the reply is authoritative (It means the DNS answer comes directly from a server that owns the truth for that domain — not from a cache.).

Data Sections:
- Questions: Contains the name and type fields being queried.
- Answers: Contains the Resource Records (RRs) in response to the query.
  - This contains the specific data you actually asked for. It holds the Resource Records (RRs) that match the name you queried.
- Authority: Contains records for authoritative servers.
  - This contains the "signposts" pointing to other servers. It is primarily used when the current server does not know the answer but wants to tell you who to ask next (a referral). It holds Resource Records for Authoritative Servers (Type NS).
- Additional Info: Contains helpful "extra" information, such as the IP address for a mail server listed in the answer section, to save the client a second lookup.

Registering a New Domain¶

To add a new domain (e.g., "Network Utopia") to the Internet, a startup must register the name with a DNS Registrar (like Network Solutions). The registrar inserts two key records into the .com TLD server:

NS Record: Maps networkutopia.com to the hostname of its authoritative name server (dns1.networkutopia.com).
A Record: Maps that authoritative name server's hostname to its actual IP address (212.212.212.1). This "glue record" ensures that when a query reaches the TLD server, it knows exactly where to redirect the traffic.

NOTES

NS records mark delegation points in DNS, where authority for a domain is handed from a parent zone to child name servers, and they are used by resolvers to know where to send the next query rather than as the final answer.During normal hostname resolution, the resolver follows these delegations behind the scenes (root → TLD → authoritative server), so NS records typically appear in the AUTHORITY section or are cached internally, not in the ANSWER section, which is reserved for the final response to the query (such as A, AAAA, or CNAME records). NS records only appear in the ANSWER section if they are explicitly queried.

DNS Security Vulnerabilities¶

DDoS Attacks Attackers may attempt to bombard root servers with traffic to paralyze the Internet. However, this is largely unsuccessful because traffic filtering is deployed, and local DNS servers cache TLD IP addresses, allowing them to bypass the root servers entirely during an attack. Attacks on TLD servers are potentially more dangerous as they are harder to bypass.

Spoofing and Cache Poisoning In a spoofing attack, a malicious actor intercepts a DNS query and returns a bogus reply. This leads to DNS Cache Poisoning, where a DNS server accepts and caches a fake record, directing users to a fraudulent website (e.g., a fake bank site).

The industry solution is DNSSEC (RFC 4033), which adds cryptographic authentication to ensure records are genuine.

DNSSEC (Domain Name System Security Extensions) is a suite of protocols that adds a security layer to the DNS protocol by using public-key cryptography to digitally sign DNS records.

P2P Applications¶

See Peer-to-Peer (P2P) Architecture section for Architecture.

File Distribution Architectures¶

The goal of file distribution is to distribute a large file of size \(F\) from a single server to \(N\) peers. The performance difference between the two primary architectures—Client-Server and Peer-to-Peer (P2P)—is determined by how upload capacity is utilized.

Client-Server Architecture¶

In this model, the server is the bottleneck because it must upload the file individually to every single peer.

Server Load: The server must sequentially send \(N\) copies of the file. If the server's upload speed is \(u_s\), sending one copy takes \(F/u_s\), so sending \(N\) copies takes \(N \times F/u_s\).
Client Download: Each client downloads the file at a rate limited by its own download capacity \(d_i\). The slowest client takes \(F/d_{min}\).
Distribution Time Formula

Time to distribute \(F\) to \(N\) clients:

\[ D_{c-s} \ge \max \left\{ \frac{NF}{u_s}, \frac{F}{d_{min}} \right\} \]
- Interpretation: As the number of peers \(N\) increases, the time required increases linearly. The server's upload capacity is a fixed resource divided among more and more users.

P2P Architecture (Peer-to-Peer)¶

In this model, the capacity scales with the network. Every peer that downloads a chunk of the file can simultaneously upload that chunk to other peers, adding their own upload capacity (\(u_i\)) to the system.

Server Load: The server must upload at least one copy of the file to get it into the swarm (\(F/u_s\)).
Aggregate Capacity: The total system capacity is the sum of the server's upload speed plus the upload speeds of all participating peers (\(u_s + \sum u_i\)).
Distribution Time Formula

Time to distribute \(F\) to \(N\) clients:

\[ D_{P2P} \ge \max \left\{ \frac{F}{u_s}, \frac{F}{d_{min}}, \frac{NF}{u_s + \sum u_i} \right\} \]
- Interpretation: Although the demand (\(NF\)) increases linearly with \(N\), the supply (\(u_s + \sum u_i\)) also increases linearly. As a result, the distribution time stays relatively flat (constant) regardless of how many users join.

BitTorrent Protocol¶

BitTorrent is the standard implementation of P2P file distribution.

The Mechanics

Chunks: The file is divided into small 256Kb chunks. Peers send and receive these chunks purely based on availability.
Tracker: A central server that tracks which peers are currently in the swarm. When Alice joins, she registers with the tracker to get a list of peers to connect to.
Swarm: The group of peers exchanging chunks of a file.
Churn: Peers can come and go at any time (join, download, leave), making the network dynamic.
Once peer has entire file, it may (selfishly) leave or (altruistically) remain in swarm.

Chunk Selection Strategy

Requesting (Rarest First): Alice does not ask for random chunks. She determines which missing chunks are the rarest among her neighbors (held by the fewest people) and requests those first. This ensures rare chunks propagate quickly so they don't vanish if a peer leaves.

Incentive Mechanism: Tit-for-Tat BitTorrent prevents "free-riding" (downloading without uploading) using a "tit-for-tat" algorithm.

Top 4 (Unchoked): Alice measures the download rate she is receiving from all her neighbors. She sends chunks only to the 4 peers currently sending data to her at the highest rate.
Optimistic Unchoking: Every 30 seconds, Alice randomly selects one additional neighbor to send data to, regardless of their past performance.
- Purpose: This allows new peers (who have nothing to trade yet) to get their first chunk and enter the trading economy.
- Result: If this random peer reciprocates with a high speed, they may be promoted to the "Top 4" list in the next round.

How First Join Works

When you first join, you ask the Tracker for a list of peers. The Tracker gives you a random subset (e.g., 50 IP addresses). You establish TCP connections with these people to form your "neighborhood".
The "Top 4" list is strictly calculated based on upload speed (Tit-for-Tat). You send data to the 4 people who are sending data to you the fastest.
- You decide who your "Top 4" friends are based on how fast they are uploading data TO you.
When you first join, you have 0 chunks. You have nothing to trade. Therefore, nobody ranks you in their "Top 4" because you cannot send them anything.
You don't rely on being in the Top 4 immediately. Instead, you wait for a neighbor to randomly select you as their "Optimistic Unchoke" (the 1 random peer they help every 30 seconds). Once you get that first chunk from them, you can enter the market and start trading to get into people's Top 4.

Video Streaming and Content Distribution Networks¶

Video Streaming Context and Challenges¶

Video traffic is the major consumer of Internet bandwidth, with platforms like Netflix and YouTube accounting for approximately 80% of residential ISP traffic. The fundamental architecture faces two massive challenges:

Scale: The system must reach approximately 1 billion users.
Heterogeneity: Users have vastly different capabilities, ranging from wired connections to mobile data, and from bandwidth-rich to bandwidth-poor environments.
Variable Network Conditions: In a simple server-client streaming scenario, server-to-client bandwidth varies over time due to congestion, which can lead to packet loss, delay, and poor video quality.
Solution: To address these issues, the industry uses distributed, application-level infrastructure.

Dynamic Adaptive Streaming over HTTP (DASH)¶

DASH allows the system to handle varying bandwidth by shifting the "intelligence" to the client side.

Server Responsibilities The server divides the video file into multiple small chunks. Each chunk is encoded at multiple different bit rates (qualities) and stored in different files across various CDN nodes. The server creates a manifest file that provides the URLs for these different chunks.

Client Responsibilities ("The Intelligence") The client periodically estimates the server-to-client bandwidth and consults the manifest to request one chunk at a time.

What (Encoding Rate): The client chooses the maximum coding rate sustainable given its current bandwidth, requesting higher quality when bandwidth is available.
When (Timing): The client determines when to request chunks to prevent buffer starvation or overflow.
Where (Location): The client decides which server to request the chunk from, typically choosing a URL that is "close" or has high available bandwidth.

Streaming video = encoding + DASH + playout buffering

Encoding: The server divides the video into small chunks and encodes every single chunk at multiple different bit rates (e.g., Low, Medium, High quality).
DASH: The client (your browser/app) constantly monitors your internet speed. Based on that speed, it dynamically decides which encoding rate to request for the next chunk.
Playout Buffering: The client does not display a chunk the instant it arrives. instead, it stores a few seconds of video in a local "buffer" (waiting room) before playing it. This absorbs network jitter. If the internet lags for a second, the video doesn't freeze because the player just pulls the next frame from the buffer while waiting for the network to catch up. The client manages this buffer carefully to avoid "starvation" (empty buffer = buffering wheel) or "overflow".

Content Distribution Networks (CDNs)¶

The challenge of streaming content to hundreds of thousands of simultaneous users means a single, large "mega-server" is not a viable solution because it creates a single point of failure and suffers from network congestion. Instead, networks use CDNs to store and serve multiple copies of videos at geographically distributed sites.

Placement Strategies

Enter Deep: This strategy pushes CDN servers deep into many access networks to get close to users (e.g., Akamai has 240,000 servers in >120 countries).
Bring Home: This strategy uses a smaller number of large server clusters placed in Points of Presence (POPs) near access networks (e.g., Limelight).

Operation and OTT In this "Over The Top" (OTT) model, Internet host-host communication is treated as a service. When a subscriber requests content, the service provider returns a manifest file. The client then retrieves content using the manifest, potentially switching between different rates or copies if a network path becomes congested.

Case Study: Netflix Architecture¶

Netflix illustrates the separation of control and data planes in streaming.

Registration: The user (Bob) manages his account and browses videos via the Netflix registration/accounting servers.
Upload: Netflix uses Amazon Cloud to upload copies of multiple versions of the video to its Open Connect CDN servers.
Manifest Delivery: When Bob selects a video, the system returns a manifest file for that specific video.
Streaming: Bob's client uses the manifest to select a specific CDN server (DASH), contacts it, and begins streaming the video content directly from the CDN.

Socket Programming with UDP and TCP¶

Overview¶

Concept

Goal: Build client/server applications that communicate over the network.
Socket: Defined as the "door" between the application process and the transport layer protocols (TCP/UDP).
Application Example: A client sends a line of text; the server capitalizes it and sends it back.

UDP Socket Programming (Unreliable)¶

Characteristics

No Connection: There is no handshaking before sending data.
Explicit Addressing: The sender must explicitly attach the destination IP and Port to every packet.
Unreliable: Data ("datagrams") may be lost or received out of order.

Python Implementation (UDP)

Socket Type: socket(AF_INET, SOCK_DGRAM).
- AF_INET stands for IPv4, and SOCK_DGRAM means UDP protocal.
Client:
- Uses clientSocket.sendto(message, (serverName, serverPort)).
  - This method will attach the IP address to the message
- Uses clientSocket.recvfrom(2048) to get the reply.
Server:
- Uses bind(('', serverPort)) to listen on a specific port.
- Extracts the message and client's address from the received packet using recvfrom and uses the address to send the reply back.

TCP Socket Programming (Reliable)¶

Characteristics

Connection-Oriented: The client must first establish a connection (handshake) with the server before sending data.
Reliable Pipe: Provides a reliable, in-order byte-stream transfer (no data loss or reordering).
Implicit Addressing: Once connected, the socket knows where to send data; you do not need to attach the address to every packet.
The server distinguishes clients by looking at the unique combination of Source IP Address and Source Port Number attached to every incoming packet.

Python Implementation (TCP)

Socket Type: socket(AF_INET, SOCK_STREAM).
Client:
- Initiates contact using clientSocket.connect((serverName, serverPort)).
Server:
- Uses serverSocket.listen(1) to wait for incoming requests.
  - Set the backlog. It specifies the maximum number of unaccepted connections that can wait in the queue. If 1 client is already waiting to be accepted and another client tries to connect, the OS may reject the new connection.
- Uses serverSocket.accept() to complete the connection setup.

Why TCP Servers Use Two Different Sockets¶

In TCP, the server maintains two distinct types of sockets to handle concurrency and connection management efficiently.

1. The "Welcoming" Socket (serverSocket)

Role: This is the initial "door" or receptionist.
Behavior: It stays permanently bound to the server's public port (e.g., Port 12000) and listens for new strangers trying to knock.
Action: When a client contacts the server, this socket handles the initial handshake. It does not handle the actual data conversation.

2. The "Connection" Socket (connectionSocket)

Role: This is a dedicated "private line" created specifically for one client.
Creation: When the serverSocket.accept() function returns, it automatically creates this new socket.
Behavior: The server uses this new socket to exchange data (send/receive) with that specific client. When the conversation is over, this socket is closed, but the Welcoming Socket remains open.

Why separate them?¶

The slides explain that this architecture "allows the server to talk with multiple clients" simultaneously.

If the server only had one socket (the welcoming one) and used it to chat with Client A, Client B would get a "busy signal" (or just wait) until Client A finished.
By spawning a new Connection Socket for every client, the Welcoming Socket is immediately freed up to go back to listening for the next client .