DNS: Domain Name System
People:
molti identificativi:
o # CF, nome, # passaportoHost 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
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
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
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
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
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
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
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 2136DNS 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
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)
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
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)
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/serverParte 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
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
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
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
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
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 (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
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
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
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
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
UDP: User Datagram Protocol
[RFC 768]
❒ protocollo di livello trasportoin 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 unaconnessione (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!
source port # dest port # 32 bits Dati applicazione (messaggio) lunghezza checksum Lunghezza, in bytes 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 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
Principi del trasferimento dati affidabile
❒ importante nel livello applicazione, trasporto e data link ❒ importante argomento di networking!
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
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
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):
rdt2.0: specifica dei FSM
FSM del mittente
FSM del ricevente
Il mittente spedisce un pacchetto, ed attende una risposta del ricevente
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?
Gestione dei duplicati:
❒ il mittente aggiunge unnumero 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: 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
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
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
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!
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
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
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
GBN in
azione
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
Selective repeat
data dal livello superiore:
❒ se il prossimo numero disequenza 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 pacchettoricevente
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 applicationStruttura 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
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
Numeri di sequenza e ACK in TCP
file di 500000 byte
MSS di 1000 byte
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 laricezione di del segmento e comunica il # di sequenza
del prossimo byte atteso
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 terzol’host manda un ACK per il # di sequenza
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 ricezionedell’ echo ‘C’ l’host manda un ACK per confermare la ricezione di ‘C’, Manda indietro un “echo” per ‘C’ tempo
TCP: trasferimento dati affidabile
mittente semplificato
assumendo che:
wait for event attendi eventoevento: 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
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
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
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
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
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
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
Gestione della connessione in TCP
Ricordate:
mittente ericevente 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
Gestione della connessione in TCP
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 attesa chiusaGestione 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, ricevel’ACK. Connessione chiusa.
client FIN server ACK ACK FIN chiusura chiusura attesa chiusa
Gestione della connessione in TCP
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)
Approcci per il controllo di congestione
Controllo della
congestione End-end:
❒ nessun feedback esplicitodalla 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 fornisconofeedback agli host
❍ un bit che indica
congestione (SNA, DECbit, TCP/IP ECN, ATM)
❍ indicazione esplicita
della velocità alla quale un mittente dovrebbe trasmettere
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
Controllo di congestion in TCP
❒due “fasi”
❍ slow start ❍ congestion avoidance ❒variabili importanti:
❍ Congwin ❍ threshold: definisceuna soglia tra la fase di slow start e di congestion avoidance ❒
“
sondaggio”
della
larghezza di banda
usabile:
❍ idealmente: trasmettere il più velocementepossibile (Congwin il più grande possibile) senza perdite
❍ incrementare Congwin
fino a quando si hanno perdite (congestione)
❍ perdite: decrementare
Congwin, quindi iniziare
a sondare
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 A1 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/2
Congwin = 1
perform slowstart
Congestion avoidance
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 “colloParte 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