Transcript Application protocol

CMPT 371
Data Communications and Networking
Introducing the Application Layer
© Janice Regan, CMPT 128, Jan 2007
0
What is in the application layer
 All user applications
 Electronic mail, instant messaging, telephony
 Web, video, music
 Remote login
 File transfer and file sharing
 Multiplayer networked games
 What else?
Janice Regan © Sept. 2007-2013
1
How do apps communicate
 Applications may be built on a reliable
network (TCP) or a best effort network
(UDP). In the case of the best effort
network the application itself must take
care of assuring the communications are
as reliable as necessary
Janice Regan © Sept. 2007-2013
2
Some Application layer Protocols
 Users most commonly directly use application
layer protocols like Hypertext Transfer Protocol
(HTTP), File Transfer Protocol (FTP), Simple
Mail Transfer Protocol (SMTP); Telnet,
 Other common application layer protocols help
facilitate the use and management of TCP/IP
networks: These include Domain Name System
(DNS), the Routing Information Protocol (RIP),
the Simple Network Management Protocol
(SNMP).
Janice Regan © Sept. 2007-2013
3
Network application architectures
 Client server




Servers provide services to other hosts, always available
Clients request services from other hosts, when needed (not
always connected)
Examples include, web, file servers, e-mail
When a service is heavily used it may be provided by a group of
servers, not just one
Server
Server
Client
Client
Janice Regan © Sept. 2007-2013
Client
Client
Client
4
Network application architectures
 P2P (peer to peer)



Arbitrary pairs of hosts directly communicating (no server)
Easily scalable, each host both services and makes requests
Decentralized, highly distributed, may be difficult to manage to
provide reliable service

If only one host has the information and it leaves the application
the information is lost
Client
Client
Client
Client
 Hybrid systems (both client server and P2P aspects)
Janice Regan © Sept. 2007
2007-2013
5
Hybrid client-server and P2P
 Instant Messaging
 Sending messages is P2P
 Central server manages


client detection (are you on right now?)
Searching for friends addresses
 Skype
 Voice over IP is a P2P application
 Your client accesses a centralized server to
manage addresses and memberships
Janice Regan © Sept. 2007-2013
6
Issues with P2P
 P2P distributes the function of the server
over many users, this increases upstream
traffic, stresses ISPs
 Difficulty in proving security in P2P apps
 Perception that supporting P2P is
supporting “illegal” applications
Janice Regan © Sept. 2007-2013
7
Communication between
processes
 In order to build an application that
communicates between processes (on the same
or different hosts) need a way to send
information, (data messages) from one process
to another.
 To write a user application you need not know
how this communication works in detail, but you
need a set of services that allows you to send
messages.

The interface for sending messages will likely be the
interface to the transport layer.
Janice Regan © Sept. 2007-2013
8
Communication between
processes
.
 Think in terms of a client server architecture:
 If your architecture is P2P think of the peer that is
requesting (receiving) as the client and the host that
is replying (sending) as the server.
 Any communication can be thought of in terms
of a series of communications from one process
to another

If your architecture is P2P, the identity of the client
and server may reverse for different communications
in the series
Janice Regan © Sept. 2007-2013
9
Building an application
 How do we build a communication channel in an
application?
 Usually use the socket API



A socket is one end of a communication connection
A process may include more than one communication
connection, that is more than one socket
Your application will build the needed sockets, then connect
them (or wait for them to be connected to) to the socket at the
other end of the communication.
 We will look at sockets in much more detail when we
discuss the transport layer.
Janice Regan © Sept. 2007-2013
10
Socket API
 Basic ideas: how to use the socket API
 A socket is one end of a communication connection
 A socket includes



The address of the host running the process (IP address)
The address of the process running on the host (port)
A specification of the transport protocol to use (TCP, UDP).
 Your application will build needed sockets
 Each socket will
 Wait for a request to connect to another socket
 Make a request to connect to another socket
Janice Regan © Sept. 2007-2013
11
After connection?
 What happens after we build our sockets and
connect them to each other so the two
processes can communicate?
 The purpose of the connection is to enable the
transfer of information between the processes,
so the next step will be transferring information.
 To transfer information we send messages from
one process to the other through the
communication connection
Janice Regan © Sept. 2007-2013
12
After connection?
 To transfer information we send messages from
one process to the other
 The application level protocol developed for the
particular application will define

The types of messages
 The syntax of each message (layout and number of
fields)
 The semantics of each message (the content of each
field, its meaning and use)
 Rules for processing each type of message and
building replies
Janice Regan © Sept. 2007-2013
13
Transport requirements
 Some application will tolerate some data loss


Voice, some interactive games, and video will
file transfer, many web apps, and email will not
 Some apps are time sensitive

video games, video conferencing, streamed video
 Some apps are bandwidth sensitive and require
continuous minimum throughput

audio, video, telephony
 Some apps can tolerate bursts of throughput (elastic
throughput) email, file transfer, …
Janice Regan © Sept. 2007-2013
14
Available Transport services
 TCP
 connection oriented (not a physical
connection)
 Reliable (guaranteed delivery)
 No guarantee on the rate of delivery, will slow
down transmission in case of congestion
 Available congestion control mechanisms
Janice Regan © Sept. 2007-2013
15
Available Transport services
 UDP
 Simple, efficient
 Best effort delivery, no guarantee of delivery
 No congestion control, will not slow down
transmission in case of congestion.
 Can to a certain extent build guarantee into
your application and avoid congestion control
slowdowns to support rate critical (inelastic)
applications
Janice Regan © Sept. 2007-2013
16
Internet applications (TCP)
 Application
 e-mail
 remote access
 Web
 file transfer
Janice Regan © Sept. 2007-2013
protocol
SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
17
CMPT 371
Data Communications and Networking
HTTP
© Janice Regan, CMPT 128, Jan 2007
18
HTTP
 HyperText Transfer Protocol
 The main application layer communication protocol of
the world wide web (WWW)
 For detailed information on any protocol refer to
the RFC documents (Request for comment)
these are the standard reference documents
defining protocols
 For HTTP see RFC 1945 and RFC 2616
 You will not be expected to read all the RFC’s
for this course
Janice Regan © Sept. 2007-2013
19
WWW: objects
 When we use WWW we provide a URL
and expect to see the web page displayed
by our browser
 Each web page is made up of many
objects including images, text, audio or
video clips, animations, applets and other
components
Janice Regan © Sept. 2007-2013
20
WWW: objects
 Each web page is described by an HTML
file
 The HTML file will include a reference (a
separate URL) for each of the objects on the
page
 After the HTML file is received in response to
the original HTML request, the objects in it
can be individually requested
 All the requested objects can then be
assembled in the displayed page
Janice Regan © Sept. 2007-2013
21
WWW: using agents
 Each browser is called an agent
 Agents use HTTP to communicate across
the Internet.
 Agents are clients, they request
information, the objects on a web page
 For any operating system your agent is
always uses HTTP to communicate
across the Internet
Janice Regan © Sept. 2007-2013
22
WWW basic operation
 Your agent (browser) is the client in a
client server system
 The hosts containing the objects that
make up your web page are servers
 You (the client) must request the objects
from the servers (which store and provide
the objects) using HTTP
 HTTP is an application layer protocol
Janice Regan © Sept. 2007-2013
23
Access a web page
 When we type a URL into our browser we
expect to see a page displayed. How does
it happen?
 HTTP is used to send a request from your
browser to the web server
 HTTP is used by the server the send a
reply to your HTTP request
Janice Regan © Sept. 2007-2013
24
Steps to access an object
 The web server must first be located: use the URL
 A TCP (reliable transport protocol) connection is
made between the client and the server
 The client sends a HTTP request for the object to
the server, (or a series of HTTP requests)
 The server will process the request and if
appropriate sends a HTTP reply containing the
requested object to the client
 The client will add the object to the page and
request the next object
Janice Regan © Sept. 2007-2013
25
Non-persistent connections
 In the original version (1.0) of HTTP it was
assumed that a TCP connection would be made
to transfer each object.
 As soon as the single object had been
transferred the connection would be terminated
 A new connection would be made for the next
object that needed transferring between the
same client server pair
Janice Regan © Sept. 2007-2013
26
Non-persistent connections
 Early web pages contained one or a very small
number of objects, this was not a critical
problem
 Today web pages contain many objects and the
extra load of creating and terminating
connections would place a significant extra load
on the internet
 A nonpersistant connection transports at most 1
HTTP request and 1 HTTP reply
Janice Regan © Sept. 2007-2013
27
Non-persistent connection
Host A
Request TCP
connection (SYN)
Acknowledge acceptance
(ACK) and HTTP GET
request object
Acknowledge close request
and make close request
(FIN, ACK)
Janice Regan © Sept. 2007-2013
Host B
(SYN, ACK)
Accept TCP
connection
HTTP OK
send object
Request close of TCP
connection (FIN)
Acknowledge close request
(ACK)
28
non-persistent connections
 Each time a non persistent connection is
made, it is necessary to initialize and
terminate a TCP connection
 Send request to make/break connection A-B
 Send back a response agreeing to
make/break connection (B-A)
 Send an acknowledgement that the
connection has been made/terminated.
Janice Regan © Sept. 2007-2013
29
Efficiency: non-persistent connections
 Each time a non persistent connection is made, it is
necessary to initialize and terminate a TCP connection
 The RTT (round trip travel time) is the time it takes to
propagate from A to B and back to A
 For each connection it take 3 round trip travel times to
make and break the connection.
 If many objects are to be transmitted this extra delay
becomes significant. How can we increase the
efficiency?
 By sending multiple objects through each connection.
Janice Regan © Sept. 2007-2013
30
Persistent connections
 In the late 1990’s HTTP 1.1 came into use
 The default in HTTP1.1 is a persistent
connection
 When a web page is requested the client
requests a TCP connection to the Web server
 Many objects on the requested web page are
then transferred through that connection before
it is terminated.
Janice Regan © Sept. 2007-2013
31
Persistent connections
 In fact when the web page has been completely
sent the connection will remain open

It is likely if one page has been retrieved from the
server another will be retrieved soon after
 The connection can be terminated by the client
or the server, or will be closed after a
“reasonable” time has elapsed without any
traffic passing through the connection.
Janice Regan © Sept. 2007-2013
32
Persistent connection
Host A
(SYN)
Host B
(SYN, ACK)
(ACK)
HTTP GET request object 1
With Piggyback ACK
HTTP GET request object 1
Piggyback ACK object
HTTP GET request object n
Piggyback ACK object n-1
HTTP OK send object 1
Piggyback ACK of request

HTTP OK send object
n
(FIN, ACK)
Janice Regan © Sept. 2007-2013
(FIN)
(ACK)
May remain open
33
Persistent connections
 Each time an object is sent through a
persistent connection
 Send request for the object to the server
 Send back a response agreeing to
make/break connection (B-A)
 Send an acknowledgement that the object
has been received
 We wait for the first object to be received
before requesting the next object.
Janice Regan © Sept. 2007-2013
34
Efficiency: persistent connections
 The server must wait 1 RTT between the end of
transmitting one object and the start of
transmitting the next object

Transmission time plus ½ RTT for the end of the
message to reach the client,
 ½ RTT for the client to make the next request
 If we pipeline, that is allow the next request to
be made before finishing the present request
we can improve efficiency by removing the need
for this 1 RTT per object wait.
Janice Regan © Sept. 2007-2013
35
Pipelining
 A series of objects can be requested
 As the user’s agent tries to display a web
page it may encounter embedded objects
that need to be requested
 With pipelining these objects are requested
as soon as the agent knows they are needed.
 At the web server the requests are queued
and replied to (by sending the object)
sequentially
Janice Regan © Sept. 2007-2013
36
Pipelining
 A series of objects can be requested
 At the web server the requests are queued
and replied to sequentially
 As soon as the web server has transmitted
one object it can begin servicing the next
request (sending the next object)
 Eventually all requests have been serviced
and the connection becomes idle
 After the connection is idle for a short time
(usually 10s of seconds) it will be closed
Janice Regan © Sept. 2007-2013
37
Persistent connection pipelining
Host A
(SYN)
request object 1
Piggyback ACK
Host B
(SYN, ACK)
request object 2
send object
1

request object n
Transmission
time object 1
send object
Transmission
2
send object n time object n
Acknowledge
object n (ACK)
(FIN, ACK)
Janice Regan © Sept. 2007-2013
(FIN)
(ACK)
38