Chapter 1

Application Layer

1
1.1 Principles of network application
 At the core of network application development is writing programs
that run on different end system and communicate with each other
over the network.
 Example in web application there two distinct programs that
communicate with each other.

Web browser Web Server

 Another example is a peer to peer file sharing system

 When developing a network application the software must be written
to run on multiple end systems
 The program can be written in java or python

2
Network Application Architecture
• Application architecture is designed by the application developer and dictates
how the application is structured over the various end systems.
• When choosing, the developer can choose among the two predominant
architectural paradigms used in modern network application.

• Client server architecture and

• Peer to peer architecture
• Hybrid of client-server and P2P

3
Client-server architecture
server:
 always-on host
 permanent IP address
 server farms for scaling

clients:
 communicate with server
 may be intermittently
connected
client/server
 may have dynamic IP
addresses
 do not communicate
directly with each other

4
Often in client server
application, a single host server
is incapable of keeping up with
all the request from its clients.
 For example Facebook or
Google will quickly be
overwhelmed if it has only one
server handling all of its
requests.
 For this reason, a large
cluster of hosts- some times
referred as data centers are
often used to create a powerful
virtual server.

Fig. One of Google data center

5
Pure P2P architecture
 no always-on server
 arbitrary end systems directly
communicate
 peers are intermittently connected
and change IP addresses peer-peer
 They are not owned by internet
service providers
 They are simple desktop, laptop
controlled by users
 Highly scalable but difficult to
manage
 Peer to peer application examples
 Emule , bit torrent, internet
telephony

6
 Hybrid of client-server and P2P
Skype
 voice-over-IP P2P application
 centralized server: finding address of remote party:
 client-client connection: direct (not through server)
Instant messaging
 chatting between two users is P2P
 centralized service: client presence detection/location
• user registers its IP address with central server when it
comes online
• user contacts central server to find IP addresses of
buddies

7
Processes communicating
 Process: program running within a host.
 within same host, two processes communicate using inter-process
communication with rules governed by the end system’s operating
system.
 Processes in different hosts(with potentially different operating
system) communicate by exchanging messages across the computer
network.
 A sending process creates and sends messages into the network and
a receiving process receives these messages and possibly responds
by sending messages back.
 Client process: process that initiates communication
 Server process: process that waits to be contacted
 Note: applications with P2P architectures have client processes &
server processes
8
Sockets
 A process sends a message into and
received a message from the
network through a software host or host or
interface called sockets. server server

 socket analogous to door controlled by

 sending process shoves message app developer
process process
out door
socket socket
 sending process relies on transport
TCP with TCP with
infrastructure on other side of door Internet buffers,
buffers,
which brings message to socket at variables variables
receiving process
 Socket is the interface between the controlled
application layer and the transport by OS
layer with in a host. The only control the application
 It is also referred as application developer on the transport layer is
program interface(API) between the choice of a protocol TCP or UDP.
the application and the network. 9
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?
 A: No, many processes can be running on same host
 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

 more shortly…
10
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
 Some application layer protocols are specified in RFCs and are therefore public
documents.
 For example the web application layer protocol HTTP is available in RFC.
 If a browser developer follows the rule of HTTP RFC, the browser will be able to
retrieve web pages from any web server that has also followed the rules of HTTP
RFC.
 Many other application layer protocol are proprietary and intentionally not
available in public domain.
 For example most p2p file sharing system use proprietary application layer
protocols.
11
What transport layer service does an app need?
Reliable data transfer
 some apps (e.g., audio) can
tolerate some loss
 other apps (e.g., file transfer,
telnet) require 100% reliable
data transfer
Timing
 A transport-layer protocol can
also provide timing guarantees.
 some apps (e.g., Internet
telephony, interactive games)
require low delay to be
“effective”
Throughput
The transport protocol ensure
guaranteed throughput of r bits/sec
some apps (e.g., multimedia)
require minimum amount of
throughput to be “effective”.
Such Applications are said to be
bandwidth-sensitive applications
other apps (“elastic apps”)
make use of whatever throughput
they get
Security
Provides Encryption,
decryption, data integrity, …
12
 Transport service requirements of common apps

Application Data loss Throughput Time Sensitive

file transfer no loss elastic no

e-mail no loss elastic no
Web documents no loss elastic no
real-time audio/video loss-tolerant audio: 5kbps-1Mbps yes, 100’s msec
video:10kbps-5Mbps
stored audio/video loss-tolerant same as above yes, few secs
interactive games loss-tolerant few kbps up yes, 100’s msec
instant messaging no loss elastic yes and no

13
transport protocols services
TCP service: UDP service:
 connection-oriented: setup  unreliable data transfer
required between client and server between sending and
processes receiving process
 reliable transport between  does not provide:
sending and receiving process connection setup,
 flow control: sender won’t reliability, flow control,
overwhelm receiver congestion control, timing,
 congestion control: throttle sender throughput guarantee, or
when network overloaded security
 does not provide: timing,
minimum throughput guarantees,
security

14
Internet apps: application, transport protocols

Application Underlying
Application layer protocol transport protocol

e-mail SMTP [RFC 2821] TCP

remote terminal access Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
file transfer FTP [RFC 959] TCP
streaming multimedia HTTP (eg Youtube), TCP or UDP
RTP [RFC 1889]
Internet telephony SIP, RTP, proprietary
(e.g., Skype) typically UDP

15
DNS: Domain Name System
People: many identifiers:
 SSN(social security Number),
name, passport #, ID No
Just as humans can be identified
in many ways so do Internet
hosts, routers:
 IP address (32 bit) - used for
addressing datagrams
 “name”, e.g., www.yahoo.com
- used by humans
 Host names are appropriate for
people but not for routers as they
simply provide location.
 For example www.bdu.edu.et
Domain Name System:
 Is a distributed database implemented
in hierarchy of many name servers
 Is an application-layer protocol that
allow hosts to query the distributed data
base.
 The DNS servers are often UNIX
machines running the Berkley Internet
Name Domain(BIDN) software.
 The DNS runs over UDP and uses Port
53.
 Is commonly employed by other
application layer protocols including
HTTP, SMTP, and FTP to translate user
supplied host names to IP address.
16
 As an example consider what happens when the browser running
on some host want access to www.bdu.edu.et
 The same user machine runs the client side of the DNS
application
 The browser extracts the host name www.bdu.edu.et from the
URL and pass it to client side of the DNS application
 The DNS client sends a query containing the host name to the
DNS server
 The DNS client eventually receives a reply, which include the
IP address of the host name
 once the browser receives the IP address from DNS, It can
initiate a TCP connection to the HTTP server process located at
port 80 at the IP address.

17
DNS
DNS services
 Hostname to IP address
translation
 host aliasing: A host with
complicated host name can have one or
more alias. For example a host name
such as relay.west-cost.enterprise.com
could have two aliases such as
Enterprise.com and
www.enterprise.com.
 In this case relay.west-
cost.enterprise.com is said to be
canonical host name.
 mail server aliasing
 load distribution
 Among replicated Web servers: set of
IP addresses for one canonical name
Why not centralize DNS?
 Single point of failure
 If the DNS server crashes, so
does the entire Internet.
 Traffic volume
 A single DNS server has to
respond to hundreds of
millions request.
 Distant centralized database
 Can’t be close to all querying
clients.
 Maintenance
 A single server has to keep
record of all internet hosts
 doesn’t scale!
18
Distributed, Hierarchical Database
 DNS is a distributed database system
 Uses a large number of computers called name
servers
 Organized in a hierarchical way and distributed all
over the world
 No single host has all the exact mappings for all the
hosts in the Internet

19
Distributed, Hierarchical Database
Root DNS Servers

com DNS servers org DNS servers edu DNS servers

pbs.org poly.edu umass.edu

yahoo.com amazon.com
DNS servers DNS serversDNS servers
DNS servers DNS servers

Client wants IP for www.amazon.com (simplified):

 client queries a 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

20
 DNS: Root name servers

 Root server: a server which has references for the top level domains
 13 root servers distributed all over the world
 contacted by local name server that cannot resolve name

a Verisign, Dulles, VA
c Cogent, Herndon, VA (also LA)
d U Maryland College Park, MD
g US DoD Vienna, VA
h ARL Aberdeen, MD k RIPE London (+16 other locations)
j Verisign, ( 21 locations)
i Autonomica, Stockholm
(+28 other locations)
e NASA Mt View, CA m WIDE Tokyo (also Seoul,
f Internet Software Corporation Paris, San Francisco)
Palo Alto, CA (+36 other locations)

13 root name
servers worldwide
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA

21
TLD and Authoritative Servers
 Top-level domain (TLD) servers:
 responsible for com, org, net, edu, etc, and all top-level country
domains uk, fr, ca, jp.
 Network Solutions maintains servers for com TLD
 Edu cause for edu TLD
 The 13 server are a cluster of replicated servers
 Authoritative DNS servers:
 organization’s DNS servers, providing authoritative hostname to IP
mappings for organization’s servers (e.g., Web, mail).
 can be maintained by organization or service provider
 Most universities and large companies implement and maintain their
own primary and secondary authoritative DNS servers

22
 Local Name Server
 does not strictly belong to hierarchy
 each ISP (residential ISP, company, university) has one.
also called “default name server”
 when host makes DNS query, query is sent to its local DNS server
 acts as proxy, forwards query into hierarchy
 Usually near the end hosts who use it

23
 root DNS server
DNS name resolution example
 Host at cs.ubc.ca wants IP
2
address for cs.umass.edu 3
TLD DNS server
4
iterated query:
 contacted server replies with 5
name of server to contact local DNS server
 “I don’t know this name, but dns.ubc.ca
ask this server” 7 6
1 8

authoritative DNS server

dns.umass.edu
requesting host
cs.ubc.ca

cs.umass.edu

24
DNS name resolution root DNS server
example
6
2 3
 Host at cs.ubc.ca wants 7
IP address for TLD
DNS
cs.umass.edu server

recursive query: local DNS server 4 5

dns.ubc.ca
 puts burden of name
resolution on the 1 8
contacted name server
 heavy load? authoritative DNS server
dns.umass.edu
requesting host
cs.ubc.ca

cs.umass.edu

2: Application Layer 25
 DNS: caching and updating records
 once (any) name server learns mapping, it caches mapping
 cache entries timeout (disappear) after some time
 TLD servers typically cached in local name servers
• Thus root name servers not often visited
 update/notify mechanisms under design by IETF
 RFC 2136
 http://www.ietf.org/html.charters/dnsind-charter.html

26
 DNS records
DNS: distributed DB storing Resource Records (RR)

 TTL is the time to live of the resource record; it determines when a resource should be removed from a cache

RR format: (name, value, type, ttl)

 Type=A • Type A record provides the

 name is hostname standard host name to IP Address
 value is IP address for the host name translation.
Example: (bdu.edu.et, 10.1.184.25,A)

 Type=NS
 name is domain

(e.g., foo.com)
 value is hostname of authoritative name server for this domain

 Example: (bdu.edu.et,Dns.bdu.edu.et,NS)
27
 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

Example: (www.ibm.com,servereast.backup2.ibm.com,CNAME)

 Type=MX
 value is the canonical name of mail server that has an alias
host name
Example: (bdu.edu.et, Mail.bdu.edu.et, MX)
 MX records allow the host name of mail servers to have simple
aliases.
 By using MX record a company can have the same aliased
name for its mail server and web server.

28
 DNS protocol, messages
DNS protocol : query and reply messages, both with same message format

Message header
 identification: 16 bit # for query,
reply to query uses same #
 flags:
 1 bit flag to indicate whether the
message is query(0) or reply(1)
 recursion desired (1 bit)-is set
when a client(host or DNS
server) desire that the DNS
server perform recursion when it
doesn’t have a record.
 recursion available-is set in reply
if the DNS server support
recursion
 reply is authoritative
29
DNS protocol, messages

Name, type fields

for a query

RRs in response
to query

records for
authoritative servers

additional “helpful”
info that may be used

30
 Inserting records into DNS
 The discussion above focused on how records are retrieved from the DNS
database.
 Now we will see how to insert a record to the DNS data base.
 For example: new startup website is created and it is called “Network Utopia”
 The first thing that you want to do is register the domain name
networkutopia.com by the registrar.
 A registrar is a commercial entity that verifies the uniqueness of domain name,
enters the domain name into the DNS database.
 register name networkutopia.com at DNS registrar you need to provide the
registrar
 provide names, IP addresses of authoritative name server (primary and
secondary)
 registrar inserts two RRs into com TLD server:

(networkutopia.com, dns1.networkutopia.com, NS)

(dns1.networkutopia.com, 212.212.212.1, A)

 create authoritative server Type A record for www.networkutopia.com; Type MX

record for networkutopia.com

31
Electronic Mail
outgoing
 E-mail is an asynchronous
message queue
communication medium –people
user mailbox
send and read messages when it is
user
convenient for them agent
Three major components: mail
user
 user agents server
agent
 mail servers
SMTP mail
 simple mail transfer protocol: SMTP
server user
SMTP agent
User Agent
 a.k.a. “mail reader” SMTP
mail user
 Are used for composing, editing, agent
server
reading mail messages
 e.g., Eudora, Outlook, elm, Mozilla user
Thunderbird agent
user
 outgoing, incoming messages stored
agent
on server
32
 Electronic Mail: mail servers
Mail Servers
 mailbox contains incoming messages
for user user
 message queue of outgoing (to be sent) agent

mail messages mail

user
server
 SMTP protocol is used between mail agent
servers to send email messages SMTP mail
 client: sending mail server server user
 “server”: receiving mail server SMTP agent

SMTP
mail user
server agent

user
agent
user
agent

33
Electronic Mail: SMTP [RFC 2821]
 uses TCP to reliably transfer email message from client to server,
port 25
 direct transfer: sending server to receiving server
 three phases of transfer
 handshaking (greeting)
 transfer of messages
 closure
 command/response interaction
 commands: ASCII text
 response: status code and phrase
 messages must be in 7-bit ASCII

34
Scenario: Alice sends message to Bob
1) Alice uses UA to compose message
and “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

1 mail
mail
server user
user server
2 agent
agent 3 6
4 5

35
 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
The numeric values are reply code. They are used to identify the next step
to be done by the client server.
36
Mail message format
SMTP: protocol for
exchanging email msgs
RFC 822: standard for text
message format: header
blank
 header lines, e.g., line
 To:
 From:
body
 Subject:

different from SMTP

commands!
 body
 the “message”, ASCII
characters only

37
Mail access protocols

SMTP SMTP access user

user
agent protocol agent

sender’s mail receiver’s mail

server server
 SMTP: delivery/storage to receiver’s server
 Mail access protocol: retrieval from server
 POP: Post Office Protocol [RFC 1939]
• authorization (agent <-->server) and download
 IMAP: Internet Mail Access Protocol [RFC 1730]
• more features (more complex)
• manipulation of stored msgs on server
 HTTP: gmail, Hotmail, Yahoo Mail, etc.

38
 POP3 protocol
 Uses a TCP connection at port 110
S: +OK POP3 server ready
authorization phase C: user bob
 POP3 progress through three phases. S: +OK
Authorization, transaction, and update. C: pass hungry
 Client sends commands : S: +OK user successfully logged on
 username: declare username C: list
 password: password S: 1 498
 to authenticate the user S: 2 912
 server responses S: .
C: retr 1
 +OK
S: <message 1 contents>
 -ERR
S: .
 transaction phase, the user agent C: dele 1
 list: list message numbers C: retr 2
 retr: retrieve message by number S: <message 1 contents>
 dele: delete S: .
C: dele 2
 The third phase, update, occurs after
C: quit
the client has issued the quit command S: +OK POP3 server signing off
39
 POP3 (more) and IMAP
More about POP3
 Previous example uses
“download and delete” mode.
 Bob cannot re-read e-mail if
he changes client
 “Download-and-keep”:
copies of messages on
different clients
 the POP3 protocol does not
provide any means for a user
to create folders and assign
messages to folders.
 Simple implementation
IMAP
 Keep all messages in one place: the
server
 Allows user to organize messages in
folders on the server
 IMAP has a commands that permit the
user agent to obtain component of the
message.
 For example: a user agent can obtain
just the message header of the
message or part of the message.
 IMAP keeps user state across
sessions:
 names of folders and mappings
between message IDs and folder
name
 More complex implementation
40
Web Based email /HTTP/
 More users today are sending and accessing their email through their web
browsers.
 Hot mail introduced web access in the 1990’s
 Now web based email is provided by Yahoo, Google as well as every
major university and corporation.
 With this service user agent is an ordinary web browser and the user
communicate with its remote mailbox via HTTP protocol
 When a recipient such as Bob wants to access a message in his mailbox,
the email message is sent from Bob’s mail server to Bob’s browser using
the HTTP protocol rather than POP3 or IMAP protocol.
 When a sender such as Alice, wants to send an email message, the email
message is sent from her browser to her mail server over HTTP rather than
over SMTP.
 Alice’s mail server, however , still send messages to and receive messages
from the other mail servers using SMTP.
41
Web and HTTP
First some jargon
 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
 Example URL:

www.someschool.edu/someDept/pic.gif

host name path name

42
HTTP overview
HTTP: hypertext transfer protocol
 HTTP Is a Web’s application layer
protocol
 HTTP is implemented in two programs:
HT
a client program and a server program. TP
r
equ
PC running HT est
 The client program and server program, TP
Explorer res
executing in different end systems, talk pon
se
to each other by exchanging HTTP
message. est
u
 HTTP defines P req se Server
T o n
 Structure of HTTP messages HT r es
p running
T P Apache Web
 How the client and server exchange messages HT
server
 client/server model
 client: browser that requests, Mac running
receives, “displays” Web objects Navigator
 server: Web server sends objects in
response to requests
43
 HTTP Overview
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
44
 HTTP connections
 In many internet applications, the client and the server communicate for
an extended period of time, with the client making a series of request and
a server responding to each request.
 Depending on the application and how the application is being used, the
series of requests may be made back to back, periodically at a regular
interval or intermittently.
 When this client –server interaction takes place over TCP, the application
developer needs to make an important decision
 Should each request/response pair be sent over a separate TCP connection or
 Should all of the request and their corresponding response be sent over the same TCP
connection

 In the first approach the application is said to use non-persistent

connection and in the later approach persistent connection.
45
Nonpersistent HTTP
Suppose user enters URL for the base HTML file
www.someSchool.edu/someDepartment/home.index
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
time
Let assume the
webpage(contains text,
references and 10
jpeg images)
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
46
 Nonpersistent HTTP (cont.)

4. HTTP server closes TCP

connection.
5. HTTP client receives response
message containing html file,
displays html. Parsing html
file, finds 10 referenced jpeg
objects
time 6. Steps 1-5 repeated for each
of 10 jpeg objects

47
 Non-Persistent HTTP: Response time
Definition of RTT(Round Trip Time):
time for a small packet to travel from
client to server and back.
 RTT includes
 Packet-propagation delays
initiate TCP
 Packet queuing delays in intermediate connection
routers and switches and
RTT
 Packet processing delays
request
Response time: file
time to
 one RTT to initiate TCP connection RTT
transmit
 one RTT for HTTP request and first file
file
few bytes of HTTP response to return received
 file transmission time
total = 2RTT+transmit time time time

48
Persistent HTTP
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
 Multiple web pages residing on the same the server can be sent from the server
to the same client over a single persistent TCP connection.
 These requests can be made back to back, without waiting for replies to
pending requests (pipelining)
 The HTTP server closes the connection when it is not used for a certain time.
 When the server receives back to back request it sends the objects back to
back.
 The default mode of HTTP connection is persistent connection with pipelining.

49
 HTTP request message
 two types of HTTP messages: request, response
 HTTP request message:
 ASCII (human-readable format)

request line
(GET, POST, GET /somedir/page.html HTTP/1.1
HEAD commands) Host: www.someschool.edu
User-agent: Mozilla/4.0
header Connection: close
lines Accept-language:fr

Carriage return,
(extra carriage return, line feed)
line feed
indicates end
of message

50
 The above request message has five lines
 1st line
 is called request line
 Has three fields: the method field, the request field and the HTTP version
field
 The method field can take on several different values, including GET,POST,
HEAD, PUT and DELETE.
 The great majority of HTTP request message use GET method.
 GET method is used when the browser request an object identified in the
URL field.
 2nd,3rd,4th lines are header lines
 Host: www.someschool.edu specifies the host on which the object resides
 User Agent: specifies the browser type that is making the request to the
server. This header line is useful because the server can actually send
different version of the same object to different types of user agents.
 Accept Language: indicates the language preference of the user. The user
prefer the language French in the above request statement.
51
HTTP request message: general format

52
Uploading form input
Post method: URL method:
 Web page often includes  Uses GET method
form input  Input is uploaded in URL
 Input is uploaded to server field of request line:
in entity body by using
post method

www.somesite.com/animalsearch?monkeys&banana

53
Method types
HTTP/1.0 HTTP/1.1
 GET  GET, POST, HEAD
 POST  PUT
 HEAD  uploads file in entity body
to path specified in URL
 asks server to leave
field
requested object out of
response  DELETE
 Used by application  deletes file specified in the
developers for debugging URL field

54
HTTP Response Message
status line
(protocol
status code HTTP/1.1 200 OK
status phrase) Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
header Server: Apache/1.3.0 (Unix)
lines Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html

data, e.g., data data data data data ...

requested
HTML file

55
 The response message has three section

 Status line
 Six header lines and
 Entity body
 The status line has three fields protocol, status line and status code.

 Connection: close header line is used to tell the client that it is going to close the
TCP connection after sending the message.
 The Date: indicates the time and date when the response was created and sent by
the server.
 The Server: indicates the server name which create the response message.

 The last-modified: indicates the time and date when the object was created and
last modified.
 Content length: indicates the number of bytes in the object sent

 Content type: indicates the object in the entity

56
 HTTP response status codes
In first line in server->client response message.
A few sample codes:
200 OK
 request succeeded, requested object later in this message
301 Moved Permanently
 requested object moved, new location specified later in this message
(Location:)
400 Bad Request
 request message not understood by server
404 Not Found
 requested document not found on this server
505 HTTP Version Not Supported

57
User-server state: cookies
• The stateless nature of HTTP server
• simplified server design and
• has permitted web servers to handle
thousand of simultaneous TCP
connections
• Identification of users is also
important for web servers either to
the server wishes to restrict user
access or it wants to serve the
content as a function of the user
identity.
• Cookies allow sites to keep track of
users.
• Many major Web sites use cookies
Four components of Cookie:
1) cookie header line of HTTP
response message
2) cookie header line in 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
always 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
58
 Cookies: keeping “state” (cont.)
client server
ebay 8734
usual http request msg
Amazon server
cookie file usual http response creates ID
Set-cookie: 1678 1678 for user create
ebay 8734 entry
amazon 1678
usual http request msg
cookie: 1678 cookie- access
specific
one week later: usual http response msg action backend
database
access
ebay 8734
usual http request msg
amazon 1678
cookie: 1678 cookie-
spectific
usual http response msg action

59
 Cookies (continued) aside
What cookies can bring: Cookies and privacy:
 authorization  cookies permit sites to

 shopping carts learn a lot about you

 you may supply name and
 recommendations
e-mail to sites

How to keep “state”:

 protocol endpoints: maintain
state at sender/receiver over
multiple transactions
 cookies: http messages carry
state

60
 Web caches (proxy server)
Goal: satisfy client request without involving origin server
 A web cache also called a
proxy server- is a network
entity, which has its own disk origin
and keeps copies of recently server
requested objects.
 user sets browser: Web HT Proxy
TP
req server q uest
accesses via cache H u P re
T
client TP est T T o n se
H p
 browser sends all HTTP res
pon P res
se H TT
requests to cache est
u
 object in cache: cache P req nse
T po
HT r es
returns object TP
HT
 else cache requests object
from origin server, then client
origin
returns object to client server

61
More about Web caching
 cache acts as both client and server
 When it receives a request from and send a responses to a browser, it is a
server.
 When it send request to and receive response from an origin server, it is a
client.
 typically cache is installed by ISP (university, company, residential ISP)

Why Web 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

62
 Caching example
Assumptions
 average object size = 1mb origin
 avg. request rate from institution’s
servers
browsers to origin servers = 15/sec public
Internet
 delay from institutional router to any
origin server and back to router = 2 sec
Consequences
15 Mbps
 utilization on LAN = 15% access link
(15 request/second *1mb/s)/100 mb/s=0.15 institutional
 utilization on access link = 100% network
100 Mbps LAN
(15 request/second *1mb/s)/15 mb/s=1
 total delay = Internet delay + access delay +
LAN delay
= 2 sec + minutes + milliseconds institutional
cache

63
 Caching example (cont)
possible solution
 increase bandwidth of access link to, origin
say, 100 Mbps servers
consequence public
 utilization on LAN = 15% Internet
 utilization on access link = 15%
 Total delay = Internet delay + access
delay + LAN delay 100 Mbps
access link
= 2 sec + msecs + msecs
institutional
 often a costly upgrade
network
100 Mbps LAN

institutional
cache

64
Caching example (cont)
possible solution: install cache origin
 suppose hit rate is 0.4 servers
consequence public
 40% requests will be satisfied Internet
almost immediately
 60% requests satisfied by origin
server
 utilization of access link reduced 15 Mbps
to 60%, resulting in negligible access link
delays (say 10 msec) institutional
 total avg delay = Internet delay network
100 Mbps LAN
+ access delay + LAN delay =
6*(2.01) secs + .4*milliseconds
< 1.4 secs
institutional
cache

65
Conditional GET
 Although caching can reduce
user perceived response time ,
it introduce a new problem – cache server
the copy of an object residing
in the cache may be stale. HTTP request msg
If-modified-since:
 Conditional GET is a
<date>
object
mechanism HTTP use to not
verify if the cache objects are HTTP response modified
up to date. HTTP/1.0
 cache: specify date of cached 304 Not Modified
copy in HTTP request
If-modified-since: <date> HTTP request msg
 server: response contains no If-modified-since:
<date> object
object if cached copy is up-to-
modified
date: HTTP response
HTTP/1.0 304 Not Modified HTTP/1.0 200 OK
<data>
66
 FTP: the file transfer protocol

FTP file transfer

FTP FTP
user client server
interface
user
at host remote file
local file
system system

 transfer file to/from remote host

 The user must provide a user identification and password
 client/server model
 client: side that initiates transfer (either to/from remote)
 server: remote host

 ftp: RFC 959

 ftp server: port 21

67
FTP: separate control, data connections
 FTP client contacts FTP server
TCP control connection
at port 21, TCP is transport port 21
protocol
 client authorized over control
connection TCP data connection
FTP port 20 FTP
 client browses remote client server
directory by sending commands
over control connection.  server opens another TCP
 when server receives file data connection to transfer
transfer command, server another file.
opens 2nd TCP connection (for  control connection: “out of
file) to client band”
 after transferring one file,  FTP server maintains “state”:
server closes data connection. current directory, earlier
authentication

68
 FTP commands, responses
Sample commands:
 sent as ASCII text over
control channel
 USER username
 PASS password
 LIST return list of file in
current directory
 RETR filename retrieves
(gets) file
 STOR filename stores
(puts) file onto remote host
Sample return codes
 status code and phrase (as
in HTTP)
 331 Username OK,
password required
 125 data connection
already open;
transfer starting
 425 Can’t open data
connection
 452 Error writing
file
69
 DHCP(Dynamic Host Configuration Protocol)
 The Dynamic Host Configuration Protocol (DHCP) is a protocol used in
the TCP/IP networking model for automatically and dynamically
configuring hosts attached to a network with parameters they’ll need to
be able to use the network.
 The protocol is defined in RFC 2131 (reference [1]), which updated and
clarified the original specification in RFC 1541 (reference [2]);
 The service provided by DHCP frees a network administrator from
having to manually configure each host connected to his network
(though the protocol does not prevent this, and can provide partial
information for hosts which have been partially configured).
 One of the widest uses of DHCP is for the automatic assignment of
network (IP) addresses to hosts.
 A system administrator configures the DHCP server module with a pool
of addresses which it may allocate.
70
 DHCP
 The protocol allows reuse of addresses that have been relinquished by
hosts that have disconnected from the network; this is especially
valuable when the pool of available addresses is limited and shared
among all hosts, as in the case of an internet service provider with many
dial-in clients.
 The protocol uses a client-server approach, with the DHCP client
requesting network parameters from a DHCP server designated by the
network administrator.
 One of the interesting features of this protocol involves the issue of the
addressing of the DHCP messages exchanged by the client and server
during the address allocation sequence.
 Since the purpose of this exchange is to assign a network address to the
client, the protocol must specify a mechanism for the server to convey
its responses to the client before the client has a valid network address.
 In addition, the client need not know an address for a DHCP server to
initiate its requests for configuration information.
71
 DHCP
Services
 DHCP is really an application-layer protocol in the TCP/IP model, residing
above and using services provided by the Transport layer.
 The messages exchanged by DHCP use the unreliable UDP (User
Datagram Protocol) packet delivery service provided by the Transport layer.
 DHCP provides its services to the operating system.
 The operating system can ask the DHCP client module to request certain
specific network parameters (usually including an IP address) from a DHCP
server whenever the host detects that it has been connected to a network.
 The parameters are passed from the DHCP layer to the operating system,
which then configures the IP layer of the protocol stack with these settings.
 Thus DHCP is a particularly interesting protocol in that it in a sense
provides services for a layer below it in the protocol stack, though of course
indirectly, through the operating system (which resides with it in the
application layer).

72
 DHCP

• DHCP servers can be on a LAN, on a router or at an ISP.

• They can be accessed remotely by sites on a WAN.
 DHCP
• DHCP is a four step process.

1. Client broadcasts a DHCP Discover frame to find a DHCP

server. There may be more than one available.
The client and server peers communicate by exchanging messages in
UDP packets, using UDP ports 67 for the server and 68 for the client.
DHCP DISCOVER
Sent by a DHCP client when it first wishes to receive configuration
information including a network address, containing a list of parameters
for which it would like information.
Since the client does not in general know the IP address of a DHCP
server, this message is sent to the IP broadcast address.
As such, more than one DHCP server may receive and respond to such
a message.
This can improve reliability by providing redundancy.
DHCPOFFER
 Sent by a DHCP server in response to the receipt of a
DHCPDISCOVER message, containing values for the configuration
parameters requested.
Since the client does not at this point have a valid IP address, the server
must either address the message using the client’s hardware (data link)
address (supplied in the DHCPDISCOVER message), or broadcast the
response.
In addition, the server is not required at this stage to commit these
parameters to this client, or reserve them exclusively for this client for any
specified period of time; these are merely proposed values, which must be
confirmed through subsequent messages.
This improves efficiency in the case in which more than one server
responds to a client’s inquiry; since the client will choose parameters from
only one of the servers, the others shouldn’t be forced to reserve resources
that will not be used.

76
DHCPREQUEST
Sent by a client upon receipt of one or more DHCPOFFER responses.
The client selects the parameters offered in one of the DHCPOFFER
messages, and sends a DHCPREQUEST containing these same parameter
values back to the specific server which provided them.
This is necessary since the server isn’t required to reserve those parameter
values (including the suggested IP address) for the client when it makes an
offer; thus the client must re-confirm that they are still available.
DHCPACK
Sent by a server on receipt of a DHCPREQUEST message if the
requested parameters (e.g., IP address) are still available.
At this point, the server reserves these parameters for this client; only on
receipt of this message can a client consider those parameters to be its own
(it becomes “bound”).
Since the client may not have a network address until this message has
been received, the server may have to address it in some alternate fashion,
as in the case of DHCPOFFER messages.
77
DHCPNAK
Sent by a server in response to a DHCPREQUEST message which
requests parameters that are no longer available.
If a client receives this message, it must send another
DHCPREQUEST message requesting other parameters (or send a new
DHCPDISCOVER message if it has no other outstanding offers).

DHCPDECLINE
Sent by a client to a specific server in response to a DHCPACK
message, which contain parameters which the client has determined are
not in fact valid.
 For example, the client might test an IP address it has received by
sending an ARP (Address Resolution Protocol) message on its shared
LAN to see if any other host has been assigned this address; if it
discovers that another host is in fact using this address, it must send a
DHCPDECLINE message to the server which supplied the address.
78
This both allows the server to release the resources it has allocated to this
client, and inform a system administrator of the problem.
(Such a problem might arise in a situation in which a host has been
manually configured by an administrator with an IP address, but the DHCP
server hasn’t been informed that this address is no longer available in its
pool.
Though it is suggested that a server test an address before allocating it to
a client for example by “pinging” the address to see if another host is
using it, it may be that the test or the response to it is lost, incorrectly
suggesting to the server that the address is available.)

DHCPINFORM
This is sent by a client when it needs only certain configuration
information, but already has a network address.
The server sends a DHCPACK in response with the requested
parameters.
79
DHCPRELEASE
Sent by a client to inform the server that it no longer requires the
allocated parameters.
This allows the server to return these parameters (such as IP
address) to its pool for reallocation.
This message is not required; the allocated parameters are generally
configured with a finite lifetime (called a “lease”), and are deallocated
automatically when the lease expires.
 This is discussed further in the next section, Leases and Renewals.

80
Initial Message Flow
Server A Client Server B
Client attempts to discover
DHCPDISCOVER DHCPDISCOVER available DHCP servers

Servers reply with offers

DHCPOFFER DHCPOFFER
Client collects offers and
decides which offer to accept

Client broadcasts request for

DHCPREQUEST DHCPREQUEST one of the received offers

Server acknowledges client’s

Configuration complete DHCPACK use of IP address

Graceful shutdown Client explicitly releases

DHCPRELEASE use of IP address

81
Leases and Renewals
 When a server has allocated a network address to a client, the address is
generally provided as a “lease” for a limited period of time.
 The length of the lease assigned is configurable by the network
administrator, and may be very long or even infinite, providing for
permanent assignment of IP addresses to specific clients.
 (The lease time is specified as an unsigned 32-bit value interpreted in
seconds, giving finite lease times from 1 second to approximately 100 years;
the value 0xffffffff is reserved to represent an infinite lease time.)
 The lease record for a client is maintained by the server, containing the
assigned configuration information, and is identified by either the
combination of the client’s hardware (data link) and assigned network
address, or by a unique “client identifier” supplied by the client.
 For finite leases, the client must periodically renew the lease with the
server before it expires if it wants to continue using the assigned network
address.

82
Clients generally try to renew their leases well before they expire,
as they must stop using the assigned address if they are not successful
in renewing the lease.
The message exchange for the renewal process is illustrated below.

In the case of infinite or very long-term leases, clients will likely be
rebooted many times before the lease has expired.
In such cases, the client and servers need not go through the entire
process of creating a new lease.
The client, remembering the IP address it was previously assigned,
simply asks the available DHCP servers if any of them holds a valid
lease for it; if it receives an affirmative reply, it can then begin using
the corresponding network address.
83
Multimedia networking protocols
 In the old days, most of the data carried on
networks was textual data
 Today, with the rise of multimedia and network
technologies, multimedia has become an
indispensable feature on the Internet
 Animation, voice and video clips become more and
more popular on the Internet.
 Multimedia networking products like Internet
telephony, Internet TV, video conferencing have
appeared on the market

84
Multimedia networking: 3 application types
 Streaming stored audio, video
 Like DVD but via Internet Prerecorded multimedia content, user
may pause, rewind, forward,
 streaming: can begin playout before downloading entire file
 stored (at server): can transmit faster than audio/video will be
rendered (implies storing/buffering at client)
 e.g., YouTube, Netflix, Hulu

 Conversational voice/video over IP

 interactive nature of human-to-human conversation limits delay
tolerance
 IP phone, video conferencing. Can’t pause, rewind.
 e.g., Skype

 streaming live audio, video

 Like broadcast TV/radio but via Internet,
 Can’t pause, rewind
 e.g., live sporting event (futbol) 7-
85
 VoIP
 VoIP = “Voice over Internet Protocol”
 Basically, VoIP means Voice transmitted over a Digital Network”
 Also called IP Telephony
 Standards based (e.g., H.323, G.711, G.729, RTP, UDP, IP, RSVP, SIP)
 VoIP is the latest in a long series of actions to change voice transmission
from an all analog to an all digital network
 Transmission of voice telephone calls using internet
infrastructure.
 Challenges
 Voice transmission delay (require much higher bandwidth)
 Call setup: call establishment, call termination, etc.
 Backward compatibility with existing PSTN (Public Switched
Telephone Network)

86
Why need to IP Telephony?
 Economic (uses internet, IP routers...)
 Further savings. Because underlying network
infrastructure can be shared a single set of equipment,
wiring, network connection enough.
 Not only voice but also video is transmitted using
similar concepts.
 Spreads at a fast pace.
For instance there isn’t any internet cafe which doesn’t
have tiny video cameras over their monitors.
 Independent. Much larger selection of service providers
to provide voice and video communication services .
No geographical restriction!
Located virtually anywhere in the world!

87
 What is Multimedia Streaming?User’s perspective:
• Multimedia Streaming: •Quick start without waiting for
Clients request full download.
audio/video files from •Coming continuously without
servers and pipeline interruption.
reception over the •VCR operation (pause, resume,
network and display fast forward, rewind, etc.)

Streaming Server Client/Receiver

Storage Video Audio

StorageDevice
Device
Decoder Decoder
Multimedia
Raw Compressed Streaming Multimedia
Video Video Protocols Streaming
Protocols

Raw Compressed Transport Transport

Audio Audio Protocols Protocols

Internet
88
 Challenges in Media Streaming Protocols
Clients/Receivers
1. Rate Control:
Determine the sending rate
based on the available
bandwidth in the network.
Ethernet
Streaming Server

Broadband
Modem
3. Continuous Distribution: 2. Error Control:
TCP/UDP/IP suite provides Improve video presentation
best-effort, no guarantees on quality in the presence of
expectation or variance of packet loss.
packet delay
89
 A General View of the Multimedia Streaming
Protocols
 Stream description SDP
Describe the session and content
 Stream control RTSP
Remote control the session
 Media transport RTP
Error control and flow control
 Resource reservation (if any!): RSVP
provide QoS for media streaming packets

90
 Protocol stacks for media streaming

Data Plane Control Plane

Compressed
RTP
RTP Layer
Layer RTCP
RTCP Layer
Layer RTSP
RTSP Layer
Layer
Video/Audio

UDP
UDP TCP
TCP

IPv4,
IPv4, IPv6
IPv6

Internet
91
Real Time Streaming Protocol (RTSP)

92
 Real Time Streaming Protocol (RTSP) (Con)
 Supports the following
operations:
 Supports VCR-like control
operations
 Chooses delivery channels,
e.g. UDP, TCP.
 Supports any session
description.
 Establish and control stream
of continuous audio and video
media.
• Retrieves requested media.
• Add Media to an existing
session.

93
Real-Time Protocol (RTP/RTCP)
 RTP is a data transfer protocol and RTCP is a control
protocol.
 RTP provides
• Payload type identification: Identify which kind of
information is being transmitted, RTP provides 128
possible different types of encoding; eg MPEG2 video,
etc.
• Sequencing: Reassemble the stream and detect packet
loss.
• Time stamping: Assure synchronization.
• Source identification: Provide a means for the receiver
to distinguish different sources.
 RTP DO NOT provide
 Quality of service
 Reliability in packet delivery.
 Security. Sequence Source
Payload Timestamp Misc.
Number Identifier
Type
94
 Real-Time Protocol (RTP/RTCP) (Con)
 Exchange information about the connection
to assure quality of data distribution.
 Control connection is held over a different
channel than the RTP one.
 RTCP provides
 QoS Feedback: In form of sender
reports/receiver reports. Senders adjust
transmission rate based on reports.
 Participant Identification: Human-friendly
source identification.
 Control Packets Scaling: Typically, limit the
RTCP bandwidth to 5% of the session
bandwidth, divided between the sender
reports (25%) and the receivers reports
(75%)
 Minimal Session Control Information:
Advanced control functions must be
implemented in a higher level protocol.

95
 Session Description Protocol (SDP)

 SDP is Text Format for describing multimedia

sessions
 Not really a protocol (similar to markup
language like HTML)
 Can be carried in any protocol, e.g., RTSP or
SIP
 Describes unicast and multicast sessions
 SIP(Session Initiation Protocol)
 SIP is used to set up, modify and terminate an RTP-based
multimedia session (like IP telephone conversation or
videoconferencing).
 It is a catalytic protocol that delivers key signaling elements
that can turn a VoIP Network into a true IP Communications
Network
 It replaces older and proprietary signaling protocols
 It enables multiple vendors to interoperate
 It enables new services to be easily added
 Enables Presence Based Capabilities

97
 SIP – The Session Initiation Protocol
The SIP methods defined in the core specification.

98
 The H323 protocol stack.
H.323 is a protocol standard for multimedia communications.
H.323 was designed to support real-time transfer of audio and video data over
packet networks like IP.
The standard involves several different protocols covering specific aspects of
Internet telephony.
The International Telecommunication Union (ITU-T) maintains H.323 and
these related standards.

99
 Most voice over IP (VoIP) applications utilize H.323.
 H.323 supports
• Call Setup,
• Teardown and
• Forwarding/Transfer.
 Architectural elements of a H.323 based system are Terminals,
Multipoint Control Units (MCUs), Gateways, an optional Gatekeeper
and Border Elements.
 Different functions of H.323 run over either TCP or UDP Overall, H.323
competes with the newer Session Initialization Protocol (SIP), another
proven standard often found in VoIP systems.
 A key feature of H.323 is Quality of service(QoS).
 QoS technology allows real-time prioritization and traffic management
constraints to be placed on "best-effort" packet delivery systems like
TCP/IP over Ethernet.
 QoS improves the quality of voice or video feeds.

100
 Voice over IP

 Logical channels between the caller and callee during a

call.

101
 Comparison of H.323 and SIP

PSTN(Public Switch Telephone Network) 102