Transcript Chap. 2 - WINSLab

Ch 2. Application Layer
Myungchul Kim
[email protected]
Principles of network applications
–
Develping new applications -> writing software running on
multiple end systems
2

Network application architecture
–
–
Network architecture
Application architecture


Client-server architecture
P2P architecture
3

Client and server processes

The interface between the process and the computer network
–
Application programming interface (API)
4

Transport service available to applications
–
Reliable data data transfer
–
Throughput: bandwidth-sensitive applications and elastic
applications
–
Timing
–
Security
5

Transport services provided by the Internet
–
TCP services

Connection-oriented service: handshaking, connection
establishment, tearing down the connection
–

Reliable data transfer service

Congestion-control mechanism
UDP services

Connectionless

No handshaking

An unreliable data transfer service
6
7

Today’s Internet can often provide satisfactory service to timesentive
applications, but it cannot provide any timing or bandwidth guarantees.

Addressing processes: host by IP address + process by port number
8

Application-layer protocols
–
The types of messages exchanged
–
The syntax of the various message types
–
The semantics of the fields
–
Rules for examining when and how a process a sends messages and
responds to messages
–
e.g., HTTP – Web’s application-layer protocol
9
The Web and HTTP

Overview of HTTP
–
–
–
–
–

HyperText Transfer Protocol
Web page = a set of objects: an object = a file
Web browser = the client of HTTP
Web server = the server of HTTP
A stateless protocol
Non-persistent and persistent connections
–
HTTP with non-persistent connections


–
Each TCP connection is closed after the server sends the object.
(next slide)
HTTP with persistent connections

The server leaves the TCP connection open after sending a
response.
10
Nonpersistent HTTP
Suppose user enters URL
www.someSchool.edu/someDepartment/home.index
(contains text,
references to 10
jpeg images)
1a. HTTP client initiates TCP connection to
HTTP server (process) at
www.someSchool.edu on port 80
1b. HTTP server at host
www.someSchool.edu waiting for
TCP connection at port 80.
“accepts” connection, notifying
client
2. HTTP client sends HTTP request
message (containing URL) into TCP
connection socket. Message
indicates that client wants object
someDepartment/home.index
3. HTTP server receives request
message, forms response message
containing requested object, and
sends message into its socket
time
11
Nonpersistent HTTP (cont.)
4. HTTP server closes TCP connection.
5. HTTP client receives response
message containing html file, displays
html. Parsing html file, finds 10
referenced jpeg objects
time
6. Steps 1-5 repeated for each of 10
jpeg objects
12
13

HTTP message format
–
–
Request messages and response messages
HTTP request message
request line
(GET, POST,
HEAD commands)
Carriage return,
line feed
indicates end
of message
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)
14
15
HTTP response message
status line
(protocol
status code
status phrase)
header
lines
data, e.g.,
requested
HTML file
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 ...
16
–
HTTP response message:
17

User-server interaction: Cookies
–
–
Identify users
One-click shopping; shopping cart service
18

Web caching
–
–
Web cache = proxy server
A cache is both a server and a client at the same time.
19
20
Conditional GET
server
cache


Goal: don’t send object if cache
has up-to-date cached version
cache: specify date of cached
copy in HTTP request
If-modified-since: <date>

server: response contains no
object if cached copy is up-to-date:
HTTP request msg
If-modified-since:
<date>
HTTP response
object
not
modified
HTTP/1.0
304 Not Modified
HTTP/1.0 304 Not Modified
HTTP request msg
If-modified-since:
<date>
HTTP response
object
modified
HTTP/1.0 200 OK
<data>
21
FTP
–
Out-of-band, stateful protocol
22
Electronic Mail

Simple Mail Transfer Protocol (SMTP)
23
–
–
–
The body of SMTP: 7-bit ASCII
Use persistent connections
Push protocol (cf. pull protocol e.g. HTTP)
24
1) Alice uses UA to compose
message and “to”
[email protected]
2) Alice’s UA sends message to her
mail server; message placed in
message queue
3) Client side of SMTP opens TCP
connection with Bob’s mail
server
4) SMTP client sends Alice’s
message over the TCP
connection
5) Bob’s mail server places the
message in Bob’s mailbox
6) Bob invokes his user agent to
read message
25

Mail Message Formats and MIME
– Multipurpose Internet Mail Extensions (MIME)



Content-Type
Content-Transfer-Encoding
Mail Access Protocols
–
Post Office Protocol - Verson 3 (POP3), Internet Mail Acess Protocol
(IMAP), and HTTP
26
DNS – The Internet’s Directory Service
–
–
–
–
–
–
–
Domain name system
Identifer: hostname, IP address
Translate hostnames to IP addresses
Host aliasing: canonical hostname
Mail server aliasing
Load distribution: DNS rotation
A centralized design




A single point of failure
Traffic volume
Distant centralized database
Maintenance
27

A distributed, hierachical database
–
–
–
Root DNS servers
Top-level domain (TLD) servers
Authoritative DNS servers
28
29
30
31
–

DNS caching: cache the mapping in its local memory
DNS records and messages
–
–
–
–
–
–
Resource records (RRs)
RR: (Name, Value, Type, TTL)
Type = A: hostanme and its IP address
Type = NS: domain and hostname of an authoritative DNS server
Type = CNAME: cananical hostname
Type = MX: canaonical name of a mail server
32
33

Inserting records into the DNS database
–
–
Registrar
Internet Corporation for Assigned Names and Numbers (ICANN)
34
Peer-to-Peer Applications
–
–

Peers vs service providers
File distribution, organizing and searching for information and
Internet telephony application
P2P file distribution
–
Scalability of P2P architectures
35

BitTorrent
–
–
–
–
–
–
–
–
File distribution
Torrent: the collection of all peers participating in the distribution of a
particular file
Chungs of a file (256KBytes)
Each torrent has an infrasturecture node called a tracker
Rarest first: from neighbors
Trading algorithm: gives priority to the neighbors that are currently
supplying data at the highest rate
Four top peers and one probing peer
Free-riding
36
37

Searching for information in a P2P community
–
–
–
–
Information index – a mapping of information to host locations
File sharing: files to peers
Instant message: username to locations (IP addresses)
Centralized index



Napster
A hybird of P2P and client-server architecture
Copyright infringement
38
–
Query flooding





Gnutella
The index is fully distributed over the community peers
Overlay network
Limited-scope query flooding
New peers join: bootstrap problem
39
Gnutella: Peer joining
1.
2.
3.
4.
joining peer Alice must find another peer in Gnutella network: use
list of candidate peers
Alice sequentially attempts TCP connections with candidate peers
until connection setup with Bob
Flooding: Alice sends Ping message to Bob; Bob forwards Ping
message to his overlay neighbors (who then forward to their
neighbors….)

peers receiving Ping message respond to Alice with Pong
message
Alice receives many Pong messages, and can then setup
additional TCP connections
40
–
Hierarchical overlay


FastTrack, Kazaa and Morpheus
Limited-scope flooding in the overlay network of super peers
41

Case study: P2P Internet Telephony with Skype
–
–
Real time
P2P for user location and for NAT traversal
42
P2P Case study: Skype



P2P (pc-to-pc, pc-to-phone,
phone-to-pc) Voice-Over-IP
(VoIP) application
– also IM
Skype
proprietary application-layer login server
protocol (inferred via reverse
engineering)
hierarchical overlay
Skype clients (SC)
Supernode
(SN)
43
Skype: making a call

User starts Skype

SC registers with SN
–
list of bootstrap SNs
Skype
login server

SC logs in (authenticate)

Call: SC contacts SN will callee ID
–

SN contacts other SNs (unknown
protocol, maybe flooding) to find
addr of callee; returns addr to SC
SC directly contacts callee, overTCP
44