¿La distancia física afecta la velocidad de descarga?

22

Acabo de discutir con un colega mío y pensé en comunicarme con los expertos en esto. Aquí está el escenario. Estábamos usando un sitio web que mide la velocidad de su conexión. Probamos con un servidor que está lejos de nosotros (estamos en Malasia y el servidor estaba en EE. UU.). Fue alrededor de 2 Mbps. Luego probamos con un servidor en Singapur y fue mucho más rápido (alrededor de 15 Mbps). Mi colega creía que se debía a la distancia física, aunque no creo que importe. Según tengo entendido, una vez que haya realizado el protocolo de enlace inicial y haya comenzado el flujo de datos, no importa dónde se encuentre el servidor y el resultado debería ser casi el mismo. ¿Me estoy perdiendo de algo? ¿Cómo funciona realmente?

Navid
fuente
2
Puede confirmar esto usted mismo trivialmente. Haga ping al servidor para adquirir latencia. Entonces 2Mbps * Latencia == Ventana. Puede confirmar el tamaño real de la ventana con wireshark. Pero supongamos que no tiene escala de ventana activada, entonces es 64kB / 2Mbps = 256ms, por lo que predigo que su servidor estará a 256ms de distancia.
ytti
2
@ytti está describiendo indirectamente el BDP (producto de retardo de ancho de banda) que se traduce aproximadamente en redes largas (retraso), gruesas (ancho de banda) que son más difíciles de mantener llenas y cualquier cosa menos disminuye su rendimiento potencial. Ver en.wikipedia.org/wiki/Bandwidth-delay_product .
generalnetworkerror
2
@ytti, Windows Vista y versiones posteriores tienen escala de ventana activada de forma predeterminada ... necesitamos saber qué sistema operativo usa Navid para la prueba
Mike Pennington
De acuerdo con esto, el escalado de support.microsoft.com/kb/934430 (factor 8) es predeterminado en Vista, pero solo para no HTTP. No soy usuario de Windows, así que no puedo verificarlo.
ytti
2
@ytti, no estoy seguro de que sea relevante. Ejecuto Vista, y estoy viendo un poco de mi conexión HTTP a esa página de soporte, y el TCP SYN dice: "Escala de ventana: 2 (Multiplicar por un factor de 4)"
Mike Pennington

Respuestas:

23

Mi colega creía que se debía a la distancia física, aunque no creo que importe. Según tengo entendido, una vez que haya realizado el protocolo de enlace inicial y haya comenzado el flujo de datos, no importa dónde se encuentre el servidor y el resultado debería ser casi el mismo. ¿Me estoy perdiendo de algo? ¿Cómo funciona realmente?

Ambos tenían razón en algún momento de la historia, pero su comprensión es mayormente correcta ... hoy :). Hay algunos factores que cambiaron entre la respuesta anterior que dio su amigo y las capacidades que tenemos hoy.

  • Escalado de ventana TCP
  • Host buffer tuning

La diferencia en los resultados que vio podría haber sido afectada por:

  • Paquete perdido
  • Transferencias TCP paralelas

Escalado de ventana TCP: el efecto de retraso de ancho de banda

Como su amigo mencionó, las implementaciones anteriores de TCP sufrieron los límites impuestos por el tamaño original de la ventana de recepción de 16 bits en el encabezado TCP (ref RFC 793: Sección 3.1 ); RWIN controla la cantidad de datos no reconocidos que pueden estar esperando en un solo socket TCP. RWIN de 16 bits valora las rutas de Internet limitadas con productos con alto retardo de ancho de banda (y muchas de las conexiones de Internet de alto ancho de banda actuales estarían limitadas por un valor de 16 bits).

Para valores RTT altos, es útil tener un RWIN muy grande. Por ejemplo, si su ruta RTT de Malasia a los EE. UU. Es de aproximadamente 200 ms, el TCP RWIN original lo limitaría a 2.6Mbps.

Rendimiento máximo = Rcv_Win / RTT

* Rendimiento máximo = 65535 * 8 / 0.200 *

Rendimiento máximo = 2.6Mbps

RFC 1323 definió algunas "Opciones TCP" para superar estas limitaciones; una de esas opciones de TCP es "escala de ventana". Introduce un factor de escala, que multiplica el valor RWIN original, para obtener el valor completo de la ventana de recepción; El uso de opciones de escala de ventana permite un RWIN máximo de 1073725440 bytes. Aplicando los mismos cálculos:

Rendimiento máximo = Rcv_Win / RTT

* Rendimiento máximo = 1073725440 * 8 / 0.200 *

Rendimiento máximo = 42,96 Gbps

Tenga en cuenta que TCP aumenta RWIN gradualmente durante la duración de una transferencia, siempre que la pérdida de paquetes no sea un problema. Para ver velocidades de transferencia realmente grandes en una conexión de alto retraso, debe transferir un archivo grande (para que TCP tenga tiempo de aumentar la ventana) y la pérdida de paquetes no puede ser un problema para la conexión.

Paquete perdido

Los circuitos de Internet a través del Océano Pacífico se congestionan a veces. Parte de mi familia vive en Taiwán, y habitualmente nos encontramos con problemas cuando usamos Google Talk con ellos. A menudo veo una pérdida de paquetes superior al 0,5% cuando hago ping a su línea DSL desde los EE. Si está viendo algo así como una pérdida del 0,5% en el servidor "más lento", limitaría muy fácilmente el rendimiento en un solo socket TCP.

Secuencias TCP paralelas

Para su información, algunos sitios web de prueba de velocidad utilizan flujos TCP paralelos para aumentar el rendimiento ; esto puede estar afectando los resultados que ve, porque las secuencias TCP paralelas aumentan drásticamente el rendimiento en caso de que tenga alguna pérdida de paquetes en la ruta. He visto cuatro flujos TCP paralelos que saturan completamente un cable módem de 5 Mbps que sufrió una pérdida de paquetes constante del 1%. Normalmente, una pérdida del 1% reduciría el rendimiento de una sola secuencia TCP.

Material extra: sintonización del búfer de host

Muchas implementaciones de SO más antiguas tenían sockets con buffers limitados; con sistemas operativos más antiguos (como Windows 2000), no importaba si TCP permitía que grandes cantidades de datos estuvieran en vuelo ... sus memorias intermedias de socket no estaban sintonizadas para aprovechar el gran RWIN. Se realizó mucha investigación para permitir un alto rendimiento en las transferencias TCP . Los sistemas operativos modernos (para esta respuesta, podemos llamar a Windows Vista y más tarde "moderno") incluyen mejores mecanismos de asignación de búfer en sus implementaciones de búfer de socket.

Mike Pennington
fuente
44
Como nota al margen: hay muchos enrutadores de estilo antiguo que irritarán en el escalado de la ventana (hay menos todos los días, pero todavía hay muchos) y lo restablecen a cero, disminuyendo drásticamente su ancho de banda. La probabilidad de golpear uno de estos enrutadores rotos aumenta con el número de saltos hacia el destino, aunque la mayoría de los proveedores de infraestructura de red no deberían tener este problema hoy en día.
Chris Down
Los enrutadores son dispositivos L3. El escalado de la ventana TCP es un proceso L4. El enrutador reenvía el paquete o no lo hace y, salvo el uso de mecanismos de QoS, no hay diferenciación entre TCP, UDP o cualquier otro protocolo. Los enrutadores ciertamente tienen un efecto en la negociación inicial de MSS (... o si dejan caer ICMP inalcanzables) pero el algoritmo de ventana deslizante es puramente una función de las pilas en los sistemas finales.
rnxrx
2
@rnxrx Estoy de acuerdo, sería principalmente FW de borde que se enojaría con las opciones de TCP. No he oído hablar de la opción de escalamiento de la ventana TCP de enrutador de enrutador, pero no me sorprendería mucho si alguien se le ocurrió el proveedor / modelo que lo ha hecho, teniendo en cuenta que no es raro que los enrutadores de borde alteren la opción TCP MSS en tránsito , no es un gran salto imaginar a alguien jodiendo eso.
ytti
3

Respuesta corta: Sí, la distancia tiene un efecto en el ancho de banda de flujo único.

Internet ha desarrollado medios para limitar ese efecto ... ACK retrasado, escalado de ventanas, otros protocolos :-) Pero la física sigue ganando al final. En este caso, es mucho más probable que se trate de una congestión general de la red en tantos saltos: solo se necesita un único paquete descartado para eliminar una secuencia TCP.

Ricky Beam
fuente
1

Si bien ya hay excelentes respuestas a esto, me gustaría agregar: no, la velocidad no se ve necesariamente afectada por la distancia y sí, muy a menudo la velocidad se ve afectada por la distancia , ambas son ciertas.

¿Porqué es eso?

Fuertemente simplificado, cuanto mayor es la distancia, más "saltos" están involucrados en el camino a través de Internet. El ancho de banda máximo está determinado por el salto más lento y el tráfico concurrente. Con el aumento de la distancia y una distribución algo aleatoria de las velocidades de salto, aumenta la probabilidad de obtener velocidades generales más lentas. Además, la física se interpone y el aumento de la latencia también puede ralentizar el enlace.

Pero esto no debe darse por sentado. La tecnología nos permite construir una conexión que abarca todo el planeta de casi cualquier ancho de banda deseado. Sin embargo, el ancho de banda y la distancia son enemigos y ambos aumentan drásticamente el costo de la conexión, lo que hace que sea menos probable que exista solo para la conexión que pueda necesitar en este momento.

Por supuesto, esto está demasiado simplificado, pero en realidad, esta situación es lo que a menudo encuentra. Y, de nuevo, no lo hace cuando hay una conexión sorprendentemente rápida o un proxy de distribución a la vuelta de la esquina, pero cuando todo es instantáneo, rara vez pensamos en la velocidad de Internet ...

Zac67
fuente
-1

Según Andrew Martin, la respuesta es sí

Gráficos

Jonathan
fuente
Enlace solo se desaconsejan las respuestas. Proporcione detalles que hagan que esta respuesta sea útil sin depender de la página web vinculada.
Teun Vink
Amigo, no es solo una respuesta de enlace, es una imagen con estadísticas
Jonathan
No soy tu amigo Además, esta imagen no tiene sentido sin una explicación de qué hay en el eje Y y cómo se midió. E incluso entonces, debe explicar cómo esta imagen es una respuesta a la pregunta.
Teun Vink
No sé por qué es difícil para ti, pero los ejes X e Y están etiquetados. "Velocidad de descarga promedio en Mbps"
Jonathan