Chapter2_Session1.pdf

8/10/2019 Chapter2_Session1.pdf

1/47

2: Application Layer 1

Chapter 2

Application Layer

Computer Networking:A Top Down Approach,4thedition.Jim Kurose, Keith RossAddison-Wesley, July2007.

A note on the use of these ppt slides:Were making these slides freely available to all (faculty, students, readers).Theyre in PowerPoint form so you can add, modify, and delete slides(including this one) and slide content to suit your needs. They obviously

represent a lotof work on our part. In return for use, we only ask thefollowing:

!

If you use these slides (e.g., in a class) in substantially unaltered form,that you mention their source (after all, wed like people to use our book!)! If you post any slides in substantially unaltered form on a www site, that

you note that they are adapted from (or perhaps identical to) our slides, andnote our copyright of this material.

Thanks and enjoy! JFK/KWR

All material copyright 1996-2007

J.F Kurose and K.W. Ross, All Rights Reserved


2/47


Killer Apps

1970s-1980s! Text e-mail, remote access, file transfer,

newsgroup, text chat

mid-1990s!

World Wide Web, search, electronic commerceEnd of the millennium! Instant message, P2P file sharing

2000s! Internet telephony, video sharing and streaming,

Internet radio and IPTV, wireless access


3/47


Chapter 2: Application layer

! 2.1 Principles ofnetwork applications

! 2.2 Web and HTTP

!

2.3 FTP! 2.4 Electronic Mail

" SMTP, POP3, IMAP

! 2.5 DNS

! 2.6 P2P Applications! 2.7 Socket programming

with TCP

!

2.8 Socket programmingwith UDP


4/47


Chapter 2: Application Layer

Our goals:! conceptual,

implementationaspects of network

application protocols" networking

service models

" client-server

paradigm" peer-to-peer

paradigm

!

learn about protocolsby examining popularapplication-levelprotocols

" HTTP

" FTP" SMTP / POP3 / IMAP

" DNS

!

programming networkapplications

" socket API


5/47


Creating a network app

Write programs that" run on (different) end

systems" communicate over network" e.g., web server software

communicates with browser

software

Dont need to write software fordevices in network core" network core devices do not

run user applications" confining applications on end

systems has facilitated therapid app development,propagation

applicationtransportnetworkdata link

physical

applicationtransportnetwork

data linkphysical

applicationtransportnetworkdata linkphysical


6/47


Application architectures

Designed by application developer and dictatehow the application is structed over thevarious end systems

!

Client-server! Peer-to-peer (P2P)

! Hybrid of client-server and P2P


7/47


Client-server architecture

server:" always-on host

" permanent IP address

" server farms for scaling,infrastructure intensive

clients:" communicate with server

" may be intermittentlyconnected

" may have dynamic IPaddresses

" do not communicate directlywith each other

client/server


8/47


!

Server farm: a cluster of hosts" Powerful virtual server to support many reqests

" Infrastructure intensive --- costly

Service providers to purchase, install and maintainserver farms

Also pay recurring interconnection and bandwidthcosts for sending receiving data

Search engine: Google, BaiduInternet commerce: Amazon, e-Bay

Web-based email: Yahoo Mail, Gmail

Social network: facebook

Video sharing: YouTube

Client-server architecture


9/47

Google Data Centers

!

Estimated cost of data center: $600M

! Google spent $2.4B in 2007 on new datacenters

!

Each data center uses 50-100 megawattsof power


10/47


Pure P2P architecture! noalways-on server

!

arbitrary end systems directlycommunicate

!

peers are intermittentlyconnected and change IPaddresses

!

Traffic-intensive applications:" File distribution: BitTorrent

" IPTV: PPlive

Self-scalability: add service capacity tothe system by distributing files topeers

Cost effective: dont require significantserver infrastructure and serverbandwidth

But secure problem and difficult to

manage

peer-peer


11/47


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 centralserver when it comes online

user contacts central server to find IPaddresses of buddies


12/47


Processes communicating

Process:program runningwithin a host.

! within same host, twoprocesses communicateusing inter-processcommunication(definedby OS).

! processes in different

hosts communicate byexchanging messages

Client process:processthat initiatescommunication

Server process:process

that waits to becontacted

! Note: applications with

P2P architectures haveclient processes &server processes


13/47


Interface between the process andthe computer network: Sockets

!

process sends/receivesmessages to/from itssocket---softwareinterface

!

socket analogous to door" sending process shoves

message out door" sending process relies on

transport infrastructure

on other side of door whichbrings message to socketat receiving process

process

TCP with

buffers,

variables

socket

host orserver

process

TCP with

buffers,

variables

socket

host orserver

Internet

controlledby OS

controlled by

app developer

! API: (1) choice of transport protocol; (2) ability to fixa few parameters (maximum buffer, maximum

segment sizes)


14/47


Addressing processes

How does a process indicate which process it wants tocommunicate with using these services?

To identify the receiving process, two pieces of

information need to be specified1. The name or address of the host--- host device has unique 32-bit IP address

2. The identifier that specifies the receiving process

in the destination host--- port number


15/47


Addressing processes!

identifierincludes both IP addressand port numbersassociated with process on host.

! Example port numbers:" HTTP server: 80" Mail server: 25

! to send HTTP message to gaia.cs.umass.edu webserver:" IP address:128.119.245.12" Port number:80


16/47


App-layer protocol defines

! Types of messagesexchanged," 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

Public-domain protocols:! defined in RFCs

! allows for

interoperability! e.g., HTTP, SMTP

Proprietary protocols:! e.g., Skype


17/47


What transport service does an app need?Reliable Data Transfer!

some apps (e.g., audio) can toleratesome loss

! other apps (e.g., file transfer,telnet) require 100% reliable datatransfer

Timing! some apps (e.g., Internet

telephony, interactive games)require low delay to beeffective

Throughput/Bandwidth: the rate at

which the sending process candeliver bits to the receiving process--- fluctuate with time

! some apps (e.g., multimedia) requireminimum amount(32kbps for voice

encoding) of bandwidth to beeffective

!

other apps (elastic apps) make useof whatever bandwidth they get

Security! Confidentiality: encrypt/decrypt! Data integrity and end-point

authentication


18/47


Transport service requirements of common apps

Application

file transfer

e-mail

Web documentsreal-time audio/video

stored audio/video

interactive games

instant messaging

Data loss

no loss

no loss

no lossloss-tolerant

loss-tolerant

loss-tolerant

no loss

Bandwidth

elastic

elastic

elasticaudio: 5kbps-1Mbps

video:10kbps-5Mbps

same as above

few kbps up

elastic

Time Sensitive

no

no

noyes, 100s msec

yes, few secs

yes, 100s msec

yes and no


19/47


Internet transport protocols servicesTCP service:! connection-oriented:client and

server exchange transport layercontrol info. with each othersetup before app. level messagesbegin to flow" After handshaking, a TCP connection

is said to exist between the sockets

of the two processes" Connection is full-duplex

! reliable transport : without errorand in the proper order betweensending and receiving process

!

flow control:sender wontoverwhelm receiver! congestion control:throttle

sender when network overloaded

! does not provide:timing,minimum bandwidth guarantees

UDP service: lightweight

protocol! No handshaking! unreliable data transfer

between sending andreceiving process

!

does not provide: connectionsetup, reliability, flowcontrol, congestion control,timing, or bandwidthguarantee

Q:why bother? Why is there aUDP?


20/47


Internet apps: application, transport protocols

Application

e-mail

remote terminal access

Webfile transfer

streaming multimedia

Internet telephony

Applicationlayer protocol

SMTP [RFC 2821]

Telnet [RFC 854]

HTTP [RFC 2616]FTP [RFC 959]

HTTP, RTP

(e.g. YouTube)

SIP, RTP or proprietary

(e.g., skype)

Underlyingtransport protocol

TCP

TCP

TCPTCP

TCP or UDP

typically UDP


21/47


App-layer protocols!

An app-layer protocoldefines how an appsprocesses, running ondifferent end system, passmessages to each other:"

Types of messages exchanged,

e.g., request, response" Message syntax:

what fields in messages & howfields are delineated

" Message semantics meaning of information in fields

" Rules for when and how

processes send & respond tomessages

Public-domain protocols:! defined in RFCs

! allows for

interoperability! e.g., HTTP, SMTP

Proprietary protocols:! e.g., Skype


22/47


Chapter 2: Application layer

! 2.1 Principles ofnetwork applications" app architectures

" app requirements

!

2.2 Web and HTTP! 2.3 FTP

! 2.4 Electronic Mail" SMTP, POP3, IMAP

! 2.5 DNS

! 2.6 P2P file sharing! 2.7 Socket programming

with TCP

!

2.8 Socket programmingwith UDP


23/47


Web and HTTP (HyperText Transfer Protocol)

1994, Berners-Lee, World Wide Web: the applicationthat elevated the Internet from just one of many datanetworks to essentially the one and only one datanetwork" Operate on demand: users receive what they want, when they

want it" enormously easy for any individual to make information

available over the web

" Hyperlinks and search engines help us navigate through anocean of web sites

! HTTP: the webs application-layer protocol" The heart of the Web [RFC 1945, RFC 2616]

" Implemented in two programs: client and server program, executing

on different end systems, talk to each other by exchanging HTTPmessages


24/47

WEB


First some jargon!

Web pageconsists of objects

! An object is a file: can be HTML file, JPEG image, Javaapplet, audio file,

! Web page consists of base HTML-filewhich includes

several referenced objects! Each object is addressable by a URL (Uniform Resource

Locator) that has three components

! Example URL:

http://www.someschool.edu/someDept/pic.gif

host name of the server objects path nameprotocol


25/47


HTTP overview

HTTP: hypertext transferprotocol, defines how Webclients request Web pagesfrom Web servers and howservers transfer Web pagesto clients

!

Webs application layerprotocol --- at the heart ofthe Web" define message structure

" exchange of the messages

!

client/server model" client:browser that

requests, receives,displays Web objects

" server:Web server sendsobjects in response to

requests

PC runningExplorer

Server (running Apache Web Server orMicrosoft Internet Information Server):

Implement the server side of HTTPHouse Web objects, each addressable by a URL

Mac runningNavigator

HTTP 1.0: RFC 1945

HTTP 1.1: RFC 2068


26/47


HTTP overview (continued)

Uses TCP as underlyingtransport protocol:

! client initiates TCPconnection (creates socket)

to server, port 80!

server accepts TCPconnection from client

!

HTTP messages (application-layer protocol messages)

exchanged between browser(HTTP client) and Webserver (HTTP server)

! TCP connection closed

HTTP is stateless!

server maintains noinformation aboutpast client requests

Protocols that maintainstate are complex!

! past history (state) mustbe maintained

!

if server/client crashes,their views of state maybe inconsistent, must bereconciled

aside


27/47


HTTP connections

Nonpersistent HTTP!

At most one object issent over a TCPconnection.

! HTTP/1.0 usesnonpersistent HTTP

Persistent HTTP! Multiple objects can

be sent over singleTCP connectionbetween client andserver.

! HTTP/1.1 usespersistent connections

in default mode

Client-server interaction is

taking place over TCP! Series of requests made back-to-

back, periodically at regularintervals, or intermittently

Q: should each request/response pair

be sent over separate TCP connectionor all over the same TCPconnection?


28/47


Nonpersistent HTTPSuppose user enters URL www.someSchool.edu/

someDepartment/home.index

1a.HTTP client initiates TCPconnection to HTTP server(process) at

www.someSchool.edu on port 80

2.HTTPclient sends HTTPrequest message(containingURL) into TCP connection

socket. Message indicatesthat client wants objectsomeDepartment/home.index

1b.HTTPserver at hostwww.someSchool.edu waiting

for TCP connection at port 80.accepts connection, notifyingclient

3.HTTPserver receives request

message, forms responsemessagecontaining requestedobject, and sends messageinto its socket

time

(contains HTML file,references to 10

jpeg images)


29/47


Nonpersistent HTTP (cont.)

5.HTTP client receives responsemessage containing html file,displays html. Parsing htmlfile, finds 10 referenced jpegobjects

6.Steps 1-5 repeated for eachof 10 jpeg objects

4.HTTPserver closes TCPconnection.

time

Q:10 JPEG objects obtained

over 10 serial TCPconnections, or over parallelTCP connections?

" Most browsers open 5-10parallel connections


30/47


Non-Persistent HTTP: Response time

Definition of RTT:time to senda small packet to travel fromclient to server and back." Propagation delay, queuing

delay, packet-processing delays

Response time:! one RTT to initiate TCP

connection

! one RTT for HTTP request

and first few bytes of HTTPresponse to return

! file transmission timetotal = 2RTT+transmit time of

the requested file

time totransmitfile

initiate TCPconnection

RTT

requestFile + ack

RTT

entire filereceived

time time


31/47


32/47


Persistent HTTP

Nonpersistent HTTP issues:!

requires 2 RTTs per object! OS overhead for eachTCP

connection

! browsers often open parallel

TCP connections to fetchreferenced objects

Persistent HTTP

! server leaves connectionopen after sending response

! subsequent HTTP messagesbetween same client/serversent over open connection

Persistent withoutpipelining:! client issues new request

only when previousresponse has been received

! one RTT for each

referenced objectPersistent withpipelining:

!

default in HTTP/1.1

! client sends requests assoon as it encounters areferenced object

!

as little as one RTT for allthe referenced objects


33/47


HTTP request message

! two types of HTTP messages: request, response! HTTP request message:

" ASCII (human-readable format)

GET /somedir/page.html HTTP/1.1

Host: www.someschool.edu

User-agent: Mozilla/4.0

Connection: close

Accept-language:fr

(extra carriage return, line feed)

request line(Method: GET, POST,

HEAD commands)

header

lines

Carriage return,line feed

indicates end

of message

doesnt want

persistent connections

Can send different versionsto diff. types of agents


34/47


HTTP request message: general format

Request lineGET: requests an object; POST: uploads a form,e.g., when a userprovides search words to a search engineHEAD: as GET but no requested object in response, for debug


35/47


Method types

HTTP/1.0! GET

! POST!

HEAD" asks server to leave

requested object out ofresponse

HTTP/1.1! GET, POST, HEAD

! PUT" uploads file in entity body

to a specific path on aspecific Web server(specified in URL field)

! DELETE

" deletes file on a Webserver (specified in theURL field)


36/47


HTTP response message

HTTP/1.1 200 OK

Connection close

Date: Thu, 06 Aug 1998 12:00:15 GMT

Server: Apache/1.3.0 (Unix)

Last-Modified: Mon, 22 Jun 1998 ...

Content-Length: 6821

Content-Type: text/html

data data data data data ...

status line(protocol,status code,

status phrase)

headerlines

Entity body:

data, e.g.,requestedHTML file


37/47


HTTP response status codes

200 OK"

request succeeded, requested object later in this message301 Moved Permanently

" requested object moved, new URL is specified in Location:header of the response message. The client software willautomatically retrieve the new URL

400 Bad Request" request message not understood by server

404 Not Found" requested document not found on this server

505 HTTP Version Not Supported

In first line in server->client response message." Indicate the result of a request

A few sample codes:


38/47


User-Server Interaction:Cookies!

Stateless HTTP server is simple with highperformance, but it is often desirable for aWeb site to identify users

" To restrict user access" To serve content as a function of the user

identity

! Defined in RFC 2965"

Allow sites to keep track of users


39/47


User-server state: cookies

Many major Web sitesuse cookies

Four components:1) cookie header line of

HTTP responsemessage2) cookie header line inHTTP requestmessage

3) cookie file kept onusers host, managed byusers browser

4) back-end database atWeb site

Example:! Susan always access

Internet always from PC

! visits specific e-

commerce site for firsttime

! when initial HTTPrequests arrives at site,

site creates:" unique ID

" entry in backenddatabase for ID


40/47


Cookies: keeping state (cont.)client

server

usual http response msg

usual http response msg

cookie file

one week later:

usual http request msgcookie: 1678 cookie-

specificaction

access

ebay 8734usual http request msg Amazon server

creates ID1678 for usercreate

entry

usual http responseSet-cookie: 1678

ebay 8734amazon 1678

usual http request msgcookie: 1678 cookie-

spectificaction

accessebay 8734

amazon 1678

backenddatabase


41/47


Cookies (continued)

What cookies can bring:! 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 stateat sender/receiver over multipletransactions

! cookies: http messages carry state


42/47


Web caches (proxy server)

! Network entity

" Has its own disk storage,keeps copies of recentlyrequested objects

!

browser sends all HTTPrequests to cache" object in cache: cache

returns object

" else cache requestsobject from origin server,then returns object toclient over the existingTCP connection

Goal:satisfy client request without involving origin server

client

Proxy

server

clientoriginserver

originserver


43/47


Benefit of Caches: an example

Assumptions! average object size = 1Mbits! avg. request rate from institutions browsers

to origin servers = 15/sec! delay from router on the Internet side of

access link to any origin server and back torouter (Internet delay) = 2 sec

! total delay = Internet delay + access delay

(delay between two routers) + LAN delayConsequences! traffic intensity on the LAN = (15req/

sec*1Mbits/req)/100Mbps = 0.15 (tens ofmillisecond)

! traffic intensity on access link = (15req/

sec*1Mbits/req)/15Mbps = 1 (very large andgrows without bound)! avg: the order of minutes)! total delay = Internet delay + access delay +

LAN delay= 2 sec + minutes + milliseconds

originservers

publicInternet

institutionalnetwork 100Mbps LAN

15 Mbpsaccess link


44/47


Caching example (cont)

possible solution!

increase bandwidth of accesslink to, say, from 15Mbps to100 Mbps

consequence!

traffic intensity(utilization) onLAN = 0.15

! traffic intensity on access link =0.15

! Total delay = Internet delay +

access delay + LAN delay= 2 sec + msecs + msecs

! often a costly upgrade

origin

serverspublic

Internet

institutionalnetwork 100 Mbps LAN

15->100 Mbpsaccess link


45/47


More about Web caching

! cache acts as bothclient and server

! typically cache isinstalled by ISP

(university, company,residential ISP)

Why Web caching?


46/47


Caching example (cont)

possible solution: installcache!

suppose hit rate is 0.4

consequence! 40% requests will be satisfied

almost immediately! 60% requests satisfied by origin

server" traffic intensity reduced from 1 to

0.6, delay is about tens of ms

! utilization of access link reducedto 60%, resulting in negligibledelays (say 10 of msec)

! total avg delay = Internet delay+ access delay + LAN delay =0.6*(2.01) secs +0.4*(0.01)seconds =~ 1.2 secs" Lower response time than the

upgrade solution"

Save cost

origin

serverspublic

Internet

institutionalnetwork 100 Mbps LAN

15 Mbpsaccess link

institutionalcache


47/47

Why Web caching?!

reduce response time for client request

! reduce traffic on an institutions access link to theInternet

" The institution does not have to upgrade bandwidth asquickly

!

reduce Web traffic in the Internet as a whole: enablespoor content providers to effectively deliver content

Chapter2_Session1.pdf

Documents