IP Mobility e Multihoming nell'architettura Serval

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "IP Mobility e Multihoming nell'architettura Serval"

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Protocolli per Reti Mobili IP Mobility e Multihoming nell'architettura Serval Anno Accademico 2014/2015 Candidato: Umberto Ferrandino matr. N46/000932

2 IP Mobility e Multihoming nell'architettura Serval Umberto Ferrandino LATEX 2

3 Dedicato a chi, nei modi più svariati, ma sempre con le migliori intenzioni, mi ha sostenuto ed accompagnato in questo cammino. 3

4 Indice Introduzione 5 1 Serval Architecture Problematiche arontate Cos'è Serval? La rete del futuro Il concetto di Servizio Service Access Layer (SAL) Installazione del SAL Funzionalità di base Ripensare lo stack TCP/IP Livello Applicazione Livello Trasporto Livello Rete Astrazione dei servizi e dei ussi Service Naming Flow Naming Inoltro dei pacchetti nello stack Serval Active Socket Forwarding e data plane Service discovery e registration Meccanismi di segnalazione eventi Prototipo dell'architettura Benchmark performance Casi di studio Web Service replicato con load balancing Storage distribuito Migrazione ussi e macchine virtuali Translator per compatibilità con host legacy 32 8 Dimostrazioni e test di funzionamento Catturare pacchetti Serval con Wireshark Invio di un le Flow migration Conclusioni 39 Bibliograa 40 4

5 Introduzione Fin dagli anni sessanta, la rete Internet, o ancora prima ARPANET, si è evoluta seguendo quelle che erano le necessità cui tale invenzione poteva far fronte. In pochi anni, il mondo intero ha assistito a quella che è probabilmente una delle più grandi rivoluzioni tecnologiche che la storia ricordi: da un progetto partito per essere un esperimento militare, poi un modo per interconnettere una quantità limitata di terminali, si è giunti ad interconnettere l'intero globo, rendendo pressoché irrisoria ogni distanza e possibile ogni comunicazione. Come è ovvio che sia, anché tale evoluzione fosse possibile, la rete ha dovuto subire una serie di cambiamenti e migliorie, con l'introduzione di nuovi protocolli e funzionalità, al ne di restare al passo con i tempi e garantire specici standard in materia di sicurezza, ecienza e quant'altro. Ad oggi, Internet va incontro ad ulteriori e più radicali cambiamenti. Infatti, nel corso degli anni, pur evolvendosi, la struttura di base della rete è rimasta fedele allo stesso modello, il famoso Stack TCP/IP. Con l'avvento del cosiddetto Web 2.0, Internet è diventato fortemente interattivo, grazie alla creazione delle piattaforme e delle applicazioni, che fanno ormai parte, della vita di tutti i giorni di ognuno di noi. Tuttavia, tale processo, ha mostrato agli sviluppatori, agli ingegneri e a chiunque lavorasse nell'ambito del networking, una serie di inadeguatezze cui la rete è soggetta, specialmente in vista di quello che potrebbe essere il passo successivo nella trasformazione di Internet e dunque, inevitabilmente, della vita di coloro che ne usufruiscono. Per far fronte alle problematiche postesi, quali ad esempio il crescente numero di dispositivi connessi alla rete (e di conseguenza al carico di lavoro dei server), o alla sempre più frequente presenza nella rete di dispositivi mobili, molti provvedimenti, sono già stati messi in atto, altrettanti invece, sono in cantiere o in attesa di essere standardizzati. Ad ogni modo, così come si è passati da un web prevalentemente statico, ad uno fortemente sociale, che basa le propria fondamenta sulla libertà di espressione e di condivisione (appunto il Web 2.0 ), allo stesso modo, si viaggia verso un nuovo web, in cui ogni oggetto possa essere connesso alla rete per sfruttarne le potenzialità, in cui l'utente possa vivere un'esperienza virtuale completa grazie alla realtà aumentata e alla semantica dei contenuti (solitamente indicato con Web 3.0 ). Tale elaborato, si propone dunque, di illustrare uno dei progetti in via di sviluppo più interessanti nell'ambito della mobilità e del multihoming, ovvero: Serval Architecture. 5

6 1 Serval Architecture 1.1 Problematiche arontate Un tempo, il web era popolato prevalentemente da dispositivi la cui mobilità era limitata ad un ambiente domestico o aziendale. La comunicazione avveniva dunque, tra singoli terminali che dicilmente avevano necessità di spostarsi. Oggigiorno, le cose sono profondamente cambiate. Infatti, sempre più spesso, un'altissima percentuale dei client che usufruiscono di un determinato servizio, sono dispositivi mobili con diverse interfacce di comunicazione (ad esempio, Wi-Fi e 3G/4G). Data la proliferazione degli abitanti del web, i provider, e in generale tutte le realtà che forniscono servizi online ad una copiosa utenza, hanno dovuto adeguare i propri organismi, passando ad architetture che prevedono numerosi server dislocati in tutto il globo. Tutto ciò ovviamente, si ripercuote sul funzionamento e sulla essibilità dei servizi. Lo stack TCP/IP, risulta essere inadeguato per quelli che sono i prossimi step nell'evoluzione della mobilità e della fruizione dei contenuti. Ad esempio, diverse sono le problematiche legate allo spostamento del usso di rete da un'interfaccia all'altra (si pensi ad esempio al fatto che, sul proprio smartphone, non si possa intercambiare Wi-Fi e 3G/4G in modo trasparente e senza interrompere le connessioni in corso), o all'utilizzo parallelo di più interfacce per lo stesso scopo (ad esempio, uno streaming in cui il download dei dati avviene in parallelo tra rete wireless e rete mobile). Per quanto riguarda invece la gestione dei server, si rende necessario un load balancer, in grado di distribuire nel miglior modo possibile il carico di lavoro tra i server, evitandone il sovraccarico. An application can run on multiple servers at dierent locations, and can launch at or migrate to a new machine at any time. In addition, user devices are often multi-homed (e.g., WiFi and 4G) and mobile. In short, modern services operate under unprecedented multiplicity (in service replicas, host interfaces, and network paths) and dynamism (due to replica failure and recovery, service migration, and client mobility). Yet, multiplicity and dynamism match poorly with today's host-centric TCP/IP-stack that binds connections to xed attachment points with topology-dependent addresses and conates service, ow, and network identiers. This forces online services to rely on clumsy and restrictive techniques that manipulate the network layer and constrain how services are composed, managed, and controlled. For example, today's load balancers repurpose IP addresses to refer to a group of (possibly changing) service instances; unfortunately, this requires all client trac to traverse the load balancer. Si veda [1, p. 1] per maggiori informazioni. 6

7 1.2 Cos'è Serval? Serval, è un progetto open source dell'università di Princeton, nato da un'idea di Michael J.Freedman, professore associato della facoltà di Informatica. Come spiegato precedentemente, le problematiche cui va incontro Internet, sono molteplici e rischiano di comprometterne un funzionamento ottimale in futuro. Per tale motivo, molti sono i progetti nati al ne di evitare che ciò accada. Serval è uno di questi: Freedman infatti, sostiene che ad oggi, gli ingegneri per poter implementare talune funzionalità, debbano ricorrere ad una serie di hack piuttosto complessi, che non sarebbero necessari risolvendo alla base le problematiche di cui sopra. Si veda [3]. Smart engineers are great at mastering complexity and hacking around it. But with the current approach, everybody needs to reinvent the wheel [...] Serval is something that will make things easier to build and easier to manage without relying on these hacks. Oltre Freedman, lavorano a Serval, anche Erik Nordstrom, David Shue, Prem Gopalan, Robert Kiefer, Matvey Arye, Steven Y.Ko e Jennifer Rexford. Il progetto, è stato nanziato da: National Science Fundation, DARPA, Oce of Naval Research e Cisco Systems. [4] La rete del futuro L'idea che sta alla base di Serval, vede l'utente, non più interessato al web come mezzo per interconnettersi ad uno specico terminale nella rete, ma piuttosto come tramite verso uno specico servizio. Si pensi ad esempio a realtà quali Google, che mettono a disposizione una moltitudine di servizi (Gmail, Maps, Drive etc.) dislocati su altrettanti server: un indirizzo IP, all'interno della rete, non può che rappresentare una specica macchina. Tale approccio, che prevede l'utilizzo dei load balancers sopracitati, risulta dunque fortemente limitativo in ambienti in cui, ogni funzionalità deve necessariamente essere dislocata su più server per far fronte al carico di lavoro. Inoltre, tutto ciò, impone dei vincoli in termini di mobilità degli host, i quali, non possono ad esempio migrare da una interfaccia all'altra, e dunque cambiare il proprio indirizzo IP, senza che la fruizione del servizio venga interrotta. Jennifer Rexfort, professoressa del dipartimento di Informatica, impegnata nello sviluppo di Serval, sostiene che (si veda [3]): A lot of applications can be rewritten to hide the fact that you break your connection and re-establish it, but it makes things unnecessarily complex and more expensive. The Internet is increasingly a platform for connecting mobile 7

8 users with the cloud and the Internet was not designed to do that [...] All the work that goes into shoehorning that into the old network architecture is very dicult Il concetto di Servizio Gli sviluppatori di Serval, hanno deciso di astrarre il concetto di servizio al punto da far sì che, l'utente, piuttosto che connettersi ad un indirizzo IP, e di conseguenza ad un terminale ben preciso, possa invece richiedere la connessione ad uno specico servizio, senza avere diretta visibilità dell'ip. Diamo allora una denizione più rigorosa di servizio [1, p. 1]: Un servizio, corrisponde ad un gruppo di sistemi, che orono le stesse funzionalità, disaccoppiando il servizio stesso, dagli identicatori di rete. Le applicazioni, possono instaurare una comunicazione senza badare ad indirizzo IP e porto. In altre parole: Service names identify who one communicates with, ow names identify what communication context to use, while addresses tell where to direct the communication. 8

9 1.3 Service Access Layer (SAL) Il cuore di Serval, è il Service Access Layer (di qui in poi SAL), che viene introdotto nello stack TCP/IP tra il livello rete e il livello trasporto. Lo scopo del SAL, è quello di realizzare l'astrazione di cui sopra e di mappare l'identicatore del servizio all'indirizzo IP corrispondente, mediante una service table, similmente a quel che avviene nel livello rete per le forwarding table. Tutto ciò senza nessuna ulteriore modica allo stack TCP/IP e senza che siano necessari ulteriori apparecchi di rete. Figura 1: Lo stack TCP/IP con e senza Serval. [1, Fig. 1] Installazione del SAL Il SAL, viene integrato all'interno del sistema operativo, mediante un modulo del Kernel Linux e/o Android, (in futuro gli sviluppatori prevedono di rendere il tutto compatibile con tutti i SO Unix-based nonché con i sistemi Windows) che può essere caricato e rimosso a tempo d'esecuzione mediante gli specici comandi da shell. Il codice sorgente necessario, può essere prelevato dall'apposita pagina del progetto su Github: Princeton-sns/Serval. Ovviamente, prima che sia possibile caricare il modulo del SAL, sarà necessario generarlo compilando il codice sorgente scaricato, mediante la tipica procedura certamente nota agli utilizzatori di un sistema operativo GNU/Linux. Per ogni dubbio, è possibile consultare la documentazione online (Serval Wiki) o i le README ed INSTALL all'interno del pacchetto contenente i sorgenti. Una volta caricato il modulo, sarà possibile far uso dei servizi messi a 9

10 disposizione da Serval ed avviare alcuni software di base (forniti all'interno dell'archivio disponibile su Github) per il testing delle funzionalità Funzionalità di base Uno degli scopi principali di Serval è quello di migliorare la mobilità delle connessioni (Mobility e Multihoming), che nell'approccio attuale risulta essere ineciente. In particolare, tramite l'astrazione realizzata dal SAL, Serval fa in modo che, non avendo le applicazioni visibilità in tutto e per tutto degli indirizzi IP, quest'ultimo possa variare senza interrompere il usso dati, nel passare da una rete all'altra o nel cambiare interfaccia di connessione. Figura 2: Mobility e multihoming. [2, Pag. 6] Oltre che per la mobilità dei client, Serval, prevede anche delle migliorie che possano invece interessare gli Internet Provider e più in generale i fornitori di servizi online. Attualmente, una architettura che prevede la distribuzione del carico di lavoro su più server, richiede l'utilizzo di terminali che si occupino di gestire le connessioni in entrata per indirizzarle in modo intelligente ad uno dei server disponibili. Tale approccio, fa sì che i load balancer, debbano gestire l'inoltro di tutti i pacchetti inviati dai client verso i server, cosa che, evidentemente, accresce la complessità ed il costo del sistema complessivo. Un simile approccio viene inoltre utilizzato per la risoluzione dei nomi tramite DNS, e di conseguenza presenta le stesse problematiche. 10

11 Figura 3: Approccio con load balancer. [2, Pag. 8] Serval gestisce tali situazioni, in modo diverso e sicuramente più eciente, e lo fa tramite i cosiddétti service routers, dei terminali che si occupano di instaurare il collegamento al servizio su richiesta del client, mediante un apposito pacchetto. Il traco successivamente generato, viaggia invece direttamente tra gli host implicati nella comunicazione (dierentemente da quando accade in presenza dei load balancer, che rischiano invece di essere sovraccaricati). Michael J.Freedman, spiega infatti che (si veda [4]): One can think of this as an overlay, but really, it means there is some software running on machines that act as service routers (much like DNS resolvers/nameservers or DHCP servers [...] These are only 'on-path' for the rst packet of each ow, unlike today's load balancers, which must be on-path for each packet. Inne, altra interessante miglioria, che potrebbe interessare in particolar modo i servizi di Cloud riguarda la migrazione delle macchine virtuali. Attualmente, qualora una organizzazione in possesso di diversi server, su ognuno dei quali sono in funzione più VM, abbia necessità di trasferirne una o più da un terminale ad un altro, dovrà necessariamente sospendere la comunicazione con i client che stavano interfacciandosi con la macchina in questione. 11

12 Figura 4: Migrazione VM tra diversi host. [2, Pag. 9] Tale inconveniente, potrebbe essere evitato se fosse possibile migrare le connessioni dei client implicati, verso altre VM. Ed è proprio in tal modo che Serval conta di risolvere tale problematica, oltre che riuscendo a diminuire il tempo di interruzione del servizio durante la migrazione della macchina. 12

13 2 Ripensare lo stack TCP/IP Le problematiche dello stack TCP/IP odierno, derivano prevalentemente dal fatto che, i concetti di indirizzo IP e porta, siano sovraccaricati dei più svariati signicati. Dierentemente, Serval, separa in modo netto il servizio dal usso dati corrispondente (relativo ad una specica socket) e dall'indirizzo di rete (che identica l'interfaccia dell'host). Di seguito sono riportati, per vari livelli dello stack, i cambiamenti che hanno luogo all'interno di quest'ultimi quando Serval è in funzione. Per maggiori informazioni, si veda [1, p. 2]. 2.1 Livello Applicazione Ad oggi, il livello applicativo, presenta le seguenti limitazioni: Indirizzo IP e port number, identicano solo in modo implicito il nome del servizio, che deve essere eventualmente risolto generando ulteriore traco (ad esempio tramite DNS), prima che la connessione possa aver luogo (early-binding). Le applicazioni utilizzano meccanismi di caching per velocizzare la risoluzione dei nomi, tuttavia, possono creare rallentamenti in caso di fallimento. Ogni socket, può essere legata al più ad un unico, immodicabile, indirizzo. In presenza del SAL, la necessità, all'interno delle applicazioni, di implementare alcuni meccanismi di risoluzione e di ottimizzazione della gestione del traco di rete, possono essere evitati o resi superui. In particolare, in termini di livello applicativo, l'introduzione del SAL comporta le seguenti migliorie: Grazie al concetto di servizio, attraverso il quale fa sì che l'ip sia trasparente alle applicazioni, è possibile risolvere l'indirizzo di rete, direttamente quando si instaura l'eettiva connessione tra gli host (late-binding). Tale questione è trattata in modo più approfondito nel paragrafo 4.1. In presenza di load balancer (ed eventualmente di NAT), la connessione può essere stabilita mediante l'invio di uno specico pacchetto (anycast-forwarded), senza che il restante traco debba attraversare il load balancer stesso. 13

14 2.2 Livello Trasporto Lo stack TCP/IP, a livello trasporto, fa uso della classica quintupla di elementi, formata da: IP mittente, porta mittente, IP destinatario, porta destinatario, protocollo. Tali informazioni, risultano necessarie per il demultiplexing dei pacchetti. In conseguenza di ciò, accade che: L'IP non può cambiare senza che le connessioni in corso siano interrotte; Le possibilità di mobilità e migrazione, sono pressoché nulle. Ad oggi, esistono diverse proposte per quanto riguarda l'integrazione della mobilità e del multihoming in TCP, ma nessuna ricopre tutti i possibili scenari in modo soddisfacente. Alcune soluzioni, prevedono che gli IP nella quintupla sopracitata possano cambiare dinamicamente, altre sostituiscono agli indirizzi altri identicatori, ma nessuna di queste soluzioni è in grado di supportare, oltre che TCP, altri protocolli di livello trasporto. Dierentemente, Serval, risolve il problema alla base, facendo sì che i protocolli di trasporto non si occupino del demultiplexing dei pacchetti, il quale ha luogo invece nel SAL grazie agli identicatori di servizio (serviceid) e di usso (owid). Così facendo, gli indirizzi di rete sono liberi di cambiare, e poiché il controllo del usso dati è relegato al SAL, tale soluzione può essere adottata con diversi protocolli di trasporto. 2.3 Livello Rete Dal momento che il SAL è posizionato al di sopra del livello rete, l'inoltro dei pacchetti, avviene così come previsto dal protocollo IP mediante una gestione gerarchica degli indirizzi. 14

15 3 Astrazione dei servizi e dei ussi 3.1 Service Naming Ogni servizio, è rappresentato da un nome di facile memorizzazione per gli utenti, e da un identicatore, che viene invece utilizzato dai dispositivi di rete e dai terminali, comunemente detto serviceid. Le istanze del servizio corrispondente, si aspettano dunque di ricevere in ingresso connessioni per quello specico identicatore, nascondendo ai client indirizzi e porti, garantendo dunque una certa essibilità. Seguendo la schematizzazione vista su [1, p. 3.1], è possibile discutere le seguenti caratteristiche: Granularità: Il concetto di servizio, realizza un'astrazione tale da nascondere l'eettiva tipologia del sistema complessivo, ad esempio: un service name può indierentemente rappresentare un singolo demone, un cluster di stampanti, un insieme di peer che distribuiscono lo stesso le o un normale servizio online distribuito su più macchine. In sostanza, la granularità del servizio è estranea ai client. Formato dell'identicatore: Di fondamentale importanza è la questione del naming. È necessario infatti, stabilire le dimensioni dei serviceid e decidere come questi debbano essere memorizzati. Gli sviluppatori di Serval, suggeriscono una soluzione che preveda un namespace di 256 bit, gestito eventualmente da autorità che si occupino della memorizzazione ed eventualmente di una suddivisione in blocchi, in base a dei pressi rappresentativi di speciche entità. È possibile in tal modo, adoperare una risoluzione gerarchica dei servizi, specialmente per quelle realtà che ne orono molteplici. Sicurezza e registrazione: Dal punto di vista della sicurezza, Serval, propone l'utilizzo di una bitstring alla ne del serviceid, ottenuta mediante crittograa hash di una chiave pubblica e del presso, rappresentativi del servizio. Tale meccanismo, non richiede la presenza di infrastrutture, ma soltanto una strategia per garantire che i serviceid vengano appresi attraverso canali sicuri e che la registrazione stessa dei servizi, avvenga mediante un sistema adabile di registrazione. Ad ogni modo, da questo punto di vista, Serval non impone alcuna politica di gestione dei serviceid, lasciando libere le imprese di scegliere come eettuare le registrazioni all'interno della propria rete. Tuttavia, va specicato che tali misure di sicurezza, non bastano ad assicurare che l'hoster del servizio sia autorizzato. Memorizzazione dei nomi: Anche per quanto riguarda questo aspetto, non vi è alcuna imposizione. Serval non si occupa di gestire 15

16 il mapping tra serviceid e service name, lasciando che sia l'utente a decidere come associare ad un identicatore un nome che possa essere facilmente memorizzato, mediante gli più svariati meccanismi (come accade ad esempio per DNS). 3.2 Flow Naming Serval fornisce un sistema di naming per il usso dati di una specica connessione, basato sul owid. Tramite tale identicatore, il SAL può eettuare il demultiplexing dei pacchetti, senza aver bisogno della classica quintupla di elementi di cui si è discusso nel paragrafo 3.2. In denitiva, il serviceid e il owid rappresentano tutto ciò che è necessario per l'inoltro dei pacchetti. Tali informazioni, vengono trasportate all'interno di uno specico header, posizionato tra quello del livello rete e quello del livello trasporto, come da immagine. Figura 5: Identicatori di Serval all'interno di un pacchetto (alcuni campi sono stati omessi per una migliore leggibilità). [1, Fig. 2] Possiamo quindi concludere che, come spiegato in [1, p. 3.2], Serval, tramite i suoi identicativi, implementa: Mobilità e multi-path: attraverso eventi che possano modicare l'interfaccia corrispondente ad un owid, o associando ad un'unica interfaccia più ussi che attraversino percorsi diversi. Inconsapevolezza del livello rete: i ussi dati sono identicati pur senza conoscere gli indirizzi IP corrispondenti, cosa che permette a Serval, di supportare indierentemente IPv4 e IPv6. Migrazione in presenza di NAT: un NAT consapevole della presenza del SAL, sostituisce l'indirizzo IP mittente, con l'ip pubblico (come di consueto) e il owid, unica informazione necessaria a destinazione per l'identicazione del usso dati corrispondente. In questo modo, può passare da una rete provvista di NAT all'altra, senza alcuna preoccupazione. 16

17 Sicurezza: dal momento che i owid possono essere generati casualmente, un identicatore sucientemente lungo, dovrebbe servire a proteggere da eventuali malintenzionati. Tuttavia, un owid troppo lungo, potrebbe generare un overhead eccessivo: per tale motivo, Serval adotta un owid di 32 bit più dei nonces che sono scambiati soltanto durante il setup della connessione e durante eventuali migrazioni. Port number non richiesto: il numero di porta, spesso identica anche il protocollo utilizzato per il usso dati verso l'applicazione (si pensi ad esempio al fatto che, il porto 80, è generalmente associato al protocollo HTTP). Il owid, invece, non tiene in alcun modo memoria del protocollo utilizzato, che può essere eventualmente specicato all'interno dell'apposito campo nel transport-header. 17

18 4 Inoltro dei pacchetti nello stack Serval Vedremo, nei paragra successivi, come Serval gestisce l'inoltro e il demultiplexing dei pacchetti all'interno delle reti, mediante i seguenti approcci e componenti: Scissione del control plane dal data plane; Service-controller, una componente che si occupa della risoluzione dei servizi, della gestione di particolari eventi, della comunicazione con gli altri controller; Service table che realizzano il mapping tra serviceid ed indirizzi di rete; Flow table che realizzano il mapping tra owid e socket; Meccanismi di comunicazione e segnalazione per la gestione di particolari eventi; Active socket per l'interazione tra le applicazioni. Figura 6: Stack Serval con le varie componenti che partecipano all'inoltro e alla gestione del traco. [1, Fig. 3] 18

19 4.1 Active Socket Le Active Socket, così come le socket BSD, su cui sono basate, vengono utilizzate per il passaggio dei dati da e verso le applicazioni, realizzando un'astrazione di un canale di comunicazione. Tali socket, si dierenziano da quelle classiche, per via del fatto che, le funzioni normalmente utilizzate per la gestione delle connessioni, hanno tra i parametri il serviceid, invece che gli indirizzi IP e il porto. Mediante un meccanismo di segnalazione eventi (si veda 4.4), Serval gestisce automaticamente la registrazione/deregistrazione dei servizi, quando vengono eseguite speciche operazioni sulle socket. Tipiche funzioni sono ad esempio: bind(): associa un indirizzo e un porto ad una socket (nel caso di Serval fa uso invece di un serviceid), su cui ci si pone in ascolto (l'evento generato da una chiamata alla funzione bind, causa una registrazione all'interno della service table che viene noticata al service-controller). close(): chiude la socket (causa una deregistrazione all'interno della service table che viene noticata al service-controller). connect(): chiamata utilizzata dai client per connettersi ad una speci- ca socket. accept(): accetta la prima connessione in coda. sendto(): invia i dati verso la specica destinazione. Figura 7: Dierenze d'utilizzo delle socket BSD classiche rispetto a quelle modicate da Serval per il funzionamento tramite serviceid. [1, Tab. 1] 19

20 Le applicazioni che fanno uso di tali funzioni, di conseguenza, non hanno visibilità dell'indirizzo di rete (dal momento che è il SAL ad occuparsi della risoluzione del serviceid nell'indirizzo corrispondente). Questo, non solo fa sì che gli IP possano cambiare liberamente, ma consente anche di eettuare il late binding, ovvero di mappare l'identicatore del servizio sul corrispondente indirizzo, solo all'atto di una connetct() o di una sendto(). 4.2 Forwarding e data plane L'instaurazione di una nuova connessione, mediante l'invio di uno specico pacchetto, comporta che venga eettuata una ricerca all'interno della service table dello specico serviceid contenuto all'interno dell'header Serval, mediante LPM (longest prex matching). Vari servizi infatti, possono avere lo stesso presso, poiché appartenenti alla stessa entità. Come è possibile notare guardando la Figura 6, la service table è composta da 3 campi, di cui il campo Action, il quale può assumere 4 diversi valori: FORWARD: viene utilizzato per l'inoltro di un pacchetto tramite il livello rete ad uno o più indirizzi. Sia il mittente, sia eventuali hop SAL intermedi o eventuali dispositivi di rete, presentano tuple all'interno della propria service table con ruolo impostato su FORWARD, contribuendo all'invio del pacchetto verso la specica destinazione. Tali hop, si comportano eettivamente come fossero dei service router. DEMUX: è il ruolo presente nella service table del destinatario, per poter smistare i pacchetti ricevuti verso la socket presso la quale la specica applicazione è in ascolto per quel serviceid. Una chiamata alla funzione bind() (si veda 4.1) fa sì che all'interno della service table, venga aggiunta una nuova voce con ruolo DEMUX per quel servizio, viceversa, una chiamata alla funzione close(), causa l'eliminazione della stessa. Figura 8: Aggiunta e rimozione di un ruolo DEMUX nella service table per il servizio X. [2, Pag ] 20

21 DELAY: un pacchetto il cui serviceid trova nella service table in sua corrispondenza una action DELAY, viene messo in coda ed una notica viene inviata al service controller. Tale ruolo, viene ad esempio utilizzato per una risoluzione ritardata (si veda 4.3). DROP: utilizzato semplicemente per scartare i pacchetti per uno speci- co servizio. Va specicato che, di default, ogni volta che un interfaccia si connette alla rete, un ruolo FORWARD viene inserito nella service table, cui corrisponde l'indirizzo di broadcast per l'interfaccia. Di seguito è illustrato un esempio di come avviene l'inoltro di un pacchetto: Figura 9: Inoltro di un pacchetto tra due terminali attraverso un service router intermedio. [1, Fig. 4] 1. Un client stabilisce una connessione per il servizio X, per il quale è presente nella service table un ruolo FORWARD verso il nodo b. 2. Il nodo intermedio, riceve il pacchetto; per lo specico serviceid ha nella sua service table un ruolo FORWARD. Il pacchetto viene dunque inoltrato verso il nodo g. 3. A destinazione, un ruolo DEMUX smista il pacchetto verso la socket sulla quale l'applicazione è in ascolto. Un esempio più complesso, è mostrato in Figura 10. Nell'esempio, un client richiede di poter usufruire di un servizio X, disponibile su due diversi server, allora il SAL assegna un owid ed un nonce generato casualmente (per proteggere da eventuali attacchi) alla socket corrispondente, ed una nuova tupla è aggiunta alla ow table. 21

22 Figura 10: Connessione ad un servizio X da parte del client a, tramite inoltro del pacchetto SYN. I ruoli indicato con ' * ' sono quelli di default. [1, Fig. 5] 1. Il SAL del client, cerca il serviceid all'interno della service table, ed inoltra la richiesta verso il nodo b (indicato come indirizzo per il ruolo FORWARD di default). 2. Il SR (service router) b, trova all'interno della propria service table, un ruolo FORWARD verso un ulteriore nodo, detto e. Reinoltra dunque il pacchetto sovrascrivendo l'indirizzo destinazione. 3. Il forwarding del pacchetto continua ricorsivamente attraverso il nodo e ed altri, nché non raggiunge il terminale g in ascolto sulla socket. 4. Il nodo g, crea quindi una nuova socket da utilizzare per l'invio della risposta al pacchetto SYN ricevuto, aggiornando la propria ow table. 5. Il pacchetto SYN-ACK generato da g, contiene il suo indirizzo di rete, il owid ed il nonce. Tale pacchetto, e tutti quelli che seguiranno, saranno scambiati in modo diretto tra i due host, senza che debbano attraversare i SR intermedi (b ed e). Va inoltre specicato, che il demultiplexing dei pacchetti successivi potrà essere eettuato pur senza l'invio del SAL header, essendo ormai noto il owid. 22

23 4.3 Service discovery e registration Al ne di poter gestire situazioni dierenti, Serval, supporta diverse modalità di registrazione e risoluzione dei servizi. Sono infatti i service controller a gestire le service table, ed eventualmente a propagarle verso altri service controller. È possibile distinguere diversi scenari: Risoluzione e routing in larga scala (wide-area): ogni qual volta una nuova istanza di un servizio è disponibile, il service controller si occupa di propagare l'informazione agli altri controller, permettendo così che il servizio possa essere raggiunto. Mediante l'utilizzo dei pressi, organizzazioni che forniscono molteplici servizi, possono organizzare i propri resolvers. Servizi nelle reti ad-hoc: essendo prive di infrastrutture di rete, le informazioni sui servizi devono essere propagate tramite ooding. Eventuali richieste vengono quindi inviate in broadcast, in attesa di risposte da istanze del servizio richiesto. Lato server, all'atto di una registrazione, il service controller può: inserire un ruolo DEMUX nella service table, propagare la registrazione agli altri controller (che potranno quindi installare nelle proprie service table un ruolo FOR- WARD). Viceversa, all'atto di una deregistrazione. Risoluzione con lookup server (on demand): come spiegato nel paragrafo 4.2, uno dei possibili ruoli per una tupla all'interno della service table, è DELAY. Tale ruolo, fa sì che i pacchetti corrispondenti al servizio, vengano messi in coda, in attesa ad esempio che il service controller si occupi della risoluzione. Una volta che tale risoluzione ha avuto luogo, i DELAY corrispondenti possono essere sostituiti con ruoli FORWARD per permettere l'inoltro dei pacchetti. Un approccio che prevede simili meccanismi, è quello con lookup server: i client interessati, inoltrano il pacchetto SYN verso il server in questione, il quale prima li mette in coda (DELAY) ed una volta eettuata la risoluzione, li inoltra (FORWARD) verso il servizio destinazione. 23

24 4.4 Meccanismi di segnalazione eventi I meccanismi di segnalazione, per la gestione di particolari eventi all'interno dello stack, sono fondamentali per garantire la essibilità e il dinamismo messi a disposizione dal SAL, in particolar modo per una corretta gestione della mobilità e della migrazione in presenza di più ussi dati. I protocolli utilizzati in Serval, si dierenziano dai classici meccanismi solitamente adottati in TCP. Prima di tutto, i messaggi di controllo viaggiano separati dai dati ed hanno un proprio sequence number, cosa che non accade ad esempio nei più comuni MPTCP e TCP Migrate, i quali possono inviare messaggi di controllo solo all'interno dei pacchetti dati, inoltre diversi protocolli di trasporto sono supportati grazie alla presenza del SAL che gestisce i ussi dati ad un livello più basso, e per lo stesso motivo migrazione e ussi multipli sono ammissibili. Per maggiori informazioni si veda [1, p. 4.4]. Per meglio illustrare le possibilità messe a disposizione da Serval, in termini di multihoming, multipath e migrazione, si faccia riferimento all'esempio riportato nella gura sottostante: Figura 11: Esempio di comunicazione multipath (con possibilità di migrazione) in presenza di terminali multihomed. [1, Fig. 6] Multipath e multihoming: in presenza di diverse interfacce di rete, possono essere instaurati più ussi dati lungo percorsi diversi. Si faccia riferimento all'esempio di Figura 11: i due host, posseggono ambedue una coppia di interfacce (a1 e a2 per il client Host C, a3 e a4 per server Host S). Il primo usso viene instaurato quando il client richiede di connettersi, usando ad esempio l'interfaccia a1 con owid fc1, che lato server corrispondono all'interfaccia a3 con owid fs1. Ogni qual volta viene inviato un pacchetto, all'interno del SAL extension header, gli host possono indicare eventuali altre interfacce disponibili per la connessione per dare la possibilità di creare più ussi dati. In questo caso ad esempio, qualora Host S lo segnali ad Host C, quest'ultimo potrebbe decidere di instaurare una nuova connessione tra le interfacce a2 e a4. 24

25 Migrazione: essendo il livello trasporto ignaro della gestione del owid da parte del SAL, è possibile migrare ussi dati da una interfaccia all'altra, su percorsi diversi o verso un altro indirizzo. Ovviamente, eventuali migrazioni possono inuire sulle prestazioni, e ridurre la banda a disposizione per il trasferimento dati. Per questo motivo, il SAL può noticare a livello trasporto l'avvio di una migrazione, così che questa possa essere gestita in modo adeguato. Facendo riferimento all'esempio di Figura 11, immaginiamo che improvvisamente l'interfaccia a3 del server smetta di funzionare. Per non interrompere la connessione, il server può migrare il usso dati su un'altra interfaccia, ad esempio a4. Tale migrazione avviene mediante l'invio da parte del server, di un pacchetto di risincronizzazione detto RSYN, contenente i owid della connessione corrente (fc1 e fs1) nonché l'indirizzo della nuova interfaccia (a4). Il client invia quindi un RSYN-ACK per noticare al server il proprio assenso alla migrazione, ed attende un ulteriore conferma da parte di quest'ultimo. La presenza di un sequence number all'interno dei pacchetti di sincronizzazione, assicura che questa vada a buon ne anche nel caso in cui arrivino fuori ordine (eventualità rara ma possibile). 25

26 5 Prototipo dell'architettura Attraverso la prototipazione dell'architettura, gli sviluppatori, si sono resi conto man mano di quelle che sono le potenzialità di Serval e i beneci che può apportare in termini di dinamicità, prestazioni e quant'altro. Attualmente, il prototipo disponibile, supporta: migrazione, SAL forwarding (comprensivo di service table con ruoli FORWARD e DEMUX, risoluzione dei servizi e meccanismi di segnalazione) ed altre funzionalità. Tuttavia, non è ancora possibile far uso del multi-path, che gli sviluppatori progettano di aggiungere in futuro. Inoltre, la presenza del service controller (che interagisce a sua volta con lo stack mediante una particolare socket), permette una gestione dinamica delle service table in presenza delle chiamate a funzioni bind(), connect() etc. Attualmente sono supportati i protocolli di livello trasporto TCP e UDP. Per maggiori informazioni su come Serval sia giunto all'architettura attuale attraverso le varie prototipazioni susseguitesi, si veda [1, p. 5.1]. 5.1 Benchmark performance Gli sviluppatori di Serval, si sono preoccupati dell'esecuzione di alcuni test che mostrassero in termini di throughput, pacchetti inviati, data loss, deviazione standard, le prestazioni di uno stack modicato dal SAL, rispetto ad un classico TCP/IP. Figura 12: Statistiche di confronto tra connessioni tramite stack TCP/IP nativo e con SAL. [1, Tab. 2] I dati mostrati, sono relativi a test di 10 secondi, eseguiti mediante tool iperf su macchine con 2 CPU Intel 2.4GHz ed interfaccia GigE con sistema operativo Ubuntu Si consideri nel valutare i risultati ottenuti da Serval, che alcune ottimizzazioni non sono ancora implementate. Sono inoltre riportati nella tabella in Figura 12, i risultati in presenza di un translator, ovvero una componente che si occupa del rendere possibile una comunicazione tra host che implementano l'architettura Serval ed host che fanno uso del classico stack TCP/IP (si veda il paragrafo 7). 26

27 La seconda parte della tabella in Figura 12, mostra i risultati ottenuti nell'inoltro di alcuni pacchetti con payload da 48 byte gestiti dal SAL, rispetto ad altri inviati con l'approccio attuale previsto da IP. Gli sviluppatori condano di poter colmare il divario presente, specialmente in termini di packet-rate, con le future ottimizzazioni. 6 Casi di studio Per dimostrare l'ecacia di Serval in una serie di casi possibili, gli sviluppatori hanno realizzato dei test su sistemi realmente funzionanti, di svariati tipi. Di seguito sono riportati i risultati ed una serie di considerazioni derivanti da tali test, per diversi utilizzi di Serval in ambito server. 6.1 Web Service replicato con load balancing In questo esperimento, si fa uso di un web-cluster con architettura Serval, per mostrare i vantaggi che quest'ultimo può apportare all'interno di una simile architettura. Supponiamo, che 4 client invino richieste verso il web service, il quale gira su diverse istanze di un web server Mongoose. Tutti gli host, sono connessi allo stesso switch di rete ToR GigE. Il load balancing, è a carico di un singolo service router, che si occupa della risoluzione delle richieste. Per illustrare i risultati ottenuti, si faccia riferimento alla seguente immagine, considerando che ogni client richiede un le di 3MB su una nestra di 20 richieste HTTP, al ne di saturare la banda a disposizione. Figura 13: Relazione tra request rate e throughput in presenza di più istanze di servizio. [1, Fig. 7] 27

28 Distinguiamo situazioni dierenti, in base alle istanze del servizio disponibili, in particolare: 0-60 secondi: due istante di servizio servono un totale di 80 richieste al secondo (20 per client), raggiungendo un throughput di circa 1.8Gbps; secondi: dopo 60 secondi, due nuove istanze di servizio si registrano presso il service router, ed iniziano a servire richieste. Si ottiene così un request rate di 160 req/s ed un throughput di circa 3.6Gbps; secondi: le prime due istanze di servizio, vengono stoppate. Dunque, eseguono la deregistrazione e servono le ultime richieste pendenti. I risultati ottenuti in termini di request rate e throughput sono comparabili a quelli ottenuti nei primi 60 secondi (avendo lo stesso numero di istanze attive); secondi: una terza istanza viene avviata su uno dei server disponibili, ottenendo così migliori prestazioni (120 req/s e 2.7Gbps). Dall'esperimento si capisce dunque, come Serval sia in grado di gestire senza l'uso di un costoso load balancer, un notevole carico di richieste riuscendo a distribuirle in modo adeguato sui server disponibili ed ottenendo ottimi risultati in termini di throughput e request rate (tali da saturare la banda disponibile). Il tutto, ricordando che il service router, non è altro che un nodo coinvolto nella sola registrazione e risoluzione dei servizi (attraversato unicamente dal primo pacchetto di una connessione e non dall'interno traco generato dal trasferimento dei dati). 6.2 Storage distribuito Si illustra di seguito, l'impiego di Serval in un sistema di storage basato su Memcached. Memcached fornisce un servizio di caching, basato sull'utilizzo di alcune chiavi, tramite le quali un algoritmo di risoluzione, fa corrispondere speciche partizioni distribuite su più server. Tramite una mappa, il client può individuare il server contenente la partizione di interesse, ed inviare ad esso le sue richieste. Tuttavia, la staticità di questo approccio, complica la gestione dei server quando se ne vogliano aggiungere o sottrarre, o nel caso in cui si voglia ripartizionare lo spazio. Con Serval, il mapping delle partizione può avvenire dinamicamente: i client possono inoltrare le proprie richieste al service router indicando un serviceid con presso comune a Memcached, seguito dalla chiave del contenuto. Il mapping tra il serviceid e la partizione corrispondente alla chiave, avviene mediante LPM nella service table. Le richieste possono quindi essere 28

29 inoltrate verso il server, il quale di qui in poi, comunicherà in modo diretto col client. Nel caso in cui un nuovo server si registri alla rete, le partizioni possono essere semplicemente riassegnate modicando la service table, tuttavia, con tale approccio, non avendo i client visibilità diretta del server (ma solo del servizio) non possono aggregare richieste (si richiede che sia il service router ad occuparsene). L'immagine sottostante, riporta i risultati ottenuti per l'esperimento, in presenza di 4 server ed un client (con un service router intermedio). Il client ed il service router sono su macchine con le stesse speciche indicate per i benchmark del paragrafo 5.1, mentre i server hanno le seguenti speciche: due CPU AMD Opteron 2.4GHz quad-core con interfaccia GigE. Il service router, assegna un totale di 16 partizioni (4 per ogni server), le cui chiavi sono codicate sugli ultimi 4 bit del presso del serviceid. Figura 14: Gestione Serval delle partizioni sotto Memcached, in presenza di 4 server. [1, Fig. 8] Anche in questo caso, come nell'esperimento precedente, distinguiamo diverse situazioni in base ai server disponibili nei vari intervalli di tempo: 0-10 secondi: inizialmente, tutti i server sono in funzione; secondi: dopo circa 10 secondi, un server viene rimosso (server 3) ed il service router ridistribuisce le 4 partizioni del server rimosso tra quelli rimanenti; secondi: dopo 20 secondi, un altro server viene rimosso (server 2) e le partizioni corrispondenti distribuite sui due server rimanenti; 29

30 30-40 secondi: il server 3, si registra nuovamente alla rete dopo circa 30 secondi, il carico dovuto alla gestione delle partizioni viene ridistribuito; secondi: il server 4 si registra nuovamente, e si torna alla situazione iniziale. 6.3 Migrazione ussi e macchine virtuali Nel seguito, sono illustrati in breve, esperimenti che mostrano come Serval possa gestire la migrazione di ussi dati su diverse interfacce, o di vere e proprie macchine virtuali, situazione particolarmente di interesse ad esempio per i servizi di cloud. Nel primo caso, abbiamo un server (sul quale è lanciato iperf) con due interfacce di rete GigE, che serve due client. Tali interfacce, possono garantire una velocità a piena banda, di 1Gbps. Figura 15: Miglioramenti in termini di throughput dovuti alla migrazione del usso dati del secondo client sulla seconda interfaccia. [1, Fig. 9] Inizialmente, i ussi di entrambi i client sono diretti verso un'unica interfaccia server, raggiungendo una velocità di circa 500Mbps (e dunque in totale di 1Gbps). Dopo 6 secondi, il service controller segnala al SAL di voler migrare uno dei ussi sulla seconda interfaccia. Trascorso un breve periodo, necessario per l'assestamento della velocità di trasmissione, entrambi i client ottengono una velocità pari a 1Gbps (2Gbps totali), raddoppiando dunque il throughput rispetto alla situazione iniziale. 30

31 Un possibile uso della migrazione oerta da Serval, utile in particolar modo a fornitori di servizi cloud, è quello in cui una macchina virtuale, debba essere trasferita da un host all'altro senza una interruzione del usso dati. Figura 16: Flusso dati, in presenza di una migrazione. [1, Fig. 10] Come l'immagine suggerisce, il usso dati subisce un lieve rallentamento ed una breve interruzione, nel periodo in cui un nuovo indirizzo di rete viene assegnato alla macchina virtuale, e mentre viene eettuata la risincronizzazione. 31

32 7 Translator per compatibilità con host legacy L'integrazione di Serval all'interno dello stack TCP/IP, risulta essere piuttosto semplice, tuttavia, per ovvi motivi, è necessario garantire compatibilità anche con host che presentano uno stack privo del SAL. Per questo motivo, sono stati sviluppati dei translators, attraverso i quali è possibile risolvere tale problematica. In particolar modo, il translator TCP-to-Serval, può tradurre una normale connessione basata su TCP (senza SAL), in una connessione adatta ad essere gestita da uno stack Serval. Un translator Serval-to-TCP, eettua invece l'operazione inversa. [1, p. 7] - [5, p. 3.1] TCP-to-Serval (lato client): per poter eettuare la traduzione, il translator (che in questo caso è un middlebox lato client) ha bisogno di conoscere quale servizio il client desidera utilizzare, e di ricevere i pacchetti relativi al usso dati associato. Il translator, agisce non molto dierentemente da un recursive DNS, utilizzando i nomi dei domini cui il client desidera connettersi, come nomi del servizio richiesto. Il translator, mappa quindi tali nomi su un indirizzo IP privato. TCP-to-Serval (lato server): alcune grandi organizzazioni, che permettono la fruizione di una molteplicità di servizi, potrebbero pensare di implementare un proprio translator, presso i propri PoP (Points of presence). Tale approccio, prevede una architettura siatta: Figura 17: Comunicazione client-server mediante translator lato server. Solo il primo pacchetto attraversa il service router, i restanti solo il translator. [5, Fig. 2] In una situazione simile, il client ovviamente non conosce il serviceid, ma piuttosto risolve tramite DNS l'indirizzo IP di una specica macchina. Ogni server che permette l'utilizzo del servizio è associato ad un IP pubblico e ad una porta. Tuttavia, l'ip che il client scopre, non 32

33 corrisponde ad una delle macchine del servizio, bensì al translator. Quest'ultimo, riceve dunque tutto il traco generato dalle richieste dei client, e tramite una tabella mappa l'ip e la porta richiesti dal client sul corretto serviceid, come mostrato nell'immagine sottostante. Figura 18: Tabella per il mapping di IP e porta sul corretto serviceid. [5, Fig. 1] Riconosciuto il serviceid corretto, il translator, invia una richiesta di connessione mediante Serval, al service router della rete. Il service router a sua volta, decide per quale server della rete stabilire la connessione. Una volta stabilita la connessione, i pacchetti successivi, potranno essere trasferiti senza attraversare il service router, mentre dovranno sempre essere gestiti dal translator, il quale mantiene una connessione classica verso il client ed una basata su Serval, verso il server che fornisce il servizio. Per le strategie di realizzazione di un translator, si veda [5, p. 4]. Serval-to-TCP/UDP: un translator di questo tipo, funziona in modo molto simile a quanto visto per il TCP-to-Serval. È piuttosto interessante valutare la possibilità di utilizzare una coppia di translator in serie, al ne di poter usufruire delle funzionalità messe a disposizione da uno stack Serval, ad esempio: si immagini un client privo di SAL, che stabilisca una connessione verso una specica destinazione. I pacchetti inviati, attraversano prima un translator TCP-to-Serval e poi un translator Serval-to-TCP, al ne di inoltrare a destinazione pacchetti mediante una connessione legacy. Così facendo, pur essendo il client un dispositivo non modicato, potrà usufruire dei vantaggi tipici dell'architettura Serval, grazie alla presenza dei translator. 33

34 8 Dimostrazioni e test di funzionamento Di seguito, sono riportati alcuni esempi e test dimostrativi eettuati, al ne di mostrare il funzionamento di Serval in alcuni scenari d'uso comune. Tutte le istruzioni riportare, fanno chiaramente riferimento a le generati tramite il processo di compilazione, primo passo da eseguire, così come accennato nel paragrafo (si consiglia ad ogni modo di far riferimento alla pagina Serval su Github e al relativo Wiki). I comandi vengono lanciati dall'interno della directory principale di Serval, comunemente chiamate servalmaster. Serval, può essere avviato in due dierenti modalità: come modulo del Kernel Linux, o in user-space. Tutti gli esempi riportati di seguito, sono stati eseguiti lanciando Serval in user-space. Avvio di Serval tramite caricamento del modulo nel Kernel: # insmod./src/stack/serval.ko Per controllare che il modulo sia stato eettivamente caricato: $ lsmod grep serval Avvio di Serval in user-space: #./src/stack/serval -i INTERFACCIA -d Una lista delle interfacce disponibili si può ottenere lanciando ifcong. L'opzione d, lancia Serval in background, come demone. Serval fornisce anche un demone (il cui uso è opzionale), detto servd, utile alla gestione degli eventi, poiché segnala registrazioni e deregistrazioni dei servizi al service router di competenza. È possibile specicare alcune opzioni per servd, creando il le /usr/local/etc/servd.conf. Per lanciare il demone: #./src/servd/servd L'opzione -rip può essere specicata per indicare esplicitamente l'ip del service router (che servd trova da solo qualora sia nella stessa sottorete, diversamente è necessario indicarlo in modo esplicito). Per maggiori informazioni, si lanci servd -h. 34

35 Una volta avviato il demone, è possibile visualizzare service e ow table, lanciando: $ telnet Figura 19: Service e ow table, visualizzate tramite telnet. Prima di iniziare, potrebbe essere utile aggiungere una entry d'esempio nella service table per il serviceid 76568: $./src/tools/serv service add IP_SERVER 8.1 Catturare pacchetti Serval con Wireshark Di base, Wireshark, noto programma per l'analisi del traco di rete, non è in grado di individuare all'interno dei pacchetti il SAL (e dunque header ed estensioni realtive). Tuttavia, è possibile istruire Wireshark anché sia in grado di individuare correttamente pacchetti Serval. Per farlo, è necessario un dissector. Un dissector non è altro che uno script, programmato in LUA, contenente le direttive necessarie per la corretta decodica di talune caratteristiche dei pacchetti nel traco di rete. Per maggiori informazioni, si veda [6]. Un dissector attraverso il quale è possibile decodicare correttamente pacchetti Serval, è stato realizzato da Isaakidis Marios (misaakidis) nell'ambito del suo progetto ServalDHT e distribuito sotto licenza GNU General Public License. Il le.lua, è disponibile tra i le del progetto sotto la directory: serval/src/serval_wireshark_dissector.lua Scaricato il le, è necessario istruire Wireshark anché ne faccia uso per la decodica dei pacchetti. Wireshark, all'avvio, carica alcuni script in base alle direttive che sono contenute nel le init.lua, dunque, per far uso del dissector, si lancino si seguenti comandi: 35

36 # cp serval_wireshark_dissector.lua /usr/share/wireshark # nano /usr/share/wireshark/init.lua Inserire alla ne del le la direttiva: dofile(data_dir.."serval_wireshark_dissector.lua") Wireshark, sarà adesso in grado di individuare il SAL. In alternativa, si faccia uso di tshark (la versione a riga di comando di Wireshark). Il comando da eseguire per catturare pacchetti Serval è il seguente: $ tshark -i INTERFACCIA -X lua_script:serval_wireshark_dissector.lua Come mostra la gura seguente, Wireshark individua correttamente il SAL. Figura 20: Pacchetto Serval individuato da Wireshark. 36

37 8.2 Invio di un le Serval, mette a disposizione una serie di semplici programmi di test, al ne di vericare il corretto funzionamento di talune funzionalità. In questo esempio, verrà mostrato come, degli host Serval, possano scambiarsi un le come se questo fosse fornito dal servizio. Si noti che, qualora i due host si trovino in sottoreti diverse, sarà necessario aggiungere nella service table, una entry che indichi presso quale indirizzo raggiungere il servizio relativo al serviceid indicato. Supponendo di voler inviare un le.jpg contenuto nella cartella Immagini di nome dark_side.jpg, lato server si lanci: $./src/test/tcp_server_user -s f /home/user/immagini/dark_side.jpg Lato client invece, si può scaricare il le mediante il seguente comando: $./src/test/tcp_client_user -s f /home/user/scrivania/serval_test.jpg Figura 21: Invio di un le tramite stack Serval. 37

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

CORSO DI RETI SSIS. Lezione n.2. 2 Novembre 2005 Laura Ricci

CORSO DI RETI SSIS. Lezione n.2. 2 Novembre 2005 Laura Ricci CORSO DI RETI SSIS Lezione n.2. 2 Novembre 2005 Laura Ricci IL DOMAIN NAME SYSTEM (DNS) Indirizzi IP poco adatti per essere memorizzati da utenti umani è prevista la possibiltà di associare nomi simbolici

Dettagli

La nascita di Internet

La nascita di Internet La nascita di Nel 1969 la DARPA (Defence Advanced Research Project Agency) studia e realizza la prima rete per la comunicazione tra computer (ARPAnet) fra 3 università americane ed 1 istituto di ricerca.

Dettagli

Laboratorio del corso Progettazione di Servizi Web e Reti di Calcolatori Politecnico di Torino AA 2014-15 Prof. Antonio Lioy

Laboratorio del corso Progettazione di Servizi Web e Reti di Calcolatori Politecnico di Torino AA 2014-15 Prof. Antonio Lioy Laboratorio del corso Progettazione di Servizi Web e Reti di Calcolatori Politecnico di Torino AA 2014-15 Prof. Antonio Lioy Soluzioni dell esercitazione n. 2 a cura di Giacomo Costantini 19 marzo 2014

Dettagli

Protocolli di Comunicazione

Protocolli di Comunicazione Protocolli di Comunicazione La rete Internet si è sviluppata al di fuori dal modello ISO-OSI e presenta una struttura solo parzialmente aderente al modello OSI. L'architettura di rete Internet Protocol

Dettagli

Concetti fondamentali. Indirizzamento. Multicast su LAN. Multicast su Internet. RTP/RTCP su multicast IP. Ostacoli all'utilizzo del multicast

Concetti fondamentali. Indirizzamento. Multicast su LAN. Multicast su Internet. RTP/RTCP su multicast IP. Ostacoli all'utilizzo del multicast Migliore uso della banda alla sorgente Unicast Multicast 4 Concetti fondamentali Indirizzamento Unicast Multicast su LAN Multicast su Internet Host Migliore uso della banda alla sorgente Router Protocolli

Dettagli

Corso di Sistemi di Elaborazione delle informazioni

Corso di Sistemi di Elaborazione delle informazioni Corso di Sistemi di Elaborazione delle informazioni Reti di Calcolatori Claudio Marrocco Componenti delle reti Una qualunque forma di comunicazione avviene: a livello hardware tramite un mezzo fisico che

Dettagli

Come si può notare ogni richiesta ICMP Echo Request va in timeout in

Come si può notare ogni richiesta ICMP Echo Request va in timeout in Comandi di rete Utility per la verifica del corretto funzionamento della rete: ICMP Nelle procedure viste nei paragrafi precedenti si fa riferimento ad alcuni comandi, come ping e telnet, per potere verificare

Dettagli

Classe bit: 0 1 2 3 4 8 16 24 31. 0 net id host id. 1 0 net id host id. 1 1 0 net id host id. 1 1 1 0 multicast address

Classe bit: 0 1 2 3 4 8 16 24 31. 0 net id host id. 1 0 net id host id. 1 1 0 net id host id. 1 1 1 0 multicast address CAPITOLO 11. INDIRIZZI E DOMAIN NAME SYSTEM 76 Classe bit: 0 1 2 3 4 8 16 24 31 A B C D E 0 net id host id 1 0 net id host id 1 1 0 net id host id 1 1 1 0 multicast address 1 1 1 1 0 riservato per usi

Dettagli

Introduzione. Livello applicativo Principi delle applicazioni di rete. Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio 2-1

Introduzione. Livello applicativo Principi delle applicazioni di rete. Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio 2-1 Introduzione Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio Livello applicativo Principi delle applicazioni di rete 2-1 Pila di protocolli Internet Software applicazione: di

Dettagli

La classificazione delle reti

La classificazione delle reti La classificazione delle reti Introduzione Con il termine rete si intende un sistema che permette la condivisione di informazioni e risorse (sia hardware che software) tra diversi calcolatori. Il sistema

Dettagli

10. Stratificazione dei protocolli

10. Stratificazione dei protocolli 10. Stratificazione dei protocolli 10.1. Introduzione Abbiamo visto la struttura dell'internet. Ora dobbiamo esaminare la struttura del restante software di comunicazione, che è organizzato secondo il

Dettagli

LAN MAN WAN. Una internet è l'insieme di più reti reti distinte collegate tramite gateway/router

LAN MAN WAN. Una internet è l'insieme di più reti reti distinte collegate tramite gateway/router Rete di reti (interrete, internet) 2 Prof. Roberto De Prisco TEORIA - Lezione 8 Rete di reti e Internet Università degli studi di Salerno Laurea e Diploma in Informatica Una rete di comunicazione è un

Dettagli

Internet, così come ogni altra rete di calcolatori possiamo vederla suddivisa nei seguenti componenti:

Internet, così come ogni altra rete di calcolatori possiamo vederla suddivisa nei seguenti componenti: Pagina 1 di 8 Struttura di Internet ed il livello rete Indice Struttura delle reti Estremità della rete Il nucleo della rete Reti a commutazione di pacchetto e reti a commutazione di circuito Funzionalità

Dettagli

4 - Il livello di trasporto

4 - Il livello di trasporto Università di Bergamo Dipartimento di Ingegneria Gestionale e dell Informazione 4 - Il livello di trasporto Architetture e Protocolli per Internet Servizio di trasporto il livello di trasporto ha il compito

Dettagli

Reti di Calcolatori. Lezione 2

Reti di Calcolatori. Lezione 2 Reti di Calcolatori Lezione 2 Una definizione di Rete Una moderna rete di calcolatori può essere definita come: UN INSIEME INTERCONNESSO DI CALCOLATORI AUTONOMI Tipi di Rete Le reti vengono classificate

Dettagli

Reti. Reti. IPv4: concetti fondamentali. arp (address resolution protocol) Architettura a livelli (modello OSI)

Reti. Reti. IPv4: concetti fondamentali. arp (address resolution protocol) Architettura a livelli (modello OSI) Reti Architettura a livelli (modello OSI) Prevede sette livelli: applicazione, presentazione, sessione, trasporto, rete, collegamento dei dati (datalink), fisico. TCP/IP: si può analizzare in maniera analoga

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca. Parte II Lezione 1

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca. Parte II Lezione 1 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Parte II Lezione 1 Martedì 4-03-2014 1 TESTO DI RIFERIMENTO RETI DI CALCOLATORI

Dettagli

Iptables. Mauro Piccolo piccolo@di.unito.it

Iptables. Mauro Piccolo piccolo@di.unito.it Iptables Mauro Piccolo piccolo@di.unito.it Iptables Iptables e' utilizzato per compilare, mantenere ed ispezionare le tabelle di instradamento nel kernel di Linux La configurazione di iptables e' molto

Dettagli

TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI

TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI Confronto tra ISO-OSI e TCP/IP, con approfondimento di quest ultimo e del livello di trasporto in cui agiscono i SOCKET. TCP/IP

Dettagli

Reti di Calcolatori 18-06-2013

Reti di Calcolatori 18-06-2013 1. Applicazioni di rete [3 pts] Si descrivano, relativamente al sistema DNS: Compito di Reti di Calcolatori 18-06-2013 a) i motivi per i quali viene usato; b) l architettura generale; c) le modalità di

Dettagli

Livello Trasporto. Liv. Applic. Liv. Transport. Transport Entity. Liv. Network. Trasporto

Livello Trasporto. Liv. Applic. Liv. Transport. Transport Entity. Liv. Network. Trasporto Livello Trasporto Fornire un trasporto affidabile ed efficace dall'host di origine a quello di destinazione, indipendentemente dalla rete utilizzata Gestisce una conversazione diretta fra sorgente e destinazione

Dettagli

Modulo 8. Architetture per reti sicure Terminologia

Modulo 8. Architetture per reti sicure Terminologia Pagina 1 di 7 Architetture per reti sicure Terminologia Non esiste una terminologia completa e consistente per le architetture e componenti di firewall. Per quanto riguarda i firewall sicuramente si può

Dettagli

Protocolli di rete. Vittorio Maniezzo Università di Bologna. Vittorio Maniezzo Università di Bologna 02 Protocolli - 2/30

Protocolli di rete. Vittorio Maniezzo Università di Bologna. Vittorio Maniezzo Università di Bologna 02 Protocolli - 2/30 Protocolli di rete Vittorio Maniezzo Università di Bologna Vittorio Maniezzo Università di Bologna 02 Protocolli - 1/30 Strati di protocolli (Protocol Layers) Le reti sono complesse Molti elementi: host

Dettagli

C) supponendo che la scuola voglia collegarsi in modo sicuro con una sede remota, valutare le possibili soluzioni (non risolto)

C) supponendo che la scuola voglia collegarsi in modo sicuro con una sede remota, valutare le possibili soluzioni (non risolto) PROGETTO DI UNA SEMPLICE RETE Testo In una scuola media si vuole realizzare un laboratorio informatico con 12 stazioni di lavoro. Per tale scopo si decide di creare un unica rete locale che colleghi fra

Dettagli

Indirizzi Internet e. I livelli di trasporto delle informazioni. Comunicazione e naming in Internet

Indirizzi Internet e. I livelli di trasporto delle informazioni. Comunicazione e naming in Internet Indirizzi Internet e Protocolli I livelli di trasporto delle informazioni Comunicazione e naming in Internet Tre nuovi standard Sistema di indirizzamento delle risorse (URL) Linguaggio HTML Protocollo

Dettagli

Reti basate sulla stack di protocolli TCP/IP

Reti basate sulla stack di protocolli TCP/IP Reti basate sulla stack di protocolli TCP/IP Classe V sez. E ITC Pacioli Catanzaro lido 1 Stack TCP/IP Modello TCP/IP e modello OSI Il livello internet corrisponde al livello rete del modello OSI, il suo

Dettagli

Parte II: Reti di calcolatori Lezione 11

Parte II: Reti di calcolatori Lezione 11 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15 Parte II: Reti di calcolatori Lezione 11 Martedì 14-04-2015 1 Esempio di uso di proxy Consideriamo

Dettagli

UDP. Livello di Trasporto. Demultiplexing dei Messaggi. Esempio di Demultiplexing

UDP. Livello di Trasporto. Demultiplexing dei Messaggi. Esempio di Demultiplexing a.a. 2002/03 Livello di Trasporto UDP Descrive la comunicazione tra due dispositivi Fornisce un meccanismo per il trasferimento di dati tra sistemi terminali (end user) Prof. Vincenzo Auletta auletta@dia.unisa.it

Dettagli

Fondamenti di routing (pag.34)

Fondamenti di routing (pag.34) Fondamenti di routing (pag.34) UdA2L1 Il livello di rete (Network layer) è il livello 3 della pila ISO/OSI. Questo livello riceve datagrammi (pacchetti) dal livello di trasporto e forma pacchetti che vengono

Dettagli

Reti di calcolatori. Lezione del 18 maggio

Reti di calcolatori. Lezione del 18 maggio Reti di calcolatori Lezione del 18 maggio Riepilogo concetti Il software di rete La gestione della rete non può essere lasciata alle applicazioni-utente Necessità di un software specifico dedicato a gestire

Dettagli

Principi fondamentali

Principi fondamentali Principi fondamentali Elementi di base Definizione di rete di calcolatori Tipologia di connessioni Architettura di rete Prestazioni di una rete di calcolatori Conclusioni 1 1 Bit e Byte BIT = BInary digit

Dettagli

Comandi di Rete. Principali Comandi di Rete. Verificare, testare ed analizzare da Riga di Comando

Comandi di Rete. Principali Comandi di Rete. Verificare, testare ed analizzare da Riga di Comando Comandi di Rete Principali Comandi di Rete. Verificare, testare ed analizzare da Riga di Comando PING: verifica la comunicazione tra due pc Il comando ping consente di verificare la connettività a livello

Dettagli

La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento Indice

La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento Indice Indice 1. Definizioni essenziali 2. Modelli di rete 3. Reti fisiche 4. Protocolli di rete 5. Modelli di riferimento 6. Raffronto tra modelli Architettura degli Elaboratori 2 - T. Vardanega Pagina 275 Definizioni

Dettagli

CdL MAGISTRALE in INFORMATICA

CdL MAGISTRALE in INFORMATICA 05/11/14 CdL MAGISTRALE in INFORMATICA A.A. 2014-2015 corso di SISTEMI DISTRIBUITI 7. I processi : il naming Prof. S.Pizzutilo Il naming dei processi Nome = stringa di bit o di caratteri utilizzata per

Dettagli

Protocolli di Sessione TCP/IP: una panoramica

Protocolli di Sessione TCP/IP: una panoramica Protocolli di Sessione TCP/IP: una panoramica Carlo Perassi carlo@linux.it Un breve documento, utile per la presentazione dei principali protocolli di livello Sessione dello stack TCP/IP e dei principali

Dettagli

Informatica Generale Andrea Corradini. 10 - Le reti di calcolatori e Internet

Informatica Generale Andrea Corradini. 10 - Le reti di calcolatori e Internet Informatica Generale Andrea Corradini 10 - Le reti di calcolatori e Internet Cos è una rete di calcolatori? Rete : È un insieme di calcolatori e dispositivi collegati fra loro in modo tale da permettere

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15. Pietro Frasca. Parte II Lezione 1

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15. Pietro Frasca. Parte II Lezione 1 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15 Parte II Lezione 1 Giovedì 5-03-2015 TESTO DI RIFERIMENTO RETI DI CALCOLATORI E INTERNET un

Dettagli

12.5 UDP (User Datagram Protocol)

12.5 UDP (User Datagram Protocol) CAPITOLO 12. SUITE DI PROTOCOLLI TCP/IP 88 12.5 UDP (User Datagram Protocol) L UDP (User Datagram Protocol) é uno dei due protocolli del livello di trasporto. Come l IP, é un protocollo inaffidabile, che

Dettagli

Internet e protocollo TCP/IP

Internet e protocollo TCP/IP Internet e protocollo TCP/IP Internet Nata dalla fusione di reti di agenzie governative americane (ARPANET) e reti di università E una rete di reti, di scala planetaria, pubblica, a commutazione di pacchetto

Dettagli

Linux Network Testing

Linux Network Testing Introduzione agli strumenti per il testing di rete su Linux 6, 13 Novembre 2007 Sommario 1 Introduzione Panoramica sugli strumenti di misura 2 I tool di base per l amministrazione di rete Configurare le

Dettagli

Infrastrutture e Protocolli per Internet Risposte alle domande dei Laboratori

Infrastrutture e Protocolli per Internet Risposte alle domande dei Laboratori Advanced Network Technologies Laboratory Infrastrutture e Protocolli per Internet Risposte alle domande dei Laboratori Stefano Napoli Alberto Pollastro Politecnico di Milano Laboratorio 2 Sniffing con

Dettagli

Reti di calcolatori: Internet

Reti di calcolatori: Internet Reti di calcolatori: Internet Sommario Introduzione Le reti reti locali: LAN La rete geografica Internet protocollo TCP-IP i servizi della rete Rete di calcolatori Interconnessione di computer e accessori

Dettagli

INTRODUZIONE A RETI E PROTOCOLLI

INTRODUZIONE A RETI E PROTOCOLLI PARTE 1 INTRODUZIONE A RETI E PROTOCOLLI Parte 1 Modulo 1: Introduzione alle reti Perché le reti tra computer? Collegamenti remoti a mainframe (< anni 70) Informatica distribuita vs informatica monolitica

Dettagli

TCP/IP. Principali caratteristiche

TCP/IP. Principali caratteristiche TCP/IP Principali caratteristiche 1 TCP/IP Caratteristiche del modello TCP/IP Struttura generale della rete Internet IL MONDO INTERNET Reti nazionali e internazionali ROUTER Rete Azienade ROUTER ROUTER

Dettagli

Università degli Studi di Roma Tor Vergata. Facoltà di Ingegneria. Corso di Informatica Mobile. http://mislash.googlecode.com

Università degli Studi di Roma Tor Vergata. Facoltà di Ingegneria. Corso di Informatica Mobile. http://mislash.googlecode.com Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Corso di Informatica Mobile http://mislash.googlecode.com Professore: Vincenzo Grassi Studenti: Simone Notargiacomo "Roscio" Tavernese Ibrahim

Dettagli

Sistemi informatici in ambito radiologico

Sistemi informatici in ambito radiologico Sistemi informatici in ambito radiologico Dott. Ing. Andrea Badaloni A.A. 2015 2016 Reti di elaboratori, il modello a strati e i protocolli di comunicazione e di servizio Reti di elaboratori Definizioni

Dettagli

Corso di Sistemi di Elaborazione delle informazioni. Reti di calcolatori 2 a lezione a.a. 2009/2010 Francesco Fontanella

Corso di Sistemi di Elaborazione delle informazioni. Reti di calcolatori 2 a lezione a.a. 2009/2010 Francesco Fontanella Corso di Sistemi di Elaborazione delle informazioni Reti di calcolatori 2 a lezione a.a. 2009/2010 Francesco Fontanella Una definizione di Rete Una moderna rete di calcolatori può essere definita come:

Dettagli

3. Introduzione all'internetworking

3. Introduzione all'internetworking 3. Introduzione all'internetworking Abbiamo visto i dettagli di due reti di comunicazione: ma ce ne sono decine di tipo diverso! Occorre poter far comunicare calcolatori che si trovano su reti di tecnologia

Dettagli

I modelli di riferimento ISO OSI e TCP-IP

I modelli di riferimento ISO OSI e TCP-IP Gli Standards I modelli di riferimento ISO OSI e TCP-IP Dipartimento ICT Istituto e Liceo tecnico statale di Chiavari 2004 prof. Roberto Bisceglia ISO: International Standards Organization. ANSI: American

Dettagli

Informatica per la comunicazione" - lezione 9 -

Informatica per la comunicazione - lezione 9 - Informatica per la comunicazione" - lezione 9 - Protocolli di livello intermedio:" TCP/IP" IP: Internet Protocol" E il protocollo che viene seguito per trasmettere un pacchetto da un host a un altro, in

Dettagli

Le Reti LAN: componenti attivi

Le Reti LAN: componenti attivi Le Reti LAN: componenti attivi Descrizione dei principali componenti attivi di rete: Livello1: Repeater, Hub Livello 2: Bridge, Switch Livello 3: Router Componenti di una rete Nelle reti informatiche alcuni

Dettagli

Introduzione. Che cos'è un Firewall? Tipi di Firewall. Perché usarlo? Ci occuperemo di: Application Proxy Firewall (o "Application Gateway )

Introduzione. Che cos'è un Firewall? Tipi di Firewall. Perché usarlo? Ci occuperemo di: Application Proxy Firewall (o Application Gateway ) Sistemi di elaborazione dell'informazione (Sicurezza su Reti) Introduzione Guida all'installazione e configurazione del Software Firewall Builder ver 2.0.2 (detto anche FWBuilder) distribuito dalla NetCitadel

Dettagli

5. Traduzione degli indirizzi di rete in indirizzi fisici: ARP

5. Traduzione degli indirizzi di rete in indirizzi fisici: ARP 5. Traduzione degli indirizzi di rete in indirizzi fisici: ARP 5.1. Introduzione Due macchine si parlano solo se conoscono l'indirizzo fisico di sottorete Due applicazioni si parlano solo se conoscono

Dettagli

Istruzioni per il server

Istruzioni per il server Istruzioni per il server Alessandro Bugatti (alessandro.bugatti@istruzione.it) 9 dicembre 2007 Introduzione Questa breve dispensa riassume brevemente le procedure per connettersi al server che ci permetterà

Dettagli

Reti di Calcolatori. Master "Bio Info" Reti e Basi di Dati Lezione 2

Reti di Calcolatori. Master Bio Info Reti e Basi di Dati Lezione 2 Reti di Calcolatori Sommario Software di rete TCP/IP Livello Applicazione Http Livello Trasporto (TCP) Livello Rete (IP, Routing, ICMP) Livello di Collegamento (Data-Link) I Protocolli di comunicazione

Dettagli

SUITE PROTOCOLLI TCP/IP ( I protocolli di Internet )

SUITE PROTOCOLLI TCP/IP ( I protocolli di Internet ) PARTE 2 SUITE PROTOCOLLI TCP/IP ( I protocolli di Internet ) Parte 2 Modulo 1: Stack TCP/IP TCP/IP Protocol Stack (standard de facto) Basato su 5 livelli invece che sui 7 dello stack ISO/OSI Application

Dettagli

Livello Trasporto Protocolli TCP e UDP

Livello Trasporto Protocolli TCP e UDP Livello Trasporto Protocolli TCP e UDP Davide Quaglia Reti di Calcolatori - Liv Trasporto TCP/UDP 1 Motivazioni Su un host vengono eseguiti diversi processi che usano la rete Problemi Distinguere le coppie

Dettagli

Reti di Calcolatori. Il software

Reti di Calcolatori. Il software Reti di Calcolatori Il software Lo Stack Protocollare Application: supporta le applicazioni che usano la rete; Transport: trasferimento dati tra host; Network: instradamento (routing) di datagram dalla

Dettagli

Introduzione a TI-Nspire Navigator NC Teacher Software - Amministratori del dipartimento tecnico

Introduzione a TI-Nspire Navigator NC Teacher Software - Amministratori del dipartimento tecnico Introduzione a TI-Nspire Navigator NC Teacher Software - Amministratori del dipartimento tecnico La presente Guida è relativa alla versione 3.6 del software TI-Nspire. Per ottenere la versione più aggiornata

Dettagli

RETI DI CALCOLATORI. Che cosa sono gli IS e gli ES?

RETI DI CALCOLATORI. Che cosa sono gli IS e gli ES? RETI DI CALCOLATORI Domande di riepilogo Quinta Esercitazione Che cosa sono gli IS e gli ES? Il termine Intermediate System (IS) è un termine OSI che indica un nodo (tipicamente un router) che ha capacità

Dettagli

Parte II: Reti di calcolatori Lezione 16

Parte II: Reti di calcolatori Lezione 16 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Parte II: Reti di calcolatori Lezione 16 Giovedì 24-04-2014 1 Traduzione degli

Dettagli

Introduzione a Internet

Introduzione a Internet Contenuti Architettura di Internet Principi di interconnessione e trasmissione World Wide Web Posta elettronica Motori di ricerca Tecnologie delle reti di calcolatori Servizi Internet (come funzionano

Dettagli

Introduzione al TCP/IP Indirizzi IP Subnet Mask Frame IP Meccanismi di comunicazione tra reti diverse Classi di indirizzi IP Indirizzi IP privati e

Introduzione al TCP/IP Indirizzi IP Subnet Mask Frame IP Meccanismi di comunicazione tra reti diverse Classi di indirizzi IP Indirizzi IP privati e TCP/IP Sommario Introduzione al TCP/IP Indirizzi IP Subnet Mask Frame IP Meccanismi di comunicazione tra reti diverse Classi di indirizzi IP Indirizzi IP privati e pubblici Introduzione al TCP/IP TCP/IP

Dettagli

Reti di calcolatori. Prof. Giovanni Giuffrida

Reti di calcolatori. Prof. Giovanni Giuffrida Reti di calcolatori Prof. Giovanni Giuffrida Rete di calcolatori É un insieme di calcolatori, collegati tra loro da una rete di comunicazione, che possono condividere informazioni e risorse Rete di comunicazione:

Dettagli

Sistemi Distribuiti. Libri di Testo

Sistemi Distribuiti. Libri di Testo Sistemi Distribuiti Rocco Aversa Tel. 0815010268 rocco.aversa@unina2.it it Ricevimento: Martedì 14:16 Giovedì 14:16 1 Libri di Testo Testo Principale A.S. Tanenbaum, M. van Steen, Distributed Systems (2

Dettagli

Sommario. Configurazione della rete con DHCP. Funzionamento Configurazione lato server Configurazione lato client

Sommario. Configurazione della rete con DHCP. Funzionamento Configurazione lato server Configurazione lato client Seconda esercitazione Sommario Configurazione della rete con DHCP Funzionamento Configurazione lato server Configurazione lato client 2 Sommario Test di connettività ping traceroute Test del DNS nslookup

Dettagli

AdRem Free itools 2006. - L importanza degli strumenti di diagnostica -

AdRem Free itools 2006. - L importanza degli strumenti di diagnostica - AdRem Free itools 2006 - L importanza degli strumenti di diagnostica - Introduzione La capacità di configurare, gestire e risolvere i problemi relativi alle reti TCP/IP è parte fondamentale dell attività

Dettagli

Reti standard. Si trattano i modelli di rete su cui è basata Internet

Reti standard. Si trattano i modelli di rete su cui è basata Internet Reti standard Si trattano i modelli di rete su cui è basata Internet Rete globale Internet è una rete globale di calcolatori Le connessioni fisiche (link) sono fatte in vari modi: Connessioni elettriche

Dettagli

Introduzione alle reti di calcolatori

Introduzione alle reti di calcolatori Introduzione alle reti di calcolatori Definizioni base. Collegamenti diretti e indiretti Strategie di multiplazione Commutazione di circuito e di pacchetto Caratterizzazione delle reti in base alla dimensione

Dettagli

Lezione 4. Le Reti ed i Protocolli

Lezione 4. Le Reti ed i Protocolli Lezione 4 Le Reti ed i Protocolli Come nasce internet I computer, attraverso i software applicativi, consentono di eseguire moltissime attività. Nel corso degli anni è emersa la necessità di scambiare

Dettagli

I protocolli TCP/IP di Internet

I protocolli TCP/IP di Internet I protocolli TCP/IP di Internet Introduzione E' quasi impossibile oggigiorno leggere un giornale o una rivista dove non si parli di Internet. I riferimenti ad Internet ed alle "autostrade dell'informazione"

Dettagli

Livello di Rete. Gaia Maselli maselli@di.uniroma1.it

Livello di Rete. Gaia Maselli maselli@di.uniroma1.it Livello di Rete Gaia Maselli maselli@di.uniroma1.it Queste slide sono un adattamento delle slide fornite dal libro di testo e pertanto protette da copyright. All material copyright 1996-2007 J.F Kurose

Dettagli

TOPOLOGIA di una rete

TOPOLOGIA di una rete TOPOLOGIA di una rete Protocolli di rete un protocollo prevede la definizione di un linguaggio per far comunicare 2 o più dispositivi. Il protocollo è quindi costituito dai un insieme di convenzioni

Dettagli

Corso GNU/Linux - Lezione 5. Davide Giunchi - davidegiunchi@libero.it

Corso GNU/Linux - Lezione 5. Davide Giunchi - davidegiunchi@libero.it Corso GNU/Linux - Lezione 5 Davide Giunchi - davidegiunchi@libero.it Reti - Protocollo TCP/IP I pacchetti di dati vengono trasmessi e ricevuti in base a delle regole definite da un protocollo di comunicazione.

Dettagli

Modello OSI e architettura TCP/IP

Modello OSI e architettura TCP/IP Modello OSI e architettura TCP/IP Differenza tra modello e architettura - Modello: è puramente teorico, definisce relazioni e caratteristiche dei livelli ma non i protocolli effettivi - Architettura: è

Dettagli

Capitolo 1 - parte 1. Corso Reti ed Applicazioni Mauro Campanella

Capitolo 1 - parte 1. Corso Reti ed Applicazioni Mauro Campanella Capitolo 1 - parte 1 Corso Reti ed Applicazioni Mauro Campanella Precisazione Noi ci occuperemo solo della trasmissione di informazione in formato digitale. Un segnale analogico è basato su una variazione

Dettagli

UBIQUITY 6 e Server. Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity.

UBIQUITY 6 e Server. Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity. UBIQUITY 6 e Server Privato Introduzione Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity. Versione Descrizione Data 1 Prima emissione 21/06/2015 Disclaimer

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

Reti. Reti e interconnessione di reti - Internetwork WAN 1 WAN 1. Router multiprotocollo (gateway) Terminologia

Reti. Reti e interconnessione di reti - Internetwork WAN 1 WAN 1. Router multiprotocollo (gateway) Terminologia Reti Reti e interconnessione di reti - Internetwork WAN WAN Router multiprotocollo (gateway) Terminologia internet - internetwork :interconnessione di più reti generiche Internet - la specifica internetwork,

Dettagli

DNS (Domain Name System) Gruppo Linux

DNS (Domain Name System) Gruppo Linux DNS (Domain Name System) Gruppo Linux Luca Sozio Matteo Giordano Vincenzo Sgaramella Enrico Palmerini DNS (Domain Name System) Ci sono due modi per identificare un host nella rete: - Attraverso un hostname

Dettagli

Reti di Telecomunicazione Lezione 8

Reti di Telecomunicazione Lezione 8 Reti di Telecomunicazione Lezione 8 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Livello di trasporto Programma della lezione relazione tra lo strato di trasporto e lo strato

Dettagli

Protocollo TCP/IP & Indirizzamento IP

Protocollo TCP/IP & Indirizzamento IP Protocollo TCP/IP & Indirizzamento IP L architettura TCP/IP: Nasce per richiesta del Dipartimento della Difesa degli USA che intendeva poter creare una rete in grado di funzionare in qualsiasi tipo di

Dettagli

Il modello TCP/IP. Sommario

Il modello TCP/IP. Sommario Il modello TCP/IP Il protocollo IP Mario Cannataro Sommario Introduzione al modello TCP/IP Richiami al modello ISO/OSI Struttura del modello TCP/IP Il protocollo IP Indirizzi IP Concetto di sottorete Struttura

Dettagli

Sommario. Introduzione ai firewall. Firewall a filtraggio dei pacchetti. Il firewall ipfw. Definizione e scopo Classificazione

Sommario. Introduzione ai firewall. Firewall a filtraggio dei pacchetti. Il firewall ipfw. Definizione e scopo Classificazione Sesta Esercitazione Sommario Introduzione ai firewall Definizione e scopo Classificazione Firewall a filtraggio dei pacchetti Informazioni associate alle regole Interpretazione delle regole Il firewall

Dettagli

network subnet host Classe A poche reti di dimensioni molto grandi 127

network subnet host Classe A poche reti di dimensioni molto grandi 127 INDIRIZZAMENTO IP Gli indirizzi IP, che devono essere univoci sulla rete, sono lunghi 32 bit (quattro byte) e sono tradizionalmente visualizzati scrivendo i valori decimali di ciascun byte separati dal

Dettagli

SBSAfg.exe nella cartella Tools del DVD Opzioni avanzate: Migration Mode Unattend Mode Attended Mode con dati pre-caricati

SBSAfg.exe nella cartella Tools del DVD Opzioni avanzate: Migration Mode Unattend Mode Attended Mode con dati pre-caricati SBSAfg.exe nella cartella Tools del DVD Opzioni avanzate: Migration Mode Unattend Mode Attended Mode con dati pre-caricati Collegare il router e tutti i devices interni a Internet ISP connection device

Dettagli

Elementi di Sicurezza e Privatezza Laboratorio 6 - Sniffing. Chiara Braghin chiara.braghin@unimi.it

Elementi di Sicurezza e Privatezza Laboratorio 6 - Sniffing. Chiara Braghin chiara.braghin@unimi.it Elementi di Sicurezza e Privatezza Laboratorio 6 - Sniffing Chiara Braghin chiara.braghin@unimi.it Sniffing (1) Attività di intercettazione passiva dei dati che transitano in una rete telematica, per:

Dettagli

Reti: unità di misura

Reti: unità di misura Reti: unità di misura bandwidth: range di frequenze usate per la trasmissione del segnale elettromagnetico che codifica l informazione misurata in Hertz (Hz) bit rate: #bit trasmissibili su canale per

Dettagli

Scritto da Administrator Martedì 02 Settembre 2008 06:30 - Ultimo aggiornamento Martedì 10 Maggio 2011 17:15

Scritto da Administrator Martedì 02 Settembre 2008 06:30 - Ultimo aggiornamento Martedì 10 Maggio 2011 17:15 Entrare in un pc è una espressione un po generica...può infatti significare più cose: - Disporre di risorse, quali files o stampanti, condivise, rese fruibili liberamente o tramite password con i ripettivi

Dettagli

IP Internet Protocol

IP Internet Protocol IP Internet Protocol Vittorio Maniezzo Università di Bologna Vittorio Maniezzo Università di Bologna 13 IP - 1/20 IP IP è un protocollo a datagrammi In spedizione: Riceve i dati dal livello trasporto e

Dettagli

Spinelli Raffaele. SISI on cluster

Spinelli Raffaele. SISI on cluster Spinelli Raffaele SISI on cluster Introduzione SISI - Scalable Intermediary Software Infrastructure, è un framework per sviluppare e fare deploy di Edge Service. SISI è basato su Apache e mod_perl Grazie

Dettagli

I Principali Servizi del Protocollo Applicativo

I Principali Servizi del Protocollo Applicativo 1 I Principali Servizi del Protocollo Applicativo Servizi offerti In questa lezione verranno esaminati i seguenti servizi: FTP DNS HTTP 2 3 File Transfer Protocol Il trasferimento di file consente la trasmissione

Dettagli

Le reti di calcolatori

Le reti di calcolatori Le reti di calcolatori 1 La storia Computer grandi e costosi Gli utenti potevano accerdervi tramite telescriventi per i telex o i telegrammi usando le normali linee telefoniche Successivamente le macchine

Dettagli

pod Guida all installazione di rete del Solstice Pod Introduzione Solstice Pod Collaborazione Visuale Wireless Solstice sulla vostra rete

pod Guida all installazione di rete del Solstice Pod Introduzione Solstice Pod Collaborazione Visuale Wireless Solstice sulla vostra rete Introduzione Solstice Pod Collaborazione Visuale Wireless Una volta installato, il Solstice Pod permette a più utenti di condividere simultaneamente il proprio schermo su un display tramite la rete Wi-Fi

Dettagli

Reti di calcolatori e Internet

Reti di calcolatori e Internet Corso di Laboratorio di Tecnologie dell'informazione Reti di calcolatori e Internet Copyright Università degli Studi di Firenze - Disponibile per usi didattici Cos è Internet: visione dei componenti Milioni

Dettagli

La Sicurezza delle Reti. La Sicurezza delle Reti. Il software delle reti. Sistemi e tecnologie per la multimedialità e telematica.

La Sicurezza delle Reti. La Sicurezza delle Reti. Il software delle reti. Sistemi e tecnologie per la multimedialità e telematica. Sistemi e tecnologie per la multimedialità e telematica Fabio Burroni Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena burronif@unisi unisi.itit La Sicurezza delle Reti La presentazione

Dettagli

Il firewall ipfw. Introduzione ai firewall. Problema: sicurezza di una rete. Definizione di firewall. Introduzione ai firewall

Il firewall ipfw. Introduzione ai firewall. Problema: sicurezza di una rete. Definizione di firewall. Introduzione ai firewall Il firewall ipfw Introduzione ai firewall classificazione Firewall a filtraggio dei pacchetti informazioni associate alle regole interpretazione delle regole ipfw configurazione impostazione delle regole

Dettagli