La mejor descripción que he escuchado sobre el método de aceleración inherente de TCP fue un podcast reciente de Security Now . Para citar a Steve Gibson:
Entonces, por acuerdo universal, siendo TCP un protocolo muy inteligente, hace algo llamado "inicio lento". Generalmente se le da permiso para enviar una cierta cantidad de paquetes sin acuse de recibo. Entonces, la idea es, vamos a poner las cosas en movimiento aquí. Y típicamente ese número es dos. Y así, cuando se inicia TCP, puede enviar dos paquetes, uno tras otro. Sin tener el primero reconocido, enviará el segundo. Pero luego espera. Y luego la regla para la limitación es que permitimos que el número de paquetes no reconocidos aumente en uno por cada reconocimiento que recibimos.
Así que pensemos en eso. Permitimos que el número de paquetes no reconocidos se incremente en uno por cada reconocimiento que recibimos. Entonces, primero enviamos dos paquetes como nuestro inicio acordado. Ellos son reconocidos. Entonces tenemos nuestro primer reconocimiento. Nos permitíamos enviar dos. Ahora, con la recepción de este primer acuse de recibo, lo incrementamos de uno a tres. Así que ahora podemos enviar tres paquetes más sin ningún otro reconocimiento. Cuando vuelve un reconocimiento por lo que hayamos enviado antes, lo aumentamos a cuatro. Esto se conoce como la "ventana de congestión". No es una ventana que se envía en la línea, es decir, no es como la ventana de recepción, que son 16 bits del encabezado TCP que nos dice cuántos datos podemos enviar por adelantado. Esta es, es una ventana. Eso'
Si seguimos aumentando el número de paquetes no reconocidos, se nos permite enviar por uno cada vez que recibimos un reconocimiento, en algún momento llegaremos a un límite. Y la belleza de este sistema es que lo hará, cuando empecemos a tratar de enviar paquetes más rápido que el enlace más débil, literalmente enlace, entre enrutadores, en algún momento encontramos el punto donde se rompe el enlace más débil. Descarta los paquetes que estamos tratando de enviar porque estamos tratando de enviarlos demasiado rápido. Por lo tanto, los reconocimientos del otro extremo se detienen porque los datos ya no se transmiten.
Y lo que hace TCP es, si no ha podido recibir, y esto varía en las estrategias. Con el tiempo, la estrategia, la estrategia real para evitar la congestión ha variado mucho. Hay nombres como Tahoe y Reno, y muchos otros que verás si buscas en Google y Wikipedia, que especifican exactamente cuál es el comportamiento. Pero la idea es que, cuando el remitente se da cuenta de que sus datos ya no se transmiten porque faltan reconocimientos, reduce rápidamente su tasa de envío. Típicamente, lo divide por la mitad. Por lo tanto, lo reduce drásticamente y luego vuelve a aumentarlo.
En esencia, lo que esto significa es que la pérdida de paquetes es la función de señalización para "No podemos enviar los datos más rápido", y que los remitentes TCP en cada extremo de una conexión, en todo Internet, siempre son algo así como: " estamos tratando de ir más rápido que la velocidad máxima disponible entre los dos puntos finales, es decir, ese enlace más débil, donde sea que esté, y siempre lo están llevando al límite. Entonces, dado que hay un punto en algún lugar que es más débil que su capacidad para enviar paquetes, lo encontrarán porque bombearán paquetes. Siempre que haya datos para enviar y tengan una conexión de ancho de banda alto, el remitente aumentará la velocidad de envío, es decir, la cantidad de paquetes pendientes, los paquetes que pueden estar disponibles al instante como agradecimientos Vuelve, sigue moviendo agresivamente ese número hacia arriba hasta que lo empuja demasiado lejos. Luego retrocede mucho, y luego nuevamente avanza.
Entonces, esto es lo que realmente está sucediendo entre las conexiones TCP que, como, probablemente, no sé qué porcentaje, pero el mayor porcentaje de tráfico en Internet se realiza a través de conexiones TCP. Todos nuestros sistemas operativos en el núcleo, en la llamada pila TCP, tienen estos contadores. Y cuando enviamos un archivo, cuando cargamos un archivo grande o recibimos una página web, el servidor en el otro extremo está haciendo lo mismo. Impulsa, en una conexión individual, tantos paquetes que aún no se han confirmado como puede, aumentando la tasa de paquetes hasta que llega al punto en que comienza a fallar o tartamudear. Luego retrocede, para permitir que las cosas se recuperen, y luego comienza a funcionar nuevamente.
Y eso termina siendo una especie de sistema de auto-estrangulamiento que, dadas las limitaciones, quiero decir, realmente parece un poco funky y crudo ".