¿Aumentar el ancho de banda en un enlace de digamos 1mb a 30mb reduce el RTT?
No, aumentar el ancho de banda no reduce RTT estrictamente hablando. ¡Digo "estrictamente hablando" porque depende de lo que estés midiendo!
Escenario 1: la capa física
Dada la siguiente topología simple que es fácil de seguir, una conexión Ethernet de cobre que se ejecuta a 1 Mbps con una MTU de 1500 bytes entre dos dispositivos con un cable de 10 metros, tiene el mismo RTT (el tiempo que tomaría un paquete de solicitud de eco ICMP para viajar del dispositivo 1 al dispositivo 2 y el mensaje de respuesta de eco ICMP para viajar del dispositivo 2 de regreso al dispositivo 1) como una conexión Ethernet de cobre de 10/30/50/100 mbps entre ellos con una MTU de 1500 bytes en el mismo cable de 10 metros.
Esto se debe a que el "retraso" de la señal en el cable de cobre está relacionado con su constante dialéctica ( permitividad relativa ). Vea esas dos páginas de Wikipedia para obtener información adicional sobre la física que están fuera de alcance aquí.
Esencialmente, el "tiempo de vuelo" de las señales eléctricas por el cable de cobre es la misma velocidad para una conexión de 10 Mbps y 1000 Mbps cuando se utiliza el mismo cable Cat5e de longitud y grado. La diferencia es que con una conexión de 10Mbps, los datos se codifican en el cable con menos frecuencia que una conexión de 100Mbps, por lo que hay brechas más pequeñas entre los bits de datos a medida que se colocan en el cable (esto se llama retraso de serialización ). Estos dos artículos de Wikipedia amplían aún más estos conceptos: tiempo de bits y tiempo de ranura .
Escenario 2: Capa 4 y superior (ejemplo de TCP)
Dada la siguiente topología de ejemplo, una conexión Ethernet de cobre que se ejecuta a 1 Mbps con una MTU de 1500 bytes entre dos dispositivos con un cable de 10 metros. Si tiene una cantidad X de datos que supondremos que son 100 Megabytes de datos para transportar entre el dispositivo 1 y el dispositivo 2, esto llevará más tiempo del que necesitaría con una conexión Ethernet de cobre de 30 o 100Mbps con una MTU de 1500 bytes en un medidor de 10 metros cable de cobre entre los mismos dos dispositivos. Esto se debe a que lleva más tiempo codificar y transmitir los datos en el cable y la NIC receptora será igual de lenta en recibir y decodificar las señales.
Aquí, el RTT de "datos reales", que es quizás un solo archivo de 100 MB, llevará más tiempo porque con los protocolos de nivel superior introducidos, no solo tiene que transferir los datos, sino que también los paquetes SYN, ACK y PUSH intercambiados aquí usando tiempos de bits adicionales, antes en la capa de aplicación se puede enviar un mensaje desde el dispositivo 2 al dispositivo 1 diciendo "He recibido todos los datos ahora".
Además, ¿cuáles son los mejores mecanismos para reducir la RTT?
Respuesta corta: no mucho
Respuesta larga:
Para llevar esto a un ejemplo de la vida real ampliando los ejemplos anteriores; Si está "haciendo ping" entre dos dispositivos que están conectados entre sí a través de varios enrutadores y / o conmutadores intermedios, el RTT es un producto de la distancia física y el tiempo que tardan las señales en viajar tan lejos y de regreso a través de todos esos dispositivos (básicamente ) Si QoS está configurado en estos dispositivos, eso también puede aumentar el retraso de extremo a extremo y complicar aún más el modelo.
No hay mucho que pueda hacer aquí aparte (en una situación puramente hipotética donde el dinero no es un objeto y la política no importa, etc.); Instale una conexión de fibra que se ejecute directamente del dispositivo 1 al dispositivo 2 cortando todos los conmutadores y enrutadores intermedios. Ese sería un escenario ideal. De manera realista, puede actualizar cualquier enlace de cobre o inalámbrico a fibra (no es que la fibra sea mucho más rápida [ i ], [ ii ]) e intente hacer que la ruta de conexión sea lo más directa posible para que los datos pasen por la menor cantidad de dispositivos intermedios y diferentes conexiones físicas El ajuste de QoS y la ingeniería de tráfico (enrutamiento basado en restricciones) también pueden ayudar a distancias más grandes con muchos saltos intermedios.
Si desea transferir datos entre puntos con lo que considera que tiene un "RTT demasiado alto", puede buscar tecnologías como TCP SACK que ya está en uso en muchos lugares, pero si lo lee, le dará un punto de partida, ya que hay otras tecnologías similares que puede considerar. Esto incluye tecnologías como los aceleradores y compresores WAN, aunque eso estaría divagando fuera del alcance de este tema. Debe considerar con la transferencia de datos a través de un enlace con un RTT alto el BDP (producto de retardo de ancho de banda, [ iii ]): cuando usa algo como TCP, esto siempre lo detendrá.
[i] El tiempo de "vuelo" sobre un medio dieléctrico de cobre es muy similar al de una guía de ondas de fibra.
[ii] Sin embargo, esto podría cambiar, es de esperar que nuevas investigaciones y tecnologías aumenten la velocidad de la luz en una fibra desde el promedio de 0.6 * c hasta cerca de 1.0 * c, http://www.orc.soton.ac.uk/ speedoflight.html
[iii] http://www.kehlet.cx/articles/99.html - Ejemplo de BDP