Reti di calcolatori PDF | Introduzione e Concetti Fondamentali

RETI DI CALCOLATORI (31/09-01/10) Una rete di calcolatori è una collezione di dispositivi elaborativi connessi in vari modi con l’obiettivo di comunicare tra di loro e condividere delle risorse e dati. L’eterogeneità dei calcolatori stessi rende i collegamenti molto complessi; essi differiscono infatti per i terminali e quindi per la varietà di dispositivi connessi (smartwatch, televisori, telefoni, sono tutti sistemi diversi tra loro) i mezzi trasmissivi (comunicazioni tramite fibre ottiche, cavi ethernet, wireless) le tecnologie di comunicazione (esistono diverse tecnologie wireless, come il wifi o il 3g) la molteplicità di operatori e gestori che caratterizza le sfumature di ogni rete (ogni rete diventa una scatola nera per gli altri operatori, che ne ignorano la struttura) la qualità e quantità di servizi offerti (servizi multimediali audiovideo in differita che privilegiano la rapidità dei pacchetti, la cui ricezione e correttezza è verificata con la tecnica della modulazione e la tecnica del bit di parità che impone la parità del numero di 1 nella stringa ricevuta, piuttosto che applicazioni come home banking che invece richiedono una maggiore correttezza a fronte di una maggiore tolleranza dei ritardi): internet deve essere in grado di servire applicazioni che offrono servizi differenti. I dispositivi inoltre si distinguono in: Terminali (aka host o end-system): ovvero dispositivi che producono o ricevono informazioni e che sono interessati direttamente dalle comunicazioni tra utenti. Sono di questo tipo i dispositivi degli utenti e i server Dispositivi di rete o intermedi: ovvero dispositivi che non producono o ricevono alcuna informazione, il cui ruolo è consentire la comunicazione tra i diversi terminali. Alcuni esempi sono switch router e access points, ognuno con diverse funzioni e livelli della pila protocollare Connessioni: fili e cavi La comunicazione avviene tramite un canale digitale, che permette la trasmissione di bit da un device all’altro, per cui ad ogni bit è associata una particolare forma d’onda oppure. Tuttavia per ottenere una trasmissione più efficiente, e che quindi fa arrivare a parità di unità di tempo, un maggiore trasporto di informazione, è possibile usare più forme d’onda nella modulazione rappresentando combinazioni di più bit. All’aumentare del numero di combinazioni e di forme d’onda, ci sarà una minore chiarezza della forma d’onda complessiva, aumentando le probabilità d’errore anche sensibilmente nel caso in cui figurino anche dei rumori. È logicamente necessario trovare un compromesso. La modulazione scelta, cioè il numero di bit associati a un singolo trasmesso, impatterà sul valore del il valore del 1𝑏𝑖𝑡 rate trasmissivo, ossia il numero di bit trasmesso nell’unità di tempo 1𝑚𝑠 = 1𝑘𝑏/𝑠, direttamente proporzionale al numero di bit (diverso dal concetto di banda, ossia un insieme di frequenze misurate in Hertz). Viceversa, per ottenere il tempo impiegato nella trasmissione, nota la trasmission rate e la dimensione del pacchetto, devo fare la divisione tra le due (dimensione in bit : trasmission rate). Ex 1000 Byte e 40kb/s T= 1000x8 b/40x10^3 b/s= 0.2s. Con questa operazione stiamo calcolando esclusivamente il tempo della trasmissione fisica dei dati, senza includere il tempo di ricezione dei dati, che fa ridurre il numero di dati effettivamente ricevuti dall’utente in quell’intervallo temporale. PSTN e cirucit Switching Le vecchie reti telefoniche erano formate da tante matrici che mettevano in comunicazione uno dato input con un determinato output. Nel PSTN (public switched telephone network) i terminali in comunicazione sono connessi tramite cabine commutanti organizzate gerarchicamente. Quando una chiamata è effettuata un circuito è stabilito tra due telefoni come collegamenti concatenati lungo un circuito fissato. Un circuito è dedicato ad una singola chiamata così come la capacità di trasmissione assegnata ad essa, che resta la stessa anche quando nessuna delle due persone ai terminali sta parlando. Le cabine sono sottodimensionate, in quanto statisticamente è improbabile che tutti gli utenti serviti dalla rete effettuino simultaneamente la chiamata. La comunicazione comprendeva tre fasi 1. Stabilire un circuito tramite la allocazione di contatti tra le risorse 2. Chiamata o trasferimento dati 3. Circuit tear-down o deallocazione delle risorse Le fasi 1 e 3 implicano lo scambio di informazione segnalante entrambi tra terminali e le cabine commutanti e tra le cabine stesse. Ogni coppia di utenti ha un suo circuito dedicato, questo però non implica la presenza di un cavo fisico dedicato: si riserva una porzione di risorse all’interno di un cavo. Esistono due tecniche per condividere una risorsa fisica tra sue utenti: MULTIPLAZIONE NEL DOMINIO DEL TEMPO (TDM): questa tecnica sfrutta una divisione di tempi, per cui si dedica alla trasmissione di ogni coppia un determinato slot. I diversi utenti faranno a turno nella trasmissione, a rotazione, per cui dopo n slot ritornerò a servire l’utente 1. Gli slot sono staticamente assegnati, per cui ogni porzione di slot concederà 1/n-esimo della sua ampiezza ad ogni utente. Anche nella tecnica TDM ogni coppia di utenti avrà un circuito riservato, con una certa periodicità. MULTIPLAZIONE NEL DOMINIO DELLA FREQUENZA (FDM): data una banda con un determinato intervallo di frequenza, essa viene divisa tra n utenti. Ciascuna coppia di utenti può trasmettere continuamente nel tempo, ma in una dedicata porzione di banda. Entrambe queste tecniche venivano usate nella telefonia tradizionale per multiplexare più utenti sullo stesso cavo e si basano sulla limitatezza della sensibilità dell’orecchio umano, per cui, se l’intervallo di inattività di servizio per la slot è abbastanza piccolo, allora esso non è percepito. La voce inoltre può essere codificata con sole poche decine di bit al secondo, per cui è possibile realizzare un multiplexing di un elevato numero di utenti. La caratteristica fondamentale della commutazione di circuito è che esiste un circuito completamente dedicato ad una coppia di utenti (per circuito si può intendere uno slot temporale o una determinata banda di utenti), per cui anche se nessuno sta parlando, le risorse vanno comunque sprecate. Inoltre i requisiti di questo servizio sono abbastanza deterministici, per cui è possibile dimensionare opportunamente la banda di frequenza o la slot temporale. Questo discorso però non si può applicare al traffico di rete, per cui non è possibile caratterizzare in maniera precisa il profilo di traffico di ogni utente. Poiché l’utilizzo di pacchetti non è costante, un approccio statico sprecherebbe troppe risorse. In questo caso, la risorsa è utilizzata da chi ha da trasmettere: le risorse non vengono riservate a nessuno, chi ha da trasmettere utilizza le risorse ha disposizione. Questo prende il nome del paradigma di commutazione di pacchetto in cui le informazioni vengono divise in pacchetti, che diventano unità di dati autonome formate da un header, che contiene informazione di controllo incluso un indirizzo di destinazione e un payload. Anche in questo caso ci sarà un fenomeno di multiplexing e quindi di aggregazione: a un certo dispositivo intermedio arriveranno più pacchetti, che non verranno suddivisi in slot secondo uno schema fisso, e inviati in uscita non appena arrivano al dispositivo di rete. Il primo pacchetto che arriva è il primo ad essere spedito, evitando quindi uno spreco di risorse. Ciò è una conseguenza del carattere aleatorio di un profilo di traffico. L’approccio tipico della commutazione di pacchetto è l’approccio a datagrammi (su cui si basa il protocollo IP): ogni informazione viene suddivisa in diversi pacchetti (n.b. trattati come unità indipendente dagli altri). Per arrivare a destinazione devono attraversare un certo dispositivo intermedio, che li elaborerà e dovrà capire a quale altro dispositivo intermedio dovrà inviarli, non in base a percorsi prestabiliti, ma al percorso migliore, che cambia istante per istante, deciso in base alle informazioni note in quel momento, in quanto il traffico ha una natura dinamica. Diversi pacchetti saranno instradati autonomamente da ogni router e quindi potranno seguire anche percorsi differenti), con il rischio di arrivare anche in ordine diverso rispetto a quello inviato; per avere affidabilità nella consegna dei pacchetti sarà necessario riordinarli. Un’altra problematica da tener conto è l’integrità del pacchetto (non ha senso far proseguire un pacchetto interrotto). Inoltre, se un dispositivo ha più linee di uscita il dispositivo dovrà decidere da che linea farlo uscire, rendendo necessaria una certa elaborazione che dovrà stare al passo con la frequenza di ingresso dei pacchetti; nasceranno inevitabilmente delle code in uscita all’interno del dispositivo (come nei collegamenti LAN), quando il traffico dei pacchetti è maggiore della capacità del singolo dispositivo. Le code sono responsabili di altre due problematiche, la latenza (ritardo di trasmissione che aumenta, accumulandosi) e della perdita di pacchetti. Una coda, infatti è necessariamente mantenuta in una memoria finita, quindi sarà anch’essa finita; un pacchetto potrà quindi anche essere scartato, causa la pienezza delle code/memoria con un relativo aumento del tempo di consegna e un ritardo impredicibile. Un altro approccio possibile è quello dei circuiti virtuali: quando due entità devono comunicare tra loro viene stabilito un percorso virtuale, utilizzato da tutti i pacchetti generati da A e destinati a B. Come conseguenza di ciò, dando per scontato che ogni router instrada prima i pacchetti arrivati per prima, i pacchetti arrivano nello stesso ordine a destinazione. Il circuito virtuale, generalmente non ha nessuna implicazione sulla riservabilità delle risorse, è solo un’indicazione del percorso che deve seguire, ma nulla è riservato a un determinato source (diversamente dalle tecniche di commutazione telefoniche). Tuttavia, prima di far partire il traffico, abbiamo dovuto configurare in ogni router il circuito virtuale da noi scelto: sarà necessaria una fase di set up prima dell’effettivo invio dei dati, non necessario nella tecnica a datagrammi. In più, dato che ogni pacchetto viene instradato indipendentemente dagli altri, in quel momento viene instradato sul percorso ritenuto migliore. Un circuito non sarà scelto se c’è un problema in un collegamento di rete, ma passare ad un circuito di backup è più complicato, perché bisogna fare il setup di un diverso circuito virtuale. Inoltre, non si esclude che i pacchetti possano essere scartati lungo il percorso, perché corrotti o perché le code del dispositivo erano piene. Tipi di network per estensioni geografiche (molti utenti con bassi tassi trasmissivi): LAN (LOCAL-AREA NETWORK): connette un basso numero di terminali relativamente vicini. In una rete locale non c’è bisogno di utilizzare alti tassi di trasmissività, data la scarsità di utenti, che non possono creare un eccessivo traffico di pacchetti. WAN (WIDE AREA NETWORK ): Connette più LAN in una grande area geografica, che, avendo molti utenti, avrà bisogno di un maggiore tasso di trasmissività. MAN (METROPOLITAN AREA NETWORK ): mette in comunicazione infrastrutture che spaziano in grandi città. In Generale avremo tassi di trasmissività più elevati nelle reti geograficamente importanti che non nelle reti locali. In un piccolo agglomerato, ogni edificio avrà una rete locale, gerarchicamente organizzata a sua volta, che sarà collegata ad un centro stella che sarà di tipo WAN. Avremo però diverse tipologie di collegamento tra utenti, come quella ad anello o a bus, che richiedono un unico cavo che metta in collegamento tutti gli utenti. Le prime tecnologie si basavano sul modello a bus. Quando più lan in diversi siti, devono essere collegate, necessiteranno di link di tipo wan; un nodo in particolare di ogni LAN deve servire da gateway per gestire le comunicazioni tra la lan e gli altri network. In presenza di interconnessioni di larga scala la situazione si complica. Consideriamo una rete di n- siti, o n-LAN che vogliamo interconnettere tra di loro, una possibilità e di collegare ogni LAN ad un’altra secondo una topologia full mesh. Questa topologia sarà di ottime prestazioni in quanto non dovremo utilizzare dispositivi intermedi, a fronte però di un elevato numero di collegamenti che cresce in maniera quadratica a fronte di un aumento di nodi con legge N*(N- 1)/2. Diverse reti LAN non saranno tutte collegate tra loro, ma saranno disposte in un grafo non completo, connesso, che fa sì che ogni rete locale sia in comunicazione con le altre, tramite reti locali intermedie. Non tutti i collegamenti inoltre sono uguali, alcuni hanno maggiore capacità di altre e sono capaci di trasportare una maggiore quantità di informazione per unità di tempo. RETI DI CALCOLATORI 07-10 Modelli stratificati di reti I 7 livelli protocollari sono implementati tutti nei terminali, ossia nei dispositivi utente. Il livello fisico, occupandosi della modulazione dei segnali, è implementato in hardware, nelle diverse schede di rete corrispondenti. Il modello data link segna lo stadio intermedio, la transizione tra l’implementazione hardware e software: normalmente è implementato parte in hardware e parte nei driver del SO. Ciò perché il livello data link è strettamente segnato al livello fisico, basando il suo funzionamento sulla scheda di rete caratteristica di ogni dispositivo (ethernet, wifi..), le cui funzioni specifiche saranno implementate nei driver o nel SO stesso. I livelli superiori sono implementati tutti in software, con la distinzione che il livello applicazioni sarà implementato dalle applicazioni stesse (con i loro protocolli), gli altri due nel SO. In linea di principio, nei dispositivi intermedi (switch e router), non sarebbe necessario implementare tutti i livelli della pila (I router sono ad esempio dispositivo di livello 3, mentre switch/access point e ripetitori sono di livello 2), essendo il loro obiettivo puramente quello di far avanzare i pacchetti ed elaborarli a seconda del livello a cui operano, con un utilizzo esclusivo dei livelli necessari. Nella pratica però essi prevedono comunque tutti i livelli, sfruttati per questione di monitoraggio e manutenzioni (statistiche di switch relative al traffico, controllo corretto funzionamento… ad esempio gli switch saranno quindi dotati di un server SSH, un protocollo per la connessione a riga di comando con un dispositivo di controllo). Trasmissione dei messaggi Supponiamo di voler utilizzare normalmente un browser. Logicamente, il livello applicazione comunicherà col corrispettivo livello applicazione del host di destinazione, mentre il protocollo applicativo stabilirà dei messaggi che le app vogliono scambiarsi per poter realizzare il servizio richiesto. La comunicazione reale, parallelamente, avviene mandando il messaggio ai livelli inferiori, fino ad arrivare al livello fisico. In fase di trasmissione, l’applicazione prepara il messaggio (che sarà una serie di bit il cui formato è stabilito dal protocollo) in modo che il ricevente sia in grado di interpretarlo correttamente. Durante la discesa, ogni protocollo aggiunge delle proprie informazioni al pacchetto. Tale operazione sarà fondamentale, ad esempio se abbiamo due applicazioni/messaggi sull’host comunicante, per cui il livello trasporto del ricevente dovrà passare i messaggi corretti alle corrispondenti applicazioni (M1 to A1 e M2 to A2). Questo prende il nome di problema del demultiplexing, al livello ricezione. A livello trasmissione, si attuerà in tutta la pila ISO/OSI la procedura di imbustamento del messaggio. Quando il livello trasporto lato mittente riceve il messaggio M1, aggiunge un proprio header in cui mette le informazioni utili a regolare la comunicazione tra le entità da quel livello, con un identificativo che farà capire al ricevente dove il messaggio dovrà essere inviato (n.b il messaggio giungerà al livello applicazione senza header). Il livello data link, oltre all’header, aggiungerà anche un trailer di 4byte, un’informazione di coda aggiunta per una questione di elaborazione delle frame: vengono infatti aggiunti i bit di controllo di errore per facilitare un controllo più veloce, per cui si scarta direttamente la frame non appena si individua un errore e il controllo può essere fatto anche direttamente in hardware. L’insieme di header e messaggio diventerà il blocco di dati che verrà trasmesso a livello base. Riassumendo L’applicazione crea un messaggio Il messaggio applicativo viene passato a un protocollo del livello trasporto Tutto questo viene passato al livello rete che antepone un header di livello 3 Tutto ciò viene passato al livello data link che inserisce un header di livello 2 e un trailer Tutto ciò viene passato al livello fisico. Ci aspetteremo di trovare quindi il pacchetto in questo ordine: H2 H3 H4 M. Pdu (protocol data unit) e SDU (service data unit) Il blocco di dati passerà dal livello n a livello n-1. Per questo livello il dato ricevuto sarà una service data unit ricevuta dal livello superiore; in seguito all’aggiunta di un header, il nuovo blocco rappresenta (sempre dal punto di vista n-1) una protocol data unit. Service data unit: il blocco di dati ricevuto dall’alto protocol data unit è il blocco che verrà logicamente scambiato con un protocollo di stesso livello, formata da una SDU + header. Ogni livello avrà la propria pdu caratterizzata da un proprio nome distintivo a seconda del livello in cui operiamo. A livello applicazione si chiameranno messaggi. A livello trasporto prenderà il nome di segmento. A livello rete si chiamerà datagramma o pacchetto (un pacchetto quindi sarà una stringa di bit, per questo sono necessari dei protocolli per leggerlo correttamente). A livello data link prenderà il nome di frame. Al più basso livello invece avremo una stringa di bit trasmessa secondo le regole dei vari protocolli. Tecnica di frammentazione Tipicamente a livello data link esiste un limite sulla dimensione massima di un singolo blocco di dati che esso si aspetta di ricevere (per ethernet il limite è 1500B). Essendo i vari livelli strettamente correlati tra loro, questo limite il livello rete non sarà l’unico che dovrà tenerne conto, anche quelli superiori non potranno superare le dimensioni prefissate. Per gestire questa situazione si adotta la frammentazione, con cui si frammenta il blocco in due sottoblocchi più piccoli indipendenti che rispettino le dimensioni. Essendo indipendenti ad ogni sottobloccho sarà aggiunto un proprio header. Arrivati a destinazione, i frammenti saranno riassemblati secondo le norme del protocollo IP per assicurare la corretta visualizzazione al livello applicativo. In ricezione si farà un processo inverso, rimuovendo tutti gli header durante la salita. Notiamo in questa configurazione la presenza di un router, un dispositivo dotato quindi di più interfacce che collega più reti. Ogni interfaccia avrà il proprio mini-stack dotato di proprio livello data link e fisico, mentre avrà un unico livello rete per dispositivo. Il compito del livello rete La funzione di una rete è consentire la comunicazione tra due applicazioni, sfruttando il paradigma della commutazione di pacchetto; tuttavia, essendo le risorse della rete condivise da chi sta trasmettendo dati, non ci sono garanzie relative alla qualità con cui viene offerto il servizio di trasmissione dei dati di una rete di calcolatori. Le grandezze utilizzate per valutare la qualità di servizio della rete sono: End-to-end delay: tempo che intercorre tra la trasmissione e la ricezione dei pacchetti o ritardo nella consegna dei pacchetti [s]. Esso è determinato da: 1. Tempo di elaborazione nel nodo: controllo di errori, determinazione link di uscita,... 2. Tempo di trasmissione del pacchetto su ciascun link = Lunghezza in bit / velocità in bps 3. Tempo di accodamento/attesa nelle code dei router (variabile) 4. Tempo di propagazione sulle linee (tipicamente trascurabile, a meno di tratte molto estese, perché legato alla velocità della luce Packet delay variation (PDV): variazione temporale del ritardo one-way, spesso anche indicata con il termine packet jitter; misura quanto si discosta il delay dall’arrivo del pacchetto successivo. Se c’è un’elevata variabilità di ritardo di consegna dei pacchetti (ad esempio nei servizi multimediali) avremo un servizio scadente. Throughput: quantità di bit al secondo che la rete è in grado di trasferire tra i due terminali [b/s]. Differisce dal concetto di rate trasmissivo, che è legato alle caratteristiche della modulazione di livello fisico e alle forme d’onda, ipotizzando una trasmissione continua. Il throughput prende in considerazione tutto l’arco temporale, considerando anche l’intervallo in cui non abbiamo trasmesso bit (per effettuare ulteriori operazioni o trasmissioni ad altri utenti). Nominalmente quindi è il fattore della quantità di bit utili ricevuti da un’applicazione in un’unità di tempo e quindi inferiore al tasso trasmissivo. Maggiore è il throughput, migliore sarà la qualità del servizio Dati inviati secondo il rate trasmissivo Dati effettivamente inviati Loss-Rate: probabilità che un pacchetto non venga consegnato a destinazione (ad esempio per la corruzione di un pacchetto). Se un pacchetto viene perso sarà necessaria una ritrasmissione che implicherà dei ritardi e quindi un non utilizzo del servizio. Internet Protocol suite ed il protocollo IP Lo stack TCP /IP è una suite di protocolli che si collocano ai diversi livelli standard della pila (da network in su) Al livello trasporto troviamo il TCP ( trasmission control protocol) e l’UDP, che offrono funzionalità complementari, a cui sono stati aggiunti e coniati altri protocolli che forniscono una via di mezzo. Al livello applicativo notiamo un’enorme varietà di protocolli a fronte di eterogeneità di richieste(http navigazione rete, IMAP per le mail, ftp per i file). A lato notiamo anche dei protocolli ausiliari che servono a gestire e coordinare i dispositivi di rete, utilizzati per trasportare informazioni di controllo. Da livello 3 in su (tutti quelli che vediamo in figura), la definizione dei protocolli è responsabilità dell’ente internazionale di standardizzazione noto come IETF, che opera mediante gruppi di lavoro incaricati di diverse aree di problematiche, che producono dei documenti che specificano le caratteristiche del protocollo e che assumono diverse denominazioni a seconda del loro stato (internet draft nello stato iniziale, RFC dopo l’approvazione ma prima della standardizzazione). Per i livelli inferiori, non c’è un unico ente di standardizzazione, anche a causa dell’eterogeneità delle diverse tecnologie; alcuni esempi sono l’IEEE (che ha standardizzato reti ethernet e wifi), 3GPP (che ha standardizzato le reti cellulari) RETI DI CALCOLATORI 08/10 Protocollo IPv4 Il collante per l’eterogeneità della rete è il protocollo IPv4. Nonostante questa non sia la versione più recente, è la più utilizzata oggi. La versione 6 fu introdotta 20 anni fa per superare alcune limitazioni della versione 4, ma la transizione non è stata ancora completata grazie all’introduzione di nuovi meccanismi che ne hanno allungato la vita. L’IPv4 è stato definito e standardizzato nell’RFC 791. Collocandosi a livello rete, che si occupa di creare comunicazioni end-to-end, il suo compito è quello di instradare i pacchetti, ossia scegliere l’interfaccia sulla quale un pacchetto deve essere trasmesso per arrivare a destinazione, offrendo un servizio di tipo best-effort, ossia “facendo il proprio meglio per far avanzare i pacchetti verso la destinazione” senza quindi dare garanzie sull’effettiva consegna. Da esso dipenderanno anche i protocolli collocati ai livelli superiori (TCP-UDP). Oltre all’instradamento, esso si occupa di l’indirizzamento ossia assegnare un indirizzo uni-identificativo di livello globale a ogni dispositivo attaccato alla rete. frammentazione ri-assemblaggio dei pacchetti multiplexing dei protocolli (meccanismo grazie al quale un protocollo riesce a sapere a quale entità di livello superiore deve passare il pacchetto). Essendo collocato a livello rete esso sarà implementato sia nei router che in tutti i dispositivi collegati alla rete (terminali, necessario per le comunicazioni end-to-end oltre i confini della rete locale a cui apparteniamo, per la quale invece la connessione è garantita al suo interno anche senza internet). Come tutti i protocolli definisce una dimensione massima dei pacchetti che può gestire: un datagramma IPv4 può avere una dimensione massima di 65535 byte (216 – 1) ed è costituito da un header ed un payload. l’header è costituito da una parte a struttura fissa (20 byte) ed una opzionale; il payload è creato di norma da un protocollo di trasporto (TCP o UDP), ma in circostanze particolari può contenere un altro pacchetto IP (incapsulamento IP in IP). Inoltre alcuni protocolli ausiliari (cioè non intesi a supportare la comunicazione di applicazioni eseguite nei terminali) inviano i loro messaggi inserendoli direttamente in un payload IP (ICMP, IGMP, OSPF) STRUTTURA DI UN DATAGRAMMA A LIVELLO IPV4 NUMERO DI VERSIONE. Questi quattro bit, che specificano la versione del protocollo IP del datagramma, consentono al router la corretta interpretazione del datagramma; infatti, versioni diverse di IP hanno differenti formati per i datagrammi. L’identificativo del protocollo IPv4 è 08 00 LUNGHEZZA DELL ’INTESTAZIONE (HEADER LENGTH ). Dato che può contenere un numero variabile di opzioni nel header, questi 4 bit indicano dove iniziano effettivamente i dati del datagramma. La maggior parte dei datagrammi IP non contiene opzioni, pertanto il tipico datagramma IP ha un’intestazione di 20 byte. T IPO DI SERVIZIO. I bit relativi al tipo di servizio (TOS, type of service) sono stati inclusi per distinguere diversi tipi di datagrammi (per esempio, quelli che richiedono basso ritardo, alto throughput o affidabilità). Spesso è utile distinguere datagrammi in tempo reale (usati nelle applicazioni di telefonia) da altro traffico. Lo specifico livello di servizio è determinato dall’amministratore del router. I due bit del campo TOS sono utilizzati per la notifica di congestione esplicita. LUNGHEZZA DEL DATAGRAMMA. Rappresenta la lunghezza totale del datagramma (intestazione + dati) misurata in byte. Considerato che questo campo è lungo 16 bit, la massima dimensione dei datagrammi IP è 65.535 byte, anche se rara- mente questi superano i 1500 in modo da non superare la lunghezza massima del campo dati dei frame Ethernet. IDENTIFICATORE , FLAG, OFFSET DI FRAMMENTAZIONE : indicatori che possono assumere il valore vero o falso. Il primo non è utilizzato, conservato per usi futuri. Gli altri due flag servono per la frammentazione. Il primo è il bit don’t fragment per imporre che il pacchetto non venga frammentato. Il secondo è il bit more fragment, che indica che ci sono ancora frammenti da elaborare. TEMPO DI VITA. Il campo time-to-live (TTL) è stato incluso per assicurare che i datagrammi non restino in circolazione per sempre nella rete (per esempio, a causa di un instradamento ciclico). Questo campo viene decrementato di un’unità ogni volta che il datagramma è elaborato da un router; quando raggiunge 0, il datagramma deve essere scartato. È un modo per prevenire che un pacchetto resti in circolo in tempo indefinito per un errore di configurazione della rete PROTOCOLLO. Questo campo è usato quando il datagramma raggiunge la destinazione finale. Il valore del campo indica lo specifico protocollo a livello di trasporto al quale vanno passati i dati del datagramma. Per esempio, il valore 6 indica che i dati sono destinati a TCP, mentre il valore 17 designa UDP. Il numero di protocollo nel datagramma IP ha un ruolo analogo a quello del campo numero di porta nel segmento a livello di trasporto: il primo è l’anello di collegamento tra i livelli di rete e di trasporto, mentre il numero di porta è il “collante” che lega i livelli di trasporto e di applicazione. CHECKSUM DELL’ INTESTAZIONE. Consente ai router di rilevare gli errori sui bit nei datagrammi ricevuti. È calcolato trattando ogni coppia di byte dell’intestazione come numeri che sono poi sommati in complemento a 1. Il complemento a 1 di questa somma, noto come checksum Internet, viene memorizzato nel campo corrispondente. Un router calcola tale valore per ciascun datagramma IP ricevuto e rileva una condizione di errore se il checksum trasportato nell’intestazione del datagramma non corrisponde a quello calcolato. I router normalmente scartano i datagrammi in cui si verifica un errore. Notiamo che il checksum deve essere ricalcolato e aggiornato a ogni router, come anche il campo TTL e i campi opzione, che possono cambiare. TCP/IP effettua la verifica di errore sia a livello di trasporto che di rete per diversi motivi: innanzitutto, notiamo che a livello IP il checksum riguarda soltanto l’intestazione, mentre il checksum TCP/UDP è calcolato sull’intero segmento e, in secondo luogo, TCP/UDP e IP non appartengono necessariamente alla stessa pila di protocolli. Essendo una checksum crittografica non protegge da alterazioni esterne. INDIRIZZI IP SORGENTE E DESTINAZIONE. Quando un host crea un datagramma, inserisce il proprio indirizzo IP nel campo indirizzo IP dell’origine e quello della destinazione nel campo indirizzo IP di destinazione. Un indirizzo IP è una sequenza di 32 bit (4 byte). Un pacchetto IP ha, nell’header, l’indirizzo IP del mittente e quello del destinatario e, in forma testuale, per un uso da parte di un utente umano, è solitamente rappresentato nella notazione dotted decimal per cui i 32 bit sono decomposti in 4 byte, il valore di ciascuno dei quali è riportato in decimale come numero naturale tra 0 e 255, scritti in sequenza separati dal punto OPZIONI. Questi campi consentono di estendere l’intestazione IP. Essendo state concepite per un utilizzo sporadico, l’informazione dei campi opzione non sono incluse nell’intestazione di tutti i datagrammi. Il problema delle opzioni risiede nella loro lunghezza variabile, per cui non è possibile determinare a priori dove comincerà il campo dati. Inoltre, dato che i datagrammi possono richiedere o non richiedere l’elaborazione delle opzioni, il tempo necessario per questa operazione su un router può variare in modo significativo. DATI (PAYLOAD). Nella maggior parte dei casi, il campo dati contiene il segmento a livello di trasporto (TCP o UDP) da consegnare alla destinazione. Tuttavia, può trasportare anche altri tipi di dati, quali i messaggi ICMP. I datagrammi IP hanno 20 byte di intestazione (escludendo le opzioni). I datagrammi non frammentati che trasportano segmenti TCP hanno 40 byte complessivi di intestazione: 20 di intestazione IP + 20 di intestazione TCP, assieme al messaggio di livello applicativo. IP: servizio best effort IP non garantisce la consegna di un pacchetto e quindi di prevenire: pacchetti duplicati: il tcp deve attuare delle misure per garantire una consegna affidabile del pacchetto, attuando un meccanismo di riscontro per cui attenderà un certo tempo una conferma di avvenuta ricezione dal destinatario, dopo il quale, se non ricevuta, il pacchetto verrà nuovamente inviato. Nulla impedisce però che la prima copia del pacchetto potrebbe essere arrivata a destinazione dopo il tempo massimo previsto: in questo caso Ip non si preoccupa di non passare il pacchetto duplicato, passandolo indipendentemente. Ciò comporta che un’applicazione che voglia offrire un servizio affidabile dovrà preoccuparsi di eliminare eventuali duplicati passati dall’Ip. consegna ritardata o fuori ordine: non da garanzie sul tempo che ci impiegherà un pacchetto ad arrivare a destinazione, né tantomeno sull’ordine, la cui gestione sarà compito del protocollo del livello superiore. corruzione di dati perdita di pacchetti FUNZIONI DI UN ROUTER: FORWARDING E ROUTING Ip sfrutta la tecnica dei datagrammi, per cui ogni router opera indipendentemente, ma non del tutto rispetto alle scelte degli altri (se ciò accadesse i pacchetti potrebbero rimanere in circolo indefinitamente); è necessario, comunque, un coordinamento dei router per individuare percorsi ottimali e consistenti nelle scelte. Il compito di scambiare informazioni per prendere decisioni coordinate è a capo dei protocolli di routing o di instradamento, che si collocano a livello rete e implementano delle logiche che sfruttano l’indirizzamento dei pacchetti. All’interno del router sono esplicate due funzioni fondamentali a fine di portare a termine il processo di instradamento: routing (determinazione delle regole di instradamento) e forwarding (inoltro effettivo dei pacchetti). La funzione di forwarding consiste nell’inoltrare ciascun pacchetto che entra da un’interfaccia verso un’altra interfaccia; deve essere coordinata, in modo da far sì che un pacchetto, generato da un qualunque host mittente, possa arrivare verso un qualsiasi host destinatario. La funzione di routing ha il compito di determinare i percorsi secondo determinate regole (path). A seconda dell’indirizzo di destinazione del pacchetto, che andrà confrontato con le opportune regole di instradamento, il router determinerà da dove dovrà uscire. Le due funzioni sono svolte contemporaneamente da due distinte sezioni del router, il Forwarding è esplicato dal data plane, mentre il Routing dal control plan Il control plane si occupa dell’instradamento e viene implementato in software, il data plane, occupandosi del confronto della destinazione con le regole definite, viene implementato totalmente in hardware; essi avranno quindi velocità diverse e in particolareil data plane deve essere molto più veloce e operare alla velocità dei link. Per capire quanto tempo impiega il router ad inviare un pacchetto (1Gb/s pacchetto di 1000 b) facciamo 1000/1Gb= 10^-6 s= 1micros. Se un router vuole tenere il suo link di uscita sempre occupato a far uscire qualcosa deve impiegare 1 microsecondo. Il control plane ha tempi più rilassati. ASSEGNAZIONE INDIRIZZI IP Gli indirizzi ip non sono associati al dispositivo, ma ad una sua interfaccia di rete (se un dispositivo ha più interfacce di rete connesse avranno tutti diversi indirizzi ip), e devono essere univoci per i dispositivi pubblici. È pertanto necessaria un’organizzazione che ne coordini l’assegnazione. Il gestore globale dell’intero spazio di indirizzamento è IANA - Internet Assigned Numbers Authority. IANA delega la gestione degli indirizzi IP a cinque autorità regionali (RIR) e in Europa opera come Regional Internet Registry il RIPE NCC. I registry regionali assegnano blocchi di indirizzi agli Internet Service Provider (ISP) ed alle grosse organizzazioni che, a loro volta, sono responsabili della assegnazione unica degli indirizzi di loro pertinenza ai singoli dispositivi delle proprie reti. RETI DI CALCOLATORI 11/10 LE MANSIONI DEL LIVELLO RETE il compito del livello trasporto è quello di consentire alle molteplici applicazioni eseguite in un end-system lo scambio di informazioni attraverso il servizio offerto dal livello rete, offendo come servizio la possibilità di consegnare dati e messaggi tra i processi applicativi, col la risoluzione del conseguente problema del multiplexing; in maniera opzionale può offrire il servizio di consegna affidabile dei pacchetti. Figura 1 Ogni processo genererà un proprio flusso di dati che sarà trattato separatamente dal livello trasporto. I diversi programmi in esecuzione concorrente all’interno di un terminale (end-system) sono detti processi. Il compito del livello trasporto è quello di consegnare i messaggi applicativi contenuti nei pacchetti che arrivano dal livello rete al processo al quale sono destinati Questa funzione di smistamento (demultiplexing ossia smistare tra i processi che sono gli effettivi destinatari di quell’informazione) è esplicata al livello trasporto attraverso un’informazione ausiliaria contenuta nell’header dei protocolli di livello trasporto: si assegna ad ogni processo in esecuzione su un host un numero identificativo (nell’ambito del sistema operativo è il PID), chiamato numero di porto o port number. Ogni applicazione che fa uso della rete si mette in ascolto su un determinato port number -che ora si dice occupato-, per cui all’arrivo dei messaggi il livello rete li smisterà alle applicazioni messe in ascolto sui corrispettivi port numbers. Così come al livello rete troviamo un IP destinazione e un IP sorgente, anche a livello trasporto avremo un port number destinazione e uno sorgente (anche il mittente si sarà messo in ascolto su un determinato port number). Un flusso a livello trasporto verrà identificato dalla quadrupla IP sorgente, IP destinazione, Port number Sorgente e Port number destinazione a cui si aggiunge un identificativo del protocollo di livello trasporto utilizzato (ricordiamo esistono diversi protocolli di cui i principali sono il TCP e l’UDP). Il Transport_protocol (TP) è un numero naturale rappresentato su 8 bit che identifica il protocollo di livello trasporto ed è collocato nell’header di livello rete (IP), 6 per TCP, 17 per UDP. La quintupla elimina ogni ambiguità specialmente in caso di host distinti che usano lo stesso numero di porta (essendo essi assegnati localmente e non univoci). Due flussi potranno essere distinti grazie agli indirizzi IP sorgente che differiscono da Host a Host. Una situazione possibilmente ambigua è quando su uno stesso host due applicazioni usano lo stesso numero di porto; questa però è esclusa dal sistema operativo che fa in modo che, quando un’applicazione si mette in ascolto su un numero di porto esso, lo rende occupato e non disponibile per altre applicazioni. PROTOCOLLO UDP Protocollo di livello trasporto molto semplice, che aggiunge al servizio di IP la mansione di demultiplexing grazie al port number e opzionalmente un controllo d’errore sull’intero datagramma UDP. Offre alle applicazioni un servizio di consegna best-effort ma senza garanzie di messaggi. Per ciascun messaggio applicativo ricevuto dall’applicazione e proveniente da un livello superiore, UDP forma un datagram IP, per cui però non è garantita né la consegna né il rispetto dell’ordine di sequenza. Opzionalmente, UDP effettua un controllo di correttezza del datagramma ricevuto tramite una checksum; se il controllo da esito negativo, il datagramma UDP è scartato Le applicazioni che usano UDP devono, se lo ritengono opportuno, implementare meccanismi che implementino contromisure nel caso di perdita di datagrammi o di consegna fuori ordine Le applicazioni che usano UDP sono orientate a semplici interazioni richiesta-risposta, per la rapidità dei suoi tempi di elaborazione, a scapito di un’effettiva garanzia sui pacchetti. PROTOCOLLO TCP Oltre alle funzionalità che offre l’UDP, TCP offre alle applicazioni un servizio di consegna senza perdite e con rispetto dell’ordine di uno stream di byte bidirezionale tra due endpoint Il servizio è di tipo connection-oriented, cioè, prima di iniziare la trasmissione dei dati, occorre stabilire una associazione (connessione) tra i due endpoint attraverso una procedura di connection establishment per cui sarà prevista anche una procedura di connection teardown per l’eliminazione della connessione precedentemente stabilita tra due endpoint. Una connessione TCP tra due endpoint X ed Y consente un flusso di dati bidirezionale (da X ad Y e viceversa) Un pacchetto è associato ad una connessione TCP mediante la quintupla: Transport_protocol, Source_IP_address, Source_port_number, Destination_IP_address, Destination_port_number Negli end-system, i processi si “agganciano” agli endpoint di una connessione TCP mediante opportuni strumenti di comunicazione previsti dal sistema operativo (socket) MODELLO CLIENT SERVER Il modello comportamentale a cui si ispira la maggioranza delle applicazioni distribuite è il modello client-server, che sfrutta quindi queste due definizioni. Un processo server è un processo in costante ascolto, ma che non comunica a meno di una richiesta esplicita; è in esecuzione su un host S, e si rende disponibile alla comunicazione attraverso il protocollo TCP o UDP, ad un numero di porta X noto a priori (well-known) ai client. Un processo client viene eseguito su un host C, acquisisce dal sistema operativo in esecuzione la disponibilità all’uso del numero di porta e “chiede” al sistema operativo di stabilire una comunicazione tramite TCP o UDP con il processo server, del quale conosce a priori l’indirizzo IP S ed il port number. L’interazione tra le componenti client e server delle applicazioni è governata da protocolli di livello applicativo che definisce il formato dei messaggi ed i pattern di interazione. I server, si mettono in ascolto su un numero di porto standard per evitare che i client ne debbano andare alla ricerca. Ciò però non vale (e non è necessario) per i client, però, che sono gli iniziatori della connessione verso il server: inviando ad esso il primo messaggio, sappiamo che questo conterrà l’indirizzo IP sorgente e numero di porto sorgente, fornendo al server automaticamente l’informazione necessaria per i propri messaggi di risposta. La scelta tra UDP e TCP dipende dalle caratteristiche dell’applicazione. Una volta definito un protocollo standard possiamo implementare diverse applicazioni che possono comunicare tra loro per il livello di standardizzazione. I servizi offerti tramite Internet si attengono a protocolli applicativi standard definiti dall’IETF e definiti in specifici documenti RFC HTTP È un protocollo definito in documenti RFC (il primo RFC1945 del ’96) pensato per trasferire gli ipertesti ossia testi con un collegamenti che rimandano ad altri testi, nel tentativo di svincolarci da applicazioni specifiche che assumono determinate scelte arbitrarie: se abbiamo un protocollo standard che definisce come interagire, allora possiamo implementare un’eterogeneità di applicazioni che svolgeranno le mansioni richieste indipendentemente dalla loro natura. Esso si basa sul protocollo TCP, in quanto vogliamo la corretta visualizzazione delle sue applicazioni e adotta il modello client server per cui il client apre una connessione TCP verso il server in ascolto sul porto 80 che accetta la connessione in seguito alla quale possono scambiarsi messaggi secondo le norme del protocollo. Vive di serie di richieste e di risposte: il client chiede una risorsa che il server gli inoltrerà, dove per risorsa si intende o un testo o un’immagine presente all’interno di una pagina web. Dopo aver inviato la risposta al client il server chiude la connessione TCP, dando viga ad un unico scambio richiesta-risposta; per ulteriori domande sarà necessario stabilire un’ulteriore connessione TCP. Per questo motivo Il protocollo HTTP è stateless: né il server né il client mantengono a livello HTTP informazioni relative ai messaggi precedentemente scambiati e quindi informazioni di stato (Il concetto di stato ha infatti senso solo in una sessione) Per identificare una risorsa richiesta da un client si sfrutta un url (uniform Resource Locator) che ha il seguente formato http://host[:port]/path[#fragment][?query] L’host identifica il server e può essere sia un nome simbolico che un indirizzo IP in notazione dotted decimal. Opzionalmente, esso sarà seguito dal numero di porto per contattare il server in ascolto, che se non specificato, assume il valore di default 80. La risorsa è specificata dopo lo slash e l’esplicazione del percorso. Opzionalmente il simbolo di # indica l’inizio di un riferimento alla specifica sezione che viene richiesta. ?query è usato per passare informazioni dal client al server, come passare i dati inseriti nei campi di una form al server. Tipicamente, una pagina web è descritta da un file testuale in formato HTML (Hypertext Markup Language, standard per la codifica di un ipertesto), che può contenere riferimenti ad altri oggetti che arricchiscono la pagina con elementi grafici (sfondo, immagini, ecc.) Ciascun oggetto è identificato dal proprio URL e possono trovarsi anche su server web diversi Una volta ricevuta la pagina HTML, il browser estrae i riferimenti agli altri oggetti che devono essere prelevati e li richiede attraverso una serie di connessioni http. MODELLO DI INTERAZIONE A seguito dello stabilimento della connessione TCP, viene inviata la richiesta http con cui il client chiede al server il file html che descrive la pagina web fornita. Per effetto di questa prima richiesta il browser ottiene la pagina e ne fa il rendering, ma, per ogni risorsa ulteriore da dover caricare (ex immagini) il client opera una nuova richiesta al server (è possibile anche creare ulteriori connessioni con altri server). Tipicamente le diverse risorse vengono richieste contemporaneamente e non serialmente per aumentare le prestazioni. A tal fine, non si può mantenere una connessione TCP fissa proprio per non appesantire il server oltre che evitare DoS. I server che usano la s aggiungono un ulteriore livello di sicurezza. Indagando sullo scambio tra client server su un sito internet, come primo pacchetto dovrei trovare un pacchetto TCP. Tuttavia i browser per velocizzare le cose possono aprire delle connessioni tcp a vuoto col server, di cui alcune sono utilizzate altre rimangono aperte. Quando effettuo la stessa richiesta ricaricando la pagine, sfrutto quelle connessioni residue, per cui il primo pacchetto che trovo è http. http è un protocollo testuale, ossia un messaggio http è un messaggio di testo per cui ogni carattere sarà codificato mediante il corrispondente codice ASCII (per ogni carattere sarà utilizzato 1B). Il payload dei messaggi può essere comunque anche in formato binario (es. un’immagine GIF, un video, ecc.) FORMATO DAI MESSAGGI DI RICHIESTA DI UN CLIENT (formati da un header e da un payload) L’header è costituito da una prima riga di richiesta che specifica il tipo di richiesta che il client sta facendo al server, e da una serie di linee ulteriori chiamate header lines. Queste righe constano di: Metodo: operazione che il client sta chiedendo al server (quello più utilizzato è il metodo GET). Versione di http specificata in formato testuale. Caratteri di fine riga e andata a capo (0d 0a) Ogni riga specifica poi il valore di un determinato attributo. L’ultima riga è vuota e contiene solamente caratteri di fine riga e andata a capo Reti di calcolatori Ogni connessione consta di tre messaggi, secondo la filosofia three way handshake: col primo messaggio stabilisco la connessione, col secondo si effettua la richiesta, col terzo si chiude la connessione. Sappiamo che si definisce metodo una qualsiasi operazione richiesta dal client: una richiesta HTTP è caratterizzata proprio dal campo Method nella Request Line. Esistono diversi metodi di richiesta http, ma ogni versione può aggiungere dei nuovi metodi GET HEAD POST PUT DELETE TRACE OPTIONS Essi possono essere caratterizzati sulla base di due proprietà. Sicuro quando non richiede cambiamenti lato server; ad esempio, i metodi GET e HEAD sono sicuri Idempotente quando l’effetto di più richieste identiche sul server è lo stesso di quello di una sola richiesta. I metodi HTTP sono tutti idempotenti tranne POST IL METODO GET è utilizzato per richiedere una risorsa identificata da un URL per cui se la risorsa è disponibile, il server la invia nel body del messaggio di risposta. GET è un metodo sicuro (è in un certo senso di sola lettura) ed idempotente. È il metodo più frequentemente usato: viene attivato ad esempio in un browser quando si fa click su un link ipertestuale di un documento HTML o si inserisce un URL nella barra degli indirizzi del browser. GET può avere diverse forme a seconda di vari attributi esplicitati nell’header. Esso può essere: assoluto: la risorsa viene richiesta senza altre specificazioni condizionale: si richiede la risorsa a patto che sia soddisfatto un criterio indicato negli header dal client. Il client può includere delle condizioni quali “If-match, If-modified-since, If-range” ecc. parziale: si richiede una sottoparte di una risorsa memorizzata IL METODO HEAD è simile a GET: si richiede la validità̀ di una risorsa identificata da un URL, ma differenza di GET, nel caso di HEAD la risorsa non viene inviata nel messaggio di risposta: è solo un modo per verificare se la risposta è disponibile, senza effettivamente ottenerla. Head è un metodo sicuro ed idempotente e serve al client per verificare: Validità di un URL e per apprendere le caratteristiche della risorsa rappresentate nell’header del messaggio di risposta Accessibilità di un URL, cioè per verificare se l’accesso ad una risorsa non sia vincolato ad una autenticazione Verifica di coerenza di una copia della risorsa già disponibile nella cache del browser rispetto all’originale sul server. Nei messaggi di risposta il server indica anche la data di modifica della risorsa per cui il client può sapere se è stata alterata o meno senza riottenerla (tuttavia ciò è meglio realizzato con la GET condizionale) IL METODO POST è usato per trasmettere informazioni in direzione opposta, dal client al server senza la creazione di una nuova risorsa. Nell’header ci saranno i valori di alcuni attributi che il client vuole inviare al server. POST è un metodo non sicuro ( il server modificherà il proprio stato sulla base delle informazioni inviate dal client) e non idempotente (non è detto che invocare più volte il post abbia lo stesso effetto, in quanto dipende dalla risposta del server) L’URL presente nel messaggio di richiesta è associato ad un programma eseguito sul server che riceve come input le informazioni inviate dal client nel body del messaggio di richiesta Il server può rispondere positivamente in tre modi: 200 Ok: dati ricevuti e sottomessi alla risorsa specificata; è stata data risposta 201 Created: dati ricevuti, la risorsa non esisteva ed è stata creata 204 No content: dati ricevuti e sottomessi alla risorsa specificata; non è stata data risposta Poiché html genera una pagina statica, è nata l’esigenza di dare vita a pagine dinamiche che cambiassero il proprio stato. Ciò è realizzato mettendo in esecuzione in lato server un’applicazione apposita che interagisce con l’utente, capace di mantenere un’informazione di stato. Il protocollo http fa da tramite, ma la memorizzazione dello stato non avviene attraverso esso perché è un protocollo stateless. In un’applicazione web, è possibile includere delle form utilizzando delle get e delle form con un codice come questo: First name: Last name: Il metodo get può essere utilizzato per inviare dei dati al server sfruttando la struttura dell’url, per cui esso può contenere dopo ? un insieme di attributi da inviare al server, consapevoli però che esse espongono molto facilmente informazioni al furto. È più opportuno utilizzare una combinazione di metodo post e protocollo ssl (Secure Sockets Layer e successivamente Transport Layer Security sono dei protocolli crittografici web per proteggere le comunicazioni client-server). Se i valori di una form vengono inseriti in una url, è possibile salvarlo così da poter accedere alla pagina senza dover necessariamente reinserire i dati. IL METODO PUT serve per trasmettere delle informazioni o risorse dal client al server (quindi non dati!), creando o sostituendo la risorsa specificata dall’URL. Per questo PUT è un metodo non sicuro (va a modificare lo stato del server) ma idempotente. In caso di risposta positiva ad una richiesta PUT, i dati inviati nel body del messaggio PUT dovrebbero costituire il valore della risorsa che il server restituisce ad una successiva richiesta GET per la stessa URL. Per motivi di sicurezza, questo metodo è scarsamente utilizzato. STRUTTURA DEI MESSAGGI DI RISPOSTA HTTP Versione del protocollo http Status code: contiene un codice che indica l’esito della richiesta mossa dal client Reason Phrase: una frase che fornisce qualche informazione in più sulle motivazioni della status code Le altre righe possono contenere coppie attributo valore CODICI DI RISPOSTA : Lo status code è un numero di tre cifre, di cui la prima indica la classe o categoria della risposta, e le altre due indicano la risposta specifica. Esistono le seguenti classi: 1xx: Informational: rappresenta una risposta temporanea alla richiesta, durante il suo svolgimento, inviata a titolo informativo prima di fornire la risposta definitiva 2xx: Successful: Il server ha ricevuto, capito e accettato la richiesta 3xx: Redirection: Il server ha ricevuto e capito la richiesta, ma sono necessarie altre azioni da parte del client per portare a termine la richiesta 4xx: Client error: La richiesta del client non può essere soddisfatta per un errore da parte del client (errore sintattico o richiesta non autorizzata) 5xx: Server error: La richiesta può anche essere corretta, ma il server non è in grado di soddisfare la richiesta per un problema interno Alcuni esempi di codici specifici sono 100: Continue (se il client non ha ancora mandato il body, metodo GET versione parziale) 200 Ok (GET con successo) 201 Created (PUT con successo) 301 Moved permanently (URL non valida perché la risorsa si trova in una locazione differente, il server indica la nuova posizione (Location: )) 400 Bad request (errore sintattico nella richiesta, non conforme alle regole del protocollo) 401 Unauthorized (manca l’autorizzazione) 403 Forbidden (richiesta non autorizzabile) 404 Not found (L’oggetto richiesto non è presente sul server, URL non valido) 500 Internal server error tipicamente un programma in esecuzione sul server ha generato errore 501 Not implemented metodo non conosciuto dal server 505 HTTP Version Not Supported La versione del protocollo HTTP usata non è supportata dal server HEADER GENERALI Gli header generali si applicano solo al messaggio trasmesso e si applicano sia ad una richiesta che ad una risposta, ma non necessariamente alla risorsa trasmessa. Alcuni attributi generali sono Date: data ed ora della trasmissione MIME-Version: Mime è uno standard che fornisce una classificazione dei diversi formati di codifica delle diverse tipologie di risorse. Ad esempio, definisce la categroia di risorse immagine e i possibili metodi di codifica (JPEG, PNG, BITMAP…). Anche se il formato di una risorsa è indicato dall’estensione del nome del file, non ci si affida su di essa, ma sul suo contenuto. Quando un messaggio http contiene una risorsa, sarà necessariamente presente questo attributo. Questo attributo definisce la versione MIME usata per la trasmissione. È sempre 1.0. Content type: usa le informazioni del protocollo mime per stabilire il tipo di risorsa utilizzato. Questo attributo può essere utilizzato nella richiesta per specificare i formati che accetta. Transfer-Encoding: il tipo di formato di codifica usato per la trasmissione Cache-Control: il tipo di meccanismo di caching richiesto o suggerito per la risorsa Connection: riguarda la possibilità di tenere aperta la connessione tcp dopo l’invio della risposta, a seconda della richiesta del client. Indica il tipo di connessione da usare: Connection: Keep-Alive → tenere attiva la connessione TCP dopo la risposta Connection: Close → chiudere dopo la risposta Via: usato da proxy e gateway Reti di calcolatori ALTRI TIPI DI HEADER HEADER DI RISPOSTA : Forniscono informazioni sulla risposta e su se stesso al client Gli header della risposta sono posti dal server per specificare Server: una stringa che descrive il server (tipo, sistema operativo e versione) Accept-ranges: specifica che tipo di range può accettare (valori previsti: byte e none) HEADER DELL’ENTITÀ danno informazioni sul body del messaggio con lo standard MIME, o, se non vi è body, sulla risorsa specificata. Essi sono presenti sia nei messaggi di richiesta che di risposta. Alcuni esempi sono Content-Type: oggetto/formato, Obbligatorio in ogni messaggio che abbia un body perché obbligatorio specificare un tipo di risposta. Ogni coppia oggetto/formato costituisce un tipo MIME dell’entità acclusa. Specifica se è un testo, se un’immagine GIF, un’immagine JPG, un suono WAV, un filmato MPG, ecc... Content-Length: la lunghezza in byte del body. Non è detto che l’intera risposta venga trasferita in un unico trasporto perché tcp potrebbe segmentarla sulla base dell’algoritmo di controllo di congestione. L’applicazione ricevente non può assumere che il blocco ricevuto sia un messaggio intero, perciò deve necessariamente capire la lunghezza della risorsa per poter intendere che essa non è contenuta interamente nel blocco ricevuto. (È fondamentale ricordare che tcp opera su flussi). Per cui risulta obbligatorio, soprattutto se la connessione è persistente Content-Base (url di base della risorsa), Content-Encoding (come è stata codificata la risorsa, che ci informa magari se è stata compressa o meno, a seconda di una determinata richiesta del client nella get che si è detto disponibile a riceverla), Content- Language (MD5 per un controllo di integrità), Content-Location, Content-MD5, Content- Range: l’URL di base, la codifica, il linguaggio, l’URL della risorsa specifica, il valore di digest MD5 e il range richiesto della risorsa Expires: una data dopo la quale la risorsa è considerata non più valida (e quindi va richiesta o cancellata dalla cache) Last-Modified: la data e l’ora dell’ultima modifica Serve per decidere se la copia posseduta (es. in cache) è ancora valida o no Obbligatorio se possibile. TELNET È un’applicazione che in origine è stata pensata come shell remota, che ci permetteva di scrivere comandi sul nostro pc da eseguire sull’host remoto. Con essa stabiliamo quindi connessione tcp verso un determinato host (di cui forniamo l’indirizzo ip) e un determinato numero di porto. Tutti i caratteri digitati sulla tastiera vengono da esso trasportati fino ad arrivare a destinazione in ascolto sul porto sul quale abbiamo creato la connessione. È necessario che ci sia un processo in ascolto sul porto dell’host ricevente per rispondere alla richiesta di connessione. Il mittente può sostituirsi a qualunque client di un protocollo che prevede messaggi di tipo testo. COOKIES HTTP è stateless: il server non è tenuto a mantenere Un cookie è una breve informazione scambiata tra il server ed il client. Tramite un cookie il client mantiene lo stato di precedenti connessioni, e lo manda al server di pertinenza ogni volta che richiede un documento: a seguito di una prima richiesta, le sue informazioni di stato vengono rimandate dal server al client, che può accettarle. Al re-inoltro di una ulteriore richiesta da parte del client, questa includerà anche un riferimento al cookie. I cookie sono stati definiti originariamente nel 1997 in RFC2109, presentati come una tecnica indipendente da http, che nei suoi RFC non vengono menzionati. Attualmente definiti in RFC 2965 “HTTP State Management Mechanism”. Il cookie viene veicolato tramite un header di risposta del messaggio del server In aggiunta ad un nome ed un valore, un cookie può avere degli attributi che ne specificano la durata o lo “scope”, specificati solo nei messaggi di risposta del server. Gli attributi che definiscono la durata di un cookie sono: Expires: specifica una data oltre la quale il browser deve eliminare il cookie come con la riga di comando “Set-Cookie: sessionToken=abc123; Expires=Sat, 09 Jun 2019 10:18:14 GMT” Max-Age: specifica dopo quanti secondi, rispetto al momento della ricezione, il browser dovrà eliminare il cookie, come con la riga “Set-Cookie: sessionToken=abc123; Max-Age=300”. Questo attributo non è supportato da Internet Explorer Un cookie per il quale non è specificata la durata è detto un session cookie e dura finché il browser non è chiuso SCOPE Un cookie può essere dotato anche di attributi di scope: la visibilità di un cookie può essere allargata anche ad un intero dominio e non ad un singolo server. L’attributo Domain indica i domini a cui si applica il cookie. Se non è specificato, il browser invia il cookie a tutte le successive richieste fatte al server dal quale il cookie è stato ricevuto: ad esempio, se il server docs.foo.com invia il cookie il cookie sarà inviato a tutte le successive richieste fatte ai server del dominio foo.com (es. anche ad images.foo.com). L’attributo Path indica a quali oggetti (URL) si deve applicare il cookie. Se Path=/ il cookie si applica a tutti gli oggetti. ROUND TRIP TIME E CONNESIONI HTTP Il comportamento previsto dalla prima versione di http 1.0 era che ogni singola connessione venisse utilizzata per una sola richiesta e che per questo era chiamata non persistente. Con la versione 1.1 si aggiunge anche la possibilità di mantenere, su richiesta del client, aperta la connessione a seguito di una richiesta, chiudendola solo al loro termine (keep alive), per cui questa è una versione persistente. Col protocollo 1.1 le risorse possono essere parallelizzate o chieste “simultaneamente”: il client manda una richiesta una dopo un’altra senza attendere la risposta del server, mettendole in fila una dopo l’altra e mandandole al tcp, che le tratta come uno stream. Le attuali implementazioni non sfruttano il modello di pipelining, ma preferiscono sfruttare più porti. Utilizzare 5 connessioni parallele può aiutare a smaltire il carico più velocemente, senza trattarle come un’unica connessione con tanti dati da trasmettere: più sessioni hanno più throughput rispetto ad una grande connessione. WEB CACHING Si parla genericamente di Web caching, quando le richieste di un determinato client non raggiungono il Web Server, ma vengono intercettate da una cache. Una web cache o proxy è quindi un’applicazione in esecuzione su un dispositivo che ha lo scopo di memorizzare i dati ricevuti in un certo momento per poterli poi riutilizzare. Tipicamente, un certo numero di client di una stessa rete condivide una stessa cache web, posta nelle loro prossimità (es. nella stessa LAN) in modo tale che, se diversi host chiedano la stessa risorsa, non sarà necessario scaricare lo stesso contenuto più di una volta. Se l’oggetto richiesto non è presente nella cache, sarà questa a richiederlo invece del client, conservandone poi una copia per eventuali richieste successive, così che esse sono così servite più rapidamente. Per fare in modo che la cache intercetti le risorse richieste dall’utente, ci sono diverse strategie. La soluzione a cui si fa riferimento è quella con cui sui client viene fatta un’esplicita configurazione che rende possibile l’intercettazione di risorse della cache. Quando su un host viene configurato un proxy/cache, anziché stabilire la connessione tcp col server, la stabilisce con la cache, così che faccia da intermediario con il server, memorizzando le richieste ricevute. È possibile connettersi a diversi proxy associate a diversi indirizzi http così da poter accedere ai servizi ad essi riservati GESTIONE DELLA COERENZA Un Problema nella cache è capire se una risorsa memorizzata è ancora valida oppure no: cosa succede se l’oggetto presente nel server è aggiornato rispetto a quello salvato sull’host? Questo si chiama problema della coerenza tra risorsa memorizzata nella cache e risorsa attuale, per cui la copia in cache deve essere aggiornata per mantenersi uguale all’originale HTTP fornisce due meccanismi per la gestione della coerenza: TTL (Time To Live) con cui il server, quando fornisce un oggetto, ne indica anche la data di scadenza (header Expires). Quando TTL diventa < 0, non è detto in realtà che l’oggetto sia stato realmente modificato, per cui il client può fare un ulteriore controllo mediante una GET condizionale (If-Modified-Since) Questo algoritmo è implementabile anche da un browser sul singolo host (che avrà comunque lì la propria cache, mantenuta da esso anche se noi non la configuriamo). BROWSER Un browser è costituito da un'interfaccia utente (UI) e un browser engine, contenente le procedure, data la pagina html, per interpretarla e mostrarla sullo schermo Un browser engine è, a sua volta, composto da Un layout engine che decodifica e visualizza il documento HTML e gli oggetti multimediali in essa contenuti e le procedure per poter interpretare ed eseguire i codici di diversi linguaggi. http è utilizzato anche quando lato serve c’è un’applicazione in esecuzione. Un JavaScript engine che esegue il codice JavaScript incapsulato nel documento HTML o contenuto in altri file esterni (file.js) Reti di calcolatori Protocolli applicativi FTP e SMTP FTP (FILE TRANSFER PROTOCOL) è un protocollo applicativo definito agli albori di internet, descritto in RFC959. Internet, infatti, nasce con l’idea di trasferire file da un computer a un altro, senza limiti di distanza, connettendo anche due punti in locazioni remote. La sua idea è quella di non necessariamente dover trasferire un solo file da un computer a un altro, cosa possibile anche con http (con GET), ma per poter stabilire una intera sessione tra due dispositivi all’interno della quale scambiare più file. Esso lavora utilizzando due sessioni o connessioni: una dati e un controllo (out of band). Il protocollo di trasporto utilizzato è il TCP, che garantisce l’affidabilità nello scambio dei messaggi. Adotterà inoltre un paradigma client (l’entità che dà luogo al trasferimento ) -server (entità remota che è in continua attesa di connessioni FTP da parte di altre per cui); poiché si scambiano sia dati sia comandi (inviati dal client) è opportuno avere due tipi di connessione tcp adatta ad una specifica risorsa da trasferire, per non confondere dati e comandi, che tcp tratterebbe indistintamente come un flusso (problema che non sussiste con http, con cui ad ogni singola richiesta viene prodotta una risorsa, senza gestire molteplici richieste in parallelo). Anche qui il lato server sarà in ascolto su un porto prestabilito al numero 21 per la ricezione di connessioni di controllo, 20 invece per la ricezione di connessioni dati. Quando ci colleghiamo in ftp dobbiamo autenticarci (un server può essere multiutente), per proteggere i file appartenenti ad altri privati e darci accesso ai nostri. Ciò si realizzza con la riga ftp nome@pagina. Stabilisco una sessione tra client e server, in quanto mantrngo informazioni di stato. Poiché l’utente può navigare le diverse directory presenti sul server, è necessario un concetto di stato. I messaggi che il client e il server si scambiano vengono inviati come testo ASCII sulla connessione di controllo, sia per i comandi che per le risposte. In ogni computer esiste un’interfaccia di rete virtuale che non è collegata all’esterno, che consente a due processi in esecuzione sulla stessa macchina di comunicare tra loro, chiamata local host:1 è l’indirizzo ipv6 del sito specificato, per cui in seguito, se il collegamento è fallito, si crea un indirizzo ipv4. Dopo aver aperto il pacchetto successivo, il server fornisce al client una stringa con cui si fa riconoscere. Il client ha fatto partire un messaggio per comunicare il nome dell’utente, tramite il nome che abbiamo specificato nella riga di inizializzazione del protocollo ftp. Con la richiesta di immissione della password, essa viene inviata al server dopo averla digitata. Prima di inviare la richiesta, il client crea la connessione dati. La risposta al comando ls viene è vista come un insieme di dati, trasferiti su un’altra connessione. Ora il server deve aprire una connessione verso il client. Il trasferimento client server può avvenire secondo due filosofie. FTP ATTIVA E PASSIVA. Il Client apre una connessione di controllo, creando una sessione, verso l’indirizzo del server sul porto 21 utilizzando un ephemeral port. Il Server apre una connessione dati dal porto 20 verso il client. Il server invia una richiesta al client di connessione dati, sfruttando l’indirizzo acquisito connessione precedente stabilita, a cui seguirà una conferma di corretta acquisizione del porto. Il numero di porto è costituito da 2 byte in dotted notation, corrispondente ad un’unica stringa binaria da convertire in decimale (oppure in 2 numeri in base 256= num1x256+ num2). Ora il client potrà invia un comando -definito dal protocollo FTP- relativo alla risorsa desiderata. Il problema della connessione attiva è che il server invia una richiesta al client di connessione dati, creando problemi quando il client non ha un indirizzo pubblico oppure si trova dietro un firewall. FTP PASSIVA Per risolvere tale problema, fu introdotta la passive mode, nel momento in cui si sono cominciati ad utilizzare indirizzi privati e port forwarding. Il Client apre una connessione di controllo verso l’indirizzo del server sul porto 21 utilizzando un ephemeral port. Il Server sceglie un ephemeral port per la connessione dati e la comunica al Client. Il Client apre la connessione dati sul porto indicato dal server. Ciò accade per permetter al server di associare una nuova connessione dati lato client a una connessione di controllo lato già esistente in quanto ha la facoltà di seguire più client ftp contemporaneamente. Quando il client ha inviato il messaggio passive al server. Ciò avviene con la connessione 2, in cui il server fornisce al client il numero di porto verso il quale il client dovrà comunicare la sua richiesta di connessione dati. PROTOCOLLO SMTP (SIMPLE MAIL TRANSFER PROTOCOL) È un protocollo per il trasferimento di mail. Una volta che una e-mail è stata scritta attraverso l’uso di un programma su un personal computer, è necessario inviarla al destinatario. Come è noto, il destinatario potrebbe non essere in quel momento disponibile ad accettare messaggi di posta (utente impegnato, computer spento). Il destinatario delle nostre mail deve essere quindi un server sempre in esecuzione ossia un server SMTP. Inviare un messaggio direttamente al destinatario presupporrebbe che egli sia sempre pronto. Per questo la posta elettronica sfrutta degli intermediari per il trasferimento delle e-mail tra le parti, alla stregua degli uffici postali che ospitano pacchi nell’attesa che i destinatari passino a ritirarli, utilizzati sia per inviare la posta elettronica sia per conservarla in attesa che l’utente sia di nuovo disponibile Per trasferire messaggi di posta elettronica tra gli intermediari si utilizza un apposito protocollo di nome Simple Mail Transfer Protocol, definito in RFC821. Nella infrastruttura del servizio di posta elettronica, ci saranno gli utenti o user agent ossia le applicazioni utente che gestiscono la posta (outlook, mail, gmail) e i server con duplice funzione. protocollo SMTP definisce un protocollo per definire la comunicazione tra questi due enti. È parlato sia dallo user agent quando deve inviare una mail al server utilizzato dall’utente che dal mail server di origine e il mail server di destinazione. Durante l’inoltro della mail al server destinatario, il nostro server sorgente fungerà da client, in quanto inizierà la connessione con la destinazione, implementando quindi sia le funzionalità lato client, che quelle lato server. Anch’esso utilizzerà il protocollo TCP perché non vogliamo mail corrotte, in cui il porto scelto per l’ascolto del server è il 25. Anche il protocollo SMTP NON è un protocollo stateless. Nell’ambito di una sessione del SMTP avranno luogo 3 fasi: handshaking (inizializzazione, condivisione indirizzo del mittente e destinatario) Trasferimento del messaggio (ripetibile più volte) Chiusura della connessione. L’interazione è sempre di tipo comando risposta, dove i messaggi sono di tipo testo. I messaggi però saranno codificati con caratteri ASCII a 7-biy Protocollo SMTP -2 Un Mail Server rappresenta una mailbox contenente messaggi in entrata (non letti) per l’utente e la coda dei messaggi in uscita non ancora recapitati Per rendere possibile l’interazione tra due mail server si sfrutta il protocollo SMTP che li classifica: “client”: mail server mittente “server”: mail server destinatario Un “mail server” può fungere, in momenti diversi, da client o da server a seconda del ruolo che ricopre nello scambio del messaggio ( se viene contattato dall’utente o si mette in contatto con il mail server di destinazione aprendo una connessione). I messaggi vengono codificati in codifica ASCII a 7 bit (tra 0 e 127). ESEMPIO INTERAZIONE CLIENT SERVER Il formato dei messaggi è definito dal protocollo SMTP Nella prima fase di handshaking dobbiamo inviare prima di tutto un messaggio di hello, indicando il nome del dominio di origine del mittente della mail. Il server risponde (250). MAIL FROM: viene utilizzato dal client per specificare l’indirizzo mail del mittente. I messaggi risposta contengono sempre un codice di stato. RCPT TO: Il client specifica con un altro messaggio il destinatario della mail. Prima di dare la sua approvazione il server fa dei controlli per assicurarsi che il destinatario appartenga a un dominio valido. DATA: il messaggio vero e proprio viene inviato. Codice 354: il server chiede al client ulteriori informazioni (di inserire un punto). Riconosciuta la fine del messaggio, il server invia una conferma di invio. La comunicazione viene interrotta con QUIT. Operazione di relay : operazione con cui si sfrutta un mail server intermedio tra il dominio mittente e il dominio destinazione. Alcuni server si rifiutano di inviare mail che non provengono dal proprio dominio, non consentendo il relay, in quanto gmail non sfrutta mailserver intermedi. FORMATO DEL MESSAGGIO SMTP Nell’header ci sono una serie di linee possibili per specificare le generalità di mittente e destinatario. Il body rappresenta il vero e proprio contenuto della mail, che può essere sia in formato testo che in formato HTML e può includere uno o più allegati multimediali. Le informazioni del body della mail sono codificate grazie allo standard mime, introdotto appositamente per la gestione del problema. Ad esempio, si inserisce nel header un attributo content type che ci informa del tipo di allegato successivo. Per allegare le immagini sarà inoltre necessaria una codifica, in quanto smtp prevede che il contenuto del messaggio sia codificato con la codifica ASCII-7 bit, che prevede che in un byte, il bit più significativo deve essere pari a 0. Dobbiamo quindi garantire che i byte delle immagini rispettino i parametri di codifica, mediante un’operazione di codifica per rendere l’immagine nel formato appropriato. Una delle codifiche più utilizzate per questo scopo è la codifica base64 che produce in uscita byte che contengono valori da 0 a 63, ossia una codifica su 6 bit, che sicuramente soddisfa il requisito di smtp. Ad esempio, consideriamo 3 byte: 11000110 01110011 11010001 (rappresentano un file da allegare). Suddividiamo i byte in gruppi di 6 bit, a cui aggiungeremo due 0. 110001|10 0111|0011 11| 010001 => suddivisione codice originale 00110001|00100111|00001111|00010001 => gruppi di 6 + due 0 Avremo quindi un byte in più, dovuto all’incremento della dimensione portato dalla codifica su base64, che quindi renderà l’allegato più pesante. Alla ricezione si dovrà fare chiaramente la conversione inversa. Il content type si presenterà in questa forma: type/subtype; parameters. Normalmente è opportuno che le mail siano inviate sia in formato HTML che in formato testo, in quanto non tutti i client potrebbero essere dotati di capacità di rendering. Sarà necessario dividere le due parti in modo tale da poter saltare all’una o altra a seconda della capacità, sfruttando lo standard MIME, attraverso cui sarà definito il content type che apparterrà alla categoria multipart (esistono due parti), con sottotipo alternative, proprio perché le due parti sono una l’alternativa dell’altra. In questo caso la codifica non è base64 ma a 7 bit. La categoria multipart richiederà dei delimitatori che vadano a dividere le parti che compongono la mail, rappresentato dalla stringa boundary, che segna la fine di una parte e l’inizio di un’altra. Anche qui dovrà essere specificato il Content type della parte che inizia. PRELIEVO DELLA POSTA : POSTOFFICE PROTOCOL Fino ad ora abbiamo visto come sia possibile trasferire messaggi tra i vari mail server. Non abbiamo però ancora parlato di come un utente possa, in un momento qualsiasi, accedere alla propria casella di posta elettronica per leggere i propri messaggi. Per questa operazione è previsto un ulteriore protocollo definito in RFC 1939 Esso è chiamato POP3 (Post Office Protocol – versione 3) Si tratta sempre di un protocollo client server: lo user agent ancora una volta gioca il ruolo di client POP il mail server gioca il ruolo di server POP RIASSUMENDO: SMTP: consegna di messaggi Protocolli di accesso alla mail: recupero dei messaggi dai server e visualizzazione mail POP: Post Office Protocol. Richiede autorizzazione (agent server) e download IMAP: Internet Mail Access Protocol [RFC 2060] più complicato e potente Una manipolazione avanzata dei messaggi sul server http avviene grazie a gmail, Hotmail, Yahoo! Mail, ecc. Il protocollo POP consente di prelevare e cancellare le mail presenti nella inbox, basato su TCP ed è di tipo testo, per cui è possibile emularlo usando il client di tipo tellnet. Imap è un protocollo più sofisticato che mantiene la sincronizzazione tra dispositivi. RETI DI CALCOLATORI 22-10 PROTOCOLLO DNS (DOMAIN NAME SYSTEM) Tutti noi oggi siamo abituati a raggiungere un servizio utilizzando nomi simbolici di facile memorizzazione. Questi nomi non sono immediatamente adatti ad essere compresi dai dispositivi che costituiscono la rete internet. Un nome di questo tipo, infatti, non da informazioni esatte sulla dislocazione sul territorio della macchina da contattare. I router non saprebbero come instradare i dati in maniera tale da raggiungere la destinazione. Inoltre, c’è un problema di memorizzazione, per cui la lunghezza del nome simbolico non è fissa, rendendo le elaborazioni meno comode. Nasce quindi un problema di traduzione, con cui far corrispondere l’indirizzo Ip al dato nome simbolico. Il DNS si occupa di effettuare questa corrispondenza. Essendo indispensabile, esso fu introdotto nei primi RFC. Esso si presta ad una interazione di tipo client server e domanda riposta. A differenza dei protocolli precedenti, il DNS normalmente non si basa su TCP per il trasferimento domanda-risposta in quanto esso aggiunge ritardo indesiderato e un rallentamento dovuto al controllo di congestione. Il DNS si basa su un singolo scambio richiesta risposta, e quindi sul protocollo UDP (il server ricevente sarà in ascolto sul porto 53), per cui sarà fondamentale una bassa latenza, piuttosto che l’affidabilità: se arriva una risposta sbagliata, l’utente riprova semplicemente a reinviare la richiesta. Il server DNS può essere utilizzato anche per funzioni di: aliasing dei nomi degli host, con cui a una macchina con un nome complicato può essere associato un soprannome più piccolo e semplice da ricordare (P.es.: rcsn1.roma.rai.it ->www.rai.it) mantenimento di indirizzi ip dei server smtp di risposta, a cui si associa il nome di un dominio per facilitare la memorizzazione dell’indirizzo di posta, distribuzione del carico: quando un server gestisce un carico troppo elevato si suole replicare il suo contributo su molte macchine differenti, il servizio dns distribuisce il carico tra le macchina rilasciando ciclicamente gli indirizzi appartenenti all’intero pool. Il problema della realizzazione di server dns presenta due soluzioni, una centralizzata e una distribuita. Con l’approccio centralizzato, la soluzione consisterebbe nel piazzare in un unico punto della terra una macchina che realizzi la risoluzione di tutti i nomi Questa soluzione, sebbene teoricamente realizzabile, ha così tanti svantaggi da risultare impraticabile: Single Point of Failure (il suo fallimento comporterebbe un malfunzionamento globale) Volume di traffico Database distante (chi è più lontano geograficamente da un dispositivo subirà inevitabilmente delle latenze) Manutenzione (si dovrebbe erigere un’organizzazione responsabile della comunicazione globale) Si preferisce quindi optare per un DNS distribuito. Con questa filosofia la distribuzione non riguarda solo la frammentazione dei server nel mondo, ma anche dei dati che essi trattano, col presupposto che essi contengono diversi set di informazioni: ogni server mantiene un sottoinsieme delle informazioni necessarie per risolvere gli indirizzi di tutta la rete. Si distribuiscono le informazioni tra varie entità server, ognuna ha la responsabilità̀ di raccogliere, gestire, aggiornare e divulgare le informazioni che la riguardano. In particolare, l’approccio adotta un’organizzazione gerarchica: gli elementi più alti nella gerarchia contengono molte informazioni non dettagliate gli elementi più bassi nella gerarchia contengono poche informazioni dettagliate Attraverso un colloquio concertato tra le entità (di cui gli utenti non hanno percezione) si riesce a fornire il servizio di risoluzione. GERARCHIA SERVER DNS Ipotizziamo che un cliente chiede l’ip del dominio www.foo.it. Per fare ciò, il client dapprima contatta uno dei root server, che gli restituisce uno o più indirizzi IP relativi al server TLD per il dominio it (detto “dominio di primo livello” o anche “top-level”, in quanto è in cima alla gerarchia). Quindi contatta uno di questi server TLD, che gli restituisce uno o più indirizzi IP del server autoritativo per foo.it. Infine, contatta uno dei server autoritativi per amazon.com, che gli restituisce l’indirizzo IP dell’hostname www.foo.it. Root server. I root server forniscono gli indirizzi IP dei server TLD. Ad esempio, sanno solo quale server TLD serve il dominio.it. Sono i root di più alto livello che mantengono le informazioni relative all’indirizzo ip di tutti i server relativi al livello TLD. Esistono storicamente 13 root server indicati con lettere da A ad M, i cui indirizzi ip sono standard (non c’è problema nel ricercarli), ma per rafforzarne la robustezza contro fallimenti, essi vengono replicati aumentando considerevolmente. In realtà quindi si tratta di 376 diversi server fisici. Ad essi si riferiscono i Local Name Server che non possono soddisfare immediatamente una richiesta di risoluzione, che si comportano come client DNS ed inviano una richiesta di risoluzione al Root Name Server. TOP-LEVEL DOMAIN (TLD) SERVER. Situati a un livello inferiore, si dividono in domini generici e domini geografici. Ognuno di questi domini avrà un server dns replicato noto ad ogni root nameserver. Costituiscono un insieme di server che non conoscono le informazioni di dettaglio della richiesta, ma qual è il server che le possiedono. Questi server si occupano dei domini di primo livello quali com, org, net, edu e gov, e di tutti i domini di primo livello relativi ai vari paesi, come uk, fr, ca e jp. I server TLD forniscono gli indirizzi IP dei server autoritativi. DNS server autoritativi. I server specifici per ogni dominio vengono detti server autoritative perché forniscono informazioni ufficiali per le corrispondenze dei nomi al suo interno. Ade esempio un server dei nomi assoluto per il dominio unina.it deve essere capace di risolvere tutti i nomi del tipo xyz.unina.it. Ad esso si riferiscono i Name Server TLD quando devono risolvere un indirizzo del dominio. Può essere mantenuto dall’organizzazione che ha titolo all’uso del dominio o da un provider che gestisce il servizio di risoluzione dei nomi per conto del proprietario del dominio. Ogni organizzazione dotata di host pubblicamente accessibili tramite Internet (quali web server e mail server) deve fornire record DNS pubblicamente accessibili che associno i nomi di tali host a indirizzi IP. Il DNS server autoritativo dell’organizzazione ospita questi record. Un’organizzazione può scegliere di implementare il proprio server autoritativo o di pagare un fornitore di servizi per ospitare questi record su un suo server. La maggior parte delle università e delle grandi società implementa e gestisce dei propri server autoritativi primario e secondario (di backup). Nella lettura di un dominio, andando da destra verso sinistra avremo un’indicazione di livelli sempre più alti. La parte a sx (www) rappresenta il nome che diamo al singolo host. Tutto il resto sta ad indicare dove si trova il dominio di questo host. Ex www.dieti.unina.it “esiste una macchina a cui è stato assegnato il nome www, che si trova nel sottodominio dieti del dominio unina.it.” La risoluzione del dominio avviene con un approccio top down. Local Name Server Un’ulteriore tipologia di server dns sono i server locali (local name server), che non fanno parte della gerarchia, ma rappresentano un ausilio per gli utenti nel risolvere i nomi simbolici di indirizzi IP. Un Local Name Server opera da proxy ed invia la query alla gerarchia di server DNS restituendo ai client le risposte finali. Ogni organizzazione normalmente installa nella propria rete uno o più name server locali, che sono contattati dagli utenti a fronte di una richiesta dns di risoluzione. Ottenere la risoluzione di un nome simbolico (il suo indirizzo ip) può coinvolgere un certo numero di richieste: con un local name server la cui gestione non sarà compito dell’utente (che farà una sola richiesta) ma del dns che si occuperà di fare tutte le richieste per fornire l’indirizzo richiesto. Ciascun ISP aziendale e residenziale, ha un DNS server locale (detto anche default name server). Quando un host si connette a un ISP, quest’ultimo gli fornisce un indirizzo IP tratto da uno o più dei suoi DNS server locali. L’indirizzo cambia a seconda della connessione utilizzata, in quanto i name servers sono forniti dagli internet providers. Nulla vieta di inserire dei name server manualmente quando il nameserver locale ha dei guasti. Un tentativo può essere quello di cambiare name server locale. ESEMPIO DI RISOLUZIONE DI UN DOMINIO Query iterativa: Supponiamo che l’host cse.nyu.edu voglia l’indirizzo IP di gaia.cs.umass.edu. L’host cse.nyu.edu dapprima invia un messaggio di richiesta DNS al proprio server locale. Il messaggio contiene il nome da tradurre, supponiamo gaia.cs.umass.edu. Il server locale inoltra il messaggio di richiesta a un root server. Quest’ultimo prende nota del suffisso edu e restituisce al server locale un elenco di indirizzi IP per i TLD server responsabili di edu. Il server locale rinvia quindi il messaggio di richiesta a uno di questi ultimi. Il TLD server 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. Si noti che in questo esempio, per ottenere la mappatura di un hostname, sono stati inviati ben otto messaggi DNS: quattro messaggi di richiesta e quattro messaggi di risposta, riducibili tramite il caching (è come se componesse le informazioni sull’indirizzo attraverso varie interrogazioni) Query ricorsiva Può capitare che il TLD server conosca solo un DNS server intermedio, il quale a sua volta conosce il server autoritativo relativo all’hostname. Per esempio, supponiamo ancora che Università del Massachusetts abbia un proprio DNS server, chiamato dns.umass.edu. Ipotizziamo, inoltre, che ciascun dipartimento dell’università abbia un proprio server, competente per tutti gli host presenti in dipartimento. In questo caso, quando il DNS server intermedio, dns.umass.edu, riceve una richiesta da dns.nyu.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.nyu.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. In questo caso, vengono inviati ben dieci messaggi DNS. (è come se il messaggio fosse inviato direttamente all’indirizzo). Non è la tecnica di default per effettuare le risouzioni perché impone un maggiore carico sui server più alti nella gerarchia. che dovranno mantenere delle informazioni di stato di provenienza della richiesta oltre che ad inoltrare le richieste. Nella richiesta, il richiedente può chiedere la modalità ricorsiva ma il server è libero di rifiutarla. Questa modalità ricorsiva è prevista per consentire al local name server di gestire le operazioni di risoluzione dei domini, tramite richieste ricorsive. Il TLD potrebbe anche non contattare necessariamente l’Authoritative Name Server finale, ma un Authoritative Name Server intermediario che fornirà il nome del server di competenza, ma in questi casi il numero di messaggi DNS aumenta IL CACHING DEI NOMI Il DNS caching è una caratteristica di fondamentale importanza che sfrutta in modo estensivo il caching per migliorare le prestazioni di ritardo e per ridurre il numero di messaggi DNS che “rim- balzano” su Internet: in una concatenazione di richieste, il DNS server che riceve una risposta DNS (contenente, per esempio, la traduzione da hostname a indirizzo IP), può mettere in cache le infor- mazioni contenute. I server dns che hanno fatto risoluzione di un nome possono mantenere la corrispondenza nella cache per esigenze di efficienza; dovendo interrogare tutti i server della rete, esso manterrà specialmente gli indirizzi del dns server dei domini di primo livello, con una riduzione del numero di richieste eventualmente effettuate. Per evitare che informazioni non aggiornate restino nella rete, dopo un certo tempo (circa un giorno), le associazioni vengono eliminate dalla cache, stimando

Reti di calcolatori PDF | Introduzione e Concetti Fondamentali

Document Details

Tags

Related

Summary

Full Transcript