Anteprima
Vedrai una selezione di 7 pagine su 27
Riassunti esame Reti di Calcolatori, prof Calefato, libro consigliato Reti di calcolatori e internet, Pearson Pag. 1 Riassunti esame Reti di Calcolatori, prof Calefato, libro consigliato Reti di calcolatori e internet, Pearson Pag. 2
Anteprima di 7 pagg. su 27.
Scarica il documento per vederlo tutto.
Riassunti esame Reti di Calcolatori, prof Calefato, libro consigliato Reti di calcolatori e internet, Pearson Pag. 6
Anteprima di 7 pagg. su 27.
Scarica il documento per vederlo tutto.
Riassunti esame Reti di Calcolatori, prof Calefato, libro consigliato Reti di calcolatori e internet, Pearson Pag. 11
Anteprima di 7 pagg. su 27.
Scarica il documento per vederlo tutto.
Riassunti esame Reti di Calcolatori, prof Calefato, libro consigliato Reti di calcolatori e internet, Pearson Pag. 16
Anteprima di 7 pagg. su 27.
Scarica il documento per vederlo tutto.
Riassunti esame Reti di Calcolatori, prof Calefato, libro consigliato Reti di calcolatori e internet, Pearson Pag. 21
Anteprima di 7 pagg. su 27.
Scarica il documento per vederlo tutto.
Riassunti esame Reti di Calcolatori, prof Calefato, libro consigliato Reti di calcolatori e internet, Pearson Pag. 26
1 su 27
D/illustrazione/soddisfatti o rimborsati
Disdici quando
vuoi
Acquista con carta
o PayPal
Scarica i documenti
tutte le volte che vuoi
Estratto del documento

DNS

In internet viene utilizzato un indirizzo chiamato indirizzo IP per identificare univocamente un nodo all'interno della rete. Il protocollo IP assegna ad un host un indirizzo di 32 bit; questo tipo di indirizzo è facile da gestire per i calcolatori ma non per gli umani che quindi hanno la necessità di identificare un host tramite un nome al posto di numeri. Questi nomi però danno poche informazioni sulla posizione dell'host in internet e hanno una lunghezza variabile. Allora si è pensato di associare il nome dell'host ad un indirizzo IP implementando delle tecniche di traduzione da nome a indirizzo.

La soluzione più immediata e più semplice è quella di associare ad ogni host un nome unico e creare un unico server con tutti i nomi degli host e i rispettivi indirizzi IP. Questa soluzione però, per ovvie ragioni, non è fattibile in quanto tutte le richieste fatte in internet chiederebbero la risoluzione a questo server unico, creando un collo di bottiglia e un singolo punto di fallimento.

unico server che dovrebbe rispondere e migliori di richieste e inoltre non renderebbe la soluzione a prova di malfunzionamento in quanto se dovesse fallire il server dei DNS tutta la rete non potrebbe tradurre i domini. Inoltre se i dati di traduzione degli hostname risiedessero in un solo punto, esso può trovarsi vicino ad un host ma lontanissimo ad un altro rendendo la traduzione molto lenta per alcuni e molto veloce per altri.

La soluzione trovata è il protocollo DNS che fa utilizzo di una base di dati gerarchica e distribuita. Questo implica che il DNS utilizza un grande numero di server organizzati in maniera gerarchica e distribuiti nel mondo. Ovviamente nessun server DNS conosce le risoluzioni di tutti i domini che appunto sono distribuite tra vari server DNS.

Il protocollo DNS prevede la presenza anche di più hostname per singolo host quindi permette degli alias. Questo permette ad un hostname molto lungo e difficile di essere ritrovato anche con degli hostname non più

semplici detti anche non canonici.

La gerarchia generale dei DNS è formata da tre blocchi principali: I ROOT SERVER, i TOP-LEVEL DOMAIN SERVER o TLD e i authoritative server.

Tutti questi tipi di server DNS fanno uso di caching per ridurre il numero di richieste DNS. Questa cache consiste in una lista locale di nomi e indirizzi risolti recentemente e dato che questi indirizzi non sono permanenti ogni tot di tempo la cache viene svuotata. Le risposte ricevute dalla cache sono dette non autoritative.

Quando viene fatta richiesta per la risoluzione di un dominio, il client DNS contatta un DNS server root che gli fornisce una lista di indirizzi di server TLD relativi al TLD dell'indirizzo dell'host (es com, if, fr, gov ecc detto dominio di primo livello o top-level-domain). Successivamente il client contatta uno di questi server TLD che gli restituisce uno o più indirizzi IP del server autoritativo per quel nome. Infine il client contatta uno dei server autoritativi che

gli indirizzi IP dei nomi di dominio passano attraverso questa gerarchia di server DNS.

hostname vengono reindirizzate a questo server DNS che fa sia da proxy e inoltra anche la richiesta ai DNSROOT SERVER.

Un DNS server, quale che esso sia, può fare 2 tipi di richieste o quei: richieste ricorsive o iterative;

Nelle richieste ricorsive il server richiede direttamente la risposta quindi richiede al DNS server direttamente l'indirizzo IP dell'hostname ed esso può rispondere a sua volta facendo una richiesta ricorsiva oppure dando direttamente la risposta se magari presente in cache.

Nelle richieste iterative invece il server richiede ad un altro server DNS la risposta oppure una lista di riferimenti ad altri server da interrogare.

Ogni applicativo fa uso a sua volta di un applicativo client DNS chiamato name Resolver che fa le richieste di risoluzione DNS e queste richieste possono essere solo ricorsive.

Generalmente però i ROOT SERVER e i TLD SERVER non accettano richieste ricorsive mentre i server autoritativi è possibile fare richieste.

ricorsive quindi si utilizza un architettura in cui tutte le richieste con i root server e i mld server vengono fatte in maniera iterativa mente quelle ai server autoritativi vengono fatte in maniera ricorsiva.

Descrittori di risorsa

Ogni name server memorizza dei dati nella cache e questi dati sono i descrittori di risorsa (Resource record) che sono formati da 4 campi: Name, Value, Type, TTL;

Il TTL è il time to live cioè il tempo che il descrittore deve rimanere in cache prima di essere cancellato mentre name e value dipendono dal tipo di Type;

Type: A

Quando Type è A allora name sarà l'hostname originario dell'host mentre value sarà l'indirizzo IP finale dell'host.

Type = NS

Quando Type è NS allora name sarà un dominio e value invece sarà l'hostname del DNS server autoritativo che sa come ottenere gli indirizzi IP degli host in quel dominio.

Type = CNAME

Quando type e CNAME allora value sarà il nome

canonico dell'host con nome presente in nameType = MX

Quando type è MX allora value sarà il nome canonico di un mail server che ha come nome noncanonico il valore presente in name. Questo permette di avere server mail con nomi molto più facilmente riformabili e corti.

Struttura messaggio DNS

Un messaggio DNS è formato inizialmente da un intestazione di 12 byte. I primi 16 bit sono dedicati per un numero identificativo che può viene anche utilizzato la risposta per far corrispondere domanda e risposta. Subito dopo abbiamo la sezione flag dove il primo di questi indica se il messaggio è una domanda o una risposta. Viene anche usato un altro bit chiamato richiesta di ricorsione in cui si specifica se il client vuole che il server deve effettuare ricorsione e nella risposta il server setta un flag in cui dichiara se ha la possibilità di effettuare la ricorsione o no. Dopo i flag si una zona in cui si salvano i numeri di occorrenze delle 4

Sezioni di tipo dati che seguono i 12 byte dell'intestazione. La prima sezione è la sezione delle domande che contiene informazioni sulle richieste che stanno per essere fatte. La seconda sezione delle risposte contiene tutti i resource record solo in caso di risposta. La terza sezione è la sezione autoritativa in cui vengono salvati i resource record dei server autoritativi. L'ultima è quella aggiuntiva che può essere utilizzata per informazioni utili.

LIVELLO DI TRASPORTO

Come abbiamo visto nell'architettura a livelli di internet tramite una pila di protocolli ISO/OSI, dopo il livello di applicazione abbiamo quello di trasporto e quello di rete. Essenzialmente il livello di trasporto permette il trasferimento delle informazioni, che sono chiamati segmenti, da un processo ad un altro quindi end to end mentre il compito dei protocolli di rete è quello di stabilire la connessione logica tra 2 calcolatori. È risaputo che

destinatario e non fornisce un meccanismo di controllo di flusso o di controllo di congestione. D'altra parte, il protocollo TCP è un protocollo affidabile che garantisce la consegna dei dati in ordine e senza errori. Utilizza un meccanismo di controllo di flusso per evitare che il mittente sovraccarichi il destinatario con troppi dati e un meccanismo di controllo di congestione per evitare che la rete diventi congestionata. Entrambi i protocolli, UDP e TCP, sono utilizzati per la comunicazione tra processi, ma hanno caratteristiche diverse e vengono utilizzati in contesti diversi. UDP è spesso utilizzato per applicazioni in cui la velocità e la latenza sono più importanti della correttezza dei dati, come ad esempio lo streaming video o i giochi online. TCP, invece, è utilizzato per applicazioni in cui la correttezza dei dati è fondamentale, come ad esempio il trasferimento di file o la navigazione web. In conclusione, il protocollo IP è considerato non affidabile perché non garantisce la consegna dei dati, mentre i protocolli di trasporto come TCP e UDP forniscono meccanismi per garantire l'affidabilità dei dati in diversi contesti di comunicazione.destinatario e inoltre offre un servizio senza connessione. Il protocollo TCP invece offre alle applicazioni diversi servizi aggiuntivi quale un trasferimento dati affidabile in quanto garantisce che tutti i segmenti arrivino intatti e in ordine, è orientato alla connessione ed offre anche dei meccanismi di controllo della congestione della rete per evitare che le connessioni TCP intasino la rete. Tutti e due i protocolli offrono il servizio di multiplexing e demultiplexing che consiste appunto la conversione del servizio di trasporto host to host del livello di rete in servizio di comunicazione tra processi di applicazioni in esecuzione. Multiplexing e Demultiplexing Abbiamo detto che le tecniche di multiplexing e demultiplexing sono quelle tecniche che permettono di tradurre il servizio di comunicazione host to host tipico del protocollo IP in un servizio di comunicazione tra processi di applicazioni. I processi che necessitano di comunicare fanno uso di una speciale API chiamata16 bit menzionati in precedenza. Inoltre, l'intestazione può contenere altre informazioni come il numero di sequenza, il checksum e i flag di controllo. Per implementare il multiplexing e il demultiplexing, il socket API utilizza un meccanismo chiamato "porta di ascolto" (listening port). Ogni processo che desidera ricevere dati tramite una socket deve specificare una porta di ascolto. Quando un datagramma arriva al livello di trasporto, il socket API controlla l'identificatore di porta di destinazione e lo confronta con le porte di ascolto dei processi in esecuzione. Se trova una corrispondenza, il datagramma viene inviato al processo corrispondente. In caso contrario, il datagramma viene scartato. In sintesi, il socket API svolge un ruolo fondamentale nel trasferimento dei dati tra il livello di trasporto e i processi in esecuzione su un nodo. Utilizza il multiplexing per indirizzare i dati verso la socket corretta e il demultiplexing per incapsulare i segmenti provenienti dalle socket e inoltrarli al protocollo di rete successivo. L'identificatore di porta svolge un ruolo chiave nell'indirizzamento dei dati verso i processi corretti.16bit e i primi 1023 sono riservati e utilizzati dai protocolli di applicazione, diventati ormai inquinati.
Dettagli
Publisher
A.A. 2020-2021
27 pagine
2 download
SSD Ingegneria industriale e dell'informazione ING-INF/03 Telecomunicazioni

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher vitAndreA di informazioni apprese con la frequenza delle lezioni di Reti di calcolatori e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Università degli Studi di Bari o del prof Calefato Fabio.