Appunti di Reti

INSTAURAZIONE DELLA CONNESSIONE

L’instaurazione della connessione avviene secondo la procedura detta di “three-way handshake” che

serve a sincronizzare i numeri di sequenza in entrambe le direzioni:

1. La stazione che richiede la connessione (A) invia un segmento di

SYN (dove i parametri specificati sono il numero di porta

dell’applicazione cui si intende accedere e il proprio Initial Sequence

Number (ISN-A));

2. La stazione che riceve la richiesta (B) risponde con un segmento

SYNACK (in cui i parametri specificati sono l’ISN-B e il riscontro

(ACK) di ISN-A);

3. la stazione A riscontra il segmento SYN della stazione B (ISN-B)

mediante un ACK ( qui può esserci piggybacking, ossia A potrebbe

già includere il questo pacchetto i primi segmenti di dati relativi al

contenuto vero e proprio della connessione).

Calcolare il MSS (Maximum Segment Size)

Come calcola TCP la dimensione massima possibile per i pacchetti da inviare?

26

MSS dipende dalla MTU (Maximum Transfer Unit) del livello IP , che a sua volta dipende dal

livello Data-Link del collegamento con MTU più piccola lungo il percorso. Questo presuppone che

TCP abbia una conoscenza di quali tecnologie e risorse vengono sfruttate nella trasmissione dei dati

in qualsiasi punto e/o canale di comunicazione (ma ciò non è ovviamente possibile!). Purtroppo non

esistono nemmeno meccanismi di segnalazione per comunicare MSS. TCP può cercare quindi di

stimare la MTU minima (la MTU minima in tutto il percorso è idealmente la MSS valida per la

connessione) con un meccanismo di “trial and error”, provando ad inviare segmenti sempre più

grossi fino a quando uno viene scartato per dimensione eccessiva e il dispositivo che l’ha scartato

manda un messaggio ICMP (v. livello rete) al mittente (purtroppo non tutti i dispositivi lo inviano).

Default: MSS = 1460 (1500 trama ethernet – 40 byte di header)

27

Default “minimo”: MSS = 536 (576 MTU nella rete X25 – 40 byte di header)

**QUESTI NUMERI VANNO MEMORIZZATI AI FINI DELL’ESAME

TERMINAZIONE DELLA CONNESSIONE

Poiché la connessione è bidirezionale, la terminazione deve avvenire in entrambe le direzioni. Si

può avere una procedura di terminazione “gentle”:

(1) La stazione che non ha più dati da trasmettere e decide di chiudere la connessione invia un

segmento FIN (segmento con il campo FIN posto a 1 e il campo dati vuoto).

(2) La stazione che riceve il segmento FIN invia un ACK e indica all’applicazione che la

comunicazione è stata chiusa nella direzione entrante.

26 A livello IP i pacchetti potrebbero essere segmentati, ma questa azione è deprecata. Inoltre molti router si rifiutano

di segmentare i pacchetti e piuttosto lo scartano. Quindi se si vuole ottenere un protocollo di trasporto affidabile è

meglio attenersi alla MTU minima nel percorso.

27 Rete a commutazione di pacchetto ottenuta sulle reti telefoniche, una delle prime ad usufruire della suite

protocollare TCP/IP. Se questa procedura avviene solo in una direzione (half close), nell’altra

28

il trasferimento dati può continuare (gli ACK non sono considerati

come traffico originato, ma come risposta al traffico).

(3) Per chiudere completamente la connessione, la procedura di half close

deve avvenire anche nell’altra direzione.

Nell’esempio a fianco, A non ha più nulla da inviare a B e quindi gli invia un segmento di FIN. Dopo l’ACK

sul FIN di A, B invia gli ultimi dati richiesti da A (per i quali si aspetta comunque di ricevere i relativi ACK

da A). Finito di inviare i dati anche B chiude la connessione in maniera ‘gentle’, mediante un FIN (al quale

A si suppone debba sempre rispondere con un FINACK). Le risorse dedicate alla connessione vengono

liberate dopo 30 secondi dalla ricezione del FINACK.

La terminazione “gentle” è molto lenta e complessa. Si presta

inoltre ad attacchi DoS. La maggior parte delle applicazioni

moderne (soprattutto i grandi web server) terminano la connessione

con un singolo RST. RST nasce come “disaster recovery” per

liberare le risorse logiche in caso di impossibilità di comunicazione.

Se l’altro end-point della connessione riceve RST libera anche lui le

risorse logiche.

GESTIONE DEL TIMEOUT

Il timeout (RTO - Retransimission Time Out) indica il tempo entro il quale la sorgente si aspetta di

ricevere il riscontro (ACK) – nel caso in cui il riscontro non arrivi, la sorgente procede alla

ritrasmissione. Inizialmente il timer può essere tranquillamente fissato ad un valore anche piuttosto

alto, poi per questioni di efficacia e ottimizzazione (in caso di perdita dei pacchetti) dovrebbe essere

29

pian piano ridefinito dinamicamente di volta in volta in base a delle stime fatte sul RTT presente e

quelli passati (inerenti alla stessa connessione). RTO non può essere quindi un valore statico

predefinito, il tempo di percorrenza sperimentato dai segmenti è variabile e dipende:

• dalla distanza tra sorgente e destinazione;

• dalle condizioni della rete;

• dalla disponibilità della destinazione;

STIMA DEL RTT

SRTT[i] = (1- α)*SRTT[i-1] + α*RTT → “Peso” sempre meno i valori vecchi e, con un certo “peso”, aggiungo il valore nuovo

RTT = valore del campione attuale di RTT

SRTT = stima “smoothed” di RTT

i = istante i considerato

SRTT(1) = RTT(1)

SRTT(2) = (1-α)RTT(1) + αRTT(2)

SRTT(3) = ((1-α)^2)RTT(1) + (α)(1-α) RTT(2) + αRTT(3)

SRTT(i) = (j=1 to i)∑ [α(1-α)^(i-j)RTT(j)]

28 In una GET http, teoricamente il client potrebbe aprire la connessione con il server, richiedere il file e poi chiudere

la mezza connessione da lui al server, poichè sarà il server a dovergli inviare il file e il client avrà l’unico compito

di notificare la ricevuta dei segmenti mediante ACK

29 Si ricordi che RTT(Round Trip Time) per TCP corrisponde all’intervallo di tempo tra l’invio di un segmento e la

ricezione del riscontro di quel segmento (misurato in TCP mediante l’opzione timestamp).

Poiché RTT può variare anche molto in base alle condizioni della rete, il valore di RTT (SRTT,

Smoothed RTT) utilizzato per il calcolo di RTO risulta una stima del valor medio di RTT

sperimentato dai diversi segmenti. Il parametro α è regolabile e, a seconda dei valori assunti, rende

il peso della misura di RTT istantaneo più o meno incisivo

– se α è 0 il SRTT stimato risulta abbastanza stabile e non viene influenzato da singoli segmenti che

sperimentano RTT molto diversi

– se α è 1 il SRTT stimato dipende fortemente dalla misura puntuale dei singoli RTT istantanei

***tipicamente α = 0.125 = (1/8).

RTTVAR = (1- b)*RTTVAR + b*|SRTT – RTT|

RTTVAR = stima smoothed della varianza di RTT → Ci interessa la varianza nella finestra temporale considerata

**tipicamente b = 0.25 = (1/4)

Conoscere media e varianza di RTT serve a impostare correttamente il timeout di ritrasmissione.

STIMA DI RTO

RTO = SRTT + 4*RTTVAR

La sorgente attende il RTT medio (SRTT) più quattro volte la sua

varianza (RTTVAR) prima di considerare il segmento perso e

ritrasmetterlo. In caso di ritrasmissione, il RTO per quel segmento viene

ricalcolato in base ad un processo di exponential backoff:

– se è scaduto il RTO, probabilmente c’è congestione, quindi meglio

aumentare il RTO per quel segmento;

30

– RTO-retransmission = 2*RTO .

RTO viene riportato al suo valore “calcolato” senza backoff dopo la

31

trasmissione corretta di un segmento nuovo .

RTO ha un valore minimo (normalmente intorno a 200ms) e uno

massimo (normalmente 60s e oltre).

GESTIONE DELLA CONGESTIONE

Come è stato trattato nella gestione del timeout, i pacchetti possono andare persi. Ciononostante non

si è parlato di come questo possa avvenire. Esso è principalmente dovuto a condizioni di

congestione della rete. A causa dei buffer limitati degli apparati di rete, alcuni segmenti potrebbero

infatti venire scartati dagli stessi e quindi non arrivare mai alla reale destinazione. La perdita dei

segmenti e il relativo scadere del timeout di ritrasmissione è considerato da TCP un sintomo di

congestione, dal momento che non ha altri mezzi per conoscere lo stato della rete (si ricordi che è

un protocollo di livello 4 e possiede una semantica strettamente end-to-end). In taluni casi la

30 TCP ritrasmette il pacchetto per 16 volte max, di cui le prime 10 raddoppia il RTO. Fatto ciò, se non arriva ancora

nessun ACK, il trasmettitore si arrende.

31 Affermazione approssimata per semplificare “l’esplorazione didattica” del TCP 32

sorgente dovrebbe essere in grado di reagire diminuendo il tasso di immissione dei vecchi e/o

nuovi segmenti. Questa reazione viene detta “controllo della congestione” e si differenzia dal

controllo di flusso che serve invece ad evitare il sovraccarico del ricevitore.

Banalmente la congestione si verifica nel momento in cui le sorgenti offrono più traffico rispetto a

quello che la rete è in grado di smaltire. In termini matematici, è lo stato di una rete in cui il traffico

offerto η è maggiore della capacità della rete C:

normalizzando ρ = η/C, se ρ >= 1 significa che si ha uno stato di congestione

•

Esemplificando (e semplificando)….

Se S1 e S2 hanno una capacità di inviare pacchetti a 100 Mbit/s e inviano allo stesso momento, il ruoter di fronte al

canale di rete evidenziato dall’immagine(da 100 Mbit/s), dovrà memorizzare in un buffer metà dei dati da inviare. Ora

il problema è insito nel fatto che i buffer NON sono infiniti e prima o poi si esauriranno. Esauriti i buffer disponibili

degli apparati di rete, questi sono costretti a scartare i pacchetti e si ha la cosiddetta congestione.

Si noti che in molti casi la congestione non è detto che sia necessariamente ed esclusivamente a

livello dei canali di rete, ma potrebbe facilmente essere anche a livello delle unità di

33

commutazione . Tutto questo non interessa nulla a TCP (nemmeno lo sa), poiché l’unica cosa che è

in grado di notare è il fatto che alcuni pacchetti sono andati persi.

Idealmente si supponga che la capacità della rete sia condivisa da n host e che, per ciascuna

sorgente, il suo traffico in uscita (λ ) cresca linearmente con il traffico smaltito assumendo come

in

limite massimo un valore pari a λ = C/n.

in

Si ipotizzi ora che i buffer degli apparati

siano illimitati, in tal caso le ritrasmissioni

non sono necessarie, ma mano a mano che

ci si avvicina alla propria capacità

massima (C/n) il ritardo cresce in mani