Application Layer
All material copyright 1996-2012
J.F Kurose and K.W. Ross, All Rights Reserved
George Parisis
School of Engineering and Informatics
University of Sussex
Application Layer 2-2
Outline
v Principles of network applications
v Electronic mail
§ SMTP, POP3, IMAP
v Web and HTTP
v DNS
v socket programming with UDP and TCP
Application Layer 2-3
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:
v distributed database
implemented in hierarchy of
many name servers
v 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”
Application Layer 2-4
DNS: services, structure
why not centralize DNS?
v single point of failure
v traffic volume
v distant centralized
database
v maintenance
DNS services
v hostname to IP address
translation
v host aliasing
§ canonical, alias names
v mail server aliasing
v load distribution
§ replicated Web
servers: many IP
addresses
correspond to one
name
A: doesn’t scale!
Application Layer 2-5
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 approx:
v client queries root server to find com DNS server
v client queries .com DNS server to get amazon.com DNS
server
v client queries amazon.com DNS server to get IP address for
www.amazon.com
… …
Application Layer 2-6
DNS: root name servers
13 root name
“servers”
worldwide
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)
Application Layer 2-7
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
Application Layer 2-8
Local DNS name server
v does not strictly belong to hierarchy
v each ISP (residential ISP, company,
university) has one
§ also called “default name server”
v 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
Application Layer 2-9
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
v host at cis.poly.edu
wants IP address for
gaia.cs.umass.edu
iterated query:
v contacted server
replies with name of
server to contact
v “I don’t know this
name, but ask this
server”
Application Layer 2-10
4 5
6
3
recursive query:
v puts burden of
name resolution on
contacted name
server
v 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
Application Layer 2-11
DNS: caching, updating records
v 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
v 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
Application Layer 2-12
DNS records
DNS: distributed db 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
Application Layer 2-13
DNS protocol, messages
v query and reply messages, both with same
message format
msg header
v identification: 16 bit # for
query, reply to query uses
same #
v 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
Application Layer 2-14
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
Application Layer 2-15
Inserting records into DNS
v example: new startup “Network Utopia”
v 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)
v create authoritative server type A record for
www.networkuptopia.com; type MX record for
networkutopia.com
Content Delivery Networks
• Overlay networks across the world
• Efficiently manage popular content on behalf of
content providers
• Web Mirroring – a very simple approach
• Different sites with different addresses that replicate popular
content (e.g. Linux Distributions) – not appropriate for serving parts
of a web page
• DNS Redirection
DNS Redirection
• A nice photo in Facebook: https://www.facebook.com/photo.php?
fbid=10153425280267954&set=t.532692953&type=3&size=2048%2C1358
• You can’t see it because you are not FB friends with me
• Right click à Copy image url à Paste
• https://scontent.xx.fbcdn.net/v/
t31.0-8/11845080_10153425280267954_3099288129582999879_o.jpg?oh=e45030cf1d88d7e545b4398051f9ae54&oe=594520AA
• This is not Facebook!!
• And this is not Google:
https://lh4.googleusercontent.com/-6kihAcO5zeA/UtVI0OiAiGI/AAAAAAAAorg/
vDUY686AKsU/w1900-h1068-no/DSCF0127.JPG
• Let’s look at the HTML Source
v Side note: there is no access control on the CDN’s side
DNS Redirection
• Facebook, Google and other content providers change the URLs
that point to static content (even for logos) to point to a CDN provider
• Such URLs are resolved by DNS servers owned and ran by CDN
providers
• There happens all the magic!
DNS Resolution
• Resolve a7.g.akamai.net
• Resolver contacts root server
• Root server sends a referral to a name server responsible for .net
• Resolver queries .net name server
• Returns a referral for .akamai.net
• This is the top-level Akamai server
• Resolver queries a top-level Akamai server
• Returns a referral for .g.akamai.net
• Low-level Akamai server (TTL approx 1 hour)
• Resolver queries a low-level Akamai server
• Returns IP addresses of servers available to satisfy the request
• Short TTL (several seconds to 1 minute)
Application Layer 2-20
Outline
v Principles of network applications
v Electronic mail
§ SMTP, POP3, IMAP
v Web and HTTP
v DNS
v socket programming with UDP and TCP
2: Application Layer 21
Socket programming
Socket API
v introduced in BSD4.1 UNIX,
1981
v explicitly created, used,
released by apps
v client/server paradigm
v two types of transport service
via socket API:
§ unreliable datagram
§ reliable, byte stream-
oriented
a host-local,
application-created,
OS-controlled interface
(a “door”) into which
application process can
both send and
receive messages to/from
another application
process
socket
Goal: learn how to build client/server application that
communicate using sockets
2: Application Layer 22
Socket-programming using TCP
TCP service: reliable transfer of bytes from one process to another
process
TCP with
buffers,
variables
socket
controlled by
application
developer
controlled by
operating
system
host or
server
process
TCP with
buffers,
variables
socket
controlled by
application
developer
controlled by
operating
system
host or
server
internet
TCP provides reliable, in-order
transfer of bytes (“pipe”)
between client and server
application viewpoint
2: Application Layer 23
Socket programming with TCP
Client must contact server
v server process must first be
running
v server must have created
socket (door) that welcomes
client’s contact
Client contacts server by:
v creating client-local TCP
socket
v specifying IP address, port
number of server process
v When client creates socket:
client TCP establishes
connection to server TCP
v When contacted by client,
server TCP creates new
socket for server process to
communicate with client
§ allows server to talk with
multiple clients
§ source port numbers used
to distinguish clients
2: Application Layer 24
Client/server socket interaction: TCP
wait for incoming
connection request
connectionSocket =
welcomeSocket.accept()
create socket,
port=x, for
incoming request:
welcomeSocket =
ServerSocket()
create socket,
connect to hostid, port=x
clientSocket =
Socket()
close
connectionSocket
read reply from
clientSocket
close
clientSocket
Server (running on hostid) Client
send request using
clientSocket read request from
connectionSocket
write reply to
connectionSocket
TCP
connection setup
2: Application Layer 25
Socket programming with TCP
Example client-server application:
1) client reads line from standard input (inFromUser stream) , sends
to server via socket (outToServer stream)
2) server reads line from socket
3) server converts line to uppercase, sends back to client
4) client reads, prints modified line from socket (inFromServer
stream)
2: Application Layer 26
Example: Java client (TCP)
import java.io.*;
import java.net.*;
class TCPClient {
public static void main(String argv[]) throws Exception
{
String sentence;
String modifiedSentence;
BufferedReader inFromUser =
new BufferedReader(new InputStreamReader(System.in));
Socket clientSocket = new Socket(“hostname”, 6789);
DataOutputStream outToServer =
new DataOutputStream(clientSocket.getOutputStream());
Create
input stream
Create
client socket,
connect to server
Create
output stream
attached to socket
2: Application Layer 27
Example: Java client (TCP), cont.
BufferedReader inFromServer =
new BufferedReader(new
InputStreamReader(clientSocket.getInputStream()));
sentence = inFromUser.readLine();
outToServer.writeBytes(sentence + ‘\n’);
modifiedSentence = inFromServer.readLine();
System.out.println(“FROM SERVER: ” + modifiedSentence);
clientSocket.close();
}
}
Create
input stream
attached to socket
Send line
to server
Read line
from server
2: Application Layer 28
Example: Java server (TCP)
import java.io.*;
import java.net.*;
class TCPServer {
public static void main(String argv[]) throws Exception
{
String clientSentence;
String capitalizedSentence;
ServerSocket welcomeSocket = new ServerSocket(6789);
while(true) {
Socket connectionSocket = welcomeSocket.accept();
BufferedReader inFromClient =
new BufferedReader(new
InputStreamReader(connectionSocket.getInputStream()));
Create
welcoming socket
at port 6789
Wait, on welcoming
socket for contact
by client
Create input
stream, attached
to socket
2: Application Layer 29
Example: Java server (TCP), cont
DataOutputStream outToClient =
new DataOutputStream(connectionSocket.getOutputStream());
clientSentence = inFromClient.readLine();
capitalizedSentence = clientSentence.toUpperCase() + ‘\n’;
outToClient.writeBytes(capitalizedSentence);
}
}
}
Read in line
from socket
Create output
stream, attached
to socket
Write out line
to socket
End of while loop,
loop back and wait for
another client connection
2: Application Layer 30
Socket programming with UDP
UDP: no “connection” between
client and server
v no handshaking
v sender explicitly attaches IP
address and port of
destination to each packet
v server must extract IP
address, port of sender from
received packet
UDP: transmitted data may be
received out of order, or lost
application viewpoint
UDP provides unreliable transfer
of groups of bytes (“datagrams”)
between client and server
2: Application Layer 31
Client/server socket interaction: UDP
Server (running on hostid)
close
clientSocket
read datagram from
clientSocket
create socket,
clientSocket = DatagramSocket()
Client
Create datagram with server IP and
port=x; send datagram via
clientSocket
create socket,
port= x.
serverSocket =
DatagramSocket()
read datagram from
serverSocket
write reply to
serverSocket
specifying
client address,
port number
2: Application Layer 32
Example: Java client (UDP)
import java.io.*;
import java.net.*;
class UDPClient {
public static void main(String args[]) throws Exception
{
BufferedReader inFromUser =
new BufferedReader(new InputStreamReader(System.in));
DatagramSocket clientSocket = new DatagramSocket();
InetAddress IPAddress = InetAddress.getByName(“hostname”);
byte[] sendData = new byte[1024];
byte[] receiveData = new byte[1024];
String sentence = inFromUser.readLine();
sendData = sentence.getBytes();
Create
input stream
Create
client socket
Translate
hostname to IP
address using DNS
2: Application Layer 33
Example: Java client (UDP), cont.
DatagramPacket sendPacket =
new DatagramPacket(sendData, sendData.length, IPAddress, 9876);
clientSocket.send(sendPacket);
DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
clientSocket.receive(receivePacket);
String modifiedSentence =
new String(receivePacket.getData());
System.out.println(“FROM SERVER:” + modifiedSentence);
clientSocket.close();
}
}
Create datagram
with data-to-send,
length, IP addr, port
Send datagram
to server
Read datagram
from server
2: Application Layer 34
Example: Java server (UDP)
import java.io.*;
import java.net.*;
class UDPServer {
public static void main(String args[]) throws Exception
{
DatagramSocket serverSocket = new DatagramSocket(9876);
byte[] receiveData = new byte[1024];
byte[] sendData = new byte[1024];
while(true)
{
DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
serverSocket.receive(receivePacket);
Create
datagram socket
at port 9876
Create space for
received datagram
Receive
datagram
2: Application Layer 35
Example: Java server (UDP), cont
String sentence = new String(receivePacket.getData());
InetAddress IPAddress = receivePacket.getAddress();
int port = receivePacket.getPort();
String capitalizedSentence = sentence.toUpperCase();
sendData = capitalizedSentence.getBytes();
DatagramPacket sendPacket =
new DatagramPacket(sendData, sendData.length, IPAddress,
port);
serverSocket.send(sendPacket);
}
}
}
Get IP addr
port #, of
sender
Write out
datagram
to socket
End of while loop,
loop back and wait for
another datagram
Create datagram
to send to client
Application Layer 2-36
Summary
v application architectures
§ client-server
§ P2P
v application service
requirements:
§ reliability, bandwidth, delay
v Internet transport service
model
§ connection-oriented,
reliable: TCP
§ unreliable, datagrams:
UDP
our study of network applications now complete!
v specific protocols:
§ HTTP
§ SMTP, POP, IMAP
§ DNS
v socket programming:
TCP, UDP sockets