Ho appena avuto una discussione con un mio collega e ho pensato di contattare gli esperti in merito. Ecco lo scenario. Stavamo utilizzando un sito Web che misura la velocità della tua connessione. Abbiamo testato utilizzando un server che è lontano da noi (siamo in Malesia e il server era negli Stati Uniti). Era di circa 2 Mbps. Quindi abbiamo provato con un server a Singapore ed è stato molto più veloce (circa 15 Mbps). Il mio collega ha creduto che fosse a causa della distanza fisica mentre non penso che sia importante. La mia comprensione è che dopo aver eseguito l'handshake iniziale e avviato il flusso di dati, non importa dove si trova il server e il risultato dovrebbe essere quasi lo stesso. Mi sto perdendo qualcosa qui? Come funziona veramente?
La distanza fisica influisce sulla velocità di download?
Risposte:
Il mio collega ha creduto che fosse a causa della distanza fisica mentre non penso che sia importante. La mia comprensione è che dopo aver eseguito l'handshake iniziale e avviato il flusso di dati, non importa dove si trova il server e il risultato dovrebbe essere quasi lo stesso. Mi sto perdendo qualcosa qui? Come funziona veramente?
Entrambi avevate ragione ad un certo punto della storia, ma la vostra comprensione è per lo più corretta ... oggi :). Ci sono alcuni fattori che sono cambiati tra la risposta più vecchia data dal tuo amico e le capacità che abbiamo oggi.
- Ridimensionamento finestra TCP
- Ottimizzazione del buffer host
La differenza nei risultati che hai visto potrebbe essere stata influenzata da:
- Perdita di pacchetti
- Trasferimenti TCP paralleli
Ridimensionamento finestra TCP: l'effetto ritardo larghezza di banda
Come ha detto il tuo amico, le precedenti implementazioni di TCP soffrivano dei limiti imposti dalla dimensione originale della finestra di ricezione a 16 bit nell'intestazione TCP (rif RFC 793: Sezione 3.1 ); RWIN controlla quanti dati non riconosciuti possono essere in attesa in un singolo socket TCP. I valori RWIN a 16 bit limitavano i percorsi Internet con prodotti ad elevato ritardo di larghezza di banda (e molte delle connessioni Internet ad alta larghezza di banda di oggi sarebbero limitate da un valore di 16 bit).
Per valori RTT elevati, è utile disporre di un RWIN molto grande. Ad esempio, se il tuo percorso RTT dalla Malesia agli Stati Uniti è di circa 200 ms, il TCP RWIN originale ti limiterebbe a 2,6 Mbps.
Throughput max = Rcv_Win / RTT
* Velocità effettiva massima = 65535 * 8 / 0.200 *
Velocità effettiva massima = 2,6 Mbps
RFC 1323 ha definito alcune "Opzioni TCP" per superare queste limitazioni; una di queste opzioni TCP è il "ridimensionamento delle finestre". Introduce un fattore di scala, che moltiplica il valore RWIN originale, al fine di ottenere il valore della finestra di ricezione completa; l'utilizzo delle opzioni di ridimensionamento delle finestre consente un RWIN massimo di 1073725440 byte. Applicando gli stessi calcoli:
Throughput max = Rcv_Win / RTT
* Velocità effettiva massima = 1073725440 * 8 / 0.200 *
Velocità effettiva massima = 42,96 Gbps
Tieni presente che TCP aumenta RWIN gradualmente durante la durata di un trasferimento, a condizione che la perdita di pacchetti non sia un problema. Per vedere velocità di trasferimento molto elevate su una connessione a ritardo elevato, devi trasferire un file di grandi dimensioni (quindi TCP ha il tempo di aumentare la finestra) e la perdita di pacchetti non può essere un problema per la connessione.
Perdita di pacchetti
I circuiti Internet attraverso l'Oceano Pacifico a volte diventano piuttosto congestionati. Alcuni della mia famiglia vivono a Taiwan e incontriamo regolarmente problemi quando utilizziamo Google Talk con loro. Vedo spesso una perdita di pacchetti superiore allo 0,5% quando eseguo il ping della loro linea DSL dagli Stati Uniti; se si riscontra una perdita del 0,5% sul server "più lento", limiterebbe molto facilmente il throughput su un singolo socket TCP.
Flussi TCP paralleli
Cordiali saluti, alcuni siti Web di test di velocità utilizzano flussi TCP paralleli per aumentare la velocità effettiva ; questo potrebbe influire sui risultati visualizzati, poiché i flussi TCP paralleli aumentano notevolmente la velocità di trasmissione in caso di perdita di pacchetti nel percorso. Ho visto quattro flussi TCP paralleli saturare completamente un modem via cavo da 5 Mbps che soffriva di una perdita di pacchetti costante dell'1%. Normalmente una perdita dell'1% ridurrebbe il throughput di un singolo flusso TCP.
Materiale bonus: ottimizzazione del buffer host
Molte implementazioni di sistemi operativi precedenti avevano socket con buffer limitati; con sistemi operativi precedenti (come Windows 2000), non importava se TCP consentiva che grandi quantità di dati fossero in volo ... i loro buffer socket non erano sintonizzati per sfruttare l'ampio RWIN. Sono state fatte molte ricerche per consentire alte prestazioni sui trasferimenti TCP . I sistemi operativi moderni (per questa risposta, possiamo chiamare Windows Vista e successivamente "moderni") includono meccanismi di allocazione del buffer migliori nelle loro implementazioni di buffer socket.
Risposta breve: Sì, la distanza influisce sulla larghezza di banda a flusso singolo.
Internet ha evoluto i mezzi per limitare questo effetto ... ritardato ACK, ridimensionamento delle finestre, altri protocolli :-) Ma la fisica vince ancora alla fine. In questo caso, è molto più probabile che si verifichi una congestione della rete generale su così tanti hop: basta un solo pacchetto rilasciato per uccidere un flusso TCP.
Mentre ci sono già ottime risposte a questo, vorrei aggiungere: no, la velocità non è necessariamente influenzata dalla distanza e sì, molto spesso la velocità è influenzata dalla distanza sono entrambi veri.
Perché?
Fortemente semplificato, maggiore è la distanza, maggiore è il "luppolo" coinvolto nel percorso attraverso Internet. La larghezza di banda massima è determinata dal hop più lento e dal traffico concorrente. Con l'aumentare della distanza e una distribuzione alquanto casuale delle velocità del luppolo, aumenta la probabilità di rallentare la velocità complessiva. Inoltre, la fisica si mette in mezzo e l'aumento della latenza può anche rallentare il collegamento.
Ma questo non è scontato. La tecnologia ci consente di costruire una connessione globale che comprende quasi tutta la larghezza di banda desiderata. Tuttavia, la larghezza di banda e la distanza sono nemici ed entrambi aumentano drasticamente il costo della connessione, rendendo di nuovo meno probabile l'esistenza solo per la connessione di cui potresti aver bisogno in questo momento.
Certo, questo è troppo semplificato, ma in realtà questa situazione è ciò che trovi molto spesso. E poi di nuovo no quando c'è una connessione sorprendentemente veloce o un proxy di distribuzione proprio dietro l'angolo - ma quando tutto è istantaneo raramente pensiamo alla velocità di Internet ...
Secondo Andrew Martin la risposta è sì
