Computer Networking - Application Layer.ppt

Computer
Networking: A Top
Down Approach
A note on the use of these Powerpoint slides:
We’re making these slides freely available to all (faculty, students, readers).
They’re in PowerPoint form so you see the animations; and can add, modify,
and delete slides (including this one) and slide content to suit your needs.
They obviously represent a lot of work on our part. In return for use, we only
ask the following:
 If you use these slides (e.g., in a class) that you mention their source
(after all, we’d like people to use our book!)
 If you post any slides on a www site, that you note that they are adapted
from (or perhaps identical to) our slides, and note our copyright of this
material.
Thanks and enjoy! JFK/KWR
All material copyright 1996-2016
J.F Kurose and K.W. Ross, All Rights Reserved
7th
edition
Jim Kurose, Keith Ross
Pearson/Addison Wesley
April 2016
Chapter 2
Application Layer
Application Layer 2-1

Chapter 2: outline
2.1 principles of network
applications
2.2 Web and HTTP
2.3 electronic mail
• SMTP, POP3, IMAP
2.4 DNS
2.5 P2P applications
2.6 video streaming and
content distribution
networks
2.7 socket programming
with UDP and TCP

DNS: domain name system
people: many identifiers:
• SSN, name, passport #
Internet hosts, routers:
• IP address (32 bit) -
used for addressing
datagrams
• “name”, e.g.,
www.yahoo.com -
used by humans
Q: how to map between IP
address and name, and
vice versa ?
Domain Name System:
 distributed database
implemented in hierarchy of
many name servers
 application-layer protocol: hosts,
name servers communicate to
resolve names (address/name
translation)
• note: core Internet function,
implemented as application-
layer protocol
• complexity at network’s
“edge”

DNS: services, structure
why not centralize DNS?
 single point of failure
 traffic volume
 distant centralized database
 maintenance
DNS services
 hostname to IP address
translation
 host aliasing
• canonical, alias names
 mail server aliasing
 load distribution
• replicated Web
servers: many IP
addresses correspond
to one name
A: doesn‘t scale!

Root DNS Servers
com DNS servers org DNS servers edu DNS servers
poly.edu
DNS servers
umass.edu
DNS servers
yahoo.com
DNS servers
amazon.com
DNS servers
pbs.org
DNS servers
DNS: a distributed, hierarchical database
client wants IP for www.amazon.com; 1st
approximation:
 client queries root server to find com DNS server
 client queries .com DNS server to get amazon.com DNS server
 client queries amazon.com DNS server to get IP address for
www.amazon.com
… …

Local DNS name server
 does not strictly belong to hierarchy
 each ISP (residential ISP, company, university) has
one
• also called “default name server”
 when host makes DNS query, query is sent to its
local DNS server
• has local cache of recent name-to-address translation
pairs (but may be out of date!)
• acts as proxy, forwards query into hierarchy

DNS: root name servers
 contacted by local name server that can not resolve name
 root name server:
• contacts authoritative name server if name mapping not known
• gets mapping
• returns mapping to local name server
13 logical root name
“servers” worldwide
•each “server” replicated
many times
a. Verisign, Los Angeles CA
(5 other sites)
b. USC-ISI Marina del Rey, CA
l. ICANN Los Angeles, CA
(41 other sites)
e. NASA Mt View, CA
f. Internet Software C.
Palo Alto, CA (and 48 other
sites)
i. Netnod, Stockholm (37 other sites)
k. RIPE London (17 other sites)
m. WIDE Tokyo
(5 other sites)
c. Cogent, Herndon, VA (5 other sites)
d. U Maryland College Park, MD
h. ARL Aberdeen, MD
j. Verisign, Dulles VA (69 other sites )
g. US DoD Columbus,
OH (5 other sites)

TLD, authoritative servers
top-level domain (TLD) servers:
• responsible for com, org, net, edu, aero, jobs, museums,
and all top-level country domains, e.g.: uk, fr, ca, jp
• Network Solutions maintains servers for .com TLD
• Educause for .edu TLD
authoritative DNS servers:
• organization’s own DNS server(s), providing authoritative
hostname to IP mappings for organization’s named hosts
• can be maintained by organization or service provider

requesting host
cis.poly.edu
gaia.cs.umass.edu
root DNS server
local DNS server
dns.poly.edu
1
2
3
4
5
6
authoritative DNS server
dns.cs.umass.edu
7
8
TLD DNS server
DNS name
resolution example
 host at cis.poly.edu
wants IP address for
gaia.cs.umass.edu
iterated query:
 contacted server
replies with name of
server to contact
 “I don’t know this
name, but ask this
server”

4
5
6
3
recursive query:
 puts burden of name
resolution on
contacted name
server
 heavy load at upper
levels of hierarchy?
requesting host
cis.poly.edu
gaia.cs.umass.edu
root DNS server
local DNS server
dns.poly.edu
1
2
7
authoritative DNS server
dns.cs.umass.edu
8
DNS name
resolution example
TLD DNS
server

DNS: caching, updating records
 once (any) name server learns mapping, it caches
mapping
• cache entries timeout (disappear) after some time (TTL)
• TLD servers typically cached in local name servers
• thus root name servers not often visited
 cached entries may be out-of-date (best effort
name-to-address translation!)
• if name host changes IP address, may not be known
Internet-wide until all TTLs expire
 update/notify mechanisms proposed IETF standard
• RFC 2136

DNS records
DNS: distributed database storing resource records (RR)
type=NS
• name is domain (e.g.,
foo.com)
• value is hostname of
authoritative name
server for this domain
RR format: (name, value, type, ttl)
type=A
 name is hostname
 value is IP address
type=CNAME
 name is alias name for some
“canonical” (the real) name
 www.ibm.com is really
servereast.backup2.ibm.com
 value is canonical name
type=MX
 value is name of mailserver
associated with name

DNS protocol, messages
 query and reply messages, both with same message format
message header
 identification: 16 bit # for
query, reply to query uses
same #
 flags:
 query or reply
 recursion desired
 recursion available
 reply is authoritative
identification flags
# questions
questions (variable # of questions)
# additional RRs
# authority RRs
# answer RRs
answers (variable # of RRs)
authority (variable # of RRs)
additional info (variable # of RRs)
2 bytes 2 bytes

name, type fields
for a query
RRs in response
to query
records for
authoritative servers
additional “helpful”
info that may be used
identification flags
# questions
questions (variable # of questions)
# additional RRs
# authority RRs
# answer RRs
answers (variable # of RRs)
authority (variable # of RRs)
additional info (variable # of RRs)
DNS protocol, messages
2 bytes 2 bytes

Inserting records into DNS
 example: new startup “Network Utopia”
 register name networkuptopia.com at DNS registrar
(e.g., Network Solutions)
• provide names, IP addresses of authoritative name server
(primary and secondary)
• registrar inserts two RRs into .com TLD server:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
 create authoritative server type A record for
www.networkuptopia.com; type MX record for
networkutopia.com

Attacking DNS
DDoS attacks
 bombard root servers
with traffic
• not successful to date
• traffic filtering
• local DNS servers cache
IPs of TLD servers,
allowing root server
bypass
 bombard TLD servers
• potentially more
dangerous
redirect attacks
 man-in-middle
• Intercept queries
 DNS poisoning
 Send bogus relies to
DNS server, which
caches
exploit DNS for DDoS
 send queries with
spoofed source
address: target IP
 requires amplification

Chapter 2: outline
applications
2.2 Web and HTTP
2.3 electronic mail
2.4 DNS
networks
with UDP and TCP

Pure P2P architecture
 no always-on server
 arbitrary end systems
directly communicate
 peers are intermittently
connected and change
IP addresses
examples:
• file distribution
(BitTorrent)
• Streaming (KanKan)
• VoIP (Skype)

File distribution: client-server vs P2P
Question: how much time to distribute file (size F) from one server to N peers?
• peer upload/download capacity is limited resource
us
uN
dN
server
network (with abundant
bandwidth)
file, size F
us: server upload
capacity
ui: peer i upload
capacity
di: peer i download
capacity
u2 d2
u1 d1
di
ui

File distribution time: client-server
 server transmission: must
sequentially send (upload) N
file copies:
• time to send one copy: F/us
• time to send N copies: NF/us
increases linearly in N
time to distribute F
to N clients using
client-server approach
Dc-s > max{NF/us,,F/dmin}
 client: each client must
download file copy
• dmin = min client download rate
• min client download time: F/dmin
us
network
di
ui
F

File distribution time: P2P
 server transmission: must
upload at least one copy
• time to send one copy: F/us
time to distribute F
to N clients using
P2P approach
us
network
di
ui
F
DP2P > max{F/us,,F/dmin,,NF/(us + ui)}
 client: each client must
download file copy
• min client download time: F/dmin
 clients: as aggregate must download NF bits
• max upload rate (limiting max download rate) is us + ui
… but so does this, as each peer brings service capacity
increases linearly in N …

0
0.5
1
1.5
2
2.5
3
3.5
0 5 10 15 20 25 30 35
N
Minimum
Distribution
Time
P2P
Client-Server
Client-server vs. P2P: example
client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us

P2P file distribution: BitTorrent
tracker: tracks peers
participating in torrent
torrent: group of peers
exchanging chunks of a file
Alice arrives …
 file divided into 256Kb chunks
 peers in torrent send/receive file chunks
… obtains list
of peers from tracker
… and begins exchanging
file chunks with peers in torrent

 peer joining torrent:
• has no chunks, but will
accumulate them over time
from other peers
• registers with tracker to get
list of peers, connects to
subset of peers (“neighbors”)
P2P file distribution: BitTorrent
 while downloading, peer uploads chunks to other peers
 peer may change peers with whom it exchanges chunks
 churn: peers may come and go
 once peer has entire file, it may (selfishly) leave or
(altruistically) remain in torrent

BitTorrent: requesting, sending file chunks
requesting chunks:
 at any given time, different
peers have different subsets
of file chunks
 periodically, Alice asks each
peer for list of chunks that
they have
 Alice requests missing
chunks from peers, rarest
first
sending chunks: tit-for-tat
 Alice sends chunks to those
four peers currently sending
her chunks at highest rate
• other peers are choked by Alice
(do not receive chunks from her)
• re-evaluate top 4 every10 secs
 every 30 secs: randomly select
another peer, starts sending
chunks
• “optimistically unchoke” this peer
• newly chosen peer may join top 4

BitTorrent: tit-for-tat
(1) Alice “optimistically unchokes” Bob
(2) Alice becomes one of Bob’s top-four providers; Bob reciprocates
(3) Bob becomes one of Alice’s top-four providers
higher upload rate: find better
trading partners, get file faster !

Chapter 2: outline
applications
2.2 Web and HTTP
2.3 electronic mail
2.4 DNS
networks (CDNs)
with UDP and TCP

Chapter 2: outline
applications
2.2 Web and HTTP
2.3 electronic mail
2.4 DNS
networks
with UDP and TCP

Socket programming
goal: learn how to build client/server applications that
communicate using sockets
socket: door between application process and end-end-
transport protocol
Internet
controlled
by OS
controlled by
app developer
transport
application
physical
link
network
process
transport
application
physical
link
network
process
socket

Socket programming
Two socket types for two transport services:
• UDP: unreliable datagram
• TCP: reliable, byte stream-oriented
Application Example:
1. client reads a line of characters (data) from its
keyboard and sends data to server
2. server receives the data and converts characters
to uppercase
3. server sends modified data to client
4. client receives modified data and displays line on
its screen

Socket programming with UDP
UDP: no “connection” between client & server
 no handshaking before sending data
 sender explicitly attaches IP destination address and
port # to each packet
 receiver extracts sender IP address and port# from
received packet
UDP: transmitted data may be lost or received
out-of-order
Application viewpoint:
 UDP provides unreliable transfer of groups of bytes
(“datagrams”) between client and server

Client/server socket interaction: UDP
close
clientSocket
read datagram from
clientSocket
create socket:
clientSocket =
socket(AF_INET,SOCK_DGRAM)
Create datagram with server IP and
port=x; send datagram via
clientSocket
create socket, port= x:
serverSocket =
socket(AF_INET,SOCK_DGRAM)
read datagram from
serverSocket
write reply to
serverSocket
specifying
client address,
port number
Application 2-32
server (running on serverIP) client

Example app: UDP client
from socket import *
serverName = ‘hostname’
serverPort = 12000
clientSocket = socket(AF_INET,
SOCK_DGRAM)
message = raw_input(’Input lowercase sentence:’)
clientSocket.sendto(message.encode(),
(serverName, serverPort))
modifiedMessage, serverAddress =
clientSocket.recvfrom(2048)
print modifiedMessage.decode()
clientSocket.close()
Python UDPClient
include Python’s socket
library
create UDP socket for
server
get user keyboard
input
Attach server name, port to
message; send into socket
print out received string
and close socket
read reply characters from
socket into string

Example app: UDP server
serverPort = 12000
serverSocket = socket(AF_INET, SOCK_DGRAM)
serverSocket.bind(('', serverPort))
print (“The server is ready to receive”)
while True:
message, clientAddress = serverSocket.recvfrom(2048)
modifiedMessage = message.decode().upper()
serverSocket.sendto(modifiedMessage.encode(),
clientAddress)
Python UDPServer
create UDP socket
bind socket to local port
number 12000
loop forever
Read from UDP socket into
message, getting client’s
address (client IP and port)
send upper case string
back to this client

Socket programming with TCP
client must contact server
 server process must first be
running
 server must have created
socket (door) that
welcomes client’s contact
client contacts server by:
 Creating TCP socket,
specifying IP address, port
number of server process
 when client creates socket:
client TCP establishes
connection to server TCP
 when contacted by client,
server TCP creates new socket
for server process to
communicate with that
particular client
• allows server to talk with
multiple clients
• source port numbers used
to distinguish clients (more
in Chap 3)
TCP provides reliable, in-order
byte-stream transfer (“pipe”)
between client and server
application viewpoint:

Client/server socket interaction: TCP
wait for incoming
connection request
connectionSocket =
serverSocket.accept()
create socket,
port=x, for incoming
request:
serverSocket = socket()
create socket,
connect to hostid, port=x
clientSocket = socket()
server (running on hostid) client
send request using
clientSocket
read request from
connectionSocket
write reply to
connectionSocket
TCP
connection setup
close
connectionSocket
read reply from
clientSocket
close
clientSocket

Example app: TCP client
serverName = ’servername’
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_STREAM)
clientSocket.connect((serverName,serverPort))
sentence = raw_input(‘Input lowercase sentence:’)
clientSocket.send(sentence.encode())
modifiedSentence = clientSocket.recv(1024)
print (‘From Server:’, modifiedSentence.decode())
clientSocket.close()
Python TCPClient
create TCP socket for
server, remote port 12000
No need to attach server
name, port

Example app: TCP server
serverPort = 12000
serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind((‘’,serverPort))
serverSocket.listen(1)
print ‘The server is ready to receive’
while True:
connectionSocket, addr = serverSocket.accept()
sentence = connectionSocket.recv(1024).decode()
capitalizedSentence = sentence.upper()
connectionSocket.send(capitalizedSentence.
encode())
connectionSocket.close()
Python TCPServer
create TCP welcoming
socket
server begins listening for
incoming TCP requests
loop forever
server waits on accept()
for incoming requests, new
socket created on return
read bytes from socket (but
not address as in UDP)
close connection to this
client (but not welcoming
socket)

Chapter 2: summary
 application architectures
• client-server
• P2P
 application service
requirements:
• reliability, bandwidth, delay
 Internet transport service model
• connection-oriented, reliable:
TCP
• unreliable, datagrams: UDP
our study of network apps now complete!
 specific protocols:
• HTTP
• SMTP, POP, IMAP
• DNS
• P2P: BitTorrent
 video streaming, CDNs
 socket programming:
TCP, UDP sockets

 typical request/reply
message exchange:
• client requests info or
service
• server responds with
data, status code
 message formats:
• headers: fields giving info
about data
• data: info(payload) being
communicated
important themes:
 control vs. messages
• in-band, out-of-band
 centralized vs. decentralized
 stateless vs. stateful
 reliable vs. unreliable
message transfer
 “complexity at network edge
”
Chapter 2: summary
most importantly: learned about protocols!

Computer Networking - Application Layer.ppt

More Related Content

Similar to Computer Networking - Application Layer.ppt (20)

Recently uploaded (20)

Computer Networking - Application Layer.ppt