Transcript 2장 Application Layer

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
receiving process on the desitination host
– IP address : 32bit that uniquely identifies the
end system
– port number : the appropriate process on the
destination 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
transfer 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,
retrives 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
terminates
– 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
sending 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 message
GET /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 message
HTTP/1.1 200 OK --> status line
Connection : close ---> header line
Date : Thu, 06 Aug 1998 12:00:15 GMT
Server : Apache/1.3.0 (Unix)
Last-Modefied : Mon, 22 Jun 1998 09:23:24 GMT
Content-Length : 6821
Content-Type : text/html
data data data data…. ---> entity body
User-Server Interaction :
Authentication and Cookies
• Authentication
– client sends an ordinary request message with
no special header lines
– server responds with empty entity body and
with a 401 Authorization Reuqired status code
– server includes WWW-Authenticate : header
– client prompts the user for a username and
password
– 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
want 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
items 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
client request
– can substantially reduce traffic on an
institution’s access link to the Internet
– provides an infrastructure for rapid distribution
of 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
body 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
agent
• POP3 : rfc 1939
– opens a tcp connection to the server on port 110
– progresses through authorization, transaction,
and update
– +OK, -ERR
– list, retr, dele, quit : RFC 1939
• IMAP : rfc 1730 : www.imap.org
• designed to allow users to manipulate
remote 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
store large CM objects
– can lead to excessive waste of bandwidth and storage
– current mail access protocols are inappropriate for
streaming CM to recipients