5 Protocolli Trasporto Parte3

1,282 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,282
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
31
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

5 Protocolli Trasporto Parte3

  1. 1. Parte 5 Modulo 13: Controllo di flusso Trasmissione dati nel TCP Processo applicativo Processo applicativo W rite Read bytes bytes … … TCP TCP Send buffer Receive buffer Segment Segment … Segment Trasmissione segmenti Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.154 1
  2. 2. Controllo di flusso Obiettivo: il mittente non deve riempire il buffer del destinatario inviando una quantità eccessiva di dati ad un tasso di trasmissione troppo elevato Il destinatario informa esplicitamente il mittente della quantità di spazio libero nel buffer ricezione TCP. La dimensione della finestra nel segmento TCP varia dinamicamente per cui ogni segmento ACK informa il mittente del numero massimo di byte ricevibili Window ricezione Dati provenienti Dati verso il Dati TCP dal livello IP livello applicazione nel buffer Buffer in ricezione IP TCP del livello TCP Applicazione Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.155 Controllo di flusso a livello di end-point L’ack è inviato a livello di segmento, per cui un solo ack vale 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 Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.156 2
  3. 3. 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.157 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 processo CONSEGUENZA: Un processo applicativo lento sul computer destinatario può provocare il blocco di un processo mittente veloce! Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.158 3
  4. 4. 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 riceve una AdvertisedWindow=0, continua ad inviare periodicamente un segmento con 1 byte di dati Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.159 Esempio: Sindrome della finestra cattiva Che cosa succede se il destinatario dà l’ACK appena ha 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 e byte inviati byte in attesa confermati 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 byte inviati e byte inviati confermati byte che verrà inviato subito Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.160 4
  5. 5. Possibili contromisure LATO 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 riduce troppo (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 RTT LATO 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.161 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 Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.162 5
  6. 6. 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 i  del tutto simile ad un “not ack” (NACK) sul segmento successivo i+1 Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.163 Parte 5 Modulo 14: Controllo di congestione 6
  7. 7. Controllo della congestione Congestione (def.): • Informalmente: “un numero elevato di sorgenti inviano contemporaneamente troppi dati generando un traffico che 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.165 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 Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.166 7
  8. 8. 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 decrease Esempio – 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.167 Controllo della congestione nel TCP SCELTA: Congestione end-to-end  nessuna informazione proveniente dalla rete Timeout e ritrasmissione contribuiscono ad aumentare la congestione TCP riduce il tasso di trasmissione in caso di congestione scegliendo il minimo tra: CongestionWindow (CW): dimensione della finestra di congestione AdvertisedWindow (AW): dimensione della finestra di ricezione Effective window = min(AW, CW) Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.168 8
  9. 9. Controllo della congestione nel TCP (2) • Misura delle prestazioni di una connessione TCP: - Throughput (tasso di trasmissione) w * MSS throughput = Bytes/sec RTT w = numero di segmenti nella finestra MSS = dimensione massima del segmento RTT = Round Trip Time • Valutazione della banda disponibile: • idealmente: trasmettere il più velocemente possibile senza perdita di segmenti (valore massimo di CongestionWindow) • incrementare CongestionWindow il più possibile, finché non si verifica un episodio di congestione • diminuire CongestionWindow, ricominciando poi a incrementarla nuovamente Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.169 Controllo della congestione nel TCP (3) 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 a congestione di una connessione la dimensione della finestra è pari a 1 • incremento progressivo (esponenziale) della dimensione della finestra • threshold: valore della dimensione della finestra, raggiunto il quale la fase di incremento esponenziale termina e si raggiunge lo stato stazionario di incremento lineare Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.170 9
  10. 10. Slow start del TCP Host A Host B Algoritmo di slow-start Inizializza: CW = 1 RTT for (ogni segmento ACK) CW=CW*2 until ((timeout OR (CW > threshold)) • log2N RTT prima di usare finestra di dimensione N  aumento esponenziale tempo Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.171 Calcolo CW: Algoritmo Tahoe Evitare la congestione (algoritmo dell’incremento additivo e decremento moltiplicativo): si incrementa esponenzialmente fino a threshold, e poi si incrementa di 1 Tahoe /* slow-start terminato */ /* CW > threshold */ if not(perdita) { ogni w segmenti ACK: CW++ } else { threshold = congwin/2; CW = 1; esegui slow-start } Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.172 10
  11. 11. Calcolo CW: Algoritmo Reno Si rilevano due tipi di errore Reno /* slow-start terminato */ - Timeout /* CW > threshold */  Riduci la window a 1 Until (loss event) { every w segments ACKed: CW++ - Tre ACK duplicati }  Non “esagera” come il threshold = CW/2 Tahoe riducendo la window a if (loss detected by timeout) { 1, ma diminuisce la finestra di CW = 1 metà perform slowstart } (MOTIVAZIONE: 1 segmento si è if (loss detected by triple perso, ma la rete funziona perché almeno 3 segmenti sono stati duplicate ACK) ricevuti dal destinatario) CW = CW/2 Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.173 Es., controllo congestione: Reno • Aumenta la window di 1 per RTT se non c’è perdita: CW++ destinatario W mittente • Riduci la window di metà se viene evidenziata una perdita con un triplo ACK duplicato: CW = CW/2 destinatario W mittente Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.174 11
  12. 12. TCP Reno e TCP Tahoe a confronto Al turno 8, si verifica una perdita di pacchetto (rilevata dal time-out nel Tahoe e da un triplo ACK nel Reno) 14 congestion window size (CW) 12 TAHOE: 10  threshold=CW/2 (segmenti) 8  CW=1 6 threshold 4 iniziale RENO: threshold  threshold=CW/2 2 dopo perdita 0  CW=threshold 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Turno di trasmissione TCP Series1 TCP Series2 Tahoe Reno NOTA: Il Reno utilizza il cosiddetto fast recovery: riprende da threshold e non da 1, ma con crescita lineare e non esponenziale Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.175 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 Usate in Linux 2.6.x, – CUBIC Adatte a LFN (Long Fat Networks) Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.176 12
  13. 13. 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 Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.177 TCP Reno vs. TCP Vegas • Individuazione della • Individuazione della perdita di pacchetti perdita di pacchetti – Timeout – Timeout basato su RTT – 3 ACK replicati – Verifiche basate su timer – Verifiche basate su a grana fine per ogni timer a grana grossa pacchetto (timer globale, 500 ms) Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.178 13
  14. 14. TCP Reno vs. TCP Vegas • Congestion detection • Congestion detection – Perdita di pacchetti – Aumento di RTT – Il throughput diventa • In caso di timeout o 3 insensibile al send rate ACK replicati: • Gestione della congestione – Si assume congestione separata da slow start: – Si esegue slow start o – Si considera una funzione fast recovery 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 Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.179 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 14
  15. 15. Analisi del protocollo TCP Reno Send window (buffer size) Congestion window Threshold slow start Pacchetti persi (invio) Pacchetti persi (rilevazione) Traffico Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.181 Analisi del protocollo TCP Vegas Send window (buffer size) Congestion window Slow start RTT Stima throughput Misurazione throughput Traffico Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.182 15
  16. 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 Parte 5 Modulo 15: UDP vs. TCP 16
  17. 17. 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 il controllo della congestione, numeri di sequenza ed acknowledgment) – un server può supportare un maggior numero di connessioni attive se usa UDP piuttosto che TCP Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.185 Perché usare UDP anziché TCP (cont.) • Overhead minore dovuto all’header del segmento 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 Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.186 17
  18. 18. 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.187 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 Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.188 18
  19. 19. Applicazioni e protocollo trasporto 1) Posta elettronica, accesso da terminale remoto, Web, trasferimento di file  TCP Necessario il servizio di trasferimento dati affidabile fornito da TCP 2) Aggiornamento tabelle di routing in RIP  UDP Aggiornamenti periodici delle tabelle  eventuali informazioni perse sostituite da informazioni più aggiornate Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.189 Applicazioni di rete per UDP 4) DNS query  UDP Si evitano i ritardi dovuti all’instaurazione della connessione 5) Telefonia Internet  UDP Tolleranza alla perdita di dati (no servizio affidabile) Tasso di trasmissione costante (no controllo di congestione) 6) Applicazioni multimediali  UDP TCP non può essere impiegato con multicast (problema della mancanza del controllo di congestione in UDP) Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.190 19
  20. 20. Parte 5 Modulo 16: Altre caratteristiche del TCP 20
  21. 21. 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 bottleneck TCP router connessione 2 (capacità R) Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.193 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 Limite della condivisione paritetica di banda perdita: decrementa window di un fattore 2 congestione evitata: incremento additivo perdita: decrementa window di un fattore 2 congestione evitata: incremento additivo Throughput connessione 1 R Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.194 21
  22. 22. Numeri di sequenza e acknowledgment Numero 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 di minimizzare la probabilità che sia presente un segmento identificato con lo stesso numero appartenente ad una connessione precedente con identici numeri di porta) Esempio: Si supponga di trasferire un file di 500000 byte, con MSS=1000 byte. I numeri sequenza saranno: X, X+1000, X+2000, … #seq #seq segmento 1 segmento 2 data for 500th segment Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.195 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 sta inviando 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 del successivo byte che A si aspetta di ricevere da B (tutti i byte precedenti 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 Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.196 22
  23. 23. Esempio Esempio 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 ricevuto tutti i byte fino a 42 - trasmette un dato Scopo unico: - avvisa l’host che ha ricevuto tutti i byte fino a 43 - il campo dati è vuoto Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.197 Protezione contro il Wrap around SequenceNum è a 32 bit Bandwidth Time until Wrap Around T1 (1.5 Mbps) 6.4 hours Ethernet (10 Mbps) 57 minutes T3 (45 Mbps) 13 minutes FDDI (100 Mbps) 6 minutes STS-3 (155 Mbps) 4 minutes STS-12 (622 Mbps) 55 seconds STS-24 (1.2 Gbps) 28 seconds Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.198 23
  24. 24. Mantenere la pipe piena AdvertisedWindow è a 16 bit Bandwidth Delay x Bandwidth Product T1 (1.5 Mbps) 18KB Ethernet (10 Mbps) 122KB T3 (45 Mbps) 549KB FDDI (100 Mbps) 1.2MB STS-3 (155 Mbps) 1.8MB STS-12 (622 Mbps) 7.4MB STS-24 (1.2 Gbps) 14.8MB Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.199 Attenzione alll’intervallo dei numeri di 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 relazione tra dimensione delle finestre e intervallo dei numeri di sequenza Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 6.200 24
  25. 25. 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 SWSMaxSeqNum-1 dove MaxSeqNum è il massimo dei numeri di sequenza disponibili, non basta • Se RWS=1, allora è sufficiente che MaxSeqNumSWS+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) / 2 Il protocollo sliding window considera alternativamente le due metà dello spazio dei numeri di sequenza Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.201 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 Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.202 25
  26. 26. 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” Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.203 Piggybacking 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 Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.204 26
  27. 27. 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? Protocolli e Architetture di Rete 2009/2010 – Livello Trasporto 5.205 27

×