DNS: Domain Name System - di.unito.itrossano/DIDATTICA/reti/lezione5-6-7.pdf · Semplice esempio...

2: Livello Application 43

DNS: Domain Name System

People: molti identificativi:o # CF, nome, # passaporto

Host e router in Internet:o indirizzo IP (32 bit) – usato

per indirizzare datagramso “nome”, e.g.,

pianeta.di.unito.it – usato dagli esseri umani

Domanda: corrispondenza tra indirizzo IP e nome ?

Domain Name System:database distribuitoimplementato con una gerarchia di name serverprotocollo di livello applicationhost, router, e name servers comunicano per risolvere nomi (traduzione indirizzo/nome)

o nota: funzione chiave in Internet, implementata come protocollo a livello application

o complessità nella edge network


Servizi offerti dal DNS

Traduzione di indirizzi mnemonico -> IPHost aliasing

o indirizzi mnemonici “complicati” possono avere alias piùsemplici

Mail server aliasingDistribuzione di carico

o web server replicati su host con stesso indirizzo mnemonico (e.g., cnn.com) ma diversi indirizzi IP

o rotazione degli indirizzi nelle risposte (l’ordine determina chi contattare per primo da parte del client HTTP)


DNS name serversnessun server ha tutte le corrispondenze nome-indirizzo IP

name server locali:o ogni ISP o azienda ha dei name

server locali (default) o la query DNS di un host è

innanzitutto diretta al nameserver locale

name server autoritativo:o per un host: memorizza il

nome e l’indirizzo IP di quell’ host

o può eseguire la traduzione nome/indirizzo per il nome di quell’ host

Perché non centralizzare il DNS?punto unico di guastovolume di trafficodatabase centralizzato distante mantenimento

non scala!


DNS: Root name serverscontattati dai name server locali che non sanno risolvere un nomeroot name server:o contatta il name server autoritativo se la corrispondenza per il

nome non è conosciutao ottiene la corrispondenzao restituisce la corrispondenza al name server locale

b USC-ISI Marina del Rey, CAl ICANN Marina del Rey, CA

e NASA Mt View, CAf Internet Software C. Palo Alto, CA

i NORDUnet Stockholmk RIPE London

m WIDE Tokyo

a NSI Herndon, VAc PSInet Herndon, VAd U Maryland College Park, MDg DISA Vienna, VAh ARL Aberdeen, MDj NSI (TBD) Herndon, VA

13 root nameserver nel mondo


Semplice esempio DNS

l’ hostsurf.eurecom.frvuole l’indirizzo IP di gaia.cs.umass.edu

1. contatta il suo server DNS locale,

dns.eurecom.fr2. dns.eurecom.fr contatta

il root name server, se necessario

3. il root name server contatta il name server autoritativo, dns.umass.edu, se necessario

host richiedente surf.eurecom.fr

gaia.cs.umass.edu

root name server

name server autorititivo dns.umass.edu

local name serverdns.eurecom.fr

1

23

45

6


Esempio DNS

Root name server:può non conoscere il name server autoritativopuò conoscere un nameserver intermedio : chi contattare per trovare il name server autoritativo

host richiedentesurf.eurecom.fr

gaia.cs.umass.edu

root name server


1

23

4 5

6

name server autoritativo dns.cs.umass.edu

name server intermedio dns.umass.edu

7

8


DNS: query iteratequery ricorsive:

scarica il peso della risoluzione del nome sul name server contattatocarico pesante?

query iterate:il server contattato risponde con il nome del server da contattare“Non conosco questo nome ma chiedi a questo server”

host richiedentesurf.eurecom.fr

gaia.cs.umass.edu

root name server


1

23

4

5 6

name server autoritativo dns.cs.umass.edu

name server intermedio dns.umass.edu

7

8

query iterate


DNS: caching e aggiornamento record

una volta che un (qualunque) name server impara una corrispondenza, la mette in una “cache”o gli elementi della cache vanno in timeout

(scompaiono) dopo qualche tempomeccanismo di aggiornamento/notifica sotto progetto del IETF

o RFC 2136o http://www.ietf.org/html.charters/dnsind-charter.html


DNS recordDNS: database distribuito che memorizza record di risorse,

resource records (RR)

Type=NSo name è un dominio (e.g.

foo.com)o value è un indirizzo IP di un

name server autoritativo per questo dominio

formato RR: (name, value, type, ttl)

Type=Ao name è un hostnameo value è un indirizzo IP

Type=CNAMEo name è un alias di un nome

“canonico” (quello vero)www.ibm.com

è in realtàservereast.backup2.ibm.com

o value è il nome canonicoType=MXo value è il nome del

mailserver associato a name


DNS record

Se un name server è autoritativo per un host allora conterrà un record con Type=A per quell’hostUn name server non autoritativo può contenere un record con Type=A (caching)Se un name server non è autoritativo per un host allora conterrà un record con Type=NS per il dominio che include l’host; conterrà anche un record con Type=A e indirizzo IP per il campo Value del record con Type=NS

o (umass.edu, dns.umass.edu, NS)o (dns.umass.edu,128.119.40.111,A)


Protocollo DNS: i messaggiProtocollo DNS : messaggi di query e reply, entrambi con lo

stesso formato di messaggio

header del messaggioidentificazione: # di 16 bit per le query, e il reply alla query usa lo stesso #flag:

o query o replyo ricorsione desiderata o ricorsione disponibileo reply è autoritativo


Protocollo DNS: i messaggi

Nome, campi tipoper una query

RR in risposta ad una query

record perserver autoritativi

informazioni “utili” aggiuntiveche possono essere usate

(e.g., RR con Type=A per alias mail server)


Parte 2: sommario

requisiti di servizio delle applicazioni:

o affidabilità, larghezza di banda, ritardo

paradigma client-serverModelli di servizio di trasporto in Internet

o connection-oriented, affidabile: TCP

o non affidabile, datagram: UDP

Completato lo studio delle applicazioni di rete!

protocolli specifici:o httpo ftpo smtp, pop3o dns

programmazione con socket

o implementazione di un client/server

o usando socket tcp, udp


Parte 2: sommario

tipico scambio di messaggi request/reply:

o il client richiede servizi o informazioni

o il server risponde inviando dati e codici di stato

formati dei messaggi:o header (intestazioni): i

campi danno informazioni sui dati

o dati: informazioni che vengono comunicate

Più importante: imparato qualcosa sui protocolli

messaggi di controllo vs. datio in-based, out-of-band

centralizzato vs. decentralizzato stateless vs. con statotrasferimento di messaggiaffidabile vs. non affidabile“complessità ai bordi della rete”sicurezza: auetenticazione

3: Livello Transport 1

Parte 3: livello transportObiettivi:❒ comprendere i principi

alla base dei servizi a livello di trasporto:

❍ multiplexing/demultiplexing

❍ trasferimento dati affidabile

❍ controllo di flusso❍ controllo di congestione

❒ realizzazione in Internet

Panoramica:❒ servizi del livello di trasporto❒ multiplexing/demultiplexing❒ trasporto connectionless: UDP❒ principi di trasferimento dati

affidabile❒ trasporto connection-oriented:

TCP❍ trasferimento affidabile❍ controllo di flusso❍ gestione delle connessioni

❒ principi del controllo di congestione

❒ controllo di congestione in TCP


Protocolli e servizi di Trasporto

❒ fornire la comunicazione logica tra processi (applicazioni di rete) in esecuzione su host diversi

❒ i protocolli di trasporto sono eseguiti sugli host (end-system)

❒ servizi di livello transport vsservizi di livello network:

❒ livello network: trsferimentodati tra host (end-system)

❒ livello trasporto:trasferimento dati tra processi

❍ si affida ai sevizi di livello network

applicationtransportnetworkdata linkphysical


networkdata linkphysical



networkdata linkphysicalnetwork

data linkphysical

trasporto end-to-end logico


Protocollo di livello di trasporto

Servizi di trasporto in Internet:❒ trasporto affidabile, in ordine,

unicast (1-to-1): (TCP)❍ congestione ❍ controllo di flusso❍ setup della connessione

❒ trasporto non affidabile (“best-effort”), non ordinato,unicast o multicast (1 to-M): UDP

❒ servizi non disponibili:❍ real-time❍ larghezza di banda garantita❍ multicast affidabile






networkdata linkphysicalnetwork

data linkphysical

trasporto end-to-end logico


Analogia umana (1)

❒ Due abitazioni (Italia, Australia) abitate da fratelli (10 in Italia e 10 in Australia) cugini degli altri 10

❒ Ognuno scrive agli altri 10 una lettera in buste separate recapitate dalle Poste (Italiana ed Australiana)

❒ Ogni settimana 100 lettere partono da una abitazione verso l’altra

❒ In ogni abitazione c’è un responsabile (Teo e Tea) che, ogni settimana, raccoglie e distribuisce le lettere (in partenza e in arrivo). Se in partenza le passa al postino che passa dall’abitazione ogni giorno dal quale raccoglie quelle in arrivo


Analogia umana (2)

❒ Le Poste offrono, in questo esempio, la comunicazione logica tra le due abitazioni

❒ Teo e Teo offrono la comunicazione logica tra cugini (abitanti nella stessa casa)

❒ Dal punto di vista dei cugini, Teo e Tea sono il servizio postale anche se ne sono solo una parte (quella finale)


Analogia umana (3)

❒ Abitazioni = Host (End System)❒ Cugini = Processi su un Host❒ Lettere in busta = Messaggi delle Applicazioni❒ Servizio postale = Protocolli di livello network❒ Teo e Tea = Protocolli di livello Transport


Analogia umana (4)

❒ Teo e Tea svolgono il loro compito nelle abitazioni e non si curano della gestione delle lettere nei vari uffici postali nel cammino dall’Italia all’Australia e viceversa

❒ Analogamente, i protocolli di livello Transport sono parte degli host (end system) e non dei router (egateway)

❒ Il servizio postale non conosce il contenuto delle lettere o distingue tra tipi di mittente o destinatario

❒ Analogamente, i router della core network non discriminano i pacchetti che stanno instradando


Analogia umana (5)

❒ Teo e Tea a volte sono sostituiti da Beo e Bea che, essendo più piccoli, non raccolgono e smistano frequentemente le lettere o, a volte, ne smarriscono alcune

❒ Analogamente, i servizi del livello Transportofferti ai processi possono differire all’interno di un host (TCP o UDP)

❒ I servizi offerti da Teo e Tea sono vincolati ai servizi che il servizio postale offre, e.g., garanzia del recapito entro tre giorni

❒ Analogamente, i servizi del livello transport sono limitati e condizionati dal modello di servizio del livello network, e.g., garanzie sul ritardo o ampiezza di banda


applicationtransportnetwork

M P2applicationtransportnetwork

Multiplexing/demultiplexing

Ricordate: segmento – unità dati scambiata tra entità del livello di trasporto

❍ alias TPDU: transport protocol data unit

ricevente

HtHn

Demultiplexing: smistare i segmenti ricevuti ai giusti processi del livello application in esecuzione sugli host

segmentosegmento M

applicationtransportnetwork

P1M

M MP3 P4

headersegmento

dati del livello application

IP fornisce comunicazione logica tra due host usando l’indirizzo IP !!


Multiplexing/demultiplexing

multiplexing/demultiplexing:❒ si basa sul numero di porta del

mittente (source) e del destinatario (destination), e sugli indirizzi IP

❍ numero di porta di source(mittente) e destination(ricevente) in ogni segmento

❍ ricordate: ci sono i numeri di porta well-known usati da applicazioni specifiche (http,smtp……) (da 0 a 1023)

raccolta dei messaggi da diversi processi del livello application, aggiunta di un headerai dati (usato successivamente per il demultiplexing)

source port # dest port #

32 bits

datiapplicazione(messaggio)

altri campi dell’ header

formato del segmento TCP/UDP

Multiplexing: analogia umana?


Multiplexing/demultiplexing: esempi

host A server Bsource port: xdest. port: 23

source port:23dest. port: x

uso della porta: applicazione telnet

client Webhost A

Webserver B

client Webhost C

Source IP: CDest IP: B

source port: xdest. port: 80

Source IP: CDest IP: B

source port: ydest. port: 80

uso della porta: Web server

Source IP: ADest IP: B

source port: xdest. port: 80


UDP: User Datagram Protocol [RFC 768]

❒ protocollo di livello trasporto in Internet

❒ servizio “best effort”, i segmenti UDP possono essere:

❍ persi❍ recapitati non in ordine

all’applicazione❒ connectionless:

❍ senza handshaking tra mittente UDP e ricevitore UDP

❍ ogni segmento UDP viene gestito indipendentemente dagli altri

Perché esiste UDP?❒ senza creazione di una

connessione (che può aggiungere ritardo)

❒ semplice: senza stato della connessione nel mittente e nel ricevitore

❒ piccolo header del segmento

❒ senza controllo di congestione: UDP può spedire dati alla velocità che desidera


UDP: User Datagram Protocol❒ usato spesso per applicazioni di

streaming multimedia❍ tolleranti alle perdite❍ dipendenti dalla velocità

(rate sensitive)❒ altri usi di UDP(perché?):

❍ DNS❍ SNMP

❒ trasferimento affidabile con UDP: si aggiunge l’affidabilità al livello di applicazione

❍ recupero dall’ errore dipendente dall’applicazione!


32 bits

Datiapplicazione(messaggio)

formato del segmento UDP

lunghezza checksum

Lunghezza, inbytes del

segmento UDP,incluso

l’header


UDP checksum

Mittente:❒ tratta il contenuto dei

segmenti come sequenze di interi di 16 bit

❒ checksum: somma (in complemento ad 1) del contenuto dei segmenti

❒ il mittente scrive il valore del checksum nel campochecksum del segmento UDP

Ricevente:❒ calcola il checksum del segmento

ricevuto❒ controlla se il checksum

calcolato è uguale al valore del campo checksum del segmento:

❍ NO – riconoscimento errore ❍ SI – nessun errore

riconosciuto. Forse c’è comunque un errore?Vediamo dopo ….

Obiettivo: riconoscimento “errori” (e.g., bit invertiti) nei segmenti trasmessi


Principi del trasferimento dati affidabile❒ importante nel livello applicazione, trasporto e data link❒ importante argomento di networking!

❒ le caratteristiche di un canale non affidabile determineranno la complessità del protocollo di trasferimento affidabile di dati (rdt)


Trasferimento dati affidabile : gli inizi

lato mittente

latoricevente

rdt_send(): invocata dall’alto, (e.g., dall’applicazione). Passaggio

dei dati da recapitare al ricevitore al livello superiore

udt_send(): invocata da rdt,per trasferire pacchetti su un

canale non affidabile ad un ricevitore

rdt_rcv():invocata quando il pacchetto arriva sul lato del

ricevitore del canale

deliver_data(): invocata da rdt per recapitare i dati

al livello superiore


Trasferimento dati affidabile : gli iniziCosa faremo:❒ sviluppiamo in maniera incrementale (con miglioramenti

successivi) il lato mittente e ricevente del protocollo per trasferimento di dati affidabile (rdt)

❒ consideriamo solo trasferimenti dati unidirezionali❍ anche se le informazioni di controllo possono viaggiare in

entrambe le direzioni!❒ usiamo una macchina a stati finiti (FSM) per specificare

(descrivere) mittente e destinatario

stato1

stato2

evento che causa una transizione di statoazioni effettuate in seguito a transizione di stato

stato: quando ci si trova in questo “stato” il

prossimo stato è univocamente

determinato dal prossimo evento

eventoazione


Rdt1.0: trasferimento affidabile su un canale affidabile

❒ canale sottostante perfettamente affidabile❍ nessun errore sui bit trasmessi❍ nessuna perdita di pacchetti

❒ FSM separati per mittente e ricevente:❍ mittente spedisce dati sul canale sottostante❍ ricevente riceve dati dal canale sottostante


Rdt2.0: canale con errori sui bit❒ IPOTESI: pacchetti ricevuti in ordine❒ il canale sottostante può invertire i bit in un pacchetto

❍ ricordate: il checksum di UDP rileva gli errori sui bit❒ la domanda: come si può recuperare un errore?:

❍ acknowledgements (ACK) (conferma di ricezione): il ricevitore comunica esplicitamente al mittente di aver ricevuto correttamente il pacchetto

❍ negative acknowledgements (NAK): il ricevitore comunica esplicitamente al mittente di aver ricevuto con errori il pacchetto

❍ il mittente ritrasmette il pacchetto in seguito alla ricezione di un NAK

❍ analogie umane dell’uso di ACK e NAK?❒ nuovi meccanismi in rdt2.0 (rispetto a rdt1.0):

❍ rilevazione di errori❍ feedback da parte del ricevente: messaggi di controllo

(ACK,NAK) ricevente -> mittente❍ ri-trasmissione


rdt2.0: specifica dei FSM

FSM del mittente FSM del ricevente

Il mittente spedisce un pacchetto, ed attende una risposta del ricevente

stop and wait


rdt2.0: in azione (senza errori)



rdt2.0: in azione (scenario con errori)



rdt2.0 ha un difetto fondamentale!

Che succede se ACK/NAK vengono rovinati (errori in trasmissione)?

❒ il mittente non sa cosa è successo al ricevente!

❒ non può solo ritrasmettere: possibile duplicazione

Cosa fare?❒ ACK/NAK del mittente e

ACK/NAK del ricevente? Cosa succede se ACK/NAK del mittente vengono rovinati?

❒ ritrasmettere, ma ciò potrebbe causare la ri-trasmissione di pacchetti ricevuti correttamente!

Gestione dei duplicati: ❒ il mittente aggiunge un

numero di sequenza ad ogni pacchetto

❒ il mittente ri-trasmette il pacchetto corrente se l’ ACK/NAK contiene errori

❒ il ricevente scarta (non recapita ai livelli superiori) pacchetti duplicati


rdt2.1: mittente, gestisce ACK/NAK distorti


rdt2.1: ricevente, gestisce ACK/NAK distorti


rdt2.1: discussione

Mittente:❒ numero di sequenze aggiunto

ai pacchetti❒ solo due numeri di sequenza

(0,1) vanno bene. Perché?❒ si deve controllare se gli

ACK/NAK ricevuti sono rovinati

❒ gli FSM hanno il doppio degli stati

❍ lo stato deve “ricordare” se il “pacchetto corrente” ha numero di sequenza 0 o 1

Ricevente:❒ deve controllare se il

pacchetto ricevuto è duplicato

❍ lo stato indica se 0 o 1 è il numero di sequenza atteso

❒ nota: il ricevente non può sapere se il suo ultimo ACK/NAK è stato ricevuto dal mittente senza errori


rdt2.2: un protocollo senza NAK

❒ stesse funzionalità di rdt2.1, usando solo ACK

❒ invece di un NAK, il ricevente spedisce un ACK per l’ultimo pacchetto ricevuto correttamente

❍ il ricevitore deve includere esplicitamente il numero di sequenza del pacchetto confermato dall’ACK

❒ ACK duplicati al mittente danno origine alla stessa azione di un NAK: ri-trasmissione del pacchetto corrente

FSM delmittente

!


rdt3.0: canali con errori e perdite

Nuove ipotesi: il canale sottostante può anche perdere pacchetti (dati o ACK)

❍ checksum, numeri di sequenza, ACK, ri-trasmissioni aiutano ma non abbastanza

Domanda: come gestire le perdite?

❍ rilevare le perdite❍ azioni per gestire la

perdita

Approccio: il mittente attende un ACK per un tempo “ragionevole”

❒ ri-trasmette se non ha ricevuto ACK entro questo tempo

❒ se il pacchetto (o l’ACK) sono solo in ritardo (non persi) :

❍ la ri-trasmissione sarà duplicata, ma l’uso dei numeri di sequenza gestisce questo caso

❍ il ricevitore deve specificare il numero di sequenza del pacchetto per il quale spedisce l’ACK

❒ è necessario un countdown timer


rdt3.0 mittente


rdt3.0 in azione


Prestazioni di rdt3.0

❒ rdt3.0 funziona ma fornisce pessime prestazioni❒ esempio: canale a 1 Gbps link, 15 ms propagation delay, pacchetti

da 1KB:

Ttransmit = 8kb/pkt10**9 b/sec = 8 microsec

Utilizzazione = U = = 8 microsec30.016 msec

frazione di tempodurante la quale il

mittente è impegnato a trasmettere

= 0.00015

❍ un pacchetto da 1KB ogni 30 msec -> 33kB/sec su 1 Gbps ❍ il protocollo di rete limita l’uso delle risorse fisiche!


Protocolli PipelinedPipelining: il mittente permette che ci siano pacchetti “in

transito” per i quali ancora non è stato ricevuto un ACK❍ i possibili valori dei numeri di sequenza devono aumentare❍ buffering al mittente e/o ricevente

❒ Due forme generiche di protocolli pipelined: go-Back-N, selective repeat


Go-Back-NMittente:❒ numero di sequenza di k bit nell’ header del pacchetto❒ “finestra” di, fino a, N pacchetti consecutivi non ancora con ACK

❒ ACK(n): fornise un ACK di tutti i pacchetti i cui numeri di sequenza vanno fino ad n incluso “cumulative ACK”

❒ timer per ogni pacchetto in transito❒ timeout(n): ri-trasmette il pacchetto con numero di sequenza n e

tutti quelli con numero di sequenza maggiore nella finestra


GBN: FSM esteso del mittente


GBN: FSM esteso del ricevente

semplice ricevente:❒ manda un ACK: manda sempre un ACK per pacchetti con il

numero di sequenza più alto ricevuti in ordine e correttamente

❍ può generare ACK duplicati❍ deve solo ricordare expectedseqnum

❒ pacchetti non in ordine: ❍ elimina (non bufferizza) -> ricevente senza buffering!❍ ACK per pacchetto con il numero di sequenza più alto ricevuto in

ordine


GBN inazione


Selective Repeat

❒ il ricevente manda un ACK individuale per tutti i pacchetti correttamente ricevuti

❍ bufferizza pacchetti, se necessario, per il recapito finale in ordine al livello superiore

❒ il mittente ri-spedisce solo i pacchetti per i quali non ha ricevuto un ACK

❍ timer del mittente per ogni pacchetto senza ACK❒ finestra del mittente

❍ N numeri di sequenza consecutivi❍ limita il numero di sequenza di pacchetti spediti e non

ancora con ACK


Selective repeat: finestre mittente e ricevente


Selective repeat

data dal livello superiore:❒ se il prossimo numero di

sequenza disponibile è nella finestra spedisce il pacchetto

timeout(n):❒ ri-spedisce il pacchetto, ri-

inizializza il timerACK(n) in [sendbase,sendbase+N]:❒ marca il pacchetto n come

ricevuto❒ se n è il più piccolo

pacchetto senza ACK, avanza la base della finestra al prossimo numero di sequenza di un pacchetto senza ACK

mittente pacchetto n in [rcvbase, rcvbase+N-1]

❒ spedisce ACK(n)❒ non in ordine: bufferizza❒ in ordine: recapita

(recapita anche pacchetti in ordine bufferizzati), avanza la finestra al prossimo pacchetto non ancora ricevuto

pacchetto n in [rcvbase-N,rcvbase-1]

❒ ACK(n)altrimenti:❒ ignora pacchetto

ricevente


Selective repeat in azione


TCP: Panoramica RFC: 793, 1122, 1323, 2018, 2581

❒ Dati full-duplex:❍ flusso dati bi-direzionale

nella stessa connessione❍ MSS: maximum segment

size❒ connection-oriented:

❍ handshaking (scambio di messaggi di controllo)inizializzazione dello stato del mittente e del ricevitore prima dello scambio dati

❒ controllo di flusso:❍ il mittente non

sovraccaricherà il ricevente

❒ punto-punto:❍ 1 mittente, 1 ricevente

❒ Flusso di byte ordinato ed affidabile:

❒ pipelined:❍ Il controllo di flusso e di

congestione determinano una dimensione di finestra

❒ Buffer di spedizione e ricezione

socketdoor

TCPsend buffer

TCPreceive buffer

socketdoor

segment

applicationwrites data

applicationreads data


Struttura del segmento TCP


32 bits

applicationdata

(variable length)

sequence numberacknowledgement number

rcvr window sizeptr urgent datachecksum

FSRPAUheadlen

notused

Options (variable length)

URG: urgent data (in genere non usato)

ACK: numero ACKvalido

PSH: push data now(in genere non usato)

RST, SYN, FIN:inizio connessione

(comandi setup, teardown)

numero di bytesche il ricevente desidera accettare

contano in termini di byte di dati(non segmenti!)

Internetchecksum

(come in UDP)


Numeri di sequenza e ACK in TCPNumeri di sequenza:

❍ numero del primo byte di un segmento del flusso di byteACK:

❍ numero di sequenza del prossimo byte atteso dall’altra parte

❍ ACK cumulativoDomanda: come sono gestiti dal ricevente segmenti non in

ordine?❍ Risposta: la specifica di TCP non lo stabilisce – scelta

dell’implementazione


Numeri di sequenza e ACK in TCP

file di 500000 byteMSS di 1000 byte



Host A Host B

Seq=1000, ACK=79, data = ‘…’

Seq=79, ACK=2000, data = ‘…’

Spedizionesecondo segmento

l’host mandaun ACK per

confermare laricezione di del segmento

e comunica il # di sequenzadel prossimo byte atteso

tempo



Host A Host B

Seq=4000, ACK=79, data = ‘…’

Seq=79, ACK=2000, data = ‘…’

Spedizionequarto segmento

con perdita del terzol’host mandaun ACK per

il # di sequenzadel prossimo byte atteso

tempo


Numeri di sequenza e ACK in TCPHost A Host B

Seq=42, ACK=79, data = ‘C’

Seq=79, ACK=43, data = ‘C’

Seq=43, ACK=80

Utentedigita

‘C’

l’host manda un ACK per la ricezione

dell’ echo ‘C’

l’host mandaun ACK per

confermare laricezione di ‘C’, Manda indietroun “echo” per ‘C’

temposemplice scenario telnet


TCP: trasferimento dati affidabile

mittente semplificato assumendo che:

waitfor

eventattendievento

evento: dato ricevutodall’applicazione (livello superiore)

evento: timeout del timer per il segmento con

numero di sequenza y

evento: ACK ricevutocon numero di ACK y

crea e spedisci il segmento

ri-trasmetti il segmento

elaborazione dell’ACK

•trasferimento dati one way•senza controllo di flusso econgestione


TCP: trasferimento dati affidabile

00 sendbase = initial_sequence number 01 nextseqnum = initial_sequence number 0203 loop (forever) {04 switch(event)05 event: data received from application above 06 create TCP segment with sequence number nextseqnum 07 start timer for segment nextseqnum 08 pass segment to IP09 nextseqnum = nextseqnum + length(data) 10 event: timer timeout for segment with sequence number y 11 retransmit segment with sequence number y12 compute new timeout interval for segment y 13 restart timer for sequence number y 14 event: ACK received, with ACK field value of y 15 if (y > sendbase) { /* cumulative ACK of all data up to y */ 16 cancel all timers for segments with sequence numbers < y17 sendbase = y 18 } 19 else { /* a duplicate ACK for already ACKed segment */ 20 increment number of duplicate ACKs received for y 21 if (number of duplicate ACKS received for y == 3) { 22 /* TCP fast retransmit */23 resend segment with sequence number y 24 restart timer for segment y 25 } 26 } /* end of loop forever */

Mittente TCPsemplificato


Generazione di ACK in TCP [RFC 1122, 2581]

Evento

arrivo di un segmento in ordine,senza “buchi” nella sequenza,tutto il resto già con ACK

arrivo di un segmento in ordine,senza “buchi” nella sequenza, un ACK ritardato è pendente

arrivo di un segmento non in ordine,# di sequenza > di quello attesorilevazione di un “buco”

arrivo di un segmento cheparzialmente o completamenteriempie il buco

Azione del ricevente TCP

ACK ritardato. Attende fino a 500msil prossimo segmento. Se non c’è unprossimo segmento manda un ACK

spedisce immediatamente un soloACK cumulativo

spedisce un ACK duplicato che indica il #di sequenza del prossimo byte atteso

spedisce una ACK immediatamente se il segmento inizia al limite sinistro del “buco”


TCP: scenari di ri-trasmissioneHost A

Seq=92, 8 bytes data

ACK=100

perdita

tim

eout

tempo scenario per ACK perso

Host B

X


ACK=100

Host A


ACK=100

Seq=

92 t

imeo

uttempo timeout prematuro,

ACK cumulativi

Host B


ACK=120


Seq=

100

tim

eout

ACK=120


Controllo di flusso in TCPricevente: informa

esplicitamente il mittente dell’ammontare di spazio disponibile nel buffer (dinamicamente variabile)

❍ RcvWindow campo nelsegmento TCP

mittente: mantiene l’ammontare di dati trasmessi ancora senza ACK minore del valore più recentemente ricevuto di RcvWindow

il mittente non sovraccaricherà il

buffer del ricevente trasmettendo troppo troppo velocemente

controllo di flusso

buffer di ricezione

RcvBuffer = dimensione del buffer di ricezione TCPRcvWindow = ammontare di spazio disponibile nel buffer


Round Trip Time e Timeout in TCP

Domanda: come si determina il valore del timeout in TCP?

❒ più alto del RTT❍ nota: RTT è variabile

❒ troppo piccolo: timeout prematuro

❍ ritrasmissioni non necessarie

❒ troppo alto: reazione lenta alla perdita di segmenti

Domanda: come stimare il RTT?❒ SampleRTT: tempo misurato dalla

trasmissione del segmento fino alla ricezione dell’ACK

❍ si ignorano le ritrasmissioni, e segmenti con ACK cumulativi

❒ SampleRTT è variabile, vogliamo una stima migliore del RTT

❍ si usano diverse recenti misurazioni non solo il SampleRTT correntemente disponibile


Round Trip Time e Timeout in TCP

EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT

❒ Exponential weighted moving average❒ l’influenza di un campione decresce esponenzialmente❒ valori tipici di x: 0.1

Determinare il timeout❒ EstimtedRTT più “margine di sicurezza”❒ grandi variazioni di EstimatedRTT -> grande margine di sicurezza

Timeout = EstimatedRTT + 4*Deviation

Deviation = (1-x)*Deviation +x*|SampleRTT-EstimatedRTT|


Gestione della connessione in TCP

Ricordate: mittente e ricevente TCP stabiliscono una “connessione” prima dello scambio di segmenti di dati

❒ inizializzazione di variabili TCP:

❍ numeri di sequenza❍ buffer, informazioni per il

controllo di flusso (e.g.RcvWindow)

❒ client: iniziatore della connessioneSocket clientSocket = newSocket("hostname","port

number");

❒ server: contattato dal clientSocket connectionSocket =welcomeSocket.accept();

Three way handshake:

Passo 1: l’host del client spedisce un segmento di controllo TCP (SYN=1) al server

❍ specifica il # di sequenza iniziale direzione client -> server

Passo 2: l’host del server riceve il SYN, risponde con un segmento di controllo SYNACK

❍ è un ACK per il SYN❍ alloca i buffer❍ specifica il numero di sequenza

iniziale in direzione server->client

Passo 3: l’host del client riceve il SYNACK, risponde con un segmento di controllo con il campo SYN=0

❍ è un ACK per il SYN❍ alloca i buffer


Three way handshake: esempio



Chiusura della connessione:

il client chiude il socket:clientSocket.close();

Passo 1: l’host del clientspedisce un segmento di controllo FIN al server

Passo 2: il server riceve il FIN e risponde con un ACK. Chiude la connessione e spedisce un FIN.

client

FIN

server

ACK

ACK

FIN

chiusura

chiusura

chiusa

atte

sachiusa



Passo 3: il client riceve il FIN, risponde con un ACK.

❍ Entra in una “attesa” –risponderà con un ACK al FIN ricevuto

Step 4: il server, riceve l’ACK. Connessione chiusa.

client

FIN

server

ACK

ACK

FIN

chiusura

chiusura

chiusa

atte

sachiusa



ciclo di vita di un client TCP

ciclo di vita di un server TCP


Principi del controllo di congestione

Congestione:❒ informalmente: “troppe sorgenti spediscono troppi dati

troppo velocemente perché la rete possa gestirli”❒ diverso dal controllo di flusso!❒ manifestazioni:

❍ pacchetti persi (overflow dei buffer nei routers)❍ grandi ritardi (accodamento nei buffer dei routers)


Approcci per il controllo di congestione

Controllo della congestione End-end:

❒ nessun feedback esplicito dalla rete

❒ la congestione si inferisce dall’osservazione da parte degli host delle perdite e dei ritardi

❒ approccio di TCP

Controllo di congestione con l’aiuto della rete:

❒ i routers forniscono feedback agli host

❍ un bit che indicacongestione (SNA,DECbit, TCP/IP ECN, ATM)

❍ indicazione esplicita della velocità alla quale un mittente dovrebbe trasmettere

Due grandi approcci:


Controllo di congestion in TCP❒ controllo end-end (senza assistenza della rete)❒ velocità di trasmissione limitata dalla dimensione della

finestra di congestione sui segmenti, Congwin:

❒ w segmenti, ognuno di MSS bytes spediti in un RTT:

throughput = w * MSSRTT Bytes/sec

Congwin


Controllo di congestion in TCP

❒ due “fasi”❍ slow start❍ congestion avoidance

❒ variabili importanti:❍ Congwin

❍ threshold: definisce una soglia tra la fase di slow start e di congestion avoidance

❒ “sondaggio” della larghezza di banda usabile:

❍ idealmente: trasmettere il più velocemente possibile (Congwin il più grande possibile) senza perdite

❍ incrementare Congwinfino a quando si hanno perdite (congestione)

❍ perdite: decrementareCongwin, quindi iniziare a sondare (incrementare) ancora


TCP Slowstart

❒ incremento esponenziale(per RTT) della dimensione della finestra (non così slow!)

❒ evento di perdita: timeout (Tahoe TCP) e/o tre ACK duplicati (Reno TCP)

inizio: Congwin = 1for (each segment ACKed)

Congwin++until (loss event OR

CongWin > threshold)

Algoritmo di SlowstartHost A

1 segmento

RTT

Host B

tempo

2 segmenti

4 segmenti


TCP Congestion Avoidance

/* slowstart è terminato *//* Congwin > threshold */Until (loss event) {every w segments ACKed:

Congwin++}

threshold = Congwin/2Congwin = 1perform slowstart

Congestion avoidance


TCP FairnessObiettivo: se N connessioni

TCP condividono lo stesso canale “collo di bottiglia”ognuna dovrebbe ottenere 1/N della capacità del canale

TCP congestion avoidance:❒ AIMD: additive

increase, multiplicative decrease

❍ incremento della dimensione della finestra di 1 ogni RTT

❍ decremento della dimensione della finestra di un fattore 2 per un evento di perdita

AIMD

connessione TCP 1

router “collodi bottiglia” con

canale a capacità Rconnessione TCP 2


Parte 3: Sommario

❒ principi dietro i servizi del livello di trasporto:

❍ multiplexing/demultiplexing❍ trasferimento affidabile❍ controllo di flusso❍ controllo di congestione

❒ implementazione in Internet❍ UDP❍ TCP

Prossima puntata:❒ lasciamo la edge

network (livello application e transport)

❒ ci tuffiamo nella core network

DNS: Domain Name System - di.unito.itrossano/DIDATTICA/reti/lezione5-6-7.pdf · Semplice esempio...

Documents

Transcript of DNS: Domain Name System - di.unito.itrossano/DIDATTICA/reti/lezione5-6-7.pdf · Semplice esempio...