2003-2004reti di calcolatori1 il modello client/server internet: gli standard de facto application...

2003-2004 Reti di Calcolatori 1

Il modello Client/ServerInternet: gli standard de facto

Application

Presentation

Session

Transport

Network

Link

Physical

Application

Presentation

Session

Transport

Network

Link

Physical

Node Node

Host AHost A Host BHost B

IP

UDP e TCP

HTTP – SMTP – FTP …

Ethernet, PPP, ATM …


Il modello Client/ServerInternetInterconnessione tra reti

Le implementazioni per internet devonotenere conto della presenza ditante reti interconnesse

• Gateway: modulo di rete che si occupa di connettere due sistemi Indipendenti di rete: il gateway Risolve i problemi di routing (livello 3) il bridge invece risolvei problemi di interfacciamento tra lediverse implementazioni dei livelli fisicie di data link

• Routing: per esigenze reali non costruiscoReti ad hoc per ogni applicazione. Riutilizzo le reti già stese ed operative per un sistema di interconnessione universale

• Apertura: il sistema interconnesso è un sistema aperto in grado di accettare qualsiasi tipo di applicazione al di sopra degli standard sottostanti:

• Il requisito di base è la capacità di adattarsi alle nuove tecnologie relative ai diversi livelli del sistema

• Pagamento: se i servizi utilizzano le reti interconnesse… chi paga?

rete 1 rete 2

rete 3

gateway

gateway


Il modello Client/ServerInternetLo stack TCP-IP

Processodi utente

Processodi utente

TCP UDP

ICMP IP ARP RARP

Interfacciafisica di rete Livello 1

Livello 2

Livello 3

Livello 4livello di TRASPORTO:

• TCP Transmission Control Protocol: flusso di byte bidirezionale a canale virtuale best effort, dati non duplicati, affidabili, con controllo di flusso

• UDP User Datagram Protocol: Scambio di datagrammi

livello di RETE:

• IP Internet Protocol: Scambio di datagrammi senza garanzia di consegna• ICMP Internet Control Message Protocol: Scambio messaggi di controllo • ARP Address Resolution Protocol: Ricerca dell’indirizzo fisico di un nodo• RARP Reverse Address Resolution Protocol: Ricerca un indirizzo IP di un nodo


Il modello Client/ServerInternetApplicazioni e Comunicazioni in TCP/IP

Applicazione

Trasporto

Internet

Interfacciadi rete

Rete fisica

Trasporto

Internet

Interfacciadi rete

Host BHost A

ApplicazioneProtocollo

di Applicazione

Protocollo TCP o UDP

Protocollo IP

Protocollo di Datalink


Il modello Client/ServerInternetInterazioni via Gateway

Internet

Interfacciadi rete

Applicazione

Trasporto

Internet

Interfacciadi rete

Applicazione

Trasporto

Internet

Interfacciadi rete

Rete fisica 1 Rete fisica 2

Identico messaggio

Identico pacchetto

Identico datagramma

Identico frame Identico frame

Identico datagramma

Host BHost A


Il modello Client/ServerInternetIl Servizio IP

IP si occupa di gestire il scambio dei pacchetti sulla rete:

• Problema dei Nomi: come identifico un nodo sulla rete?

• IP definisce uno standard gerarchico basato su una sequenza di 4 byte: ad esempio 137.204.56.1

• Protezione delle informazioni: i pacchetti dovrebbero essere manipolati solo dai destinatari

• Routing: i pacchetti devono poter essere consegnati su reti diverse attreverso i gateway


Il modello Client/ServerInternetIP Naming ed indirizzamento gerarchico

• Ogni connessione di un host a una rete ha un indirizzo internet unico formato da due elementi e detto IP-ADDRESS=NETID, HOSTID

• NETID è l’identificatore di rete• HOSTID è l’dentificatore di host• La distinzione facilita il routing

• Una rete è un ambiente considerato omogeneo: se il mio indirizzo è 137.204.56.1 ed il numero di rete è per esempio 137, sono sicuro che all’interno della rete 137 ci sarà o il nodo identificato dall’id 204.56.1 oppure il gateway per la rete 137.204

• Il routing quindi è automaticamente definito dalla struttura del nome

• Esiste inoltre uno standard per definire la struttura di una rete:• Reti di Classe A:

• Le WAN tipicamente

• Reti di Classe B:• LAN di grandi dimensioni

• Reti di Classe C:• LAN di piccole dimensioni

0 NETID HOSTID

1 7 8 31

0 NETID HOSTID

1 31

1 0 NETID HOSTID

1 31

1 1 0 NETID HOSTID

classe B

classe C


Il modello Client/ServerInternetIP Naming: le classi degli indirizzi

classe A

classe B

classe C

classe D

classe E

0

1

1 1

1 1 1

1 1 1 1

0

0

0

0

0 1 2 3 4 8 16 24 31

netid hostid

hostid

hostid

netid

netid

indirizzo multicast

indirizzi riservati ad usi futuri

Esempio: 137.204.56.1: 137= 10001001 è una rete di classe B ! una LAN di grandi dimensioni

NETID= 137.204HOSTID= 56.1


Il modello Client/ServerInternetIP Naming: Broadcast e Multicast

Se un byte è a 255 (11111111) indico tutti i nodi a quel livello gerarchico:

• 255.255.255.255: indirizzo di tutti i nodi della rete locale (si parla di limited broadcast perché i gateway scarcano il messaggio che quindi non si propaga tra le reti)

• 137.204.255.255: indirizzo tutti i nodi della rete 137.204 (si parla di directed broadcast perché scelgo la rete locale che voglio indirizzare)

Tutti gli indirizzi dal 224.x.x.x al 239.x.x.x invece rappresentano un gruppo di specifici indirizzi che si sono precedentemente accreditati (multicast)


Il modello Client/ServerInternetIP Naming: Assegnamento indirizzi

• Il numero IP identifica in modo univoco un host nella sua rete

• Attraverso i protocolli ARP e RARP è possibile passare dal MAC-ADDRESS di una scheda di rete ethrnet al suo corrispettivo indirizzo

• Un host può avere più indirizzi IP associati ad una o più schede di rete• Se un host ha più di un indirizzo IP allora può anche avere compiti di

routing tra una rete ed un’altra

• Ci sono 2 modi per assegnare un indirizzo IP ad un host• Assegnamento statico: configuro ogni macchina con un suo specifico IP

reti molto stabili o di piccole dimensioni• Assegnamento dinamico: ogni volta che un host viene agganciato alla

rete gli viene assegnato dinamicamente un IP DHCP Dynamic Host Configuration Protocol: utile in reti di computer che a variabilità molto elevata


Il modello Client/ServerInternetIP: Caratteristiche e specifiche

IPv4: gestisce la comunicazione attraverso datagrammi

• Servizio:• Connectionless: ciascun pacchetto è trattato indipendentemente

dagli altri. Diversi pacchetti possono seguire percorsi diversi ed essere consegnati fuori ordine

• Unreliable: la consegna non è garantita, cioè non effettua un controllo sull'avvenuta ricezione di un pacchetto

• Best-effort: l'inaffidabilità del trasferimento è dovuta a cause esterne e non al software di rete nessun messaggio di errore al richiedente

• Protocollo:• Elaborazione: del messaggio del livello superiore nel formato per la

trasmissione• Incapsulamento / frammentazione

• Instradamento (routing) cioè:• Traduzione da indirizzo logico a indirizzo fisico• Scelta del percorso


Il modello Client/ServerInternetIP: Struttura del Datagramma

I sottocampi del campo header contengono:• versione del protocollo• lunghezza header e totale (totale < 64K)• identificazione del datagramma (usato per ricomporre i frammenti)• precedenza (0-7)• tipo di trasporto desiderato (bit di qualità): Type of Service (ToS vedi

qualità del servizio)• throughput T,di affidabilità R, di ritardo D, costo C• Internet non può garantire il soddisfacimento del tipo di trasporto

richiesto che dipende dal cammino che deve percorrere il datagramma• frammentazione e flags• time to live, tempo di permanenza del datagramma• indirizzo IP sorgente e destinazione• tipo di protocollo livello superiore (TCP 6, UDP 17, ICMP 1, ...)• checksum per il controllo • opzioni: monitoraggio e controllo rete

DATAGRAM HEADER DATAGRAM DATA

Intestazione Dati


Il modello Client/ServerInternetARP Address Resolution Protocol

ARP protocollo semplice ed efficiente (costo broadcast)

• invia un pacchetto broadcast in cui chiede l'indirizzo fisico corrispondente ad indirizzo IP (Quale Fa per questo Ia?)

• tutti gli hosts ricevono tale pacchetto: solo quello che riconosce il suo indirizzo IP risponde con il proprio indirizzo fisico

richiesta ARP broadcast

risposta ARP


Il modello Client/ServerInternet ARP Address Resolution Protocol

• IP non ha bisogno di scatenare una sequenza ARP ad ogni invio di messaggio. Esiste una memoria cache che contienne le coppie IP- MAC Address ottenute in precedenza

• Lo stato viene mantenuto per un certo tempo e poi scade • Se si riceve un errore dal livello di datalink all’invio di un messaggio il

dato viene invalidato

• Attraverso i broadcast ARP tutti i nodi della rete cercano di mantenere aggiornata la loro cache non è in generale il nodo a cui appartiene l’indirizzo IP a rispondere, ma tutti i nodi che conoscono il MAC Address associato a quello specifico IP

• Il pacchetto ARP:messaggio ARP

frame data area

frame header


Il modello Client/ServerInternetRARP Reverse Address Resolution Protocol

Normalmente un sistema si attiva caricando le sue configurazioni (e quindi anche il suo indirizzo IP) da una memoria di massa.

Cosa succede se una macchina è diskless?

• L’host conosce il suo Mac Address ha bisogno di chiedere ad un server dedicato quale è il suo indirizzo IP

• Il cliente fa un broadcast per richiedere il suo IP

• Il server risponde con l’ip corrispondente

• Ci possono essere più server sulla rete possono rispondere tutti senza problemi di coordinamento (operazione idempotente)


Il modello Client/ServerInternetRouting e separazione fra reti

ARP e RARP funzionano solamente all’interno della stessa LAN: non è possibile fare indirizzamento diretto tra due reti diverse.

• Reti Logicamente Separate: se definisco due o più reti logiche al di sopra della rete fisica (esempio: nella stessa LAN definisco due reti ip, come 137.204 e 137.205)

• Reti Fisicamente Separate: sono completamente distinte e sono unite da un gateway, un host con due o più schede di rete con il compito di reindirizzare i pacchetti da una rete all’altra

GATEWAY

HOST

dida02 cineca

deis33


Il modello Client/ServerInternetRouting e separazione fra reti

La separazione logica può essere ulteriorimente diversificata attraverso il concetto di subnet:

• All’interno della rete 137.204 è possibile definire due sottoreti: 137.204.56 e 137.204.57

• La subnet è rispettata permettendo una comunicazione diretta solo all’interno, obbligando il passaggio per un gateway per andare nell’altra rete

• Si realizza questa astrazione attraverso lo strumento della Maschera• Viene impostata una maschera di 32 bit es: 255.255.255.0

maschera di classe C implica che sono visibili al nodo solo gli host che hanno la stessa rete di classe C

• La maschera è una impostazione di connessione (viene decisa sul lato client, può essere quindi rimossa per accedere direttamente fuori dalla subnet


Il modello Client/ServerInternetRouting in topologie complesse

Per garantire prestazioni e tolleranza ai guasti ratamente le reti hanno un unico cammino per procedere da un host ad un altro: Nello schema seguente sono identificabili diversi percorsi per connettere Host A a Host B

GATEWAY

HOST A

HOST B


Il modello Client/ServerInternetRouting: i percorsi multipli

Si possono identificare vari percorsi:• Rosso: percorso più breve (3 nodi prima di destinazione hop)• Blu: percorso alternativo che salta una rete (5 hop)• Verde: un percorso completamente diverso (5 hop)

HOST A

HOST B


Il modello Client/ServerInternetRouting: gestione dei percorsi

Ricordiamo che in generale, dal protocollo esistono solo due casi:

• I due host sono nella stessa rete fisica (direct routing):• Grazie a ARP posso avere indirizzo fisico • Invio diretto dei datagrammi

• I due host sono in due reti fisiche diverse (indirect routing):• Invio il datagramma al gateway più adatto ( secondo quali politiche?)• Se il gateway è fisicamente connesso alla rete destinazione passa in

uno stato di direct routing• Se non conosce la rete fisica invia il pacchetto ad un altro gateway

Il datagramma passa da un gateway ad un altro fino ad un gateway che può inoltrarlo direttamente

Alterata solo la parte di frame fisico (checksum e fram.)

Utilizzo di tabella di routing che lavora (per lo più) sulle informazioni di rete


Il modello Client/ServerInternetAlgoritmi di routing

• Algoritmi generalmente globali basati su tabelle che sono disponibili ai diversi router partecipanti

• A parte alcuni casi iniziali è diffuso l’uso di protocolli isolati tipo patata bollente

1. Algoritmi Statici• basati su informazioni statiche riguardanti il cammino più breve (per piccole reti

ed interconnessioni)2. Algoritmi Dinamici

• basati su informazioni dinamiche di traffico della rete, lunghezza del messaggio e tipo di servizio richiesto

• I Router (gli host che si occupano di routing) si coordinano attraverso protocolli:• time out delle entry dei router in modo asincrono• propagazione asincrona delle informazioni di routing

• Sia che l’impostazione del routing sia statica o dinamica è necessario tenere conto che la rete è comunque un sistema dinamico

• I percorsi possono mutare per guasti o modifica della struttura della rete• È necessario gestire attraverso diversi protocolli specifici la evoluzione delle

topologie


Il modello Client/ServerInternetAlgoritmi di routing: Distance Vector

• Ogni gateway mantiene una tabella per tutte le reti che conosce memorizzando i diversi percorsi in funzione della distanza misurata in hop

• Associo quindi staticamente quale è il miglior percorso per una rete• I percorsi non sono memorizzati per intero viene memorizzato solo l’hop

successivo • La propagazione delle informazioni (nelle tabelle di routing) è la chiave della

gestione dell’algoritmo

G1 G2 G3Rete Rete Rete Rete

R0 R1 R2 RnGn

R0 0 R1 0 R2 0 Rn-1 0

R1 0 R2 0 R3 0 ... Rn 0

R0 0 R1 0 R2 0 Rn 0

R1 0 R2 0 R3 0 Rn-1 0

R2 1 G2 R0 1 G1 R1 1 G2 .. ... Rn-2 1 Gn-1

R3 1 G3 R4 1 G4

1° passo propagazione

2° passo propagazione


Il modello Client/ServerInternetAlgoritmi di routing: Distance Vector

• Cosa succede se cambia un percorso:

G1 G2 G3Rete Rete Rete Rete

R0 R1 R2 RnGn

Rete

RQ

R0 0 R1 0 R2 0 Rn 0

R1 0 R2 0 R3 0 Rn-1 0

RQ 0 R0 1 G1 RQ 0 Rn-2 1 Gn-1

R2 1 G2 R3 1 G3 R1 1 G2 Rn-3 2 Gn-1

R3 1 G3 RQ 1 G3 R0 1 G1 Rn-4 3 Gn-1

... ... ... ...Propagazione locale delle tabelle di routing ad ogni vicino in modo asincronoChi riceve una offerta aggiorna la propria tabella se la proposta è conveniente in base alla

metrica

Le entry hanno scadenza (e devono essere sostituite)Ogni gateway decide il routing in modo indipendente in base alla tabella locale


Il modello Client/ServerInternetDistance Vector: problemi di riconfigurazione

• Supponiamo che ci sia una variazione di configurazione come da esempio:

• Se un pacchetto deve andare da E a B:• Il pacchetto viene inviato a D• D non ha più rotta per B e quindi manda il pacchetto all’unico gateway che

conosce: E• Finché E non viene aggiornato ho una condizione di loop counting-to-

infinity incremento infatti il numero di hop del mio pacchetto ogni volta e posso potenzialmente andare avanti all’infinito (spesso si limita infinito a 16 !!)

• E e D continuano ad incrementare la loro distanza da B in base alla rotta che prende il pacchetto informazioni errate di routing

• In una condizione come questa A,B e C si danno delle informazioni non coerenti il problema è che non si tiene traccia di chi fornisce le informazioni

A

B

C D E

A

B

CD10

Rete


Il modello Client/ServerInternetDistance Vector: Varianti per ridurre i problemi

• Il problema è sostanzialmente legato alla lenta convergenza del sistema:• Le buone notizie viaggiano con i pacchetti (aggiornamenti sui costi di routing)• Le cattive notizie invece sono molto lente (informazioni di caduta di un nodo

viene raccolta in caso di timeout), solo dopo il timeout possono essere inoltrate, nel frattempo la situazione è inconsistente e vengono danneggiate le tabelle di routing

• Split Horizon: per evitare di inserire informazioni errate nella mia tabella di routing non accetto informazioni da nodi a cui ho precedentemente inoltrato aggiornamenti su quella specifica riga

• Hold down: dopo una notifica di un problema si ignorano le informazioni di cammino per un certo periodo, lasciando il tempo a tutti i nodi di accorgersi della eccezione

• I loop che si sono già creati vengono mantenuti durante il periodo di attesa

• Split Horizon con Poisoned Reverse e Triggered Broadcast: quando avviene una eccezione ogni nodo invia in broadcast le informazioni dei cammini in loro possesso:

• A inva a C un messaggio di non raggiungibilità se crede di raggiungere D via C• C non può rifarsi ad A (che non raggiungeva D) • L’algoritmo permette di ricostruire i cammini corretti in base alle informazioni

ottenute in broadcast• Ci sono ulteriori problemi relativamente alla possibilità di creare diverse catene

di boradcast che rendono difficile la rigenerazione delle tabelle


Il modello Client/ServerInternetAlgoritmi di routing: Link State

Link State: si basano sul principio della completa conoscenza della topologia di rete e della relativa ricerca del percorso minimo (Shortest Path First)

Il grafo di interconnessione per evitare cicli viene gestito con algoritmi che possono favorire decisioni locali (routing dinamico)

Dijkstra shortest-path-first

Possibilità di fare source routing e anche di spedire messaggi su cammini diversi (routing dinamico)

A REGIME, ogni gateway tiene sotto controllo le proprie connessioni e le verifica periodicamente

• invio periodico di messaggi nel vicinato per controllare la correttezza delle risorse locali

• identificazione del guasto e segnalazione di eventi di guasto (uso di più messaggi per evitare transitori e accelerare la propagazione)

Non appena si verifica un problema chi ha rilevato il problema invia il messaggio a tutti i componenti (broadcast o flooding)


Il modello Client/ServerInternetLink State: Caratteristiche degli Algoritmi

• Vantaggi:• si controlla solo il vicinato• informazioni di variazione propagate rapidamente (senza ambiguità

via broadcast)• possibilità di scelte differenziate dei cammini nella topologia• conoscenza dei cammini completi e source routing

• In sostanza le variazioni non sono dipendenti da possibili intermediari• I messaggi sono gli stessi qualunque sia la dimensione del sistema

• Problemi:• necessità di mantenere tutta la topologia• azioni costose (broadcast) in caso di variazione

• In generale, necessità di limitare i domini di conoscenza reciproca

In conclusione possiamo dire che algoritmi di natura globale come i link state sono molto efficienti ma non permettono una forte scalabilità


Il modello Client/ServerInternetRouting: i protocolli di coordinamento tra gateway

• Per implementare i diversi algoritmi sono necessari protocolli che permettano ai router di coordinarsi e scambiarsi informazioni

• Ci sono differenze legate alle possibilità di controllo sulla rete:• Un sistema si dice autonomo se è controllato in modo unificato da una unica

autorità all’interno di un sistema autonomo sono implementate in autonomia le politiche di routing considerate più appropriate internet è un aggregato di molti sistemi autonomi

• Esistono dei router detti core mantengono la totalità delle informazioni di routing per un sistema

• IGP: Interior Gate Protocol• protocollo per trovare il percorso all'interno di un sistema autonomo politica che

consente percorsi multipli e con possibilità di tollerare i guasti (algoritmi multipath IGRP CISCO)

• EGP: Exterior Gate Protocol• protocollo rilevente per i gateway di controllo per trovare il percorso fino ai core

dei diversi sistemi autonomi• struttura ad albero con i core come radice


Il modello Client/ServerInternetICMP: Internet Control Message Protocol

Permette di gestire e controllare la rete• ICMP consente di inviare messaggi di controllo o di errore al sorgente del

messaggio (solo a questo)• ICMP usato per il coordinamento tra livelli di IP

• Condizioni di errore al mittente (non correzione) per i relativi provvedimenti

• nodi intermedi non informati dei problemi • nodo sorgente può provvedere a correggere

• Rappresenta un mezzo per rendere note condizioni anomale a chi ha

mandato datagrammi (usando IP) La politica di uso è tutta a carico dell'utilizzatore

• METALIVELLO: Errori su messaggi ICMP non possono causare a loro volta messaggi ICMP

• I messaggi ICMP sono considerati a livello di datagrammi IP sono soggetti alle stesse regole di routing

• non hanno priorità• possono essere persi• possono causare ulteriore congestione



Formato:

• Messaggio ICMP inserito un datagramma IP: il messaggio ICMP contiene sempre l'header e 64 bit dell'area dati del datagramma che ha causato il problema

• I campi type e code consentono di fornire informazioni ulteriori -----------------------

TYPE

DATA

. . .

0 8 16 31

CODE CHECKSUM

in caso di errore l'header del datagramma sbagliato

0 Echo Reply

3 Destinazione irraggiungibile

4 Problemi di congestione (source quench)

5 Cambio percorso (redirect)

8 Echo Request

11 Superati i limiti di tempo del datagramma

12 Problemi sui parametri del datagramma

13 Richiesta di timestamp

14 Risposta di timestamp

15 Richiesta di Address mask

16 Risposta di Address mask



Eventi Segnalati

campo CODE ==> un intero dipendente dai valori di TYPE • Se il destinatario non si raggiunge campo type vale 3• Il campo Code contiene quindi il codice di errore

0 Rete irraggiungibile

1 Host irraggiungibile

2 Protocollo irraggiungibile

3 Porta irraggiungibile

4 Frammentazione necessaria

5 Errore nel percorso sorgente (source route fail)

6 Rete di destinazione sconosciuta



I servizi offerti dal protocollo sono relativi alla gestione dinamica della rete:

• echo request/reply (type 8/0): controllo percorso• un host può verificare la raggiungibilità di una destinazione• Comando ping

• address mask (type 17/18) richiesta di maschera• un gateway può richiedere la struttura di mack si una sottorete

• sincronizzazione degli orologi (type 13/14)• ricezione e invio del tempo fisico• si misurano i millisecondi• si considera tempo di invio, di ricezione, di risposta

• redirect (type 5) cambio percorso • un gateway deve cambiare la propria tabella di routing• funzione di controllo di gestione


Il modello Client/ServerInternetUDP: User Datagram Protocol

È il protocollo di livello trasporto per la gestione da parte dell’utente di comunicaizoni di tipo datagramma

• Indirizzo: mentre IP deve identificare un nodo, UDP deve identificare uno specifico processo all’interno di un nodo

• Definisco la porta UDP come numero di 2 byte in grado di identificare uno specifico processo da parte del sistema operativo

• Indirizzo UDP: indirizzo IP + porta UDP

• Si appoggia a IP per la consegna dei datagrammi

Application

User Datagram

Internet (IP)

Interfaccia di rete

(UDP)Area dati

header Area dati

Area dati FrameFrame

header

IP

UDP



UDP fornisce un servizio unreliable e connectionless

• I datagrammi possono essere persi, duplicati, pesantemente ritardati o consegnati fuori ordine

• il programma applicativo che usa UDP deve trattare i problemi

Formato di un datagramma UDP

UDP SOURCE PORT

UDP MESSAGE LENGTH

DATA

. . .

0 16 31

UDP CHECKSUM

UDP DESTINATION PORT



Quali sono i servizi che offre UDP:

• Multiplexing: possibilità di inviare diversi messaggi in parallelo da parte di diversi processi al di sopra di un unico servizio IP

• Demultiplexing: ricostruzione in ricezione dei messaggi in modo che vengano recapitati alla porta corretta

UDP

ICMP IP

Interfacciaverso la rete fisica

Processodi utente

Processodi utente

Porta Porta Porta



Assegnazione dei numeri di porta:

• Alcune porte sono riservate secondo lo standard del protocollo a specifici servizi:

0 Riservato

7 Echo

9 Discard

11 Users

13 Daytime

37 Time

69 tfpt (trivial file transfer protocol)

111 Sun RPC protocol

513 who (demone di rwho)

514 system log



Assegnazione dei numeri di porta:

• Quando un processo ha bisogno di inviare un datagramma:• UDP assegna al processo dinamicamente una porta• UDP genera il pacchetto e passa ad IP per l’invio

• Quando un processo riceve un datagramma:• Il processo deve richiedere una specifica porta per la ricezione • Porte da 1-1024 sono accessibili solo da processi di sistema (servizi

standard)• Quando un processo risponde ad un datagramma:

• UDP invia il messaggio verso la porta mittente che ha letto nel pacchetto di request

• Non esiste nessun concetto di connessione: l’unico stato è dato dalla definizione di una porta specifica per la ricezione


Il modello Client/ServerInternetTCP: Transfer Control Protocol

TCP fornisce un servizio reliable e connection oriented stream full-duplex:

• Se i pacchetti TCP si perdono vengono automaticamente reinviati• Garanzia della sequenza dei pacchetti

• Astrazione del canale virtuale o stream: i messaggi del mittente vengono inviati sotto forma di stream di byte in modo affidabile

• Gestione dei dati prioritari:• Banda per i dati normali• Fuori Banda per i dati urgenti

• Gestire una connessione significa avere uno stato relativo: TCP non impegna risorse nei nodi intermedi: è un canale virtuale end-to-end



Formato del segmento TCP (header 20 byte):

SEQUENCE NUMBER

RSRVD WINDOW

URGENT POINTER

OPTIONS (IF ANY) PADDING

DATA

. . .

0 4 10 16 24 31

SOURCE PORT DESTINATION PORT

HLEN

CHECKSUM

ACKNOWLEDGEMENT NUMBER

CODE BIT



CODE BITURG un dato urgente nel segmento ACK acknowledgement nel segmento PUSH invio immediato del segmento RST reset di una connessioneSYN si stabilisce la connessione FIN termine della connessione

• Si cerca di frammentare meno possibile i messaggi detti segmenti dal protocollo:

• segmenti troppo corti: grosso overhead di trasmissione• segmenti troppo lunghi: frammentazione a livello di IP e possibili

perdite ed overhead



Le porte seguono lo stesso razionale di UDP alcune delle porte riservate:

PORTA PROTOCOLLO DESCRIZIONE

20 FTP-DATA File Transfer Protocol (dati)

21 FTP File Transfer Protocol

23 TELNET Terminale remoto

25 SMTP Protocollo di posta elettronica

80 HTTP Protocollo WWW

119 NNTP Protocollo di invio news



Come viene implementata la Reliability:• richiederebbe una attesa sincrona di un messaggio di conferma

(acknowledgement o ACK) per ogni segmento spedito prima di inviarne uno successivo vedi ARQ

MITTENTE RETE RICEVENTE

Invio pacchetto 2

Invio pacchetto 1

Ricezione pacchetto 1

Invio ACK 1

Ricezione ACK 1

Ricezione pacchetto 2

Invio ACK 2

Il mittente deve attendere tra una trasmissione e l'altra

• Soluzione inefficiente: devo inviare una conferma per ogni pacchetto inviato

• PiggyBacking: inserisco uno stato di ack nel messaggio di risposta successivo

• Finestra scorrevole: TCP invia gli ack tutti insieme per una determinata finestra di messaggi

• TCP usa GO BACK-N: se un segmento non viene ricevuto (manca ack) viene richiesta la rispedizione del segmento complessivo e tutti i seguenti vengono scartati (ripetizione dell’intera comunicazione dalla eccezione in poi)



Protocollo per stabilire la CONNESSIONE TCP: Connessione tra due nodi: three-way handshake

• PRIMA FASE: A invia il segmento SYN a B e richiede la connessione (SYN nell'header del segmento e X valore scelto da A)

• SECONDA FASE: B riceve il segmento SYN e ne invia uno identico ad A insieme all'ACK (e Y valore scelto da B)

• TERZA FASE: A riceve il segmento SYN ed ACK e conferma la ricezione a B attraverso un ack a sua volta

POSTAZIONE A RETE

Invio ACK y+1

Invio segmento SYN

Ricezione segmento SYN

Invio segmento SYN seq=y,

Ricezione SYN + ACK

Ricezione segmento ACK

POSTAZIONE B

numero seq=x

ACK x+1

Il sistema di comunicazione a tre fasi compromesso ogni nodo invia un messaggio ed ha conferma

Semantica at-most once



Protocollo per stabilire la CONNESSIONE TCP: Protocollo di BIDDING (senza rifiuto)

NEGOZIAZIONE a tre fasi per stabilire proprietà; si verifica che:

• Entrambi i nodi disponibili alla connessione per una sessione di comunicazione• Accordo sulla sequenza iniziale di valori: ogni pari propone per il proprio verso:

• numeri di porta• numeri per i flussi (messaggi ed ack)• tempo di trasmissione e risposta (finestra, ...)

• La sequenza é confermata proprio durante la inizializzazione • Scelta casuale di un numero da cui iniziare la numerazione e comunicato all'altra per

ogni flusso

• In fase iniziale si negoziano anche altre opzioni:• accordo sul MSS (maximum segment size) • dimensione del blocco di dati massimo da inviare (default 536)

• Maggiore il valore, migliori le performance• fattore di scala della finestra • richiesta di tempo e risposta per il coordinamento degli orologi



Protocollo di chiusura della CONNESSIONE TCP:

NEGOZIAZIONE chiusura a fasi semplice operazione di close graceful• Chiusura monodirezionale

• Chiusura definitiva in un verso senza perdere i messaggi in trasferimento

• Il nodo A comunica a TCP di non avere ulteriori dati e chiude

• TCP chiude la comunicazione solo nel verso da A a B• se B non ha terminato, i dati continuano a fluire da B ad A• I dati che precedono la fine sono ricevuti prima della fine della connessione

da A a B.• controllo ancora aperto da A a B (flusso di ack)• TCP permette solo il passaggio di ack su canale intenzionalmente chiuso



Protocollo di chiusura della CONNESSIONE TCP:

POSTAZIONE A RETE

Invio ACK y+1

Invio segmento FIN

Ricezione segmento FINInvio ACK di x+1

Ricezione ACK

Ricezione segmento ACK

Invio segmento FIN, ACK x+1

POSTAZIONE B

numero seq=x

Ricezione diFIN + ACK

Ancora dati da B ad A

e ack da A a B

Chiusura a quattro fasi:

• A invia segmento FIN (che arriva dopo i relativi dati)

• TCP aspetta a dare corso alla chiusura definitiva, ma invia ad A solo un ack

• Dopo il tempo necessario per i programmi applicativi B invia ad A il suo segmento FIN che informa della disponibilità a chiudere la connessione

• L'ultimo passo: conferma da A a B della ricezione del segmento FIN e la chiusura del collegamento



I sintesi:

• La gestione della connessione e della reliability porta ad un costo in termini di overhead non trascurabili per piccole interazioni

• I possibili guasti del dialogo sono spesso relativi al concetto di congestione (i gateway scartano i pacchetti IP in caso di congestione:

• TCP implementa diversi algoritmi che manipolano i time out e le dimensioni della slicing window per recuperare al meglio uno stato di congestione

• Il protocollo fornisce all’utente una astrazione di stream completa:

• A Livello di applicazioni si usa quindi TCP quando si hanno esigenze di gestione della reliability (es: HTTP, FTP)

• Si usa invece UDP se si ha la necessità di gestire interazioni non per forza affidabili e senza uno stato necessario (es: protocolli di peering)


Il modello Client/ServerInternetDNS: Domain Name System

È un servizio standard costruito per permettere una associazione logica più semplice all’indirizzo IP.

• In Unix esiste un file /etc/hosts che contiene una tabella fatta in questo modo:

192.168.0.10 localhost pc001pc001.deis.unibo.it137.204.56.1 www-lia www-lia.deis.unibo.it

• È possibile associare ad un indirizzo IP uno o più alias che identificano l’host a cui è associato l’indirizzo

• Cosa fa il sistema:• Riconosce un alias• Verifica se l’alias è nella tabella /etc/hosts• Converte l’alias nell’ip corrispondente• Passa a TCP (o UDP) l’indirizzo IP

• Il DNS non è altro che un servizio distribuito e standard in internet per la conversione degli alias in numeri IP



Quali sono i requisiti di questo servizio:

• Deve essere flessibile e distribuito, non è possibile che ci sia una singola entità che tenga traccia di tutti gli indirizzi di Internet:

• Scalabile• Completamente Distribuito località ogni domonio deve gestire in

proprio il suo naming

• Deve garantire prestazioni significative e garantire un qualità costante nelle risposte perché tutti i client in internet hanno bisogno di risolvere il nome prima di utilizzare uno specifico servizio:

• Reliability (affidabilità)• Efficienza

• Deve essere fidato: devo fidarmi di quello che mi dice (cosa succede se un DNS invece di darmi un indirizzo di una banca mi da un indirizzo di un sito malicious?)

• Trustness (fiducia)



Come possiamo costruire il servizio:

• I numeri IP sono costruiti in modo gerarchico e “parlante”: posso cercare di riprendere il concetto di gerarchia:

• Reti (e sotto reti) vs. Domini• Hosts vs. Servizi in un dominio

• Devo costruire una struttura generale che mi garantisca un ordine:• Delega: ogni Dominio è responsabile del suo naming interno• Autorità riconosciute: decidono i domini di livello 0 (.com .it .org ..) e

forniscono gli indirizzi riconosciuti dei domini di primo livello (amazon.com , unibo.it, mit.edu)

• Ogni dominio è responsabile della integrità dei suoi sottodomini / hosts (è difficile che una banca inserisca nel suo dominio spontaneamente un sito acker)



È stata definita una struttura gerarchica standard.

int com edu gov mil org net it uk fr

yalesun acm ieee cineca unibo inria

java cs eng jack jill deis cs eng

Generic Countries

unims



Caratteristiche Standard del Servizio:

• I singoli nomi sono case insensitive e al max 63 char

• Il nome completo al max 255 char

• Non sono validi solo caratteri riconosciuti in TUTTI gli standard di codifica: ASCII 7

• Non si possono utilizzare inoltre alcuni caratteri riservati (. , / \ | …etc)

• I domini non sono collegati in nessun modo alle reti fisiche o alle organizzazioni (logico vs. fisico): non ho mai vincoli fisici relativamente alla costruzione dei miei domini (motivo per cui possono esistere gli ISP: Internet Service Provider)

• Quando si ha la responsabilità di gestire un dominio si deve garantire una qualità del servizio specifica (si delega la gestione del naming ad operatori specializzati in grado di offire il servizio adeguato)



Implementazione:

• Ogni richiesta viene fatta al servizio di nomi tramite un agente specifico di gestione dei nomi per una località

• a livello di API si passa il riferimento da mappare ad un resolver che • o conosce già la corrispondenza (cache)• o la trova attraverso una richiesta C/S a un name server

• Ogni hosts sa quale è il suo server (DNS Server) di riferimento (configurazione di sistema)

• Il DNS Server di riferimento è normalmente il DNS della organizzazione di cui si fa parte

• Ogni dominio corrisponde infatti al Name Server che ha autorità sulla traslazione degli indirizzi che non ha una visione completa, ma solo locale

• In genere, ogni zona ha un primary master responsabile per i dati della intera zona

• ma in più ci sono una serie di secondary master che sono copie del primary, con consistenza garantita dal protocollo DNS (non massima)



• allo start up il secondario chiede i dati al primario e può fare fronte al traffico in caso di guasto

• Ad intervalli prefissati, i secondari chiedono le informazioni al primario (modello pull)

• I ruoli sono mescolati in modo libero: primario di una zona può diventare il backup (master secondario) di un'altra zona

• Efficienza su località: i dati ottenuti possono essere richiesti nuovamente i server mantengono informazioni

• caching dei diversi server per ottimizzare i tempi di risposta al cliente

• È definito un protocollo di richiesta e risposta per il name server• con uso di protocollo UDP (comunicazione porte 53)• e se messaggi troppo lunghi? Eccezione e uso di TCP



Quale è lo stato che il DNS mantiene per gestire i nomi:

• Un server mantiene un record per ogni risorsa dinamico (caricato da file di configurazione ed aggiornato)

• Le query consultano l'insieme dei record:• Nome dominio• Time to live (tempo validità in secondi)• Classe (Internet IN)• Tipo (descrizione del tipo)• Valore

Tipo Significato Valore

SOA Start of Authority parametri della zona

A IP host address intero a 32 bit (dot not.)

MX Mail exchange server di domino di mail

NS Name server server per dominio corrente

CNAME Canonical name alias di nome in un dominio

PTR Pointer per corrispondenza inversa

HINFO Host description descrizione di host e SO

TXT Text testo qualunque



• Esempi di record DNS:--------------------------------------------------------------@ IN SOA promet1.deis.unibo.it. postmaster.deis.unibo.it. (644 10800 1800 604800 86400) ; serial number, refresh, retry, expiration, TTL in sec ; versione , 3 ore, 1/2 o, 1 sett, 1 d IN NS promet1.deis.unibo.it. IN NS promet4.deis.unibo.it. IN NS almadns.unibo.it. IN NS admii.arl.army.mil.-------------------------------------------------------------------------------------localhost IN A 127.0.0.1@ A 137.204.59.1 MX 10 deis.unibo.it. MX 40 mail.ing.unibo.it.-------------------------------------------------------------------------------------lab2 IN NS lab2fw.deis.unibo.it.lab2fw IN A 137.204.56.136amce11 IN A 137.204.57.244 IN HINFO HW:PC IBM SW:WINDOWS 95 IN WKS 137.204.57.244 TCP FTP TELNET SMTP IN MX 40 amce11.deis.unibo.it.labvisione IN CNAME csite27deis18 IN TXT "Qualunque testo non significativo"deis18 IN RP root.deis.unibo.it luca\.ghedini.mail.ing.unibo.it ; record per responsabile



Come procede la risoluzione dei nomi:

• Se il DNS di zona non è in grado di offrire la risposta deve partire una sequenza di ricerca sugli altri DNS; questa sequenza, a seconda delle implementazioni può seguire due algoritmi:

• Soluzione ricorsiva richiede che al cliente • o si fornisca risposta (anche chiedendo ad altri) • o si segnali errore (dominio non esistente, etc.)

• Soluzione iterativa richiede che al cliente si fornisca • o la risposta • o il migliore suggerimento (come un riferimento al migliore name

server)

• A seconda del ruolo dell’servitore nella gerarchia verranno implementati i due algoritmi:

• Il resolver usa una query tipicamente ricorsiva: ha bisnogno di una risposta e demanda al DNS server di riferimento l’onere di una eventuale escalation

• il server di dominio si incarica di rispondere coordinandosi con altri sequendo un procedimento iterativo

• Tutti i server si comporteranno quindi tra loro in modo iterativo



client

resolver

pippo.cineca.ittrova

Gestoredeis.unibo.it

unibo.itRIF a it

it

cineca.it

RIF a cineca.it

trovato per pippo.cineca.it137.205.88.00

pippo.cineca.itServer diDominio

Server

Dominio

Secondari

Server

Dominio

Secondari


Il modello Client/ServerInternetIn Sintesi: L’accesso ad una pagina WEB

Uso dei diversi livelli di protocolli Da cliente a servitore remotoI passi che devono essere fatti sono i seguenti:

• Richiesta di pagina Web• Richiesta al DNS• Protocollo ARP per trovare percorsi in uscita• Connessione TCP tra client e server• Passaggio dei dati• Chiusura

dns. .unibo.it

127.204.1.4

www.blob.co.uk160.160.1.42

127.204.1.1

dns.blob.co.uk160.160.1.20

160.160.1.1

Internet

router-pippo router-blob

host1.pippo.unibo.it

127.204.1.10

1) DNS query for host www.blob.co. uk

2) ARP request for 127.204.1.4, ARP reply from 127.204.1.4

4) Routing decision based on default entry in routing table

5) ARP request for 127.204.1.1, ARP reply from 127.204.1.1

6) TCP connection request sent to www.blob.co.uk via 127.204.1.1

3) DNS query sent to 127.204.1.4 (resolved), DNS reply from 127.204.1.4

8) TCP connection reply arrives at hosts1,HTTP connection request sent to www.blob.co.uk

7) TCP connection request arrives www.blob.co.uk,TCP connection reply returned

127.204.0.0/16 127.204.1.10default 127.204.1.1

pippo


Il modello Client/ServerInternetEstensioni dei Protocolli TCP/IP

Al di sopra della suite TCP/IP è possibile costruire soluzioni adatte alle esigenze più diverse:

FTPHTTP

TCP

IP

UDP

RTPTELNET

SMTPPOP SNMPDNS

Internet

VT

XDR

NFS

Accanto ai protocolli tradizionali, compaiono molte linee di sviluppo, incoraggiate da IETF con la costituzione di gruppi di lavoro:

• Alcuni protocolli rappresentano necessità di ampie utenze: NAT, DHCP, PPP, ...• estensioni per consentire una migliore sicurezza• estensioni per la gestione della mobilità• estensioni per considerare sistemi a flusso di informazioni multimedial• estensioni per la gestione della qualità di servizio


Il modello Client/ServerInternetAlcuni protocolli standard

PPP e SLIP:

• Protocolli nati per la gestione di ampie batterie di modem:• È troppo costoso assegnare un IP ad ogni utente• Viene creato un pool di indirizzi che viene associato dinamicamente

alla sola sessione di accesso di un modem• Quando un modem chiude la connessioen il numero IP assegnato torna

nel pool

DHCP (rfc 2131)• Protocollo nato per la gestione di reti molto dinamiche Quando un host

entra nella rete chiede un IP:• Si basa su due ruoli: clienti e servitori con protocollo di bidding a fasi

• broadcast del discovery (richiesta di ingresso)• offerte dei servitori (con parametri di scelta)• scelta di una offerta (in broadcast)• conferma della offerta• messaggi di mantenimento prima della scadenza (lease)

• È molto interessante vista la diffusione dei computer portatili nelle grosse organizzazioni


Il modello Client/ServerInternetDHCP: implementazione

clientserver A server B

DHCPACK

DHCPRELEASE

DHCPOFFER DHCPOFFER

i server mandano inbroadcast reply (porta 68)

DHCPDISCOVER DHCPDISCOVERmessaggio broadcast(porta 67 bx limitato)

DHCPREQUESTDHCPREQUESTconferma ancora bxcon scelta del server B


Il modello Client/ServerInternetReti Publiche vs. Private, Aperte vs. Opache

• Il naming basato su IP ha permesso di creare una rete pubblica completa; ogni host è in grado di raggiungere ogni altro host attraverso il routing.

• Questa soluzione però non sempre è interessante, a volte infatti può essere favorevole creare reti private (non raggiungibili direttamente) con un set di indirizzi separato dal resto della rete:

• Vantaggio di costo: un indirizzo IP pubblico ha un costo• Protezione e sicurezza: non espongo direttamente la mia macchina su

internet ma gestisco direttamente il suo accesso• Flessibilità: posso utilizzare senza complessità aggiunta protocolli di

assegnamento dinamico come il DHCP

• Si parla di Reti Private o Opache quando gli indirizzi IP della rete non sono esposti direttamente su internet

• In Internet, una rete opaca è vista attraverso i suoi gateway, i gateway nascondono gli indirizzi interni e si occupano della traduzione (ad esempio FastWeb ha una rete privata, da internet si vedono solo i gateway delle diverse reti cittadine


Il modello Client/ServerInternetNAT

• NAT: Network Address Transaltion: è il servizio che gestisce la traduzione degli indirizzi nel caso di reti opache

• Traduce, all’interno dei pacchetti IP gli indirizzi pubblici/privati e si occupa di ricostruire i pacchetti (checksum) in modo corretto

• Le applicazioni che utilizzano direttamente i numeri IP possono andare incontro a problemi nel pacchetto infatti risulta un destinatario IP privato… se provo a raggiungerlo al di fuori della sessione di interazione specifica (controllata dal NAT) non riesco a risolvere il nome

Internet

10.2.2.210.1.1.1

10.1.1.1 210.55.66.77 10.2.2.2 212.22.33.44

src=10.1.1.1dst

src=210.55.66.77dst=212.22.33.44

src=210.55.66.77dst=212.22.33.44

=10.2.2.2

src=10.1.1.1dst=10.2.2.2

IPheader

IPheader

2003-2004reti di calcolatori1 il modello client/server internet: gli standard de facto application...

Documents

ip internet protocol

il requisito

rete se

calcolatori11 il modello

costruisco reti

il gateway risolve

rete ethrnet

suo specifico ip reti