Ch 2. Application Layer

Myungchul Kimmckim@icu.ac.kr

2

Principles of application-layer protocols Distributed among two or more end systems

– Browser (client) – server– Processes– How processes running on different end systems communicate vs interpr

ocess communication Networking applications have application-layer protocols that d

efine the format and order of the messages exchanged between processes, as well as define the actions taken on the transmission or receipt of a message

– Web: a network application– Web application = document formats, browsers, servers, and an applicati

on protocol HTTP An application-layer protocol defines:

– Types of messages exchanged– Syntax of the various message types– Semantics of the fields– Rules for determining when and how a process sends messages and res

ponds to messages.

3

The host that initiates the session is labeled the client. Fig 2.2

4

Socket– A process’s socket can be thought of as the process’s door.– API (application programmers’ interface)– Application developer has (1) the choice of transport protocols and (2)

the ability to fix a few transport-layer parameters such as max buffer and max segment sizes.

Addressing processes – To identify a process: (1) the name or address of the host and (2) an

identifier that specifies the process in the host.– IP address globally uniquely identifies the network interface.– Destination port number: a web server process with port number 80, a

mail server process with port number 25, etc. User agents

– An interface between the user and the network application.– The browser also implements the client side of the HTTP protocols.

5

An application’s service requirements– Reliable data transfer: loss-tolerant applications?– Bandwidth: bandwidth-sensitive application vs elastic applications– Timing: end-to-end delays– Fig 2.4

6

Services provided by the Internet Transport Protocols– UDP, TCP

TCP services– Connection-oriented service: handshaking procedure, a TCP

connection, a full-duplex– Reliable transport service: without error and in the proper order– Congestion-control mechanisms– Real-time applications usually run over UDP rather than TCP– TCP does not guarantee a min transmission rate– TCP does not provide any delay guarantee– TCP guarantee delivery of all data.

UDP services– Lightweight transport protocol– Connectionless, no handshaking, no guarantee, no congestion-control

7

– Fig 2.5

8

The Web and HTTP

HTTP– A client and a server– Web page: objects (an HTML file, a JPEG image, a Java Applet,

…)– TCP– A stateless protocol: an HTTP server maintains no information a

bout the clients.– No relation with a Web page

Nonpersistent connections – Only a single Web object is transferred over a TCP connection.– Most browsers open five to ten parallel TCP connections.– RTT (Round Trip Time)

9

– Fig 2.7

10

Persistent connections– Without pipelining and with pipelining– Without pipelining: the client issues a new request only when the previous

response has been received: one RTT– HTTP/1.1: persistent connections with pipelining

HTTP message format– ASCII text– HTTP request message, response message– Request line (GET, POST, HEAD) (pp. 94, 96)– Header line– Fig 2.8

11

File Transfer: FTP

On TCP Out of band: A control connection and a data

connection, cf. in-band for HTTP The FTP server must maintain state about the user. Fig 2.11

12

Electronic Mail

components– User agents– Mail servers (mailbox)– Simple Mail Transfer Protocol (SMTP)

On TCP Fig 2.13

13

Comparison with HTTP – HTTP: a pull protocol, SMTP: a push protocol– SMTP: in seven-bit ASCII format– HTTP encapsulates each object in its own HTTP response

message. Internet mail places all of the message’s objects into one message.

– MIME extension for non-ASCII data: Content-Type and Content-Transfer-Encoding

– Content-Type: text, image, and application

14

Mail Access Protocols– A mail server is always on and always connected to the Internet?– POP3, IMAP and HTTP– Fig 2.14

15

DNS (Directory Service) Hostname -> IP address Domain Name System (DNS)

– A distributed database in a hierarchy of name servers– An application-layer protocol that allows host and name servers to com

municate for the translation service.– On UDP– Host aliasing– Mail server aliasing– Load distribution: a set of IP addresses is associated with one canonical

hostname.– Gethostbyname() in UNIX

The problems with a centralized design -> doesn’t scale– A single point of failure– Traffic volume– Distant centralized database– Maintenance

16

The DNS with a large number of name servers – Local name servers: configured by hand in a host– Root name servers (pp. 126)– \Authoritative name servers: each host is registered with an authoritative name

server Recursive queries

– Fig 2.17

17

Recursive and iterative queries – Fig 2.18

18

DNS caching DNS records

– Resource record (name, value, type, TTL0– Type = A, NS, CNAME, and MX– Fig 2.19

– Flag: query or reply, authoritative, recursion, …– How data gets into the database in the first place?