Alma Mater Studiorum - Universita' di Bologna
Sede di Cesena
Reti di Calcolatori
Il Layer di Trasporto - COTS
Vedi:
• A.S. Tanenbaum, Computer Networks, 4th ed., Prentice Hall,
sez. 6, pagg. 481-574.
• M.T. Rose, The open book, Prentice Hall, cap. 3 e 5, pagg. 3549 e 85-120.
• D. Comer, Internetworking con TCP/IP - Principi, protocolli e
architetture, vol. 1, Addison-Wesley, 4a ed., cap. 13, pagg. 219261.
Copyright © 2006-2014 by Claudio Salati.
Lez. 3
1
Il Layer di Trasporto
Tanenbaum:
• The Transport Layer is not just another layer.
• It is the heart of the whole protocol hierarchy.
• Its task is to provide reliable (N.B.: in realta' esiste anche un
CLTS), cost effective data transport from the source machine to
the destination machine (N.B.: in realta' “from the source to the
destination module of a distributed application”), independently of
the physical network or networks currently in use.
• To provide this goal, the Transport Layer makes use of the
services provided by the Network Layer.
• Just as there are 2 types of Network Service, CONS and CLTS,
there are also 2 types of Transport Service.
• COTS is similar to CONS in many ways.
Furthermore CLTS is also very similar to CLNS.
• If the TS is so similar to the NS why are there 2 distinct layers?
Why is one layer not adequate?
2
OSI Reference Model
Transport
Transport
3
Layer di Rete e di Trasporto
• "End-to-end services (Network & Transport Layer) are concerned with data
transfer, thus with moving octets (8-bit values) form an ES to another (N.B.:
in realta' NS e TS hanno funzioni diverse). The syntax and semantics of
those octets are unimportant: bits are bits.
 N.B.: questo significa che stiamo assumendo che i byte siano fatti
nello stesso modo ovunque!
• It is difficult to separate the functionality of the 2 key layers involved in
providing end-to-end (data transfer) services. In realta:
•
NS is concerned with moving octets from an ES to another.
•
TS is concerned with moving octets from a module to another of a
distributed application.
• This is because of the unfortunate history of the OSI end-to-end services:
there have been 2 technopolitical camps with very different views of the
lower-layer infrastructure.“ (Rose)
• Lo scontro deriva dal fatto che in OSI sia il Transport che il Network Layer
possono fornire sia un servizio CO che un servizio CL.
• Ovviamente il protocollo per fornire il servizio di Trasporto CO e' molto
diverso se si usa CONS o CLNS:
 OSI prevede 5 (cinque) diversi protocolli di trasporto CO!
4
Layer di Rete
 "NS is responsible for moving data from one ES to another, hiding
the technology of the subnetworks that must be traversed.
 The primary goal of the NS is to provide transparency in 2 forms:
 transparency over the topology of the network; and,
 transparency over the transmission media used in each
subnetwork that comprises the network." (Rose)
 N.B.: ma prestazioni e affidabilita' del NS cambiano molto a
seconda che esso sia fornito da una LAN o da una internet
geografica!
 NL implica 2 funzioni fondamentali:
 routing: in base all'indirizzo destinazione decidere lungo quale
percorso instradare la comunicazione perche' essa possa
giungere a buon fine;
 switching: commutare i messaggi della comunicazione
secondo il percorso deciso dalla funzione di routing.
5
I DUE APPROCCI AI SERVIZI END-TO-END
• Il partito CONS:
• Il Network Layer fornisce il CONS,
• Il Transport Layer, per fornire il COTS, si fida del CONS, e si limita a
gestire TSAP e connessioni di Rete.
• "An ES is little more than a spectator with regard to use of the protocols
that make up the end-to-end data transfer services.
• "If the underlying NS is also CO, then the Transport protocol supporting
COTS can be trivial." (Rose)
• Il partito CLNS:
• Il Network Layer fornisce il CLNS,
• Il Transport Layer, per fornire il COTS, deve gestire in proprio il recupero
degli errori e la sequenzializzazione dei messaggi, poiche' il CLNS non
fornisce alcuna garanzia.
• "An ES is the most important player, as it has the final responsibility for
robust communication.
• "Use of CLNS requires sophisticated algorithms in the Transport
protocols that provide COTS." (Rose)
•
Nel mondo Internet c'e' solo il partito CLNS.
6
Layer di Rete e di Trasporto
• In teoria una NSDU e una TSDU possono essere di lunghezza
arbitraria, ma in pratica sono di lunghezza finita e la lunghezza
della NSDU e' spesso piu' piccola di quella della TSDU, per cui
il livello di Trasporto deve comunque gestire segmentazione e
riassemblaggio delle TSDU.
• "TP0 does nothing more than Transport addressing (ma questa
e’ una funzione fondamentale!) and segmentation." (Rose)
• Esistono comunque due distinzioni fondamentali tra NS e TS:
1. NS si occupa della comunicazione tra processori (nodi della
rete), mentre
TS si occupa della comunicazione tra processi (programmi,
applicazioni).
2. "The Transport code runs entirely on the users' machines
(ES), but the Network Layer mostly runs on the routers (IS),
which are operated by the carrier." (Tanenbaum)
7
Layer di Rete e di Trasporto
Tanenbaum, argomento 1:
• "What happens if the Network Layer offers inadequate service?
• The users have no real control over the Network Layer.
• The only possibility is to put on top of the Network Layer another layer
(allocato sugli ES! Quindi sotto il controllo degli utenti della rete!) that
improves the quality of the service.
• In essence, the existence of the Transport Layer makes it possible for
the TS to be more reliable than the underlying NS."
Tanenbaum, argomento 2:
• "Thanks to the Transport Layer, application programmers can write
code according to a standard of service primitives and have these
programs work on a wide variety of networks, without having to worry
about dealing with different subnetwork interfaces (qualita' eterogenea
del NS, vedi ad es. Reti OSI di classe A e B).
• For this reason, many people have traditionally made a distinction
between layers 1 through 4 on the one hand and layers above 4 on 8the
other."
Layer di Rete e di Trasporto
• "The bottom 4 layers can be seen as the Transport Service provider
(lower network infrastructure), whereas the upper layers are the
Transport Service user (upper network infrastructure).
• This distinction of provider vs. user puts the Transport Layer in a key
position, since it forms the major boundary between the provider and
user of the reliable transmission service." (Tanenbaum)
• Per rendere la distinzione veramente efficace occorrerebbe che l'API
del TS fosse standardizzata:
 In questo modo i programmi utente sarebbero portabili su diversi
ES.
• Implementativamente,
•
i livelli 2-4 sono realizzati (normalmente) come parte del sistema
(in spazio kernel),
•
i livelli superiori (5-7) sono realizzati (normalmente) nello spazio
utente (o come processi autonomi o, molto piu’ frequentemente,
9
come librerie linkate al codice utente).
OSI TRANSPORT LAYER E TRANSPORT SERVICE
 OSI prevede sia un COTS (Connection-Oriented Transport
Service) che un CLTS (ConnectionLess Transport Service).
 Il TS viene offerto su TSAP (Transport Service Access Point).
 Un TSAP e' identificato da un indirizzo a 2 componenti:

un transport selector (TSEL),
che e' un nome che ha significato locale e serve a distinguere
un TSAP locale dall'altro (e quindi un cliente del TS dall'altro) a
parita' di NSAP (e, quindi, di protocollo di trasporto),

uno o piu' network address (NSAP, quello/i della protocol
entity di Trasporto).
 COTS prevede le primitive (i servizi) per gestire le tre fasi di

instaurazione della connessione,

trasferimento dati,

rilascio della connessione.
10
PROTOCOLLI OSI DI TRASPORTO
•
COTS fornisce un servizio affidabile end-to-end
indipendentemente dal NS che ha a disposizione.
•
Data la variabilita' di caratteristiche del NS, per fornire la stessa
interfaccia COTS sono stati definiti 5 diversi CO Transport
Protocols (TP): TP0, ..., TP4.
• TP0, TP1, TP2 e TP3 possono operare solo sul CONS.
• TP4 puo' operare sia su CONS che su CLNS, ma in realta' e'
pensato per operare su CLNS.
•
Durante la fase di instaurazione della connessione le entita' di
Trasporto negoziano quale TP utilizzare.
•
Questo consente ad implementazioni sofisticate di offrire servizi
di qualita' superiore pur mantenendo la compatibilita' con
implementazioni piu' povere.
11
Classi di reti secondo OSI
•
Perche' sono definiti 4 TP diversi per operare su CONS?
•
Perche' le implementazioni reali di CONS differiscono per qualita'.
•
OSI definisce 3 classi di reti.
•
Reti di classe A: rilevano come un errore qualsiasi perdita di dati.
Non duplicano, desequenzializzano, o corrompono dati.
La probabilita' di errore effettiva e' bassa.
Una rete di classe A fornisce il CONS con qualita' accettabile.
•
Reti di classe B: differiscono dalle reti di classe A perche' la
probabilita' di perdita effettiva e' piu' alta di quanto (localmente)
considerato tollerabile (e.g. a causa della fragilita' delle connessioni).
Anche una rete di classe B fornisce il CONS, ma non con un livello di
qualita' accettabile.
•
Reti di classe C: forniscono il CLNS e quindi non offrono alcuna
garanzia di non perdere, duplicare o desequenzializzare dati.
•
I TP OSI CO si differenziano per la capacita' di operare su reti di
classi diverse, e per le modalita' con cui utilizzano il NS.
12
Classi di reti secondo IP?
•
Il protocol layer IP prevede solo un servizio CL.
•
L’architettura di rete internet prevede che il Network Layer debba
fornire solo un servizio CL, considera cioe’ solo reti di classe C.
•
Anche alle singole sottoreti l’architettura internet richiede solo di
fornire un servizio CL, di classe C.
•
Se una sottorete e’ capace di fornire anche un servizio CO, questo
•
non viene utilizzato da IP, se e’ disponibile anche un servizio CL.
•
e’ sottoutilizzato da IP, se il servizio CO e’ l’unico fornito dalla
sottorete.
•
IP in realta’ fa anche fatica ad utilizzare sottoreti CO perche’ deve
assorbire la complessita’ aggiuntiva della gestione di connessioni
senza poterne sfruttare i vantaggi.
13
PROTOCOLLI OSI DI TRASPORTO: TP0
 TP0:
 Puo' operare solo su reti di classe A.
 Fornisce solo le funzioni di segmentazione e riassemblaggio.
(oltre che, ovviamente, quella di addressing, cioe' la capacita'
di distinguere un TSAP dall'altro e una connessione
dall'altra)
 Ogni connessione di Trasporto e' associata ad una
connessione di Rete.
(non c'e' alcun multiplexamento di diverse connessioni di
Trasporto tra i due ES su un'unica connessione di Rete)
14
PROTOCOLLI OSI DI TRASPORTO: TP1

TP1:
 Puo' operare su reti di classe A e B.
 In caso di disconnessione spontanea di Rete, non deve
necessariamente abortire la connessione di Trasporto, ma
e' in grado di recuperare l'errore
(quale tipo di errore? Perdita! Si assume che NS sia
adeguato dal punto di vista di non-desequenzializzazione e
non-duplicazione).

"When TPDU are sent, each TPDU is numbered and then
retained until an ack is received from the remote Transport
entity. The ack takes the form of a special TPDU.

When a Network disconnect occurs, the Transport provider may
decide to establish a new Network connection and then resume
the Transport connection by resending those PDUs that haven't
been acknowledged.“ (Rose)
15
PROTOCOLLI OSI DI TRASPORTO: TP2 e TP3

TP2:
 E' l'equivalente di TP0 ma
 Effettua il multiplexing delle connessioni di Trasporto tra
due nodi su una unica connessione di Rete.
 Perche' e' conveniente il multiplexing?
Perche' pago una sola connessione di Rete anche se sto
utilizzando diverse connessioni di Trasporto su di essa.

TP3:
 E' la combinazione di TP2 e TP1.
 Combina la funzione di de/multiplexing con quella di
recupero di errori per disconnessione del Network Service.
16
PROTOCOLLI OSI DI TRASPORTO: TP4
 TP4:
 E' in grado di operare su reti di classe C.
 E' l'analogo OSI di TCP.
 In pratica e' poco adatto ad operare su reti CONS.
 Offre servizi di error detection (opzionalmente) e recovery.
 "TP4 achieves reliability through retransmission.
 The trick is knowing when to retransmit.
 If data is lost in the network and the sending Transport entity
retransmits too slowly, then throughput suffers.
 If data is lost due to congestion in the network and the Transport
entity retransmits too quickly then it merely adds to the
congestion and throughput gets even worse!
 Hence, sophisticated protocols of this variety employ adaptive
algorithms to predict the latency characteristics of the network, which
may fluctuate considerably because of other traffic." (Rose)
17
PROTOCOLLI Internet DI TRASPORTO: TCP
 E' l'equivalente Internet del protocollo OSI TP4.
 E' progettato per offrire un COTS affidabile basandosi sui servizi di
un Layer di Rete CL e non affidabile (IP).
 Il servizio implementato da TCP si differenzia dal COTS OSI per
alcuni punti fondamentali
(per il resto e' analogo al COTS OSI definito nella lezione 1).
 Adesso:
 Esistono anche altri protocolli di trasporto CO nell’architettura di
rete Internet (e.g. per gestire reti piu’ veloci che per essere
utilizzate in modo efficiente richiedono finestre di trasmissione
piu’ grandi).
 Esistono varianti del TCP (e.g. per gestire ACK selettivi).
ma il corso prende in considerazione solo il TCP tradizionale.
18
TCP vs. TP4 OSI
.1
Differenze tra TCP e TP4 OSI:
 I dati trasferiti tra i due end-point TCP sono costituiti da uno stream
continuo di byte anziche’ da una sequenza di messaggi, come e' nel
caso di COTS OSI.
 TCP (sia lato TX che lato RX) e' libero di segmentare/aggregare le
richieste di trasmissione dei byte dello stream come piu' gli conviene.
 E se due moduli di una applicazione distribuita hanno bisogno di
comunicare a messaggi?
Come fa un ricevitore a capire dove finisce un messaggio e dove
inizia l’altro?
 In caso di tentativo simultaneo di setup della connessione da parte dei
due ES le due richieste sono matchate da TCP ed e' creata un'unica
connessione.
 Puro buon senso, quello che manca ai comitati di standardizzazione.
 In pratica, in un mondo client-server asimmetrico, il problema e’
irrilevante, tanto che lo scenario non e’ nemmeno realizzabile
facilmente sull’interfaccia socket.
19
TCP vs. TP4 OSI
.2
Differenze tra TCP e TP4 OSI:
 La procedura di disconnessione e' "ordinata" e bilaterale, anziche'
essere brusca e unilaterale, come e' nel caso di COTS OSI.
 E' responsabilita' dei clienti del COTS OSI assicurarsi che tutti i dati
di cui e' stata chiesta la trasmissione siano stati effettivamente
ricevuti prima di chiedere la chiusura della connessione.
 Puro buon senso, quello che manca ai comitati di
standardizzazione.
 Di norma, la connessione non viene monitorata (testata) quando i clienti
non la utilizzano effettivamente (quando non richiedono la trasmissione
di dati).
 La protocol entity si accorge che la connessione e’ caduta solo
a seguito di un tentativo di trasmissione.
 Questo comportamento deriva dal fatto che TCP e’ stato progettato
quando i bit trasmessi in rete erano preziosi!
 Differenza interna: una connessione TCP e’ identificata solo dagli
indirizzi delle porte ai suoi estremi, mentre in TP4 una connessione ha
un suo identificatore specifico. Conseguenze?
20
Recupero degli errori: PDU persi o corrotti
 La tecnica fondamentale per il recupero degli errori di trasmissione e'
indicata come
conferma di ricezione positiva con ritrasmissione
(positive acknowledgement with retransmission)
 Il lato ricevente deve comunicare al lato mittente l'avvenuta
ricezione di dati tramite un PDU di ACKnowledgement.
 Il lato mittente, quando spedisce un PDU informativo, avvia un
timer.
 Se il timer scade prima che il mittente riceva l'ACK al proprio PDU
informativo, il mittente ritrasmette il PDU
(il mittente assume che il PDU sia andato perso o danneggiato).
 Se il lato ricevente riceve un PDU danneggiato, lo ignora
(lo scarta, di solito in un Layer piu’ basso del Trasporto).
 Se il lato ricevente riceve un PDU che aveva gia' ricevuto, lo
scarta ma lo riscontra al mittente.
 N.B.: la procedura di recupero degli errori in caso di PDU persi o
corrotti puo' portare alla ricezione ripetuta di uno stesso PDU.
21
Recupero degli errori: PDU duplicati
 In realta' non c'e' solo il problema dei PDU (anche quelli di ACK)
persi o corrotti.
 I PDU possono essere ritardati dalla rete (la rete "ha memoria").
 I PDU (compresi quelli di ACK) possono anche essere duplicati
(e.g. causa ritrasmissione da parte del mittente, o perche' il routing di
una sottorete e' basato sul flooding).
 PDU informativi duplicati possono (devono poter) essere riconosciuti.
 I PDU informativi devono essere identificati univocamente
(e.g. numerando ciascuno di essi con un numero progressivo).
 Il lato ricevente deve ricordare quali PDU informativi ha gia'
ricevuto.
 Se il lato ricevente riceve un PDU informativo che aveva gia'
ricevuto, lo riscontra al mittente ma lo scarta.
 Ogni PDU di ACK riporta esplicitamente il numero del/i PDU
informativo/i che riscontra.
22
Finestra a scorrimento: efficienza di banda
 Un protocollo con conferma di ricezione positiva semplicistico spreca
una quantita' enorme di banda disponibile perche' utilizza la rete in
modo half-duplex.
 Il lato trasmissione non trasmette il prossimo PDU informativo fino
a che non ha ricevuto l'ACK del PDU precedente.
 Il trasmettitore puo' pero' essere autorizzato a trasmettere un certo
numero di PDU informativi anche senza avere ricevuto un ACK (prima
di doversi fermare in attesa dell'ACK).
 Il lato trasmissione ha una certa finestra di credito di
trasmissione.
 Quando il trasmettitore riceve un ACK fa scorrere in avanti la sua
finestra di credito (non e’ proprio esatto: vedi seguito).
 "Poiche' un protocollo a finestra di scorrimento ben ottimizzato
mantiene la rete completamente satura di pacchetti (se il trasmettitore
e' piu' veloce della rete!), ottiene una velocita' di trasferimento
sostanzialmente maggiore rispetto ad un semplice protocollo con
conferma di ricezione positiva." (Comer)
23
Finestra a scorrimento: efficienza di banda
 Nel caso del TCP la nozione di finestra di scorrimento e' piuttosto
sofisticata (anche se TCP non utilizza ACK selettivi, vedi seguito).
 Il lato mittente:
 Ricorda quali sono i PDU informativi confermati.
 Mantiene un timer separato per ogni PDU non confermato.
 Quando fa scorrere la finestra in avanti oltrepassa tutti i PDU
informativi confermati (ack cumulativo).
 Il lato ricevente:
 Mantiene una lista dei PDU informativi ricevuti.
 Accetta e memorizza un PDU informativo corretto anche se uno o
piu' PDU precedenti non sono stati ancora ricevuti, ma non lo
riscontra.
 Puo' riscontrare piu' di un PDU informativo in un unico colpo se
riceve un PDU che precede logicamente (ed e’ adiacente ad) un
24
PDU gia' prima ricevuto.
ACK e ritrasmissioni
 Il ricevente assembla i byte dati dei segmenti ricevuti per ricostruire lo
stream trasmesso dal suo pari.
 Poiche' i datagram che contengono i segmenti possono andare persi
o essere ricevuti fuori ordine la ricostruzione dello stream avviene
grazie al numero di sequenza.
 In un qualunque momento il ricevente
 ha ricevuto un prefisso contiguo massimo dello stream;
 puo' avere ricevuto altri blocchi di byte, successivi al prefisso
contiguo massimo, ma non adiacenti ad esso.
 Il ricevente conferma sempre (solo) la ricezione del prefisso contiguo
massimo a quell'istante (ack cumulativo).
 Blocchi ricevuti correttamente ma che non non estendono il prefisso
contiguo massimo sono memorizzati ma non sono riscontrati.
 La conferma avviene indicando come ACK l'indice nello stream del
byte successivo all'ultimo byte del prefisso contiguo massimo (cioe'25
l'indice del primo byte mancante).
ACK cumulativo vs. ACK selettivo

TCP utilizza un metodo di riscontro cumulativo.

TCP non ammette ACK selettivi, cioe' ACK relativi a byte successivi
ma non contigui al prefisso contiguo massimo.

Supponiamo che il mittente invii 10 segmenti e che il primo (solo il
primo) vada perso.
 Quanti byte puo' riscontrare positivamente il ricevente? 0.
 Quanti segmenti deve ritrasmettere di conseguenza il mittente?
 Notare che dopo avere ricevuto il primo segmento ritrasmesso, il
ricevente riscontrera' il prefisso fino all'ultimo byte del decimo
segmento.
 Se il mittente ritrasmettesse piu' di un segmento occuperebbe
inutilmente la rete.

In base a questo argomento la prassi implementativa accettata indica
che in caso di ritrasmissione il mittente deve ritrasmettere solo il
segmento non riscontrato, quello per cui e’ scaduto il timer.
26
Finestra a scorrimento: controllo di flusso .1

L'utilizzo di un protocollo a finestra di scorrimento consente al TCP di
risolvere anche un altro problema:
 Cosa succede se il lato ricevente e' meno veloce della rete e del
lato mittente?
 Se la finestra del mittente e' abbastanza ampia il lato ricevente
viene sovraccaricato di PDU che non riesce a processare!
TCP
sender side
TCP
receiver side
send
send
send
send
send
ack
receive
ack
ack
ack
ack
receive
27
Finestra a scorrimento: controllo di flusso .2

TCP consente al lato ricevente di controllare la dimensione della
finestra del lato mittente, fino a chiuderla nel caso non abbia (buffer
di) memoria sufficiente per ricevere e registrare nuovi PDU
informativi.

La dimensione della finestra di scorrimento non e' quindi fissa, ma
puo' variare per adattarsi alla velocita' di processamento dei due ES.

Ovviamente il lato ricevente non e' autorizzato a contraddire aperture
di finestra effettuate in precedenza.

Dire che ti concedo una finestra di n messaggi vuole dire che ho la
capacita’ di bufferare gli n messaggi che ti autorizzo a inviarmi.

Non posso concederti una finestra di n messaggi se non ho buffer
di memoria sufficienti a contenerli.
 N.B.: ACK dei PDU e gestione della finestra devono poter essere
disaccoppiati: il ricevitore deve potere anche riscontrare la ricezione
di un PDU senza aprire la finestra del mittente (e viceversa).
28
Finestra a scorrimento: controllo di flusso .3

La dimensione della finestra di trasmissione lato Tx e’ determinata
dalla capacita’ di bufferamento in ricezione lato Rx.

La protocol entity TCP lato Rx riscontra un PDU informativo nel
momento in cui ne ha potuto salvare il contenuto nel buffer di
ricezione.

Non quando il suo cliente locale lo legge effettivamente.

Se non lo riscontrasse il pari lato Tx, scaduto il timeout di error
recovery, lo ritrasmetterebbe, sprecando banda, e cio’ deve
essere evitato.

Quando il cliente locale della protocol entity lato Rx legge
effettivamente dei byte informativi questi possono essere eliminati
dal buffer di ricezione, liberando spazio per nuovi byte inviati dal
pari lato Tx.

E’ quindi l’operazione di lettura di byte ricevuti dalla rete effettuata
dal cliente locale che porta la protocol entity lato Rx ad aprire la
finestra di trasmissione del suo pari.
29
Finestra a scorrimento: 2 funzioni distinte e indipendenti

Sul meccanismo della finestra di scorrimento e sulla relativa numerazione dei
PDU si appoggiano 2 funzioni diverse e indipendenti:
 La funzione di recupero degli errori tramite riscontro esplicito ed eventuale
ritrasmissione in caso di mancato riscontro.
 La funzione di controllo di flusso tra i due end-point della connessione.

Deve essere possibile:
1.
riscontrare la ricezione di un PDU informativo senza aprire ulteriormente la
finestra per il mittente (per evitare inutili ritrasmissioni).
2.
aprire la finestra per il mittente senza riscontrare la ricezione di alcun PDU
(se non c’e’ niente da riscontrare, ma si sono liberati buffer di memoria per
la ricezione).
3.
riscontrare la ricezione di un PDU informativo e contestualmente aprire
ulteriormente la finestra per il mittente.

Il PDU che il lato ricevente invia al mittente deve contenere due campi diversi
(per riscontro e controllo finestra) che citano la numerazione dei PDU informativi
nella direzione di comunicazione opposta.

Esercizio: rappresentare 3 scenari di interazione tra utenti e provider del
Servizio di Trasporto su due nodi A e B in cui si verifichino le 3 situazioni
indicate.
30
Trasmissione e ricezione sulla rete
TCP
entity
write()
read()
IP
TCP
entity
end-point
end-point
TX buffer
RX buffer
RX buffer
.1
TX buffer
• Chiedere la trasmissione di n byte su una connessione non implica che questi
n byte siano trasmessi immediatamente.
• Ad esempio perche’ la finestra di trasmissione e’ chiusa.
• Quello che succede e’ che gli n byte sono copiati in un buffer di trasmissione
associato all’end-point locale della connessione.
• E se il buffer e’ gia’ pieno o non c’e’ posto per tutti gli n byte?
• Analogamente succede per la ricezione: i byte ricevuti dalla rete sono inseriti
in un buffer di ricezione in attesa che il cliente del TCP chieda di acquisirli con
una operazione di lettura.
• Domanda: perche’ per ogni endpoint e’ necessario l’utilizzo di buffer
sia in trasmissione che in ricezione?
31
Trasmissione e ricezione sulla rete
TCP
entity
write()
read()
IP
TCP
entity
end-point
end-point
TX buffer
RX buffer
RX buffer
.2
TX buffer
• E’ evidente che la finestra di trasmissione di un end-point non puo’
eccedere la quantita’ di memoria libera sul buffer di ricezione
dell’altro end-point.
• Altrimenti l’end-point mittente sarebbe autorizzato a trasmettere
dei byte che il ricevente non saprebbe dove mettere.
• Quando e’ che il ricevente apre la finestra di trasmissione del
mittente?
• Quando si liberano dei byte nel suo buffer di ricezione.
• Cioe’ quando il cliente del TCP acquisce dei byte dal buffer di
32
ricezione tramite una operazione di lettura
Scenario elementare di trasmissione / ricezione
TCP entity
write()
IP
end-point
TX buffer
tempo
TCP entity
end-point
info
RX buffer
ack
end-point
end-point
TX buffer
RX buffer
read()
window
 Quando il ricevente ha inserito i byte ricevuti in RX buffer puo’
generare ACK.
 Quando il mittente riceve ACK puo’ liberare i byte trasmessi ma
ancora contenuti in TX buffer (per eventuali ritrasmissioni).
 Quando il cliente acquisisce i byte contenuti in RX buffer, questi byte
possono essere liberati e di conseguenza la finestra di trasmissione
33
del mittente puo’ venire aperta
Controllo di flusso e congestione
•
Il meccanismo del controllo di flusso consente al TCP di risolvere il
problema della comunicazione tra due ES con diverse velocita' di
processamento.
•
Ma cosa succede se i due ES che comunicano sono piu' veloci della rete
che li connette (di uno dei router lungo il path seguito dai loro datagram
IP)?
•
"Quando le macchine intermedie diventano sovraccariche, la condizione
e' definita congestione.
•
I meccanismi per risolvere la situazione sono chiamati meccanismi di
controllo di congestione.
•
TCP non ha un meccanismo esplicito per il controllo della congestione (la
congestione e' un problema del Network Layer!). Ma,
• Un'implementazione TCP programmata accuratamente puo' rilevare e
risolvere la congestione.
• Un'implementazione peggiore puo' peggiorarla!" (Comer)
 Il buon funzionamento della rete dipende dal buon comportamento degli
ES connessi !
•
Naturalmente un IS puo’ essere anche congestionato dal traffico di
diversi flussi di comunicazione indipendenti tra loro.
34
Controllo di flusso
I meccanismi per il controllo di flusso e la regolazione della finestra di
trasmissione servono a 3 diversi scopi:
1. Utilizzo efficiente della banda di rete.
•
Il trasmettitore puo’ inviare nuovi dati senza dovere attendere
l’ACK di quelli inviati in precedenza.
2. Regolazione della velocita’ di scambio dell’informazione tra gli endpoint della comunicazione.
•
L’entita’ di Trasporto in ricezione apre la finestra solo quando il
cliente estrae dei dati dal buffer di ricezione.
•
Se il cliente in ricezione e’ lento e non estrae dati, la finestra
non viene riaperta.
3. Contenimento dei fenomeni di congestione della rete.
•
Vedi pagine seguenti.
35
PDU TCP (segmento)
Identificazione
della
connessione
Identificazione dei dati
trasmessi con il PDU
Riscontro di dati
ricevuti
Dimensione della
finestra di
trasmissione
per il pari
36
PDU TCP
.1
 I PDU del protocollo TCP sono chiamati segmenti:
 ogni segmento e’ relativo ad una connessione e puo’ esistere ad
un certo istante un’unica connessione tra gli stessi due end-point.
 La struttura dell’informazione trasportata da un segmento e’ descritta
tramite una mappa di byte.
 La dimensione massima del segmento (e quindi della sua parte dati)
viene contrattata al momento del set-up della connessione.
 Poiche' TCP trasporta uno stream continuo di byte, esso puo'
 assemblare,
 disassemblare,
 riassemblare diversamente (e.g. in caso di ritrasmissione),
le richieste di trasmissione del cliente.
 Ogni segmento dati trasporta anche l'indice (numero di sequenza) del
primo dei suoi byte all'interno dello stream.
 Ovvio che sia cosi’, TCP e’ stream oriented.
In TPx ci sarebbe il numero del messaggio!
 Ogni segmento trasporta informazioni di protocollo relative ad
entrambe le direzioni della comunicazione.
37
PDU TCP
.2
 Ogni PDU puo’ trasportare sia una informazione di ACK che una
informazione di controllo della finestra
(N.B.: dimensione massima della finestra: solo 216 byte, tanti nel 1980
ma molto pochi nel 2010. Su una rete a 1Gbps ci vuole meno di 1 ms
per consumarla tutta, in assenza di aperture dal ricevente).
 L'informazione di ACK e quella di controllo della finestra sono
separate: il ricevitore puo' riscontrare la ricezione di un PDU senza
aprire la finestra del mittente.
 Poiche' TCP trasporta uno stream continuo di byte l'indicazione di
ACK e quella di finestra presenti in un segmento sono espresse
rispettivamente come
 indice di byte nello stream (del prossimo byte atteso, quello
successivo al prefisso contiguo massimo gia’ ricevuto),
 numero di byte ricevibili a partire da quello indicato nell'ACK.
 Considerando l'ACK, deve essere cosi' perche' non solo TCP invia dati
in segmenti di lunghezza variabile, ma in caso di ritrasmissione e'
anche libero di riassemblarli, inviando piu' dati che nel segmento 38
originale.
Timeout di ritrasmissione
.1
 Per ogni segmento dati che trasmette TCP avvia un timer.
 Se il timer termina senza che i dati del segmento siano riscontrati
positivamente TCP assume che il segmento sia andato perso e lo
ritrasmette.
 Quanto deve essere lungo il timer? Cioe’, dopo quanto tempo scatta il
timeout?
 Il timer di ritrasmissione deve essere il piu' possibile vicino al
round-trip delay ma non deve sottostimarlo.
 TCP non opera su un Data Link con round-trip delay fisso e calcolabile
a priori.
 TCP opera su IP e il roud-trip delay puo' variare moltissimo da un
datagram all'altro:
 Perche' le reti che connettono due ES possono essere
estremamente eterogenee (LAN vs. internetwork).
 Perche' due datagram seguono percorsi diversi.
 Perche' il carico di rete incontrato (e quindi il tempo di
attraversamento degli switch e dei router, anche lungo un
medesimo percorso) e' diverso.
39
Timeout di ritrasmissione
.2

TCP gestisce la variabilita' del roud-trip delay utilizzando un timer
di ritrasmissione adattativo.

"TCP tiene sotto controllo le prestazioni di ogni collegamento e ne
deduce valori ragionevoli per i timeout: se le prestazioni di una
connessione cambiano, TCP riesamina tali valori, ovvero si adatta
alla variazione." (Comer)

Per ogni segmento trasmesso TCP campiona (in base al relativo
ACK) il round-trip delay relativo.

L'implementazione canonica del TCP calcola lo RTT (Round Trip
Time stimato) come una media pesata, che viene via via
aggiornata dai nuovi campioni:
RTT(k) =  * RTT(k-1) + (1- ) * RTTsample(k), con 0<<1

La risposta piu' o meno rapida alle variazione dipende dal valore di
 piu' o meno vicino a 0.

Il valore consigliato e' =7/8.

Esercizio: Cosa succede se =1? E se =0?
40
Timeout di ritrasmissione
.3

In base al valore corrente di RTT viene poi calcolato il Timeout
di ritrasmissione.

Ad esempio:
Timeout =  * RTT, con >1

Quanto vale  ?
 Se  e' prossimo a 1 si rilevano in fretta eventuali perdite di
segmenti,
ma e' anche facile che si debbano effettuare ritrasmissioni
inutili.
 La specifica originale indicava come valore consigliato =2.
41
Stima di RTT: problemi
.1

L'algoritmo base per il calcolo del timeout di ritrasmissione non
tollera un jitter (variazione del ritardo di rete) molto ampio.

La variazione statistica (varianza)  del round-trip delay e' tanto
maggiore quanto maggiore e' il traffico L (0L 1, espresso
come frazione della capacita' della rete) ( e’ inversamente
proporzionale a 1-L).

La regola canonica per il calcolo del timeout non sopporta un
traffico L>0.3.

TCP adesso richiede che anche la variazione (la derivata) del
RTT sia presa in considerazione per il calcolo del timeout,
ottenendo cosi' un valore di timeout piu' adattativo.

In realta', in pratica, anche se il valore medio del delay varia
significativamente nel tempo, la variazione tra due datagram
consecutivi e' molto piu’ contenuta.
42
Algoritmo di calcolo di RTT e Timeout

Algoritmo di calcolo raccomandato:
 diff(k) = RTTsample(k) - RTT(k-1)
 RTT(k) = RTT(k-1) +  * diff(k)
(N.B. la formula per il calcolo di RTT non e' cambiata.
Basta sostituire  con (1-)).
 dev(k) = dev(k-1) +  * (|diff(k)| - dev(k-1))
= (1 - ) * dev(k-1) +  * |diff(k)|
 Timeout(k) = RTT(k) +  * dev(k)
dove
 0<<1con valore consigliato = 1/23
 0<<1con valore consigliato = 1/22
 valore consigliato di  = 4
43
Stima di RTT: problemi
.2
 In realta' la procedura per il calcolo di RTT deve essere ancora piu'
complessa di quanto indicato.
 TCP utilizza uno schema di riscontro cumulativo, non selettivo-persegmenti. A quale/i segmento/i e' relativo un riscontro?
 In caso di ritrasmissione, il riscontro e' relativo al segmento originale
o alla ritrasmissione?
(in realta' entrambe le assunzioni si rivelano fuorvianti)
 Supponiamo che l'associazione sia con il segmento originale:
se ogni segmento viene perso almeno una volta RTT diverge,
perche' ogni incremento porta ad un aumento del timeout, che a
sua volta porta ad un ulteriore aumento di RTT.
 Supponiamo che l'associazione sia con il segmento ritrasmesso:
questo provoca un decremento di RTT che a sua volta provoca un
decremento di timeout, che quindi spirera' prima dell'ACK
causando una ritrasmissione e l'associazione dell'ACK con la
nuova ritrasmissione, e cosi' via.
Ogni segmento viene cosi' trasmesso 2 volte (anche in
44
assenza di perdite)!
Stima di RTT: algoritmo di Karn
.1
Strategia per la gestione delle ritrasmissioni:
1.
Nel calcolo di RTT si devono ignorare campioni relativi a
segmenti ritrasmessi.
2.
Quindi in caso di necessita' di ritrasmissione il valore di RTT
non viene aggiornato.
3.
In caso di ritrasmissione, pero', il valore del timer di
ritrasmissione (Timeout) viene disaccoppiato da quello di RTT.
4.
Il valore di Timeout viene aumentato di un fattore moltiplicativo
 ogni volta che si deve ritrasmettere un segmento (timer
backoff).
(normalmente, e' =2)
5.
Quando alla fine il mittente riesce a ricevere un ACK relativo
ad un segmento originale, il calcolo di un nuovo valore per
RTT viene riabilitato e il Timeout viene riagganciato a RTT.
45
Stima di RTT: algoritmo di Karn

.2
Per evitare che il Timeout cresca indefinitamente viene
normalmente fissato amministrativamente un valore massimo.
 Dovrebbe essere maggiore del massimo round-trip delay
possibile su Internet!

E' ovvio che l'algoritmo di Karn non funzionerebbe se non
disaccoppiasse Timeout da RTT:
 Altrimenti, in caso di rallentamento della rete con
conseguente ritrasmissione di un segmento, dato che RTT
non viene piu' aggiornato anche Timeout rimarrebbe di
conseguenza invariato!
 Il che comporterebbe ulteriori ritrasmissioni per timeout.
 Fino alla caduta della connessione.

N.B.: con l’aumentare delle ritrasmissioni la loro frequenza
decresce esponenzialmente!
46
TCP e congestione
.1
• La congestione dei router e' un fenomeno che si verifica nel Layer di Rete,
non in quello di Trasporto.
• Il Layer di Rete ha i suoi strumenti per fronteggiare la congestione:
• PDU di source squench ICMP.
• Politiche di scarto dei datagram in eccesso (nei router):
• Tail Drop,
• Random Early Discard.
• Anche senza interagire con il Livello di Rete TCP ha modo di accorgersi
dell'esistenza di una situazione di congestione:
 E' costretto a ritrasmettere dei segmenti.
 TCP assume che ogni ritrasmissione sia dovuta a congestione.
• TCP stesso, autonomamente, a fronte di una situazione di congestione, puo'
contribuire a risolverla.
• O a peggiorarla! Basta che effettui le ritrasmissioni previste senza
applicare l’algoritmo di Karn!
• Gia’ l’algoritmo di Karn garantisce che in caso di congestione le
ritrasmissioni siano rapidamente rallentate.
• Il problema e’ quindi limitare la trasmissione di nuovi byte anche se la 47
finestra di trasmissione la autorizzasse.
I bei tempi andati
• Nelle reti TLC tradizionali non sarebbe mai stato concepibile che il
malcomportamento di un ES potesse danneggiare il funzionalmento
della rete.
• Infatti la rete a pacchetto TLC per eccellenza, la rete X.25:
• era connection oriented (a livello di Network Service);
• preallocava le risorse per ciascuna connessione, ma evitava che
una singola connessione potesse accaparrarsi piu' risorse di
quelle previste;
• poteva effettuare un controllo d'accesso limitando l'ingresso di
nuovi utenti nel caso le risorse di rete risultassero sature.
• L'argomento di Tanenbaum:
• "What happens if the Network Layer offers inadequate service?
• The users have no real control over the Network Layer.
• The only possibility is to put on top of the Network Layer another
layer (allocato sugli ES!) that improves the quality of the service".
era quasi impensabile (vedi TP0-TP3 vs. TP4 nell'OSI).
48
TCP e congestione
•
.2
Per contrastare fenomeni di congestione lo standard TCP
raccomanda che ogni ES implementi due politiche:
1. multiplicative decrease
2. slow start
•
Lo scopo di queste due politiche e' di:
1. ridurre rapidamente la finestra effettiva di trasmissione (cioe’ la
trasmissione di ulteriori byte sulla rete) in caso di percezione di
congestione
 indipendentemente dalla disponibilita' del pari ricevente a
ricevere altri dati
 N.B. la ritrasmissione di byte gia’ trasmessi e’ limitata
dall’algoritmo di Karn
2. riaprire la finestra effettiva di trasmissione abbastanza
lentamente da evitare, al momento della fine della congestione,
che tutti gli ES che avevano in precedenza limitato le proprie
trasmissioni le riprendano cosi' rapidamente da ricreare la 49
situazione di congestione
TCP e congestione
.3
• A fianco della finestra di trasmissione TCP mantiene anche una
seconda finestra, detta finestra di congestione.
• La finestra di congestione serve, in caso di percezione di congestione, a
limitare la finestra effettiva, quella davvero utilizzata per regolare la
trasmissione dei dati (di nuovi dati), a valori piu' bassi di quanto indicato
dalla finestra di trasmissione:

finestra effettiva = min (finestra di trasmissione,
finestra di congestione)
• In condizioni normali (non di congestione) il valore della finestra di
congestione e' maggiore o uguale a quello della finestra di trasmissione:

finestra effettiva = finestra di trasmissione
• In caso di (per ogni) ritrasmissione (si assume che sia dovuta a
congestione) la finestra di congestione viene dimezzata.
•
La riduzione avviene per ogni ritrasmissione.
•
In caso di congestione la finestra di congestione e quindi anche
quella effettiva si riducono in modo esponenziale.
•
Il valore minimo ammesso della finestra di congestione e' 1 50
segmento.
TCP e fine della congestione: slow start
•
La riapertura della finestra di congestione, e quindi della finestra
effettiva, non avviene in modo moltiplicativo ma in modo additivo.
•
Aprire la finestra in modo moltiplicativo porterebbe a instabilita' del
sistema (oscillazioni tra congestione e rete scarica).
•
Quando si comincia ad utilizzare una nuova connessione e dopo
una fase di congestione, la finestra di congestione viene
posizionata a 1 segmento, e viene incrementata di 1 segmento per
ogni ACK ricevuto.
•
Il nome slow start e' fuorviante: il traffico cresce rapidamente (in
effetti la crescita non e' additiva ma esponenziale!).
• Dopo il primo ACK sono trasmessi 2 segmenti.
• Alla ricezione degli ACK relativi i segmenti trasmessi diventano
4, e cosi' via.
•
La finestra di congestione cresce cosi' rapidamente che per
rallentarne l'apertura, quando arriva a meta' del valore antecedente
la fase di congestione, essa viene incrementata di 1 solo quando
51
tutti i segmenti della finestra sono stati riscontrati.
TCP e fine della congestione: esempio
(Tanenbaum)
52
Implementazione di un TSAP su Internet
 Secondo OSI un TSAP e' un punto d'accesso al servizio del layer di
Trasporto.
 Il concetto di TSAP e' implementato (circa) in Internet attraverso la
nozione di porta di protocollo.
 Una porta di protocollo e' individuata attraverso una tripla:
 Un indirizzo IP del sistema su cui la porta si trova
 NSAP OSI
 Il protocollo cui la porta e' relativa (TCP vs. UDP)
 Il numero della porta (un intero compreso tra 1 e 65.535)
( TSEL OSI)
 Una porta identifica univocamente una applicazione che accede,
tramite il servizio di Trasporto, alla rete.
 Nel TCP l'astrazione fondamentale e‘ la connessione, identificata
dalla coppia di porte che si trovano ai suoi estremi, non la porta.
 TCP associa le comunicazioni (i TSAP) alle connessioni, non
alle porte.
 Ogni porta puo' partecipare a diverse connessioni.
53
Porte e Connessioni
Comer:
•
Dal punto di vista di un programmatore l'astrazione connessione e'
significativa.
•
Egli puo' creare un programma in grado di fornire un servizio
concorrente a piu' connessioni simultaneamente, senza avere
bisogno di numeri univoci di porta per ciascun collegamento.
 Le connessioni verso i diversi client avranno tutte uguale
identificatore di porta lato server, ma identificatore diverso per
ciascun client, e saranno quindi tutte distinguibili tra loro.
•
La maggior parte dei sistemi fornisce accesso simultaneo al sistema
di posta elettronica, consentendo a piu' computer di inviar loro in
parallelo le mail.
•
Poiche' il programma che accetta la posta in ingresso usa TCP per
comunicare, anche se consente a piu' connessioni di avere luogo
simultaneamente, deve utilizzare localmente solo una porta TCP.
•
N.B.: un servizio viene offerto su una porta. Uno specifico cliente
viene servito tramite una connessione che ha quella porta come 54
uno dei suoi 2 end-point.
Connessioni

Una connessione rappresenta una relazione tra 2 porte TCP, i suoi
end-point.

Dal punto di vista del protocollo TCP l’unico modo per identificare
una connessione e’ tramite gli indirizzi dei suoi due end-point.
 Invece nei protocolli di trasporto OSI ad ogni connessione e’
associato anche un ulteriore identificatore che la rende
distinguibile rispetto ad altre connessioni tra gli stessi end-point.
 Nota che la modalita’ TCP di identificare le connessioni e’ fonte
di notevoli problemi (vedi seguito).

Per evitare ambiguita’, ad ogni istante non possono esistere sulla
rete piu’ connessioni tra gli stessi end-point.

Le protocol entity TCP che gestiscono le porte agli estremi della
connessione mantengono lo stato della connessione stessa.

Il protocollo TCP in realta’ non gestisce porte ma solo connessioni.

Una porta TCP non connessa e non in corso di dis/connessione (in
particolare, una porta in stato Listening) viene marcata come
55
connessa alla porta inesistente 0.0.0.0:0
+---------+ ---------\
active OPEN
| CLOSED |
\
----------+---------+<---------\
\
create TCB
|
^
\
\ snd SYN
passive OPEN |
|
CLOSE
\
\
------------ |
| ---------\
\
create TCB |
| delete TCB
\
\
V
|
\
\
+---------+
CLOSE
|
\
| LISTEN |
---------- |
|
+---------+
delete TCB |
|
rcv SYN
|
|
SEND
|
|
----------|
|
------|
V
+---------+
snd SYN,ACK /
\
snd SYN
+---------+
|
|<---------------------------------->|
|
|
SYN
|
rcv SYN
|
SYN
|
|
RCVD |<-----------------------------------------------|
SENT |
|
|
snd ACK
|
|
|
|------------------------------------|
|
+---------+
rcv ACK of SYN \
/ rcv SYN,ACK
+---------+
|
-------------|
|
----------|
x
|
|
snd ACK
|
V
V
| CLOSE
+---------+
| ------| ESTAB |
| snd FIN
+---------+
|
CLOSE
|
|
rcv FIN
V
------|
|
------+---------+
snd FIN /
\
snd ACK
+---------+
| FIN
|<---------------------------------->| CLOSE |
| WAIT-1 |-----------------|
WAIT |
+---------+
rcv FIN \
+---------+
| rcv ACK of FIN
------|
CLOSE |
| -------------snd ACK
|
------- |
V
x
V
snd FIN V
+---------+
+---------+
+---------+
|FINWAIT-2|
| CLOSING |
| LAST-ACK|
+---------+
+---------+
+---------+
|
rcv ACK of FIN |
rcv ACK of FIN |
| rcv FIN
-------------- |
Timeout=2MSL -------------- |
| ------x
V
-----------x
V
\ snd ACK
+---------+delete TCB
+---------+
------------------------>|TIME WAIT|------------------>| CLOSED |
+---------+
+---------+
TCP Connection State Diagram
56
O:\>netstat -a -n
Connessioni attive
Proto
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
Indirizzo locale
0.0.0.0:21
0.0.0.0:25
0.0.0.0:80
0.0.0.0:5900
127.0.0.1:21
127.0.0.1:1084
127.0.0.1:2935
127.0.0.1:6129
172.16.2.64:21
172.16.2.64:139
172.16.2.64:1064
172.16.2.64:1711
172.16.2.64:2215
172.16.2.64:2501
172.16.2.64:2536
172.16.2.64:2942
172.16.2.64:2944
172.16.2.64:2945
172.16.2.64:2948
Indirizzo esterno
0.0.0.0:0
0.0.0.0:0
0.0.0.0:0
0.0.0.0:0
127.0.0.1:2935
127.0.0.1:6129
127.0.0.1:21
127.0.0.1:1084
172.16.2.64:2948
0.0.0.0:0
172.16.0.79:139
172.16.0.59:80
172.16.0.42:139
172.16.0.4:139
172.16.0.5:445
172.16.0.6:389
172.16.0.6:389
172.16.0.6:445
172.16.2.64:21
Stato
LISTENING
LISTENING
LISTENING
LISTENING
ESTABLISHED
ESTABLISHED
ESTABLISHED
ESTABLISHED
ESTABLISHED
LISTENING
ESTABLISHED
ESTABLISHED
ESTABLISHED
ESTABLISHED
ESTABLISHED
TIME_WAIT
TIME_WAIT
TIME_WAIT
ESTABLISHED
57
TSAP e connessioni
• Nel mondo TCP un TSAP rappresenta una connessione.
• Una porta non connessa (in stato “Listening”) e’ formalmente
connessa alla porta remota 0.0.0.0:0.
 Che e’ evidentemente un indirizzo di porta fittizio, perche’
• il numero di porta 0 non e’ ammesso
• 0.0.0.0 non e’ ammesso come indirizzo remoto e ha un
significato particolare quando utilizzabile come indirizzo
locale.
• Una porta in stato “Listening” su qualunque indirizzo IP della
macchina si considera che sia associata all’indirizzo IP 0.0.0.0.
 Nel momento in cui una porta “Listening” diventa connessa le
viene comunque attribuito un preciso indirizzo IP, quello relativo
alla sottorete su cui e’ stata attivata la connessione.
• Quando una connessione in stato “Listening” si avvia a diventare
connessa, TCP crea un’altra connessione in stato “Listening” per la
58
stessa porta.
TCP e creazione di una connessione
• Perche' e' difficile creare in modo affidabile una connessione TCP?
• Perche' il servizio fornito dal layer IP e' inaffidabile.
• In particolare e' possibile che datagram IP vengano non solo persi,
ma anche ritardati e/o duplicati.
• Uno dei problemi che possono nascere in presenza di segmenti
ritardati (eventualmente duplicati) e' il seguente:
• Segmenti ritardati dalla rete e relativi ad una vecchia connessione
sono ricevuti quando una nuova connessione tra gli stessi endpoint e' gia' stata stabilita.
• TCP, a differenza di OSI TPx, non utilizza un identificatore
specifico di connessione, oltre ai due end-point, cosi’ da essere in
grado di distinguere i segmenti relativi alla connessione corrente
da quelli obsoleti.
• Caso estremo (Tanenbaum): tutti i segmenti inviati da un end-point di
una connessione sono duplicati, e tutti i duplicati sono consegnati al
destinatario ritardati ma in ordine, dopo che la connessione e' gia'
59
stata chiusa.
Eliminazione di datagram obsoleti
•
E' possibile limitare a priori il tempo di vita di un datagram IP?
•
Si' perche', se si evitano cicli, il numero di hop necessari per
attraversare l'intera Internet e' finito.
•
Basta inserire uno hop-count in ogni datagram e decrementarlo ogni
volta che un router lo ritrasmette. Quando lo hop count raggiunge lo 0
il datagram deve essere cestinato.
•
Equivalentemente si potrebbe marcare ogni datagram con un timestamp.
• Ma questo e' piu' complesso in quanto richiederebbe che gli
orologi di tutti i nodi della rete fossero sincronizzati.
• In effetti esiste un protocollo di internet per la sincronizzazione
degli orologi (NTP), e funziona anche molto bene, ma l’utilizzo
dell’hop-count e’ ovviamente molto piu’ efficiente.
•
In realta' bisogna garantire anche che l'ACK di un segmento sia morto
entro un tempo finito:
• indichiamo con Tmax il tempo di vita massimo di un segmento e
60
del suo ACK.
TP4 OSI e creazione di una connessione
•
•
•
•
Basandosi
• sulla eliminazione dei datagram obsoleti e
• sul fatto che ogni volta che l’initiator chiede al responder l’apertura
di una connessione marca la richiesta con un ID di connessione
diverso
e’ sufficiente che il responder mantenga memoria dell’ID di una
connessione chiusa per un tempo Tmax.
Ogni volta che riceve un richiesta di connessione il responder puo’
verificare facilmente se la richiesta e’ attuale o e’ obsoleta.
Ma in caso di restart del responder?
• Il responder perde la lista delle connessioni chiuse per le quali
possono ancora essere presenti nella rete dei segmenti obsoleti!
• Questo problema puo' essere risolto proibendo ad un end-system
di attivare la rete dopo il boot per un periodo di tempo pari a Tmax.
Ma in caso di restart dell’initiator?
• Come fa l’initiator a ricordarsi degli ID gia’ usati?
61
• Tramite il meccanismo dell’orologio contatore!
Il meccanismo dell’orologio contatore
•
•
•
•
•
•
Ogni macchina viene dotata di un contatore periodico
autoincrementante (un orologio contatore).
L’orologio contatore deve operare anche in caso di spegnimento
della macchina.
Il contatore deve avere un numero di bit sufficientemente grande.
Nel caso di TP4 l’orologio contatore puo’ venire utilizzato per
selezionare in modo sicuro un ID univoco per la prossima richiesta
di connessione che viene generata sulla macchina.
Ma in TCP le connessioni non sono marcate con un ID
addizionale!
Nel caso del TCP l’orologio contatore locale viene utilizzato da
ciascun end-point per selezionare il valore iniziale del sequence
number che esso usera’ in trasmissione.
• Il sequence number dei segmenti trasmessi in una
connessione viene inizializzato con i bit piu' leggeri del
contatore.
• Il numero di bit dell’orologio contatore deve quindi essere
maggiore o uguare a 232, dimensione del sequence number
TCP.
62
TCP e creazione di una connessione
• E’ evidente che perche’ TCP funzioni bene lo spazio dei valori del
sequence number deve essere talmente grande che quando una
connessione riutilizza un valore il segmento che lo aveva gia' utilizzato
e' gia' stato eliminato dalla rete.
• Bisogna cioe’ evitare che ci siano nella rete due segmenti
• relativi alla stessa connessione (cioe' agli stessi end-point),
• con uguale sequence number,
• ma indipendenti tra loro (non uno la ritrasmissione dell'altro).
• Se riuscissimo a fare questo anche il problema di realizzare una
connessione sicura, evitando interazioni con segmenti relativi a
connessioni passate tra gli stessi end-point, sarebbe risolto.
• Per ottenere questo TCP correla (limita) la velocita’ di trasmissione
sulla connessione all’avanzamento dell’orologio contatore, cosi’ che
l’orologio contatore sia sempre in grado di fornire un valore sicuro di
sequence number iniziale in caso di chiusura ed immediata riapertura
della connessione tra due end-point .
• E’ sufficiente che la il numero di byte trasmessi non ecceda il
numero di tick di cui e’ avanzato l’orologio contatore.
• L’orologio contatore deve avanzare ad una velocita’ tale da non
63
limitare la banda della connessione.
Creazione di una connessione: 3-way handshake

Ogni macchina sceglie in modo sicuro il sequence number iniziale
(utilizzando il proprio orologio contatore).

Le due macchine si scambiano i propri contatori (e confermano la
ricezione del contatore dell'altra) con uno scambio di 3 segmenti.
Send(SYN(seq=x))
Receive(SYN(seq=x))
Send(SYN(seq=y)+ACK(x+1))
Receive(SYN(seq=y)+ACK(x+1))
Send(ACK(y+1))
Receive(ACK(y+1))
Esercizio: quali altri parametri devono essere concordati durante il protocollo di set-up?
Esercizio: mappare la specifica del servizio T-CONNECT su questo scambio di PDU64
Creazione di una connessione: 3-way handshake
Comer:
• Di solito il SW TCP su una macchina aspetta passivamente la
sincronia (richiesta di apertura passiva della connessione) e il SW TCP su
un'altra la inizia (richiesta di apertura attiva della connessione).
• La sincronia e' pero' progettata per funzionare anche se entrambe le
macchine tentano di iniziare una connessione simultaneamente.
• (in ogni caso) Una volta che la connessione e' stata stabilita, i dati
possono fluire in entrambe le direzioni: non esiste una macchina
principale e una secondaria.
• Il protocollo deve usare un meccanismo di timeout e ritrasmettere le
richieste andate perse.
• TCP ignora altre richieste di connessione (tra uno stesso paio di
end-point) dopo che tra loro e' gia' stata stabilita una connessione.
• La sincronia svolge due importanti funzioni (+ altre: quali?):
• garantisce che entrambi i lati siano pronti a trasferire dati
• consente ad entrambi di concordare sui numeri di sequenza
65
iniziali.
Connection Establishment (Tanenbaum)
Three protocol scenarios for establishing a connection using a three-way
handshake. CR denotes CONNECTION REQUEST.
(a) Normal operation,
(b) Old CONNECTION REQUEST appearing out of nowhere.
(c) Duplicate CONNECTION REQUEST and duplicate ACK.
66
TCP e chiusura di una connessione
.1
 La procedura di disconnessione morbida (ordinata) deve
consentire di chiudere una connessione dopo che
 le parti hanno trasmesso tutto cio' che dovevano trasmettere;
 ciascuna parte ha ricevuto tutto cio' che l'altra parte ha
trasmesso.
 Le connessioni TCP sono viste a tutti gli effetti come due flussi
indipendenti di dati, uno in ciascuna direzione.
 Quando un cliente TCP chiude la connessione, indica
effettivamente che non ha piu' dati da trasmettere su di essa:
 chiede quindi la chiusura di una direzione della connessione.
 Prima di iniziare il protocollo di disconnessione l'entita' di
protocollo TCP lato mittente aspetta di
 avere trasmesso tutti i dati pendenti;
 avere ricevuto tutti i relativi ACK dalla controparte.
67
TCP e chiusura di una connessione
.2
 Dopo che ha effettuato la richiesta di chiudere la connessione, il
cliente non puo' piu' chiedere la trasmissione di altri dati.
 Il lato ricevente del TCP, quando riceve un segmento FIN
 lo riscontra;
 informa il proprio cliente che dalla connessione non
arriveranno piu' altri dati (e.g. con una indicazione di EOF).
 Notare che se una connessione e' stata chiusa in una direzione,
rimane pero' ancora aperta nell'altra.
 Dire che una direzione e' chiusa significa dire che e' chiusa a
segmenti informativi:
 segmenti che non trasportano informazioni (e.g. semplici
ACK) possono continuare a viaggiare in quella direzione.
 Una connessione e' effettivamente chiusa quando entrambe le
sue direzioni sono state chiuse.
68
TCP e chiusura di una connessione
.3
FromClient(close.req)
Send(FIN(seq=x))
Receive(FIN(seq=x))
ToClient(close.ind)
Send(ACK(x+1))
Receive(ACK(x+1))
FromClient(close.req)
Send(FIN(seq=y)+ACK(x+1))
Receive(FIN(seq=y)+ACK(x+1))
ToClient(close.ind)
Send(ACK(y+1))
Receive(ACK(y+1))
N.B.: non esiste un servizio OSI di disconnessione ordinata
69
TCP e chiusura di una connessione
.4
 Naturalmente e' possibile che segmenti (di FIN e di ACK) vadano
persi durante l'esecuzione del protocollo di disconnessione.
 Per recuperare la perdita di segmenti ci si basa su timer.
 Se il mittente del primo segmento di FIN non riceve un ACK entro lo
scadere del timer, riprende il protocollo da capo.
 Dopo n tentativi falliti il mittente del primo segmento FIN chiude
unilateralmente la connessione.
 La controparte non e' naturalmente informata di cio'.
 Se ne accorgera' nel caso sia ancora attiva e provi a comunicare
perche' non otterra' risposta.
 Anche il mittente del secondo segmento di FIN, se non riceve un
ACK entro lo scadere del timer, chiude unilateralmente la
connessione.
 I timer di disconnessione sono normalmente collegati al tempo di vita
massimo di un segmento.
70
TCP e chiusura non ordinata di una connessione
 Una connessione puo' anche essere chiusa unilateralmente in
modo brusco.
 In questo caso:
 non c'e' alcuna garanzia che precedenti richieste di
trasmissione siano (state) onorate,
 ne' che tutti i dati trasmessi dall'altra parte siano stati ricevuti.
 In ogni caso una richiesta di abort della connessione da parte del
cliente provoca l'invio di un segmento di protocollo (RST) all'altra
parte per informarla della cosa.
 Un abort ha effetto in modo bidirezionale:
 interrompe le comunicazioni in entrambe le direzioni.
71
Scenario elementare di trasmissione / ricezione
TCP entity
write()
IP
end-point
TX buffer
tempo
TCP entity
end-point
info
RX buffer
ack
end-point
end-point
TX buffer
RX buffer
read()
window
 Quando il ricevente ha inserito i byte ricevuti in RX buffer puo’ (deve?)
generare ACK.
 Quando il mittente riceve ACK puo’ liberare (elimina) i byte trasmessi ma
ancora contenuti in TX buffer (per eventuali ritrasmissioni).
 Quando il cliente acquisisce i byte contenuti in RX buffer, questi byte possono
essere liberati e di conseguenza la finestra di trasmissione del mittente puo’
(deve?) essere aperta.
 In realta’ l’apertura della finestra puo’ essere convenientemente dilazionata
72
(per limitare l’overhead), tanto piu’ se la finestra stessa non era stata
completamente chiusa.
Problemi di prestazioni: delayed ACK .1
 Lo scenario di comunicazione elementare e’ molto inefficiente:
 Per ogni PDU informativo (contenente byte di payload) trasmesso
viaggiano 2 PDU contenenti solo byte di overhead.
 Le prestazioni del TCP possono essere migliorate se il ricevente non
trasmette subito l'ACK ad un segmento informativo ricevuto.
 Puo' comunque unificare ACK e apertura di finestra
(che dovrebbe/potrebbe generare dopo la lettura dell'informazione
del segmento da parte del cliente).
 Puo' trasmettere l'ACK facendone il piggyback su un segmento
informativo trasmesso in direzione opposta .
 E.g. sul segmento contenente la risposta applicativa al
segmento ricevuto.
 Ma perche’ dovrebbe esseci una risposta applicativa?
 Perche’ molti protocolli applicativi seguono il pattern
request-reply, e.g. HTTP e RPC.
 Esempio: eco dei caratteri ricevuti in una applicazione di73
terminale remoto.
Problemi di prestazioni: delayed ACK .2
 L’ACK comunque deve essere generato entro un tempo massimo,
per evitare l’inutile ritrasmissione del PDU informativo.
 Ritardare la generazione di ACK puo' avere controindicazioni:
 Se il ritardo e' eccessivo puo' stimolare la inutile ritrasmissione di
segmenti (ma questo, ovviamente non dovrebbe succedere).
 Puo' confondere il calcolo del round-trip delay (questo e’
inevitabile!).
 Lo standard TCP:
 Raccomanda di utilizzare la politica di delayed ACK.
 Specifica che l'inerzia di generazione di un ACK deve essere al
massimo di 500 msec.
 N.B.: questo diventa un lower bound per RTT!
 La generazione di ACK deve essere immediata almeno ogni 2
segmenti.
 Esercizio: definire uno scenario in cui ACK e apertura di finestra
risultino fisiologicamente contestuali.
74
Problemi di prestazioni:
la sindrome della finestra scema
 Supponiamo che un lato della connessione sia piu' veloce dell'altro e
che la rete non ponga limiti significativi di banda.
 Consideriamo la trasmissione dal lato veloce a quello lento:
 Dopo un po' il buffer del lato ricevente sara’ completamente
occupato e la finestra sara' chiusa.
 A questo punto il cliente lato ricevente legge un byte (dal buffer di
ricezione della connessione).
 Di conseguenza il TCP lato ricevente genera un segmento di
apertura di finestra di un byte.
 Il lato trasmittente invia immediatamente un segmento informativo
contenente un byte, saturando di nuovo il buffer del lato ricevente.
 Il ciclo si ripete con il lato mittente che trasmette dati un byte alla
volta, un byte per segmento.
 Si utilizza un PDU informativo per trasmettere 1 solo byte di payload
75
(senza contare eventuali, conseguenti, PDU di overhead).
La sindrome della finestra scema, lato ricevente
 Esistono contromisure lato ricevente. La strategia e':
• Non aprire la finestra per un numero di byte troppo piccolo.
• Aspettare ad aprire la finestra finche' la si possa aprire in modo
abbastanza significativo.
 TCP definisce questa quantita' come:
• Almeno meta' della dimensione totale del buffer disponibile lato
ricezione,
oppure (il minimo dei due):
• Almeno la dimensione del massimo segmento consentito (MTU)
(N.B.: cio’ garantisce il miglior rapporto payload/overhead
possibile).
 La ricetta secondo Comer:
Receive-Side Silly window Avoidance: before sending an updated
window advertisment after advertising a 0-window (dopo avere
bloccato il lato mittente), wait for space to become available to be at
least 50% of the total buffer size or equal to a maximum-sized
76
segment.
La sindrome della finestra scema, lato mittente
.1
 Esistono contromisure lato mittente. La strategia e':
 Cercare di evitare l'invio di segmenti informativi che contengano
pochi dati.
 Cercare di evitarlo anche a fronte di singole richieste, da parte del
cliente, di trasmissione di pochi byte.
 In questo caso, aspettare a soddisfare le singole richieste, cercando,
con un singolo segmento trasmesso, di soddisfare
contemporaneamente piu' di una richiesta di trasmissione del cliente.
 La ricetta secondo Comer (algoritmo di Nagle):
Send-Side Silly window Avoidance: when a sending application
generates additional data to be sent over a connection for which
previous data has been transmitted but not acknowledged, place the
new data in the output buffer as usual, but do not send additional
segments until there is sufficient data to fill a maximum-sized segment.
If still waiting to send when an acknowledgement arrives, send all data
that has accumulated in the buffer.
77
La sindrome della finestra scema, lato mittente
.2
 Il principio e' che il tempo di isteresi per soddisfare una richiesta di
trasmissione del cliente e' adattativo.
 Dipende dalla velocita' della rete.
 Dipende dalla velocita' della controparte.
 Dipende dal tipo di traffico generato dal cliente.
 Consideriamo i casi estremi:
 Per un file transfer il cliente mittente genera grandi quantita' di
dati che saturano il segmento di massima dimensione.
La trasmissione dei dati non viene quindi ritardata.
 Nel caso di un virtual terminal il cliente mittente genera un
carattere alla volta. Il primo viene inviato immediatamente.
Quelli successivi sono accumulati in attesa dell'ACK del primo, e
non appena questo arriva sono immediatamente trasmessi in
blocco.
Dal punto di vista del cliente non c'e' una significativa percezione
78
di ritardo.
Algoritmo di Nagle
 L’algoritmo di Nagle e’ utile per eliminare la sindrome della finestra
scema ma rappresenta anche una politica generale capace di
ottimizzare il rapporto payload/overhead.
 Vedi l’esempio Telnet (terminale virtuale).
 Infatti tutte le implementazioni di TCP implementano l’algoritmo di
Nagle e, di default, lo applicano a tutte le connessioni.
 Esercizio: essendo attivo l’algoritmo di Nagle che differenza c’e’ tra
N richieste, immediatamente in sequenza, di trasmissione di 1 byte
e una singola richiesta di trasmissione di N byte?
 Dal punto di vista del carico di rete.
 Dal punto di vista del carico computazionale sui due endsystem.
 Descrivere alcuni possibili scenari (per diverse velocita’ di endsystem e rete).
79
Push dei dati e Algoritmo di Nagle
 Ci sono applicazioni per le quali l'utilizzo dell'algoritmo di Nagle non e'
appropriato:
 in una applicazione come X-term o VNC, ad esempio, il suo
utilizzo causerebbe lo spostamento a scatti del mouse.
 In teoria TCP consente, tramite una operazione di push, di forzare la
trasmissione dei dati.
 L'operazione di push pero' non by-passa l'algoritmo di Nagle.
 L'algoritmo di Nagle puo' essere disabilitato per una connessione
attraverso una opportuna configurazione dell'entita' di protocollo TCP.
 Vedi l'opzione TCP_NODELAY della system call setsockopt()
(lezione 4).
 L'algoritmo di Nagle viene normalmente disabilitato nelle
applicazioni in tempo reale.
 Esercizio: supponiamo che sia MTU=1000 e che il processo mittente esegua
in successione 4 operazioni di trasmissione, rispettivamente di 500, 500, 250,
500 byte. Come vengono effettivamente trasmessi questi byte in rete, e come
vengono ricevuti dal processo destinatario se assumiamo che questo sia 80
permanentemente in ricezione?
Interazione livello applicativo - TCP
 TCP cerca di ottimizzare le prestazioni della rete qualunque siano le
caratteristiche del dialogo applicativo, caratteristiche che ovviamente
non possono essere limitate a priori.
 L’algoritmo di Nagle ha questo scopo, anche al di la’ del caso specifico
della sindrome della finestra scema.
 Le caratteristiche dell’applicazione possono avere impatti significativi
sulle prestazioni fornite da TCP.
 Ad esempio, se in un dialogo request-reply la risposta e’ sempre (o
non e’ mai) generata in tempi sufficientemente brevi da consentire il
piggybacking dell’ACK.
 Se l’applicazione disabilita le modalita’ operative normali di TCP se ne
assume la responsabilita’ e ne subisce eventualemente le
conseguenze.
 In caso di disabilitazione dell'algoritmo di Nagle non e’ piu’ vero che
N operazioni di write da 1 byte l’una sono piu’ o meno equivalenti a
1 operazione di write da N byte.
Dovra’ essere cura dell’applicazione minimizzare le operazioni 81
di write.
Dati fuori banda (expedited data)
 Il TCP fornisce un servizio di trasmissione affidabile di una sequenza
continua e ordinata di byte.
 Puo' pero' essere significativo poter trasmettere dei dati che siano
ricevuti dalla controparte al di fuori della sequenza: ad esempio se
voglio inviare un comando di abort all'applicazione remota.
 Per consentire una cosa del genere il cliente puo' marcare una
richiesta di trasmissione come urgente (out-of-band), e questa e'
trasportata in un segmento che contiene anch'esso la marca di urgente
(e che viene trasmesso immediatamente).
 TCP specifica che quando il lato ricevente riceve un segmento marcato
urgente, esso deve entrare in stato di urgenza e informare
immediatamente della cosa il cliente.
 A cosa servono i dati fuori banda se il processo destinatario non
viene informato subito della loro ricezione?
 Come? Dipende dal sistema operativo, e.g. attraverso un signal.
 Quando il cliente lato ricevente ha letto tutti i dati urgenti viene
informato della fine dello stato di urgenza.
82