Ritardi nelle reti a commutazione di pacchetto › ~rossano › DIDATTICA › reti ›...

1: Introduzione 35

Ritardi nelle reti a commutazione di pacchettoI pacchetti avvertono un

ritardo sul cammino sorgente-destinazionequattro sorgenti di ritardo ad ogni hop (routervisitato)

Elaborazione del router: o Controllo dei bit di erroreo Determinazione del canale

di uscitaaccodamento

o Tempo d’attesa al canale di uscita per la trasmissione

o Dipende dal livello di congestione del router

A

B

propagazione

trasmissione

elaborazionedel router accodamento

1: Introduzione 36

Ritardi nelle reti a commutazione di pacchettoRitardo 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

elaborazionedel router accodamento

Nota: s ed R sono quantità MOLTO diverse!

1: Introduzione 37

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 piccoloL a / R -> 1: ritardo medio di accodamento diventa grandeL a / R > 1: il “lavoro” che arriva è più di quello che può essere svolto, il ritardo medio diventa infinito!

1: Introduzione 38

Ritardi e cammini “veri” in Internet

1 cs-gw (128.119.240.254) 1 ms 1 ms 2 ms2 border1-rt-fa5-1-0.gw.umass.edu (128.119.3.145) 1 ms 1 ms 2 ms3 cht-vbns.gw.umass.edu (128.119.3.130) 6 ms 5 ms 5 ms4 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 ms7 nycm-wash.abilene.ucaid.edu (198.32.8.46) 22 ms 22 ms 22 ms8 62.40.103.253 (62.40.103.253) 104 ms 109 ms 106 ms9 de2-1.de1.de.geant.net (62.40.96.129) 109 ms 102 ms 104 ms10 de.fr1.fr.geant.net (62.40.96.50) 113 ms 121 ms 114 ms11 renater-gw.fr1.fr.geant.net (62.40.103.54) 112 ms 114 ms 112 ms12 nio-n2.cssi.renater.fr (193.51.206.13) 111 ms 114 ms 116 ms13 nice.cssi.renater.fr (195.220.98.102) 123 ms 125 ms 124 ms14 r3t2-nice.cssi.renater.fr (195.220.98.110) 126 ms 126 ms 124 ms15 eurecom-valbonne.r3t2.ft.net (193.48.50.54) 135 ms 128 ms 133 ms16 194.214.211.25 (194.214.211.25) 126 ms 128 ms 126 ms17 * * *18 * * *19 fantasia.eurecom.fr (193.55.113.142) 132 ms 128 ms 136 ms

traceroute: router, ritardi sul cammino sorgente-destinazione path: vedi anche pingplotter, ed altri

1: Introduzione 39

Struttura di Internet: rete di reti

a grandi linee gerarchicanational/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 regionalio connettono ai NBP

ISP locali, privati, istituzioni

o connettono agli ISP regionali

NBP A

NBP B

NAP NAP

ISP regionali

ISP regionali

ISP locali

ISPlocali

1: Introduzione 40

National Backbone Providere.g. Sprint US backbone network

1: Introduzione 41

Livelli di un protocolloLe reti di telecomunicazionesono complesse!

molte componenti:o hosto routero canali di comunicazione

(diversi mezzi trasmissivi)

o applicazionio protocollio hardware, software

Domanda:Si può organizzare la struttura di una rete?

O, almeno, la discussione?

1: Introduzione 42

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

1: Introduzione 43

Organizzazione di un viaggio: vista diversa

Livelli: ogni livello implementa un servizioo attraverso azioni interne al proprio livelloo 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

1: Introduzione 44

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

rotta aereo da partenza a destinazione

1: Introduzione 45

Implementazione distribuita delle funzionalità di un livello

rotta aerea

Aer

opor

to d

i par

tenz

a

Siti intermedi di traffico aereorotta aerea rotta aerea

Aer

opor

to d

’arri

vobiglietto (acquisto)

bagaglio (accett.)

uscita (imbarco)

pista (decollo)

rotta aerea

biglietto (reclamo)

bagaglio (ritiro)

uscita (sbarco)

pista (atterraggio)

rotta aerea

1: Introduzione 46

Perché i livelli?Sistemi complessi:

Una strutturazione esplicita consente l’identificazione e le relazioni tra parti di un sistema complessoo modello di riferimento a livelli per lo studio

Modularizzazione facilita il mantenimento e l’aggiornamento di un sistemao La modifica dell’implementazione del servizio di

un livello è trasparente al resto del sistemao e.g., modifica nella procedura d’imbarco non

condiziona il resto del sistema “viaggio aereo”Alcuni criticano la strutturazione a livelli

1: Introduzione 47

Stack di protocolli Internet application: supporto per applicazioni di rete

o ftp, smtp, httptransport: trasferimento dati da host a host

o tcp, udpnetwork: instradamento di datagram da mittente a destinazione

o ip, protocolli di routinglink: trasferimento dati tra due elementi vicini (connessi) delle rete

o ppp, ethernetphysical: trasferimento di bits lungo i canali di comunicazione fisici

application

transport

network

link

physical

1: Introduzione 48

Funzionalità dei livelli

Ogni livello può eseguire uno, o più, dei seguenti tipi di compitoo controllo degli errorio controllo di flussoo segmentazione e ricostruzioneo multiplexing/demultiplexingo “setup” di connessione

1: Introduzione 49

Struttura a livelli: comunicazione logica

applicationtransportnetwork

linkphysical


linkphysical application

transportnetwork

linkphysical


linkphysical

networklink

physical

Ogni livello:distribuito“entità” implementano funzioni di un livello ad ogni nodoentità eseguono azioni, scambiano messaggi con i propri “pari”

1: Introduzione 50

Struttura a livelli: comunicazione logica


linkphysical


linkphysical application

transportnetwork

linkphysical


linkphysical

networklink

physical

dati

datiE.g.: transportRiceve dati dall’ applicationAggiunge 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”)analogia: ufficio postale

dati

transport

transport

ack

1: Introduzione 51

Struttura a livelli: comunicazione fisica


linkphysical


linkphysical


linkphysical


linkphysical

networklink

physical

dati

dati

1: Introduzione 52

Protocolli a livelli e dati

Ogni livello prende dati dal livello superioreAggiunge informazioni in un header (intestazione) per creare una nuova unità di datiPassa la nuova unità di dati al livello sottostante


linkphysical


linkphysical

sorgente destinazioneMMMM

Ht

HtHnHtHnHl

MMMM

Ht

HtHnHtHnHl

messaggiosegmentodatagramframe

1: Introduzione 53

Storia di Internet

1961: Kleinrock – teoria delle code dimostra l’efficacia della commutazione di pacchetto1964: Baran –commutazione di pacchetto nelle reti militari1967: ARPAnet concepita dal Advanced Research Projects Agency1969: 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

1: Introduzione 54

Storia di Internet

1970: rete satellitare ALOHAnet nelle Hawaii1973: Metcalfe nella sua tesi di PhD propone Ethernet1974: architettura proposta da Cerf e Kahn per l’interconnessione di retifine anni 70: architetture proprietarie: DECnet, SNA, XNAfine 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 decentralizzatoDefiniscono l’architettura

dell’attuale Internet

1972-1980: Internetworking, nuove reti e reti proprietarie

1: Introduzione 55

Storia di Internet

1983: diffusione di TCP/IP1982: definizione del protocollo smtp per l’e-mail 1983: definizione del DNS per la traduzione da nome ad indirizzo IP1985: definizione del protocollo ftp1988: controllo di congestione in TCP

Nuove reti nazionali: Csnet, BITnet, NSFnet, Minitel100,000 host connessi alla confederazione di reti

1980-1990: nuovi protocolli, proliferazione di reti

1: Introduzione 56

Storia di Internet

Primi anni 90: disarmo di ARPAnet1991: 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-Leeo 1994: Mosaic, più tardi

Netscapeo fine anni 90:

commercializzazione del WWW

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

1: Introduzione 57

Introduzione: sommarioMolto materiale

panoramica su Internetcos’è un protocollo?network edge, core, access network

o commutazione di pacchetto e di circuito

prestazioni: perdite, ritardistrutturazione a livelli e modelli di serviziobackbone, NAP, ISPstoria

Ora avete:Una panoramica sulle problematicaAndremo nel dettaglio

2: Livello Application 1

Parte 2: livello ApplicationObiettivi:

Aspetti concettuali ed implementativi di protocolli di applicazioni di rete

o Paradigma client-server

o Modello dei serviziImparare concetti sui protocolli esaminando protocolli a livello applicazione molto diffusi

Altri obiettivi Protocolli specifici:

o httpo ftpo smtpo pop o dns

Programmazione di applicazioni di rete

o socket API


Applicazioni e protocolli a livello applicationApplicazione: processi distribuiti

comunicantio vengono eseguiti sugli host di

rete come processi utenteo scambio di messaggi per

implementare l’applicazioneo e.g., email, ftp, Web

Protocolli a livello Applicationo una parte di un’applicazioneo definiscono i messaggi

scambiati dall’applicazione e le azioni intraprese

o Usano i servizi di comunicazione forniti da protocolli a livello sottostante (TCP, UDP)

applicationtransportnetworkdata linkphysical




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 livelloapplication

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: browsero E-mail: mail readero streaming audio/video:

media player


Paradigma Client-serverUna tipica applicazione di rete si

compone di due parti: client e server



Client:Avvia il contatto con il server (“parla per primo”)Solitamente, richiede un servizio al serverWeb: il client è implementato nel browser; e-mail: in mail reader

request

reply

Server:Fornisce il servizio richiesto al cliente.g., il Web server spedisce la pagina Web richiesta, il mail server recapita l’e-mail


Protocolli a livello application

API: application programming interfaceDefinisce l’interfaccia tra l’applicazione ed il livello transportsocket: 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 il messaggio

… ne vedremo di più dopo.


Applicazioni, socket e livello trasporto

InternetTCP convariabili,buffer

processo

socket

sotto il controllo del

programmatore

sotto il controllo del sistema operativo

host o server

TCP convariabili,buffer

socket

sotto il controllo del

programmatore

sotto il controllo del sistema operativo

host o server

processo


Di quale servizio di trasporto necessita un’applicazione?Perdita di dati

Alcune applicazioni (e.g., audio) possono tollerare perditeAltre applicazioni (e.g., trasferimento file, telnet) richiedono un trasferimento dati affidabile al 100%

Time-sensitiveAlcune applicazioni (e.g., telefonia su Internet, giochi interattivi) richiedono piccoli ritardi

Larghezza di bandaAlcune 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 riescono ad ottenere


Requisiti del servizio di Trasporto di applicazioni comuni

Applicazione

trasferimento filee-mail

documenti Webreal-time audio/video

stored audio/videogiochi interattivi

applicazioni finanziarie

Perdite dati

senzasenzatollerantetollerante

tollerantetollerantesenza

Larghezza di banda

elasticaelasticaelasticaaudio: 5Kb-1Mbvideo:10Kb-5Mbcome sopra alcuni Kbpselastica

Time Sensitive

nononosi, alcuni 100 msec

si, pochi secssi, alcuni 100 msecsi e no


Servizi di trasporto in Internet

Servizio TCP:connection-oriented: fase iniziale di “setup” necessaria tra client e servertrasporto affidabile tra processo mittente e destinatariocontrollo di flusso: il mittente non sovraccaricherà il ricevitorecontrollo di congestione:regolazione della velocità del mittente quando la rete è sovraccaricanon fornisce: tempi, garanzie su larghezza di banda minima

Servizio UDP:trasferimento dati non affidabile tra processo mittente e processo destinatarionon 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-mailaccesso a terminale remoto

Web trasferimento file

streaming multimedia

file server remototelefonia su Internet

Protocollo a livello applicazione

smtp [RFC 821]telnet [RFC 854]http [RFC 2068]ftp [RFC 959]proprietario(e.g. RealNetworks)NSFproprietario(e.g., Vocaltec)

Protocollo a livello transport sottostante

TCPTCPTCPTCPTCP or UDP

TCP or UDPsolitamente UDP


Il Web: il protocollo http

http: hypertext transfer protocolProtocollo a livello applicazione per il WebModello 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 1945http1.1: RFC 2068-2616

PC che esegueExplorer

Server che esegue

NCSA Web server

Mac che esegueNavigator

http request

http request

http response

http response


Il WEB: terminologia

pagina WEB (documento): collezione di oggettioggetto: un file (HTML, JPEG, …)file HTML base: con direttive e riferimenti ad altri oggettiURL (Uniform Resource Locator): meccanismo di identificazione risorse. Si compone del nome del host sul quale risiede l’oggetto e il path-name dell’oggettoo www.di.unito.it/various/presentation_en.html

nome host path-name


Il protocollo http

http: usa servizio TCP:il client avvia una connessione TCP (crea un socket) con il server, porta 80il server accetta la connessione TCP dal clientvengono 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 client

I protocolli che mantengono lo stato sono complessi!Tutta la storia passata della connessione (stato) deve essere mantenuta, memorizzatase server o client subiscono un crash, la loro conoscenza dello stato può essere inconsistente e deve essere ricostruita

nota


http: esempioSupponiamo 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’ hostwww.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 (someDepartment/home.index), e spedisce un messaggio nel socket

tempo

(contiene testo e 10 riferimenti ad

immagini jpeg)


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.

tempo


Connessioni persistenti e non persistenti

Non persistentihttp/1.0: il server parsificale richieste, risponde, chiude la connessione TCP2 RTT (round trip time) per ottenere l’oggetto

o connessione TCPo richiesta/trasferimento

oggettoOgni trasferimento risente della bassa velocità iniziale di trasferimento di TCPmolti browser aprono connessioni multiple in parallelo

Persistentidefault per http/1.1usando 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.Con o senza pipelining


Connessioni persistenti e non persistenti

open

close

open

close

open

close

client server

HTTP 1.0

open

close

client server

HTTP 1.1

open

close

client server

HTTP 1.1pipelining


Formato dei messaggi http: request

due tipi di messaggi http: request, responsehttp request message:

o ASCII (formato human-readable)

GET /somedir/page.html HTTP/1.0 Host: www.someschool.eduUser-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,…)

lineeheader

Carriage return, line feed

indicano la finedel messaggio


http request message: formato generale


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 serverHEAD: simile al GET ma l’oggetto non viene trasferito (controllo stato dei documenti)POST: per spedire dati al server (contenuto di una form HTML)


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.From: specifica l'indirizzo e-mail del richiedente.


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: gzipContent-Length: 6821 Content-Type: text/html

data data data data data ...

status line(codice di stato

del protocollofrase di stato)

lineeheader

dati, e.g., file htmlrichiesto


http response message: formato generale

versionversionversionversion status codestatus codestatus codestatus code phrasephrasephrasephrase status status status status linelinelineline


Codici di stato per http response

200 OKo richiesta con successo, l’oggetto richiesto segue in questo

messaggio301 Moved Permanently

o L’oggetto richiesto è stato spostato, la nuova locazione è specificata dopo in questo messaggio (Location:)

400 Bad Requesto request message non compreso dal server

404 Not Foundo Documento richiesto non trovato su questo server

505 HTTP Version Not Supported

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) suwww.eurecom.fr. Qualunque cosa si digiti vienespedita 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

3. Guardate il response message spedito dal server http!


Interazione utente-server: autenticazioneAutenticazione: controllo

dell’accesso ai contenuti sul servercredenziali per autorizzazione: tipicamente nome, passwordstateless: 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 spedisceWWW authenticate:

header line nel response

client serversolito http request msg401: authorization req.WWW authenticate:

solito http request msg+ Authorization: <cred>

solito http response msg

solito http request msg+ Authorization: <cred>


time


Cookies: mantenere lo “stato”

# generato dal server, # ricordato dal server, usato in futuro per:

o autenticazioneo ricordare le

preferenze dell’utente, scelte precedenti

il server manda un “cookie” al client nel response messageSet-cookie: 1678453

il client presenta il cookiein richieste futurecookie: 1678453

client serversolito http request msgsolito http response +Set-cookie: #

solito http request msgcookie: #


solito http request msgcookie: #


azionispecifiche per

il cookie

azionispecifiche per

il cookie


Conditional GET: caching lato client

Obiettivo: non spedire un oggetto se il client ha una versione in cache aggiornataclient: specifica la data della copia nella cache nel http requestIf-modified-since:

<date>

server: l’http response non contiene l’oggetto se la copia in cache è aggiornata: HTTP/1.0 304 Not

Modified

client serverhttp request msg

If-modified-since: <date>

http responseHTTP/1.0

304 Not Modified

oggetto non

modificato

http request msgIf-modified-since:

<date>

http responseHTTP/1.1 200 OK

<data>

oggetto modificato


Web Cache (proxy server)

utente configura il browser: accesso Web via web cacheIl 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 originale

client

Proxyserver

client

http request

http request

http response

http response

http request

http response

serverd’origine

serverd’origine


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 clientDiminuzione del traffico verso server distanti

o i canali esterni alla rete del ISP locale/istituzionale sono spesso colli di bottiglia

server d’origine

Internetpubblica

reteistituzionale 10 Mbps LAN

canale d’accessoa 1.5 Mbps

cacheistituzionale


Posta Elettronica

Tre componenti principali:user agent mail server simple mail transfer protocol: smtp

User Agentalias “mail reader”comporre, editare, leggere messaggi di postae.g., Eudora, Outlook, elm, Netscape MessengerMessaggi in uscita e in arrivo memorizzati su un server

user mailbox

coda di messaggi in uscita

mailserver

useragent

useragent

useragent

mailserver

useragent

useragent

mailserver

useragent

SMTP

SMTP

SMTP


Posta Elettronica: mail servers

Mail Servermailbox contiene messaggi in arrivo (ancora da leggere) per l’utentecoda 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 entrambi

mailserver

useragent

useragent

useragent

mailserver

useragent

useragent

mailserver

useragent

SMTP

SMTP

SMTP


Posta Elettronica: smtp [RFC 821]

usa TCP per trasferire in maniera affidabile messaggi di posta elettronica dal client al server, porta 25trasferimento diretto: dal sending server al receivingservertre fasi del trasferimento

o handshaking (greeting-saluti)o trasferimento del messaggioo chiusura

Interazione comandi/risposteo comandi: testo ASCIIo risposte: codici di stato e frasi (come HTTP e FTP)

I messaggi devono essre in ASCII a 7-bit


Scenario tipico

1. Alice usa il suo user agent per l’email, gli fornisce l’indirizzo di Bob ([email protected]), 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 SMTP spedisce il messaggio di Alice usando la connessione TCP


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 cui vorrà leggere i messaggi in arrivo


Scenario tipicoSolitamente, SMTP non

usa mail server intermediSe 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 !

bodyo il “messaggio”, solo caratteri

ASCIIheader lines aggiunte dal lato server del SMTP che riceveo Received: from name by name

header

body

lineavuota


Esempio di interazione smtp S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <[email protected]> S: 250 [email protected]... Sender ok C: RCPT TO: <[email protected]> S: 250 [email protected] ... 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 S: 221 hamburger.edu closing connection


Provate l’interazione smtp:

telnet servername 25

vedete la risposta 220 dal serverdigitando i comandi HELO, MAIL FROM, RCPT TO, DATA, QUIT

vi permette di spedire un email senza usare uno user agent (client)


smtp: ultime nozionismtp usa connessioni persistentismtp 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 CRLF.CRLF per determinare la fine del messaggio

Confronto con http:http: pullemail: push

entrambi hanno un’interazione comando/risposta con testo ASCII e con codici di stato

http: ogni oggetto è incapsulato nel proprio messaggio di risposta

smtp: oggetti multipli spediti in messaggi multi-parte


Formato messaggio: estensioni multimediali

MIME: (multipurpose internet mail extension) RFC 2045, 2056linee aggiuntive nel header del messaggio dichiarano il tipo di contenuto MIME

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

tipo di datimultimedia, sotto-tipo, dichiarazione parametri

metodo usato percodificare dati

versione MIME

dati codificati


Tipi MIMEContent-Type: type/subtype; parameters

Textesempi di sotto-tipo: plain, html

Imageesempi di sotto-tipo: jpeg, gif

Audioesempi di sotto-tipo: basic (8-bit mu-law encoded), 32kadpcm (32 kbps coding)

Videoesempi di sotto-tipo: mpeg, quicktime

Applicationaltri dati che devono essere elaborati dal readerprima che siano “visualizzabili”esempi di sotto-tipo: msword, octet-stream


Tipo MultipartFrom: [email protected] To: [email protected] Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=98766789

--98766789Content-Transfer-Encoding: quoted-printableContent-Type: text/plain

Dear Bob, Please find a picture of a crepe.--98766789Content-Transfer-Encoding: base64Content-Type: image/jpeg

base64 encoded data ..... ......................... ......base64 encoded data --98766789--


Protocolli d’accesso alla Mail

SMTP: recapito/memorizzazione al server del destinatarioProtocollo 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.

useragent

mail server del mittente

useragent

SMTP SMTP POP3 oIMAP

mail serverdel destinatario


Protocollo POP3lo user agent (client) apre una

connessione TCP (porta 110) con il mail server (server)

fase di autorizzazionecomandi client: o user: dichiarazione usernameo pass: password

risposte del servero +OK

o -ERR

fase di transazione, client:list: elenca numeri di messaggioretr: recupera messaggio tramite numerodele: cancellaquit

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 C: quit S: +OK POP3 server signing off

S: +OK POP3 server ready C: user alice S: +OK C: pass hungry S: +OK user successfully logged on


ftp: il file transfer protocol

trasferimento file da/a host remotomodello client/server

o client: lato che inizia il trasferimento (o da o verso remoto)

o server: host remotoftp: RFC 959ftp server: porta 21

file transfer FTPserver

Interfacciautente

FTP

FTPclient

file system locale

filesystem remoto

utentesu un host


ftp: controllo e connessione dati separati

il client ftp contatta il server ftp sulla porta 21, specificando TCP quale protocollo di trasportosi 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

serverserver ftp mantiene lo “stato”: directory corrente, autenticazione precedente

clientFTP

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 controlloUSER username

PASS password

LIST restituisce la lista dei file nella directory correnteRETR filename reperisce il fileSTOR filename scrive il file sull’ host remoto

Esempi di codici di ritornoCodice 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

452 Error writing file

Ritardi nelle reti a commutazione di pacchetto › ~rossano › DIDATTICA › reti ›...

Documents

Transcript of Ritardi nelle reti a commutazione di pacchetto › ~rossano › DIDATTICA › reti ›...