WIXLIB

Review of Previous Lecture Network access and physical media Internet structure and ISPs Delay & loss in packet-switched networks Protocol layers, service modelsSome slides are in courtesy of J. Kurose and K. Ross

Announcement Project1, ignore “go.sh udp server u 1500” Recitation materials online All find partners? Report to TA and getgroup IP address Room location: Tu. 381 and Th. 343.Confusing?

Application LayerOur goals: conceptual,implementation aspectsof network applicationprotocols learn about protocolsby examining popularapplication-levelprotocols– HTTP– transport-layerservice models– FTP– client-serverparadigm– DNS– peer-to-peerparadigm– SMTP / POP3 / IMAP programming networkapplications– socket API

Outline Principles of app layer protocols– clients and servers– app requirements Web and HTTP FTP Electronic Mail: SMTP, POP3, IMAP

Network applications: some jargonProcess: program runningwithin a host. within same host, twoprocesses communicateusing interprocesscommunication (definedby OS). processes running indifferent hostscommunicate with anapplication-layerprotocoluser agent: interfaceswith user “above” andnetwork “below”. implements userinterface & applicationlevel protocol– Web: browser– E-mail: mail reader– streaming audio/video:media player

Applications and application-layer protocolsApplication: communicating,distributed processes– e.g., e-mail, Web, P2P filesharing, instant messagingapplicationtransportnetworkdata linkphysical– running in end systems (hosts)– exchange messages toimplement applicationApplication-layer protocols– one “piece” of an app– define messages exchanged byapps and actions taken– use communication servicesprovided by lower layerprotocols (TCP, UDP)applicationtransportnetworkdata linkphysicalapplicationtransportnetworkdata linkphysical

App-layer protocol defines Types of messagesexchanged, eg, request &response messagesPublic-domain protocols: Syntax of message types:what fields in messages &how fields are delineated allows forinteroperability defined in RFCs eg, HTTP, SMTP Semantics of the fields, ie,Proprietary protocols:meaning of information infields eg, KaZaA Rules for when and howprocesses send & respondto messages

Client-server paradigmTypical network app has twopieces: client and serverClient:applicationtransportnetworkdata linkphysical initiates contact with server(“speaks first”) typically requests service fromserver Web: client implemented inbrowser; e-mail: in mail readerServer: provides requested service to client e.g., Web server sends requested Webpage, mail server delivers e-mailrequestreplyapplicationtransportnetworkdata linkphysical

Processes communicating across network process sends/receivesmessages to/from itssocket socket analogous to door– sending process shovesmessage out door– sending process asssumestransport infrastructureon other side of door whichbrings message to socketat receiving processhost orserverhost orserverprocesscontrolled byapp developerprocesssocketsocketTCP withbuffers,variablesInternetTCP withbuffers,variablescontrolledby OS API: (1) choice of transport protocol; (2) ability to fix afew parameters (lots more on this later)

Addressing processes For a process to receivemessages, it must have anidentifier Every host has a unique32-bit IP address Q: does the IP address ofthe host on which theprocess runs suffice foridentifying the process? Answer: No, manyprocesses can be runningon same host Identifier includesboth the IP addressand port numbersassociated with theprocess on the host. Example port numbers:– HTTP server: 80– Mail server: 25 More on this later

What transport service does an app need?Data loss some apps (e.g., audio) cantolerate some loss other apps (e.g., filetransfer, telnet) require100% reliable datatransferTiming some apps (e.g.,Internet telephony,interactive games)require low delay to be“effective”Bandwidth some apps (e.g.,multimedia) requireminimum amount ofbandwidth to be“effective” other apps (“elasticapps”) make use ofwhatever bandwidththey get

Transport service requirements of common appsData lossBandwidthTime Sensitivefile transfere-mailWeb documentsreal-time audio/videono lossno lossno lossloss-tolerantnononoyes, 100’s msecstored audio/videointeractive gamesinstant messagingloss-tolerantloss-tolerantno losselasticelasticelasticaudio: 5kbps-1Mbpsvideo:10kbps-5Mbpssame as abovefew kbps upelasticApplicationyes, few secsyes, 100’s msecyes and no

Internet transport protocols servicesTCP service:UDP service: connection-oriented: setuprequired between client andserver processes unreliable datatransfer betweensending and receivingprocess reliable transport betweensending and receiving process flow control: sender won’toverwhelm receiver congestion control: throttlesender when networkoverloaded does not providing: timing,minimum bandwidth guarantees does not provide:connection setup,reliability, flowcontrol, congestioncontrol, timing, orbandwidth guarantee

Internet apps: application, transport protocolsApplicatione-mailremote terminal accessWebfile transferstreaming multimediaInternet telephonyApplicationlayer protocolUnderlyingtransport protocolSMTP [RFC 2821]Telnet [RFC 854]HTTP [RFC 2616]FTP [RFC 959]proprietary(e.g. RealNetworks)proprietary(e.g., Dialpad)TCPTCPTCPTCPTCP or UDPtypically UDP

Outline Principles of app layer protocols– clients and servers– app requirements Web and HTTP FTP Electronic Mail: SMTP, POP3, IMAP

Web and HTTPFirst 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 includesseveral referenced objects Each object is addressable by a URL Example URL:www.someschool.edu/someDept/pic.gifhost namepath name

HTTP overviewHTTP: hypertext transferprotocol Web’s application layer protocol client/server model– client: browser that requests,receives, “displays” Webobjects– server: Web server sendsobjects in response torequests HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2068HTTPrequestPC running HTTPresExplorerponsesteuqrese ServerPnTorunningHTesprPTApache WebHTserverMac runningNavigator

HTTP overview (continued)Uses TCP:HTTP is “stateless” client initiates TCP connection(creates socket) to server,port 80 server maintains noinformation about pastclient requests server accepts TCP connectionfrom client HTTP messages (applicationlayer protocol messages)exchanged between browser(HTTP client) and Web server(HTTP server) TCP connection closedasideProtocols that maintain “state”are complex! past history (state) must bemaintained if server/client crashes,their views of “state” may beinconsistent, must bereconciled

HTTP connectionsNonpersistent HTTPPersistent HTTP At most one object issent over a TCPconnection. Multiple objects can besent over single TCPconnection betweenclient and server. HTTP/1.0 usesnonpersistent HTTP HTTP/1.1 usespersistent connectionsin default mode

Nonpersistent HTTP(contains text,Suppose user enters URLreferences to 10www.someSchool.edu/someDepartment/home.indexjpeg images)1a. HTTP client initiates TCPconnection to HTTP server(process) at www.someSchool.eduon port 802. HTTP client sends HTTPrequest message (containingURL) into TCP connectionsocket. Message indicatesthat client wants objectsomeDepartment/home.indextime1b. HTTP server at hostwww.someSchool.edu waitingfor TCP connection at port 80.“accepts” connection, notifyingclient3. HTTP server receives requestmessage, forms responsemessage containing requestedobject, and sends messageinto its socket

Nonpersistent HTTP (cont.)4. HTTP server closes TCP5. HTTP client receives responsemessage containing html file,displays html. Parsing html file,finds 10 referenced jpegobjectstime 6. Steps 1-5 repeated for eachof 10 jpeg objectsconnection.

Response time modelingDefinition of RRT: time to senda small packet to travel fromclient to server and back.Response time: one RTT to initiate TCPconnectioninitiate TCPconnectionRTT one RTT for HTTP requestand first few bytes of HTTPresponse to return file transmission timetotal 2RTT transmit timerequestfileRTTfilereceivedtimetime totransmitfiletime

Persistent HTTPNonpersistent HTTP issues:Persistent without pipelining: requires 2 RTTs per object client issues new requestonly when previousresponse has been received OS must work and allocatehost resources for each TCPconnection but browsers often openparallel TCP connections tofetch referenced objectsPersistent HTTP server leaves connectionopen after sending response subsequent HTTP messagesbetween same client/serverare sent over connection one RTT for eachreferenced objectPersistent with pipelining: default in HTTP/1.1 client sends requests assoon as it encounters areferenced object as little as one RTT for allthe referenced objects

HTTP request message two types of HTTP messages: request, response HTTP request message:– ASCII (human-readable format)request line(GET, POST,HEAD commands)GET /somedir/page.html HTTP/1.1Host: www.someschool.eduUser-agent: Mozilla/4.0header Connection: closelines Accept-language:frCarriage return,line feedindicates endof message(extra carriage return, line feed)

HTTP request message: general format

Uploading form inputPost method: Web page oftenincludes form input Input is uploaded toserver in entity bodyURL method: Uses GET method Input is uploaded in URLfield of request line:www.somesite.com/animalsearch?monkeys&banana

Method typesHTTP/1.0HTTP/1.1 GET GET, POST, HEAD POST PUT HEAD– asks server to leaverequested object out ofresponse– uploads file in entity bodyto path specified in URLfield DELETE– deletes file specified inthe URL field

HTTP response messagestatus line(protocolstatus codestatus phrase)headerlinesdata, e.g.,requestedHTML fileHTTP/1.1 200 OKConnection closeDate: Thu, 06 Aug 1998 12:00:15 GMTServer: Apache/1.3.0 (Unix)Last-Modified: Mon, 22 Jun 1998 .Content-Length: 6821Content-Type: text/htmldata data data data data .

HTTP response status codesIn first line in server- client response message.A few sample codes:200 OK– request succeeded, requested object later in this message301 Moved Permanently– requested object moved, new location specified later inthis message (Location:)400 Bad Request– request message not understood by server404 Not Found– requested document not found on this server505 HTTP Version Not Supported

Cookies: keeping “state”clientebay: 8734Cookie fileamazon: 1678ebay: 8734usual http request msgusual http response Set-cookie: 1678usual http request msgcookie: 1678usual http response msgCookie fileamazon: 1678ebay: 8734cookiespecificactionac cessacceone week later:enserverda try itab n bcreates IDas acekend1678 for userssCookie fileserverusual http request msgcookie: 1678usual http response msgcookiespectificaction

Cookies (continued)What cookies can bring: authorization shopping carts recommendations user session state (Web e-mail)

Conditional GET: client-side caching Goal: don’t send object ifclient has up-to-date cachedversion client: specify date ofcached copy in HTTP requestIf-modified-since: date server: response contains noobject if cached copy is upto-date:HTTP/1.0 304 NotModifiedserverclientHTTP request msgIf-modified-since: date HTTP responseobjectnotmodifiedHTTP/1.0304 Not ModifiedHTTP request msgIf-modified-since: date HTTP responseHTTP/1.0 200 OK data objectmodified

Outline Principles of app layer protocols– clients and servers– app requirements Web and HTTP FTP Electronic Mail: SMTP, POP3, IMAP

FTP: the file transfer protocoluserat hostFTPFTPuserclientinterfacefile transferlocal filesystemFTPserverremote filesystem transfer file to/from remote host client/server model– client: side that initiates transfer (either to/fromremote)– server: remote host ftp: RFC 959 ftp server: port 21