2. Il livello applicazione

2.1 Principi delle applicazioni di rete

2.1.1 Architetture delle applicazioni di rete

Lo sviluppatore si occupa di progettare l'architettura dell'applicazione e stabilire la sua organizzazione sui vari sistemi periferici, basandosi su una delle due principali architetture di rete utilizzate: l'architettura client-server o P2P.

Architettura client-server

Nell'architettura client-server vi è un host sempre attivo, chiamato server, che risponde alle richieste di servizio di molti altri host, detti client. Un esempio è un web server che risponde alle richieste dei browser dei clienti. Tra le più note applicazioni con architettura client-server ci sono il Web, il trasferimento dei file con FTP, Telnet e la posta elettronica.
In questa architettura i client possono avere un indirizzo dinamico, si possono disconnettere temporaneamente e non comunicano direttamente tra loro, mentre il server dispone di un indirizzo IP fisso e noto, che permette ai client di contattare il server in qualsiasi momento, inviandogli un pacchetto. Dato che un singolo host, che esegue un server, non sarebbe in grado di rispondere a tutte le richieste dei suoi client, nelle architetture client-server si usano spesso i data center, che ospitano molti host creando un potente server virtuale, ma che devono essere costantemente alimentati e tenuti sotto controllo. Alcuni esempi sono i motori di ricerca (es Google e Bing), il commercio elettronico (es Amazon e eBay), la posta elettronica basata sul Web (es Gmail) ed il social networking (es Instagram e Facebook).

Architettura P2P

In un’architettura P2P non è presente un server sempre attivo perché sfrutta la comunicazione diretta tra coppie di host, chiamati peer (ossia pari), collegati in modo intermittente (solo quando ce n'è bisogno). Dato che i peer sono solitamente i computer degli utenti, che comunicano senza passare per un server specializzato, l'architettura viene detta peer-to-peer. Alcuni esempi sono le applicazioni di condivisione file (es BitTorrent) e telefonia/videoconferenza su Internet (es Skype).
Uno dei punti di forza dell'architettura P2P è la sua scalabilità perché aggiunge capacità di servizio al sistema, rispondendo alle richieste di altri peer. Nonostante siano economicamente convenienti (non ci sono data center), sono difficili da gestire in termini di sicurezza, prestazioni e affidabilità.

Architettura ibrida (client-server e P2P)

Molte applicazioni di messaggistica istantanea utilizzano un'architettura ibrida, infatti utilizzano i server per tenere traccia degli indirizzi IP degli utenti, ma i messaggi tra utenti sono inviati direttamente tra gli host, senza passare attraverso server intermedi. Stessa cosa accade con Skype che utilizza il server solamente per conoscere gli indirizzi dell'host remoto.

Cloud computing

Insieme di tecnologie che permettono di memorizzare, archiviare e/o elaborare dati (con CPU o software) tramite l'utilizzo di risorse distribuite e virtualizzate in rete. La creazione di una copia di sicurezza (backup) è automatica e l'operarività si trasferisce tutta online. I dati sono memorizzati in server farm, generalmente localizzate nei paesi di origine del service provider.

2.1.2 Processi comunicanti

Un processo è un programma in esecuzione su di un host. All'interno dello stesso host, due processi comunicano utilizzando schemi interprocesso (definiti dal SO). I processi su due host differenti comunicano scambiandosi messaggi attraverso la rete. Il processo client crea ed invia i messaggi nella rete, mentre il processo server attende di essere contattato e, quando previsto, invia messaggi di risposta.
Le applicazioni con architettura P2P hanno processi client e processi server.

Interfaccia tra il processo e la rete

La maggior parte delle applicazioni consiste di 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.
Un processo lo possiamo immaginare come una casa ed il socket come una porta. Quando un processo invia un messaggio, lo fa uscire dalla propria "porta", che è il socket. Il processo presuppone l'esistenza di un'infrastruttura esterna che trasporterà il messaggio attraverso la rete fino alla "porta" del processo di destinazione, il quale opera sul messaggio.

Una il socket è l’interfaccia tra il livello di applicazione e il livello di trasporto all’interno di un host. Possiamo parlare anche di API, che sono un processo attraverso il quale due software scambiano dati, tra l'applicazione e la rete.
Il progettista può scegliere il protocollo di trasporto, che non sempre è possibile, e a volte determinare alcuni parametri a livello di trasporto. Dopo ciò si costruisce l’applicazione usando i servizi del livello di trasporto forniti dal protocollo.

Indirizzamento

Affinché un processo su un host invii un messaggio a un processo su un altro host, il mittente deve identificare il processo destinatario. Per identificare tale processo è necessario specificare due informazioni, ovvero l'indirizzo dell'host e un identificatore del processo ricevente sull’host di destinazione. Tale identificatore comprende l'indirizzo IP, che è un numero univoco di 32 bit che identifica a chi è rivolto il messaggio, ed i numeri di porta, per identificare la socket che deve ricevere il dato. Questo serve perché sull'host di destinazione potrebbero essere in esecuzione molte applicazioni di rete. Alle applicazioni più note sono stati assegnati numeri di porta specifici, come i server web (HTTP) con la porta 80 ed i Mail server con la 25.

Protocolli a livello di applicazione

Un protocollo a livello di applicazione definisce:

• Tipi di messaggi scambiati, ad esempio messaggi di richiesta e di risposta
• Sintassi dei tipi di messaggio: quali sono i campi nel messaggio e come sono descritti
• Semantica dei campi, ovvero significato delle informazioni nei campi
• Regole per determinare quando e come un processo invia e risponde ai messaggi

I protocolli di pubblico dominio sono definiti nelle RFC della IETF e consentono l'interoperabilità, come ad esempio HTTP E SMTP. I protocolli proprietari sono ad esempio Skype.

2.1.3 Servizi di trasporto disponibili per le applicazioni

Quando si progetta un'applicazione occorre scegliere il protocollo a livello di trasporto più opportuno, valutando i servizi forniti più adeguati per l'applicazione.

Trasferimento affidabile

In una rete di calcolatori i pacchetti possono andare perduti, infatti alcune applicazioni (es audio/video) possono tollerare qualche perdita, ma altre (es il trasferimento di file, messaggistica istantanea, applicazioni finanziarie) richiedono un trasferimento affidabile al 100%. Se un protocollo fornisce questo servizio di consegna garantita dei dati, si dice che fornisce un trasferimento dati affidabile, soprattutto tra i processi in un'applicazione.

Throughput

Dato che più sessioni condividono la banda sul percorso di rete e poiché queste sessioni verranno istituite e rilasciate dinamicamente, il throughput disponibile può fluttuare nel tempo. Alcune applicazioni, ad esempio quelle multimediali, per essere efficaci richiedono un certo throughput minimo per funzionare e vengono dette applicazioni sensibili alla banda. Altre applicazioni, ovvero le applicazioni elastiche, utilizzano il throughput a disposizione (es la posta elettronica e il trasferimento di file).

Temporizzazione

Un protocollo a livello di trasporto può anche fornire garanzie di temporizzazione, che però possono assumere varie forme come quelle per il throughput. Alcune applicazioni interattive (es telefonia Internet e giochi interattivi) per essere realistiche richiedono piccoli ritardi e quindi un tempo breve per la consegna dei dati.

Sicurezza

Un protocollo a livello di trasporto può fornire a un’applicazione uno o più servizi di sicurezza, come ad esempio cifratura, riservatezza, integrità dei dati e autenticazione.

Servizi dei protocolli di trasporto Internet

A livello di trasporto sono disponibili due protocolli: TCP e UDP.

TCP

Il protocollo TCP prevede alcuni servizi:

• Servizio orientato alla connessione: prima che i messaggi a livello applicazione comincino a fluire, TCP fa in modo che client e server si scambino informazioni di controllo a livello di trasporto. Questa procedura è detta di handshaking e serve per preparare il client ed il server alla partenza dei pacchetti. Dopo questa fase c'è una connessione TCP tra le socket dei due processi che è full-duplex, in modo che i processi possano scambiarsi contemporaneamente messaggi sulla connessione.

• Servizio di trasferimento affidabile: permette di trasportare i dati senza errori, senza duplicazioni, senza perdita e nel giusto ordine.

• Viene eseguito un controllo di flusso e viene fornito anche un meccanismo di controllo della congestione, in cui viene "strozzato" il processo d'invio quando la rete è sovraccarica.

• Non offre temporizzazione, garanzie su un'ampiezza di banda minima e, senza SSL, non offre la sicurezza.

Dato che la riservatezza e altre questioni di sicurezza sono diventate critiche per molte applicazioni, è stato sviluppato un elemento aggiuntivo per TCP, ovvero il secure sockets layer (SSL). Questo "arricchimento" a livello applicazione gli rende possibile la cifratura, il controllo dell'integrità dei dati e l'autenticazione end-to-end. Un'applicazione che vuole usare SSL deve includerne il codice sia sul lato client sia sul lato server dell’applicazione. SSL possiede delle proprie API per le socket e i dati passano da esse quando devono essere eseguite delle operazioni per rendere TCP più sicuro.

UDP

UDP è un protocollo di trasporto leggero, senza connessione (quindi non necessita di handshaking) e fornisce un servizio di trasferimento dati non affidabile. Quando un processo invia un messaggio tramite la socket UDP, non si ha garanzia che questo raggiunga il processo di destinazione o che giunga in ordine.
Non garantisce un meccanismo di controllo della congestione, temporizzazione, ampiezza di banda minima e sicurezza.
Questo protocollo, essendo leggero, è molto utilizzato per lo streaming o per i videogiochi online, perchè anche se si perdesse qualche pacchetto non comporterebbe gravi conseguenze.

2.2 Web e HTTP

HTTP (hypertext transfer protocol) è un protocollo a livello di applicazione del Web.
Una pagina web è costituita da oggetti, un oggetto può essere un file HTML, un'immagine JPEG, un'appletoJava, un file audio, ...
Una pagina web è formata da un file base scritto tramite l'Hypertext Markup Language (HTML), che solitamente include diversi oggetti referenziati. Ogni oggetto è referenziato da uno Uniform Resource Locator (URL), il quale ha due componenti.

Esempio di URL: $\underset{\text{nome dell’host}}{\underbrace{www.someschool.edu}}$/$\underset{\text{nome del percorso}}{\underbrace{someDept/home.html}}$

Un browser web (come Explorer o Firefox) implementa il lato client HTTP che richiede, riceve e visualizza gli oggetti del Web, mentre un web server, che implementa il lato server di HTTP, ospita oggetti web, indirizzabili tramite URL (es Apache), e li invia in risposta a una richiesta. HTTP definisce in che modo i client web richiedono le pagine ai web server e come questi ultimi le trasferiscono ai client.

HTTP utilizza TCP come protocollo di trasporto. Il client HTTP inizializza la connessione TCP con il server creando una socket, che è la porta tra un processo e la sua connessione TCP (in questo caso la porta è la 80). Non appena il server web (server HTTP) accetta la connessione TCP dal browser (client HTTP), esso gli invia richieste e riceve risposte HTTP (ovvero messaggi HTTP) tramite la propria interfaccia socket, stessa cosa per il server. Successivamente la connessione TCP verrà chiusa.
Dato che HTTP è un protocollo stateless (senza stato), il server non mantiene informazioni sulle richieste fatte dal client. I protocolli che mantengono lo stato sono complessi perché bisogna memorizzare gli stati precedenti.

2.2.2 Connessioni persistenti e non persistenti

HTTP con connessioni non persistenti

Supponiamo che avvenga un trasferimento di una pagina web dal server al client e che tale pagina consista di un file HTML principale e di 10 immagini JPEG, tutti gli undici oggetti risiedono sullo stesso server.
Ipotizziamo che l’URL del file HTML principale sia: http://www.someschool.edu/someDepartment/home.index

Ecco cosa avviene:

1. Il processo client HTTP inizializza una connessione TCP con il server HTTP (processo) a www.someSchool.edu sulla porta 80. Il server HTTP all'host www.someSchool.edu in attesa di una connessione TCP alla porta 80 "accetta" la connessione e avvisa il client.
2. Il client HTTP, tramite la propria socket, trasmette un messaggio di richiesta (con l'URL) nella socket della connessione TCP. Il messaggio indica che il client vuole l'oggetto someDepartment/home.index.
3. Il server HTTP riceve il messaggio di richiesta attraverso la propria socket associata alla connessione, forma il messaggio di risposta che contiene l'oggetto richiesto, recuperando /someDepartment/home.index dalla memoria, incapsulandolo in un messaggio di risposta HTTP e inviandolo al client attraverso la socket.
4. Il server HTTP chiude la connessione TCP, ma non la termina finché non è certo che il client abbia ricevuto integro il messaggio di risposta.
5. Il client HTTP riceve il messaggio di risposta che contiene il file html e visualizza il documento html. Esamina il file HTML e trova i riferimenti a 10 oggetti JPEG.
6. I passi 1-5 sono ripetuti per ciascuno dei 10 oggetti JPEG

Nelle connessioni non persistenti ogni connessione TCP viene chiusa dopo l’invio dell’oggetto da parte del server, quindi ognuna trasporta soltanto un messaggio di richiesta ed un messaggio di risposta. In questo caso sono state generate 11 connessioni TCP, ma alcuni browser possono gestirne dalle 5 alle 10 in parallelo.

Tempo di risposta

Il Round-Trip Time (RTT) è il tempo di propagazione di andata e ritorno tra due host (es tempo impiegato da un piccolo pacchetto per andare dal client al server e tornare al client). RTT include i ritardi di propagazione, di accodamento nei router e nei commutatori intermedi nonché di elaborazione del pacchetto.

Quando un utente fa click su un collegamento ipertestuale, il browser inizializza una connessione TCP con il web server. Ciò comporta un handshake a tre vie dove il client invia un piccolo segmento TCP al server, il quale manda conferma per mezzo di un piccolo segmento TCP. Il client poi dà conferma di ritorno al server. Le prime due parti dell’handshake a tre vie richiedono un RTT, invece con la terza parte (conferma) il client ci combina un messaggio di richiesta HTTP e lo invia tramite la connessione TCP. Quando il messaggio di richiesta arriva al server, quest’ultimo inoltra il file HTML sulla connessione TCP e ciò consuma un altro RTT. Pertanto il tempo di risposta totale è di circa due RTT, sommati al tempo di trasmissione da parte del server del file HTML.

HTTP con connessioni persistenti

Le connessioni non persistenti presentano diversi svantaggi:

• per ogni oggetto occorre stabilire e mantenere una nuova connessione, oltre che allocare un buffer e mantenere variabili TCP sia nel client che nel server, il quale potrebbe dover servire contemporaneamente molte richieste.
• per ciascun oggetto poi si subisce un ritardo di consegna di due RTT, uno per stabilire la connessione e uno per richiedere e ricevere un oggetto

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 aperta.
In particolare, non solo il server può inviare un’intera pagina web (es il file HTML principale e le 10 immagini) su una sola connessione TCP permanente, ma può anche spedire allo stesso client più pagine web. Queste richieste di oggetti da parte del client possono essere effettuate una di seguito all’altra senza aspettare le risposte delle richieste pendenti (pipelining). Per cui il ritardo di consegna è di un solo RTT per tutti gli oggetti referenziati.
Il server HTTP poi chiude la connessione quando essa rimane inattiva per un dato lasso di tempo (configurabile).

2.2.3 Formato dei messaggi HTTP

I messaggi HTTP sono di due tipi: richiesta e risposta.

Messaggi di richiesta

Un tipico messaggio di richiesta HTTP

Il messaggio è scritto in testo ASCII, ogni riga è seguita da un carattere di ritorno a capo (carriage return) e un carattere di nuova linea (line feed), mentre l'ultima riga è seguita da una coppia di caratteri di ritorno a capo e nuova linea aggiuntivi.
La prima riga è detta riga di richiesta e quelle successive righe di intestazione.

La riga di richiesta presenta tre campi: il campo metodo, il campo URL e il campo versione di HTTP. Il campo metodo può assumere diversi valori, tra cui GET, POST, HEAD, PUT e DELETE (GET è il più usato). In questo esempio il browser, che implementa la versione HTTP/1.1, sta richiedendo l'oggetto /somedir/page.html.

La riga Host: www.someschool.edu specifica l’host su cui risiede l’oggetto.
Includendo la linea di intestazione Connection: close, il browser sta comunicando al server di chiudere la connessione dopo aver inviato l'oggetto richiesto.
La riga di intestazione User-agent: specifica il tipo di browser che sta effettuando la richiesta al server, in questo caso Mozilla/5.0, un browser Firefox.
Infine, Acceptlanguage: indica che l’utente preferisce ricevere una versione in francese dell’oggetto se disponibile, altrimenti il server dovrebbe inviare la versione di default.

Dopo le linee di intestazione si trova il corpo dell'entità, che nel caso del GET è vuoto, ma viene utilizzato dal metodo POST. Un client HTTP usa in genere il metodo POST quando l’utente riempie un form (es input nel motore di ricerca), in questo caso il corpo contiene ciò che l'utente ha immesso nei campi del form.
I form HTML spesso usano il metodo GET e includono i dati immessi (l'input del form) nell'URL richiesto. Per esempio se i dati immessi fossero scimmie e banane, allora l'URL avrà la struttura: www.somesite.com/animalsearch?scimmie&banane.
Oltre ai metodi GET e POST esiste anche il metodo HEAD. Quando un server riceve una richiesta con il metodo HEAD, risponde con un messaggio HTTP, ma tralascia gli oggetti richiesti (es usato dagli sviluppatori per verificare la correttezza del codice prodotto).
In HTTP/1.1 sono presenti anche il metodo PUT, che permette di includere il file (un oggetto) nel corpo dell'entità e lo invia al percorso specificato, ovvero una directory su uno specifico web server, come indicato nel campo URL, ed il metodo DELETE che cancella un file (un oggetto), specificato nel campo URL, su un server. Questi due metodi sono spesso disabilitati nei web server per motivi di sicurezza e sono spesso sostituiti dal metodo POST in cui si specifica che cosa aggiungere o cancellare dal server.

Messaggio di risposta HTTP

Un esempio di risposta HTTP al messaggio precedente potrebbe essere la seguente:

Il messaggio comprende tre sezioni: una riga di stato iniziale, sei righe di intestazione e il corpo che contiene l'oggetto richiesto (dati dati dati …).
La riga di stato presenta tre campi: la versione del protocollo, un codice di stato e un corrispettivo messaggio di stato. Alcuni codici di stato con i rispettivi messaggi sono:

• 200 OK

  • La risposta ha avuto successo; l'oggetto richiesto viene inviato nella risposta

• 301 Moved Permanently

  • L'oggetto specificato è stato trasferito; la nuova posizione è specificata nell'intestazione Location : della risposta

• 400 Bad Request

  • Il messaggio di richiesta non è stato compreso dal server

• 404 Not Found

  • Il documento richiesto non si trova su questo server

• 505 HTTP Version Not Supported

  • Il server non supporta la versione richiesta del protocollo HTTP

Il server usa la riga di intestazione 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 creazione e invio, da parte del server, della risposta HTTP. Non si tratta dell’istante in cui l’oggetto è stato creato o modificato per l’ultima volta, ma del momento in cui il server recupera l’oggetto dal proprio file system, lo inserisce nel messaggio di risposta e invia il messaggio.
La riga Server: indica che il messaggio è stato generato da un web server Apache. Essa è analoga alla riga User-agent: nel messaggio di richiesta HTTP.
La riga Last-Modified: indica l’istante e la data il cui l’oggetto è stato creato o modificato per l’ultima volta.
La riga Content-Length: contiene il numero di byte dell’oggetto inviato.
La riga Content-Type: indica che l’oggetto nel corpo è testo HTML. Il tipo dell'oggetto è identificato da questa intestazione e non dall'estensione del file.

2.2.4 Interazione utente-server: i cookie

I server HTTP sono privi di stato e proprio per questo HTTP adotta i cookie, che consentono ai server di tener traccia degli utenti (es autenticazione). La tecnologia dei cookie presenta quattro componenti:

1. Una riga di intestazione nel messaggio di risposta HTTP
2. Una riga di intestazione nel messaggio di richiesta HTTP
3. Un file cookie mantenuto sul sistema terminale dell'utente e gestito dal browser dell'utente
4. Un database sul sito

Supponiamo che Susan acceda sempre a Internet con lo stesso PC e utilizzando Internet Explorer. Visita per la prima volta il sito di Amazon.com. Supponiamo inoltre che in passato abbia già visitato il sito di eBay. Quando giunge la richiesta al web server di Amazon, il sito crea un identificativo unico (ID) e una voce nel proprio database (entry), indicizzata dal numero identificativo.
A questo punto il server risponde al browser di Susan, includendo nella risposta HTTP l’intestazione Set-cookie: che contiene il numero identificativo (es 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, la quale contiene il nome dell’host del server e il numero identificativo nell'intestazione Set-cookie:.
Mentre Susan continua a navigare nel 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 nella richiesta HTTP una riga di intestazione del cookie che include tale numero (es cookie: 1678). In tale modo è possibile monitorare l'attività di Susan nel sito, anche se esso non ne conosce esattamente il nome ma solo l'ID dell'utente (1678). Questo permette ai siti come Amazon di mantenere, per esempio, una lista di tutti i prodotti nel carrello e di acquistarli assieme alla fine della sessione, oppure di suggerire dei prodotti sulla base delle pagine web che ha visitato in passato. Se poi Susan si registra sul sito, fornendo il suo nome completo, l’indirizzo di posta elettronica, un recapito postale e informazioni sulla carta di credito, Amazon può includere queste informazioni nel proprio database e quindi associare il nome di Susan al suo numero identificativo (e a tutte le pagine precedentemente visitate in quel sito).

I cookie possono essere utilizzati anche per memorizzare la carta per gli acquisti e lo stato della sessione dell'utente, ovvero che una volta effettuato il login, anche se si chiude la scheda, non bisognerà effettuarlo nuovamente.

2.2.5 Web caching

Una web cache, nota anche come proxy server, è un'entità di rete che soddisfa le richieste HTTP del client senza coinvolgere il server d'origine. Il proxy ha una propria memoria su disco (una cache) in cui conserva copie di oggetti recentemente richiesti ed il browser di un utente può essere configurato in modo che tutte le richieste HTTP vengano dirette a questo proxy server. Se il dato non è presente in cache, l'oggetto viene richiesto al server d'origine e poi inoltrato al client, salvandolo prima nella propria cache.

Il proxy è sia server, quando fornisce le risposte che trova in cache, sia client, quando deve richiedere l'oggetto al server di origine. Tipicamente il proxy è installato da un ISP (università, aziende o ISP residenziali).
Il web catching è stato sviluppato perché riduce i tempi di risposta alle richieste del client, specie se l'ampiezza di banda tra client e server di origine è molto inferiore rispetto all'ampiezza di banda tra client e proxy, ed anche perché riduce il traffico sul collegamento di accesso a Internet. Grazie alla presenza di cache, Internet consente ai provider "scadenti" di fornire dati con efficacia, ma così fa anche la condivisione di file P2P.

Supponiamo che la dimensione media di un oggetto sia di 100.000 bit (0,1 Mbit) e che i browser dell'ente abbiano una frequenza media di 15 richieste al secondo ai server di origine. Il ritardo dal router istituzionale a qualsiasi server d'origine con il rispettivo ritorno al router istituzionale è di 2 secondi (ritardo Internet), mentre il collegamento tra un router della prima rete a uno della seconda è di 1,5 Mbit/s.

L'intensità di traffico sulla rete LAN è pari a $(15richieste/secondo)\ast (0,1Mbit/richiesta)/(10Mbit/s)=0,15$ (15%).
L'intensità di traffico sul collegamento di accesso (dal router Internet al router dell’ente) vale $(15richieste/secondo)\ast (0,1Mbit/richiesta)/(1,5Mbit/s)=1$ (100%).
Un ritardo di 0,15 su una rete locale può essere trascurato, mentre se si avvicina a 1, come nel collegamento d'accesso, cresce senza limiti.
Il ritardo totale sarà quindi: ritardo di Internet + ritardo di accesso + ritardo delle LAN = 2 s + 1 minuto + qualche ms.

Una possibilità consiste nell'aumentare l'ampiezza di banda del collegamento d'accesso a 10 Mbps. Questo abbasserà l’intensità di traffico sul collegamento di accesso fino a 0,15 (non arrivando al minuto quindi), ma il ritardo totale sarà comunque di circa due secondi. Oltretutto l'ente dovrebbe aggiornare il proprio collegamento a Internet, il che può risultare costoso.

Una soluzione possibile consiste nell'adozione di un proxy nella rete del istituzione. Supponiamo che una percentuale di successo (hit rate) sia del 40%, quindi il 40% delle richieste sarà soddisfatto quasi immediatamente (entro 0,01 s) dalla cache, mentre il restante 60% delle richieste sarà soddisfatto dal server d'origine. Dato che l'utilizzo del collegamento d'accesso si è ridotto al 60%, l'intensità di traffico sul collegamento di accesso è di:
$(0,6\ast 15richieste/secondo)\ast (0,1Mbit/richiesta)/(1,5Mbit/s)=0,6$ che è minore di 1.

Questo determina ritardi trascurabili (10 ms), per cui il ritardo totale è di 2,01 secondi (ovvero ritardo Internet + 10 ms). Il ritardo medio adesso sarà quindi di:
$0,6\ast (2,01secondi)+0,4\ast (0,01secondi)=1,21secondi$. Questo comporta una spesa contenuta perché molti proxy sono software di pubblico dominio che possono essere eseguiti su PC economici.

Supporto HTTP per le cache: GET condizionale

Sebbene il web caching riduca i tempi di risposta percepiti dall’utente, introduce un nuovo problema. Può accadere che l'oggetto nel web server sia stato modificato rispetto alla copia del client (sia esso un proxy o un browser), ma 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 usa il metodo GET e include una riga di intestazione IF-modified-since: < data >, che specifica la data della copia dell'oggetto nella richiesta HTTP. Un esempio può essere il seguente:
Un proxy invia un messaggio di richiesta a un web server per conto del browser richiedente e poi il web server invia al proxy un messaggio di risposta con l'oggetto richiesto.

Il proxy poi inoltra l'oggetto al browser richiedente e pone anche l’oggetto nella cache locale, memorizzando anche la data di ultima modifica di tale oggetto. Quando un altro browser richiederà, per esempio, una settimana più tardi lo stesso oggetto attraverso il proxy, dato che tale oggetto può essere stato modificato nel web server durante la settimana trascorsa, il proxy effettua un controllo di aggiornamento inviando un GET condizionale.

Il valore della riga di intestazione If-modified-since: equivale esattamente, in questo caso, al valore della riga di intestazione Last-Modified: inviata dal server una settimana prima, difatti questo GET condizionale sta comunicando al server di inviare l’oggetto solo se è stato modificato rispetto alla data specificata. Se l'oggetto non è stato modificato durante la settimana, allora il server invia un messaggio al server di tale tipo:

In questo caso il web server invia un messaggio di risposta, ma non include l'oggetto richiesto perché sprecherebbe banda e incrementerebbe il tempo di risposta percepito dall'utente, specie se l'oggetto è grande. La riga di stato 304 Not Modified comunica al proxy che può procedere e inoltrare al browser richiedente la copia dell’oggetto presente in cache.

HTTP/1.0 e HTTP/1.1

HTTP 1.1 non aspetta un ACK di conferma per procedere ad inviare nuovi file, ma ne vengono inviati più alla volta.
HTTP/2 rappresenta un'evoluzione di HTTP, cioè mantiene i metodi HTTP, i codici di stato e la semantica. Il protocollo è focalizzato sulle prestazioni, specificatamente sulla latenza percepita dall'utente e l'utilizzo delle risorse di rete e dei server. L'obiettivo è utilizzare un'unica connessione dai browser ad un sito web. HTTP/2 si basa su SPDY, protocollo di livello applicazione per trasportare contenuti sul web con minima latenza, tramite:

• Multiplexing di flussi: supporta un numero illimitato di flussi su una singola connessione TCP ("allunga la connessione" aumentandone l'efficienza)
• Priorità delle richieste: il client può inviare quante richieste desidera, assegnando a ciascuna una priorità (evita la congestione)
• Compressione dell'header HTTP: diminuisce i byte trasmessi

Framing binario

Nuovo livello di framing binario, responsabile delle modalità di incapsulamento e trasferimento dei messaggi HTTP.
La semantica HTTP è invariata, ma la codifica in transito è differente.
Tutte le comunicazioni HTTP/2 sono suddivise in messaggi e frame più piccoli, ognuno dei quali codificato in formato binario. Sia il client che il server devono utilizzare il nuovo meccanismo di codifica binario per capirsi tra loro: un client HTTP/1.x non comprende un server HTTP/2 e viceversa.

Stream, messaggi, frame

Tutte le comunicazioni vengono eseguite all'interno di una singola connessione TCP che può portare qualsiasi numero di stream bidirezionali di byte. Ogni stream ha un identificativo univoco e le informazioni di priorità opzionali, utilizzate per il trasporto di messaggi. Ogni messaggio è un messaggio HTTP logico, come una richiesta o una risposta, che consiste di uno o più frame. Il frame è la più piccola unità di comunicazione che porta un tipo specifico di dati (intestazioni HTTP, payload del messaggio). I frame di diversi stream possono essere interposti e quindi riassemblati tramite l'identificatore di flusso incorporato nell'intestazione di ciascun frame.

Multiplexing di richieste e di risposte

In HTTP/1.x, se il client desiderava fare più richieste parallele per migliorare le prestazioni, doveva utilizzare più connessioni TCP. Il nuovo livello di framing binario in HTTP/2 rimuove queste limitazioni e consente il multiplexing di richieste e risposte. Il client e il server possono dividere un messaggio HTTP in frame indipendenti, intervallarli e ricomporli all'altro capo.

Priorità degli stream

L'ordine in cui i frame vengono interposti e consegnati sia dal client che dal server influenza le prestazioni. HTTP/2 consente a ciascun stream di avere preso e dipendenza associati:

• Ogni stream può avere assegnato un peso intero compreso tra 1 (più leggero) e 256 (più pesante)
• Ogni stream può avere una dipendenza esplicita su un altro stream
  Il client può costruire e comunicare un "albero di priorità" che esprime come preferirebbe ricevere le risposte. A sua volta, il server può utilizzare queste informazioni per dare priorità all'elaborazione dello stream.

Ogni stream corrisponde ad una richiesta GET del client, perché se il client invia più GET assieme senza numerare ogni stream, il server non saprebbe a quale GET mandare la corrispondente risposta.

Connessione HTTP/2

HTTP/2 non ha più bisogno di più connessioni TCP per eseguire multiplex di stream in parallelo, ogni stream è suddiviso in molti frame che possono essere intervallati e gestiti con priorità diverse. Tutte le connessioni HTTP/2 sono persistenti, e si rende necessaria solo con una connessione per origine.

Server push

Il server può inviare più risposte per una singola richiesta del client. Oltre alla risposta alla richiesta originale, il server può inviare risorse aggiuntive senza che il client debba richiederle esplicitamente. Una tipica applicazione web è costituita da decine di risorse, tutte scoperte dal cliente esaminando il documento fornito dal server.
Ad oggi infatti viene eliminata la latenza supplementare e si lascia che il server invii le risorse in anticipo.

Transport Layer Security (TLS) - HTTP

Protocollo crittografico che permette una comunicazione sicura dalla sorgente al destinatario fornendo: autenticazione, integrità dei dati e confidenzialità. Il funzionamento del protocollo TLS può essere suddiviso in tre fasi principali:

• Negoziazione fra le parti dell'algoritmo da utilizzare
• Scambio delle chiavi e autenticazione
• Cifratura simmetrica e autenticazione dei messaggi
  Estende HTTP inviando tutte le richieste e risposte attraverso una comunicazione cifrata (tramite TLS) sulla porta 443. Es http://www.unitn.it:
• Il browser capisce automaticamente che deve usare TLS
• Inizializza la connessione
• Invia richieste criptate e deve decriptate le risposte che riceve
  Nota: questo cripta solo le informazioni del protocollo HTTP non gli header dei protocolli inferiori, quindi le porte TCP usate e gli indirizzi IP usati sono in chiaro. Recentemente più del 50-70% dei siti usa HTTPS.
  La 'S' aumenta il ritardo di connessione perchè applica la crittografia ai messaggi con TLS e l'inizializzazione di una sessione richiede tempo, ovvero 2RTT + 1RTT per stabilire una connessione TCP. La soluzione è l'utilizzo di protocolli più moderni.

2.3 FTP: file transfer protocol

Trasferimento file a/da un host remoto attraverso il modello client/server, dove il client è il lato che inizia il trasferimento (a/da un host remoto) ed il server è l'host remoto, che utilizza la porta 21. È definito nell'RFC 959.
Il client FTP contatta il server FTP alla porta 21, specificando TCP come protocollo di trasporto. Il client ottiene l'autorizzazione sulla connessione di controllo e cambia la directory remota inviando i comandi sulla connessione di controllo. Quando il server riceve un comando per trasferire un file, apre una connessione dati TCP con il client e dopo il trasferimento di un file, il server chiude la connessione solo della porta 20, mantenendo quella della porta 21. Il server apre una seconda connessione dati TCP per trasferire un altro file sulla stessa connessione di controllo. Dato che FTP utilizza la connessione dati e non la connessione di controllo per trasferire un file parliamo di out-of-band. Il server FTP mantiene "lo stato", ovvero mantiene la stessa directory utilizzata per il trasferimento precedente, non c'è bisogno di autenticarsi nuovamente.

2.4 Posta elettronica in Internet

La posta elettronica è un mezzo di comunicazione asincrono, infatti ogni utente può leggere i messaggi nel momento più opportuno senza doversi coordinare con altri utenti. La posta elettronica presenta tra componenti principali: agente utente, server di posta e il protocollo SMTP.

Agente utente (user agent)

Gli user agent, come Microsoft Outlook e Apple Mail, consentono agli utenti di leggere, rispondere, inoltrare, salvare e comporre i messaggi. Se per esempio Alice vuole mandare un messaggio a Bob, quando ha finito di comporre il messaggio 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 mail server.

Server di posta

Ciascun destinatario, come per esempio Bob, ha una casella di posta (mailbox) collocata in un mail server che gestisce e contiene i messaggi a lui inviati. Per accedere ai messaggi della propria casella Bob deve essere autenticato dal server che lo ospita tramite nome utente e password. Il mail server di Alice deve anche gestire eventuali problemi del server di Bob, infatti se il server di Alice non può consegnare la posta a quello di Bob, la trattiene in una coda di messaggi e cerca di trasferirla in un secondo momento. Se dopo alcuni giorni non si ottiene successo, il server rimuove il messaggio e notifica la mancata consegna al mittente con un messaggio di posta elettronica.

Protocollo SMTP

SMTP è il principale protocollo a livello di applicazione per la posta elettronica su Internet e fa uso del servizio di trasferimento dati affidabile, proprio di TCP, per trasferire la mail dal server del mittente a quello del destinatario. Presenta un lato client, in esecuzione sul mail server del mittente e un lato server, in esecuzione sul server del destinatario. Quando client e server si invertono, SMTP cambia la sua funzione da client a server e viceversa.

Tratta il corpo di tutti i messaggi di posta come semplice ASCII a 7 bit, penalizzando l'invio di allegati come immagini, audio o video, che devono prima essere codificati in ASCII e poi decodificati in binario dopo il trasporto. Le operazioni base di SMTP verranno descritte con un esempio:

Supponiamo che Alice voglia inviare a Bob un messaggio ASCII.

1. Alice usa il suo agente utente per comporre il messaggio da inviare a [email protected]
2. L'agente utente di Alice invia il messaggio al server di posta di Alice, dove viene collocato nella coda di messaggi
3. Il lato client SMTP apre una connessione TCP con il server di posta di Bob
4. Dopo un handshaking SMTP, il client SMTP invia il messaggio di Alice sulla connessione TCP
5. Il server di posta di Bob pone il messaggio nella casella di posta di Bob
6. Bob invoca il suo agente utente per leggere il messaggio

Di solito SMTP non usa mail server intermedi per inviare la posta, anche quando i mail server finali sono collocati agli angoli opposti del mondo. La connessione TCP ha luogo direttamente tra questi ultimi, infatti se il mail server del destinatario è spento, il messaggio rimane nel mail server del mittente finchè non verrà inviato. Difatti questo protocollo presenta somiglianze con l'interazione umana faccia a faccia, perché come primo passo il client SMTP fa stabilire a TCP una connessione sulla porta 25 verso il server SMTP e se è inattivo, il client riprova più tardi. Solo dopo aver stabilito la connessione il server e il client effettuano una qualche forma di handshaking a livello applicativo, come le persone che si presentano prima di scambiarsi informazioni. Durante questa fase, il client indica l’indirizzo e-mail del mittente e quello del destinatario, poi invia il messaggio. SMTP può contare sul servizio di trasferimento dati affidabile proprio di TCP per recapitare il messaggio senza errori e, appena non ci sono altri messaggi da inviare, il client ordina a TCP di chiudere la connessione.

Un esempio di trascrizione di messaggi scambiati tra un client SMTP (C) e un server SMTP (S). Il nome dell’host del client è crepes.fr mentre il nome dell’host del server è hamburger.edu. Le righe di testo ASCII precedute da C: sono esattamente quelle che il client invia nella propria socket TCP, mentre le righe precedute da S: sono esattamente quelle che il server invia nella propria socket TCP. La seguente trascrizione inizia appena si stabilisce la connessione TCP:

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: Ti piace il ketchup?
C: Che cosa ne pensi dei cetrioli?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection

Nell’esempio sopra riportato, il client invia un messaggio (“Ti piace il ketchup? Che cosa ne pensi dei cetrioli?”) dal server di posta crepes.fr al server di posta hamburger.edu e, come parte del dialogo, ha inviato cinque comandi: HELO, MAIL FROM, RCPT TO, DATA e QUIT. SMTP richiede che ogni riga termini con i caratteri di ritorno a capo e nuova linea (< CR > e < LF >). Il server invia risposte a ogni comando, e ciascuna presenta un codice di risposta.
SMTP fa uso di connessioni persistenti, se il mail server di invio ha molti messaggi da inviare allo stesso mail server in ricezione, può mandarli tutti sulla stessa connessione TCP. Per determinare la fine del messaggio SMTP usa **< CR >< LF >.< CR >< LF > **

2.4.2 Confronto con HTTP

I protocolli SMTP e HTTP vengono utilizzati per trasferire file da un host a un altro, ma ci sono delle differenze.

• HTTP trasferisce file (chiamati oggetti) da un web server a un web client (solitamente un browser), ma ciascun oggetto è incapsulato nel suo messaggio di risposta. Inoltre è un protocollo pull, ovvero che qualcuno carica informazioni su un web server e gli utenti usano HTTP per attirarle a sé (pull) dal server. In particolare, la connessione TCP viene iniziata dalla macchina che vuole ricevere il file.
• SMTP trasferisce file (messaggi di posta elettronica) da un mail server a un altro, ma più oggetti vengono trasmessi in un unico messaggio. SMTP poi è un protocollo push, ovvero che il mail server di invio spinge (push) i file al mail server in ricezione. In particolare, la connessione TCP viene iniziata dall’host che vuole spedire il file.

Entrambi hanno un'interazione comando/risposta in ASCII, solamente che SMTP deve codificare il messaggio in ASCII a 7 bit, vincolo che HTTP non possiede.

2.4.3 Formati dei messaggi di posta

Il corpo dei messaggi di posta elettronica, formato soltanto da caratteri ASCII, è preceduto da un'intestazione contenente le informazioni di servizio. Tale informazione è contenuta in una serie di righe di intestazione, definite nell’RFC 5322, che sono separate dal corpo del messaggio mediante una riga senza contenuto e che sono diverse dai comandi del paragrafo 2.4.1. Esse sono delle parole chiave seguite da due punti, a loro volta seguiti da un valore (es From: [email protected]).

Vi è poi il Multipurpose Internet Mail Extensions (MIME), uno standard che estende il formato dei messaggi di posta elettronica multimediale e definito dall'RFC 2045, 2056. MIME aggiunge il supporto per codifiche di caratteri diversi dall'ASCII e per la codifica di messaggi (o loro parti) non testuali. Alcune righe aggiuntive nell'intestazione dei messaggi dichiarano il tipo di contenuto MIME.

2.4.4 Protocolli di accesso alla posta

Quando SMTP consegna il messaggio di Alice al mail server destinatario, questo lo colloca nella casella di posta di Bob. Il server di posta di Bob non può risiedere sul suo PC locale perché sennò dovrebbe essere sempre acceso e connesso ad Internet al fine di ricevere nuova posta che può giungere in qualsiasi istante. Per cui si preferisce che l'utente abbia in esecuzione uno user agent sul PC locale, ma acceda alla propria casella memorizzata su un mail server condiviso con altri utenti e sempre attivo, che è generalmente gestito dall'ISP dell'utente (es università o azienda).
Tecnicamente lo user agent di Alice potrebbe spedire i messaggi direttamente al mail server di Bob usando SMTP, ma invece Alice usa il suo mail server perché altrimenti non saprebbe come gestire un mail server di destinazione non raggiungibile. Alice deve dapprima depositare la email nel proprio mail server, che può ripetutamente tentare l’invio del messaggio al mail server di Bob, per esempio ogni trenta minuti, finché questo non diventa operativo. E nel caso in cui il proprio server di posta sia inattivo, Alice può lamentarsi con il proprio amministratore di sistema! L’RFC (documento con informazioni) relativo a SMTP definisce i comandi SMTP per consegnare un messaggio attraverso più server SMTP.

Lo user agent di Bob non può usare SMTP per ottenere i messaggi che si trovano nel mail server del suo provider, questo perché si tratta di un'operazione di pull, mentre SMTP è un protocollo push. Proprio per questo viene introdotto un protocollo di accesso alla posta per trasferire i messaggi dal mail server di Bob al suo PC locale. Alcuni di questi protocolli sono: POP3 (Post Office Protocol), IMAP (Internet mail access protocol) e HTTP

POP3

POP3 è un protocollo di accesso alla posta estremamente semplice e proprio per questo le sue funzionalità sono piuttosto limitate. 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 fase di autorizzazione, lo user agent invia il nome utente (comando user) e password (comando pass) per autenticare l'utente.
Nella seconda fase, la transazione, lo user agent recupera i messaggi, ma può anche marcare i messaggi per la cancellazione, rimuovere i marcatori di cancellazione e ottenere statistiche sulla posta. Per esempio:

• list per ottenere l'elenco dei messaggi in cui ogni numero di messaggio viene visualizzato con la dimensione in byte accanto
• retr per recuperare i messaggi in base al numero, ma non se il messaggio è stato eliminato
• dele per cancellare un messaggio, che altrimenti non verrebbe mai cancellato
• quit per disconnettersi una volta completata la conversazione POP3

Nell fase di aggiornamento, che avviene dopo il comando quit, il server di posta rimuove i messaggi che sono stati marcati per la cancellazione.
In una transazione POP3 lo user agent invia comandi e il server reagisce a ogni comando con una tra due possibili risposte: +OK oppure –ERR.

In questo esempio viene utilizzata la modalità scarica e cancella, in cui lo user agent chiede al server di elencare la dimensione dei messaggi memorizzati, quindi li recupera e li cancella. Una volta finita la fase di aggiornamento i messaggi 1 e 2 sono rimossi dalla casella di posta. Il problema di questa modalità sussiste nel caso in cui il destinatario volesse utilizzare un altro PC per accedere ai propri messaggi di posta, perché i messaggi vengono ripartiti su più client. In questo caso se Bob leggesse il messaggio in uno dei client non potrebbe più leggerlo dagli altri.

In modalità scarica e mantieni lo user agent lascia i messaggi sul server di posta dopo averli scaricati, permettendo a Bob di rileggerli su più macchine diverse e in momenti differenti.

Dato che POP3 è un protocollo senza stato tra le varie sessioni è molto semplice implementarlo.

IMAP

Con POP3, dopo aver scaricato i messaggi sulla macchina locale, Bob può creare cartelle nelle quali includere i messaggi scaricati e può spostarli tra cartelle, effettuare ricerche per nome del mittente o cancellarli. Gli utenti però preferirebbero avere una gerarchia di cartelle su un server remoto cui accedere da differenti calcolatori, perché su POP3 le modifiche delle cartelle sono locali. Proprio per questo è stato messo a punto il protocollo IMAP, che permette di mantenere tutti i messaggi in un unico posto, ovvero il server, consentendo all'utente di organizzare i messaggi in cartelle. I server di IMAP conservano lo stato dell'utente tra le varie sessioni, ovvero i nomi delle cartelle e l'associazione tra identificatori dei messaggi e nomi delle cartelle.

Posta basata sul Web (HTTP)

Vi sono poi gli utenti che accedono alle proprie e-mail tramite un browser web, questo è il caso di Hotmail, Google e Yahoo. In questo caso lo user agent è un browser web e l'utente comunica con la propria casella remota tramite HTTP, anziché POP3 o IMAP. Tra i server di mittente e destinatario si usa comunque SMTP.

Transport Layer Security (TLS) - SMTP

Per garantire la sicurezza della comunicazione si può usare SMTP insieme a TLS, ma in questo caso le comunicazioni non possono avvenire su porte di comunicazione ove è in ascolto un server di posta che non usa la crittografia. Sono pertanto utilizzate porte diverse:

• SMTP con SSL/TLS su porta 465
• POP3 con SSL/TLS su porta 995
• IMAP con SSL/TLS su porta 993
  Vi è poi un evoluzione di TLS, ovvero STARTTLS, che consente di cifrare la connessione anche sulle porte originali o standard (110 per POP3, 143 per IMAP, 25 per SMTP). Il client che sfrutta tale protocollo chiede in prima istanza al server l'instaurazione di una connessione cifrata, poi la sessione inizia "in chiaro" e quindi diventa cifrata prima che venga trasmessa qualunque informazione sensibile o potenzialmente tale.
  Viene spesso impiegato tra MTA (Mail Transfer Agent) ovvero durante il trasporto dell'email da un provider all'altro.

2.5 DNS (Domain Name System)

Le persone possono essere identificate in molti modi, come ad esempio il nome, il codice fiscale o il numero della carta d'identità. Proprio come le persone, anche gli host Internet possono essere identificati in vari modi. Uno tra questi sono i nomi degli host (hostname), quali www.facebook.com, www.google.com e gaia.cs.umass.edu, che sono usati dagli uomini ma forniscono poca informazione sulla loro collocazione all’interno di Internet. Proprio per questo gli host vengono identificati anche dai cosiddetti indirizzi IP.
Un indirizzo IP è formato da quattro byte (32 bit) ed è usato per indirizzare i datagrammi. Ha una forma del tipo 121.7.106.83 ed ogni punto separa un campo dall'altro, il cui valore è compreso tra 0 e 255. È un indirizzo gerarchico perché, leggendolo da sinistra a destra, otteniamo informazioni sempre più specifiche sulla collocazione dell’host in Internet.

2.5.1 Servizi forniti da DNS

Dato che per identificare gli host le persone preferiscono il nome, mentre i router prediligono gli indirizzi IP, per conciliare i due approcci si utilizza il DNS (domain name system). DNS è un database distribuito implementato in una gerarchia di DNS server e un protocollo a livello di applicazione che consente agli host, ai router e ai server DNS di interrogare il database per risolvere i nomi (tradurre indirizzi/nomi).
Per esempio, quando un browser (ossia un client HTTP) in esecuzione sull'host di un utente richiede l'URL www.someschool.edu/index.html, per inviare un messaggio di richiesta HTTP al web server www.someschool.edu, l'host deve come prima cosa ottenere il suo indirizzo IP. Quello che accade è:

1. La macchina utente esegue il lato client dell’applicazione DNS.
2. Il browser estrae il nome dell’host, www.someschool.edu, dall’URL e lo passa al lato client dell’applicazione DNS.
3. Il client DNS invia una 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 verso il processo server HTTP collegato alla porta 80 di quell’indirizzo IP.

Il DNS però introduce un ritardo aggiuntivo, ma spesso l'IP che si richiede si trova nella cache di un DNS server vicino.
Oltre alla traduzione degli hostname in indirizzi IP, DNS mette a disposizione altri servizi.

Host aliasing

Un host dal nome complicato può avere uno o più sinonimi, detti alias. Per esempio relay1.west-coast.enterprise.com, detto hostname canonico, potrebbe avere come sinonimi enterprise.com e www.enterprise.com, che sono più semplice da ricordare. Il DNS può essere invocato sia per ottenere l'hostname canonico di un sinonimo, sia per ottenere l'indirizzo IP dell'host.

Mail server aliasing

Solitamente gli indirizzi email dovrebbero essere facili da ricordare, ma se per esempio Bob ha un account Hotmail del tipo [email protected], l'hostname del server di posta Hotmail è più complicato e meno facile da ricordare. Il nome canonico potrebbe essere relay1.west-coast.yahoo.com, per cui un'applicazione di posta può invocare il DNS per ottenere il nome canonico di un sinonimo fornito, così come l'indirizzo IP dell'host. Infatti il record MX permette al server di posta di una società e al web server di avere hostname (alias) identici, per esempio enterprise.com.

Distribuzione del carico di rete

Il DNS viene anche utilizzato per distribuire il carico tra server web replicati, soprattutto per quei siti con molto traffico. Ogni server viene eseguito su un host diverso con un indirizzo IP differente, ma vengono raggruppati sotto lo stesso nome canonico. Dato che solitamente un client invia la sua richiesta HTTP al primo indirizzo IP elencato nell'insieme, la rotazione DNS distribuisce il traffico sui server replicati.

Come HTTP, FTP e SMTP, anche DNS è un protocollo a livello di applicazione dato che viene usato tra sistemi periferici che comunicano tra loro adottando il paradigma client-server e si affida a un protocollo sottostante di trasporto end-to-end per trasferire i messaggi, ma non interagisce direttamente con gli utenti perché fa tutto da solo (viene fatto a prescindere, con la mail sono io che decido quando inviarla).

2.5.2 Panoramica del funzionamento di DNS

Il DNS è un insieme di server distribuiti e non è centralizzato perché ciò comporterebbe ad alcuni problemi:

• Un solo punto di fallimento: se il DNS server si guasta, ne soffre l’intera Internet.
• Volume di traffico: un singolo DNS dovrebbe gestire tutte le richieste HTTP e i messaggi di posta elettronica generati da centinaia di milioni di host.
• Database centralizzato distante: un singolo DNS server non può essere vicino a tutti i client. Se il server si trovasse a New York, le query provenienti dall’Australia dovrebbero viaggiare fino all’altro capo del mondo, magari su collegamenti lenti e congestionati, causando ritardi significativi.
• Manutenzione: il singolo DNS server dovrebbe contenere record relativi a tutti gli host di Internet. Non solo tale database centralizzato sarebbe vasto, ma dovrebbe essere aggiornato frequentemente per tener conto di ogni nuovo host.

Per tali motivi un database centralizzato su un singolo DNS server non è in grado di adattarsi alla crescita esponenziale della rete, ovvero non è scalabile.

Database distribuito e gerarchico

Il DNS utilizza un grande numero di server, organizzati in maniera gerarchica e distribuiti nel mondo. Nessun grande numero di server, organizzati in maniera gerarchica e distribuiti nel mondo perché sono distribuite tra tutti i DNS server. Esistono tre classi di DNS server: i root server, i top-level domain (TDL) server e i server autoritativi.
Supponiamo che il client cerchi l'IP di www.amazon.com. Come prima cosa il client contatta uno dei root server che gli restituisce uno o più indirizzi IP relativi al server TLD per il dominio .com (dominio di primo livello). Quindi contatta uno di questi TLD che gli restituisce uno o più indirizzi IP del server autoritativo per amazon.com. Infine contatta uno dei server autoritativi per amazon.com che gli restituisce l’indirizzo IP dell’hostname www.amazon.com.

Server radice (Root server)

Esistono 13 diverse organizzazioni che gestiscono server radici, ognuna delle quali ha diverse repliche in tutto il mondo. Il root server, che viene contattato da un server DNS locale che non può tradurre il nome, contatta un server DNS autorizzato se non conosce la mappatura. Una volta ottenuta la mappatura la restituisce al server DNS locale.

Server TLD (Top-level domain server)

Si occupano dei domini di primo livello quali com, org, net, edu e gov, ma anche di tutti i domini locali di alto livello relativi ai vari paesi, come it, uk, fr, ca e jp. Network Solutions gestisce i server TLD per il dominio com, mentre Educause gestisce quelli per il dominio edu. I server TLD forniscono gli indirizzi IP dei server autoritativi.

Server di competenza (authoritative server)

Ogni organizzazione dotata di host pubblicamente accessibili tramite Internet (quali i web server e i mail server di posta) deve fornire record DNS pubblicamente accessibili che associno i nomi di tali host a indirizzi IP. Possono essere mantenuti dall'organizzazione o dal service provider.

Server DNS locale

Esiste il DNS server locale che non appartiene strettamente alla gerarchia dei server e ciascun ISP, come un’università, un dipartimento universitario, un’azienda o un ISP residenziale, ha un DNS server locale, detto anche default name server. Quando un host effettua una richiesta DNS, la query viene inviata al suo server DNS locale, il quale opera da proxy e la inoltra in una gerarchia di server DNS. Il DNS locale non è sempre presente e quindi potrebbe coincidere con il client.

Query iterativa

Supponiamo che l'host cis.poly.edu voglia l'indirizzo IP di gaia.cs.umass.edu. Come prima cosa l'host cis.poly.edu invia un messaggio di richiesta DNS al proprio server locale contenente il nome da tradurre, ossia gaia.cs.umass.edu. Il server locale inoltra il messaggio di richiesta a un root server, il quale prende nota del suffisso edu e restituisce al server locale un elenco di indirizzi IP per i TLD server che gestiscono edu. Il server locale rinvia quindi il messaggio di richiesta a uno di questi server TLD, il quale prende nota del suffisso umass.edu e risponde con l’indirizzo IP del server autoritativo per l’Università del Massachusetts, ossia dns.umass.edu. Infine, il DNS server locale rimanda il messaggio di richiesta direttamente a dns.umass.edu, che risponde con l’indirizzo IP di gaia.cs.umass.edu.
Se però l'Università del Massachusetts avesse un proprio DNS server, chiamato dns.umass.edu, e ciascun dipartimento dell’università avesse un proprio server che gestisce tutti gli host del dipartimento, quando il DNS server intermedio, dns.umass,edu, riceve una richiesta da dns.poly.edu per un host il cui nome termina con cs.umass.edu, gli restituisce l’indirizzo IP di dns.cs.umass.edu, che rappresenta il server autoritativo per tutti i nomi di host terminanti con cs.umass.edu. Il server locale dns.poly.edu invia quindi la richiesta al server autoritativo, che restituisce la corrispondenza desiderata al DNS server locale, il quale a sua volta la restituisce all’host richiedente.

Questo esempio fa uso sia di query ricorsive che di query iterative.
La richiesta inviata da cis.poly.edu a dns.poly.edu è ricorsiva, in quanto richiede a dns.poly.edu di ottenere l’associazione per conto del richiedente.
Le successive tre richieste sono invece iterative, dato che tutte le risposte sono restituite direttamente a dns.poly.edu.

Query ricorsiva

In questo esempio le richieste sono tutte ricorsive, perchè ogni server DNS delega un'altro server DNS, fino a che non si raggiunge il server DNS di competenza.

DNS Caching

Una volta che un server DNS riceve una risposta DNS (contenente, per esempio, la traduzione da hostname a indirizzo IP), 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 server può fornire l’indirizzo IP desiderato, anche se non è autoritativo per tale indirizzo.
Dato che gli host e le associazioni tra nome e indirizzo IP non sono in alcun modo permanenti, i DNS server invalidano le informazioni in cache dopo un periodo di tempo fissato (in genere di 2 giorni).
Supponiamo, per esempio, che un host apricot.nyu.edu richieda a dns.nyu.edu l’indirizzo IP dell’hostname cnn.com. Supponiamo, inoltre, che poche ore dopo un altro host della stessa organizzazione, per esempio kiwi.nyu.edu, faccia richiesta a dns.nyu.edu con lo stesso hostname. Grazie al caching, il DNS server locale sarà in grado di restituire immediatamente l’indirizzo IP di cnn.com a questo secondo host richiedente, senza dover interrogare alcun altro DNS server.
Un DNS server locale può, inoltre, memorizzare in cache gli indirizzi IP dei TLD server, consentendogli di aggirare i root server nella catena di richieste per non visitarli spesso.

Abilitando una cache DNS, che non è sempre aggiornata, può capitare che si trovi il memento in cui ci sono dati vecchi, come l’ip sbagliato.

I casi in cui i DNS falliscono sono molto rari perché l'infrastruttura è estremamente ridondata e gli indirizzi IP dei server TLD sono cached quasi ovunque.
Un attacco DDoS è quasi inefficace, invece attacchi più mirati hanno maggiori probabilità di successo.
Se venisse fatto un attacco ad un root DNS server, che magari possiede tecniche di filtraggio e che viene utilizzato molto meno rispetto ad un DNS che gestisce il dominio .com, i danni sarebbero molto contenuti, se non quasi assenti. Anche nel caso di un attacco ad un server DNS autoritativo però i danni potrebbero essere mitigati dalle cache dei DNS locali
Un attacco al DNS locale impedisce l'accesso al DNS, mentre un attacco al DNS autoritativo impedisce l'accesso al dominio. Ciò nonostante il DNS si è dimostrato comunque molto robusto agli attacchi fino ad oggi.

2.5.3 Record e messaggi DNS

I server che implementano il database distribuito di DNS memorizzano i cosiddetti record di risorsa (RR), tra cui quelli che forniscono le corrispondenze tra nomi e indirizzi. Ogni messaggio di risposta DNS trasporta uno o più record di risorse.
Un record di risorsa contiene i seguenti campi: (Name, Value, Type, TTL).
TTL è il time to live, ossia il tempo residuo di vita di un record e determina quando una risorsa vada rimossa dalla cache. Il significato di Name e Value dipende da Type:

• Type=A: vi è un associazione standard tra nome dell'host e indirizzo IP, quindi name è il nome dell'host e value è l'indirizzo IP. Es: (es relay1.bar.foo.com, 145.37.93.126, A).
• Type=NS: name è il dominio (es foo.com) e value è il nome dell'host del server DNS di competenza di questo dominio. Viene utilizzato per instradare le richieste DNS successive alla prima nella concatenazione delle query. Es: (foo.com, dns.foo.com, NS).
• Type=CNAME: value è il nome canonico, mentre name è il nome alias di qualche nome canonico (nome vero). Questo record può fornire agli host richiedenti il nome canonico relativo a un hostname. Es: (foo.com, relay1.bar.foo.com, CNAME).
• Type=MX: value è il nome canonico di un mail server che ha il sinonimo name. Es (foo.com, mail.bar.foo.com, MX). Questo record consente agli hostname dei mail server di avere sinonimi semplici.

Può accadere che una società utilizzi gli stessi sinonimi per il proprio server di posta e per uno dei propri altri server (es web server). Per ottenere il nome canonico del server di posta, un client DNS dovrebbe interrogare un record MX. Per ottenere il nome canonico dell’altro server, il client DNS dovrebbe interrogare il record CNAME.
Un DNS server non autoritativo per un certo hostname contiene un record NS per un dominio che include l'host gaia.cs.umass.edu, per esempio (umass.edu, dns.umass.edu, NS), ma anche un record di tipo A che indica il DNS server dns.umass.edu in un indirizzo IP, per esempio (dns.umass.edu, 128.119.40.111, A).

Messaggi DNS

Le domande (query) ed i messaggi di risposta DNS presentano lo stesso formato.

Sezione di intestazione

I primi 12 byte rappresentano la sezione di intestazione, che a sua volta contiene un certo numero di campi.

• Identificazione: numero di 16 bit che identifica la richiesta e che viene utilizzato anche nel messaggio di risposta.
• Flag:
  • il primo di questi bit indica se il messaggio è una richiesta (0) oppure una risposta (1). Nel caso di risposta si imposta il bit quando il server è autoritativo per il nome richiesto
  • un ulteriore bit, detto richiesta di ricorsione, viene impostato quando un client desidera che il DNS server effettui ricorsione quando non dispone del record
  • un altro bit, detto ricorsione disponibile, viene impostato se il DNS server supporta la ricorsione (lo si imposta comunque, in caso non si usa).
  • un bit per la risposta di competenza, ovvero se il server è autoritativo, TLD ecc...
• Vi sono poi quattro campi il cui nome comincia con “numero di”, che indicano il numero di occorrenze delle quattro sezioni di tipo dati che seguono l’intestazione.

Sezione delle domande

Contiene informazioni sulle richieste che stanno per essere effettuate, includendo un campo con il nome che sta per essere richiesto e un campo tipo che indica il tipo della domanda: per esempio, un indirizzo di host associato a un nome (tipo A) o il server di posta per un nome (tipo MX).

Sezione delle risposte

Contiene i record di risorsa (RR) relativi al nome originariamente richiesto. In ogni record di risorsa troviamo Type (A, NS, CNAME o MX), Value e TTL. Ogni risorsa può restituire più RR, dato che un hostname può avere più indirizzi IP (es web server replicati).

Sezione autoritativa

Contiene i record di altri server autoritativi.

Sezione aggiuntiva

Include altri record che possono essere usati: per esempio, se il campo di risposta relativo a una richiesta MX contiene un record di risorsa che fornisce l’hostname canonico del server di posta, la sezione aggiuntiva contiene un record di tipo A che fornisce l’indirizzo IP relativo all’hostname canonico del server di posta.

Inserimento di record nel database DNS.

Abbiamo appena avviato una società chiamata Network Utopia e come prima cosa che bisogna fare è registrare il nome di dominio networkutopia.com presso un ente di registrazione (registrar). Registrar è un’azienda che verifica l’unicità del nome di dominio, lo inserisce nel database DNS e richiede una piccola somma di denaro per i propri servizi. Al giorno d'oggi esistono molti registrar concorrenti.
Quando si registra il dominio networkutopia.com bisogna fornire i nomi e gli indirizzi IP dei nostri server DNS autoritativi primario e secondario (es dns1.networkutopia .com, dns2.networkutopia.com, 212.2.212.1 e 212.212.212.2). Per ognuno dei due server autoritativi l'ente inserirà un record di tipo NS e di tipo A nei TLD server relativi al suffisso com. Più nello specifico, per il server autoritativo primario di networkutopia.com il registrar inserirebbe nel sistema DNS i due seguenti record di risorsa:

• (networkutopia.com, dns1.networkutopia.com, NS)
• (dns1.networkutopia.com, 212.212.212.1, A)

Bisogna inoltre inserire nel server DNS un record di tipo A per il web server www.networkutopia.com e un record di tipo MX per il server di posta mail.networkutopia.com. Grazie all'aggiunta dell'opzione UPDATE i dati del database vengono aggiornati dinamicamente attraverso messaggi DNS.

Supponiamo ora che un utente in Australia, che chiameremo Alice, voglia visitare e la pagina web www.networkutopia.com. Il suo host effettuerà una richiesta DNS al suo DNS server locale, il quale contatterà un TLD server del dominio com (verrà contattato anche un root server se l'indirizzo del TLD server responsabile di com non è in cache). Il TLD server contiene i record di risorsa di tipo NS e A, dato che il registrar li aveva precedentemente inseriti in tutti i TLD server relativi al suffisso com.
Il TLD server di com invia una risposta al server locale di Alice e la risposta contiene i due record di risorsa.
Il DNS locale manda una richiesta DNS a 212.212.212.1, cercando il record di tipo A che corrisponde a www.networkutopia.com. Questo record fornisce l’indirizzo IP del web server desiderato, per esempio 212.212.71.4, che verrà restituito dal DNS server locale all’host di Alice.
Il browser di Alice può ora inizializzare una connessione TCP verso l’host 212.212.71.4 e inviare una richiesta HTTP sulla connessione.

2.6 Condivisione di file P2P

Nell'architettura P2P non è presente un server sempre attivo, perché ci sono coppie di host (peer) connessi in modo intermittente, che comunicano direttamente tra loro. I peer inoltre non devono necessariamente essere sempre attivi e cambiano indirizzo IP.

Distribuzione di file

Bit rate = banda, ovvero quanti bit si possono trasmettere al secondo in un collegamento.

Siano $F$ la dimensione del file da distribuire (in bit) e $N$ il numero di peer che vuole una copia del file.
Il tempo di distribuzione è il tempo richiesto perché tutti gli $N$ peer ottengano una copia del file.
Si suppone inoltre che il nucleo di Internet abbia banda in abbondanza, quindi i colli di bottiglia sono nelle reti di accesso, e tutti i peer/client hanno la banda di accesso in upload e download riservata alla distribuzione di questo file.

Distribuzione di file: server-client

Il server invia in sequenza una copia del file a ciascuno degli $N$ peer, cioè $NF$ bit. Dato che la banda di upload del server è $u_s$, il tempo per distribuire il file deve essere almeno $NF/u_s$.

Sia $d_{min}$ la banda di download del peer avente il valore più basso tra tutti. Quindi il peer con la banda di download più bassa non può ricevere tutti gli $F$ bit del file in meno di $F/d_{min}$ secondi. Quindi il tempo minimo di distribuzione è almeno $F/d_{min}$.

Quindi il tempo per distribuire $F$ a $N$ client usando l'approccio client/server è: $d_{cs}=max[NF/U_S,F/min(d_i)]$. Di conseguenza il tempo di distribuzione aumenta linearmente con il numero N di peer, ovvero che se il numero di peer aumenta da un migliaio a un milione, il tempo richiesto per distribuire il file a tutti i peer aumenta di 1000 volte.

Distribuzione di file: P2P

Nell'architettura P2P ciascun peer assiste il server nella distribuzione del file. Quando un peer riceve alcuni dati del file può usare la propria capacità di upload per re-distribuire i dati agli altri peer.

All'inizio della distribuzione solo il server dispone del file e per trasmetterlo a tutti i peer della comunità deve inviare tutti i bit del file almeno una volta nel collegamento di accesso. Il tempo minimo di distribuzione è quindi $F/u_s$. Nella client-server un bit inviato dal server non necessitava di essere inviato di nuovo perché i peer possono re-distribuire i bit tra loro.

Anche in questo caso il peer con la velocità di download più bassa non può ottenere tutti i bit del file in meno di $F/d_{m}in$ secondi. Quindi il tempo minimo di distribuzione è almeno $F/d_{m}in$.

Infine, la capacità totale di upload del sistema nel suo complesso è uguale alla velocità di upload del server più quella di ciascun peer ($u_{tot}=u_s+u_1+...+u_N)$. Il sistema deve consegnare (upload) $F$ bit a ciascuno degli $N$ peer, consegnando quindi un totale di $NF$ bit, ma ad una velocità massima di $u_{tot}$. Quindi il tempo di distribuzione minimo è almeno $NF/u_{tot}$.

Quindi il tempo minimo di distribuzione per l'architettura P2P è: $D_{P2P}=max[F/U_s,F/min(d_i),NF/u_{tot}]$.

Confronto tra client-server e P2P

Supponiamo che tutti i peer abbiano la stessa velocità di upload $u$, $F/u=1$ ora, $u_s=10u$ e $d_{min}\ge u_s$. Quindi, un peer può trasmettere l’intero file in un’ora, la velocità di trasmissione del server è dieci volte la velocità di upload dei peer e, per semplicità, le velocità di download dei peer sono grandi abbastanza da non avere effetto. Graficamente è mostrato che le applicazioni con architettura P2P possono essere scalabili e la scalabilità è una diretta conseguenza del fatto che i peer re-distribuiscono i bit oltre che a scaricarli.

BitTorrent

BitTorrent è un diffuso protocollo P2P per la distribuzione di file e l'insieme di tutti i peer che partecipano alla distribuzione di un particolare file è chiamato torrent. I peer in un torrent scaricano chunk (parti) del file di uguale dimensione, con una dimensione tipica di 256 kbyte. Quando un peer entra a far parte del torrent per la prima volta non ha chunk del file, ma con il passare del tempo accumula sempre più parti che, mentre scarica, invia agli altri peer. Ciascun torrent ha un nodo di infrastruttura chiamato tracker e quando un peer entra a far parte di un torrent, si registra presso il tracker per avere la lista dei peer e periodicamente lo informa che è ancora nel torrent. In questo modo, il tracker tiene traccia dei peer che stanno partecipando al torrent. Un certo torrent può avere centinaia o migliaia di peer che partecipano in un dato istante.
Una volta che un peer ha acquisito l’intero file, può (egoisticamente, leech) lasciare il torrent o (altruisticamente, seeder) rimanere nel torrent e continuare a inviare chunk agli altri peer. Inoltre, qualsiasi peer può lasciare il torrent in qualsiasi momento con solo un sottoinsieme dei chunk del file e rientrare a far parte del torrent in seguito. Proprio per questo, in un dato istante, peer diversi hanno differenti sottoinsiemi del file.

Quando un nuovo peer, Alice, entra a far parte di un torrent, il tracker seleziona in modo casuale un sottoinsieme di peer (diciamo 50) dall’insieme dei peer che stanno partecipando a quel torrent e invia l’indirizzo IP di questi 50 peer ad Alice. Con questi peer vicini, detti neighboring peer, Alice cerca di stabilire delle connessioni TCP contemporanee con tutti i peer della lista. I peer vicini però cambiano nel tempo, dato che comunque alcuni di essi possono lasciare il torrent o nuovi possono aggiungersi.
In un dato istante, ciascun peer avrà un diverso sottoinsieme di chunk e quindi periodicamente un peer, Alice, chiederà a ciascuno dei suoi vicini, tramite le connessioni TCP, la lista dei chunk del file in loro possesso. Tramite questa conoscenza, Alice invierà richieste, di nuovo sulle connessioni TCP, per i chunk del file che ancora le mancano.
Di conseguenza, in un dato istante Alice avrà un sottoinsieme dei chunk del file e saprà quali chunk hanno i suoi vicini, perciò dovrà decidere inizialmente quali chunk deve richiedere per primi ai suoi vicini e successivamente a quali vicini dovrebbe inviare i chunk a lei richiesti.
Nel decidere quali chunk richiedere, Alice adotta la tecnica del rarest first (il più raro per primo), ovvero i chunk con il minor numero di copie ripetute tra i suoi vicini li richiede per primi, questo per rendere uguale il numero di copie di ciascun chunk nel torrent.
Per determinare a quali richieste Alice deve rispondere, BitTorrent usa un algoritmo per fare in modo che Alice attribuisca priorità ai vicini che le stanno inviando dati in questo momento alla velocità più alta. Alice tiene continuamente misurata la velocità alla quale riceve i bit e determina, ogni 10 secondi, i quattro peer che le stanno passando i bit alla velocità più elevata, con un eventuale modifica dei quattro (detti unchoked, ovvero non soffocati). Alice poi contraccambia inviando chunk del file a quegli stessi quattro peer.
Ogni 30 secondi Alice sceglie casualmente un vicino in più, detto Bob, e gli invia dei chunk. Bob viene anche detto optimistically unchoked, ovvero non soffocato in maniera ottimistica. Nel caso Alice diventasse uno dei quattro peer unchoked di Bob, anche Bob inizierebbe a inviare dati ad Alice. Se la velocità alla quale Bob manda i dati ad Alice è abbastanza alta, Bob, a sua volta, potrebbe diventare uno dei quattro peer unchoked di Alice.
Se i due peer sono soddisfatti degli scambi, l’uno metterà l’altro nella propria lista dei quattro unchoked e continueranno a effettuare scambi tra loro finché uno non trovi un partner migliore, dopo il controllo che avviene ogni 30 secondi. Questa selezione casuale permette anche ai nuovi peer di ottenere chunk del file.
Tutti gli altri peer, a parte quei cinque (quattro unchoked e uno di prova), sono detti choked, ovvero che non ricevono nulla.

Il meccanismo di incentivazione degli scambi descritto precedentemente viene spesso chiamato tit-for-tat (occhio per occhio), io do a te e tu dai a me.

Ricerca informazioni

Vi sono poi delle tabelle hash distribuite (DHT) che sono semplici database, in cui vengono salvati gli indici e i cui record sono distribuiti tra i peer di un sistema P2P.

File sharing (es: e-mule)

L'indice tiene traccia dinamicamente della posizione del file che i peer condividono. I peer comunicano all'indice ciò che possiedono e lo consultano per determinare dove trovare i file.

Messaggeria istantanea

L'indice crea la corrispondenza tra utenti e posizione. Quando l'utente lancia l'applicazione, informa l'indice della sua posizione. I peer consultano l'indice per determinare l'indirizzo IP dell'utente.

Query flooding

È un metodo distribuito, senza alcun server centrale, per cercare una risorsa in una rete peer-to-peer. Gnutella, un'applicazione di condivisione file di dominio pubblico, operava tramite query flooding. I peer formano una rete astratta e logica chiamata overlay network, un grafo in pratica.
Vi è un arco, ovvero un collegamento virtuale e non fisico, tra i peer X e Y se c'è una connessione TCP. Tutti i peer attivi e gli archi formano la rete di copertura.
Un dato peer, nonostante una rete possa avere migliaia di peer partecipanti, sarà in genere connesso con meno di 10 peer vicini nella rete di copertura.

I peer inviano messaggi di richiesta ai peer vicini sulle connessioni TCP esistenti. I vicini inoltrano il messaggio query a tutti i loro vicini, che lo inoltrano a tutti i loro vicini e così via. Quando un peer riceve un messaggio di query verifica se dispone del file che deve condividere, in tal caso invia un messaggio di successo che è trasmesso sul percorso inverso sulle connessioni TCP preesistenti. Il query flooding, poichè si propaga a ogni altro peer nella rete, ha un raggio limitato e quindi non è scalabile.

Copertura gerarchica

La copertura gerarchica combina le migliori caratteristiche di un indice centralizzato e del query flooding. Ogni peer è un leader di gruppo o è assegnato a un leader di gruppo. C'è una connessione TCP tra peer e il suo leader di gruppo e delle connessioni TCP tra qualche coppia di leader di gruppo. Il leader di gruppo tiene traccia del contenuto di tutti i propri figli.

Skype

Intrinsecamente Skype è P2P, perché le coppie di utenti comunicano tra loro. Protocollo proprietario (dedotto mediante reverse engineering). Vi è una copertura gerarchica con i supernodi. L'indice crea corrispondenza tra i nomi utente e indirizzi IP.

2.7 Cloud computing

Il cloud computing prevede uno o più server reali, generalmente organizzati in un'architettura ad alta flessibilità e fisicamente collocati presso il data center del fornitore del servizio.

• Il fornitore di servizi espone delle interfacce per elencare e gestire i propri servizi.
• Il cliente amministratore utilizza tali interfacce per selezionare il servizio richiesto (es un server virtuale completo oppure solo storage) e per amministrarlo (configurazione, attivazione, disattivazione).
• Il cliente finale utilizza il servizio configurato dal cliente amministratore. Un software apposito isola le risorse per il client.

Le caratteristiche fisiche dell'implementazione (server reale, localizzazione del data center) sono irrilevanti. Il layer di virtualizzazione mette una barriera tra il client e le risorse, non si sa che macchina c'è sotto e dove si trova.

Criticità:

• sicurezza e privacy, perché i dati personali possono risiedere nelle server farms di aziende che risiedono in uno stato diverso da quello dell'utente ed il cloud provider potrebbe accedervi.
• problemi internazionali di natura economica e politica dovuti a territori instabili
• continuità del servizio offerto nel caso i sevizi non fossero operativi
• difficoltà di migrazione dei dati

I data center si trovano dislocati in tutto il mondo per servire più velocemente gli utenti di quella parte del mondo e di ogni server si può spesso affittarne una parte.

L'architettura dei datacenter è gerarchica ed è simile a quella di internet. C'è una parte core di smistamento e le reti di aggregazione gestiscono una sottoparte dei server. Per usare la rete in maniera ottimale, gli ISP cercano di tenere confinati nella stessa area i server che si utilizzano. Più si va in locale e minore è il numero di server. Contenuti statici vicini e dinamici lontani.

Video delivery

YouTube serve ogni giorno più di 100 milioni di video a utenti sparsi in tutto il mondo. Per fare ciò utilizza le CDN (content distribution networks) ed ognuna di esse gestisce server distribuiti in molti posti diversi, memorizza copie dei video e di altri contenuti web nei server e cerca di dirigere le richieste degli utenti al punto della CDN in grado di offrire il servizio migliore (più vicino). Questo accade per i contenuti più popolari, gli altri invece restano sui server di YouTube.
Il concetto è quello di memorizzare i dati il più vicino possibile ai consumatori, in modo da: ottimizzare le prestazioni di rete, ridurre la latenza ed evitare i colli di bottiglia. Le CDN generalmente adottano una delle due politiche di dislocazione dei server:

• Enter deep: Una filosofia proposta da Akamai è quella di installare i server nelle reti degli ISP in tutto il mondo, in modo da essere vicini agli utenti finali, perché ciò migliora il ritardo e il throughput percepiti dagli utenti
• Bring home: Il secondo approccio è seguito da Limelight e consiste nel costruire grandi cluster, che sono un insieme di computer (server nel nostro caso) connessi tra loro tramite una rete per distribuire un'elaborazione complessa ed aumentando la potenza di calcolo del sistema. Questi verranno installati in pochi punti chiave, ovvero gli IXP (Internet Exchange Point), interconnettendoli usando una rete privata ad alta velocità. Questo permetterà di servire le reti di più ISP contemporaneamente con la stessa infrastruttura.

Esempio: Facebook ha la propria CDN
Basta aprire una pagina di Facebook ed esaminare l'html. Vi sono dei riferimenti a fbcdn.net, che è la CDN di Facebook. Per scoprire dove si trova il nodo che serve i contenuti basta:

• inviare il comando "ping www.fbcdn.net" e ottenere l'indirizzo IP di un nodo della CDN
• localizzare geograficamente l'indirizzo IP con una ricerca su Google

2.8 Programmazione delle socket

La socket è un interfaccia di un host locale, creata dalle applicazioni, controllata dal SO (una porta) in cui il processo di un'applicazione può inviare e ricevere messaggi al/dal processo di un'altra applicazione. È una porta tra il processo di un'applicazione e il protocollo di trasporto end-end (UDP o TCP).

TCP

Il client deve contattare il server e quindi il processo server deve essere in esecuzione. Il server deve avere creato una socket (porta) che da il benvenuto al contatto con il client. Il client poi contatta il server creando una socket TCP e specificando l'indirizzo IP e il numero di porta del processo server. Quando il client crea la socket, il client TCP stabilisce una connessione con il server TCP. Quando viene contattato dal client, il server TCP crea una nuova socket per il processo server per comunicare con il client. Questo permette al server di comunicare con più client ed i numeri di porta d'origine sono usati per distinguere i client.