Algoritmo del tester di velocità TCP domanda

Question

Sto lavorando in una società di ISP. Stiamo sviluppando un tester di velocità per i nostri clienti, ma stiamo riscontrando alcuni problemi con i test di velocità TCP.

Un client aveva una durata totale di 102 secondi con trasferimento di 100 MB con una dimensione del pacchetto di 8192. 100.000.000/8192 = 12.202 pacchetti. Se il client invia un ACK ad ogni altro pacchetto che sembra un sacco di tempo, basta trasmettere gli ACK. Supponiamo che il client invii 6000 ACK e che l'RTT sia 15ms - questo è 6000 * 7.5 = 45.000ms = 45 secondi solo per gli ACK?

Se io uso questo calcolo per Mbit/s:

(((sizeof_download_in_bytes/durationinseconds) /1000) /1000) * 8 = Mbp/s 

mi metterò il risultato in Mbp/s, ma poi il più alto è il TTL è tra il mittente e il cliente più basso il Mbp/s la velocità diventerà.

Per simulare che l'utente sia più vicino al server, sarebbe "legale" rimuovere il tempo di risposta ACK nel risultato finale su Mbp/s? Sarebbe come simulare l'utente finale vicino al server?

quindi vorrei mostrare questo calcolo per l'utente finale:

(((sizeof_download_in_bytes/(durationinseconds - 45sec)) /1000)/1000) * 8 = Mbp/s 

Che è valida?

Answer 1

Il problema qui è che RTT è troppo grande in modo da non utilizzare l'intera larghezza di banda. Potrebbe essere necessario aumentare la dimensione della finestra TCP, che può essere eseguita su base socket per scopi di test, nonché system-wide.

Come cliente, lo considererei un ottimo servizio se un programma di test della velocità mi informasse di impostazioni di sistema non ottimali e mi offrisse un'opzione per correggerle.

Se le impostazioni della finestra TCP sono corrette, RTT non dovrebbe importare in un test di velocità TCP, a meno che non si stia perdendo un numero significativo di pacchetti (ma dopo tutto questo è ciò che si desidera rilevare in primo luogo).

Answer 2

TCP utilizza il controllo del flusso della finestra e normalmente non attende gli ACK prima di inviare il fotogramma successivo. Gli ACK vanno contemporaneamente ai frame di dati e non richiedono alcun tempo aggiuntivo per l'orologio a muro. Qualsiasi recente implementazione TCP può gestire tale RTT e bitrate senza perdita di velocità.

Così corretto calcolo è il numero 1.

Inoltre, stai sicuro che la rete davvero avere 8192 MTU dal PC del cliente al tuo server di prova? È piuttosto probabile che un segmento Ethernet con 1500 MTU esista e che i tuoi 8192 byte inviano buffer suddivisi dallo stack TCP in segmenti TCP standard da 1500 byte.

Infine, ci sono 1024 byte in kilobyte e 1024 kilobyte in megabyte.