5 protocolli trasporto parte3
DESCRIPTION
TRANSCRIPT
1
Modulo 13:Controllo di flusso
Parte 5
Trasmissione dati nel TCP
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.154
Processo applicativo
Write
bytes
TCP
Send buffer
Segment Segment Segment
Trasmissione segmenti
Read
bytes
TCP
Receive buffer
…
… …
Processo applicativo
2
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.155
Controllo di flusso
Obiettivo: il mittente non deve riempire il buffer deldestinatario inviando una quantità eccessiva di dati adun tasso di trasmissione troppo elevatoIl destinatario informa esplicitamente il mittente della quantità dispazio libero nel buffer ricezione TCP. La dimensione della finestranel segmento TCP varia dinamicamente per cui ogni segmento ACKinforma il mittente del numero massimo di byte ricevibili
Dati provenientidal livello IP
Dati verso illivello applicazione
Buffer in ricezionedel livello TCP
Dati TCPnel buffer
Windowricezione
IP TCP Applicazione
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.156
Controllo di flusso a livello di end-point
L’ack è inviato a livello di segmento, per cui un solo ackvale per molti byte
L’ack porta due informazioni:• Quanti byte sono stati ricevuti dal destinatario• Quanti byte il destinatario può ancora ricevere (in quel
momento)
• Il mittente regola la sua finestra in base alla disponibilità che gli è stata indicata dal destinatario– Se il destinatario ha esaurito il buffer, indica una disponibilità pari a 0– In tal caso, la trasmissione si sospende e riprende solo quando il
destinatario segnala di essere nuovamente in grado di ricevere byte
3
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.157
Dimensione della finestra effettiva• AdvertisedWindow: dimensione della finestra
massima di ricezione comunicata dal destinatario (=quantità di spazio libero nel buffer di ricezione)
AdvertisedWindow = MaxRcvBuffer –((NextByteExpected-1)-LastByteRead)
• EffectiveWindow: il mittente calcola la finestra effettiva che limita la massima quantità di dati che possono essere inviati (il mittente sa che ha già spedito dei segmenti):
EffectiveWindow = AdvertisedWindow –(LastByteSent - LastByteAcked)
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.158
Esempio: blocco processo• Il mittente può spedire dati solo se EffectiveWindow>0• Quindi, è possibile che arrivi un segmento che conferma
x byte, consentendo al mittente di aumentare LastByteAcked di x, ma nell’ipotesi che il processo applicativo ricevente non stia leggendo dati dal buffer, viene anche comunicata una AdvertisedWindow di x byte più piccola di prima Il mittente può liberare un po’ di spazio nel suo buffer, ma non può spedire altri dati.
• Se la situazione persiste, può capitare che il buffer mittente si riempia e il TCP deve bloccare la generazione di nuovi dati da parte del processoCONSEGUENZA: Un processo applicativo lento sul computer destinatario può provocare il blocco di un processo mittente veloce!
4
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.159
Come riprendere da una windows=0• Una volta che il destinatario ha comunicato una
finestra di dimensione 0 Il mittente non può più inviare dati Il mittente non può più conoscere se la finestra di ricezione è aumentata perché il destinatario non invia messaggi spontaneamente, ma solo in risposta a segmenti in arrivo
SOLUZIONE TCP: Quando il mittente riceveuna AdvertisedWindow=0, continua ad inviareperiodicamente un segmento con 1 byte di dati
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.160
Esempio: Sindrome della finestra cattiva
Che cosa succede se il destinatario dà l’ACK appenaha un po’ di spazio libero (ad esempio un byte)?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
byte inviati econfermati
byte inviati byte in attesa
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
byte inviati econfermati
byte inviatibyte che verrà inviato subito
5
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.161
Possibili contromisureLATO DESTINATARIO• Il destinatario aspetta di avere svuotato almeno il 50% del
“buffer” prima di inviare un ACK di restart• In alternativa, il destinatario ritarda l’invio dell’ACK
sistematicamente quando il buffer disponibile si riducetroppo (raccomandato dagli standard)
• Il rischio è di attendere troppo e che il mittente ri-invii i dati che vanno in time-out
• Inoltre, questo approccio altera la stima di RTTLATO MITTENTE • Il mittente aspetta di avere abbastanza dati per riempire
un segmento di dimensione MSS• Se però, mentre attende, arriva un ACK, invia comunque
un segmento (più corto)
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.162
Ritrasmissione rapida
• Nel caso in cui il time-out sia abbastanza lungo, si può ritardare molto la necessaria ritrasmissione di un segmento, con conseguenti limitazioni a livello di buffer mittente e destinatario
In alcune versioni di TCP si implementa un meccanismo aggiuntivo per rilevare la perdita dei pacchetti prima che si verifichi un time-out: ACK duplicato
6
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.163
Ritrasmissione rapida (cont.)
• Quando il destinatario riceve segmenti fuori ordine, continua a spedire ACK relativi all’ultimo byte del segmento dati che ha ricevuto correttamente ed in sequenza ordinata
• Poiché il mittente invia, in genere, molti segmenti con una certa continuità, la perdita di un segmento causerà l’invio di molti ACK duplicati
Triplo ACK replicato dello stesso segmento idel tutto simile ad un “not ack” (NACK) sul segmento successivo i+1
Modulo 14:Controllo di congestione
Parte 5
7
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.165
Controllo della congestione
Congestione (def.):• Informalmente: “un numero elevato di sorgenti inviano
contemporaneamente troppi dati generando un trafficoche la rete (Internet) non è in grado di gestire”
Congestione Controllo del flusso!
• Effetti della congestione:– perdita di pacchetti (overflow dei buffer nei router)– lunghi ritardi (tempi di attesa nei buffer dei router)
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.166
Due approcci per il controllo congestione
• Controllo di congestione end-to-end– il livello di rete non fornisce un supporto esplicito al livello di
trasporto– la situazione di congestione è determinata analizzando le perdite
di pacchetti ed i ritardi nei nodi terminali– approccio utilizzato dal TCP
• Controllo di congestione assistito dalla rete– i router forniscono un feedback esplicito ai nodi terminali
riguardante lo stato di congestione nella rete– misura della congestione nei router: lunghezza della coda dei
buffer– singolo bit che indica la congestione di un link (es., controllo di
congestione in reti ATM ABR)– feedback diretto oppure aggiornando un campo del pacchetto
che viaggia tra i nodi terminali
8
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.167
Soluzioni TCP
1. CONTROLLO DI CONGESTIONE “END-TO-END”(cioè, regolato da mittente e destinatario, non dalla rete)
2. “SLOW START”
3. AIMD (sulla congestion window)
Additive Increase - Multiplicative decreaseEsempio– Aumenta la window size linearmente per ACK arrivato entro
timeout (oppure differenzia l’inizio dai passi successivi)– Diminuisce la window di un fattore moltiplicativo in caso di
perdita (es., dividi la window size di 2)
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.168
SCELTA: Congestione end-to-end nessunainformazione proveniente dalla rete
Timeout e ritrasmissione contribuiscono adaumentare la congestioneTCP riduce il tasso di trasmissione in caso dicongestione scegliendo il minimo tra:
CongestionWindow (CW): dimensione della finestra di congestione
AdvertisedWindow (AW): dimensione della finestra di ricezione
Effective window = min(AW, CW)
Controllo della congestione nel TCP
9
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.169
Controllo della congestione nel TCP (2)
throughput = w * MSSRTT Bytes/sec
• Misura delle prestazioni di una connessione TCP:- Throughput (tasso di trasmissione)
w = numero di segmenti nella finestraMSS = dimensione massima del segmentoRTT = Round Trip Time
• Valutazione della banda disponibile:• idealmente: trasmettere il più velocemente possibile senza perdita disegmenti (valore massimo di CongestionWindow)
• incrementare CongestionWindow il più possibile, finché non siverifica un episodio di congestione
• diminuire CongestionWindow, ricominciando poi a incrementarlanuovamente
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.170
Tecniche per il controllo della congestione nel TCP
• Evitare la congestione (congestion avoidance)• stato stazionario (non di congestione): la dimensione della finestra èpari a quella indicata dal ricevente (per il controllo di flusso)
• stato di congestione: riduzione della dimensione della finestra
• Slow-start• all’inizio dell’utilizzo di una nuova connessione o in seguito acongestione di una connessione la dimensione della finestra è pari a 1
• incremento progressivo (esponenziale) della dimensione dellafinestra
• threshold: valore della dimensione della finestra, raggiunto il quale lafase di incremento esponenziale termina e si raggiunge lo statostazionario di incremento lineare
Controllo della congestione nel TCP (3)
10
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.171
Slow start del TCP
• log2N RTT prima di usare finestra di dimensione N aumento esponenziale
Inizializza: CW = 1for (ogni segmento ACK)
CW=CW*2
until ((timeout OR(CW > threshold))
Algoritmo di slow-startHost A
RTT
Host B
tempo
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.172
Calcolo CW: Algoritmo Tahoe
/* slow-start terminato */ /* CW > threshold */
if not(perdita) {ogni w segmenti ACK:CW++}
else { threshold = congwin/2;CW = 1;esegui slow-start }
Tahoe
Evitare la congestione (algoritmo dell’incremento additivo edecremento moltiplicativo): si incrementa esponenzialmentefino a threshold, e poi si incrementa di 1
11
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.173
Calcolo CW: Algoritmo RenoSi rilevano due tipi di errore
- Timeout Riduci la window a 1
- Tre ACK duplicati Non “esagera” come il Tahoe riducendo la window a 1, ma diminuisce la finestra di metà(MOTIVAZIONE: 1 segmento si è perso, ma la rete funziona perché almeno 3 segmenti sono stati ricevuti dal destinatario)
/* slow-start terminato */ /* CW > threshold */Until (loss event) {every w segments ACKed:
CW++}
threshold = CW/2if (loss detected by timeout) {
CW = 1perform slowstart }
if (loss detected by triple duplicate ACK)
CW = CW/2
Reno
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.174
Es., controllo congestione: Reno
• Aumenta la window di 1 per RTT se non c’è perdita: CW++
• Riduci la window di metà se viene evidenziata una perdita con un triplo ACK duplicato:
CW = CW/2
mittente
destinatario
W
mittente
destinatario
W
12
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.175
TCP Reno e TCP Tahoe a confronto
0
2
4
6
8
10
12
14
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15Turno di trasmissione
cong
estio
n w
indo
w s
ize
(CW
)(s
egm
enti)
thresholdiniziale
Series1 Series2TCPTahoe
TCPReno
Al turno 8, si verifica una perdita di pacchetto (rilevatadal time-out nel Tahoe e da un triplo ACK nel Reno)
thresholddopo perdita
TAHOE: threshold=CW/2 CW=1
NOTA: Il Reno utilizza il cosiddetto fast recovery: riprende da threshold e non da 1,ma con crescita lineare e non esponenziale
RENO: threshold=CW/2 CW=threshold
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.176
Controllo di congestione TCP
• Non c’è una scelta migliore assodata • All’inizio si è usata la versione Tahoe• Attualmente, la versione più diffusa è la New
Reno
• Sono state proposte tante varianti. Es.,– Vegas– BIC– CUBIC
Usate in Linux 2.6.x,Adatte a LFN (Long Fat Networks)
13
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.177
Controllo di congestione “Vegas”• Cerca di comprendere problemi di trasmissione,
prima che si verifichino– Approccio pro-attivo invece che reattivo
• Elementi di modifica rispetto a TCP Reno– Meccanismo di ritrasmissione per individuare più
velocemente i pacchetti persi– Congestion avoidance basata su osservazione dei RTT– Modifica del meccanismo slow start
• Principio: diminuzione (lineare) della dimensione della CW nel momento in cui si osserva un continuo aumento del RTT
TCP Reno vs. TCP Vegas
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.178
• Individuazione della perdita di pacchetti– Timeout– 3 ACK replicati– Verifiche basate su
timer a grana grossa (timer globale, 500 ms)
• Individuazione della perdita di pacchetti– Timeout basato su RTT– Verifiche basate su timer
a grana fine per ogni pacchetto
14
TCP Reno vs. TCP Vegas
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.179
• Congestion detection– Perdita di pacchetti
• In caso di timeout o 3 ACK replicati:– Si assume congestione– Si esegue slow start o
fast recovery
• Congestion detection– Aumento di RTT– Il throughput diventa
insensibile al send rate• Gestione della congestione
separata da slow start:– Si considera una funzione
per il calcolo di X come differenza tra precedente CW e attuale CW, entrambi rapportati a RTT
– Se X>0 diminuisci CW di 1/8– Se X≤0 aumenta di 1 MSS
Congestion detection in TCP Vegas• Se X>0
– CW e RTT sono direttamente correlati– Alla diminuzione del RTT, corrisponde un aumento
della CW– All’aumento del RTT, corrisponde un aumento della
CW
• Se X≤0– Non si evidenzia chiara connessione tra CW e RTT– Si ipotizza che non ci sia congestione: non si modifica
la CW, ma si aumenta (di poco) il MSS
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.180
15
Analisi del protocollo TCP Reno
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.181
Send window(buffer size)
Thresholdslow start
Congestion window
Pacchetti persi(invio)
Pacchetti persi(rilevazione)
Traffico
Analisi del protocollo TCP Vegas
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.182
Send window(buffer size)
Slow start
Congestion window
Stima throughput
Misurazionethroughput
Traffico
RTT
16
Fairness: Vegas vs. Reno• Problema della fairness: se flussi TCP Vegas e
Reno competono per la banda– Vegas sente la congestione prima e riduce il
transmission rate– Reno continua ad aumentare la congestion window
• Limiti nella diffusione di TCP Vegas– Supportato da diversi Sistemi operativi (disponibile già
nel kernel Linux dal 1999, v2.2) – Accettato dalla comunità scientifica, tuttavia “the TCP
Vegas variant was not widely deployed outside Peterson's laboratory”
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 6.183
Modulo 15:UDP vs. TCP
Parte 5
17
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.185
Perché usare UDP anziché TCP
• Non c’è instaurazione della connessione– TCP usa un meccanismo di three-way handshaking
prima di iniziare il trasferimento dei dati– UDP non introduce un ritardo per instaurare la
connessione
• Non c’è stato di connessione– TCP mantiene lo stato della connessione tra i nodi
terminali (buffer di invio/ricezione, parametri per ilcontrollo della congestione, numeri di sequenza edacknowledgment)
– un server può supportare un maggior numero diconnessioni attive se usa UDP piuttosto che TCP
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.186
Perché usare UDP anziché TCP (cont.)
• Overhead minore dovuto all’header delsegmento più piccolo– segmento TCP: 20 byte– segmento UDP: 8 byte
• Flusso di invio non regolato– il controllo di congestione del TCP può avere un forte
impatto (negativo) sulle applicazioni di rete in real-time
18
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.187
Quando si può usare UDP
• Si opera su rete locale
• L’applicazione mette tutti i dati in un singolo pacchetto
• Non è importante che tutti i pacchetti arrivino a destinazione (es., alcune applicazioni multimediali)
• L’applicazione gestisce meccanismi di ritrasmissione
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.188
Applicazioni e protocollo trasporto
Applicazione Prot. strato applicativo Prot. trasporto sottostante
posta elettronica SMTP TCP
accesso terminale remoto Telnet TCP
Web HTTP TCP
trasferimento file FTP TCP
file server remote NFS solitamente UDP
multimedia streaming proprietario solitamente UDP
Telefonia Internet proprietario solitamente UDP
Gestione della rete SNMP solitamente UDP
Protocollo di routing RIP solitamente UDP
Traduzione dei nomi DNS solitamente UDP
19
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.189
Applicazioni e protocollo trasporto1) Posta elettronica, accesso da terminaleremoto, Web, trasferimento di file TCP
Necessario il servizio di trasferimento datiaffidabile fornito da TCP
2) Aggiornamento tabelle di routing in RIP
UDPAggiornamenti periodici delle tabelle eventualiinformazioni perse sostituite da informazioni piùaggiornate
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.190
Applicazioni di rete per UDP4) DNS query UDP
Si evitano i ritardi dovuti all’instaurazione dellaconnessione
5) Telefonia Internet UDPTolleranza alla perdita di dati (no servizio affidabile)
Tasso di trasmissione costante (no controllo dicongestione)
6) Applicazioni multimediali UDPTCP non può essere impiegato con multicast (problemadella mancanza del controllo di congestione in UDP)
20
Modulo 16:Altre caratteristiche del TCP
Parte 5
21
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.193
Fairness del TCP• Scopo della fairness: se vi sono N sessioni
TCP che condividono lo stesso link, ciascuna deve ottenere 1/N-mo della capacità del link
TCP connessione 1
bottleneckrouter
(capacità R)
TCP connessione 2
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.194
Perché TCP è fair?
Due sessioni in competizione su un link a capacità limitata• Incremento additivo dà la direzione di 1, facendo crescere il
throughput• Decremento moltiplicativo diminuisce il throughput proporzionalmente
R
R
Limite della condivisione paritetica di banda
Throughput connessione 1
congestione evitata: incremento additivoperdita: decrementa window di un fattore 2
congestione evitata: incremento additivoperdita: decrementa window di un fattore 2
22
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.195
Numeri di sequenza e acknowledgmentNumero di sequenza per un segmento TCP è dato da:- primo ISN random- poi offset del primo byte del flusso dati inviati dal mittente(L’Initial Sequence Number è scelto casualmente con l’obiettivo diminimizzare la probabilità che sia presente un segmento identificato con lostesso numero appartenente ad una connessione precedente con identicinumeri di porta)Esempio: Si supponga di trasferire un file di 500000 byte, con MSS=1000byte. I numeri sequenza saranno: X, X+1000, X+2000, …
#seqsegmento 1
#seqsegmento 2
data for500th segment
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.196
Numeri sequenza e acknowledgment (2)
Il numero di acknowledgment per un segmento TCP:• TCP è full duplex: l’host A può ricevere dati dall’host B mentre stainviando dati a B sulla stessa connessione
• Segmento da B a A:
- numero di sequenza: numero sequenziale del byte del flusso dati
- numero di acknowledgment: numero di sequenza delsuccessivo byte che A si aspetta di ricevere da B (tutti i byteprecedenti sono stati ricevuti (acknowledgement incrementale)
Esempi
- A ha ricevuto da B i segmenti da 0 a 999 byte e da 1000 a 1999 byte,per cui il numero di acknowledgment nel segmento da A a B 2000
- A ha ricevuto da B i segmenti da 0 a 999 byte e da 2000 a 2999 byte,per cui il numero di acknowledgment nel segmento da A a B 1000
23
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.197
EsempioEsempio numeri di sequenza ed acknowledgement (Telnet)• 88.88.88.88 invia un carattere C a 99.99.99.99• 99.99.99.99 eco del carattere inviato a 88.88.88.88• numeri iniziali di sequenza: 42 per 88.88.88.88 e 79 per 99.99.99.99
Doppio scopo:- avvisa l’host che ha ricevutotutti i byte fino a 42- trasmette un dato
Scopo unico:- avvisa l’host che ha ricevutotutti i byte fino a 43- il campo dati è vuoto
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.198
SequenceNum è a 32 bit
Bandwidth Time until Wrap AroundT1 (1.5 Mbps) 6.4 hoursEthernet (10 Mbps) 57 minutesT3 (45 Mbps) 13 minutesFDDI (100 Mbps) 6 minutesSTS-3 (155 Mbps) 4 minutesSTS-12 (622 Mbps) 55 secondsSTS-24 (1.2 Gbps) 28 seconds
Protezione contro il Wrap around
24
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.199
AdvertisedWindow è a 16 bit
Bandwidth Delay x Bandwidth ProductT1 (1.5 Mbps) 18KBEthernet (10 Mbps) 122KBT3 (45 Mbps) 549KBFDDI (100 Mbps) 1.2MBSTS-3 (155 Mbps) 1.8MBSTS-12 (622 Mbps) 7.4MBSTS-24 (1.2 Gbps) 14.8MB
Mantenere la pipe piena
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 6.200
Attenzione alll’intervallo dei numeridi sequenza e dimensione window
Esempio (malfunzionamento)• Dimensione finestra=3• Numeri di sequenza: 0, 1, 2, 3
• Il destinatario non vede differenze nei due scenari a fianco
• Di conseguenza nel caso (a) considera come nuovo un pacchetto duplicato
Ci deve essere una relazionetra dimensione delle finestree intervallo dei numeri disequenza
25
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.201
Sliding window e numeri di sequenza
• I numeri di sequenza non sono illimitati, ma limitati dal numero di bit disponibili (es., 3 bit consentirebbero i numeri di sequenza da 0 a 7).
• Scegliere SWSMaxSeqNum-1 dove MaxSeqNum è il massimo dei numeri di sequenza disponibili, non basta
• Se RWS=1, allora è sufficiente che MaxSeqNumSWS+1• Se RWS=SWS, la dimensione della finestra di invio non
può essere maggiore della metà del numero di sequenza disponibili, cioè
SWS < (MaxSeqNum+1) / 2Il protocollo sliding window considera alternativamente le due metà dello spazio dei numeri di sequenza
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.202
Gestione ack
• Nella direzione da host1 a host2 viaggiano i segmenti dati inviati da host1 a host2 e i segmenti di ack inviati da host1 a host2 (in risposta ai segmenti dati inviati da host2 a host1)
• Nella direzione da host2 a host1 viaggiano i segmenti dati inviati da host2 a host1 e i segmenti di ack inviati da host2 a host1 (in risposta ai segmenti dati inviati da host1 a host2);
• Il campo code bit serve a distinguere fra i due tipi di segmenti, dati e di ack, che viaggiano nella stessa direzione
26
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.203
Gestione ack migliorata: piggybacking
• Obiettivo: aspettare e combinare
• Nella direzione, per esempio, da host2 a host1 faccio viaggiare nello stesso segmento:– sia i dati che l’host2 deve inviare a host1– sia gli ack che host2 deve inviare a host1 in risposta ai
segmenti dati inviati da host1 a host2
• Piggybacking “portare sulle spalle”
Piggybacking
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.204
1 - 2 - 3 a 4 b 5 c 6 d 7 e 8 f ... .
a - b - c 1 d 2 e 3 f 4 g 5 h 6 ... .
Si sfrutta il flusso inverso opposto per portare gli ack dei pacchetti ricevuti
27
Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.205
Alcune domande sul TCP
• Perché è necessario il 3-way handshaking?
• Chi invia il primo segmento FIN: il server o il client?
• Una volta che la connessione TCP è stata stabilita, qual è la differenza tra le operazioni del livello TCP del server e del livello TCP del client?