Network Transports layers and Transport Networks

Qun Wang (qunwang@sfsu.edu)
CSC 645
Computer Networks
01-Introduction

Loading…
Who am I
Xi’an
1990-2016
Logan
2016-2022
SFSU
2022-Now

Who am I
Xi’an
2013-2016
Logan
2016-2022
SFSU
2022-Now

Loading…
CIDER Lab
• AI in IoT Network
• Federated Learning with Multi-Party Computation
• Vision Camera-Based Hand Tracking and Gesture Recognition
• Phishing URL and Phishing UI Detection
• On devices LLM application and implements
• Generative AI-Based IoT Attack Detection
• On-Device LLM-Based Recycle Bin Design
• LLM-Based 3D Layout Design
• AI in wireless networks
• Module-Based CNN for IRS-Assisted Spectrum Sensing
• GNN-Based Physical Layer Security with Power Allocation
https://sites.google.com/view/qun-wang/sfsu-cider-lab

Course Overview
• This course introduces the fundamental principles and methods on
design and implementation of computer networks and network
protocols.
• Topics will include TCP/IP Protocol Stack, Packet Switching,
Reliable Data Transfer, Routing, Multiple Access Control, Internet
Protocols (HTTP, TCP, UDP, IP, RIP, OSPF), Socket Programming,
and other emerging topics (as time permits).

Question time
• What is Internet and why it is important?

Network Transports layers and Transport Networks

Internet
• The Internet started in the 1960s as a way for
government researchers to share information.
• ARPANET (Advanced Research Projects Agency
Network), the network that ultimately evolved into
what we now know as the Internet.
• Transfer Control Protocol/Internetwork Protocol
(TCP/IP) allowed different kinds of computers on
different networks to "talk" to each other.
ARPANET and the Defense Data Network officially
changed to the TCP/IP standard, hence the birth of
the Internet.
Introduction: 1-9

Internet
https://www.oberlo.com/blog/internet-statistics

Loading…
Future Network
Introduction: 1-11

Why Computer Network is important?
1. Digital Foundation:
• Networks are the backbone of digital communication and information sharing.
• Understanding networks is fundamental in the modern digital age.
2. Career Opportunities:
• Many IT, cybersecurity, and tech-related careers require network knowledge.
• Networking skills open doors to diverse job opportunities.
3. Effective Communication:
• Networks enable seamless remote communication and collaboration.
• Learn how data is transmitted across devices and platforms.
4. Cybersecurity Awareness:
• Networks are crucial in understanding and preventing cyber threats.
• Enhance your ability to protect sensitive data and online activities.
5. Problem-Solving Skills:
• Equip yourself to troubleshoot network connectivity issues.

Syllabus
• Instructor : Qun Wang (Claude)
• Office Hours : Zoom （with appointment）
• Email : qunwang@sfsu.edu
Introduction: 1-13

Learning Outcome
Gain knowledge on how
to design and implement
computer networks.
Gain hands-on
experience in network
programming and
troubleshooting
Build a collaborative
and supportive
classroom.
Have fun!
Introduction: 1-14

Prerequisite
• Grade of C or better in CSC415
• Please contact the instructor if you have questions
regarding the material or concerns about whether
your background is suitable for the course.
Introduction: 1-15
I will send students that doesn’t meet the prerequisite an email for
explanations. If you didn’t response me by the end of this week, I
will drop you.

Course Materials
Textbook Canvas
https://github.com/TimorYang/Computer-Networking-Keith-Ross/blob/main/book/Computer%20Networking_%20A%20Top-
Down%20Approach%2C%20Global%20Edition%2C%208th%20Edition.pdf

Late Submission
• Late submission within 48 hours of the deadline is
allowed, for 75% of the credits
• Students with legitimate reasons should contact the
instructor before the deadline to ask for an extension
• ALWAYS start the assignments as early as possible
Introduction: 1-18

Academic Integrity
• As scientists and engineers, we must trust each other to
make progress
• Academic dishonesty, whether from cheating, copying,
fabricating results or through any other dishonest practice
will not be tolerated
• Refer to the link http://cs.sfsu.edu/plagarism.html for the
department policy on plagiarism/cheating
• I take this very seriously – you should too.
Introduction: 1-19

ChatGPT
• Encouragement for students to use advanced AI tools such
as ChatGPT to:
• Enhance their learning experience.
• Grasp new concepts.
• Articulate project code explanations effectively.
• Important guidelines:
• Direct use of ChatGPT for solving homework and exam problems
will be graded as 0 points.
• Cautionary advice:
• Using ChatGPT to generate answers may lead to:
• The use of terminology that differs from the course.
• Identical responses for the same questions.
• Such patterns are easily detectable and may lead to severe
consequences if discovered.

General Information
● If you skip or miss classes, you are responsible to know all information
covering in classes, i.e. information such as updated & additional class
notes/project statements.
● If you skip/miss classes because of emergency events, you should communicate
with me as soon as possible to make proper arrangement.
● You are always welcome to ask me any course-related questions.
● It is never too late to catch up and solve questions.
● I will always provide all the support you need and help you succeed throughout
the semester.

Introduce Yourself
• Please tell us
• Name
• Hometown/Country
• Junior/Senior
• One thing you have
done that related to
computer network
Introduction: 1-22

What’s next
• Read textbook chapter 1.1 to 1.4
Introduction: 1-23

CSC 645
Computer Networks
02 Intro to Internet

Chapter 1: introduction
▪ Get “feel,” “big picture,” introduction to terminology
▪ more depth, detail later in course
Chapter goal:

Loading…
Chapter 1: introduction
Overview/roadmap:
▪ What is the Internet? What is a protocol?
▪ Network edge: hosts, access network, physical media
▪ Network core: packet/circuit switching, internet structure
▪ Performance: loss, delay, throughput
▪ Protocol layers, service models
▪ Security
▪ History

Interne
t
The Internet
Billions of connected
computing devices:
▪ hosts = end systems
▪ running network apps at
Internet’s “edge”
Introduction: 1-7

Web-enabled toaster +
weather forecaster
Internet
phones
Slingbox: remote
control cable TV
Security
Camera
IP picture
frame
Internet
refrigerator
Tweet-a-watt:
monitor energy
use
sensorized,
bed
mattress
Amazon
Echo
Others
?
Pacemaker &
Monitor
AR
devices
Fitbit
Gaming
devices
cars
scooters
bike
s
Introduction: 1-8

Interne
t
The Internet:
mobile network
home network
enterprise
network
national or global
ISP
local or
regional
ISP
datacenter
network
content
provider
network
Packet switches: forward
packets (chunks of data)
▪ routers, switches
Communication links
▪ fiber, copper, radio, satellite
▪ transmission rate: bandwidth
Billions of connected
computing devices:
▪ hosts = end systems
▪ running network apps at
Internet’s “edge”
Networks
▪ collection of devices, routers,
links: managed by an
organization
Introduction: 1-9

Build a network
What you need to make
sure this network works?

Loading…
▪ Internet: “network of networks”
• Interconnected ISPs
The Internet
mobile network
home network
enterprise
network
national or global
ISP
local or
regional
ISP
datacenter
network
content
provider
network
▪ protocols are everywhere
• control sending, receiving of
messages
• e.g., HTTP (Web), streaming
video, Skype, TCP, IP, WiFi, 4G,
Ethernet
Ethernet
HTTP
Skype
IP
WiFi
4G
TCP
Streaming
video
▪ Internet standards
• RFC: Request for Comments
• IETF: Internet Engineering Task
Force
Introduction: 1-11

▪ Infrastructure that provides services to
applications:
• Web, streaming video, multimedia
teleconferencing, email, games, e-
commerce, social media, inter-
connected appliances, …
The Internet: a “services” view
mobile network
home network
enterprise
network
national or global
ISP
local or
regional
ISP
datacenter
network
content
provider
network
HTTP
Skype
Streaming
video
▪ provides programming interface
to distributed applications:
• “hooks” allowing sending/receiving
apps to “connect” to, use Internet
transport service
• provides service options, analogous
to postal service
Introduction: 1-12

What’s a protocol?
Human protocols:
▪ “what’s the time?”
▪ “I have a question”
▪ introductions
Network protocols:
▪ computers (devices) rather than
humans
▪ all communication activity in Internet
governed by protocols
Rules for:
… specific messages
sent
… specific actions taken
when message
received, or other
events
Introduction: 1-13

A human protocol and a computer network
protocol:
Hi
Hi
Got the
time?
2:00
time
TCP
connection
response
<file>
TCP
connection
request
GET
http://gaia.cs.umass.edu/kurose_ross
Introduction: 1-14

Human protocols:
▪ “what’s the time?”
▪ “I have a question”
▪ introductions
Network protocols:
▪ computers (devices) rather than
humans
▪ all communication activity in Internet
governed by protocols
Protocols define the format, order
of messages sent and received
among network entities, and
actions taken on message
transmission, receipt
Rules for:
… specific messages
sent
… specific actions taken
when message
received, or other
events
Introduction: 1-15

Interne
t
The Internet:
mobile network
home network
enterprise
network
national or global
ISP
local or
regional
ISP
datacenter
network
content
provider
network
Introduction: 1-16

A closer look at Internet structure
mobile network
home network
enterprise
network
national or global
ISP
local or
regional
ISP
datacenter
network
content
provider
network
Network edge:
▪ hosts: clients and servers
▪ servers often in data centers
Introduction: 1-17

mobile network
home network
enterprise
network
national or global
ISP
local or
regional
ISP
datacenter
network
content
provider
network
Network edge:
Access networks, physical
media:
▪ wired, wireless communication links
Introduction: 1-18

Network edge:
Access networks, physical
media:
▪ wired, wireless communication links
Network core:
▪ interconnected routers
mobile network
home network
enterprise
network
national or global
ISP
local or
regional
ISP
datacenter
network
content
provider
network
Introduction: 1-19

Week 1-1 Quiz (10 Minutes)
Please complete the quiz on Canvas.
• Multiple choice question.
• Only 1 correct answer for each question.
• Maximum 2 attempts and highest result will be choose.
• Work independently
• Only available during class.

Network edge: hosts, access network, physical media

Access networks and physical media
mobile network
home network
enterprise
network
national or global
ISP
local or
regional
ISP
datacenter
network
content
provider
network
Q: How to connect end
systems to edge router?
▪ residential access nets
▪ institutional access networks (school,
company)
▪ mobile access networks (WiFi, 4G/5G)
Introduction: 1-22
What to look for:
Transmission rate (bits per second, bps) of access
network?
Shared or dedicated access among users?

Access networks: cable-based access
cable
modem
splitter
…
cable headend
Channels
V
I
D
E
O
V
I
D
E
O
V
I
D
E
O
V
I
D
E
O
V
I
D
E
O
V
I
D
E
O
D
A
T
A
D
A
T
A
C
O
N
T
R
O
L
1 2 3 4 5 6 7 8 9
frequency division multiplexing (FDM): different channels transmitted in
different frequency bands
Introduction: 1-23

Access networks: cable-based access
cable
modem
splitter
…
cable headend
data, TV transmitted at different
frequencies over shared cable
distribution network
▪ HFC: hybrid fiber coax
• asymmetric: up to 40 Mbps – 1.2 Gbps downstream transmission rate, 30-100
Mbps upstream transmission rate
▪ network of cable, fiber attaches homes to ISP router
• homes share access network to cable headend
cable modem
termination system
CMTS
ISP
Introduction: 1-24

ISP
Access networks: digital subscriber line
(DSL)
central office telephone
network
DSLAM
voice, data transmitted
at different frequencies over
dedicated line to central office
▪ use existing telephone line to central office DSLAM
• data over DSL phone line goes to Internet
• voice over DSL phone line goes to telephone net
▪ 24-52 Mbps dedicated downstream transmission rate
▪ 3.5-16 Mbps dedicated upstream transmission rate
DSL
modem
splitter
DSL access
multiplexer
Introduction: 1-25

Discussion
▪ Why downlink is faster than uplink?
▪ What applications/services you are using via Internet (today vs 10 years
ago)?
▪ What are the common features
▪ Do we need to increase the uplink rate for today’s applications?

Access networks: home networks
to/from headend or
central office
cable or DSL
modem
router, firewall, NAT
wired Ethernet (1 Gbps)
WiFi wireless
access
point (54, 450
Mbps)
Wireless and wired
devices
often combined
in single box
Introduction: 1-27

Wireless access networks
Shared wireless access network connects end system to
router
▪ via base station aka “access point”
Wireless local area networks
(WLANs)
▪ typically within or around
building (~100 ft)
▪ 802.11b/g/n (WiFi): 11, 54, 450
Mbps transmission rate
to Internet
to Internet
Wide-area cellular access
networks
▪ provided by mobile, cellular network
operator (10’s km)
▪ 10’s Mbps
▪ 4G cellular networks (5G coming)
Introduction: 1-28

Loading…
Speed of Wi-Fi 6 and 5G

Host: sends packets of data
host sending function:
▪ takes application message
▪ breaks into smaller chunks,
known as packets, of length L
bits
R: link transmission
rate
host
1
2
two
packets,
L bits each
Introduction: 1-30

Host: sends packets of data
host sending function:
▪ takes application message
▪ breaks into smaller chunks, known
as packets, of length L bits
▪ transmits packet into access
network at transmission rate R
• link transmission rate, aka link
capacity, aka link bandwidth
R: link transmission
rate
host
1
2
two
packets,
L bits each
packet
transmission
delay
time needed to
transmit L-bit
packet into link
L (bits)
R (bits/sec)
= =
Introduction: 1-31

Questions
▪ Wifi 4: R = 600 Mbps, what is delay
▪ LTE: R =100 Mbps
packet
transmission
delay
time needed to
transmit L-bit
packet into link
L (bits)
R (bits/sec)
= =
L=150 MBytes = ? Mbits
What is packet transmission delay?

Links: physical media
▪ bit: propagates between
transmitter/receiver pairs
▪ physical link: what lies
between transmitter &
receiver
▪ guided media:
• signals propagate in
solid media: copper,
fiber, coax
▪ unguided media:
Twisted pair (TP)
▪ two insulated copper wires
• Category 5: 100 Mbps, 1 Gbps
Ethernet
• Category 6: 10Gbps Ethernet
Introduction: 1-33

• signals propagate
Coaxial cable:
▪ two concentric copper
conductors
▪ bidirectional
▪ broadband:
• multiple frequency channels on
cable
• 100’s Mbps per channel
Fiber optic cable:
▪ glass fiber carrying light pulses, each
pulse a bit
▪ high-speed operation:
• high-speed point-to-point
transmission (10’s-100’s Gbps)
▪ low error rate:
• repeaters spaced far apart
• immune to electromagnetic noise
Introduction: 1-34

Wireless radio
▪ signal carried in various
“bands” in electromagnetic
spectrum
▪ no physical “wire”
▪ broadcast, “half-duplex”
(sender to receiver)
▪ propagation environment
effects:
• reflection
• obstruction by objects Introduction: 1-35

Radio link types:
▪ Wireless LAN (WiFi)
• 10-100’s Mbps; 10’s of meters
▪ wide-area (e.g., 4G cellular)
• 10’s Mbps over ~10 Km
▪ Bluetooth: cable replacement
• short distances, limited rates
▪ terrestrial microwave
• point-to-point; 45 Mbps channels
▪ satellite
• up to 45 Mbps per channel
Introduction: 1-36

Network core: packet/circuit switching, internet structure
Introduction: 1-39
▪ Packet switching
▪ Circuit switching
▪ Structure of today’s internet

The network core
▪ mesh of interconnected routers
▪ packet-switching: hosts break
application-layer messages into
packets
• network forwards packets from
one router to the next, across
links on path from source to
destination
mobile network
home network
enterprise
network
national or global
ISP
local or
regional
ISP
datacenter
network
content
provider
network
Introduction: 1-40

Moving from Utah to SF with a truck
▪ What do you need?

Network Core
Packet Router/Switch

Two key network-core functions
1
2
3
0111
destination address in arriving
packet’s header
routing algorithm
header value output link
0100
0101
0111
1001
3
2
2
1
local forwarding table
Forwarding:
▪ aka “switching”
▪ local action: move
arriving packets
from router’s
input link to
appropriate
router output link
local forwarding table
Routing:
▪ global action:
determine source-
destination paths
taken by packets
▪ routing algorithms
routing algorithm
Introduction: 1-43

Circuit Switching vs Packet Switching

Alternative to packet switching: circuit switching
end-end resources allocated to,
reserved for “call” between source and
destination
▪ in diagram, each link has four circuits.
• call gets 2nd circuit in top link and
1st circuit in right link.
▪ dedicated resources: no sharing
• circuit-like (guaranteed)
performance
▪ circuit segment idle if not used by call
(no sharing)
▪ commonly used in traditional telephone
networks
Introduction: 1-48

Circuit switching: FDM and TDM
freq
uen
cy
time
freq
uen
cy
time
4 users
Frequency Division Multiplexing
(FDM)
▪ optical, electromagnetic frequencies
divided into (narrow) frequency
bands
Time Division Multiplexing (TDM)
▪ time divided into slots
▪ each call allocated its own band,
can transmit at max rate of that
narrow band
▪ each call allocated periodic slot(s),
can transmit at maximum rate of
(wider) frequency band (only)
during its time slot(s) Introduction: 1-49

Read:
▪ https://www.communicationsmuseum.org.uk/emuseum/packetswitching/
History of Packet Switching (how the Internet works)
Read and Answer following questions:
• Q1: What is change of number of bits used for the
address from IPV4 to IPV6?
• Q2: Which company and lab developed Unix operating
system?

Packet-switching: store-and-forward
▪ packet transmission delay: takes L/R seconds
to transmit (push out) L-bit packet into link at
R bps
▪ store and forward: entire packet must arrive at
router before it can be transmitted on next link
source
R
bps
destination
1
2
3
L bits
per
packet
R
bps
One-hop numerical
example:
▪ L = 10 Kbits
▪ R = 100 Mbps
Introduction: 1-51
one-hop transmission delay
= 0.1 msec

Packet-switching: queueing
A
B
C
R = 100 Mb/s
R = 1.5 Mb/s
D
E
queue of packets
waiting for transmission
over output link
Queueing occurs when work arrives faster than it can be serviced:
Introduction: 1-52

Packet-switching: queueing
A
B
C
R = 100 Mb/s
R = 1.5
Mb/s
D
E
queue of packets
waiting for transmission
over output link
Packet queuing and loss: if arrival rate (in bps) to link exceeds
transmission rate (bps) of link for some period of time:
▪ packets will queue, waiting to be transmitted on output link
▪ packets can be dropped (lost) if memory (buffer) in router fills up
Introduction: 1-53

Packet switching versus circuit switching
example:
▪ 1 Gb/s link
▪ each user:
• 100 Mb/s when “active”
• active 10% of time
Q: how many users can use this network under circuit-switching and packet
switching?
N
user
s
1 Gbps
link
…..
▪ circuit-switching: 10 users
▪ packet switching: with 35 users, probability > 10 active at same time is
less than 0.0004 *
Introduction: 1-54

Packet switching versus circuit switching
▪ great for “burst” data – sometimes has data to send, but at other times not
• resource sharing
• simpler, no call setup
▪ excessive congestion possible: packet delay and loss due to buffer overflow
• protocols needed for reliable data transfer, congestion control
▪ Q: How to provide circuit-like behavior with packet-switching?
• “It’s complicated.” We’ll study various techniques that try to make packet
switching as “circuit-like” as possible.
Is packet switching a “winner”?
Introduction: 1-55

Internet structure: a “network of networks

Internet structure: a “network of networks”
▪ hosts connect to Internet via
access Internet Service Providers
(ISPs)
▪ access ISPs in turn must be
interconnected
• so that any two hosts
(anywhere!) can send packets to
each other
▪ resulting network of networks is
very complex
• evolution driven by economics,
Let’s take a stepwise approach to describe current Internet structure
mobile network
home network
enterprise
network
national or global
ISP
local or
regional
ISP
datacenter
network
content
provider
network

Question: given millions of access ISPs, how to connect them
together?
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
…
…
…
…
…
…
Introduction: 1-58

…
…
…
…
…
Question: given millions of access ISPs, how to connect them
together?
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
…
…
…
…
…
…
connecting each access ISP
to each other directly doesn’t
scale: O(N2) connections.
Introduction: 1-59

Option: connect each access ISP to one global transit ISP?
Customer and provider ISPs have economic agreement.
global
ISP
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
…
…
…
…
…
…
Introduction: 1-60

ISP
A
ISP C
ISP
B
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
…
…
…
…
…
…
But if one global ISP is viable business, there will be competitors ….
Introduction: 1-61

ISP
A
ISP
C
ISP
B
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
…
…
…
…
…
…
But if one global ISP is viable business, there will be competitors ….
who will want to be connected
IXP
peering link
Internet exchange point
IX
P
Introduction: 1-62

ISP
A
ISP
C
ISP
B
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
…
…
…
…
…
…
… and regional networks may arise to connect access nets
to ISPs
IXP
IX
P
access
net
access
net
regional ISP
access
net access
net
access
net
Introduction: 1-63

ISP
A
ISP
C
ISP
B
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
access
net
…
…
…
…
…
…
… and content provider networks (e.g., Google, Microsoft,
Akamai) may run their own network, to bring services, content
close to end users
IXP
IX
P
access
net
access
net
access
net access
net
access
net
Content provider network
regional ISP
Introduction: 1-64

access
ISP
access
ISP
access
ISP
access
ISP
access
ISP
access
ISP
access
ISP
access
ISP
At “center”: small number of well-connected large networks
▪ “tier-1” commercial ISPs (e.g., Level 3, Sprint, AT&T, NTT), national & international
coverage
▪ content provider networks (e.g., Google, Facebook): private network that connects its
data centers to Internet, often bypassing tier-1, regional ISPs
Regional
ISP
Regional
ISP
Tier 1 ISP Tier 1 ISP
IX
P
Google
IX
P
IX
P
Introduction: 1-65

CSC 645
Computer Networks
03
Internet core &
network performance

Network Performance
Introduction: 1-2
• Components of network delay
• packet loss,
• throughput

Loading…
“Real” Internet delays and routes
▪ what do “real” Internet delay & loss look like?
▪ traceroute program: provides delay measurement from
source to router along end-end Internet path towards
destination. For all i:
3 probes
3 probes
3 probes
• sends three packets that will reach router i on path towards
destination (with time-to-live field value of i)
• router i will return packets to sender
• sender measures time interval between transmission and
reply
Introduction: 1-3
RFC 1393 describes Traceroute in detail.

“Real” Internet delays and routes

Loading…
Real Internet delays and routes
1 cs-gw (128.119.240.254) 1 ms 1 ms 2 ms
2 border1-rt-fa5-1-0.gw.umass.edu (128.119.3.145) 1 ms 1 ms 2 ms
3 cht-vbns.gw.umass.edu (128.119.3.130) 6 ms 5 ms 5 ms
4 jn1-at1-0-0-19.wor.vbns.net (204.147.132.129) 16 ms 11 ms 13 ms
5 jn1-so7-0-0-0.wae.vbns.net (204.147.136.136) 21 ms 18 ms 18 ms
6 abilene-vbns.abilene.ucaid.edu (198.32.11.9) 22 ms 18 ms 22 ms
7 nycm-wash.abilene.ucaid.edu (198.32.8.46) 22 ms 22 ms 22 ms
8 62.40.103.253 (62.40.103.253) 104 ms 109 ms 106 ms
9 de2-1.de1.de.geant.net (62.40.96.129) 109 ms 102 ms 104 ms
10 de.fr1.fr.geant.net (62.40.96.50) 113 ms 121 ms 114 ms
11 renater-gw.fr1.fr.geant.net (62.40.103.54) 112 ms 114 ms 112 ms
12 nio-n2.cssi.renater.fr (193.51.206.13) 111 ms 114 ms 116 ms
13 nice.cssi.renater.fr (195.220.98.102) 123 ms 125 ms 124 ms
14 r3t2-nice.cssi.renater.fr (195.220.98.110) 126 ms 126 ms 124 ms
15 eurecom-valbonne.r3t2.ft.net (193.48.50.54) 135 ms 128 ms 133 ms
16 194.214.211.25 (194.214.211.25) 126 ms 128 ms 126 ms
17 * * *
18 * * *
19 fantasia.eurecom.fr (193.55.113.142) 132 ms 128 ms 136 ms
traceroute: gaia.cs.umass.edu to www.eurecom.fr
* Do some traceroutes from exotic countries at
www.traceroute.org
* means no response (probe lost, router not replying)
3 delay measurements from
gaia.cs.umass.edu to cs-gw.cs.umass.edu
3 delay measurements
to border1-rt-fa5-1-0.gw.umass.edu
trans-oceanic link
Introduction: 1-5

How do packet delay and loss occur?
▪ packets queue in router buffers, waiting for turn for transmission
▪ queue length grows when arrival rate to link (temporarily) exceeds output
link capacity
▪ packet loss occurs when memory to hold queued packets fills up
A
B
packet being transmitted (transmission delay)
packets in buffers (queueing delay)
free (available) buffers: arriving packets
dropped (loss) if no free buffers
Introduction: 1-6

Packet delay: four sources
dproc: nodal
processing
▪ check bit errors
▪ determine output link
▪ typically < microsecs
dqueue: queueing delay
▪ time waiting at output link for
transmission
▪ depends on congestion level of
router
propagation
nodal
processing queueing
dnodal = dproc + dqueue + dtrans
+ dprop
A
B
transmission
Introduction: 1-7

Packet delay: four sources
propagation
nodal
processing queueing
dnodal = dproc + dqueue + dtrans +
dprop
A
B
transmission
dtrans: transmission delay:
▪ L: packet length (bits)
▪ R: link transmission rate (bps)
▪ dtrans = L/R
dprop: propagation delay:
▪ d: length of physical link
▪ s: propagation speed (~2x108 m/sec)
▪ dprop = d/s
dtrans and
dprop
very different
Introduction: 1-8

Transmission delay vs propagation delay
▪ Q1: What is the difference between
transmission delay and propagation
delay?
▪ Transmission delay is the time needed to
put the entire packet on the link and is
dependent on the length of the packet,
while the propagation delay is needed
time for one bit to reach to the other end
of the link.
▪ Q2: How is propagation delay affected if
the length of the packet is increased?
▪ This delay is just a function of link length
and its physical characteristics, so it is
NOT affected
https://computerscience.unicam.it/marcantoni/reti/applet/TransmissionVsPropagationDelay/traProp.html

Packet queueing delay (revisited)
▪ a: average packet arrival rate
▪ L: packet length (bits)
▪ R: link bandwidth (bit transmission
rate)
▪ La/R ~ 0: avg. queueing delay small
▪ La/R -> 1: avg. queueing delay large
▪ La/R > 1: more “work” arriving is more than
can be serviced - average delay infinite!
La/R ~ 0
La/R -> 1
traffic intensity = La/R
ave
r
a
g
e
q
u
e
u
e
i
n
g
d
e
l
a
y
1
service rate of bits
R
arrival rate of bits
L a
.
: “traffic intensity”

Loading…
Packet loss
▪ queue (aka buffer) preceding link in buffer has finite capacity
A
B
packet being
transmitted
buffer
(waiting area)
packet arriving to
full buffer is lost
▪ packet arriving to full queue dropped (aka lost)
▪ lost packet may be retransmitted by previous node, by source
end system, or not at all
Introduction: 1-11

Question
▪ How long does it take a packet of length 1,000 bytes to propagate over a link
of distance 5,000 km, propagation speed 2.5×10^8 m/s, and transmission rate
2 Mbps?
▪ Suppose the packet is 1,000 Bytes, the propagation speed on link is 2.5×10^8
m/s, the transmission rate is 2 Mbps, the packet switch processing delay is 3
msec, the length of the link is 5,000 km, what is the end-to-end delay? (No
queue delay)

Throughput
▪ throughput: rate (bits/time unit) at which bits are being sent from
sender to receiver
• instantaneous: rate at given point in time
• average: rate over longer period of time
server, with
file of F bits
to send to client
link
capacity
Rs
bits/sec
link
capacity
Rc
bits/sec
server sends bits
(fluid) into pipe
pipe that can carry
fluid at rate
(Rs bits/sec)
pipe that can carry
fluid at rate
(Rc bits/sec)
Introduction: 1-13

Throughput
Rs < Rc What is average end-end throughput?
Rs bits/sec Rc bits/sec
Rs > Rc What is average end-end throughput?
link on end-end path that constrains end-end throughput
bottleneck link
Rs bits/sec Rc bits/sec
Introduction: 1-14

Throughput: network scenario
10 connections (fairly) share
backbone bottleneck link R
bits/sec
Rs
Rs
Rs
Rc
Rc
Rc
R
▪ per-connection end-
end throughput:
min(Rc,Rs,R/10)
▪ in practice: Rc or Rs is
often bottleneck
Introduction: 1-15

Chapter 1: roadmap
Introduction: 1-16
Architectural layering
Internet layers
Encapsulation
Protocol layers, service models

Protocol “layers” and reference models
Networks are complex,
with many “pieces”:
▪ hosts
▪ routers
▪ links of various media
▪ applications
▪ protocols
▪ hardware, software
Question: is there any hope of
organizing structure of network?
Introduction: 1-17

Example: organization of air travel
▪ a series of steps, involving many services
ticket (purchase)
baggage (check)
gates (load)
runway takeoff
airplane routing
ticket (complain)
baggage (claim)
gates (unload)
runway landing
airplane routing
airplane routing
How would you define/discuss the system of airline
travel?
end-to-end transfer of person plus baggage
Introduction: 1-18

Example: organization of air travel
ticket (purchase)
baggage (check)
gates (load)
runway takeoff
airplane routing
ticket (complain)
baggage (claim)
gates (unload)
runway landing
airplane routing
airplane
routing
ticketing service
baggage service
gate service
runway service
routing service
layers: each layer implements a service
▪ via its own internal-layer actions
▪ relying on services provided by layer below Introduction: 1-19

Communication model
Example information flow supporting virtual communication in layer 5.

Q&A
Discuss the Layered System Design in Real life
▪ How Many Layers?
▪ What is the function within each Layer
▪ What they need from lower layer
▪ What they need to provide to upper Layer

Why layering
Approach to designing/discussing complex systems:
• explicit structure allows identification, relationship of system's
pieces
• layered reference model for discussion
• modularization eases maintenance, updating of system
• change in layer's service implementation: transparent to rest of system
• e.g., change in gate procedure doesn’t affect rest of system

The OSI Reference Model
Open System Interconnection（OSI）
Principles for the seven layers
• Layers created for different abstractions
• Each layer performs well-defined function
• Function of layer chosen with definition of international standard
protocols in mind
• Minimize information flow across interfaces between
boundaries
• Number of layers optimum

OSI Layer Model
https://community.fs.com/blog/tcpip-vs-osi-whats-the-difference-between-the-two-models.html

Physical Layer
● Concerned with
transmitting raw bit over
a communications
channel
● Deals with voltages,
frequencies, signal
durations, simplex or
duplex, etc

Datalink Layer
● Transforms a raw
transmission facility into a
line that appears free of
undetected transmission
errors.
● Handles Framing, Flow
control, Medium Access
control, Logical link
control, error detection and
correction.

Network Layer
● Controls operation of the
subnet
● Determines how packets are
routed from source to
destination, statically or
dynamically.
● Handles routing and provides
host-to-host communication
through the subnet.

Loading…
Transport Layer
● Provides end-to-end communication
from one entity or process on a host
to another.
● The program on the source
machine carries on a
conversation with a similar
program on the destination
machine, using headers and
control information.
● In the lower layers, each protocol
is between a machine and its
immediate neighbors.
● Determines what type of service to
provide to the upper layers.
● Communication can be connection-
oriented or connection-less.

Session Layer
● Establish the sessions
between users on different
machines.
● Handles dialog control, token
management, synchronization
to keep both sides from
attempting a critical operation
(e.g. transaction) at the same
time. This layer is not
generally useful and is usually
omitted.

Presentation Layer
● Provides language or
format translation. This
is also the place that
data encryption and
decryption occurs in
the OSI model.

Application Layer
● The protocols at this layer
are specific to an
application, for example
file transfer, web service,
e-mail etc.

ISO/OSI reference model
Introduction: 1-34
Two layers not found in Internet
protocol stack!
▪ presentation: allow applications to
interpret meaning of data, e.g.,
encryption, compression, machine-
specific conventions
▪ session: synchronization, checkpointing,
recovery of data exchange
▪ Internet stack “missing” these layers!
• these services, if needed, must be
implemented in application
application
presentation
session
transport
network
link
physical
The seven layer
OSI/ISO
reference model

Critique of the OSI Model and Protocols
● Bad timing.
● Bad technology.
● Bad implementations.
● Bad politics.

Layered Internet protocol stack
▪ application: supporting network applications
• HTTP, IMAP, SMTP, DNS
▪ transport: process-process data transfer
• TCP, UDP
▪ network: routing of datagrams from source to
destination
• IP, routing protocols
▪ link: data transfer between neighboring
network elements
• Ethernet, 802.11 (WiFi), PPP
lin
k
applicatio
n
networ
k
transpor
t
physical
applicatio
n
transport
network
link
physical
Introduction: 1-36

Services, Layering and Encapsulation
sourc
e
▪ transport-layer protocol encapsulates
application-layer message, M, with
transport layer-layer header Ht to
create a transport-layer segment
• Ht used by transport layer protocol to
implement its service
application
transport
network
link
physical
destination
application
transport
network
link
physical
Transport-layer protocol transfers M (e.g., reliably) from
one process to another, using services of network layer
Ht M
Application exchanges messages to implement some
application service using services of transport layer
M
Introduction: 1-37

sourc
e
Transport-layer protocol transfers M (e.g., reliably) from
one process to another, using services of network layer
Ht M
▪ network-layer protocol encapsulates
transport-layer segment [Ht | M] with
network layer-layer header Hn to create a
network-layer datagram
• Hn used by network layer protocol to
application
transport
network
link
physical
destination
M
application
transport
network
link
physical
M
Ht
Hn
Network-layer protocol transfers transport-layer segment
[Ht | M] from one host to another, using link layer services
Introduction: 1-38

sourc
e
Ht M
▪ link-layer protocol encapsulates network
datagram [Hn| [Ht |M], with link-layer
header Hl to create a link-layer frame
application
transport
network
link
physical
destination
M
application
transport
network
link
physical
M
Ht
Hn
Link-layer protocol transfers datagram [Hn| [Ht |M] from
host to neighboring host, using network-layer services
M
Ht
Hn
Hl
Network-layer protocol transfers transport-layer segment
[Ht | M] from one host to another, using link layer services
Introduction: 1-39

sourc
e
application
transport
network
link
physical
destination
application
transport
network
link
physical
Ht M
M
M
Ht
Hn
M
Ht
Hn
Hl
M
Ht
Hn
Ht M
M
message
segment
datagram
frame M
Ht
Hn
Hl
Introduction: 1-40

network
link
physical
application
transport
network
link
physical
application
transport
network
link
physical
Encapsulation:
an end-end view
sourc
e
Ht
Hn M
segmen
t
Ht
datagram
destination
Ht
Hn
Hl M
Ht
Hn M
Ht M
M Ht
Hn
Hl M
Ht
Hn M
Ht
Hn M
Ht
Hn
Hl M
router
switch
message
M
Ht M
Hn
frame
link
physical
Introduction: 1-41

Chapter 1: roadmap
Introduction: 1-44
Network security

Network security
▪ Internet not originally designed with (much) security in
mind
• original vision: “a group of mutually trusting users attached
to a transparent network” ☺
• Internet protocol designers playing “catch-up”
• security considerations in all layers!
▪ We now need to think about:
• how bad guys can attack computer networks
• how we can defend networks against attacks
Introduction: 1-45

Bad guys: packet interception
packet “sniffing”:
▪ broadcast media (shared Ethernet, wireless)
▪ promiscuous network interface reads/records all packets
(e.g., including passwords!) passing by
A
B
C
src:B dest:A payload
Introduction: 1-47

Bad guys: fake identity
IP spoofing: injection of packet with false source
address
A
B
C
src:B dest:A payload
Introduction: 1-48

Bad guys: denial of service
target
Denial of Service (DoS): attackers make resources
(server, bandwidth) unavailable to legitimate traffic
by overwhelming resource with bogus traffic
1. select target
2. break into hosts
around the network
(see botnet)
3. send packets to target
from compromised
hosts
Introduction: 1-49

Lines of defense:
▪ authentication: proving you are who you say you are
• cellular networks provides hardware identity via SIM card; no
such hardware assist in traditional Internet

Lines of defense:
▪ confidentiality: via encryption
Introduction: 1-51

Lines of defense:
▪ integrity checks: digital signatures prevent/detect
tampering
Introduction: 1-52

Lines of defense:
▪ access restrictions: password-protected VPNs
Introduction: 1-53

Lines of defense:
▪ firewalls: specialized “middleboxes” in access and
core networks:
▪ off-by-default: filter incoming packets to restrict senders,
receivers, applications
▪ detecting/reacting to DOS attacks
… lots more on security (throughout, Chapter 8)
Introduction: 1-54

Chapter 1: roadmap
Introduction: 1-56
Internet history

Internet history
▪ 1961: Kleinrock - queueing
theory shows effectiveness
of packet-switching
▪ 1964: Baran - packet-
switching in military nets
▪ 1967: ARPAnet conceived
by Advanced Research
Projects Agency
▪ 1969: first ARPAnet node
operational
▪ 1972:
• ARPAnet public demo
• NCP (Network Control
Protocol) first host-host
protocol
• first e-mail program
• ARPAnet has 15 nodes
1961-1972: Early packet-switching principles

Internet history
▪ 1970: ALOHAnet satellite
network in Hawaii
▪ 1974: Cerf and Kahn -
architecture for
interconnecting networks
▪ 1976: Ethernet at Xerox PARC
▪ late70’s: proprietary
architectures: DECnet, SNA,
XNA
1972-1980: Internetworking, new and proprietary networks
Cerf and Kahn’s internetworking
principles:
▪ minimalism, autonomy - no
internal changes required to
interconnect networks
▪ best-effort service model
▪ stateless routing
▪ decentralized control
define today’s Internet
architecture
Introduction: 1-58

Internet history
▪ 1983: deployment of TCP/IP
▪ 1982: smtp e-mail protocol
defined
▪ 1983: DNS defined for
name-to-IP-address
translation
▪ 1985: ftp protocol defined
▪ 1988: TCP congestion
control
▪ new national networks: CSnet,
BITnet, NSFnet, Minitel
▪ 100,000 hosts connected to
confederation of networks
1980-1990: new protocols, a proliferation of networks
Introduction: 1-59

Internet history
▪ early 1990s: ARPAnet
decommissioned
▪ 1991: NSF lifts restrictions on
commercial use of NSFnet
(decommissioned, 1995)
▪ early 1990s: Web
• hypertext [Bush 1945, Nelson 1960’s]
• HTML, HTTP: Berners-Lee
• 1994: Mosaic, later Netscape
• late 1990s: commercialization of the
late 1990s – 2000s:
▪ more killer apps: instant
messaging, P2P file sharing
▪ network security to forefront
▪ est. 50 million host, 100 million+
users
▪ backbone links running at Gbps
1990, 2000s: commercialization, the Web, new applications
Introduction: 1-60

Internet history
▪ aggressive deployment of broadband home access (10-100’s
Mbps)
▪ 2008: software-defined networking (SDN)
▪ increasing ubiquity of high-speed wireless access: 4G/5G, WiFi
▪ service providers (Google, FB, Microsoft) create their own networks
• bypass commercial Internet to connect “close” to end user, providing
“instantaneous” access to social media, search, video content, …
▪ enterprises run their services in “cloud” (e.g., Amazon Web Services,
Microsoft Azure)
2005-present: scale, SDN, mobility, cloud
Introduction: 1-61

▪ rise of smartphones: more mobile than fixed devices on Internet
Chapter 1: summary
Introduction: 1-62
We’ve covered a “ton” of
material!
▪ Internet overview
▪ what’s a protocol?
▪ network edge, access network,
core
• packet-switching versus circuit-
switching
• Internet structure
▪ performance: loss, delay,
throughput
You now have:
▪ context,
overview,
vocabulary,
“feel” of
networking
▪ more depth,
detail, and fun to
follow!

CSC 645
Computer Networks
04
Application Layer Into
& HTTP

Review
We’ve covered a “ton” of material!
Internet overview
what’s a protocol?
network edge, access network, core
• packet-switching versus circuit-switching
• Internet structure
performance: loss, delay, throughput
layering, service models
security
Application Layer: 1-2

Loading…
QUIZ
What is the primary difference between forwarding and routing in the context of network
layer functions?
▪ Forwarding involves moving a packet to the next router, while routing determines the
entire end-to-end path of the packet.
What is a key characteristic of circuit-switched networks?
▪ They establish a dedicated path for the entire communication session.
Routing algorithms in a network are used to:
▪ Determine the optimal path for packet delivery.
What is the disadvantage of circuit switching compared to packet switching?
▪ It can be less efficient because the dedicated circuit may be idle during the
transmission.
Packet switching is considered more efficient for bursty data communication because:
▪ It allows multiple connections to share network bandwidth.

Quiz
Why are protocols often structured in layers?
▪ To organize protocol functions in a hierarchical manner and ensure interoperability.
Which of the following is NOT a layer in the 5-layer TCP/IP model?
▪ Session
In the 5-layer TCP/IP model, which layer is responsible for routing of data?
▪ Network
The 802.11 (WiFi) protocol operates at which layer?
▪ Link
Which layer uses the DNS protocol?
▪ Application

Loading…
Application layer: overview
● Principles of network applications
● Web and HTTP
● E-mail, SMTP, IMAP
● The Domain Name System (DNS)

Application layer: overview
Our goals:
● conceptual and
implementation aspects of
application-layer protocols
• transport-layer service
models
• client-server paradigm
• peer-to-peer paradigm
● learn about protocols by
examining popular
application-layer protocols
and infrastructure
• HTTP
• SMTP, IMAP
• DNS
• video streaming systems,
CDNs

Principles of network applications

Internet Application History
Network applications are driving force behind the Internet’s success, motivating people in
homes, schools, governments, and businesses to make the Internet an integral part of their
daily activities.
1970s-1980s:
• Text e-mail, Remote access to computers, File transfers, Newsgroups
Mid-1990s:
• World Wide Web (web surfing, search, and e-commerce)
2000s:
• Voice over IP and video conferencing (Skype, Facetime, Google Hangouts), User-
generated video (YouTube), Multiplayer online games (Second Life, World of Warcraft)
2000s-2010s:
• Social networking (Facebook, Instagram, Twitter)
2010s-Present:
• Location-based mobile apps (Yelp, Tinder, Waze), Mobile payment apps (WeChat, Apple
Pay), Messaging apps (WeChat, WhatsApp)

mobile network
home network
enterprise
network
national or global ISP
local or
regional
ISP
datacenter
network
content
provider
network
application
transport
network
data link
physical
application
transport
network
data link
physical
application
transport
network
data link
physical
Creating a network app
write programs that:
● run on (different) end systems
● communicate over network
● e.g., web server software
communicates with browser software
no need to write software for
network-core devices
● network-core devices do not run user
applications
● applications on end systems allows
for rapid app development,
propagation

Some network apps
● social networking
● Web
● text messaging
● e-mail
● multi-user network games
● streaming stored video
(YouTube, Hulu, Netflix)
● P2P file sharing
● voice over IP (e.g., Skype)
● real-time video
conferencing (e.g., Zoom)
● Internet search
● remote login
● …

Loading…
Network Applications Groups

mobile network
home network
enterprise
network
local or
regional
ISP
datacenter
network
content
provider
network
Client-server paradigm
server:
● always-on host
● permanent IP address
● often in data centers, for scaling
clients:
● contact, communicate with server
● may be intermittently connected
● may have dynamic IP addresses
● do not communicate directly with
each other
● examples: HTTP, IMAP, FTP

mobile network
home network
enterprise
network
local or
regional
ISP
datacenter
network
content
provider
network
Peer-peer architecture
● no always-on server
● arbitrary end systems directly
communicate
● peers request service from other
peers, provide service in return to
other peers
• self scalability – new peers bring new
service capacity, as well as new service
demands
● peers are intermittently connected
and change IP addresses
• complex management
● example: P2P file sharing

P2P Living streaming
Peer-to-Peer (P2P) live streaming
refers to a decentralized method of
streaming multimedia content over
the internet, where data is shared
between users (peers) instead of
being hosted on a central server.
➢ Reduced Server Load
➢ Increased Resilience
➢ Better Quality of Service
➢ More Efficient Use of Bandwidth
➢ Privacy Concerns
➢ Legal Issues

Processes communicating
process: program running
within a host
● within same host, two
processes communicate
using inter-process
communication (defined by
OS)
● processes in different hosts
communicate by exchanging
messages
● note: applications with
P2P architectures have
client processes &
server processes
client process: process that
initiates communication
server process: process
that waits to be contacted
clients, servers

Sockets
● process sends/receives messages to/from its socket
● socket analogous to door
• sending process shoves message out door
• sending process relies on transport infrastructure on other side of door
to deliver message to socket at receiving process
• two sockets involved: one on each side
Internet
controlle
d
by OS
controlled by
app
developer
transport
application
physical
link
network
process
transport
application
physical
link
network
process
socket

Addressing processes
● to receive messages, process
must have identifier
● host device has unique 32-bit
IP address
● Q: does IP address of host on
which process runs suffice for
identifying the process?
● identifier includes both IP address
and port numbers associated with
process on host.
● example port numbers:
• HTTP server: 80
• mail server: 25
● to send HTTP message to
cs.sfsu.edu web server:
• IP address: 23.185.0.253
• port number: 80
● A: no, many processes
can be running on
same host

An application-layer protocol defines:
● types of messages exchanged,
• e.g., request, response
● message syntax:
• what fields in messages &
how fields are delineated
● message semantics
• meaning of information in
fields
● rules for when and how
processes send & respond to
messages
open protocols:
● defined in RFCs, everyone
has access to protocol
definition
● allows for interoperability
● e.g., HTTP, SMTP
proprietary protocols:
● e.g., Skype, Zoom

Q&A
What do you need to consider, and what don't you need to consider?
➢ Do you need to consider which router your message will be handled on?
➢ Do you need to worry about the network delay?
➢ Do you need to worry about the network rate?
What do you need to create a network application such as YouTube?

What transport service does an app need?
data integrity
● some apps (e.g., file transfer,
web transactions) require
100% reliable data transfer
● other apps (e.g., audio) can
tolerate some loss
timing
● some apps (e.g., Internet
telephony, interactive games)
require low delay to be “effective”
throughput
● some apps (e.g., multimedia)
require minimum amount of
throughput to be “effective”
● other apps (“elastic apps”)
make use of whatever
throughput they get
security
● encryption, data integrity,
…

Transport service requirements: common apps
application
file transfer/download
e-mail
Web documents
real-time audio/video
streaming audio/video
interactive games
text messaging
data loss
no loss
no loss
no loss
loss-tolerant
loss-tolerant
loss-tolerant
no loss
throughput
elastic
elastic
elastic
audio: 5Kbps-1Mbps
video:10Kbps-
5Mbps
same as above
Kbps+
elastic
time sensitive?
no
no
no
yes, 10’s msec
yes, few secs
yes, 10’s msec
yes and no

Internet transport protocols services
TCP service:
● reliable transport between sending and
receiving process
● flow control: sender won’t overwhelm
receiver
● congestion control: throttle sender
when network overloaded
● connection-oriented: setup required
between client and server processes
● does not provide: timing, minimum
throughput guarantee, security
UDP service:
● unreliable data transfer between
sending and receiving process
● does not provide: reliability, flow
control, congestion control,
timing, throughput guarantee,
security, or connection setup.
Q: why bother? Why is
there a UDP?

Internet applications, and transport protocols
application
file transfer/download
e-mail
Web documents
Internet telephony
streaming audio/video
interactive games
application
layer protocol
FTP [RFC 959]
SMTP [RFC 5321]
HTTP 1.1 [RFC 7320]
SIP [RFC 3261], RTP
[RFC 3550], or
proprietary HTTP [RFC
7320], DASH
WOW, FPS (proprietary)
transport
protocol
TCP
TCP
TCP
TCP or UDP
TCP
UDP or TCP

Securing TCP
Vanilla TCP & UDP sockets:
● no encryption
● cleartext passwords sent into socket
traverse Internet in cleartext (!)
Transport Layer Security (TLS)
● provides encrypted TCP connections
● data integrity
● end-point authentication
TSL implemented in
application layer
● apps use TSL libraries,
that use TCP in turn
● cleartext sent into “socket”
traverse Internet encrypted
● more: Chapter 8

Web and HTTP

Web and HTTP Outline
● Web and HTTP
● Web, HTTP overview
● HTTP connections
• TCP, ‘stateless’
• Persistent, non-persistent
● HTTP messages
• Request, responses
● HTTP cookies

HTTP & HTML
https://youtu.be/kBXQZMmiA4s

Loading…
History of Web
Until the early 1990s, the Internet was used primarily by researchers, academics, and university
students for various purposes. The Internet was essentially unknown outside of academic and
research communities.
The World Wide Web arrived in the early 1990s and changed how people interact.
➢ The Web operates on demand and appeals to users.
➢ The Web is different from traditional broadcast radio and television.
➢ The Web is easy for individuals to make information available at low cost.
➢ Hyperlinks and search engines help navigate through information.
➢ Photos, videos, forms, JavaScript, and other devices enhance interaction with pages and sites.
➢ The Web and its protocols serve as a platform for various applications.
The HyperText Transfer Protocol (HTTP), the Web’s application-layer protocol, is at the heart of the
Web. It is defined in [RFC 1945], [RFC 7230] and [RFC 7540].

Web and HTTP
● web page consists of objects, each of which can be stored on
different Web servers
● object can be HTML file, JPEG image, Java applet, audio
file,…
● web page consists of base HTML-file which includes several
referenced objects, each addressable by a URL, e.g.,
www.someschool.edu/someDept/pic.gif
host name path name

HTTP overview
HTTP: hypertext transfer protocol
● Web’s application-layer protocol
● client/server model:
• client: browser that requests,
receives, (using HTTP protocol)
and “displays” Web objects
• server: Web server sends (using
HTTP protocol) objects in response
to requests
HTTP request
HTTP response
HTTP
request
HTTP
response
iPhone running
Safari browser
PC running
Firefox browser
server running
Apache Web
server

HTTP overview (continued)
HTTP uses TCP:
● client initiates TCP connection
(creates socket) to server, port 80
● server accepts TCP connection
from client
● HTTP messages (application-layer
protocol messages) exchanged
between browser (HTTP client) and
Web server (HTTP server)
● TCP connection closed
HTTP is “stateless”
● server maintains no
information about past client
requests
protocols that maintain “state”
are complex!
● past history (state) must be
maintained
● if server/client crashes, their views
of “state” may be inconsistent, must
be reconciled
aside

HTTP connections: two types
Non-persistent HTTP
1. TCP connection
opened
2. at most one object sent
over TCP connection
3. TCP connection closed
downloading multiple
objects required multiple
connections
Persistent HTTP
● TCP connection opened to
a server
● multiple objects can be
sent over single TCP
connection between client,
and that server
● TCP connection closed

Non-persistent HTTP: example
User enters URL:
1a. HTTP client initiates TCP
connection to HTTP server
(process) at www.someSchool.edu on
port 80
2. HTTP client sends HTTP
request message (containing
URL) into TCP connection
socket. Message indicates
that client wants object
someDepartment/home.index
1b. HTTP server at host
www.someSchool.edu waiting for TCP
connection at port 80 “accepts”
connection, notifying client
3. HTTP server receives request message,
forms response message containing
requested object, and sends message
into its socket
time
(containing text, references to 10 jpeg images)
www.someSchool.edu/someDepartment/home.index

Non-persistent HTTP: example (cont.)
User enters URL:
(containing text, references to 10 jpeg images)
www.someSchool.edu/someDepartment/home.index
5. HTTP client receives response
message containing html file,
displays html. Parsing html file,
finds 10 referenced jpeg objects
6. Steps 1-5 repeated for
each of 10 jpeg objects
4. HTTP server closes TCP
connection.
time

Non-persistent HTTP: response time
RTT (definition): time for a small
packet to travel from client to
server and back
HTTP response time (per object):
● one RTT to initiate TCP connection
● one RTT for HTTP request and first few
bytes of HTTP response to return
● obect/file transmission time
time to
transmit
file
initiate
TCP
connection
RT
T
request file
RT
T
file received
time time
Non-persistent HTTP response time = 2RTT+ file transmission time

Non-persistent HTTP issues
Non-persistent HTTP issues:
● requires 2 RTTs per object
● OS overhead for each TCP connection
● browsers often open multiple parallel TCP connections to fetch
referenced objects in parallel

Persistent HTTP (HTTP 1.1)
Persistent HTTP (HTTP1.1):
● server leaves connection open after sending response
● subsequent HTTP messages between same client/server sent over open
connection
● client sends requests as soon as it encounters a referenced object
● as little as one RTT for all the referenced objects (cutting response time in
half)

HTTP request message: general format
request
line
header
lines
body
method sp sp cr lf
version
URL
cr lf
value
header field name
cr lf
value
header field name
~
~ ~
~
cr lf
entity body
~
~ ~
~

HTTP request message
● two types of HTTP messages: request, response
● HTTP request message:
• ASCII (human-readable format)
header
lines
GET /index.html HTTP/1.1rn
Host: www-net.cs.umass.edurn
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15;
rv:80.0) Gecko/20100101 Firefox/80.0 rn
Accept: text/html,application/xhtml+xmlrn
Accept-Language: en-us,en;q=0.5rn
Accept-Encoding: gzip,deflatern
Connection: keep-alivern
rn
carriage return character
line-feed character
request line (GET,
POST,
HEAD commands)
carriage return, line feed
at start of line indicates
end of header lines * Check out the online interactive exercises for more
examples: http://gaia.cs.umass.edu/kurose_ross/interactive/

Other HTTP request messages
POST method:
● web page often includes form
input
● user input sent from client to
server in entity body of HTTP
POST request message
GET method (for sending data to
server):
● include user data in URL field of HTTP
GET request message (following a ‘?’):
www.somesite.com/animalsearch?monkeys&banana
HEAD method:
● requests headers (only) that
would be returned if specified
URL were requested with an
HTTP GET method.
PUT method:
● uploads new file (object) to
server
● completely replaces file that
exists at specified URL with
content in entity body of POST
HTTP request message

Questions
Consider the figure below, where a client is sending an HTTP GET message to a web server,
gaia.cs.umass.edu
Suppose the client-to-server HTTP GET message is the following:
1. GET /kurose_ross_sandbox/interactive/quotation10.htm HTTP/1.1
2. Host: gaia.cs.umass.edu
3. Accept: text/plain, text/html, image/gif, image/jpeg, audio/basic, audio/mp4, video/wmv,
video/mp4,
4. Accept-Language: en-us, en-gb;q=0.9, en;q=0.3, fr, fr-ch, de
5. If-Modified-Since: Mon, 13 Feb 2023 09:26:55 -0800
6. User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)

HTTP response message
status line (protocol
status code status phrase)
header
lines
data, e.g., requested
HTML file
HTTP/1.1 200 OK
Date: Tue, 08 Sep 2020 00:53:20 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-
fips PHP/7.4.9 mod_perl/2.0.11 Perl/v5.16.3
Last-Modified: Tue, 01 Mar 2016 18:57:50 GMT
ETag: "a5b-52d015789ee9e"
Accept-Ranges: bytes
Content-Length: 2651
Content-Type: text/html; charset=UTF-8
rn
data data data data data ...
* Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/

HTTP Response Status Codes
200 OK
• request succeeded, requested object later in this message
301 Moved Permanently
• requested object moved, new location specified later in this message (in
Location: field)
400 Bad Request
• request msg not understood by server
404 Not Found
• requested document not found on this server
505 HTTP Version Not Supported
● status code appears in 1st line in server-to-client response message.
● some sample codes:

Questions
Consider the figure below, where the server is sending a HTTP RESPONSE message back the client.
Suppose the server-to-client HTTP RESPONSE
message is the following:
1. HTTP/1.0 404 Not Found
2. Date: Mon, 13 Feb 2023 17:37:59 +0000
3. Server: Apache/2.2.3 (CentOS)
4. Content-Length: 667
5. Connection: Close
6. Content-type: image/html
1. Is the response message using HTTP 1.0 or HTTP 1.1?
2. Was the server able to send the document successfully?
3. How big is the document in bytes?
4. Is the connection persistent or nonpersistent?
5. What is the type of file being sent by the server in response?
6. What is the name of the server and its version?
Questions

Exploring HTTP Communication with Python
Step 2: install python and requests module:
pip install requests
• Sending GET, POST, HEAD, and PUT requests
• Observing different response status codes
• Interacting with both https://www.sfsu.edu and public HTTP testing services like
https://httpbin.org to explore request/response behaviors
Step 1: read tutorial
https://www.geeksforgeeks.org/python-requests-tutorial/

Task 1. Basic GET Request (SFSU.edu), try the code below
import requests
response = requests.get("https://www.sfsu.edu")
print("Status Code:", response.status_code)
print("Final URL (after redirection):", response.url)
print("Headers:n", response.headers)
print("Body (first 200 chars):n", response.text[:200])
Use ChatGPT to explain the output for you

Task 2. HEAD Request (Only headers, no body), try the code
below
head_response = requests.head("https://www.sfsu.edu")
print("Status Code:", head_response.status_code)
print("Headers:n", head_response.headers)

Task 3. POST Request (Form submission simulation), try the code
below
data = {"name": "SFSU Student", "project": "HTTP Exploration"}
post_response = requests.post("https://httpbin.org/post", data=data)
print("Status Code:", post_response.status_code)
print("JSON Response:n", post_response.json())

Task 3. PUT Request (Update simulation), try the code below
update_data = {"update": "true"}
put_response = requests.put("https://httpbin.org/put",
data=update_data)
print("Status Code:", put_response.status_code)
print("Response JSON:n", put_response.json())
Use ChatGPT to explain the output for you, what is the difference between POST and PUT

Maintaining user/server state: cookies

Recall: HTTP GET/response interaction is stateless
● no notion of multi-step exchanges of HTTP messages to
complete a Web “transaction”
• no need for client/server to track “state” of multi-step exchange
• all HTTP requests are independent of each other
• no need for client/server to “recover” from a partially-
completed-but-never-completely-completed transaction

HTTP is Stateless
Why can Amazon still
remember your
shopping cart?

Web sites and client browser use
cookies to maintain some state
between transactions
four components:
1) cookie header line of HTTP
response message
2) cookie header line in next HTTP
request message
3) cookie file kept on user’s host,
managed by user’s browser
4) back-end database at Web site
Example:
● Susan uses browser on laptop, visits
specific e-commerce site for first
time
● when initial HTTP requests arrives
at site, site creates:
• unique ID (aka “cookie”)
• entry in backend database for ID
• subsequent HTTP requests from
Susan to this site will contain cookie
ID value, allowing site to “identify”
Susan

client
server
usual HTTP response msg
usual HTTP response msg
cookie file
one week later:
usual HTTP request msg
cookie: 1678 cookie-
specifi
c
action
access
ebay 8734
usual HTTP request msg Amazon server
creates ID
1678 for user create
entry
usual HTTP
response
set-cookie: 1678
ebay 8734
amazon 1678
usual HTTP request msg
cookie: 1678 cookie-
specifi
c
action
access
ebay 8734
amazon 1678
backend
database
time time

HTTP cookies: comments
What cookies can be used for:
● authorization
● shopping carts
● recommendations
● user session state (Web e-mail)
cookies and privacy:
● cookies permit sites to
learn a lot about you on
their site.
● third party persistent
cookies (tracking cookies)
allow common identity
(cookie value) to be
tracked across multiple
web sites
aside
Challenge: How to keep state?
● at protocol endpoints: maintain state at
sender/receiver over multiple
transactions
● in messages: cookies in HTTP
messages carry state

Web caches

Web caches
● user configures browser to point to a (local) Web cache
● browser sends all HTTP requests to cache
• if object in cache: cache returns object to client
• else cache requests object from origin server, caches received object,
then returns object to client
Goal: satisfy client requests without involving origin server

Web caches
client
Web
cache
client
HTTP request
HTTP response
HTTP request HTTP request
origin
server
HTTP response HTTP response

Web caches (aka proxy servers)
● Web cache acts as both client and server
• server for original requesting client
• client to origin server
● server tells cache about object’s allowable caching in response
header:

Why Web caching?
● reduce response time for client request
• cache is closer to client
● reduce traffic on an institution’s access link
● Internet is dense with caches
• enables “poor” content providers to more effectively deliver
content

Caching example
origin
servers
public
Internet
institutiona
l
network
1 Gbps LAN
1.54 Mbps
access link
Scenario:
● access link rate: 1.54 Mbps
● RTT from institutional router to server: 2 sec
● web object size: 100K bits/request
● average request rate from browsers to origin servers:
15 request/sec
● avg data rate to browsers:
15 request/sec *100K /request = 1.50 Mbps

Caching example
origin
servers
public
Internet
institutiona
l
network
1 Gbps LAN
1.54 Mbps
access link
Performance:
● access link utilization = 1.5/1.54=.97
● LAN utilization: 1.5Mbps/1Gbps=0.0015
● end-end delay = Internet delay +
access link delay + LAN
delay
= 2 sec + minutes + usecs
Scenario:
● RTT from institutional
router to server: 2 sec
1.50 Mbps
problem: large queueing
delays at high utilization!

Performance:
● access link utilization = .97
● LAN utilization: .0015
delay
Option 1: buy a faster access link
origin
servers
public
Internet
institutiona
l
network
1 Gbps LAN
1.54 Mbps
access link
Scenario:
● web object size: 100K bits
● average request rate from browsers to origin
servers: 15/sec
● avg data rate to browsers: 1.50 Mbps
154 Mbps
154 Mbps
.0097
msecs
Cost: faster access link Application Layer: 2-6

Performance:
● LAN utilization: .?
● access link utilization = ?
● average end-end delay = ?
Option 2: install a web cache
origin
servers
public
Internet
institutiona
l
network
1 Gbps LAN
1.54 Mbps
access link
Scenario:
servers: 15/sec
How to compute link
utilization, delay?
Cost: web cache (cheap!)
local web cache

access link utilization, end-end delay with cache
origin
servers
public
Internet
institutiona
l
network
1 Gbps LAN
1.54 Mbps
access link
local web cache
suppose cache hit rate is 0.4:
● 40% requests served by cache, with low
(msec) delay
● 60% requests satisfied at origin
• rate to browsers over access link
= 0.6 * 1.50 Mbps = .9 Mbps
• access link utilization = 0.9/1.54 = .58 means
low (msec) queueing delay at access link
● average end-end delay:
= 0.6 * (delay from origin servers)
+ 0.4 * (delay when satisfied at cache)
= 0.6 (2.01) + 0.4 (~msecs) = ~ 1.2 secs
lower average end-end delay than with 154 Mbps link (and cheaper too!) Application Layer: 2-6

Conditional GET
Goal: don’t send object if cache has
up-to-date cached version
• no object transmission delay (or use
of network resources)
● client: specify date of cached copy
in HTTP request
If-modified-since: <date>
● server: response contains no
object if cached copy is up-to-date:
HTTP/1.0 304 Not Modified
HTTP request msg
HTTP response
HTTP/1.0
304 Not Modified
object
not
modified
before
<date>
HTTP request msg
HTTP response
HTTP/1.0 200 OK
<data>
object
modified
after
<date>
client server

HTTP/2
Key goal: decreased delay in multi-object HTTP requests
HTTP1.1: introduced multiple, pipelined GETs over single
TCP connection
● server responds in-order (FCFS: first-come-first-served scheduling) to
GET requests
● with FCFS, small object may have to wait for transmission (head-of-
line (HOL) blocking) behind large object(s)
● loss recovery (retransmitting lost TCP segments) stalls object
transmission

HTTP/2
HTTP/2: [RFC 7540, 2015] increased flexibility at server in sending
objects to client:
● methods, status codes, most header fields unchanged from HTTP 1.1
● transmission order of requested objects based on client-specified
object priority (not necessarily FCFS)
● push unrequested objects to client
● divide objects into frames, schedule frames to mitigate HOL
blocking

HTTP/2: mitigating HOL blocking
HTTP 1.1: client requests 1 large object (e.g., video file) and 3 smaller
objects
objects
client
server
GET
O1
GET
O2
GET
O3
GET
O4
O
1 O
2 O
3
O
4
object data requested
O1
O2
O3
O4
objects delivered in order requested: O2, O3, O4 wait behind O1 Application Layer: 2-7

HTTP/2: objects divided into frames, frame transmission interleaved
client
server
GET
O1
GET
O2
GET
O3
GET
O4
O
2 O
4
O1
O2
O3
O4
O2, O3, O4 delivered quickly, O1 slightly delayed
O
3
O
1

HTTP/2 to HTTP/3
HTTP/2 over single TCP connection means:
● recovery from packet loss still stalls all object transmissions
• as in HTTP 1.1, browsers have incentive to open multiple parallel
TCP connections to reduce stalling, increase overall throughput
● no security over vanilla TCP connection
● HTTP/3: adds security, per object error- and congestion-
control (more pipelining) over UDP
• more on HTTP/3 in transport layer

CSC 645
Computer Networks
Application Layer
HTTP& SMTP

Application Layer: 2-
Web caches
If you want to send a video to 10 of your friends who live in the same apartment, and they will randomly
download it within the next 10 days, what is the most convenient way for you to do this? Your data plan
is $10 per MB, and video size is 10 GB.

Loading…
Web Caches

Web caches
● user configures browser to point to a (local) Web cache
● browser sends all HTTP requests to cache
• if object in cache: cache returns object to client
• else cache requests object from origin server, caches received object,
then returns object to client

Loading…
Web caches
client
Web
cache
client
HTTP request
HTTP response
HTTP request HTTP request
origin
server
HTTP response HTTP response

● Web cache acts as both client and server
• server for original requesting client
• client to origin server
● server tells cache about object’s allowable caching in response
header:

Why Web caching?
● reduce response time for client request
• cache is closer to client
● reduce traffic on an institution’s access link
● Internet is dense with caches
• enables “poor” content providers to more effectively deliver
content

Caching example
origin
servers
public
Internet
institutiona
l
network
1 Gbps LAN
1.54 Mbps
access link
Scenario:
● web object size: 100K bits/request
● average request rate from browsers to origin servers:
15 request/sec
15 request/sec *100K /request = 1.50 Mbps

Caching example
origin
servers
public
Internet
institutiona
l
network
1 Gbps LAN
1.54 Mbps
access link
Performance:
● access link utilization = 1.5/1.54=.97
● LAN utilization: 1.5Mbps/1Gbps=0.0015
delay
Scenario:
● RTT from institutional
router to server: 2 sec
1.50 Mbps
problem: large queueing
delays at high utilization!

Performance:
● access link utilization = .97
● LAN utilization: .0015
delay
Option 1: buy a faster access link
origin
servers
public
Internet
institutiona
l
network
1 Gbps LAN
1.54 Mbps
access link
Scenario:
servers: 15/sec
154 Mbps
154 Mbps
.0097
msecs
Cost: faster access link Application Layer: 2-1

Loading…
Performance:
● LAN utilization: .?
● access link utilization = ?
● average end-end delay = ?
Option 2: install a web cache
origin
servers
public
Internet
institutiona
l
network
1 Gbps LAN
1.54 Mbps
access link
Scenario:
servers: 15/sec
How to compute link
utilization, delay?
Cost: web cache (cheap!)
local web cache

access link utilization, end-end delay with cache
origin
servers
public
Internet
institutiona
l
network
1 Gbps LAN
1.54 Mbps
access link
local web cache
suppose cache hit rate is 0.4:
● 40% requests served by cache, with low
(msec) delay
● 60% requests satisfied at origin
• rate to browsers over access link
= 0.6 * 1.50 Mbps = .9 Mbps
• access link utilization = 0.9/1.54 = .58 means
low (msec) queueing delay at access link
● average end-end delay:
= 0.6 * (delay from origin servers)
+ 0.4 * (delay when satisfied at cache)
= 0.6 (2.01) + 0.4 (~msecs) = ~ 1.2 secs
lower average end-end delay than with 154 Mbps link (and cheaper too!) Application Layer: 2-1

Conditional GET
Goal: don’t send object if cache has
up-to-date cached version
• no object transmission delay (or use
of network resources)
● client: specify date of cached copy
in HTTP request
● server: response contains no
object if cached copy is up-to-date:
HTTP/1.0 304 Not Modified
HTTP request msg
HTTP response
HTTP/1.0
304 Not Modified
object
not
modified
before
<date>
HTTP request msg
HTTP response
HTTP/1.0 200 OK
<data>
object
modified
after
<date>
client server

HTTP/2
HTTP1.1: introduced multiple, pipelined GETs over single
TCP connection
● server responds in-order (FCFS: first-come-first-served scheduling) to
GET requests
● with FCFS, small object may have to wait for transmission (head-of-
line (HOL) blocking) behind large object(s)
● loss recovery (retransmitting lost TCP segments) stalls object
transmission

HTTP/2
HTTP/2: [RFC 7540, 2015] increased flexibility at server in sending
objects to client:
● methods, status codes, most header fields unchanged from HTTP 1.1
● transmission order of requested objects based on client-specified
object priority (not necessarily FCFS)
● push unrequested objects to client
● divide objects into frames, schedule frames to mitigate HOL
blocking

objects
client
server
GET
O1
GET
O2
GET
O3
GET
O4
O
1 O
2 O
3
O
4
O1
O2
O3
O4
objects delivered in order requested: O2, O3, O4 wait behind O1 Application Layer: 2-1

HTTP/2: objects divided into frames, frame transmission interleaved
client
server
GET
O1
GET
O2
GET
O3
GET
O4
O
2 O
4
O1
O2
O3
O4
O2, O3, O4 delivered quickly, O1 slightly delayed
O
3
O
1

HTTP/2 to HTTP/3
HTTP/2 over single TCP connection means:
● recovery from packet loss still stalls all object transmissions
• as in HTTP 1.1, browsers have incentive to open multiple parallel
TCP connections to reduce stalling, increase overall throughput
● no security over vanilla TCP connection
● HTTP/3: adds security, per object error- and congestion-
control (more pipelining) over UDP
• more on HTTP/3 in transport layer

Application layer: E-mail
● infrastructure: user agents, servers, mail boxes
● SMTP: simple mail transfer protocol

Read: The History of Email
https://www.emailonacid.com/blog/article/needs-improvement/history-of-email/
Question: What is the storage space for Gmail in 2004?

E-mail
Three major components:
● user agents
● mail servers
● simple mail transfer protocol: SMTP
User Agent
● a.k.a. “mail reader”
● composing, editing, reading mail messages
● e.g., Outlook, iPhone mail client
● outgoing, incoming messages stored on
server user mailbox
outgoing
message queue
mail
server
mail
server
mail
server
SMT
P
SMT
P
SMT
P
user
agent
user
agent
user
agent
user
agent
user
agent
user
agent

E-mail: mail servers
user mailbox
outgoing
message queue
mail
server
mail
server
mail
server
SMT
P
SMT
P
SMT
P
user
agent
user
agent
user
agent
user
agent
user
agent
user
agent
mail servers:
● mailbox contains incoming
messages for user
● message queue of outgoing (to be
sent) mail messages
SMTP protocol between mail
servers to send email messages
● client: sending mail server
● “server”: receiving mail server

Scenario: Alice sends e-mail to Bob
1) Alice uses UA to compose e-mail
message “to” bob@someschool.edu
4) SMTP client sends Alice’s message
over the TCP connection
user
agen
t
mail
server
mail
server
1
2 3 4
5
6
Alice’s mail server Bob’s mail server
user
agen
t
2) Alice’s UA sends message to her
mail server using SMTP; message
placed in message queue
3) client side of SMTP at mail server
opens TCP connection with Bob’s mail
server
5) Bob’s mail server places
the message in Bob’s
mailbox
6) Bob invokes his user
agent to read message

SMTP RFC (5321)
● uses TCP to reliably transfer email message
from client (mail server initiating
connection) to server, port 25
● direct transfer: sending server (acting like
client) to receiving server
● three phases of transfer
• SMTP handshaking (greeting)
• SMTP transfer of messages
• SMTP closure
● command/response interaction (like HTTP)
• commands: ASCII text
• response: status code and phrase
initiate
TCP
connection
RT
T
time
220
250 Hello
HELO
SMTP
handshaking
TCP connection
initiated
“client”
SMTP server
“server”
SMTP server
SMTP
transfers

Sample SMTP interaction
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection

SMTP: observations
● SMTP uses persistent
connections
● SMTP requires message
(header & body) to be in
7-bit ASCII
● SMTP server uses
CRLF.CRLF to
determine end of
message
comparison with HTTP:
● HTTP: client pull
● SMTP: client push
● both have ASCII command/response
interaction, status codes
● HTTP: each object encapsulated in
its own response message
● SMTP: multiple objects sent in
multipart message

Loading…
Mail message format
SMTP: protocol for exchanging e-mail messages, defined in RFC 5321
(like RFC 7231 defines HTTP)
RFC 2822 defines syntax for e-mail message itself (like HTML defines
syntax for web documents)
header
body
blank
line
● header lines, e.g.,
• To:
• From:
• Subject:
these lines, within the body of the email
message area different from SMTP MAIL
FROM:, RCPT TO: commands!
● Body: the “message” , ASCII characters only

Retrieving email: mail access protocols
sender’s e-mail
server
SMTP SMTP
receiver’s e-mail
server
e-mail access
protocol
(e.g., IMAP,
HTTP)
user
agen
t
user
agen
t
● SMTP: delivery/storage of e-mail messages to receiver’s server
● mail access protocol: retrieval from server
• POP: Post Office Protocol [RFC 1939]: authorization, download
• IMAP: Internet Mail Access Protocol [RFC 1730]: more features, including
manipulation of stored messages on server
• HTTP: gmail, Hotmail, Yahoo! Mail, etc.

POP3 protocol
authorization phase
▪ client commands:
• user: declare username
• pass: password
▪ server responses
• +OK
• -ERR
transaction phase, client:
▪ list: list message numbers
▪ retr: retrieve message by number
▪ dele: delete
▪ quit
C: list
S: 1 498
S: 2 912
S: .
C: retr 1
S: <message 1 contents>
S: .
C: dele 1
C: retr 2
S: <message 1 contents>
S: .
C: dele 2
C: quit
S: +OK POP3 server signing off
S: +OK POP3 server ready
C: user bob
S: +OK
C: pass hungry
S: +OK user successfully logged on

POP3 (more) and IMAP
more about POP3
▪ previous example uses POP3
“download and delete” mode
• Bob cannot re-read e-mail if he
changes client
▪ POP3 “download-and-keep”:
copies of messages on different
clients
▪ POP3 is stateless across
sessions
IMAP
▪ keeps all messages in one place: at
server
▪ allows user to organize messages
in folders
▪ keeps user state across sessions:
• names of folders and mappings between
message IDs and folder name

HTTP: gmail, Hotmail, Yahoo!Mail, etc. provides web-based interface on top of STMP (to send), IMAP
(or POP) to retrieve e-mail messages

DNS: Domain Name System
https://youtu.be/MwxMsaFFycg

Internet hosts, routers:
• IP address (32 bit) - used for addressing datagrams,
• “name”, e.g., cs.sfsu.edu - used by humans
Q: how to map between IP address and name, and vice versa ?
we need a directory service that translates hostnames to IP addresses.
This is the main task of the Internet’s domain name system (DNS).

Domain Name System (DNS):
● distributed database implemented in hierarchy of many name servers
● application-layer protocol: hosts, DNS servers communicate to resolve
names (address/name translation)
• core Internet function, implemented as application-layer protocol
• Keep complexity at network’s “edge”
• Based on UDP, port number 53

DNS: services, structure
DNS services:
● hostname-to-IP-address translation
● host aliasing
• A host with a complicated hostname can have one or more alias names.
• relay1.west-coast.enterprise.com =enterprise.com=www.enterprise.com
• the host name relay1 .west-coast.enterprise.com is said to be a canonical hostname
● mail server aliasing
• SFSU mail server and Web server to have identical (aliased) hostnames: sfsu.edu
● load distribution
• replicated Web servers: many IP addresses correspond to one name

DNS: services, structure
Q: Why not centralize DNS?
● single point of failure
● traffic volume
● distant centralized database
● maintenance
A: doesn‘t scale!
● Comcast DNS servers alone: 600B DNS queries/day
● Akamai DNS servers alone: 2.2T DNS queries/day

Thinking about the DNS
humongous distributed database:
● ~ billion records, each simple
handles many trillions of queries/day:
● many more reads than writes
● performance matters: almost every Internet transaction interacts
with DNS - msecs count!
organizationally, physically decentralized:
● millions of different organizations responsible
for their records
“bulletproof”: reliability, security
IPV4:2^32= 4,294,967,295
IPv6: 2^128 = 3.4 x 1038

Hierarchical Database
Layer design allows us to divide and conquer the complex problem
cs.sfsu.edu

DNS
Hierarchy of DNS servers
Root Server
Top-Level
Domain (TLD)
Server
Authoritative
Server

DNS: A Distributed, Hierarchical Database
Client wants IP address for www.amazon.com; 1st approximation:
● client queries root server to find .com DNS server
● client queries .com DNS server to get amazon.com DNS server
● client queries amazon.com DNS server to get IP address for www.amazon.com
.com DNS servers .org DNS servers .edu DNS servers
… …
Top Level
Domain
Root DNS Servers Root
sfsu.edu
DNS servers
umass.edu
DNS servers
yahoo.com
DNS servers
amazon.com
DNS servers
pbs.org
DNS servers Authoritative
…
… … …
cs.sfsu.edu

DNS: root name servers
● official, contact-of-last-resort by
name servers that can not resolve
name

● incredibly important Internet function
• Internet couldn’t function without it!
• DNS Security Extensions (DNSSEC) – provides security (authentication,
message integrity)
● ICANN (Internet Corporation for Assigned Names and Numbers) manages
root DNS domain

13 logical root name “servers” worldwide each “server” replicated many times (~200
servers in US)
https://root-servers.org/

https://www.iana.org/domains/root/servers

Top-Level Domain, and authoritative servers
Top-Level Domain (TLD) servers:
● responsible for .com, .org, .net, .edu, .aero, .jobs, .museums,
● all top-level country domains, e.g.: .cn, .uk, .fr, .ca, .jp
● Network Solutions: authoritative registry for .com, .net TLD
● Educause: .edu TLD
https://www.icann.org/resources/pages/tlds-2012-02-25-en

Top-Level Domain, and authoritative servers
authoritative DNS servers:
● organization’s own DNS server(s),
● providing authoritative hostname to IP mappings for organization’s named hosts
● can be maintained by organization or service provider

Local DNS name servers
● when host makes DNS query, it is sent to its local DNS server
• Local DNS server returns reply, answering:
• from its local cache of recent name-to-address translation pairs (possibly out
of date!)
• forwarding request into DNS hierarchy for resolution
• each ISP has local DNS name server; to find yours:
• MacOS: % scutil --dns
• Windows: >ipconfig /all
● local DNS server doesn’t strictly belong to hierarchy

Home DNS server can be your wireless router

DNS name resolution: iterated query
Example: host at engineering.nyu.edu
wants IP address for hulk.cs.sfsu.edu
Iterated query:
● contacted server replies
with name of server to
contact
● “I don’t know this
name, but ask this
server”
requesting host at
engineering.nyu.edu
hulk.cs.sfsu.edu
root DNS server
local DNS server
dns.nyu.edu
1
2
3
4
5
6
authoritative DNS server
dns.cs. sfsu.edu
7
8
TLD DNS server

DNS name resolution: recursive query
requesting host at
engineering.nyu.edu
hulk.cs.sfsu.edu
root DNS server
local DNS server
dns.nyu.edu
1
2 3
4
5
6
authoritative DNS server
dns.cs.sfsu.edu
7
8
TLD DNS server
Recursive query:
● puts burden of name
resolution on
contacted name
server
● heavy load at upper
levels of hierarchy?
Example: host at engineering.nyu.edu
wants IP address for hulk.cs.sfsu.edu

Caching DNS Information
● once (any) name server learns mapping, it caches mapping,
and immediately returns a cached mapping in response to a
query
• caching improves response time
• cache entries timeout (disappear) after some time (TTL)
• TLD servers typically cached in local name servers
● cached entries may be out-of-date
• if named host changes IP address, may not be known Internet-wide
until all TTLs expire!
• best-effort name-to-address translation!

DNS records
DNS: distributed database storing resource records (RR)
RR format: (name, value, type, ttl)
type=A (Address record)
● name is hostname
● value is IP address

DNS records
type=NS (Name server record)
● name is domain (e.g., sfsu.edu)
● value is hostname of authoritative name server for this domain

DNS records
type=CNAME
● name is alias name for some “canonical” (the real) name
● www.ibm.com is really servereast.backup2.ibm.com
● value is canonical name

DNS records
type=MX
● value is name of SMTP mail server associated with name

identification flags
# questions
questions (variable # of questions)
# additional RRs
# authority RRs
# answer RRs
answers (variable # of RRs)
authority (variable # of RRs)
additional info (variable # of RRs)
2
b
yt
e
s
2
b
yt
e
s
DNS protocol messages （RFC 1035）
DNS query and reply messages, both have same format:
message header:
● identification: 16 bit # for query,
reply to query uses same #

# questions
# additional RRs
# authority RRs
# answer RRs
2
b
yt
e
s
2
b
yt
e
s
DNS protocol messages
message header:
● flags:
• query or reply
• recursion desired
• recursion available
• reply is authoritative

# questions
# additional RRs
# authority RRs
# answer RRs
2
b
yt
e
s
2
b
yt
e
s
name, type fields for a query
RRs in response to query
records for authoritative servers
additional “ helpful” info that may be
used
DNS protocol messages （RFC 1035）

nslookup

Getting your info into the DNS
example: new startup “Network Utopia”
● register name networkuptopia.com at DNS registrar (e.g., Network
Solutions)
• provide names, IP addresses of authoritative name server (primary and
secondary)
• registrar inserts NS, A RRs into .com TLD server:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
● create authoritative server locally with IP address 212.212.212.1
• type A record for www.networkuptopia.com
• type MX record for networkutopia.com

DNS security
DDoS attacks
● bombard root servers with
traffic
• not successful to date
• traffic filtering
• local DNS servers cache IPs of
TLD servers, allowing root server
bypass
● bombard TLD servers
• potentially more dangerous
Spoofing attacks
● intercept DNS queries,
returning bogus replies
● DNS cache poisoning
● RFC 4033: DNSSEC
authentication services

mobile network
home network
enterprise
network
local or
regional
ISP
datacenter
network
content
provider
network
Peer-to-peer (P2P) architecture
● no always-on server
● arbitrary end systems directly
communicate
● peers request service from other peers,
provide service in return to other peers
• self scalability – new peers bring new service
capacity, and new service demands
● peers are intermittently connected and
change IP addresses
• complex management
● examples: P2P file sharing (BitTorrent),
streaming (KanKan), VoIP (Skype)

File distribution: client-server vs P2P
Q: how much time to distribute file (size F) from one
server to N peers?
• peer upload/download capacity is limited resource
u
s
uN
dN
server
network (with abundant
bandwidth)
file, size F
us: server upload capacity
ui: peer i upload
capacity
di: peer i download
capacity
u2 d2
u1 d1
di
ui

File distribution time: client-server
● server transmission: must
sequentially send (upload) N file
copies:
• time to send one copy: F/us
• time to send N copies: NF/us
● client: each client must
download file copy
• dmin = min client download rate
• min client download time: F/dmin
u
s
network
di
ui
F
increases linearly in N
time to distribute F
to N clients using
client-server approach
Dc-s >
max{NF/us,,F/dmin}

File distribution time: P2P
● server transmission: must upload
at least one copy:
at least one copy:
● client: each client must download
file copy
u
s
network
di
ui
F
● clients: as aggregate must download NF bits
• max upload rate (limiting max download rate) is us + Sui
to N clients using
P2P approach
DP2P > max{F/us,,F/dmin,,NF/(us +
Sui)}
… but so does this, as each peer brings service capacity
increases linearly in N …

Client-server vs. P2P: example

P2P file distribution: BitTorrent
● file divided into 256Kb chunks
● peers in torrent send/receive file chunks
tracker: tracks peers
participating in torrent
torrent: group of peers
exchanging chunks of a file
Alice arrives …
… obtains list
of peers from tracker
… and begins exchanging
file chunks with peers in torrent

P2P file distribution: BitTorrent
● peer joining torrent:
• has no chunks, but will accumulate
them over time from other peers
• registers with tracker to get list of
peers, connects to subset of peers
(“neighbors”)
● while downloading, peer uploads chunks to other peers
● peer may change peers with whom it exchanges chunks
● churn: peers may come and go
● once peer has entire file, it may (selfishly) leave or (altruistically)
remain in torrent

BitTorrent: requesting, sending file chunks
Requesting chunks:
● at any given time,
different peers have
different subsets of file
chunks
● periodically, Alice asks
each peer for list of
chunks that they have
● Alice requests missing
chunks from peers,
rarest first
Sending chunks: tit-for-tat
● Alice sends chunks to those
four peers currently sending her
chunks at highest rate
• other peers are choked by Alice
(do not receive chunks from her)
• re-evaluate top 4 every10 secs
● every 30 secs: randomly select
another peer, starts sending
chunks
• “optimistically unchoke” this peer
• newly chosen peer may join top 4

BitTorrent: tit-for-tat
(1) Alice “optimistically unchokes” Bob
(2) Alice becomes one of Bob’s top-four providers; Bob reciprocates
(3) Bob becomes one of Alice’s top-four providers
higher upload rate: find better
trading partners, get file faster !

video streaming & content distribution networks
(CDNs)

Video Streaming and CDNs: context
● stream video traffic: major consumer of Internet
bandwidth
• Netflix, YouTube, Amazon Prime: 80% of residential ISP traffic (2020)
● challenge: scale - how to reach ~1B users?
● challenge: heterogeneity
● different users have different capabilities (e.g., wired
versus mobile; bandwidth rich versus bandwidth poor)
● solution: distributed, application-level infrastructure

Multimedia: video
● video: sequence of images
displayed at constant rate
• e.g., 24 images/sec
● digital image: array of pixels
• each pixel represented by bits
frame i
frame i+1

Multimedia: video
● coding: use redundancy within and
between images to decrease # bits
used to encode image
• spatial (within image)
• temporal (from one image to next)
…………………
…..
spatial coding example: instead of
sending N values of same color (all
purple), send only two values: color
value (purple) and number of repeated
values (N)
……………….…
….
frame i
frame i+1
temporal coding example: instead of
sending complete frame at i+1,
send only differences from frame i

Multimedia: video
…………………
…..
spatial coding example: instead of sending N
values of same color (all purple), send only two
values: color value (purple) and number of
repeated values (N)
……………….…
….
frame i
frame i+1
temporal coding example:
instead of sending complete
frame at i+1, send only
differences from frame i
● CBR: (constant bit rate): video
encoding rate fixed
● VBR: (variable bit rate): video
encoding rate changes as
amount of spatial, temporal
coding changes
● examples:
• MPEG 1 (CD-ROM) 1.5
Mbps
• MPEG2 (DVD) 3-6 Mbps
• MPEG4 (often used in
Internet, 64Kbps – 12 Mbps)

Loading…
Main challenges:
● server-to-client bandwidth will vary over time, with changing network
congestion levels (in house, access network, network core, video server)
● packet loss, delay due to congestion will delay playout, or result in poor video
quality
Streaming stored video
simple scenario:
video server
(stored video)
client
Internet

1. video
recorded (e.g., 30
frames/sec)
2. video
sent
C
u
m
u
l
a
ti
v
e
d
a
t
a
streaming: at this time, client playing out
early part of video, while server still sending
later part of video
time
3. video received, played out at client
(30 frames/sec)
network delay
(fixed in this
example)

Streaming stored video: challenges
● continuous playout constraint: during client video
playout, playout timing must match original timing
• … but network delays are variable (jitter), so will need
client-side buffer to match continuous playout constraint
● other challenges:
• client interactivity: pause, fast-forward, rewind,
jump through video
• video packets may be lost, retransmitted

Streaming stored video: playout buffering
constant bit
rate video
transmission
C
u
m
u
l
a
ti
v
e
d
a
t
a
time
variable
network
delay
client video
reception
constant bit
rate video
playout at client
client playout
delay
buf
fere
d
vid
eo
● client-side buffering and playout delay: compensate for
network-added delay, delay jitter

Streaming multimedia: DASH
server:
● divides video file into multiple chunks
● each chunk encoded at multiple different rates
● different rate encodings stored in different files
● files replicated in various CDN nodes
● manifest file: provides URLs for different chunks client
?
client:
● periodically estimates server-to-client bandwidth
● consulting manifest, requests one chunk at a time
• chooses maximum coding rate sustainable given current bandwidth
• can choose different coding rates at different points in time (depending on
available bandwidth at time), and from different servers
...
...
...
Dynamic, Adaptive Streaming over HTTP

...
...
...
● “intelligence” at client: client
determines
• when to request chunk (so that buffer
starvation, or overflow does not occur)
• what encoding rate to request (higher
quality when more bandwidth
available)
• where to request chunk (can request
from URL server that is “close” to
client or has high available
bandwidth)
Streaming video = encoding + DASH + playout
client
?

buffering
Content distribution networks (CDNs)
challenge: how to stream content (selected from millions of
videos) to hundreds of thousands of simultaneous users?
● option 1: single, large “mega-server”
• single point of failure
• point of network congestion
• long (and possibly congested) path to distant clients
….quite simply: this solution doesn’t scale

• enter deep: push CDN servers deep into many access networks
• close to users
• Akamai: 240,000 servers deployed
in > 120 countries (2015)
● option 2: store/serve multiple copies of videos at multiple
geographically distributed sites (CDN)

…
…
…
…
…
…
●subscriber requests content, service provider returns manifest
● CDN: stores copies of content (e.g. MADMEN) at CDN nodes
where’s Madmen?
manifest file
• using manifest, client retrieves content at highest supportable rate
• may choose different rate or copy if network path congested

Summary
• Conceptual of application-layer protocols
• Transport-layer service models
• Client-server paradigm
• Peer-to-peer paradigm
• Learn about protocols by examining popular application-layer
protocols and infrastructure
• HTTP
• SMTP, IMAP
• DNS
• P2P
• CDN

CSC 645
Computer Networks
Video & Socket
Programming

Main content
P2P
Video Streaming Application
• Content distribution networks
Socket Programing
• UDP
• TCP

Loading…
P2P applications

Loading…
File distribution: client-server vs P2P
Q: how much time to distribute file (size F) from one
server to N peers?
• peer upload/download capacity is limited resource
u
s
uN
dN
server
network (with abundant
bandwidth)
file, size F
us: server upload capacity
ui: peer i upload
capacity
di: peer i download
capacity
u2 d2
u1 d1
di
ui

File distribution time: P2P
● server transmission: must upload
at least one copy:
● client: each client must download
file copy
u
s
network
di
ui
F
● clients: as aggregate must download NF bits
• max upload rate (limiting max download rate) is us + Sui
to N clients using
P2P approach
DP2P > max{F/us,,F/dmin,,NF/(us +
Sui)}
… but so does this, as each peer brings service capacity
increases linearly in N …

Loading…
BitTorrent: requesting, sending file chunks
Requesting chunks:
● at any given time,
different peers have
different subsets of file
chunks
● periodically, Alice asks
each peer for list of
chunks that they have
● Alice requests missing
chunks from peers,
rarest first
Sending chunks: tit-for-tat
● Alice sends chunks to those
four peers currently sending her
chunks at highest rate
• other peers are choked by Alice
(do not receive chunks from her)
• re-evaluate top 4 every10 secs
● every 30 secs: randomly select
another peer, starts sending
chunks
• “optimistically unchoke” this peer
• newly chosen peer may join top 4

Read:A Brief History of P2P Content Distribution
https://medium.com/paratii/a-brief-history-of-
p2p-content-distribution-in-10-major-steps-
6d6733d25122
Question:
What is the key word in DSNs?

Video streaming & content distribution networks
(CDNs)

Video Streaming and CDNs: context
● stream video traffic: major consumer of Internet bandwidth
• Netflix, YouTube, Amazon Prime: 80% of residential ISP traffic (2020)
● challenge: scale - how to reach ~1B users?
● challenge: heterogeneity
● different users have different capabilities (e.g., wired
versus mobile; bandwidth rich versus bandwidth poor)
● solution: distributed, application-level infrastructure

Main challenges:
● server-to-client bandwidth will vary over time, with changing network
congestion levels (in house, access network, network core, video server)
● packet loss, delay due to congestion will delay playout, or result in poor video
quality
simple scenario:
video server
(stored video)
client
Internet

1. video
recorded (e.g., 30
frames/sec)
2. video
sent
C
u
m
u
l
a
ti
v
e
d
a
t
a
streaming: at this time, client playing out
early part of video, while server still sending
later part of video
time
3. video received, played out at client
(30 frames/sec)
network delay
(fixed in this
example)

Streaming stored video: challenges
● continuous playout constraint: during client video
playout, playout timing must match original timing
• … but network delays are variable (jitter), so will need
client-side buffer to match continuous playout constraint
● other challenges:
• client interactivity: pause, fast-forward, rewind,
jump through video
• video packets may be lost, retransmitted

Streaming stored video: playout buffering
constant bit
rate video
transmission
C
u
m
u
l
a
ti
v
e
d
a
t
a
time
variable
network
delay
client video
reception
constant bit
rate video
playout at client
client playout
delay
buf
fere
d
vid
eo
● client-side buffering and playout delay: compensate for
network-added delay, delay jitter

server:
● divides video file into multiple chunks
● each chunk encoded at multiple different rates
● different rate encodings stored in different files
● files replicated in various CDN nodes
● manifest file: provides URLs for different chunks client
?
client:
● periodically estimates server-to-client bandwidth
● consulting manifest, requests one chunk at a time
• chooses maximum coding rate sustainable given current bandwidth
• can choose different coding rates at different points in time (depending on
available bandwidth at time), and from different servers
...
...
...
Dynamic, Adaptive Streaming over HTTP

...
...
...
● “intelligence” at client: client
determines
• when to request chunk (so that buffer
starvation, or overflow does not occur)
• what encoding rate to request (higher
quality when more bandwidth
available)
• where to request chunk (can request
from URL server that is “close” to
client or has high available
bandwidth)
client
?

buffering
● option 1: single, large “mega-server”
• single point of failure
• point of network congestion
• long (and possibly congested) path to distant clients
….quite simply: this solution doesn’t scale

• enter deep: push CDN servers deep into many access networks
• close to users
• Akamai: 240,000 servers deployed
in > 120 countries (2015)
● option 2: store/serve multiple copies of videos at multiple
geographically distributed sites (CDN)

…
…
…
…
…
…
●subscriber requests content, service provider returns manifest
● CDN: stores copies of content (e.g. MADMEN) at CDN nodes
where’s Madmen?
manifest file
• using manifest, client retrieves content at highest supportable rate
• may choose different rate or copy if network path congested

Loading…
Application Layer: Socket programming with UDP and TCP

Socket as a pair of doors
● A typical network application consists of a pair of programs residing in two different end
systems: a client program and a server program.
● When these two programs are executed, a client process and a server process are
created, and these processes communicate with each other by reading from and writing
to sockets.
● When creating a network application, the developer’s main task is to write the code for
both the client and server programs.
Socket acts like a pair of doors.

Socket programming
goal:
learn how to build client/server applications that communicate using sockets
socket:
door between application process and end-end-transport protocol
Internet
controlled by
app
developer
transport
application
physical
link
network
process
transport
application
physical
link
network
process
socket

Addressing processes
● to receive messages, process
must have identifier
● host device has unique 32-bit
IP address
● Q: does IP address of host on
which process runs suffice for
identifying the process?
● identifier includes both IP address
and port numbers associated with
process on host.
● example port numbers:
• HTTP server: 80
• mail server: 25
● to send HTTP message to
cs.sfsu.edu web server:
• IP address: 23.185.0.253
• port number: 80
● A: no, many processes
can be running on
same host

Socket programming
Application Example:
1. client reads a line of characters (data) from its keyboard and sends
data to server
server (running on server IP)
client
hello, nice to
meet you

Socket programming
data to server
server (running on serverIP)
client
hello, nice to
meet you

Socket programming
data to server
2. server receives the data and converts characters to uppercase
client
HELLO, NICE
TO MEET YOU

Socket programming
data to server
3. server sends modified data to client
client
HELLO, NICE
TO MEET YOU

Socket programming
data to server
3. server sends modified data to client
4. client receives modified data and displays line on its screen
client
HELLO, NICE
TO MEET YOU

Socket programming
Two socket types for two transport services:
● UDP: connectionless and sends independent packets
of data from one end system to the other, without any
guarantees about delivery
● TCP: connection oriented and provides a reliable byte-
stream channel through which data flows between two
end systems.

Socket programming
UDP: Put in front door
TCP: Hand shake and double confirm
Both need: address and apartment number
Socket (TCP/UDP): IP address and port number

Socket programming with UDP
UDP: no “connection” between client and server:
no handshaking before sending data
sender explicitly attaches IP destination address and port # to each packet
receiver extracts sender IP address and port# from received packet
UDP: transmitted data may be lost or received out-of-order
Application viewpoint:
● UDP provides unreliable transfer of groups of bytes (“datagrams”)

Client/server socket interaction: UDP
close
clientSocket
read datagram from
clientSocket
create socket:
clientSocket =
socket(AF_INET,SOCK_DGRAM)
Create datagram with server IP address
And port=x; send datagram via
clientSocket
create socket, port= x:
serverSocket =
socket(AF_INET,SOCK_DGRAM)
read datagram from
serverSocket
write reply to
serverSocket
specifying
client address,
port number
server (running on serverIP) client

UDPClient.py
1. from socket import *
2. serverName = ’hostname’
3. serverPort = 12000
4. clientSocket = socket(AF_INET, SOCK_DGRAM)
5. message = input(’Input lowercase sentence:’)
6. clientSocket.sendto(message.encode(),(serverName, serverPort))
7. modifiedMessage, serverAddress = clientSocket.recvfrom(2048)
8. print(modifiedMessage.decode())
9. clientSocket.close()
https://docs.python.org/3/library/socket.html

UDPClient.py
from socket import *
The socket module forms the basis of all network communications in Python. By including this
line, it allow us to create sockets within our program.
serverName = ’hostname’
serverPort = 12000
variable serverName = string ‘hostname’. A string containing either the IP address of the server
(e.g., “128.138.32.126”) or the hostname of the server (e.g., “cs.sfsu.edu”). If we use the
hostname, then a DNS lookup will automatically be performed to get the IP address.
integer variable serverPort = 12000: port number at server side.

UDPClient.py
clientSocket = socket(AF_INET, SOCK_DGRAM)
Parameter 1 indicates the address family, AF_INET indicates that the underlying
network is using IPv4.
Parameter 2 indicates that the socket is of type SOCK_DGRAM, which means it
is a UDP socket (rather than a TCP socket).
Note that we are not specifying the port number of the client socket when we
create it; we are instead letting the operating system do this for us
Creates the client’s socket: socket(param1, param2)

UDPClient.py
message = input(’Input lowercase sentence:’)
input() is a built-in function in Python. When this command is executed, the
user at the client is prompted with the words “Input lowercase sentence:” The
user then uses keyboard to input a line, which is put into the variable
message.
clientSocket.sendto(message.encode(),(serverName, serverPort))
encode() method convert the message from string type to byte type
sendto() method attaches the destination address (serverName, serverPort)
to the message and sends the resulting packet into the process’s socket, i.e,
clientSocket.

UDPClient.py
After sending the packet, the client waits to receive data from the server.
modifiedMessage, serverAddress = clientSocket.recvfrom(2048)
when a packet arrives from the Internet at the client’s socket, the packet’s
data is put into the variable modifiedMessage and the packet’s source
address is put into the variable serverAddress.
The variable serverAddress contains both the server’s IP address and the
server’s port number.
The method recvfrom also takes the buffer size 2048 as input. (This buffer
size works for most purposes.)

UDPClient.py
print(modifiedMessage.decode())
clientSocket.close()
prints out modifiedMessage on the user’s display, after converting the
message from bytes to string.
closes the socket and terminate process

Example app: UDP client
serverName = ‘hostname’
serverPort = 12000
clientSocket = socket(AF_INET,
SOCK_DGRAM)
message = raw_input(’Input lowercase sentence:’)
clientSocket.sendto(message.encode(),
(serverName, serverPort))
modifiedMessage, serverAddress =
clientSocket.recvfrom(2048)
print modifiedMessage.decode()
Python UDPClient
include Python’s socket library
create UDP socket for server
get user keyboard input
attach server name, port to message; send into socket
print out received string and close socket
read reply characters from socket into string

UDPServer.py
1. from socket import *
2. serverPort = 12000
3. serverSocket = socket(AF_INET, SOCK_DGRAM)
4. serverSocket.bind(('', serverPort))
5. print("The server is ready to receive")
6. while True:
7. message, clientAddress = serverSocket.recvfrom(2048)
8. modifiedMessage = message.decode().upper()
9. serverSocket.sendto(modifiedMessage.encode(),
10. clientAddress)

UDPServer.py
The first line of code that is significantly different from UDPClient is:
serverSocket.bind(('', serverPort))
The above line binds (assigns) the port number 12000 to the server’s
socket.
In this manner, when anyone sends a packet to port 12000 at the IP
address of the server, that packet will be directed to this socket.

UDPServer.py
while True:
message, clientAddress = serverSocket.recvfrom(2048)
• UDPServer then enters a while loop, it will allow UDPServer to receive and
process packets from clients indefinitely.
• When a packet arrives at the server’s socket, the packet’s data is put into the
variable message and the packet’s source address is put into the variable
clientAddress.
• clientAddress contains both the client’s IP address and the client’s port
number.
• UDPServer will make use of this source address information to direct its reply,
as it provides a return address, similar to the return address with ordinary
postal mail.

UDPServer.py
modifiedMessage = message.decode().upper()
It takes the line sent by the client, after converting the message to a string,
uses the method upper() to capitalize it.
serverSocket.sendto(modifiedMessage.encode(),
clientAddress)
This line attaches the client’s address (IP address and port number) to the
capitalized message (after converting the string to bytes), and sends the
resulting packet into the server’s socket.

Example app: UDP server
Python UDPServer
serverPort = 12000
serverSocket = socket(AF_INET, SOCK_DGRAM)
serverSocket.bind(('', serverPort))
print (“The server is ready to receive”)
while True:
message, clientAddress = serverSocket.recvfrom(2048)
modifiedMessage = message.decode().upper()
serverSocket.sendto(modifiedMessage.encode(),
clientAddress)
create UDP socket
bind socket to local port number 12000
loop forever
Read from UDP socket into message, getting
client’s address (client IP and port)
send upper case string back to this client

Try this client server code by yourself, you can try to revise the method in serverside
You should change the IP address as server’s address
Task

Socket programming with TCP
Client must contact server
server process must first be running
server must have created socket (door) that welcomes client’s contact
Client contacts server by:
Creating TCP socket, specifying IP address, port number of server process
when client creates socket: client TCP establishes connection to server TCP
TCP is a connection-oriented protocol. Before the client and server can start to
send data to each other, they first need to handshake and establish a TCP
connection.
Hand shake and double confirm

● when contacted by client, server TCP creates new socket for server
process to communicate with that particular client
• allows server to talk with multiple clients
• source port numbers used to distinguish clients (more in Chap 3)
TCP provides reliable, in-order
byte-stream transfer (“pipe”)
Application viewpoint

From the application’s perspective, the client’s socket and the server’s connection socket are
directly connected by a pipe.

Client/server socket interaction: TCP
server (running on hostid) client
wait for incoming
connection request
connectionSocket =
serverSocket.accept()
create socket,
port=x, for incoming
request:
serverSocket = socket()
create socket,
connect to hostid, port=x
clientSocket = socket()
send request using
clientSocket
read request from
connectionSocket
write reply to
connectionSocket
TCP
connection setup
close
connectionSocket
read reply from
clientSocket
close
clientSocket

TCPClient.py
serverName = 'servername'
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_STREAM)
clientSocket.connect((serverName,serverPort))
sentence = input('Input lowercase sentence:')
clientSocket.send(sentence.encode())
modifiedSentence = clientSocket.recv(1024)
print('From Server: ', modifiedSentence.decode())!

TCPClient.py
This line creates the client’s socket, called clientSocket.
The first parameter indicates that the underlying network is using IPv4.
The second parameter indicates that the socket is of type SOCK_STREAM,
which means it is a TCP socket (rather than a UDP socket).

TCPClient.py
This line initiates the TCP connection between the client and server.
The parameter of the connect() method is the address of the server side of the
connection.
After this line of code is executed, the three-way handshake is performed and a
TCP connection is established between the client and server.

TCPClient.py
sentence = input('Input lowercase sentence:')
The string sentence continues to gather characters until the user ends the line
by typing a carriage return
The above line sends the sentence through the client’s socket and into the TCP
connection. Note that the program does not explicitly create a packet and
attach the destination address to the packet (as with UDP sockets).
The client program simply drops the bytes in the string sentence into the TCP
connection.
The client then waits to receive bytes from the server.

TCPClient.py
When characters arrive from the server, they get placed into the string
modifiedSentence. Characters continue to accumulate in
modifiedSentence until the line ends with a carriage return character
This last line closes the socket and, hence, closes the TCP connection
between the client and the server. It causes TCP in the client to send a
TCP message to TCP in the server.

Example app: TCP client
serverName = ’servername’
serverPort = 12000
sentence = raw_input(‘Input lowercase sentence:’)
print (‘From Server:’, modifiedSentence.decode())
Python TCPClient
create TCP socket for server,
remote port 12000
No need to attach server name, port

TCPServer.py
serverPort = 12000
serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind(('',serverPort))
serverSocket.listen(1)
print('The server is ready to receive')
while True:
connectionSocket, addr = serverSocket.accept()
sentence = connectionSocket.recv(1024).decode()
capitalizedSentence = sentence.upper()
connectionSocket.send(capitalizedSentence.encode())
connectionSocket.close()

TCPServer.py
As with TCPClient, the server creates a TCP socket
serverSocket.bind(('',serverPort))
Similar to UDPServer, we associate the server port number,
serverPort, with this socket. But with TCP, serverSocket will
be our welcoming socket

TCPServer.py
This line has the server listen for TCP connection requests from the client. The
parameter specifies the maximum number of queued connections (at least 1)
• When a client knocks on this door, the program invokes the accept() method
for serverSocket, which creates a new socket in the server, called
connectionSocket, dedicated to this particular client.
• The client and server then complete the handshaking, creating a TCP
connection between the client’s clientSocket and the server’s
connectionSocket.
• With the TCP connection established, the client and server can now send
bytes to each other over the connection.

TCPServer.py
In this program, after sending the modified sentence to the client, we close
the connection socket. But since serverSocket remains open, another client
can now knock on the door and send the server a sentence to modify.

Example app: TCP server
serverPort = 12000
serverSocket.bind((‘’,serverPort))
print ‘The server is ready to receive’
while True:
sentence = connectionSocket.recv(1024).decode()
capitalizedSentence = sentence.upper()
connectionSocket.send(capitalizedSentence.
encode())
Python TCPServer
create TCP welcoming socket
server begins listening for
incoming TCP requests
loop forever
server waits on accept() for incoming
requests, new socket created on return
read bytes from socket (but
not address as in UDP)
close connection to this client (but not
welcoming socket)

Task
Try this client server code by yourself, you can try to revise the method in server side
You should change the IP address as server’s address

Httpclient.py
import socket
import os
import webbrowser
# Server Configuration
SERVER_IP = input("Enter the server IP address (Instructor's laptop IP): ")
SERVER_PORT = 8080
# Student Inputs HTTP Method and Path
http_method = input("Enter HTTP method (GET or POST): ").strip().upper()
request_path = input("Enter request path (e.g., /index.html, /wow.jpg, or /post): ").strip()
# Handle POST request (Ask for user input)
post_data = ""
. if http_method == "POST":
. post_data = input("Enter data to send in POST request: ")
. content_length = len(post_data)
http_request = f"{http_method} {request_path} HTTP/1.1rnHost: {SERVER_IP}rnContent-Length:
{content_length}rnContent-Type: text/plainrnrn{post_data}"
else: # Handle GET request
http_request = f"{http_method} {request_path} HTTP/1.1rnHost: {SERVER_IP}rnrn"
.
print("n--- Sending HTTP Request ---")
. print(http_request)

# Create Socket and Send Request
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((SERVER_IP, SERVER_PORT))
sock.sendall(http_request.encode())
# Receive Response
response = b""
while True:
chunk = sock.recv(4096)
if not chunk:
break
response += chunk
# Close Socket
sock.close()
# Ensure we received data
if not response:
print("Error: No response received from the server.")
exit(1)
# Attempt to split headers and body safely
if b"rnrn" in response:
headers, body = response.split(b"rnrn", 1)
print("n--- Received HTTP Response Headers ---")
print(headers.decode(errors="ignore"))
else:

Httpserver.py
import socket
# HTML Content (Valid Response)
HTML_PAGE = """
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: {length}
<!DOCTYPE html>
<html>
<head>
<title>Sample Webpage</title>
</head>
<body>
<h1>Welcome to the Computwer Network Student HTTP Test</h1>
<p>This is a simple webpage served from the instructor's server.</p>
<h2>WoW, You can really dance!!!</h2>
<img src="wow.jpg" alt="Sample Image" width="300">
</body>
</html>
""".replace("n", "rn") # Ensure proper HTTP newlines
# Error 404 Response
ERROR_PAGE = """
HTTP/1.1 404 Not Found
Content-Type: text/html

Content-Length: {length}
def handle_client(conn, addr):
"""Handles incoming HTTP requests."""
request = conn.recv(1024).decode(errors="ignore")
print(f"n--- Received Request from {addr} ---n{request}")
# Extract Method and Requested Path
request_lines = request.split("rn")
if len(request_lines) > 0 and request_lines[0].startswith(("GET", "POST")):
method, requested_file, _ = request_lines[0].split(" ")
else:
requested_file = "/error"
method = "UNKNOWN"
# Serve HTML Page
if method == "GET" and (requested_file == "/index.html" or requested_file == "/"):
body = HTML_PAGE.format(length=len(HTML_PAGE)).encode()
response = body
elif method == "GET" and requested_file == "/wow.jpg":
image_data = load_image()
response = b"HTTP/1.1 200 OKrnContent-Type: image/jpegrnContent-Length: " + str(len(image_data)).encode() + b"rnrn" +
image_data
elif method == "POST" and requested_file == "/post":
# Extract POST Data
post_data = request.split("rnrn")[1] if "rnrn" in request else ""
print(f"n--- Received POST Data ---n{post_data}")
response = b"HTTP/1.1 200 OKrnContent-Type: text/plainrnContent-Length: 14rnrnPOST Received!"
else:

# Image File Path
IMAGE_PATH = "wow.jpg"
def load_image():
"""Load the image as binary data."""
with open(IMAGE_PATH, "rb") as f:
return f.read()
def start_server():
"""Starts the HTTP server."""
server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_socket.bind(("0.0.0.0", 8080))
server_socket.listen(5)
print("Server running on port 8080...")
print("Waiting for connections...")
while True:
conn, addr = server_socket.accept()
handle_client(conn, addr)
# Run the server
start_server()

Chapter 2: Summary
● application architectures
• client-server
• P2P
● application service requirements:
• reliability, bandwidth, delay
● Internet transport service model
• connection-oriented, reliable: TCP
• unreliable, datagrams: UDP
our study of network application layer is now complete!
● specific protocols:
• HTTP
• SMTP, IMAP
• DNS
● video streaming, CDNs
● socket programming:
TCP, UDP sockets

Chapter 2: Summary
Most importantly: learned about protocols!
typical request/reply message exchange:
client requests info or service
server responds with data, status code
message formats:
headers: fields giving info about data
data: info(payload) being communicated
important themes:
● centralized vs.
decentralized
● stateless vs. stateful
● scalability
● reliable vs. unreliable
message transfer
● “complexity at network
edge”

See you next class
Transport Layer

CSC 645
Computer Networks
Transport Layer 01

Review
buffering
socket: door between application process and end-end-transport
protocol
identifier includes both IP address and port numbers associated with
process on host.
Two socket types for two transport services:
● UDP: connectionless and sends independent packets
● TCP: connection oriented and provides a reliable byte-
stream channel.

Loading…
Transport layer: overview
Chapter 3.1

Transport layer: overview
Our goal:
● understand principles behind
transport layer services:
• multiplexing, demultiplexing
• reliable data transfer
• flow control
• congestion control
● learn about Internet transport
layer protocols:
• UDP: connectionless transport
• TCP: connection-oriented
reliable transport
• TCP congestion control

Loading…
Transport layer: roadmap
▪ Transport-layer services
▪ Multiplexing and demultiplexing
▪ Connectionless transport: UDP
▪ Principles of reliable data transfer
▪ Connection-oriented transport: TCP
▪ Principles of congestion control
▪ TCP congestion control
▪ Evolution of transport-layer functionality

sourc
e
▪ transport-layer protocol encapsulates
application-layer message, M, with
transport layer-layer header Ht to create a
transport-layer segment
• Ht used by transport layer protocol to
application
transport
network
link
physical
destination
application
transport
network
link
physical
Transport-layer protocol transfers M (e.g., reliably) from one
process to another, using services of network layer
Ht M
Application exchanges messages to implement some
application service using services of transport layer
M

Socket
▪ A socket is a software interface between the transport layer and the
application layer.
▪ The transport layer offers a set of services to the application layer.
▪ The socket provides the abstraction to access these services.

Transport services and protocols
● provide logical communication between
application processes running on different
hosts
● Logical communication:
● from an application’s perspective, the
hosts running the processes were directly
connected;
● in reality, the hosts may be on opposite
sides of the planet, connected via
numerous routers and a wide range of link
types.
● Application processes use the logical
communication provided by the transport
layer to send messages to each other, free
mobile network
home network
enterprise
network
local or
regional
ISP
datacenter
network
content
provider
network
application
transport
network
data link
physical
application
transport
network
data link
physical
l
o
g
i
c
a
l
e
n
d
-
e
n
d
tr
a
n
s

▪ The IP service model is a best-effort delivery service. This means that
IP makes its “best effort” to deliver segments between communicating
hosts, but it makes no guarantees.
▪ does not guarantee segment delivery
▪ does not guarantee orderly delivery of segments
▪ does not guarantee the integrity of the data in the segments.
Network layer service

Wake up transport layer designer
➢ Don’t care about order
➢ Don’t care about packet loss
➢ Don’t care delay
➢ Don’t care congestions
Network layer just want sample life
Do those thing by yourself within transport layer
Network layer are a set of routers

Loading…
Transport vs. network layer services and protocols
● network layer: logical
communication between
hosts
● transport layer: logical
communication between
processes
• relies on, enhances, network
layer services
household analogy:
12 kids in Ann’s house
sending letters to 12 kids in
Bill’s house:
● hosts = houses
● processes = kids
● app messages = letters in
envelopes
● transport protocol = Ann and
Bill who demux to in-house
siblings

Transport services and protocols
mobile network
home network
enterprise
network
local or
regional
ISP
datacenter
network
content
provider
network
application
transport
network
data link
physical
application
transport
network
data link
physical
l
o
g
i
c
a
l
e
n
d
-
e
n
d
tr
a
n
s
● transport protocols actions in end
systems:
● segments : application messages
may need to be broken into smaller
chunks. The transport layer attaches
a header to each chunk, which
typically contains information such
as, the sending and receiving
application ports.
• sender: breaks application messages into
segments, passes to network layer
• receiver: reassembles segments into
messages, passes to application layer

Why segment
Your real task
Your expectation

Why segment
Why we need segment?
▪ Fit the pipe
▪ Packet loss
▪ Retransmission
What are the problems can be caused by segment?
▪ Orders of arrival
▪ Dissemble and assemble

physical
link
network (IP)
application
physical
link
network (IP)
application
transport
Transport Layer Actions
Sender:
app. msg
● is passed an application-
layer message
● determines segment
header fields values
● creates segment
● passes segment to IP
transport
Th
Th app. msg

physical
link
network (IP)
application
physical
link
network (IP)
application
transport
Transport Layer Actions
transport
Receiver:
app. msg ● extracts application-layer
message
● checks header values
● receives segment from IP
Th app. msg
● demultiplexes message up
to application via socket

Two principal Internet transport protocols
mobile network
home network
enterprise
network
local or
regional
ISP
datacenter
network
content
provider
network
application
transport
network
data link
physical
application
transport
network
data link
physical
l
o
g
i
c
a
l
e
n
d
-
e
n
d
tr
a
n
s
● TCP: Transmission Control
Protocol
• reliable, in-order delivery
• congestion control
• flow control
• connection setup
● UDP: User Datagram Protocol
• unreliable, unordered delivery
• no-frills extension of “best-effort” IP
● services not available:

TCP/UDP
▪ The most fundamental responsibility of UDP and TCP is to extend IP’s
delivery service between two end systems to a delivery service between
two processes running on the end systems.
▪ Extending host-to-host delivery to process-to-process delivery is called
transport-layer multiplexing and demultiplexing.
▪ UDP and TCP also provide integrity checking by including error
detection fields in their segments’ headers. These two minimal
transport-layer services—process-to-process data delivery and error
checking—are the only two services that UDP provides.

Multiplexing and demultiplexing

transport
physical
link
network transport
application
physical
link
network
transport
application
physical
link
network
HTTP
server
client
HTTP
msg

transport
physical
link
network transport
application
physical
link
network
transport
application
physical
link
network
HTTP
server
client
HTTP msg
Ht
HTTP msg

transport
physical
link
network transport
application
physical
link
network
transport
application
physical
link
network
HTTP
server
client
HTTP
msg
H
t
HTTP
msg
Ht
H
n
HTTP
msg

transport
physical
link
network transport
application
physical
link
network
transport
application
physical
link
network
HTTP
server
client
HTTP msg
Ht
Hn

transport
physical
link
network transport
application
physical
link
network
transport
application
physical
link
network
HTTP
server
client
1
client
2
P-
client1
P-
client2

Multiplexing/demultiplexing on highway

Loading…
Multiplexing/demultiplexing
proces
s
socket
use header info to deliver
received segments to correct
socket
demultiplexing at receiver:
transport
application
physical
link
network
P2
P1
transport
application
physical
link
network
P4
transport
application
physical
link
network
P3
handle data from multiple
sockets, add transport header (later
used for demultiplexing)
multiplexing at sender:

How demultiplexing works
● host receives IP datagrams
• each datagram has source IP
address, destination IP address
• each datagram carries one
transport-layer segment
• each segment has source,
destination port number
● host uses IP addresses & port
numbers to direct segment to
appropriate socket
source port # dest port #
32 bits
application
data
(payload)
other header fields
TCP/UDP segment format

32 bits
application
data
(payload)
other header fields
• Each port number is a 16-bit
number, ranging from 0 to 65535.
• The port numbers ranging from 0
to 1023 are called well-known
port numbers and are restricted,
which means that they are
reserved for use by well-known
application protocols
• When develop a new application,
we must assign the application a
port number.
2^16-1=65535
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

32 bits
application
data
(payload)
other header fields

UDP: Connectionless demultiplexing
● when creating datagram to send into UDP socket, must specify
• destination IP address
• destination port #

Connectionless demultiplexing
when receiving host receives UDP segment:
• checks destination port # in segment
• directs UDP segment to socket with that port #
IP/UDP datagrams with same dest. port #, but different source IP
addresses and/or source port numbers will be directed to same socket at
receiving host

Connectionless demultiplexing: an example
DatagramSocket serverSocket
= new DatagramSocket(6428);
transport
application
physical
link
network
P3
transport
application
physical
link
network
P1
transport
application
physical
link
network
P4
DatagramSocket mySocket1 =
new DatagramSocket (5775);
DatagramSocket mySocket2 =
new DatagramSocket (9157);
source port: 9157
dest port: 6428
source port: 6428
dest port: 9157
source port: ?
dest port: ?
source port: ?
dest port: ?

TCP:Connection-oriented demultiplexing
● TCP socket identified by 4-tuple:
• source IP address
• source port number
• dest IP address
• dest port number

Connection-oriented demultiplexing
● demux: receiver uses all four values (4-tuple) to direct
segment to appropriate socket
● The TCP server application has a “welcoming socket,”
that waits for connection establishment requests from
TCP clients on port number 12000.
● The TCP client creates a socket and sends a connection
establishment request segment with the lines:
clientSocket.connect((serverName,12000))

Connection-oriented demultiplexing
● server may support many simultaneous TCP sockets:
• each socket identified by its own 4-tuple:
• (1) the source port number in the segment,
• (2) the IP address of the source host,
• (3) the destination port number in the segment,
• (4) its own IP address
• each socket associated with a different connecting client

Connection-oriented demultiplexing: example
transport
application
physical
link
network
P1
transport
application
physical
link
P4
transport
application
physical
link
network
P2
host: IP address A
host: IP address C
network
P6
P5
P3
source IP,port: A,9157
dest IP, port: B,80
source IP,port: B,80
dest IP,port: A,9157 source IP,port: C,5775
dest IP,port: B,80
source IP,port: C,9157
dest IP,port: B,80
server: IP address B
Three segments, all destined to IP address: B,
dest port: 80 are demultiplexed to different sockets

Question
Consider a TCP connection between Host A and Host B.
1. What are the source and destination port
numbers for the segments traveling from Host B to
Host A?
2. What are the IP addresses in the network-layer
datagrams carrying above transport-layer segments

Summary
● Multiplexing, demultiplexing: based on segment, datagram
header field values
● UDP: demultiplexing using destination port number (only)
● TCP: demultiplexing using 4-tuple: source and destination IP
addresses, and port numbers
● Multiplexing/demultiplexing happen at all layers

Connectionless transport: UDP
Chapter 3.3

Connectionless transport: UDP
▪ Connectionless transport: UDP
▪ UDP sender/receiver actions
▪ UDP segment format
▪ Internet checksum

UDP: User Datagram Protocol
● “best effort” service,
● UDP segments may be:
• lost
• delivered out-of-order to app
● connectionless:
• no handshaking between UDP sender, receiver
• each UDP segment handled independently of others
Why we need this un-reliable protocol?

● no connection establishment (which can add RTT delay)
● simple: no connection state at sender, receiver
● small header size
● no congestion control
● UDP can blast away as fast as desired!
● can function in the face of congestion
Why is there a UDP?

● UDP use:
● streaming multimedia apps (loss tolerant, rate sensitive)
● DNS
● SNMP
● HTTP/3
● if reliable transfer needed over UDP (e.g., HTTP/3):
● add needed reliability at application layer
● add congestion control at application layer

UDP: User Datagram Protocol [RFC 768]
https://www.rfc-editor.org/rfc/rfc768

Read RFC 768 and answer following questions
▪ If source UDP port number not used, what is the value in it?
▪ What is the minimum length of UDP ?
▪ What is protocol number of UDP in IP?

SNMP
server
SNMP
client
transport
(UDP)
physical
link
network (IP)
application
UDP: Transport Layer Actions
transport
(UDP)
physical
link
network (IP)
application

SNMP
server
SNMP
client
transport
(UDP)
physical
link
network (IP)
application
transport
(UDP)
physical
link
network (IP)
application
UDP sender actions:
SNMP msg
● is passed an application-
layer message
● determines UDP segment
header fields values
● creates UDP segment
● passes segment to IP
UDPh
UDPh SNMP msg

SNMP
server
SNMP
client
transport
(UDP)
physical
link
network (IP)
application
transport
(UDP)
physical
link
network (IP)
application
UDP receiver actions:
SNMP msg
● extracts application-layer
message
● checks UDP checksum
header value
● receives segment from IP
UDPh SNMP msg
● demultiplexes message up
to application via socket

UDP segment header
32 bits
application
data
(payload)
UDP segment format
length checksum
length, in bytes of UDP
segment, including
header
data to/from application
layer
Let’s see a Wireshark captured real segment

Error detection question
▪ Reciever:1001001
▪ What is the data sent by sender?
▪ Sender: 1001101?
▪ Sender: 1001001?

UDP checksum
Transmitted: 5 6 11
Goal: detect errors (i.e., flipped bits) in transmitted segment
Received: 4 6 11
1st number 2nd number sum
receiver-computed
checksum
sender-computed
checksum (as received)
=

UDP checksum
sender:
● treat contents of UDP segment (including UDP header fields and IP
addresses) as sequence of 16-bit integers
● checksum: addition (one’s complement sum) of segment content
● checksum value put into UDP checksum field

UDP checksum
receiver:
● compute checksum of received segment
● check if computed checksum equals checksum field value:
• Not equal - error detected
• Equal - no error detected. But maybe errors nonetheless? More later ….

Internet checksum: an example
example: add two 16-bit integers
sum
checksum
Note: when adding numbers, a carryout from the most significant bit needs to be
added to the result
* Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
wraparound
1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

Internet checksum: weak protection!
example: add two 16-bit integers
sum
checksum
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
wraparound
1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
0 1
1 0
Even though
numbers have
changed (bit
flips), no change
in checksum!

Summary: UDP
● “no frills” protocol:
• segments may be lost, delivered out of order
• best effort service: “send and hope for the best”
● UDP has its plusses:
• no setup/handshaking needed (no RTT incurred)
• can function when network service is compromised
• helps with reliability (checksum)
● build additional functionality on top of UDP in application layer
(e.g., HTTP/3)

Principles of reliable data transfer
▪ Chapter 3.4

sending
process
data
receiving
process
data
reliable channel
application
transport
reliable service abstraction

sending
process
data
receiving
process
data
application
transport
reliable service implementation
unreliable channel
network
transport
sender-side of
reliable data
transfer protocol
receiver-side
of reliable data
transfer protocol
sending
process
data
receiving
process
data
reliable channel
application
transport
reliable service abstraction

sending
process
data
receiving
process
data
application
transport
unreliable channel
network
transport
sender-side of
reliable data
transfer protocol
receiver-side
of reliable data
transfer protocol
Complexity of reliable data
transfer protocol will depend
(strongly) on characteristics of
unreliable channel (lose,
corrupt, reorder data?)

sending
process
data
receiving
process
data
application
transport
unreliable channel
network
transport
sender-side of
reliable data
transfer protocol
receiver-side
of reliable data
transfer protocol
Sender, receiver do not know
the “state” of each other, e.g.,
was a message received?
● unless communicated via a
message

rdt1.0: reliable transfer over a reliable
channel
● underlying channel perfectly reliable
• no bit errors
• no loss of packets
packet = make_pkt(data)
udt_send(packet)
rdt_send(data)
extract (packet,data)
deliver_data(data)
rdt_rcv(packet)
Wait for
call from
below
receiver
● separate FSMs for sender, receiver:
• sender sends data into underlying channel
• receiver reads data from underlying channel
sender
Wait for
call from
above

rdt2.0: channel with bit errors
● underlying channel may flip bits in packet
• checksum (e.g., Internet checksum) to detect bit errors
● the question: how to recover from errors?
How do humans recover from “errors” during
conversation?

How do humans recover from “errors”

rdt2.0: channel with bit errors
● underlying channel may flip bits in packet
• checksum to detect bit errors
● the question: how to recover from errors?
• acknowledgements (ACKs): receiver explicitly tells sender that pkt
received OK
• negative acknowledgements (NAKs): receiver explicitly tells sender
that pkt had errors
• sender retransmits pkt on receipt of NAK
stop and wait
sender sends one packet, then waits for receiver response

rdt2.0 has a fatal flaw!
what happens if ACK/NAK corrupted?
● sender doesn’t know what happened at receiver!
● can’t just retransmit: possible duplicate
Ack: 101
NAK: 010
Ack: 101→010 →000
NAK: 010 →101 →000
Solution to handle corrupted ACK/NAK
• Sender resends the current data packet when it receives a
garbled ACK or NAK

rdt2.0 has a fatal flaw!
what happens if ACK/NAK
corrupted?
● sender doesn’t know what
happened at receiver!
● can’t just retransmit: possible
duplicate
handling duplicates:
● sender retransmits current pkt if
ACK/NAK corrupted
● sender adds sequence number to
each pkt
● receiver discards (doesn’t
deliver up) duplicate pkt

rdt2.1: discussion
sender:
● seq # added to pkt
● two seq. #s (0,1) will suffice.
Why?
● must check if received
ACK/NAK corrupted
● twice as many states
• state must “remember” whether
“expected” pkt should have seq # of
0 or 1
receiver:
● must check if received packet
is duplicate
• state indicates whether 0 or 1 is
expected pkt seq #
● note: receiver can not know if
its last ACK/NAK received
OK at sender

rdt2.2: a NAK-free protocol
● same functionality as rdt2.1, using ACKs only
● instead of NAK, receiver sends ACK for last pkt received OK
• receiver must explicitly include seq # of pkt being ACKed
● duplicate ACK at sender results in same action as NAK:
retransmit current pkt
As we will see, TCP uses this approach to be NAK-
free

Questions
▪ How to detect packet loss ?
▪ How to handle packet loss ?

rdt3.0: channels with errors and loss
New channel assumption: underlying channel can also lose
packets (data, ACKs)
• checksum, sequence #s, ACKs, retransmissions will be of help …
but not quite enough
Q: How do humans handle lost sender-to-
receiver words in conversation?

rdt3.0: channels with errors and loss
Approach: sender waits “reasonable” amount of time for ACK
● retransmits if no ACK received in this time
● if pkt (or ACK) just delayed (not lost):
• retransmission will be duplicate, but seq #s already handles this!
• receiver must specify seq # of packet being ACKed
timeout
● use countdown timer to interrupt after “reasonable” amount of
time

rdt3.0 in action
sender receiver
rcv pkt1
rcv pkt0
send ack0
send ack1
send ack0
rcv ack0
send pkt0
send pkt1
rcv ack1
send pkt0
rcv pkt0
pkt0
pkt0
pkt1
ack1
ack0
ack0
(a) no loss
sender receiver
rcv pkt1
rcv pkt0
send ack0
send ack1
send ack0
rcv ack0
send pkt0
send pkt1
rcv ack1
send pkt0
rcv pkt0
pkt0
pkt0
ack1
ack0
ack0
(b) packet loss
pkt1
X
loss
pkt1
timeout
resend pkt1

rdt3.0 in action
rcv pkt1
send ack1
(detect duplicate)
pkt
1
sender receiver
rcv pkt1
rcv pkt0
send ack0
send ack1
send ack0
rcv ack0
send pkt0
send pkt1
rcv ack1
send pkt0
rcv pkt0
pkt0
pkt0
ack1
ack0
ack0
(c) ACK loss
ack1
X
loss
pkt1
timeout
resend pkt1
rcv pkt1
send ack1
(detect duplicate)
pkt1
sender receiver
rcv pkt1
send ack0
rcv ack0
send pkt1
send pkt0
rcv pkt0
pkt0
ack0
(d) premature timeout/ delayed ACK
pkt1
timeout
resend pkt1
ack1
ack1
send ack1
send pkt0
rcv ack1
pkt0
rcv pkt0
send ack0
ack0
pkt1
(ignore)
rcv ack1

Performance of rdt3.0 (stop-and-wait)
● example: 1 Gbps link, 15 ms prop. delay, 8000 bit packet
● U sender: utilization – fraction of time sender busy sending
Dtrans
=
L
R
8000 bits
109 bits/sec
= = 8 microsecs
• time to transmit packet into channel:

rdt3.0: stop-and-wait operation
first packet bit transmitted, t = 0
sender receive
r
RTT
first packet bit arrives
last packet bit arrives, send
ACK
ACK arrives, send next
packet, t = RTT + L / R

Loading…
rdt3.0: stop-and-wait operation
sender receive
r
Usen
der
=
L /
R
RT
T RTT
L/R
+ L /
R
= 0.00027
=
.008
30.008
● rdt 3.0 protocol performance stinks!
● Protocol limits performance of underlying infrastructure (channel)

Next class
▪ Pipeline protocol
▪ Improve the efficiency
▪ Go Back N
▪ Selective repeat

Network Transports layers and Transport Networks

More Related Content

Similar to Network Transports layers and Transport Networks (20)

Recently uploaded (20)

Network Transports layers and Transport Networks