Tlc10 21 Transport layer TCP UDP -...

1

21: 21: TransportTransport layerlayer: TCP e UDP: TCP e UDP

1

R. Cusani - F. Cuomo, Telecomunicazioni - Data link layer: Protocolli, Maggio 2010

SommarioSommario

� Trasporto in TCP/IP

� User Datagram Protocol (UDP)

� Transmission Control Protocol (TCP)

� MTU, RTU, MSS

� Controllo della congestione

� Header TCP

2


2

TrasportoTrasporto in TCP/IPin TCP/IP

� TCP/IP utilizza due protocolli di trasporto

⇒ UDP (User Datagram Protocol): protocollo inaffidabile, connection- less

⇒ TCP (Transmission Control Protocol): connection –oriented, affidabile

� Entrambi forniscono una interfaccia agli applicativi per la trasmissione dei dati,

ed utilizzano IP per il trasporto dei dati (e, nel caso di TCP, delle informazioni di

controllo del protocollo)

� Esiste una interfaccia di programmazione, chiamata socket, standardizzata per

il linguaggio C (esistono implementazioni di interfacce al socket anche per altri

linguaggi, ad esempio per il perl )

� Questo rende possibile scrivere applicazioni specifiche (home-made) che

debbano far uso della rete di trasmissione dati in aggiunta agli applicativi

standardizzati già esistenti (generalmente forniti con il sistema operativo)

3


Indirizzamento del trasporto in TCP/IPIndirizzamento del trasporto in TCP/IP

� Le applicazioni che utilizzano il TCP/IP si registrano sullo strato di trasporto

ad un indirizzo specifico, detto porta, pari a un numero di 16 bit (da 1 a 65535;

la porta 0 non e’ utilizzata)

⇒ permette ad una applicazione di identificare l’applicazione remota a cui

inviare i dati

� TCP/IP permette alla applicazione di registrarsi su una porta definita dalla

applicazione (come nel caso dei server) o su una qualunque porta libera

scelta dal livello di trasporto (spesso e’ il caso dei client)

� Per rendere funzionali i servizi di utilizzo diffuso, TCP/IP prevede che

determinati servizi utilizzino dal lato server delle porte ben definite

⇒ il valore dei numeri di porta vengono specificati negli RFC che

definiscono il protocollo delle applicazioni in questione

4


3

Indirizzamento del trasporto in TCP/IPIndirizzamento del trasporto in TCP/IP

� Esiste una autorita’ centrale, lo IANA (Internet Assigned Numbers Authority),

che pubblica la raccolta dei numeri di porta assegnati alle applicazioni negli

RFC (http://www.iana.org)

� IANA centralizza la gestione anche di altro, come:

⇒ assegnazioni dei numeri di protocollo dei diversi protocolli di trasporto

utilizzati nel protocol number di IP

⇒ l’assegnazione dei domini di primo livello (nomi) del DNS

5


User Datagram Protocol (UDP)User Datagram Protocol (UDP)

� Realizza un servizio di consegna inaffidabile dei dati a destinazione

� Riceve i dati dalla applicazione e vi aggiunge un header di 8 byte, costruendo

cosi’ il segmento da inviare

� L’applicazione definisce (l’indirizzo di rete e) la porta di destinazione, ed in

ricezione UDP recapita il campo dati al destinatario

� UDP non si preoccupa di sapere nulla sul destino del segmento inviato, ne’

comunica alla applicazione qualsiasi informazione

� Costituisce una semplice interfaccia ad IP (che fornisce lo stesso tipo di

servizio), i più esegue multiplexing del traffico delle applicazioni su IP tramite il

meccanismo delle porte a cui sono associate le applicazioni

6


4

UDP orientato al datagrammaUDP orientato al datagramma

� A differenza di TCP, UDP si occupa di un datagramma per volta

� quando una applicazione passa dati ad UDP, UDP li maneggia in un unico

segmento, senza suddividerlo in pezzi

� il segmento di massime dimensioni che UDP puo’ gestire deve stare

interamente nel campo dati del pacchetto IP

� il segmento viene passato ad IP che eventualmente lo frammenta, ma a

destinazione UDP ricevera’ il datagramma intero

� l’applicazione di destinazione ricevera’ quindi il blocco completo di dati inviato

dalla applicazione che li ha trasmessi in un unico segmento

7


Il segmento UDPIl segmento UDP

� E’ costituito da un header di lunghezza fissata (8 byte) piu’ il campo dati, che

deve avere dimensione massima tale da stare dentro il campo dati di IP

⇒ poiche’ il pacchetto IP puo’ essere lungo 65535 byte, il campo dati UDP

puo’ essere lungo al massimo (65535 – 8 – lunghezza header IP) byte

� UDP header presenta 4 campi di due byte

� source e destination port: porte di associazione alle applicazioni mittente e

destinataria dei dati

� length: lunghezza del segmento in byte (compreso l’header)

8


5

UDP headerUDP header

� checksum: contiene una checksum del segmento completo (viene aggiunto uno

pseudo-header con le informazioni degli indirizzi IP di sorgente e destinazione)

� Checksum è opzionale, l’applicativo può decidere di non utilizzarlo (in questo

caso il campo e’ riempito con zeri) � molti applicativi non loutilizzano il per

motivi di efficienza

� se viene utilizzato, un errore provoca la rimozione del segmento senza che

vengano prese altre iniziative

9


Caratteristiche di UDPCaratteristiche di UDP

� Benché inaffidabile, UDP è appetibile per molte applicazioni

� Può utilizzare trasmissione multicast o broadcast

⇒ TCP e’ un protocollo orientato alla connessione, quindi per definizione

non puo’ gestire una comunicazione tra più di due entità

� è molto leggero, quindi efficiente

⇒ la dimensione ridotta dell’header impone un overhead minimo, ed una

rapidita’ di elaborazione elevata

⇒ la mancanza di meccanismi di controllo rende ancora più rapida

l’elaborazione del segmento e non introduce ritardi dovuti ad eventuali

ritrasmissioni

10


6

Applicativi che utilizzano UDPApplicativi che utilizzano UDP

� Applicativi che necessitano di trasmissioni broadcast

� Applicativi dove la perdita di una porzione di dati non e’ essenziale, ma

richiedono un protocollo rapido e leggero � streaming voce/video

� Applicativi che si scambiano messaggi (e non flussi di byte) di piccole

dimensioni, e che non risentono della perdita di un messaggio

⇒ interrogazione di database

⇒ sincronizzazione oraria

⇒ in questi casi la perdita della richiesta o della risposta provoca un nuovo

tentativo di interrogazione

11


Applicativi che utilizzano UDPApplicativi che utilizzano UDP

� Applicativi che necessitano di risparmiare l’overhead temporale provocato

dalla connessione, ed implementano a livello di applicazione il controllo della

correttezza dei dati

⇒ ad esempio applicativi che scambiano dati con molti host, rapidamente,

per i quali dover stabilire ogni volta una connessione e’ peggio che

ritentare se qualcosa va storto

12


7

Applicativi standard su UDPApplicativi standard su UDP

� Sono molti, ed in aumento

� Gli applicativi che storicamente utilizzano UDP sono

⇒ DNS, sulla porta 53

⇒ TFTP (Trivial File Transfer Protocol), sulla porta 69

⇒ NetBIOS Name Service (anche WINS) sulla porta 137

⇒ SNMP (Simple Network Management Protocol) sulla porta 161

⇒ NTP (Network Time Protocol) sulla porta 123

⇒ NFS (Network File System) via portmap

13


Transmission Control ProtocolTransmission Control Protocol

� TCP e’ stato progettato per offrire un flusso di byte affidabile orientato alla

connessione

� TCP offre i seguenti servizi allo strato applicativo:

⇒ protocollo orientato alla connessione

⇒ affidabilita’ dei dati (controllo, ritrasmissione, ordinamento)

⇒ gestione del controllo di flusso

⇒ gestione della congestione

14


8

Trasmissione dei dati in TCPTrasmissione dei dati in TCP

� TCP trasmette dati in segmenti, ciascuno costituito da un header ed un

campo dati

� TCP considera i dati da trasmettere come flusso di byte (a differenza di UDP

che opera in termini di messaggi)

� TCP utilizza buffer in trasmissione e ricezione per la gestione dei dati

⇒ TCP non invia necessariamente i dati appena li riceve dalla applicazione:

per motivi di efficienza puo’ tenere nei buffer i dati da inviare fino a che

non ce ne siano abbastanza per evitare messaggi troppo piccoli

� L’informazione sul numero di sequenza e’ quindi riferito al byte trasmesso, ed

e’ utilizzato sia per l’acknowledge che per il riordinamento e la ritrasmissione

15


Dimensione del segmento TCPDimensione del segmento TCP

� Il segmento TCP e’ costituito da un header di 20 byte (piu’ campi opzionali,

come in IP) seguito dal campo dati

� La dimensione massima del segmento TCP deve stare nel campo dati di un

pacchetto IP

⇒ poiche’ il pacchetto IP ha lunghezza massima 65535 byte, con un header

di 20 byte, il campo dati di TCP avra’ valore massimo 65495 byte (ma in

caso di utilizzo di intestazione estesa sara’ meno)

16


9

MTU (Maximum Transfer Unit)MTU (Maximum Transfer Unit)

� Ogni rete e’ caratterizzata dall’avere un valore massimo della dimensione del campo

dati nel frame a livello 2

� Questa lunghezza si chiama MTU (Maximum Transfer Unit)

⇒ nel caso di Ethernet, la MTU e’ di 1500 byte

� Ogni volta che IP deve inviare un pacchetto piu’ grande della MTU deve

frammentare

� Per motivi di efficienza TCP tiene conto di questo, e la MTU solitamente definisce la

dimensione massima del segmento TCP (meno i 20 byte dell’header IP)

⇒ va osservato che TCP non sa nulla sulla eventuale intestazione estesa di IP,

che potrebbe ridurre il campo utile nel pacchetto IP: in questo caso si avrebbe

frammentazione

17


MRU: MRU: MaximumMaximum ReceiveReceive UnitUnit,,MSS (MSS (MaximumMaximum SegmentSegment SizeSize))

� Per tentare di raggiungere la massima efficienza, i due lati della connessione TCP si

scambiano le informazioni delle rispettive MTU, in modo che il trasmittente possa

correttamente dimensionare i segmenti in base al valore minimo tra le due MTU

(quella in ricezione viene chiamata MRU: Maximum Receive Unit) per definire la

MSS (Maximum Segment Size)

MSS = min(MTU,MRU) – 20 byte

� In caso di mancanza di informazioni (dipende dalle implementazioni del TCP) viene

utilizzato come valore di default 536 byte (il valore di default del pacchetto IP: 576

bytes meno i 20 byte di header IP e meno i 20 byte dell’header TCP

18


10

Connessione TCPConnessione TCP

� TCP utilizza per la connessione il meccanismo di handshake a 3 vie

⇒ un segmento (SYN) viene inviato dal client al server; questo trasporta il

sequence number iniziale del client, e le informazioni di porta sorgente e

destinazione

⇒ un segmento (SYN+ACK) viene inviato in risposta dal server; questo

trasporta l’acknowledge del SYN precedente, ed il sequence number

iniziale del server, per le comunicazioni in verso opposto

• se nessuno ascolta sulla porta di destinazione, il server inviera’ un

segmento RST (Reset) per rifiutare la connessione

⇒ un segmento di ACK viene inviato dal client al server; questo riporta lo

stesso sequence number iniziale (non sono ancora stati trasmessi dati) e

l’acknowledge del secondo segmento SYN

19


Connessione TCPConnessione TCP

� A questo punto la connessione viene considerata stabilita (la connessione e’

definita dalla quaterna host1-port1-host2-port2)

� I messaggi di SYN possono opzionalmente trasportare le informazioni di

MTU/MRU per determinare il MSS della connessione

20


11

Disconnessione TCPDisconnessione TCP

� La connessione TCP e’ full duplex

� Per la disconnessione, si utilizza un handshake a due vie per ogni direzione:

⇒ chi vuole disconnettere invia un segmento FIN

⇒ l’altro invia un ACK del FIN: il primo considera chiusa la comunicazione

in quel verso, ma non nel verso opposto

⇒ la stessa cosa fa il secondo quando non ha piu’ dati da trasmettere, ed

aspetta il relativo ACK

⇒ il tutto spesso viene fatto con tre segmenti, inviando il secondo FIN

assieme all’ACK del primo

� Vengono utilizzati dei timer per aggirare il problema dei due eserciti

21


ControlloControllo di di flussoflusso

� Viene comunicato lo spazio

(byte liberi) nei buffer

disponibile in ricezione

� Permette al ricevente di

regolare la trasmissione del

trasmittente in modo

disgiunto dagli ack

� La dimensione della finestra

(quanti segmenti si possono

inviare) e’ data dal rapporto

tra i byte a disposizione e il

valore del MSS

22


12

Controllo della congestioneControllo della congestione

� Accanto alla finestra di ricezione (legata ai buffer) viene utilizzata una finestra di

congestione: il limite a cui si puo’ trasmettere e’ il minimo tra la finestra di

ricezione e quella di congestione

� Per prevenire le congestioni, il TCP utlizza una tecnica detta “slow start”:

⇒ inizialmente il trasmittente inizializza la finestra di congestione al valore del

MSS, ed invia un segmento

⇒ se il segmento riceve l’ACK, raddoppia la finestra di congestione, e via

cosi’ fino al massimo valore determinato dalla finestra di ricezione, o fino a

che si incontra un timeout; questo valore viene quindi mantenuto per la

comunicazione

23


Controllo della congestioneControllo della congestione

⇒ in base alla insorgenza di timeout o di ack duplicati (o di ICMP source

quench), il trasmittente puo’ valutare l’insorgere di una congestione

⇒ quando questo avviene, la finestra di congestione viene ridotta ad un MSS,

ed una soglia viene impostata alla meta’ del valore precedente (il limite

raggiunto dallo startup lento)

⇒ riprende la progressione iniziale, ma solo fino al valore di soglia, oltre il

quale si incrementa la dimensione di un MSS per volta

� In questo modo il TCP tenta di prevenire la congestione (con l’avvio lento), ed

abbatte immediatamente la trasmissione di segmenti quando la congestione

inizia a presentarsi, risale rapidamente fino ad un certo valore per non perdere in

efficienza e poi piu’ lentamente per non ricreare le condizioni di congestione

24


13

Il Il protocolloprotocollo TCP: slow startTCP: slow start

� Iniziare a trasmettere lentamente, e, se tutto va bene accelerare, salvo poi rallentare qualora le cose andassero male

⇒ receiver window (rwnd)= finestra comunicata dal destinatario (controllo di flusso)

⇒ congestion window (cwnd) = decisa dal mittente (controllo di congestione)

⇒ cwnd=min(cwnd, rwnd)⇒ SMSS=dimensione massima del segmento⇒ IW = valore iniziale di cwnd = <2 SMSS

25


Il Il protocolloprotocollo TCP: slow start (cont.)TCP: slow start (cont.)

⇒ ogni volta che il mittente riceve un riscontro (non duplicato), cwnd= cwnd + SMSS

• il mittente trasmette un segmento ed aspetta il relativo riscontro • quando lo riceve (non duplicato), aumenta di SMSS la cwnd e può

quindi emettere due segmenti • quando entrambi questi sono riscontrati, cwnd è portata a 4 SMSS• si ha così un incremento esponenziale di cwnd • l’aumento di cwnd continua finché si raggiunge un’opportuna soglia,

denominata “slow start threshold” (ssthresh)• oppure fin quando il mittente non rilevi una situazione di congestione

(dedotta dallo scadere del TO)

26


14

Il Il protocolloprotocollo TCP: TCP: congestion avoidancecongestion avoidance

� Algoritmo (continuazione di slow start):

⇒ il mittente può trovarsi in due stati: Congestion Avoidance e Slow Start⇒ ssthresh è inizializzata ad un valore alto così da non avere effetto nelle

fasi iniziali • quando cwnd < ssthresh si applica Slow Start• quando cwnd > ssthresh si applica Congestion Avoidance (quando

cwnd=ssthresh la scelta è libera)

27



⇒ la ricezione di un riscontro non duplicato determina l’aumento di cwnd• se si è in slow start cwnd è incrementata in modo esponenziale• se si è in congestion avoidance: cwnd è incrementata di

segsize*segsize/cwnd ogni volta che si riceve un segmento, dove segsize è la dimensione di un segmento e cwnd è misurata in bytes: ciò corrisponde ad un incremento lineare (un segmento per ogni RTT)

⇒ quando si verifica una congestione (= scadere di un time-out):• ssthresh posta ad un valore non superiore a: max(FlightSize/2,

2*SMSS), dove FlightSize è la quantità di dati emessa dal mittente ma non ancora riscontrata (sstresh è circa dimezzata)

• cwnd è posta ad un valore pari a 1 segmento, da cui ricomincerà ad essere aumentata

28


15


� La quantità di dati trasmessi ma non ancora riscontrati non può superare il minimo tra cwnd e rwnd; tale minimo è quindi il valore corrente della finestra usata in trasmissione

� L’unione degli algoritmi slow start e congestion avoidance ha dato luogo ad una versione di TCP nota come “TCP Berkeley“

29


Il protocollo TCP: SS+CA=“Il protocollo TCP: SS+CA=“TCP BerkeleyTCP Berkeley““

⇒ andamento a “dente di sega”: la portata media può essere molto minore del valore massimo

02468

10121416182022242628303234363840

0 5 10 15 20 25 30

Fin

estr

a di

con

gest

ione

, cw

nd

(pas

si d

a 10

24 b

ytes

)

Threshold (ssthresh )

Threshold (ssthresh)

Timeout

Numero di trasmissioni

Slow start

Congestion avoidance

30


16

Il protocollo TCP: Il protocollo TCP: fast retransmitfast retransmit

� Fast retransmit è pensato per migliorare il controllo di errore ma ha effetti anche sul controllo di congestione

� TCP dovrebbe (SHOULD) generare un riscontro immediato (un ACK duplicato) quando riceve un segmento fuori sequenza:

⇒ TCP NON riscontra il segmento ricevuto fuori sequenza, bensì, alla ricezione di un segmento ricevuto fuori sequenza, riscontra nuovamente l’ultimo segmento ricevuto in sequenza completa (ovvero emette un duplicato di un riscontro già emesso)

⇒ TCP mittente non sa perché riceve un ACK duplicato• quando si perde un segmento, tutti i segmenti successivi a quello perso che

arrivano al destinatario genereranno ACK duplicati• se la rete altera la sequenza dei segmenti, questi arriveranno a destinazione

fuori sequenza e genereranno ACK duplicati• la rete potrebbe duplicare degli ACK o dei segmenti dati (che quindi

genererebbero ACK duplicati, al loro arrivo a destinazione)

31


Il protocollo TCP: Il protocollo TCP: fast retransmit (cont.)fast retransmit (cont.)

� Se l’ACK duplicato è dovuto a perdita conviene rinviare subito il segmento perso, altrimenti no

⇒ se il mittente riceve solo uno o due ACK duplicati assume che si tratti di un fuori sequenza

⇒ se il mittente invece riceve tre o più ACK duplicati successivi (ovvero 4 ACK identici senza altri segmenti intermedi), ritrasmette subito quello che ritiene un segmento perso, senza aspettare lo scadere del time-out

⇒ questo è fast retransmit (di fatto implementa un NACK)

� Migliora le prestazioni in caso di perdita di un segmento

⇒ velocizza la ri-trasmissione del segmento

32


17

ESEMPIO:Senza Fast Retransmit

ack=100

ack=100

ack=100

ack=100

TO

Valore attualedi cwnd = 6

Porre cwnd = 1, ritrasmettere il segmento seq=100

ack=400!Ripartire con cwnd=2 e trasmettere seq=400, 450, etc.

ack=100ack=100

Il protocollo TCP: fast Il protocollo TCP: fast retransmitretransmit ((contcont.).)33


ack=100

ack=100

ack=100

TO

Porre cwnd = 1, ritrasmettere segmento con seq=100

ack=400!

ack=100

ack=100


ESEMPIO, con Fast Retransmit:l’errore è recuperato in un tempo minore

Ripartire con cwnd=2 e inviare seq=400, 450, etc.

ack=100

Il protocollo TCP: fast Il protocollo TCP: fast retransmitretransmit ((contcont.).)34


18

Il protocollo TCP: Il protocollo TCP: fast retransmit (cont.)fast retransmit (cont.)

� Slow Start + Congestion Avoidance + Fast Retransmit = “TCP Tahoe”

� TCP Tahoe, dopo Fast Retransmit va nella fase di Slow Start, poiché assume che un segmento sia stato perso, e pone cwnd=1

� Questo modo di operare è però forse troppo conservativo visto che, siccome si stanno ricevendo degli ACK, la rete non dovrebbe essere in uno stato di congestione, anche se un segmento è stato perso

35


Il protocollo TCP: Il protocollo TCP: fast recoveryfast recovery

� fast recovery=

⇒ quando l’entità mittente trasmette subito quello che ha dedotto essere un segmento perso, senza aspettare lo scadere del time-out, essa non entra nello stato di slow start, ma segue una diversa procedura (basata su Congestion Avoidance)

⇒ ciò consente di aumentare la portata del trasferimento• Cioè: abbiamo perso ma non c’e’ congestione, visto che dei

segmenti STANNO arrivando a destinazione, e quindi è meglio non rallentare

� Slow Start + Congestion Avoidance + Fast Retransmit + Fast Recovery= “TCP Reno”

36


19

Inizio di Fast Retransmit eFast Recovery:

ssthresh=3;cwnd=3+3

cwnd=3+4

cwnd=3+5

Recovery ack=400cwnd=3


Il protocollo TCP: fast Il protocollo TCP: fast recoveryrecovery ((contcont.).)

Esempio con Fast Recovery

37


ConfrontoConfronto tratra Tahoe e RenoTahoe e Reno

02468

10121416182022242628303234363840

0 5 10 15 20 25 30

Fin

estr

a di

con

gest

ione

, cw

nd (

pass

i da

1024

byt

es)

Threshold (ssthresh )

Threshold (ssthresh)

Rilevazione di evento di perdita

Slow start

Congestion avoidance

Andamento seguito se la perdita è stata rilevata da un TO e, in ogni caso, da Tahoe

Esempio di andamento seguito da TCP Reno se la perdita è stata rilevata dalla ricezione di 3 ACK duplicati

Turni di trasmissione

38


20

⇒ Simulazione di TCP Reno: una connessione di capacità C attraversa un router con buffer di dimensione B, che è un collo di bottiglia.

⇒ curva 1, B=C*RTT⇒ curva 2, B=0.1*C*RTT

Esempio di evoluzione TCPEsempio di evoluzione TCP39


Esempio di evoluzione TCPEsempio di evoluzione TCP

⇒ Simulazione di TCP Reno (mostra anche un TO)⇒ rtt=20ms⇒ C=10Mbit/s⇒ finestra ricezione massima 64kbyte⇒ dimensione pacchetti 1000 byte⇒ buffer=C*rtt

40


21

Esempio di evoluzione TCPEsempio di evoluzione TCP

⇒ Simulazione di TCP Reno⇒ Finestra “gonfiata” in fast recovery⇒ rtt=10ms⇒ C=10mbit/s⇒ buffer=C*rtt

41


Ack parziale (300).Sarebbe stato un Ack “totale”, con il riscontro di tutti i dati emessi prima di iniziare il Fast Retransmit,se fosse stato ack=400

Fast Retransmit eFast Recovery

Il protocollo TCP: Il protocollo TCP: NewRenoNewReno

Perdite multiple e New Reno

42


22

Il protocollo TCP: commentiIl protocollo TCP: commenti

� Congestione dedotta da perdita

⇒ (ciò causa problemi in canali rumorosi, e.g., wireless)

� Perdita dedotta da:

⇒ scadere del time-out di trasmissione⇒ ricezione di riscontri (ACK) duplicati (vedi fast retrasmit)

43


HeaderHeader TCPTCP44


23

Header TCP (cont.)Header TCP (cont.)

� source e destination port: le porte del sorgente e del destinatario, che per-

mettono di identificare le applicazioni a cui sono destinati i dati (16 bit ciascuna)

� sequence number (32 bit): il valore del primo byte trasmesso nel segmento;

all’atto della connessione viene stabilito il valore iniziale, basato sul clock del

trasmittente

� acknowledge number (32 bit): il valore dell’ultimo byte riscontrato piu’ uno (cioe’

del successivo atteso)

� TCP header length (4 bit): il numero di gruppi di 32 bit contenuti nella intesta-

zione; necessario perche’ sono previsti campi opzionali (non piu’ di 60 byte)

45



� flag URG (urgent): il campo dati contiene dati urgenti, che devono essere passati

alla applicazione prima degli altri ancora in attesa nei buffer (ad esempio: il

CTRL^C in applicazioni di terminale remoto)

� flag ACK: il segmento trasporta un riscontro; tutti i segmenti tranne il primo

dovrebbero averlo definito ad 1

� flag PSH (push): indica che l’applicativo ha richiesto l’invio dei dati senza ulteriore

attesa (ed in ricezione deve essere fatto lo stesso)

� flag RST (reset): utilizzato per comunicare che la connessione deve essere

abortita, o quando viene rifiutata una nuova connessione

� flag SYN (synchronize): utilizzato per stabilire una connessione; questi segmenti

definiscono il sequence number iniziale per i due versi

� flag FIN (finish):; utilizzato per comunicare alla controparte che non si hanno più

dati da inviare e che si desidera chiudere la connessione; il doppio FIN con

relativo riscontro genera il rilascio della connessione

46


24


� window size (16 bit): la dimensione in byte dello spazio disponibile dei buffer

in ricezione: il valore massimo e’ di 64 KB

⇒ le reti moderne molto veloci rendono questo limite inefficiente: e’

possibile utilizzare un header opzionale per accordarsi su una window

size a 30 bit (buffer fino ad 1 GB)

� checksum (16 bit): obbligatoria per TCP (al contrario di UDP); anche in TCP

la checksum viene calcolata su tutto il segmento piu’ uno pseudo header che

riporta gli indirizzi IP di sorgente e destinazione

� urgent pointer (16 bit)

⇒ definisce l’offset dell’ultimo byte facente parte dei dati urgenti quando la

flag URG e’ settata

47


Header opzionaliHeader opzionali

� Le opzioni sono definite da una lunghezza, un tipo, ed i dati relativi; sono

definite diverse opzioni, tra cui:

⇒ padding: necessario in presenza di opzioni per rendere il campo header nel

suo complesso un multiplo di 32 bit

⇒ MSS: utilizzato con i segmenti SYN per determinare il MSS scambiandosi i

valori di MTU ed MRU

⇒ window scale: utilizzata per definire la dimensione della finestra fino a 30

bit

⇒ selective acknowledge: TCP utilizza normalmente il go-back-N; questa

opzione permette di utilizzare il selective reject

⇒ timestamp: utilizzata per valutare (a livello di trasporto) il round trip time e

poter definire valori opportuni per i timer interni

48


25

Applicazioni che usano TCPApplicazioni che usano TCP

� Tutte quelle che richiedono affidabilita’ dei dati, e che non hanno bisogno

della comunicazione multicast/broadcast

⇒ la comunicazione in TCP e’ orientata alla connessione tra due punti

terminali; non puo’ quindi supportare multicast

� Esistono tantissime applicazioni; tra le piu’ diffuse:

⇒ file transfer (port 21)

⇒ login remoto criptato (ssh, port 22)

⇒ login remoto (port 23)

⇒ posta elettronica (port 25)

⇒ TFTP (port 69) (esiste anche su UDP)

⇒ HTTP (port 80) (il protocollo del World Wide Web)

49


Tlc10 21 Transport layer TCP UDP -...

Documents

Transcript of Tlc10 21 Transport layer TCP UDP -...