Internet transport protocols services

TCP service: UDP service:

 reliable transport between sending  unreliable data transfer
and receiving process between sending and receiving
 flow control: sender won’t process
overwhelm receiver  does not provide: reliability,
 congestion control: throttle/reduce flow control, congestion
sender data rate when network control, timing, throughput
overloaded guarantee, security, or
connection setup.
 connection-oriented: setup required
between client and server processes Q: why bother? Why
 does not provide: timing, minimum is there a UDP?
throughput guarantee, security Application Layer: 2-1
Application Layer: Overview
 P2P applications
 Principles of network  video streaming and content
applications distribution networks
 Web and HTTP  socket programming with
 E-mail, SMTP, IMAP UDP and TCP
 The Domain Name System
DNS

Application Layer: 2-2

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

Application Layer: 2-3

DNS: services, structure
DNS services: Q: Why not centralize DNS?
 hostname-to-IP-address translation  single point of failure
 traffic volume
 host aliasing
 distant centralized database
• canonical, alias names
 maintenance
 mail server aliasing
 load distribution A: doesn‘t scale!
• replicated Web servers: many IP  Comcast DNS servers alone:
addresses correspond to one 600B DNS queries/day
name  Akamai DNS servers alone:
2.2T DNS queries/day

Application Layer: 2-4

 DNS: a distributed, hierarchical database

Root DNS Servers Root

… …
.com DNS servers .org DNS servers .edu DNS servers Top Level Domain
… … … …
yahoo.com amazon.com pbs.org nyu.edu umass.edu
DNS servers DNS servers DNS servers DNS servers DNS servers Authoritative

Client wants IP address 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
Application Layer: 2-5
DNS: root name servers
 official, contact-of-last-resort by
name servers that can not
resolve name

Application Layer: 2-6

DNS: root name servers
 official, contact-of-last-resort by
name servers that can not 13 logical root name “servers”
worldwide each “server” replicated
resolve name many times (~200 servers in US)
 incredibly important Internet
function
• Internet couldn’t function without it!
• DNSSEC – provides security
(authentication, message integrity)
 ICANN (Internet Corporation for
Assigned Names and Numbers)
manages root DNS domain

Application Layer: 2-7

Top-Level Domain, and authoritative servers
Top-Level Domain (TLD) servers:
 responsible for .com, .org, .net, .edu, .aero, .jobs, .museums, and all top-level
country domains, e.g.: .cn, .uk, .fr, .ca, .jp
 Network Solutions: authoritative registry for .com, .net TLD
 Educause: .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 servers
 when host makes DNS query, it is sent to its local DNS server
• Local DNS server returns reply, answering:
• from its local cache of recent name-to-address translation pairs (possibly out
of date!)
• forwarding request into DNS hierarchy for resolution
• each ISP has local DNS name server; to find yours:
• MacOS: % scutil --dns
• Windows: >ipconfig /all
 local DNS server doesn’t strictly belong to hierarchy

Application Layer: 2-9

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

Application Layer: 2-10

DNS name resolution: recursive query
root DNS server
Example: host at engineering.nyu.edu
wants IP address for gaia.cs.umass.edu 2 3

7 6
Recursive query: 1 TLD DNS server
 puts burden of name 8
resolution on requesting host at local DNS server
5 4
engineering.nyu.edu dns.nyu.edu
contacted name gaia.cs.umass.edu

server
 heavy load at upper authoritative DNS server
levels of hierarchy? dns.cs.umass.edu

Application Layer: 2-11

Caching DNS Information
 once (any) name server learns mapping, it caches mapping,
and immediately returns a cached mapping in response to a
query
• caching improves response time
• cache entries timeout (disappear) after some time (TTL)
• TLD servers typically cached in local name servers
 cached entries may be out-of-date
• if named host changes IP address, may not be known Internet-
wide until all TTLs expire!
• best-effort name-to-address translation!

Application Layer: 2-12

DNS records
DNS: distributed database storing resource records (RR)
RR format: (name, value, type, ttl)

type=A type=CNAME
 name is hostname  name is alias name for some “canonical”
 value is IP address (the real) name
 www.ibm.com is really servereast.backup2.ibm.com
type=NS  value is canonical name
 name is domain (e.g., foo.com)
 value is hostname of type=MX
 value is name of SMTP mail
authoritative name server for
this domain server associated with name
Application Layer: 2-13
DNS protocol messages
DNS query and reply messages, both have same format:
2 bytes 2 bytes

message header: identification flags

 identification: 16 bit # for query, # questions # answer RRs

reply to query uses same # # authority RRs # additional RRs

 flags:
questions (variable # of questions)
• query or reply
• recursion desired
answers (variable # of RRs)
• recursion available
• reply is authoritative authority (variable # of RRs)

additional info (variable # of RRs)

Application Layer: 2-14

 DNS protocol messages
DNS query and reply messages, both have same format:
2 bytes 2 bytes

identification flags

# questions # answer RRs

# authority RRs # additional RRs

name, type fields for a query questions (variable # of questions)

RRs in response to query answers (variable # of RRs)

records for authoritative servers authority (variable # of RRs)

additional “ helpful” info that may additional info (variable # of RRs)

be used
Application Layer: 2-15
Getting your info into the 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 NS, A RRs into .com TLD server:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
 create authoritative server locally with IP address 212.212.212.1
• type A record for www.networkuptopia.com
• type MX record for networkutopia.com

Application Layer: 2-16

DNS security
DDoS attacks Spoofing attacks
 bombard root servers with  intercept DNS queries,
traffic returning bogus replies
 DNS cache poisoning
• not successful to date
 RFC 4033: DNSSEC
• traffic filtering
authentication services
• local DNS servers cache IPs of TLD
servers, allowing root server
bypass
 bombard TLD servers
• potentially more dangerous

Application Layer: 2-17

Application Layer: Overview
 P2P applications
 Principles of network  video streaming and content
applications distribution networks
 Web and HTTP  socket programming with
 E-mail, SMTP, IMAP UDP and TCP
 The Domain Name System
DNS

Application Layer: 2-18

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

transport transport
network network controlled
link
by OS
link Internet
physical physical

Application Layer: 2-19

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

Application Layer: 2-20

Socket programming with UDP
UDP: no “connection” between
client and 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 processes
Application Layer: 2-21
Client/server socket interaction: UDP
server (running on serverIP) client
create socket:
create socket, port= x: clientSocket =
serverSocket = socket(AF_INET,SOCK_DGRAM)
socket(AF_INET,SOCK_DGRAM)
Create datagram with serverIP address
And port=x; send datagram via
read datagram from clientSocket
serverSocket

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

Application Layer: 2-23

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

Application Layer: 2-24

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

wait for incoming create socket,

connection request
TCP connect to hostid, port=x
connectionSocket = connection setup clientSocket = socket()
serverSocket.accept()

send request using

read request from clientSocket
connectionSocket

write reply to
connectionSocket read reply from
clientSocket
close
connectionSocket close
clientSocket
Application Layer: 2-26
Example app: TCP client
Python TCPClient
from socket import *
serverName = ’servername’
serverPort = 12000
create TCP socket for server, clientSocket = socket(AF_INET, SOCK_STREAM)
remote port 12000
clientSocket.connect((serverName,serverPort))
sentence = raw_input(‘Input lowercase sentence:’)
clientSocket.send(sentence.encode())
No need to attach server name, port modifiedSentence = clientSocket.recv(1024)
print (‘From Server:’, modifiedSentence.decode())
clientSocket.close()

Application Layer: 2-27

Example app: TCP server
Python TCPServer
from socket import *
serverPort = 12000
create TCP welcoming socket serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind((‘’,serverPort))
server begins listening for
incoming TCP requests
serverSocket.listen(1)
print ‘The server is ready to receive’
loop forever while True:
server waits on accept() for incoming connectionSocket, addr = serverSocket.accept()
requests, new socket created on return

read bytes from socket (but sentence = connectionSocket.recv(1024).decode()

not address as in UDP) capitalizedSentence = sentence.upper()
connectionSocket.send(capitalizedSentence.
encode())
close connection to this client (but not connectionSocket.close()
welcoming socket)
Application Layer: 2-28