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.