|
|
Il controllo del flusso dei dati TCP è la regolazione dinamica del numero di pacchetti che possono essere spediti dal mittente prima che il destinatario faccia pervenire l’ACK sul primo di essi. In generale, questo numero di pacchetti si chiama finestra di scorrimento del protocollo. In poche parole la finestra a scorrimento denota il numero massimo di pacchetti inviabili senza aver ricevuto un ACK. Di seguito un esempio di finestra a scorrimento size N=3:
Se un software di rete, per spedire ciascun pacchetto di una sequenza, attende di aver ricevuto l’ACK su quello precedente, si dice che lavora con finestra costante (ed eguale a 1). Il controllo del flusso di TCP è invece a finestra variabile, perché prevede che la dimensione della finestra debba essere continuamente variata dal mittente durante la connessione, sulla base del valore che il destinatario specifica nel campo Window dell’ intestazione TCP degli acknowledgement. Si tratta di un aspetto un po’ ostico, ma estremamente importante di TCP, soprattutto quando alla rete sono collegate macchine molto diverse come velocità di elaborazione. Semplificando un po’, diremo che il valore del campo Window nell’intestazione di ciascun ACK (che, come abbiamo visto, detta istante per istante la dimensione della finestra usata dal mittente) viene calcolato dal software di rete TCP del computer destinatario sulla base della dimensione della zona che in quel momento è libera nel buffer di memoria in cui conserva i pacchetti che sono arrivati a destinazione ma non sono stati ancora inoltrati all’applicazione che li deve ricevere. Se, per qualche motivo, l’applicazione destinataria è lenta a consumare i pacchetti in arrivo dal mittente, il software di rete del destinatario “chiuderà” progressivamente la finestra, comunicando al mittente valori via via inferiori del campo Window, finché il valore del numero di pacchetti che il mittente é abilitato a inviare prima del prossimo ACK non diventerà nullo. Ci si potrebbe a questo punto chiedere come il mittente possa riprendere la trasmissione, visto che una nuova dimensione non nulla della finestra dovrebbe arrivargli dal destinatario attraverso un ACK, che però richiederebbe la trasmissione di un pacchetto.. Ebbene, quando riceve un ACK con valore di Window pari a zero, il mittente smette di inviare pacchetti di dati, ma continua a mandare piccoli pacchetti di sondaggio, che hanno appunto lo scopo di permettere al destinatario di rispondere con degli ACK. Prima o poi uno di questi ACK conterrà un valore di Window maggiore di zero, e il mittente riprenderà a spedire pacchetti di dati. Il meccanismo della finestra variabile funziona perfettamente sulle reti locali, dove il rallentamento di una connessione TCP dipende quasi sempre dalla differenza tra la velocità con cui il mittente produce pacchetti e il destinatario riesce a consumarli. La situazione è diversa sulle inter-reti composte da reti locali collegate da router, dove è importante che non solo il destinatario, ma anche ogni router intermedio posto sul cammino tra mittente e destinatario possa “frenare” il flusso dei dati che riceve, per evitare di esaurire la memoria locale e essere costretto a scartare dei pacchetti. Il meccanismo della finestra variabile non risolve quest' ultimo problema (detto congestione), che pure è estremamente importante per il buon funzionamento delle grandi reti TCP e di Internet. Lo standard TCP non prevede alcun meccanismo di controllo della congestione, lasciando agli implementatori del software di rete il compito di risolvere questo tipo di problemi. Una lecita domanda che può sorgere a questo punto è “cosa bisogna fare in caso di mancato arrivo di un pacchetto ACK?” Le strategie di controllo d'errore e ritrasmissione sono diverse (es. ARQ: Automatic Repeat Request). Se l'utente destinatario non invia al mittente un segnale ACK (Acknowledge) si possono avere tre modi distinti per rimediare gli errori:
Stop & wait: la sorgente non invia il pacchetto successivo finché non riceve l' ACK relativo al pacchetto precedente.
Go Back N: trasmetto N pacchetti ogniqualvolta ricevo gli ACK relativi agli N precedenti. Se sbaglio, cioè non ricevo uno degli ACK, invio di nuovo tutti gli N ultimi pacchetti.
Select repeat: in questo caso ritrasmetto solo il pacchetto o i pacchetti errati all'interno degli N inviati, nel caso di presenza d'errore. E' più efficiente, ma e' anche più difficile da implementare.
Per saperne di più consulta i seguenti approfondimenti:
Tutto quanto riportato in questa pagina è a puro scopo informativo personale. Se non ti trovi in accordo con quanto riportato nella pagina, vuoi fare delle precisazioni, vuoi fare delle aggiunte o hai delle proposte e dei consigli da dare, puoi farlo mandando un email. Ogni indicazione è fondamentale per la continua crescita del sito.