Application Layer 1 Goals: conceptual + implementation aspects of network application protocols ...

Application Layer 1

Application Layer

Goals: conceptual + implementation aspects of

network application protocolsclient-server paradigmpeer-to-peer (p2p) paradigm

learn about protocols by examining popular application-level protocols HTTP, FTP, SMTP, POP, DNS

Application Layer 2

Applications and application-layer protocolsApplication: communicating,

distributed processes running in network

hosts in “user space” exchange messages to

implement app e.g., email, file transfer,

p2p file share, the WebApplication-layer protocols

define messages exchanged by apps and actions taken

uses services provided by lower layer protocols

application

transportnetworkdata linkphysical

application


application


Application Layer 3

Client-server paradigm

Typical network app has two pieces: client and server

Client: initiates contact with server typically requests service

from server (e.g., request WWW page, send email)

Server: provides requested service

to client e.g., sends requested WWW

page, receives/stores received email

application


application


request

reply

Application Layer 4

Transport service requirements of appsData Delivery some apps (e.g., audio, video) can tolerate some

loss other apps (e.g., file transfer, telnet) require

100% reliable data transfer

Bandwidth some apps (e.g., multimedia) require minimum

amount of bandwidth to be “effective” other apps (“elastic apps”) make use of

whatever bandwidth they can get

Timing some apps (e.g., Internet telephony, interactive

games) require low delay to be “effective”

Application Layer 5

Transport service requirements of common apps

Application

file transfere-mail

Web documentsreal-time

audio/videostored audio/videointeractive games

financial apps

Data loss

no lossno lossno lossloss-tolerant

loss-tolerantloss-tolerantno loss

Bandwidth

elasticelasticelasticaudio: 5Kb-1Mbvideo:10Kb-5Mbsame as above few Kbps upelastic

Time Sensitive

nononoyes, 100’s msec

yes, few secsyes, 100’s msecyes and no

Application Layer 6

Services provided by Internet transport protocols

TCP service: connection-oriented: setup

required between client, server

reliable transport between sending and receiving process

flow control: sender won’t overwhelm receiver

congestion control: throttle sender when network overloaded

does not provide: timing, minimum bandwidth guarantees

UDP service: unreliable data transfer

between sending and receiving process

does not provide: connection setup, reliability, flow control, congestion control, timing, or bandwidth guarantee

Application Layer 7

Internet apps: application & transport protocols

Application

e-mailremote terminal access

Web file transfer

streaming multimedia

remote file serverInternet telephony

Applicationlayer protocol

SMTP [RFC 821]Telnet [RFC 854]HTTP [RFC 2068]FTP [RFC 959]proprietary(e.g. Windows Media)NFSproprietary(e.g., Vocaltec)

Underlyingtransport protocol

TCPTCPTCPTCPTCP or UDP

TCP or UDPtypically UDP

Application Layer 8

WWW: the HTTP protocolHTTP: HyperText

Transfer Protocol WWW’s application layer

protocol client/server model

client: browser that requests, receives, “displays” WWW objects

server: WWW server sends objects in response to requests

HTTP/1.0: RFC 1945 HTTP/1.1: RFC 2068

PC runningExplorer

Server runningApache

Webserver

Mac runningNavigator

http request

http re

quest

http response

http re

sponse

Application Layer 9

HTTPTCP transport service: client initiates a TCP

connection to server, port 80

server accepts TCP connection from client

http messages (application-layer protocol messages) exchanged between browser and WWW 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 recovered

aside

Application Layer 10

HTTP exampleSuppose user enters URL

www.someUniv.ac.kr/someDepartment/index.html

1a. HTTP client initiates TCP connection to HTTP server (process) at www.someUniv.ac.kr. Port 80 is default for HTTP server.

2. HTTP client sends HTTP request message (containing URL) into TCP connection socket

1b. HTTP server at host www.someUniv.ac.kr waiting for TCP connection at port 80. “accepts” connection, notifying client

3. HTTP server receives request message, forms response message containing requested object (someDepartment/index.html), sends message into socket

time

(contains text, references to 10

jpeg images)


HTTP example (cont.)

non-persistent connection: one object in each TCP connection some browsers create multiple TCP connections

simultaneously - one per object (HTTP/1.0) persistent connection: multiple objects transferred

within one TCP connection (HTTP/1.1)

5. HTTP client receives response message containing HTML file, displays HTML. Parsing HTML file, finds 10 referenced jpeg objects

6. Steps 1-5 repeated for each of 10 jpeg objects

4. HTTP server closes TCP connection.

time


HTTP message format: Request two types of HTTP messages: request,

response HTTP request message:

ASCII (human-readable format)

GET /somedir/page.html HTTP/1.1 Connection: close User-agent: Mozilla/4.0 Accept: text/html, image/gif,image/jpeg Accept-language:fr

(extra carriage return, line feed)

request line(GET, POST,

HEAD commands)

header lines

Carriage return, line feed

indicates end of message


HTTP request message: general format


HTTP message format: Reply

HTTP/1.1 200 OK Connection: close Date: Fri, 12 May 2000 12:30:00 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html

data goes here ...

status line(protocol

status codestatus phrase)

header lines

data, e.g., requestedhtml file


HTTP reply status codesIn the first line of response message. 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

304 Not Modified requested document has not been modified (Conditional

GET)

505 HTTP Version Not Supported


User-server interaction: conditional GET

Goal: don’t send object if client has up-to-date stored (cached) version

client: specify date of cached copy in HTTP requestIf-modified-since: <date>

server: response contains no object if cached copy up-to-date: HTTP/1.0 304 Not Modified

client server

http request msgIf-modified-since:

<date>

http responseHTTP/1.0

304 Not Modified

object not

modified

http request msgIf-modified-since:

<date>

http responseHTTP/1.1 200 OK

…

<data>

object modified


User-server interaction: Authentication

Goal: control access to server documents

stateless: client must present authorization in each request

authorization: typically name, password authorization: header

line in request if no authorization

presented, server refuses access, sendsWWW authenticate:

header line in response

client server

usual http request msg401: authorization req.

WWW authenticate:

usual http request msg

+ Authorization:lineusual http response

msg


+ Authorization:lineusual http response

msg

time


User-server interaction: CookiesCookies is a way of

remembering things for you (e.g., authentication, user preferences, previous choices)

server sends “cookie” to client in responseSet-cookie: #

client present cookie in later requestscookie: #

server matches presented-cookie with server-stored cookies

client server

usual http request msgusual http response

+Set-cookie: #


cookie: #usual http response

msg


cookie: #usual http response msg

cookie-specificaction

cookie-specificaction


Web Caching

user sets browser: WWW accesses via web cache

client sends all HTTP requests to web cache if object at web cache,

web cache immediately returns object in HTTP response

else requests the object from origin server, saves it in the cache, then returns object in HTTP response

Goal: satisfy client request without involving origin server

client

Cacheserver

client

http request

http re

quest

http response

http re

sponse

http re

quest

http re

sponse

http requesthttp response

origin server

origin server


Why Web Caching?

Assume: cache is “close” to client (e.g., in the same network)

faster response time: cache “closer” to client

decrease traffic to distant servers link out of enterprise

network often bottleneck

Cache server farm could be deployed to distribute load thus to increase performance

originservers

public Internet

enterprisenetwork 100 Mbps LAN

T1 Internetlink enterprise

cache server


FTP: the file transfer protocol

transfer file to/from remote host client/server model

client: side that initiates transfer (either to/from remote)

server: remote host FTP: RFC 959 FTP server: port 21

file transfer FTPserver

FTPuser

interface

FTPclient

local filesystem

remote filesystem

user at host


FTP: separate control, data connections

FTP client contacts FTP server at port 21, specifying TCP as transport protocol

two parallel TCP connections opened: control: exchange

commands, responses between client, server.“out of band control”

data: file data to/from server using port 20

ftp server maintains “state”: current directory, earlier authentication

FTPclient

FTPserver

TCP control connection

port 21

TCP data connectionport 20


Active Mode vs. Passive Mode FTP

Passive Mode FTP when client is located inside a firewall. Use dynamically generated port number instead of 20 Cannot detect the FTP data transfer by the packet header only

Visit http://slacksite.com/other/ftp.html for detailed explanation

client FTP Server

21connect2834

connect

Active Mode

accept

active mode 2835

202835 data transfer202835

21acceptdisconnect2834

client FTP Server

21connect2834

connect

Passive Mode

accept

passive mode request

38482835 data transfer38482835

21acceptdisconnect2834

passive mode 3848


Analysis of Passive FTP traffic Use the same mechanism as the multimedia

traffic analysis Examination of FTP control packet payload The payload data from a FTP server to a FTP client

IP, TCP Header FTP Payload

227 Entering Passive Mode (141,223,82,141,128,40)

The IP address of the FTP server = 141.223.82.141

The port number of the FTP server for data transfer = 128 * 256 + 40 = 32808


Electronic MailThree major

components: user agents mail servers simple mail transfer

protocol (SMTP) is used between mail servers

User Agent a.k.a. “mail reader” composing, editing,

reading mail messages e.g., Outlook, elm, mutt also uses SMTP between

agent and server

user mailbox

outgoing message queue

mailserver

useragent

useragent

useragent

mailserver

useragent

useragent

mailserver

useragent

SMTP

SMTP

SMTP


Electronic Mail: mail servers

Mail Servers mailbox contains

incoming messages (yet to be read) for users

message queue of outgoing (to be sent) mail messages

smtp protocol between mail servers to send email messages client: sending mail

server “server”: receiving

mail server

mailserver

useragent

useragent

useragent

mailserver

useragent

useragent

mailserver

useragent

SMTP

SMTP

SMTP


Electronic Mail: SMTP [RFC 821]

uses TCP to reliably transfer email msg from client to server, port 25

direct transfer: sending server to receiving server

three phases of transferhandshaking (greeting)transferclosure

command/response interactioncommands: ASCII textresponse: status code and phrase


Mail message formatRFC 822: standard for

text message format:

header lines To: From: Subject:

body the “message”,

ASCII characters only line containing only

`.’

header

body

.

blankline


Message format: multimedia extensions MIME: Multipurpose Internet Mail Extension, RFC

2045, 2056 MIME content type declared in msg header

From: [email protected] To: [email protected] Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg

base64 encoded data ..... ......................... ......base64 encoded data .

multimedia datatype, subtype,

parameter declaration

method usedto encode data

MIME version

encoded data


MIME typesText example subtypes: plain, html

Image example subtypes: jpeg, gif

Audio example subtypes: basic (8-bit mu-law encoded), 32kadpcm (32 kbps coding)

Video example subtypes: mpeg, quicktime

Application other data that

must be processed by reader before “viewable”

example subtypes: msword, octet-stream


Mail access protocols

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

useragent

sender’s mail server

useragent

SMTP SMTP POP3 orIMAP

receiver’s mail server


POP3 protocolauthorization phase client commands:

user: username pass: password

server responses +OK -ERR

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 alice S: +OK C: pass hungry S: +OK user successfully logged on

transaction phase, client:

list: list message numbers

retr: retrieve message by number

dele: delete quit


IMAP More functionalities than POP

users can manipulate messages on server, e.g., to create hierarchy of folders

folders organization accessed from all user’s machines (office, @home, mobile)

users can retrieve only part(s) of a multipart message, e.g., downloading in a small portable terminal only header or text part of a multimedia message.

More complex server maintains state, e.g., hierarchy of

folders for each user


Web Mail

Convenient for the user on the go (Internet Café, WebTV, …)

User can organize their hierarchy of folders on servers

May be slow: server typically far from client interaction with server through CGI scripts

useragent

ordinaryWeb browsersender’s mail

server

useragent

ordinaryWeb browser

HTTP SMTP HTTP

receiver’s mail 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., www.postech.ac.kr - used by humans

Q: map between IP addresses and name ?

Domain Name System: distributed database

implemented in hierarchy of many name servers

application-layer protocol host, routers, name servers

to communicate to resolve names (address/name translation) note: core Internet function

implemented as application-layer protocol

complexity at network’s “edge”


DNS name servers

no server has all name-to-IP address mappings

local name servers: each ISP, company has

local (default) name server

host DNS query first goes to local name server

authoritative name server: for a host: stores that

host’s IP address, name can perform

name/address translation for that host’s name

Why not centralize DNS? single point of failure traffic volume distant centralized

database maintenance

Just doesn’t scale!


DNS: Root name servers contacted by local

name server that can not resolve name

root name server: contacts

authoritative name server if name mapping not known

gets mapping returns mapping

to local name server

13 root name servers worldwide


Simple DNS example

host surf.eurecom.fr wants IP address of gaia.cs.umass.edu

1. Contacts its local DNS server, dns.eurecom.fr

2. dns.eurecom.fr contacts root name server, if necessary

3. root name server contacts authoritative name server, dns.umass.edu, if necessary

requesting hostsurf.eurecom.fr

gaia.cs.umass.edu

root name server

authorititive name serverdns.umass.edu

local name serverdns.eurecom.fr

1

23

4

5

6


DNS example

Root name server:

may not know authoritative name server

may know intermediate name server: who to contact to find authoritative name server


gaia.cs.umass.edu

root name server


1

23

4 5

6

authoritative name serverdns.cs.umass.edu

intermediate name serverdns.umass.edu

7

8


DNS: iterated queriesrecursive query: puts burden of

name resolution on contacted name server

heavy load?

iterated query: contacted server

replies with name of server to contact

“I don’t know this name, but ask this server”


gaia.cs.umass.edu

root name server


1

23

4

5 6

authoritative name serverdns.cs.umass.edu

intermediate name serverdns.umass.edu

7

8

iterated query


DNS: caching and updating records once (any) name server learns

mapping, it caches mappingcache entries timeout (disappear)

after some time DNS Related RFCs -

http://www.zoneedit.com/doc/rfc/


DNS records

DNS: distributed db storing resource records (RR)

Type=NS name is domain (e.g.

foo.com) value is IP address of

authoritative name server for this domain

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

Type=A name is hostname value is IP address

Type=CNAME name is an alias name

for some “cannonical” (the real) name

value is cannonical name

Type=MX value is hostname of

mailserver associated with name


DNS protocol, messages

DNS protocol : query and repy messages, both with the same message format

msg header identification: 16 bit #

for query, repy to query uses same #

flags: query or reply recursion desired recursion available reply is authoritative


DNS protocol, messages

Name, type fields for a query

RRs in reponseto query

records forauthoritative servers

additional “helpful”info that may be used


Peer-to-peer (P2P) paradigm

Server

Client-Server ArchitectureClient-Server Architecture

Client

ClientClient

Client

Peer

Peer

PeerPeer

Peer

P2P ArchitectureP2P Architecture

Peer has the functionality of both client and server


Why peer-to-peer (P2P)? The information creation, distribution and

consummation are ideally a decentralized and distributed process

The relationship between consumer and producer of information normally is peer to peer

Popular P2P applicationso Instant Messaging – MSN/Yahoo Messengers, ICQ, etc.o File Sharing – WinMX, Kazaa, Morpheus, e-donkey, V-

share, BitTorrent, etc.

P2P apps use proprietary, Freenet, Gnutella, FastTrack, BitTorrent protocols


P2P Profit Model

Infrastructure

Intermediary

CPU 공유Hard Disk 공유

Company’sInfrastructure

Providing

Commerce

ContentsDistribution

Service Model Profit ModelApplication

중고 매매

복덕방

벼룩시장

광고Payment

Web HardSuper

Computing

TemporaryBack Up

Video Conference

Messenger

Collaboration

File Sharing

ContentsDistribution

File Sharing

DRM

KMS

GroupWare

EDMS

SCM

Commerce

B2B B2CC2C

P2P 결재수수료

컨텐츠유통 수수료

CP가입비

P2P 광고

B2B,B2CInfra 제공 광고

가입비 / 수수료

InternetInfrastructure

By Product

SI

VideoConference

CollaborationComponent

LocalSearch Engine

Many businesses are attempting to utilize P2P for commercial purposes


Summary Learned the conceptual +

implementation aspects of network application protocolsclient-server paradigmpeer-to-peer (p2p) paradigm

Learned about protocols by examining popular application-level protocols HTTP, FTP, SMTP, POP, DNS

Application Layer 1 Goals: conceptual + implementation aspects of network application protocols ...

Documents

Transcript of Application Layer 1 Goals: conceptual + implementation aspects of network application protocols ...