CS-324-6-3 (1).pdf

UNIT-06-03
• Session Layer, Design issues, remote procedure call.
• Presentation Layer, Design issues, Data compression techniques,
cryptography.
• Application Layer - File Transfer, Access and Management, Electronic
mail, Virtual Terminals, Other applications, Example Networks -
Internet and Public Networks.

Introduction
• Network applications are the raisons d'etre of a computer network.
• If we couldn't conceive of any useful applications, there wouldn't be any need to
design networking protocols to support them.
• But over the past thirty years, many people have devised numerous ingenious
and wonderful networking applications.
• These applications include the classic text –based applications that became
popular in the 1980s, including remote access to computers, electronic mail, file
transfers, newsgroups, and chat.
• But they also include more recently conceived multimedia applications, such as
the World Wide Web, Internet telephony, video conferencing, and audio and
video on demand.

Applications
• e-mail
• web
• text messaging
• remote login
• P2P file sharing
• multi-user network games
• streaming stored video (YouTube, Hulu, Netflix)
• voice over IP (e.g., Skype)
• real-time video conferencing (e.g. zoom)
• social networking
• search

Application-Layer Protocols
• Network applications run on end systems
• They depend on the network to provide a service
• … but cannot run software on the network elements
• Network applications run on multiple machines
• Different end systems communicate with each other
• Software is often written by multiple parties
• Leading to a need to explicitly define a protocol
• Types of messages (e.g., requests and responses)
• Message syntax (e.g., fields, and how to delineate)
• Semantics of the fields (i.e., meaning of the information)
• Rules for when and how a process sends messages
application
transport
network
data link
physical
application
transport
network
data link
physical
application
transport
network
data link
physical

Application vs. Application-Layer Protocols
• Application-layer protocol is just one piece
• Defining how the end hosts communicate
• Example: World Wide Web
• HyperText Transfer Protocol is the protocol
• But the Web includes other components, such as document formats (HTML),
Web browsers, servers, …
• Example: electronic mail
• Simple Mail Transfer Protocol (SMTP) is the protocol
• But e-mail includes other components, such as mail servers, user mailboxes,
mail readers

Protocols Tailored to the Application
• Telnet: interacting with account on remote machine
• Client simply relays user keystrokes to the server
• … and server simply relays any output to the client
• TCP connection persists for duration of the login session
• Network Virtual Terminal format for transmitting ASCII data, and control
information (e.g., End-of-Line delimiter)
• FTP: copying files between accounts
• Client connects to remote machine, “logs in, and issues commands for
transferring files to/from the account
• … and server responds to commands and transfers files
• Separate TCP connections for control and data
• Control connection uses same Network Virtual Terminal format as Telnet

Protocols Tailored to the Application
• SMTP: sending e-mail to a remote mail server
• Sending mail server transmits e-mail message to a mail server running on a
remote machine
• Each server in the path adds its identifier to the message
• Single TCP connection for control and data
• SMTP replaced the earlier use of FTP for e-mail
• HTTP: satisfying requests based on a global URL
• Client sends a request with method, URL, and meta-data
• … and the server applies the request to the resource and returns the response,
including meta-data
• Single TCP connection for control and data

Comparing the Protocols
• Commands and replies
• Telnet sends commands in binary, whereas the other protocols are text based
• Many of the protocols have similar request methods and response codes
• Data types
• Telnet, FTP, and SMTP transmit text data in standard U.S. 7-bit ASCII
• FTP also supports transfer of data in binary form
• SMTP uses MIME standard for sending non-text data
• HTTP incorporates some key aspects of MIME (e.g., classification of data formats)

Comparing the Protocols (Continued)
• Transport
• Telnet, FTP, SMTP, and HTTP all depend on reliable transport protocol
• Telnet, SMTP, and HTTP use a single TCP connection
• … but FTP has separate control and data connections
• State
• In Telnet, FTP, and SMTP, the server retains information about the session
with the client
• E.g., FTP server remembers client’s current directory
• In contrast, HTTP servers are stateless

Reflecting on Application-Layer Protocols
• Protocols are tailored to the applications
• Each protocol is customized to a specific need
• Protocols have many key similarities
• Each new protocol was influenced by the previous ones
• New protocols commonly borrow from the older ones
• Protocols depend on same underlying substrate
• Ordered reliable stream of bytes (i.e., TCP)
• Domain Name System (DNS)
• Relevance of the protocol standards process
• Important for interoperability across implementations
• Yet, not necessary if same party writes all of the software
• …which is increasingly common (e.g., P2P software)

Client-server architecture
server:
• always-on host
• permanent IP address
• data centers for scaling
clients:
• communicate with server
• may be intermittently connected
• may have dynamic IP addresses
• do not communicate directly with each other
• examples: HTTP, IMAP, FTP
client/server

mobile network
home network
enterprise
network
national or global ISP
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

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
client process: process that initiates
communication
server process: process that waits to be
contacted
 aside: applications with P2P architectures
have client processes & server processes
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
Internet
controlled
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
gaia.cs.umass.edu web server:
• IP address: 128.119.245.12
• port number: 80
A: no, many processes can be running on
same host

App-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
• allows for interoperability
• e.g., HTTP, SMTP
proprietary protocols:
• e.g., Skype, zoom, google meet

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
e-mail
Web documents
real-time audio/video
stored 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
few kbps up
elastic
time sensitive
no
no
no
yes, 100’s
msec
yes, few secs
yes, 100’s
msec
yes and no

Internet apps: application, transport protocols
application
e-mail
remote terminal access
Web
file transfer
streaming multimedia
Internet telephony
application
layer protocol
SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
HTTP (e.g., YouTube),
RTP [RFC 1889]
SIP, RTP, proprietary
(e.g., Skype)
underlying
transport protocol
TCP
TCP
TCP
TCP
TCP or UDP
TCP or UDP

Securing TCP
TCP & UDP
• no encryption
• cleartext passwds sent into socket
traverse Internet in cleartext
SSL
• provides encrypted TCP connection
• data integrity
• end-point authentication
SSL is at application layer
• Apps use SSL libraries, which “talk” to
TCP
SSL socket API
• cleartext passwds sent into
socket traverse Internet
encrypted

E-Mail Message
• E-mail messages have two parts
• A header, in 7-bit U.S. ASCII text
• A body, also represented in 7-bit U.S. ASCII text
• Header
• Lines with “type: value”
• “To: jrex@princeton.edu”
• “Subject: Go Tigers!”
• Body
• The text message
• No particular structure
or meaning
header
body
blank
line

E-Mail Message Format (RFC 822)
• E-mail messages have two parts
• A header, in 7-bit U.S. ASCII text
• A body, also represented in 7-bit U.S. ASCII text
• Header
• Series of lines ending in carriage return and line feed
• Each line contains a type and value, separated by “:”
• E.g., “To: kd@nith.ac.in” and “Subject: CS-324 midterm exam”
• Additional blank line before the body begins
• Body
• Series of text lines with no additional structure/meaning
• Conventions arose over time (e.g., e-mail signatures)

Limitation: Sending Non-Text Data
• E-mail body is 7-bit U.S. ASCII
• What about non-English text?
• What about binary files (e.g., images and executables)?
• Solution: convert non-ASCII data to ASCII
• Base64 encoding: map each group of three bytes into four printable U.S.-ASCII
characters
• Uuencode (Unix-to-Unix Encoding) was widely used
• Limitation: filename is the only cue to the data type
begin 644 cat.txt
#0V%T
`
end

Limitation: Sending Multiple Items
• Users often want to send multiple pieces of data
• Multiple images, powerpoint files, or e-mail messages
• Yet, e-mail body is a single, uninterpreted data chunk
• Example: e-mail digests
• Encapsulating several e-mail messages into one aggregate messages (i.e., a
digest)
• Commonly used on high-volume mailing lists
• Conventions arose for how to delimit the parts
• E.g., well-known separator strings between the parts
• Yet, having a standard way to handle this is better

Multipurpose Internet Mail Extensions
• Additional headers to describe the message body
• MIME-Version: the version of MIME being used
• Content-Type: the type of data contained in the message
• Content-Transfer-Encoding: how the data are encoded
• Definitions for a set of content types and subtypes
• E.g., image with subtypes gif and jpeg
• E.g., text with subtypes plain, html, and richtext
• E.g., application with subtypes postscript and msword
• E.g., multipart for messages with multiple data types
• A way to encode the data in ASCII format
• Base64 encoding, as in uuencode/uudecode
• uuencode/decode became popular for sending binary (and especially compressed) files by
email and posting to Usenet newsgroups, etc. It has now been largely replaced by MIME and
yEnc.

Example: E-Mail Message Using MIME
From: kd@nith.ac.in
To: fgrecord@gatemail.com
Subject: picture of logo
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
type and subtype
method used
to encode data
MIME version
encoded data

Distribution of Content Types
• Content types in e-mail archive
• Searched on “Content-Type”, not case sensitive
• Extracted the value field, and counted unique types
• At UNIX command line:
grep -i Content-Type * | cut -d" " -f2 | sort | uniq -c | sort –nr
• Out of 44343 matches
• 25531: text/plain
• 7470: multipart to send attachments
• 4230: text/html
• 759: application/pdf
• 680: application/msword
• 479: application/octet-stream
• 292: image (mostly jpeg, and some gif, tiff, and bmp)

E-Mail Addresses
• Components of an e-mail address
• Local mailbox (e.g., jrex or bob.flower)
• Domain name (e.g., cs.princeton.edu)
• Domain name is not necessarily the mail server
• Mail server may have longer/cryptic name
• E.g., cs.princeton.edu vs. mail.cs.princeton.edu
• Multiple servers may exist to tolerate failures
• E.g., cnn.com vs. atlmail3.turner.com and nycmail2.turner.com
• Identifying the mail server for a domain
• DNS query asking for MX records (Mail eXchange)
• E.g., nslookup –q=mx cs.princeton.edu
• Then, a regular DNS query to learn the IP address

Mail Servers and User Agents
• Mail servers
• Always on and always accessible
• Transferring e-mail to and from other servers
• User agents
• Sometimes on and sometimes accessible
• Intuitive interface for the user
user
agent
mail server
user
agent
mail server
user
agent
user
agent

SMTP Store-and-Forward Protocol
• Messages sent through a series of servers
• A server stores incoming messages in a queue
• … to await attempts to transmit them to the next hop
• If the next hop is not reachable
• The server stores the message and tries again later
• Each hop adds its identity to the message
• By adding a “Received” header with its identity
• Helpful for diagnosing problems with e-mail
user
agent
mail server
user
agent
mail server

Example With Received Header
Return-Path: <casado@cs.stanford.edu>
Received: from ribavirin.CS.Princeton.EDU (ribavirin.CS.Princeton.EDU [128.112.136.44])
by newark.CS.Princeton.EDU (8.12.11/8.12.11) with SMTP id k04M5R7Y023164
for <jrex@newark.CS.Princeton.EDU>; Wed, 4 Jan 2006 17:05:37 -0500 (EST)
Received: from bluebox.CS.Princeton.EDU ([128.112.136.38])
by ribavirin.CS.Princeton.EDU (SMSSMTP 4.1.0.19) with SMTP id M2006010417053607946
for <jrex@newark.CS.Princeton.EDU>; Wed, 04 Jan 2006 17:05:36 -0500
Received: from smtp-roam.Stanford.EDU (smtp-roam.Stanford.EDU [171.64.10.152])
by bluebox.CS.Princeton.EDU (8.12.11/8.12.11) with ESMTP id k04M5XNQ005204
for <jrex@cs.princeton.edu>; Wed, 4 Jan 2006 17:05:35 -0500 (EST)
Received: from [192.168.1.101] (adsl-69-107-78-147.dsl.pltn13.pacbell.net [69.107.78.147])
(authenticated bits=0)
by smtp-roam.Stanford.EDU (8.12.11/8.12.11) with ESMTP id k04M5W92018875
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Wed, 4 Jan 2006 14:05:32 -0800
Message-ID: <43BC46AF.3030306@cs.stanford.edu>
Date: Wed, 04 Jan 2006 14:05:35 -0800
From: Martin Casado <casado@cs.stanford.edu>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: jrex@CS.Princeton.EDU
CC: Martin Casado <casado@cs.stanford.edu>
Subject: Using VNS in Class
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Multiple Server Hops
• Typically at least two mail servers
• Sending and receiving sides
• May be more
• Separate servers for key functions
• Spam filtering
• Virus scanning
• Servers that redirect the message
• From jrex@princeton.edu to jrex@cs.princeton.edu
• Messages to princeton.edu go through extra hops
• Electronic mailing lists
• Mail delivered to the mailing list’s server
• … and then the list is expanded to each recipient

Electronic Mailing Lists
• Community of users reachable by one address
• Allows groups of people to receive the messages
• Exploders
• Explode a single e-mail message into multiple messages
• One copy of the message per recipient
• Handling bounced messages
• Mail may bounce for several reasons
• E.g., recipient mailbox does not exist; resource limits
• E-mail digests
• Sending a group of mailing-list messages at once
• Messages delimited by boundary strings
• … or transmitted using multiple/digest format

Simple Mail Transfer Protocol
• Client-server protocol
• Client is the sending mail server
• Server is the receiving mail server
• Reliable data transfer
• Built on top of TCP (on port 25)
• Push protocol
• Sending server pushes the file to the receiving server
• … rather than waiting for the receiver to request it
user
agent
mail server
user
agent
mail server
SMTP SMTP
access
protocol

Simple Mail Transfer Protocol (Cont.)
• Command/response interaction
• Commands: ASCII text
• Response: three-digit status code and phrase
• Synchronous
• Sender awaits response from a command
• … before issuing the next command
• Though pipelining of commands was added later
• Three phases of transfer
• Handshaking (greeting)
• Transfer of messages
• Closure

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

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

Extended SMTP
• Formally SMTP is defined in RFC 821 as amended by RFC 1123. Modern clients use the protocol
known as ESMTP and is defined in RFC 2821.
• When sending emails, we use two types of ‘greetings’, HELO and EHLO. Most clients (e.g. Outlook,
Eudora Mail) will use EHLO.
• EHLO invokes an Extended SMTP (ESMTP). We use it to enable more options and to see which
extensions are supported by the server. However, if the server fails to respond to the EHLO
command, the client can use HELO. HELO will always work.

Try SMTP For Yourself
• Running SMTP
• Run “telnet servername 25” at UNIX prompt
• See 220 reply from server
• Enter HELO, MAIL FROM, RCPT TO, DATA commands
• Thinking about spoofing?
• Very easy
• Just forge the argument of the “FROM” command
• … leading to all sorts of problems with spam
• Spammers can be even more clever
• E.g., using open SMTP servers to send e-mail
• E.g., forging the “Received” header

Retrieving E-Mail From the Server
• Server stores incoming e-mail by mailbox
• Based on the “From” field in the message
• Users need to retrieve e-mail
• Asynchronous from when the message was sent
• With a way to view the message and reply
• With a way to organize and store the messages
• In the olden days…
• User logged on to the machine where mail was delivered
• Users received e-mail on their main work machine

Influence of PCs on E-Mail Retrieval
• Separate machine for personal use
• Users did not want to log in to remote machines
• Resource limitations
• Most PCs did not have enough resources to act as a full-fledged e-mail server
• Intermittent connectivity
• PCs only sporadically connected to the network
• … due to dial-up connections, and shutting down of PC
• Too unwieldy to have sending server keep trying
• Led to the creation of Post Office Protocol (POP)

Post Office Protocol (POP)
• POP goals
• Support users with intermittent network connectivity
• Allow them to retrieve e-mail messages when connected
• … and view/manipulate messages when disconnected
• Typical user-agent interaction with a POP server
• Connect to the server
• Retrieve all e-mail messages
• Store messages on the user’s PCs as new messages
• Delete the messages from the server
• Disconnect from the server
• User agent still uses SMTP to send messages

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

Limitations of POP
• Does not handle multiple mailboxes easily
• Designed to put user’s incoming e-mail in one folder
• Not designed to keep messages on the server
• Instead, designed to download messages to the client
• Poor handling of multiple-client access to mailbox
• Increasingly important as users have home PC, work PC, laptop, cyber café
computer, friend’s machine, etc.
• High network bandwidth overhead
• Transfers all of the e-mail messages, often well before they are read (and they
might not be read at all!)

Interactive Mail Access Protocol (IMAP)
• Supports connected and disconnected operation
• Users can download message contents on demand
• Multiple clients can connect to mailbox at once
• Detects changes made to the mailbox by other clients
• Server keeps state about message (e.g., read, replied to)
• Access to MIME parts of messages & partial fetch
• Clients can retrieve individual parts separately
• E.g., text of a message without downloading attachments
• Multiple mailboxes on the server
• Client can create, rename, and delete mailboxes
• Client can move messages from one folder to another
• Server-side searches
• Search on server before downloading messages

Web-Based E-Mail
• User agent is an ordinary Web browser
• User communicates with server via HTTP
• E.g., Gmail, Yahoo mail, and Hotmail
• Reading e-mail
• Web pages display the contents of folders
• … and allow users to download and view messages
• “GET” request to retrieve the various Web pages
• Sending e-mail
• User types the text into a form and submits to the server
• “POST” request to upload data to the server
• Server uses SMTP to deliver message to other servers
• Easy to send anonymous e-mail (e.g., spam)

SMTP2GO
• Email technology and standards are constantly evolving.
• The main problem many people have with sending emails is that most sending
servers require you to always connect to the internet through the ISP that
provides the server.
• For mobile users this is often impossible.
• SMTP2GO allows you to send from any city or country, anywhere in the world, no
matter where you are or what device you’re using.

SMTP2GO
• SMTP2GO provides visual reports, which help users to understand real-time
responses of emails sent from user infrastructure.
• The solution helps users' emails stay away from blacklists and spam folders and
notifies them whenever it detects any problem in account such as an increase in
bounce rate.

SMTP2GO
Sending via SMTP
• SMTP server: mail.smtp2go.com
• SMTP port: 2525 (or 80, 25, 8025 or 587 if that doesn’t work).
• Username / Password: Turn on SMTP authentication and enter your account’s SMTP
username and SMTP password.
• Note: TLS/SSL is optional. TLS is available on the same ports. SSL is available on ports
465, 8465, and 443.
Sending via the API
• Generate an API key on the "Settings > API Keys" page in your control panel. Use the API
docs as a guide to generate code for sending emails.

Architectural
Overview
(a) A Web page (b) The page reached by clicking on
Department of Animal Psychology.

Architectural Overview
• The parts of the Web model.

The Client Side
• (a) A browser plug-in. (b) A helper application.

The Server Side
• A multithreaded Web server with a front end and processing
modules.

The Server Side
• A server farm.

The Server Side
(a) Normal request-reply message sequence.
(b) Sequence when TCP handoff is used.

URLs – Uniform Resource Locaters
• Some common URLs.

HTTP Methods
• The built-in HTTP request methods.

HTTP Methods
• The status code response groups.

HTTP Message Headers
• Some HTTP message headers.

Example HTTP
Usage
• The start of the output of
www.ietf.org/rfc.html.

HTML – HyperText Markup Language
(a) The HTML for a sample Web page. (b) The formatted page.
(b)

HTML
• A selection of common HTML tags. some can have
additional parameters.

Web and HTTP
• web page consists of objects
• object can be HTML file, JPEG image, Java applet, audio
file,…
• web page consists of base HTML-file which includes several
referenced objects
• each object is 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
PC running
Firefox browser
server
running
Apache Web
server
iphone running
Safari browser

HTTP overview
usesTCP:
• client initiatesTCP connection (creates
socket) to server, port 80
• server acceptsTCP 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/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
Key goal: decreased delay in multi-object HTTP requests

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

HTTP/2: mitigating HOL blocking
HTTP/2: objects divided into frames, frame transmission interleaved
client
server
GET O1
GET O2
GET O3
GET O4
O2
O4
object data requested
O1
O2
O3
O4
O2, O3, O4 delivered quickly, O1 slightly delayed
O3
O1

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

HTTP connections
non-persistent HTTP
• at most one object sent over TCP
connection
• connection then closed
• downloading multiple objects required
multiple connections
persistent HTTP
• multiple objects can be
sent over singleTCP
connection between client,
server

Non-persistent HTTP
suppose user enters URL:
1a. HTTP client initiatesTCP
connection to HTTP server
(process) at
www.someSchool.edu on port 80
2. HTTP client sends HTTP request
message (containing URL) intoTCP
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
(contains text,
references to 10
jpeg images)
www.someSchool.edu/someDepartment/home.index

Non-persistent HTTP
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 closesTCP 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:
• one RTT to initiate TCP connection
• one RTT for HTTP request and first few
bytes of HTTP response to return
• file transmission time
• non-persistent HTTP response time =
2RTT+ file transmission time
time to
transmit
file
initiate TCP
connection
RTT
request
file
RTT
file
received
time time

Persistent HTTP
non-persistent HTTP issues:
• requires 2 RTTs per object
• OS overhead for eachTCP connection
• browsers often open parallel TCP
connections to fetch referenced objects
persistent HTTP:
• 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

HTTP request message
• two types of HTTP messages: request, response
• HTTP request message:
• ASCII (human-readable format)
request line
(GET, POST,
HEAD commands)
header
lines
carriage return,
line feed at start
of line indicates
end of header lines
GET /index.html HTTP/1.1rn
Host: www-net.cs.umass.edurn
User-Agent: Firefox/3.6.10rn
Accept: text/html,application/xhtml+xmlrn
Accept-Language: en-us,en;q=0.5rn
Accept-Encoding: gzip,deflatern
Accept-Charset: ISO-8859-1,utf-8;q=0.7rn
Keep-Alive: 115rn
Connection: keep-alivern
rn
carriage return character
line-feed character

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
~
~ ~
~

Uploading form input
POST method:
• web page often includes form input
• input is uploaded to server in entity body
URL method:
• uses GET method
• input is uploaded in URL field of request line:
www.somesite.com/animalsearch?monkeys&banana

Method types
HTTP/1.0:
• GET
• POST
• HEAD
• asks server to leave requested
object out of response
HTTP/1.1:
• GET, POST, HEAD
• PUT
• uploads file in entity body to path
specified in URL field
• DELETE
• deletes file specified in the URL field

HTTP response message
status line
(protocol
status code
status phrase)
header
lines
data, e.g.,
requested
HTML file
HTTP/1.1 200 OKrn
Date: Sun, 26 Sep 2010 20:09:20 GMTrn
Server: Apache/2.0.52 (CentOS)rn
Last-Modified: Tue, 30 Oct 2007 17:00:02
GMTrn
ETag: "17dc6-a5c-bf716880"rn
Accept-Ranges: bytesrn
Content-Length: 2652rn
Keep-Alive: timeout=10, max=100rn
Connection: Keep-Alivern
Content-Type: text/html; charset=ISO-8859-
1rn
rn
data data data data data ...

HTTP response status codes
200 OK
• request succeeded, requested object later in this msg
301 Moved Permanently
• requested object moved, new location specified later in this msg (Location:)
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:

Trying out HTTP (client side)
1.Telnet to your Web server:
opens TCP connection to port 80
(default HTTP server port) at cis.poly.edu.
anything typed in sent
to port 80 at cis.poly.edu
telnet cis.poly.edu 80
2. type in a GET HTTP request:
GET /~ross/ HTTP/1.1
Host: cis.poly.edu
by typing this in (hit carriage
return twice), you send
this minimal (but complete)
GET request to HTTP server
3. look at response message sent by HTTP server!
(or use Wireshark to look at captured HTTP request/response)

User-server state: cookies
many Web sites use cookies
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 always access Internet from PC
• visits specific e-commerce site for first time
• when initial HTTP requests arrives at site,
site creates:
• unique ID
• entry in backend database for ID

Cookies: keeping “state”
client server
usual http response msg
usual http response msg
cookie file
one week later:
usual http request msg
cookie: 1678 cookie-
specific
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-
specific
action
access
ebay 8734
amazon 1678
backend
database

Cookies
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
 you may supply name and
e-mail to sites
aside
how to keep “state”:
 protocol endpoints: maintain state at
sender/receiver over multiple transactions
 cookies: http messages carry state

Web caches (proxy server)
• user sets browser:Web accesses via
cache
• browser sends all HTTP requests to
cache
• object in cache: cache returns
object
• else cache requests object from
origin server, then returns object
to client
goal: satisfy client request without involving origin server
client
proxy
server
client origin
server
origin
server

Web caching
• cache acts as both client and server
• server for original requesting client
• client to origin server
• typically cache is installed by ISP
(university, company, residential ISP)
whyWeb caching?
• reduce response time for client request
• reduce traffic on an institution’s access link
• Internet dense with caches: enables “poor”
content providers to effectively deliver
content (so too does P2P file sharing)

Caching example:
origin
servers
public
Internet
institutional
network
1 Gbps LAN
1.54 Mbps
access link
assumptions:
 avg object size: 100K bits
 avg request rate from browsers to origin
servers:15/sec
 avg data rate to browsers: 1.50 Mbps
 RTT from institutional router to any
origin server: 2 sec
 access link rate: 1.54 Mbps
consequences:
 LAN utilization (traffic intensity): 15%
 access link utilization = 99%
 total delay = Internet delay + access
delay + LAN delay
= 2 sec + minutes + usecs
problem!

assumptions:
servers:15/sec
 RTT from institutional router to any
origin server: 2 sec
consequences:
 LAN utilization: 15%
 total delay = Internet delay + access
delay + LAN delay
Caching example: access link
origin
servers
1.54 Mbps
access link
154 Mbps 154 Mbps
msecs
Cost: increased access link speed
9.9%
public
Internet
institutional
network
1 Gbps LAN

institutional
network
1 Gbps LAN
Caching example: install local cache
origin
servers
1.54 Mbps
access link
local web
cache
assumptions:
servers:15/sec
 RTT from institutional router to any origin server:
2 sec
consequences:
 LAN utilization: 15%
 total delay = Internet delay + access delay + LAN
delay
Cost: web cache (cheap!)
public
Internet

Caching example: install local cache
Calculating access link utilization, delay with cache:
• suppose cache hit rate is 0.4
• 40% requests satisfied at cache, 60% requests
satisfied at origin
origin
servers
1.54 Mbps
access link
 access link utilization:
 60% of requests use access link
 data rate to browsers over access link = 0.6*1.50 Mbps = .9 Mbps
 utilization = 0.9/1.54 = .58
 total delay
 = 0.6 * (delay from origin servers) +0.4 * (delay when
satisfied at cache)
 = 0.6 (2.01) + 0.4 (~msecs)
 = ~ 1.2 secs
 less than with 154 Mbps link
public
Internet
institutional
network
1 Gbps LAN
local web
cache
0.4 * 0.01 + 0.6 * 2.01 = 1.2 seconds
0.01 s – access time on the LAN
2.01 s- access time on LAN + Internet

Conditional GET
• Goal: don’t send object if cache has
up-to-date cached version
• no object transmission delay
• lower link utilization
• cache: 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

DNS: Domain Name System
people: many identifiers:
• SSN, name, passport #
Internet hosts, routers:
• IP address (32 bit) - used for
addressing datagrams
• “name”, e.g., cs.umass.edu -
used by humans
Q: how to map between IP
address and name, and vice
versa ?
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)
• note: core Internet function,
implemented as application-layer
protocol
• complexity at network’s “edge”

DNS: services, structure
Q: Why not centralize DNS?
 single point of failure
 traffic volume
 distant centralized database
 maintenance
DNS services:
 hostname-to-IP-address translation
 host aliasing
• canonical, alias names
 mail server aliasing
 load distribution
• replicated Web servers: many IP
addresses correspond to one
name
A: doesn‘t scale!
 Comcast DNS servers alone:
600B DNS queries/day
 Akamai DNS servers alone:
2.2T DNS queries/day

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

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
nyu.edu
DNS servers
umass.edu
DNS servers
yahoo.com
DNS servers
amazon.com
DNS servers
pbs.org
DNS servers Authoritative
…
… … …

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

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!
• 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)

Top-Level Domain, and authoritative servers
Top-Level Domain (TLD) servers:
 responsible for .com, .org, .net, .edu, .aero, .jobs, .museums, and all top-level
country domains, e.g.: .cn, .uk, .fr, .ca, .jp
 Network Solutions: authoritative registry for .com, .net TLD
 Educause: .edu TLD
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

DNS name resolution: iterated query
Example: host at engineering.nyu.edu
wants IP address for gaia.cs.umass.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
gaia.cs.umass.edu
root DNS server
local DNS server
dns.nyu.edu
1
2
3
4
5
6
authoritative DNS server
dns.cs.umass.edu
7
8
TLD DNS server

DNS name resolution: recursive query
requesting host at
engineering.nyu.edu
gaia.cs.umass.edu
root DNS server
local DNS server
dns.nyu.edu
1
2 3
4
5
6
authoritative DNS server
dns.cs.umass.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 gaia.cs.umass.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)
type=NS
 name is domain (e.g., foo.com)
 value is hostname of authoritative name
server for this domain
RR format: (name, value, type, ttl)
type=A
 name is hostname
 value is IP address
{name} {ttl} addr-class {type} address
host1.siterequest.com IN A 128.32.0.4
IN A 10.0.0.78
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
alias {ttl} addr-class {type} Canonical name
wip.siterequest.com IN CNAME host1.siterequest.com
type=MX
 value is name of SMTP mail
server associated with name

DNS records
DNS: distributed database storing resource records (RR)
RR format: (name, value, type, ttl)
type= SOA
 name is start of authority
 value includes
administrative
information about your
zone, as defined by the
domain name system
type=PTR (Pointer)
name Maps IP addresses to host names.
These records are used for reverse name
lookups.
name {ttl} addr-class PTR real name
7.0 IN PTR monet.Berkeley.Edu.
The example of a PTR record shown in Figure is used to set up
reverse pointers for the special IN-ADDR.ARPA domain.

• AAAA : IPv6 address record that maps a hostname to an IPv6 address.
• SPF : Sender Policy Framework (SPF) is a legacy record that is now generally
handled in the TXT record.
• TXT: Text record can be used for general information as well as Sender Policy
Information or other machine-readable information.

DNS lookup
https://www.dnsqueries.com/en/dns_lookup.php

Is my ip banned? Do i send spam? Is
my server used to send spam?
• This service checks if an IP address is listed in the Relay Black Lists (RBLs) used to
fight spam by antispam software.
• RBLs are a distributed system to track spammers and to fight actively spam.
• Actually many softwares use them to know if a particular mail message has been
sent from an ip address known to send spam.
• This tool currently supports the best Relay Black Lists around there and you can
find checks for all the RBLs used by Spamassassin on his spam fight activity.
• Clicking on the removal link you will be taken directly to the Black List's removal
tool.

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 bytes 2 bytes
DNS protocol messages
DNS query and reply messages, both have same format:
message header:
 identification: 16 bit # for query,
reply to query uses same #
 flags:
• query or reply
• recursion desired
• recursion available
• reply is authoritative

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 bytes 2 bytes
DNS query and reply messages, both have same format:
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

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
national or global ISP
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
us
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
us
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:
• time to send one copy: F/us
 client: each client must download
file copy
• min client download time: F/dmin
us
network
di
ui
F
 clients: as aggregate must download NF bits
• max upload rate (limiting max download rate) is us + Sui
time to distribute F
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
client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us
0
0.5
1
1.5
2
2.5
3
3.5
0 5 10 15 20 25 30 35
N
Minimum
Distribution
Time
P2P
Client-Server

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 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
 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)

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

Streaming stored video
1. video
recorded
(e.g., 30
frames/sec)
2. video
sent
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
time
variable
network
delay
client video
reception
constant bit
rate video
playout at client
client playout
delay
buffered
video
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

...
...
...
Streaming multimedia: DASH
“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 buffering
client
?

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

challenge: how to stream content (selected from millions of
videos) to hundreds of thousands of simultaneous users?
• 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)
• bring home: smaller number (10’s) of
larger clusters in POPs near access nets
• used by Limelight

 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

Internet host-host communication as a service
OTT challenges: coping with a congested Internet from the “edge”
 what content to place in which CDN node?
 from which CDN node to retrieve content? At which rate?
OTT: “over the top”

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 OS
controlled by
app developer
transport
application
physical
link
network
process
transport
application
physical
link
network
process
socket

Socket programming
Two socket types for two transport services:
 UDP: unreliable datagram
 TCP: reliable, byte stream-oriented
Application Example:
1. client reads a line of characters (data) from its keyboard and sends
data to server
2. server receives the data and converts characters to uppercase
3. server sends modified data to client
4. client receives modified data and displays line on its screen

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”)
between client and server processes

Client/server socket interaction: UDP
close
clientSocket
read datagram from
clientSocket
create socket:
clientSocket =
socket(AF_INET,SOCK_DGRAM)
Create datagram with serverIP 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

Example app: UDP client
from socket import *
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()
clientSocket.close()
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

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

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
 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”)
between client and server
processes
Application viewpoint

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

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

Example app: TCP server
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()
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)

CDN content access: a closer look
netcinema.com
KingCDN.com
1
1. Bob gets URL for video
http://netcinema.com/6Y7B23V
from netcinema.com web page
2
2. resolve http://netcinema.com/6Y7B23V
via Bob’s local DNS
netcinema’s
authoratative DNS
3
3. netcinema’s DNS returns CNAME for
http://KingCDN.com/NetC6y&B23V 4
5
6. request video from
KINGCDN server,
streamed via HTTP
KingCDN
authoritative DNS
Bob’s
local DNS
server
Bob (client) requests video http://netcinema.com/6Y7B23V
 video stored in CDN at http://KingCDN.com/NetC6y&B23V

Case study: Netflix
1
Bob manages
Netflix account
Netflix registration,
accounting servers
Amazon cloud
CDN
server
2
Bob browses
Netflix video
Manifest file,
requested
returned for
specific video
DASH server
selected, contacted,
streaming begins
upload copies of
multiple versions of
video to CDN servers
CDN
server
CDN
server
3
4

CS-324-6-3 (1).pdf

Recommended

Recommended

More Related Content

Similar to CS-324-6-3 (1).pdf

Similar to CS-324-6-3 (1).pdf (20)

Recently uploaded

Recently uploaded (20)

CS-324-6-3 (1).pdf