• Non ci sono risultati.

Lezione 5-6-7

N/A
N/A
Protected

Academic year: 2021

Condividi "Lezione 5-6-7"

Copied!
82
0
0

Testo completo

(1)

DNS: Domain Name System

People:

molti identificativi:

o # CF, nome, # passaporto

Host e router in Internet:

o indirizzo IP (32 bit) – usato

per indirizzare datagrams

o “nome”, e.g.,

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

Domanda:

corrispondenza

tra indirizzo IP e nome ?

Domain Name System:

‰ database distribuito

implementato con una gerarchia di name server

‰ protocollo di livello application

host, 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

(2)

Servizi offerti dal DNS

‰

Traduzione di indirizzi mnemonico -> IP

‰

Host aliasing

o indirizzi mnemonici “complicati” possono avere alias più

semplici

‰

Mail server aliasing

‰

Distribuzione 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

(3)

DNS name servers

‰ nessun 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 name server 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

Perché non centralizzare il

DNS?

‰

punto unico di guasto

‰

volume di traffico

‰

database centralizzato

distante

‰

mantenimento

(4)

DNS: Root name servers

‰ contattati dai name server locali che non sanno risolvere un nome ‰ root name server:

o contatta il name server autoritativo se la corrispondenza per il

nome non è conosciuta

o ottiene la corrispondenza

o restituisce la corrispondenza al name server locale

b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA e NASA Mt View, CA

f Internet Software C. PaloAlto, CA i NORDUnet Stockholm k RIPE London m WIDE Tokyo a NSI Herndon, VA c PSInet Herndon, VA

d U Maryland College Park, MD g DISA Vienna, VA

h ARL Aberdeen, MD

j NSI (TBD) Herndon, VA

13 root name

(5)

Semplice esempio DNS

l’ host

surf.eurecom.fr

vuole l’indirizzo IP di

gaia.cs.umass.edu

1. contatta il suo server DNS

locale,

dns.eurecom.fr

2. dns.eurecom.fr contatta

il root name server, se necessario

3. il root name server

contatta il name server

autoritativo, host richiedente gaia.cs.umass.edu

root name server

name server autorititivo

dns.umass.edu

local name server

dns.eurecom.fr 1 2 3 4 5 6

(6)

Esempio DNS

Root name server:

‰ può non conoscere il

name server autoritativo

‰ può conoscere un name

server intermedio : chi

contattare per trovare il name server

autoritativo

host richiedente

surf.eurecom.fr

gaia.cs.umass.edu

root name server

local name server

dns.eurecom.fr 1 2 3 4 5 6

name server autoritativo

dns.cs.umass.edu

name server intermedio

dns.umass.edu

7

(7)

DNS: query iterate

query ricorsive:

‰ scarica il peso della

risoluzione del nome sul name server

contattato

‰ carico pesante?

query iterate:

‰ il server contattato

risponde con il nome del server da

contattare

‰ “Non conosco questo

nome ma chiedi a surf.eurecom.frhost richiedente

root name server

local name server

dns.eurecom.fr 1 2 3 4 5 6

name server autoritativo

dns.cs.umass.edu

name server intermedio

dns.umass.edu

7

8

(8)

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 tempo

‰

meccanismo di aggiornamento/notifica sotto

progetto del IETF

o RFC 2136

(9)

DNS record

DNS: database distribuito che memorizza record di risorse, resource records (RR)

‰ Type=NS

o 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=A

o name è un hostname o value è un indirizzo IP

‰

Type=CNAME

o name è un alias di un nome

“canonico” (quello vero)

www.ibm.com

è in realtà

servereast.backup2.ibm.com o value è il nome canonico

(10)

DNS record

‰

Se un name server è autoritativo per un host allora

conterrà un record con Type=A per quell’host

‰

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

(11)

Protocollo DNS: i messaggi

Protocollo DNS : messaggi di query e reply, entrambi con lo stesso formato di messaggio

header del messaggio

‰ identificazione: # di 16

bit per le query, e il reply alla query usa lo stesso #

‰ flag:

o query o reply

o ricorsione desiderata o ricorsione disponibile o reply è autoritativo

(12)

Protocollo DNS: i messaggi

Nome, campi tipo per una query

RR in risposta ad una query record per server autoritativi informazioni “utili” aggiuntive che possono essere usate

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

(13)

Parte 2: sommario

‰ requisiti di servizio delle

applicazioni: o affidabilità, larghezza di banda, ritardo ‰ paradigma client-server ‰ Modelli 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 http o ftp o smtp, pop3 o dns ‰

programmazione con

socket

o implementazione di un client/server

(14)

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. dati

o in-based, out-of-band

‰ centralizzato vs. decentralizzato ‰ stateless vs. con stato

‰ trasferimento di messaggi

affidabile vs. non affidabile

‰ “complessità ai bordi della rete” ‰ sicurezza: auetenticazione

(15)

Parte 3: livello transport

Obiettivi:

❒ comprendere i principi

alla base dei servizi a livello di trasporto: ❍ multiplexing/demultiplex ing ❍ 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

(16)

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 vs

servizi di livello network:

❒ livello network: trsferimento

dati tra host (end-system)

❒ livello trasporto:

trasferimento dati tra processi

❍ si affida ai sevizi di livello

network application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical trasporto end -to -end log ico

(17)

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

application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical trasporto end -to -end log ico

(18)

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

(19)

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)

(20)

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

(21)

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 (e

gateway)

Il servizio postale non conosce il contenuto delle

lettere o distingue tra tipi di mittente o

destinatario

Analogamente, i router della core network non

(22)

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 Transport

offerti 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

(23)

application transport network M P2 application transport network

Multiplexing/demultiplexing

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

❍ alias TPDU: transport

protocol data unit

ricevente

Ht Hn

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

segmento

segmento M applicationtransport

network P1 M M M P3 P4 header segmento

dati del livello application

(24)

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,

raccolta dei messaggi da diversi processi del livello application, aggiunta di un header

ai dati (usato successivamente per il demultiplexing)

source port # dest port #

32 bits

dati

applicazione (messaggio)

altri campi dell’ header

formato del segmento TCP/UDP

(25)

Multiplexing/demultiplexing: esempi

host A source port: xdest. port: 23 server B

source port:23 dest. port: x

uso della porta: applicazione telnet

client Web host A Web server B client Web host C Source IP: C Dest IP: B source port: x dest. port: 80 Source IP: C Dest IP: B source port: y dest. port: 80 Source IP: A Dest IP: B source port: x dest. port: 80

(26)

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

(27)

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!

source port # dest port # 32 bits Dati applicazione (messaggio) lunghezza checksum Lunghezza, in bytes del segmento UDP, incluso l’header

(28)

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 campo checksum 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

(29)

Principi del trasferimento dati affidabile

❒ importante nel livello applicazione, trasporto e data link ❒ importante argomento di networking!

(30)

Trasferimento dati affidabile

: gli inizi

lato

mittente

ricevente

lato

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

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

(31)

Trasferimento dati affidabile

: gli inizi

Cosa 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

stato

1 stato2

evento che causa una transizione di stato

azioni effettuate in seguito a transizione di stato stato: quando ci si trova

in questo “stato” il

(32)

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

(33)

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

(34)

rdt2.0: specifica dei FSM

FSM del mittente

FSM del ricevente

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

(35)
(36)

rdt2.0: in azione (scenario con errori)

(37)

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?

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

(38)
(39)

rdt2.1: ricevente, gestisce ACK/NAK

distorti

(40)

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

(41)

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

FSM del

mittente

(42)

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

(43)
(44)
(45)
(46)

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 = durante la quale il frazione di tempo = 8 microsec30.016 msec 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!

(47)

Protocolli Pipelined

Pipelining:

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

(48)

go-Back-Go-Back-N

Mittente:

❒ 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

(49)
(50)

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

(51)

GBN in

azione

(52)

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

(53)
(54)

Selective repeat

data dal livello superiore:

❒ se il prossimo numero di

sequenza disponibile è nella finestra spedisce il

pacchetto

timeout(n):

❒ spedisce il pacchetto,

ri-inizializza il timer

ACK(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

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

(55)
(56)

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

socket door socket application

(57)

Struttura del segmento TCP

source port # dest port #

32 bits application data (variable length) sequence number acknowledgement number rcvr window size ptr urgent data checksum F S R P A U head

len usednot

Options (variable length)

URG: urgent data (in genere non usato) ACK: numero ACK

valido PSH: push data now (in genere non usato) RST, SYN, FIN: inizio connessione (comandi setup, teardown) numero di bytes che il ricevente desidera accettare contano in termini di byte di dati (non segmenti!) Internet checksum

(58)

Numeri di sequenza e ACK in TCP

Numeri di sequenza:

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

ACK:

❍ numero di sequenza del prossimo byte atteso dall’altra

parte

❍ ACK cumulativo

Domanda: come sono gestiti dal ricevente segmenti non in ordine?

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

(59)

Numeri di sequenza e ACK in TCP

file di 500000 byte

MSS di 1000 byte

(60)

Numeri di sequenza e ACK in TCP

Host A Host B Seq=1000,ACK=7 9, data = ‘…’ Seq=79, ACK=2 000, data = ‘…’ Spedizione secondo segmento l’host manda un ACK per confermare la

ricezione di del segmento e comunica il # di sequenza

del prossimo byte atteso

(61)

Numeri di sequenza e ACK in TCP

Host A Host B Seq=4000,ACK=7 9, data = ‘…’ Seq=79, ACK=2 000, data = ‘…’ Spedizione quarto segmento con perdita del terzo

l’host manda un ACK per il # di sequenza

(62)

Numeri di sequenza e ACK in TCP

Host A Host B Seq=42, A CK=79, data = ‘C’ Seq=79, ACK=43 , data = ‘C’ Seq=43, ACK=80 Utente digita ‘C’ l’host manda un ACK per la ricezione

dell’ echo ‘C’ l’host manda un ACK per confermare la ricezione di ‘C’, Manda indietro un “echo” per ‘C’ tempo

(63)

TCP: trasferimento dati affidabile

mittente semplificato

assumendo che:

wait for event attendi evento

evento: dato ricevuto

dall’applicazione (livello superiore)

evento: timeout del timer per il segmento con numero di sequenza y

evento: ACK ricevuto con numero di ACK y crea e spedisci il segmento

ri-trasmetti il segmento

•trasferimento dati one way •senza controllo di flusso e congestione

(64)

TCP:

trasferimento

dati affidabile

00 sendbase = initial_sequence number 01 nextseqnum = initial_sequence number 02

03 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 IP

09 nextseqnum = nextseqnum + length(data)

10 event: timer timeout for segment with sequence number y 11 retransmit segment with sequence number y

12 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 < y 17 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 }

Mittente TCP semplificato

(65)

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 atteso

rilevazione di un “buco”

Azione del ricevente TCP

ACK ritardato. Attende fino a 500ms il prossimo segmento. Se non c’è un prossimo segmento manda un ACK spedisce immediatamente un solo ACK cumulativo

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

(66)

TCP: scenari di ri-trasmissione

Host A

Seq=92, 8 bytes data

ACK=100

perdita

timeout

tempo scenario per ACK perso

Host B

X

Seq=92, 8 bytes data

ACK=100 Host A Seq=100, 20 bytes da ta ACK=100 Seq=92 t imeout

tempo timeout prematuro,

ACK cumulativi Host B

Seq=92, 8 bytes data

ACK=120

Seq=92, 8 bytes data

Seq=100 t

imeout

(67)

Controllo di flusso in TCP

ricevente: informa

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

RcvWindow campo nel

segmento 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

RcvBuffer= dimensione del buffer di ricezione TCP RcvWindow = ammontare di spazio disponibile nel buffer

(68)

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

(69)

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

(70)

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

connessione

Socket clientSocket = new Socket("hostname","port number");

❒ server: contattato dal client

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

(71)
(72)

Gestione della connessione in TCP

Chiusura della connessione:

il client chiude il socket:

clientSocket.close();

Passo 1:

l’host del client

spedisce 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 attesa chiusa

(73)

Gestione della connessione in TCP

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 attesa chiusa

(74)

Gestione della connessione in TCP

ciclo di vita di un client TCP

ciclo di vita di un server TCP

(75)

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)

(76)

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 indica

congestione (SNA, DECbit, TCP/IP ECN, ATM)

❍ indicazione esplicita

della velocità alla quale un mittente dovrebbe trasmettere

(77)

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 * MSS Bytes/sec

(78)

Controllo di congestion in TCP

due “fasi”

❍ slow start ❍ congestion avoidance ❒

variabili importanti:

Congwinthreshold: 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 Congwin

fino a quando si hanno perdite (congestione)

❍ perdite: decrementare

Congwin, quindi iniziare

a sondare

(79)

TCP Slowstart

❒ incremento esponenziale

(per RTT) della dimensione della finestra (non così

slow!)

inizio: Congwin = 1

for (each segment ACKed)

Congwin++

until (loss event OR

CongWin > threshold)

Algoritmo di Slowstart

Host A

1 segmento RTT Host B tempo 2 segmenti 4 segmenti

(80)

TCP Congestion Avoidance

/* slowstart è terminato */

/* Congwin > threshold */

Until (loss event) {

every w segments ACKed:

Congwin++

}

threshold = Congwin/2

Congwin = 1

perform slowstart

Congestion avoidance

(81)

TCP Fairness

Obiettivo: 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 “collo

(82)

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

Riferimenti

Documenti correlati

Come già detto, nella pila TCP/IP esistono due protocolli di trasporto, TCP e UDP, che offrono diversi tipi di servizio, quindi ciascuno di essi è più adatto a particolari tipi

elettriche: scambiare elettricità (dati) tra due o più entità diverse che hanno tecnologie differenti, ma con un protocollo comune.. e Reti - Socket 3 di 11

Il tipo di comunicazione specifica come deve avvenire la comunicazione, ovvero se si debbano usare i datagram o se si vuole una connessione di qualità, o ancora se si

Esempio indirizzi : Vediamo alcuni esempi di

• Modificare il codice del Sender in modo che esso usi due sockets diversi per inviare lo stesso messaggio a due diversi receivers. Mandare in esecuzione prima i

  produce un valore uguale a 0 se la stringa non è un indirizzo IP nel formato corretto (&gt;0 se la conversione avviene con successo).  

 l’astrazione di comunicazione interprocesso fornita dai socket consiste nella possibilità di inviare un messaggio tramite un socket di un processo e ricevere il messaggio tramite

■ Il client effettua la richiesta di una connessione ad un server per un servizio collegato ad una determinata porta. ■ Se la richiesta è accettata la connessione tra i due