1. What’s a Network App?

A network app is a program that:

• Runs on devices like your phone, computer, or server (called end systems).
• Talks to other devices over the internet or a network (e.g., a website you visit on your browser).
• You don’t need to worry about writing software for the core network stuff like routers—they just move
ata, not run apps.
• Putting apps on end devices (not the network core) makes it easy and fast to create and share new apps.

Think of it like: Writing an app for your phone to chat with a friend online, not messing with the phone towers
that carry the signal.

2. Client-Server Setup (Like a Restaurant)

This is how many apps work, with two roles:

• Server (the chef):

o Always on and ready to serve (like a website server in a data center).
o Has a fixed address (IP address) so you can always find it.
o Handles lots of requests at once (scalable).
• Clients (the customers):
o You (on your phone or computer) contact the server when you need something (e.g., loading a
webpage).
o You might connect or disconnect anytime (intermittently).
o Your address (IP) might change, but you still reach the server.

o Clients don’t talk directly to each other—everything goes through the server.

Examples: Browsing the web (HTTP), checking email (IMAP), or downloading files (FTP).

3. Peer-to-Peer (P2P) Setup (Like a Potluck)

This is different—no always-on server. Instead:

• Everyone’s device (peers) talks directly to each other.

• You ask for something (e.g., a file) from another peer, and you share stuff back.
• It scales well because more people joining means more sharing power.
• Peers can come and go, and their addresses might change.
• It’s trickier to manage than client-server.
Example: Sharing files with BitTorrent—everyone’s computer helps distribute the data.

4. How Programs Talk (Processes Communicating)

• A “process” is just a program running on a device (e.g., your browser or a server app).
• On the same device: Two programs talk using the device’s operating system (like roommates chatting n
the same house).
• On different devices: Programs send messages over the network (like texting someone far away).

Client-Server Example:

• Your browser (client) sends a request; the website server (server) waits for and responds to it.
• In P2P, both peers can send and receive, like friends chatting back and forth.

5. Sockets (The Door for Talking)

• A socket is like a door on your device’s program for sending or receiving data over the network.
• One program opens its door to send a message, and another opens its door to receive it.
• There’s a door (socket) on both sides of the conversation.

Think of it like: Sending a letter through a mailbox—each house has its own mailbox (socket).

6. Finding the Right Program (Addressing)

• Every device has a unique address (IP address, like a house number).
• But how do you find the right program on that device? You use a port number (like an apartment
umber).
• Together, the IP address and port number tell the network exactly which program to talk to.

Examples:

• Web servers often use port 80.

• Email servers might use port 25.
• Many programs can run on one device, each with its own port.

7. App Rules (Application-Layer Protocol)

• This is the “language” apps use to talk to each other.

 • It defines:
o What kinds of messages are sent (e.g., “Give me this webpage”).
o How the message looks (syntax, like grammar).
o What the message means (semantics, like understanding “hello”).
o When and how to send replies (rules, like taking turns talking).

Open Protocols:

• Publicly defined (e.g., HTTP for websites, SMTP for email) so anyone can use them.

Proprietary Protocols:

• Private, made by companies (e.g., Skype, Zoom).

8. What Does an App Need from the Network? (Transport Services)

Apps have different needs from the network (handled by TCP or UDP). Here’s what matters:

• Data Loss:
o Some apps need every bit to arrive (e.g., downloading a file—no loss).
o Others can handle missing bits (e.g., a live video can skip a frame—loss-tolerant).
• Speed (Throughput):
o Elastic: Can handle slow or fast speeds (e.g., email, file downloads).
o Inelastic: Needs a steady minimum speed (e.g., streaming video).
• Time Sensitivity:
o Some need instant responses (e.g., video calls, games—delays ruin it).
o Others can wait (e.g., downloading a file—time doesn’t matter).

Examples:

• File downloads: No loss, flexible speed, not time-sensitive.

• Real-time video: Can lose some data, needs steady speed, very time-sensitive (milliseconds matter).
• Text messages: No loss, flexible speed, not time-sensitive.

9. Network Delivery Options (TCP vs. UDP)

The internet gives you two ways to send data:

• TCP (Reliable Delivery):

o Makes sure data arrives correctly, in order, and without loss.
o Manages traffic to avoid overwhelming the network.
o Sets up a connection first (like calling before sending a package).
o Doesn’t guarantee speed or security, but it’s reliable.
• UDP (Fast but Unreliable):
 o Sends data quickly but doesn’t guarantee it arrives or in order.
o No traffic control or connection setup—just fires and forgets.
o Used for apps where speed matters more than perfect delivery (e.g., live streaming, games).

Why UDP? It’s faster for apps that can handle missing data, like real-time video or games.

10. Apps, Their Protocols, and Delivery Methods

Here’s a quick cheat sheet of common apps, their “languages” (application protocols), and how they’re
delivered (TCP or UDP):

App App Protocol Delivery (TCP or UDP)

File transfer/download FTP TCP (reliable)
Email SMTP TCP (reliable)
Web browsing HTTP TCP (reliable)
Internet calls SIP, RTP TCP or UDP
Streaming video/audio HTTP, DASH TCP (mostly)
Online games Proprietary (e.g., WOW) UDP or TCP

1. Application Layer: Overview

The application layer is the top layer of the network stack where users interact with apps. It includes:

• Principles of network applications: How apps work over networks (we covered some earlier, like
client-server and P2P).
• P2P applications: Peer-to-peer apps where devices share directly (e.g., BitTorrent for file sharing).
• Common network apps:
o Web and HTTP: Browsing websites (we’ll dive deeper below).
o E-mail: SMTP, IMAP: Sending (SMTP) and retrieving (IMAP) emails.
o The Domain Name System (DNS): Translates human-friendly names (e.g., [Link])
into machine-readable IP addresses (e.g., [Link]).

Think of it like: The application layer is the “front desk” where you use apps like browsing the web or
checking email, while DNS is like a phonebook for finding the right address.

2. Web and HTTP

HTTP (HyperText Transfer Protocol) is the foundation of the web.

• What’s a web page?

o A web page is made of objects: text, images (JPEG, GIF), videos, etc., which can be stored on
different servers.
o The base of a web page is an HTML file (the main document) that includes links to other objects
(like images or videos), each addressable by a URL (e.g.,
[Link]/someDept/[Link]).
o A URL has two parts:
▪ Host name: The website’s name (e.g., [Link]).
▪ Path name: The specific location of the file (e.g., /someDept/[Link]).

Think of it like: A web page is like a magazine article with text and photos, where each photo might be stored
in a different folder on a server, and the URL is the address to find it.

3. HTTP Overview

HTTP is the protocol that makes web browsing work. It’s a client-server protocol where:

• Client (your browser): Sends requests (e.g., “Show me this webpage”).

• Server (website server): Responds with the requested objects (e.g., HTML, images).

Key Features:

• Uses TCP: Reliable delivery (no lost data, ordered packets).

• The client starts a TCP connection (usually on port 80).
• The server accepts the connection.
• Messages (HTTP requests and responses) are exchanged between the browser (client) and web server.
• After the exchange, the TCP connection closes.

HTTP is “stateless”:

• It doesn’t remember past requests. Each request is treated independently.

• This means the server doesn’t keep track of what you did before (e.g., it doesn’t know you visited page
A before page B).
• If you want to maintain some “memory” (like tracking a shopping cart), you need something extra—
cookies (we’ll cover that later).

4. HTTP Connections: Two Types

HTTP can use two approaches for connections:

• Non-persistent HTTP:
1. One object (e.g., an image) is sent over one TCP connection.
2. The connection closes after sending that object.
3. For multiple objects (e.g., a webpage with text and 10 images), it requires multiple TCP
connections—one for each object.
o Issues: Slow because each object needs its own connection setup, causing overhead (extra time).
• Persistent HTTP (HTTP/1.1):
o A single TCP connection stays open for the server to send multiple objects.
o Objects are sent one after another over the same connection between client and server.
o The connection closes only when done.
o Advantages: Faster because it avoids opening multiple connections, cutting response time in
half for multiple objects.

Example of Non-persistent HTTP (for [Link]/someDept/home_index with 10 images):

1. You enter the URL in your browser.

2. Your browser opens a TCP connection to the server at [Link] on port 80.
3. It sends an HTTP request for the HTML file.
4. The server accepts the connection, sends the HTML, and closes the connection.
5. The browser parses the HTML, finds references to 10 images, and repeats steps 2–4 for each image (11
connections total).

• Response time: Takes 2 round-trip times (RTTs) per object plus file transmission time (RTT is the time
for a message to go to the server and back).

Persistent HTTP is faster because it keeps the connection open, sending all objects (e.g., HTML + 10 images)
through one connection, reducing delays.

5. HTTP Request Message

An HTTP request is what your browser sends to the server. It has:

• Two types: Request and response messages.

• Format: ASCII (human-readable text), with:
o A request line (e.g., GET /[Link] HTTP/1.1).
o Header lines (e.g., specifying browser type or language).
o Optional body (data, if needed, like form input).
Common Request Methods:

• GET: Asks for a specific page or object (e.g., GET /animals/monkeys/banana HTTP/1.1 to get a
webpage about monkeys and bananas).
• POST: Sends user input (e.g., form data) to the server, including it in the message body.
• HEAD: Requests only headers (not the full object), useful for checking if a file exists.
• PUT: Uploads a new file or updates an existing one at a specified URL.

Think of it like: You’re ordering food (GET) or placing an order with special instructions (POST).

6. HTTP Response Message

The server sends this back to your browser. It includes:

• A status line (e.g., HTTP/1.1 200 OK, showing success or an error).

• Header lines (e.g., file type, server info).
• Optional body (the actual content, like HTML, images).

HTTP Status Codes (examples in the first line of the response):

• 200 OK: Request succeeded, object is in the message.

• 301 Moved Permanently: Object moved, new location specified.
• 400 Bad Request: Request not understood by the server.
• 404 Not Found: Requested document isn’t on this server.
• 505 HTTP Version Not Supported: Server doesn’t support the HTTP version.

Think of it like: The restaurant replying, “Here’s your food” (200 OK) or “Sorry, we don’t have that”
(404 Not Found).

7. Maintaining User/Server State: Cookies

HTTP is stateless, so it doesn’t remember past interactions. Cookies solve this by maintaining some “memory”
between transactions.

• How Cookies Work:

1. The server sends a cookie in an HTTP response (a unique ID, like 1678).
2. Your browser stores the cookie on your device.
3. Next time you request something, your browser sends the cookie back.
4. The server uses the cookie to identify you or track your actions (e.g., shopping cart, login status).
5. The website’s back-end database links the cookie to your data.
Example (Amazon):

• You visit Amazon, and it gives your browser a cookie (e.g., ID 1678).
• Next time you visit, your browser sends the cookie, and Amazon knows it’s you, showing your cart or
recommendations.

Uses for Cookies:

• Shopping carts (remembering items you added).

• Recommendations (suggesting products based on past behavior).
• Login tracking (keeping you logged in).

Challenge: Since HTTP doesn’t naturally maintain state, cookies carry that state in messages to connect
multiple interactions.

1. Web Caches (aka Proxy Servers)

What are they?

• A web cache is like a local storage spot (a “middleman”) that saves copies of web pages or objects (like
images, videos) you’ve visited.
• It sits between your browser and the origin server (the main website server) and acts as both a client
(requesting from the origin) and a server (serving you).

How do they work?

• Goal: Satisfy your browser’s requests without always going to the origin server.
• Your browser sends all HTTP requests to the cache.
• If the object (e.g., a webpage or image) is in the cache, the cache returns it to you directly.
• If not, the cache requests it from the origin server, stores a copy, and then sends it to you.
• The origin server can tell the cache how long to keep an object fresh using a “Cache-Control: max-
age=seconds” header.

Why use web caches?

• Faster response time: The cache is closer to you than the origin server, so it delivers content quicker.
• Reduce traffic: Cuts down on internet traffic at your institution or network, easing congestion.
• Efficient delivery: Helps content providers (like websites) deliver data more effectively by reducing
load on their servers.

Think of it like: A local library stocking popular books so you don’t always have to order from a far-away
warehouse (origin server).
2. Caching Example

Here’s a practical scenario to understand web caches:

Scenario (without a cache):

• You’re at an institution with a 1.54 Mbps access link to the public internet.
• It takes 2 seconds (RTT, or round-trip time) for a request to travel from the institutional router to the
origin server.
• Webpages are 100,000 bits on average, and browsers request them at 15/sec from origin servers.
• Average data rate to browsers: 1.5 Mbps.

Performance (without cache):

• Access link utilization: How busy the link is = 0.015 (very low, 1.5% busy).
• LAN utilization: 0.0015 (negligible on the local network).
• End-to-end delay: Time from request to delivery = 2 seconds (RTT) + Internet delay + LAN delay.

Options to improve performance:

• Option 1: Buy a faster access link (1.54 Mbps → 154 Mbps):

o Faster link reduces delay, but it’s expensive.
o New performance: Link utilization drops to 0.007 (0.7% busy), end-to-end delay is still about 2
seconds (faster but costly).
• Option 2: Install a web cache:
o Cheaper than upgrading the link.
o Cache sits locally, serving requests faster if it has the object.
o Performance with cache:
▪ If 40% of requests are served by the cache (cache hit rate = 0.4), with low delay (e.g., 1
msec).
▪ 60% of requests go to the origin server (cache miss), taking 2 seconds RTT + file
transmission time.
▪ Link utilization: Drops to 0.9/154 Mbps = 0.0058 (0.58% busy, much better than
without cache).
▪ Average end-to-end delay: 0.4 (delay from cache, 1 msec) + 0.6 (delay from origin, ~2
seconds) ≈ 1.2 seconds (faster and cheaper than upgrading the link).

Conclusion: A web cache is a cost-effective way to speed up web access and reduce network load.

3. Browser Caching: Conditional GET

What is it?

• Your browser can store (cache) web objects locally (e.g., images, pages) to avoid re-downloading them.
• But what if the object on the server has changed? The browser uses a Conditional GET to check.

How it works:

• Goal: Don’t send the object again if it hasn’t changed, saving time and data.
• Your browser sends an HTTP request with an “If-modified-since:
<date>
” header, referencing its cached copy.
• The server checks if the object has changed since that date:
o If not modified, it responds with “HTTP/1.1 304 Not Modified” (no data sent, just confirmation).
o If modified, it sends “HTTP/1.1 200 OK” with the updated object.

Think of it like: Checking if a book in your local library has a new edition before ordering from the
warehouse—if not, you’re good with the copy you have.

4. HTTP/2

What is it?

• HTTP/2 is an update to HTTP/1.1, designed to make web requests faster, especially for multiple objects
(like a webpage with images and videos).

Key Goal: Decrease delay in multi-object HTTP requests.

• HTTP/1.1 Issues: Used multiple, pipelined GETs over a single TCP connection, but:
o Server responded in order (FCFS, first-come, first-served scheduling).
o If one object was delayed (e.g., a large video), smaller objects behind it waited (called Head-of-
Line, or HOL, blocking).
o TCP loss recovery (retransmitting lost packets) stalled all object transmissions.
• HTTP/2 Improvements (RFC 7540, 2015):
o Keeps using a single TCP connection (no multiple parallel connections like HTTP/1.1).
o Increases flexibility for servers in sending objects.
o Allows transmission of requested objects based on client-specified priority (not just FCFS).
o Pushes unrequested objects to the client (e.g., predicting what you might need).
o Divides objects into smaller frames and schedules frame transmission to mitigate HOL
blocking—objects arrive faster, even if some data is delayed.

Example of HOL Blocking Mitigation:

• HTTP/1.1: If you request 1 large video file and 3 smaller images, the video delay holds up the images.
• HTTP/2: Breaks objects into frames, interleaves their transmission, so smaller images arrive quickly,
while the video might be slightly delayed but doesn’t block others.
Think of it like: Instead of waiting for a slow truck to deliver all packages, HTTP/2 splits them into smaller
deliveries that can arrive out of order but faster overall.

5. HTTP/3

What is it?

• HTTP/3 builds on HTTP/2 but switches from TCP to UDP for transport, adding more improvements.

Key Features:

• Over single TCP connection (like HTTP/2), but solves issues with TCP:
o TCP packet loss still stalls all object transmissions in HTTP/2, reducing speed.
o HTTP/3 uses UDP, which doesn’t have this problem, increasing overall throughput and reducing
delays.
• Adds security, per-object error handling, and congestion control (more advanced than TCP or
HTTP/2).
• More details are handled in the transport layer (beyond HTTP).

Think of it like: HTTP/3 is like using a faster, more flexible delivery service (UDP) instead of the traditional
truck (TCP), with extra security and error fixes.

Numerical Example: Web Caching Scenario

Let’s use the "Caching Example" from the slides to explain the calculations. We’ll break it down into the
original scenario (without a cache) and the two options (faster link or web cache), then create a sample question
for practice.

Original Scenario (Without Cache)

• Access link rate: 1.54 Mbps (megabits per second).

• RTT from institutional router to server: 2 seconds.
• Average web object size: 100,000 bits.
• Average request rate from browsers to origin servers: 15 requests/second.
• Average data rate to browsers: 1.5 Mbps.

Calculations:
 1. Access Link Utilization:
o Utilization = (Data rate used) / (Link capacity).
o Data rate used = Average request rate × Average object size.
o Average request rate = 15 requests/second.
o Average object size = 100,000 bits.
o Data rate used = 15 × 100,000 = 1,500,000 bits/second = 1.5 Mbps.
o Link capacity = 1.54 Mbps.
o Utilization = 1.5 Mbps / 1.54 Mbps ≈ 0.974 (or 97.4%, but the slide shows 0.015—let’s assume a
typo or simplified value; we’ll use 0.015 as given).
o Corrected Interpretation: The slide likely intends a lower utilization (0.015 = 1.5%), possibly
due to a smaller effective data rate or typo. Let’s proceed with 0.015 for consistency with the
slide.
2. LAN Utilization:
o LAN utilization = 0.0015 (very low, as shown in the slide, likely due to local network capacity
being much higher, e.g., 1 Gbps).

3. End-to-End Delay:
o End-to-end delay = RTT + Internet delay + LAN delay.
o RTT = 2 seconds (given).
o Internet delay and LAN delay are not explicitly stated but assumed minimal in the slide.
o So, end-to-end delay ≈ 2 seconds (as implied by the slide).

Performance (Without Cache):

• Access link utilization = 0.015 (1.5% busy).

• LAN utilization = 0.0015 (negligible).
• End-to-end delay ≈ 2 seconds.

Option 1: Buy a Faster Access Link (154 Mbps)

• New access link rate: 154 Mbps.

• RTT from institutional router to server: Still 2 seconds (RTT doesn’t change with link speed, only
delay from transmission does).
• Web object size: 100,000 bits.
• Average request rate: 15 requests/second.
• Average data rate to browsers: 1.5 Mbps (unchanged).

Calculations:

1. Access Link Utilization:

o Data rate used = 1.5 Mbps (15 requests/sec × 100,000 bits/request = 1,500,000 bits/sec).
o New link capacity = 154 Mbps.
 o Utilization = 1.5 Mbps / 154 Mbps ≈ 0.00974 (or 0.97%, but the slide shows 0.007—let’s use
0.007 as given, possibly a rounded value).
o Slide Value: Utilization = 0.007 (0.7% busy).

2. LAN Utilization:
o Remains 0.0015 (LAN isn’t affected by the access link upgrade).

3. End-to-End Delay:
o End-to-end delay = RTT + Transmission delay (Internet + LAN).
o RTT = 2 seconds.
o Transmission delay for 100,000 bits over 154 Mbps = (100,000 bits) / (154,000,000 bits/sec) ≈
0.000649 seconds (0.649 msec, negligible).
o Assuming minimal Internet and LAN delays, end-to-end delay ≈ 2 seconds (still dominated by
RTT, as the slide implies no significant change in delay beyond cost).

Performance (With Faster Link):

• Access link utilization = 0.007 (0.7% busy).

• LAN utilization = 0.0015.
• End-to-end delay ≈ 2 seconds.
• Cost: Expensive (upgrading hardware).

Option 2: Install a Web Cache

• Access link rate: Still 1.54 Mbps.

• RTT from institutional router to server: 2 seconds.

• Average web object size: 100,000 bits.

• Average request rate: 15 requests/second.
• Average data rate to browsers: 1.5 Mbps.
• Cache hit rate: 0.4 (40% of requests served by the cache, with low delay, e.g., 1 msec).
• Cache miss rate: 0.6 (60% of requests go to the origin server, taking 2 seconds RTT + transmission
ime).
Calculations:

1. Access Link Utilization (With Cache):

o Total data rate without cache = 1.5 Mbps (15 requests/sec × 100,000 bits/request).
o With cache, 40% of requests are served locally (no load on the access link).
o 60% of requests (misses) use the access link: 0.6 × 1.5 Mbps = 0.9 Mbps.
o Link capacity = 1.54 Mbps.
o Utilization = 0.9 Mbps / 1.54 Mbps ≈ 0.5844 (or 58.44%, but the slide shows 0.0058—let’s use
0.0058, possibly a typo or specific assumption).
o Slide Value: Utilization = 0.0058 (0.58% busy, suggesting a very low load—likely a calculation
error; let’s assume it’s meant to be higher, but we’ll stick to the slide for consistency).

2. LAN Utilization:
o Not explicitly recalculated, but assumed minimal (e.g., 0.0015, as before, since cache is local).
3. Average End-to-End Delay (With Cache):
o Cache Hit (40%): Delay = 1 msec (very fast, local cache response).
o Cache Miss (60%): Delay = RTT + Transmission delay ≈ 2 seconds + (100,000 bits / 1.54
Mbps).
o Transmission delay = 100,000 bits / 1,540,000 bits/sec ≈ 0.0649 seconds (64.9 msec).
o Total miss delay ≈ 2 + 0.0649 ≈ 2.0649 seconds.
o Average delay = (0.4 × 1 msec) + (0.6 × 2.0649 seconds).
o Convert 1 msec to seconds = 0.001 seconds.
o Average delay = (0.4 × 0.001) + (0.6 × 2.0649) = 0.0004 + 1.23894 ≈ 1.23934 seconds (or ~1.2
seconds, as the slide approximates).

Performance (With Cache):

• Access link utilization = 0.0058 (0.58% busy, likely a typo—should be higher, but we’ll use the slide
value).
• LAN utilization = ~0.0015 (minimal).
• Average end-to-end delay ≈ 1.2 seconds.
• Cost: Cheap (adding a cache is less expensive than upgrading the link).

Conclusion: Installing a web cache is cheaper and reduces average delay (1.2 seconds vs. 2 seconds) compared
to buying a faster link, while also lowering link utilization.

Sample Question for Practice

Question: An institution has a 1.54 Mbps access link to the internet, with a 2-second RTT to the origin server.
Webpages average 100,000 bits, and browsers request them at 15 requests/second, generating a 1.5 Mbps data
rate to browsers. The current access link utilization is 0.015, and LAN utilization is 0.0015, with an end-to-end
delay of 2 seconds.

1. If the institution installs a web cache with a 40% hit rate (cache serves requests in 1 msec, misses take 2
seconds RTT plus transmission time), calculate:
o The new access link utilization.
o The average end-to-end delay.
o Compare the cost and performance to upgrading the access link to 154 Mbps (assume utilization
drops to 0.007, delay remains ~2 seconds, but it’s expensive).

Solution:

1. New Access Link Utilization (With Cache):

o Total data rate without cache = 1.5 Mbps.
o Cache hits (40%) don’t use the access link, so only cache misses (60%) do: 0.6 × 1.5 Mbps = 0.9
Mbps.
o Link capacity = 1.54 Mbps.
o Utilization = 0.9 Mbps / 1.54 Mbps ≈ 0.5844 (58.44%).
o Note: The slide shows 0.0058, which seems incorrect. Based on the data, 0.5844 is more
accurate, but for exam purposes, use 0.0058 if the slide is the reference (assume a typo or
specific assumption in the problem).

2. Average End-to-End Delay (With Cache):

o Cache hit (40%): Delay = 1 msec = 0.001 seconds.
o Cache miss (60%): Delay = RTT + Transmission delay.
o Transmission delay = 100,000 bits / 1.54 Mbps = 100,000 / 1,540,000 ≈ 0.0649 seconds (64.9
msec).
o Total miss delay = 2 + 0.0649 ≈ 2.0649 seconds.
o Average delay = (0.4 × 0.001) + (0.6 × 2.0649) = 0.0004 + 1.23894 ≈ 1.23934 seconds (or ~1.2
seconds, as in the slide).

3. Comparison (Cache vs. Faster Link):

o With Cache:
▪ Utilization ≈ 0.0058 (slide value, though likely incorrect—should be ~0.58).
▪ Average delay ≈ 1.2 seconds.
▪ Cost: Cheap (installing a cache).
4.
o With Faster Link (154 Mbps):
▪ Utilization = 0.007 (0.7% busy).
▪ Average delay ≈ 2 seconds (RTT dominates, transmission delay is negligible).
 ▪ Cost: Expensive (upgrading hardware).
5.
o Conclusion: The web cache is cheaper and faster (1.2 seconds vs. 2 seconds), making it the
better option.

Final Answer:

• New access link utilization with cache: 0.0058 (or 0.5844, depending on interpretation).
• Average end-to-end delay with cache: ~1.2 seconds.
• Comparison: Cache is cheaper and reduces delay compared to the expensive faster link option.

Explanation Notes

• RTT (Round-Trip Time): The time for a request to go to the server and back (2 seconds here).
• Transmission Delay: Time to send the object over the link = Object size / Link rate.
• Utilization: How much of the link’s capacity is used, calculated as (Data rate) / (Link capacity).
• Cache Hit Rate: Percentage of requests served by the cache (40% here), reducing load on the access
link.
• Assumptions: The slide’s utilization values (0.015, 0.007, 0.0058) may have typos or specific
assumptions (e.g., lower effective data rates). For accuracy, use the calculated values unless the exam
specifies the slide’s values.

Formula Description Variables Example from Scenario

Link Utilization = (Data Measures how much of the - Data Rate Used (bps) - Without cache: 1.5 Mbps /
Rate Used) / (Link link’s capacity is being <br> 1.54 Mbps ≈ 0.974 (or 0.015
Capacity) used, expressed as a - Link Capacity (bps) as per slide)
fraction or percentage. <br>
- With faster link: 1.5 Mbps /
154 Mbps ≈ 0.00974 (or
0.007 per slide)
<br>
- With cache: 0.9 Mbps / 1.54
Mbps ≈ 0.5844 (or 0.0058
per slide)
Transmission Delay = Time taken to transmit an - Object Size (bits) - 100,000 bits / 1.54 Mbps =
Object Size / Link Rate object over the link, <br> 100,000 / 1,540,000 ≈ 0.0649
assuming no queuing or - Link Rate (bps) seconds (64.9 msec)
other delays. <br>
- With 154 Mbps: 100,000 /
154,000,000 ≈ 0.000649
seconds (0.649 msec)

End-to-End Delay Total time from sending a - RTT (seconds) - 2 seconds (RTT) + 0.0649
(Without Cache) = RTT request to receiving the <br> seconds (transmission) ≈
+ Transmission Delay + response, including round- - Transmission Delay 2.0649 seconds (simplified to
Other Delays trip time and transmission (seconds) 2 seconds in slide due to
delays. <br> minimal other delays)
- Other Delays (e.g.,
Internet, LAN, queuing)

End-to-End Delay (With Weighted average of delays - Cache Hit Rate - (0.4 × 0.001) + (0.6 ×
Cache) = (Cache Hit for cache hits and misses, (fraction, e.g., 0.4) 2.0649) = 0.0004 + 1.23894 ≈
Rate × Cache Delay) + where cache hits are fast <br> 1.23934 seconds (or ~1.2
(Cache Miss Rate × Miss and misses include RTT and - Cache Delay (seconds, seconds as per slide)
Delay) transmission. e.g., 0.001 sec)
<br>
- Cache Miss Rate
(fraction, e.g., 0.6)
<br>
- Miss Delay (seconds,
e.g., 2.0649 sec)

Data Rate Used = Calculates the total data - Request Rate - 15 requests/sec × 100,000
Request Rate × Object rate generated by browser (requests/second) bits/request = 1,500,000
Size requests, assuming all <br> bits/sec = 1.5 Mbps
requests go to the origin - Object Size
without caching. (bits/request)

Data Rate With Cache = Adjusts the data rate used - Cache Miss Rate - 0.6 × 1.5 Mbps = 0.9 Mbps
Cache Miss Rate × on the access link when a (fraction, e.g., 0.6) (load on access link with 40%
(Request Rate × Object cache is present, <br> cache hits)
Size) accounting for only cache - Request Rate
misses. (requests/second)
<br>
- Object Size
(bits/request)
1. Application Layer: Overview

The application layer is the top layer of the network where you use apps like browsing the web, sending emails,
or looking up website addresses. It includes:

• Principles of network applications: How apps work over networks (like client-server or P2P, which
we’ve covered before).
• P2P applications: Peer-to-peer apps where devices share directly (e.g., file sharing).
• Common apps:
o Web and HTTP: Browsing websites (we covered this earlier).
o E-mail: SMTP, IMAP: Sending and retrieving emails.
o DNS: Translating human-friendly names (e.g., [Link]) into computer-friendly IP
addresses (e.g., [Link]).
o Video streaming and content distribution networks: Delivering videos or files efficiently
(e.g., YouTube or Netflix).

Think of it like: The application layer is the “user-friendly part” of the internet where you interact with apps,
while lower layers handle the technical stuff like routing data.

2. E-mail: Overview

Email is a common way to send messages over the internet. Here’s how it works in simple terms:

Three Major Components:

• User agents: These are the email programs or apps you use, like Outlook, Gmail, or the mail app on
your phone. They let you write, read, and manage emails. You compose, send, or read messages using
these tools, often stored on a server.
• Mail servers: These are the behind-the-scenes computers that store and transfer emails. They hold
incoming messages for users (in mailboxes) and send outgoing messages.
• Simple Mail Transfer Protocol (SMTP): This is the protocol (set of rules) that mail servers use to send
emails to each other.

Think of it like: You’re writing a letter (user agent), putting it in a mailbox (mail server), and the postal service
(SMTP) delivers it to your friend’s mailbox.

E-mail: Mail Servers

Mail servers manage emails by:

• Storing incoming messages in users’ mailboxes (like a digital inbox).

• Queuing outgoing messages (holding them until they can be sent).
• Using SMTP to send emails between servers.

There are two types of mail servers in this process:

• Client (sending mail server): The server that sends your email.
 • Server (receiving mail server): The server that receives the email for the recipient.

Think of it like: One post office sends your letter, and another post office receives it for your friend.

3. SMTP (Simple Mail Transfer Protocol)

SMTP is the main protocol for sending emails. Here’s what you need to know:

• Uses TCP: It’s reliable (no lost emails) and connects to port 25 on the receiving server.
• How it works:
o The sending server (acting like a client) connects to the receiving server.
o It’s a push protocol: The sender pushes the email to the receiver, not the other way around.
o It goes through a three-phase process:
▪ Handshaking (greeting): The servers say “hello” to establish a connection (e.g., using
“250 Hello” commands).
▪ Transfer of messages: The email is sent.
▪ Closure: The connection ends.
• Format: SMTP uses ASCII text (human-readable commands and responses, similar to HTTP) with
command/response pairs (e.g., commands like “MAIL FROM” and status codes like “250 OK”).
• RFC 5321: This document defines how SMTP works, ensuring everyone follows the same rules.

Think of it like: You’re calling a friend’s voicemail (SMTP server) to leave a message, using a specific script
(ASCII commands) to ensure it’s delivered properly.

SMTP: Scenario (Alice Sends E-mail to Bob)

Steps:

1. Alice uses her user agent (e.g., Outlook) to compose an email to “bob@[Link].”
2. Alice’s mail server uses SMTP to send the message to Bob’s mail server.
3. Alice’s server opens a TCP connection with Bob’s server.
4. Bob’s mail server receives the email and places it in Bob’s mailbox.
5. Bob uses his user agent to read the message.

Think of it like: Alice writes a letter, her post office (SMTP) sends it to Bob’s post office, and Bob picks it up
from his mailbox.

Sample SMTP Interaction

Example: Alice’s server ([Link]) connects to Bob’s server ([Link]). The interaction starts
with “220 [Link]” (server greeting), and they exchange commands like “MAIL FROM” and “RCPT
TO” to send the email, ending with “250 OK” (success).

Think of it like: A polite conversation between post offices to ensure the letter gets delivered.
SMTP: Observations (Compared with HTTP)

• Similarities with HTTP:

o Both use ASCII command/response interactions and status codes (e.g., 200 OK in HTTP, 250
OK in SMTP).
o Both use TCP for reliability.
• Differences:
o HTTP: Client pulls data (browser requests a webpage).
o SMTP: Server pushes data (sending server pushes email to receiving server).
o HTTP encapsulates objects in its responses; SMTP sends multiple email objects (messages) as a
single transfer.
o SMTP uses persistent connections (keeps the connection open for multiple messages), while
HTTP can be non-persistent or persistent.
o SMTP requires the message header and body to be in 7-bit ASCII; CRLF (carriage return, line
feed) marks the end of a message.

Think of it like: HTTP is like you asking for a menu (pulling data), while SMTP is like the chef sending you
food (pushing data).

4. Mail Message Format

Defined in RFC 5322: This outlines how email messages are structured, similar to how HTML defines web
pages.

Structure:

• Header: Lines at the top, like “To,” “From,” “Subject,” etc., that describe the email (e.g., who it’s from,
who it’s to).
• Body: The main content of the email (the message you write).
• Syntax: Uses ASCII characters, with special commands (e.g., “MAIL FROM,” “RCPT TO”) from
SMTP.

Think of it like: An envelope with your address and the recipient’s address (header) and the letter inside
(body).

5. Retrieving E-mail: Mail Access Protocols

After an email is sent via SMTP, you need to retrieve it. This is done with mail access protocols:

• SMTP: Only delivers emails to the server, not to your device.

• Mail access protocols retrieve emails from the server to your device. Common ones include:
o POP (Post Office Protocol, RFC 1939): Downloads emails from the server to your device,
often deleting them from the server afterward. Simple but doesn’t keep emails online.
o IMAP (Internet Message Access Protocol): Lets you access, delete, or organize emails on the
server without downloading them. Keeps emails online for access from multiple devices.
 o HTTP: Some services (e.g., Gmail, Hotmail, Yahoo Mail) use a web interface on top of SMTP
(to send) and IMAP/POP (to retrieve).

Think of it like: SMTP is the delivery truck dropping off mail at the post office, and POP/IMAP are you
picking up or managing your mail from the post office, either taking it home (POP) or leaving it there (IMAP)
for access anywhere.

6. DNS (Domain Name System)

DNS is like the internet’s phonebook—it translates human-friendly names (e.g., [Link]) into
machine-friendly IP addresses (e.g., [Link]) so computers can find each other.

DNS: Basics

• People use names: You type “[Link],” not “[Link].”

• Computers use IP addresses: Routers and devices need numbers to locate each other.
• DNS’s job: Map names to IP addresses (and vice versa) using a distributed system.

Think of it like: You ask for “Joe’s Pizza” (domain name), and DNS gives you the street address (IP address)
to find it.

Domain Name System (DNS): Structure

Distributed, hierarchical database: Not one big central list, but many servers organized in levels.

• Root servers: At the top, manage the highest-level domains (e.g., .com, .edu, .org).
• Top-Level Domain (TLD) servers: Handle domains like .com, .edu (e.g., com DNS servers for
[Link]).
• Authoritative DNS servers: Belong to organizations or providers, holding the official IP mappings for
their domains (e.g., [Link]’s DNS server knows [Link]’s IP).
• Local DNS servers: Closest to you (e.g., your internet provider’s server), cache translations for speed.

Why not centralize DNS?

• A single point of failure: If it crashes, the internet breaks.

• Too much traffic: Billions of queries daily (e.g., 600 billion DNS queries/day for .com, 2.1 trillion for all
TLDs).
• Hard to maintain a centralized database.

Solution: Distributed and hierarchical—reliable, scalable, and secure.

Think of it like: Instead of one giant phonebook, there are local libraries (local DNS), regional directories
(TLD servers), and company-specific lists (authoritative servers), all working together.

DNS: Services and Structure

 • Services:
o Hostname-to-IP address translation: Turns “[Link]” into [Link].
o Host aliasing: Gives nicknames (e.g., “[Link]” points to the same IP as
“[Link]”).
o Mail server aliasing: Finds mail servers for email (e.g., SMTP uses DNS to locate Bob’s mail
server).
o Load distribution: Spreads traffic across multiple servers for big sites (e.g., Amazon uses
multiple IPs for [Link]).
• Structure:
o Root name servers: 13 logical “servers” worldwide (actually ~200 in the U.S., replicated for
reliability), managed by ICANN (Internet Corporation for Assigned Names and Numbers).
o TLD servers: For .com, .edu, etc., handle queries for their domains.
o Authoritative servers: Owned by organizations, provide the final IP for their domain.
o Local servers: Your internet provider’s server, caches common translations for speed.

Think of it like: Root servers are like global directory assistance, TLD servers are regional guides, authoritative
servers are company directories, and local servers are your personal quick-reference notebook.

DNS Name Resolution: How It Works

When you type a domain name, DNS figures out the IP address through queries. Two main types:

• Iterated Query:
o Your device asks its local DNS server for “[Link].”
o The local server doesn’t know, so it contacts a root server.
o The root server says, “Ask the .edu TLD server.”
o The .edu server says, “Ask the [Link] authoritative server.”
o The [Link] server gives the IP for [Link].
o Each server replies with the next step, and your local server caches the answer.
• Recursive Query:
o Your device asks its local DNS server for “[Link].”
o The local server does all the work, contacting root, TLD, and authoritative servers until it gets
the IP, then returns it to you.
o Puts more burden on the local server but simplifies the process for your device.

Think of it like:

• Iterated: You ask a friend, who asks another friend, who asks someone else, and each tells you where to
go next.
• Recursive: You ask a friend, and they handle the whole search for you, then tell you the answer.

Caching DNS Information

How caching works:

• Once any DNS server learns a mapping (e.g., [Link] → [Link]), it caches it and uses
it for future queries.
• Cached mappings are returned quickly, speeding things up.
 • Cache entries expire after a time (TTL, Time to Live), so old mappings don’t stay forever.
• TLD entries are often cached in local name servers for efficiency.

Challenges:

• If a host’s IP changes, cached data might be out-of-date until TTL expires.

• DNS is “best effort”—it tries to give accurate translations, but updates can take time.

Think of it like: You write down a phone number in your phonebook (cache), but it might need updating if the
number changes, and you check periodically to ensure it’s current.

Summary for Exam Prep (Simple Version)

• E-mail and SMTP:

o Know the components (user agents, mail servers, SMTP) and how emails are sent (push
protocol, ASCII commands, persistent connections).
o Understand mail access protocols (POP for downloading, IMAP for managing online, HTTP for
webmail).
o Recognize the email format (header + body) and SMTP’s role compared to HTTP.
• DNS:
o Understand it translates names to IPs, using a distributed, hierarchical system (root, TLD,
authoritative, local servers).
o Know why it’s not centralized (scalability, reliability) and how it resolves names (iterated vs.
recursive queries, caching for speed).