2 장 Application Layer

Principles of Application Layer Protocols

• Net applications are core of a computer net

• A process : a program that is running within an end sysem

• application layer protocol : define the format and order of the messages exchanged between processes and the actions taken on the transmission or receipt of a message

Application layer Protocols

• Network applications and application layer protocols

• application layer protocol : a piece of a network application

• Web application : a standard for documentformats, web browsers, web servers, an application layer protocol

Application layer protocol defines

• The types of messges exchanged

• the syntax of the various message types

• the semantics of the fileds

• rules for determining when and how a process sends messages and responds to messages

• Clients and servers

• the host that initiates the session is labeled the client

• Processes communication across a network– through sockets : interface between application

layer and transport layer– see fig 2.1– API

Addressing processes

• To identify the receiving process– the name or address of the host machine– an identifier that specifies the identity of the recei

ving process on the desitination host– IP address : 32bit that uniquely identifies the end

system– port number : the appropriate process on the desti

nation host – well-known port in RFC 1700

User agents

• An interface between the user and the network application

• In the web, browser is an user agent

What services does an application need?

• Data loss

• bandwidth

• timing

• see fig 2.2

Services provided by the Internet Transport Protocol

• TCP – a connection oriented service and a reliable data tra

nsfer sevice– tcp does no guarantee a minimum transmission rate

: regulated by congestion control– tcp does not provide any delay guarantees

• UDP– connectionless, no handshaking– unreliable data tranfer

• see fig 2.3

World wid web : http

• HTTP– defines the structure of these messages and how

the client and server exchange the messages– object : simply a file : html file, jpeg image 등– URL : host name of server, and object’s path– browser, server– see fig 2.4– uses TCP : slow start– stateless protocol

Nonpersistent and Persistent Connections

• Nonpersitent connections : a base HTML file and 10 JPEG images, on the same server– client initiates a tcp connection to the server– client sends a request message into the socket– server receives the request message via the socket, r

etrives the object from its storage, encapsulates it in a response message, and sends it into tcp connection

– server tells tcp to closed the connection– client receivs the response message. Connection ter

minates

– The message indicates that the encapsulated object is an html file.

– The client extracts the file from the response message, parses the html file, and finds references to the 10 JPEG objects

– repeat the steps for each of the referenced JPG objects

• Shortcomings– a brand new connectin must be established and

maintained for each requested object– each object suffers two RTT– each object suffers from TCP slow start

• Persistent connections– server leaves the TCP connection open after sen

ding responses– without pipelining and with pipelining– without : client issues a new request only when

the previous response has been received, and wastes server resources(no action after sending response)

– with : client issues a request as soon as it encounters a reference

HTTP message format

• Request messageGET /somedir/page.html HTTP/1.1 --> request line

Connection : close ----> heaer line from here

User-agent : Mozilla/4.0

Accept : text/html, image/gif, image/jpeg

Accept-language : fr

(extra carriage returen, line feed)

• see fig 2.5

• Response messageHTTP/1.1 200 OK --> status lineConnection : close ---> header lineDate : Thu, 06 Aug 1998 12:00:15 GMTServer : Apache/1.3.0 (Unix)Last-Modefied : Mon, 22 Jun 1998 09:23:24 GMTContent-Length : 6821Content-Type : text/htmldata data data data…. ---> entity body

User-Server Interaction : Authentication and Cookies

• Authentication – client sends an ordinary request message with n

o special header lines– server responds with empty entity body and wit

h a 401 Authorization Reuqired status code– server includes WWW-Authenticate : header– client prompts the user for a username and pass

word– client sends Authorization: header line

• Cookies : Rfc 2109

• when a client connect server first time, server responde with Set-cookie: header

• later client request with Cookie: header

• usage of cookies– If a server requires authentication but doesn’t w

ant to hassele a user with a username and passwerd prompt every time

– If a server wants to rember a user’s preferences – If a user is shopping at a site, keep track of the i

tems that the user is purchasing

Conditional GET

• Caching : reduce object-retrieval delays and diminish the amount of web traffic sent over the Internet

• problem : a coy of an object residing in the cache may be stale

• conditional get : if the request message uses the GET method and the request messge includes an If-Modified-Since: header

Web Caches

• Called a proxy server

• see fig 2.7

• reason to use– can substantially reduce the response time for a c

lient request– can substantially reduce traffic on an institution’s

access link to the Internet– provides an infrastructure for rapid distribution o

f content

• Cooperative caching– multiple web caches, located at different places

in the Internet, can cooperate and improve overall performance.

– NLANR caching system : www.nlanr.net– ICP RFC 2186– clusters of caches, co-located on the same LAN

File Transfer : FTP

• A protocol for transferring a file from one host to another host (rfc 959)

• see fig 2.11

• ftp uses two parallel tcp connention– control connection and a data connection– said to send its control information out-of-band– see fig 2.12

FTP Commands and Replies

• USER username• PASS password• LIST• RETR filename• STOR filename• 331 Username OK, password required• 125 Data connection already open; transfer starting• 425 Can’t open data connection

Electronic mail in the Internet

• See fig 2.13

• user agent : Eudora, outlook express, messenger, mail, pine, elm 등

• SMTP : rfc 821 : port number 25

• initially only ASCII text

• helo, mail from, mail to, data, quit

Comparison with HTTP

• HTTP : pull protocol– someone loads information on a web server and users

pull the information off the server at their convenience– encapsulates each object in each response message

• SMTP : push protocol– the sending mail server pushes the file to the receiving

mail server– ASCII format 사용– places all of the message’s objects into one message

Mail message format and MIME

• Rfc 822 specifies the exact format for mail header lines, semantic interpretations

• After the message header, a blank line follows, then the body follows

• message terminates with a line containing only a period

MIME extension

• Rfc 2045, 2046 -multipurpose internet mail extension

• Content-Type: allow receiving user agent to take an appropriate action on the message

• Content-Transfer-Encoding: alerts the receiving user agent that the message body has been ASCII-encoded and the type of encoding used

• Content-Type : type/subtype; parameters– parameters is optional– used to specify the nature of the data in the bod

y of a MIME entity, by giving media type and subtype names

• mime extensible : registration process IANA ; rfc 2048

• Currently 7 top-level types defined

• text : message body contains textual info.– Text/plain, text/html– plain text : no formating commands or directives

• image : message body contains an image– image/gif, image/jpeg

• audio : audio/basic(basic eight-bit mu-law encoded) audio/32kadpcm

• video : mpeg, quicktime for subtypes

• application : for data that does not fit in any of the other categories

• Multipart : many objects in one mail message– Content-type : multipart/mixed

• receving user agent needs a mean to determine– where each object begins and ends– how each non-ASCII object was transfer-encoded– the content type of each message– placing boundary char between each object– preceding with content-type: and content-transfer -

endoding: heaer line

The received message

• Receiving SMTP server put Receive: header

• specifies the name of the SMTP server that sent the message(“from”), the name of the SMTP server that received the message(“by”) and the time at which the receiving server received the message

• multiple Received or Return-Path heaer

Mail Access Protocols

• See fig 2.15• how to retrieve from a mail server to user age

nt• POP3 : rfc 1939

– opens a tcp connection to the server on port 110– progresses through authorization, transaction, an

d update– +OK, -ERR– list, retr, dele, quit : RFC 1939

• IMAP : rfc 1730 : www.imap.org• designed to allow users to manipulate remot

e mailboxes as if they were local• permit a user agent to obtain components of

messages• IMAP server state

– nonauthenticated state– authenticated state– selected state– logout state

• HTTP : web based mail service– convenient to goers– slow : through CGI scripts and distance

Continuous-media e-mail• E-mail that includes audio or video• CM e-mail

– much larger messages, more stringent end-to-end delay requirements, greater sensitivity to recipients with higly heterogeneous Internet access rates and local storage capabilities

• 문제점– many existing mail servers do not have the capacity to stor

e large CM objects– can lead to excessive waste of bandwidth and storage– current mail access protocols are inappropriate for streamin

g CM to recipients