In telecomunicazioni e informatica il TCP tuning è una tecnica che consiste nell'impostare adeguatamente i parametri del controllo della congestione delle connessioni TCP su reti a banda larga e latenza elevata. Le reti impostate in maniera corretta possono avere prestazioni più elevate anche più di 10 volte, in qualche caso.[1] Comunque, l'esecuzione delle istruzioni per il TCP tuning senza la comprensione delle reali conseguenze potrebbe influenzarne in maniera negativa le prestazioni della connessione.

Caratteristiche di Rete e di Sistema modifica

Bandwidth-delay product (BDP) modifica

Il Bandwidth-delay product (BDP) è un termine usato originariamente in relazione con il TCP per indicare il numero di byte necessari a riempire un "percorso" TCP, es.: è pari al numero massimo di bit in transito simultaneamente tra mittente e destinatario.

Le reti con elevate prestazioni hanno dei BDP molto grandi. Per fornire un esempio pratico, due nodi comunicano tramite il collegamento di un satellite geostazionario con un round trip delay di 0,5 secondi a un'ampiezza di banda di 10 Gbit/s può avere più di 0.5×1010 bit, per esempio, 5 Gbit = 625 MB di dati non ancora riscontrati in transito.

Nonostante abbiano meno latenza dei collegamenti satellitari, anche i collegamenti in fibra possono avere BDP molto grandi dovuti non alla latenza, ma all'elevata ampiezza di banda. I sistemi operativi e i protocolli meno recenti, sviluppati quando le reti erano più lente, sono stati configurati con valori di BDP relativamente bassi, implicando così un limite nel raggiungimento di prestazioni ottimali.

Buffers modifica

Le configurazioni originali del TCP supportano buffer con dimensioni della finestra di ricezione TCP a partire da 65,535 Bytes (64 KiB-1), adeguate per collegamenti lenti o con valori di round trip time (RTT) piccoli. Buffer più grandi sono richiesti per le opzioni di alte prestazioni descritte qui sotto. Il buffering è usato nelle reti ad alte prestazioni per gestire i ritardi nel sistema. In generale, la dimensione dei buffer ha bisogno di essere dimensionata in proporzione alla quantità di dati "in transito" ad ogni momento.

Limiti di velocità del TCP modifica

Il throughput massimo ottenibile per una connessione TCP è determinato da diversi fattori. Una limitazione banale è la massima larghezza di banda del collegamento più lento nel percorso. Ma ci sono anche altri limiti meno evidenti per il throughput TCP. Gli errori di bit possono creare una limitazione per il collegamento così come i round-trip time.

Ampiezza Finestra modifica

  Lo stesso argomento in dettaglio: TCP window scale option e Congestion window.

Nel computer networking, RWIN (TCP Receive Window) è la quantità di dati che un computer può accettare senza mandare un riscontro al mittente. Se il mittente non ha ancora ricevuto l'acknowledgement del primo pacchetto inviato, si stoppa e attende il riscontro, se l'attesa supera un certo limite, il pacchetto viene ritrasmesso. Così il TCP implementa il trasferimento dati affidabile.

Anche se non c'è perdita di pacchetti nella rete, la finestra di ricezione può limitare il throughput. A causa della trasmissione TCP ristretta alla taglia della finestra di ricezione, e alla necessità della ricezione di un riscontro, potrebbero verificarsi casi in cui la totale grandezza di banda non viene sfruttata. I limiti causati dalla taglia della finestra possono essere calcolati così:

 

Dove RWIN è la finestra di ricezione TCP e RTT è il round-trip time per il percorso.

Per ogni segmento ricevuto, viene segnalata la quantità di spazio libero allocato per la connessione tramite un apposito campo dell'intestazione del segmento TCP. Altrimenti ci sarebbe il rischio di perdita di pacchetti dovuta alla mancanza di spazio nei buffer di ricezione, ovvero overhead dei buffer.

Il lato che trasmette dovrebbe anche allocare la stessa quantità di memoria allocata dal lato che riceve. Questo perché, anche dopo che i dati sono stati inviati sulla rete, il mittente li deve tenere in memoria fino a quando non riceve un riscontro positivo, nel caso in cui i dati debbano essere ritrasmessi. Se il ricevitore è lontano, i riscontri richiederanno molto tempo per arrivare. Se la memoria del mittente è piccola, può saturare e bloccare l'emissione di pacchetti. Un semplice calcolo dà la stessa dimensione ottimale di memoria sia per chi invia che per chi riceve.

Perdita di pacchetto modifica

Un ulteriore limite sulle prestazioni può verificarsi quando un pacchetto viene smarrito nella rete.[2] Quando viene limitata la velocità della connessione TCP a causa dell'algoritmo per il controllo della congestione, il limite può essere calcolato in questo modo:

 

Dove MSS è la maximum segment size e Ploss è la probabilità di perdità di pacchetto.[3] Se la perdita di pacchetto è talmente rara che la finestra di ricezione viene regolarmente estesa completamente, questa formula non va applicata.

Opzioni TCP per Prestazioni Elevate modifica

Molte estensioni di TCP sono state fatte nel corso degli anni per migliorare le prestazioni su collegamenti veloci con high-RTT.

I TCP timestamp (RFC 1323) Gioca un doppio ruolo: evitano le ambiguità dovute ai numeri di sequenza a 32 bit, e permettono una stima più precisa degli RTT in presenza di perdite multiple ad ogni RTT. Con queste migliorie, diventa ragionevole incrementare la finestra di ricezione oltre i 64 kB, che può essere fatto usando la window scaling option (RFC 1323).

L'opzione TCP di selective acknowledgment (SACK, RFC 2018) permette, in caso di perdita di pacchetto, al destinatario nella comunicazione TCP, di richiedere al mittente un preciso segmento che è andato perso. Questo migliora le performance su collegamenti con high-RTT, dove perdite multiple nelle finestre sono possibili.

Il Path MTU discovery evita il bisogno di frammentare i segmenti durante la comunicazione, incrementando così le prestazioni in presenza di perdite di pacchetto.

Note modifica

  1. ^ High Performance Enabled SSH/SCP [PSC] Archiviato il 5 aprile 2007 in Internet Archive.
  2. ^ Copia archiviata (ps), su psc.edu. URL consultato il 10 maggio 2012 (archiviato dall'url originale l'11 maggio 2012).
  3. ^ RFC 3155

Collegamenti esterni modifica