Las técnicas de ajuste de TCP ajustan los parámetros de prevención de congestión de la red en las conexiones del Protocolo de Control de Transmisión (TCP) en redes de gran ancho de banda y alta latencia . Las redes bien ajustadas pueden funcionar hasta 10 veces más rápido en algunos casos. [1] Sin embargo, seguir instrucciones ciegamente sin comprender sus consecuencias reales también puede afectar el rendimiento.
El producto de ancho de banda-retardo (BDP) es un término utilizado principalmente en conjunto con TCP para referirse a la cantidad de bytes necesarios para llenar una "ruta" TCP, es decir, es igual a la cantidad máxima de bits simultáneos en tránsito entre el transmisor y el receptor.
Las redes de alto rendimiento tienen BDP muy grandes. Para dar un ejemplo práctico, dos nodos que se comunican a través de un enlace satelital geoestacionario con un tiempo de retardo de ida y vuelta (o round-trip time, RTT) de 0,5 segundos y un ancho de banda de 10 Gbit/s pueden tener hasta 0,5×10 Gbits , es decir, 5 Gbit de datos no reconocidos en vuelo. A pesar de tener latencias mucho más bajas que los enlaces satelitales, incluso los enlaces de fibra terrestre pueden tener BDP muy altos porque su capacidad de enlace es muy grande. Los sistemas operativos y protocolos diseñados hace tan solo unos años, cuando las redes eran más lentas, estaban ajustados para BDP de órdenes de magnitud más pequeños, con implicaciones para el rendimiento alcanzable limitado.
Las configuraciones TCP originales admitían búferes de tamaño de ventana de recepción TCP de hasta 65 535 (64 KiB - 1) bytes, lo que era adecuado para enlaces lentos o enlaces con RTT pequeños. Las opciones de alto rendimiento que se describen a continuación requieren búferes más grandes.
El almacenamiento en búfer se utiliza en todos los sistemas de redes de alto rendimiento para gestionar los retrasos del sistema. En general, el tamaño del búfer deberá escalarse proporcionalmente a la cantidad de datos "en tránsito" en cualquier momento. Para aplicaciones de muy alto rendimiento que no son sensibles a los retrasos de la red, es posible interponer grandes retrasos de almacenamiento en búfer de extremo a extremo colocando puntos de almacenamiento de datos intermedios en un sistema de extremo a extremo y luego utilizar transferencias de datos automatizadas y programadas que no sean en tiempo real para hacer llegar los datos a sus puntos finales.
El rendimiento máximo alcanzable para una única conexión TCP está determinado por distintos factores. Una limitación trivial es el ancho de banda máximo del enlace más lento de la ruta. Pero también hay otros límites menos obvios para el rendimiento TCP. Los errores de bit pueden crear una limitación para la conexión, así como para el RTT.
En redes informáticas , RWIN (Ventana de recepción TCP) es la cantidad de datos que una computadora puede aceptar sin reconocer al remitente. Si el remitente no ha recibido el acuse de recibo del primer paquete que envió, se detendrá y esperará y, si esta espera excede un cierto límite, incluso puede retransmitir . Así es como TCP logra una transmisión de datos confiable .
Incluso si no hay pérdida de paquetes en la red, el uso de ventanas puede limitar el rendimiento. Debido a que TCP transmite datos hasta el tamaño de la ventana antes de esperar los acuses de recibo, es posible que no siempre se utilice todo el ancho de banda de la red. La limitación causada por el tamaño de la ventana se puede calcular de la siguiente manera:
donde RWIN es la ventana de recepción TCP y RTT es el tiempo de ida y vuelta de la ruta.
En cualquier momento dado, la ventana anunciada por el lado receptor de TCP corresponde a la cantidad de memoria de recepción libre que ha asignado para esta conexión. De lo contrario, se correría el riesgo de perder los paquetes recibidos por falta de espacio.
El lado emisor también debe asignar la misma cantidad de memoria que el lado receptor para un buen rendimiento. Esto se debe a que, incluso después de que se hayan enviado los datos en la red, el lado emisor debe mantenerlos en la memoria hasta que se haya confirmado su recepción exitosa, en caso de que deba retransmitirse. Si el receptor está lejos, los acuses de recibo tardarán mucho tiempo en llegar. Si la memoria de envío es pequeña, puede saturarse y bloquear la emisión. Un cálculo simple arroja el mismo tamaño de memoria de envío óptimo que el tamaño de memoria de recepción indicado anteriormente.
Cuando se produce una pérdida de paquetes en la red, se impone un límite adicional a la conexión. [2] En el caso de una pérdida de paquetes de leve a moderada cuando la tasa de TCP está limitada por el algoritmo de evitación de congestión , el límite se puede calcular de acuerdo con la fórmula (Mathis, et al.):
donde MSS es el tamaño máximo del segmento y P loss es la probabilidad de pérdida de paquetes. Si la pérdida de paquetes es tan poco frecuente que la ventana TCP se extiende por completo de forma regular, esta fórmula no se aplica.
A lo largo de los años se han realizado varias ampliaciones al protocolo TCP para aumentar su rendimiento en enlaces rápidos de alto RTT ("redes largas y pesadas" o LFN).
Las marcas de tiempo TCP (RFC 1323) cumplen una doble función: evitan ambigüedades debido a la superposición de campos de números de secuencia de 32 bits y permiten una estimación más precisa del RTT en presencia de múltiples pérdidas por RTT. Con esas mejoras, resulta razonable aumentar la ventana TCP más allá de los 64 kB, lo que se puede hacer utilizando la opción de escalado de ventana (RFC 1323).
La opción de reconocimiento selectivo TCP (SACK, RFC 2018) permite que un receptor TCP informe con precisión al emisor TCP sobre qué segmentos se han perdido. Esto aumenta el rendimiento en enlaces con RTT alto, cuando es posible que se produzcan múltiples pérdidas por ventana.
Path MTU Discovery evita la necesidad de fragmentación dentro de la red , lo que aumenta el rendimiento en presencia de pérdida de paquetes.
La longitud de cola de IP predeterminada es 1000, que generalmente es demasiado grande. Imagine una estación base Wi-Fi que tenga una velocidad de 20 Mbit/s y un tamaño de paquete promedio de 750 bytes. ¿Qué tan grande debería ser la cola de IP? Un cliente de voz sobre IP debería poder transmitir un paquete cada 20 ms. El número máximo estimado de paquetes en tránsito sería entonces:
Tamaño de búfer estimado = 20000000 * 0,020 / 8 / 750 = 66
Una mejor longitud de cola sería:
ifconfig wlan0 mtu 1492 txqueuelen 100
