Aumentare la larghezza di banda su un collegamento da diciamo 1mb a 30mb riduce la RTT?
No, aumentare la larghezza di banda non riduce la RTT in senso stretto. Dico "rigorosamente parlando" perché dipende da cosa stai misurando!
Scenario 1: il livello fisico
Data la seguente semplice topologia che è facile da seguire, una connessione Ethernet in rame in esecuzione a 1 Mbps con un MTU di 1500 byte tra due dispositivi con un cavo da 10 metri, questo ha lo stesso RTT (il tempo necessario per un pacchetto di richiesta echo ICMP per viaggiare dal dispositivo 1 al dispositivo 2 e il messaggio di risposta echo ICMP per viaggiare dal dispositivo 2 al dispositivo 1) come una connessione Ethernet in rame 10/30/50 / 100mbps tra loro con un MTU da 1500 byte sullo stesso cavo da 10 metri.
Questo perché il "ritardo" del segnale lungo il cavo di rame è correlato alla sua costante dialettica ( permittività relativa ). Vedi quelle due pagine di Wikipedia per ulteriori informazioni sulla fisica che non rientrano nel campo di applicazione qui.
In sostanza, il "tempo di volo" dei segnali elettrici lungo il cavo di rame è la stessa velocità per una connessione da 10 Mbps e 1000 Mbps quando si utilizza lo stesso cavo Cat5e di lunghezza e grado. La differenza è che con una connessione a 10 Mbps i dati vengono codificati sul filo meno frequentemente di una connessione a 100 Mbps, quindi ci sono piccoli spazi tra i bit di dati quando vengono posizionati sul filo (questo si chiama ritardo di serializzazione ). Questi due articoli di Wikipedia espandono ulteriormente questi concetti: Bit time e Slot time .
Scenario 2: livello 4 e versioni successive (esempio TCP)
Data la seguente topologia di esempio, una connessione Ethernet in rame funzionante a 1 Mbps con un MTU di 1500 byte tra due dispositivi con un cavo da 10 metri. Se hai una quantità X di dati che supponiamo siano 100 Megabyte di dati da trasportare tra il dispositivo 1 e il dispositivo 2, ciò richiederà più tempo rispetto a una connessione Ethernet in rame da 30 o 100 Mbps con un MTU di 1500 byte su un 10 metri cavo di rame tra gli stessi due dispositivi. Questo perché richiede più tempo per codificare e trasmettere i dati sul filo e la scheda NIC di ricezione sarà altrettanto lenta nel ricevere e decodificare i segnali.
Qui l'RTT di "dati effettivi" che è forse un singolo file da 100 MB richiederà più tempo perché con i protocolli di livello superiore introdotti non solo è necessario trasferire i dati ma anche i pacchetti SYN, ACK e PUSH possono essere scambiati qui usando ulteriori bit time, prima a livello di applicazione è possibile inviare un messaggio dal dispositivo 2 al dispositivo 1 dicendo "Ho ricevuto tutti i dati ora".
Inoltre, quali sono i migliori meccanismi per ridurre la RTT.
Risposta breve: non molto
Risposta lunga:
Per portare questo in un esempio di vita reale espandendo gli esempi sopra; Se stai eseguendo il "ping" tra due dispositivi collegati tra loro tramite diversi router e / o switch intermedi, l'RTT è un prodotto della distanza fisica e del tempo impiegato dai segnali per viaggiare così lontano e indietro attraverso tutti quei dispositivi (in pratica ). Se QoS è configurato su questi dispositivi, è possibile aumentare anche il ritardo end-to-end e complicare ulteriormente il modello.
Non c'è molto che tu possa fare qui a parte (in una situazione puramente ipotetica in cui il denaro non è un oggetto e la politica non importa ecc.); Installare una connessione in fibra che corre direttamente dal dispositivo 1 al dispositivo 2 tagliando tutti gli switch e i router in mezzo. Sarebbe uno scenario ideale. Realisticamente potresti aggiornare qualsiasi collegamento in rame o wireless alla fibra (non che la fibra sia enormemente più veloce [ i ], [ ii ]) e provare a rendere il percorso di connessione il più diretto possibile in modo che i dati passino attraverso il minor numero di dispositivi intermedi e diversi connessioni fisiche. L'ottimizzazione QoS e l' ingegneria del traffico (instradamento basato sui vincoli) possono anche aiutare su distanze maggiori con molti salti intermedi.
Se vuoi trasferire dati tra i punti con quello che ritieni abbia "un RTT troppo alto" puoi guardare tecnologie come TCP SACK che è già in uso in molti posti, ma se leggi su quello ti darà un punto di partenza in quanto ci sono altre tecnologie simili che puoi quindi esaminare. Ciò include tecnologie come acceleratori e compressori WAN, anche se ciò si estinguerebbe dall'ambito di questo argomento. Con il trasferimento dei dati su un collegamento con RTT elevato è necessario considerare il BDP (prodotto di ritardo di larghezza di banda, [ iii ]) - quando si utilizza qualcosa come TCP, questo ti terrà sempre indietro.
[i] Il tempo di "volo" su un mezzo dielettrico in rame è molto simile a una guida d'onda in fibra
[ii] Ciò potrebbe cambiare, tuttavia, nuove ricerche e tecnologie spero che la velocità della luce in una fibra salga dalla media di 0,6 * c a quasi 1,0 * c, http://www.orc.soton.ac.uk/ speedoflight.html
[iii] http://www.kehlet.cx/articles/99.html - Esempio BDP