Ritardi nelle reti a commutazione di
pacchetto
I pacchetti avvertono un
ritardo sul cammino sorgente-destinazione
quattro sorgenti di ritardo
ad ogni hop (router visitato)
Elaborazione del router:
o Controllo dei bit di errore o Determinazione del canale
di uscita
accodamento
o Tempo d’attesa al canale di
uscita per la trasmissione
o Dipende dal livello di
congestione del router
A
B
propagazione trasmissione
Ritardi nelle reti a commutazione di
pacchetto
Ritardo di Trasmissione:
R=larghezza di banda del
canale (bps)
L=lunghezza del pacchetto
(bits)
Tempo per spedire i bit
lungo il canale = L/R
Ritardo di Propagazione:
d = lunghezza del canale fisico
(m)
s = velocità di propagazione
nel mezzo (~2x108 m/sec)
Ritardo di propagazione = d/s
A
B
propagazione trasmissione
Nota:
s ed R sono quantità
MOLTO diverse!
Ritardo di accodamento
R=larghezza di banda del
canale (bps)
L=lunghezza del pacchetto
(bits)
a=velocità media di arrivo
di pacchetti
intensità di traffico = L a / R
L a / R ~ 0: ritardo medio di accodamento piccolo
L a / R -> 1: ritardo medio di accodamento diventa
grande
Ritardi e cammini “veri” in Internet
1 cs-gw (128.119.240.254) 1 ms 1 ms 2 ms 2 border1-rt-fa5-1-0.gw.umass.edu (128.119.3.145) 1 ms 1 ms 2 ms 3 cht-vbns.gw.umass.edu (128.119.3.130) 6 ms 5 ms 5 ms 4 jn1-at1-0-0-19.wor.vbns.net (204.147.132.129) 16 ms 11 ms 13 ms 5 jn1-so7-0-0-0.wae.vbns.net (204.147.136.136) 21 ms 18 ms 18 ms 6 abilene-vbns.abilene.ucaid.edu (198.32.11.9) 22 ms 18 ms 22 ms 7 nycm-wash.abilene.ucaid.edu (198.32.8.46) 22 ms 22 ms 22 ms 8 62.40.103.253 (62.40.103.253) 104 ms 109 ms 106 ms 9 de2-1.de1.de.geant.net (62.40.96.129) 109 ms 102 ms 104 ms 10 de.fr1.fr.geant.net (62.40.96.50) 113 ms 121 ms 114 ms 11 renater-gw.fr1.fr.geant.net (62.40.103.54) 112 ms 114 ms 112 ms 12 nio-n2.cssi.renater.fr (193.51.206.13) 111 ms 114 ms 116 ms 13 nice.cssi.renater.fr (195.220.98.102) 123 ms 125 ms 124 ms 14 r3t2-nice.cssi.renater.fr (195.220.98.110) 126 ms 126 ms 124 ms 15 eurecom-valbonne.r3t2.ft.net (193.48.50.54) 135 ms 128 ms 133 ms 16 194.214.211.25 (194.214.211.25) 126 ms 128 ms 126 ms 17 * * *traceroute:
router, ritardi sul cammino
sorgente-destinazione path: vedi anche pingplotter, ed altri
Struttura di Internet: rete di reti
a grandi linee gerarchica
national/international
backbone providers (NBP)
o e.g. BBN/GTE, Sprint,
AT&T, IBM, UUNet
o si inter-connettono
direttamente, o tramite
Network Access Point (NAP)
ISP regionali
o connettono ai NBP
ISP locali
, privati,
istituzioni
o connettono agli ISP regionali
NBP A
NBP B
NAP
NAP
ISP regionali ISP regionali ISP locali ISP localiNational Backbone Provider
e.g. Sprint US backbone network
Livelli di un protocollo
Le reti di telecomunicazione
sono complesse!
molte componenti:
ohost
orouter
ocanali di comunicazione
(diversi mezzi
trasmissivi)
oapplicazioni
oprotocolli
ohardware, software
Domanda:
Si può organizzare la
struttura di una rete?
O, almeno, la discussione?
Organizzazione di un viaggio aereo
Una serie di passi
biglietto (acquisto) bagaglio (accettazione) uscita (imbarco) pista (decollo) rotta aerea biglietto (reclamo) bagaglio (ritiro) uscita (sbarco) pista (atterraggio) rotta aerea rotta aerea
Organizzazione di un viaggio
: vista diversa
Livelli: ogni livello implementa un servizio
o attraverso azioni interne al proprio livello
e confidando su servizi forniti dal livello sottostante biglietto (acquisto) bagaglio (accettazione) uscita (imbarco) pista (decollo) rotta aerea biglietto (reclamo) bagaglio (ritiro) uscita (sbarco) pista (atterraggio) rotta aerea rotta aerea
Viaggi aerei “a livelli”: i servizi
persone+bagaglio da bancone a bancone da ritiro-bagagli a ritiro-bagagli
persone: uscita di imbarco a uscita di sbarco trasferimento aereo da pista a pista
Implementazione
distribuita
delle funzionalità di
un livello
Aeropo
rto di partenza
Siti intermedi di traffico aereo
rotta aerea rotta aerea
Aeropo
rto d’arrivo
biglietto (acquisto) bagaglio (accett.) uscita (imbarco) pista (decollo) rotta aerea biglietto (reclamo) bagaglio (ritiro) uscita (sbarco) pista (atterraggio) rotta aereaPerché i livelli?
Sistemi complessi:
Una strutturazione esplicita consente
l’identificazione e le relazioni tra parti di un
sistema complesso
o
modello di riferimento
a livelli per lo studio
Modularizzazione facilita il mantenimento e
l’aggiornamento di un sistema
o
La modifica dell’implementazione del servizio di
un livello è trasparente al resto del sistema
o
e.g., modifica nella procedura d’imbarco non
condiziona il resto del sistema “viaggio aereo”
Stack di protocolli Internet
application: supporto per applicazioni di
rete
o ftp, smtp, http
transport: trasferimento dati da host a
host
o tcp, udp
network: instradamento di datagram da
mittente a destinazione
o ip, protocolli di routing
link: trasferimento dati tra due elementi
vicini (connessi) delle rete
o ppp, ethernet
physical: trasferimento di bits lungo i canali
di comunicazione fisici
application
transport
network
link
physical
Funzionalità dei livelli
Ogni livello può eseguire uno, o più, dei
seguenti tipi di compito
o
controllo degli errori
ocontrollo di flusso
o
segmentazione e ricostruzione
omultiplexing/demultiplexing
o“setup” di connessione
Struttura a livelli: comunicazione logica
application transport network link physical application transport network link physical application transport network link physical application transport network link physical network link physicalOgni livello:
distribuito
“entità”
implementano
funzioni di un
livello ad ogni
nodo
entità eseguono
azioni, scambiano
messaggi con i
propri “pari”
Struttura a livelli: comunicazione logica
application transport network link physical application transport network link physical application transport network link physical application transport network link physical network link physical dati datiE.g.: transport
Riceve dati dall’
application Aggiunge indirizzamento, informazioni sul controllo di affidabilità per formare un segmento spedisce il segmento al proprio “pari” Attende che il “pari” confermi la ricezione (con un “ack”) dati transport transport ack
Struttura a livelli: comunicazione fisica
application transport network link physical application transport network link physical application transport network link physical application transport network link physical network link physical dati datiProtocolli a livelli e dati
Ogni livello prende dati dal livello superiore
Aggiunge informazioni in un header (intestazione)
per creare una nuova unità di dati
Passa la nuova unità di dati al livello sottostante
application
transport
network
link
physical
application
transport
network
link
physical
sorgente
destinazione
M M M M Ht Ht Hn Ht Hn Hl M M M M Ht Ht Hn Ht Hn Hl messaggio segmento datagram frameStoria di Internet
1961: Kleinrock – teoria
delle code dimostra l’efficacia della
commutazione di pacchetto
1964: Baran –
commutazione di pacchetto nelle reti militari
1967: ARPAnet concepita
dal Advanced Research Projects Agency
1969: primo nodo ARPAnet
operativo 1972: o Dimostrazione pubblica di ARPAnet o NCP (Network Control Protocol) primo protocollo host-host o Primo programma di e-mail o ARPAnet ha 15 nodi
1961-1972: primi principi della commutazione di
pacchetti
Storia di Internet
1970: rete satellitare
ALOHAnet nelle Hawaii
1973: Metcalfe nella sua tesi
di PhD propone Ethernet
1974: architettura proposta
da Cerf e Kahn per
l’interconnessione di reti
fine anni 70: architetture
proprietarie: DECnet, SNA, XNA
fine anni 70: commutazione di
pacchetti di lunghezza fissa (precursore di ATM)
1979: ARPAnet ha 200 nodi
Principi di internetworking di Cerf e Kahn:
o minimalismo, autonomia –
nessuna modifica interna richiesta per
interconnettere reti
o modello di servizio best
effort (al meglio)
o router che non mantengono
lo stato delle connessioni
o controllo decentralizzato
Definiscono l’architettura dell’attuale Internet
1972-1980: Internetworking, nuove reti e reti
proprietarie
Storia di Internet
1983: diffusione di TCP/IP 1982: definizione del
protocollo smtp per l’e-mail
1983: definizione del DNS
per la traduzione da nome ad indirizzo IP
1985: definizione del
protocollo ftp
1988: controllo di
congestione in TCP
Nuove reti nazionali:
Csnet, BITnet,
NSFnet, Minitel
100,000 host connessi
alla confederazione di
reti
Storia di Internet
Primi anni 90: disarmo di
ARPAnet
1991: l’NSF allenta le
restrizioni sull’uso
commerciale di NSFnet (in disarmo nel 1995)
Primi anni 90: WWW
o ipertesti [Bush 1945,
Nelson 1960’s]
o HTML, http: Berners-Lee o 1994: Mosaic, più tardi
Netscape o fine anni 90:
Fine anni 90:
50 milioni di
computers on
Internet (stime)
più di 100 milioni di
utenti (stime)
canali di
comunicazione dei
backbone operanti a
1 Gbps
Anni 90: commercializzazione, il WWW
Introduzione: sommario
Molto materiale panoramica su Internet cos’è un protocollo?
network edge, core, access
network
o commutazione di pacchetto e
di circuito
prestazioni: perdite, ritardi
strutturazione a livelli e modelli
di servizio
backbone, NAP, ISP storia
Ora avete:
Una panoramica sulle
problematica
Parte 2: livello Application
Obiettivi: Aspetti concettuali ed implementativi di protocolli di applicazioni di rete o Paradigma client-servero Modello dei servizi
Imparare concetti sui
protocolli esaminando protocolli a livello
applicazione molto diffusi
Altri obiettivi
Protocolli specifici:
o http o ftp o smtp o pop o dns Programmazione di
applicazioni di rete
o socket APIApplicazioni e protocolli a livello
application
Applicazione: processi distribuiti comunicanti
o vengono eseguiti sugli host di
rete come processi utente
o scambio di messaggi per
implementare l’applicazione
o e.g., email, ftp, Web
Protocolli a livello Application
o una parte di un’applicazione o definiscono i messaggi scambiati dall’applicazione e le azioni intraprese o Usano i servizi di comunicazione forniti da application transport network data link physical application transport network data link physical application transport network data link physical
Applicazioni di rete: terminologia
Processo:
programma in
esecuzione in un host.
sullo stesso host, due
processi comunicano
usando l’
interprocess
communication
(definito
dal sistema operativo).
processi in esecuzione
su host diversi
comunicano con un
protocollo a livello
user agent: processo
software, che si
interfaccia con l’utente “verso l’alto” e con la rete “verso il basso”.
o implementa il protocollo
a livello application
o Web: browser
o E-mail: mail reader
o streaming audio/video:
Paradigma Client-server
Una tipica applicazione di rete si compone di due parti: client e
server application transport network data link physical application transport network data link physical
Client:
Avvia il contatto con il server
(“parla per primo”)
Solitamente, richiede un
servizio al server
Web: il client è implementato
nel browser; e-mail: in mail reader
request
reply
Server:
Fornisce il servizio richiesto al client e.g., il Web server spedisce la pagina
Protocolli a livello application
API: application
programming interface
Definisce l’interfaccia
tra l’applicazione ed il
livello transport
socket: Internet API
o Due processi comunicano
spedendo dati nel socket, e leggendo dati dal socket
domanda:
come fa un
processo ad
identificare l’altro
processo con il quale
vuole comunicare?
o Indirizzo IP dell’ host sul
quale è in esecuzione l’altro processo
o “numero di porta” –
permette all’ host che riceve di determinare a quale dei processi che sta eseguendo (locali) debba essere recapitato
Applicazioni, socket e livello trasporto
Internet TCP con variabili, buffer processo socket sotto il controllo del programmatore sotto il controllo del sistema operativo host o server TCP con variabili, buffer socket sotto il controllo del programmatore sotto il controllo del sistema operativo host o server processoDi quale servizio di trasporto necessita
un’applicazione?
Perdita di dati
Alcune applicazioni (e.g., audio)
possono tollerare perdite
Altre applicazioni (e.g.,
trasferimento file, telnet) richiedono un trasferimento dati affidabile al 100%
Time-sensitive
Alcune applicazioni
(e.g., telefonia su
Internet, giochi
interattivi) richiedono
Larghezza di banda
Alcune applicazioni (e.g.,
multimediali) richiedono
un ammontare minimo di
larghezza di banda per
essere “efficaci”
Altre applicazioni
(“applicazioni elastiche”)
fanno uso di qualunque
larghezza di banda
Requisiti del servizio di Trasporto di
applicazioni comuni
Applicazione trasferimento file e-mail documenti Web real-time audio/video stored audio/video giochi interattivi applicazioni finanziarie Perdite dati senza senza tollerante tollerante tollerante tollerante senza Larghezza di banda elastica elastica elastica audio: 5Kb-1Mb video:10Kb-5Mb come sopra alcuni Kbps elastica Time Sensitive no no nosi, alcuni 100 msec si, pochi secs
si, alcuni 100 msec si e no
Servizi di trasporto in Internet
Servizio TCP:
connection-oriented: fase
iniziale di “setup” necessaria tra client e server
trasporto affidabile tra
processo mittente e destinatario
controllo di flusso: il mittente
non sovraccaricherà il ricevitore
controllo di congestione:
regolazione della velocità del mittente quando la rete è sovraccarica
Servizio UDP:
trasferimento dati non
affidabile tra processo mittente e processo destinatario
non fornisce: setup della
connessione, affidabilità, controllo di flusso,
controllo di congestione, tempi o larghezza di
banda garantiti
Domanda: perché mai esiste UDP?
Applicazioni Internet: protocolli a livello
applicazione e transport
Applicazione e-mail accesso a terminale remoto Web trasferimento file streaming multimedia file server remoto telefonia su Internet Protocollo a livello applicazione smtp [RFC 821] telnet [RFC 854] http [RFC 2068] ftp [RFC 959] proprietario (e.g. RealNetworks) NSF proprietario (e.g., Vocaltec) Protocollo a livello transport sottostante TCP TCP TCP TCP TCP or UDP TCP or UDP solitamente UDP
Il Web: il protocollo http
http: hypertext transfer
protocol
Protocollo a livello
applicazione per il Web
Modello client/server
o client: il browser che
richiede, riceve e mostra oggetti Web
o server: Web server che
spedisce oggetti in risposta ad una richiesta http1.0: RFC 1945 http1.1: RFC 2068-2616 PC che esegue Explorer Server che esegue NCSA Web server
Mac che esegue Navigator http req uest http request http respons e http respons e
Il WEB: terminologia
pagina WEB (documento):
collezione di oggetti
oggetto:
un file (HTML, JPEG, …)
file HTML base:
con direttive e riferimenti ad
altri oggetti
URL (Uniform Resource Locator):
meccanismo di
identificazione risorse. Si compone del nome del
host sul quale risiede l’oggetto e il path-name
dell’oggetto
o
www.di.unito.it/various/presentation_en.html
Il protocollo http
http: usa servizio TCP:
il client avvia una
connessione TCP (crea un socket) con il server, porta 80
il server accetta la
connessione TCP dal client
vengono scambiati messaggi
http (messaggi del protocollo di livello applicazione) tra il browser (client http) ed il Web server (server http)
la connessione TCP viene chiusa
http è “stateless”
il server nono mantiene alcuna informazione sulle richieste passate dei clientI protocolli che mantengono lo stato sono complessi!
Tutta la storia passata della
connessione (stato) deve essere mantenuta,
memorizzata
se server o client subiscono un
crash, la loro conoscenza dello stato può essere inconsistente
http: esempio
Supponiamo l’utente digiti l’URL
www.someSchool.edu/someDepartment/home.index
1a. il client http inizia una
connessione TCP al server http (che è un processo)
all’indirizzo
www.someSchool.edu. La porta 80 è il default per i server
http.
2. il client http spedisce il messaggio http request message (contenente l’URL) nel socket della connessione TCP
1b. il server http sull’ host
www.someSchool.edu in attesa di connessioni TCP alla porta 80. “accetta” la connessione, notificandola al client
3. il server http riceve il
messaggio di richiesta, forma un messaggio http response message contenente l’oggetto richiesto
(contiene testo e 10 riferimenti ad
http: esempio (continuazione)
5. il client http riceve il messaggio di risposta
contenente il file html e lo mostra. Parsifica (analizza) il file html, trova i riferimenti a 10 oggetti jpeg.
6. passi 1-5 si ripetono per ognuno dei 10 oggetti jpeg.
4. il server http chiude la connessione TCP.
Connessioni persistenti e non persistenti
Non persistenti
http/1.0: il server parsifica
le richieste, risponde, chiude la connessione TCP
2 RTT (round trip time) per
ottenere l’oggetto
o connessione TCP
o richiesta/trasferimento
oggetto
Ogni trasferimento risente
della bassa velocità iniziale di trasferimento di TCP
molti browser aprono
connessioni multiple in parallelo
Persistenti
default per http/1.1 usando la stessa connessione TCP: il server, parsifica richieste,risponde, parsifica nuove richieste……
il client spedisce le
richieste per tutti gli oggetti a cui si fa
riferimento non appena riceve il file HTML base.
Meno RTT, meno slow
start.
Connessioni persistenti e non persistenti
open close open close open closeclient
server
HTTP 1.0
open closeclient
server
HTTP 1.1
open closeclient
server
HTTP 1.1
Formato dei messaggi http: request
due tipi di messaggi http:
request, response
http request message:
o ASCII (formato human-readable)
GET /somedir/page.html HTTP/1.0 Host: www.someschool.edu
User-agent: Mozilla/4.0
Accept: text/html, image/gif,image/jpeg Accept-language:fr
(extra carriage return, line feed)
request line
(comandi GET, POST, HEAD,…)
linee header Carriage return,
http request message: i metodi
GET: richiede il trasferimento di una
risorsa (oggetto)
OPTIONS: richiede le opzioni di
comunicazione associate ad un oggetto o al
server
HEAD: simile al GET ma l’oggetto non viene
trasferito (controllo stato dei documenti)
POST: per spedire dati al server
http request message: l’header
Accept:
specifica i tipi di file accettati come
risposta.
Accept-Encoding:
specifica il metodo di
compressione accettato.
Accept-Language:
specifica i linguaggi accettati
(nel caso in cui un documento sia disponibile in più
lingue).
Authorization:
e Proxy Authorization:
sono utilizzati per inviare le credenziali dell'utente
e servono per entrare in siti privati dove viene
chiesto user-name e password.
http request message: l’header
Host:
specifica l'indirizzo del server a cui
è indirizzata la richiesta.
If-Modified-Since:
restituisce il
documento solo se è stato modificato
recentemente.
User-Agent:
specifica nome e versione
del programma client.
Formato dei messaggi http: response
HTTP/1.0 200 OK
Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …... Content-Encoding: gzip
Content-Length: 6821 Content-Type: text/html
data data data data data ...
status line (codice di stato del protocollo frase di stato) linee header dati, e.g., file html richiesto
http response message: formato generale
version version version
version status codestatus codestatus codestatus code phrasephrasephrasephrase
status
status
status
status
line
line
line
line
Codici di stato per http response
200 OK
o richiesta con successo, l’oggetto richiesto segue in questo
messaggio
301 Moved Permanently
o L’oggetto richiesto è stato spostato, la nuova locazione è
specificata dopo in questo messaggio (Location:)
400 Bad Request
o request message non compreso dal server
404 Not Found
Nella prima linea del response message server->client.
Alcuni codici d’esempio:
Provate http (lato client)
1. Collegatevi con telnet ad un Web server:
Apre una connessione TCP sulla porta 80 (porta di default per un http server) su
www.eurecom.fr. Qualunque cosa si digiti viene spedita sulla porta 80 a www.eurecom.fr
telnet www.eurecom.fr 80
2. Digitate un http request GET:
GET /~ross/index.html HTTP/1.0 Digitando questo (digitate due volte
carriage return), spedite un minimale (ma completo)
GET request al server http
Interazione utente-server: autenticazione
Autenticazione: controllo
dell’accesso ai contenuti sul server
credenziali per autorizzazione:
tipicamente nome, password
stateless: il client deve
presentare un’autorizzazione ad ogni richiesta
o authorization: header line in
ogni request
o senza authorization: header,
il server rifiuta l’accesso, e spedisce
WWW authenticate:
header line nel response
client
server
solito http request msg 401: authorization req. WWW authenticate: solito http request msg + Authorization: <cred> solito http response msg solito http request msg + Authorization: <cred>Cookies: mantenere lo “stato”
# generato dal server,
# ricordato dal server, usato in futuro per:
o autenticazione o ricordare le preferenze dell’utente, scelte precedenti il server manda un
“cookie” al client nel response message
Set-cookie: 1678453
il client presenta il cookie
in richieste future
client
server
solito http request msg solito http response + Set-cookie: # solito http request msg cookie: # solito http response msg solito http request msg cookie: # solito http response azioni specifiche per il cookie azioni specifiche per il cookieConditional GET: caching lato client
Obiettivo: non spedire un
oggetto se il client ha una versione in cache aggiornata
client: specifica la data
della copia nella cache nel http request
If-modified-since: <date>
server: l’http response non
contiene l’oggetto se la
copia in cache è aggiornata:
HTTP/1.0 304 Not Modified
client
server
http request msg If-modified-since: <date> http response HTTP/1.0 304 Not Modified oggetto non modificato http request msg If-modified-since: <date> http response oggetto modificatoWeb Cache (proxy server)
utente configura il
browser: accesso Web via web cache
Il client manda tutti gli
http request al web cache
o oggetto nel web cache: il
web cache spedisce l’oggetto
o altrimenti il web cache
richiede l’oggetto dal server d’origine, quindi lo spedisce al client
Obiettivo:
soddisfare le richieste del client senza coinvolgere il server originaleclient Proxy server client http req uest http request http respons e http respons e http req uest http respons e server d’origine server
Perché il Web Caching?
Se:
il web cache è
“vicino” al client (e.g.,
nella stessa rete)
tempi di risposta
inferiori: il web cache
è “più vicino” al client
Diminuzione del
traffico verso server
distanti
o i canali esterni alla rete
del ISP
locale/istituzionale sono spesso colli di bottiglia
server d’origine Internet pubblica rete istituzionale 10 Mbps LAN canale d’accesso a 1.5 Mbps cache istituzionale
Posta Elettronica
Tre componenti principali:
user agent mail server
simple mail transfer
protocol: smtp
User Agent
alias “mail reader”
comporre, editare, leggere
messaggi di posta
e.g., Eudora, Outlook, elm,
Netscape Messenger Messaggi in uscita e in arrivo memorizzati su un user mailbox coda di messaggi in uscita mail server user agent user agent user agent mail server user agent user mail server user agent
SMTP
SMTP
SMTP
Posta Elettronica: mail servers
Mail Server
mailbox contiene messaggi in
arrivo (ancora da leggere) per l’utente
coda di messaggi in uscita
(da spedire)
protocollo smtp tra mail
server per spedire messaggi di posta elettronica
o lato client: sul mail
server del mittente
o lato server: sul mail
server del destinatario
o un mail server ospita
mail server user agent user agent user agent mail server user agent mail server user agent
SMTP
SMTP
SMTP
Posta Elettronica: smtp
[RFC 821]
usa TCP per trasferire in maniera affidabile messaggi di
posta elettronica dal client al server, porta 25
trasferimento diretto: dal sending server al receiving
server
tre fasi del trasferimento
o handshaking (greeting-saluti) o trasferimento del messaggio o chiusura
Interazione comandi/risposte
o comandi: testo ASCII
o risposte: codici di stato e frasi (come HTTP e FTP)
Scenario tipico
1.
Alice usa il suo user agent per l’email, gli fornisce
l’indirizzo di Bob (bob@hamburger.edu), compone
il messaggio, invia il comando di spedizione
2.
lo user agent spedisce il messaggio al mail server
di Alice il quale lo inserice in una coda di messaggi
in uscita
3.
Il lato client SMTP, in esecuzione sul mail server
di Alice, esamina il messaggio nella coda, apre una
connessione TCP (porta 25) verso un SMTP
server in esecuzione sul mail server di Bob
4.
Dopo una fase iniziale di handshaking, il client
Scenario tipico
5.
Sul mail server di Bob, il lato server di
SMTP riceve il messaggio. Il mail server di
Bob lo deposita nella mailbox di Bob.
6.
Bob userà il suo user agent nel momento in
Scenario tipico
Solitamente, SMTP non usa mail server intermedi Se il mail server di Bob
non è in funzione il messaggio rimane nel mail server di Alice
o nuovi tentativi di spedizione (e.g., ogni 30 minuti)
o dopo molti tentativi (e.g., alcuni giorni) il messaggio viene rimosso ed Alice viene avvertita con un email
Formato dei messaggi di posta
smtp: protocollo per lo scambio di messaggi di email
RFC 822: standard per i messaggi in formato testo:
header lines, e.g.,
o To: o From: o Subject:
diversi dai comandi smtp !
body
o il “messaggio”, solo caratteri
ASCII
header lines aggiunte dal lato
server del SMTP che riceve
header
body
linea vuota
Esempio di interazione smtp
S: 220 hamburger.edu C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr... Sender ok C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... Recipient ok C: DATA
S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup?
C: How about pickles? C: .
S: 250 Message accepted for delivery C: QUIT
Provate l’interazione smtp:
telnet servername 25
vedete la risposta 220 dal server
digitando i comandi HELO, MAIL FROM, RCPT TO,
DATA, QUIT
vi permette di spedire un email senza usare uno user
agent (client)
smtp: ultime nozioni
smtp usa connessioni
persistenti
smtp richiede che i
messaggi (header e body) siano in ASCII a 7-bit
alcune stringhe di caratteri
non sono permesse nel messaggio (e.g.,
CRLF.CRLF). Quindi il messaggio deve essere codificato (di solito, o base-64 o quoted printable) il server smtp usa per
Confronto con http:
http: pull email: push entrambi hanno un’interazionecomando/risposta con testo ASCII e con codici di stato
http: ogni oggetto è
incapsulato nel proprio messaggio di risposta
smtp: oggetti multipli
multi-Formato messaggio: estensioni multimediali
MIME: (multipurpose internet mail extension) RFC 2045,
2056
linee aggiuntive nel header del messaggio dichiarano il
tipo di contenuto MIME
From: alice@crepes.fr To: bob@hamburger.edu
Subject: Picture of yummy crepe. MIME-Version: 1.0
Content-Transfer-Encoding: base64 Content-Type: image/jpeg
base64 encoded data ... ... ...base64 encoded data
tipo di dati multimedia, sotto-tipo, dichiarazione parametri metodo usato per
codificare dati versione MIME
Tipi MIME
Content-Type: type/subtype; parameters
Text
esempi di sotto-tipo: plain, htmlImage
esempi di sotto-tipo: jpeg, gifAudio
esempi di sotto-tipo:basic (8-bit mu-law
encoded), 32kadpcm (32 kbps coding)
Video
esempi di sotto-tipo: mpeg, quicktimeApplication
altri dati che devono
essere elaborati dal reader prima che siano
“visualizzabili”
esempi di sotto-tipo:
Tipo Multipart
From: alice@crepes.fr To: bob@hamburger.edu
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 ... ...
Protocolli d’accesso alla Mail
SMTP: recapito/memorizzazione al server del destinatario Protocollo d’accesso alla mail: recupero dal server
o POP: Post Office Protocol [RFC 1939]
• autorizzazione (agent <--> server) e download
o IMAP: Internet Mail Access Protocol [RFC 1730]
• più funzionalità (più complesso)
• manipolazione dei messaggi memorizzati sul server
o HTTP: Hotmail , Yahoo! Mail, etc.
user agent mail server del mittente user agent
SMTP
SMTP
POP3 o
IMAP
mail server del destinatarioProtocollo POP3
lo user agent (client) apre una
connessione TCP (porta 110) con il mail server (server)
fase di autorizzazione
comandi client:
o user: dichiarazione username o pass: password
risposte del server
o +OK o -ERR
fase di transazione,
client: list: elenca numeri di messaggio
retr: recupera messaggio tramite numero C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents> S: . C: dele 1 C: retr 2 S: <message 1 contents> S: . C: dele 2
S: +OK POP3 server ready C: user alice
S: +OK
C: pass hungry
ftp: il file transfer protocol
trasferimento file da/a host remoto modello client/server
o client: lato che inizia il trasferimento (o da o verso
remoto)
o server: host remoto
ftp: RFC 959 file transfer FTP server Interfaccia utente FTP FTP client file system locale file system remoto utente su un host
ftp: controllo e connessione dati separati
il client ftp contatta il server
ftp sulla porta 21,
specificando TCP quale protocollo di trasporto
si aprono due connessioni TCP
parallele:
o controllo: scambio di
comandi, risposte tra client e server.
controllo “out of band”
o dati: file di dati verso/dal
server
server ftp mantiene lo
“stato”: directory corrente,
client FTP serverFTP controllo connessione TCP porta 21 connessione dati TCP porta 20
Comandi e risposte ftp
Esempi di comandi:
Spediti come testo ASCII
sul canale di controllo
USER username
PASS password
LIST restituisce la lista dei file nella directory corrente
RETR filename reperisce il file
STOR filename scrive il file sull’ host remoto
Esempi di codici di ritorno
Codice di stato e frase (come
per http)
331 Username OK, password required
125 data connection
already open; transfer starting
425 Can’t open data connection
