Algoritmo de comprobador de velocidad de TCP pregunta

Question

Estoy trabajando en una empresa de ISP. Estamos desarrollando un comprobador de velocidad para nuestros clientes, pero estamos teniendo problemas con las pruebas de velocidad de TCP.

Un cliente tenía una duración de tiempo total de 102 segundos transfiriendo 100 MB con un tamaño de paquete de 8192. 100.000.000/8192 = 12.202 paquetes. Si el cliente envía un ACK cada dos paquetes que parece mucho tiempo simplemente transmitir los ACK. Supongamos que el cliente envía 6000 ACK y el RTT es de 15ms, eso es 6000 * 7.5 = 45,000ms = 45 segundos solo para los ACK.

Si utilizo este cálculo para Mbit/s:

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

voy a conseguir el resultado en MBP/s, pero entonces el más alto es el TTL es entre el remitente y el cliente menor será la Mbp/s la velocidad se convertirá.

Para simular que el usuario está más cerca del servidor, ¿sería "legal" eliminar el tiempo de respuesta de ACK en el resultado final en los Mbps? ¿Esto sería como simular que el usuario final está cerca del servidor?

Así que sería mostrar este cálculo para el usuario final:

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

¿Eso es válido?

Answer 1

El problema aquí es que el RTT es demasiado grande para que no se use todo el ancho de banda. Es posible que desee aumentar el tamaño de la ventana TCP, que se puede hacer por socket para fines de prueba, así como system-wide.

Como cliente, consideraría un gran servicio si un programa de prueba de velocidad fuera a notificarme una configuración del sistema no óptima y me ofreciera una opción para corregirla.

Si la configuración de la ventana TCP es correcta, RTT no debería importar en una prueba de velocidad TCP, a menos que pierda una cantidad significativa de paquetes (pero después de todo esto es lo que quiere detectar en primer lugar).

Answer 2

TCP utiliza el control de flujo de ventana y normalmente no espera los ACK antes de enviar el siguiente fotograma. Los ACK van simultáneamente con los marcos de datos y no requieren ningún tiempo adicional de reloj de pared. Cualquier implementación reciente de TCP puede manejar dicho RTT y velocidad de bits sin pérdida de velocidad.

cálculo de manera correcta es el número 1.

Además, ¿estás seguro de la red realmente tiene MTU 8192 desde el PC del cliente para el servidor de prueba? Es bastante probable que exista algún segmento Ethernet con 1500 MTU y sus búferes de envío de 8192 bytes se dividen por la pila TCP en segmentos TCP estándar de 1500 bytes.

Y, por último, hay 1024 bytes en kilobyte y 1024 kilobytes en megabyte.