Riassunto Reti di Calcolatori, Sintesi di Reti Di Calcolatori. Università degli Studi di Roma La Sapienza
juvedelpiero
juvedelpiero
Questo è un documento Store
messo in vendita da juvedelpiero
e scaricabile solo a pagamento

Riassunto Reti di Calcolatori, Sintesi di Reti Di Calcolatori. Università degli Studi di Roma La Sapienza

61 pagine
8Numero di download
705Numero di visite
Descrizione
Riassunto ben fatto, con cui ho passato l'esame, dei primi 4 capitoli del libro "Keith W. Ross James F. Kurose - Reti di calcolatori e internet.Un approccio top-down".
5.99
Prezzo del documento
Scarica il documento
Questo documento è messo in vendita dall'utente juvedelpiero: potrai scaricarlo in formato digitale subito dopo averlo acquistato! Più dettagli
Anteprima3 pagine / 61
Questa è solo un'anteprima
3 pagine mostrate su 61 totali
Scarica il documento
Questa è solo un'anteprima
3 pagine mostrate su 61 totali
Scarica il documento
Questa è solo un'anteprima
3 pagine mostrate su 61 totali
Scarica il documento
Questa è solo un'anteprima
3 pagine mostrate su 61 totali
Scarica il documento

CAPITOLO 1: RETI DI CALCOLATORI E INTERNET

Ci sono due metodi per rispondere alla domanda che cos’è Internet. Il primo consiste nel descrivere i componenti software e hardware che lo compongono mentre il secondo consiste nel descrivere gli ingranaggi che lo caratterizzano. Diamo una spiegazione in base al primo metodo.

Internet è una rete di calcolatori che interconnette milioni di dispositivi di calcolo in tutto il mondo. Al giorno d’oggi però, vengono connessi a internet sistemi non tradizionali, quali computer portatili, TV, console di gioco e per questo il termine rete di calcolatori comincia ad essere datato. Tutti questi dispositivi sono detti host (ospiti) o sistemi periferici. I sistemi periferici sono connessi tra loro tramite una rete di collegamenti (communication link) e commutatori di pacchetti (packet switch). Collegamenti diversi possono trasmettere dati a velocità differenti e tale velocità di trasmissione viene misurata in bit/secondo. Quando un sistema periferico vuole inviare dati ad un altro sistema periferico, suddivide i dati in blocchi e aggiunge un’intestazione a ciascuno di essi che ne indica la destinazione del blocco. Questi blocchi vengono chiamati pacchetti e sono inviati attraverso la rete alla destinazione dove vengono riassemblati per ottenere i dati originari. Un commutatore di pacchetto prende un pacchetto che arriva da uno dei collegamenti in ingresso e lo ritrasmette su uno di quello in uscita. Esistono vari tipi di commutatori di pacchetto ma i due principali sono i router e i commutatori a livello di collegamento. Dal sistema di invio a quello di ricezione la sequenza di collegamenti e di commutatori attraversati da un singolo pacchetto viene detta percorso. I sistemi periferici accedono a Internet tramite i cosiddetti Internet Service Provider (ISP). Un provider è un insieme di commutatori di pacchetto e di collegamenti. Gli ISP forniscono vari tipi di accesso alla rete: DSL, quello senza fili e il dial-up a 56 kbps. Sistemi periferici, commutatori di pacchetto e altre parti di Internet fanno uso di protocolli che controllano l’invio e la ricezione di informazioni all’interno della rete. Due dei principali protocolli Internet sono il transmission control protocol (TCP) e l’Internet Protocol (IP). I documenti sugli standard di Internet vengono detti request for comment (RFC).

Talvolta gli host vengono suddivisi in due categorie: client e server. In modo informale, i client sono host che richiedono dei servizi e tendono ad essere PC, smartphone e via dicendo mentre i server si occupano di erogare servizi.

Le reti di accesso connettono fisicamente un sistema al suo edge router, che è il primo router (commutatore di pacchetto) sul percorso.Ci sono vari tipi di reti di accesso a seconda di dove vengono usate.

ACCESSO RESIDENZIALE

1

I due accessi residenziali a larga banda più diffusi sono il digital subscriber line (DSL) e quella via cavo. Un accesso di tipo DSL viene generalmente fornito dalla stessa compagnia telefonica che fornisce anche il servizio di telefonia fissa, ma non deve essere per forza così. Il modem DSL dell’utente usa la linea telefonica esistente per scambiare dati con un DSLAM che si trova nella centrale locale (central office) della compagnia telefonica. Il modem DSL residenziale converte i dati digitali in toni ad alta frequenza per poterli trasmettere alla centrale locale sul cavo telefonico; i dati provenienti dalle abitazioni vengono poi riconvertiti in formato digitale nel DSLAM. Le linee telefoniche residenziali trasportano contemporaneamente dati e segnali telefonici tradizionali codificandoli in tre bande sovrapposte: un canale di downstream, un canale di upstream e un canale telefonico ordinario. Tale approccio permette che una chiamata telefonica e una connessione a Internet possano contemporaneamente condividere lo stesso collegamento DSL. Centinaia e anche migliaia di abitazioni sono connesse ad un unico DSLAM.

Mentre la DSL usa le infrastrutture già esistenti della compagnia telefonica locale, l’accesso a internet via cavo utilizza le infrastrutture esistenti della compagnia che le fornisce il servizio di televisione via cavo. Con questo tipo di connessione tramite fibra ottica si raggiungono vari quartieri e poi tramite cavo coassiale si raggiunge le singole case. Tale sistema viene infatti chiamato hybrid fiber coax (HFC) in quanto impiega sia la fibra ottica sia il cavo coassiale. L’accesso a Internet via cavo richiede modem speciali, chiamati cable modem e al posto del DSLAM che è presente nelle reti DSL qui abbiamo il CMTS che svolge sostanzialmente le stesse operazioni di conversione da analogico a digitale. Un’importante caratteristica delle reti HFC è il fatto di rappresentare un mezzo di trasmissione condiviso. In particolare, ciascun pacchetto inviato dalla stazione di testa viaggia sul canale di downstream verso ogni abitazione, per questa ragione se diversi utenti stanno contemporaneamente scaricando un file la velocità con cui ciascun utente riceve il proprio file sarà significativamente inferiore a quella totale del canale di downstream.

Sebbene le reti DSL e via cavo sono ad oggi le più diffuse una tecnologia promettente che vanta velocità anche maggiori è detta fiber to the home (FTTH) e il concetto è quello di fornire fibra ottica dalla central office direttamente alle abitazioni. La rete di distribuzione ottica più semplice è chiamata fibra diretta, in cui una singola fibra collega una centrale locale a un’abitazione. Di solito però una fibra uscente dalla centrale locale è inizialmente condivisa da molte abitazioni e solo quando arriva relativamente vicina alle abitazioni viene suddivisa in più fibre, ognuna dedicata a un utente.

ACCESSO AZIENDALE: ETHERNET E WIFI

2

Nelle aziende e nelle università per collegare i sistemi periferici a router edge si utilizza una rete locale LAN. Esistono molti tipi di LAN, ma la tecnologia Ethernet è attualmente la più utilizzata. Ethernet utilizza un doppino di rame intrecciato per collegare numerosi sistemi periferici a uno switch Ethernet. Lo switch viene poi connesso a Internet. Sempre più utenti accedono a Internet via wireless. In una LAN wireless gli utenti trasmettono e ricevono pacchetti da e verso un access point wireless che è connesso a una rete aziendale.

Abbiamo già visto alcuni mezzi trasmessivi utilizzati, come ad esempio il doppino utilizzato nelle reti DSL, il cavo coassiale e la fibra ottica. I mezzi fisici utilizzati si dividono in due categorie: i mezzi vincolati e quelli non vincolati. Nei primi le onde vengono contenute in un mezzo fisico, quale un cavo in fibra ottica, un filo di rame o un cavo coassiale mentre nei secondi le onde si propagano nell’atmosfera come avviene per le LAN Wireless. Vediamo ora nel dettaglio alcuni mezzi trasmessivi più utilizzati.

Doppino di rame intrecciato

Il mezzo trasmissivo vincolato meno costoso e più utilizzato è il doppino di rame intrecciato. Il doppino intrecciato è costituito da due fili di rame distinti che vengono intrecciati assieme per ridurre l’interferenza elettrica. Di regola, un certo numero di doppini viene riunito e avvolto in uno schermo protettivo a formare un cavo.

Cavo coassiale

Anche il cavo coassiale è costituito da due conduttori di rame concentrici. Con questa struttura e grazie a uno speciale isolamento il cavo coassiale può raggiungere alte frequenze di trasmissione.

Fibra ottica

La fibra ottica è un mezzo sottile e flessibile che conduce impulsi di luce, ciascuno dei quali rappresenta un bit. Tale mezzo è immune alle interferenza elettromagnetica e presenta attenuazione di segnale molto bassa nel raggio di 100 chilometri. Queste caratteristiche hanno reso la fibra ottica il mezzo trasmissivo vincolato a lungo raggio favorito dagli operatori. Tuttavia l’alto costo di trasmettitori e ricevitori ha impedito il loro utilizzo per il trasporto a corto raggio.

Canali radio terrestri

I canali radio trasportano segnali all’interno dello spettro elettromagnetico. Si tratta di un mezzo interessante dato che non richiede l’installazione fisica di cavi, è in grado di attraversare pareti. La qualità dei canali radio dall’ambiente di propagazione e

3

dalla distanza alla quale il segnale deve essere inviato. L’ambiente determina infatti la perdita di segnale lungo il percorso causata dalla distanza o dall’interferenza con altri canali radio.

Esaminiamo adesso il nucleo della rete che è formato da una maglia di commutatori di pacchetti e collegamenti che collegano i sistemi periferici di Internet. La sorgente suddivide i messaggi lunghi in parti più piccole note come pacchetti. Tra la sorgente e la destinazione questi pacchetti viaggiano attraverso collegamenti e commutatori di pacchetto (che possono essere router o commutatori a livello di collegamento). I pacchetti vengono trasmessi su ciascun collegamento a una velocità pari alla velocità totale di trasmissione del collegamento stesso. Quindi se inviamo un pacchetto di L bit su un canale con velocità R bps, il tempo di trasmissione risulta pari a L/R secondi.

La maggior parte dei commutatori di pacchetto utilizza la trasmissione store-and- forward. Ciò significa che il commutatore deve ricevere l’intero pacchetto prima di poter cominciare a trasmettere sul collegamento in uscita. Con questa trasmissione all’istante L/R il pacchetto è ricevuto e memorizzato nel router e in tale istante il router avendo appena ricevuto l’intero pacchetto comincia a trasmetterlo sul collegamento in uscita verso il destinatario; e all’istante 2L/R l’intero pacchetto è stato trasmesso dal router e ricevuto dal destinatario.

Come fa un router a fa il router a determinare su quale collegamento il pacchetto deve essere inoltrato? In Internet ogni sistema periferico ha un indirizzo chiamato IP. Ogni pacchetto che percorre la rete contiene nella propria intestazione l’indirizzo della propria destinazione. Ogni router ha una tabella di inoltro che mette in relazione gli indirizzi di destinazione con i collegamenti in uscita. Così quando un pacchetto giunge ad un router questo esamina l’indirizzo di destinazione e consulta la propria tabella di inoltro per determinare il collegamento uscente più appropriato. Queste tabelle di inoltro vengono impostate attraverso protocolli di instradamento.

Per spostare i dati nella rete di collegamenti e commutatori esistono due approcci fondamentali: la commutazione di circuito e la commutazione di pacchetto di cui abbiamo già parlato. Nelle reti a commutazione di circuito le risorse richieste da due sistemi periferici rimangono riservate per l’intera durata della sessione di comunicazione. Si prenda come esempio le reti telefoniche. Si consideri cosa avviene quando una persona vuole inviare informazioni (voce o fax) a un'altra persona. Prima che possa iniziare l’invio, la rete deve stabilire una connessione tra mittente e destinatario, questo collegamento è detto circuito. Questo è collegamento in cui i commutatori sul percorso mantengono lo stato di connessione per tutta la durata della comunicazione. Un circuito è implementato tramite multiplexing a divisione di

4

frequenza (FDM) o multiplexing a divisione di tempo (FDT). Con FDM il collegamento dedica una banda di frequenza a ciascuna connessione per la durata della connessione stessa. Con un collegamento FDT il tempo viene suddiviso in frame che sono a loro volta divisi in slot di dimensione costante. Quando le rete stabilisce una connessione le dedica uno slot di tempo in ogni frame.

Oggigiorno Internet è una rete di reti complessa che consiste di dozzine di ISP di primo livello e centinaia di migliaia di ISP di livello inferiore. Gli ISP di livello più basso si collegano a quelli di livello superiore e questi ultimi si interconnettono tre loro. Ultimamente i fornitori di contenuti come Google hanno creato le proprie reti private e quando possibile si connettono direttamente agli ISP di livello inferiore.

Ricordiamo che un pacchetto parte da un host passa attraverso una serie di router e conclude il viaggio in un altro host. A ogni tappa da router A a router B il pacchetto subisce vari tipi di ritardo, che possono essere: ritardo di elaborazione, ritardo di accodamento, ritardo di trasmissione, ritardo di propagazione. Il tempo richiesto per esaminare l’intestazione del pacchetto e determinare dove dirigerlo fa parte del ritardo di elaborazione. Dopo l’elaborazione il router dirige il pacchetto verso la coda che precede l’altro router. Una volta in coda il pacchetto subisce un ritardo di accodamento mentre attende la trasmissione sul collegamento. La lunghezza di tale ritardo dipenderà dal numero di pacchetti precedentemente arrivati e in attesa di trasmissione sullo stesso collegamento. Se la coda è vuota e non è in corso la trasmissione di altri pacchetti allora il ritardo di accodamento per il nostro pacchetto sarà nullo. Assumendo che i pacchetti siano trasmessi secondo la politica first-in- first-out, come avviene comunemente, il nostro pacchetto può essere trasmesso solo dopo la trasmissione di tutti i pacchetti che sono arrivati prima; questo viene detto ritardo di trasmissione. Una volta immesso nel collegamento il tempo che impiega per arrivare al prossimo router è detto ritardo di propagazione. Il ritardo totale di nodo è dato dalla somma di tutti questi ritardi. Un pacchetto però può trovare la coda piena. Non essendo possibile memorizzare tale pacchetto, il router lo eliminerà e il pacchetto andrà perduto. Oltre al ritardo e alla perdita di pacchetti un’altra misura critica delle prestazioni in una rete di calcolatori è il throughput end-to-end. Il throughput istantaneo è la velocità alla quale la destinazione sta ricevendo il file: molte applicazioni di condivisione file mostrano il throughput istantaneo durante il download nell’interfaccia utente. Si prenda l’esempio di due sistemi periferici, un server e un client, connessi da due collegamenti e da un router e si consideri il throughput per un trasferimento di file dal server al client. Sia Rs la velocità tra il server e il router e Rc quella del collegamento tra il router e il client e si supponga che i soli bit inviati sull’intera rete siano quelli tra il server e il client. Dobbiamo quindi pensare ai bit come a un fluido mentre i collegamenti sono i condotti. Chiaramente il

5

server non può pompare nel suo collegamento a una velocità maggiore di Rs e il router non può inoltrare a una velocità maggiore di Rc bps. Se Rs>Rc allora i bit immessi dal server attraverseranno il router e arriveranno al client ad una velocità di Rs bps, dando un throughput di Rs. Se invece Rc<Rs il router non sarà in grado di inoltrare i bit alla stessa velocità alla quale li riceve. In tal caso i bit lasceranno il router a una velocità di Rc bps, dando un throughput end-to-end di Rc. Quindi in sostanza il throughput è il min(Rc,Rs) ovvero la velocità di trasmissione che fa da collo di bottiglia.

I progettisti dividono i protocolli di rete in livelli o strati e ciascun protocollo appartiene a uno dei livelli. La stratificazione dei protocolli rende più facile aggiornare la componentistica. Mentre un eventuale svantaggio della stratificazione è la possibilità che un livello duplichi le funzionalità di quello inferiore. Un altro svantaggio è che un livello possa richiedere informazioni presenti solo in un altro livello violando così la separazione dei livelli. Considerati assieme, i protocolli dei vari livelli sono detti pila di protocolli. La pila di protocolli di Internet consiste di cinque livelli: fisico, collegamento, rete, trasporto e applicazione.

LIVELLO DI APPLICAZIONE

Il livello di applicazione è la sede dei protocolli di rete. Tale livello include molti protocolli quali HTTP che consente la richiesta e il trasferimento dei documenti web, SMTP che consente il trasferimento di messaggi di posta elettronica e FTP che consente il trasferimento di file tra due sistemi remoti.

LIVELLO DI TRASPORTO

Il livello di trasporto trasferisce i messaggi del livello di applicazione tra punti periferici gestiti dalle applicazioni. In Internet troviamo due protocolli di trasporto: TCP e UDP. TCP fraziona i messaggi lunghi in segmenti più brevi e fornisce un meccanismo di controllo della congestione, in modo che una sorgente la propria velocità trasmissiva quando la rete è congestionata. D’ora in avanti chiameremo segmenti i pacchetti a livello di trasporto.

LIVELLO DI RETE

Il livello di rete si occupa di trasferire i pacchetti a livello di rete, detti datagrammi, da un host a un altro. Il protocollo Internet a livello di trasporto (TCP o UDP) passa al livello sottostante un segmento e un indirizzo di destinazione. Il livello di rete consegna poi il segmento del livello di trasporto all’host di destinazione. Il livello di rete di Internet contiene il famoso protocollo IP, che definisce i campi dei datagrammi e come i sistemi periferici e i router agiscono su tali campi.

6

LIVELLO DI COLLEGAMENTO

Il livello di rete instrada un datagramma attraverso una serie di router tra la sorgente e la destinazione. Per trasferire da un nodo (host o router) a quello successivo sul percorso, il livello di rete si affida ai servizi del livello di collegamento. Chiameremo frame i pacchetti a livello di collegamento.

LIVELLO FISICO

Mentre il compito del livello di collegamento è spostare interi frame da un elemento della rete a quello adiacente, il ruolo del livello fisico è trasferire i singoli bit del frame da un nodo a quello successivo. I protocolli di questo livello sono ancora dipendenti dal collegamento e in più dipendono dal mezzo trasmissivo usato (Ethernet, Wi-Fi ecc). In ciascuno di tali casi i bit sono trasferiti lungo il collegamento secondo differenti modalità.

CAPITOLO 2: LIVELLO DI APPLICAZIONE

Supponiamo che vogliamo creare un applicazione di rete, per prima cosa nostro compito o quello dello sviluppatore sarà quello di progettare l’architettura dell’applicazione e quindi scegliere tra le due principali architetture più utilizzate: l’architettura client-server e quella P2P. Nell’architettura client-server vi è un host sempre attivo chiamato server, che risponde alle richieste di molti altri host chiamati client. Un esempio classico è rappresentato dall’applicazione web, in cui un web server, sempre attivo risponde alle richieste dei browser in esecuzione sui client. Si noti che in un architettura client-server i client non comunicano direttamente tra loro e inoltre il server dispone di un indirizzo fisso, detto indirizzo IP. Spesso in un’applicazione client-server un singolo host che fa da server non è in grado di gestire tutte le richieste dei suoi client per questo si fa ricorso ai data center che ospitano molti host per creare un potente server virtuale. In un’architettura P2P l’infrastruttura di server in data center è minima o del tutto assente; si sfrutta invece la comunicazione diretta tra coppie di host, chiamati peer. Dato che i peer comunicano senza passare attraverso un server, l’architettura è detta peer-to-peer. Molte della applicazioni di rete con un elevata intensità di traffico sono basate su un architettura P2P un esempio su tutto BitTorrent.

Prima di costruire un’applicazione di rete dovrete anche conoscere come comunicano tra loro i programmi in esecuzione su diversi sistemi terminali. I processi su due sistemi terminali comunicano scambiandosi messaggi attraverso la rete: il processo mittente crea e invia messaggi nella rete e il processo destinatario li riceve e, quando previsto, invia messaggi di risposta. La maggior parte delle applicazioni consiste di

7

coppie di processi comunicanti che si scambiano messaggi. Un processo invia messaggi nella rete e riceve messaggi dalla rete attraverso un’interfaccia software detta socket. Una socket fa da interfaccia tra il livello di applicazione e il livello di trasporto all’interno di un host. Come nella posta tradizionale affinché la consegna possa essere effettuata il destinatario deve avere un indirizzo, stessa cosa succede in Internet. In Internet gli host vengono identificati attraverso i loro indirizzi IP che è un numero di 32 bit che identifica univocamente un host. Oltre a conoscere l’indirizzo dell’host a cui è destinato il messaggio, il mittente deve anche identificare la socket che deve ricevere il messaggio. L’applicazione lato mittente spinge fuori i messaggi tramite la socket; dall’altra parte, lato ricevente, il protocollo a livello di trasporto ha la responsabilità di consegnare i messaggi alla socket del processo ricevente. Internet mette a disposizione vari protocolli di trasporto ma nel progettare la nostra applicazione di rete occorre scegliere il protocollo a livello di trasporto. I servizi che il protocollo a livello di trasporto può offrire a un’applicazione che li invoca possono essere classificati in quattro grandi dimensioni: trasferimento di dati affidabile, throughput e temporizzazione.

Trasferimento dati affidabile

Come abbiamo già visto in una rete di calcolatori i pacchetti possono andare perduti. In alcune applicazioni ,come ad esempio quelle di messaggistica istantanea, la perdita di informazioni potrebbe causare gravi conseguenze. Quindi, per supportare queste applicazioni occorre garantire che i dati inviati siano consegnati corretti e completi. Se un protocollo fornisce questo tipo di servizio si dice che fornisce un trasferimento dati affidabile. Quando un protocollo a livello di trasporto fornisce tale servizio, il processo mittente può passare i propri dati alla socket e sapere con assoluta certezza che quei dati arriveranno senza errori al processo ricevente.

Throughput

Un altro servizio che un protocollo a livello di trasporto può fornire è un throughput disponibile garantito. Con tale servizio l’applicazione può richiedere un throughput garantito di r bps e il protocollo di trasporto assicurerà poi che il throughput disponibile sia sempre di almeno r bps. Questo tipo di servizio interesserebbe molte applicazioni tipo quelle di telefonia su Internet che codificano la voce a 32 kbs e se il protocollo a livello di trasporto non può fornire questo throughput l’applicazione dovrà codificare i dati a un livello inferiore o rinunciare.

Temporizzazione

Un protocollo a livello di trasporto può anche fornire garanzie di temporizzazione. Per esempio, la garanzia potrebbe essere che ogni bit che il mittente invia alla socket

8

venga ricevuto dalla socket di destinazione non più di un tot di tempo più tardi. Questo tipo di servizio potrebbe interessare le applicazioni interattive in tempo reale.

Abbiamo considerato i servizi di trasporto che una rete di calcolatori potrebbe offrire in generale ora entriamo più nello specifico e vediamo il tipo di supporto alle applicazioni fornito da Internet. Internet mette a disposizione delle applicazioni due protocolli di trasporto: UDP e TCP, che offrono servizi differenti.

Servizi di TCP

Quando un’applicazione invoca TCP come protocollo di trasporto riceve un servizio orientato alla connessione e un servizio di trasferimento affidabile.

TCP fa in modo che client e server si scambino informazioni di controllo a livello di trasporto prima che i messaggi a livello di applicazione comincino a fluire. Questa procedura, detta di handshaking, mette in allerta client e server preparandoli alla partenza di pacchetti. Dopo la fase di handshaking si dice che esiste una connessione TCP tra le socket dei due processi. Tale connessione è full-duplex, nel senso che i due processi possono scambiarsi contemporaneamente messaggi sulla connessione.

I processi comunicanti possono contare su TCP per trasportare i dati senza errori e nel giusto ordine.

Servizi di UDP

UDP è un protocollo di trasporto leggero che non necessita di connessione, quindi nemmeno di handshaking, e fornisce un servizio di trasferimento dati non affidabile. Così quando un processo invia un messaggio tramite la socket UDP, il protocollo non garantisce che questo raggiunga il processo di destinazione.

Possiamo notare però che nella nostra breve descrizione di UDP e TCP sono assenti i riferimenti a garanzie di throughput e temporizzazione, che sono servizi non forniti dagli odierni protocolli di trasporto di Internet.

Abbiamo visto come i processi di rete comunichino tra loro inviando messaggi tra socket. Un protocollo a livello di applicazione definisce come i processi di un’applicazione, in esecuzione su due sistemi periferici diversi, si scambiano i messaggi. In particolare un protocollo a livello di applicazione definisce: i tipi di messaggi scambiati (di richiesta o di risposta), la sintassi dei vari tipi di messaggio, la semantica dei campi (ossia il significato delle informazioni che contengono), le regole per determinare quando e come un processo invia e risponde ai messaggi.

Prenderemo di seguito in considerazione cinque applicazioni di rete: il Web, il trasferimento di file, la posta elettronica, il servizio di directory e le applicazioni P2P.

9

Per primo tratteremo il web non solo perché rappresenta un’applicazione estremamente diffusa ma anche perché il suo protocollo a livello di applicazione, HTTP, è diretto e facile da comprendere.

WEB e HTTP

HTTP protocollo a livello di applicazione del web, costituisce il cuore del web. Questo protocollo è implementato in due programmi, client e server, in esecuzione su sistemi periferici diversi che comunicano tra loro scambiandosi messaggi HTTP. Il protocollo definisce la lettura dei messaggi sia la modalità con cui client e server si scambiano i messaggi. Prima di vedere nel dettaglio HTTP vediamo alcune terminologie usate nel mondo del web. Una pagina web detta anche documento è costituita da oggetti. Un oggetto è semplicemente un file indirizzabile tramite URL, ad esempio se una pagina web contiene testo in HTML e cinque immagini JPEG, allora nel complesso presenta sei oggetti. Ogni URL ha due componenti: il nome dell’host del server che ospita l’oggetto e il percorso dell’oggetto. Per esempio, l’URL: http://www.someSchool.edu/someDepartement/picture.gif ha www.someSchool.edu come host e /someDepartement/picture.gif come percorso. Un browser web implementa il lato client di HTTP mentre un web service implementa il lato server di HTTP e contiene oggetti web indirizzabili tramite URL. HTTP definisce in che modo i client web richiedono le pagine ai web server e come quest’ultimi le trasferiscono ai client. HTTP utilizza TCP come protocollo di trasporto. Il client HTTP per prima cosa stabilisce una connessione TCP con il server. Una volta stabilita, il client invia richieste e riceve risposte HTTP tramite la propria interfaccia socket, analogamente il server riceve richieste e invia messaggi di risposta attraverso la propria interfaccia socket. Quando un client ha mandato un messaggio alla sua interfaccia socket, questo non è più in suo possesso, ma si trova nelle mani di TCP.

In molte applicazioni per Internet client e server comunicano per un lungo periodo di tempo, con il client che inoltra una serie di richieste e il server che risponde a ciascuna di esse. Quando tale interazione client-server ha luogo su TCP, gli sviluppatori dell’applicazione devono decidere se ciascuna coppia richiesta/risposta deve essere inviata su una connessione TCP separata o devono essere inviate tutte sulla stessa connessione TCP. Nel primo approccio si dice che l’applicazione usa connessioni non persistenti, mentre nel secondo caso usa connessioni persistenti. HTTP di default usa connessioni persistenti.

HTTP CON CONNESSIONI NON PERSISTENTI

Seguiamo passo dopo passo il trasferimento di una pagine web dal server al client nel caso di connessioni non persistenti. Supponiamo che la pagina consista di un file

10

HTML principale e dieci immagini JPEG, e che tutti gli undici oggetti risiedano sullo stesso server. Ipotizziamo che l’URL del file HTML principale sia: http:// www.someSchool.edu/someDepartement/home.index ecco cosa avviene:

1. Il processo client HTTP inizializza una connessione TCP con il server www.someSchool.edu sulla porta 80 che è la porta di default per HTTP. Associate alla connessione TCP ci saranno una socket per il client e una per il server

2. Il client HTTP tramite la propria socket invia al server un messaggio di richiesta HTTP che include il percorso /someDepartement/home.index

3. Il processo server HTTP riceve il messaggio di richiesta attraverso la propria socket associata alla connessione TCP, recupera l’oggetto /someDepartement/ home.index, lo incapsula in messaggio di risposta HTTP che viene inviato al client attraverso la socket

4. Il processo server comunica a TCP di chiudere la connessione che però non la chiude fine a quando non è sicuro che il client abbia ricevuto integro il messaggio di risposta

5. Il client HTTP riceve il messaggio di risposta e la connessione TCP termina. Il messaggio indica che il file incapsulato è un file HTML. Il client estrae il file dal messaggio di risposta, esamina il file HTML e trova i riferimenti a 10 oggetti JPEG e ripete i primi quattro passaggi per ognuno dei riferimenti JPEG.

Quando il browser riceve la pagina web la visualizza all’utente. Due browser diversi possono interpretare la stessa pagina web secondo modalità leggermente diverse. HTTP non ha niente a che fare con l’interpretazione di una pagina web esso definisce soltanto il protocollo di comunicazione tra il programma HTTP client e il programma HTTP server.

HTTP CON CONNESSIONI PERSISTENTI

Le connessioni persistenti riportano alcuni limiti: ad esempio per ogni oggetto richiesto occorre stabilire e mantenere una nuova connessione. Ciò pone un grave onere sul web server, che può dover servire contemporaneamente richieste provenienti da centinai di diversi client. Nelle connessioni persistenti il server lascia la connessione TCP aperta dopo l’invio di una risposta, per cui le richieste e le risposte successive tra gli stessi client e server possono essere trasmesse sulla stessa connessione. In generale, il server HTTP chiude la connessione quando essa rimane inattiva per un dato lasso di tempo.

11

Le specifiche di HTTP includono la definizione dei formati dei messaggi HTTP, di richiesta e di risposta.

Osservandolo accuratamente notiamo innanzitutto che il messaggio è scritto in ASCII, in modo che l’utente sia in grado di leggerlo. In generale i messaggi di richiesta possono essere costituiti da un numero indefinito di righe, anche una sola. La prima riga è detta riga di richiesta e quelle successive righe di intestazione. La riga di richiesta contiene tre campi il campo metodo (GET), il campo URL, e il campo versione di HTTP (HTTP/1.1). Il campo metodo può assumere diversi valori tra cui GET, POST, HEAD, PUT e DELETE. La maggioranza dei messaggi di richiesta usa il metodo GET. Nell’esempio il browser che implementa la versione HTTP/1.1 sta richiedendo l’oggetto /somedir/page.html. Consideriamo ora le righe di intestazione dell’esempio. La riga Host specifica l’host su cui risiede l’oggetto. Includendo la linea di intestazione Connection: close, il browser sta comunicando al server che non si deve occupare di connessioni persistenti, ma vuole che questi chiuda la connessione dopo aver inviato l’oggetto richiesto. La riga User-agent: specifica il tipo di browser che sta effettuando la richiesta al server. Infine Accept- language indica che l’utente preferisce ricevere una versione in francese dell’oggetto se disponibile, altrimenti il server dovrebbe inviare la versione di default. HEAD viene usato dal client quando non vuole scaricare l’intero oggetto ma solo alcune informazioni. POST è usato per fornire degli input al server da utilizzare per un particolare oggetto.PUT è utilizzato per memorizzare un oggetto nel server mentre DELETE per cancellarlo.

Presentiamo ora un tipico messaggio di risposta HTTP che potrebbe rappresentare la risposta al messaggio di richiesta dell’esempio precedente.

Analizzando in dettaglio questo messaggio di risposta, osserviamo tre sezioni: una riga di stato iniziale, sei righe di intestazione e il corpo. Quest’ultimo è il fulcro del messaggio: contiene l’oggetto richiesto (rappresentato da data data data). La riga di stato presenta tre campi: la versione del protocollo, un codice di stato e un corrispettivo messaggio di stato. In questo esempio la riga di stato indica che il server sta usando HTTP/1.1 e che tutto va bene (ossia che il server ha trovato e sta inviando l’oggetto richiesto). Osserviamo ora le righe di intestazione. Il server utilizza la riga Connection: close per comunicare al client che ha intenzione di chiudere la connessione TCP dopo l’invio del messaggio. La riga Date: indica l’ora e la data di invio della risposta HTTP da parte del server. La riga Server: indica che il messaggio è stato generato da un web server Apache. La riga Last-Modified indica l’istante e la data in cui l’oggetto è stato modificato per l’ultima volta. La riga Content-Length:

12

contiene il numero di byte dell’oggetto inviato. La riga Content-Type: indica che l’oggetto nel corpo è testo HTML.

I server HTTP inviano i file richiesti ai client senza memorizzare alcuna informazione di stato a proposito del client. Per cui in caso di ulteriore richiesta dello stesso oggetto da parte dello stesso client, il server procederà nuovamente all’invio, non avendo mantenuto alcuna traccia di quello precedentemente effettuato. Tuttavia è spesso auspicabile che i web server possano autenticare gli utenti. A questo scopo, HTTP adotta i cookie. I cookie consentono ai server di tener traccia degli utenti. Supponiamo che Susan acceda sempre al web con lo stesso browser e contatti per la prima volta il sito di Amazon.com. Quando giunge la richiesta al web server di Amazon il sito crea un identificativo unico e una voce nel proprio database. A questo punto il server risponde alla richiesta HTTP includendo nella risposta Set-cookie: che contiene l’identificativo, supponiamo ad esempio Set-cookie: 1678. Quando il browser di Susan riceve il messaggio di risposta HTTP, vede l’intestazione Set- cookie e aggiunge una riga al file dei cookie che gestisce. Mentre Susan continua a navigare sul sito di Amazon, ogni volta che richiede una pagina web, il suo browser consulta il suo file dei cookie, estrae il suo numero identificativo per il sito e pone nelle richieste HTTP una riga che contiene tale numero. In tale modo è possibile monitorare l’attività di Susan nel sito. Per tale motivo i cookie sono fonte di controversie in quanto possono essere considerati una violazione della privacy dell’utente.

Una web cache, o proxy server, è un’entità di rete che soddisfa richieste HTTP al posto del web server. Il proxy ha una propria memoria su disco (una cache) in cui conserva copie di oggetti recentemente richiesti. Il browser può essere configurato in modo che tutte le richieste HTTP dell’utente vengano innanzitutto dirette al proxy server. Una volta configurato il browser supponiamo per esempio che il browser stia richiedendo l’oggetto http://www.someschool.edu/campus.gif. Ecco che cosa succede.

1. Il browser stabilisce una connessione TCP con il proxy server e invia una richiesta HTTP per l’oggetto specificato

2. Il proxy controlla la presenza di una copia dell’oggetto memorizzata localmente. Se l’oggetto è presente, il proxy lo inoltra all’interno di un messaggio di risposta HTTP al browser.

3. Se invece la cache non dispone dell’oggetto, apre una connessione TCP verso il server di origine; ossia, www.someschool.edu nel nostro caso. Poi il proxy invia al server una richiesta HTTP per l’oggetto. Una volta ricevuta tale richiesta il server di origine invia l’oggetto al proxy attraverso un messaggio di risposta HTTP.

13

4. Quando il proxy riceve l’oggetto ne salva una copia nella propria memoria locale e ne inoltra un’altra copia al browser all’interno di un messaggio di risposta HTTP.

Si noti che il browser è contemporaneamente client e server: quando riceve richieste dal browser e gli invia risposte è server mentre quando invia richieste e riceve risposte da un server di origine agisce da client.

Sebbene il web caching riduca i tempi di risposta percepiti dall’utente, introduce un nuovo problema: l’oggetto ospitato nel web server potrebbe esser stato modificato rispetto alla copia nel client. Fortunatamente HTTP presenta un meccanismo che permette alla cache di verificare se i suoi oggetti sono aggiornati. Questo meccanismo è chiamato get condizionale. Un messaggio di richiesta HTTP viene detto messaggio di GET condizionale se contiene il metodo GET e include una riga di intestazione If- modified-since:. Quando un proxy server salva l’oggetto nella cache locale memorizza anche la data di ultima modifica dell’oggetto. Successivamente quando tale oggetto presente nel proxy viene richiesto da un altro browser, il proxy effettua un controllo di aggiornamento inviando un GET condizionale. Questo GET condizionale presenta la riga if-modified-since che riporta la data di ultima modifica. Con questo GET condizionale il proxy sta comunicando al server di inviare l’oggetto solo se è stato modificato rispetto alla data specificata. Nel caso l’oggetto non è stato modificato il web server invia un messaggio di risposta che non contiene l’oggetto ma dice soltanto che esso non è stato modificato e così il proxy server può procedere a inoltrare la copia dell’oggetto presente in cache.

TRASFERIMENTO DI FILE: FTP

In una tipica sessione FTP, l’utente utilizza un host (locale) per trasferire file da o verso un host remoto. Per accedere ed essere autorizzato a scambiare informazioni con il file system remoto, l’utente deve fornire un nome identificativo e una password, dopo di che può trasferire file tra i due file system. HTTP e FTP sono protocolli di trasferimento dei file e condividono molto caratteristiche. Per esempio entrambi fanno uso di TCP. Tuttavia, tra le più rilevanti differenze che distinguono questi due protocolli a livello di applicazione, notiamo che FTP utilizza due connessioni TCP parallele dette connessione di controllo e connessione dati. La prima connessione viene utilizzata per inviare informazioni di controllo tra gli host, quali l’identificativo dell’utente e la password mentre la seconda connessione viene usata per il vero e proprio invio di file. Quando un utente inizia una sessione FTP con un host remoto, il lato client di FTP come prima cosa inizializza una connessione di controllo TCP con il lato server sulla porta 21 dove invia l’identificativo dell’utente e la password. Quando il lato server riceve sulla connessione di controllo un comando

14

di trasferimento file inizializza una connessione dati TCP verso il lato client. FTP invia esattamente un file sulla connessione TCP e poi la chiude. Se nel corso della stessa sessione l’utente volesse trasferire un altro file, FTP aprirebbe un’altra connessione dati. Pertanto la connessione di controllo rimane aperta per tutta la durata della sessione utente. I comandi di FTP sono anch’essi scritti in formato ASCII e quindi facilmente leggibili dall’utente. Tra i comandi più comuni troviamo: user username utilizzato per inviare l’identificativo dell’utente al server, pass password utilizzato per inviare la password dell’utente al server, list utilizzato per richiedere al server di inviare un elenco di tutti i file nella directory remota corrente, retr filename usato per recuperare un file dall’attuale directory dell’host remoto, stor filename utilizzato per memorizzare un file nell’attuale directory dell’host remoto.

POSTA ELETTRONICA IN INTERNET

La posta elettronica è presente fin dagli albori di Internet è ne è stata l’applicazione più diffusa durante i suoi anni. I componenti chiave dei sistemi di posta sono: gli user agent, i server di posta e il protocollo SMTP. Per descrivere questi tre componenti prendiamo l’esempio, Alice che invia una messaggio a Bob. Gli user agent (per esempio Outlook e Apple Mail) consentono agli utenti di leggere, rispondere comporre messaggi. Quando Alice ha finito di comporre il messaggio e preme “Invia”, il suo user agent lo invia al server di posta, dove viene posto nella coda di messaggi in uscita. Quando Bob vuole leggere il messaggio il suo user agent lo recupera dalla casella di posta nel suo web server. SMTP rappresenta il principale protocollo a livello di applicazione per la posta elettronica su Internet. Fa uso del servizio di trasferimento dati affidabile TCP per trasferire la mail dal server del mittente a quello del destinatario.

SMTP

Questo protocollo definisce il cuore della posta elettronica. Come detto precedentemente, SMTP trasferisce i messaggi dal mail server del mittente a quello del destinatario. SMTP è assai più vecchio di HTTP e tratta il corpo di tutti i messaggi di posta come semplici ASCII a 7 bit. Questa restrizione oggi è molto penalizzante perché richiede che i dati multimediali binari vengano codificati in ASCII prima di essere inviati e che il messaggio venga decodificato in binario dopo il trasporto. Al fine di illustrare le operazioni base di SMTP, presentiamo uno scenario tipico. Supponiamo che Alice voglia inviare a Bob un semplice messaggio ASCII.

1. Alice invoca il suo user agent per la posta elettronica, fornisce l’indirizzo per la posta di Bob, compone il messaggio e da istruzione all’user agent di inviarlo.

15

2. L’user agent di Alice invia il messaggio al suo mail server, dove viene collocato nella coda dei messaggi

3. Il lato client di SMTP, eseguito sul server di Alice, vede il messaggio nella coda dei messaggi e apre una connessione TCP sulla porta 25 verso un server SMTP in esecuzione sul mail server di Bob

4. Dopo un handshaking, il client SMTP invia il messaggio di Alice sulla connessione TCP

5. Presso il mail server di Bob, il lato server di SMTP riceve il messaggio, che viene posizionato nella casella di Bob pronto per essere lette quando Bob aprirà il suo user agent di posta elettronica.

Confrontiamo brevemente HTTP con SMTP. Entrambi i protocolli vengono usati per trasferire file da un host a un altro. HTTP trasferisce file da un web server a un web client, mentre SMTP trasferisce file da un mail server a un altro e entrambi i protocolli durante i trasferimenti fanno uso di connessioni persistenti. Esistono però alcune differenze. Innanzitutto HTTP è un protocollo pull: qualcuno carica le informazioni su un web server e gli utenti usano HTTP per attirarle a se da server. In particolare la connessione TCP viene inizializzata dalla macchina che vuole ricevere il file. Al contrario, SMTP è sostanzialmente un protocollo push: il mail server di invio spinge i file al mail server in ricezione. In particolare, la connessione TCP viene inizializzata dall’host che vuole spedire il file. Una seconda differenza è che SMTP deve codificare tutto in ASCII a 7 bit mentre HTTP non impone tale vincolo.

Nell’ipotesi che Bob esegua il proprio user agent sul suo PC locale, verrebbe naturale pensare alla collocazione di un mail server anch’esso sul PC locale. Con questo approccio, il mail server di Alice dialogherebbe direttamente con il PC di Bob ma questo dovrebbe rimanere sempre acceso e connesso a Internet al fine di ricevere nuova posta che può giungere in qualsiasi momento. Ecco perché un tipico utente manda in esecuzione uno user agent sul PC locale, ma accede alla propria casella memorizzata su un mail server condiviso con altri utenti e sempre attivo. Questo server è generalmente gestito dall’ISP dell’utente. Tuttavia nel nostro puzzle manca ancora un pezzo. Come fa un destinatario (quale Bob), che esegue un user agent sul proprio PC locale, a ottenere i messaggi che si trovano nel web server del suo provider? Osserviamo che lo user agent di Bob non può usare SMTP per ottenere tali messaggi dato che si tratta di un’operazione di pull, mentre SMTP è un operazione di push. Vengono introdotti allora speciali protocolli di accesso alla posta che permettono di trasferire i messaggi dal mail server di Bob al suo PC locale. Attualmente esistono svariati protocolli che fanno questo, tra cui POP3, IMAP e HTTP. SMTP è utilizzato per trasferire posta dallo user agent del mittente al suo mail

16

server e anche per trasferire posta dal server del mittente a quello del destinatario. Mentre per trasferire la posta dal mail server allo user agent del destinatario viene utilizzato un protocollo di accesso alla posta, quale POP3.

POP3

POP3 è un protocollo di accesso alla posta estremamente semplice. POP3 entra in azione quando lo user agent apre una connessione TCP verso il mail server sulla porta 110. Quando la connessione TCP è stabilita, POP3 procede in tre fasi: autorizzazione, transazione e aggiornamento. Durante la prima fase (autorizzazione) lo user agent invia nome utente e password per autentificare l’utente. Durante la seconda fase (transazione) lo user agent recupera i messaggi. La fase di aggiornamento avviene quando il client ha inviato il comando quit che conclude la sessione POP3. In una transazione POP3 lo user agent invia comandi e il server risponde: +OK per indicare che il precedente comando è andato bene; e –ERR per indicare che qualcosa non ha funzionato nel precedente comando.

IMAP

Con l’accesso tramite POP3, dopo aver scaricato i messaggi sulla macchina locale Bob può creare cartelle nelle quali includere i messaggi scaricati. Queste cartelle create sulla macchina locale non sono però accessibili da Bob accedendo con un altro dispositivo e quindi l’utente preferirebbe mantenere una gestione di cartelle su un server remoto cui accedere poi da differenti calcolatori. Ciò non è permesso tramite POP3 che non fornisce all’utente nessuna procedura per creare e gestire cartelle remote. Per risolvere questo e altri problemi nasce il protocollo IMAP che presenta maggiori potenzialità rispetto a POP3. Un server IMAP associa a una cartella INBOX del destinatario ogni messaggio arrivato dal server. Quest’ultimo può poi spostare il messaggio in una cartella creata dall’utente, leggerlo, cancellarlo e così via.

Posta basata sul Web

È oggi in costante crescita il numero di utenti che inviano posta e accedono alle proprie e-mail tramite un browser web. Grazie a tale servizio lo user agent è un semplice browser web e l’utente comunica con la propria casella remota via HTTP. Quando un destinatario vuole accedere alla propria casella di posta, il messaggio e- mail viene spedito dal server di posta al browser del destinatario usando il protocollo HTTP. Quando un mittente vuole inviare un messaggio di posta elettronica, quest’ultimo viene spedito dal suo browser al suo server di posta tramite HTTP e non più con SMTP. Mentre il server di posta del mittente manda e riceve i messaggi utilizzando ancora SMTP.

17

DNS: IL SERVIZIO DI DIRECTORY DI INTERNET

Le persone possono essere identificate in molti modi: usando il nome di battesimo, il codice fiscale o il numero della patente. Proprio come le persone, anche gli host Internet possono essere identificati in vari modi. I nomi degli host (hostname), quali cnn.com o www.yahoo.com risultano facilmente leggibili per l’uomo ma forniscono poca informazione sulla loro posizione all’interno di Internet. Per tali motivi gli host vengono elaborati anche con i cosiddetti indirizzi IP. Un indirizzo IP consiste di quattro byte, ogni byte viene espresso con un numero decimale compreso tra 0 e 255 ed ha una forma del tipo X.X.X.X dove ogni punto separa ogni byte.

Abbiamo appena visto che esistono due modi per identificare gli host: il nome e l’indirizzo IP. Le persone preferiscono il primo, mentre i router prediligono gli indirizzi IP. Al fine di conciliare i due approcci è necessario è necessario un servizio in grado di tradurre i nome degli host nei loro indirizzi IP. Si tratta del principale compito del DNS di Internet. DNS è una database implementato in una gerarchia di DNS Server e un protocollo a livello di applicazione che consente agli host di interrogare il database. DNS viene comunemente utilizzato da altri protocolli a livello di applicazione tra cui HTTP, SMTP e FTP per tradurre i nomi di host forniti dall’utente in indirizzi IP. Per esempio, consideriamo che cosa succede quando un browser in esecuzione sull’host di un utente richiede l’URL www.someschool.edu/ index.html. Affinché l’host dell’utente sia in grado di inviare un messaggio di richiesta HTTP al web server www.someschool.edu, esso deve come prima cosa ottenere il suo indirizzo IP. Ciò avviene come segue:

1. La stessa macchina dell’utente esegue il lato client dell’applicazione DNS

2. Il browser estrae il nome dell’host, www.someschool.edu e lo passa al lato client dell’applicazione DNS.

3. Il client DNS invia un interrogazione (query) contenente l’hostname a un DNS server.

4. Il client DNS prima o poi riceve una risposta, che include l’indirizzo IP corrispondente all’hostname.

5. Una volta ricevuto l’indirizzo IP dal DNS, il browser può dare inizio a una connessione TCP con quell’indirizzo IP.

Da questo esempio vediamo che il DNS aggiunge un ritardo aggiuntivo, fortunatamente però l’indirizzo IP desiderato si trova spesso nella cache di un DNS server il che aiuta a ridurre il ritardo medio del servizio. Oltre alla traduzione degli hostname in indirizzi IP, il DNS mette a disposizione altri importanti servizi.

18

host aliasing. Un host dal nome complicato può avere uno o più sinonimi (alias). Per esempio relay1.west-coast.enterprise.com potrebbe avere due sinonimi più semplici quali enterprise.com e www.enterprise.com . In questo caso si dice che relay1.west-coast… è un hostname canonico. Il DNS può essere invocato da un’applicazione per ottenere l’hostname canonico di un sinonimo, così come l’indirizzo IP dell’host.

mail server aliasing. Per ovvi motivi è auspicabile che gli indirizzi di posta siano facili da ricordare. Tuttavia l’hostname canonico del server di posta potrebbe essere molto difficile da ricordare e per questo vengono usati dei sinonimi. Un’applicazione di posta può invocare il DNS per ottenere il nome canonico di un sinonimo fornito.

distribuzione del carico di rete. I siti con molto traffico vengono replicati su più server e ciascuno di questi viene eseguito su un host diverso e presenta un indirizzo IP differente. Nel caso di web server replicati, va dunque associato a ogni hostname canonico un insieme di indirizzi IP. Quando i client effettuano una query DNS per un nome associato a un insieme di indirizzi, il server risponde con l’intero insieme di indirizzi, ma ne varia l’ordinamento a ogni risposta. Dato che generalmente un client invia il suo messaggio di richiesta HTTP al primo indirizzo IP elencato nell’insieme, la rotazione DNS distribuisce il traffico sui server replicati.

Vediamo adesso come funziona il DNS, analizziamo quindi il servizio di traduzione da hostname a indirizzo IP. Supponiamo che una certa applicazione (browser web ecc.) in esecuzione sull’host di un utente abbia bisogno di tradurre un hostname in indirizzo IP. L’applicazione invocherà il lato client del DNS, specificando l’hostname da tradurre. Il DNS sull’host invia un messaggio (query) sulla rete. Tutte le query e i messaggi di risposta vengono inviati all’interno di datagrammi UDP. Dopo un po’ di tempo, il client DNS sull’host dell’utente riceve un messaggio di risposta contenente la corrispondenza desiderata, che viene poi passata all’applicazione che ne ha fatto richiesta. Il DNS appare così come una scatola nera che fornisce un servizio di traduzione semplice e diretta. In realtà questa scatola è formata da un gran numero di DNS server sparsi in tutto il mondo e da un protocollo a livello di applicazione che specifica la comunicazione tra DNS server e host richiedenti. Il DNS utilizza un grande numero di server, organizzati in maniera gerarchica e distribuiti nel mondo. Nessun DNS server ha le corrispondenze per tutti gli host in Internet, che sono invece distribuite tra tutti i DNS server. Approssimativamente esistono tre classi di DNS server: i root server, i top-level

19

domain (TLD), e i server autoritativi, organizzati in una gerarchia. Supponiamo che un client DNS voglia determinare l’indirizzo IP relativo all’hostname www.amazon.com. Per fare ciò, il client dapprima contatta un root server, che gli restituisce uno o più indirizzi IP relativi al server TLD per il dominio com. Quindi contatta uno di questi server TLD, che gli restituisce uno o più indirizzi IP del server autoritativo per amazon.com . Infine contatta uno di questi server autoritativo per amazon.com che gli restituisce l’indirizzo IP dell’hostname www.amazon.com. Esiste un altro importante tipo di DNS, detto DNS server locale, che non appartiene alle classi prima citate ma è comunque importante nell’architettura DNS. Ciascun ISP, come un università, un’azienda, ha un DNS server locale. Un DNS server locale è generalmente vicino all’host. Quando un host effettua una richiesta DNS, la query viene inviata al DNS server locale, che opera da proxy e inoltra la query alla gerarchia dei DNS server. L’host dapprima invia una richiesta DNS al proprio server locale contenente l’hostname da tradurre. Il server locale inoltra il messaggio di richiesta a un root server. Quest’ultimo prende note del dominio e restituisce al server locale un elenco di indirizzi IP per i TLD server responsabili di quel dominio. Il server locale rinvia quindi il messaggio di richiesta a uno di questi Top Level Domain server che risponde con l’indirizzo IP di un server autoritativo per quel suffisso, a questo punto il DNS server locale rimanda il messaggio di richiesta direttamente al server autoritativo che gli risponde dandogli l’IP dell’hostname.

Fino a questo momento abbiamo ignorato il DNS caching. In verità, il DNS sfrutta il caching per migliorare i tempi e per ridurre il numero di messaggi DNS che rimbalzano su Internet. L’idea alla base del DNS caching è molto semplice. Il DNS server che riceve una risposta DNS può mettere in cache le informazioni contenute. Se una coppia hostname/indirizzo IP è nella cache di un DNS server e giunge al server un’altra richiesta con lo stesso hostname, il DNS può fornire l’indirizzo IP desiderato anche se non è autoritativo per tale indirizzo. Un DNS server può memorizzare in cache gli indirizzi IP dei TLD server, aggirando così i root server nella catena delle richieste.

I server che implementano il database distribuito DNS memorizzano i cosiddetti record di risorsa, tra cui quelli che forniscono le corrispondenze tra nomi e indirizzi. Un record di risorsa contiene i seguenti campi (Name, Value, Type, TTL). TTL determina quando una risorsa vada rimossa dalla cache. Il significato di Name e Value dipende da Type:

• Type=A, allora Name è il nome dell’host e Value è il suo indirizzo IP.

• Type=NS, allora Name è un dominio e Value è l’hostname del DNS server autoritativo che sa come ottenere gli indirizzi IP.

20

• Se Type=CNAME, allora Value rappresenta il nome canonico per il sinonimo Name. Questo record può fornire agli host richiedenti il nome canonico relativo a un hostname.

• Se Type=MX, allora Value è il nome canonico di un mail server che ha il sinonimo Name. Questo tipo di record permette agli hostname dei mail server di avere sinonimi semplici.

Messaggi DNS

Gli unici due tipi di messaggi DNS: le query e i messaggi di risposta, presentano lo stesso formato. La semantica dei messaggi DNS è la seguente:

• abbiamo un campo identificazione di 16 bit che identifica le richieste. Tale identificatore viene copiato nei messaggi di risposta a una richiesta, consentendo al client di far corrispondere le risposte ricevute con le query inviate

• troviamo poi il campo flag. i cui bit in base a come vengono settati indicano se il messaggio è una richiesta o una risposta, in caso di messaggio di risposta un bit viene settato per definire se il DNS server è autoritativo, un ulteriore bit viene impostato quando il client desidera che il DNS server effettui ricorsione quando non dispone del record.

• la sezione delle domande contiene un campo nome con il nome che sta per essere richiesto e, un campo tipo che indica il tipo della domanda sul nome.

• in una risposta proveniente da DNS server, la sezione delle risposte contiene i record di risorsa relativi al nome originariamente richiesto.

• la sezione autoritativa contiene i record di altri server autoritativi

• la sezione aggiuntiva riporta altri record che danno informazioni utili

APPLICAZIONI PEER-TO-PEER

Tutte le applicazioni descritte fino adesso: il Web, la posta elettronica, il DNS e il FTP utilizzano un’architettura client-server con una significativa dipendenza da un’infrastruttura di server sempre attivi. Nell’architettura peer-to-peer questa dipendenza è minima o del tutto assente. Ci sono, invece, coppie di host connessi in modo intermittente, chiamati peer, che comunicano direttamente l’uno con l’altro. I peer sono host controllati dagli utenti. In una distribuzione di flie client-server, il server deve inviare una copia del file a ciascun peer, ponendo un enorme fardello sul

21

server. In una distribuzione di file P2P ciascun peer può redistribuire agli altri qualsiasi porzione del file abbia ricevuto, aiutando in questo il server nel processo di distribuzione. Nell’architettura P2P il tempo di distribuzione è sempre minore di quello dell'architettura client-server.

CAPITOLO 3: LIVELLO DI TRASPORTO

Abbiamo già visto il ruolo del livello di trasporto e i servizi che esso fornisce ai livelli limitrofi. Mentre un protocollo a livello di trasporto mette a disposizione una comunicazione logicatra processi applicativi di host differenti, un protocollo a livello di rete fornisce comunicazione logica tra host. I protocolli a livello di trasporto sono implementati nei sistemi periferici, ma non nei router della rete. Internet, ma più in generale una rete TCP/IP, mette a disposizione del livello di applicazione due diversi protocolli. Uno è UDP che fornisce alle applicazioni un servizio non affidabile e non orientato alla connessione, l’altro è TCP che offre un servizio affidabile e orientato alla connessione. D’ora in avanti chiameremo segmento il pacchetto a livello di trasporto. UDP e TCP forniscono servizio di multiplexing e demultiplexing a livello di trasporto, come vedremo tra poco.UDP e TCP forniscono, inoltre, un controllo d’integrità includendo campi per il riconoscimento di errori nelle intestazioni dei propri segmenti. Questi due servizi sono gli unici offerti da UDP. TCP invece offre alle applicazioni diversi servizi aggiuntivi. Innanzitutto fornisce un trasferimento dati affidabile. TCP fornisce anche il controllo di congestione, in pratica evita che le connessioni TCP intasino i collegamenti e i router tra gli host comunicanti con un’eccessiva quantità di traffico. Questo risultato viene raggiunto regolando la velocità alla quale il lato mittente della connessione TCP immette traffico in rete.

MULTIPLEXING E DEMULTIPLEXING

In questo paragrafo analizzeremo il multiplexing e il demultiplexing, cioè come il servizio di trasporto da host a host fornito dal livello di rete possa diventare un servizio di trasporto da processo a processo per le applicazioni in esecuzione sugli host. Nell’host destinatario il livello di trasporto riceve segmenti dal livello di rete. Il livello di trasporto ha il compito di consegnare i dati di questi segmenti al processo applicativo appropriato in esecuzione nell’host. Innanzitutto ricordiamo che un processo può gestire una o più socket, attraverso cui i dati fluiscono dalla rete all’applicazione e viceversa. Di conseguenza il livello di trasporto nell’host di ricezione non trasferisce i dati direttamente ad un processo ma a una socket che fa da intermediario. In ogni dato istante possono esserci più socket nell’host di ricezione (caso in cui ci sono più processi attivi) e ciascuna avrà un identificatore univoco.

22

Ciascun segmento a livello di trasporto ha vari campi che permettono all’host in ricezione di indirizzare il segmento verso la socket più appropriata. L’host ricevente esamina questi campi per identificare la socket di ricezione e quindi vi dirige il segmento. Il compito di trasportare i segmenti a livello di trasporto verso la giusta socket viene detto demultiplexing. Il compito di radunare frammenti di dati da diverse socket sull’host di origine e incapsulare ognuno con intestazioni (che serviranno poi per fare il demultiplexing) per creare dei segmenti e passarli a livello di rete, viene detto multiplexing.

Multiplexing e demultiplexing non orientati alla connessione (UDP)

Alle socket sono assegnati numeri di porta. Supponiamo che un processo nell’Host A, con porta UDP 19157, voglia inviare un blocco di dati applicativo a un processo nell’Host B con porta UDP 46428. Il livello di trasporto che un segmento che include i dati applicativi, i numeri di porta d’origine e di destinazione. Il livello di trasporto passa quindi il segmento al livello di rete, che lo incapsula in un datagramma IP, ed effettua un tentativo best-effort di consegna del segmento all’host di ricezione. Se il segmento arriva all’host di ricezione B, il suo livello di trasporto esamina il numero di porta di destinazione del segmento e lo consegna alla propria socket UDP (46428 in questo caso).

Multiplexing e demultiplexing orientati alla connessione (TCP)

Una socket TCP è identificata da quattro valori: indirizzo IP di origine, numero porta di origine, indirizzo IP di destinazione e numero di porta di destinazione. Quando un segmento TCP giunge dalla rete in un host, quest’ultimo utilizza i quattro valori per dirigire il segmento verso la porta socket appropriata (fa demultiplexing). In particolare due segmenti TCP in arrivo, aventi indirizzi IP di origine o numeri di porta di origine diversi, saranno sempre diretti verso socket differenti.

TRASPORTO NON ORIENTATO ALLA CONNESSIONE

Lato mittente, prendiamo i messaggi dal processo applicativo e li passiamo direttamente a livello di rete; lato ricevente, prendiamo i messaggi in arrivo dal livello di rete e li trasferiamo direttamente al processo applicativo. Ma come già visto dobbiamo fare qualcosa in più. Quantomeno il livello di trasporto deve fornire un servizio di multiplexing/demultiplexing al fine di trasferire dati tra il livello di rete e il processo corretto a livello di applicazione. UDP fa praticamente il minimo che un protocollo di trasporto debba fare. A parte la funzione di multiplexing/demultiplexing e una forma di controllo degli errori molto semplice. UDP prende i messaggi dal processo applicativo, aggiunge il numero di porta di origine e di destinazione per il multiplexing/demultiplexing, aggiunge altri due piccoli campi e passa il segmento

23

risultante al livello di rete. Questi incapsula il segmento in un datagramma IP e quindi effettua un tentativo di consegnarlo all’host di destinazione in modalità best- effort. Se il segmento arriva a destinazione, UDP utilizza il numero di porta di destinazione per consegnare i dati del segmento al processo applicativo corretto. Notiamo che in UDP non esiste handshaking tra le entità di arrivo e di ricezione per questo si dice che UDP sia non orientato alla connessione. DNS è un esempio di protocollo a livello applicativo che utilizza UDP. Ci si potrebbe chiedere perché non viene sempre preferito TCP visto che fornisce anche un servizio di trasferimento dati affidabile mentre UDP no. Ci sono vari motivi:

• Uno dei motivi è che quando un processo applicativo passa dei dati a UDP, quest’ultimo li impacchetta in un segmento e li trasferisce subito al livello di rete. TCP invece dispone di un meccanismo di controllo della congestione che ritarda l’invio a livello di trasporto quando i collegamenti diventano eccessivamente congestionati. Le applicazioni in tempo reale ad esempio non sopportano ritardi eccessivi nella trasmissione dei pacchetti mentre tollerano una certa perdita di dati.

• Al contrario di TCP che prima di iniziare il trasferimento effettua handshaking, UDP invece manda subito i dati a livello di rete senza alcun preliminare formale. Pertanto UDP non introduce nessuno ritardo nello stabilire una connessione, motivo per il quale DNS utilizza UDP anziché TCP.

• L’intestazione dei pacchetti TCP aggiunge 20byte, mentre UDP solo 8

I segmenti UDP sono formati da quattro campi per l’intestazione più un campo che contiene il messaggio. Nei primi quattro campi abbiamo: il numero di porta d’origine, il numero di porta di destinazione, la lunghezza che riporta il numero di byte del segmento e un campo checksum che viene utilizzato dall’host ricevente per verificare se sul segmento sono avvenuti errori.

Il checksum UDP serve per il rilevamento degli errori. Viene utilizzato per determinare se i bit del segmento UDP sono stati alterati durante il loro trasferimento da sorgente a destinazione. Lato mittente UDP effettua il complemento a 1 della somma di tutte le parole da 16 bit nel segmento, tale risultato viene posto nel campo checksum. In ricezione si sommano le tre parole iniziali e il checksum. Se non ci sono errori nel pacchetto, l’addizione dara sedici 1… altrimenti se un bit vale 0 sappiamo che c’è almeno un errore nel pacchetto. Sebbene metta a disposizione tale controllo, UDP non fa nulla per risolvere le situazioni di errore. Alcune implementazioni di UDP si limitano a scartare il segmento danneggiato, altre lo trasmettono all’applicazione con un avvertimento.

24

PRINCIPI DEL TRASFERIMENTO DATI AFFIDABILE

Con un canale affidabile a disposizione nessun bit dei dati trasferito è corrotto o va perduto e tutti i bit sono consegnati nell’ordine di invio. Questo è il compito dei protocolli di trasferimento dati affidabile, ciò è reso però difficile dalla possibile inaffidabilità del livello “al di sotto” del protocollo di trasferimento dati. Per esempio, TCP è un protocollo di trasferimento dati affidabile implementato appoggiandosi a un livello di rete (IP) che non è affidabile end-to-end.

Passiamo ora in rassegna una serie di protocolli via via sempre più complessi, per arrivare a un impeccabile protocollo di trasferimento dati affidabile.

Trasferimento dati affidabile su un canale perfettamente affidabile: rdt1.0

Consideriamo il caso più semplice in cui il canale sottostante è completamente affidabile.

Il lato mittente accetta dati dal livello superiore con la chiamata rdt_send(data), crea un pacchetto contenenti i dati con make_pkt(data) e lo invia sul canale. Lato ricevente, rdt raccoglie i pacchetti dal sottostante canale tramite l’evento rdt_rcv (packet), estrae i dati dai pacchetti tramite extract(packet,data) e li passa al livello superiore con l’azione deliver_data(data). In questo semplice protocollo tutti pacchetti fluiscono dal mittente al destinatario con un canale perfettamente affidabile.

Trasferimento dati affidabile su un canale con errori sui bit: rdt2.0

Un modello più realistico del canale sottostante è quello in cui i bit in un pacchetto possono essere corrotti. In una rete di calcolatori, i protocolli di trasferimento dati affidabili basati su ritrasmissioni dei dati sono noti come protocolli ARQ. Per gestire la presenza di errori nei bit, i protocolli ARQ devono avere tre funzionalità aggiuntive:

• Innanzitutto è richiesto un meccanismo che consenta al destinatario di rilevare gli errori sui bit. Come avviene con checksum con trasferimento tramite UDP

• Il mittente deve sapere se il pacchetto sia stato ricevuto correttamente o meno. Il nostro protocollo rdt2.0 manderà pacchetti ACK in caso di notifica positiva o pacchetti NAK in caso di notifica negativa.

• Un pacchetto ricevuto con errori sarà ritrasmesso dal mittente.

Il lato mittente di rdt2.0 presenta due stati. In quello di sinistra, il protocollo sta attendendo i dati da raccogliere dal livello superiore. Quando si verifica l’evento rdt_send(data), il mittente crea un pacchetto contenente i dati da inviare e infine

25

non sono stati rilasciati commenti
Questa è solo un'anteprima
3 pagine mostrate su 61 totali
Scarica il documento