Diapositiva 1

1
Internet gli standard de facto
Il modello Client/Server
HTTP SMTP FTP
UDP e TCP
IP
Ethernet, PPP, ATM
2
InternetInterconnessione tra reti
Il modello Client/Server

• Le implementazioni per internet devono
• tenere conto della presenza di
• tante 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 risolve
• i problemi di interfacciamento tra le
• diverse implementazioni dei livelli fisici
• e di data link
• Routing per esigenze reali non costruisco
• Reti 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

3
InternetLo stack TCP-IP
Il modello Client/Server

• livello 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
  dellindirizzo fisico di un nodo
• RARP Reverse Address Resolution Protocol Ricerca
  un indirizzo IP di un nodo

4
InternetApplicazioni e Comunicazioni in TCP/IP
Il modello Client/Server
5
InternetInterazioni via Gateway
Il modello Client/Server
6
InternetIl Servizio IP
Il modello Client/Server

• 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

7

InternetIP Naming ed indirizzamento gerarchico
Il modello Client/Server

• Ogni connessione di un host a una rete ha un
  indirizzo internet unico formato da due elementi
  e detto IP-ADDRESSNETID, HOSTID
• NETID è lidentificatore di rete
• HOSTID è ldentificatore 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
  allinterno della rete 137 ci sarà o il nodo
  identificato dallid 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

8

InternetIP Naming le classi degli indirizzi
Il modello Client/Server
Esempio 137.204.56.1 137 10001001 ? è una
rete di classe B ! ? una LAN di grandi
dimensioni NETID 137.204 HOSTID 56.1
9

InternetIP Naming Broadcast e Multicast
Il modello Client/Server

• 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)

10

InternetIP Naming Assegnamento indirizzi
Il modello Client/Server

• 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
  unaltra
• 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

11

InternetIP Caratteristiche e specifiche
Il modello Client/Server

• 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

12

InternetIP Struttura del Datagramma
Il modello Client/Server
Intestazione Dati

• I sottocampi del campo header contengono
• versione del protocollo
• lunghezza header e totale (totale lt 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

13

InternetARP Address Resolution Protocol
Il modello Client/Server

• 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

14

Internet ARP Address Resolution Protocol
Il modello Client/Server

• 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
  allinvio 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 lindirizzo IP a rispondere, ma tutti
  i nodi che conoscono il MAC Address associato a
  quello specifico IP
• Il pacchetto ARP

15

InternetRARP Reverse Address Resolution Protocol
Il modello Client/Server

• 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?
• Lhost 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 lip corrispondente
• Ci possono essere più server sulla rete ?
  possono rispondere tutti senza problemi di
  coordinamento (operazione idempotente)

16

InternetRouting e separazione fra reti
Il modello Client/Server

• ARP e RARP funzionano solamente allinterno 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 allaltra

17

InternetRouting e separazione fra reti
Il modello Client/Server

• La separazione logica può essere ulteriorimente
  diversificata attraverso il concetto di subnet
• Allinterno della rete 137.204 è possibile
  definire due sottoreti 137.204.56 e 137.204.57
• La subnet è rispettata permettendo una
  comunicazione diretta solo allinterno,
  obbligando il passaggio per un gateway per andare
  nellaltra 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

18

InternetRouting in topologie complesse
Il modello Client/Server
GATEWAY
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
19

InternetRouting i percorsi multipli
Il modello Client/Server

• 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)

20

InternetRouting gestione dei percorsi
Il modello Client/Server

• 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

21

InternetAlgoritmi di routing
Il modello Client/Server

• Algoritmi generalmente globali basati su tabelle
  che sono disponibili ai diversi router
  partecipanti
• A parte alcuni casi iniziali è diffuso luso di
  protocolli isolati tipo patata bollente
• Algoritmi Statici
• basati su informazioni statiche riguardanti il
  cammino più breve (per piccole reti ed
  interconnessioni)
• 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 limpostazione 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

22

InternetAlgoritmi di routing Distance Vector
Il modello Client/Server

• 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 lhop successivo
• La propagazione delle informazioni (nelle tabelle
  di routing) è la chiave della gestione
  dellalgoritmo

R0 0 R1 0 R2 0 Rn-1 0
R1 0 R2 0 R3 0 ... Rn 0
1 passo propagazione
2 passo propagazione
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
23

InternetAlgoritmi di routing Distance Vector
Il modello Client/Server

• Cosa succede se cambia un percorso

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 asincrono Chi 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
24

InternetDistance Vector problemi di
riconfigurazione
Il modello Client/Server

• 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 allunico 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 allinfinito
  (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

25

InternetDistance Vector Varianti per ridurre i
problemi
Il modello Client/Server

• 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)
• Lalgoritmo 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

26

InternetAlgoritmi di routing Link State
Il modello Client/Server

• 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)

27

InternetLink State Caratteristiche degli
Algoritmi
Il modello Client/Server

• 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à

28

InternetRouting i protocolli di coordinamento
tra gateway
Il modello Client/Server

• 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à ?
  allinterno 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

29

InternetICMP Internet Control Message Protocol
Il modello Client/Server

• 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

30

InternetICMP Internet Control Message Protocol
Il modello Client/Server

• 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 -----------------------?

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
31

InternetICMP Internet Control Message Protocol
Il modello Client/Server

• Eventi Segnalati
• campo CODE gt 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
32

InternetICMP Internet Control Message Protocol
Il modello Client/Server

• 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

33

InternetUDP User Datagram Protocol
Il modello Client/Server

• È il protocollo di livello trasporto per la
  gestione da parte dellutente di comunicaizoni di
  tipo datagramma
• Indirizzo mentre IP deve identificare un nodo,
  UDP deve identificare uno specifico processo
  allinterno 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

34

InternetUDP User Datagram Protocol
Il modello Client/Server

• 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

35

InternetUDP User Datagram Protocol
Il modello Client/Server

• 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

36

InternetUDP User Datagram Protocol
Il modello Client/Server

• 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
37

InternetUDP User Datagram Protocol
Il modello Client/Server

• 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 linvio
• 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
  lunico stato è dato dalla definizione di una
  porta specifica per la ricezione

38

InternetTCP Transfer Control Protocol
Il modello Client/Server

• 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

39

InternetTCP Transfer Control Protocol
Il modello Client/Server
Formato del segmento TCP (header 20 byte)
40

InternetTCP Transfer Control Protocol
Il modello Client/Server

• CODE BIT
• URG un dato urgente nel segmento
• ACK acknowledgement nel segmento
• PUSH invio immediato del segmento
• RST reset di una connessione
• SYN 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

41

InternetTCP Transfer Control Protocol
Il modello Client/Server
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
42

InternetTCP Transfer Control Protocol
Il modello Client/Server

• 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

• 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
  dellintera comunicazione dalla eccezione in poi)

43

InternetTCP Transfer Control Protocol
Il modello Client/Server

• 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

Il sistema di comunicazione a tre fasi ?
compromesso ogni nodo invia un messaggio ed ha
conferma Semantica at-most once
44

InternetTCP Transfer Control Protocol
Il modello Client/Server

• 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

45

InternetTCP Transfer Control Protocol
Il modello Client/Server

• 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

46

InternetTCP Transfer Control Protocol
Il modello Client/Server
Protocollo di chiusura della CONNESSIONE TCP

• 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

47

InternetTCP Transfer Control Protocol
Il modello Client/Server

• 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 allutente 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)

48

InternetDNS Domain Name System
Il modello Client/Server

• È un servizio standard costruito per permettere
  una associazione logica più semplice
  allindirizzo IP.
• In Unix esiste un file /etc/hosts che contiene
  una tabella fatta in questo modo
• 192.168.0.10 localhost pc001 pc001.deis.unibo.
  it
• 137.204.56.1 www-lia www-lia.deis.unibo.it
• È possibile associare ad un indirizzo IP uno o
  più alias che identificano lhost a cui è
  associato lindirizzo
• Cosa fa il sistema
• Riconosce un alias
• Verifica se lalias è nella tabella /etc/hosts
• Converte lalias nellip corrispondente
• Passa a TCP (o UDP) lindirizzo IP
• Il DNS non è altro che un servizio distribuito e
  standard in internet per la conversione degli
  alias in numeri IP

49

InternetDNS Domain Name System
Il modello Client/Server

• 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)

50

InternetDNS Domain Name System
Il modello Client/Server

• 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)

51

InternetDNS Domain Name System
Il modello Client/Server
È stata definita una struttura gerarchica
standard.
52

InternetDNS Domain Name System
Il modello Client/Server

• 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)

53

InternetDNS Domain Name System
Il modello Client/Server

• 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)

54

InternetDNS Domain Name System
Il modello Client/Server

• 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

55

InternetDNS Domain Name System
Il modello Client/Server

• 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
56

InternetDNS Domain Name System
Il modello Client/Server

• Esempi di record DNS
• --------------------------------------------------
  ------------
• _at_ 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
• _at_ 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.136
• amce11 IN A 137.204.57.244
• IN HINFO HWPC IBM SWWINDOWS 95

57

InternetDNS Domain Name System
Il modello Client/Server

• 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 dellservitore 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 lonere 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

58

InternetDNS Domain Name System
Il modello Client/Server
59

InternetIn Sintesi Laccesso ad una pagina WEB
Il modello Client/Server

• Uso dei diversi livelli di protocolli ? Da
  cliente a servitore remoto
• I 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

60

InternetEstensioni dei Protocolli TCP/IP
Il modello Client/Server
Al di sopra della suite TCP/IP è possibile
costruire soluzioni adatte alle esigenze più
diverse

• 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

61

InternetAlcuni protocolli standard
Il modello Client/Server

• 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

62

InternetDHCP implementazione
Il modello Client/Server
63

InternetReti Publiche vs. Private, Aperte vs.
Opache
Il modello Client/Server

• 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

64

InternetNAT
Il modello Client/Server

• NAT Network Address Transaltion è il servizio
  che gestisce la traduzione degli indirizzi nel
  caso di reti opache
• Traduce, allinterno 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