Transcript ppt - The Fengs

CSE 524: Lecture 5
Application layer protocols
Where we’re at…
●
Internet architecture and history
●
Internet protocols in practice
●
Application layer
–
–
–
Overview and functions
Network programming interface
Specific application protocols
●
HTTP
●
DNS, SMTP/POP, FTP
●
Transport layer
●
Network layer
●
Data-link layer
●
Physical layer
AL: Web Caches (proxy server)
Goal: satisfy client request without involving origin server
• user sets browser:
Web accesses via web
cache
• client sends all http
requests to web cache
origin
server
client
Proxy
server
– if object at web cache, web
cache immediately returns
object in http response
– else requests object from origin
server, then returns http
response to client
• Internet dense with
caches enables “poor”
client
origin
server
AL: More about Web caching
●
Cache acts as both client to content servers
●
Cache acts as server to its users
●
●
Typically installed by ISP (university, company, residential ISP)
Cache can do up-to-date check using If-modified-since
HTTP header
–
Issue: should cache take risk and deliver cached object without
checking?
–
Heuristics are used.
AL: Benefits of web caches
Assume: cache is “close” to client
(e.g., in same network)
• smaller response time: cache
“closer” to client
• decrease traffic to distant servers
origin
servers
public
Internet
– link out of institutional/local ISP
network often bottleneck
• Further info on web caching
– http://www.ircache.net/
– http://www.squid.org
– ICP
• http://www.rfc-editor.org/rfc/rfc2186.txt
• http://www.rfc-editor.org/rfc/rfc2187.txt
1.5 Mbps
access link
institutional
network
10 Mbps LAN
institutional
cache
AL: Content distribution networks (CDNs)
• The content providers are the
CDN customers.
Content replication
• CDN company installs hundreds
of CDN servers throughout
Internet
origin server
in North America
CDN distribution node
– in lower-tier ISPs, close to users
• CDN replicates its customers’
content in CDN servers. When CDN server
provider updates content, CDN in S. America
updates servers
CDN server
CDN server in Asia
in Europe
CDN example
HTTP request for
www.foo.com/sports/sports.html
1
Origin server
2
3
DNS query for www.cdn.com
CDNs authoritative
DNS server
HTTP request for
www.cdn.com/www.foo.com/sports/ruth.gif
origin server
• www.foo.com
• distributes HTML
• Replaces:
Nearby
CDN server
http://www.foo.com/sports.ruth.gif
with
http://www.cdn.com/www.foo.com/sports/ruth.gif
CDN company
• cdn.com
• distributes gif files
• uses its authoritative
DNS server to route
redirect requests
More about CDNs
routing requests
not just Web pages
• CDN creates a “map”,
indicating distances from
leaf ISPs and CDN nodes
• streaming stored
audio/video
• when query arrives at
authoritative DNS server:
– server determines ISP from
which query originates
– uses “map” to determine best
CDN server
• streaming real-time
audio/video
– CDN nodes create
application-layer multicast
overlay network
AL: Domain Name System (DNS)
●
Internet hosts, routers like to use fixed-length addresses
(numbers)
–
●
●
IP address (32 bit) - used for addressing datagrams
Humans like to use variable-length names
–
www.cse.ogi.edu
–
keywords
DNS, keywords, naming protocols
–
Map from IP addresses to names
–
Map from names to IP addresses
AL: Original Name to Address Mapping
●
●
Flat namespace
–
/etc/hosts
–
SRI kept main copy
–
Downloaded regularly
Problems
–
Count of hosts was increasing: machine per domain -> machine per
user
●
Many more downloads
●
Many more updates
AL: Goals for a new naming system
●
Implement a wide area distributed database
–
Scalability
–
Decentralized maintenance
–
Robustness, fault-tolerance
–
Global scope
●
–
Names mean the same thing everywhere
Don’t need
●
Atomicity
●
Strong consistency
AL: Goals for a new naming system
Why not centralize DNS?
●
Single server with all name-to-IP address mappings
–
single point of failure
–
traffic volume
–
distant centralized database (performance)
–
maintenance
–
doesn’t scale!
AL: DNS (Domain Name System)
●
http://www.rfc-editor.org/rfc/rfc1034.txt
●
http://www.rfc-editor.org/rfc/rfc1035.txt
●
distributed database implemented in hierarchy of many name
servers
●
decentralized control and management of data
●
application-layer protocol used by hosts and name servers
–
communicate to resolve names (address/name translation)
–
core Internet function implemented as application-layer protocol
●
complexity at network’s “edge”
●
compare to phone network
–
–
Naming (none supported)
Addressing (complex mechanism within network)
AL: DNS nutshell solution
●
Hierarchical canonical name space
–
www.cse.ogi.edu
root
org
gwu
edu
net
com
ogi
ucb
cse
www
uk
bu
ece
ca
mit
AL: DNS nutshell solution
●
Authoritative name servers store parts of the database
–
–
Names assigned to authoritative name servers
●
For a host, authority stores that host’s IP address, name
●
Responds to queries for host’s IP address
●
Perform name/address translation for that host’s name
Root name server knows authoritative servers for particular subdomains
●
●
●
Hierarchy organizes authoritative name servers
Reserving a domain gives you control of entry in root name server for particular
names
DNS hierarchical lookup
–
–
–
Each host has a pointer to a local name server for which to query for
unknown names
Each local name server knows root of hierarchy
Root points to sub-levels, sub-levels point to deeper sub-levels, … ,
deeper sub-levels point to leaf name server representing authority for
unknown name
AL: DNS nutshell figure
root name
server
Root name servers:
• may not know
authoratiative name
server
• may know intermediate
name server: who to
contact to find
authoritative name
server
• multiple root name
servers for faulttolerance
Example:
• surf.eurecom.fr wants to
6
2
7
local name server
dns.eurecom.fr
1
8
requesting host
3
intermediate name server
dns.umass.edu
4
5
authoritative name server
dns.cs.umass.edu
surf.eurecom.fr
gaia.cs.umass.edu
AL: DNS: Root name servers
• contacted by local name server that can not resolve any part of the name
• root name server:
– contacts authoritative name server if name mapping not known
– gets mapping
– returns mapping to local name server
a NSI Herndon, VA
c PSInet Herndon, VA
d U Maryland College Park, MD
g DISA Vienna, VA
h ARL Aberdeen, MD
k RIPE London
i NORDUnet Stockholm
m WIDE Tokyo
j NSI (TBD) Herndon, VA
e NASA Mt View, CA
f Internet Software C. Palo Alto,
CA
b USC-ISI Marina del Rey, CA
l ICANN Marina del Rey, CA
13 root name
servers worldwide
(all that fit in a 512
octet SOA record)
AL: DNS server name database
●
DB contains tuples called resource records (RRs)
–
RR contains type, class and application data
●
●
Before types added, only one record type (A)
–
Classes = Internet (IN), Chaosnet (CH), etc.
–
Each class defines types, e.g. for IN:
●
A = address
●
NS = name server
●
CNAME = canonical name (for aliasing)
●
HINFO = CPU/OS info
●
MX = mail exchange
●
PTR = pointer for reverse mapping of address to name
nslookup example
AL: DNS record types
Resource records (RR) and their types
RR format: (name,
• Type=A
– name is hostname
– value is IP address
• Type=NS
– name is domain (e.g. foo.com)
value, type,ttl)
• Type= CNAME
– name is an alias name for
some “cannonical” (the
real) name
– value is cannonical
name
– value is IP address of
• Type=MX
authoritative name server for this
– value is hostname of
domain
mailserver associated with
name
AL: DNS MX record type
●
MX records point to mail exchanger for a name
–
●
E.g. mail.acm.org is MX for acm.org
Addition of MX record type proved to be a challenge
–
How to get mail programs to lookup MX record for mail delivery rather
than A record?
–
Needed critical mass of such mailers
AL: DNS server database distribution
●
●
●
Administrative hierarchy
–
Organized into regions known as “zones”
–
“.” as separator
–
zone = contiguous section of name space
Zones created by convincing owner node to delegate a subzone
–
umass.edu zone delegates cs.umass.edu to a different set of authoritative name servers
–
Each zone contains multiple redundant servers
●
Primary (master) name server updated manually
●
Secondary (redundant) servers updated by zone transfer of name space
●
Provides fault-tolerance within zone
Host name to address section
–
Top-level domains -> edu, gov, ca, us, etc.
–
Sub-domains = subtrees
–
Human readable name = leaf -> root path
AL: DNS client lookups
●
Each host has a resolver
–
Typically a library that applications can link gethostbyname()
–
Local name servers hand-configured (e.g. /etc/resolv.conf) or
automatically configured (DHCP)
–
●
●
Can specify a file /etc/hosts
●
Can specify a name server by its IP address (i.e. 129.95.50.2)
Host queries local name server for unknown names
Name servers
–
Configured with well-known root servers
●
–
Currently {a-m}.root-servers.net
Local servers
●
Typically answer queries about local zone
●
Typically do a lookup of distant host names for local hosts
AL: Lookup Methods
●
●
Recursive queries
–
Server goes out and searches for more info on behalf of the client
(recursive)
–
Only returns final answer or “not found”
Iterative
–
–
Server responds with as much as it knows (i.e. name of server to contact
next)
Client iteratively queries additional servers
AL: All recursive DNS example
root name
server
host surf.eurecom.fr
wants IP address of
gaia.cs.umass.edu
2
4
5
3
1. Contacts its local DNS server,
dns.eurecom.fr
2. dns.eurecom.fr contacts
root name server, if necessary
3. root name server contacts
authoritative name server,
dns.umass.edu, if
necessary
local name server
dns.eurecom.fr
1
authorititive name server
dns.umass.edu
6
requesting host
surf.eurecom.fr
gaia.cs.umass.edu
AL: DNS: iterated queries
●
recursive query:
–
–
–
●
root name
server
puts burden of name
resolution on contacted
name server
heavy load?
root servers now disable
recursive queries (RFC
2010)
iterated query:
–
–
contacted server replies
with name of server to
contact
“I don’t know this name,
but ask this server”
iterated
query
2
3
4
7
local name server
dns.eurecom.fr
1
8
requesting host
intermediate name server
dns.umass.edu
5
6
authoritative name server
dns.cs.umass.edu
surf.eurecom.fr
gaia.cs.umass.edu
AL: Typical Resolution
●
Client does recursive request to local name server
●
Local name server does iterative requests to find name
●
Local name server has knowledge of root servers
●
Steps for resolving www.ogi.edu
●
–
Application calls gethostbyname()
–
Resolver contacts local name server (S1)
–
S1 queries root server (S2) for (www.ogi.edu)
–
S2 returns NS record for ogi.edu (S3)
–
S1 queries S3 for www.ogi.edu
–
S3 returns A record for www.ogi.edu
Can return multiple addresses -> what does this mean?
AL: DNS Caching
●
DNS responses are cached
–
–
Quick response for repeated translations
Other queries may reuse some parts of lookup
●
●
DNS negative queries are also cached
–
–
●
Don’t have to repeat past mistakes
E.g. misspellings
Cached data periodically times out
–
–
–
–
●
NS records for domains
Soft state
Lifetime (TTL) of data controlled by owner of data
TTL passed with every record
TTL affects DNS-based load balancing techniques
update/notify mechanisms under design by IETF
–
RFC 2136
–
http://www.ietf.org/html.charters/dnsind-charter.html
AL: DNS Lookup Caching Example
www.cse.ogi.edu
Client
Local
DNS server
root & edu
DNS server
ogi.edu
DNS server
cse.ogi.edu
DNS
server
AL: Subsequent Lookup Example
cse.ogi.edu entry cached
ftp.cse.ogi.edu
Client
Local
DNS server
root & edu
DNS server
ogi.edu
DNS server
cse.ogi.edu
DNS
server