TCP tuning: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m Bot: Sistemo note con collegamenti esterni senza titolo (documentazione) |
Ortografia |
||
(17 versioni intermedie di 14 utenti non mostrate) | |||
Riga 1:
▲La tecnica di '''TCP tuning''' consiste nell'impostare adeguatamente i parametri del [[Controllo della congestione]] delle connessioni [[Transmission Control Protocol|TCP]] su reti a banda larga e latenza elevata. Le reti impostate in maniera corretta possono avere prestazioni più elevate di anche più di 10 volte, in qualche caso.<ref>[http://www.psc.edu/networking/projects/hpn-ssh/ High Performance Enabled SSH/SCP [PSC]<!-- Bot generated title -->]</ref> 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 ==
Riga 17 ⟶ 15:
== Limiti di velocità del TCP ==
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 ===<!--[[Receive Window]] redirects here-->
{{
Nel [[computer networking]], '''RWIN''' ([[Transmission Control Protocol|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 (reti)|pacchetto]] inviato, si stoppa e attende il riscontro, se l'attesa supera un certo limite, il pacchetto viene ritrasmesso. Così il TCP implementa
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.
Riga 33 ⟶ 31:
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
=== Perdita di pacchetto ===
Un ulteriore limite sulle prestazioni può verificarsi quando un pacchetto viene smarrito nella rete.<ref>{{cita web |url=http://www.psc.edu/networking/papers/model_ccr97.ps |titolo=Copia archiviata |accesso=10 maggio 2012 |urlmorto=sì |urlarchivio=https://web.archive.org/web/20120511174032/http://www.psc.edu/networking/papers/model_ccr97.ps }}</ref> Quando viene limitata la velocità della connessione TCP a causa dell'[[TCP congestion avoidance algorithm|algoritmo per il controllo della congestione]], il limite può essere calcolato in questo modo:
<math> \mathrm{Throughput} \le \frac {\mathrm{MSS}} {\mathrm{RTT} \sqrt{ P_{\mathrm{loss} }}}</math>
Dove MSS è la maximum segment size e ''P''<sub>loss</sub> è la probabilità di
==Opzioni TCP per Prestazioni Elevate==
Riga 48 ⟶ 46:
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,
Il [[Path MTU discovery]] evita il bisogno di frammentare i segmenti durante la comunicazione, incrementando così le prestazioni in presenza di perdite di pacchetto.
Riga 56 ⟶ 54:
== Collegamenti esterni ==
* [http://fasterdata.es.net/TCP-tuning/background.html TCP Tuning Guide] {{Webarchive|url=https://web.archive.org/web/20100618075447/http://fasterdata.es.net/TCP-tuning/background.html |date=18 giugno 2010 }}, ESnet
*
*
* [
* [
* [http://www.speedguide.net/analyzer.php TCP/IP Analyzer], speedguide.net
* [http://blogs.technet.com/winserverperformance/archive/2008/05/03/nt-ttcp-network-performance-test-tool-available.aspx NTTTCP Network Performance Test Tool], Microsoft Windows Server Performance Team Blog
Riga 66 ⟶ 64:
{{IPstack}}
[[Categoria:Transmission Control Protocol]]
|