¿TCP aprovecha al máximo la capacidad de rendimiento de la red? ¿Por qué?

Teóricamente lo intenta, pero también tiene un mecanismo incorporado para controlar la congestión y, por lo tanto, no siempre puede aprovechar todo el potencial para aprovechar el ancho de banda disponible. Cuando el protocolo TCP elimina los datos de sus memorias intermedias en el cable, inicialmente hay una etapa llamada inicio lento. Durante el inicio lento, el número de paquetes transmitidos se duplica durante cada transmisión exitosa y la ventana de congestión sigue aumentando. Como habrás notado, si la conexión tcp es de corta duración, el protocolo de inicio lento será muy ineficiente para utilizar el ancho de banda (y de ahí su nombre “inicio lento”). Sin embargo, supongamos que la conexión tcp tiene una vida útil más larga, por lo que una vez que se cruza el umbral de inicio lento, pasa a otro modo llamado evitar la congestión. Ahora, en lugar de aumentar rápidamente la salida de datos, aumenta más de forma lineal. Esto sigue aumentando mientras se reciban los acuses de recibo de los paquetes. Sin embargo, una vez que se producen retransmisiones tres veces consecutivas, pasa a otro estado llamado recuperación rápida y la tasa de flujo de salida baja al umbral estándar. Tenga en cuenta aquí que las retransmisiones podrían no haber ocurrido debido a la plena realización del uso del ancho de banda (podría haber sucedido porque el recibido se redujo por cualquier motivo), pero tcp no tiene forma de saberlo y supone que el ancho de banda es el culpable y reduce su tasa de flujo de salida. Una vez que se produce un tiempo de espera para evitar la congestión o la recuperación rápida, vuelve a la fase de inicio lento. Entonces, teóricamente, se esfuerza por lograr usar el ancho de banda hasta su máximo potencial, pero en realidad está lejos de usarlo debido al diseño del protocolo en sí.

No, a propósito no lo hace. La experiencia inicial con TCP descubrió que cuando varios remitentes intentaban usar toda la capacidad de la red, causaban un cuello de botella que causaba tantas retransmisiones que el rendimiento real de los datos se reducía significativamente. TCP fue modificado (RFC 2001) y ahora ajusta su velocidad de transmisión y retransmisión en función de las métricas de congestión de la red.

Un Google de TCP Retransmit produce RFC 2001, 2581, 3390, 5681 y 6928, por lo que algunos ajustes al algoritmo se sugirieron hace tan solo un par de años.

No, no lo hace. UDP lo hace.