Tests de velocidad para banda ancha (III): TCP, la empresa de paquetería
Como vimos en el post anterior, los test de velocidad actuales consisten en la descarga de un contenido de tamaño conocido a través de una conexión TCP y la medición del tiempo empleado para completar la transferencia. Sin embargo, como ya adelantábamos, la influencia del protocolo TCP en la velocidad de descarga puede ser significativa en determinados casos y, en particular, cuando se trabaja con conexiones de alta capacidad.
Para comprender mejor las limitaciones que TCP impone a un test de velocidad, nos valdremos aquí de una analogía sencilla que nos permita analizar intuitivamente los factores que condicionan este tipo de transmisiones.
Supongamos una empresa de paquetería cuyo único cometido es transportar de forma fiable paquetes postales de un edificio a otro. Para ello, se vale de una cinta transportadora “de alta velocidad” que, en un recorrido circular —similar al de las cintas de equipaje de los aeropuertos—, va y vuelve entre los dos edificios.
Para llevar a cabo esta tarea con éxito, la empresa dispone de dos trabajadores, cada uno emplazado en un extremo, de manera que el primero (el “emisor”) se encargaría de depositar los paquetes por orden en la cinta, y el otro (el “receptor”) se encargaría de recogerlos en el otro extremo y pegar un post-it en su lugar, para que llegue a su compañero a modo de acuse de recibo, aprovechando así que la cinta es circular. De esta forma, en caso de que alguno de los paquetes se perdiera por el camino (cosas que pasan…), el “emisor” estaría en disposición de ensamblar otro paquete idéntico al extraviado y volverlo a poner sobre la cinta (como veis, se trata de una empresa de paquetería con habilidades sorprendentes).
En estas circunstancias cabe preguntarse: ¿cómo podrían coordinarse los dos extremos para aprovechar al máximo la velocidad de la cinta (es decir, para enviar el máximo número posible de paquetes por hora) a la vez que garantizan una entrega fiable?
Una forma posible de organizar estos envíos sería que el “emisor” enviase un paquete y esperase a la recepción del correspondiente acuse de recibo para poner el siguiente en la cinta (o, en su defecto, esperase un tiempo prudencial antes de reenviar el paquete presumiblemente “extraviado”). Sin embargo, si la distancia entre ambos edificios fuera considerable, con esta operativa no conseguiríamos aprovechar la capacidad de transporte de la cinta transportadora, toda vez que, a lo sumo, estaríamos introduciendo un paquete por cada vuelta completa de la cinta, de manera que casi toda su superficie de transporte quedaría desocupada.
Para mejorar la eficiencia de este proceso, en lugar de depositar un solo paquete en la cinta y esperar su acuse de recibo para cargar el siguiente, la empresa de paquetería decide que puedan cargarse 2 paquetes sin que se haya recibido aún su confirmación y, una vez se reciba el acuse de recibo del primero, se vuelva a depositar un nuevo paquete en la cinta, de manera que vuelva a haber 2 paquetes “en circulación”, y así sucesivamente. Una vez que la empresa descubre que, con esta sencilla medida, ha conseguido doblar el número de paquetes que era capaz de transportar en una hora, decide ir aumentando gradualmente este número de paquetes “en circulación”, de manera que a la semana siguiente se pasa de 2 a 4, la siguiente de 4 a 8, y así sucesivamente. De esta forma, cada semana la empresa consigue doblar su capacidad de transporte… hasta que llega a trabajar con un número tan grande de paquetes “en circulación” que consigue llenar completamente el espacio de la cinta (al menos, en su camino de ida). Una vez alcanzado este punto de “saturación”, la empresa entiende que está aprovechando al máximo la velocidad de la cinta transportadora pues, por cada paquete que se esté introduciendo en un extremo, la cinta estará entregando otro al receptor, y éste, a su vez, estará colocando un nuevo acuse de recibo que, más adelante, provocará que se deposite un nuevo paquete al ritmo adecuado… En estas condiciones de funcionamiento, nos encontramos con que:
- El sistema está trabajando de forma óptima, y la única forma de aumentar el ritmo al que se transportan paquetes pasa por aumentar la velocidad de la cinta.
- En caso de que algún día aumentara la longitud de la cinta transportadora (porque hubiera que enviar paquetes a un edificio más lejano) sería necesario un nuevo aumento de los paquetes “en circulación” para volver alcanzar la máxima eficiencia.
Como ya habrá deducido el lector, en el caso de un protocolo de transporte como TCP las cosas funcionan de una forma muy parecida:
- La velocidad de la cinta transportadora equivale al ancho de banda disponible.
- Los paquetes postales que viajaban por la cinta son ahora paquetes de información que se transmiten por la red.
- Los dos trabajadores que se ocupaban de cargar y descargar paquetes al ritmo adecuado son ahora los dos extremos del protocolo TCP (el emisor y el receptor, respectivamente).
- Así mismo, el papel que jugaban los post-it que se depositaban en la cinta lo desempeñan ahora paquetes especiales de asentimiento, ACK, que envía el receptor al emisor para ir confirmando la correcta recepción de paquetes de datos.
- La longitud de la cinta (dependiente de la distancia entre los edificios) equivale aquí al RTT, que es el tiempo necesario para transportar un paquete de un extremo a otro y que llegue su correspondiente ACK de vuelta.
- El número máximo de paquetes “en circulación” se denomina en TCP “ventana” y, al igual que sucedía en el ejemplo anterior, es un parámetro fundamental para su correcto funcionamiento con altas velocidades.
- El tanteo inicial de la empresa hasta encontrar un número adecuado de paquetes “en circulación”, equivale a un procedimiento análogo al que existe en TCP, denominado slow start, por el que se va aumentando gradualmente la ventana (y, con ella, el caudal de la conexión) hasta detectar una situación de saturación.
En definitiva, al igual que sucedía en el ejemplo anterior, nos encontramos con que es necesario que el parámetro de ventana sea el adecuado para que, en las condiciones de RTT que haya en cada momento, TCP pueda aprovechar al máximo el ancho de banda disponible. Así mismo, nos encontramos con que, a causa de este proceso inicial de “tanteo”, la conexión no alcanza su máximo caudal hasta que no ha transcurrido un cierto tiempo, tanto mayor cuanto mayor sea la velocidad máxima que puede alcanzarse en la línea.
Como puede intuirse fácilmente, el impacto que estos dos fenómenos tienen en el resultado del test puede llegar a ser muy relevante a altas velocidades. A analizar estas implicaciones y los efectos que provocan en algunos de los tests de velocidad más populares, dedicaremos las próximas entregas.
ENTRADAS DE ESTA SERIE:
Comentarios
2 Comentarios to “Tests de velocidad para banda ancha (III): TCP, la empresa de paquetería”
Deja un comentario

(Votos: 7. Media: 4,86/5) 





[...] vimos en el post anterior, si TCP sólo enviase un paquete cada vez y esperase a la llegada de su ACK para mandar el [...]
[...] no empieza la transferencia con el tamaño definitivo de ventana. Por el contrario, como ya hacía la empresa de paquetería de nuestro ejemplo, TCP comienza con una ventana de un solo paquete y la va aumentando poco a poco hasta detectar el [...]