Reti di calcolatori e
Sicurezza
-- Application Layer --Part of these slides are adapted from the slides of the book:
Computer Networking: A Top Down Approach Featuring the Internet,
2nd edition.
Jim Kurose, Keith Ross
Addison-Wesley, July 2002.
(copyright 1996-2002
J.F Kurose and K.W. Ross, All Rights Reserved)
Introduction
1-1
Chapter 2: Application Layer
Our goals:
 conceptual,
implementation
aspects of network
application protocols
 transport-layer
service models
 client-server
paradigm

peer-to-peer
paradigm
 learn about protocols
by examining popular
application-level
protocols




HTTP
FTP
SMTP / POP3 / IMAP
DNS
 programming network
applications

socket API
Introduction
1-2
Chapter 2 outline
 2.1 Principles of app
layer protocols


clients and servers
app requirements
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Socket programming
with TCP (facoltativo)
 2.7 Socket programming
with UDP (facoltativo)
 2.8 Building a Web
server (facoltativo)
 2.9 Content distribution
(self study)



Network Web caching
Content distribution
networks
P2P file sharing
Introduction
1-3
Applicazioni
Applicazioni di rete
 Insieme di processi
distribuiti: sono in esecuzione
su di un host connesso in rete
 Cooperano tramite scambio di
messaggi
 e.g., email, file transfer, P2P
file sharing, IM, Web,
Protocolli del livello delle applicazioni
 Una componente delle
applicazioni di rete
 Definiscono la struttura dei
msg
 Richieste di servizio ai livelli
inferiori
application
transport
network
data link
physical
application
transport
network
data link
physical
application
transport
network
data link
physical
Introduction
1-4
Protocolli livello applicazioni
 Tipo dei msg scambiati
 Sintassi dei msg
 Semantica header dei
msg
 Regole di elaborazione
Public-domain protocols:
 RFC
 Interoperability

HTTP, SMTP
Proprietary protocols:
KaZaA
Introduction
1-5
Terminologia comune
 user agent: interfaccia tra le applicazioni di
rete ed i protocolli di comunicazione del
livello delle applicazioni.
Web:browser
 E-mail: mail reader
 App. audio/video: player

Introduction
1-6
Il modello Client - Server
Si identificano due componenti:
client e server
Client:
 Connette al server (“speaks
first”)
 Effettua la richiesta del
servizio,
 E.g. Web: cliente è il browser;
e-mail: cliente è il mail reader
Server:
 Fornisce un certo numero di
servizi (in risposta alle
richieste del cliente)
 Web server invia le pagine
richieste
application
transport
network
data link
physical
request
reply
application
transport
network
data link
physical
Introduction
1-7
Processes communicating across network
 process sends/receives
messages to/from its
socket
 socket analogous to door


sending process shoves
message out door
sending process asssumes
transport infrastructure
on other side of door which
brings message to socket
at receiving process
host or
server
host or
server
process
controlled by
app developer
process
socket
socket
TCP with
buffers,
variables
Internet
TCP with
buffers,
variables
controlled
by OS
 API: (1) choice of transport protocol; (2) ability to fix
a few parameters (lots more on this later)
Introduction
1-8
Addressing processes:
 For a process to
receive messages, it
must have an identifier
 Every host has a unique
32-bit IP address
 Q: does the IP address
of the host on which
the process runs
suffice for identifying
the process?
 Answer: No, many
processes can be
running on same host
 Identifier includes
both the IP address
and port numbers
associated with the
process on the host.
 Example port numbers:


HTTP server: 80
Mail server: 25
 More on this later
Introduction
1-9
Quali sono I requisiti di servizio delle
applicazioni di rete
Data loss
 Alcune app. (e.g., audio)
possono tollerare la perdita di
dati
 Altre app. (e.g., file transfer,
telnet) richiedono il 100% di
affidabilità nella trasmissione
dei dati
Bandwidth
Timing
 App (e.g., Internet telephony)
non possono ammettere dei
ritardi nella trasmissione dei
dati
 Alcune app. (e.g.,
multimedia) richiedono di
avere almeno un
determinato livello di banda
per poter operare
 Altre applicazioni (“elastic
apps”) non fanno richieste
sulla banda di trasmissione
Introduction
1-10
Requisiti applicazioni
Data loss
Bandwidth
Time Sensitive
file transfer
e-mail
Web documents
real-time audio/video
no loss
no loss
no loss
loss-tolerant
no
no
no
yes, 100’s msec
stored audio/video
interactive games
instant messaging
loss-tolerant
loss-tolerant
no loss
elastic
elastic
elastic
audio: 5kbps-1Mbps
video:10kbps-5Mbps
same as above
few kbps up
elastic
Application
yes, few secs
yes, 100’s msec
yes and no
Introduction
1-11
I servizi di trasporto
TCP:
 connection-oriented: richiede
una fase di inizializzazione
 affidabile
 Controllo del flusso e della
congestione
 Non fornisce: timing, e un
livello minimo di banda
UDP:
 Non affidabilie
 No controllo del
flusso e della
congestione
D: Come mai esiste
UDP?
Introduction
1-12
Internet apps: application, transport protocols
Application
e-mail
remote terminal access
Web
file transfer
streaming multimedia
Internet telephony
Application
layer protocol
Underlying
transport protocol
SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
proprietary
(e.g. RealNetworks)
proprietary
(e.g., Dialpad)
TCP
TCP
TCP
TCP
TCP or UDP
typically UDP
Introduction
1-13
Seminari approfondimento
 2004: QoS
 2004: Teleconferenze
Introduction
1-14
Chapter 2 outline
 2.1 Principles of app
layer protocols


clients and servers
app requirements
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Socket programming
with TCP
 2.7 Socket programming
with UDP
 2.8 Building a Web
server
 2.9 Content distribution



Network Web caching
Content distribution
networks
P2P file sharing
Introduction
1-15
Web and HTTP
First some jargon
 Web page consists of objects
 Object can be HTML file, JPEG image, Java
applet, audio file,…
 Web page consists of base HTML-file which
includes several referenced objects
 Each object is addressable by a URL
 Example URL:
www.someschool.edu/someDept/pic.gif
host name
path name
Introduction
1-16
HTTP overview
HTTP: hypertext
transfer protocol
 Web’s application layer
protocol
 client/server model
 client: browser that
requests, receives,
“displays” Web objects
 server: Web server
sends objects in
response to requests
 HTTP 1.0: RFC 1945
 HTTP 1.1: RFC 2068
PC running
Explorer
Server
running
Apache Web
server
Mac running
Navigator
Introduction
1-17
HTTP overview (continued)
Uses TCP:
 client initiates TCP
connection (creates socket)
to server, port 80
 server accepts TCP
connection from client
 HTTP messages (applicationlayer protocol messages)
exchanged between browser
(HTTP client) and Web
server (HTTP server)
 TCP connection closed
HTTP is “stateless”
 server maintains no
information about
past client requests
aside
Protocols that maintain
“state” are complex!
 past history (state) must
be maintained
 if server/client crashes,
their views of “state” may
be inconsistent, must be
reconciled
Introduction
1-18
HTTP connections
Nonpersistent HTTP
 At most one object is
sent over a TCP
connection.
 HTTP/1.0 uses
nonpersistent HTTP
Persistent HTTP
 Multiple objects can
be sent over single
TCP connection
between client and
server.
 HTTP/1.1 uses
persistent connections
in default mode
Introduction
1-19
Nonpersistent HTTP
(contains text,
Suppose user enters URL
references to 10
www.someSchool.edu/someDepartment/home.index
jpeg images)
1a. HTTP client initiates TCP
connection to HTTP server
(process) at
www.someSchool.edu on port 80
2. HTTP client sends HTTP
request message (containing
URL) into TCP connection
socket. Message indicates
that client wants object
someDepartment/home.index
1b. HTTP server at host
www.someSchool.edu waiting
for TCP connection at port 80.
“accepts” connection, notifying
client
3. HTTP server receives request
message, forms response
message containing requested
object, and sends message
into its socket
time
Introduction
1-20
Nonpersistent HTTP (cont.)
4. HTTP server closes TCP
5. HTTP client receives response
connection.
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
Introduction
1-21
Response time modeling
Definition of RRT: time to
send a small packet to
travel from client to
server and back.
Response time:
 one RTT to initiate TCP
connection
 one RTT for HTTP
request and first few
bytes of HTTP response
to return
 file transmission time
total = 2RTT+transmit time
initiate TCP
connection
RTT
request
file
time to
transmit
file
RTT
file
received
time
time
Introduction
1-22
Persistent HTTP
Nonpersistent HTTP issues:
 requires 2 RTTs per object
 OS must work and allocate
host resources for each TCP
connection
 but browsers often open
parallel TCP connections to
fetch referenced objects
Persistent HTTP
 server leaves connection
open after sending response
 subsequent HTTP messages
between same client/server
are sent over connection
Persistent without pipelining:
 client issues new request
only when previous
response has been received
 one RTT for each
referenced object
Persistent with pipelining:
 default in HTTP/1.1
 client sends requests as
soon as it encounters a
referenced object
 as little as one RTT for all
the referenced objects
Introduction
1-23
Non Persistente vs persistente
Introduction
1-24
Persistente: non pipeling vs pipeling
Introduction
1-25
HTTP request message
 two types of HTTP messages: request, response
 HTTP request message:
 ASCII (human-readable format)
request line
(GET, POST,
HEAD commands)
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
User-agent: Mozilla/4.0
header Connection: close
lines Accept-language:fr
Carriage return,
line feed
indicates end
of message
(extra carriage return, line feed)
Introduction
1-26
HTTP request message: general format
Introduction
1-27
Uploading form input
Post method:
 Web page often
includes form input
 Input is uploaded to
server in entity body
URL method:
 Uses GET method
 Input is uploaded in
URL field of request
line:
www.somesite.com/animalsearch?monkeys&banana
Introduction
1-28
Method types
HTTP/1.0
 GET
 POST
 HEAD

asks server to leave
requested object out of
response
HTTP/1.1
 GET, POST, HEAD
 PUT

uploads file in entity
body to path specified
in URL field
 DELETE
 deletes file specified in
the URL field
Introduction
1-29
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 ...
Introduction
1-30
HTTP response status codes
In first line in server->client response message.
A few sample codes:
200 OK

request succeeded, requested object later in this message
301 Moved Permanently

requested object moved, new location specified later in
this message (Location:)
400 Bad Request

request message not understood by server
404 Not Found

requested document not found on this server
505 HTTP Version Not Supported
Introduction
1-31
Trying out HTTP (client side) for yourself
1. Telnet to your favorite Web server:
telnet www.eurecom.fr 80 Opens TCP connection to port 80
(default HTTP server port) at www.eurecom.fr.
Anything typed in sent
to port 80 at www.eurecom.fr
2. Type in a GET HTTP request:
GET /~ross/index.html HTTP/1.0
By typing this in (hit carriage
return twice), you send
this minimal (but complete)
GET request to HTTP server
3. Look at response message sent by HTTP server!
Introduction
1-32
esercizio
 Come si fa a far rispondere al server
301 Moved Permanently

requested object moved, new location specified
later in this message (Location:)
Introduction
1-33
User-server interaction: authorization
Authorization : control access to
server
client
server content
usual http request msg
 authorization credentials:
typically name, password
401: authorization req.
WWW authenticate:
 stateless: client must present
authorization in each request
 authorization: header line in
usual http request msg
+ Authorization: <cred>
each request
 if no authorization: header,
usual http response msg
server refuses access,
sends
WWW authenticate:
header line in response
usual http request msg
+ Authorization: <cred>
usual http response msg
time
Introduction
1-34
Cookies: keeping “state”
Many major Web sites
use cookies
Four components:
1) cookie header line in
the HTTP response
message
2) cookie header line in
HTTP request message
3) cookie file kept on
user’s host and managed
by user’s browser
4) back-end database at
Web site
Example:



Susan access Internet
always from same PC
She visits a specific ecommerce site for first
time
When initial HTTP
requests arrives at site,
site creates a unique ID
and creates an entry in
backend database for
ID
Introduction
1-35
Cookies: keeping “state” (cont.)
client
Cookie file
server
usual http request msg
usual http response +
ebay: 8734
Cookie file
amazon: 1678
ebay: 8734
Set-cookie: 1678
usual http request msg
cookie: 1678
usual http response msg
one week later:
Cookie file
amazon: 1678
ebay: 8734
usual http request msg
cookie: 1678
usual http response msg
server
creates ID
1678 for user
cookiespecific
action
cookiespectific
action
Introduction
1-36
Cookies (continued)
What cookies can bring:
 authorization
 shopping carts
 recommendations
 user session state
(Web e-mail)
aside
Cookies and privacy:
 cookies permit sites to
learn a lot about you
 you may supply name
and e-mail to sites
 search engines use
redirection & cookies
to learn yet more
 advertising companies
obtain info across
sites
Introduction
1-37
Conditional GET: client-side caching
 Goal: don’t send object if
client has up-to-date cached
version
 client: specify date of
cached copy in HTTP request
If-modified-since:
<date>
 server: response contains no
object if cached copy is upto-date:
HTTP/1.0 304 Not
Modified
server
client
HTTP request msg
If-modified-since:
<date>
HTTP response
object
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>
Introduction
1-38
Seminari
 2004: Cookies
 Tipi di autenticazione su web
 Gestione sessioni in http
 Web services
Introduction
1-39
Chapter 2 outline
 2.1 Principles of app
layer protocols


clients and servers
app requirements
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Socket programming
with TCP
 2.7 Socket programming
with UDP
 2.8 Building a Web
server
 2.9 Content distribution



Network Web caching
Content distribution
networks
P2P file sharing
Introduction
1-40
ftp: file transfer protocol
user
FTP
FTP
user
client
interface
file transfer
FTP
server
File
system
locale
Sistema
remoto
 Funzionalità: trasferimento di dati (files) da/per il
sistema remoto
 Architettura software: client/server
 client: il sistema che attiva il trasferimento
 server: il sistema remoto
 ftp: RFC 959
 ftp server: port 21
Introduction
1-41
FTP: separate control, data connections
TCP control connection
port 21
 FTP client contacts FTP




server at port 21, specifying
TCP as transport protocol
Client obtains authorization
over control connection
Client browses remote
directory by sending
commands over control
connection.
When server receives a
command for a file transfer,
the server opens a TCP data
connection to client
After transferring one file,
server closes connection.
FTP
client
TCP data connection
port 20
FTP
server
 Server opens a second TCP
data connection to transfer
another file.
 Control connection: “out of
band”
 FTP server maintains “state”:
current directory, earlier
authentication
Introduction
1-42
FTP commands, responses
(PROVATELI!!)
Sample commands:
Sample return codes
 sent as ASCII text over
 status code and phrase (as
control channel
 USER username
 PASS password
 LIST return list of file in


current directory
 RETR filename retrieves

 STOR filename stores

(gets) file
(puts) file onto remote
host
in HTTP)
331 Username OK,
password required
125 data connection
already open;
transfer starting
425 Can’t open data
connection
452 Error writing
file
Introduction
1-43
Seminari
 Server/client ftp in Java
Introduction
1-44
Chapter 2 outline
 2.1 Principles of app
layer protocols


clients and servers
app requirements
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Socket programming
with TCP
 2.7 Socket programming
with UDP
 2.8 Building a Web
server
 2.9 Content distribution



Network Web caching
Content distribution
networks
P2P file sharing
Introduction
1-45
Strumenti per l’interazione fra
utenti: la posta elettronica
 Caratteristiche:
velocità
 versatilità
 economicità
 Indipendenza dal tempo
e dallo spazio

Introduction
1-46
Posta elettronica:
gli strumenti necessari
 Mailbox (casella postale)
 indirizzo posta elettronica
 PC connesso ad Internet
 programma “client” sul PC
Introduction
1-47
La Mailbox
•E’ il contenitore elettronico dei
messaggi ricevuti
 Normalmente risiede su un calcolatore potente e
sempre connesso alla rete
 Ha associato un indirizzo di posta elettronica
Introduction
1-48
Un applicativo di rete: la posta
elettronica
La posta elettronica (e-mail) consente di spedire
messaggi ad altri utenti connessi ad Internet.
I messaggi sono tipicamente preparati con programmi
di videoscrittura.
Ad essi possono essere allegati video e/o audio.
Gli indirizzi hanno la forma del seguente esempio:
nome utente
separatore
nome dominio
[email protected]
Introduction
1-49
Clienti di posta elettronica
 Eudora, Microsoft Outlook, Netscape messager,
Pine, Rmail …
 Comunicano con il server mediante il protocollo
SMTP
 Funzionalità





Risposta
Inoltro
Archiviazione e recupero messaggi
Reindirazzamento
Vacation
Introduction
1-50
Tecnica store-and-forward
• [email protected] manda un messaggio di
posta elettronica a [email protected].
•Il messaggio viene depositato sul server di
posta di domain.com.
•Il messaggio viene recapitato al destinario
solo quando questo si collega al sistema.
Introduction
1-51
Tecnica store-and-forward
Introduction
1-52
Tecnica store-and-forward
• [email protected] manda un messaggio di
posta elettronica a [email protected]
•Il messaggio viene inviato dal server di posta
di domain.com al server di posta di
anotherdomain.com
•Come nel caso precedente, il messaggio viene
recapitato al destinario solo quando questo si
collega al sistema
•Quindi la tecnica scala facilmente
Introduction
1-53
Funzioni del servizio: lettura
dei messaggi
• Protocollo POP3
• Username + password
• Trasferimento messaggi sul PC
e successiva lettura
Introduction
1-54
Funzioni del servizio: spedizione
dei messaggi
Mail da spedire
(indirizzo,
subject, testo)
(SMTP)
(SMTP)
INTERNET
Introduction
1-55
E-Mail: smtp [RFC 821]
 Basato su tcp per avere un trasferimento affidabile delle
mail, la porta 25 è la porta di default
 Trasferimento diretto tra i server coinvolti effettuato
in tre passi denominati:
 handshaking (greeting)
 transfer
 closure
 Modalità di interazione: command/response
 command: testo in formato ASCII
 response: status code e testo
 Messaggi sono codificati in 7-bit ASCII
Introduction
1-56
Scenario: Alice e Bob
4) SMTP (lato cliente)
trasmette il messaggio di
Alice sulla connessione TCP
5) Il mailserver di Bob
memorizza il messaggio
nella mailbox di Bob
6) Bob legge il messaggio
tramite il suo user agent
1) Alice vuole inviare una email a
[email protected]
2) Messsaggio è inserito nella
coda del mail server
3) SMTP (lato cliente) apre
una connessione TCP con il
mail server di Bob
1
user
agent
2
mail
server
3
mail
server
4
5
6
user
agent
Introduction
1-57
Esempio di interazione smtp
S:
C:
S:
C:
S:
C:
S:
C:
S:
C:
C:
C:
S:
C:
S:
220 hamburger.edu
HELO crepes.fr
250 Hello crepes.fr, pleased to meet you
MAIL FROM: <[email protected]>
250 [email protected]... Sender ok
RCPT TO: <[email protected]>
250 [email protected] ... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Do you like ketchup?
How about pickles?
.
250 Message accepted for delivery
QUIT
221 hamburger.edu closing connection
Introduction
1-58
Piccole esercitazione:
 telnet server_di_posta 25
 220 reply from server
 Digitare i comandi HELO, MAIL FROM, RCPT TO,
DATA, QUIT
Introduction
1-59
smtp
 smtp utilizza connessioni
persistenti
 Smtp: formato dei
messaggi (header & body)
in 7-bit ascii
 Caratteri non permessi
(e.g., CRLF.CRLF). Codifica
dei messaggi (in base-64 o
quoted printable)
 smtp server: utilizza
CRLF.CRLF per indicare la
fine del msg
Smtp vs http
 http: pull
 email: push
 Interazione ASCII di tipo
command/response + status
codes
 http: ogni oggetto è
incapsulato nella risposta
 smtp: multipart message
con oggetti multipli (eg
attachment)
Introduction
1-60
Seminari
 MIME,smime,etc
Introduction
1-61
POP3-IMAP4
Introduction
1-62
Accesso alla posta
 Esistono diversi protocolli per costruire una
infrastruttura distribuita per la gestione delle
email. I piu’ diffusi sono:

POP3 - Post Office Protocol versione 3
• Protocollo molto ‘vecchio’ quindi molto diffuso
• Semplice
• Gestisce la posta in “locale”: scarica i messaggi!

IMAP4 - Internet Message Access Protocol (ver 4)
• Piu’ complesso del POP3
• Permette la gestione delle mailbox remote come se fossero
locali
Introduction
1-63
POP3
 Funziona con paradigma client-server
 Supporta le funzioni di base per il recupero
della posta elettronica da mailbox remota
Download
 Delete

Introduction
1-64
Come funziona
 Il client POP3 si connette tramite TCP alla porta 110 del
server
 Il server POP3 risponde con messaggio di benvenuto
 La sessione entra nello stato di autenticazione

Il client manda la sua idetificazione (user-id e password)
 Se il server riconosce il client si entra nello stato di
transazione

Il client puo’ accedere alla mailbox
 Quando il client esegue il comando quit si entra nello stato
update e la connessione e’ chiusa
Introduction
1-65
IMAP4
 Supporta i modelli di posta elettronica
 Off-line (POP3): il client si connette periodicamente al
server e scarica i messaggi (processati localmente)
 On-line il client esegue delle modifiche sul server
(accesso tramite protocollo di file system remoto NFS)
 Disconnected: (modo “ibrido”) il client si connette al
server, scarica i messaggi, li processa localmente e poi li
aggiorna sul server
 Connessione su porta 143
Introduction
1-66
POP3
authorization phase
 client:
user: username
 pass: password
 Server:
 +OK
 -ERR

transaction phase, client:
 list: list (message
numbers)
 retr: retrieve message
 dele: delete
 quit
S:
C:
S:
C:
S:
+OK POP3 server ready
user alice
+OK
pass hungry
+OK user successfully logged
C:
S:
S:
S:
C:
S:
S:
C:
C:
S:
S:
C:
C:
S:
list
1 498
2 912
.
retr 1
<message 1 contents>
.
dele 1
retr 2
<message 1 contents>
.
dele 2
quit
+OK POP3 server signing off
Introduction
on
1-67
Confronto POP3-IMAP4
 POP3= recupero su richiesta verso un singolo client
 IMAP4= accesso interattivo a piu’ mailbox da piu’ client
 Vantaggi filosofia POP3:


Uso minimo del tempo di connessione.
Uso minimo delle risorse del server.
 Vantaggi filosofia IMAP4:




Possibilita’ di usare diversi computer in tempi diversi
Possibilita’ di usare macchine con client “senza-dati” (nei
laboratori).
Accesso indipendente dalla piattaforma
Accesso concorrente a mailbox condivise.
Introduction
1-68
Posta elettronica: e-mail
 Per lo scambio di messaggi elettronici
 Un messaggio contiene:
 Uno o più destinatari nel campo TO
 Destinatari per conoscenza (CC)
 Destinatari per conoscenza “in incognito” (BCC)
 Subject: tema del messaggio
 Testo del messaggio
 Eventuali allegati
Introduction
1-69
Convenzioni e netiquette
 Comunicazione di stati d’animo con le faccette:
(emoticons)
:-) sorridente e scherzoso ;-) malizioso
:-( triste
:-I indifferente
:-> sarcastico
>:-> diabolico
:-/ perplesso
:-D sorpreso
:-O molto sorpreso >;-> ammiccante e diabolico
 Usare lettere maiuscole equivale ad URLARE
Introduction
1-70
Il lingo













AFAIK As Far As I Know
AKA
Also Known As
BBIAB Be Back in a Bit
BBIAF Be Back in a Few
BBL
Be Back Later
BFN
Bye For Now
BTW
By The Way
CID
Consider It Done
CIO
Check It Out
CUL8R See You Later
FYA
For Your Amusement
FYI
For Your Information
GTSY
Glad To See Ya













GYPO
IMO
IOW
IRL
KIT
MOTD
POV
RSN
RTM
TIA
TX
TYVM
WB
Get Your Pants Off
In My Opinion
In Other Words
In Real Life
Keep In Touch
Message Of The Day
Point of View
Real Soon Now
Read The Manual
Thanks in Advance
Thanks
Thank You Very Much
Welcome Back
Introduction
1-71
Attachments
• tecnica per spedire via E-mail
ogni tipo di file
• codifica e decodifica automatiche con i
migliori client
• limitare dimensione (< 1 mb)
Introduction
1-72
MIME: multimedia extensions
 MIME: multimedia mail extension, RFC 2045, 2056
 Campi addizionali presenti per la dichiarazione dei MIME
content type
MIME version
Metodo di codifica
Dati multimediali
type, subtype,
parameter
Dati codificati
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
Introduction
1-73
MIME types
Content-Type: type/subtype; parameters
Text
 subtypes: plain, html
Image
 subtypes: jpeg, gif
Audio
 subtypes: basic (8-bit
coding), 32kadpcm (32
kbps coding)
Video
 subtypes: mpeg,
quicktime
Applications
 Invocate per rendere
“viewable” questi tipi
 subtypes: msword,
octet-stream
Introduction
1-74
Multipart Type Message
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=98766789
--98766789
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain
Dear Bob,
Please find a picture of a crepe.
--98766789
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
--98766789--
Introduction
1-75






























Return-Path: <[email protected]>
Received: from phobos.unich.it (phobos.unich.it [192.167.13.101])
by gotham.sci.unich.it (8.12.8/8.12.8) with ESMTP id i8GAZMaS011065
for <[email protected]>; Thu, 16 Sep 2004 12:35:23 +0200
Received: from phobos.unich.it (phobos.unich.it [127.0.0.1])
by phobos.unich.it (8.12.5/8.12.8) with ESMTP id i8GAZ7Rv024306
for <[email protected]>; Thu, 16 Sep 2004 12:35:07 +0200
Received: from sci111.sci.unich.it ([192.167.92.11])
by phobos.unich.it (MailMonitor for SMTP v1.2.2 ) ;
Thu, 16 Sep 2004 12:35:06 +0200 (CEST)
Message-ID: <[email protected]>
From: "Maura Fancello" <[email protected]>
To: "stefano Bistarelli" <[email protected]>
References: <[email protected]>
<[email protected]>
Subject: Re: lavagna luminosa e proiettore
Date: Thu, 16 Sep 2004 12:34:10 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0015_01C49BE9.77729620"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com)
X-Antivirus-Summary: Mod score: 0
X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com)
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on gotham.sci.unich.it
X-Spam-Level:
X-Spam-Status: No, hits=-4.8 required=3.0 tests=BAYES_00,HTML_MESSAGE Introduction
autolearn=no version=2.63
1-76
Chapter 2 outline
 2.1 Principles of app
layer protocols


clients and servers
app requirements
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Socket programming
with TCP
 2.7 Socket programming
with UDP
 2.8 Building a Web
server
 2.9 Content distribution



Network Web caching
Content distribution
networks
P2P file sharing
Introduction
1-77
Domain Name Server (DNS)
pluto.sci.unich.it ?
192.167.92.33 !
158.110.1.7
Introduction
1-78
DNS: le funzioni
 ad ogni risorsa TCP/IP può essere assegnato un nome
simbolico
sono necessari:


un metodo per associare il nome simbolico di una macchina
all’indirizzo (o agli indirizzi) IP: risoluzione diretta
un metodo per associare ad un indirizzo IP al nome simbolico
della macchina: risoluzione inversa
 Domain Name System (DNS)



definito presso ISI - USC 1984
RFC 882, RFC 883, RFC 973 (obsolete)
RFC 1034, RFC 1035, RFC 1123, RFC 1537, RFC 1912
Introduction
1-79
Un po’ di storia
 Ai tempi di ARPANET esisteva in ogni sistema
opertivo un unico file, hosts.txt, che elencava tutti
gli host e i loro indirizzi IP. Ogni notte tutti gli
host della rete lo copiavano dal sito in cui era
mantenuto
 Quando la rete comprendeva solo qualche centinaio
di grosse macchine questo approccio funzionava
bene; quando la rete crebbe venne inventato il
servizio DNS (Domain Name Server), definito nei
documenti RFC 1034 e 1035
Introduction
1-80
DNS: caratteristiche principali
 database distribuito
 basato sul modello client/server
 tre componenti principali:
• spazio dei nomi e informazioni associate
(Resource Record - RR)
• nameserver (application server che mantiene i dati)
• resolver (client per l’interrogazione del nameserver)
 accesso veloce ai dati (database in memoria centrale
e meccanismo di caching)
Introduction
1-81
Esempio
 Hosts
cheltenham.cs.princeton.edu
192.12.69.17
192.12.69.17
80:23:A8:33:5B:9F
 Files
/usr/llp/tmp/foo
(server, fileid)
 Users
Stefano Bistarelli
[email protected]
Introduction
1-82
Esempio
 Mailboxes
2
cs.princeton.edu
Name
server
User
1
user @ cs.princeton.edu
Mail
program
192.12.69.5
192.12.69.5
3
4
TCP
192.12.69.5
5
IP
Introduction
1-83
Lo spazio dei nomi
 lo spazio dei nomi è organizzato secondo il modello gerarchico:
•
•
•
•
il database del DNS ha una struttura logica “ad albero rovesciato”
ciascun nodo dell’albero rappresenta un dominio
ogni dominio può essere suddiviso in altri domini: sottodomini
ogni nodo ha una etichetta che lo identifica rispetto al padre
La radice dell'albero è unica, e la sua etichetta è vuota. In certi casi si
indica anche come “.”
 struttura dello spazio dei nomi:
• domini generali (gTLD)
• domini nazionali (ccTLD)
• domini per la risoluzione inversa (arpa)
Introduction
1-84
DNS
 Gerarchia di naming
edu
princeton … mit
cs
com
gov
cisco … yahoo nasa … nsf
mil
org
net
arpa … navy
acm … ieee
uk
fr
ee physics
ux01 ux04
Introduction
1-85
Gerarchie di naming
 Il nome di un dominio è composto dal cammino inverso dalla
foglia fino alla radice (anonima); i componenti del cammino
sono separati da punti.
 I nomi dei domini sono insensibili alle maiuscole/minuscole
 I nomi all’interno dei cammini possono essere lunghi al più 63
caratteri, mentre un cammino non può superare
complessivamente i 255 caratteri
 Esempio: il dominio del dipartimento di scienze a Pescara è
sci.unich.it
Introduction
1-86
Interrogare il DNS
 Il programma nslookup permette di interrogare il
DNS


Per convertire un nome di dominio in numero IP
Per convertire un numero IP in nome di dominio
 La funzione nslookup è presente in tutti i sistemi
operativi (es Windows 2000)
 Il sito Web www.infobear.com/nslookup.shtml
permette di interrogare via Web il DNS
 Il sito www.nic.it/RA/database/database.html accede
al registro della Registration Authority italiana
Introduction
1-87
Name Servers
 In teoria un solo name server potrebbe contenere
l’intero database DNS mondiale; in pratica, questo
server sarebbe così sovraccarico da essere
inservibile. Inoltre, se mai si guastasse, l’intera
Internet sarebbe bloccata.
 Nota: Nel 2000 c’erano solo 13 root name
servers:10 negli USA, uno a Londra, uno a
Stoccolma, uno a Tokyo
 www.icann.org/committees/dns-root/y2kstatement.htm
Introduction
1-88
Zone
 Lo spazio dei nomi DNS è suddiviso in zone non sovrapposte (cioè
senza intersezione); normalmente una zona avrà un name server
principale, che legge informazioni da un file sul proprio disco, ed
uno o più name server secondari, che prendono le loro
informazioni dal name server principale
 Per migliorare l’affidabilità, è possibile che alcuni server di zona
si trovino al di fuori della zona stessa.
 Dove siano posti i confini di una zona è affare
dell’amministratore della zona. Questa decisione è in gran parte
basata su quanti name server si vogliono e dove vanno collocati.
Introduction
1-89
Name Servers
 Partizione della gerarchia in zone
edu
princeton … mit
cs
ee
com
gov
cisco … yahoo nasa … nsf
mil
org
arpa … navy
acm … ieee
net
uk
fr
physics
ux01 ux04
Root
name server
 Ogni zona può avere
due o piu’ name servers
Princeton
name server
CS
name server
…
…
Cisco
name server
EE
name server
Introduction
1-90
DNS name servers
DNS centralizzato
 Punto di fallimento globale
 Volume di traffico elevato
 Database remoto
 maintenance
 Nessun server memorizza
l’associazione name-to-IP
address per tutta Internet
local name servers:


Non scala!!!
ogni ISP ha un local (default)
name server
Primo passo: query al local
name server
authoritative name server:


host: memorizza l’indirizzo IP
ed il nome del sistema
Effettua la traduzione
name/IP address translation
Introduction
1-91
DNS
 Quando un programma deve trasformare un nome
in un indirizzo IP chiama una procedura detta
risolutrice (resolver), passandole il nome come
parametro di ingresso.
 Il resolver interroga un server DNS locale, che
cerca il nome nelle sue tabelle e restituisce
l’indirizzo al resolver, che a sua volta lo trasmette
al programma chiamante (usando tale indirizzo IP il
programma può aprire una connessione di rete con
la destinazione)
Introduction
1-92
DNS: Root name servers
 Contattati dai name server locali root name server:



Interagiscono con il name server di autorità (se non possono
risolvere direttamente ilo nome)
Ottengono il mapping
Restituiscono il risultato
a NSI Herndon, VA
c PSInet Herndon, VA
d U Maryland College Park, MD
g DISA Vienna, VA
h ARL Aberdeen, MD
j NSI (TBD) Herndon, VA
k RIPE London
i NORDUnet Stockholm
m WIDE Tokyo
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
Introduction
1-93
DNS: Un Esempio
root name server
host surf.eurecom.fr
2
vuole determinare
5
l’indirizzo IP del nome
gaia.cs.umass.edu
1. Collegamento con il server
DNS locale
dns.eurecom.fr
local name server
2. dns.eurecom.fr si collega dns.eurecom.fr
al root name server (se
1
6
necessario)
3. root name server si collega
all’authoritative name
server,
requesting host
dns.umass.edu,(se
surf.eurecom.fr
necessario)
4
3
authorititive name server
dns.umass.edu
gaia.cs.umass.edu
Introduction
1-94
DNS
root name server
Root name server:
conoscere
l’authoratiative name
server
 Potrebbe conoscere
un intermediate name
server: Il server da
contattare per
collegarsi con il
authoritative name
server
6
2
 Potrebbe non
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
Introduction
1-95
DNS: queries
root name server
recursive query:
 Meccanismo di
3
trasmissione delle
query tra i vari name
server
iterated query:
 server restituisce il
nome del name server
da contattare per
risolvere la query
 “I don’t know this
name, but ask this
server”
iterated query
2
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
Introduction
1-96
DNS: caching
 Un generico name server può effetttuare una
operazione di caching per memorizzare i risultati
delle query
 Elementi della cache diventano “vecchi”
 Meccanismi per update/notify sono in fase di
progetto

RFC 2136

http://www.ietf.org/html.charters/dnsind-charter.html
Introduction
1-97
DNS records
DNS: distributed db che memorizza resource records (RR)
RR format: (name,
 Type=A
 name is hostname
 value is IP address
value, type,ttl)
 Type=CNAME
 name è un alias di un
nome “canonico”
www.ibm.com è
servereast.backup2.ib
m.com
 Type=NS


name is domain (e.g.
foo.com)
value is IP address of
authoritative name server
for this domain

Value è il nome
canonico
 Type=MX
 value is hostname of
mailserver associated with
name
Introduction
1-98
$TTL
43200
@
IN
hostmaster.mesys.it. (
@
@
@
localhost
ns
ns1
mail
www
ftp
IN
IN
IN
IN
IN
IN
IN
IN
IN
SOA
ns.mesys.it.
2002053101 ; serial
86400 ; refresh
3600 ; retry
604800 ; expire
86400 ; default_ttl
)
MX
5
mail.mesys.it.
NS
ns.mesys.it.
NS
dns2.nic.it.
A
127.0.0.1
A
151.4.83.2
A
151.4.83.3
A
151.4.83.2
CNAME
turtle.mesys.it.
CNAME
dolphin.mesys.it.
Introduction
1-99
C:\Documents and Settings\bista>nslookup
Server predefinito: deimos.unich.it
Address: 192.167.13.102
> set querytype=ANY
> sci.unich.it
Server: deimos.unich.it
Address: 192.167.13.102
sci.unich.it
primary name server = deimos.unich.it
responsible mail addr = root.deimos.unich.it
serial = 2002061901
refresh = 86400 (1 day)
retry
= 1800 (30 mins)
expire = 2592000 (30 days)
default TTL = 432000 (5 days)
sci.unich.it
nameserver = deimos.unich.it
sci.unich.it
nameserver = dns2.unich.it
sci.unich.it
MX preference = 10, mail exchanger =
gotham.sci.unich.it
dns2.unich.it
internet address = 192.167.14.208
deimos.unich.it internet address = 192.167.13.102
gotham.sci.unich.it
internet address = 192.167.14.11
>
Introduction
1-100
DNS protocol, messages
DNS protocol : query / reply messages,
Identico message format
msg header
 identification: 16 bit # for
query, reply to query uses
same #
 flags:
 query or reply
 recursion desired
 recursion available
 reply is authoritative
Introduction
1-101
DNS protocol, messages
Name, type fields
for a query
RRs in reponse
to query
records for
authoritative servers
additional “helpful”
info that may be used
Introduction
1-102
DNS
 Protocollo di trasporto: UDP
 Porta: 53
 … bugia ..
Introduction
1-103
Esercizi e seminari
 Scoprire per quali messaggi DNS usa la
porta 53 e il TCP (invece che l’UDP)
 2004-Seminario su configurazioni del DNS
 2005-Seminario su DNSSEC (due persone)
dopo che abbiamo fatto crittografia
(novembre)
 www.dnssec.net
Introduction
1-104
Hint seminario configurazione dns
Acl
options {
directory "/var/named";
pid-file "named.pid";
allow-transfer { mesysslaves; };
allow-recursion { mesysnets; };
blackhole { bogusnets; };
};
Introduction
1-105
DNS Data flow
Zone administrator
Zone file
master
Dynamic
updates
slaves
resolver
stub resolver
Introduction
1-106
DNS Vulnerabilities
Cache impersonation
Corrupting data
Impersonating master
Zone
administrator
Zone file
master
Dynamic
updates
slaves
resolver
stub resolver
Unauthorized updates
Server
Protection
Cache pollution by
Data spoofing
Data
Protection
Introduction
1-107
Chapter 2 outline
JUMP
 2.1 Principles of app
layer protocols


clients and servers
app requirements
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Socket programming
with TCP
 2.7 Socket programming
with UDP
 2.8 Building a Web
server
 2.9 Content distribution



Network Web caching
Content distribution
networks
P2P file sharing
Introduction
1-108
Socket programming
Goal: learn how to build client/server application that
communicate using sockets
Socket API
 introduced in BSD4.1 UNIX,
1981
 explicitly created, used,
released by apps
 client/server paradigm
 two types of transport
service via socket API:
 unreliable datagram
 reliable, byte streamoriented
socket
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
Introduction
1-109
Socket-programming using TCP
Socket: a door between application process and endend-transport protocol (UCP or TCP)
TCP service: reliable transfer of bytes from one
process to another
controlled by
application
developer
controlled by
operating
system
process
process
socket
TCP with
buffers,
variables
host or
server
internet
socket
TCP with
buffers,
variables
controlled by
application
developer
controlled by
operating
system
host or
server
Introduction
1-110
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 client-local 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 client
 allows server to talk with
multiple clients
 source port numbers
used to distinguish
clients (more in Chap 3)
application viewpoint
TCP provides reliable, in-order
transfer of bytes (“pipe”)
between client and server
Introduction
1-111
Stream jargon
 A stream is a sequence of
characters that flow into
or out of a process.
 An input stream is
attached to some input
source for the process, eg,
keyboard or socket.
 An output stream is
attached to an output
source, eg, monitor or
socket.
Introduction
1-112
Socket programming with TCP
Client
Process
process
input
stream
output
stream
inFromServer
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)
outToServer
Example client-server app:
monitor
inFromUser
keyboard
input
stream
client
TCP
clientSocket
socket
to network
TCP
socket
from network
Introduction
1-113
Client/server socket interaction: TCP
Server (running on hostid)
Client
create socket,
port=x, for
incoming request:
welcomeSocket =
ServerSocket()
TCP
wait for incoming
connection request connection
connectionSocket =
welcomeSocket.accept()
read request from
connectionSocket
write reply to
connectionSocket
close
connectionSocket
setup
create socket,
connect to hostid, port=x
clientSocket =
Socket()
send request using
clientSocket
read reply from
clientSocket
close
clientSocket
Introduction
1-114
Example: Java client (TCP)
import java.io.*;
import java.net.*;
class TCPClient {
public static void main(String argv[]) throws Exception
{
String sentence;
String modifiedSentence;
Create
input stream
Create
client socket,
connect to server
Create
output stream
attached to socket
BufferedReader inFromUser =
new BufferedReader(new InputStreamReader(System.in));
Socket clientSocket = new Socket("hostname", 6789);
DataOutputStream outToServer =
new DataOutputStream(clientSocket.getOutputStream());
Introduction
1-115
Example: Java client (TCP), cont.
Create
input stream
attached to socket
BufferedReader inFromServer =
new BufferedReader(new
InputStreamReader(clientSocket.getInputStream()));
sentence = inFromUser.readLine();
Send line
to server
outToServer.writeBytes(sentence + '\n');
Read line
from server
modifiedSentence = inFromServer.readLine();
System.out.println("FROM SERVER: " + modifiedSentence);
clientSocket.close();
}
}
Introduction
1-116
Example: Java server (TCP)
import java.io.*;
import java.net.*;
class TCPServer {
Create
welcoming socket
at port 6789
Wait, on welcoming
socket for contact
by client
Create input
stream, attached
to socket
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()));
Introduction
1-117
Example: Java server (TCP), cont
Create output
stream, attached
to socket
DataOutputStream outToClient =
new DataOutputStream(connectionSocket.getOutputStream());
Read in line
from socket
clientSentence = inFromClient.readLine();
capitalizedSentence = clientSentence.toUpperCase() + '\n';
Write out line
to socket
outToClient.writeBytes(capitalizedSentence);
}
}
}
End of while loop,
loop back and wait for
another client connection
Introduction
1-118
Chapter 2 outline
 2.1 Principles of app
layer protocols


clients and servers
app requirements
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Socket programming
with TCP
 2.7 Socket programming
with UDP
 2.8 Building a Web
server
 2.9 Content distribution



Network Web caching
Content distribution
networks
P2P file sharing
Introduction
1-119
Socket programming with UDP
UDP: no “connection” between
client and server
 no handshaking
 sender explicitly attaches
IP address and port of
destination to each packet
 server must extract IP
address, port of sender
from received packet
application viewpoint
UDP provides unreliable transfer
of groups of bytes (“datagrams”)
between client and server
UDP: transmitted data may be
received out of order, or
lost
Introduction
1-120
Client/server socket interaction: UDP
Server (running on hostid)
create socket,
port=x, for
incoming request:
serverSocket =
DatagramSocket()
read request from
serverSocket
write reply to
serverSocket
specifying client
host address,
port number
Client
create socket,
clientSocket =
DatagramSocket()
Create, address (hostid, port=x,
send datagram request
using clientSocket
read reply from
clientSocket
close
clientSocket
Introduction
1-121
Example: Java client (UDP)
input
stream
Client
process
monitor
inFromUser
keyboard
Process
Input: receives
packet (TCP
received “byte
stream”)
UDP
packet
receivePacket
packet (TCP sent
“byte stream”)
sendPacket
Output: sends
UDP
packet
client
UDP
clientSocket
socket
to network
UDP
socket
from network
Introduction
1-122
Example: Java client (UDP)
import java.io.*;
import java.net.*;
Create
input stream
Create
client socket
Translate
hostname to IP
address using DNS
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();
Introduction
1-123
Example: Java client (UDP), cont.
Create datagram
with data-to-send,
length, IP addr, port
DatagramPacket sendPacket =
new DatagramPacket(sendData, sendData.length, IPAddress, 9876);
Send datagram
to server
clientSocket.send(sendPacket);
Read datagram
from server
clientSocket.receive(receivePacket);
DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
String modifiedSentence =
new String(receivePacket.getData());
System.out.println("FROM SERVER:" + modifiedSentence);
clientSocket.close();
}
}
Introduction
1-124
Example: Java server (UDP)
import java.io.*;
import java.net.*;
Create
datagram socket
at port 9876
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)
{
Create space for
received datagram
Receive
datagram
DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
serverSocket.receive(receivePacket);
Introduction
1-125
Example: Java server (UDP), cont
String sentence = new String(receivePacket.getData());
Get IP addr
port #, of
sender
InetAddress IPAddress = receivePacket.getAddress();
int port = receivePacket.getPort();
String capitalizedSentence = sentence.toUpperCase();
sendData = capitalizedSentence.getBytes();
Create datagram
to send to client
DatagramPacket sendPacket =
new DatagramPacket(sendData, sendData.length, IPAddress,
port);
Write out
datagram
to socket
serverSocket.send(sendPacket);
}
}
}
End of while loop,
loop back and wait for
another datagram
Introduction
1-126
Building a simple Web server
 handles one HTTP




request
accepts the request
parses header
obtains requested file
from server’s file
system
creates HTTP response
message:

 after creating server,
you can request file
using a browser (eg IE
explorer)
 see text for details
header lines + file
 sends response to client
Introduction
1-127
Socket programming: references
C-language tutorial (audio/slides):
 “Unix Network Programming” (J. Kurose),
http://manic.cs.umass.edu/~amldemo/courseware/intro.
Java-tutorials:
 “All About Sockets” (Sun tutorial),
http://www.javaworld.com/javaworld/jw-12-1996/jw-12sockets.html
 “Socket Programming in Java: a tutorial,”
http://www.javaworld.com/javaworld/jw-12-1996/jw-12sockets.html
Introduction
1-128
seminari
 2005-Implementare 2.6 2.7 2.8
 2005-Invece che un client/server web
implementare un client server ftp
 2005-Invece che un client/server web
implementare un client server smtp
 2005-Invece che un client/server web
implementare un client server pop
Introduction
1-129
domande
 E’ possibile implementare un servizio di
comunicazione affidabile usando udp?

SI (implemntando I controlli a lato applicazione)
 Quale sarebbe il vantaggio?
 No
controllo congestione!! 
Introduction
1-130
Chapter 2 outline
 2.1 Principles of app
layer protocols


clients and servers
app requirements
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Socket programming
with TCP
 2.7 Socket programming
with UDP
 2.8 Building a Web
server
 2.9 Content distribution



Network Web caching
Content distribution
networks
P2P file sharing
Introduction
1-131
Web caches (proxy server)
Goal: satisfy client request without involving origin server
 user sets browser: Web
accesses via cache
 browser sends all HTTP
requests to cache


object in cache: cache
returns object
else cache requests
object from origin
server, then returns
object to client
origin
server
client
client
Proxy
server
origin
server
Introduction
1-132
More about Web caching
 Cache acts as both client
and server
 Cache can do up-to-date
check using If-modifiedsince HTTP header


Issue: should cache take
risk and deliver cached
object without checking?
Heuristics are used.
 Typically cache is installed
Why Web caching?
 Reduce response time for
client request.
 Reduce traffic on an
institution’s access link.
 Internet dense with caches
enables “poor” content
providers to effectively
deliver content
by ISP (university,
company, residential ISP)
Introduction
1-133
Caching example (1)
Assumptions
 average object size = 100,000
bits
 avg. request rate from
institution’s browser to origin
serves = 15/sec
 delay from institutional router
to any origin server and back
to router = 2 sec
Consequences
origin
servers
public
Internet
1.5 Mbps
access link
institutional
network
10 Mbps LAN
 utilization on LAN = 15%
 utilization on access link = 100%
 total delay
= Internet delay +
access delay + LAN delay
= 2 sec + minutes + milliseconds
institutional
cache
Introduction
1-134
Caching example (2)
Possible solution
 increase bandwidth of access
link to, say, 10 Mbps
Consequences
origin
servers
public
Internet
 utilization on LAN = 15%
 utilization on access link = 15%
= Internet delay +
access delay + LAN delay
= 2 sec + msecs + msecs
 often a costly upgrade
10 Mbps
access link
 Total delay
institutional
network
10 Mbps LAN
institutional
cache
Introduction
1-135
Caching example (3)
origin
servers
Install cache
 suppose hit rate is .4
Consequence
public
Internet
 40% requests will be satisfied



=
almost immediately
60% requests satisfied by
origin server
utilization of access link
reduced to 60%, resulting in
negligible delays (say 10 msec)
total delay = Internet delay +
access delay + LAN delay
.6*2 sec + .6*.01 secs +
milliseconds < 1.3 secs
1.5 Mbps
access link
institutional
network
10 Mbps LAN
institutional
cache
Introduction
1-136
Content distribution networks (CDNs)
origin server
in North America
Content replication
 I fornitori di servizi CDN
attivano centinaia di server
CDN in Internet
 ISP di secondo o terzo
livello
 Il contenuto informativo
viene duplicato sui server
CDN ogniqualvolta il cliente
del CDN aggiorna
l’informazione
CDN distribution node
CDN server
in S. America CDN server
in Europe
CDN server
in Asia
Introduction
1-137
CDN:esempio
HTTP request for
www.foo.com/sports/sports.html
Origin server
1
2
3
DNS query for www.cdn.com
CDNs authoritative
DNS server
HTTP request for
www.cdn.com/www.foo.com/sports/ruth.gif
Nearby
CDN server
server
 www.foo.com
 Rende disponibile
direttamente file HTML
 Il riferimento:
http://www.foo.com/sports.ruth.gif
viene modificato
http://www.cdn.com/www.foo.com/sports/ruth.gif
Provider CDN
 cdn.com
 Rende disponibili i file
gif
 Il server DNS di
autorità ha il compito
di gestire i Introduction
riferimenti
1-138
CDN: cont.
 CDN ha una tabella con
le informazioni relative
alle distanze tra i
server CDN e gli ISP
 Le richieste
effettuate al DNS di
autorità utilizzano
questa informazione.
Non solo pagine web
 streaming audio/video
 streaming real-time
audio/video

Nodi CDN sono una rete
virtuale del livello delle
applicazioni
Introduction
1-139
P2P file sharing
 Alice runs P2P client
application on her
notebook computer
 Intermittently
connects to Internet;
gets new IP address
for each connection
 Asks for “Hey Jude”
 Application displays
other peers that have
copy of Hey Jude.
 Alice chooses one of
the peers, Bob.
 File is copied from
Bob’s PC to Alice’s
notebook: HTTP
 While Alice downloads,
other users uploading
from Alice.
 Alice’s peer is both a
Web client and a
transient Web server.
All peers are servers =
highly scalable!
Introduction
1-140
P2P: directory centralizzata
NAPSTER
1) Quando un peer si
connette alla rete si
collega ad un server
centralizato:


Indirizzo IP
Informazione condivisa
2) Alice effettua una
query per trovare “Hey
Jude”
3) Alice scarica il file da
Bob
Bob
centralized
directory server
1
peers
1
3
1
2
1
Alice
Introduction
1-141
Discussione
 Singolo punto di
fallimento
 Performance limitata
 Copyright ….
file transfer is
decentralized, but
locating content is
highly decentralized
Introduction
1-142
P2P: decentralized directory
 Peer
 a group leader
 È associato ad un group
leader.
 Un group leader
memorizza
l’informazioni in
condivisione dei “figli”
 Peer queries group
leader

group leader è in grado
di interrogare altri
group leader.
ordinary peer
group-leader peer
neighoring relationships
in overlay network
Introduction
1-143
decentralized directory:
caratteristiche innovative
overlay network
 peer sono i nodes
 connessioni tra peer ed
i rispettivi group leader
 Connessioni tra group
leader
 Rete virtuale
bootstrap node
 un peer che si connette
deve essere associato
ad un group leader o
dveve essere designato
group leader
vantaggi
 Non è presente una
directory centralizzata

Il servizio di
localizzazione è
distribuito tra i peer
svantaggi
 bootstrap node!!!
 group leader possono
essere troppo carichi
Introduction
1-144
P2P: Query flooding
 Query sono inviate ai
 Gnutella
 no gerarchia
 bootstrap node sono
utilizzati per avere
informazioni sui pari
 join
vicini
 Query forwarding
 Se l’oggetto viene trovate
il riferimento è inviato
direttamente al peer di
partenza
join
Introduction
1-145
P2P: query flooding
Pros
 no group leader
 decxentralizzato
 no directory info
Cons
 Traffico di query
 query radius:

Potrebbe non essere
sufficiente per
individuare l’oggetto
 bootstrap node
 Gestione della overlay
network
Introduction
1-146
seminari
 2005-ICP (caching cooperativo)
 2004-Peer to peer
Introduction
1-147
Chapter 2: Summary
Our study of network apps now complete!
 application service
requirements:

reliability, bandwidth,
delay
 client-server paradigm
 Internet transport
service model


connection-oriented,
reliable: TCP
unreliable, datagrams:
UDP
 specific protocols:
 HTTP
 FTP
 SMTP, POP, IMAP
 DNS
 socket programming
 content distribution
 caches, CDNs
 P2P
Introduction
1-148
Chapter 2: Summary
Most importantly: learned about protocols
 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 being
communicated
 control vs. data msgs
in-band, out-of-band
centralized vs. decentralized
stateless vs. stateful
reliable vs. unreliable msg
transfer
“complexity at network
edge”
security: authentication






Introduction
1-149